Master Data Governance in practice: is it a waste to try to turn requesters into master data specialists?

Training requesters is important. But there is a practical limit to this approach.

The requester usually doesn't live the master data process every day. They might be a maintenance technician, a buyer, an operations user, someone from the warehouse or from any area that needs to solve a real business need.

That user may know exactly which part they need to replace, where it will be applied, which equipment is down and which vendor usually supplies that demand. But that doesn't mean they know how to translate this knowledge into a structured request that follows PDM rules, classification, technical attributes, short description, long description, unit of measure, duplicate checks and alternate part numbers.

The key point is this: the requester knows the operational need, but doesn't always know the master data language required to turn that need into high-quality master data.

Governance shouldn't require the user to stop the process to check manuals, instructions, training decks or supporting documents — much less to run later lookups on materials that live outside the master data tool.

If each material family requires different attributes, if each PDM has its own rules, if each type of request needs specific validations, it makes no sense to expect the requester to interrupt the flow to figure out which guidance applies to that case.

In practice, no one wants to leave a modern tool to look for answers in a manual — the user's day-to-day doesn't allow it.

The requester shouldn't have to consult governance outside the process. Governance has to show up for them inside the process, at the moment the decision needs to be made.

This changes the logic of the request. Instead of a passive form that just receives information, we now have an assisted process, able to guide, ask, suggest, validate and alert the user while they execute the request.

That's where the combination of RPAs and AI agents stops being a generic promise and becomes practically applicable to Master Data Governance: they bring the rules, standards and best practices into the user's real experience.

For a long time, we treated the poor quality of requests as essentially a training problem. If the user filled it in badly, the answer was almost automatic: create a training, update a manual, reinforce a communication or send the request back with new guidance.

These actions still have value. But recent market studies and movements point to a complementary — and often more effective — approach: supporting the user inside the real flow of work.

A study published in the *Quarterly Journal of Economics* analyzed the gradual rollout of a conversational AI assistant to 5,172 customer support professionals. Access to AI increased average productivity by 15%, measured by issues resolved per hour, with especially relevant gains among less experienced and lower-performing professionals.

That finding is very relevant for Master Data Governance. The requester of a master data record is usually not a specialist in PDM, taxonomy, technical attributes, descriptive rules or duplicate criteria. They are a specialist in the operational need. They know the problem they need to solve, but don't always know how to turn that knowledge into a structured request.

The takeaway for MDM is direct: in complex processes, it isn't enough to hope the user consults training, manuals or external instructions every time they need to make a decision. The process itself has to help the user at the moment they are filling in, choosing, attaching, classifying and justifying.

There is one more relevant point. According to Gartner, 59% of organizations do not measure data quality, making it hard to understand the real cost of poor quality and the ROI of improvement programs.

That means many companies probably underestimate the cost of bad requests: rework, returns, duplicates, incorrect purchases, delays, poor traceability and extra effort from the master data, purchasing and maintenance teams.

That's why the future of data quality at the source doesn't depend only on more training. It depends on better guidance. And better guidance means bringing the governance rule into the process: in the right field, at the right moment, with the right question.

To move from concept to practice, imagine a maintenance requester who has technically identified the material needed for a replacement: an SKF 16020 BEARING.

Before requesting a new record, they do what any good process user should: search the existing base to check whether the material is already registered or if there is a similar item that could meet the same need.

Zoom

Zoom

In this case, they don't find the bearing or any equivalent item in the base. From there, the process stops being just a search and becomes a new master data request.

This requester, however, doesn't arrive empty-handed: they may have a manufacturer URL, a photo of the packaging or label, a screenshot of the technical drawing or even a PDF with the datasheet. These elements are essential because they carry a large part of the technical information needed to structure the record.

Zoom

This requester, who has already spent time defining and gathering the technical information about the material, would then face a new challenge: selecting the correct PDM out of a list of thousands, filling in technical attributes, providing alternate part numbers, equivalent manufacturers and other information required by the process.

That is exactly where using a guide — an AI-based assistant — makes all the difference. See how simple it becomes:

*[The animation that will live in this space will be published later.]*

Notice that all the requester's initial effort wasn't wasted. They didn't have to know in advance which PDM was the right one out of thousands of possibilities. They also didn't need to remember every technical attribute expected for a bearing, nor master the descriptive standard that would be applied when creating the material.

What they needed to do was bring the best context available: the operational need, the technical reference, the manufacturer URL, the label image, the technical drawing or the datasheet.

From there, the AI agents started acting as support inside the process:

• first, helping to identify the most appropriate PDM;
• then, suggesting how to fill in the technical attributes;
• next, supporting the identification of part numbers, alternate manufacturers and possible equivalences;
• finally, transferring the structured information into the request form, already respecting the descriptive standard defined by governance.

That's the core of the approach: AI doesn't replace the requester, because the operational context still belongs to them. It also doesn't eliminate governance, because rules, validations and standards are still needed.

AI operates precisely in the space between the two. It turns the requester's practical knowledge into structured information for the master data process. And it does it live, during execution, before the incomplete request becomes rework.

In the traditional model, the error appears later: when master data sends the request back, when purchasing can't quote it, when the vendor misinterprets it or when the material arrives incompatible.

In the AI-assisted model, guidance happens earlier. Before the rejection. Before the rework. Before the duplicate. Before the wrong purchase.

Training requesters is still important, but we may have gone too far in expecting the end user to interpret and apply, on their own, every rule required to create a good master data request.

In Master Data Governance — especially in material master data — the requester shouldn't be treated as someone who needs to become a PDM specialist. They should be treated as someone who has the context of the need and needs support to turn that context into structured information.

That's the big shift. Data quality isn't born only from a trained user. It's born from a well-designed process, with clear rules, defined responsibilities, adequate technology and contextual assistance at the moment of execution.

AI agents come in exactly at that point: helping the requester navigate the process, interpret references, choose the correct PDM, fill in technical characteristics, identify potential duplicates and structure the request before it moves on to the next steps.

In the end, the discussion isn't training or AI. The discussion is how to shorten the distance between what the requester knows and what the process needs to receive.

And for that, the best answer might not be to require everyone to know more before they start. The best answer is to offer live help while the process happens.

Your requesters don't need to be governance specialists. They need to be guided by it.