Automatizar un proceso roto no elimina el problema

La automatización tiene una propiedad incómoda: hace permanente aquello sobre lo que se aplica. Cuando un flujo se automatiza, sus pasos, sus excepciones y sus controles quedan escritos en software y adquieren una inercia que antes no tenían. Lo que era una costumbre discutible pasa a ser una regla difícil de cambiar.

Por eso la pregunta “¿qué proceso automatizamos primero?” suele llegar demasiado pronto. Antes hay una pregunta más barata de responder y mucho más determinante: ¿este proceso está en condiciones de ser automatizado, o lo que necesita es otra cosa?

En la práctica, cuando una organización dice “vamos a automatizar”, puede estar hablando de cuatro intervenciones distintas, con costos, riesgos y prerrequisitos diferentes.

Un patrón se repite con suficiente frecuencia como para nombrarlo. Un equipo identifica una actividad que consume muchas horas —conciliar dos sistemas, corregir datos, rearmar un reporte— y la propone como caso de automatización porque el volumen es evidente y el ahorro de tiempo parece medible.

El problema es que esa actividad casi nunca es trabajo: es compensación. Existe porque algo aguas arriba entrega información incompleta, tarde o en un formato que no sirve. Automatizarla estabiliza el defecto y elimina la señal que lo hacía visible. El costo deja de verse en horas, pero no deja de existir.

La decisión entre estandarizar, rediseñar, automatizar o delegar no se resuelve con una opinión ni con una lista de casos de uso. Se resuelve mirando cómo ocurre el trabajo: dónde se concentra el esfuerzo por actividad, cuánta variación hay entre ejecuciones, qué proporción de casos toma la ruta de excepción y en qué relevos el trabajo se detiene a esperar.

Esa lectura suele cambiar el orden del plan. Un flujo con alta variación no está listo para automatizarse; un flujo estable con muchos relevos entre sistemas casi siempre lo está; un flujo con exceso de controles necesita rediseño antes que software.

Automatizar bien también significa decidir qué no se automatiza. Las decisiones con consecuencia regulatoria, contractual o de seguridad, las excepciones que todavía no tienen patrón y los casos donde el criterio depende de contexto que el sistema no observa deben quedar bajo responsabilidad humana explícita, no por omisión.

Ese reparto —qué permanece humano, qué se asiste, qué se automatiza y qué se rediseña— es el entregable que hace utilizable un plan de automatización. Sin él, cada excepción se resuelve improvisando y el flujo automatizado empieza a acumular parches.

La discusión sobre plataformas suele ocupar más tiempo del que merece. La mayoría de las herramientas actuales pueden ejecutar el flujo; muy pocas pueden decirle si ese flujo debía existir en esa forma.

Un proyecto de automatización sostenible se parece más a una secuencia que a una implementación: observar cómo ocurre el trabajo, acotar un flujo concreto, decidir qué se elimina y qué se conserva, construir sólo entonces, y medir contra la línea base con la que se empezó.