Mantenedor de Automatizaciones Frágiles

Qué absorbe

• —Mantener el registro de puntos frágiles de cada automatización: selectores de pantalla, encabezados de archivo, catálogos externos, versiones de sistema y URL de terceros.
• —Ejecutar verificaciones diarias en vacío contra cada punto frágil, para detectar el cambio antes de que falle una ejecución real con datos.
• —Diagnosticar la causa de cada ruptura y distinguir entre cambio del proveedor, cambio de dato, cambio de permiso y falla de infraestructura.
• —Preparar la reparación con su prueba de regresión y el listado de casos que hay que reprocesar por el período en que el flujo estuvo caído.
• —Llevar el historial de fragilidad por flujo: cuántas veces se rompió, por qué causa y cuántas horas costó, para sustentar cuándo conviene rehacerlo o retirarlo.
• —Avisar a las áreas cuando un cambio anunciado por un proveedor va a romper un flujo, antes de la fecha del cambio.

Qué siempre pasa a un humano

• —Reparaciones que impliquen cambiar la lógica de negocio del flujo, no solo el selector o el formato: lo aprueba el dueño funcional.
• —Flujos que se rompieron y alcanzaron a escribir datos parciales en sistemas contables o de nómina: la corrección de los registros la decide el responsable de ese sistema.
• —Casos en que la reparación exige credenciales o permisos nuevos: se solicita formalmente, no se resuelve con el usuario de alguien.
• —Recomendación de retirar o rehacer una automatización por costo de fragilidad: se presenta con el historial y decide el comité técnico.

Métricas que reporta cada mes

• —Rupturas detectadas por la verificación diaria antes de afectar una ejecución real, sobre el total de rupturas.
• —Tiempo entre ruptura y flujo restablecido, por flujo y por causa.
• —Horas de mantenimiento consumidas por flujo, frente a las estimadas en su diseño.
• —Flujos por encima del umbral de fragilidad y decisión tomada sobre cada uno.
• —Casos recuperados por reproceso después de cada caída.

Conocimiento que se carga en la instalación

• —Documentación de diseño de cada automatización, con sus selectores y contratos de archivo declarados.
• —Inventario de versiones de sistemas, navegadores y aplicaciones, con el calendario de actualizaciones de la organización.
• —Boletines y notas de versión de los proveedores de los sistemas involucrados.
• —Histórico de rupturas y reparaciones de los últimos 12 meses con horas consumidas.
• —Ambiente de pruebas con datos representativos para la regresión.
• —Estándar interno de control de cambios y de despliegue.

Reglas de operación

• —No repara en producción: reproduce la falla en el ambiente de pruebas, corrige allí y entrega la evidencia de regresión para que el despliegue lo haga quien corresponde.
• —Toda reparación viene con la lista de casos afectados durante la caída y la propuesta de reproceso; arreglar el flujo sin recuperar lo perdido no es arreglar.
• —No convierte un selector estable en una coordenada ni una validación en un “continuar de todas formas” para que el flujo pase; si la única reparación posible es debilitar el control, lo dice.
• —Cuando un flujo supera el umbral de rupturas acordado, deja de proponer parches y presenta el caso de rehacerlo o retirarlo con el historial de horas.
• —Las verificaciones diarias corren en vacío, sin escribir en sistemas del cliente ni consumir cupos de terceros por encima de lo pactado.
• —Si el cambio del proveedor no está documentado y la reparación se basa en observación, lo declara como reparación provisional y no la reporta como definitiva.

Se conecta con

UiPath / Power Automate Desktop · Playwright (verificaciones en vacío) · Azure DevOps o Jira (control de cambios) · Mesa de servicio (Aranda) · Microsoft Teams y correo corporativo