Archive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

I’m trying out a few new things in tonight’s edition.

If you can “spot the 3 differences” from last week and are the first to send me the answer, I’ll send you a free The Pure Procurement Newsletter ball cap. Anywhere in the world. As folks who have gotten one know, they are impossible to buy 👀

But don’t dawdle. You’re playing against {{active_subscriber_count}} other readers!

I’ll even be nice and give you the first one…

I added a poll in the intro. It’s meant to:

So go on… Reader poll #1:

If the answer is “Yes”, tonight’s note is a reminder for you.

Any other answer and I’ve got something interesting to show you!

Onwards.

📰 In this week’s edition:

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Many professionals I meet still think you can get your supplier master data to live in one system. A "single source of truth", as they call it… One master record that rules them all…

Here's the problem: as soon as more than 1 system needs supplier data, this assumption can’t be true...

Why?

Because different systems need fundamentally different types of supplier data to function.

And here's the kicker: even systems in the same category have different data structures.

Every system was purpose-built to solve a specific problem. Which means every system needs its own flavor of supplier data to work properly…

Yet I keep hearing organizations say they are going to use their ERP as the “single source of truth” for supplier data.

Madness!

Your ERP was never designed to manage ongoing risk monitoring, compliance certifications that expire, or strategic relationship classifications that change as your business evolves…

Trying to have ERP run the show means all systems which require supplier data will leverage the same type of data, managed the same way, with the same lifecycle… The ERP’s supplier data model.

You’re starting to see why this just can’t work…

Now here's what to do about it:

Most procurement teams operate with this mental model: supplier data lives in the ERP. Maybe the S2P system. But definitely somewhere as the “golden” master record.

Then reality hits.

You deploy a new procurement technology. A supplier risk platform. An intake tool. A payments solution. It needs supplier data. It also creates new supplier data that doesn't exist anywhere else.

Suddenly you're managing supplier information across six systems because the ERP can’t ingest these new types of supplier data. None of them talk to each other (or they talk to each other very poorly...). Your "single source of truth" is now six partial truths that often contradict each other.

And everyone is back to spending their days in Excel, ripping their hair out, trying to make sense of the data…

Almost every procurement technology you deploy needs access to supplier data... Most of them also capture new data dimensions you've never tracked before.

Your old approach? It assumes supplier data structures are static. That the data can live in one place. That "master data management" just means picking which system wins.

That's like buying a one-bedroom studio in your twenties (ERP), adopting ten kids (systems with new data), and insisting you'll never need to move because "this is our single source of housing." 😅

That assumption is killing the potential value of your technology investments...

Stop thinking about building a “single source of truth” for your supplier master records.

Instead, start thinking about a supplier “data object” that's intentionally and inevitably fragmented across multiple systems.

Different types of supplier data live in different systems… Because that's where they belong! Let’s use an example to illustrate.

You invite 3 new suppliers to a sourcing event. Do you create them all in your ERP? No, that would be silly… Why? You’ll likely only end up doing business with one of them… So why would you create 3 records in your transactional system?

But you might want to keep records on suppliers that have participated in sourcing events with you in the past… They therefore need a supplier record in your sourcing system.

And the supplier you select needs the sourcing system records to be linked to the ERP transactional record in some way, no?

Aha! So you’re starting to see what I mean…

Here's what mapping these relationships could look like in practice:

Notice the pattern? Each system owns the data it's actually responsible for collecting/managing. The other systems that need it to function consume the data.

In this scenario,

None of these systems should try to be the "master" for everything. They can't be. They weren't built for it.

Documenting these existing relationships in your own context is the first step to better supplier data management. You should also go one step further than my example by doing this exercise by data element (field).

Here's another layer to this: some supplier data only lives in one system, while other data needs to be distributed everywhere.

Your risk platform's detailed cybersecurity posture assessment data? That stays in the risk platform. Your AP team doesn't need it. Your sourcing team doesn't need it. It's relevant for risk managers reviewing supplier relationships, that's it.

But supplier legal entity name? That needs to be everywhere. Every system that references a supplier needs the correct legal name. Same with supplier ID, status (active/blocked), and a few other core identifiers.

This is the difference between:

Reference data → distributed to every system that touches suppliers

Specialized data → lives only where it's used

Most organizations treat all supplier data like it needs to be everywhere. That's how you end up with your ERP storing ESG ratings it never uses, and your risk platform trying to sync purchase order addresses it doesn't care about…

Either that, or implementing solutions that sound great in principle but can’t deliver on the nuance I’m outlining when rubber hits the road…

So once you know what kind of data is captured, by which system, when it’s captured and what other system needs it, you’re left with a plate of spaghetti to eat… (with lots of meatballs).

Sure… Once you’ve documented the dynamics, you could try to build support for all of this complexity in-house with IT in a middleware layer or “data lake”… But there’s a whole subset of the procurement technology industry working on this problem…

Why not leverage their work to leapfrog the learning curve?

Here's what you actually need to solve this problem: a central, flexible, “hub-and-spoke” type solution that's explicitly designed to manage fragmented supplier data across multiple systems.

Call it a supplier relationship management (SRM) tool. Call it a supplier data management platform. Call it supplier information management. It has many names on the software market.

But please, just call it something…😅 Because your ERP and S2P Suite weren't built to solve this problem.

The hub's job isn't just to connect systems… It's to know which system owns each piece of data, which ones need distribution and which data stays put.

When legal entity name changes? The hub pushes that update to every connected system.

When a new risk score comes in? The hub stores it and makes it available on-demand (e.g. for ad hoc business intelligence requests). It doesn't spam every system with data they don't need.

This hub needs to do five things your existing systems can't:

Your hub needs to accommodate the reality of your tech stack, not some idealized version of it. That means custom fields, legacy data structures, internal/external data and all the technical debt you've accumulated over the years.

Without this hub, you're managing point-to-point integrations between every system that touches supplier data. You’re logging improvement requests in the IT department’s backlog for changes… And that scales like garbage.

If you want to deliver supplier data system-to-system with five systems, you're managing ten integration points. With seven systems, it's twenty-one. With ten systems? Forty-five. 😭

The hub-and-spoke model scales linearly. Each new system gets one integration to the hub. The hub handles the rest.

When you accept fragmentation by design, you build integration patterns that respect data ownership instead of fighting it.

Your supplier data isn't going to live in one system… It never really did… We all just pretended it did and got by with Excel for the rest…

However, with the explosion of ProcureTech in recent years, the ramifications of not addressing this problem are only getting bigger every year… And now with folks trying to “stack AI” on top of all these systems? Solid supplier data management foundations become even more critical.

The sooner your default assumption becomes that supplier master data is a distributed object across multiple systems, the sooner you can build processes and architecture that actually deliver on promised value.

Accepting this often means deploying a purpose-built solution to manage this fragmentation because your ERP and S2P Suites certainly weren't designed for it…

Every new procurement technology you deploy will test this. Either you'll have a mental model (and system architecture) that accommodates fragmentation, or you'll spend six months in integration hell trying to make your house of cards operational…

Your call.

What's your experience with supplier master data across multiple systems?
Hit reply. I read every response.

👀 In Case You Missed It…
My Best Linkedin post this week: