Más allá de MES tradicionales: por qué el futuro de la fabricación pasa por soluciones nativas en el borde y centradas en la primera línea

La gama de productos está cambiando cada vez más rápido. Los operarios con experiencia se marchan y son sustituidos por trabajadores que necesitan más apoyo desde el primer día. Los datos de las máquinas quedan almacenados en controladores, sistemas de registro histórico o software específico de cada proveedor, que ningún otro sistema puede leer fácilmente.

Aunque estos problemas no son nuevos, cada vez resulta más difícil gestionarlos con herramientas cuya configuración lleva meses y cuya modificación requiere aún más tiempo.

Cuando un ingeniero de procesos necesita actualizar una instrucción de trabajo, redirigir un flujo de trabajo o registrar un nuevo atributo de calidad, la respuesta que suele dar un sistema tradicional es «abrir una solicitud de cambio». Para cuando ese cambio llega a la planta, es probable que los operarios ya se hayan adaptado a él de manera informal, o que el momento de riesgo ya haya pasado.

Los plazos de implementación son parte del problema. Un sistema cuya puesta en marcha lleva un año ya va con retraso. Las operaciones cambian más rápido de lo que avanzan la mayoría de los programas de implementación, lo que significa que los equipos acaban poniendo en marcha una versión del proceso que ya no refleja cómo se desarrolla realmente el trabajo.

Los ingenieros de procesos y los responsables de la transformación digital son los primeros en percibirlo. Son ellos quienes intentan salvar la brecha entre lo que indica el sistema y lo que realmente hacen los operadores.

Los equipos de operaciones lo perciben en la variabilidad del rendimiento y en el coste que supone mantener los sistemas actualizados.

Los evaluadores de TI y TO lo perciben en la deuda de integración que se acumula cada vez que es necesario conectar una nueva fuente de datos o un nuevo dispositivo.

La capa de ejecución debe adaptarse al ritmo de las operaciones. Ese es el estándar al que debe ajustarse cualquier sistema.

MES tradicionales se han ganado un lugar en la planta de producción.

Estos sistemas aportaron a los fabricantes algo verdaderamente valioso: una capa operativa coherente entre ERP los equipos de producción. De esta capa surgieron registros de trabajo estandarizados, registros electrónicos de lotes, trazabilidad desde la materia prima hasta los productos terminados y documentación lista para auditorías. Especialmente para los sectores regulados, esto no era opcional. Constituía la base del cumplimiento normativo.

El modelo ISA-95 de Nivel 3, que dio forma a la mayoría MES heredadas, tenía sentido en su época. Proporcionó a los fabricantes un lenguaje común para la integración entre la empresa y las operaciones, así como un espacio lógico para gestionar la programación, la calidad y los datos de producción en relación con los sistemas empresariales de nivel superior y los sistemas de control de nivel inferior. Esa claridad tenía un valor operativo real.

Estos sistemas también se diseñaron para un tipo específico de entorno de fabricación: líneas de productos relativamente estables, ciclos de cambio más largos, gestión centralizada de las tecnologías de la información y calendarios de producción que no variaban de una semana a otra. En ese contexto, un sistema cuya configuración llevaba meses y cuya modificación requería la intervención de especialistas no constituía necesariamente un inconveniente. El ritmo de cambio era lo suficientemente lento como para poder asumirlo.

Es importante tener esto en cuenta. El argumento a favor de MES moderna no es que los sistemas heredados estuvieran mal diseñados, sino que el entorno de fabricación para el que se diseñaron ha cambiado considerablemente y los supuestos arquitectónicos en los que se basaban esos sistemas no han sabido adaptarse a los nuevos tiempos.

Los problemas de MES heredados MES en el desfase que existe entre el momento en que se produce un cambio en un proceso y el momento en que el sistema refleja dicho cambio.

Los ciclos de implementación son el principal obstáculo. MES tradicionales MES se prolongan durante meses, a veces incluso años. Para cuando el sistema entra en funcionamiento, la necesidad operativa que lo justificaba suele haber cambiado. Se está fabricando una nueva variante de producto. Se ha reconfigurado una línea de producción. Ha cambiado un requisito de cumplimiento normativo. El sistema llega tarde a un problema que ya ha pasado a otra cosa.

