Cuando el WMS y el ERP no coinciden: fallos de interfaz, brechas de inventario y quién es dueño del número

Conclusión primero: cuando el inventario del WMS y el del ERP no coinciden, la causa no suele ser que un sistema haya calculado mal. Es que los dos sistemas definen lo mismo de forma diferente. Una interfaz rota es solo el tipo de fallo más visible. Con más frecuencia, la correspondencia de lote, unidad o estado está desalineada, de modo que los libros difieren en un registro mientras el stock físico nunca se movió en absoluto. En el trabajo de integración WMS-ERP para almacenes, el triaje tiene un orden estricto: primero comprobar si la interfaz está fluyendo, luego comprobar si las correspondencias son correctas, y solo entonces hablar de quién es dueño de la brecha. Invertir ese orden puede hacerte pasar un mes arreglando el lugar equivocado.

He visto este problema tres veces. El caso más reciente fue un cliente de bienes de consumo en la tercera semana después del arranque. Finanzas decía que el ERP mostraba un faltante de un producto en papel de más de dos mil unidades. El almacén decía que el stock físico estaba completo, y un recuento cíclico les dio la razón. Cada lado estaba seguro de que el otro estaba equivocado, y el equipo del proyecto casi reconstruyó la interfaz desde cero. La causa real era casi embarazosa: el ERP gestionaba el stock por caja, el WMS lo gestionaba por pieza, y la interfaz enviaba cantidades en cajas que el lado receptor registraba como piezas. Con veinticuatro piezas por caja, un solo pedido creaba una brecha de veintitrés unidades. Nada estaba roto. Faltaba una fila en la tabla de correspondencia de unidades.

Fallos de interfaz en la integración WMS-ERP: cuatro tipos, en orden

Cuando una interfaz falla, no reinicies el servicio primero. Un reinicio solo corrige una interrupción temporal. No corrige un error de configuración. Clasifico los fallos de interfaz en cuatro tipos y los descarto uno por uno. Primero, el mensaje nunca salió: el documento saliente queda en una cola pendiente en el WMS, a menudo porque su estado es incorrecto, por ejemplo un pedido sin aprobar que la interfaz nunca recogerá. Segundo, salió pero nunca llegó: la cola del middleware está saturada, o un certificado caducó, y la profundidad de la cola más los registros de errores lo dejan claro. Tercero, llegó pero fue rechazado: un campo faltante, o un código que no existe en los datos maestros del otro sistema, hace que el mensaje sea devuelto. Cuarto, y el más peligroso: llegó y se contabilizó, pero se contabilizó mal, por ejemplo un error de conversión de unidades o una discrepancia en el código de almacén, de modo que los libros se separan silenciosamente y el problema estalla días después.

En toda lista de verificación de la noche del arranque, insisto en tres puntos: una alerta por acumulación en la cola de la interfaz, un botón de reintento con historial de reintentos para los documentos fallidos, y un responsable diario de limpieza para los documentos que el otro lado rechazó. Una interfaz sin esos tres puntos está funcionando desnuda. Una vez trabajé con un cliente cuya interfaz se rompía todas las noches a la misma hora, porque el envío programado chocaba con la ventana de mantenimiento nocturno del otro sistema. Mover la ventana de envío lo resolvió. Revisa los tiempos y los registros antes de sospechar del código.

Tablas de correspondencia para la integración WMS-ERP: lote, unidad y estado

Una vez que la interfaz fluye y los libros siguen sin coincidir, revisa tres tablas de correspondencia. La primera es la correspondencia de unidades: caja, palé, pieza, embalaje interior, qué sistema es dueño de la unidad base, dónde vive la conversión y si alguna categoría de producto es una excepción. La segunda es la correspondencia de lotes: ¿el número de lote del ERP es lo mismo que el número de lote del WMS? Algunas empresas usan la fecha de producción como lote en el ERP mientras el WMS usa un número de lote de recepción, y ambos se parecen sin coincidir. La tercera es la correspondencia de estados: pendiente de inspección, en tránsito, congelado, dañado, ¿a qué corresponde cada estado de stock del WMS en el ERP, el stock dañado cuenta como disponible, el stock congelado queda en los libros?

