Master Data Governance for Equipment: Roles and Controls

Why you need master data governance at all

Equipment and materials directories almost always “get messy” the same way: different people add records for their own tasks without common naming rules and required fields. New suppliers appear, specifications change, and item cards start living their own lives across systems (accounting, procurement, warehouse, TOiR).

The problem isn’t just that the data is “dirty” — it’s that there’s no owner and no clear change process. Today an attribute is adjusted for procurement, tomorrow it breaks warehouse accounting, and the day after that it damages maintenance reports.

Typical consequences surface quickly: the same item is purchased under different names and codes, unnecessary stock accumulates in the warehouse, the right spare part is hard to find, maintenance planning contains errors, and reporting starts to diverge (costs, write-offs, operating hours, warranty). People end up arguing about “which record is right” instead of doing their jobs.

Master data governance for equipment is not a one-off Excel cleanup. A cleanup removes symptoms for today. Governance sets rules, roles and controls so the directory won’t fall apart again: who can change attributes, how changes are approved, where reasons are recorded, and which metrics show falling quality.

Master data typically includes more than just a “material name.” These are stable reference directories that processes rely on: material and spare-part nomenclature, equipment models and types, units of measure, classifiers, manufacturers, critical attributes (voltage, power, dimensions, accuracy class), and also statuses and coding rules.

A simple example: an engineer creates “Подшипник 6205”, while a buyer creates “Bearing 6205 ZZ”. The warehouse ends up with two items and the system shows “out of stock” even though the part exists. Governance prevents such situations through rules and accountability, not heroic firefighting every time.

What we manage exactly: objects and attributes

Governance starts with a simple answer to the question: which directories are master data and which fields must be identical across systems. In practice this is almost always a set of related entities.

Most often the scope includes:

• equipment (assets, assemblies, IT devices)
• materials and spare parts (nomenclature for procurement and warehouse)
• manufacturers and models (brand, product line, model code)
• units of measure and packaging (pcs, set, m, kg)
• classifiers (groups, types, categories)

Each entity needs a minimal set of attributes that must be present before the record can be used in operations.

For a material this usually includes: unique code, name, group, unit of measure, status (active/archived), and distinguishing characteristics (size, material, voltage, accuracy class, etc.).

For equipment: inventory or serial number (if applicable), type, model, manufacturer, commissioning date, location and owner (department).

The most costly mistakes almost always involve fields that affect money, accounting and safety. These are typically marked as critical:

• code/key (used to find and link the object between systems)
• unit of measure and conversion factors
• classification (group, type, tax or accounting category)
• lifecycle status (is it allowed to be procured, written off, used)
• manufacturer and model (important for compatibility and warranties)

It’s important to draw boundaries: master data describes the object, while transactions describe events. Examples of transactions: purchase request, goods receipt, transfer, repair, write-off. If you store “last price” or “on-hand quantity” in the material card, that’s already transactional data and such fields will start to conflict between systems.

A small example: you add a new server model to the directory (for example, from the S200 line) for a project. Master data should hold stable attributes (model, manufacturer, form factor, accounting unit, status). The purchase order number, supplier for a specific delivery and actual price belong in procurement and receiving documents, not in the equipment card.

Roles and responsibilities: who is accountable for what

For master data governance to work for equipment, directories must have clear owners and clear responsibility limits. Otherwise the argument over “who should fix the card” will take longer than the fix itself.

Data Owner is responsible for meaning. They define which objects and attributes are needed, what counts as “correct,” which values are allowed, and by what rules data changes. Typically this is a function leader: procurement head for materials, chief engineer or operations team for equipment, financial controller for accounting attributes.

Data Steward is responsible for daily operations. They accept creation and change requests, check completeness and correctness, look for duplicates, communicate with requesters and ensure that the Data Owner’s decisions are actually implemented in the records.

Data consumers (procurement, warehouse, TOiR, accounting, production) are not just “users.” They submit requests with business justification, attach sources, confirm outcomes and alert when data interferes with processes. It’s practical to assign one person in each team as responsible for the quality of requests.

IT and the integrator are responsible for systems: access and roles, ERP/CMMS/MDM configuration, integrations, change logging, format checks and backups. They should not decide how to name a material, but they must ensure the rule can be technically enforced.

Below is an example RACI for typical operations (R - does the work, A - approves, C - consulted, I - informed):

