Hay una escena que se repite en muchas empresas. Alguien de la dirección regresa de un evento convencido de que hay que automatizar. Se contrata una herramienta, se elige el primer proceso que aparece y tres meses después el proceso sigue siendo lento, pero ahora además nadie entiende por qué falla.
El problema no es la herramienta. El problema es que se automatizó un proceso que nunca se cuestionó.
Automatizar amplifica lo que ya existe
Una automatización no corrige un diseño defectuoso: lo ejecuta con más velocidad y menos intervención humana. Si el proceso tiene tres aprobaciones innecesarias, la automatización mantendrá las tres. Si el dato de entrada viene mal, ahora vendrá mal más rápido y sin que nadie lo note, porque desapareció la persona que antes lo revisaba de reojo.
Antes de automatizar hay tres preguntas que casi nadie se hace: ¿este paso debería existir?, ¿quién usa el resultado?, y ¿qué pasaría si simplemente dejáramos de hacerlo?
Medir primero, siempre
Un diagnóstico serio pone números donde antes había percepciones. No basta con que el equipo diga que un proceso "toma mucho tiempo". Hay que saber cuántas veces se ejecuta al mes, cuántos minutos consume cada ejecución, cuál es la tasa de error y cuánto cuesta corregir cada error.
Con esos cuatro datos se puede calcular el costo anual real del proceso, y esa cifra suele sorprender. Un proceso de veinte minutos que se ejecuta cuarenta veces al día equivale a más de un cargo completo al año. Ese es el número que justifica —o descarta— la inversión.
El orden correcto
- Medir el proceso actual: volumen, tiempo, errores y costo.
- Eliminar los pasos que no aportan. Es gratis y suele ser lo más rentable.
- Simplificar lo que queda: menos excepciones, menos aprobaciones, reglas más claras.
- Estandarizar: que todos lo hagan igual antes de que lo haga una máquina.
- Automatizar lo que sobreviva a los cuatro pasos anteriores.
Este orden no es una formalidad metodológica. En nuestra experiencia, entre el 20% y el 40% del tiempo de un proceso desaparece en los pasos dos y tres, sin escribir una sola línea de código.
La prueba final
Una automatización está bien hecha cuando puede explicarse en una frase, cuando alguien se entera si falla, y cuando existe un plan para operar manualmente si el sistema cae. Si no cumple las tres, no está terminada.