In a previous role, one of the first things I noticed was how master data got created: a salesperson needed a new item, customer, or vendor in the system, so they sent an email. Someone on the internal sales team received it, interpreted it, and entered the data however they saw fit. No template. No standard. No audit trail. Just inbox to ERP, one person at a time.
What followed was a project that touched process design, change management, technology implementation, and — most importantly — organizational trust. Here is how we got from email chaos to a governed, measurable workflow, and what the data revealed along the way.
The "before" picture
The core problem was not that people were careless. It was that there was no shared structure to be careful within. When a salesperson needed a new product created, they described it however made sense to them — sometimes by the name they used with their own customer, sometimes by a rough description, often without the manufacturer part number at all.
The internal sales team receiving those requests had some ERP training, but no standard operating procedure to follow. Descriptions were entered inconsistently. Naming conventions were personal. And because manufacturer part numbers were not consistently tracked, the same physical product could be requested by two different salespeople, entered by two different internal reps, and end up as two entirely separate records in the system — with no easy way to know they were the same thing.
Customers and vendors were somewhat easier to manage, but the underlying issue was the same: data quality was a function of individual habit, not organizational practice. And the downstream cost showed up later, when we began working toward golden records. Duplicate items were hard to consolidate. In some cases, we had to maintain separate golden records for what was likely the same item, because the data was too thin to make a confident determination.
Why ServiceNow — and why it took two attempts
The push to stand up a better process was tied directly to a broader ERP migration underway at the organization. With a new system on the horizon, getting master data creation under control was not just an operational improvement — it was a prerequisite. Clean, governed intake processes needed to be in place before data could flow reliably into the new ERP. That dependency set the clock: roughly one month from when I joined to having something operational — this included identifying the requirements and impacted teams.
That urgency drove our first solution: a structured sharable form that gave salespeople a template to fill out before submitting a request. It was simple, but it was a meaningful step — it introduced a shared intake format and pushed some of the data-gathering responsibility back to the requester.
As the ERP migration timeline extended, we gained enough runway to implement something more durable. ServiceNow was already in use at the company, which made it the natural choice — no new procurement, no vendor negotiations, and some existing user familiarity. We also evaluated workflow tooling within the ERP itself, but it did not fully meet our requirements.
The ServiceNow process required salespeople to submit a structured request — part number, item name, vendor, and a defined set of attributes — through a form. From there, the request moved through a defined workflow: to procurement, then to the MDM team, back to procurement, and finally activation in the ERP. Four steps, clear ownership at each stage, and full visibility into where every request stood.
De-risking the cutover: the parallel run
Before we fully cut over to the new ERP and the ServiceNow workflow, we ran both systems simultaneously for approximately one month. During that period, the sales team continued creating items in the legacy ERP the way they always had. At the same time, every new request also came through the ServiceNow intake process, and the MDM team created the same items in the new ERP.
This was deliberate. We were not asking the organization to trust a process that had never been tested at real volume. Running parallel gave us a month of live requests flowing through the new workflow — the same volume, the same variety, the same edge cases — before we asked anyone to depend on it exclusively. By the time we cut over, the MDM team had already built reps in the new system, the ServiceNow workflow had been stress-tested, and we had identified and resolved issues that only show up under real operating conditions.
It is a detail that often gets left out of process-improvement stories, but it matters: the confidence that came from go-live was not optimism. It was earned by a month of doing the work twice.
What go-live revealed
The first version of the process did not perform the way we expected. Our target was a twenty-four-hour turnaround across all teams. In practice, items were sitting with the procurement team for up to four days before moving forward.
To stay close to the data and keep executives informed, we built a three-slide weekly deck that went to senior leadership every week — this was important because if items weren't created they are not being sold, thereby directly impacting sales numbers. Slide one showed week-over-week trends across items, customers, and vendors — the headwinds and tailwinds. Slide two broke down daily intake by category, so leadership could see how many requests were coming in and where volume was concentrated. Slide three tracked how many days each request had been open, segmented by team, so it was clear not just that things were slow but exactly where they were sitting.
That granularity created its own tension. Showing which team had requests sitting open was factually accurate — but some stakeholders felt it put MDM in an unfair light, as if the team responsible for governance was also responsible for every delay anywhere in the chain. That concern was real, and it pointed to something important: a static weekly slide deck, however accurate, could be read as finger-pointing.
The answer was not to hide the data. It was to make it more visible and more mutual. We built a live ServiceNow team dashboard — available to all MDM members and to executives alike — that showed in real time how many requests were sitting with each team, and for how long. No static snapshots, no weekly email with last week's numbers. Live data, shared equally, visible to everyone in the process.
The effect was significant. When every team could see the same dashboard, accountability stopped feeling like blame directed at one group and started feeling like a shared operating reality. The conversation shifted from "who is at fault" to "what do we do about this today."
The process we should have built first
With stronger procurement engagement and a clearer picture of where friction lived, we redesigned the workflow into a two-step process: request goes to MDM first, then to procurement, then activation. The four-step structure had been driven largely by procurement's initial pushback on separation of duties. The revised process addressed those concerns while eliminating the redundant handoffs that were causing delays.
The result spoke for itself. Before the redesign, we had sixty-six items that had been open for more than seven days. After the second iteration went live, that number dropped to zero.
We hit the twenty-four-hour turnaround target consistently. The MDM team — now the single point of entry, with clear SOPs and growing ERP fluency — became noticeably more efficient over time. Accountability was visible. Improvement was measurable.
When we crossed that threshold, the team took a moment to formally recognize the contributors — across MDM, procurement, and every group that had leaned in to make the second iteration work. That kind of acknowledgment matters more than it might seem. Getting to zero was a cross-functional accomplishment, and naming it as such helped build the organizational trust that makes the next improvement easier. People engage differently when they know their effort will be seen. Recognition is not a soft gesture — it is a governance tool. It signals that accountability runs both ways: we hold people to standards, and we acknowledge when they meet them.
What changed, in plain terms
- Items older than seven days went from 66 to zero. After the second-iteration workflow went live, the backlog of aging requests was eliminated entirely — the clearest measure of what the process change actually delivered.
- Manufacturer part numbers became mandatory. The single data element most responsible for duplicates was now a required field, not an afterthought.
- Naming conventions became standardized. Items were named by the organization's convention, not by what a particular salesperson found easiest to search.
- One team owned creation. The MDM team became expert in both the tool and the SOPs. Quality improved as they got more reps.
- Turnaround became measurable and predictable. We went from "how long does this usually take?" to a defined twenty-four-hour SLA with data to back it up.
- A weekly executive deck kept leadership informed. Three slides every week: week-over-week trends, daily intake by category, and days open by team. No ambiguity about where things stood.
- A live dashboard made accountability mutual. The ServiceNow team dashboard — available to MDM, procurement, and executives alike — showed real-time request volume and aging by team. Shared visibility replaced one-sided reporting.
- Problems became visible and addressable. When something slowed down, we knew where and why — and we could act on it.
The broader lesson
This project is a good example of something I have seen consistently across MDM and governance work: the first version of a process rarely survives contact with the organization intact, and that is not failure — it is information. What matters is whether you built the infrastructure to see what is happening, and whether you have the will to act on it.
The email process was invisible. Problems accumulated silently. The ServiceNow process was imperfect at launch, but it was transparent — and that transparency is what gave us the leverage to make it better.
Governance is not about getting the process right the first time. It is about building the conditions where you can see what is wrong and fix it.