Los cambios en los flujos de trabajo agravan el problema. En la mayoría de las arquitecturas heredadas, modificar un paso del proceso implica abrir un ticket, esperar a un proveedor o a un especialista interno y seguir un ciclo de control de cambios que puede prolongarse durante semanas.

Ese no es un ritmo razonable para una planta que se adapta constantemente a la variabilidad de la demanda, a los cambios en la mano de obra y a las actualizaciones técnicas. El cuello de botella no es el personal, sino la arquitectura.

La conectividad de las máquinas sigue el mismo patrón. La conexión de un nuevo equipo a un MES heredado MES un proyecto de integración a medida, con su propio alcance, calendario y presupuesto. En entornos mixtos con máquinas antiguas, protocolos diferentes y sistemas de control de diversas generaciones, ese enfoque no resulta escalable. Cada nueva conexión se convierte en una negociación.

Por otra parte, está la experiencia del operador. Muchos sistemas heredados se diseñaron para la captura de datos, no para orientar en la ejecución. El resultado es lo que se conoce como «papel sobre cristal»: una pantalla que reproduce un formulario en papel sin ayudar realmente al operador a realizar mejor su trabajo. No hay orientación contextual, ni información en tiempo real, ni conexión entre lo que muestra el sistema y lo que está haciendo la máquina o el proceso. Los operadores tienen que adaptarse al sistema en lugar de trabajar con él.

Detrás de todo esto se esconde una dependencia estructural de los especialistas. Cada cambio, ya sea una modificación del flujo de trabajo, un nuevo campo de datos o una actualización de la conectividad, requiere que lo lleve a cabo alguien con un profundo conocimiento del sistema. Esto genera un coste de coordinación que se acumula con el tiempo y ralentiza a los equipos que están más cerca del trabajo.

MES nativo de la nube supuso un auténtico avance, y es importante comprender por qué antes de pasar a lo que dejó sin resolver.

MES tradicionales instalados en las propias instalaciones MES una inversión considerable en infraestructura, largos ciclos de implementación y un equipo especializado para gestionar cada actualización. Los sistemas nativos de la nube eliminan muchas de estas dependencias.

Las arquitecturas basadas en API facilitan la conexión MES ERP, los sistemas de calidad y otros programas empresariales sin necesidad de crear integraciones punto a punto personalizadas para cada uno de ellos. Los ciclos de actualización son más cortos, ya que no es necesario esperar a que el equipo de TI local valide e implemente cada versión. La ampliación a múltiples centros se convierte en una cuestión de coordinación, en lugar de un proyecto de infraestructura.

Los análisis, los informes y los servicios centralizados también resultan más prácticos. En lugar de agregar datos procedentes de servidores locales aislados, las plataformas nativas de la nube pueden recopilar datos operativos en una capa común, donde resultan realmente útiles para obtener una visibilidad global y realizar comparativas de rendimiento.

Este cambio también concuerda con la interpretación cada vez más extendida de la norma ISA-95. El modelo original describía una jerarquía rígida de niveles, desde los dispositivos de campo hasta los sistemas empresariales. MES nativos de la nube MES orientar el debate hacia una interpretación de la norma ISA-95 como un conjunto de límites lógicos e interfaces flexibles entre las operaciones y los sistemas empresariales, en lugar de una pila fija de niveles locales. Se trata de un enfoque más útil para entornos de fabricación distribuidos y con múltiples emplazamientos.

Sin embargo, MES nativos de la nube resolvieron MES los problemas relacionados con la coordinación y la capa de servicios. Lo que no resolvieron fue la ejecución a nivel de planta.

La conexión de máquinas, sensores y herramientas a los flujos de trabajo seguía requiriendo un importante trabajo de integración. Las aplicaciones destinadas a los operadores seguían siendo una cuestión secundaria en la mayoría de las implementaciones. El último tramo entre la nube y la estación de trabajo seguía siendo complicado, y es ahí donde, en realidad, se concentra hoy en día la mayor parte de las dificultades en la fabricación moderna.

