Integrar WMS con ERP propio: lo que nadie te dice antes de empezar

Cuando una empresa distribuidora decide integrar su WMS con su ERP propio, lo primero que aparece es una demo. El WMS muestra cómo los movimientos de bodega fluyen al ERP. El equipo del ERP muestra cómo las órdenes del ERP se convierten en instrucciones de picking en el WMS. Todo parece razonable.

Después se firma el contrato y empieza el proyecto real.

Lo que no estaba en la demo es lo que quiero contarte acá.

El problema del modelo de datos

El WMS tiene un modelo de datos. El ERP propio tiene otro. Y la integración requiere que esos dos modelos conversen sin perder información ni crear inconsistencias.

Esto parece obvio, pero la profundidad del problema no aparece hasta que empiezas a mapear en detalle.

¿Cómo se identifica un producto en el WMS? ¿Con el mismo código que en el ERP? ¿O con un código de bodega distinto que hay que traducir? ¿Quién es la fuente de verdad del código de producto — el ERP o el WMS?

¿Qué pasa cuando un producto llega con código de barra diferente al que está en el ERP? ¿El WMS lo rechaza? ¿Lo acepta y crea una inconsistencia? ¿Lo escala a alguien para resolverlo manualmente?

¿Qué es una "orden" en el ERP? ¿Es la misma entidad que una "orden de despacho" en el WMS? ¿O es una relación de uno a muchos — una orden del ERP puede generar varias oleadas de picking en el WMS?

Esas preguntas no tienen respuestas genéricas. Las respuestas correctas dependen de cómo funciona la operación de esa empresa específica, y el proyecto de integración no puede avanzar sin ellas.

El tiempo que toma responderlas no es tiempo técnico. Es tiempo de proceso — y generalmente lo toman personas que no están en el proyecto: el jefe de operaciones, el gerente comercial, el responsable de logística.

La trampa de "lo resolvemos en el proyecto"

Hay una frase que aparece frecuentemente en los proyectos de integración y que es una señal de alerta: "ese detalle lo definimos durante el proyecto".

Eso suena razonable. El problema es que hay detalles que no son detalles — son decisiones de negocio que afectan la arquitectura entera de la integración.

¿El stock actualiza en tiempo real o en lotes? Esa no es una decisión técnica. Es una decisión de negocio: ¿puede el equipo de ventas comprometer stock que todavía no está confirmado en bodega? Si el negocio necesita que sí, la integración tiene que ser en tiempo real. Si el negocio puede trabajar con stock confirmado cada 30 minutos, los lotes funcionan.

¿Quién tiene la prioridad cuando hay un conflicto de stock — el ERP o el WMS? Si el ERP dice que hay 10 unidades de un SKU y el WMS dice que hay 8, ¿cuál es la cifra correcta? ¿Quién tiene la razón y quién tiene que actualizarse?

Esas preguntas tienen respuesta solo si alguien con autoridad de negocio las responde antes de que empiece la implementación técnica. Si se posponen al proyecto, el equipo técnico va a tomar esas decisiones por defecto — con criterio técnico, no con criterio de negocio.

El problema del maestro de productos

Casi todo proyecto de integración WMS-ERP choca con el mismo muro a las pocas semanas de comenzar: el maestro de productos está en mal estado.

El maestro de productos es el catálogo que define qué existe en el sistema — códigos, descripciones, unidades de medida, dimensiones, pesos. Para que el WMS y el ERP hablen correctamente, ese catálogo tiene que ser consistente en ambos sistemas.

Lo que generalmente se encuentra:

Productos con códigos distintos en el WMS y el ERP, sin tabla de equivalencias confiable.

Unidades de medida inconsistentes. El ERP vende por unidad. El WMS recibe por caja. La caja tiene 12 unidades. Esa conversión tiene que estar en algún lado — y si no está en los datos maestros, tiene que estar en la lógica de integración, lo que agrega complejidad.

