En otoño de 2024 asistí a una demo de WMS para un almacén de comercio electrónico en Mira Loma, California. El comercial habló durante una hora entera: optimización inteligente de olas, gemelos digitales, de todo. El dueño asentía. El responsable de TI llenó tres páginas de notas.
Levanté la mano. «Pausa. Hay un pedido urgente de una cuenta clave que tiene que salir hoy. Añádalo a la ola que acaba de liberar. En vivo, por favor.»
El especialista de la demo se quedó congelado tres segundos, empezó a rebuscar en los menús, hizo clic por ahí durante dos minutos y al final sonrió: «Claro que soportamos pedidos urgentes, solo que no está configurado en el entorno de la demo de hoy.»
Cinco segundos de silencio. El dueño cerró su libreta.
He visto esa escena repetirse más veces de las que puedo contar: deslumbrante en las diapositivas, inútil en cuanto aparece un escenario real de almacén. Después de pasar por una docena de selecciones de WMS a lo largo de los años, me quedé con una lección dura: la lista de funciones es el juego del proveedor, y todas las casillas ya vienen marcadas. Entrégueles sus escenarios reales y oblíguelos a actuar en vivo, y ese será su juego. Nueve de cada diez proveedores empiezan a sudar en el tercer escenario.
Mi método habitual es este: una semana antes de la demo, envío al proveedor cinco escenarios escritos desde nuestra operación real — datos enmascarados, lógica real. El día de la demo no se permiten presentaciones; todo ocurre en vivo dentro del sistema. No pregunto «¿tienen esta función?». Cuento los clics del ratón, observo cuántas pantallas saltan, compruebo si las excepciones realmente disparan alertas. Un WMS se toca miles de veces al día. Tres clics extra por tarea son cientos de miles de movimientos desperdiciados al año.
«Meta un pedido urgente en la ola en vivo. Ahora mismo.»
El escenario es simple: la ola está liberada, los operarios ya caminan por los pasillos con sus pistolas RF, y atención al cliente llama: un pedido de una cuenta clave tiene que salir hoy, encájelo en la ola actual.
Tres cosas a observar: si se puede inyectar un pedido en una ola liberada; si la nueva tarea llega al terminal del operario en tiempo real o espera a la siguiente ola; si la ola a medio recoger se desordena.
La respuesta clásica del fracaso: «Soportamos pedidos urgentes, pero habría que cerrar la ola actual y reconstruirla.» Descalificación instantánea. En un almacén real no se puede simplemente cerrar una ola: en temporada alta, con miles de pedidos al día, cerrar una ola detiene toda la línea de picking durante media hora. Hay un fracaso más sutil: inyecta bien el pedido, pero no aparece nada en la pistola del operario hasta que un supervisor avisa a todo el mundo uno por uno por radio. Eso le dice que su «tiempo real» solo existe en la presentación.
La devolución en pallet mixto es donde los sistemas van a morir
Todo WMS se ve precioso en expedición. Las devoluciones son el detector de mentiras. El escenario: llega un pallet mixto de devoluciones — algunas unidades revendibles, otras con el embalaje destrozado rumbo a destrucción, y dos cajas que se enviaron por error y volvieron con la devolución.
Observe: si al recibir la devolución se genera automáticamente una tarea de QC en un solo paso; si una decisión de QC de «destruir» dispara el flujo de destrucción y el ajuste de inventario sin volver a teclear; si las cajas mal enviadas se enlazan con el pedido de salida original y generan un envío de reemplazo.
Muchos sistemas tienen un módulo de devoluciones que se reduce a «se puede registrar una devolución». El QC corre en papel, las destrucciones se cuentan en una hoja de cálculo. En 2023 vi a un 3PL en Fontana dejar que su zona de devoluciones se acumulara durante dos semanas enteras de pico: cuando por fin la vaciaron, la mayor parte fue directo a destrucción. El dueño miraba cómo pallet tras pallet se daba de baja, con la cara verde. Si la demo necesita tres pantallas y un campo de notas de texto libre marcado «destruir esta unidad» para procesar una devolución, eso es un suspenso: su empleado de devoluciones nunca rellenará ese campo de notas. Estará en blanco para siempre.
Movimientos de slotting y traslados entre almacenes: desenmascarando el falso multialmacén
Antes de la temporada alta, los SKU calientes bajan de los niveles superiores a la zona dorada de picking. Escenario uno: generar tareas de movimiento para doscientas ubicaciones en bloque. ¿Puede el sistema hacerlo de una vez, el stock en tránsito se muestra como en tránsito o simplemente se congela, y las tareas de movimiento se autoasignan por zona de trabajo del operario?
El escenario dos es el letal: el almacén A está corto, el almacén B tiene stock — traslade doscientas cajas de B a A. Muchos sistemas que presumen de soporte multialmacén lo resuelven como un pedido de salida en B más un pedido de entrada en A, con el inventario desvaneciéndose en el aire durante uno o dos días en medio. El inventario contable nunca cuadra con el físico. Llevé un proyecto que murió exactamente aquí: diferencias de fin de mes tan grandes que finanzas se negó a firmar, y el equipo pasó tres días haciendo conteos cíclicos.
Una arquitectura genuinamente multialmacén lo mueve como un único flujo documental, con el inventario en tránsito visible de punta a punta. Durante la demo, solo cuente: cuántas pantallas, cuántos números de documento, y si se enlazan entre sí. Más de dos documentos sin enlazar significa que está mirando un falso multialmacén.
Póngale el teclado al villano
El último escenario es mi favorito. Cree una cuenta con permisos solo de operario, e intente registrar un ajuste de inventario, abrir los informes de costes y eliminar un pedido de salida confirmado.
Tres cosas a comprobar: si los permisos bajan hasta nivel de botón y campo; si una acción no autorizada se bloquea con un error o se deja pasar en silencio; si hay un registro de auditoría que anote quién intentó hacer qué y cuándo.
La evasiva clásica es «los permisos son totalmente configurables». Configurable y existente son dos cosas distintas: hágalo configurar uno en vivo, ahora mismo. Si no puede, no existe. Lo peor que vi tenía exactamente dos roles: administrador y operario. El operario podía eliminar pedidos, ajustar inventario y leer todos los informes de costes. El comercial se encogió de hombros: «Las empresas pequeñas no lo necesitan tan granular.» Usted es una empresa pequeña hoy. ¿Y dentro de tres años, con cuatro almacenes? Migrar de sistema en ese punto cuesta lo suficiente para hacerlo llorar.
Cinco escenarios después, habrá eliminado del setenta al ochenta por ciento del campo. Negocie precio, plazos y servicios con los que queden: la base ya está verificada, así que no puede salirle mal.
Pero, honestamente, hay algo que importa más que qué proveedor elija, y se pasa por alto constantemente: ¿quién escribió estos cinco escenarios en primer lugar?
Lo he visto demasiadas veces: TI lidera la selección, la prueba cubre API, arquitectura y single sign-on, y ni un solo dolor operativo real entra en ella. Llega el día del go-live, TI firma, y los operarios maldicen en los pasillos: no se puede inyectar un pedido urgente, las devoluciones corren en papel, los traslados corren en hojas de cálculo. Ninguna de las preguntas que hizo TI importa en la planta.
Así que la pregunta que le dejaría es esta: la próxima vez que su empresa seleccione un WMS, ¿quién escribe el examen? Porque quien escribe las preguntas decide qué sistema acaba comprando.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
