The False Promise of the Single Catalog

There's a phrase that appears with unsettling regularity in multinational companies: "We sell the same products in multiple countries. We should have a single catalog."

It's usually said with conviction. As if it were a self-evident technical truth, not an organizational decision. And it almost always comes with the implicit promise of order, efficiency, and control.

The problem is that the phrase is only true if the company already operates as one. And in most multinationals, that doesn't happen even by accident.

The Real Pain Wasn't Technological

When a multinational starts suffering with its catalog, the first instinct is almost always the same: hire a PIM (Product Information Management) to centralize and enrich all their products.

In this case, there wasn't just one. Each region wanted to operate with its own PIM, aligned with its local ERP and with the promise that someday it would coexist with a global PIM. The problem is that coexistence was planned on top of a reality nobody questioned enough: each country operated with its own ERP. Not different versions of the same system, but different ERPs entirely, with distinct data models, their own rules, and commercial decisions that had been consolidating for years.

Even so, the decision was made to unify the catalog on top of that heterogeneous base. So the results didn't take long to appear: mandatory attributes in one country that didn't exist in another, categories "correct" for one ERP and "incorrect" for another, and local teams blocked waiting for decisions they didn't control.

The PIM began absorbing friction that wasn't its to bear. And here's the important point: the problem wasn't the software, nor the integration, nor the data model. The problem was trying to impose logical unity on an operational reality that was never uniform.

Three Reasonable Paths

The solution wasn't reached directly. There was debate. And trade-offs.

The Elegant Path That Didn't Survive Reality

A single category tree. The same validations. The same enrichment rules for every country.

It was elegant. Also naive. This option assumed the ERPs were simple local variations. It turned structural differences into "exceptions." And above all, it scaled very poorly organizationally.

Every local particularity became an anomaly that someone "from above" had to resolve. The catalog started looking more like a battlefield than a shared asset.

Full Independence for Each Country

The opposite reaction was straightforward: let each country manage its catalog according to its ERP and its reality.

This reduced daily friction and restored autonomy to local teams. But the cost was high: constant duplication, loss of group coherence, inability to share improvements, and no real global visibility.

It worked short-term but broke the project mid-term.

Leave the Products and Focus on the Structure

The final decision was to accept that the problem wasn't the products. It was trying to share them when the company didn't share the same operational reality. Instead of forcing a global product catalog, a less flashy but much more sustainable decision was made: don't unify the products — unify the structure.

A common tree was defined up to a certain level — categories and subcategories with cross-cutting meaning — and it was accepted that the real expansion would happen at the lowest levels, the leaf nodes.

In practice, this meant very concrete things. For example, Tools and Hand Tools were global categories. Nobody argued about them. That's where the imposition ended.

The common model didn't force every country to reach the same level of detail. For some, Hammers was a final subcategory, descriptive enough for their daily operations. In others, that same node expanded. Hammers opened into different variants — by type, size, or use — because the business demanded it and because that's how the local ERP already worked.

Both structures coexisted without conflict because they shared the same language at the upper levels but weren't forced to look identical where they diverged.

The common tree marked the meeting point. The leaf nodes absorbed local reality. This way each country could adapt the structure to its ERP and its business.

It wasn't a single catalog. It was a common grammar.

If you want these decisions to survive time and personnel turnover, documenting them matters as much as making them.

What the Catalog Will Never Fix

The initial mistake was thinking the catalog could "fix" the prior fragmentation. But a catalog:

• doesn't unify ERPs
• doesn't homogenize commercial decisions
• doesn't eliminate structural differences

What it can do is something far more valuable:

• make them visible
• govern them
• prevent them from exploding chaotically
• leverage a structure built over years

The catalog doesn't reflect how we want the company to be. It reflects how it already is.

The Point Where It Stopped Hurting

Once reality was accepted, important things started changing:

• less friction between countries
• fewer blocks "by design"
• more clarity on who decides what
• better data quality, even if less "perfect" in appearance

The lesson was clear: The single catalog doesn't fail because of technology. It fails when it tries to hide unresolved organizational decisions. Unifying without understanding is just centralizing the problem. Governing means accepting difference and designing around it.