Conclusión primero: cuando los operadores ignoran las recomendaciones de putaway del WMS, nueve de cada diez veces no es un problema de disciplina, es un problema de lógica. Lo digo en cada puesta en marcha. La mayoría de los clientes no me creen. La mayoría termina comprobando que estaban equivocados.
He visto esta trampa tres veces — bueno, más bien unas veinte veces en más de 30 implementaciones. El patrón siempre es el mismo: el sistema recomienda la ubicación A, el operador pone la tarima en la ubicación B, y el reporte de desviaciones muestra más de 40% de incumplimiento. El primer instinto del gerente de proyecto es "más capacitación, aplicación más estricta". El mío es: dejen de culpar a la gente y desarmen la lógica de recomendación.
Tres razones. Cada una dolorosamente real.
Razón 1: El hueco recomendado es físicamente inalcanzable
En 2021 me llamaron a un 3PL en el sur de China que manejaba pequeños electrodomésticos: unos 18,000 SKUs, más de 600 putaways de tarimas al día. Sus reglas de putaway se veían geniales en papel: clasificación ABC por velocidad más emparejamiento por cubo más lógica de lo más cercano disponible. Dos semanas después del go-live, la tasa de desviación de recomendaciones era 52%.
Caminé el piso con un operador una mañana y encontré al culpable en el maestro de ubicaciones. De más de 3,000 posiciones de tarima, cada atributo de altura era el mismo valor por defecto: 1.6 metros, llenado en masa durante la implementación porque nadie midió. Una fila de estantería había sido adaptada con vigas más bajas: altura libre real de 1.35 metros. Una tarima de 1.5 metros físicamente no cabe. El sistema seguía recomendando esos huecos de todos modos. Los operadores llegaban, veían que no cabía, y ponían la tarima donde cupiera.
Luego estaba el problema de la zona de temperatura. Las reglas decían "los alimentos prefieren zonas ambiente-frescas", pero el maestro de ubicaciones no tenía ningún atributo de temperatura. ¿Cuáles pasillos eran las zonas frescas? No estaba marcado en ningún lado. Los operadores colocaban el producto de memoria.
El hilo común: la lógica de recomendación depende de datos maestros que están mal o que nunca se mantuvieron. Buenas matemáticas sobre basura de entrada producen basura de salida.
Razón 2: La recomendación se ve mal, así que el piso deja de confiar en ella de un vistazo
En 2019, un almacén de comercio electrónico transfronterizo en Shenzhen: el clásico negocio de "el SKU héroe de hoy es el muerto de mañana". El consultor de implementación (no yo, yo llegué a arreglarlo) configuró la clasificación ABC con base en el volumen de salida de los tres meses antes del go-live. El problema: el go-live fue en septiembre; los datos eran de mayo a julio. La mezcla de SKUs de la temporada alta del Q4 no se parecía en nada al verano.
El resultado: los verdaderos más vendidos quedaron clasificados como artículos C y recomendados a los pasillos más lejanos; el muerto usaba la insignia de artículo A y se sentaba en los huecos dorados más cercanos al área de empaque. Los operadores lo descubrieron en tres días: sigue la recomendación y caminas el doble de distancia a la hora de pickear. Así que ignoraron el sistema colectivamente y ubicaron por experiencia.
La confianza tarda tres meses en construirse y tres días en destruirse. Una vez que el piso decide "la recomendación es más tonta que mi instinto", esa lógica está muerta. Puedes arreglar las reglas después, pero nadie les dará una segunda oportunidad.
La otra versión común: datos de cubo y peso faltantes. El maestro de artículos no tiene dimensiones, así que el "emparejamiento por cubo" degenera en asignación aleatoria. Tarimas sobredimensionadas se recomiendan a huecos pequeños, cartones pequeños a posiciones de tarima completa. De un vistazo el operador sabe que es un disparate.
Razón 3: No hay salida para las excepciones, así que rodear el sistema es la única forma de sobrevivir
Esta es la más insidiosa. El sistema solo maneja el flujo normal: tarima intacta, etiqueta legible, hueco vacío. Pero cada día trae excepciones: una tarima rota que necesita reestibarse, una tarima de SKUs mixtos que no encaja en las reglas de un solo SKU, un pedido urgente que necesita estadificarse cerca de empaque, cartones de entrada con empaque dañado que primero deben ir a QC.
Si el sistema no ofrece salida para estas — ninguna función de "asignar ubicación manualmente más código de razón obligatorio" — el operador tiene dos opciones: dejar la mercancía ahí sentada esperando a que el sistema "lo resuelva", o ponerla en un lugar sensato y seguir adelante. El piso siempre elige la segunda. Las desviaciones se acumulan hasta que las ubicaciones de libros y las ubicaciones físicas divergen por completo.
En 2023, un almacén de alimentos en el este de China hizo obligatorias las recomendaciones de putaway: la tarea no podía cerrarse sin seguir la recomendación. Suena estricto, ¿verdad? Los operadores inventaron un atajo: confirmar por escaneo en la ubicación recomendada, luego mover físicamente la tarima a donde querían, sin dejar rastro en el sistema. Los libros se veían perfectos. El piso era un caos. La varianza de conteo cíclico llegó a 8%. He visto esta trampa tres veces, y cada vez la configuración "obligatoria" era la culpable.
Lista de verificación para la noche del go-live: no enciendas las recomendaciones hasta que estas cuatro pasen
- Verifica físicamente los datos maestros de ubicaciones por muestreo. Muestrea aleatoriamente 30 ubicaciones: mide altura y profundidad libres con cinta, verifica atributos de capacidad de peso y zona de temperatura. Un error significa una reauditoría completa. Nunca confíes en valores por defecto importados en masa.
- Cobertura de cubo y peso de artículos. Largo, ancho, alto, peso: si la cobertura está por debajo de 90%, olvídate de recomendaciones inteligentes y ubica por categoría de producto de la forma honesta.
- Recalcula el ABC con los tres meses de datos más recientes, y escríbelo en el SOP: recalcular mensualmente, cada dos semanas durante temporada alta. La ventana de datos debe coincidir con el ritmo del negocio.
- Salida para excepciones más un reporte de desviaciones. El sistema debe soportar "ubicación manual más código de razón", y para el día dos después del go-live, el gerente de proyecto debe poder sacar un reporte de varianza de "ubicación recomendada vs. ubicación real". Tres códigos de razón bastan: ubicación no disponible, recomendación irrazonable, caso de excepción.
Dos puntos de falla más que repito en cada go-live: primero, el ABC calculado una vez en el go-live y nunca tocado de nuevo en tres años: eso es lo mismo que no tener ninguno. Segundo, las pruebas solo cubren el flujo normal; nadie prueba "qué pasa si el hueco recomendado está ocupado" o "qué pasa si la tarima excede la altura". El piso te enseñará esa lección el día uno.
Aquí están las cuentas. Un almacén que hace 500 tareas de putaway al día: cada rodeo le cuesta al operador más o menos un minuto extra buscando un hueco y otro minuto corrigiendo la ubicación en el sistema. Eso es unas 16 horas al día: dos personas de tiempo completo sin hacer más que compensar al sistema. Y eso excluye el recorrido extra de picking por inventario mal ubicado y las varianzas de conteo cíclico. Arreglar la lógica de recomendación suele costar una o dos semanas de limpieza de datos maestros. Las cuentas no están ni cerca.
Y una opinión contraintuitiva para cerrar: 100% de cumplimiento de recomendaciones no es necesariamente una buena noticia. Una tasa de desviación saludable está alrededor de 5–15%, con un código de razón en cada desviación. Por debajo de 5%, empieza a preocuparte de que el piso esté confirmando por escaneo y luego haciendo lo que quiera. Por encima de 30%, la lógica ya está muerta: deja de capacitar gente y arregla la lógica.
La reunión de turno de mañana por la mañana: dedica 15 minutos a preguntarle a tu líder de putaway una pregunta: ¿cuántas recomendaciones fallaron ayer, y qué pasó en cada caso? Pregunta una semana seguida y sabrás exactamente con cuál de las tres razones estás lidiando. Diagnostica primero, luego actúa. No empieces con "más capacitación".
Por Lin Xiao, consultora de implementación de WMS
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