This setup reduces gray areas and speeds up approvals.

Change procedure: step by step

A single procedure is needed so changes to equipment and material cards don’t break accounting, procurement and maintenance. A good process does two things: it quickly handles simple edits and strictly filters risky ones.

1) How to submit a request

There must be one official intake point, even if there are multiple channels: service desk, form, request from ERP or TOiR. In any case the request should enter the MDM queue, receive a ticket number and an owner for processing.

2) What the request must include

A minimal set of fields is best enforced with a template so you don’t have to “extract” data from email threads:

• object (material/equipment), current code and desired action (create/change/close)
• which attributes change: before/after with effective date
• reason (error, new supplier, standard change, model replacement)
• confirmation: datasheet/specification, nameplate photo, supplier letter (where applicable)
• affected systems and departments (accounting, warehouse, TOiR, procurement)

3) Checks before approval

Before sending for approval the steward or MDM administrator performs quick checks: duplicate search by key fields (name, manufacturer, model, unit), format validation and checks against auxiliary directories (units, classifier, groups, codes). If duplicate risk is high, the request is returned for clarification or escalated to a merge scenario.

4) Approvals according to the matrix

The approval matrix should be simple: the Data Owner is responsible for meaning (what the object is), while business owners are responsible for consequences.

For example, the materials owner approves the name, classification and basic characteristics; procurement approves procurement‑related parameters; accounting approves accounting attributes; TOiR approves technical equipment fields.

5) SLAs and priorities

SLAs set expectations and help manage the queue. Typically three classes are enough:

• urgent (minor attribute with no accounting impact)
• standard (normal edit)
• complex (affects codes, accounting rules, integrations)

Basic metrics: average request turnaround and percentage of requests handled within SLA.

6) Publication and notification

After changes are made the record is published in the master system and delivered to consumers on schedule or by event. Notifications should include: what changed, effective date, who approved and whether users need to act (for example, update request templates or re-create an order).

To keep the process on track, it’s useful to review three directory quality indicators monthly: duplicate rate, completeness of critical attributes and request turnaround. They quickly show where the procedure works and where it’s being bypassed.

Rules for changing attributes: don’t break accounting

The main risk in equipment and material master data is not that a card looks “ugly,” but that after an edit the warehouse, accounting, procurement and maintenance diverge. Therefore each attribute should have a predefined class and change rules.

It’s convenient to split fields into three groups:

• Identifying: code, base unit of measure, object type, key links (for example, to a material group).
• Descriptive: name, extended description, notes, search characteristics.
• Classificatory: class/category, hazard indicator, equipment family, flags used in reports.

Names and descriptions need standardized templates. Fix the language, allowed abbreviations, word order (what comes first: type, model, size), and how to write units and numbers. Then “Cable UTP 5e 305 m” and “UTP cable cat.5e 305m” stop looking like different items.

Critical fields should be changed with versioning and history: what was, what became, who approved and which date the new version takes effect. This makes it easier to explain reporting discrepancies and to restore past states.

Some things cannot be changed retroactively: base unit of measure, tax and accounting flags, membership in a class if the object already has transactions (receipts, write-offs, repairs). Exceptions require a separate procedure: justification, impact assessment, corrective transactions and effective date.

Pay special attention to related edits. Changing manufacturer often triggers changes to model, catalog number, specs and sometimes procurement unit. The same applies to unit changes: switching from “pcs” to “m” without adjusting quantities will break warehouse balances and write-offs.

A practical pre-approval test: what will change in reports, balances, contract specifications and maintenance history if the new version becomes effective today?

Quality control: metrics and how to calculate them

It’s easier to keep directory quality in numbers. For equipment master data governance, 3–4 metrics are usually enough to see the real picture and quickly find problems across ERP, TOiR, warehouse and procurement.

Duplicate rate

Definition: the share of records that describe the same object (material or equipment unit) under different codes or cards.

Simplified formula: % duplicates = (number of duplicates / total number of records) x 100%.

In practice duplicates are found by keys: normalized name + manufacturer + model/part number + unit of measure, and for equipment by serial number + type + site/plant.

Thresholds depend on scale, but common benchmarks are:

• up to 0.5%: mature process
• 0.5–2%: requires root‑cause analysis and prevention
• above 2%: noticeable risk for procurement, warehouse and reporting

Completeness

