Por qué fracasa MES a gran escala (y qué hacer al respecto)

La mayoría de los fracasos MES se achacan a las personas. El equipo de implementación culpa a la formación, mientras que el jefe de línea culpa a la falta de implicación de los operarios. Ninguna de estas perspectivas es necesariamente errónea, pero ambas son incompletas.

Cuando la implantación del sistema se estanca en múltiples centros y departamentos, la variable que suele explicar esta brecha es de carácter arquitectónico. El sistema no puede adaptarse con la rapidez y el nivel de detalle que exige el trabajo, por lo que es la plantilla la que se adapta a él.

McKinsey señala que al menos el 70 % de los fabricantes se encuentran atrapados en un «purgatorio de proyectos piloto», incapaces de ampliar sus iniciativas digitales más allá de su fase inicial de implementación. A pesar de las mejoras en la forma en que las empresas perciben y abordan la gestión del cambio, esa cifra se ha mantenido relativamente estable.

En esta entrada, analizaremos los aspectos más habituales en los que observamos que fracasa MES en entornos con múltiples sedes, por qué la causa subyacente es casi siempre de carácter arquitectónico (y no de comportamiento) y cómo se traduce una implantación satisfactoria cuando el sistema se diseña para adaptarse al trabajo tal y como se desarrolla en la práctica.

Al final, dispondrá del vocabulario necesario para explicar a su comité directivo por qué la próxima implementación podría estancarse en el mismo punto que la anterior, así como de una lista de verificación con cuestiones arquitectónicas que deberá incluir en su próxima solicitud de propuestas a los proveedores.

Si ya ha participado anteriormente en MES , probablemente sabe cómo es el enfoque habitual de adopción. La mayoría de los proveedores e integradores ofrecen un plan de acción similar, y las directrices de gestión del cambio se centran en las mismas recomendaciones: definir objetivos claros, estructurar la implantación por fases, invertir en formación específica para cada puesto, comunicar el cambio, conseguir el apoyo de la dirección y hacer partícipes desde el principio a los equipos y partes interesadas pertinentes en el proceso de diseño.

En todos los sectores, los proyectos que cuentan con sólidos programas de gestión del cambio tienen aproximadamente cinco veces más probabilidades de completarse según lo previsto que aquellos que carecen de ellos, y se ha demostrado que una comunicación clara por sí sola se asocia a un aumento cuantificable de las tasas de éxito. La formación, la comunicación, el apoyo de los responsables y la participación de equipos interdisciplinares contribuyen a ello.

Sin embargo, lo que el manual omite es la parte previa al lanzamiento. Considera la adopción como una consecuencia posterior de cómo se gestiona la puesta en marcha, cuando en realidad la adopción también es el resultado de cómo se ha diseñado el sistema.

Si se aplica el mismo programa de gestión del cambio a dos MES diferentes, los resultados pueden ser muy distintos. Una empresa amplía la implantación a diez plantas, mientras que la otra tiene dificultades para ir más allá de la primera.

Lo que suele explicar esta brecha es si la arquitectura es capaz de adaptarse al tipo de variaciones que se producen a diario en los entornos de producción reales. Cuando colaboramos con responsables de operaciones para analizar una implementación que se ha estancado, los retos que describen rara vez se corresponden con problemas que un mejor plan de gestión del cambio hubiera solucionado. Se corresponden con puntos en los que el sistema no ha podido seguir el ritmo del trabajo.

Hemos observado que MES que se estancan suelen fracasar de formas similares. Hemos colaborado con fabricantes con múltiples centros de producción en diversos sectores complejos, y los cuatro problemas que se indican a continuación surgen en casi todos los análisis retrospectivos que examinamos. Todos ellos se remontan a un mismo problema de arquitectura: la plataforma no puede adaptarse al ritmo al que cambia el trabajo, por lo que el equipo de planta se ve obligado a crear soluciones provisionales.

