Hay un extraño ritual que he visto repetirse en proyectos de almacenes automatizados en los últimos años. El proveedor del WMS y el proveedor del WES se sientan alrededor de la misma mesa de reuniones. Hablan de interfaces, hablan de hardware, todo es cordial... hasta que alguien dice «asignación de tareas». Entonces ambos lados empiezan a mirarse, con el pensamiento legible en sus ojos: ese es tu trabajo.
Después de la reunión, el cliente siempre me aparta. «Lao Mi, ¿quién es realmente el responsable de esto?» Normalmente respondo con una pregunta propia: «¿Está en su contrato?» Nueve de cada diez veces, la respuesta es no. Y ese silencio es exactamente el problema. Liberación de olas, picks urgentes, gestión de excepciones: tres tareas que nadie quiere reclamar y tres frentes donde los proyectos de automatización se convierten en discusiones.
Liberación de olas: el WMS escribe la melodía, el WES controla el tempo
La versión de manual es limpia. El WMS agrupa los pedidos en olas según prioridad y horas límite de los transportistas, las libera una ola a la vez y el WES las ejecuta. Un lado define la estrategia, el otro hace el trabajo.
Luego llegaron los AMR y los shuttles, y la historia se complicó. El proveedor del WES le dirá que puede ver el estado en tiempo real de cada robot y la congestión de cada pasillo, así que puede construir y liberar olas de forma dinámica, mucho más eficiente que las liberaciones rígidas y temporizadas del WMS. La respuesta del proveedor del WMS: las olas son estrategia de pedidos, son compromisos de cumplimiento, y ningún proveedor de equipos decide eso.
Vi esta misma pelea en 2023 en un centro de fulfillment de comercio electrónico en el Inland Empire del sur de California: una nave de más de 200,000 pies cuadrados, con cuarenta o cincuenta AMR en el suelo. El WMS liberaba una ola cada 20 minutos según los cortes de los transportistas. El WES no daba abasto: los robots seguían masticando la ola anterior cuando llegaba la siguiente. Los operarios esperaban en los pasillos a que llegaran tareas mientras los robots corrían vacíos. El equipo del WMS decía que su lógica de olas era sólida; el equipo del WES decía que la cadencia de liberación era imposible. El cliente, entre los dos, escuchaba argumentos razonables por ambos lados.
Mi veredicto: la estrategia de olas pertenece al WMS — las reglas de agrupación, la lógica de prioridad, eso es gestión de pedidos y fulfillment. Pero el ritmo de liberación tiene que compartirse con el WES, porque solo la capa de ejecución sabe lo que los equipos pueden realmente tragar. En la práctica no hay un único dueño aquí, solo copropiedad, y tiene que quedar por escrito en ambos contratos: el WMS es dueño de la configuración de la estrategia de olas, el WES es dueño del ritmo de liberación, y el contrato de la interfaz dice que el WMS publica las olas mientras el WES publica su capacidad en tiempo real para absorber trabajo. Qué campos, qué lógica — en papel.
Picks urgentes: la papa caliente del almacén
Nadie pelea más que por los picks urgentes: llama el servicio al cliente, una cuenta clave tiene un pedido de emergencia, tiene que salir en dos horas. El WMS lo marca como máxima prioridad y lo envía al WES. El vendedor del WES prometió priorización dinámica en la demo. En el go-live, insertar un pedido en un plan de tareas ya secuenciado significa recalcular rutas, y la eficiencia de todo el piso se resiente. El WMS dice: «Yo marqué la prioridad, el resto es tuyo». El WES dice: «Tú la marcaste, pero yo no puedo ejecutarla».
En 2024, en un sitio 3PL en Ohio, la temporada pico trajo decenas de picks urgentes al día, casi uno por hora en los peores momentos. Al investigar, el WES no tenía ningún carril dedicado para tareas aceleradas. Cada pick urgente pasaba por la cola normal de resecuenciación, el solucionador se hacía más y más lento, y los pedidos normales se arrastraban con él. El cliente, furioso: «Eso no es lo que nos vendieron».
Mi solución se resume en tres condiciones no negociables: la autoridad sobre los picks urgentes está en el WMS — quién puede acelerar y cuántas veces al día, porque tiene que haber una cuota, y lo que supere la cuota pasa por aprobación manual; acelerar sin cuota es un desastre garantizado, el WES quedará ahogado por interrupciones ilimitadas, y eso es física, no un bug de software. La ejecución de los picks urgentes está en el WES — reserve capacidad o construya un carril dedicado para que las tareas aceleradas no rompan la secuencia global. Y el SLA va en el contrato — desde que se emite un pick urgente hasta que empieza su ejecución, no más de un número acordado de minutos. El número es negociable. Tener un número no lo es.
Gestión de excepciones: donde los sistemas inteligentes se hacen los tontos
Tercero, las excepciones. Un robot se atasca, una etiqueta no escanea, falla un control de peso: la tarea muere a mitad de camino. ¿Quién la intercepta? ¿Quién decide: reintentar o pasársela a un humano? La línea del proveedor del WMS: «Somos el sistema de arriba; el WES debería atender primero las excepciones y escalar lo que no pueda». La línea del proveedor del WES: «Nosotros movemos los equipos; las excepciones de negocio, como algo mal en el pedido, eso lo decide el WMS».
Ambos suenan razonables. En la práctica, las excepciones que ningún lado reclama simplemente desaparecen dentro del sistema. En un proyecto, durante los primeros tres meses tras el go-live, el WES creía haber reportado excepciones que el WMS creía no haber recibido nunca. Encontrar la causa raíz tomó más de una semana, y era casi vergonzoso: los códigos de excepción que enviaba el WES no existían en el diccionario del WMS, así que la interfaz los descartaba en silencio. Una caja se quedó en un transportador durante dos días. Nadie lo sabía.
Así que las excepciones hay que dividirlas en dos capas. Las excepciones de la capa de equipos — robots atascados, conexiones perdidas, escaneos fallidos — pertenecen al WES, que debe intentar autorrepararse primero: reintentar, reenrutar, y solo entonces escalar. Las excepciones de la capa de negocio — pedidos cancelados, descuadres de inventario — pertenecen al WMS. Y entre las dos capas debe haber una única tabla de correspondencia de códigos de excepción, firmada por ambos proveedores y probada línea por línea durante la integración. La mayoría de los proyectos no tienen esta tabla. Prueban que la interfaz conecta y cantan victoria. Recuerde: una interfaz conectada no es lo mismo que un flujo de excepciones que funciona.
Las verdaderas causas raíz, y cómo eliminarlas por escrito
A estas alturas las causas raíz probablemente están claras. Pero déjeme nombrarlas, porque nombrarlas es lo que las hace contractuales.
Empecemos por el hecho de que nadie ha definido nunca qué es realmente un WES. Hace diez años el WMS lo corría todo y los equipos eran tontos. Luego los AMR y los shuttles desarrollaron cerebro, y nació el WES para gestionarlos. Pero la industria nunca estandarizó el límite del WES: el WES de un proveedor es prácticamente un pequeño WMS, el de otro es apenas un planificador de dispositivos. En la selección cree que está comprando lo mismo a cada licitador. No es así. Las demos se ven iguales; los contratos describen dos animales distintos.
Luego está el problema más profundo: ambos lados están «optimizando», pero optimizan cosas distintas. El WMS optimiza el fulfillment — tasa de entregas a tiempo, cumplimiento de cortes. El WES optimiza la eficiencia de los equipos — utilización de robots, rendimiento de pasillos. El fulfillment quiere velocidad; los equipos quieren suavidad. Están en tensión por naturaleza, y las olas, los picks urgentes y las excepciones son exactamente donde esos dos objetivos chocan. Así que los reproches no son un problema de actitud. Las funciones objetivo genuinamente discrepan.
Y lo más dañino: no está en el contrato. El statement of work del WMS dice «El proveedor es responsable del módulo de asignación de tareas». El statement of work del WES dice la misma frase. Límites superpuestos más redacción vaga equivalen a una invitación permanente a discutir.
Entonces, ¿cómo se escribe en el contrato? La plantilla que doy a los clientes es una tabla simple de tres columnas: ítem, dueño, codueño. Cubre al menos ocho ítems: definición de la estrategia de olas, ritmo de liberación de olas, autoridad y cuotas de picks urgentes, carril de ejecución de picks urgentes, autorreparación de excepciones de equipos, adjudicación de excepciones de negocio, mantenimiento del diccionario de códigos de excepción y propiedad de los campos de la interfaz. Cada ítem tiene exactamente un dueño. «Apoyo» o «asistencia» no cuenta como asignación.
También insisto en algunas cláusulas duras: criterios de aceptación detallados — la tabla de códigos de excepción probada línea por línea con un 100 % de aprobación, los picks urgentes pasando de la emisión al inicio de la ejecución en menos de cinco minutos, donde el número es negociable pero tener uno no lo es. Responsabilidad de mantener el diccionario de excepciones asignada a una persona nombrada, con cualquier código nuevo sincronizado al otro lado en 48 horas. Y una cláusula de desempate que agregué después de quemarme algunas veces y que nunca he quitado: las disputas de límites las decide el cliente en 48 horas, y ningún lado puede parar el trabajo mientras discute.
Volviendo a esa sala de reuniones. La próxima vez que el proveedor del WMS y el proveedor del WES se sienten juntos y empiecen a mirarse por la asignación de tareas, suelo interrumpir: dejen de mirarse, abran el contrato, busquen la página y la línea. Los límites no se resuelven discutiendo en reuniones. Se resuelven escribiendo. Escríbanlos y ambos lados conocen sus trabajos; déjenlos vagos y cada excepción, cada pick urgente se convierte en una discusión nueva. Y el costo de todas esas discusiones cae, siempre, sobre el cliente.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
