La digitalización industrial rara vez fracasa con un desplome espectacular. Lo habitual es otra cosa: el piloto funciona en la demostración y se atasca al encontrarse con los turnos reales, equipos de distintas generaciones, registros incómodos, controles de ciberseguridad o un directivo que ya atiende otra prioridad. Puede que el software siga funcionando. El proyecto ha fracasado si no consigue salir del piloto o si el valor operativo desaparece cuando se marcha el equipo que lo puso en marcha.
Es una definición práctica. Separa un prototipo prometedor de una capacidad que la planta puede mantener. Un piloto disciplinado puede detenerse pronto y ser útil si refuta un supuesto antes de comprometer más dinero. Los fracasos caros son menos visibles: siguen consumiendo licencias, integración y atención de la dirección sin demostrar que haya mejorado una decisión recurrente de planta.
Los cinco errores que siguen no son leyes de ingeniería, sino mecanismos que conviene comprobar. El sector, la madurez del centro, el riesgo, la normativa y el problema concreto pueden cambiar la respuesta. Las decisiones sobre cambios de proceso, ciberseguridad, seguridad, liberación de calidad, inversión o compromisos financieros corresponden siempre a las funciones autorizadas de la planta.
Qué significa fracasar después de la demostración
Una demostración acredita que algo funcionó una vez y bajo esas condiciones. No demuestra que el resultado vaya a resistir otra línea, familia de producto, combinación de turnos, cambio en el sistema de origen o varios meses de uso.
En esta guía, la digitalización industrial ha fracasado cuando el piloto no escala hasta el límite operativo previsto o cuando la organización no puede sostener el valor operativo que pretendía crear. Por eso un piloto puede superar la aceptación técnica y, aun así, fallar como cambio operativo.
El Foro Económico Mundial llamó “purgatorio de los pilotos” a esta brecha (informe WEF Beacons). Su trabajo Lighthouse de 2019 señaló que más del 70 % de las empresas que invertían en tecnologías como analítica de grandes volúmenes de datos, inteligencia artificial o impresión 3D no habían pasado de la fase piloto.
La cifra procedía de trabajos anteriores del Foro y no es una tasa universal de fracaso aplicable a cualquier sector, país, tipo de proyecto o año. Sí muestra que escalar plantea un problema distinto de probar una tecnología en un entorno concreto.
El piloto necesita un contrato operativo: problema, población incluida, referencia actual, decisión o tarea que se espera cambiar y responsable del resultado. También necesita una ventana de evidencia. Reducir el tiempo de investigación puede exigir varios sucesos comparables; una ayuda a la programación debe enfrentarse a distintas mezclas de producto. Un taller satisfactorio no equivale a un resultado sostenido.
Escalar tiene varias dimensiones. La técnica pregunta si interfaces, rendimiento, seguridad y soporte funcionan fuera de la prueba. La operativa comprueba el encaje con el trabajo real y sus excepciones.
La organizativa revisa la asignación de responsabilidades, la formación y los circuitos de aprobación cuando el equipo del proyecto ya no está. La económica exige que el beneficio repetible supere toda la carga recurrente, no solo la licencia inicial. El piloto solo puede ampliarse con evidencia suficiente sobre todas las dimensiones pertinentes para su riesgo.
Un estudio de 42 proyectos de fabricación también describe distintas combinaciones de condiciones sociales y técnicas, no un único recorrido tecnológico (Clausen et al., 2025). No es un baremo universal.
Las señales aparecen pronto: se informa de precisión del modelo, pero no de decisiones distintas; cada línea necesita un mapeo a medida; los operarios mantienen una hoja de cálculo paralela; la limpieza depende de una persona; o nadie asume el flujo de datos tras la entrega.
Los criterios de escalado deben escribirse antes de configurar. Hay que definir qué supondría detener, reparar, continuar con alcance limitado o ampliar. Cuando el riesgo lo requiera, el proceso original debe seguir disponible durante una comparación controlada.
Un primer piloto tampoco tiene que demostrar la economía de toda una red. Algunos beneficios de infraestructura solo aparecen al reutilizarla. Conviene separar el valor local demostrado de la hipótesis de cartera y financiar el siguiente límite como otra prueba. Llamar “transformación” a la hipótesis no la convierte en evidencia.
Error 1: elegir la tecnología antes que el problema
Los proyectos que empiezan por la tecnología buscan un problema para una capacidad ya elegida: sensores, visión artificial, una plataforma de datos, un gemelo digital o un asistente generativo. Como el producto define lo que puede verse, el éxito se formula mediante hitos de despliegue o resultados de la herramienta. La decisión retrasada, la pérdida repetida o la carga manual quedan de fondo. Una buena demostración valida la compra sin probar que haya mejorado el trabajo original.
Michael Brundage describe el caso de un fabricante que compró sensores antes de decidir cómo utilizaría los datos nuevos, pese a que ya había conocimiento útil de mantenimiento en órdenes de trabajo difíciles de analizar (NIST, “How Do We Get Smart?”). El ejemplo no demuestra que los sensores fueran una mala elección. Enseña por qué conviene inventariar los datos antes de asumir que la planta carece de ellos y por qué la primera pregunta debe ser operativa.
Las señales son conocidas. El alcance se expresa como “IA” o “plataforma”, no como una decisión. El éxito se mide en dispositivos conectados, cuadros de mando publicados o usuarios formados. Ningún responsable explica el coste o retraso actual del problema ni qué acción cambiará con el nuevo resultado. Mientras tanto, una hoja de cálculo, una conversación de relevo o un registro de mantenimiento siguen llevando el trabajo que importa.
La prevención empieza con un contrato del problema de una página. Debe recoger el suceso, quién se enfrenta a él, cómo lo resuelve, qué evidencia falta, qué decisión seguirá siendo humana y cómo se comparará el resultado.
El primer caso puede ser poco vistoso: reconstruir una parada o relacionar el lenguaje de las órdenes con los alias de activos. La guía sobre contexto de datos industriales explica por qué los registros necesitan relaciones, responsables y alcance antes de que un asistente pueda reunirlos con rigor.
Después se contrastan alternativas frente al mismo problema: mejorar el método actual, añadir una ayuda digital acotada o incorporar una plataforma. Finanzas, IT/OT y planta estiman el esfuerzo de implantación y el de operación recurrente. Es un filtro, no una autorización de inversión. Una primera estimación puede descartar una propuesta inadecuada, pero no aprobar capital ni establecer un diseño seguro.
Un estudio de ocho fabricantes situó los casos de uso basados en datos junto a la estrategia, la organización, la colaboración y el trabajo interfuncional (Budde et al., 2022). Incluso un caso técnicamente sólido necesita un cauce organizativo.
La exploración tecnológica sigue teniendo valor. A veces un equipo descubre una capacidad antes de comprender cuál es su mejor aplicación. Ese trabajo debe quedar claramente identificado como exploratorio, tener un plazo y mantenerse separado de cualquier promesa de valor. El error no es sentir curiosidad. Es permitir que esa curiosidad herede un presupuesto, una dependencia de producción o un compromiso de escalado antes de contar con un problema y un responsable reales.
Error 2: diseñar sin contar con la planta
Excluir a la planta no siempre significa dejar a los operarios fuera de las reuniones. Un proyecto puede hacer entrevistas y seguir tratando el taller como una fuente de requisitos, no como parte del diseño del trabajo que cambiará.
El fallo aparece cuando los mapas formales sustituyen a la realidad local. Quedan fuera modos anómalos, tareas interrumpidas, nombres no oficiales de activos, guantes, terminales compartidos, reparaciones temporales o el momento en que un supervisor debe elegir entre registrar más detalle y recuperar la producción.
El informe de 2024 del Foro Económico Mundial sobre personal de primera línea se basó en más de 85 entrevistas con operarios, mecánicos, electricistas, ingenieros de fabricación y supervisores de ocho fábricas de Estados Unidos, Europa y Asia (informe WEF sobre primera línea).
Los centros pertenecían a grandes corporaciones internacionales, así que los resultados no representan estadísticamente a toda la industria. Su utilidad está en mostrar preocupaciones concretas de los trabajadores durante la preparación, introducción y uso continuado de la tecnología.
Conviene desconfiar de un piloto que solo funciona con el responsable del proyecto junto al usuario. Otras señales son pedir opinión cuando el flujo ya está cerrado, formar al final, observar una adopción baja en los turnos nocturnos o de fin de semana, recurrir a cuentas compartidas, conservar notas en papel “temporalmente” o despachar cualquier queja como resistencia.
El silencio es peor: la gente deja de comunicar defectos si sus avisos no producen explicación ni cambios, o si informar acaba en reproches por retrasar el despliegue.
Para evitarlo, deben participar antes de cerrar la interfaz quienes ejecutan, supervisan, mantienen y dependen de la tarea. Hay que recorrer un caso normal y otro incómodo, y observar el flujo cuando las reglas locales lo permitan. Los usuarios deben poder cuestionar nombres, tiempos, relevos y excepciones. El WEF concluye que la perspectiva de los trabajadores suele pasarse por alto pese a ser esencial para introducir tecnología con eficacia (informe WEF sobre primera línea).
La participación tiene que modificar algo. Conviene registrar las decisiones cambiadas, las objeciones abiertas y quién responderá. El modo sombra debe cubrir turnos representativos y medir tareas completadas, retrabajo, casos sin respuesta y tiempo alejado de la tarea física. También intervienen IT y OT. La guía práctica de integración IT/OT explica por qué una conexión útil necesita una ruta segura, autoridad sobre cada campo, marcas temporales y responsables de mantenimiento.
El estudio de ocho empresas identificó en su síntesis de casos un enfoque combinado de arriba abajo y de abajo arriba (Budde et al., 2022). Su diseño cualitativo no prescribe una estructura de gobierno concreta.
Participar también tiene límites. Un taller informal no recibe por ello autoridad sobre seguridad, calidad, ciberseguridad, relaciones laborales o ingeniería, y la persona que más habla no representa a todos los turnos. Algunas decisiones de diseño estarán condicionadas por normas o procedimientos controlados. Es mejor explicar esos límites sin rodeos. Una restricción clara se acepta mejor que una consulta cuyo resultado ya estaba decidido.
Error 3: aceptar el relato del proveedor como caso de negocio
El relato de un proveedor explica qué puede hacer un producto y, en el mejor de los casos, cómo lo utilizó otro cliente. El caso de negocio debe aclarar qué espera cambiar esta planta, desde qué referencia, mediante qué mecanismo, con qué carga total y bajo la responsabilidad de quién.
Si el primero sustituye al segundo, el proyecto toma prestados el problema, la economía, la preparación de los datos y las condiciones de implantación de otra empresa. Puede que el beneficio sea real allí y resulte irrelevante aquí.
Suele empezar con un porcentaje llamativo. La cifra entra en una diapositiva, se multiplica por la producción o el coste laboral local y se convierte en valor esperado. Fuera quedan el límite de comparación, la mezcla de producto, la adopción, integración, validación, soporte, formación, ciberseguridad, tiempo de parada y mantenimiento de los datos de origen. El potencial crece en la presentación mientras se borra la incertidumbre.
Las señales incluyen beneficios sin denominador local, ahorros atribuidos a todas las horas aunque el problema sea esporádico, tiempo de trabajo presentado como ahorro de caja sin una decisión de plantilla o un retorno que omite el esfuerzo interno.
También falta a menudo el contrafactual: mejorar el proceso actual, reparar un problema conocido o esperar un trimestre. Si la única alternativa es la propuesta del proveedor, el análisis se reduce a una comparación comercial; no permite tomar una decisión de planta.
Un estudio de ocho empresas manufactureras de Europa occidental identificó estrategia y organización, colaboración, trabajo interfuncional y casos de uso basados en datos como cuatro prácticas de gestión agregadas para la transformación digital (Budde et al., 2022).
El estudio utilizó análisis cualitativo de casos y describió los efectos sobre productividad también de forma cualitativa, por lo que no ofrece un modelo financiero universal. Sostiene una conclusión más limitada: la selección tecnológica forma parte de la práctica organizativa y de gestión, no la sustituye.
El caso de negocio parte de una referencia trazable: proceso y decisión afectados, frecuencia, pérdida actual, fuente de medición, incertidumbre y responsable. La cadena causal debe ser legible: la herramienta cambia una tarea; ese cambio afecta a una medida operativa; finanzas reconoce valor solo bajo ciertas condiciones.
El cálculo incluye costes únicos y recurrentes, esfuerzo interno, mantenimiento de mapeos y modelos, formación, controles y coste de reversión. El artículo sobre decisiones de inversión en planta desarrolla la comparación entre restricción, alternativas y medidas de éxito.
Las condiciones de parada se fijan antes de aprobar. Si la adopción queda por debajo del umbral operativo acordado, las excepciones de datos superan lo que el equipo puede mantener o el resultado medido no cambia tras un periodo de observación suficiente, el patrocinador debe decidir si reparar, reducir o detener. Los umbrales se eligen en cada organización; esta guía no autoriza un gasto ni prescribe una tasa mínima de rentabilidad.
El informe Lighthouse del WEF estudió centros seleccionados que habían llevado casos de uso más allá del piloto (informe WEF Beacons). No son una referencia representativa de una planta media.
La evidencia del proveedor sigue siendo útil para descubrir exigencias de integración y preguntas que merecen probarse. Los beneficios que declara deben tratarse como hipótesis hasta conocer la fuente, el método, la población y las condiciones de transferencia local. El proveedor puede ayudar a diseñar la prueba, pero no asumir el caso de negocio del cliente.
Error 4: descubrir demasiado tarde que los datos no sirven
“Tenemos los datos” puede significar únicamente que existen valores en algún lugar. Un piloto necesita más. Los registros deben representar los objetos y ventanas temporales correctos, seguir accesibles bajo controles aprobados, conservar unidades y linaje, y resistir los cruces que exige la decisión. Si las carencias aparecen cuando el modelo o el cuadro de mando ya están prometidos, aumenta la presión para ocultar exclusiones, aceptar parches manuales o reducir la pregunta hasta que el resultado parezca completo.
El problema suele empezar con una lista de fuentes, no con una prueba de datos. Se da por disponible un histórico, MES, ERP, sistema de laboratorio o GMAO sin comprobar alias de activos, relojes, estados manuales, genealogía tras el retrabajo ni cantidad de sucesos comparables. El primer cruce completo llega después de comprometer arquitectura y licencias. Entonces cada ausencia parece un fallo de implantación, no una señal de que el caso de uso quizá no esté listo.
Un estudio de caso de IFAC de 2024 realizado en un fabricante suizo de componentes para motores examinó, desde una perspectiva técnica y de comportamiento, las desviaciones en datos recogidos manualmente en una línea de montaje (Thurnheer et al., 2024).
Desarrolló un modelo que comparaba los registros manuales con los datos del sistema de planificación para identificar discrepancias. Es un único caso de montaje manual, no una prueba de que todos los registros manuales sean inexactos ni de que los datos de planificación tengan autoridad por defecto.
Las señales son marcas temporales sin zona horaria, campos sin definición, unidades cambiantes, códigos genéricos, lagunas sin explicar, correcciones sobrescritas o emparejamientos por la hora más cercana. Si el piloto excluye los fallos que no se cruzan bien, el conjunto restante puede contar una historia tranquilizadora sobre los casos fáciles. Ningún modelo recupera sucesos que nunca se registraron ni decide qué fuente conflictiva tenía autoridad sin una regla.
La prevención consiste en probar una muestra pequeña antes de diseñar la solución. Se seleccionan sucesos normales, anómalos y ambiguos, y se sigue cada uno desde la fuente hasta la salida. Hay que conciliar recuentos, identificadores, tiempos, unidades, estado operativo, acceso e indicadores de calidad. Los valores brutos se conservan junto a las transformaciones. Los casos sin correspondencia y los excluidos se registran. Cada mapeo necesita un responsable y una respuesta cuando cambie la fuente.
Después se comprueba la aptitud para la decisión. Un dato puede ser correcto para contabilidad e inútil para analizar un proceso segundo a segundo. Los valores del histórico pueden ser precisos, pero carecer de genealogía de materiales.
El cierre de una orden de mantenimiento puede confirmar que terminó el trámite administrativo sin probar que el equipo volvió a la condición requerida. Las guías de contexto de datos industriales e integración IT/OT explican cómo mantener visibles la autoridad de la fuente y los límites de cada sistema.
En el ejemplo industrial del NIST, un texto de mantenimiento difícil de tratar resultó útil cuando el equipo analizó las variantes del lenguaje utilizado por los técnicos (NIST, “How Do We Get Smart?”). Que un dato “no sirva” depende de la decisión.
El límite importa especialmente con IA. Un asistente puede encontrar lagunas, comparar registros o redactar una lista trazable de excepciones. No puede fabricar evidencia fiable que la planta nunca capturó. La guía sobre capacidades y límites de la IA en planta mantiene esas salidas bajo revisión y aprobación humanas. Si reparar los datos exige cambiar de forma controlada un proceso, la seguridad o la calidad, las funciones autorizadas de la planta deben diseñar y aprobar ese cambio.
Error 5: confundir aprobar presupuesto con patrocinar
Aprobar un presupuesto responde a una pregunta estrecha: ¿puede la organización gastar dentro de una cantidad y una finalidad autorizadas? Patrocinar es un trabajo continuado. Quien patrocina protege el problema operativo cuando compiten las prioridades, asigna responsables de decisión, resuelve conflictos entre funciones, exige evidencia y asume la responsabilidad de detener o escalar. Tratar la firma como patrocinio deja un proyecto financiado, pero sin apoyo efectivo dentro de la organización.
La brecha aparece después del arranque. El patrocinador delega su asistencia, el comité se limita a repasar el estado del proyecto y los asuntos pendientes circulan entre planta, IT, compras, finanzas, ciberseguridad y proveedor. Nadie tiene autoridad suficiente para decidir quién responde del trabajo o reducir el alcance. El equipo optimiza lo que controla: configuración, hitos y presentación. El valor operativo queda pospuesto.
Un estudio de 42 proyectos de fabricación digital realizados entre 2018 y 2023 en un gran fabricante de aerogeneradores halló configuraciones sociotécnicas diversas, con variables sociales que contribuían al éxito de los proyectos (Clausen et al., 2025). El diseño en una sola empresa limita la generalización, pero la comparación entre proyectos sirve para no atribuir los resultados únicamente a la sofisticación técnica.
Las señales son decisiones sin responsable ni fecha, peticiones de “alinearse fuera de la reunión”, tiempo de planta prometido pero nunca liberado y riesgos que solo se elevan a una instancia superior cuando se retrasa un hito. También conviene dudar de quien describe la plataforma, pero no el problema, la referencia o la condición de parada. El dinero puede seguir disponible mientras quienes deben cambiar el trabajo responden ante prioridades incompatibles.
La prevención empieza con un contrato explícito de patrocinio. Debe indicar qué conflictos resolverá el patrocinador, qué evidencia revisará, con qué frecuencia y qué decisiones no puede delegar.
A su lado tiene que haber un responsable operativo que conviva con el resultado y otro técnico que mantenga la capacidad. Finanzas, IT/OT, ciberseguridad, calidad, seguridad y representación laboral necesitan puntos de control definidos cuando su autoridad sea pertinente. No conviene crear un comité en el que cualquiera pueda objetar y nadie pueda decidir.
En cada punto de control basta un registro corto: afirmación probada, evidencia observada, límites abiertos, responsable, siguiente alcance que se va a probar y decisión de detener, reparar, continuar o escalar. El presupuesto figura en el registro, pero no decide. Así se evita que el coste hundido sustituya a la evidencia y se puede cerrar un piloto débil sin llamar fracaso a cualquier experimento.
El estudio de ocho fabricantes describe a la alta dirección coordinando el intercambio de conocimiento, los estándares y los conflictos entre autonomía y normalización (Budde et al., 2022). Son ejemplos de patrocinio activo, no una estructura universal.
El alcance organizativo marca el límite. Un patrocinador local quizá no controle la arquitectura corporativa, los acuerdos laborales, los sistemas de calidad o la asignación de capital. Esas restricciones deben identificarse antes de prometer un despliegue. Elevar un asunto a la instancia competente forma parte del patrocinio; saltarse la autoridad, no. Apoyar el proyecto no elimina ninguna aprobación técnica, financiera, de ciberseguridad, seguridad o calidad.
Antes de la siguiente reunión de seguimiento, pida una página que reúna las cinco pruebas: problema operativo, participación de planta, caso de negocio local, circuito de datos probado y decisiones activas del patrocinador. Si falta una, reduzca el siguiente compromiso hasta el paso más pequeño capaz de producir esa evidencia. Mientras falte, no amplíe el alcance.
Preguntas frecuentes
¿Por qué los pilotos de digitalización industrial no consiguen escalar?
A menudo no escalan porque una demostración local no ha probado un resultado operativo repetible, un circuito de datos con responsable, la adopción en planta ni un caso creíble para sostener la solución. El WEF documentó el “purgatorio de los pilotos” y un estudio de 42 proyectos examinó condiciones sociales y técnicas relacionadas con el éxito (informe WEF Beacons; Clausen et al., 2025). Los criterios de escalado deben fijarse antes de configurar.
¿Cómo debe elegir una planta su primer caso de uso de digitalización?
Conviene elegir un problema recurrente, con responsable, referencia medible, límite de decisión y registros que puedan probarse antes de seleccionar la tecnología. El NIST y la investigación sobre ocho fabricantes respaldan este enfoque (NIST, “How Do We Get Smart?”; Budde et al., 2022). “Explicar estas paradas cortas repetidas” es un caso de uso; “implantar IA” no.
¿Quién debe participar en un proyecto de digitalización industrial?
Deben participar quienes ejecutan y supervisan el trabajo, especialistas de proceso y mantenimiento, responsables de datos e IT/OT, ciberseguridad y las funciones de calidad, seguridad, finanzas o aprobación del cambio que correspondan. Las entrevistas del WEF y el estudio de 42 proyectos aportan las perspectivas de planta y de proyecto (informe WEF sobre primera línea; Clausen et al., 2025). La composición depende del alcance y el riesgo. Participar debe afectar al diseño sin difuminar la autoridad formal.
¿Qué debe incluir el caso de negocio además de las ventajas del proveedor?
Debe recoger la situación de partida, el mecanismo de valor, la carga operativa total, los supuestos, explicaciones alternativas, condiciones de parada, un responsable y la evidencia necesaria para comprobar el valor.
El estudio de prácticas de gestión y el trabajo Lighthouse del WEF no ofrecen una previsión local lista para usar (Budde et al., 2022; informe WEF Beacons). Hay que separar el tiempo ahorrado del efectivo liberado. Finanzas y operaciones deciden si los supuestos del proveedor son transferibles. Esta guía no fija un umbral de inversión.
¿Qué hace que los datos industriales sean útiles para un piloto?
Los datos deben servir para la decisión: identificadores, marcas temporales, unidades, estados operativos, linaje, acceso, indicadores de calidad e histórico comparable tienen que sobrevivir a los cruces del piloto.
IFAC comparó registros manuales y de planificación; el NIST mostró que unas órdenes difíciles de tratar aún podían contener patrones útiles (Thurnheer et al., 2024; NIST, “How Do We Get Smart?”). Hay que conciliar exclusiones y mantener revisables las transformaciones. Un conjunto válido en origen puede ser inadecuado para otra pregunta.
¿Aprobar el presupuesto equivale a patrocinar el proyecto?
No. Aprobar el presupuesto libera fondos; patrocinar exige autoridad continuada para resolver prioridades, asignar responsables, retirar bloqueos, revisar evidencias y decidir si se detiene o escala el trabajo. Los estudios describen configuraciones sociotécnicas y coordinación entre niveles organizativos (Clausen et al., 2025; Budde et al., 2022). Quien patrocina debe conocer el problema y los criterios de decisión. El patrocinio no anula las aprobaciones controladas.
Fuentes
- World Economic Forum: Views from the Manufacturing Front Line
- World Economic Forum: Fourth Industrial Revolution Beacons of Technology and Innovation in Manufacturing
- NIST: When a Manufacturer Asks “How Do We Get Smart?”
- Budde et al.: Managerial Practices for the Digital Transformation of Manufacturers
- Clausen et al.: Why project success in manufacturing digitalization remains elusive
- Thurnheer et al.: Manual Data Collection in Assembly Lines