Desde una perspectiva global del plan del proyecto, esas soluciones provisionales parecen fallos de formación o problemas culturales. Pero, analizadas de cerca, son la respuesta lógica a un sistema que no se adapta a las necesidades del equipo.

Las interfaces obsoletas y la nueva fuerza laboral

La mayoría de MES heredadas se diseñaron en una época en la que los trabajadores de la industria manufacturera permanecían en su puesto durante años y adquirían experiencia en la navegación por los menús. La interfaz era poco intuitiva, pero los operadores aprendieron a manejarla y no existía necesariamente una alternativa mejor.

Deloitte y el Manufacturing Institute prevén que el sector manufacturero estadounidense podría necesitar 3,8 millones de nuevos trabajadores netos entre 2024 y 2033, con hasta 1,9 millones de puestos que podrían quedar sin cubrir. La nueva generación que llega a la planta espera una experiencia más similar a la de las aplicaciones orientadas al consumidor: limpia, basada en la interacción táctil y fácil de aprender de inmediato. MES heredados les MES pantallas corporativas basadas en menús que, literalmente, se diseñaron hace una generación.

Este desajuste se traduce en curvas de incorporación más largas en todas las plantas. El tiempo necesario para alcanzar el dominio de MES heredados se mide en semanas en lugar de días, y las plantas compensan esta diferencia recurriendo a horas extras prolongadas por parte de los operadores con experiencia o a una disminución de la productividad durante la fase de puesta en marcha. A medida que aumenta la rotación de personal, ambos costes se agravan.

La economía de los recursos alternativos y el coste del cambio

Los flujos de trabajo en la planta cambian con el tiempo. Tomemos como ejemplo a un equipo de calidad que se encuentra con un nuevo patrón de no conformidad que el formulario de resolución existente no recoge. En un MES heredado, la modificación del formulario implica una solicitud de asistencia de TI, la intervención de un proveedor y un ciclo de lanzamiento. Tras varias rondas de «lo abordaremos el próximo trimestre», el equipo de calidad deja de solicitarlo y empieza a trabajar sorteando el sistema.

Seis meses después de la puesta en marcha, suele ser habitual entrar en una planta y observar lo que denominamos la «economía de las soluciones provisionales»: un conjunto paralelo de hojas de cálculo y procesos basados en conocimientos implícitos que se han desarrollado en torno al MES el sistema oficial no daba abasto.

El equipo de Calidad lleva un registro de no conformidades en Excel, el taller de mantenimiento cuenta con su propia herramienta de órdenes de trabajo y otros departamentos disponen de su propia versión de la misma. El MES técnicamente implantado, pero el trabajo real se lleva a cabo en los sistemas paralelos que ha creado cada equipo.

Mientras el coste de cambiar el sistema oficial sea superior al coste de la solución alternativa, los equipos optarán siempre por esta última. Una mayor disciplina en el uso del sistema oficial no cambiará esta situación.

Rigidez multisite

Las implementaciones en múltiples centros se enfrentan a un problema distinto. Cada planta funciona de manera diferente a las demás: productos distintos, equipos distintos, requisitos normativos distintos, culturas operativas distintas y niveles distintos de madurez digital. Por lo general, una única MES no puede adaptarse a toda esa variedad de variaciones a la vez, pero muchas plantillas heredadas se han diseñado partiendo del supuesto de que sí puede.

La regla general que se aplica en las implementaciones en múltiples centros es que una plantilla global suele cubrir entre el 70 % y el 80 % de la implementación, reservándose el 20 %-30 % restante para factores específicos de cada centro. Si se lleva la estandarización más allá de ese límite, el centro se verá obligado a aceptar un flujo de trabajo que no se ajusta al funcionamiento de la planta, o bien a crear una variante de la plantilla con una configuración específica que el equipo central deberá mantener por separado.

Las arquitecturas modulares resuelven este dilema al permitir que cada centro adapte las soluciones a su realidad operativa, al tiempo que comparten el modelo de datos, la gobernanza y el marco de cumplimiento, que deben ser uniformes en toda la empresa.