MES nativos de la nube MES la arquitectura en la dirección correcta. Sin embargo, sigue existiendo una brecha entre lo que los sistemas en la nube hacen bien y el lugar donde realmente se lleva a cabo la fabricación.

Esa brecha es la base. Máquinas, sensores, herramientas, cámaras, operarios, estaciones de montaje, puntos de inspección. Es aquí donde se lleva a cabo la ejecución, donde se toman decisiones en tiempo real y donde los problemas de latencia y conectividad tienen consecuencias reales.

Una arquitectura exclusivamente en la nube puede tener dificultades en este caso, no porque la nube sea una herramienta inadecuada, sino porque la planta no puede permitirse esperar a que se resuelva la latencia de ida y vuelta, y la conectividad no siempre está garantizada.

La ejecución nativa en el borde significa que el sistema funciona cerca del lugar de trabajo. La lógica se ejecuta localmente. Las instrucciones para el operador aparecen en contexto. Las señales de la máquina activan los pasos del flujo de trabajo sin necesidad de esperar a un servidor remoto. Cuando una cámara detecta una anomalía o un sensor supera un umbral, la respuesta se produce en la estación de trabajo, no tras un viaje de ida y vuelta a un centro de datos.

Se trata de una distinción significativa. El perímetro no es una pasarela que se instala a posteriori para cumplir un requisito informático. Es el entorno de ejecución, la capa en la que realmente se desarrollan el contexto en tiempo real y la capacidad de respuesta de los operadores.

La nube sigue siendo importante, y lo es mucho. La coordinación, el análisis, la gobernanza, la gestión de la implementación y la escalabilidad se gestionan mejor de forma centralizada. Cuando se necesita aplicar una actualización del flujo de trabajo en 40 líneas, auditar datos de procesos para una revisión de cumplimiento normativo o agregar indicadores de calidad entre distintos centros, la infraestructura en la nube es el lugar idóneo para llevar a cabo esa labor.

Las dos capas son complementarias. La nube se encarga de lo que debe centralizarse. El borde se encarga de lo que debe gestionarse a nivel local. Juntas, resuelven los problemas que las arquitecturas exclusivamente en la nube no pueden abordar por completo: la latencia en el lugar de trabajo, las dificultades de adopción por parte de los operadores, la conectividad en entornos ya existentes y la necesidad de una capacidad de respuesta en tiempo real en el punto de trabajo.

Esta es la arquitectura que realmente requieren las operaciones de fabricación modernas.

La arquitectura solo aporta valor si las personas la utilizan realmente. Es aquí donde observamos que muchos proyectos MES se estancan silenciosamente.

El sistema se implementa, los datos fluyen y, a continuación, los operadores buscan soluciones alternativas porque la interfaz no se ajusta a la forma en que se desarrolla realmente el trabajo en la planta.

Para hacerlo bien, hay que pensar en lo que cada parte interesada necesita realmente de una capa de ejecución.

Los operarios necesitan flujos de trabajo digitales guiados que se adapten al contexto. Si cambia el número de pieza, las instrucciones deben cambiar. Si un paso no supera una comprobación, el sistema debe redirigir el proceso en consecuencia. Las pantallas estáticas que reproducen un formulario en papel no hacen eso. Trasladan la carga cognitiva al operario en lugar de reducirla, que es precisamente el problema que la mayoría de los fabricantes están tratando de resolver.

Los ingenieros de procesos necesitan actualizar la lógica de los flujos de trabajo sin tener que esperar a que se resuelva una cola de desarrollo. Cuando se produce un cambio en un proceso, se documenta una desviación o se introduce una nueva variante de producto, las personas más cercanas a ese trabajo deben poder actuar con rapidez. Los largos ciclos de desarrollo a medida rompen ese ciclo de retroalimentación y convierten la mejora continua de un hábito diario en un acontecimiento trimestral.

