Verdict first: en las implantaciones de OMS, todo el mundo mira la lista de funcionalidades y la documentación de la API, pero lo que funde la línea de soporte suele ser el elemento de configuración más aburrido: la máquina de estados del estado del pedido. Configura mal las transiciones y los pedidos empiezan a "desaparecer", "congelarse" y "volver a la vida", mientras soporte, almacén y finanzas cuentan cada uno una historia distinta. He visto este fallo exacto tres veces, cada una diferente.
Por qué la máquina de estados del estado del pedido importa tanto
El estado del pedido es el único idioma que comparten todos los roles. Soporte lo consulta, el almacén trabaja según él, finanzas liquida contra él, el cliente lo ve en la página de seguimiento. La máquina de estados del estado del pedido es el libro de gramática: qué estado va hacia dónde, quién lo mueve, a dónde va un pedido atascado.
Si la gramática está mal, nadie habla el mismo idioma. El almacén dice "enviado", soporte sigue viendo "Asignado", el cliente pregunta "dónde está mi pedido" y soporte solo puede decir "déjame comprobar" — y luego corre a preguntar al almacén en un grupo de chat. No es un soporte poco profesional. La máquina de estados la traicionó primero.
De mis tres colapsos, aquí están los dos más instructivos.
Colapso uno: estados congelados, cientos de pedidos "desaparecen"
Hace dos años lideré un go-live de OMS para un 3PL de California que movía varios miles de pedidos al día, con el lanzamiento dos semanas antes del pico de Acción de Gracias. El día tres, la responsable de soporte llamó: "Lin Xiao, un lote de pedidos está atascado en 'Asignado' en tu sistema, pero el almacén dice que la mercancía se envió ayer."
Causa raíz: cuando terminaba el picking, el WMS devolvía "picking completo", pero nuestra máquina de estados tenía "Asignado" pasando a "En picking" — y la tabla de mapeo de eventos del WMS no tenía ningún valor para "En picking". Los dos documentos de integración se escribieron por separado, y la UAT solo cubrió el camino feliz. Nadie recorrió cada evento que el WMS podía enviar a través de la máquina de estados del OMS para confirmar que cada uno tenía una salida.
Resultado: cientos de pedidos congelados en "Asignado". Soporte veía "Asignado" por todas partes, el almacén había enviado hacía tiempo, el seguimiento del transportista mostraba "recogido" — tres fuentes, tres historias, y la línea de soporte se fundió.
La solución no fue glamurosa: parcheamos el mapeo de eventos de noche y luego escribimos un trabajo de conciliación que actualizó en bloque los pedidos atascados a su progreso real en el WMS. Dos días y dos noches. Salvamos la operación, pero la primera oleada de experiencia de cliente de la temporada pico se había perdido. Esa lección entró en cada checklist desde entonces: la tabla de mapeo de eventos debe alinearse con la máquina de estados línea por línea. Ni una línea omitida.
Colapso dos: rama de cancelación ausente, los pedidos "vuelven a la vida"
Otro cliente, una marca DTC, tenía una hermosa máquina de estados con un solo flujo hacia adelante: Revisión pendiente → Asignación pendiente → Asignado → En picking → Empaquetado → Enviado → Entregado. Cuando un cliente cancelaba, el OMS enviaba una instrucción de interceptación al WMS — pero la máquina de estados no tenía ningún estado de "Interceptando", "Interceptado" o "Interceptación fallida".
La interceptación llegó al almacén, pero la tarea de picking ya estaba liberada y el operario nunca vio la marca de interceptación (el estado de tarea del WMS y el estado de pedido del OMS son dos cosas distintas). La mercancía se envió de todos modos. El OMS mostró "Cancelado" y el reembolso salió. Resultado neto: el cliente recibió un pedido "ya cancelado", la empresa asumió el flete de devolución y soporte tuvo que explicar por qué un pedido cancelado seguía llegando.
He visto este fallo exacto tres veces. Cada cliente dice "no pensamos que la cancelación necesitara estados". Mi respuesta siempre es la misma: la cancelación no es el final de un estado. La cancelación es una rama entera.
La checklist de tres tablas para diseñar la máquina de estados del estado del pedido
Tras suficientes cicatrices, ahora configuro la máquina de estados de cada proyecto a partir de estas tres tablas. Cópialas directamente.
Tabla uno: el flujo principal — la vida normal de un pedido. Cada fila necesita cuatro columnas: el estado, quién lo mueve, a dónde va al expirar el tiempo y a dónde puede retroceder.
- Revisión pendiente: lo mueve la automatización del sistema o un humano; expira hacia revisión manual; este es el inicio, sin retroceso.
- Asignación pendiente: lo mueve el waving o el motor de reglas; va a En espera cuando falta stock; retrocede a Revisión pendiente si se rechaza la revisión.
- Asignado: lo mueven las devoluciones de llamada del WMS; va a excepción cuando el WMS guarda silencio demasiado tiempo; retrocede a Asignación pendiente cuando se libera la asignación.
- En picking: lo mueven las devoluciones de llamada del WMS; expira hacia una excepción de picking; retrocede a Asignado cuando se cancela la tarea.
- Empaquetado: lo mueven las devoluciones de llamada del WMS; retrocede (con aprobación) cuando una interceptación tiene éxito y la mercancía vuelve a staging.
- Enviado: lo mueven las devoluciones de llamada del transportista o del WMS; el último punto rastreable antes de la meta.
- Entregado: lo mueven las devoluciones de llamada del transportista; el final.
Tabla dos: los estados de rama — la cancelación y la interceptación tienen su propio carril.
Cancelación solicitada → En revisión → Cancelado, o Cancelación rechazada (de vuelta al estado original). Interceptando → Interceptado (mercancía de vuelta a Empaquetado, pendiente de manejo) → Interceptación fallida (el flujo original continúa, soporte interviene).
El punto clave: la cancelación y la interceptación son dos acciones distintas — nunca las fusiones en un solo estado. "Cancelado" es el resultado para el dinero y el pedido; "Interceptado" es el resultado para la mercancía física. Cancelar después de que la mercancía se envió frente a cancelar antes de que nada se moviera son dos situaciones completamente distintas, y los estados deben permanecer separados. Fusiónalos y obtendrás historias de fantasmas como "un pedido cancelado se envió".
Tabla tres: los estados de excepción — una salida de emergencia para cada estado.
Revisión rechazada, En espera por falta de stock, Excepción de dirección, Excepción de pago, Tiempo de espera de devolución de llamada del WMS agotado, Excepción del transportista. Cada estado de excepción recibe tres asignaciones: quién es su dueño, el SLA de manejo y a quién escala cuando no se puede resolver. Un estado de excepción sin dueño es lo mismo que no tenerlo.
Al configurar cada estado, haz tres preguntas — esta es una página fija en mi checklist de la noche del go-live:
- ¿Quién mueve este estado? Un estado sin dueño se congelará. Movido por el sistema: documenta qué job y su programación. Movido por humano: documenta qué rol.
- ¿A dónde va al expirar el tiempo? Cada estado necesita una salida por tiempo — sin ella, estás plantando una mina para tu yo futuro.
- ¿A dónde puede retroceder, y el retroceso necesita aprobación? El retroceso es la parte más olvidada de una máquina de estados, y sin embargo ocurre a diario en producción.
Las tres formas más comunes en que fallan las máquinas de estados del estado del pedido
Primera, los eventos y los estados están desalineados. Los estados del OMS los mueven eventos externos — devoluciones de llamada del WMS, del transportista, de pagos — y cada evento debe mapear exactamente a una transición. Los proyectos que solo prueban el camino feliz fallan aquí tarde o temprano. La solución: lista cada evento que los sistemas externos pueden enviar, recorre cada uno a través de la máquina de estados y parchea los huecos en el acto.
Segunda, el estado visible y el estado de flujo de trabajo se mezclan. Soporte quiere la vista orientada al cliente, el almacén necesita la vista operativa, finanzas necesita la vista de liquidación. Forzar las tres en una sola máquina de estados enfada a todos. La solución: la máquina de estados del flujo de trabajo maneja solo las transiciones internas; una tabla de mapeo separada de "estado visible para el cliente" maneja la presentación. Dos tablas — una fuente de verdad, una capa de traducción.
Tercera — contraintuitivo — una máquina de estados más fina no es mejor. Una vez vi un proyecto con más de treinta estados; soporte se entrenó tres días y aún no podía buscar pedidos, y cada nueva contratación memorizaba un diagrama de transición. Las máquinas de estados de producción más estables corren alrededor de una docena de estados entre flujo principal y ramas. Los estados extra son decoración, y la decoración cobra renta de mantenimiento: cada estado necesita un tiempo de espera, una ruta de retroceso, permisos y casos de prueba. Cada estado añadido no suma coste — lo multiplica.
Una compensación más: la proporción de transiciones automáticas frente a confirmación manual. Más automatización, más eficiencia, excepciones más difíciles. Mi mínimo: revisión, interceptación y grandes reembolsos siempre mantienen confirmación humana. ¿Quieres automatización total? Termina primero la lógica de respaldo de la rama de excepciones.
Ejecuta esta checklist la noche del go-live
La noche del go-live, haz tres cosas: recorre cada estado en el entorno de prueba y pregunta "qué pasa si se atasca aquí"; confirma que cada evento externo tiene una salida en la máquina de estados; ejecuta las ramas de cancelación e interceptación tres veces cada una — ahí es donde viven los colapsos.
Si no puedes responder, no salgas en vivo esta noche. Dos horas extra en la máquina de estados antes del lanzamiento ahorran veinte llamadas de queja después. He hecho esa cuenta tres veces. Sale rentable siempre.
Por Lin Xiao, consultor de implementación de WMS Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