El calendario de implementación es otro factor agravante. MES heredados suelen tardar entre 18 y 36 meses en llegar a la puesta en marcha de la primera planta, y los despliegues en varias plantas se prolongan durante años más. Para cuando el despliegue llega a la tercera o cuarta planta, la implementación original ya no se ajusta a las operaciones actuales de la primera.

Por qué la visibilidad en tiempo real no llega a la planta de producción

MES tradicionales MES diseñados para funcionar como un sistema de registro. Los datos que el operador introduce en cada paso se registran, se recopilan en informes y se transmiten a los supervisores, al director de planta y a los paneles de control ejecutivos. El departamento de cumplimiento normativo obtiene la información que necesita, se calculan las métricas clave y se genera el registro de auditoría.

Lo que no siempre ocurre es el proceso inverso. Muchas MES no están diseñadas para transmitir información contextual en tiempo real de vuelta a la planta de producción. Un operario que desee saber si su línea va según lo previsto en ese momento puede verse obligado a consultar una pizarra que el responsable de planta actualiza una vez por turno.

Esa misma brecha se observa en el ámbito de la supervisión, donde las decisiones se toman basándose en información que llega con varias horas de retraso, y en el ámbito de la ingeniería de procesos, donde el análisis de las causas raíz se lleva a cabo a partir de exportaciones por lotes en lugar de datos en tiempo real.

La elección arquitectónica subyacente es el sistema de registro. MES tradicionales MES diseñados para registrar lo que ha ocurrido, no para facilitar la toma de la siguiente decisión. Un sistema de interacción subsana esta carencia al poner los mismos datos que el sistema recopila a disposición de las personas que pueden utilizarlos en la planta de producción. La visibilidad en tiempo real deja de ser una expresión que la empresa utiliza en relación con la elaboración de informes y se convierte en algo que se experimenta en la propia planta de producción.

Los cuatro problemas se remontan a la arquitectura. MES heredados MES diseñaron para un mundo en el que los trabajadores permanecían en sus puestos, los flujos de trabajo apenas variaban, las operaciones eran similares de una planta a otra y los datos solo tenían que fluir en una dirección, hacia arriba en la cadena. Ninguna de esas premisas se cumple hoy en día para la mayoría de los fabricantes, y estos sistemas antiguos no se diseñaron para adaptarse al funcionamiento actual de las plantas.

La mayoría de MES tradicionales se diseñan como sistemas monolíticos, en los que todas las funciones están estrechamente interconectadas entre sí dentro de un único sistema. La incorporación de un solo campo de datos a un control de calidad tiene repercusiones en todo el código, por lo que incluso los ajustes más pequeños pueden requerir semanas de desarrollo, validación y una implementación coordinada. Esa misma interdependencia que garantiza la coherencia interna y el control del sistema es también la que hace que su modificación resulte estructuralmente costosa.

Un MES modular se construye de forma diferente. Se compone de un ecosistema de aplicaciones y servicios, en lugar de ser un bloque único, lo que significa que los flujos de trabajo pueden añadirse, modificarse o eliminarse de forma independiente. Un cambio en un flujo de trabajo de calidad no requiere revalidar un flujo de trabajo de mantenimiento que no guarde relación con él. Los equipos de operaciones pueden ajustar las aplicaciones más cercanas a su trabajo sin tener que someter a toda la pila a un ciclo de lanzamiento coordinado.

La diferencia arquitectónica se refleja en el coste del cambio. MES heredados MES utilizar lenguajes de programación propios y esquemas de datos subyacentes complejos, lo que obliga a los fabricantes a recurrir a integradores de sistemas externos incluso para ajustes menores. La mayoría de los equipos lo conocen como el «coste de integración», y la mayoría lo subestima a la hora de calcular el coste total de propiedad. Cada cambio en el flujo de trabajo conlleva un coste económico real y un coste temporal real, razón por la cual los fabricantes tienden a dejar de modificar el sistema por completo y a recurrir a soluciones provisionales para hacer frente a la carga de trabajo.

