Qué datos vienen del ERP y cuáles le corresponden al PIM: una separación que parece obvia (y no lo es)
Una guía conceptual para entender qué información pertenece a cada sistema y cómo trazar la línea entre el dato de compra y el dato de venta.
Cuando hablamos de integrar un ERP con un PIM, la primera explicación suele parecer bastante sencilla: el ERP envía los datos básicos del producto y el PIM los enriquece para publicarlos en los canales de venta.
La idea es correcta, pero incompleta. En cuanto empezamos a revisar los campos reales de un catálogo, la separación deja de ser tan clara.
¿Dónde debería crearse el nombre del producto? ¿Quién administra sus dimensiones? ¿El precio pertenece al ERP, al PIM o al eCommerce? ¿Qué ocurre con las categorías, el estado de publicación o las especificaciones técnicas? ¿Y si dos áreas necesitan versiones diferentes del mismo dato?
La respuesta no consiste en decidir si «manda» el ERP o el PIM. La propiedad debe definirse campo por campo, según la función del dato, quién lo mantiene y qué procesos dependen de él.
Un ERP y un PIM pueden contener información sobre el mismo producto, pero no la utilizan para lo mismo. El ERP necesita reconocerlo para comprarlo, fabricarlo, almacenarlo, facturarlo o contabilizarlo. El PIM necesita describirlo, organizarlo y prepararlo para que una persona pueda encontrarlo, entenderlo y decidir si quiere comprarlo.
Podemos pensarlo como la diferencia entre la ficha interna de una biblioteca y la información que aparece en la contratapa de un libro. Ambas hablan de la misma obra, pero responden preguntas diferentes.
El ERP administra la operación
Un ERP, sigla de Enterprise Resource Planning, conecta procesos centrales de la empresa, como compras, finanzas, inventario, producción, logística y ventas. Su lógica está orientada a que la organización pueda operar, controlar recursos y registrar transacciones.
Dentro de ese contexto, el producto es principalmente una entidad operativa. El ERP necesita saber qué código lo identifica, quién lo provee, cuánto cuesta, dónde se almacena, cuántas unidades hay disponibles, qué impuestos se le aplican y cómo interviene en una orden de compra, una factura o un movimiento de inventario.
Entre los datos que suelen nacer o mantenerse en el ERP encontramos:
- SKU o código interno;
- proveedor;
- costo de compra;
- moneda;
- unidad de compra;
- unidad de almacenamiento;
- condiciones comerciales;
- datos fiscales y contables;
- almacén;
- stock;
- estado operativo;
- cantidades por caja o paquete;
- dimensiones logísticas.
Son datos fundamentales para el funcionamiento de la empresa, pero no todos deberían llegar a una ficha de producto.
Un cliente no necesita conocer el costo interno de adquisición, la cuenta contable vinculada al artículo ni el plazo acordado con el proveedor. Esa información pertenece al funcionamiento del negocio y debería permanecer en el back office.
El ERP administra el producto como parte de la operación. El PIM lo prepara para que pueda ser comprendido, encontrado y vendido.
El PIM administra la comprensión del producto
El PIM, sigla de Product Information Management, se concentra en recopilar, organizar, enriquecer y distribuir información de producto hacia distintos canales.
Su pregunta principal no es «¿cómo procesamos este artículo dentro de la empresa?», sino «¿qué información necesita una persona para entenderlo y elegirlo?».
Por eso, en el PIM suelen gestionarse:
- nombres comerciales;
- descripciones cortas y largas;
- beneficios;
- atributos técnicos publicables;
- categorías de navegación;
- variantes;
- imágenes y documentos;
- palabras clave;
- relaciones entre productos;
- traducciones;
- contenido específico por canal;
- reglas de completitud;
- estados de enriquecimiento y aprobación.
El PIM recibe parte de la información operativa, pero no se limita a copiarla. La combina con datos técnicos, comerciales, editoriales y visuales para construir una ficha adecuada para cada destino. Esa capacidad de enriquecimiento y contextualización es justamente una de las diferencias centrales respecto de un ERP.
Una tienda online puede necesitar una descripción extensa y fotografías. Un marketplace puede exigir un título con determinada estructura. Un portal B2B puede priorizar especificaciones y fichas técnicas. Un catálogo impreso puede necesitar textos más breves y una selección específica de atributos.
El producto es el mismo. La representación cambia según el canal y la necesidad del comprador.
¿Qué diferencia existe entre el dato de compra y el dato de venta?
Una forma práctica de comenzar a separar responsabilidades es distinguir entre dato de compra y dato de venta.
El dato de compra describe lo que la empresa necesita conocer para incorporar, almacenar y administrar un artículo. El dato de venta describe lo que el comprador necesita conocer para evaluarlo.
Supongamos que una empresa incorpora una licuadora a su catálogo.
Para comprarla y almacenarla necesita saber:
- código interno;
- proveedor;
- costo;
- moneda de compra;
- unidades por caja;
- peso logístico;
- dimensiones del embalaje;
- cantidad disponible;
- almacén asignado;
- condiciones de reposición.
Para venderla necesita explicar:
- nombre comercial;
- potencia;
- capacidad;
- materiales;
- funciones;
- cantidad de velocidades;
- accesorios incluidos;
- instrucciones de uso;
- garantía;
- beneficios;
- fotografías;
- diferencias respecto de otros modelos.
No son dos productos distintos. Son dos miradas sobre el mismo producto.
El ERP administra la mirada operativa. El PIM construye la mirada comercial.
El dato de compra permite que la empresa gestione el producto. El dato de venta permite que el comprador lo entienda y lo compare.
¿Qué sistema debería ser maestro de cada dato?
La siguiente tabla sirve como punto de partida. No es una regla universal: la arquitectura concreta depende de los procesos y sistemas de cada organización.
| Tipo de información | Sistema maestro más frecuente | Motivo |
|---|---|---|
| SKU o código interno | ERP | Identifica el artículo en procesos operativos y transaccionales. |
| Proveedor | ERP | Interviene en compras y abastecimiento. |
| Costo | ERP | Es información financiera y operativa. |
| Stock | ERP o sistema de inventario | Cambia con las operaciones y requiere actualizaciones frecuentes. |
| Precio de venta | ERP, motor de precios o eCommerce | Puede depender del cliente, el canal, la región o una promoción. |
| Nombre comercial | PIM | Debe adaptarse al comprador, al idioma y al canal. |
| Descripciones | PIM | Forman parte del enriquecimiento comercial y editorial. |
| Categorías de navegación | PIM | Organizan la búsqueda y la encontrabilidad del producto. |
| Especificaciones técnicas | PIM, ERP o PLM | El origen puede ser técnico, pero el PIM prepara la versión publicable. |
| Imágenes y documentos | PIM o DAM | Son activos destinados a comunicar el producto. |
| Relaciones de venta cruzada | PIM | Responden a una estrategia comercial. |
| Estado contable | ERP | Pertenece a la operación interna. |
| Estado de enriquecimiento | PIM | Indica si la ficha está completa y lista para publicarse. |
| Estado de publicación | PIM o canal | Depende del flujo de aprobación y distribución. |
La columna más importante no es la que indica el sistema, sino la que explica el motivo.
No deberíamos decidir la propiedad de un campo porque «siempre se hizo así». Tenemos que observar qué función cumple, quién puede validarlo y qué proceso lo mantiene actualizado.
Los campos que generan más conflictos entre el ERP y el PIM
Algunos datos parecen simples hasta que intentamos definir su dueño. Suelen aparecer en varios sistemas, pero eso no significa que todos deban poder modificarlos.
El nombre del producto
El ERP puede necesitar una denominación breve, limitada por cantidad de caracteres o construida según una convención interna:
LIC VASO 1,5 L 800 W NG MOD 450
Ese texto puede ser suficiente para una orden de compra o una consulta de inventario. Para una tienda online, en cambio, necesitamos algo más cercano a:
Licuadora de vaso de 1,5 litros y 800 W, modelo 450, color negro
Ambos nombres son válidos dentro de su contexto.
La solución no consiste en obligar al ERP a escribir títulos comerciales ni en reemplazar el nombre operativo. Consiste en crear dos atributos con funciones diferenciadas:
- denominación operativa;
- nombre comercial.
El primero puede originarse en el ERP y mantenerse bloqueado en el PIM. El segundo puede crearse y administrarse en el PIM.
Las dimensiones
Las dimensiones también parecen un dato objetivo, pero pueden describir realidades diferentes:
- dimensiones del producto;
- dimensiones del producto armado;
- dimensiones del empaque individual;
- dimensiones de la caja máster;
- dimensiones para transporte;
- dimensiones publicables en la ficha comercial.
Si utilizamos un único campo llamado «alto», tarde o temprano alguien cargará la altura del embalaje donde otro equipo esperaba la altura del producto.
Antes de discutir qué sistema manda, tenemos que definir qué estamos midiendo.
Las dimensiones logísticas suelen pertenecer al ERP. Las dimensiones físicas publicables pueden provenir del ERP, del PLM, del proveedor o de un equipo técnico y consolidarse en el PIM. Cada campo debería tener una definición, una unidad y un responsable claros.
El precio
Decir que «el precio está en el ERP» puede ser correcto, pero sigue siendo demasiado general.
Una empresa puede manejar precio de lista, precio mayorista, precio promocional, precio por cliente, precio por región, precio sugerido o precio específico de un marketplace.
El PIM puede almacenar un precio de referencia o distribuir determinados valores, pero normalmente no debería convertirse en un motor transaccional de precios. Cuando el valor cambia según el cliente, una promoción, una condición comercial o la disponibilidad, suele administrarse desde el ERP, un sistema de pricing o la plataforma de comercio.
El PIM sí puede gestionar información relacionada con la presentación del precio, como una leyenda comercial, una condición visible o el contenido que acompaña una promoción.
Las categorías
Las categorías del ERP suelen responder a necesidades internas: compras, reportes, líneas de negocio, administración de inventario o criterios fiscales.
Las categorías del PIM pueden responder a otras lógicas:
- navegación del eCommerce;
- clasificación técnica;
- campañas;
- estructura de un catálogo impreso;
- requisitos de un marketplace;
- organización por audiencia o región.
Por eso, la categoría interna del ERP no debería transformarse automáticamente en el menú de la tienda.
Una cosa es cómo la empresa organiza su operación. Otra es cómo el comprador busca.
Antes de asignar un campo al ERP o al PIM, hay que definir qué significa. Muchos conflictos de integración son, en realidad, conflictos de interpretación.
Que un dato esté en el PIM no significa que le pertenezca
Esta diferencia es importante: un campo puede estar visible dentro del PIM sin que el PIM sea su sistema maestro.
El stock puede llegar al PIM para aplicar reglas de publicación. Por ejemplo, podríamos impedir que se distribuya un producto sin disponibilidad. Sin embargo, el valor debería seguir actualizándose desde el ERP o el sistema de inventario.
Lo mismo ocurre con el costo, el proveedor o el código interno. El PIM puede necesitarlos para filtrar productos, validar registros o construir automatizaciones, pero eso no significa que los usuarios deban editarlos allí.
Para ordenar esta situación conviene diferenciar tres conceptos:
- Sistema de origen: lugar donde nace el dato.
- Sistema maestro: lugar donde reside su versión oficial.
- Sistema consumidor: lugar donde el dato se utiliza para realizar otra tarea.
A veces los tres roles recaen en una sola plataforma. En otros casos, un dato nace en un sistema, se valida en otro y se consume en varios más.
La propiedad del dato debe definirse atributo por atributo
En una integración bien diseñada, no debería existir una respuesta general a la pregunta «¿quién manda, el ERP o el PIM?».
La pregunta correcta es:
¿Qué sistema manda sobre este atributo concreto?
Podemos documentar la respuesta mediante una matriz sencilla:
| Atributo | Origen | Sistema maestro | Quién lo edita | Frecuencia | Destinos |
|---|---|---|---|---|---|
| SKU | ERP | ERP | Administración | Al crear el producto | PIM, eCommerce, POS |
| Stock | ERP | ERP | Operaciones automáticas | Varias veces al día | eCommerce |
| Nombre comercial | PIM | PIM | Contenido | Cuando cambia la ficha | Web, marketplace, catálogo |
| Descripción larga | PIM | PIM | Marketing o contenido | Según el canal | Web y marketplaces |
| Costo | ERP | ERP | Compras | Según el proveedor | Reportes internos |
| Categoría web | PIM | PIM | Equipo de catálogo | Según la navegación | eCommerce |
| Imagen principal | DAM o PIM | DAM o PIM | Contenido | Según la producción visual | Todos los canales |
Esta matriz evita dos problemas frecuentes: que nadie se haga responsable de un campo o que dos sistemas intenten sobrescribirlo.
¿Qué ocurre cuando un dato no tiene un dueño claro?
Cuando no existe una política de propiedad, aparecen situaciones bastante conocidas:
- marketing corrige un nombre en el eCommerce, pero la siguiente sincronización vuelve a colocar el texto del ERP;
- operaciones modifica una dimensión logística y reemplaza accidentalmente la medida visible para el cliente;
- el PIM actualiza un campo que después es sobrescrito por una importación automática;
- dos sistemas crean identificadores diferentes para el mismo artículo;
- un canal publica datos antiguos porque nadie definió la frecuencia de sincronización;
- un equipo deja de corregir errores porque sabe que sus cambios no sobrevivirán a la próxima actualización.
En apariencia, son fallas técnicas. En realidad, muchas empiezan como una falta de acuerdo sobre quién es responsable del dato.
Cuando dos sistemas pueden modificar el mismo atributo sin una regla de prioridad, la integración no sincroniza información: multiplica conflictos.
Un caso real de separación entre información operativa y comercial
En uno de los proyectos de CRITERIA con una empresa industrial B2B, el ERP enviaba los productos nuevos mediante un archivo, junto con sus datos comerciales básicos.
Una vez creada el alta, el equipo completaba en el PIM las especificaciones técnicas, las descripciones y los materiales necesarios para los canales de salida. Desde allí, la información enriquecida se distribuía hacia un sitio B2B y se preparaba para alimentar un catálogo diseñado en InDesign.
El ERP no tuvo que convertirse en una plataforma editorial. El PIM tampoco tuvo que asumir la gestión de compras, inventario o facturación.
Cada sistema mantuvo su especialidad y la integración funcionó como un puente entre ambas miradas.
Este tipo de flujo permite que un producto nazca con su información operativa y avance después por un proceso de enriquecimiento antes de publicarse. El alta y la venta no tienen que ocurrir al mismo tiempo: entre ambas existe una etapa de preparación que debe estar definida.
¿Cómo debería organizarse un flujo ERP-PIM?
Aunque cada empresa necesita diseñar su propio modelo, un flujo habitual puede organizarse de la siguiente manera:
- El producto se crea en el ERP. Se asignan su código, proveedor, unidad de compra y datos operativos iniciales.
- La integración detecta el alta. Una API, un archivo o un middleware transforma y envía los campos necesarios.
- El producto se crea en el PIM. Los identificadores operativos se conservan y se agregan categorías, familias y atributos comerciales.
- Los equipos enriquecen la ficha. Se incorporan descripciones, imágenes, especificaciones, relaciones y contenido localizado.
- El PIM valida la preparación por canal. No todos los destinos exigen los mismos atributos ni la misma versión del contenido.
- La información se distribuye. El eCommerce, los marketplaces, los portales B2B o los catálogos reciben la representación que les corresponde.
- Los datos dinámicos continúan actualizándose desde su maestro. El stock, el precio o el estado operativo pueden viajar por flujos separados y con mayor frecuencia.
No todo tiene que sincronizarse al mismo ritmo. Una descripción puede cambiar unas pocas veces al año; el stock, varias veces durante un mismo día.
Intentar procesar ambos tipos de información mediante el mismo flujo suele agregar complejidad innecesaria.
¿Qué preguntas hay que responder antes de construir la integración?
Antes de desarrollar un conector, conviene preparar una planilla de atributos y responder para cada uno:
- ¿Qué significa exactamente este campo?
- ¿Dónde nace?
- ¿Quién lo valida?
- ¿Cuál es su versión oficial?
- ¿Quién puede editarlo?
- ¿Con qué frecuencia cambia?
- ¿Qué sistemas lo necesitan?
- ¿Debe viajar en una o en ambas direcciones?
- ¿Qué sucede si llega vacío?
- ¿Qué sistema tiene prioridad si existen valores diferentes?
- ¿Necesita transformarse antes de publicarse?
- ¿Es información interna o puede verla el comprador?
Estas preguntas pueden parecer menos interesantes que hablar de APIs, automatizaciones o conectores, pero resuelven una parte enorme del proyecto.
Conectar sistemas sin definir el dato es como organizar una imprenta sin decidir qué versión del manuscrito vamos a imprimir: podemos tener máquinas excelentes y, aun así, producir miles de copias del archivo equivocado.
El objetivo de integrar un ERP con un PIM no es conseguir que ambos hagan lo mismo, sino permitir que cada sistema haga bien el trabajo para el que fue pensado. El ERP organiza el dato que permite operar; el PIM lo transforma y lo completa para ayudar a vender. Cuando esa línea queda definida atributo por atributo, los equipos saben dónde corregir, los cambios dejan de sobrescribirse y el catálogo puede crecer sin que cada actualización se convierta en una discusión.