El fallo más típico que he visto fue un estado "pendiente de inspección" faltante. La mercancía en espera de inspección de calidad quedaba en estado pendiente en el WMS, pero el ERP la contaba como stock disponible, así que ventas tomaba pedidos contra ese número y luego no podía enviar. La solución no fue complicada: imprimir la tabla de correspondencia de estados, hacer que los responsables de negocio de ambos lados la firmaran línea por línea, poner el stock pendiente, congelado y dañado cada uno en su propio grupo, y dejar que ventas viera solo el estado disponible. Haz firmar la tabla antes del arranque, no la acuerdes verbalmente.

La conciliación necesita una tabla de variaciones fija, no una nueva extracción de datos cada vez que algo sale mal. La tabla necesita al menos cuatro columnas: producto, cantidad del WMS, cantidad del ERP y motivo de la variación. La columna de motivo solo admite cinco valores: interfaz no llegada, conversión de unidades, correspondencia de estados, diferencia de lote o diferencia física. Cualquier fila marcada como "otro" vuelve para una nueva investigación. Ejecuta esa tabla durante un mes y verás que los motivos de variación se concentran mucho, normalmente una o dos categorías que se repiten. Esa disciplina es lo que hace que la conciliación de la integración WMS-ERP para almacenes se sostenga con el tiempo. Corrige esos uno o dos puntos y la variación total cae bruscamente.

Quién es dueño del número: fija la regla antes de la discusión

Cuando los libros no coinciden, la parte más cara rara vez es corregir el número. Es que los dos lados se culpen entre sí. El almacén dice que el sistema lo envió mal, TI dice que el negocio lo introdujo mal, finanzas dice que no se puede confiar en ningún lado. Así que la responsabilidad debe fijarse antes de que aparezca un problema, por escrito en los documentos del arranque, no discutirse después de los hechos.

La división que usamos es simple. Los problemas de transmisión de la interfaz pertenecen a TI, juzgados por los registros de transmisión: si el registro muestra que se envió y el otro lado no lo recibió, la capa intermedia es la dueña. Los problemas de reglas de correspondencia pertenecen al equipo del proyecto, juzgados por la tabla de correspondencia firmada: lo que diga la tabla es como se cuenta. Los problemas físicos pertenecen al almacén, juzgados por los resultados de recuento: si el recuento y el WMS no coinciden, revisa primero el stock físico. Los problemas de introducción de datos pertenecen a quien introdujo el documento, juzgados por el valor original del documento, y cualquier cambio deja rastro. Una vez que existe la regla, una variación se clasifica primero y se deriva a su dueño, sin gastar media reunión decidiendo de quién fue la culpa.

Este es un juicio contraintuitivo: cuanto menor es la variación, más en serio debes tomarla. Una brecha de dos mil unidades es investigada por todos. Una brecha de tres o cinco unidades se despacha con un ajuste manual, porque parece lo bastante cercana. Pero las pequeñas variaciones suelen ser la señal temprana de un error de correspondencia. Tres unidades hoy pueden ser tres mil el mes que viene. Nuestra regla es que cada variación entra en la tabla con una categoría de motivo, aunque resulte ser un escaneo extra durante un recuento. Las pequeñas variaciones sin registrar significan que, cuando llega una grande, ni siquiera sabes por dónde empezar a buscar.

Lista de verificación de arranque para la integración WMS-ERP en almacenes

Para cerrar, aquí tienes una lista de verificación que puedes usar directamente. En la noche del arranque, marca cada punto: ¿la tabla de correspondencia de unidades cubre las categorías de excepción, la tabla de correspondencia de estados está firmada por los responsables de ambos lados, la regla del número de lote es lo mismo en ambos sistemas, la interfaz tiene alertas de fallo y un mecanismo de reintento, la tabla de variaciones se ejecuta automáticamente cada día, el motivo de la variación está limitado a esas cinco categorías, y el documento de responsabilidad se ha enviado a las tres partes? Siete puntos, todos aprobados, entonces arranca. Si falta aunque sea uno, el costo de corregirlo después del arranque es varias veces lo que cuesta ahora.

La cruda verdad es esta: los libros del WMS y del ERP que no coinciden casi nunca son un problema de tecnología. Son un problema de definiciones que la dirección nunca cerró. Escribe las definiciones, haz que las firmen y concilia cada día. Eso hace más que reemplazar un sistema jamás. He visto este problema tres veces, y las causas fueron diferentes cada vez, pero la solución fue la misma: primero el triaje, segundo asignar la responsabilidad y por último corregir el sistema.

Por Lin Xiao, Consultor de Implementación de WMS

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