Lo que el analista PIM necesita entender sobre integraciones (sin tener que saber programar)
No necesito saber código para participar activamente en un proyecto de integración. Sí necesito entender cómo viajan los datos, qué reglas se aplican durante el recorrido, qué sistema responde por cada campo y cómo comprobar que el resultado final es correcto.
Cuando empecé a participar en conversaciones sobre integraciones, algunos términos parecían pertenecer a un territorio reservado para desarrolladores: API, endpoint, payload, autentificación, webhook, procesamiento por lotes, registros de error.
Mi primera reacción era bastante lógica: “Esto lo resuelve IT”.
Con el tiempo entendí que una integración PIM no es solamente una pieza de software. Es un proceso mediante el cual la información de producto sale de un sistema, atraviesa una serie de reglas y llega a otro sistema con una estructura determinada. En ese recorrido, el conocimiento del catálogo es tan importante como el código que mueve los datos.
No necesito programar un conector entre Akeneo y Adobe Commerce, entre Plytix y Shopify o entre Sales Layer y VTEX. Pero sí necesito explicar qué productos deben viajar, qué atributos corresponden a cada entidad, qué transformaciones son válidas, qué errores deben bloquear la publicación y qué resultado espera el negocio.
El desarrollador construye el puente técnico. El analista PIM ayuda a definir qué debe cruzarlo, en qué dirección y bajo qué condiciones.
No hace falta escribir código para participar en una integración PIM. Hace falta comprender el dato lo suficiente como para detectar cuándo el código está moviendo algo incorrecto.
¿Qué necesita entender un analista PIM sobre integraciones?
Un analista PIM necesita comprender cinco aspectos fundamentales:
- Qué sistemas participan y qué responsabilidad tiene cada uno.
- Cómo se identifican, mapean y transforman los datos.
- Cuándo y en qué dirección se mueve la información.
- Qué validaciones y controles necesita el flujo.
- Cómo se prueba y se monitorea el resultado.
No hace falta conocer la sintaxis de un lenguaje de programación ni desarrollar una API. Lo necesario es poder reconstruir el recorrido de la información y conversar con el equipo técnico sin perder de vista el significado del dato.
Una integración puede funcionar perfectamente desde el punto de vista técnico y publicar una categoría equivocada, una imagen correspondiente a otra variante o una medida en una unidad incorrecta.
Por eso, conexión técnica y calidad de datos no son lo mismo.
¿Qué es realmente una integración PIM?
Una integración PIM es un flujo controlado de información entre el PIM y uno o varios sistemas.
Puede conectar:
- Un ERP con el PIM para crear productos y enviar datos operativos.
- El PIM con un eCommerce para publicar contenido enriquecido.
- El PIM con marketplaces para adaptar y distribuir fichas.
- Un DAM con el PIM para relacionar activos digitales.
- El PIM con un punto de venta o portal B2B.
- El PIM con InDesign para generar catálogos impresos.
- El PIM con una plataforma de sindicación como Producteca.
Por ejemplo, un ERP puede enviar el SKU y ciertos datos básicos. El PIM recibe ese registro, lo clasifica, lo enriquece y le agrega atributos, descripciones e imágenes. Después, una integración prepara la versión que necesita Shopify, VTEX, Commercetools, Mercado Libre o cualquier otro destino.
- Microsoft Dynamics 365 puede enviar al PIM el SKU y ciertos datos operativos.
- Sales Layer puede enriquecer ese producto con descripciones, atributos e imágenes.
- Commercetools puede recibir la versión preparada para un portal B2B.
- InDesign puede recibir los campos necesarios para generar un catálogo impreso.
Desde el punto de vista técnico, ese recorrido puede resolverse mediante una API, un conector, un archivo CSV, un middleware o una combinación de mecanismos.
Desde mi lugar, necesito poder responder cuatro preguntas:
¿Qué dato sale? ¿De qué sistema sale? ¿Qué ocurre durante el recorrido? ¿Cómo debería llegar al destino?
Si no puedo responderlas, resulta difícil validar si la integración hace lo que debería.
Una conexión activa no garantiza una integración correcta. Dos sistemas pueden comunicarse sin errores técnicos y, aun así, intercambiar categorías equivocadas, valores incompletos o imágenes vinculadas con otra variante.
¿Qué sistemas participan y qué responsabilidad tiene cada uno?
Antes de hablar de campos, conectores o frecuencia de actualización, necesito comprender el ecosistema.
En una arquitectura habitual, las responsabilidades podrían distribuirse de esta manera:
| Sistema | Responsabilidad habitual |
|---|---|
| ERP | SKU, datos logísticos, inventario y otros datos operativos |
| PIM | Atributos, categorías, descripciones, relaciones y contenido enriquecido |
| DAM | Gestión de imágenes, videos, documentos y versiones de activos |
| eCommerce | Presentación del catálogo y experiencia de compra |
| Marketplace | Publicación bajo requisitos y taxonomías propias |
| POS | Información necesaria para identificar y vender el producto |
| Plataforma de sindicación | Adaptación y distribución hacia diferentes canales |
Esta distribución no es automática ni universal. Cada empresa organiza sus sistemas de una manera diferente.
Por eso, una de las primeras preguntas que hago es: ¿qué sistema tiene autoridad sobre cada dato?
El SKU puede nacer en el ERP. La descripción comercial puede pertenecer al PIM. El precio puede venir de un sistema de comercio. Las fotografías pueden administrarse en un DAM. El eCommerce debería recibir esos datos, pero no necesariamente convertirse en una fuente paralela desde la cual se corrigen.
Cuando dos sistemas pueden modificar el mismo campo sin una regla clara, aparece una pregunta inevitable: ¿qué versión debe prevalecer?
Una integración no empieza con una API. Empieza cuando se define qué sistema manda sobre cada parte de la información.
¿Qué significa y qué diferencia hay entre un flujo unidireccional y uno bidireccional?
Una integración unidireccional mueve información en un solo sentido.
Por ejemplo:
ERP → PIM
El ERP crea el producto con sus datos básicos y el PIM lo recibe para enriquecerlo.
Otro caso podría ser:
PIM → Shopify
El PIM envía la información preparada para la tienda, pero Shopify no devuelve cambios sobre esos mismos campos.
Una integración bidireccional permite que los datos viajen en ambos sentidos. Puede parecer una opción más completa, pero también aumenta la cantidad de conflictos posibles.
Imaginemos que el nombre comercial se modifica en el PIM y, poco después, alguien cambia ese mismo nombre en Shopify. La integración necesita saber qué dato conservar, cuál sobrescribir y si alguno debe regresar al sistema anterior.
Por eso no asumo que una integración bidireccional es mejor. Antes pregunto:
- ¿Qué datos necesitan regresar?
- ¿Por qué deben regresar?
- ¿Quién puede modificarlos?
- ¿Cuál es el sistema con autoridad?
- ¿Qué ocurre si ambos sistemas cambian el valor?
- ¿Cómo se registran los conflictos?
Una sincronización en dos sentidos sin reglas de propiedad puede crear más problemas de los que resuelve. En muchos proyectos, un flujo unidireccional bien gobernado es más seguro que una bidireccionalidad mal definida.
¿Qué son una API, un conector y un middleware?
No necesito desarrollar estas piezas, pero sí distinguir qué función cumple cada una.
¿Qué es una API?
Una API es un conjunto de reglas que permite que dos sistemas intercambien información.
Puedo pensarla como una puerta controlada. No deja entrar ni salir cualquier dato: define qué operaciones están disponibles, qué estructura debe enviarse y qué respuesta devolverá el sistema.
Una API puede permitir, por ejemplo:
- Consultar productos.
- Crear categorías.
- Actualizar atributos.
- Agregar activos.
- Desactivar registros.
- Recuperar estados o errores.
Plataformas como Akeneo, Plytix, Sales Layer, Shopify, VTEX y Adobe Commerce ofrecen APIs para trabajar con distintas entidades del catálogo.
¿Qué es un conector?
Un conector es una solución preparada para comunicar dos plataformas concretas.
Un conector entre Plytix y Shopify puede traer resueltas ciertas operaciones habituales, como crear productos o enviar imágenes. Sin embargo, eso no significa que el proyecto funcione sin configuración.
Todavía hay que decidir:
- Qué productos se enviarán.
- Qué campos se mapearán.
- Cómo se representarán las variantes.
- Qué ocurre con los productos discontinuados.
- Qué reglas se aplican durante una actualización.
¿Qué es un middleware?
Un middleware es una capa intermedia que recibe, transforma, valida y dirige datos entre sistemas.
Puede tomar información de un ERP, adaptarla y enviarla al PIM. También puede recibir datos del PIM y distribuir versiones diferentes hacia el eCommerce, un marketplace y un punto de venta.
Cuando hay muchos sistemas, esta capa evita que cada plataforma tenga que conectarse directamente con todas las demás.
Un conector puede traer parte del camino construido. No trae resueltas las decisiones sobre el catálogo, la propiedad del dato ni las reglas del negocio.
¿Qué es un mapeo de datos y por qué necesita al analista PIM?
El mapeo establece la correspondencia entre los campos del sistema de origen y los del destino.
Un ejemplo sencillo sería:
| Campo de origen | Campo de destino |
|---|---|
product_code | SKU |
commercial_name | Nombre comercial |
long_text | Descripción larga |
main_colour | Color principal |
package_height_mm | Alto del empaque |
El trabajo parece mecánico hasta que se revisa el significado real de cada campo.
¿commercial_name contiene el nombre aprobado para vender o una denominación interna? ¿El alto del empaque está en milímetros y el destino espera centímetros? ¿El color se guarda como texto libre o como una opción controlada? ¿La descripción contiene etiquetas que el canal rechaza?
El analista PIM aporta contexto. Mapear no es relacionar dos nombres parecidos: es confirmar que ambos campos representan el mismo concepto.
Dos campos llamados “estado” pueden tener sentidos completamente diferentes. Uno podría representar el estado del producto dentro de un flujo de aprobación y otro, el estado de publicación en un marketplace.
La coincidencia del nombre no garantiza la equivalencia semántica.
¿Qué es una transformación y cuándo debe aplicarse?
Una transformación modifica el valor o la estructura de un dato para que el sistema de destino pueda interpretarlo.
Algunos ejemplos frecuentes son:
- Convertir milímetros en centímetros.
- Combinar marca, modelo y tipo de producto para construir un título.
- Transformar “Azul marino” en una opción aceptada por el canal.
- Separar varias medidas almacenadas en un mismo campo.
- Adaptar el formato de una fecha.
- Retirar etiquetas HTML no admitidas.
- Relacionar una categoría interna con una categoría de VTEX o Mercado Libre.
- Convertir un valor booleano en “Sí” o “No”.
Una transformación puede ser necesaria, pero también puede alterar el significado del dato. Por eso necesita una regla funcional, no solamente técnica.
Si el PIM conserva el valor “Azul marino” y el marketplace solo admite “Azul”, necesito definir si esa equivalencia es válida para ese canal. No debería empobrecer el valor maestro solo para adaptarlo a una limitación externa.
Las transformaciones deben ser documentadas, repetibles y específicas por destino. Si alguien corrige manualmente los datos después de cada envío, el proceso todavía no es sostenible.
¿Por qué los identificadores son tan importantes?
Los sistemas necesitan reconocer que están trabajando sobre el mismo producto.
Para eso se usan identificadores como:
- SKU.
- GTIN o EAN.
- Código interno.
- ID del producto en el PIM.
- ID del registro en el eCommerce.
- Código del producto padre.
- Código de cada variante.
El SKU puede ser el identificador principal dentro de la empresa, pero Shopify, VTEX o Mercado Libre también generan sus propios códigos internos. La integración necesita conservar la relación entre esos identificadores para saber qué registro debe actualizar.
Si esa correspondencia se pierde, una actualización puede crear un producto nuevo en lugar de modificar el existente.
Las variantes agregan otra dificultad. El producto padre puede tener un identificador, mientras cada combinación de color y talla tiene otro. El destino puede representar esa relación de una manera distinta.
Por eso reviso:
- Si los códigos son únicos.
- Si conservan los ceros iniciales.
- Si tienen espacios ocultos.
- Si cambiaron durante el proyecto.
- Si la relación entre padres e hijos es correcta.
- Si existen identificadores duplicados.
- Si un producto discontinuado conserva vínculos activos.
Un identificador ocupa poco espacio en una ficha, pero puede ser la pieza que mantiene unido todo el ecosistema.
¿Qué formatos de intercambio conviene reconocer?
Las integraciones pueden mover información en diferentes formatos. Los más frecuentes son CSV, JSON y XML.
CSV representa la información en filas y columnas. Es fácil de revisar en una hoja de cálculo y resulta práctico para importaciones masivas, aunque tiene limitaciones para representar estructuras complejas.
JSON es habitual en APIs. Puede contener productos, variantes, atributos y relaciones dentro de una estructura anidada.
XML aparece en numerosos feeds, estándares y sistemas empresariales. También permite representar jerarquías y aplicar reglas formales.
No necesito memorizar la sintaxis de cada formato. Sí necesito comprender que el formato describe cómo viaja la información, no qué significa.
Un campo puede llegar en un CSV, un JSON o un XML y seguir siendo incorrecto. La estructura técnica puede ser válida aunque el contenido no tenga sentido para el catálogo.
¿Cuándo se envían los datos?
No todas las integraciones actualizan la información en tiempo real.
Los modelos habituales incluyen:
| Modelo | Qué ocurre |
|---|---|
| Proceso por lotes | Se envía un conjunto de registros en un horario definido |
| Consulta periódica | El sistema revisa cada cierto tiempo si hay cambios |
| Webhook o evento | Un cambio activa el flujo |
| Sincronización incremental | Solo se procesan productos nuevos o modificados |
| Carga completa | Se vuelve a enviar todo el catálogo o un conjunto amplio |
Para el analista, la pregunta principal es qué efecto tiene esa frecuencia sobre el trabajo diario.
Si el producto se aprueba a las diez de la mañana y la integración corre una vez por la noche, no debería esperarse que aparezca en el eCommerce cinco minutos después.
Cuando solo se envían cambios, necesito saber cómo se detectan. ¿Se compara una fecha de modificación? ¿Se marca el producto como pendiente? ¿Un cambio de imagen también activa el envío? ¿Qué sucede si el proceso falla después de haber marcado el registro como procesado?
¿Qué diferencia hay entre un error técnico y un error de datos?
No todos los errores tienen el mismo origen.
Un error técnico puede ocurrir porque una API no responde, una credencial venció, se alcanzó un límite de consultas o la conexión se interrumpió.
Un error de datos aparece cuando la infraestructura funciona, pero la información no cumple una regla.
Por ejemplo:
- Falta el SKU.
- La categoría no está mapeada.
- El color no pertenece a la lista permitida.
- Un campo numérico contiene texto.
- La imagen no está vinculada con el producto.
- La variante no tiene producto padre.
- Un atributo obligatorio está vacío.
- La unidad de medida no es válida.
El analista PIM tiene un papel central en este segundo grupo. Necesita definir qué condiciones bloquean el envío, cuáles producen una advertencia y cuáles pueden revisarse después.
No todos los datos faltantes deben detener una integración. Tampoco conviene enviar cualquier registro y esperar que el canal decida qué hacer con él.
La validación debería ocurrir lo antes posible, preferentemente antes de que la información abandone el PIM.
¿Qué son los registros de error y por qué debería revisarlos?
Los registros de ejecución, o logs, documentan qué ocurrió durante el proceso.
Pueden indicar:
- Cuándo comenzó y terminó la ejecución.
- Cuántos productos se revisaron.
- Cuántos se enviaron.
- Cuántos fallaron.
- Qué respuesta devolvió el destino.
- Qué producto estuvo involucrado.
- Si se realizó un nuevo intento.
No necesito comprender todos los detalles internos. Sí necesito recibir información que pueda convertirse en una acción.
Un mensaje como 400 Bad Request puede ser útil para el desarrollador, pero el equipo de catálogo necesita una explicación más concreta:
“El SKU 45892 fue rechazado porque el atributo Material contiene un valor no admitido”.
Un buen tablero traduce los eventos técnicos en tareas operativas: completar un campo, corregir una categoría, revisar una relación o volver a aprobar un producto.
Un error registrado pero imposible de convertir en una acción concreta sigue siendo un problema sin resolver.
¿Qué significan reintento, conciliación e idempotencia?
Hay conceptos técnicos que afectan directamente la calidad del catálogo.
Reintento: cuando un envío falla por un problema temporal, el sistema vuelve a ejecutarlo.
Conciliación: se comparan el origen y el destino para detectar productos faltantes, desactualizados o inconsistentes.
Idempotencia: una misma operación puede repetirse sin crear duplicados ni alterar el resultado esperado.
No necesito programar estos mecanismos, pero sí preguntar si existen.
Imaginemos que el sistema envía un producto, no recibe la respuesta y vuelve a intentarlo. Si el proceso no está preparado para reconocer que el producto ya fue creado, podría generar un duplicado.
También puede ocurrir que una integración informe que procesó todas las novedades, pero un registro haya quedado sin actualizar. La conciliación permite detectar esa diferencia.
Enviar datos y comprobar que llegaron son dos tareas distintas. Una integración madura necesita ambas.
¿Cómo participa el analista PIM en las pruebas?
Las pruebas no deberían quedar únicamente en manos del equipo técnico.
El desarrollador puede comprobar que la API respondió, que el proceso no se interrumpió y que la estructura enviada es válida. Yo necesito confirmar que el producto publicado tenga sentido.
Para eso preparo casos representativos:
- Un producto simple.
- Un producto con variantes.
- Un producto con varios activos.
- Un producto con contenido en varios idiomas.
- Una actualización de descripción.
- Un reemplazo de imagen.
- Una reclasificación.
- Una desactivación.
- Un registro incompleto que debería rechazarse.
Después comparo el origen con el destino.
¿La categoría es correcta? ¿Las variantes conservaron su relación? ¿Las imágenes aparecen en el orden esperado? ¿Las unidades se transformaron bien? ¿Una actualización modifica el registro existente o crea otro? ¿La desactivación retira el producto del canal?
Estas pruebas forman parte de la aceptación funcional.
La integración no está lista porque corre. Está lista cuando reproduce el comportamiento acordado.
¿Qué documentación debe quedar después de la implementación?
Una integración no puede depender de la memoria de las personas que participaron en el proyecto.
Debería quedar documentado:
- Qué sistemas se conectan.
- En qué dirección viajan los datos.
- Qué entidades y campos se intercambian.
- Qué sistema es responsable de cada campo.
- Qué transformaciones se aplican.
- Con qué frecuencia se ejecuta el proceso.
- Qué validaciones existen.
- Qué errores pueden aparecer.
- Quién debe intervenir en cada caso.
- Cómo se comprueba la actualización del destino.
También conviene mantener un historial de cambios.
Si Shopify modifica una estructura, VTEX agrega un campo, el ERP cambia un código o el PIM incorpora otra familia de atributos, el mapeo puede necesitar ajustes.
La documentación no es un archivo decorativo que se guarda al finalizar. Es parte de la capacidad del equipo para mantener la integración cuando el proyecto pasa a operación.
¿Qué aprendí trabajando con equipos técnicos?
Aprendí que no necesito hablar como desarrolladora para trabajar bien con desarrolladores.
Necesito describir el problema con precisión.
“No funciona” aporta muy poco. En cambio, puedo decir:
“El SKU está actualizado en el PIM, aparece en la última ejecución del proceso, pero la descripción visible en Shopify conserva el valor anterior”.
También aprendí a separar lo que observo de lo que supongo.
Que una imagen no aparezca no significa automáticamente que la API falló. Puede faltar una asociación, el archivo puede no estar aprobado, el producto puede no pertenecer al canal o el destino puede haber rechazado el formato.
Mi aporte está en conocer el catálogo, reconstruir el recorrido del dato y formular preguntas que ayuden a localizar el problema.
En proyectos de la agencia, las integraciones han conectado PIM con ERPs, Shopify, VTEX, Commercetools, Producteca, Retail Pro, herramientas de diseño y otros componentes. La complejidad técnica cambia, pero el patrón se repite: el resultado depende tanto del desarrollo como del modelo de datos, los mapeos, las reglas y las validaciones funcionales.
¿Dónde termina la responsabilidad del analista PIM?
Entender una integración no significa asumir el trabajo del desarrollador.
No necesito definir la infraestructura, escribir funciones, administrar servidores ni resolver problemas de autenticación. Tampoco debería aprobar decisiones técnicas que no comprendo o para las que no tengo responsabilidad.
Mi tarea es aportar claridad funcional:
- Qué necesita el negocio.
- Cómo está modelado el catálogo.
- Qué información debe viajar.
- Qué condiciones debe cumplir.
- Qué resultado se considera correcto.
- Qué errores requieren una intervención operativa.
Saber dónde termina mi rol también mejora el trabajo conjunto. Evita que los problemas técnicos y los problemas de datos se mezclen, y permite que cada perfil actúe sobre lo que conoce mejor.
No necesito saber programar para tener un rol activo en una integración PIM. Necesito entender quién crea el dato, cómo se identifica, qué transformación recibe, cuándo viaja, qué puede hacerlo fallar y cómo comprobar que llegó bien. Ese conocimiento me permite conversar con IT, probar el flujo y proteger la calidad del catálogo. El código mueve la información; las decisiones compartidas hacen que llegue con el significado correcto.
