.svg)
Por qué la modernización de la fabricación rara vez es un proyecto de arrancar y reemplazar
La tentación de la TI de fabricación es planificar la modernización como un único proyecto de migración al ERP. Elija el nuevo sistema, fije la fecha de transición, transfiera los datos, capacite a los equipos y retire el sistema anterior. Ese modelo funciona en las plataformas de diapositivas, pero falla en las plantas. Las operaciones de fabricación modernas rara vez toleran el tipo de riesgo de inactividad que conlleva la sustitución total de un ERP. El ecosistema circundante de aplicaciones en la nube, portales de clientes y herramientas de análisis también necesita datos de ERP confiables mucho antes de que se complete cualquier migración.
Esta es la razón por la que la mayoría de los fabricantes, en última instancia, toman un camino diferente. Mantienen su ERP heredado en funcionamiento mientras conectan las aplicaciones en la nube que lo rodean a través de una capa de integración. La modernización se lleva a cabo de forma gradual, y la capa de integración absorbe la complejidad que, de otro modo, implicaría proyectos de migración riesgosos.
Los ERP antiguos mantienen la lógica empresarial que los fabricantes no pueden permitirse romper
La razón por la que persisten los ERP tradicionales no es solo la nostalgia o las restricciones presupuestarias. Es la lógica empresarial acumulada que vive en su interior. Un ERP de fabricación típico contiene décadas de reglas de precios, secuencias de producción, condiciones de proveedores, flujos de intercambio electrónico de datos y dependencias operativas específicas para cada cliente, que se han ido creando en torno al sistema a lo largo del tiempo. En primer lugar, la mayor parte de esa lógica nunca se documentó correctamente.
Eso hace que el reemplazo sea riesgoso de una manera que es difícil de cuantificar por adelantado. Un plan de transición limpio puede incluir todos los módulos, todas las interfaces y todos los informes. No puede enumerar todas las soluciones alternativas indocumentadas que un planificador de producción creó hace seis años para resolver un problema específico de un proveedor. Esas soluciones son importantes, porque se han convertido en dependencias operativas que la empresa no sabe que tiene.
El resultado es que los proyectos de reemplazo de ERP tienden a descubrir su alcance real a mitad de la migración, momento en el que el proyecto ya está en ejecución y el costo de pausarlo aumenta cada semana.
¿Qué es una plataforma de integración híbrida?
Una plataforma de integración híbrida es una categoría de software que conecta los sistemas locales con las aplicaciones en la nube a través de una capa de integración gestionada. La palabra «híbrida» describe la arquitectura que soporta, en la que los sistemas antiguos que se ejecutan en centros de datos privados o en hardware dedicado coexisten con aplicaciones en la nube que se ejecutan en entornos compartidos.
Para la fabricación, esto es importante porque la estructura operativa rara vez se encuentra en un solo lugar. El ERP suele ejecutarse localmente en AS/400, IBM i o en una infraestructura Windows o Unix más antigua. Por el contrario, la plataforma de comercio, el CRM y el entorno de análisis suelen ser nativos de la nube, cada uno con su propio método de conexión, modelo de seguridad y formato de datos.
Una plataforma de integración híbrida gestiona los mecanismos de conexión en todos estos aspectos, incluidas las llamadas a la API, las transferencias de archivos, los mensajes EDI, las consultas a las bases de datos y los flujos impulsados por eventos. También gestiona la transformación, la validación y la supervisión de los datos a medida que pasan de un sistema a otro, de modo que las aplicaciones en la nube reciben los datos del ERP en formatos que realmente pueden utilizar.
Conexión de AS/400, IBM i y SAP ECC a aplicaciones en la nube a través de una capa de integración
El desafío técnico en la integración de los ERP antiguos rara vez tiene que ver con un solo protocolo. La conectividad del mainframe, la integración con AS/400 y la integración con SAP ECC tienen sus propias convenciones. Los entornos AS/400 suelen exponer los datos a través de consultas de DB2, transferencias de archivos o interfaces antiguas basadas en mensajes. SAP ECC normalmente admite llamadas BAPI, IDOCS y RFC. Otros sistemas aún se basan en la serie MQ, en intercambios basados en FTP o en protocolos patentados.
Una plataforma de integración como servicio (iPaaS) de uso general gestiona todo esto a través de una única capa de configuración, en lugar de requerir un código personalizado para cada uno. El iPaaS de Alumio admite la conectividad directa de bases de datos (MySQL, PostgreSQL, MSSQL), los intercambios basados en archivos a través de FTP y SFTP, los estándares EDI (X12, EDIFACT), las API REST y SOAP y los complementos de API específicos de SAP que muestran los puntos finales ECC y R/3. Esa amplitud es importante porque la mayoría de los fabricantes tienen que integrar varios sistemas antiguos, cada uno con necesidades de conexión diferentes.
Pelican Products, un fabricante estadounidense de equipo de protección para viajes con 1400 empleados en 27 países, integró su ERP SAP ECC R/3 local con Adobe Commerce a través del iPaaS Alumio. El sistema SAP sigue funcionando como registro operativo para el procesamiento de las finanzas, el inventario y los pedidos, mientras que Adobe Commerce se encarga del escaparate orientado al cliente. Los dos sistemas intercambian datos en tiempo real a través de la capa de integración, lo que resolvió los errores financieros y de inventario que generaba la configuración independiente anterior. Ese modelo, en el que el ERP tradicional permanece en su lugar y la capa de nube se conecta mediante la integración, se aplica en la mayoría de los escenarios de modernización de la fabricación.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
