Cuando llegó mi primer proyecto PIM: lo que aprendí sobre datos, procesos y operación real

La primera vez que entré a un proyecto PIM pensé que iba a trabajar, sobre todo, con fichas de producto. Imaginé atributos, categorías, descripciones, imágenes, reglas de formato, columnas de Excel y validaciones. Todo eso estaba, sí. Pero duró poco la idea de que ese era el centro del trabajo.

Muy rápido entendí que eso era apenas la superficie. Debajo aparecían decisiones viejas acumuladas, criterios distintos conviviendo a la fuerza, equipos usando las mismas palabras para hablar de cosas diferentes y áreas enteras sosteniendo procesos críticos con una mezcla de costumbre, intuición y esfuerzo manual.

Ahí apareció una de las primeras verdades que me habría gustado escuchar con más claridad desde el principio: un proyecto PIM no empieza en el catálogo; empieza en la forma en que una empresa piensa, crea, corrige, aprueba y distribuye su información de producto.

Dicho así suena ordenado. En la práctica, casi nunca lo es.

¿Qué revela realmente un proyecto PIM cuando empieza?

Un proyecto PIM revela cómo una organización gestiona su información de producto mucho antes de que esa información llegue a una ficha, a un canal o a un eCommerce. Lo primero que expone no suele ser un problema de carga, sino un problema de proceso, de criterios compartidos, de responsabilidades y de gobierno del dato.

En mis primeros meses en CRITERIA vi una situación que después se repitió muchas veces: empresas con muchísima experiencia comercial y técnica, pero con el dato de producto repartido entre ERP, carpetas compartidas, mails, PDFs de proveedores, publicaciones antiguas, descripciones copiadas entre canales y planillas con nombres parecidos, cada una supuestamente “la buena”.

Cuando eso pasa, el problema no es solamente que la información esté dispersa. El problema es que nadie puede decir con total certeza cuál es la versión correcta de un producto. Y cuando eso ocurre, el error siempre termina saliendo a la superficie en el peor lugar posible: el canal de venta.

Con el tiempo entendí algo que hoy me parece central: cuando una empresa siente que “tiene un problema de catálogo”, muchas veces en realidad tiene un problema de gobierno del dato.

Un proyecto PIM no empieza en las fichas de producto. Empieza en cómo una empresa crea, corrige, aprueba, distribuye y gobierna su información de producto. Cuando una organización cree que tiene un problema de catálogo, muchas veces lo que tiene en realidad es un problema de proceso, responsabilidades, lenguaje común y gobierno del dato.

¿El problema en un proyecto PIM es Excel?

No. El problema no es Excel. El problema aparece cuando Excel deja de ser una herramienta de apoyo y se convierte en sistema, repositorio maestro, workflow de aprobación, archivo histórico, integración improvisada y memoria institucional al mismo tiempo.

Digo esto después de trabajar mucho con planillas, exportaciones y validaciones. Excel puede ser útil, y de hecho sigue siéndolo en muchos momentos de un proyecto. El punto de quiebre aparece cuando la organización le pide resolver tareas que en realidad exigen otra estructura: control de versiones, trazabilidad, definición de propietarios del dato, reglas de publicación y consistencia multicanal.

Ahí ya no estamos hablando de una herramienta flexible. Estamos hablando de una estructura frágil disfrazada de costumbre.

En varios proyectos vi el mismo patrón: el desorden del maestro de productos no se originaba en una planilla aislada, sino en la ausencia de una arquitectura clara para definir, mantener y publicar el dato correcto. Por eso, reducir el problema a “hay muchas planillas” casi siempre es quedarse en la superficie.

¿Catalogar es cargar información o tomar decisiones?

Catalogar no es solamente cargar información. Catalogar es decidir cómo se define, clasifica, valida y usa la información de producto.

Antes de entrar de lleno en proyectos PIM, una parte de mí asumía que ordenar información consistía en completar faltantes, corregir errores y acomodar lo que estaba disperso. Eso existe, claro. Pero en un proyecto real, catalogar es tomar decisiones.

Decidir si “negro” y “Negro” son equivalentes parece una cuestión menor hasta que hay miles de productos, filtros de navegación, reglas de sindicación y distintos equipos interviniendo sobre el mismo atributo. Decidir si una categoría responde a la lógica del depósito o a la lógica del comprador cambia por completo la forma en que una persona encuentra un producto. Decidir qué atributo es obligatorio y cuál no define si un canal puede publicarse bien o si queda condenado a parches manuales.

Ahí fue cuando empecé a valorar de verdad tres cosas que en un proyecto PIM son estructurales: la taxonomía, el modelo de datos y los vocabularios controlados.