Completeness is measured in two ways: overall across all fields and for critical fields. Critical fields are defined by the Data Owner with the business. For example, for a material: group, unit, VAT rate, supplier part number/manufacturer, hazard class (if applicable). For equipment: type, inventory number, location, status, commissioning date.

Formula: % completeness = (filled values / all required values) x 100%.

It’s useful to calculate completeness separately by source: ERP (main card), TOiR (technical attributes and operation), warehouse (packaging, batch, storage conditions), procurement (supplier, pricing unit, lead time). Make sure these fields aren’t confused with transactional data.

Request turnaround time

This metric shows how the change process performs. Calculate at least three numbers: average, median and 90th percentile (P90). P90 answers: “in 90% of cases we complete within how many days?”

To keep the metric honest, record dates in the ticket or MDM log: creation, start of processing, approval, entry, publication to systems.

A weekly mini‑dashboard for the Data Owner could include:

• % duplicates for the top‑5 material groups/equipment types
• completeness of critical fields (and which fields are empty)
• median and P90 for change turnaround
• number of rejected requests (and reasons)
• top sources of divergence (ERP, TOiR, warehouse, procurement)

A simple problem signal: if P90 for changes rises from 3 to 10 days while duplicate rate also increases, requests are bypassing rules (creating new cards instead of editing) or there’s a bottleneck in approvals. Then review required fields, creation rights and verification order.

Governance artifacts: what should be documented

Governance cannot rest on oral agreements. To keep equipment and material directories from drifting you need simple, documented artifacts to refer to in disputes, audits or staff turnover.

A minimal set usually looks like:

• Data dictionary: what an object is (material, assembly, component, equipment), attribute definitions, owners and examples of valid values.
• Catalog of allowed values: units, statuses, types, groups, manufacturers (where the list is fixed versus where extension is allowed).
• Validation rules: formats (for example, serial numbers), ranges (power, voltage), mandatory fields, bans on special characters and free text where a controlled list is required.
• Deduplication rules: uniqueness keys (manufacturer code + part number, EAN, set of key attributes) and rules for handling similar names and synonyms.
• Checks and reporting rules: how often checks run (daily, weekly, monthly) and where results are recorded.

Also document the access model. It should be boring and strict: the fewer people who can do everything, the fewer duplicates and accidental edits.

• creation of cards: limited circle, usually the master data team or delegated domain users
• editing attributes: by Data Owners (e.g., technical attributes — engineer, procurement attributes — procurement)
• read access: broad, without edit rights
• mass edits: only via authorized request and logged
• emergency edits: separate procedure with post‑incident review

It’s useful to declare which metrics are “official” and how they’re calculated: duplicate rate (duplicates / all records), completeness of mandatory fields, turnaround time for change requests (median and P90). Then SLA expectations don’t depend on who is on duty today.

Common mistakes and traps

The most costly directory problems often look like small things: “slightly edited the name,” “quickly created a new code,” “pulled data from Excel.” Later this turns into duplicates, wrong purchases, accounting divergence and disputed reports.

One frequent mistake is mixing equipment and materials in a single directory without clear rules. Serial equipment with a lifecycle and consumables that are tracked by packaging and units don’t belong to the same logic. If separation is required, encode it in the data model: different object types, mandatory attributes and different change rules.

A second trap is the lack of a “golden record.” When the same object is created under different codes (for example from different branches), duplicate rate rises and search and procurement become a lottery. You’ll see this in metrics: duplicates by key (name + manufacturer + model or part number) increase and completeness of critical fields drops.

Approvals can also “kill” the process. If there are too many approvers and unclear responsibilities, turnaround time balloons from days to weeks. Measure median processing time: from request creation to change publication.

Another risk is edits bypassing the process (admins or key users changing records directly). This is fast but destroys control: no history, no justification and unexplained divergences appear. Prevent this by forbidding direct edits on critical attributes and by keeping a mandatory change log.

People often forget to standardize units and packaging. The same material ends up as “pcs”, “pkg”, “kg”, making price and stock comparisons impossible. A short standard helps: allowed units, conversion rules and where conversion factors are stored.

Finally, don’t forget checks after loads and migrations. Even nearly clean source data can spoil a directory during a bulk import. After each migration check at least three metrics: duplicate rate, completeness of mandatory attributes and request turnaround (to see whether the process choked after the change).

Quick check: a 10‑minute checklist

