El modelo mental de la automatización

Todas las herramientas de automatización son la misma herramienta con distinta piel. Cuando entiendes las cinco piezas de las que están hechas, cambiar de una a otra es cuestión de una tarde, y ninguna migración te pilla a contrapié.

Esas cinco piezas son: disparador, pasos, datos, condiciones y errores.

El disparador: qué pone esto en marcha

Toda automatización empieza porque pasa algo. Hay tres formas, y elegir mal es el fallo de principiante más caro.

Por tiempo. Cada hora, cada noche, cada lunes. Es la más simple y la más robusta. Si no sabes cuál usar, empieza por aquí.

Por aviso externo. Un servicio te avisa en el momento en que ocurre algo: ha entrado un formulario, se ha pagado una factura. Es inmediato y no gasta recursos esperando. A cambio, si tu sistema está caído cuando llega el aviso, el aviso se pierde. Muchos servicios reintentan, otros no.

Por comprobación periódica. Miras cada X minutos a ver si hay algo nuevo. Es lo más pesado y lo más tolerante a fallos: si estabas caído, en la siguiente vuelta lo recoges.

La regla práctica: usa avisos externos cuando la inmediatez importe y comprobación periódica cuando la fiabilidad importe más. Y si usas avisos, ten claro qué pasa con los que lleguen mientras estés caído — porque vas a estar caído alguna vez.

Los pasos: una cosa cada uno

Un paso hace una cosa: leer, transformar, decidir, escribir, avisar. La tentación es meter tres cosas en un paso porque «así son menos». No lo hagas: el día que falle, quieres saber exactamente cuál de las tres.

El orden mental que funciona es siempre el mismo: traer los datos → limpiarlos → decidir → actuar → registrar. Si tu flujo no se puede describir así, probablemente estés mezclando dos automatizaciones distintas en una.

Los datos: aquí es donde se va el tiempo

Esto es lo que nadie te cuenta: el 80 % del trabajo real de automatizar no es lógica, es dar forma a los datos. Lo que sale de un sitio nunca tiene la forma que necesita el siguiente. Fechas en tres formatos distintos, nombres con espacios de más, campos que unas veces vienen y otras no, listas dentro de listas.

Dos hábitos que te ahorran horas:

Mira siempre lo que sale de cada paso antes de escribir el siguiente. Todas las herramientas serias te dejan ver el resultado intermedio. La gente que no lo mira se pasa las tardes adivinando.

Normaliza pronto. En cuanto entren los datos, conviértelos a una forma tuya, estable, con los campos que tú decides y los nombres que tú eliges. A partir de ahí el resto del flujo trabaja con algo predecible, y el día que cambies de proveedor solo tocas el primer paso.

Las condiciones: donde se bifurca

Poco que explicar y mucho que vigilar: si esto, entonces aquello. El problema no son las condiciones, es el camino que no previste. ¿Qué pasa si el campo viene vacío? ¿Y si viene con un valor que no habías visto nunca?

Diseña siempre con una salida por defecto que no sea «no hacer nada en silencio». Que avise. Un flujo que se traga los casos raros sin decir nada es un flujo que te va a explotar delante de un cliente.

Los errores: la parte que separa el juguete del servicio

Una automatización que funciona cuando todo va bien la monta cualquiera en una tarde. Lo que se cobra es que siga funcionando cuando algo va mal — y algo va mal constantemente: un servicio no responde, se acaba la cuota, un dato llega corrupto, se cae internet diez minutos.

Cuatro decisiones que tienes que tomar antes de entregar nada:

Qué se reintenta y cuántas veces. Un fallo de red se reintenta. Un dato mal formado, no: se reintentará mal eternamente.

Qué es urgente y qué puede esperar. No todo merece despertarte.

Quién se entera. Si falla y nadie lo sabe, el sistema lleva tres semanas sin funcionar y tu cliente lo va a descubrir antes que tú. Eso destruye la confianza más rápido que el propio fallo.

Qué queda registrado. Cuándo se ejecutó, con qué entrada, qué salió. Sin registro no hay diagnóstico posible, solo conjeturas.

La regla de la reversibilidad

Antes de que una automatización actúe sobre el mundo real —mandar correos, cobrar, borrar—, pregúntate: si esto se ejecuta mal cien veces seguidas, ¿qué pasa?

Si la respuesta es «cien correos raros a cien clientes», necesitas un freno: un límite de ejecuciones, un modo de prueba, o una revisión humana antes del envío.

Es la diferencia entre un fallo que se arregla y uno que cuesta un cliente. Y ocurre más de lo que parece, porque los bucles son fáciles de escribir mal.