Integración ERP-WMS: por qué los datos maestros van primero — Manual de secuencia para el go-live

Mi veredicto de entrada: cuando integras ERP y WMS, los datos maestros van primero. Siempre. He liderado más de 30 go-lives, y todos los proyectos que intentaron «activemos primero las interfaces de pedidos y ya limpiaremos los datos maestros después» estallaron la noche del go-live. La única excepción no fue suerte — simplemente se retrasó lo suficiente como para que alguien terminara bien el trabajo de datos maestros.

Piensa en ello como carreteras y tráfico. La integración pone en movimiento las órdenes de compra y las órdenes de venta entre el ERP y el WMS — esa es la carretera. Los datos maestros son la señalización: códigos de artículo, códigos de ubicación, fichas de cliente. Si la señal del ERP dice «SKU-48213» y el WMS lee «SKU48213», el tráfico se estrella. Tener las interfaces activas no significa estar listo para el go-live. Esa escena la he visto tres veces, al pie de la letra.

Por qué empezar por los datos maestros al final siempre detona

Verano de 2024. Una marca de belleza con su propio almacén en Riverside, California — 50,000 pies cuadrados, unos 4,000 pedidos al día. El director de TI del cliente decidió: «La limpieza de datos maestros toma demasiado tiempo. Activemos primero las interfaces de PO y SO y rellenamos los datos maestros después del go-live.»

Tres días antes del go-live, el ERP envió una orden de compra al WMS. Error: artículo no encontrado. El número de artículo del ERP era «SKU-48213»; el WMS lo había importado como «SKU48213» — faltaba un guion. Ninguno de los dos lados cedía, porque la especificación de la interfaz solo decía «pasar el número de artículo tal cual». Basura entra, basura sale.

Y empeoró. El ERP tenía más de 6,000 SKU activos, incluidos más de 400 artículos zombi — descatalogados, resucitados, descatalogados de nuevo, pero aún sentados en las tablas de precios. La mañana del go-live, la primera oleada de recepción se topó con errores de «artículo no mantenido» en el muelle. Los camiones se apilaban. No empezamos a operar hasta las 4 PM, con 12 remolques atascados en las puertas. La solución: congelar la creación de artículos en el ERP esa noche, declarar al WMS maestro de artículos y sincronizar de vuelta hacia el ERP. El go-live se retrasó dos semanas y quemó tres semanas extra de consultoría.

Contrástalo con un 3PL de artículos para el hogar en Ohio al año siguiente. El día uno, bloqueamos tres estándares de codificación — artículos, clientes, ubicaciones — ocho semanas antes del go-live. Cualquier SKU nuevo que entrara al edificio tenía que pasar primero una revisión de datos maestros. Las interfaces de pedidos se integraron al final, en las últimas dos semanas. La noche del go-live tuvimos exactamente dos incidencias. Una fue un desajuste de longitud de campo — 20 caracteres en el ERP, 30 en el WMS — corregido con una regla de truncado en media hora. Fue uno de los go-lives más tranquilos que he liderado.

Lado a lado, la respuesta es obvia: los datos maestros primero no es la opción prudente, es la única opción que sobrevive al contacto con la realidad. Los datos maestros son el lenguaje común de los dos sistemas. Si el lenguaje no está unificado, conversaciones más rápidas solo producen malentendidos más grandes.

Cómo dirijo las integraciones ERP-WMS: la secuencia en siete pasos

El mismo manual en todos los proyectos. Síguelo y estarás bien:

1. Bloquea los estándares de codificación antes que nada. De ocho a diez semanas antes del go-live, finaliza el estándar de codificación de artículos, el estándar de codificación de ubicaciones y el estándar de codificación de clientes/proveedores — firmados por las tres partes. Quien firma se hace cargo de cualquier cambio posterior. Después de la firma, congelado: los casos especiales pasan por una solicitud de cambio, no por una conversación de pasillo.

2. Dale a cada dominio de datos maestros un único dueño. El ERP y el WMS necesitan los datos de artículos, pero solo un sistema es la fuente de la verdad. Mi reparto habitual: los artículos pertenecen al ERP (las finanzas y las compras viven allí), las ubicaciones pertenecen al WMS (el almacén conoce sus racks), los clientes pertenecen al ERP, los proveedores pertenecen al ERP. El dueño crea y mantiene; los sistemas aguas abajo leen.

3. Haz una conciliación completa de datos maestros. Sin atajos: recorre los artículos activos del ERP línea por línea contra el stock físico del WMS. Caza tres cosas — códigos que no coinciden, nombres/especificaciones que no coinciden y artículos zombi sin actividad pero que siguen apareciendo en los documentos. En un proyecto la limpieza sacó a la luz un 7% de zombis. Déjalos vivos y el go-live se convierte en un explosivo con temporizador.

4. Firma el documento de mapeo de campos campo por campo. Nada de «más o menos funciona» — cada cabecera, línea de pedido, código de artículo, unidad de medida, número de lote y fecha de caducidad recibe un origen, un destino y una regla de conversión. Las unidades de medida especialmente: he hecho cuatro proyectos donde el ERP usaba cajas y el WMS usaba piezas. Equivoca el factor de conversión una sola vez y todo un lote de documentos es basura.