Los supervisores necesitan una visibilidad que refleje lo que realmente está ocurriendo en la ejecución, y no solo datos brutos de telemetría de las máquinas que se muestran en un panel de control independiente. Saber que una máquina está en funcionamiento aporta menos información que saber que una máquina está en funcionamiento, que un operador se encuentra en el paso 7 de 12 y que se ha activado una alerta de calidad hace 20 minutos. La visibilidad operativa conectada implica que todas esas señales se reúnen en un único lugar.

Los responsables de TI y de la tecnología operativa (OT) necesitan una adaptabilidad regulada. Otorgar a los equipos de primera línea la capacidad de crear y modificar aplicaciones solo es sostenible si existe una capa de gobernanza que lo respalde. Las aprobaciones configurables, los controles de cambios y los permisos de acceso son los elementos que evitan que una flexibilidad bienintencionada se convierta en una proliferación descontrolada de aplicaciones y en un quebradero de cabeza a la hora de realizar auditorías.

El modelo que aglutina todo esto es una mejora impulsada por el personal de primera línea y regulada por las tecnologías de la información. Los operadores y los ingenieros impulsan los cambios. Las tecnologías de la información y las tecnologías operativas establecen las directrices. Ese equilibrio es lo que evita que la autonomización se convierta en un riesgo de incumplimiento normativo y que el control se convierta en un cuello de botella.

El argumento sobre la arquitectura solo es válido si la realidad de la implementación lo respalda. A continuación se explica cómo funciona realmente la capa periféricaTulip en la práctica.

Conectar máquinas sin necesidad de un gran programa de integración.Los dispositivos periféricos Tulip conectan máquinas, sensores y herramientas inteligentes directamente a las aplicaciones y actúan como fuentes de datos de máquina nativas. No tendrá que esperar a que se complete un proyecto de middleware personalizado para incorporar los datos de las señales a un flujo de trabajo. La conexión forma parte del entorno de desarrollo de aplicaciones, no es una iniciativa de TI independiente que se desarrolle en un plazo distinto.

La conectividad en entornos industriales existentes es una opción real, no una solución provisional. La mayoría de las plantas no parten de cero. Tulip los entornos mixtos mediante Node-RED en dispositivos periféricos, patrones de conector-host locales y configuraciones orientadas a OPC UA y MQTT. Esa combinación le permite acceder a equipos heredados, PLC y sistemas locales sin necesidad de reconstruir primero su infraestructura. De este modo, se reduce el alcance de lo que realmente requiere la conectividad.

Orientación al operario integrada en la ejecución. Las instrucciones de trabajo digitales de Tulip documentos estáticos que se muestran en una pantalla. Son flujos de trabajo en tiempo real que responden a las señales de la máquina, activan pasos en función de eventos en tiempo real y recogen datos contextuales en el momento en que se realiza el trabajo. Cuando una herramienta de par de apriete indica que ha finalizado, la aplicación responde. Cuando se omite un paso o un valor se sale del rango, el sistema lo detecta. Esa es la diferencia entre un documento de referencia y una capa de ejecución.

La visión cierra el ciclo en la estación de trabajo. Tulip utiliza cámaras comerciales que ejecutan funciones locales en el borde para complementar a los operadores con comprobaciones visuales prácticas: OCR para la verificación de etiquetas y piezas, detección de anomalías, detección de plantillas, compatibilidad con «pick-to-light» e inspección de defectos. No se trata de un sistema de visión independiente acoplado al sistema. Se ejecuta dentro del mismo entorno de la aplicación, lo que significa que el resultado de la comprobación visual puede activar el siguiente paso del flujo de trabajo, señalar un evento de calidad o detener un proceso antes de que un defecto pase a la siguiente fase.

Empiece con un enfoque específico y amplíe de forma planificada. El modelo de aplicaciones modulares Tulip se basa en un modelo de datos común y en componentes reutilizables. Un equipo puede implementar una prueba piloto específica en una línea o un proceso, validar su valor y ampliarla a partir de ahí. No se compromete desde el principio a sustituir toda la plataforma. La arquitectura está diseñada para permitir una implantación por fases, lo cual resulta importante a la hora de gestionar las limitaciones de recursos, la gestión del cambio y el riesgo operativo que supone intervenir en el entorno de producción en funcionamiento.