El problema no es Excel. El problema aparece cuando una planilla deja de ser una herramienta de apoyo y se convierte en repositorio maestro, flujo de aprobación, archivo histórico e integración improvisada al mismo tiempo. En ese escenario, la fragilidad no está en el archivo: está en la forma en que la empresa sostiene su operación.

Una taxonomía bien pensada ordena cómo se clasifica y se navega un catálogo. Un modelo de datos sólido define qué información existe, dónde vive y con qué relación. Un vocabulario controlado evita que cada persona escriba “a su manera” algo que el negocio necesita tratar como una sola cosa.

Dicho más simple: si el dato no tiene estructura, cada tarea futura cuesta más.

¿Un PIM ordena automáticamente la información de producto?

No. Un PIM ayuda a centralizar, organizar y distribuir información, pero no resuelve por sí solo lo que la empresa todavía no definió.

Esta fue, para mí, una de las lecciones más importantes. Cuando una organización implementa un PIM suele haber una expectativa razonable, pero peligrosa: que la herramienta “ponga orden”. Y un buen PIM ayuda muchísimo, claro. Centraliza, da trazabilidad, mejora consistencia, facilita publicaciones multicanal y permite trabajar con una fuente unificada. IBM y Akeneo describen ese valor con una idea similar: construir una single source of truth, una fuente única y confiable para gestionar el dato de producto.

Pero la herramienta no decide quién aprueba un dato, quién mantiene un atributo, qué área define una categoría, qué nombre se vuelve preferido, qué canal necesita qué versión del contenido ni qué hacer cuando dos sistemas se contradicen.

Eso lo tiene que resolver la organización.

Por eso digo que un proyecto PIM se parece menos a “ordenar un catálogo” y más a negociar una nueva forma de trabajar. A veces esa negociación ocurre de manera explícita, en workshops, reuniones y definiciones operativas. Otras veces aparece más silenciosamente, cuando el equipo empieza a notar que ya no alcanza con seguir haciendo las cosas “como siempre”.

¿Por qué los errores en los datos de producto tienen historia?

Porque la mayoría de los errores visibles en un catálogo son síntomas de procesos incompletos, urgencias operativas o decisiones heredadas. Rara vez son fallas puramente técnicas.

Una de mis primeras torpezas fue mirar ciertos errores como si fueran solo problemas de dato. Un atributo duplicado, una categoría incoherente, una descripción incompleta, una unidad de medida mezclada. Yo veía el síntoma y quería corregirlo rápido.

Con el tiempo aprendí a hacer otra pregunta: ¿por qué esto terminó así?

A veces la respuesta era una importación apurada o una carga manual sin validaciones. Pero otras veces aparecía una historia más interesante: equipos creando atajos para sobrevivir al volumen, proveedores enviando información inconsistente, áreas comerciales presionando por publicar rápido, operaciones priorizando una lógica interna que no coincidía con la navegación del eCommerce o integraciones inexistentes que obligaban a repetir el trabajo en varios sistemas.

Cuando empecé a mirar los errores como huellas de proceso, cambió por completo mi forma de trabajar.

Dejé de pensar “hay que limpiar esto” y empecé a pensar “hay que entender qué lo produce para que no vuelva a pasar”.

¿Qué relación tiene un PIM con la experiencia de compra?

La relación es directa. La calidad del dato de producto impacta en la navegación, en los filtros, en la consistencia entre canales y en la confianza que transmite una marca.

Al principio, cuando una empresa habla de familias, atributos, normalización o taxonomías, todo parece muy interno. Muy de sistema. Muy de operación. Pero ese límite dura poco. La consecuencia comercial aparece enseguida.

Una taxonomía deficiente rompe la navegación. Un atributo mal estructurado inutiliza filtros. Una ficha incompleta baja la calidad de una publicación. Una diferencia entre ERP, PIM y eCommerce genera inconsistencias visibles. Y cuando el dato cambia según el canal, la confianza también cambia según el canal.

Las propias fuentes del ecosistema PIM y MDM insisten en esto: sin datos completos, consistentes y gobernados, la operación omnicanal se vuelve más lenta, más costosa y menos confiable.

En CRITERIA vemos este patrón una y otra vez. Hay organizaciones que sienten que “su plataforma no convierte”, cuando en realidad la plataforma está recibiendo datos mal modelados o mal gobernados. Hay otras que creen que el problema es publicar en muchos canales, cuando el problema real es no tener una arquitectura de datos capaz de servirle a cada canal lo que necesita.

¿Qué enseñan los proyectos PIM reales?

Los proyectos reales enseñan que el desorden no se corrige solo limpiando datos. Hace falta revisar estructura, reglas, flujos, integraciones y criterios de clasificación.

Algo que agradezco de trabajar en implementaciones reales es que te sacan rápido de cualquier idea romántica del orden.