Una arquitectura de sistema modular no garantiza necesariamente su adopción. Las implementaciones deficientes de las plataformas modulares siguen fracasando, normalmente cuando el equipo trata la plataforma como un lienzo en blanco y espera que la adopción surja por sí sola.

No obstante, la arquitectura modular sí facilita su adopción. Que funcione o no depende del modelo operativo que el equipo desarrolle sobre la plataforma.

Hemos observado que las empresas que logran ampliar con mayor éxito sus operaciones digitales en todos los departamentos y centros suelen haber adoptado tres decisiones en materia de arquitectura y modelo operativo que los manuales tradicionales suelen pasar por alto. Cada una de estas decisiones aborda directamente los retos señalados anteriormente y, en conjunto, describen lo que entendemos por un sistema diseñado desde el principio para facilitar su adopción.

Estandarización con flexibilidad local

Lo que hace fracasar a la mayoría de las implementaciones es estandarizar los aspectos equivocados. En las implementaciones a gran escala que hemos observado, la solución es lo que solemos denominar «estandarización global con flexibilidad local»: una estandarización rigurosa en lo que respecta a los modelos de datos, los protocolos de seguridad, los registros de auditoría y la gobernanza a nivel de plataforma, combinada con una configurabilidad a nivel de flujo de trabajo que permite a cada centro adaptar las aplicaciones a sus productos, equipos, sistemas heredados y cultura operativa.

Esto suele requerir un modelo de gobernanza federada. Un Centro de Excelencia (COE) se encargará de los aspectos que deben ser uniformes en todas las plantas. Los equipos de cada centro se encargarán de los aspectos que deben adaptarse a cada caso. Esta división permite al equipo global garantizar el cumplimiento de los requisitos de auditoría y seguridad sin obligar a todas las plantas a aplicar el mismo flujo de trabajo, lo que podría no ajustarse a la realidad operativa sobre el terreno.

Desarrollo ciudadano regulado

La disyuntiva entre «agilidad y control» se hace más evidente cuando la gobernanza se aplica a nivel de proyecto. Cada cambio en el flujo de trabajo debe pasar por un proceso de revisión, aprobación, validación e implementación, lo que significa que el ritmo de cambio está limitado por la capacidad del equipo central para procesar las solicitudes de cambio. Esta disyuntiva desaparece cuando la gobernanza se integra en la propia plataforma.

El desarrollo ciudadano regulado es un modelo operativo en el que los expertos en la materia más cercanos al trabajo (ingenieros y operadores) crean y modifican directamente aplicaciones de fabricación listas para la producción, mientras que la gobernanza a nivel de plataforma, los controles de permisos, los flujos de trabajo de aprobación y los registros de auditoría garantizan el cumplimiento de los límites establecidos por los departamentos de TI y de cumplimiento normativo. El cambio se produce al ritmo del trabajo, ya que la persona que realiza el trabajo es también quien crea y perfecciona las soluciones, y los límites se mantienen porque se aplican como características de la plataforma en lugar de negociarse proyecto por proyecto.

Los equipos de TI plantean una objeción razonable a este modelo que merece la pena destacar. El desarrollo ciudadano puede convertirse rápidamente en «TI en la sombra» cuando la plataforma no cuenta con un sistema de gobernanza real integrado. Las herramientas genéricas de bajo código que carecen de contexto industrial, de flujos de trabajo de aprobación, de registro de auditoría y de una gestión rigurosa de los permisos sí dan lugar a ese resultado, y hemos visto cómo los equipos de TI se han visto perjudicados por ello en el pasado.

Tulip estas cuestiones de forma directa. La gobernanza se integra en el modelo de permisos de la plataforma, el control de versiones, el flujo de trabajo de aprobación de cambios y el registro de auditoría, lo que significa que un ingeniero que desarrolle un flujo de trabajo en la línea de trabajo opera, por defecto, dentro de un marco autorizado.

