Un pedido que atraviesa el ERP (Enterprise Resource Planning), el WMS (Warehouse Management System o SGA) y el TMS (Transportation Management System) pasa por tres sistemas que rara vez comparten una única base de datos. Cuando la integración entre ellos no está bien resuelta, el síntoma no tarda en aparecer: un mismo artículo con dos códigos distintos, un stock que cuadra en un sistema y no en otro, un pedido que el almacén da por servido y el transporte no encuentra. El artículo explica qué papel debe jugar cada sistema, qué datos exigen sincronía constante y qué patrones de integración sostienen esa sincronía sin depender de que alguien corrija a mano lo que dos aplicaciones no se dijeron entre sí.
Qué gobierna cada sistema en la cadena de suministro
El ERP es, por definición, el sistema que administra los datos maestros de la empresa: artículos, clientes, proveedores, precios y pedidos de venta y compra. Es el punto donde nace un pedido y donde se registra la factura que lo cierra, pero no es el sistema que sabe en qué ubicación exacta descansa una referencia ni cuánto tarda un camión en llegar a un punto de entrega.
El WMS gobierna lo que ocurre dentro de las cuatro paredes del almacén: ubicaciones, unidades de carga, tareas de recepción, picking y expedición. Trabaja con el mismo maestro de artículos que el ERP, pero añade una capa de detalle operativo — ubicación, lote, estado físico de la mercancía — que al ERP no le corresponde mantener. El TMS, por su parte, gobierna lo que ocurre desde que la mercancía sale del muelle: planificación de rutas, asignación de transportista, seguimiento de la entrega y el EDI (Electronic Data Interchange) con los operadores externos. Los tres sistemas necesitan los mismos hechos — qué se ha pedido, qué hay en stock, qué se ha enviado —, pero cada uno los necesita con un grado de detalle distinto y en un momento distinto del proceso.
Dónde aparecen las duplicidades y los descuadres
La consecuencia de no delimitar ese reparto se ve antes en los síntomas que en la causa. El más habitual es la duplicidad de maestros: el mismo artículo dado de alta con una referencia en el ERP y con otra ligeramente distinta en el WMS, porque ambos sistemas permitieron crear registros de forma independiente. A partir de ahí, cualquier informe que cruce ventas con stock arrastra el error sin que salte ninguna alarma.
El segundo síntoma es el descuadre de stock: el ERP muestra una cantidad disponible que no coincide con la que el WMS tiene físicamente ubicada, porque un ajuste de inventario se hizo en un sistema y no se propagó al otro. El tercero es la pérdida de trazabilidad entre almacén y transporte: una expedición que el WMS marca como preparada y que el TMS nunca llega a planificar, porque la confirmación de que el paquete está listo para salir no viajó de un sistema a otro con la fiabilidad necesaria. En los tres casos, el problema no está en ningún sistema por separado — cada uno hace bien lo que le corresponde —, sino en el punto donde se tocan.
Por qué ocurre: la frontera confusa entre maestros de datos
Esos descuadres casi siempre nacen de la misma decisión no tomada: nadie ha fijado qué sistema es la fuente única de verdad para cada dato. Si el ERP y el WMS pueden crear o modificar un código de artículo de forma independiente, es cuestión de tiempo que diverjan; si el estado de un pedido puede cambiar en el WMS sin que el ERP se entere del cambio hasta el cierre de un proceso por lotes nocturno, existe una ventana en la que ambos sistemas cuentan una historia distinta del mismo pedido.
La solución no consiste en que los tres sistemas compartan toda la información entre sí, sino en que cada dato tenga un único origen y que el resto de sistemas lo reciban, no lo generen. El ERP es el origen del maestro de artículos, de clientes y de pedidos; el WMS es el origen del estado físico del inventario — ubicación, disponibilidad real, lote — mientras la mercancía está en el almacén; el TMS es el origen del estado de una expedición desde que sale del muelle. Cuando esa jerarquía está clara, cada sistema deja de intentar llevar su propia versión de un dato que no le corresponde generar y se limita a consumir la versión oficial.
Los datos que exigen sincronía constante
Establecido quién genera cada dato, queda decidir qué información concreta necesita viajar entre sistemas y con qué frecuencia. Las referencias de artículo deben sincronizarse en el momento en que se crean o modifican en el ERP, porque cualquier retraso deja al WMS operando con un maestro desactualizado. Las ubicaciones y los estados de SKU (Stock Keeping Unit) por unidad de carga, en cambio, son datos que solo tiene sentido mantener en el WMS y exponer al ERP como una cifra agregada de disponibilidad, no como el detalle físico completo.
Los estados de pedido son, de los tres, los que más penalizan un retraso: si el WMS confirma que una línea está preparada y esa confirmación tarda horas en llegar al ERP, el equipo comercial sigue prometiendo un plazo de entrega que ya no es real. Las confirmaciones de envío cierran el ciclo: cuando el TMS registra que un vehículo ha recogido la mercancía, ese evento debe llegar al ERP y al WMS con la rapidez suficiente para que ambos actualicen el estado del pedido sin depender de una consulta manual. Cuanto más cerca de tiempo real viaje este último grupo de datos, menor es la ventana en la que un cliente o un transportista reciben una respuesta que ya no coincide con la realidad del almacén.
Los patrones de integración que sostienen esa sincronía
Qué tan cerca del tiempo real llega cada dato depende del patrón de integración elegido, y no todos sirven para todo. Una API expone operaciones puntuales — crear un pedido, consultar un stock, confirmar una expedición — con una respuesta inmediata, lo que la hace adecuada para los eventos que no toleran retraso, como la confirmación de una recogida. Su coste es que exige que ambos sistemas mantengan la conexión disponible y respondan dentro de un tiempo razonable, algo que no todos los ERP heredados garantizan.
El EDI resuelve el intercambio con socios externos — proveedores, clientes, transportistas — mediante mensajes estructurados con un formato acordado de antemano; es el estándar habitual para intercambiar pedidos y confirmaciones de entrega con terceros que no van a integrarse por API. Las colas de mensajes desacoplan el envío de la recepción: el sistema origen publica un evento y el destino lo procesa cuando puede, lo que absorbe picos de carga sin perder información, a cambio de que la actualización no sea instantánea sino casi inmediata. Los procesos por lotes, por último, siguen siendo razonables para lo que no exige inmediatez — una conciliación contable nocturna, por ejemplo —, pero se convierten en un problema en cuanto se usan para datos como el estado de un pedido, porque introducen precisamente la ventana de desactualización que genera los descuadres descritos antes.
La integración entre ERP, WMS y TMS no se resuelve eligiendo la tecnología más sofisticada, sino decidiendo primero qué sistema es dueño de cada dato y, después, qué patrón de intercambio respeta la urgencia real de cada uno. Un almacén que sincroniza por lotes lo que debería viajar por API arrastrará descuadres aunque los tres sistemas estén técnicamente conectados; uno que tiene claro el reparto de responsabilidades puede sostener esa sincronía incluso con una integración modesta.