Productos activos en uno e inactivos en el otro. El ERP tiene 4.200 SKUs activos. El WMS tiene 3.800. Los 400 de diferencia son un problema que nadie anticipó.

Descripciones y categorías que no coinciden. Esto no rompe la integración técnica, pero rompe los reportes — y los reportes son la razón por la que muchas empresas hacen la integración.

Limpiar el maestro de productos no es trabajo del equipo de integración. Es trabajo del área comercial, del área de operaciones, y de quien administra los sistemas. Y toma tiempo — generalmente más de lo que estaba en el plan.

Los procesos de excepción

El 80% del flujo en una distribuidora es predecible: el pedido entra, se confirma stock, se genera el picking, se despacha, se factura. Eso la integración lo puede manejar bien.

El problema es el 20% restante. Las excepciones.

¿Qué pasa cuando un producto está reservado en el ERP pero dañado en bodega? ¿El WMS cancela el picking automáticamente? ¿Avisa al ERP? ¿Quién avisa al cliente?

¿Qué pasa cuando llega una devolución? ¿Entra al WMS como una recepción normal? ¿Se integra automáticamente al ERP como un abono? ¿O hay un proceso manual de inspección antes de que se pueda devolver al inventario disponible?

¿Qué pasa cuando se recibe más cantidad de la que venía en la orden de compra? ¿El WMS acepta el excedente? ¿El ERP ajusta la orden automáticamente? ¿O hay un flujo de aprobación?

Cada una de esas excepciones requiere una decisión. Algunas son simples. Otras tienen implicancias contables, de inventario y de relación con proveedores o clientes que requieren involucrar a más personas.

La integración técnica puede manejar cualquier excepción — si el proceso está definido. Lo que no puede hacer es inventar el proceso.

El timing entre sistemas

Un problema que aparece tarde es el de la sincronización temporal entre los sistemas.

El ERP confirma una orden y espera que el WMS genere el picking. ¿Cuánto espera? ¿Un segundo? ¿Diez minutos? ¿No espera y el vendedor tiene que verificar manualmente?

El WMS confirma el despacho y el ERP tiene que generar la factura. ¿Eso es inmediato? ¿O hay un proceso de validación intermedia que puede tomar horas?

Si los dos sistemas no tienen expectativas alineadas sobre los tiempos de respuesta del otro, se crean estados inconsistentes — órdenes que están confirmadas en el ERP pero que el WMS todavía no recibió, despachos que el WMS marcó como completados pero que el ERP todavía no facturó.

Esos estados inconsistentes no son un error del sistema. Son el resultado de no haber definido los tiempos de espera, los reintentos y el comportamiento cuando algo falla.

Lo que hay que tener resuelto antes de empezar

Si estás planificando esta integración, hay cuatro cosas que tienen que estar definidas antes de contratar el proyecto técnico:

El modelo maestro de datos compartido. Quién es la fuente de verdad para productos, clientes, precios. Cómo se resuelven los conflictos cuando los datos no coinciden. Quién tiene la autoridad para resolver esas inconsistencias.

Los procesos de excepción documentados. No todos — los más frecuentes y los de mayor impacto. Al menos con la lógica de negocio, aunque no con el detalle técnico.

El modelo de sincronización. Tiempo real o lotes. Qué es tiempo real y qué puede esperarse. Cuál es el comportamiento cuando la integración falla en uno de los dos sentidos.

El plan de limpieza de datos maestros. Cuándo se hace, quién lo hace, cuánto tiempo toma. Esto tiene que estar en el cronograma del proyecto, no como un prerequisito que "ya debería estar listo".

Con esas cuatro cosas definidas, el proyecto técnico tiene un alcance real. Sin ellas, el alcance es un estimado basado en supuestos que van a romperse durante la implementación.

---

Si estás evaluando este proyecto o estás en medio de uno que está frenado, el diagnóstico suele encontrar que el problema no es técnico — es de definición. El equipo técnico puede construir cualquier integración que se les pida. El problema es que nadie les dijo exactamente qué pedir.