Integración WMS–TMS–OMS sin caos
Arquitectura simple de datos para que pedidos, stock y transporte hablen el mismo idioma.
Integrar WMS, TMS y OMS no es “conectar tres logos en un diagrama”. Es decidir qué sistema es dueño de cada verdad —pedido, stock, guía, ETA— y cómo viajan los eventos cuando el Wi-Fi del muelle falla o el carrier responde tarde.
En operaciones mexicanas híbridas (ERP local + WMS cloud + paqueterías con APIs imperfectas), el caos aparece como stock duplicado, guías huérfanas y SAC inventando estados. La cura es arquitectura simple con contratos claros, no más archivos CSV nocturnos sin dueño.
Esta guía propone un diseño mínimo viable de integración: IDs, eventos, patrones técnicos sobrios y operación de fallos. Para que pedidos, inventario y transporte hablen el mismo idioma sin un proyecto eterno.
Síntomas de integración enferma
Pedidos que existen en OMS pero no bajan a WMS; stock web que vende lo que el rack no tiene; TMS con guía mientras el andén aún no cerró packing; ajustes manuales “para que cuadre” al cierre del día.
El Excel puente suele nacer como solución temporal y se vuelve sistema crítico sin versionado, sin alerta y con una macro que solo entiende una persona.
Primero nombra las fuentes de verdad: OMS (promesa y pedido), WMS (inventario y fulfillment), TMS (plan de transporte y tracking de ruta). Todo lo demás consume o proyecta.
- Inventaría interfaces actuales (API, CSV, email, WhatsApp).
- Cuenta errores de sync por semana y tiempo de detección.
- Identifica dobles capturas del mismo dato.
- Marca el “héroe” humano que pega datos a mano —riesgo clave.
Errores de sincronización / semana
IDs y contratos: el idioma común
Un pedido necesita ID estable de punta a punta (y correlaciones con ID de carrier). Un SKU, una unidad de medida y una ubicación deben mapearse sin ambigüedad. Sin eso, la integración solo propaga confusión más rápido.
Escribe contratos de payload mínimos: alta/cambio de pedido, reserva/liberación de stock, orden de despacho, confirmación pick/pack, creación de guía, eventos de tracking, excepciones. Campos obligatorios, tipos y ejemplos.
Versiona los contratos. Un cambio “pequeño” en OMS que rompe WMS un sábado es un clásico evitables con consumer-driven tests o al menos una checklist de release.
Dueños de datos
OMS no debería “inventar” stock. WMS no debería reescribir la promesa comercial sin evento. TMS no crea pedidos: los transporta.
Idempotencia
Reintentar un mensaje no debe duplicar guías ni doblar reservas. Diseña claves de idempotencia desde el día uno.
Artefactos y controles
| Control | Qué valida |
|---|---|
| Contrato de eventos | OpenAPI/ejemplo JSON por mensaje. |
| Mapa de dueños de datos | Evitar dobles fuentes de verdad. |
| Monitor de sync | Fallos, latencia, pedidos atrapados. |
| Dead-letter + runbook | Operar excepciones técnicas. |
| Pedido canario | Prueba de humo post-release. |
Contratos de datos mínimos
| Sistema | Emite | Consume |
|---|---|---|
| OMS | Pedido | WMS/TMS |
| WMS | Stock/evento pick | OMS |
| TMS | ETA/tracking | OMS/cliente |
| Todos | Excepción | Alertas |
Eventos canónicos del triángulo
Flujo feliz: OMS confirma → WMS reserva y cumple → WMS emite listo/salida → TMS/carrier asigna y trackea → OMS refleja estado a cliente y cierra. En cada flecha, un evento con timestamp.
Flujo de excepción: sin stock, dirección inválida, carrier rechazo, devolución. Las excepciones también son eventos de primer nivel —no comentarios en un chat.
Evita sincronizar “todo el catálogo cada hora” si puedes emitir cambios. Los lotes masivos esconden fallas y saturan.
Fuente de verdad
OMS pedido, WMS stock, TMS ruta —sin empates.
Evento idempotente
Reintentar no duplica guías ni reservas.
DLQ con runbook
El fallo visible se repara; el silencioso pudre el OTIF.
Patrones técnicos sobrios (sin overengineering)
API síncrona para acciones que deben confirmarse al momento (reserva, cotización). Cola/event bus o jobs confiables para eventos asíncronos (tracking, posteo de costos). Archivos solo como respaldo o para partners sin API —con validación y alerta.
Un iPaaS o middleware ligero ayuda cuando hay muchos endpoints; no es obligatorio si tienes 3 sistemas y un integrador disciplinado.
En México, planifica degradación: ¿qué pasa si la API del carrier cae en Hot Sale? Modo manual documentado + cola de reintento > silencio absoluto.
- Timeouts y reintentos con backoff.
- Dead-letter queue visible para ops/TI.
- Ambientes de prueba con pedidos sintéticos.
- Correlación de logs por order_id.
Fallos de sync / semana
Operar la integración: monitoreo y rollback
Tablero mínimo: mensajes exitosos/fallidos, latencia, pedidos atrapados entre sistemas, discrepancias de stock OMS vs WMS. Alerta a humanos con runbook: no solo a un correo que nadie lee.
Define rollback: cómo cancelar una reserva, anular guía, o reponer estado si un deploy falló. Sin rollback, cada incidente se vuelve arqueología.
Caso: una marca omnicanal bajó errores de sync semanales de ~48 (manual) a ~3 al sustituir CSV por API de eventos + cola de dead-letter y un orden_id único gobernado por OMS.
WMS, TMS y OMS solo “se hablan” cuando hay ID único, evento canónico y alguien mirando la cola de fallidos un martes a las 11.
— Arquitectura logística Problank
Gobernanza: el cambio que no rompe el sábado
Comité ligero (ops + TI + proveedor) para cambios de contrato. Calendario de releases. Catálogo de integraciones vivo. Pruebas de humo post-deploy con un pedido canario.
La integración madura cuando ops puede explicar el flujo feliz y el de excepción sin llamar al desarrollador cada vez. Documentación corta > wiki interminable.
Efecto medible del piloto
*Valores de referencia del piloto descrito en este artículo sobre integración WMS TMS OMS; mide tu propia línea base antes de proyectar.
FAQ de adopción
¿OMS o ERP como orquestador?
Si el ERP no maneja bien promesa omnicanal, un OMS (o capa de pedidos) orquesta mejor; el ERP sigue siendo financiero.
¿Tiempo real estricto en todos lados?
No. Reserva y stock crítico sí; algunos tracking pueden tolerar minutos. Declara SLAs por evento.
¿Qué hacer con carriers sin API?
Conector de portal/archivo con latencia explícita y plan de upgrade; no finjas paridad con APIs maduras.
¿Cómo probar sin romper producción?
Sandbox + pedidos canario en producción monitorizados + feature flags cuando exista.
¿Cuánto dura un MVP de integración?
Un flujo feliz pedido–fulfillment–guía suele tomar semanas, no trimestres, si el alcance se defiende con uñas.
Errores de implementación
Error
‘Con un CSV nocturno estamos integrados.’
Corrección
Estás diferido y ciego; el cliente vive en tiempo de promesa, no de batch.
Error
‘Hay que comprar un bus enterprise ya.’
Corrección
Primero contratos e IDs; el middleware amplifica un buen diseño, no lo sustituye.
Error
‘TI sola puede cerrar la integración.’
Corrección
Sin ops definiendo excepciones reales, el flujo feliz engaña en UAT y falla en piso.
Términos que no puedes mezclar
- SKU A/B/C: clasificación por rotación o criticidad.
- Slotting: ubicación física orientada a metros caminados y flujo.
- Evento canónico: estado único acordado entre WMS/TMS/OMS.
- Modo degradado: operación mínima cuando falla el sistema.
- Guardrail: métrica que evita romper servicio/costo al optimizar otra.
Criterio de go / no-go
La integración sin caos es menos magia de plataforma y más oficio de contratos: quién manda el dato, cómo viaja, qué pasa cuando falla. Con eso, el triángulo WMS–TMS–OMS deja de ser un diagrama aspiracional.
Empieza por IDs y el flujo feliz, añade excepciones y observabilidad, y gobierna cada cambio como si pudiera romper el sábado de envíos —porque puede. Ahí nace la operación digital que sí escala.
Checklist técnico de adopción
Marca lo que ya tienes resuelto. Tu progreso se guarda en este navegador.