If you only have 10 minutes, the goal is simple: find out if directories for equipment and materials have owners, rules and measurable control. Open the latest directory export and the change request log (even if it’s just a table).

Mini checklist

• Data owners are assigned and decision routes are clear. Each directory should have one Data Owner and one executor (Data Steward). Quick test: can you name the person responsible for “Materials” and “Equipment” without calling anyone?
• Mandatory attributes and a minimal “passport” are defined. Check 5–10 random cards. Are key fields filled (name, unit, group, manufacturer/model, code)? Metric: % completeness for critical fields (a common target is 95–99% for key fields).
• Duplicates are checked before creation, not after. Is there a duplicate check by attribute combination (for example name + manufacturer + model) or normalized name? Metric: % duplicates (practical starting target: less than 1–3% for the active portion of the directory).
• Change request turnaround is measured and explained. Take the last 20 requests and calculate time from registration to resolution. Metrics: average turnaround and % overdue. Record reasons for delays (missing data from requester, classification dispute, owner not approving).
• Regular checks and a short quality report exist. Not a yearly cleanup, but repeatable checks: list of duplicates, empty critical fields, disputed values. Minimum monthly report: three numbers — % duplicates, % completeness, median turnaround for changes.

If you answer “don’t know” or “we don’t measure” to two or more items, governance is already costing you: duplicate purchases, accounting errors, manual reconciliations. Start by assigning owners and tracking the three metrics above, then add rules and automated checks as you stabilize.

Practical example: how a material card change is handled

Scenario: procurement found a new cable supplier. The materials directory already contains several similar items: “Power cable 1.8 m”, “Cable 1800mm”, “Power cord 1.8m”. Creating another card will later break analytics, warehouse accounting and contractual prices.

A change or creation request should include minimal facts to avoid three days of email. Typically include:

• user description (as on packaging) and a short normalized name
• manufacturer and supplier part number (if available)
• unit of measure and packaging quantity (pcs, m, pkg)
• key distinguishing attributes (length, connector, cross‑section, color)
• purpose (procurement, replacement, delisting)

The Data Steward checks for duplicates: searches by supplier part number, normalized name and combination of key attributes. The steward also checks units: “m” and “pcs” are often mixed, and sometimes an item is created as a “package” though it’s issued by piece. If they find a match, they suggest linking the purchase to the existing card and adding missing attributes instead of creating a new one.

If the change is critical (for example changing base unit, material class, serial flag or tax attributes), the Data Owner decides. They assess the impact on accounting, prices, balances and contracts and either approve or return the request with comments.

One to two months after rules are applied you usually see metric improvements. For a materials directory, for example:

• duplicate rate drops from 6–8% to 2–3% (duplicates / all active items)
• completeness of required attributes rises from 70–75% to 90%+
• request processing times stabilize, e.g. median 2 working days, P90 5 days

Most importantly, urgent purchases stop creating chaos: instead of “quickly creating ad hoc records” there’s a clear route where speed doesn’t conflict with quality.

Next steps: rollout plan and support

Start with 1–2 most painful directories rather than all at once — usually materials (nomenclature) and equipment (units, assemblies, serials). It’s easier to agree on rules and see quick results.

A minimal 4–6 week plan:

• assign a Data Owner and a Data Steward for each chosen directory and record who approves changes
• write a short procedure: mandatory attributes, what cannot be changed after creation, what requires approval
• launch a change request queue (service desk or form) and define processing statuses
• set up quality measurement and a weekly report on metrics
• review the first 20–50 requests and refine rules

Keep metrics simple and regular. Minimum: duplicate rate (records that match on key attributes), completeness (share of mandatory attributes filled), request turnaround (average, median and P90). In reports show both absolute numbers and trends: what improved and why.

Agree SLAs and responsibilities with the business and IT up front. Business defines which data is authoritative and required timings. IT provides tools, integration and access control. Example split: simple description edits — 2 working days; changes to units or classification — require extended approval.

An integrator is often needed if data lives in multiple systems and synchronization is required, if you need approval workflows and quality checks, if there are bulk loads and historical cleanup, and if audit, roles and traceability are important.

Check infrastructure early: where will master data live, how is high availability ensured and who operates it. In projects like this GSE.kz (gse.kz) is often engaged as a system integrator: from selecting and supplying servers and workstations to organizing round‑the‑clock technical support for key systems.