Este modelo funciona a la hora de implantarlo porque quienes comprenden el trabajo son precisamente quienes diseñan el flujo de trabajo. Según nuestra experiencia, las implantaciones que se estancan suelen ser aquellas diseñadas por alguien que se encuentra a dos pasos del operario, mientras que las que logran escalar incorporan los comentarios directamente de los miembros del equipo que realizan el trabajo.

Un sistema de interacción, no solo un sistema de registro

La capa de datos es el tercer elemento. En un sistema de interacción, los datos fluyen en ambos sentidos. El operador genera datos a través del flujo de trabajo y, al mismo tiempo, recibe datos del sistema para tomar la siguiente decisión. La dirección sigue teniendo acceso a los datos y al registro de auditoría de las fases anteriores, pero el operador, el supervisor y el ingeniero de procesos obtienen la visibilidad que necesitan para tomar decisiones en tiempo real en la línea de producción.

Los datos se recogen de forma pasiva como consecuencia de la propia actividad, a través de lecturas de sensores, señales de las máquinas y confirmaciones del operario integradas en el paso que este ya estaba realizando de todos modos. No hay que rellenar ningún formulario aparte ni recordar ningún paso adicional.

La mayoría de las implementaciones comienzan con la arquitectura y el modelo operativo ya definidos. Lo que queda por decidir son cuestiones tácticas, y estas cinco áreas son en las que nos centramos desde el principio en todas las implementaciones en las que trabajamos. Las respuestas se van consolidando a lo largo del resto del proceso de implementación.

Empiece con un operario, un puesto de trabajo y una tarea

La primera implementación más fiable en cualquier proyecto en el que trabajamos es una única aplicación modular diseñada para un solo operador en una sola estación. Elija una tarea concreta que el operador realice en cada turno, a ser posible una que plantee dificultades y que el equipo haya estado resolviendo con papel. Cree un flujo de trabajo que le ayude a llevar a cabo ese paso de forma más eficaz, impleméntelo y deje que el operador y el supervisor evalúen si merece la pena utilizarlo antes de ampliarlo a más aplicaciones, más estaciones o más centros.

El enfoque ascendente resulta útil porque la adopción se decide operador por operador. Una vez que una aplicación se ha ganado su lugar en una estación, el equipo cuenta con la credibilidad necesaria para implementar la siguiente. Cuando varias aplicaciones se han ganado su lugar en un departamento, el equipo dispone de la base necesaria para implementarlas en todo el centro.

Elija un sitio piloto que sea representativo de la implantación

La planta más fácil suele ser la peor para la formación de pilotos. Las dificultades a las que se enfrentará finalmente la operación son precisamente las que el piloto debe aprender a superar, y un piloto que se forme en la planta más fácil obtendrá resultados que no serán extrapolables.

Un sitio piloto más útil es aquel que pone de manifiesto las dificultades con las que se encontrará la implantación más adelante: una planta que MES cuenta con un MES heredado en la planta de producción, o un entorno de producción regulado con su propio ciclo de auditoría. La función del proyecto piloto es detectar los puntos débiles antes de que la planta tres o la planta cuatro los pongan de manifiesto, lo que supondría un coste mayor.

Otorgue a los departamentos la responsabilidad sobre sus propios flujos de trabajo

A menudo, los departamentos no comparten los flujos de trabajo. La lógica de resolución de no conformidades de Calidad no se adapta realmente a la programación de la producción, y el ciclo de mantenimiento preventivo de Mantenimiento tiene su propia lógica en cuanto a mano de obra y piezas que Calidad no necesita. Intentar estandarizar la planta con una única estructura de formulario suele adaptarse razonablemente bien a un departamento y mal a los demás.

Las aplicaciones modulares ayudan a resolver este problema. Cada departamento puede adaptar la aplicación que utiliza dentro del marco de gobernanza de la plataforma mencionado anteriormente. No es necesario crear una solicitud de personalización para cada cambio en el flujo de trabajo, ya que el cambio se produce dentro de los límites que la plataforma ya impone. El equipo dispone de un sistema que se adapta a las necesidades de su trabajo, mientras que el equipo central sigue contando con el registro de auditoría y el nivel de seguridad que requiere.

