Written by Richard Turner

25 Years of PIM: What We Learned Before There Was a Playbook

Twenty-five years ago, we started our first product data project with no PIM system, no playbook and, for some of the people involved, no computer on their desk.

It was an oil and gas project. A company had grown fast through acquisitions, and every business it bought came with its own parts, its own part numbers and its own way of describing things. Our job was to clean all of that up before it went into one global ERP system.

There was no software built for the job, so we built it. There was no method to follow, so we wrote one as we went.

A lot has changed since then. Much more than I expected has stayed the same. This is the story of that first project, what it taught us, and why those lessons matter even more now that AI has arrived in product data.

The project: 50 acquisitions, one ERP

The client had acquired many businesses that made the same kinds of tooling. That meant they bought the same parts, sometimes from different suppliers and sometimes from the same supplier under different part numbers.

If all of that data went straight into the new global ERP system, JD Edwards, the company would carry the same part many times over. More inventory, more cost, more confusion.

So the data had to be cleansed before each business was onboarded. And each onboarding had its own go-live date, which meant we never quite knew how much data work was waiting for us until we opened it up.

The working conditions would be hard to imagine today:

• Many people, including some executives, didn't have a computer on their desk.
• Cell phones were only just becoming common.
• There were no web meetings and no screen sharing. It was phone calls or nothing.

So we worked on site. Every week, our team and the client's people from Scotland, Canada and other locations met in Houston. We were on the road about 45 weeks a year for roughly three years, and over that time we converted around 50 businesses.

We even stayed in apartments rather than hotels so the team could spend time together. Long days and weekends were normal, and that shared effort built a bond I still value.

Building a PIM before PIM existed

We had no PIM system, so we built one on a SQL database and the very first version of .NET.

It wasn't one application. It was a set of downloadable tools that all worked off the same database:

• Classification Manager for building and maintaining the taxonomy
• Attribute Manager for the master attributes
• Allowed Values Manager for cleansing and normalizing attribute values
• A data developer tool for loading data into each category from Excel
• A validation tool to catch errors after data was loaded
• Import and export tools to bring part numbers in and send classification data out
• An admin tool for permissions, which back then meant little more than "can you log in?" and "can you edit?"

There were no integrations to speak of. Everything moved as files, and some of those files were very large. Loading them took a long time, and finding and fixing errors was hard because the diagnostics were basic. We built around 20 custom reports just to see what was going on across the projects. Many of those reports still exist today in our web-based platform.

Our development team was in Romania. At the end of each day we sent them the problems we'd found and the improvements we needed. Because of the time difference, fixes were often waiting for us the next morning to load and test.

So the days were for data work with the client, and the nights were for improving the software. It was a round-the-clock operation.

Writing the playbook as we went

The software was only half the challenge. The other half was how people worked together on the data, and nobody had written that down yet.

So we made it up, carefully:

• A classification steering committee decided which category changes were allowed. Requests were reviewed, then approved or rejected.
• Workshops with every business showed people what a taxonomy looks like, checked we had the categories each business needed, and taught the basics: how to share attributes, when to add a category and when not to.
• A growing playbook captured all of it in one large PowerPoint deck, covering how PIM works and what each business was responsible for. I believe we still have it.

We also worked out how the taxonomy itself should be structured. At the top were what we called root attributes: the ERP fields that exist on every single item, like description, commodity code and business unit. We were careful about adding new ones, and even so, the list grew past 20.

That forced us to build inheritance into the taxonomy tool. Add a root attribute once, and it appears in every category. We also had to decide which attribute properties could change from one category to the next, and which had to stay fixed.

It was more painful to create categories and add attributes back then than it is today. But there was one central taxonomy that everyone could see at any time. Nobody was working in Excel.

That still surprises people, because many companies are still doing this work in spreadsheets today. I honestly can't see how that scales.

What it achieved

The biggest win was stopping duplicate parts from reaching the global ERP.

When we onboarded some acquisitions, we mapped as many as 40% of their parts as duplicates of parts the company already had. Very common items were the worst. A single O-ring or seal might have 25 different legacy part numbers, all of which we mapped to one global part number.

We kept the link to the old numbers so people could still look them up, but anyone ordering or buying had to use the new one. Across the program, that saved the company millions of dollars in inventory carrying costs.

We did this without the duplicate-detection tools available now. It was mostly brute force and long hours.

The data didn't stop at the ERP, either:

• PLM: We worked with early versions of PTC Windchill, which had no classification at the time. Customizations were needed to make classification appear in it.
• Unified search: As a startup ourselves, we partnered with another startup in Boston that had a web-based search tool. We sent it our data models, classifications and technical data, and it combined them with ERP information such as cost and inventory. People could find a part through the taxonomy and see everything about it in one place.

Looking back, that was one of the first web-based business intelligence tools for manufacturing, and we were proud to help pioneer it.

What has changed, and what hasn't

The tools are almost unrecognizable. The thinking behind them has barely moved.

What hasn't changed is the philosophy. You still need one data model. You still need people to agree on the rules. You still need someone who understands both the data and the business making the calls. And you still need to educate people before you ask them to change how they work.

That's why our PIM is built the way it is. Every capability in it comes from 25 years of doing this work for real, first in oil and gas and then in aerospace, HVAC, automotive and electronics.

Five lessons that still apply today

1. Clean the data before it moves, not after. We cleansed every acquisition's data before it reached the ERP. Fixing duplicates after go-live is far harder and far more expensive. If you're planning a migration or a new system, find out where your risks are first. Our Product Data Risk Audit is a good place to start.

2. Bad data costs real money, even when nobody sees it. Forty percent duplicates in one acquisition is not a data problem. It's an inventory problem, a procurement problem and a cash problem. The Product Data Revenue Leak Scorecard helps you put a number on what your data is costing you.

3. Governance is a people decision before it's a software feature. Our steering committee did more for data quality than any tool we built. Someone has to decide what changes are allowed, and everyone has to agree on how. If you don't have that yet, the Governance Starter Template gives you a structure to begin with.

4. Get everyone onto one model before you add technology. Fifty businesses worked because they all moved to one data model. That's still true, whether the new technology is a PIM or AI. Check where you stand with the PIM Readiness Checklist and the AI-Ready Product Data Checklist.

5. Treat data work like a production line. We learned to run data work day and night, with clear handoffs and constant feedback. Today that's our managed data factory. If you're scaling your own product data work, the Product Data Factory Blueprint shows how to set one up.

The next 25 years

Technology moved slowly for much of the last 25 years. I don't think the next stretch will look anything like that.

AI is the biggest leap I've seen since we were writing code on .NET 1.0. It's already making things possible in our software that we simply couldn't do back then. And the way data moves between companies is changing too. New platforms are making integration far simpler than the file-and-API struggles we used to live with.

But if that first project taught me anything, it's that technology is never the hard part on its own. The hard part is getting people aligned, agreeing on the rules, and doing the data work properly. AI will make all of that faster. It won't make it optional.

I'm genuinely excited about where PIM goes from here. We've spent 25 years building the foundation for it.

Not sure where your product data stands? Start with the Product Data Risk Audit, browse the full Convergence Data toolkit, or talk to our team.