El proceso que más te molesta no es el que debes automatizar primero
Al elegir qué automatizar, el instinto manda al proceso más doloroso. Casi siempre es el peor candidato, y hay tres criterios que funcionan mejor.
Cuando una empresa decide automatizar algo, casi nunca empieza por la pregunta difícil. Empieza por una lista.
Y en esa lista siempre hay un proceso que todos señalan primero: el que genera más quejas, el que nadie quiere hacer, el que sale en cada junta desde hace dos años.
Ese es, casi siempre, el peor lugar para empezar.
Por qué el proceso que más duele es mal candidato
Un proceso duele por alguna razón. Y cuando lo revisas de cerca, la razón casi nunca es el volumen. Es que está lleno de excepciones.
El proceso que todos odian suele ser el que cambia según el cliente. El que tiene tres formas distintas de resolverse dependiendo de quién lo atienda. El que obliga a llamar a alguien para confirmar un dato que no está en ningún sistema.
Duele porque cada caso hay que pensarlo.
Y pensar caso por caso es justamente lo que un sistema automatizado hace peor.
Si empiezas por ahí, te pasa una de dos cosas. O construyes algo tan lleno de condiciones que nadie lo entiende ni lo puede mantener seis meses después. O construyes algo que funciona en el caso típico y falla en todos los demás, que resultan ser buena parte.
El resultado es el mismo en los dos casos: tu equipo pierde la confianza en la automatización antes de haber visto que funciona. Y esa confianza cuesta mucho más recuperarla que ganarla la primera vez.
Los tres criterios que sí funcionan
Hay una combinación que hace a un proceso buen candidato. No incluye qué tanto molesta.
Volumen alto. No es lo mismo un trámite que ocurre cuatro veces al año que uno que ocurre cuarenta veces al día. El segundo devuelve la inversión aunque ahorre poco por caso; el primero no la devuelve nunca, por más elegante que quede.
Reglas estables. Si puedes explicarle a alguien nuevo cómo se resuelve el proceso en una hoja, y esa hoja sigue siendo cierta el mes que viene, es automatizable. Si la explicación termina en “depende”, todavía no.
Esta es la más difícil de evaluar honestamente, porque los procesos que llevan años funcionando se sienten estables aunque no lo sean. La prueba real no es si tú puedes explicarlo: es si dos personas de tu equipo lo explican igual. Cuando las respuestas no coinciden, lo que existe no es un proceso con reglas — es un criterio compartido a medias, y automatizarlo congela una de las dos versiones sin que nadie haya decidido cuál.
Bajo costo de error. Aquí es donde casi todos se equivocan al evaluar, y vale la pena detenerse.
El criterio que la mayoría se salta
No todos los errores cuestan igual.
Que un sistema clasifique mal un correo es un error barato: alguien lo mueve y se acabó. Que emita una nota de crédito equivocada, que mande un precio mal calculado a un cliente, o que borre un registro que nadie respaldó, es otra categoría completamente distinta.
La diferencia no es la probabilidad de fallar. Es qué tan caro sale deshacerlo.
Y esto no significa que los procesos caros no se puedan automatizar. Significa que se automatizan distinto: el sistema prepara el trabajo completo y una persona autoriza el paso que tiene consecuencias.
Eso es más lento que la automatización total, sí. También es lo único que hace que el equipo lo adopte. Un sistema que puede cometer un error caro sin que nadie lo revise no es más avanzado — es uno que nadie va a querer encender.
Qué hacer con esto el lunes
Toma una hoja y escribe los procesos que estás considerando. Para cada uno, contesta tres preguntas, sin adornar:
¿Cuántas veces ocurre por semana? El número real, contado, no el que recuerdas.
¿Puedes escribir las reglas en una hoja? Intenta escribirlas de verdad. Si al hacerlo aparecen cinco excepciones que no habías considerado, acabas de aprender algo más valioso que la respuesta.
Si el sistema se equivoca, ¿qué tan caro es deshacerlo? Barato, incómodo o grave. Si es grave, el proceso no queda descartado: queda marcado como uno que necesita un punto de aprobación.
El que gane esas tres preguntas es por donde empiezas. Probablemente no sea el que más te molesta.
Y ese es justo el punto: el primer proyecto de automatización no se elige por cuánto alivio promete. Se elige por qué tan seguro es que va a funcionar. Porque el primero no está resolviendo un proceso. Está decidiendo si va a haber un segundo.