La mayoría de las automatizaciones muere en el tercer mes

Los proyectos de automatización fallidos tienen una forma reconocible. El desarrollo va bien. La demo gusta. Funciona unas semanas. Luego algo aguas arriba cambia de formato, el proceso falla en silencio, una semana después alguien nota que los números no cuadran y el equipo vuelve discretamente a la hoja de cálculo de siempre mientras alguien abre un ticket que nadie recoge.

El sistema sigue ahí. Simplemente no se usa y, con el tiempo, nadie recuerda que existe. Sobre el papel el proyecto se entregó. En la práctica compró tres semanas de alivio.

Casi nada de esto es un problema de calidad del desarrollo. Es un problema de responsabilidad. La agencia que lo construyó ya está con otro cliente, el equipo interno nunca llegó a entenderlo del todo y lo que lo habría salvado, que alguien detectara el fallo en una hora en lugar de en una semana, no era tarea de nadie.

Las soluciones son poco vistosas. Alertas que llegan a una persona de la que se espera una respuesta, no a un canal que nadie lee. Runbooks escritos para quien no construyó el sistema. Un responsable con nombre al que se pueda localizar en el sexto mes. Modos de fallo que se detienen ruidosamente en vez de seguir con datos malos, porque un fallo parcial silencioso hace mucho más daño que una caída limpia.

Esa es buena parte de por qué nos quedamos integrados y operamos lo que construimos. No porque los clientes no puedan hacerlo, sino porque el traspaso es donde estos proyectos suelen morir, y saber que la alerta nos va a sonar a nosotros nos hace construirlo distinto desde el principio.