El lunes por la mañana después del Black Friday del año pasado, mi teléfono se encendió a las 7 a.m. El director general de un cliente me escribió: "Lao Mi, nuestro equipo de atención al cliente está recibiendo críticas feroces en internet."
Una marca de cuidado de la piel, operando desde un almacén 3PL de 120,000-square-foot en Ontario, California. Durante todo el Black Friday su página principal anunciaba "2-Day Delivery Sitewide." Para el lunes por la mañana, más de a thousand pedidos seguían en "awaiting shipment," los teléfonos estaban desbordados y las redes sociales los llamaban estafadores.
Pasé esa tarde en su oficina desarmando la lógica de promesa de entrega de su OMS. El almacén no era lento: los pickers habían trabajado hasta pasada la medianoche toda la semana. El verdadero problema era que el sistema nunca debió haber hecho esas promesas. Available-to-promise (ATP) y la promesa de fecha de entrega es la función del OMS que la mayoría de los equipos configuran una vez y olvidan. También es la que más te deja en evidencia.
Three traps. Déjame explicarte cada una.
El inventario en los libros no está en el edificio
La primera trampa es la clásica: el cálculo del ATP está mal.
Available-to-promise suena simple: si lo tienes, puedes venderlo. Pero ¿qué significa realmente "tenerlo"? He visto demasiados sistemas que usan una fórmula como: existencias menos lo asignado igual a lo vendible. Suena razonable. Está mal, porque las existencias incluyen en silencio three cosas que no puedes tocar: inventario inbound aún en tránsito, stock reservado de forma suave y stock congelado por control de calidad.
El inventario en tránsito causa el mayor daño. Un cliente de pequeños electrodomésticos contabilizaba las órdenes de compra "already shipped, on the way" como vendibles, con la teoría de que "llegará en three days de todos modos." La semana antes del Black Friday, un envío de 8,000 humidificadores estuvo esperando atracar fuera del Puerto de Los Ángeles durante nine días seguidos. La página siguió vendiendo todo el tiempo: más de 3,000 units, cada una prometida con "3-day delivery." Para cuando el contenedor llegó al muelle, el equipo de CS ya se había disculpado hasta quedarse ronco.
El stock reservado es la segunda mina terrestre. Grandes órdenes de clientes B2B, planes de reposición para Amazon FBA: atan inventario en el sistema pero no se han enviado físicamente. Algunas plataformas OMS registran las reservas solo a nivel de cabecera del pedido, no a nivel de línea, o reservan sin descontar del ATP. El peor caso que he visto: el mismo lote fue reservado una vez por una orden B2B y de nuevo por un plan de reposición de FBA, y el ATP lo descontó zero veces. Un lote de inventario, vendido three veces.
Las retenciones de control de calidad son las más traicioneras. Un lote inbound falla la inspección puntual, todo el lote se congela a la espera de la respuesta del proveedor y queda bloqueado en el WMS: intocable. Pero si el OMS solo lee el número total de existencias, nunca ve el estado de congelado. En aquel almacén de cuidado de la piel en Ontario, 20,000 frascos de sérum fueron bloqueados por control de calidad por un error de etiquetado justo antes del Black Friday. El sistema siguió vendiéndolos como si nada hubiera pasado.
¿Cómo lo compruebas? Mi método de baja tecnología: extrae los números de ATP para twenty SKUs de alta rotación del OMS y haz que el almacén cuente físicamente "qué podemos picking ahora mismo" para esos mismos SKUs. Dondequiera que los two números diverjan, la brecha es una de esas three cosas. Al corregirlo, no intentes abarcarlo todo: cambia la fórmula a existencias menos reservas menos retenciones congeladas, y muestra el stock en tránsito como su propia línea, "expected arrival," desglosada por fecha de llegada. Nada entra en la cantidad vendible hasta que esté físicamente en el edificio. Guié a un almacén de 80,000-square-foot en ese cambio en two weeks. Las quejas por sobreventa cayeron a zero después de eso.
La promesa supone el almacén A. El paquete sale del almacén B.
La trampa two vive en el fulfillment multi-nodo. El cálculo de un solo almacén es fácil: envío hoy más tiempo de tránsito del transportista. Agrega más almacenes y se complica rápido.
Cuando un OMS promete una fecha de entrega, tiene que responder two preguntas: qué almacén lo envía y cuántos días tomará. Muchos sistemas calculan una bonita fecha de entrega para la tienda usando "el almacén más cercano al cliente" y, después de realizado el pedido, el motor de asignación vuelve a seleccionar el nodo según "quién tiene stock al menor costo." La tienda prometió los two días del almacén A; el paquete realmente sale del almacén B y tarda four. El cliente mira la página de seguimiento, ve "shipped from California" mientras vive en Nueva York, y ahí es donde viene la llamada furiosa.
Hay otra más sutil: los cutoffs de los transportistas. El sistema calcula la promesa suponiendo "ships today," pero no nota que ya son las 4 p.m. y que el cutoff diario del almacén era a las 3 p.m. Ese pedido realmente se envía mañana: la promesa nació corta por un día. Durante la temporada alta, los almacenes adelantan los cutoffs, las 3 p.m. se convierten en 2 p.m., nadie actualiza el parámetro en el sistema y cada fecha prometida llega un día tarde durante semanas.
La solución va en la dirección opuesta: haz que la lógica de promesa y la lógica de asignación usen las mismas reglas. Antes de que la tienda muestre una fecha de entrega, ejecuta la pasada de asignación real, descubre qué almacén realmente lo enviará y luego calcula el tránsito del transportista desde ese nodo más la verificación del cutoff. Suena obvio. Apuesto que la mitad de las plataformas OMS del mercado medio ejecutan la promesa y la asignación como two rutas de código separadas que nunca se hablan entre sí. Es la demo que siempre exijo durante la selección del sistema: haz three test orders a diferentes códigos postales y comprueba si la fecha prometida coincide con la asignación real. Si no cuadran, ese proveedor queda fuera.
Llega la temporada alta y cada promesa se derrumba
La trampa three pertenece a la temporada alta. El ATP parece preciso todo el año y luego se desmorona en noviembre. La fórmula no es el problema: la concurrencia sí.
En un día normal, decenas de pedidos por minuto, los descuentos de inventario aguantan. A la medianoche del Black Friday, miles de pedidos por minuto entran en tromba y el ATP sigue vendiendo a partir de una instantánea calculada hace minutos. La instantánea dice 500 units; en realidad se acabaron en three seconds. Todos los que pidieron en los siguientes two minutes aún recibieron la promesa de "in stock, 2-day delivery." El almacén llega a la mañana siguiente, no hay nada que picking, y las únicas opciones son disculparse uno por uno o esperar la reposición mientras los "2 days" se estiran hasta "2 weeks."
Luego está la doble venta de preventa frente a stock actual. Marketing lanza una preventa en livestream de "the batch arriving next week," mientras la página sigue vendiendo el stock actual. Los two canales no comparten un pool de inventario, así que el mismo lote inbound se promete twice. Cuando llega, hay suficiente para la mitad de los compradores. Los "2-day delivery" de la otra mitad se convierten en "we'll notify you."
Las soluciones de temporada alta vienen en three parts. Primero, dales a los SKUs promocionales su propio pool de inventario, físicamente separado del stock de venta diaria: preventa es preventa, stock actual es stock actual, y nunca se prestan entre sí. Segundo, pon bloqueo pesimista en el ATP durante ventanas de alta concurrencia, o como mínimo reduce las actualizaciones de la instantánea a segundos; eso requiere involucrar a ingeniería, operaciones no puede hacerlo solo. Tercero, ejecuta un "promise stress test" antes del pico: reproduce el volumen de pedidos del pico del año pasado contra un entorno de prueba y observa cuándo el ATP empieza a mentir. Saber dónde se rompe con anticipación es mucho más barato que disculparse después.
No te apresures a reemplazar el sistema. Revisa en este orden.
Muchos dueños quieren arrancar el OMS en cuanto esto explota. Mi consejo: diagnostica primero y luego decide, porque nine times out of ten estas trampas son problemas de configuración, no de plataforma.
Revisa en este orden. Primero, haz la conciliación física de twenty-SKU y confirma si la fórmula del ATP descuenta correctamente las reservas y las retenciones congeladas. Segundo, haz pedidos de prueba a diferentes códigos postales y compara la fecha prometida de la tienda con la asignación real y los cutoffs. Tercero, reproduce tu última temporada alta y clasifica los pedidos sobrevendidos: cuántos vinieron de instantáneas de concurrencia obsoletas, cuántos de preventa y stock actual compartiendo un pool. Al final de esos three pasos, conocerás la causa raíz.
Corrige también en orden de prioridad. Corregir la fórmula va primero: sin cambios de código. Unificar las reglas de promesa y asignación va segundo: eso requiere tiempo de ingeniería. El bloqueo de concurrencia y la separación de pools van tercero: prográmalo a month antes de tu próximo pico. En esa secuencia, un almacén que hace three thousand orders a day puede recuperar la precisión de entrega a lo normal en a quarter.
One last question para ti: el número de promesa de entrega en tu sistema: ¿cuándo fue la última vez que alguien recorrió el piso del almacén con el reporte de ATP y lo concilió SKU por SKU? Si no lo recuerdas, la próxima promesa rota probablemente ya está en camino.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
