Mientras vendes por una sola tienda, un pedido es simple: entra, reserva stock, va a envío. El problema empieza cuando añades un marketplace, una app móvil, venta B2B y una tienda física. De repente el mismo pedido se ve distinto en cada sistema, y la disponibilidad de producto deja de ser un único número. Para un director de operaciones o de fulfilment eso significa sobreventa, envíos tardíos y un equipo de soporte que adivina qué pasó realmente.
Por nuestra experiencia, lo difícil en estos proyectos no es añadir otro canal, sino construir una capa coherente que lo sepa todo de cada pedido y pueda dirigirlo. Incluso donde no traemos una caja de catálogo, cubrimos los roles y combinamos las competencias necesarias para que un sistema de gestión de pedidos se construya y funcione en producción, sin montar un equipo desde cero.
¿Por qué los pedidos se separan entre canales?
Porque cada canal tiene su modelo de datos, su ritmo y su propia verdad sobre el stock. La tienda retira una unidad en la fase de carrito, el marketplace sincroniza cada pocos minutos y el ERP solo contabiliza tras el pago. Esos retrasos se suman y la misma unidad se puede vender dos veces.
Encima, los distintos estados («pagado», «en curso», «empaquetado») se llaman de forma diferente en cada herramienta, las devoluciones recorren un camino distinto que los envíos y las correcciones manuales viven en hojas de cálculo. Sin un lenguaje común para el pedido, cada equipo trabaja con una imagen distinta de la realidad, y los huecos salen a la luz solo durante una reclamación.
¿Qué es la orquestación omnicanal de pedidos y el enrutado a almacenes?
La orquestación de pedidos es el corazón de un OMS: la capa que recoge un pedido de cualquier canal, lo reduce a un único formato y decide cómo cumplirlo. Aquí el pedido deja de pertenecer a un canal y empieza a pertenecer a la empresa.
La pieza clave es la lógica de enrutado, la respuesta a «desde dónde lo enviamos». Diseñamos reglas que ponderan:
- la disponibilidad en cada almacén y tienda,
- la distancia y el coste de envío hasta el cliente,
- las prioridades (p. ej. vaciar un almacén de temporada, el SLA de un cliente B2B),
- la capacidad de preparación de una ubicación concreta en un día concreto.
Un enrutado bien formado puede además repartir un mismo pedido entre varias fuentes cuando ninguna ubicación lo tiene todo, y hacerlo de modo que el cliente reciba los menos paquetes posibles a un coste aceptable.
¿Cómo sincronizar el stock y la disponibilidad entre canales?
Esta es la pregunta con la que tropiezan la mayoría de los despliegues. En vez de mantener stock separado por canal, construimos una única fuente de verdad para la disponibilidad y alimentamos desde ella todos los puntos de venta. El OMS se sitúa entre el almacén y los canales, así que todos ven una cifra coherente.
En la práctica usamos mecanismos que protegen de la sobreventa y del stock «fantasma»:
- reservas y bloqueos blandos sobre la mercancía mientras se prepara un pedido,
- disponible para prometer (ATP), que cuenta no solo el stock en almacén sino la mercancía en tránsito,
- colchones de seguridad para canales con sincronización más lenta,
- actualizaciones por eventos en vez de un pesado recálculo nocturno.
¿Cómo tratar los envíos parciales y los pedidos pendientes?
Un pedido completo rara vez viaja en un solo paquete desde un solo sitio. El e-commerce real tiene que arreglárselas cuando una parte del pedido está disponible ahora y otra hay que conseguirla. Modelamos el pedido para que las líneas puedan tener su propio ciclo: unas empaquetadas y enviadas hoy, otras pendientes con fecha estimada de entrega.
Eso trae decisiones concretas de producto y de técnica: cómo avisar al cliente de un envío parcial, cuándo cobrar el pago, cómo imputar el envío cuando hay varios paquetes y qué hacer cuando un pedido pendiente nunca se cierra. Diseñamos estas reglas junto al equipo de operaciones, porque son ellos, y no el código por sí solo, quienes deciden la experiencia del cliente.
¿Qué herramientas de atención al cliente hacen falta para los pedidos?
Ni el mejor enrutado sirve si el agente no ve qué pasa con un pedido. Por eso parte de un OMS es una capa de herramientas para soporte y operaciones: un panel donde un pedido tiene una imagen completa.
Construimos las funciones que de verdad se usan durante una llamada con un cliente:
- el historial completo del pedido (estados, pagos, envíos, devoluciones) en un solo sitio,
- acciones correctivas: corregir una dirección, cancelar una línea, reexpedir,
- una vista de las reservas y de la fuente de preparación, para responder «dónde está mi paquete»,
- la gestión de devoluciones y reclamaciones atada al mismo pedido.
¿Cómo conectar las integraciones con ERP, WMS y pagos?
Un OMS no vive en el vacío: su valor viene de hablar con el resto del panorama de sistemas. Lo tratamos como una capa de integración que traduce el pedido entre el mundo de la venta y el mundo de la preparación y las finanzas.
Normalmente lo conectamos con:
- el ERP, para productos, precios, facturas y contabilización,
- el WMS, para preparación, empaquetado y movimientos de almacén,
- las pasarelas de pago, para autorizaciones, cobros y devoluciones,
- los transportistas, para etiquetas, seguimiento y estados de entrega.
Diseñamos estas integraciones para que sean resistentes a los fallos del otro lado: con colas, reintentos y un comportamiento claro cuando el ERP o el WMS dejan de responder un rato. Así la caída de un sistema no detiene todo el flujo de pedidos.
¿Cómo garantizar la fiabilidad y la coherencia de los pedidos?
Un pedido es dinero y una promesa al cliente, así que un OMS tiene que ser coherente e idempotente: el mismo mensaje procesado dos veces no puede crear un segundo envío ni un segundo cobro. Nos apoyamos en una arquitectura por eventos donde cada paso tiene un estado inequívoco y el historial de cambios se puede reproducir.
En la práctica eso significa diseñar para los casos límite: webhooks duplicados de un marketplace, un pago que se confirma tarde o un almacén que reporta una falta después de haber reservado el stock. Construimos mecanismos de conciliación y monitorización que detectan la desviación antes que el cliente. Esta es la capa que decide si el sistema aguanta un pico de ventas o genera caos.
¿Qué competencias aportamos a un proyecto de OMS?
Formamos el equipo alrededor de la naturaleza concreta de la gestión de pedidos, no «por si acaso». En proyectos así coconstruimos el equipo con los roles que de verdad cierran el tema:
- un arquitecto / desarrollador backend que diseña el modelo de pedido y la lógica de orquestación,
- ingenieros de integración que conocen la realidad de las API de ERP, WMS, pagos y transportistas,
- un especialista en datos y coherencia que vela por stock, reservas y conciliación,
- un especialista DevOps que construye despliegues, colas y monitorización para el tráfico de pico.
Nos apoyamos en experiencia real en proyectos de e-commerce y sistemas transaccionales, donde lo que cuenta es el volumen y la corrección del dato.
¿Cómo lo hacemos en RITS?
Trabajamos como partner nearshore desde Polonia que refuerza tu equipo con las competencias necesarias para construir y operar un OMS. En vez de vender una caja, entramos en tu panorama de sistemas y diseñamos la capa de pedidos en torno a tus canales y procesos.
- cubrimos roles desde la arquitectura hasta las integraciones y DevOps, ajustados al alcance del proyecto,
- verificamos las competencias antes de empezar, y nuestra búsqueda suele cerrarse en unas tres semanas,
- como partner en una zona horaria cercana entramos en tus revisiones de código y reuniones sin una larga puesta en marcha,
- trabajamos en el modelo que mejor encaje: software a medida construido por nuestro equipo, o refuerzo de equipo cuando hay que completar competencias rápido.
¿Por dónde empezar con un sistema de gestión de pedidos?
Empieza por el flujo que más duele, normalmente la sobreventa o un descuadre de stock entre la tienda y un marketplace. Describe cómo vive hoy un pedido, desde que entra hasta que se envía, y dónde pierdes coherencia. Eso muestra si necesitas un OMS completo o, primero, solo orquestación y sincronización de stock.
La elección del modelo de colaboración cuenta aquí tanto como la tecnología. Las diferencias entre refuerzo de equipo, equipo dedicado y servicios gestionados las describimos en nuestro artículo sobre modelos de colaboración en TI.
¿Peleando con los pedidos entre canales? Hablemos - ajustaremos el equipo y la arquitectura del OMS a tu e-commerce.