La apertura: «conectado» no es «integrado»
Un fabricante planificó una implantación de WMS de seis meses; en el mes siete aún estaba en pruebas de integración. La retrospectiva: el propio WMS se ajustó en tres meses, los otros cuatro se fueron en interfaces con el ERP. Mi regla de oro: cuando la puesta en marcha de un WMS se retrasa, el 70% de los problemas está en las interfaces. El diseño de interfaces no es «conectar y listo»: cada detalle esconde un diablo. Si caes en tres de las ocho trampas siguientes, tu proyecto se retrasará.
Las ocho trampas
Trampa 1: nadie decidió quién es dueño de los datos maestros
Los maestros de artículos, clientes y proveedores pertenecen al ERP; el WMS los lee. Las ubicaciones, las reglas de lote y los parámetros de estrategia pertenecen al WMS. La pesadilla es la escritura bidireccional: si ambos lados editan el maestro de artículos, tarde o temprano divergirán. Principio: cada registro maestro tiene exactamente un dueño.
Trampa 2: las máquinas de estado de los documentos nunca se alinearon
El «aprobado» del ERP corresponde al «ejecutable» del WMS, pero entre medias puede haber varios estados como «asignado» y «liberado». Una brecha de estados congela documentos: el ERP cree que los envió, el WMS dice que nunca llegaron. Antes de programar, dibuja una tabla de equivalencia de estados de ambos lados y confirma cada estado.
Trampa 3: sin idempotencia en las interfaces
Las fluctuaciones de red provocan reintentos; el mismo documento de recepción se ejecuta dos veces y aparece inventario fantasma. Toda interfaz de escritura debe deduplicar por claves de negocio (número de recepción más número de línea), con llamadas repetidas devolviendo el primer resultado. Regla de hierro, sin excepciones.
Trampa 4: los campos de lote y número de serie nunca se mapearon por completo
Al ERP solo le importa que exista el número de lote; el WMS debe gestionar atributos de lote: caducidad, estado de inspección, motivos de retención. La hoja de mapeo de campos necesita confirmación línea por línea, especialmente los campos que el ERP tiene pero el WMS no, y los que el WMS necesita pero el ERP no proporciona. Define valores por defecto o flujos de carga manual por adelantado.
Trampa 5: momento de sincronización de inventario equivocado
La sincronización en tiempo real suena maravillosa, pero más de 100,000 movimientos diarios de inventario colapsarán el ERP. La combinación probada es «envío incremental más conciliación programada»: el WMS envía deltas en tiempo real, el ERP concilia cada 4 horas y los incumplimientos de umbral generan alertas.
Trampa 6: sin devoluciones estándar de excepciones
Las recepciones cortas, los daños y los rechazos en el WMS necesitan códigos de retorno estándar, y el lado del ERP necesita procesos equivalentes (repedidos, reclamaciones, chatarra). Sin ellos, los documentos con discrepancias se acumulan en el WMS mientras finanzas no puede cerrar el mes, y los dos departamentos se culpan mutuamente.
Trampa 7: sin monitorización de interfaces
Toda interfaz necesita lógica de reintento, una cola de mensajes fallidos y umbrales de alerta. Concilia a diario la primera semana y luego baja a semanal. Una interfaz sin monitorizar significa que operaciones descubre los fallos antes que TI: la forma más cara de enterarse.
Trampa 8: sin operación en paralelo en el corte
Ejecuta el sistema heredado y el nuevo WMS en paralelo durante 1–2 semanas con conciliación diaria al cierre; corta solo cuando la variación de inventario se mantenga por debajo del 0.5%. El corte directo exige valentía, pero el precio puede ser una línea detenida.
Tabla de contramedidas
| Trampa | Síntoma típico | Contramedida |
|---|---|---|
| Propiedad de datos maestros | Las dos partes discrepan | Un dueño por registro maestro |
| Brecha en máquinas de estado | Documentos congelados | Dibuja primero el mapa de estados |
| Sin idempotencia | Recepciones/emisiones duplicadas | Deduplicar por claves de negocio |
| Faltan campos de lote | Caducidad sin gestionar | Mapeo de campos línea por línea |
| Tiempos de sincronización | ERP colapsado | Envío incremental + conciliación programada |
| Sin devoluciones de excepciones | Discrepancias acumuladas | Códigos de retorno estándar + flujos de tratamiento |
| Sin monitorización | El negocio encuentra los fallos primero | Reintento + cola de fallidos + alertas |
| Sin operación en paralelo | El corte detiene la línea | 1–2 semanas en paralelo, conciliación diaria |
Caso real: tres rondas de retrabajo antes de la estabilidad
Un fabricante rehízo tres veces su integración WMS–SAP: primero las máquinas de estado se desalinearon y los documentos se congelaron; luego los campos de lote ausentes arruinaron la gestión de caducidades; solo en la tercera ronda se añadieron idempotencia y monitorización. Causa raíz: el entorno de pruebas de integración llegó dos meses tarde, así que el diseño de interfaces se construyó sobre documentación e imaginación. Lección: el entorno de pruebas y la hoja de mapeo de datos maestros son la primera prioridad del proyecto, no tareas secundarias.
Errores que hay que evitar
- Especificaciones antes que código. Las tablas de mapeo de campos, de equivalencia de estados y de códigos de excepción las firman ambas partes antes de empezar el desarrollo.
- Reserva al menos el 30% del tiempo del proyecto para interfaces. Asignación sana: 40% el WMS propiamente dicho, 30% interfaces y pruebas de integración, 30% corte y estabilización.
- Pon la cooperación del proveedor del ERP en el contrato. Muchos retrasos se remontan a la agenda del lado del ERP: las promesas verbales no cuentan.
Semana uno: construye el inventario de interfaces
No escribas código en la semana uno de un proyecto WMS: construye el inventario de interfaces:
| ID | Interfaz | Dirección | Frecuencia | Volumen diario | Responsable de negocio | Responsable de TI |
|---|---|---|---|---|---|---|
| IF-01 | Descarga de PO | ERP→WMS | Tiempo real | 500 pedidos | Planificación | TI |
| IF-02 | Confirmación de recepción | WMS→ERP | Tiempo real | 500 pedidos | Almacén | TI |
| IF-03 | Sincronización de inventario | WMS→ERP | Cada 4h | 100K registros | Finanzas | TI |
Clasifica por volumen × complejidad y ataca primero las difíciles. Regla: primero las interfaces de documentos centrales (recepción, envío, inventario), luego las de informes/consulta; cada interfaz tiene doble responsable, de negocio y de TI, para que siempre haya a quién llamar.
Esta tabla es el radar de alerta temprana del proyecto: la interfaz que aún no tenga responsable de negocio es tu futuro retraso.
El entorno de pruebas de integración: prepararlo tarde garantiza retraso
La causa más común de muerte de las pruebas de integración: el entorno no estaba listo. Cuatro elementos no negociables:
- Entorno de pruebas del ERP: los datos deben ser una copia enmascarada de producción, nunca una base de datos vacía. Probar contra vacío no es probar.
- Entorno de pruebas del WMS: la misma versión que producción, con datos maestros base completos.
- Datos de prueba: flujos normales más flujos de excepción (recepciones cortas, daños, rechazos, retenciones de lote), al menos 20 transacciones de cada uno.
- Tiempo de proveedor reservado: bloquea al consultor del proveedor del ERP con 4 semanas de antelación: una reserva verbal equivale a no reservar.
Puerta de preparación: ambos equipos de TI ejecutan de forma independiente una transacción comercial completa en el entorno de pruebas antes de invitar al personal de operaciones. El tiempo de la gente de negocio es el más caro: no lo quemes esperando entornos.
La conclusión
Las ocho trampas de la integración WMS–ERP son en realidad «suposiciones»: suponer que los maestros coinciden, que los estados se alinean, que la red no fluctúa. Tres tablas firmadas (mapeo de campos, equivalencia de estados, códigos de excepción) más idempotencia, monitorización y operación en paralelo eliminan el 70% del riesgo de retraso antes de que empiece.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
