Te doy el veredicto de entrada: cuando los números de pedido no coinciden entre tus sistemas, la integración casi nunca está rota. Lo que está roto es la tabla de mapeo que nadie posee.
Otoño de 2023: un 3PL de ropa de más de 60,000 pies cuadrados a las afueras de Ontario, California. La jefa de atención al cliente me llamó: su equipo se ahogaba en tickets de «¿dónde está mi pedido?». La tienda mostraba todos los pedidos como enviados, pero al hacer clic en el número de seguimiento aparecía «no existe tal envío», o peor aún, el paquete de otra persona. TI pasó una semana revisando los registros y todas las interfaces estaban en verde: OMS, WMS, API de los transportistas, cero errores.
Tres meses antes, una actualización del WMS había cambiado la forma de generar los números de pedido hijo tras una división. Nadie avisó al lado del OMS, que siguió armando los ID a la manera antigua. Cuando los números de seguimiento volvieron del transportista, la lógica de retroescritura los emparejaba con los pedidos adivinando sobre la cadena del ID: si adivinabas mal, un número de seguimiento caía en el pedido equivocado. Los conductos estaban bien; lo que se rompió fue la suposición de que un ID en un sistema significa lo mismo en otro.
He visto esta película al menos diez veces en veinte años, y el momento del descubrimiento en Ontario muestra por qué los registros en verde mienten. El líder de TI tomó un pedido problemático y lo recorrimos juntos, pantalla por pantalla: el OMS decía pedido 88412, enviado, con número de seguimiento adjunto. El WMS decía que el pedido 88412 se había dividido en dos preparaciones hijas, pero las hijas estaban numeradas con el nuevo esquema, 88412-A y 88412-B, mientras que la retroescritura del OMS seguía emparejando con el patrón antiguo, 88412-01 y 88412-02. Los números de seguimiento habían vuelto a casa perfectamente, colgados de números de pedido que ya no existían en ningún lado. Cada API había hecho su trabajo; el contrato sobre cómo se ve un ID se había reescrito de un lado y nunca se había vuelto a firmar del otro.
La cadena se rompe en tres puntos previsibles
El viaje de un pedido tiene cuatro paradas —el pedido padre en el OMS, las preparaciones y los paquetes en el WMS, las etiquetas y el seguimiento en el TMS y el transportista, la retroescritura de estado al OMS— y tres costuras previsibles.
Primero, los envíos divididos. En el OMS, un pedido es un número. Dentro del WMS se divide en dos oleadas y tres paquetes según dónde esté el inventario, y esos números hijo viven solo en el WMS. El OMS ni sabe que las hijas existen. Los números de seguimiento vuelven a casa dirigidos al padre, y quien busque por número de hija no encuentra nada. La variante más fea es el envío parcial: tres paquetes, dos transportistas, el tercero corto de stock. El OMS marca todo el padre como «completo»: el cliente recibe dos cajas, y el tercer número de seguimiento queda huérfano.
Segunda costura: la retroescritura del seguimiento. El transportista emite el número de seguimiento, el TMS lo captura, y luego la retroescritura lo apunta al pedido equivocado. El clásico: una etiqueta sale mal impresa, alguien la reimprime, el número de seguimiento antiguo nunca se anula, y ahora dos números activos apuntan a un mismo paquete. El cliente y el representante de atención al cliente rastrean cada uno uno distinto. Todos tienen razón y todos se equivocan.
Tercera costura: los lotes y las tarimas, y esta es del público B2B. Los retailers exigen un aviso anticipado de envío 856, y el número de serie SSCC-18 de la tarima física tiene que coincidir carácter por carácter con el número a nivel de paquete del ASN: un dígito mal y toda la tarima es rechazada. Una vez vi a un almacén generar los ID de tarima automáticamente en el WMS mientras el aviso de envío 945 se tecleaba a mano. Esos dos números nunca fueron la misma cosa. Explotó tres meses después en la conciliación, y los contracargos habrían comprado un buen montacargas.
Las integraciones mueven datos; las tablas de mapeo hacen que los datos concuerden, y el segundo trabajo es donde están enterrados los cuerpos.
También hay una trampa en el flujo de devoluciones: un paquete se recibe en el almacén contra un número de RMA, pero el reembolso en el OMS cuelga del número de pedido original. Sin un mapeo de RMA a pedido, finanzas termina con reembolsos huérfanos. El peor caso que vi: cientos de reembolsos sin emparejar en un solo mes, operaciones pasando una semana entera emparejándolos a mano.
Haz que la tabla de mapeo sea aburrida
Mi método de rastreo es un solo movimiento: recorre la cadena, sin saltos. Primero averigua si el ID es un padre o un hijo, y qué sistema lo parió. Avanza hacia adelante un salto a la vez; el salto donde el ID deja de conectar es tu ruptura. Nueve de cada diez veces la encuentras en el segundo salto.
Antes de arreglar los datos, haz tres preguntas. ¿Este mapeo lo escribió un sistema o lo tecleó una persona? ¿Cambió alguna regla recientemente? ¿Cuántos más están rotos de la misma manera? Arreglar un registro es apagar incendios. Arreglar el lote es diagnosticar. En ese caso de Ontario escribimos un script que recolgó cada número de seguimiento mal mapeado de los tres meses anteriores: más de cuatro mil pedidos en una sola pasada. Ir haciendo clic uno por uno habría tenido a atención al cliente ocupada hasta el año que viene.
Luego el blindaje. Cinco reglas, cada una pagada con matrícula.
Una tabla canónica. De pedido a hijo, de hijo a paquete, de paquete a etiqueta, de etiqueta a número de seguimiento, y de ahí a lote y tarima: todo en una sola tabla de mapeo, dentro de un sistema, con un responsable nombrado y un registro de cambios. Cada tabla de mapeo que he visto pudrirse tenía el mismo problema de organigrama: el equipo del OMS pensaba que el del WMS era el dueño, el del WMS pensaba que el analista EDI del 3PL era el dueño, y el analista pensaba que era «solo una referencia». Pon un nombre en ella: alguien que revise el registro de cambios cada mes y participe en cada actualización, alta de transportista y cambio de especificación de retailer. El incidente de Ontario ocurrió porque una actualización del WMS llegó con una nota de lanzamiento que nadie del lado del OMS leyó: un responsable lo habría detectado en una revisión de diferencias de cinco minutos.
Nomina tus ID con su espacio de nombres. Prefija cada ID con su sistema de origen para que un número nacido en el WMS nunca pueda colisionar con uno nacido en el OMS. Suena burdo; me ha salvado tres veces. Dos sistemas adoran los enteros autoincrementales simples, y sin prefijos colisionarán: una vez vi los pedidos de dos clientes 3PL fluir a un mismo WMS, ambos empezando en 10001, y el sistema colgó los paquetes del cliente A en los pedidos del cliente B. Una tarima completa se envió al cliente equivocado.
Devuelve el ID del paquete en eco. Cuando un número de seguimiento vuelve a casa, debe llevar el ID del paquete con el que salió. Una cadena de seguimiento pelada no se puede rastrear hacia atrás: reimprime una etiqueta dos veces y buena suerte adivinando a qué pedido del OMS pertenece el número de seguimiento. El 856 ya tiene la estructura para esto: segmentos REF que llevan el número de seguimiento como referencia de conocimiento de embarque junto con el propio del transportista. Úsala.
Concilia a diario. Ejecuta un trabajo programado: enviado en el WMS, pendiente de actualización en el OMS, con eventos de seguimiento del transportista. Compara los tres conjuntos: lo que caiga en el despeñadero es por lo que le gritarán mañana a atención al cliente. Tres cubetas: enviado en el WMS pero nunca actualizado en el OMS: retroescritura perdida; actualizado en el OMS pero sin eventos del transportista: etiqueta impresa, mercancía nunca movida; eventos del transportista sin registro en ninguno de los dos lados: normalmente etiquetas de prueba o números obsoletos de reimpresiones. Clasifica primero, actúa después.
Versiona tu lógica de división: prueba cada cambio de regla de división contra el mapeo primero en un entorno de pruebas. Una comprobación de dos minutos, retrasada tres meses.
Una disyuntiva que conviene resolver de entrada: callbacks del transportista en tiempo real frente a conciliación por lotes para la retroescritura del seguimiento. El tiempo real es rápido, pero cuesta más y los callbacks se pierden. El lote llega con medio día de retraso y es sólido como una roca. Las operaciones pequeñas deberían usar lotes sin vergüenza y activar el tiempo real dos semanas antes de la temporada alta. Lo que ahorres no cubrirá las horas extra del incendio de las 2 a.m.
Y un «desajuste» más que no es un problema de ID en absoluto: la hora. El WMS sella los envíos en hora del Pacífico, el OMS los interpreta en UTC, y el mismo pedido cae en días distintos a cada lado. Los representantes buscan «los envíos de hoy», no encuentran nada y asumen que el ID se perdió. Los almacenes que abarcan zonas horarias pisan esta constantemente: revisa los relojes antes de revisar los ID.
Así que aquí va mi pregunta para ti: ve y pregúntale a tu equipo de TI cuándo fue la última vez que alguien abrió la tabla de mapeo de ID. Si la respuesta es «la última vez que algo se rompió», la próxima ruptura ya viene en camino.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