He visto casos donde hubo que reestructurar por completo una instancia PIM ya existente, limpiar cientos de miles de valores inconsistentes, redefinir categorías, depurar atributos sin uso y volver a conectar el PIM con ERP y canales digitales para que el dato empezara, por fin, a fluir como sistema y no como parche.

También trabajamos con catálogos muy grandes en los que fue necesario revisar estándares de clasificación, rediseñar familias y atributos, reingestar decenas de miles de productos y assets, y preparar integraciones para que el mismo núcleo de información pudiera alimentar distintos destinos.

Y en escenarios más pequeños, aunque no menos complejos, tocó construir una taxonomía casi desde cero porque la información venía incompleta, dispersa y con criterios mezclados.

No hace falta mencionar marcas para que la conclusión sea clara: el patrón se repite.

Cambian la industria, la plataforma, el volumen y el nivel de madurez. Pero los aprendizajes de base suelen ser los mismos.

¿Qué errores cometí al principio en proyectos PIM?

Cometí errores bastante comunes: querer corregir demasiado rápido lo visible, subestimar preguntas clave de gobierno del dato y asumir que ordenar siempre equivale a simplificar.

No me interesa contar esta etapa como si hubiera sido una historia prolija o una epifanía perfecta, porque no lo fue.

Uno de mis errores fue querer resolver demasiado rápido lo que se veía en superficie. Otro fue subestimar el valor de hacer ciertas preguntas incómodas al inicio: quién define qué, quién aprueba qué, desde dónde nace cada dato, cuál canal manda en caso de conflicto, qué información es de compra y cuál es de venta.

También tardé en aceptar algo importante: ordenar no siempre es simplificar.

A veces ordenar implica agregar estructura, crear reglas, distinguir tipos de producto, separar atributos, definir dependencias y forzar vocabularios. Desde afuera eso puede parecer “más complejo”. Pero en la práctica, esa complejidad bien diseñada reduce la complejidad real del día a día.

Y hubo otro aprendizaje que me quedó muy marcado: no conviene confiar a ciegas en lo que “siempre funcionó”. En proyectos PIM, analizar, verificar y buscar antecedentes no es una manía. Es una necesidad. Porque cuando una organización crece, los atajos viejos suelen empezar a cobrar intereses.

Entonces, ¿qué me habría gustado saber antes de mi primer proyecto PIM?

Me habría gustado que alguien me dijera, con todas las letras, que un proyecto PIM no se trata solo de productos. Se trata de lenguaje común, de criterio, de gobernanza y de la forma en que una organización convierte conocimiento disperso en información confiable.

Con el tiempo entendí que publicar mejor no depende solo de escribir mejor una ficha. Depende de diseñar mejor el recorrido del dato desde que nace hasta que llega a un canal.

También depende de personas: de equipos que tienen que adoptar nuevas rutinas, dejar hábitos viejos y confiar en una estructura distinta.

Un PIM bien implementado ayuda a centralizar y ordenar. Pero su verdadero valor aparece cuando la empresa entiende que la información de producto no es un subproducto de la operación; es parte de la operación. Y, en muchos negocios, es una de las capas más visibles de la experiencia de compra.

Eso fue lo que nadie me había contado al principio. O tal vez sí me lo habían contado, pero todavía no tenía dónde apoyarlo.

Ahora sí lo tengo.

Y por eso, cada vez que arranca un proyecto nuevo, ya no pienso “vamos a acomodar productos”. Pienso algo más honesto y más útil: vamos a revisar cómo esta organización convierte conocimiento disperso en información confiable, publicable y útil para vender.

Ahí empieza de verdad el trabajo.

Una forma simple de decirlo

Si hoy alguien me preguntara en voz alta qué cambia de verdad cuando una empresa implementa un PIM, lo respondería así:

“No se trata de tener más campos o una interfaz más ordenada. Se trata de saber qué dato existe, quién lo mantiene, cómo se valida y cómo llega bien a cada canal. Si eso no está resuelto, el problema nunca fue solo el catálogo: era la operación.”

Esa, para mí, es la diferencia entre implementar una herramienta y construir una base confiable para escalar.

Si hoy estás por encarar tu primer proyecto PIM —desde negocio, catálogo, operaciones o tecnología— mi consejo es este: no mires solo la herramienta. Mirá el proceso que la herramienta va a tener que sostener.

Porque cuando el proceso no está claro, el catálogo se resiente.
Y cuando el catálogo se resiente, tarde o temprano lo nota el cliente.

En CRITERIA trabajamos justamente en ese punto de cruce entre estructura, calidad del dato y operación real. Ahí es donde un proyecto PIM deja de ser una iniciativa de catalogación y se convierte en una mejora real del negocio.