5. Levanta las interfaces de datos maestros antes que las transaccionales. La secuencia no es negociable: sincronización de maestro de artículos activa y conciliada → ubicaciones/clientes/proveedores activos → documentos de negocio (PO, ASN, SO, devoluciones) al final. Invertir este orden significa que estás probando contra falsos positivos.

6. Prueba con datos sucios de verdad. Los escenarios de prueba deben incluir a los sospechosos habituales: un código de artículo con un dígito de más, un nombre de cliente con un espacio al final, un número de lote demasiado largo. Una integración probada solo con datos limpios es una integración no probada.

7. La lista de verificación de la noche anterior al go-live (la uso en todos los proyectos):

   • ¿Están congelados los tres estándares de codificación, con cero solicitudes de cambio abiertas?
   • ¿Se completó la conciliación total de artículos ERP→WMS con cero discrepancias?
   • ¿Están los maestros de ubicaciones sincronizados con el WMS y se verificaron las ubicaciones vacías?
   • ¿Están los artículos zombi marcados como inactivos y los nuevos documentos ya no pueden referenciarlos?
   • ¿Se revisaron los factores de conversión de unidades artículo por artículo?
   • ¿La reproducción completa del día de negocio (PO → recepción → putaway → wave → envío → callback) corrió en verde de principio a fin?
   • ¿Cuál es el plan de rollback si las interfaces fallan masivamente el día del go-live?

La frecuencia de sincronización de datos maestros también vale la pena fijarla. Artículos, clientes y proveedores deberían moverse casi en tiempo real: un artículo creado en el ERP debe llegar al WMS en minutos, no de la noche a la mañana. Los maestros de ubicaciones viven dentro del WMS y entran en vigor de inmediato. Vi un proyecto que sincronizaba artículos en lote a medianoche; a las 10 AM el almacén necesitaba enviar un producto nuevo cuyo artículo aún no había llegado, así que no se podían crear las tareas de picking. Casi en tiempo real es el mínimo: si la latencia supera los 15 minutos, la interfaz debería lanzar una alerta.

Cuándo puedes ir transaccional primero: la jugada híbrida

Hay excepciones. Si estás ante: un almacén greenfield, cero inventario heredado, menos de 500 artículos y solo dos tipos de documento — entonces corre un híbrido: reglas de datos maestros e interfaces transaccionales en paralelo, pero las interfaces de datos maestros siguen activándose primero. Eso en realidad es datos-maestros-primero con un calendario comprimido.

La única excepción genuina que he visto: el ERP es un sistema heredado que nadie puede tocar, y el WMS es la construcción nueva, con el ERP antiguo sin ninguna gobernanza de datos maestros. Mi jugada ahí es entregar toda la autoridad de datos maestros al WMS — el WMS crea artículos, ubicaciones, clientes; el ERP solo envía documentos y recibe callbacks. «Los datos maestros siguen al sistema nuevo» sigue siendo unificar el lenguaje antes de empezar la conversación.

Alerta de detonación: las trampas que estallan la noche del go-live

Trampa uno: longitudes de campo que no coinciden. El ERP permite 50 caracteres para el nombre corto del cliente; el WMS acepta 30. Nadie lo revisó antes del go-live. Los nombres de clientes se truncaron en tránsito, y el mismo cliente tenía nombres distintos en los dos sistemas — conciliación imposible. Solución: escribe la longitud en la tabla de mapeo para cada campo, y define la política de desbordamiento (truncar o dar error) — elige una.

Trampa dos: factores de conversión enterrados en el código. Algunos integradores codifican en duro «1 caja = 24 piezas». El cliente cambia la especificación de empaque; la interfaz no da error; los datos se van degradando en silencio durante tres meses. Solución: el factor debe ser un campo en el maestro de artículos, viajando con el artículo — nunca codificado en duro.

Trampa tres: documentos de devolución que referencian artículos muertos. El artículo se desactivó en el ERP, pero una devolución en el WMS aún lo referencia. Llega el documento, la interfaz lanza «artículo no encontrado» y el proceso de devolución se congela. Solución: antes de desactivar un artículo, revisa en el WMS los documentos abiertos que lo referencien — una puerta de prevalidación.

Trampa cuatro: desalineación de la dimensión organización. La estructura organizativa del ERP no mapea uno a uno con los códigos de almacén del WMS; la interfaz pasa un código de organización y el WMS lo resuelve al edificio equivocado. Solución: el mapeo de organizaciones tiene su propia tabla, nunca mezclado en el mapeo de artículos.

Para tu próximo proyecto de integración ERP-WMS, haz que la primera línea de la pizarra del kickoff diga «datos maestros primero» — y que las tres partes la firmen. Me lo agradecerás. Todos los proyectos que he corrido en ese orden tuvieron una noche de go-live tranquila. Todos los que corrieron el orden inverso me llamaron presa del pánico a medianoche.

Por Lin Xiao, consultor de implementación WMS

Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.