Cómo saber que una automatización ha fallado

Una automatización que lleva meses funcionando sin que nadie diga nada admite dos lecturas: que funciona, o que dejó de funcionar y nadie se ha dado cuenta. Desde fuera son indistinguibles, porque un proceso automatizado no se queja: no avisa de que va desbordado, no pregunta cuando algo no le cuadra y no pide ayuda. La decisión de este artículo es qué control mínimo exigir a cualquier proceso automatizado —lo construya un proveedor, tu equipo o tú mismo— antes de darlo por terminado. No hace falta un sistema de monitorización sofisticado; hace falta poder responder a una pregunta: si esto falla mañana, ¿cómo me entero y cuánto tardo?

El silencio no es éxito

Cuando un proceso lo ejecuta una persona, el fallo tiene síntomas: alguien pregunta, algo se queda a medias, se nota en la conversación del día a día. Al automatizar eliminas también al testigo. El trabajo se hace solo, y el silencio —que en un equipo suele ser buena señal— se vuelve ambiguo: puede significar «todo en orden» o «nadie está mirando».

Por eso muchas automatizaciones se dan por terminadas el peor día posible: el día que empiezan a funcionar. En realidad, ese día empieza su vida, y la pregunta pasa de «¿funciona?» a «¿cómo sabremos que sigue funcionando?». Esa segunda pregunta casi nunca aparece en la entrega, y es la que separa una automatización operable de una bomba de relojería educada.

Las tres formas de fallar (y solo una hace ruido)

Un proceso automatizado puede fallar de tres maneras, y no son igual de visibles.

Se para. Deja de ejecutarse: las facturas no salen, los pedidos no se registran. Es el fallo más aparatoso y, paradójicamente, el menos peligroso, porque antes o después alguien echa en falta el resultado.

Sigue funcionando, pero mal. El fichero de origen cambió de formato, una columna se renombró, y ahora el proceso mete importes en el campo equivocado o asigna clientes al comercial que no toca. Todo parece en marcha; el daño se acumula en silencio y se descubre semanas después, cuando ya está repartido por todas partes.

Funciona a medias. Procesa una parte y descarta otra sin que nadie lo sepa: los casos que no encajan en la regla se quedan por el camino. Es el fallo más lento de detectar, porque el resultado visible existe; solo está incompleto.

La mayoría de los disgustos caros vienen de las dos últimas. Un control que solo detecta paradas está vigilando la forma de fallar menos probable de hacer daño.

El control mínimo: avisos, registro y un responsable

No hace falta infraestructura nueva. Hacen falta tres cosas, y las tres caben en cualquier proyecto.

Avisos que llegan a alguien

El proceso debe avisar cuando algo va mal, y también cuando no pasa nada debiendo pasar algo. Si cada mañana debería procesar pedidos y hoy no ha procesado ninguno, eso no es un día tranquilo: es un aviso. El aviso por ausencia es el que detecta las paradas silenciosas, y casi nunca viene de serie. Y un matiz que parece obvio hasta que falla: un aviso que llega a un buzón que nadie abre no es un aviso, es un archivo.

Un registro de lo que ha hecho

Tiene que quedar constancia de qué procesó, cuándo y con qué resultado, en un sitio que alguien de la casa pueda consultar. No por burocracia: porque el día que un cliente pregunte «¿y mi factura?», la diferencia entre responder en minutos o abrir una investigación es ese registro. También es lo que permite detectar el fallo parcial: comparar lo que entró con lo que salió.

Un responsable con nombre

Alguien concreto mira los avisos y sabe que le toca mirarlos. Sin dueño, los avisos se degradan a ruido en cuestión de semanas: todos los ven, nadie los atiende. No hace falta que sea quien construyó la automatización; hace falta que sepa qué es normal, qué no, y a quién llamar cuando algo no lo es.

La pregunta que ordena todo lo demás

Si hay que quedarse con un solo criterio, es este: para cada forma de fallar, ¿quién se entera primero, tú o tu cliente? Si la respuesta honesta es «nos llamará el cliente», el control es insuficiente, porque estás usando a tus clientes como sistema de alarma. Es el sistema más caro que existe: cada aviso cuesta confianza.

En procesos internos la pregunta tiene su versión: ¿me entero del fallo antes de que el dato erróneo llegue a una decisión? Un informe automatizado que se equivoca no hace daño cuando falla, sino cuando alguien decide con él.

Cinco preguntas antes de dar por buena una automatización

1. Si se para esta noche, ¿quién se entera, por qué vía y cuándo?
2. Si sigue funcionando pero con datos erróneos, ¿qué lo detectaría?
3. ¿Avisa también cuando no pasa nada y debería pasar algo?
4. ¿Puede alguien de la casa reconstruir qué hizo —y qué no hizo— la semana pasada?
5. ¿Hay un responsable con nombre que mira los avisos y sabe que le toca?

Si alguna respuesta es «no lo sé», ese es el trabajo pendiente, y conviene hacerlo antes del primer susto. Nada de esto es un extra que se añade si sobra presupuesto: es parte de la automatización, igual que los frenos son parte del coche. Cuando encargues una, pídelo en la entrega; cuando ya la tengas funcionando sin nada de esto, considéralo la primera mejora, no la última. Mantener vivo un proceso automatizado es trabajo continuo, y es exactamente el tipo de trabajo que cubre un buen soporte: no esperar a que algo se rompa, sino saber antes que nadie que se ha roto.