Hasta ahora, en nuestra serie de blogs sobre nuestra posición como aspirante en The 2022 Gartner® Magic Quadrant™ for Manufacturing Execution Systems (MES), hemos cubierto muchos detalles específicos sobre los conceptos de componibilidad y cómo se aplica en diferentes industrias.
Ahora es el momento de pensar por qué la plataforma de operaciones de primera línea de Tulipha sido elegida como aspirante en el Cuadrante MES, y lo que creemos que eso dice sobre los MES tradicionales.
La diferencia clave entre una plataforma como servicio (PaaS) y el MES tradicional es que la arquitectura de la primera permite una solución componible.
¿Qué aspecto tiene una arquitectura componible?
Existen cuatro pilares de la arquitectura componible.
Agilidad
La agilidad requiere que pueda ajustar los procesos a lo que hay que hacer, y no al revés. Este pilar se caracteriza por una rápida implementación, actualizaciones e iteraciones y por estructuras de datos flexibles y accesibles.
Extensibilidad
Una arquitectura componible es modular en su capacidad de conectarse con otras soluciones, ofreciendo una API abierta con conectores preconstruidos. También debe contar con conectividad de borde sin código y capacidades de bajo código.
Accesibilidad y escalabilidad
Una arquitectura componible debe permitirle replicar soluciones para sitios y situaciones similares. Debería ser fiable y rendir a medida que crece. Y los datos correctos deben ser accesibles desde cualquier lugar, no sólo desde un puesto determinado o incluso desde un sitio, en las estructuras de datos que la gente necesita.
Centrado en el humano
La componibilidad está centrada en el ser humano por naturaleza. Una arquitectura componible necesita contar con interfaces intuitivas y flujos de trabajo racionalizados con los datos de los dispositivos de los trabajadores. Estos requisitos representan los deseos y expectativas de la mano de obra manufacturera actual. La gente quiere trabajar para empresas innovadoras que valoren su experiencia.
¿Cómo eran los modelos del pasado?
Los MES tradicionales no pueden gestionar la composibilidad del mismo modo que una plataforma.
Imagine que quiere implantar un MES tradicional en un centro determinado. Repasa los procesos de requisitos y los diagramas de flujo operativo y elige un proveedor. El proveedor comienza a desplegar el MES.
Casi siempre se requiere una personalización por su parte. Tiene que adaptarse a los requisitos del sistema para la integración o el proceso.
En el mejor de los casos, tiene razón en todo lo que plantea en sus requisitos y nada cambia entre el momento en que seleccionó el MES y el de su plena implantación.
Ahora, quiere desplegarse en otro lugar. Allí las cosas son diferentes. Necesita hacer adaptaciones adicionales. (Tal vez no tenga máquinas en esa ubicación, mientras que su primera implementación era todo máquinas, por ejemplo). Entonces quiere añadir esto a una tercera ubicación. En cada implementación del mismo MES, cada cambio y adaptación que realice en el núcleo de la base de código es un poco diferente del anterior.
Supongamos ahora que desea identificar una buena práctica de su segundo sitio que sea directamente aplicable a su tercero. Se encuentra con un problema. El propio concepto de una base de código monolítica hace necesaria la personalización para la implementación de cada sitio.
Un enfoque de microservicios no lo hace.
Entonces, ¿qué retiene a nadie a cambiar a este enfoque, ahora que la indecisión sobre la nube está, en general, muerta?
Legado. Los fabricantes todavía tienen que lidiar con las consecuencias de las decisiones arquitectónicas que se tomaron cuando todo el software se construyó para su uso on-prem. No se puede simplemente levantar esa base de código y enviarla a la nube y esperar que funcione.
Es difícil recrear la forma en que la arquitectura nativa en la nube le permite construir si no empezó a construir allí.
Así que está atascado. Si no empezó con la nube nativa, es muy difícil tomar las mejores prácticas y pasar al siguiente sitio. Quizás sea aún más difícil actualizar, de MES 1.0 a MES 2.0, o 2.1 o 2.2. Es doloroso y lento.
Eso desde su perspectiva. Pero imagine cómo es para un proveedor tradicional de MES. ¿Cuáles son las implicaciones para ellos?
Si gestionan 12 clientes con 12 sitios cada uno, necesitan mantener 144 versiones diferentes de su código base. Cualquier cambio que hagan en su oferta principal tiene que ser compatible a la inversa con 144 bifurcaciones diferentes de ese código. Eso hace que la solución sea compleja y difícil.
Y esto explica la lentitud del cambio en la innovación que vemos en MES. Una decisión arquitectónica de día cero lo dicta todo.
Recapitulando, el modelo MES tradicional es:
Centrado en los sistemas, no en los humanos
Difícil de actualizar
Actualización lenta y costosa
Complejo y en silos
¿Cómo está desafiando Tulip al MES tradicional?
En comparación con la arquitectura anterior que hemos descrito (que, de nuevo, nació on-prem), una arquitectura nativa en la nube facilita y acelera las cosas.
La plataforma Tulip tiene una única base de código y las aplicaciones son configuraciones, no personalizaciones codificadas. Pensando en los pilares de la arquitectura componible, la agilidad y la extensibilidad así lo exigen.
Una única base de código permite actualizaciones regulares y rápidas en toda esa base de código, lo que equivale a actualizaciones quincenales o trimestrales de la plataforma en todos sus sitios, en lugar de revisiones y personalizaciones. Obtendrá antes acceso a nuevas capacidades.
Esto también significa que puede replicar fácilmente sus mejores prácticas en todos los sitios a través de las aplicaciones.
¿Recuerda a Sofiya, que creó una solución para sus operarios de primera línea en Stanley Black & Decker? Si ella viera la oportunidad de desplegar esa aplicación en diez centros más que pudieran beneficiarse, podría hacerlo de forma trivial. Eso sería prácticamente imposible si SB&D hubiera iniciado su camino hacia el desarrollo de aplicaciones con la arquitectura anterior y un MES tradicional.
En resumen, las ventajas de una plataforma nativa en la nube y de un modelo componible:
El mismo código base se ejecuta en todos los sitios
Mejores prácticas para compartir aplicaciones
Visión global de todas las operaciones
Actualizaciones silenciosas cada dos semanas
Acceda antes a la innovación
Las aplicaciones sin código permiten flexibilidad
En The 2022 Gartner® Magic Quadrant™ for Manufacturing Execution Systems (MES) vemos muchos comentarios reflexivos sobre las implicaciones del cambio en el mercado. Y vemos la introducción de la capacidad de innovación arquitectónica MES, que supone que el proveedor proporciona una arquitectura de microservicios que soporta el nivel de agilidad y velocidad de desarrollo que creemos que requiere la empresa de fabricación de éxito de hoy en día.
El MES tradicional no lo permite. Por eso Tulip es un desafío.
Aun así, es importante señalar que el cambio de la MES tradicional a la componibilidad no es específico de Tulip.
Es más fundamental. Se trata de cómo concebimos el desarrollo de software y de dónde debe y puede producirse: Las soluciones tradicionales se construían sobre decisiones arquitectónicas on-prem, pero la composabilidad requiere una arquitectura nativa en la nube. Estamos listos para avanzar en la fabricación.
Automatice la recogida de datos y mejore la productividad con Tulip
Hable con un miembro de nuestro equipo para ver cómo un sistema de aplicaciones puede conectar a los trabajadores, las máquinas y los dispositivos de todas sus operaciones.