Por qué el piloto sale bien y la operación sigue igual
La demostración funcionó. El equipo aplaudió, alguien dijo que esto cambiaba todo, y tres meses después nadie lo usa. No es raro: es el desenlace más común de un proyecto de automatización dentro de una empresa mediana.
El motivo casi nunca es la herramienta. Un piloto se diseña sobre casos limpios, con datos que alguien preparó a mano y con una persona pendiente de que salga bien. La operación real trae el caso incompleto, el proveedor que manda el archivo en otro formato y al capturista que aprendió a resolverlo por WhatsApp hace seis años. Lo que se probó y lo que hay que resolver no son el mismo problema.
Lo que conviene medir antes
Antes de elegir qué implementar, sirve más responder tres preguntas incómodas:
- ¿Cuánto cuesta hoy? No en horas estimadas, en dinero. Si nadie puede ponerle una cifra al proceso, tampoco va a poder defender el ahorro después.
- ¿Quién pierde con el cambio? Siempre hay alguien cuyo trabajo se vuelve visible, o innecesario. Ese alguien decide si la herramienta se adopta o se sabotea en silencio.
- ¿Qué pasa cuando falla? Un proceso automatizado sin ruta de escape se abandona a la primera excepción que nadie supo atender.
Un diagnóstico que no contesta esas tres no es un diagnóstico, es un catálogo de herramientas.
El orden importa
Primero se entiende qué está costando dinero, después se decide si eso se arregla con tecnología. El orden inverso produce pilotos preciosos que no sobreviven al primer lunes.
