A full governance program is not what fits in one quarter

Every master data governance pitch I have sat through opens with a maturity model, five workstreams, and a roadmap that runs two years past the sponsor's own tenure. Almost none of them survive the first budget review, because someone on the steering committee asks what changes in the next ninety days and the honest answer is a current-state assessment. Skip that pitch. Material master and vendor master ownership is a scope that fits in one quarter, and it hands a plant manager or a controller something they can point to before the next budget cycle even opens.

The programs that get funded a second time share one trait. Someone in finance says a specific duplicate got caught before it hit a payment run, or a buyer says a material got created once instead of four times across four plants. That is the case a governance lead can make in a steering meeting, and it is the case this piece is built around.

Name an owner for each material type and vendor category, not a steward team that owns all of it

A central data steward team sounds efficient until you ask who actually approves a new raw material record for a specific plant. The steward team does not run that plant, does not know whether the vendor already exists under a different spelling, and cannot tell a buyer no when the buyer is racing a deadline to place an order. Ownership without domain knowledge is a rubber stamp with better documentation attached to it.

The assignment that works puts a name against each material type and each vendor category. Raw materials for a plant sit with that plant's materials planner. Packaging sits with whoever owns the packaging spec. Indirect spend vendors sit with the category buyer who already negotiates those contracts. Each owner approves creation and change requests inside their own domain and nowhere else, so the approval reflects real knowledge of the record instead of a turn in a queue.

This is the same lesson I would give any team keeping a governance function small. A group that reviews everything ends up understanding none of it well enough to say no. A named owner who reviews only a domain they know can actually catch the record that looks wrong.

The duplicate vendor is the tell

Pull the vendor master in almost any S/4HANA system that has been live for more than two years and you will find the same finding twice. Same company, same building on the address line, two different tax ID formats because one requester typed it with dashes and the other typed it without. Both records got created within a week of each other, by two different buyers, each one under pressure to close a purchase order before month end.

Neither buyer did anything wrong given what they could see on screen. The search did not surface the existing record because the tax ID did not match on a straight string comparison, and nobody had time to try three spelling variations before a deadline. The system rewarded the fast path, which was to create a new vendor rather than chase down whether one already existed.

This is the same failure that shows up on the customer side, where a shared customer record drifts apart the same way once two systems each create their own version of the same account. The fix starts with the same question on both sides. What durable identifier should have caught this at the moment of creation, a tax ID, a registration number, or a fuzzy match on name and address, and who is actually watching for a near match before the record saves.

Write down the approval workflow as it actually runs before proposing a new one

Ask a governance lead to describe the vendor creation workflow and you get the diagram from the design document. Request, review, approval, activation. Ask the buyer who actually creates vendors how it works and you get a different answer, because the diagram never accounted for the vendor who needs a one-time payment before the standard approval chain can run, or the emergency material a plant manager approves by phone because the system approval would take two days nobody has.

Every team I have done this exercise with found at least three of these exception paths once someone sat with the requesters instead of reading the process document. None of the exceptions were malicious. Each one was the workaround someone built the first time the documented process failed a real deadline, and it stuck because nobody ever went back to fix the process itself.

Document the workflow as it runs today, exceptions included, before anyone touches a workflow app on BTP or a new Fiori approval screen. A redesigned approval flow built on top of an undocumented set of exceptions just becomes the fourth path around a fourth set of gaps. The redesign only holds once the exceptions are visible enough to fold into the process on purpose or close off on purpose.

What actually fits in a one-quarter starter

The scope that fits in a quarter is narrower than most governance charters admit, and that is the point of keeping it there. Here is what I would put in front of a sponsor as the deliverable, and nothing past it until the first version is running in production.

  • A named business owner for each material type and vendor category in scope, published somewhere every requester can find it.
  • A documented create and change workflow for material master and vendor master, including every exception path found by talking to the people who submit requests.
  • A duplicate check run against the existing vendor and material master before a new record is allowed to save, using more than an exact string match.
  • A short list of the fields that block activation when missing or inconsistent, agreed with the owners rather than imposed on them.
  • A monthly report of duplicates caught at creation versus duplicates found later in reconciliation.

Measure how fast a duplicate gets caught, not a data quality score

A data quality score that rolls fifteen dimensions into one number tells a steering committee that things improved, but it tells the plant manager nothing about whether the next vendor she creates will get flagged before it duplicates one from last quarter. Scores like that get built to satisfy a slide, not to change behavior at the point where the record gets created.

The measure that changes behavior is simpler and less flattering. Count how many duplicate vendor or material records got caught at creation this month, and how many got found later, in a payment run, a supplier statement mismatch, or an inventory count that turns up six pallets of a material the plant already had next door. That second number is the cost of catching it late, in reversed payments, vendor phone calls, and stock nobody needed to order.

Bring that number to the same steering meeting where the original program got pitched. If creation-time catches are climbing and after-the-fact discoveries are dropping, the quarter earned its budget. If not, you know exactly which owner or which exception path to look at next, and that is a better agenda for the next review than any maturity model slide.