Automatizar sin romper: el proceso antes que la herramienta

No, automatizar primero y ajustar después casi nunca funciona: si el proceso manual ya tenía huecos, ambigüedades o excepciones no documentadas, automatizarlo no los resuelve, los reproduce a mayor velocidad y con menos gente vigilando. La regla que aplicamos siempre es sencilla de enunciar y difícil de respetar bajo presión: primero se entiende el proceso completo, con sus casos raros incluidos, y solo después se decide qué herramienta lo ejecuta.

¿Por qué automatizar un proceso mal definido sale mal?

Un proceso manual mal definido sobrevive porque una persona rellena los huecos con criterio en tiempo real: “esta factura es rara, mejor la reviso antes de enviarla”, “este cliente siempre pide el descuento por otro canal, se lo aplico manualmente”. Esas decisiones no suelen estar escritas en ningún manual, viven en la cabeza de quien lleva tiempo haciendo la tarea. Cuando se automatiza sin mapear esas excepciones, el sistema hace exactamente lo que el manual dice, no lo que la persona realmente hacía. El resultado no es un proceso más eficiente, es el mismo proceso roto, pero corriendo sin nadie que lo frene antes de que el error llegue al cliente.

Esto explica por qué tantos proyectos de automatización terminan generando más trabajo del que ahorran: alguien tiene que revisar cada salida del sistema porque nadie confía en él, y esa revisión manual es, de hecho, el mismo trabajo de antes con un paso intermedio añadido.

¿Qué hay que mapear antes de tocar ninguna herramienta?

El camino feliz, es decir, qué pasa cuando todo va bien, del paso uno al último. Esto suele estar claro y no es donde fallan los proyectos.

Las excepciones frecuentes, las que ocurren cada semana aunque no estén en ningún documento: el cliente que responde fuera de formato, el pedido que necesita aprobación especial, el dato que llega incompleto. Si una excepción ocurre más de una vez al mes, merece una regla explícita en el sistema automatizado, no un “ya lo revisamos a mano si pasa”.

Los puntos de no retorno, los momentos del proceso donde una vez ejecutada la acción no hay vuelta atrás fácil: enviar un email a un cliente, cobrar un pago, publicar contenido en un canal público. Ahí, casi siempre, conviene dejar una confirmación humana aunque el resto del flujo esté automatizado al cien por cien.

Quién es responsable si algo sale mal. No técnicamente —qué log revisar— sino organizativamente: qué persona recibe el aviso y qué autoridad tiene para pausar el sistema. Sin esto, un fallo detectado un viernes por la tarde puede seguir generando errores hasta el lunes.

¿Entonces la IA generativa hace más difícil automatizar, no más fácil?

Al contrario, pero con matices que conviene tener claros. Herramientas como Claude o GPT permiten automatizar pasos que antes exigían criterio humano puro —clasificar un email ambiguo, redactar una respuesta razonable, resumir un documento largo— y eso amplía muchísimo lo que se puede automatizar de verdad. El riesgo nuevo que introducen no es la falta de capacidad, es la falsa sensación de que, como el modelo “entiende lenguaje natural”, no hace falta definir el proceso con la misma precisión que antes. Es justo al revés: cuanto más flexible es la pieza que estás automatizando, más importa tener claros los límites de esa flexibilidad.

La herramienta no arregla un proceso confuso. Lo ejecuta más rápido, con la misma confusión dentro.

Quién debería mapear el proceso: ¿el equipo técnico o el equipo que lo ejecuta a diario?

Ni uno ni otro en solitario. El equipo técnico conoce las herramientas pero no las excepciones reales del día a día, esas que nunca llegaron a documentarse porque quien las resuelve lo hace de memoria. El equipo que ejecuta el proceso a diario conoce esas excepciones pero no siempre sabe qué es técnicamente automatizable y qué no. El mapeo previo funciona mejor como una conversación conjunta, con la persona que ejecuta el proceso describiendo casos reales de las últimas semanas —no casos hipotéticos— mientras quien diseña la automatización pregunta “¿y esto con qué frecuencia pasa?” hasta tener un mapa completo y priorizado por frecuencia real, no por lo llamativo del caso.

El orden correcto de trabajo

1. Documentar el proceso manual real, no el ideal que aparece en el manual de la empresa.
2. Listar las excepciones que ocurren con cierta frecuencia y decidir una regla explícita para cada una.
3. Identificar los puntos de no retorno y decidir dónde queda una confirmación humana.
4. Solo entonces, elegir la herramienta: automatización tipo n8n para la fontanería del flujo, un modelo de lenguaje para los pasos que requieren criterio sobre texto o contexto ambiguo, integraciones directas donde el paso es mecánico y determinista.
5. Probar con casos reales, incluidos los raros, antes de sustituir el proceso manual por completo.
6. Dejar un canal de aviso y una persona con autoridad para pausar el sistema si algo se desvía.

Este orden es más lento al principio que “conectar unas cuantas herramientas y ver qué pasa”, pero es el único que produce automatizaciones que siguen funcionando seis meses después sin que nadie tenga que estar revisando cada salida a mano.

Si tu equipo tiene un proceso que ya duele —demasiado manual, demasiado propenso a errores humanos, demasiado lento— pero no sabéis por dónde empezar a automatizarlo sin romper nada, ese mapeo previo es exactamente el punto de partida que trabajamos en PAPIHIJO antes de tocar una sola herramienta.