Reducción del tiempo hasta obtener el primer valor

Con un MES monolítico, el lapso de tiempo que transcurre entre la firma del contrato y la puesta en marcha del software en la planta suele medirse en trimestres. Las plataformas modulares y nativas de la periferia reducen considerablemente ese plazo.

Apps desarrollar e implementar en cuestión de días. Los primeros resultados, ya se trate de unas instrucciones de trabajo guiadas, un formulario de registro de calidad o un sistema de seguimiento del tiempo de inactividad de las máquinas, se hacen visibles en unas semanas. Las implementaciones a mayor escala se amplían en meses, en lugar de años.

Esa rapidez es importante porque los problemas de fabricación no esperan a que concluyan los largos ciclos de implementación.

Visibilidad en tiempo real con contexto operativo

Los datos de telemetría sin procesar de una máquina le indican qué está haciendo dicha máquina. Sin embargo, no le indican qué estaba haciendo el operador en ese mismo momento, qué fase del proceso estaba activa ni si se había registrado un incidente de calidad dos minutos antes.

Las plataformas nativas de Edge integran todas esas señales: la ejecución de los flujos de trabajo, los datos de las máquinas, los eventos de calidad y las acciones de los operadores se registran en relación entre sí. Ese contexto es lo que hace que la visibilidad sea útil, en lugar de limitarse a ser meramente informativa.

Conectividad más sencilla en zonas industriales abandonadas

La mayoría de las fábricas no son instalaciones totalmente nuevas. Funcionan con una combinación de equipos de diferentes épocas, distintos fabricantes y diversos protocolos de comunicación.

Lograr MES un MES tradicional MES comunique con ese entorno suele convertirse en un proyecto en sí mismo, con tareas de integración a medida que aumentan el tiempo y el coste antes incluso de haber capturado un solo dato.

La conectividad nativa en el borde, con compatibilidad con patrones de conectores locales, Node-RED y configuraciones orientadas a OPC UA o MQTT, hace que la modernización sea viable en esos entornos mixtos sin necesidad de realizar primero una renovación completa de la infraestructura.

Mejora continua impulsada por el personal de primera línea

Uno de los costes menos evidentes de MES monolíticos MES el tiempo que lleva realizar cualquier cambio. Un ingeniero de procesos que detecta una secuencia más adecuada, un supervisor que necesita añadir un control de calidad, un jefe de equipo que desea ajustar una instrucción de trabajo: en un sistema tradicional, esos cambios suelen requerir una solicitud de desarrollo, un ciclo de control de cambios y semanas de espera.

Las plataformas modulares permiten a los responsables de los procesos realizar esos cambios directamente, sin que ello afecte a los controles de gobernanza, las aprobaciones ni la gestión de versiones. El ciclo de mejora avanza al ritmo de la operación, no al ritmo del proveedor de software.

Menores costes de coordinación a largo plazo

Cada cambio que requiere la intervención de un proveedor de servicios supone un aumento de los costes y un retraso. Con el tiempo, esto se convierte en una carga operativa considerable, que los directores de operaciones perciben con especial intensidad cuando intentan justificar el coste total de propiedad de un sistema que sigue necesitando ayuda externa para actualizar un campo de un formulario.

La arquitectura modular reduce el volumen de cambios que requieren ese tipo de coordinación. Los equipos gestionan más tareas internamente, la colaboración con los proveedores se reserva para trabajos verdaderamente complejos y, en consecuencia, el perfil de costes a largo plazo es diferente.

Elegir una plataforma operativa resulta más sencillo cuando se saben las preguntas adecuadas que hay que plantear. A continuación, le ofrecemos algunas consideraciones que debe tener en cuenta la próxima vez que evalúe soluciones.

