Cómo monitorear robots RPA en producción

Durante bastante tiempo, en nuestros propios proyectos, quien avisaba que un robot había fallado era el cliente. Nos escribía preguntando por qué el reporte no había llegado, y recién ahí mirábamos. Es el estándar real de buena parte de la industria y no aparece en ninguna propuesta comercial: el robot se entrega, se firma la marcha blanca, y el monitoreo queda como una promesa vaga de "hacemos seguimiento".

Ese hueco es donde se pierde el ROI que se prometió en el kick-off. Un robot que falla sin avisar deja al área usuaria haciendo a mano lo que ya daba por resuelto, y el retrabajo de esos días se recupera sin drama. Lo que cuesta caro es la conversación que viene después, cuando alguien de la dirección pregunta para qué se pagó la automatización.

Un robot no se cae como se cae un sistema

Cuando se cae un ERP, todos se enteran en cinco minutos porque nadie puede trabajar. Un robot no da esa señal. Sigue "corriendo" mientras hace cualquiera de estas cosas:

• Se queda esperando un elemento de pantalla que ya no existe, y ahí queda hasta que alguien lo mate.
• Descarga un archivo vacío porque el portal del banco cambió el flujo de login, y carga cero registros sin error.
• Procesa la mitad del lote y aborta, dejando el sistema destino en un estado intermedio.
• Termina con estado "OK" habiendo saltado una validación que nadie declaró como obligatoria.

El último de la lista es el que más caro sale. Una caída visible genera un ticket y se atiende ese mismo día; los datos mal cargados que nadie detectó hasta el cierre obligan a rastrear hacia atrás qué registros tocó el robot y cuáles quedaron a medias.

Nos pasó una variante fea de esto en el servidor de un cliente. El robot se colgaba entre pasos sin patrón, y ni el equipo de TI ni nosotros encontrábamos nada en los logs de firewall. Resultó ser el antivirus corporativo, que intercepta todo el tráfico TCP como proxy invisible, incluido el tráfico local del puerto que usa Rocketbot internamente. No aparecía como bloqueo en ningún registro porque técnicamente no bloqueaba nada, dejaba conexiones a medio procesar. El robot no tenía ningún defecto y la causa vivía en el entorno donde corría, que es justamente el tipo de problema que un monitoreo armado solo alrededor del resultado de negocio te devuelve como "el robot falla a veces", o sea como nada, y termina diagnosticándose por adivinanza.

Qué hay que mirar, más allá de si corrió

La primera capa es obvia y aun así falta en muchas implementaciones: ejecución iniciada, ejecución terminada, con qué resultado. Si tienes eso registrado con hora y duración ya estás mejor que la mayoría.

Después viene lo que separa un tablero decorativo de uno útil: el volumen procesado en cada corrida, comparado contra lo que esa corrida suele procesar. Un robot de facturación que venía cargando el lote completo y de golpe cierra en verde con un puñado de documentos no está bien, por más que no haya marcado error. La duración cumple la misma función de aviso temprano: cuando una corrida empieza a tardar bastante más que su promedio histórico, algo cambió del otro lado, y eso se nota semanas antes de que el robot se caiga del todo.

El conteo de excepciones es la métrica que más terminamos mirando en los procesos con revisión humana. Ahí lo que se sigue de cerca es cuántos documentos pasaron derecho y cuántos quedaron esperando a una persona, porque el total que entró dice poco por sí solo. Si esa proporción se mueve, hay una causa concreta detrás, casi siempre un proveedor nuevo o un formato que cambió. Escribimos sobre ese efecto en el artículo de procesamiento inteligente de documentos.

La alerta que le llega a la persona equivocada no sirve

El error de diseño más común que veo es de destinatario: la alerta va al correo del desarrollador que construyó el robot, que puede estar de vacaciones, en otro proyecto o directamente fuera de la empresa si el desarrollo se contrató por proyecto cerrado.

La regla que aplicamos ahora es simple: cada robot en producción tiene un dueño del proceso del lado del cliente, y la alerta de negocio le llega a esa persona en el idioma del negocio. "El robot de conciliación no terminó su corrida de las 9:00" le sirve a un jefe de tesorería para decidir qué hace con el cierre del día; un stack trace de Python le llega igual de rápido y no le dice nada accionable. El detalle técnico va al canal técnico, en paralelo, y no reemplaza al aviso funcional.

Conviene además definir alertas por ausencia de ejecución. Si el robot debía correr a las 6:00 y a las 6:30 no hay ningún registro, eso tiene que avisar. Los fallos que más tardan en detectarse son los que ocurren antes de que el robot arranque: el servidor se reinició por una actualización, la tarea programada quedó deshabilitada, la contraseña de servicio expiró.

Dónde entra Robotipy Monitor

Monitor es la herramienta que armamos para no depender de que alguien se acuerde de mirar. Muestra el estado de cada worker (si está libre, ocupado o caído), los jobs que se ejecutaron con su resultado y su duración, los logs de cada corrida sin tener que entrar a la máquina a buscarlos, y las métricas acumuladas del período. Cuando un robot no se ejecuta, o se ejecuta y no hace lo que corresponde, sale un correo sin que nadie tenga que estar frente a la pantalla.

Ese último punto es el que más se subestima. Un log suelto te sirve para diagnosticar el incidente de hoy; la serie de las últimas cuarenta corridas es la que te muestra que el robot viene tardando cada vez más o que las excepciones se dispararon desde que el proveedor cambió el formato. Los problemas de producción rara vez aparecen de golpe, se degradan, y esa degradación solo se ve mirando el histórico.

Para un gerente el valor está en que el registro queda: cuando alguien pregunta cuántas veces falló el robot este trimestre, hay una respuesta con fecha y hora en lugar de una impresión. Esa misma trazabilidad es la que permite discutir el ROI seis meses después de la puesta en producción usando las corridas reales del período, que es la única forma de que esa conversación no termine siendo un intercambio de percepciones.

Cuándo esto es sobreingeniería

Si tienes un robot, corre una vez por semana y hay una persona que lo lanza y mira el resultado en el momento, no necesitas una plataforma de monitoreo. Un correo de fin de ejecución con el resumen alcanza y sobra. Montar un tablero para eso es agregar una pieza que alguien tiene que mantener.

El punto de quiebre llega antes de lo que la gente cree, eso sí. Con tres o cuatro robots corriendo en horarios distintos, algunos de madrugada, ya nadie está mirando cuando pasa lo que tiene que pasar. Ahí el monitoreo deja de ser una comodidad. Si además el proceso automatizado toca dinero, inventario o algo que se reporta hacia afuera, yo no lo pondría en producción sin alertas configuradas, por más chico que sea el volumen.

Antes de poner el robot en producción

Dos cosas que conviene cerrar antes del pase, porque después nunca se hacen: definir por escrito qué se considera una corrida exitosa, con volumen y salida esperados, ya que "que no dé error" es un criterio demasiado flojo para operar; y dejar documentado quién recibe cada tipo de alerta. Lo segundo suena administrativo y es lo que decide si un fallo se atiende el mismo día o queda dando vueltas hasta que lo escala el usuario. Va de la mano de documentar el proceso antes de automatizarlo, que es la otra tarea que todos posponen y todos terminan pagando.

Preguntas frecuentes

Para seguir

Si estás por poner tu primer robot en producción, vale la pena revisar los errores comunes al implementar RPA y cómo se estructura el costo de un proyecto en cuánto cuesta automatizar un proceso. Dejar el monitoreo configurado antes del pase a producción cuesta bastante menos trabajo que rastrear después qué hizo mal un robot durante las semanas en que nadie lo estuvo mirando.