Implementación de OMS: alinea tres conjuntos de datos maestros antes de fijar una fecha de lanzamiento

Primero la conclusión: cuando hay que revertir una implementación de OMS, casi nunca es porque el sistema se instaló mal. Es porque los datos no estaban listos. Si los datos maestros de pedidos, inventario o canal están desalineados, el día del lanzamiento trae sobreventas, envíos erróneos y pedidos atascados en el limbo, y ningún calendario puede salvarte. Los calendarios importan, pero vienen después de la preparación de los datos. Si quieres una idea de cuánto suele durar cada fase, esta línea de tiempo por fases de la implementación de OMS es una referencia útil. Este artículo trata de algo distinto: el trabajo de datos que debe hacerse antes de que ese calendario signifique algo. He visto este fallo tres veces, y el patrón es siempre el mismo. En 2023, un cliente de artículos para el hogar migró los datos maestros de productos pero nunca asignó los SKU de canal, así que el mismo producto llevaba dos códigos en dos marketplaces y sobrevendió más de 200 pedidos en la primera semana. Otro cliente llevaba el inventario en una hoja de cálculo manual mientras el WMS tenía cifras en vivo; ambas diferían en torno a un 30%, y un superventas se agotó sin forma de detenerlo. El tercer caso es mi historia de advertencia favorita: "shipped" significaba "salió del almacén" para el canal y "recogido por el transportista" para el OMS, una diferencia de un día que produjo una avalancha de quejas de "mi seguimiento no se mueve" mientras soporte pensaba que los pedidos se habían perdido.

Por qué estos tres: datos de pedidos, inventario y canal en la implementación de OMS

La alineación de los datos de pedidos trata del ciclo de vida completo, con las mismas palabras en todas partes: placed, paid, reviewed, picked, shipped, collected, delivered, cancelled, refunded. Cada paso necesita un nombre en el OMS, un nombre en el canal y un nombre en el WMS, escritos en una única tabla de correspondencias. El proyecto más desordenado en el que trabajé tenía cuatro nombres distintos para un pedido cancelado, y el OMS solo reconocía uno de ellos. Los otros tres quedaron como "awaiting shipment" hasta que el almacén casi los envía. La regla es tajante: sin una fila de correspondencia firmada por las tres partes, no se avanza a la siguiente fase. La alineación del inventario trata de la definición y la frescura. Definición significa decidir qué cuenta como vendible: ¿cuenta el stock en tránsito, cuenta el stock en inspección, cuenta el stock reservado, cuenta el stock dañado? Cada respuesta debe quedar por escrito. Frescura significa frecuencia de sincronización: en tiempo real, cada 15 minutes, o una vez al día. Esas decisiones no son cosméticas: deciden tu riesgo de sobreventa. En un proyecto de 2024, el cliente decía que el inventario era "básicamente preciso", pero el almacén de comercio electrónico solo sincronizaba una vez al día, y una transmisión en vivo podía vender el volumen de un día entero en una hora. La sobreventa estaba garantizada hasta que pasamos a la reserva en tiempo real al realizar el pedido. La alineación de los datos de canal trata de la correspondencia de productos y precios. El mismo producto puede tener un título, una especificación, un código de barras, un precio y un precio promocional distintos en cada canal, y el OMS necesita una tabla de correspondencias limpia: SKU de marketplace a SKU interno, precio de marketplace a precio interno, y qué reloj rige el inicio y el fin de una promoción. Un error de correspondencia de precios es más caro que un error de inventario. Un error de inventario sobrevende; un error de precio vende al precio equivocado, y eso no se puede recuperar.

Lista de verificación de preparación de datos en cuatro pasos para la implementación de OMS

Paso uno, inventariar los datos. Enumera cada sistema fuente, responsable, frecuencia de actualización y fecha de la última conciliación para los tres conjuntos de datos. Los datos sin responsable son datos que nadie mantiene, y necesitan un responsable antes del lanzamiento, no después. Paso dos, depurar. Eliminar duplicados, completar y unificar códigos. Fusiona los SKU duplicados, completa los códigos de barras que faltan y elige un código maestro donde un producto tenga varios. Mi listón es concreto: muestrea 200 registros después de la depuración, y si la tasa de error supera el 2%, devuélvelo para otra ronda. No lances con datos sucios esperando que el sistema los perdone. Paso tres, conciliar. Contrasta las tres tablas entre sí, buscando tres tipos de diferencia: diferencias de cantidad, diferencias de estado y diferencias de precio. Conserva el informe de conciliación. Las diferencias deben eliminarse o cubrirse con un plan de tratamiento por escrito antes de que nadie firme. Paso cuatro, ensayar el cambio, dos veces. La primera ronda recorre el camino feliz. La segunda ronda solo ejecuta fallos: ¿qué pasa cuando se cae una conexión de canal, cuando se detiene la sincronización de inventario, cuando un pedido se envía dos veces? Ensaya con volumen real. Que pasen diez pedidos de prueba no prueba nada sobre que pasen diez mil pedidos.

Los puntos de fallo que sigo viendo

El primer punto de fallo es migrar datos estáticos sin sus relaciones. Llegan los productos, pero no llegan las asignaciones de producto a almacén ni las relaciones de listado de producto a canal, así que el sistema tiene stock que no puede localizar y almacenes desde los que no puede listar. Los datos maestros y los datos de relaciones deben migrarse y verificarse juntos. El segundo es ignorar los pedidos históricos. Algunos equipos dejan los pedidos antiguos en el sistema viejo y los nuevos en el nuevo, así que soporte tiene que buscar en dos sistemas para un cliente y las devoluciones dejan de cuadrar. Incluso migrar solo los últimos tres meses necesita una regla escrita: cómo se asignan los estados antiguos y qué pasa con los pedidos en mitad de un reembolso. El tercero es contraintuitivo: más datos no siempre son mejores. Trabajé en un proyecto que migró cinco años de productos descatalogados, canales muertos y SKU de prueba en nombre de la exhaustividad. La tabla de correspondencias se hinchó tanto que buscar un SKU exigía un auténtico trabajo de detective. La regla correcta es migrar solo datos vivos. Los registros descatalogados, anulados y de prueba pertenecen a un archivo, no a la base de datos de producción. La preparación de los datos se mide por la limpieza, no por el volumen. Un caso de este año hace concreto el punto del ensayo. En May 2025, un cliente de ropa superó los tres primeros pasos y solo ensayó el camino feliz. En la segunda semana tras el lanzamiento, una API de marketplace falló durante dos horas y envió más de 300 pedidos dos veces. El almacén preparó los duplicados antes de que los controles de salida los detectaran. Añadimos un ensayo de fallos que cubría desconexiones, envíos duplicados y sincronización de inventario detenida, y solo entonces el proyecto estuvo realmente listo. Los flujos normales son fáciles de ensayar; los flujos de fallo son donde se decide la preparación. Así que este es mi marco de decisión. Antes de fijar una fecha de lanzamiento, responde con honestidad a cuatro preguntas. ¿Quién es el responsable de cada uno de los tres conjuntos de datos maestros? ¿Cuál es la tasa de error muestreada tras la depuración? ¿Las diferencias de conciliación en tres vías están eliminadas? ¿El ensayo del cambio ha cubierto escenarios de fallo? Si falta alguna respuesta, retrasa la fecha. Un retraso de una semana es mucho más barato que un mes de retrabajo tras un mal lanzamiento. Por Lin Xiao, Consultor de Implementación de WMS

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