Por qué su integración EDI está atada a su antiguo ERP
Las conexiones EDI (Electronic Data Interchange) parecen pertenecer al socio. En la práctica, pertenecen al sistema que está detrás.
Un cliente que le envía una orden de compra la envía en un formato acordado, con identificadores acordados, a un punto de conexión acordado. Esos identificadores proceden de su ERP. Los códigos de artículo, los códigos de cliente, las convenciones de unidades de medida y los códigos de IVA son el vocabulario de su sistema, traducido una vez cuando se construyó la conexión y congelado desde entonces.
Esa traducción suele incluir cuatro elementos:
- Identificadores de producto: sus códigos de artículo mapeados a las referencias de catálogo del propio socio, artículo por artículo
- Códigos de socio y ubicación: qué cliente, qué dirección de entrega, qué sucursal, expresados en códigos que emitió su ERP
- Estructura de los documentos: qué campos son obligatorios en un pedido, un aviso de expedición o una factura, y en qué orden
- Reglas de validación: lo que el socio rechaza, incluidas las tolerancias de cantidad, precio y ventana de entrega
En la mayoría de las empresas, nada de esto está documentado en un solo lugar. Está en la propia conexión y en la memoria de quien la construyó. Eso se convierte en un problema en cuanto cambia el sistema de debajo.
Qué se rompe cuando cambia el ERP de debajo
Un nuevo ERP emite sus propios identificadores. Los códigos de artículo cambian, los códigos de cliente cambian y el modelo de datos en el que se basaba el mapeo original deja de existir.
El fallo rara vez es espectacular. Un pedido llega y se rechaza porque un campo que el socio espera ahora está vacío. Una factura se acepta y luego se disputa porque el código de IVA se mapea de otra forma. Un aviso de expedición sale con una unidad de medida que el socio interpreta como cajas en lugar de palés.
Estos fallos aparecen socio a socio, y eso es lo que los encarece. Una empresa con decenas de socios EDI no tiene un solo fallo. Tiene una cola de ellos, y cada uno necesita que una persona distinta en una empresa distinta confirme una corrección.
El mismo patrón se aplica a la migración de datos en general, como se explica en la migración de datos de ERP y WMS con una plataforma de integración. El EDI es la versión en la que alguien de fuera de su empresa tiene que dar su aprobación antes de corregir nada.
Lo que cuesta realmente rehacer una integración EDI
El remapeo no es la parte cara. Un analista reconstruye un mapeo en unas horas. Lo que le cuesta a la empresa está alrededor de ese trabajo:
- Pedidos rechazados en el lado del socio: un campo que falta hace que el pedido nunca llegue a su sistema, y el cliente le reclama a usted en lugar de a su propio equipo de EDI
- Facturas disputadas en lugar de pagadas: un código de IVA mapeado de otra forma se convierte en una nota de abono, una conversación con finanzas y un cobro que llega un mes tarde
- Sus mayores clientes, obligados a hacerle un favor: los cambios de EDI requieren pruebas por parte del socio, así que sustituir un sistema se convierte en una petición a las empresas a las que intenta vender
- El mismo trabajo la próxima vez: los mapeos reconstruidos sobre el nuevo ERP quedan igual de atados a él, así que la siguiente sustitución costará lo mismo
- Sustitución aplazada o evitada: las empresas con grandes entornos EDI suelen aplazar los cambios de sistema por lo que les costará rehacerlo
Esto último es el verdadero precio. El EDI deja de ser una obligación técnica y se convierte en un motivo para no cambiar nunca de sistema.
Cómo gestiona una plataforma de integración la integración EDI
Un iPaaS (integration Platform as a Service) da a una empresa un único lugar donde se conectan todos sus sistemas. Cada sistema se conecta a él una vez en lugar de conectarse directamente a los demás, y la plataforma mueve y transforma los datos entre ellos. Las empresas lo usan para el trabajo diario: pedidos de la tienda online al ERP, stock de vuelta y datos de envío a un transportista.
El EDI funciona con el mismo esquema, con una diferencia que importa aquí. El socio se conecta a la plataforma en lugar de al ERP. El mapeo entre el formato del socio y su modelo de datos reside en la plataforma, no dentro de la conexión, así que cambiar lo que hay detrás no cambia lo que ve el socio.
La plataforma de integración de Alumio ofrece funciones que se pueden configurar para mantener estables las conexiones EDI durante un cambio de ERP:
- El punto de conexión del socio no cambia: los socios siguen enviando al mismo lugar en el mismo formato, así que una sustitución detrás de la plataforma no requiere ningún cambio por su parte
- Los mapeos son visibles y editables: un Transformer contiene la traducción entre los formatos de los socios y sus identificadores, así que remapear a un nuevo ERP es un cambio de configuración que su propio equipo puede hacer
- Ambos sistemas pueden funcionar a la vez: los flujos pueden apuntar al ERP antiguo y al nuevo durante la transición, así que nadie depende de una única fecha de cambio
- Puede ver lo que envió cada socio: los registros de mensajes muestran exactamente lo que llegó y lo que se devolvió, lo que resuelve una disputa con un socio en lugar de alargarla
Alumio también ofrece un EDI Broker para las empresas que prefieren que la conexión se gestione por ellas en lugar de construirla. El mismo principio se aplica fuera del EDI. AGU conecta su ERP Centric con Adobe Commerce y Akeneo a través de Alumio en lugar de hacerlo directamente, con datos normalizados que permiten conectar otras herramientas más adelante. Los nuevos canales pueden añadirse después como Routes adicionales sin reconstruir lo que ya funciona.
Lo que le aporta una integración EDI independiente de los socios
El EDI suele tratarse como una obligación heredada, mantenida porque los grandes clientes la exigen. Esa visión es la razón por la que acaba la última en el plan y la primera en los retrasos.
El ERP tampoco es el problema. Una empresa debería poder sustituirlo cuando el antiguo deja de encajar, y la mayor parte de ese proyecto está bajo su control. Lo que hace la decisión más difícil de lo necesario es que el ERP acaba conteniendo traducciones para sistemas mucho más allá de sí mismo: los socios comerciales, pero también la tienda online, el almacén y los transportistas. Trasladar esas traducciones a una capa de integración separa ambas cosas, de modo que los socios conservan su punto de conexión y el ERP vuelve a ser simplemente un ERP.
Lo que obtiene la empresa es un entorno de sistemas que puede cambiar a su propio ritmo, donde sustituir el ERP es un proyecto y no una negociación, y donde la integración EDI sobrevive al sistema para el que se construyó originalmente.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
