Hay un patrón claro: un piloto de Industria 4.0 arranca, funciona, el equipo lo celebra, dirección lo enseña como prueba de que «la transformación avanza» — y ahí se queda. Nadie lo replica en la siguiente planta. Nadie lo convierte en algo que la empresa pueda repetir sin reunir otra vez al mismo equipo de siempre.
El error, como siempre, está en confundir que un piloto funcione con que la empresa haya ganado una capacidad.
Tu piloto de Industria 4.0 funciona. ¿Por qué eres incapaz de escalarlo?
Un piloto demuestra que algo es técnicamente posible bajo condiciones muy concretas: una máquina, un conjunto de datos disponibles, y sobre todo, un grupo de personas que conoce cada detalle del proyecto porque lo ha construido a mano. Eso es un logro real. Pero no dice nada sobre si esa solución sobrevive fuera de ese contexto.
El indicador más fiable de que tienes un problema no es que el piloto falle. Es que funcione tan bien que nadie se pare a preguntar por qué funciona tan bien.
Por qué escalar cuesta más que el piloto, no solo «es más difícil»
Aquí está el elefante: un piloto y una solución industrializada no son la misma cosa en distinta escala. Son economías distintas.
El piloto se subvenciona con atención artesanal — alguien corrige a mano lo que el sistema no resuelve, alguien interpreta datos incompletos porque conoce el contexto de memoria, alguien improvisa la integración porque solo hay que hacerla funcionar una vez. Ese coste no aparece en ningún informe porque no es coste, es esfuerzo invisible de gente comprometida. Y precisamente por eso nadie lo presupuesta cuando llega el momento de replicar.
Cuando intentas llevar esa misma solución a la siguiente planta, ese esfuerzo invisible no desaparece: hay que volver a ponerlo, planta por planta, porque nunca se convirtió en proceso — se quedó en pericia de una persona. Así que el coste por implantación no baja con la repetición, como se planteó inicialmente. Se mantiene plano, o incluso sube, porque cada planta tiene sus propias variantes de máquinas, protocolos y calidad de datos que el piloto original nunca tuvo que resolver.
Esto es lo contrario de cómo funciona la deuda técnica en software, donde al menos el código se copia. Aquí ni siquiera hay algo que copiar: hay una persona que sabe hacerlo, y eso no escala nunca, por definición.
Las señales que encuentro siempre
Cuando reviso un piloto que «funciona» pero no escala, encuentro casi siempre la misma combinación: depende de una o dos personas que saben dónde están los datos y cómo corregir las incidencias que nadie ha documentado. El proceso nuevo convive con el antiguo en lugar de sustituirlo. Cada intento de desplegarlo en otra planta obliga a analizar casi todo desde cero, porque las integraciones se diseñaron a medida del piloto y los datos de la siguiente planta no tienen la misma calidad ni el mismo formato.
Y hay una señal de gobierno que es la más reveladora de todas: nadie tiene asignada la responsabilidad de la solución una vez termina la fase de prueba. El proyecto tiene dueño mientras es piloto. En cuanto deja de serlo, se queda huérfano.
Por qué esto no es un problema técnico
El bloqueo no está en la arquitectura, el bloque está en que nadie ha decidido, con autoridad real, si esa solución pasa a ser un estándar de la empresa o se queda como experimento. Sin esa decisión explícita, el piloto exitoso y el piloto abandonado son indistinguibles. Ambos siguen funcionando en su rincón, sin que nadie tenga mandato para moverlos al siguiente nivel.
La dirección puede tener la sensación de que la transformación avanza solo porque hay varias iniciativas activas al mismo tiempo. Contar pilotos no es lo mismo que haber construido capacidad. Se puede tener media docena de proyectos funcionando y cero capacidad real de repetir ninguno de ellos sin el mismo esfuerzo heroico cada vez.
Los cuatro umbrales que decides antes del siguiente piloto
Nada de preguntas abiertas. Si cualquiera de estos cuatro umbrales se incumple, no autorizas el siguiente despliegue — industrializas primero:
- Dependencia de personas: si más del 20% de las tareas del proceso requieren que una persona concreta intervenga manualmente (corregir datos, interpretar una excepción, tomar una decisión no documentada), no está listo.
- Documentación ejecutable: si el proceso no se puede ejecutar siguiendo un documento por alguien que no participó en el piloto original, no está listo.
- Reutilización de arquitectura: si menos del 60% de los componentes técnicos (integraciones, modelos de datos, protocolos) son reutilizables sin rediseño en la siguiente planta, no está listo.
- Coste conocido: si no puedes dar una cifra de coste y tiempo para el siguiente despliegue con un margen de error inferior al 30%, no está listo — significa que sigues improvisando, no repitiendo.
Estos cuatro umbrales no son KPIs bonitos. Son el termómetro de si tienes una capacidad o una anécdota bien ejecutada.
Te propongo que abras un documento de una página, no más: qué funciona hoy y bajo qué condiciones, de qué depende exactamente (personas, sistemas, datos), y las tres opciones reales — mantenerlo como piloto, industrializarlo, o descartarlo. La decisión debe llevar dueño, resultado esperado y fecha — no «lo revisamos el próximo trimestre».
Si el piloto incumple dos o más de los cuatro umbrales, la decisión está clara: se detiene el escalado y se asigna una persona a industrializar antes de tocar la siguiente planta. No se negocia caso a caso — es la única forma de que el criterio no dependa de quién tenga más ganas de enseñar el siguiente piloto en el comité.
Te dejo una pregunta para que me la respondas: ¿Cuántos de tus pilotos seguirían funcionando mañana si las dos personas que realmente saben cómo funcionan dejaran de estar disponibles?