¿Con qué rapidez puede conectar máquinas, dispositivos y sistemas locales?
Si conectar una máquina CNC o una cámara de visión requiere un programa de integración específico, se está ante un modelo obsoleto. La arquitectura moderna debe admitir la conectividad de sistemas existentes mediante protocolos estándar como OPC UA y MQTT, con dispositivos periféricos que puedan actuar como fuentes de datos nativas desde el primer momento. El objetivo es disponer de datos conectados en cuestión de semanas, no de trimestres.

¿Pueden los equipos de primera línea modificar los flujos de trabajo sin la intervención de especialistas?
Los ingenieros de procesos y los supervisores de línea saben cuándo una instrucción de trabajo es incorrecta o falta un paso. Si cada corrección requiere enviar una solicitud al departamento de TI o recurrir a los servicios de un proveedor, sus ciclos de mejora siempre irán por detrás de sus operaciones. Busque plataformas en las que los responsables de los procesos puedan actualizar la lógica dentro de un marco regulado, con aprobaciones y control de versiones integrados, y no añadidos a posteriori.

¿Convierte los datos de las máquinas y los sensores en indicaciones para el operario en el punto de trabajo?
Los datos brutos que permanecen en un panel de control y que nadie consulta no aportan ningún valor operativo. La pregunta más relevante es si el sistema puede tomar una señal de la máquina, una lectura del sensor o una comprobación de visión y presentársela al operario en forma de indicación, paso de validación o alerta de calidad en el momento oportuno.

¿Permite la arquitectura una implementación por fases y una expansión gradual?
Las implementaciones radicales conllevan riesgos reales. Evalúe si la plataforma permite comenzar con una sola línea o un solo proceso, basándose en un modelo de datos común, y expandirse de forma planificada. Los sistemas modulares le permiten demostrar el valor desde el principio y ampliar lo que funciona.

¿Puede coexistir con sus MES actuales ERP, PLM, QMS o MES ?
La sustitución rara vez resulta viable en un plazo breve. La plataforma que elija debe integrarse con los sistemas que ya gestionan su negocio, no competir con ellos por los mismos datos ni obligarle a desmantelar la infraestructura antes de obtener ningún beneficio.

La cuestión de la arquitectura no se reduce realmente a una disyuntiva entre la nube y el perímetro. Se trata de determinar dónde rinde mejor cada capa.

La nube se encarga de aquello en lo que destaca: la coordinación entre sedes, el análisis a gran escala, la gobernanza, los registros de cumplimiento normativo y las integraciones que vinculan las operaciones con los sistemas ERP, PLM y de calidad. Así es como se obtiene visibilidad en toda una red distribuida y la infraestructura necesaria para gestionar el cambio de forma coherente.

Edge se encarga de lo que la nube no puede hacer en tiempo real: la ejecución local, la conectividad de los equipos, la orientación al operador en el puesto de trabajo y una capacidad de respuesta que no depende de la latencia de la red ni de un viaje de ida y vuelta a un servidor remoto. Ahí es donde realmente se lleva a cabo el trabajo, y ahí es donde la mayoría de los sistemas heredados siempre se han quedado cortos.

Las aplicaciones de primera línea son las que conectan esas dos capas con las personas que realizan el trabajo.

Cuando los operadores disponen de flujos de trabajo guiados que reflejan la lógica actual de los procesos, y cuando los ingenieros de procesos pueden actualizar dichos flujos sin tener que esperar a que se resuelva una cola de desarrollo, la mejora continua se convierte en algo en lo que participa realmente el personal de planta, en lugar de ser algo que se impone desde arriba. La gobernanza se mantiene. Los equipos de TI/TO siguen controlando los mecanismos de seguridad. Pero las personas más cercanas al proceso disponen de las herramientas necesarias para actuar en función de lo que observan.

El modelo modular Tulip se basa en esta estructura de tres niveles. Los fabricantes pueden comenzar con una implementación específica, demostrar su valor en cuestión de semanas y ampliarla de forma planificada a otras líneas de producción, centros y áreas de proceso. Se trata de una alternativa significativa al ciclo completo MES , que a menudo requiere más tiempo y dinero de lo que justifican las mejoras operativas.