Integración ERP-PIM: quién manda en la jerarquía del dato (y por qué la respuesta importa)
La integración ERP-PIM es una de las más determinantes de todo el ecosistema de datos de producto y, también, una de las que más frecuentemente se diseña mal.
El error casi nunca empieza en los conectores. Empieza antes: cuando nadie definió qué sistema tiene autoridad sobre cada dato.
¿Quién puede modificar el stock? ¿Dónde se corrige una descripción? ¿Qué ocurre si el ERP y el PIM tienen valores diferentes para un mismo atributo? ¿Puede el eCommerce modificar información que después vuelve al PIM?
Estas preguntas no se resuelven programando. Se resuelven definiendo propiedad, autoridad y flujo del dato antes de conectar los sistemas.
En una arquitectura ERP-PIM típica, el ERP suele gobernar la identidad operativa y los datos transaccionales del producto; el PIM gobierna su información comercial y de enriquecimiento; y los canales consumen la información preparada para publicación. Pero la verdadera regla es más precisa: cada dato debe tener una fuente autoritativa claramente definida.
¿Qué es el Golden Record en la gestión de datos de producto?
El Golden Record es la versión consolidada y confiable de un registro de datos maestros. Su objetivo es ofrecer una representación consistente del producto cuando la información procede de diferentes fuentes.
Pero, al diseñar una integración ERP-PIM, hay otra pregunta todavía más operativa: ¿qué sistema tiene autoridad sobre cada campo?
No necesariamente existe un único sistema que sea maestro de todo el producto.
La autoridad puede —y normalmente debe— repartirse según la naturaleza del dato.
Los datos operativos o transaccionales —código de artículo, costo, stock, unidad de medida o determinada información logística— suelen originarse y mantenerse en el ERP. Cambian con la operación y el PIM no debería convertirse en una fuente alternativa para modificarlos.
Los datos comerciales o de enriquecimiento —descripciones, atributos, taxonomía, imágenes, vocabulario controlado y contenido específico por canal— encuentran en el PIM una estructura mucho más adecuada para su gestión.
En una arquitectura simple, el recorrido puede resumirse así:
ERP → PIM → canales
El producto nace o adquiere su identidad operativa en el ERP, se enriquece en el PIM y desde allí se prepara y distribuye hacia eCommerce, marketplaces, portales B2B y otros destinos.
Eso no significa que todos los ecosistemas deban tener exactamente esta arquitectura. Significa que cada campo necesita una fuente de autoridad inequívoca.
¿Cómo se reparte la autoridad entre ERP, PIM y canales?
El modelo maestro-esclavo —o, en términos más actuales, de sistema autoritativo y sistemas consumidores— establece que para cada campo existe una fuente con permiso para definir su valor y otros sistemas que lo consumen.
En una integración ERP-PIM típica, la jerarquía puede organizarse en tres niveles.
1. El ERP gobierna la identidad y la operación
Código de artículo, costo, stock, unidad de medida y determinados datos logísticos o financieros suelen pertenecer al ERP.
El ERP escribe. El PIM y los sistemas que correspondan consumen.
Una corrección de stock o costo no debería realizarse en el PIM si el ERP es la fuente autoritativa, porque la siguiente sincronización puede sobrescribirla.
2. El PIM gobierna el dato comercial
Descripciones, atributos técnicos y comerciales, vocabulario controlado, taxonomía, imágenes y contenido adaptado por canal pertenecen al dominio natural del PIM.
El PIM escribe y los canales consumen.
Cuando el mismo enriquecimiento se modifica indistintamente en el ERP, el PIM y el backoffice del eCommerce, deja de existir una fuente confiable. Las inconsistencias pasan a ser una consecuencia del diseño.
3. Los canales consumen y publican
El eCommerce, los marketplaces y los portales B2B deberían consumir el dato preparado para cada destino.
Esto no significa que un canal jamás genere información propia: puede producir datos de analítica, identificadores específicos o estados particulares. Pero el canal no debería convertirse accidentalmente en maestro de los datos de producto que ya tienen una fuente autoritativa definida.
Cuando un equipo empieza a corregir manualmente las fichas en el canal porque resulta más rápido, la jerarquía se rompe.
Y el problema quizá no aparece ese día. Aparece en la próxima sincronización.
¿Y qué pasa con el precio?
El precio merece un tratamiento particular.
Puede viajar del ERP al PIM como dato informativo o referencial, dependiendo de la arquitectura. Pero el precio que efectivamente se cobra al cliente puede estar gobernado por el ERP, el eCommerce, un motor de pricing u otro sistema transaccional.
Por eso, antes de integrar el campo precio, hay que distinguir entre el precio utilizado como información de producto y el precio transaccional que interviene en la venta.
La regla vuelve a ser la misma: no asumir dónde vive la autoridad; documentarla.
Por qué los conflictos de propiedad del dato son organizacionales, no técnicos
Los conflictos de propiedad rara vez nacen en los sistemas. Nacen en el organigrama y la integración simplemente los hace visibles.
El patrón se repite con pocas variantes.
Administración considera que el producto le pertenece porque lo da de alta en el ERP. Marketing considera que le pertenece porque lo convierte en algo vendible. eCommerce considera que le pertenece porque responde por el rendimiento del canal.
Cada área termina defendiendo su versión del dato.
La disputa organizacional se materializa entonces dentro de los sistemas: campos que dos aplicaciones pueden escribir, valores que se pisan durante las sincronizaciones y equipos que no pueden determinar cuál es la versión correcta.
El resultado es conocido: enriquecimiento sobrescrito, fichas incompletas, atributos inconsistentes, filtros que dejan de funcionar y correcciones manuales que vuelven a romperse con la siguiente sincronización.
Un conector no puede resolver un conflicto de propiedad del dato. Solo puede automatizar la regla que la organización haya definido previamente.
Cómo diseñar el flujo ERP-PIM antes de conectar
En CRITERIA resolvemos esta etapa con un entregable concreto: la matriz de propiedad del dato.
1. Inventariar los campos
Primero relevamos todos los campos que van a existir en el ecosistema: los actuales del ERP, los que se crearán o enriquecerán en el PIM y los que requiere cada canal.
2. Asignar una fuente autoritativa por campo
Para cada campo se define qué sistema puede escribir o determinar el valor válido.
La regla debería ser estricta: cada campo necesita un responsable y una fuente de autoridad claramente identificados.
Si dos sistemas pueden modificar el mismo dato sin una regla de precedencia explícita, existe un conflicto en pausa.
3. Definir quién consume cada dato
Después se establece qué sistemas leen cada campo, hacia dónde viaja y qué transformaciones necesita.
Así queda documentado el recorrido completo desde el origen hasta los canales.
4. Validar la matriz entre las áreas
La matriz no debería diseñarse exclusivamente desde IT.
Administración, marketing, eCommerce, operaciones y sistemas —según la organización— necesitan acordar quién origina, modifica, valida y consume cada dato.
Ese acuerdo convierte una planilla técnica en una herramienta real de gobernanza.
5. Recién entonces, conectar
Con la matriz validada, la integración cambia de naturaleza.
Ya no hay que preguntarse durante el desarrollo qué sistema debería ganar cuando aparecen dos valores diferentes. Esa decisión ya está tomada.
Los conectores ejecutan la jerarquía; no la deciden.
Y esa matriz —el campo, quién tiene autoridad, quién lo consume y hacia dónde viaja— probablemente sea una de las reuniones más baratas de todo el proyecto.
También puede ser una de las que más problemas evita.
La jerarquía del dato se decide antes de integrar ERP y PIM
Una integración ERP-PIM no debería comenzar preguntando qué API utilizar o cada cuánto sincronizar.
Debería comenzar con una pregunta mucho más básica:
¿Quién manda sobre cada dato?
El ERP suele gobernar la información operativa y transaccional. El PIM, la información comercial y de enriquecimiento. Los canales consumen la versión preparada para su contexto. Y, cuando intervienen otros sistemas especializados, su autoridad también debe quedar documentada.
La matriz de propiedad convierte ese reparto en un acuerdo verificable.
Cuando la jerarquía está definida antes de conectar, el desarrollo implementa reglas conocidas. Cuando no lo está, la integración se convierte en una fuente permanente de datos sobrescritos, fichas inconsistentes y discusiones entre áreas que ningún conector puede resolver.
Si su empresa está por integrar un ERP con un PIM —o ya los integró y los datos se pisan en cada sincronización—, en CRITERIA podemos revisar la arquitectura y construir la matriz de propiedad antes de modificar la integración.
Agende una sesión de Discovery y revisemos primero quién debe mandar sobre cada dato.
