Cuando se automatiza un proceso desordenado, el desorden no desaparece: cambia de escala y de velocidad. Un criterio ambiguo aplicado por una persona produce decisiones inconsistentes que alguien acaba notando; el mismo criterio ambiguo aplicado por un sistema produce miles de decisiones consistentemente equivocadas antes de que nadie repare en ello.
Ese cambio de escala es lo que hace que la automatización de un mal proceso sea peor que dejarlo como estaba, y no simplemente igual.
El error deja de ser detectable por contraste. En un proceso manual, la variabilidad entre personas actúa como sistema de alarma: cuando alguien resuelve un caso de forma distinta, la diferencia se discute y el criterio se corrige. Al automatizar desaparece esa variabilidad y, con ella, la señal.
La corrección deja de ser puntual. Descubrir un error tres semanas después no significa corregir un caso: significa revisar y rehacer todo lo procesado en esas tres semanas. El coste de la reversión crece linealmente con el tiempo de detección.
Las excepciones se multiplican en lugar de reducirse. Un proceso mal definido genera casos que no encajan. Automatizado, esos casos siguen llegando y ahora requieren tratamiento manual fuera del flujo, lo que suele producir más trabajo del que había antes.
La responsabilidad se difumina. Cuando un caso se resuelve mal, la respuesta pasa a ser «lo hizo el sistema». Y eso no es una respuesta útil ante un cliente ni ante un auditor, como quedó claro en el caso del chatbot de Air Canada resuelto en 2024: la empresa responde de lo que hace su software.
Momento | Qué se observa | Qué está pasando en realidad |
|---|---|---|
Semanas 1-2 | Todo funciona, hay entusiasmo | Se procesan los casos fáciles |
Semanas 3-6 | Aparecen casos «raros» | Emergen las excepciones no diseñadas |
Meses 2-4 | Crece el trabajo manual paralelo | El proceso se ha bifurcado |
Meses 4-6 | Se detecta un error sistemático | Hay que revisar el histórico |
La secuencia es tan repetitiva que sirve como diagnóstico. Si un proyecto de automatización va bien las primeras semanas y empieza a generar trabajo paralelo al segundo mes, el problema no está en la implementación: está en que el proceso no estaba definido cuando se automatizó.
Existe una comprobación previa que cuesta una tarde y evita la mayoría de estos casos: dar el mismo conjunto de veinte casos reales a tres personas distintas del equipo y comparar sus decisiones.
Si las tres coinciden en dieciocho o más, el proceso está lo bastante definido para automatizarse. Si coinciden en doce, no hay un proceso: hay tres criterios conviviendo, y automatizar significa elegir uno de los tres sin decírselo a nadie.
Este ejercicio tiene además una virtud política: convierte una discusión abstracta sobre madurez de procesos en un dato que nadie discute.
Descubrir que un proceso no está listo no obliga a aplazar todo seis meses. Hay tres intervenciones que producen valor rápido:
Definir el criterio en los casos frecuentes. No todos: el 80% del volumen suele concentrarse en cuatro o cinco situaciones. Escribir el criterio de esas cinco resuelve la mayor parte de la ambigüedad en una sesión de trabajo.
Automatizar solo la preparación. Reunir la información, contrastarla y presentarla para que una persona decida. Captura buena parte del ahorro y no propaga ningún criterio equivocado.
Instrumentar antes de automatizar. Medir el proceso manual durante unas semanas produce la línea base y revela la variabilidad real, que es exactamente el dato que falta para decidir.
Las tres son compatibles con seguir avanzando. Ninguna exige un proyecto de rediseño completo antes de tocar nada.
Conviene poner número a la reversión, porque es la partida que convierte un proyecto rentable en uno ruinoso.
Si un sistema procesa doscientos casos diarios y un error sistemático se detecta a las seis semanas, hay unos seis mil casos que revisar. Aunque solo el 10% esté afectado, son seiscientos casos que corregir, con su comunicación al cliente, su ajuste contable y su impacto reputacional.
Ese cálculo casi nunca aparece en el caso de negocio, y es la razón por la que el tiempo de detección de fallos debería ser una métrica de comité, como planteamos en automatización sin observabilidad es irresponsabilidad
Antes de automatizar cualquier proceso, hay una pregunta que ordena la decisión: si esto se equivoca de forma sistemática, ¿cuándo nos enteraríamos y cuánto costaría deshacerlo?
Si la respuesta es «en horas y con un clic», el riesgo de automatizar un proceso imperfecto es asumible y conviene avanzar. Si la respuesta es «en semanas y habría que revisar el histórico», el proceso necesita definición antes que automatización.
No es una cuestión de prudencia. Es aritmética.
El desorden cambia de escala: un criterio ambiguo aplicado por una persona produce decisiones inconsistentes que alguien acaba notando, mientras que aplicado por un sistema produce miles de decisiones consistentemente equivocadas antes de que nadie lo detecte.
Porque la variabilidad entre personas actúa como sistema de alarma: cuando alguien resuelve un caso de forma distinta, la diferencia se discute y el criterio se corrige. Al automatizar desaparece esa variabilidad y con ella la señal que permitía detectar el problema.
Dando el mismo conjunto de veinte casos reales a tres personas del equipo y comparando sus decisiones. Si coinciden en dieciocho o más, el proceso está definido; si coinciden en doce, conviven varios criterios distintos y automatizar significa elegir uno sin decidirlo explícitamente.
Tres cosas compatibles con seguir avanzando: definir el criterio de los cuatro o cinco casos que concentran el 80% del volumen, automatizar solo la preparación de la información dejando la decisión a una persona, e instrumentar el proceso manual unas semanas para obtener la línea base.
Crece con el tiempo de detección. Un sistema que procesa doscientos casos diarios con un fallo detectado a las seis semanas implica revisar unos seis mil casos; aunque solo el 10% esté afectado, son seiscientas correcciones con su comunicación al cliente y su ajuste contable.
Si el sistema se equivoca de forma sistemática, cuándo se detectaría y cuánto costaría deshacerlo. Si la respuesta es en horas y con un clic, el riesgo es asumible; si es en semanas y revisando el histórico, el proceso necesita definición antes que automatización.
¿Tu proceso está listo para automatizarse? Lo comprobamos con casos reales antes de escribir una línea de código, y te decimos qué parte conviene automatizar y qué parte definir primero. Hablemos →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
