Cómo participo en una integración ERP-PIM: el rol del analista cuando IT está en el centro
La integración entre ERP y PIM no es solo un proyecto técnico. Hablemos de mi rol: mapeo de atributos, validación de datos de origen, definición del modelo de enriquecimiento.
Cuando se habla de una integración ERP-PIM, la conversación suele quedar rápidamente en manos del equipo de IT. Aparecen las APIs, los archivos de intercambio, las credenciales, los procesos automáticos, los entornos de prueba y los registros de errores. Todo eso es necesario, pero no alcanza.
Una integración puede mover datos de un sistema a otro sin que exista un solo error técnico y, aun así, generar productos incompletos, valores inconsistentes o registros imposibles de enriquecer. El conector funciona, pero la información no.
Ahí es donde participo como analista PIM. Mi tarea no es programar la integración, sino definir qué significa cada dato, de dónde debe obtenerse, cómo debe transformarse y qué condiciones tiene que cumplir antes de ingresar al PIM.
Me gusta entender qué mueve los engranajes de un proceso. En una integración, esos engranajes no son solamente tecnológicos: también incluyen criterios de negocio, decisiones de catalogación, responsabilidades entre equipos y reglas que muchas veces nadie documentó.
¿Cuál es el rol del analista PIM en una integración ERP-PIM?
El analista PIM funciona como un puente entre el equipo técnico y las personas que gestionan el catálogo. Su responsabilidad principal es convertir las necesidades del negocio en reglas de datos claras, verificables y suficientemente precisas para que IT pueda implementarlas.
Esto implica participar en tres momentos centrales:
- El análisis y la validación de los datos que provienen del ERP.
- El mapeo entre la estructura de origen y el modelo de datos del PIM.
- La definición del proceso de enriquecimiento que comienza después de la integración.
No necesito desarrollar el conector para intervenir activamente en el proyecto. Sí necesito comprender qué información se transporta, qué transformaciones se aplican y qué resultado debería producirse en el PIM.
Una integración puede estar técnicamente activa y seguir siendo funcionalmente incorrecta. Transportar datos no garantiza que esos datos sean útiles, consistentes o adecuados para el catálogo.
Antes de integrar, hay que decidir quién es responsable de cada dato
Una de las primeras preguntas que aparecen es cuál de los dos sistemas “manda”. La respuesta más útil no suele ser elegir entre el ERP o el PIM como dueño absoluto de toda la información.
En una arquitectura bien definida, cada dato tiene una fuente autorizada.
El ERP suele concentrar la información operativa y administrativa del producto: códigos internos, identificadores, relación con proveedores, unidades logísticas, estados comerciales o datos necesarios para compras y abastecimiento.
El PIM se ocupa de estructurar, enriquecer y preparar la información que necesitan los canales de venta: nombres comerciales, descripciones, atributos técnicos, categorías, imágenes, documentos, traducciones y contenidos específicos para cada destino.
Esta separación no es universal. Depende de la arquitectura de cada empresa, de los sistemas involucrados y del flujo de creación de productos. Sin embargo, hay una regla que siempre intento dejar clara: un mismo campo no debería ser modificado libremente en dos sistemas distintos sin una política de sincronización.
Cuando nadie sabe cuál es la fuente autorizada de un dato, comienzan los conflictos. Un usuario corrige el nombre en el PIM, otro lo modifica en el ERP y la siguiente sincronización sobrescribe uno de los cambios. El problema no está en la integración, sino en la falta de una decisión previa sobre la propiedad de la información.
Mi trabajo comienza con los datos que existen, no con los que suponemos que existen
Antes de diseñar el mapeo, necesito conocer el contenido real del ERP. No alcanza con revisar una lista ideal de campos o un documento preparado para la reunión inicial.
Pido exportaciones, ejemplos de productos y muestras representativas del catálogo. Necesito ver cómo se completan los campos en la práctica, qué valores llegan vacíos, cómo se identifican las variantes y qué diferencias existen entre familias de producto.
En esta etapa suelo analizar:
- Qué identificador permite reconocer un producto de forma estable.
- Qué campos están completos y cuáles tienen valores parciales.
- Qué unidades de medida se utilizan.
- Cómo se representan categorías, marcas, proveedores y variantes.
- Qué valores se cargan mediante listas controladas y cuáles se escriben libremente.
- Qué reglas de negocio existen, aunque todavía no estén documentadas.
También reviso excepciones. Los productos que siguen perfectamente el modelo suelen ser los más fáciles de integrar. Los problemas aparecen en registros discontinuados, códigos históricos, productos sin categoría, variantes incompletas o artículos creados con criterios anteriores.
Una muestra demasiado limpia puede ocultar la complejidad real. Por eso prefiero trabajar con registros habituales, casos conflictivos y productos que hayan generado problemas anteriormente.
¿Qué datos suelen venir del ERP y cuáles se enriquecen en el PIM?
La frontera entre ambos sistemas debe definirse para cada proyecto, pero existe una separación orientativa que ayuda a iniciar la conversación.
Del ERP pueden provenir datos como:
- SKU o código interno.
- Código de proveedor.
- Marca registrada en el sistema operativo.
- Unidad de medida.
- Dimensiones o peso logístico.
- Estado de alta, baja o discontinuación.
- Relaciones básicas entre productos y variantes.
En el PIM suelen incorporarse o completarse:
- Nombre comercial.
- Descripción corta y larga.
- Familia de atributos.
- Categorías de navegación.
- Especificaciones orientadas al comprador.
- Vocabularios controlados.
- Imágenes, documentos y otros activos digitales.
- Traducciones y adaptaciones por canal.
- Relaciones de productos complementarios o alternativos.
El ERP puede crear el registro inicial, pero eso no significa que el producto ya esté listo para publicarse. El alta operativa y la publicación comercial son momentos distintos del ciclo de vida del dato.
En algunos proyectos, por ejemplo, el ERP envía mediante un archivo los datos comerciales básicos necesarios para crear el producto. Luego, el equipo trabaja en el PIM para asignar su familia, completar los atributos, incorporar imágenes y aprobar la información antes de enviarla al eCommerce.
La integración no reemplaza ese proceso de enriquecimiento. Lo inicia.
Mapear atributos no es copiar columnas de un sistema a otro
El mapeo de datos define la correspondencia entre los campos del sistema de origen y los atributos del sistema de destino. A simple vista, puede parecer una tabla donde una columna del ERP se vincula con un atributo del PIM.
En la práctica, casi nunca es tan directo.
Un campo puede contener más de un dato. Un valor puede necesitar una transformación. Una unidad puede tener que convertirse. Un atributo de texto libre puede necesitar convertirse en una lista controlada. Dos campos del ERP pueden combinarse para generar un único valor en el PIM.
También puede ocurrir lo contrario: un solo campo de origen debe separarse en varios atributos para que la información pueda utilizarse correctamente en búsquedas, filtros o fichas técnicas.
Por ejemplo, un campo llamado “Medidas” podría contener el texto “80 x 40 x 15 cm”. Para una lectura humana, el valor parece suficiente. Para un PIM, puede ser necesario separarlo en alto, ancho, profundidad y unidad de medida.
El mapeo debe explicar no solo de dónde sale el dato, sino también:
- Qué tipo de campo lo recibe.
- Qué transformación necesita.
- Qué valores son válidos.
- Qué ocurre cuando llega vacío.
- Qué sistema puede modificarlo.
- Si el valor se hereda, se calcula o se completa manualmente.
- En qué canales se utilizará.
El analista no programa el conector. Define qué significa cada dato y cuál debería ser su comportamiento para que el equipo técnico pueda construir una integración correcta.
La validación del origen evita automatizar errores
Una integración automatiza un flujo. Si los datos de origen son correctos, la automatización reduce tareas manuales y mejora la consistencia. Si son incorrectos, la automatización distribuye el problema con mayor velocidad.
Por eso, antes de aprobar el ingreso de información, reviso la calidad del origen.
No se trata de exigir que todo el ERP esté perfectamente normalizado antes de comenzar. En muchos casos, eso sería poco realista. Se trata de identificar qué problemas pueden afectar al modelo del PIM y decidir dónde deben resolverse.
Algunas inconsistencias pueden corregirse en el sistema de origen. Otras requieren una regla de transformación durante la integración. También existen datos que deben llegar al PIM para ser revisados por una persona.
La decisión depende de la naturaleza del problema.
Un error en el identificador principal no debería resolverse manualmente después de cada importación. Una abreviatura comercial, en cambio, puede transformarse automáticamente. Un dato técnico ausente quizás deba quedar pendiente dentro del flujo de enriquecimiento.
La validación también sirve para evitar falsas equivalencias. Dos valores parecidos no siempre representan lo mismo. Antes de unificarlos, necesito confirmar su significado con quienes conocen el producto o el proceso operativo.
Automatizar un dato incorrecto no mejora el proceso. Solo hace que el error llegue más rápido y a más sistemas.
El producto no termina de construirse cuando ingresa al PIM
Una vez que el ERP crea o actualiza el producto, comienza el trabajo de enriquecimiento. Esta etapa debe estar contemplada desde el diseño de la integración.
El registro puede necesitar una familia de producto para determinar qué atributos debe completar. También puede requerir una categoría, una marca normalizada, relaciones con variantes o la incorporación de imágenes y documentos.
El modelo de enriquecimiento define qué ocurre desde el momento en que el dato ingresa hasta que el producto queda aprobado para un canal.
En algunos casos, el flujo es relativamente simple: el producto llega, se completa y se publica. En otros, intervienen varias áreas. Ingeniería agrega especificaciones técnicas, marketing redacta las descripciones, el equipo de producto valida la clasificación y una persona responsable aprueba la publicación.
Como analista, necesito ayudar a responder preguntas operativas:
- ¿Con qué información mínima puede crearse un producto?
- ¿Qué atributos son obligatorios para cada familia?
- ¿Quién completa cada grupo de datos?
- ¿Qué condiciones debe cumplir el producto para publicarse?
- ¿Qué ocurre si el ERP modifica un registro que ya fue enriquecido?
- ¿Cómo se tratan los productos dados de baja o discontinuados?
Estas preguntas no son posteriores a la integración. Forman parte de su diseño.
Cómo trabajo con IT sin tener que programar el conector
El trabajo con IT funciona mejor cuando los requisitos no dependen de interpretaciones. Decir que “el producto debe llegar completo” no es una especificación. Necesitamos definir qué significa completo, para qué producto, en qué momento y según qué canal.
Los principales entregables que preparo o ayudo a construir son el diccionario de datos, la matriz de mapeo, las reglas de transformación, los criterios de validación y los casos de prueba.
El diccionario explica qué representa cada atributo. La matriz indica de dónde proviene, cómo se transforma y dónde se almacena. Las reglas determinan qué valores se aceptan. Los casos de prueba permiten comprobar si la integración se comporta como fue acordado.
También aporto ejemplos reales. Un desarrollador puede implementar correctamente una regla mal definida. Cuanto más concreto sea el ejemplo, menor será el espacio para interpretaciones.
IT necesita saber qué debe hacer el sistema. El equipo de catálogo necesita entender qué implicancias tendrá ese comportamiento sobre su trabajo cotidiano. Mi función consiste en mantener conectadas ambas perspectivas.
Las pruebas deben reproducir situaciones reales del catálogo
No considero validada una integración porque un producto haya viajado correctamente desde el ERP hasta el PIM. Ese es apenas el primer caso.
Antes de aprobar el flujo, pruebo diferentes situaciones: altas, actualizaciones, campos vacíos, datos inválidos, cambios de estado, duplicados y productos con estructuras especiales.
También verifico qué sucede cuando un proceso falla a mitad de camino. El sistema debe poder informar el error, evitar duplicaciones y recuperar el flujo sin comprometer los registros que ya fueron procesados.
Las variantes requieren atención especial. Es necesario comprobar que se mantenga correctamente la relación entre el producto padre y sus hijos, que los atributos comunes no se dupliquen sin necesidad y que los valores diferenciadores lleguen al nivel adecuado.
Después reviso el resultado desde la perspectiva del usuario del PIM. El producto puede haberse creado técnicamente, pero ¿quedó en la familia correcta? ¿Los campos son editables? ¿Los valores pueden filtrarse? ¿El equipo entiende qué debe completar?
Una prueba de integración no termina cuando el sistema responde correctamente. Termina cuando el dato puede utilizarse sin generar trabajo manual innecesario ni nuevas inconsistencias.
Lo que aprendí en proyectos reales de integración ERP-PIM
En un proyecto B2B de materiales para la construcción, el alta de productos llegaba desde el ERP mediante un archivo con información comercial básica. El PIM recibía esos registros y funcionaba como espacio de enriquecimiento antes de enviar los datos hacia la plataforma de comercio electrónico.
Además del flujo automático, existía una planilla de carga para completar información que todavía no estaba disponible en el ERP. Esto no significaba que la integración estuviera incompleta. Significaba que cada herramienta cumplía una función específica dentro del proceso.
En otro proyecto, correspondiente a un grupo multimarca, el modelo de datos debía contemplar varios destinos: ERP, eCommerce, punto de venta, un sistema de asignación de identificadores, un marketplace y un catálogo generado con herramientas editoriales.
El desafío no era solamente conectar todos esos sistemas. Primero había que determinar qué información requería cada salida, cuál era su fuente y cómo debía representarse en cada contexto.
Estos proyectos me confirmaron algo que se repite con bastante frecuencia: cuanto más complejo es el ecosistema, más importante es documentar el significado del dato antes de discutir cómo transportarlo.
El rol del analista continúa después de salir a producción
La salida a producción no convierte la integración en un proceso terminado. Los modelos cambian, aparecen nuevos atributos, se incorporan canales y el ERP puede modificar estructuras que parecían estables.
El analista necesita observar el comportamiento del flujo, revisar errores recurrentes y detectar si las excepciones empiezan a convertirse en una nueva regla.
También debe participar cuando cambian los procesos internos. Si el equipo comienza a crear productos de otra manera, la integración puede dejar de representar correctamente el ciclo de vida de la información, aunque siga funcionando desde el punto de vista técnico.
Por eso considero que una integración necesita gobierno. Alguien debe revisar los cambios, mantener la documentación y validar que las decisiones originales todavía tengan sentido.
El analista PIM no reemplaza al desarrollador ni decide en soledad cómo debe funcionar el negocio. Su valor está en traducir entre ambos mundos: transformar procesos, necesidades y excepciones en reglas de datos claras. Cuando esa traducción está bien hecha, la integración deja de ser un simple traslado de registros y se convierte en una parte confiable del ecosistema de información de producto.
