Eran las 9:40 de una noche de martes cuando me llamó el gerente de operaciones. Tenía esa calma plana que la gente adopta cuando ya hizo las cuentas y no le gusta el resultado. "Vendimos 300 unidades de un SKU esta noche", dijo. "El WMS muestra cero disponibles. El OMS todavía dice que nos quedan 40."
Ningún sistema estaba roto. La integración entre su sistema de gestión de pedidos y su sistema de gestión de almacenes funcionaba exactamente como estaba diseñada. El problema era el propio diseño: nadie había preguntado qué significaba realmente "funcionar" para los números de inventario que fluían de vuelta hacia arriba. Esa brecha de 40 unidades era el retraso de sincronización, y para cuando alguien lo notó, los pedidos sobrevendidos ya estaban en el sistema.
He visto esta película suficientes veces como para saberme el guion de memoria. La dirección OMS→WMS —los pedidos que bajan— recibe toda la atención durante la implementación. El camino de regreso, el inventario que sube, se construye como un añadido de último momento. Y ahí es donde se fuga el dinero.
La cifra en tu pantalla del OMS es historia, no una transmisión en vivo
Sigamos el flujo real de datos. Los pedidos llegan de todos los canales de venta, aterrizan en el OMS para el enrutamiento y la asignación, y luego bajan al WMS para el picking, el empaque y el envío. En la dirección contraria, el WMS tiene que reportar al OMS las recepciones, las ubicaciones, los picks y los ajustes de conteo, que a su vez envía las cantidades disponibles para prometer a cada canal. Ese tramo de regreso es donde vive el retraso, y viene de 3 lugares.
El primero es la frecuencia de sincronización. Muchas integraciones todavía funcionan por programación —cada 15 minutos, cada media hora, a veces cada hora. Eso significa que 200 unidades con pick en el WMS a las 8:05 no aparecen en el OMS hasta la siguiente ejecución programada. Durante el pico de tráfico nocturno, esa ventana es exactamente cuando ocurre la sobreventa. Pasar a envíos basados en eventos (se registra una recepción, se aprueba un ajuste de conteo y la actualización se dispara de inmediato) cierra la brecha, pero multiplica las llamadas a la API y te topas de frente con los límites de frecuencia y los costos de infraestructura. Esa es una decisión de negocio, no un rompecabezas técnico.
El segundo son las sincronizaciones fallidas que nadie nota. Un trabajo por lotes falla, reintenta 3 veces y muere en silencio. En demasiadas instalaciones no hay ninguna alerta ante un fallo —operaciones descubre a la mañana siguiente que las actualizaciones de inventario dejaron de fluir hace 6 horas. He visto un almacén donde un lote de ajustes de conteo cíclico se registró bien en el WMS pero el trabajo de sincronización hacia arriba se atascó, y los canales vendieron contra números con 2 días de antigüedad durante 48 horas.
El tercero es el retraso humano. La mercancía está en el andén, pero recepción aún no la ha confirmado en el sistema. Una diferencia de conteo está sentada en la cola de un supervisor esperando aprobación. La latencia del sistema se mide en minutos; la latencia humana se mide en horas o días. La mitad de las quejas de "precisión de sincronización" que he investigado resultaron ser problemas de proceso disfrazados de problemas de sistemas.
Un pedido sobrevendido cuesta más que la cancelación
Por eso trato el retraso como un problema de dinero, no como un ticket de TI. La sobreventa desencadena una cadena, y cada eslabón cuesta.
Primero viene la cancelación. Las cancelaciones iniciadas por el vendedor son una de las señales más feas que puedes enviarle a un marketplace. La política de Amazon mantiene las cancelaciones previas al cumplimiento iniciadas por el vendedor por debajo del 2.5% en una ventana de 7 días, y la tasa de defectos de pedido por debajo del 1% en una ventana de 60 días —cruza esas líneas y te arriesgas a restricciones en tus privilegios de venta. Unas pocas docenas de pedidos sobrevendidos en una noche pico pueden disparar la tasa de cancelación por sí solos, y la salud de la cuenta no se recupera de la noche a la mañana.
Luego viene la carga del servicio al cliente: reembolsos, disculpas, reseñas negativas. El costo laboral de atender un pedido sobrevendido suele superar el margen que ese pedido habría generado. Y el costo más silencioso es el de la solución de emergencia —algunos vendedores se apresuran a conseguir el artículo en otro lado y lo envían tarde con el doble de costo de flete, esencialmente pagando de más para ganarse una mala reseña.
No puedes eliminar el retraso, pero puedes reducirlo y asegurarte contra él
Mi veredicto por adelantado: el retraso de sincronización entre el OMS y el WMS nunca puede ser cero. 2 sistemas, saltos de red, límites de frecuencia de la API —siempre habrá segundos o minutos de desfase. El objetivo es reducir el retraso a algo que el negocio pueda absorber, y luego construir barandillas para el resto.
Reducirlo se resume a 3 decisiones de configuración. Primero, haz que los eventos críticos sean en tiempo real: un putaway completado y un ajuste de conteo aprobado deberían empujar al OMS de inmediato. Los pedidos que bajan pueden seguir en lotes; el inventario que sube debería basarse en eventos donde el presupuesto lo permita. Segundo, sincroniza el campo correcto. El WMS debería enviar el disponible para prometer —existencias menos asignado menos retenciones de calidad— no el bruto disponible. He auditado integraciones que pasaban cantidades brutas disponibles y dejaban que el OMS las tratara como vendibles. Eso es una sobredeclaración incorporada. Tercero, mantén limpio el mapeo de múltiples almacenes. Cuando un SKU está en 3 edificios, la consolidación del OMS debe excluir el inventario en tránsito y el congelado, o el número "disponible" es ficción.
El seguro tiene 2 partes. Una: retén un colchón de seguridad en los SKU calientes. Si la cantidad disponible real es 500, deja que el OMS liste 460 y guarda 40 como amortiguador contra la ventana de retraso. Estás cambiando un poco de velocidad de venta por protección —dimensiona el colchón aproximadamente a la peor tasa histórica de ventas por hora del SKU multiplicada por tu intervalo de sincronización, para que cubra al menos un ciclo completo de retraso. Dos: ejecuta una conciliación diaria con alertas de variación. 1 vez al día, durante la calma nocturna, compara instantáneas completas de inventario de ambos sistemas y alerta cuando la variación cruce un umbral. La conciliación no es teatro contable —es como te enteras de un trabajo de sincronización muerto a las 6 a.m. en lugar de enterarte por clientes furiosos al mediodía.
Cuando estalle a medianoche, revisa estas 3 cosas
¿Pedidos sobrevendidos en la cola? No empieces el juego de culpas. Trabaja esta secuencia y normalmente tendrás la causa raíz en media hora.
Revisa primero el registro de transacciones del WMS. Busca en ese SKU alrededor de la ventana del incidente grandes picks, ajustes de conteo o registros de recepción. Un número sorprendente de "sobreventas misteriosas" resultan ser un ajuste de conteo cíclico registrado en la dirección equivocada, o una devolución recibida 2 veces.
Luego revisa el registro del trabajo de sincronización. Mira la marca de tiempo de la última instantánea de inventario que el OMS tiene de ese SKU. Si la instantánea tiene 3 horas de antigüedad mientras los pedidos siguieron fluyendo hace 1 hora, el retraso es tu culpable. Presta especial atención a los reintentos fallidos —¿fue un timeout, un límite de frecuencia o una discrepancia de formato de datos?
Finalmente, revisa la lógica de asignación del OMS. Confirma que la cantidad disponible usada en el momento de la asignación incluía el colchón de seguridad, y que los pedidos ya asignados pero aún no liberados no se contaron 2 veces. Los errores de asignación y los retrasos de sincronización adoran aparecer juntos, y revisar solo un lado no atrapará la combinación.
Una vez que lo encuentres, escribe el incidente en tus reglas de conciliación —la próxima vez, la alerta debería dispararse antes de que lo haga el servicio al cliente.
La primera tarea de mañana: averigua si la sincronización de inventario de tu OMS funciona por programación o empuja en tiempo real, y anota el intervalo. Ese número es tu tiempo de reacción ante la sobreventa.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
