La falsa promesa del catálogo único

Hay una frase que aparece con una regularidad inquietante en empresas multinacionales: “Vendemos los mismos productos en varios países. Deberíamos tener un único catálogo.”

Suele decirse con convicción. Como si fuera una verdad técnica evidente, no una decisión organizativa. Y casi siempre llega acompañada de la promesa implícita de orden, eficiencia y control.

El problema es que esa frase solo es cierta si la empresa ya funciona como una sola. Y en la mayoría de multinacionales, eso no pasa ni por accidente.

El dolor real no era tecnológico

Cuando una multinacional empieza a sufrir con su catálogo, el primer reflejo suele ser siempre el mismo: contratar un PIM (Product Information Management o Gestión de Información de Producto) que les permita centralizar y enriquecer todos sus productos.

En este caso, además, no había uno solo. Cada región quería operar con su propio PIM, alineado con su ERP local y con la promesa de que algún día conviviría con un PIM global. El problema es que esa convivencia se planteó sobre una realidad que nadie cuestionó lo suficiente: cada país operaba con su propio ERP. No distintas versiones del mismo sistema, sino ERPs diferentes, con modelos de datos distintos, reglas propias y decisiones comerciales que llevaban años consolidándose.

Aun así, se decidió unificar el catálogo por encima de esa base heterogénea. Por lo que el resultado no tardó en aparecer: atributos obligatorios en un país que no existían en otro, categorías “correctas” para un ERP e “incorrectas” para otro y equipos locales bloqueados esperando decisiones que no controlaban.

El PIM empezó a absorber una fricción que no le correspondía. Y aquí viene el punto importante: el problema no era del software, ni la integración, ni el modelo de datos. El problema era intentar imponer una unidad lógica sobre una realidad operativa que nunca fue uniforme.

Tres caminos razonables

No se llegó directamente a la solución. Hubo debate. Y renuncias.

El camino elegante que no sobrevivió a la realidad

Un único árbol de categorías. Las mismas validaciones. Las mismas reglas de enriquecimiento para todos los países.

Era elegante. También ingenua. Esta opción asumía que los ERPs eran simples variaciones locales. Convertía diferencias estructurales en “excepciones”. Y, sobre todo, escalaba muy mal organizativamente.

Cada particularidad local pasaba a vivirse como una anomalía que alguien “desde arriba” tenía que resolver. El catálogo empezaba a parecerse más a un campo de batalla que a un activo común.

Empezar la independencia en cada país

La reacción opuesta fue sencilla: que cada país gestione su catálogo según su ERP y su realidad.

Esto reducía la fricción diaria y devolvía autonomía a los equipos locales. Pero el coste era alto: duplicación constante, pérdida de coherencia de grupo, imposibilidad de compartir mejoras y ninguna visión global real.

Funcionaba a corto plazo pero rompía el proyecto a medio.

Dejar los productos y centrarse en la estructura

La decisión final pasó por aceptar que el problema no eran los productos. Era intentar compartirlos cuando la empresa no compartía la misma realidad operativa. En lugar de forzar un catálogo global de productos, se tomó una decisión menos vistosa, pero mucho más sostenible: no unificar los productos, sino unificar la estructura.

Se definió un árbol común hasta un cierto nivel, categorías y subcategorías con significado transversal, y se aceptó que la expansión real ocurriría en los niveles más bajos, los nodos hoja.

En la práctica, esto significaba cosas muy concretas. Por ejemplo, Herramientas y Herramientas manuales eran categorías globales. Nadie los discutía. Ahí terminaba la imposición.

El modelo común no obligaba a todos los países a llegar al mismo nivel de detalle. Para algunos, Martillos era una subcategoría final, suficientemente descriptiva para su operativa diaria. En otros, en cambio, ese mismo nodo se desplegaba. Martillos se abría en distintas variantes, por tipo, tamaño o uso, porque el negocio lo exigía y porque así se trabajaba ya en el ERP local.

Ambas estructuras conviven sin conflicto porque compartían el mismo lenguaje en los niveles superiores, pero no se forzaban a parecer idénticas donde dejaban de serlo.

El árbol común marcaba el punto de encuentro. Los nodos hoja absorbían la realidad local. Así cada país podía adaptar la estructura a su ERP y a su negocio.

No era un catálogo único. Era una gramática común.

Si quieres que esas decisiones sobrevivan al tiempo y a la rotación de personas, documentarlas importa tanto como tomarlas.

Recurso Recomendado

Plantilla RFC (Request for Comments)

Estructura profesional para proponer cambios técnicos, evaluar alternativas y documentar decisiones en equipo.

Descargar Gratis

Lo que el catálogo nunca va a arreglar

El error inicial fue pensar que el catálogo podía “arreglar” la fragmentación previa. Pero un catálogo:

• no unifica ERPs
• no homogeneiza decisiones comerciales
• no elimina diferencias estructurales

Lo que sí puede hacer es algo mucho más valioso:

• hacerlas visibles
• gobernarlas
• evitar que exploten de forma caótica
• aprovechar una estructura trabajada durante años

El catálogo no refleja cómo queremos que sea la empresa. Refleja cómo ya es.

El punto en el que dejó de doler

Una vez aceptada la realidad, empezaron a cambiar cosas importantes:

• menos fricción entre países
• menos bloqueos “por diseño”
• más claridad sobre quién decide qué
• mejor calidad de dato, aunque menos “perfecta” en apariencia

El aprendizaje fue claro: El catálogo único no falla por tecnología. Falla cuando intenta ocultar decisiones organizativas no resueltas. Unificar sin entender es solo centralizar el problema. Gobernar es aceptar la diferencia y diseñar alrededor de ella.