Por qué fracasan los proyectos de digitalización industrial

Un patrón se repite con una regularidad incómoda: la empresa invierte en un sistema, el proyecto se entrega, y dieciocho meses después la operación sigue corriendo sobre las mismas hojas de cálculo de siempre. El sistema existe. Nadie lo usa.

Casi nunca es culpa de la tecnología. En los casos que hemos visto de cerca, la causa está mucho antes de la primera línea de código.

El proceso del manual no es el proceso real

Todo levantamiento de requerimientos empieza igual: se convoca a los responsables de área y se les pide describir el proceso. Lo que se obtiene es el proceso oficial — el que está documentado, el que se le muestra al auditor, el que debería ocurrir.

El proceso real casi siempre tiene tres o cuatro atajos que no están en ningún manual y que existen por buenas razones: una aprobación que se salta porque el gerente viaja, un formato paralelo que se llena porque el oficial no captura un dato que sí importa, una llamada al proveedor que resuelve en diez minutos lo que el flujo formal tarda tres días.

Cuando el software se construye contra el proceso oficial, obliga a la operación a abandonar esos atajos. Y como los atajos existían por una razón que no desapareció, la operación hace lo predecible: usa el sistema para cumplir, y sigue resolviendo por fuera.

El síntoma que delata el problema

Hay una señal temprana que casi nunca falla: si el equipo mantiene una hoja de cálculo paralela después del go-live, el proyecto ya falló, aunque el tablero de adopción diga lo contrario.

Esa hoja de cálculo no es resistencia al cambio. Es la evidencia de que el sistema no captura algo que la operación necesita. Vale mucho más entenderla que prohibirla.

Tres decisiones que cambian el resultado

Diagnosticar en campo, no en sala de reuniones

La diferencia entre entrevistar al jefe de área y pasar dos semanas al lado de quien ejecuta el proceso es la diferencia entre el proceso oficial y el real. Es más caro por adelantado y mucho más barato en total.

Validar prototipos con quien usa, no solo con quien aprueba

Quien aprueba el presupuesto rara vez es quien va a usar el sistema ocho horas al día. Un prototipo revisado con el comprador, el almacenero o el planner encuentra en una sesión problemas que la gerencia no puede ver.

Entregar en pedazos útiles

Un proyecto de un año con una sola entrega al final es una apuesta a que el diagnóstico inicial fue perfecto. Nunca lo es. Entregas incrementales convierten cada error de interpretación en una corrección de semanas en lugar de un fracaso de año.

La ventaja de no empezar de cero

Hay una razón por la que insistimos tanto en esto: nuestros propios productos no nacieron de un backlog. Nacieron de proyectos de consultoría donde primero vivimos el problema durante meses y después escribimos el software.

Eso no nos hace mejores programadores. Nos ahorra la parte donde uno construye con confianza la solución equivocada.

---

Trabajamos con equipos de operaciones y abastecimiento en minería, cemento, agroindustria y distribución industrial. Si estás evaluando digitalizar un proceso, conversemos antes de que escribas el requerimiento.