Considere el tiempo de formación como un indicador clave de rendimiento (KPI)

El tiempo que tarda un nuevo operador en alcanzar la competencia refleja en qué medida el sistema se adapta al trabajo. Si los nuevos operadores necesitan tres semanas en un puesto antes de poder manejarlo sin supervisión, el sistema está dejando en manos de la memoria del operador tareas que la interfaz podría realizar por él. Lo que acorta esa curva son los flujos de trabajo digitales guiados que integran el siguiente paso adecuado en la pantalla del operador. Una mayor formación teórica previa rara vez basta por sí sola para salvar esa brecha.

Tomemos como ejemplo la división de implantes Dentsply. Gracias a un sistema Tulip, diseñado para gestionar más de mil millones de combinaciones de kits, el equipo redujo el tiempo de formación de los nuevos operadores en un 75 % en comparación con su flujo de trabajo anterior. Esta mejora se debe a que el sistema asume ahora gran parte del trabajo que antes recaía en la memoria del operador. Puede escuchar la historia completa sobre la implantación de Tulip Dentsplyaquí.

Planifique implementaciones en múltiples sedes para adaptarse a los cambios desde el primer día

El error más habitual en la implementación en múltiples sitios es la clonación del segundo sitio. El primer sitio funciona correctamente, el equipo toma la implementación del primer sitio como plantilla y el segundo sitio hereda un flujo de trabajo que no se adapta a sus necesidades. El equipo de implementación pasa el año siguiente adaptando el primer sitio para que pueda gestionar los problemas que han surgido en el segundo.

En la práctica, planificar la variabilidad implica mantener el núcleo global reducido y la capa de configuración a nivel de sitio lo suficientemente flexible. Cuantas menos cosas tengan que ser idénticas en todas las plantas, más fácil resultará poner en marcha cada nuevo sitio, y menos modificaciones tendrá que realizar el equipo de implementación cuando el segundo sitio ponga de manifiesto algo que el primero ya estaba haciendo de forma implícita.

Stanley Black & Decker un excelente ejemplo de ello. Llevan utilizando Tulip 2018, y el Sistema de Producción Stanley (SPX) ha pasado de ser una iniciativa de una sola planta a convertirse en un marco global que conecta más de 50 plantas y más de 1000 aplicaciones.

A medida que el equipo de Stanley fue ampliando y perfeccionando su Tulip a lo largo de los años, observó una reducción del inventario de más de 2.000 millones de dólares, un aumento de 15 puntos en el nivel de servicio y mejoras sostenidas en materia de calidad y seguridad. La clave para impulsar la adopción en todas las sedes ha sido mantener un núcleo global reducido, al tiempo que se ha facilitado la flexibilidad en las sedes locales para dar soporte a los diversos entornos, productos y procesos que conforman la cartera de Stanley.

MES que tienen éxito suelen compartir una estructura arquitectónica común: aplicaciones modulares que el equipo puede modificar sin necesidad de solicitar un ticket de TI, un núcleo global reducido que cada centro puede configurar sin necesidad de modificar la plantilla, y una capa de datos que ofrece al personal de planta la misma visibilidad en tiempo real que se envía a los supervisores.

La mayor parte de las dificultades de adopción que surgen a medida que una solución se amplía se remontan a las decisiones arquitectónicas tomadas desde el primer momento. La pregunta más útil que conviene plantear en la próxima reunión con el proveedor es qué aspectos facilitará la arquitectura seis meses después de la puesta en marcha y cuáles dificultará.

Si está valorando cómo evaluar o implantar un MES vayan a utilizar los operadores, los departamentos y las plantas,póngase en contacto con un miembro del Tulip . Colaboramos con fabricantes que cuentan con múltiples plantas precisamente en este tipo de decisiones.