Seamos francos: nueve de cada diez proyectos de AS/RS no fracasan por las grúas transelevadoras ni por las tolerancias del racking — fracasan por la capa intermedia: el WCS. El equipo está comprado, el WMS ya existe, pero los dos no hablan el mismo idioma, así que hace falta un traductor en el medio. Y si ese traductor es malo, cuanto más rápido corre el AS/RS, más rápido se propaga el caos. Hay dos caras del asunto. Una es la integración técnica: que los mensajes fluyan. La otra es quién manda cuando algo sale mal — y esa es la cara que de verdad te mata.

Mi conclusión por adelantado: el WMS es el cerebro, el WCS es el cerebelo, el AS/RS son las manos y los pies. La integración no consiste en «conectar» — consiste en que las tres capas estén de acuerdo en lo que significan «la verdad del inventario» y «el estado de la tarea». Si no lo están, un flujo de mensajes impecable es solo una bomba con temporizador.

Cómo se «hablan» realmente el AS/RS y el WMS: la división en tres capas

Primero, dejemos claro el reparto de funciones:

Capa Responsabilidad Entrada Salida Modo de fallo clásico
WMS (cerebro) Tareas de negocio: qué pedido se piquea primero, qué reposición corre primero, cuándo se liberan las oleadas Pedidos, estrategias de oleadas Órdenes de tarea: ID de tarea, ID de palé, estación de origen/destino, prioridad Las tareas salen, pero del lado del equipo no pasa nada
WCS (cerebelo) Acciones del equipo: traducir las tareas de negocio en instrucciones para las grúas Órdenes de tarea del WMS Comandos de movimiento concretos: pasillo, estación, ID de palé Se cae en silencio, las tareas se amontonan
AS/RS (manos) Ejecución y confirmación Comandos de movimiento del WCS Resultados: éxito, fallo, código de motivo del fallo El pickeo falla y nadie sabe leer el motivo

El viaje de ida y vuelta: el WMS emite una tarea — ID de tarea, ID de palé (o LPN), estaciones de origen y destino, prioridad. El WCS la encola y la asigna al equipo. Cuando el equipo termina, el WCS informa de vuelta: éxito, fallo, código de motivo. Tres detalles causan la mayoría de los problemas: primero, ante un timeout, exactamente un lado es el dueño del reintento — no los dos, no ninguno. Segundo, el mismo ID de tarea debe ser idempotente — si la red hipoquea y el mensaje sale dos veces, la grúa no debe ejecutarlo dos veces. Tercero, el inventario contable del WMS y el inventario físico del WCS deben usar las mismas definiciones — un palé que el WMS llama «en stock» debe ser realmente localizable por el WCS. Estos tres puntos van por escrito antes de empezar las pruebas de integración.

Hay una mina enterrada en la fase de selección: ¿quién es dueño de la verdad del inventario? El WMS dice «yo soy los libros, mandan los libros». El WCS dice «yo tengo la mercancía física, manda la mercancía». La pelea más común es por el estado «en tránsito» — un palé ya extraído del rack y viajando por la cinta. El WCS lo considera «fuera del almacenamiento»; el WMS lo sigue considerando «en stock y asignable». Entonces llega un pedido urgente, el WMS asigna ese palé a otra tarea, la grúa va a la estación y coge aire. Si esta definición no se cierra antes del go-live, discutiréis sobre ella todos los días. Mi postura es simple: gana la realidad física. El «en stock y asignable» del WMS debe excluir la cantidad en tránsito del WCS. Escrito en el contrato de interfaz y se acabó la discusión.

He visto demasiados proyectos donde las pruebas de integración solo cubren el camino feliz: tarea emitida, equipo ejecuta, confirmación OK, todos aplauden. Y entonces la primera semana en producción empieza a dar lecciones.

Los tres desastres clásicos que he visto demasiadas veces

Desastre uno: el WCS se cae y el WMS sigue emitiendo tareas. Durante la integración previa al pico de temporada en una instalación, el servidor del WCS se reinició en plena noche durante unos diez minutos. El WMS no se enteró y siguió emitiendo cientos de tareas. Cuando el WCS volvió, el backlog inundó el equipo de golpe y la secuencia quedó destrozada — pedidos urgentes enterrados detrás de reposiciones rutinarias. Llevó todo un turno de día desenredar la cola de tareas. La postmortem encontró la causa raíz: el intervalo de heartbeat estaba configurado tan largo que un reinicio completo pasaba sin ser detectado.

Desastre dos: definiciones de conciliación del inventario en guerra. Los libros del WMS mostraban un palé en la Zona A del AS/RS; el WCS mostraba que había sido bajado de forma anormal al área manual una semana antes, y el mensaje de retorno se perdió en una fluctuación de red. Así que el sistema decía «en stock» y el equipo decía «nop», y la tarea de pickeo esperaba en la estación a por nada. Peor aún: esta brecha entre libros y físico no se persigue con conteos cíclicos manuales — el throughput diario de palés de un AS/RS llevaría un mes de trabajo manual contar. Acabaron conciliando palé a palé, instantáneas físicas del WCS contra libros del WMS, hasta que apareció cada palé extraviado.

