De 1 robot a un Centro de Excelencia (CoE) de automatización

La consulta casi siempre nos llega de la misma manera. Una empresa automatizó dos o tres procesos con buenos resultados, la dirección pidió un plan para el año siguiente y, mientras tanto, llegó el PDF de una consultora grande que propone montar un Centro de Excelencia como próximo paso. Entonces nos escriben para preguntar cómo armarlo.

Mi respuesta suele decepcionar un poco: con tres robots no hace falta un CoE. Lo urgente es dejar por escrito lo que hoy solo sabe una persona, un trabajo mucho menos vistoso que diseñar una estructura formal. Esa estructura viene después, y en muchas empresas medianas nunca llega a justificarse, algo que ningún proveedor tiene incentivo para decirte.

Qué se rompe entre el robot 1 y el robot 5

El primer robot no tiene problemas de escala. Lo desarrolla una persona, corre en una máquina y, cuando falla, lo arregla quien lo hizo. Todo el conocimiento del proyecto cabe en una conversación.

Al llegar al quinto robot aparecen estos problemas, casi siempre en este orden:

• Nadie sabe cuántos robots hay en producción. Pregúntalo en una reunión y es probable que salgan tres cifras distintas, porque alguien cuenta el que quedó instalado en el equipo de un analista que ya se fue de la empresa.
• Cada robot está construido de forma distinta, así que cualquier cambio obliga a entenderlo desde cero. El primero lo hizo un proveedor, el segundo un consultor independiente y el tercero un desarrollador interno que aprendió mirando los otros dos.
• La operación depende de una sola persona, que tiene las claves y sabe reiniciar los robots. Suele ser también la primera en enterarse de un fallo. Cuando sale de vacaciones, el programa completo se detiene.
• Se automatiza lo que pide quien más presiona. Sin un criterio de priorización escrito, el orden lo define la política interna y termina automatizado el proceso del gerente más insistente, aunque otro tuviera mejor retorno.
• Nadie puede decir cuánto se ahorró. El caso de negocio de cada robot se escribió para conseguir la aprobación y no se volvió a medir, de modo que a los dos años, cuando la dirección pregunta por el retorno del programa completo, no hay datos para responder.

Qué parte de un CoE necesitas con pocos robots

Ninguno de esos cinco problemas se resuelve con un comité. En nuestro rubro, buena parte de lo que se vende como "Centro de Excelencia" es una estructura de gobierno pensada para empresas con cincuenta o cien robots, ofrecida a empresas que tienen cuatro. Incluye comité de priorización, matriz RACI, una metodología propia con nombre registrado y roles como business analyst, solution architect, RPA developer y controller. En una empresa de trescientas personas, aprobar con ese esquema la automatización de un proceso de doce horas mensuales consume más horas de reunión que las que el robot ahorrará en su primer semestre.

Lo que sirve desde el primer robot son unas pocas decisiones operativas que alguien toma y deja por escrito: que todos los robots se construyan igual, que la operación tenga un responsable con nombre y apellido y que exista un registro de qué hace cada robot y quién responde por él. Nada de eso pide un organigrama. Una persona a medio tiempo puede sostenerlo hasta bastante más lejos de lo que se suele suponer, siempre que un solo equipo construya los robots y todos sirvan a una sola gerencia.

Estandarizar cómo se construyen los robots

Cuando cada robot está hecho al gusto de quien lo programó, el costo de mantenimiento crece más rápido que la cantidad de robots y el tercer año sale más caro que el primero. Estandarizar la construcción cuesta bastante menos que montar una estructura de gobierno y es la forma directa de contener ese costo.

En nuestros desarrollos, todos los robots que entregamos tienen la misma estructura. Un robot Principal orquesta el proceso. Initialization resuelve la copia local, la resolución de pantalla y las conexiones. Hay un bloque de Rutas, y EndProcess cierra, reporta y devuelve los archivos a su lugar. Los nombres de los robots van en PascalCase y las variables en snake_case, sin excepciones. Los parámetros que pueden cambiar sin tocar la lógica van en un configuracion.ini dentro de la carpeta de recursos, nunca escritos en el flujo. Cada proyecto tiene además su propia base SQLite local, donde queda el registro de lo que procesó.

Con esa estructura, un desarrollador que nunca vio el proyecto puede abrirlo con un incidente encima y saber en cinco minutos dónde buscar.

Si estás por sumar el cuarto robot y los tres primeros los hicieron proveedores distintos, define el estándar antes de encargarlo, mientras reescribir los existentes todavía cuesta una fracción de lo que costó hacerlos.

Quién hace qué cuando hay diez robots

Hay dos funciones que conviene separar pronto, aunque las cubra la misma persona: la operación diaria y la evolución del programa. Operar es revisar que las ejecuciones se hayan completado, atender el fallo del día y decidir si algo se reprocesa. Hacer crecer el programa exige analizar procesos nuevos y definir prioridades, que después se negocian con las áreas. Si ambas tareas quedan en la misma agenda, la operación desplaza a la evolución todas las semanas, hasta que el programa deja de sumar procesos.

También hay que distinguir la capa que programa las ejecuciones de la que las observa. Muchos equipos las confunden y creen que están monitoreando cuando solo cargaron los horarios. El orquestador (en nuestro caso, Rocketbot) agenda las ejecuciones y reparte el trabajo entre las máquinas disponibles. Robotipy Monitor muestra qué worker está activo, qué se ejecutó y qué falló, con sus logs y métricas.

Cuándo se justifica una estructura formal

No hay una cantidad de robots que marque ese momento. Ya no basta con una persona ordenada cuando se da alguna de estas condiciones:

• Hay más de un equipo desarrollando en paralelo.
• Los robots tocan sistemas transaccionales de más de un área, cada una con su propio dueño.
• Llegan más solicitudes de las que se pueden priorizar en una conversación de pasillo.

En ese punto, la estructura formal evita que dos desarrollos choquen sobre el mismo proceso. Mientras no llegues ahí, basta una hoja de cálculo al día con seis columnas: nombre del robot, proceso que ejecuta, área dueña, cuenta con la que se conecta, responsable de mantenerlo y fecha de la última revisión.

Explicamos esa hoja en detalle en seguridad y gobierno en proyectos de RPA, con foco en credenciales y permisos, que es lo que más rápido se descontrola cuando el programa crece.

Escalar sin medir el retorno

Cuando el primer robot logra un resultado visible, aparece la presión por sumar diez más en poco tiempo. Desde ahí, cada robot nuevo rinde menos que el anterior, porque los procesos se eligen para cumplir la cantidad de robots comprometida con la dirección.

En los diagnósticos que hacemos, cuando una empresa nos muestra su lista de procesos candidatos, es habitual que los tres primeros tengan un retorno claro y que del cuarto en adelante la cuenta se vuelva discutible. Sostener el criterio de selección en ese momento es incómodo, sobre todo si la meta ya se anunció. Si la empresa cede, el programa puede apagarse a los tres años con doce robots caros de mantener y poco ahorro que mostrar. Cómo hacer esa selección lo detallamos en cómo priorizar qué procesos automatizar primero.

Preguntas frecuentes

Siguientes pasos

Si tu empresa ya pasó del primer robot y está definiendo el plan, ordena primero el criterio y después la estructura. Los tropiezos más frecuentes están en errores comunes al implementar RPA, y la forma de armar la cuenta de un proyecto, en cuánto cuesta automatizar un proceso. Si quieres revisar tu caso con nosotros, escríbenos.