Por qué algunas automatizaciones empiezan a fallar después del go-live
Una automatización no termina cuando entra en producción. Interfaces, credenciales, reglas, aplicaciones, datos y volúmenes cambian constantemente. Sin monitoreo, gestión de incidentes, análisis de causa raíz y mejora continua, incluso una solución correctamente implementada puede degradarse con el tiempo.
La automatización funcionó correctamente durante UAT.
Entró en producción.
Las primeras ejecuciones fueron exitosas.
Tres meses después comienzan los incidentes.
Esta situación no significa necesariamente que la automatización haya sido mal desarrollada.
Significa que entró en un entorno que cambia constantemente.
Aplicaciones, datos, credenciales, infraestructura, reglas y volúmenes evolucionan.
Una automatización que permanece estática mientras su entorno cambia eventualmente puede dejar de comportarse como esperaba.
Producción es un entorno dinámico
Durante el desarrollo existe un contexto relativamente controlado.
En producción existen dependencias reales.
Una automatización puede depender simultáneamente de:
- ERP.
- Correo electrónico.
- Portales externos.
- Archivos.
- APIs.
- Bases de datos.
- Credenciales.
- Servidores.
- Reglas empresariales.
- Personas.
Cada dependencia puede cambiar independientemente.
Por eso la estabilidad de una automatización no depende solamente de su código.
Depende del ecosistema completo.
1. Cambios en las aplicaciones
Uno de los motivos clásicos de fallo ocurre cuando cambia una aplicación.
Puede modificarse:
- Una pantalla.
- Un selector.
- Una URL.
- Un menú.
- Una política de autenticación.
- Un formulario.
- Una versión del sistema.
Las automatizaciones basadas en interfaz gráfica pueden ser especialmente sensibles a este tipo de cambios.
Una modificación menor para un usuario puede ser significativa para un robot.
2. Cambios en los datos
El formato de la información también evoluciona.
Una columna adicional.
Una fecha diferente.
Un código nuevo.
Un campo anteriormente obligatorio que ahora puede venir vacío.
Una automatización puede continuar ejecutándose técnicamente y producir un resultado incorrecto porque su lógica ya no refleja los datos actuales.
3. Credenciales y permisos
Contraseñas que expiran.
Tokens revocados.
Políticas de seguridad modificadas.
Roles eliminados.
Accesos restringidos.
Muchas fallas aparentemente inexplicables terminan siendo problemas de autorización.
Por eso la gestión de identidades y credenciales debe formar parte de la operación de la solución.
4. Aumento de volumen
Una automatización diseñada para procesar 5.000 transacciones puede comenzar a enfrentar dificultades cuando el volumen aumenta a 40.000.
Pueden aparecer:
- Tiempos de ejecución excesivos.
- Ventanas operativas insuficientes.
- Límites de API.
- Bloqueos.
- Colas acumuladas.
- Problemas de infraestructura.
La escalabilidad debe revisarse a medida que cambia la operación.
5. Excepciones que no existían durante el diseño
Ningún proceso permanece completamente estable.
Aparecen nuevos productos.
Nuevos clientes.
Nuevos países.
Nuevas reglas.
Nuevos tipos de documentos.
Las excepciones que originalmente representaban 1% del volumen pueden crecer hasta convertirse en una parte significativa del proceso.
El modelo de excepción también necesita evolucionar.
El problema de las automatizaciones silenciosas
El peor escenario no siempre es que una automatización se detenga.
Un fallo visible genera una alerta.
Más peligroso es cuando la automatización continúa ejecutándose y el resultado comienza a desviarse.
Por ejemplo:
- Omite transacciones.
- Procesa información incorrecta.
- Genera datos incompletos.
- Clasifica incorrectamente.
- Actualiza solamente parte del sistema.
Por eso monitorear únicamente si el robot está "running" ofrece una visión insuficiente.
Qué debería monitorearse
Dependiendo del proceso, conviene observar:
- Ejecuciones completadas.
- Tasa de éxito.
- Transacciones procesadas.
- Transacciones fallidas.
- Excepciones.
- Duración promedio.
- Backlog.
- Cambios de volumen.
- Comportamiento anómalo.
- Errores por aplicación.
Los indicadores técnicos y los indicadores de negocio deben complementarse.
Incident Management no es mantenimiento reactivo
Cuando aparece un incidente, resolverlo rápidamente es importante.
Pero también debe registrarse:
- Qué ocurrió.
- Cuándo.
- Qué proceso fue afectado.
- Cuántas transacciones.
- Cuál fue la solución.
- Si existe riesgo de repetición.
Esto permite diferenciar un incidente aislado de un problema estructural.
Root Cause Analysis
Reiniciar una automatización puede resolver una ejecución.
No necesariamente resuelve la causa.
Si el mismo incidente ocurre repetidamente, se necesita Root Cause Analysis.
La pregunta cambia de: ¿cómo recuperamos esta ejecución?
A: ¿por qué está ocurriendo esto y cómo evitamos que vuelva a ocurrir?
Ese cambio reduce el mantenimiento acumulativo.
Problem Management
Cuando varias incidencias tienen una causa común, debe tratarse el problema de fondo.
Puede ser necesario:
- Modificar arquitectura.
- Mejorar validaciones.
- Cambiar una integración.
- Actualizar lógica.
- Incorporar alertas.
- Eliminar una dependencia frágil.
El objetivo es aumentar resiliencia, no solamente cerrar tickets.
Change Management
Una automatización productiva es un activo tecnológico.
Y cualquier modificación debería administrarse.
Eso significa conocer qué cambió, por qué, quién lo aprobó, qué fue probado, qué versión está activa y cómo volver atrás si aparece un problema.
Realizar cambios directamente en producción sin control puede convertir una solución estable en una fuente de riesgo.
Continuous Improvement
El mantenimiento no debería limitarse a evitar fallos.
Una automatización también puede mejorar.
Después del go-live se puede identificar nueva capacidad, más transacciones automatizables, excepciones que ahora pueden resolverse, oportunidades de integración, nuevas capacidades de IA y mejoras de performance.
Una automatización debería evolucionar junto con el proceso.
El go-live no es el final del ciclo
Una visión limitada considera:
Diseñar → desarrollar → implementar → terminar.
Una visión sostenible considera:
Descubrir → optimizar → desarrollar → probar → implementar → operar → medir → mejorar.
La diferencia está en asumir que la automatización se convertirá en parte de la operación real del negocio.
Y todo sistema que opera el negocio necesita gestión durante su ciclo de vida.