Desastre tres: confirmaciones de excepción que nadie atiende. Una grúa informa «fallo de pickeo». El WCS lo convierte en un código de error genérico y se lo lanza al WMS. El programa de interfaz del WMS no reconoce el código y lo descarta. La tarea no es ni éxito ni fallo — simplemente queda colgada. El operario mira la pantalla esperando una mercancía que nunca llega, llama a IT, e IT dice que el sistema muestra «emitida». Tres partes mirándose entre sí. La causa raíz casi daba risa: la tabla de códigos de error la había definido el integrador de pasada, y el lado del WMS nunca la mapeó.

Una opinión contraria a lo convencional: cuanto más automatizado estás, más dependes de tu plan de degradación. La gente cree que un AS/RS es dormir tranquilo. Es lo contrario — el mayor riesgo de un AS/RS no es el equipo roto, es el sistema creyendo que el equipo no está roto. Una grúa rota se ve; un mensaje perdido no.

Un detalle más que la mayoría pasa por alto: la prioridad de las tareas. El «el pedido urgente primero» del WMS se convierte en simple salto de cola cuando se traduce en la capa WCS — las tareas en curso se interrumpen sin parar, las tasas de desplazamiento en vacío de las grúas se disparan. El pedido urgente sale más rápido, el throughput total empeora. La estrategia de prioridad tiene que diseñarse en las dos capas a la vez: el WMS fija la prioridad de negocio, el WCS fija el loteo de ejecución, cada uno en lo suyo. Todo proyecto en el que el WMS comanda directamente el equipo acaba en un desastre.

Para que el AS/RS y el WMS sigan hablando: cuatro reglas de hierro

Primera, el contrato de interfaz antes que todo. Antes de las pruebas de integración, alinear la máquina de estados de la tarea: emitida, ejecutando, exitosa, fallida, en retención por excepción — cinco estados, ni uno menos. Quién puede hacer cada transición, cuánto timeout cuenta como fallo — por escrito. El dueño del reintento pertenece a exactamente un lado. Las claves de idempotencia deben fluir por toda la cadena. Las tablas de códigos de error deben mapearse línea por línea en los dos lados — un código tipo «error general» no puede existir.

Segunda, el plan de degradación. ¿Qué pasa cuando el WCS se cae? El WMS debe poder pausar la emisión de inmediato, y las tareas en curso deben poder exportarse como lista para manejo manual. La degradación no es «esperar a que IT lo arregle» — es un procedimiento de conmutación que ya has ensayado de verdad. Un plan nunca ensayado no es un plan. Mis criterios de aceptación para clientes siempre incluyen una línea: desconectar el WCS diez minutos; tras la recuperación, tareas e inventario deben conciliar. Si no lo hacen, se retiene el pago final.

Tercera, la conciliación. Cada turno, el WMS y el WCS concilian: inventario contable contra ubicaciones físicas. Las diferencias nunca se corrigen editando los libros a mano — pasan por el proceso de excepción: encontrar dónde fue el palé, encontrar dónde se perdió el mensaje, y entonces ajustar. Los libros pueden estar mal, pero mal con rastro. Editar a mano se siente bien un momento; todo el almacén llora a la hora de conciliar.

Cuarta, el checklist de integración. Pruebas de estrés de mensajes, simulacros de caída de red, cobertura total de pruebas de cada código de error — nada opcional. Especialmente el simulacro de caída: desenchufar el cable de red entre el WCS y el WMS diez minutos, y comprobar si tareas e inventario siguen conciliando tras la recuperación. Si lo hacen, el proyecto está genuinamente conectado. Tantos proyectos mueren en «todo estaba bien durante la integración» — claro que la red estaba bien durante la integración; nunca has visto lo que es «no estar bien».

Para los que estáis eligiendo proveedor ahora mismo, tres preguntas al integrador antes de firmar: una, cuando el WCS se cae, ¿puede el WMS pausar la emisión automáticamente, y puede exportarse la lista de tareas en curso con un clic? Dos, ¿la tabla de códigos de error está mapeada línea por línea en el WMS, o hay códigos vagos que nadie es dueño? Tres, ¿la conciliación contable-física por turno corre automáticamente o depende de que alguien se acuerde? Si no pueden responder una de las tres, la implementación costará extra — no quizás, seguro.

La próxima vez que un integrador os diga «las interfaces están todas conectadas», hacedle una pregunta: el WCS pierde red diez minutos — ¿vuestro inventario sigue conciliando?

Por Lao Mi, veterano de la cadena de suministro (20 años)

Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.