Materials and MRO Registry: Directory Model and Duplicate Control

Why a large company needs a single materials and MRO registry

A single materials and MRO registry is not about “tidy data” — it’s about saving money, time and ensuring safe operation. Once the same item appears under different names, procurement and warehouse start living in different realities: they buy extra items, write off the wrong ones, and the needed part can be on another shelf under a different card.

Duplicates and inconsistent naming almost always cause three types of loss: extra purchases (because “the system shows none”), inventory mix-ups (the same object counted as different items) and downtime (a critical part exists but can’t be found and issued quickly).

Branches diverge in data very fast. Each has its own habits: some put the manufacturer in the name, others in a note; some create “bolt M8”, others “bolt M8x30 zinc-plated”. Without common rules and a single owner of the directory, local “convenient” solutions turn into shared chaos.

A clean directory settles disputes and provides a basis for decisions: whether a part can be replaced by an equivalent without risk, what stock levels to hold and where, what is truly critical for equipment and what replenishment lead times are acceptable.

The goal is simple: one material — one card — one version of the truth trusted by procurement, warehouse, maintenance and finance.

Roles and responsibility: who owns MRO cards

To prevent the registry from becoming a “warehouse of names”, it must have an owner and clear rules. The registry owner is usually a business unit: the department focused on the overall result across procurement, warehouse and operations (often procurement or production management).

Administration is most often handled by an MDM or IT team: card templates, access rights, statuses and data quality controls. Technical experts settle the most disputable question — applicability. They confirm parameters, criticality, usage conditions and the list of equivalents so there are no arguments later during repair or on site.

Procurement and warehouse are responsible for making sure a card can actually be purchased and received: units of measure, packaging, order multiples, marking requirements, and attributes for accounting and movement.

It’s useful to define a responsibility matrix where each card has a single “owner for the result” and a clear route:

• the initiator creates a request (branch, workshop, project);
• MDM/IT checks required fields, format and absence of duplicates;
• the technical expert confirms applicability and replacement conditions;
• procurement and warehouse confirm purchasing details (units, packaging, multiples);
• the registry owner approves and activates the card.

To avoid backlog, set SLAs and make them uniform across branches: new item — 1–3 business days, error correction — up to 1 business day, adding an equivalent or changing manufacturer — 2–5 business days, investigating a suspected duplicate between branches — up to 2 business days.

Card model: identity, statuses and life cycle

An MRO card should answer one question: is this the same item already in the registry or a new one?

Uniqueness is usually defined by purpose and key parameters (size, material, accuracy class, power, voltage, connection type), and by manufacturer and series where compatibility cannot be guaranteed without them. If the same bolt is acceptable from different brands, uniqueness is better based on parameters and standard, with manufacturer stored as an acceptable option.

Immediately separate object types. Material/item (what we buy and store) should not be mixed with service (installation, calibration), tooling (tools, jigs) or assemblies/kits (sets with a bill of materials). Each type has its own accounting and fields.

Keep the life cycle as statuses:

• draft (created but incomplete);
• under approval (registry, technical, procurement/warehouse review);
• active (allowed for use);
• obsolete (replaced by a new card);
• prohibited for purchase (cannot be bought but remains for history and stock).

To avoid the registry turning into back-and-forth communication, include versioning and a change history. Record at minimum: what changed (parameter, name, unit, tolerances), who changed it, date and reason. Example: “material clarified from AISI 304 to AISI 316 per operations request.”

A useful rule is the minimally sufficient card: to launch an item you need code, clear name, object type, base unit and key parameters. Other details (packaging, equivalents, allowed manufacturers) should be added versionally and only via approval to avoid breaking procurement and stock.

Code and name: simple rules that prevent chaos

The registry code must solve one task: unambiguously point to the card.

Two workable approaches:

• “code as ID” without meaning (e.g., 10–12 digits);
• “meaningful code” with group and type encoded.

On large enterprises the ID approach often wins: it’s simpler to scale and less error-prone for manual entry.

If you keep meaningful codes, fix the structure (length, separators, what each segment means) and don’t change it without strong reasons. In any case the rule is one: uniqueness is checked by the system, not a person. Forbid manual “picking a similar” code, otherwise branches will create almost identical cards.

Naming rules

Names should help find items in search and quickly distinguish them from similar ones. A consistent word order works well: item type — key parameter — size/model — material/finish — manufacturer (if critical).

Agree on language, case and abbreviation dictionary (for example “pc”, “set”, “stainless”, “zinc”), so “bolt M8” doesn’t become “Bolt m-8” or “BOLT M8”.

Classification and description

Groups and subgroups are needed not for “beauty” but for search and reporting: procurement, warehouse, maintenance, projects.

Add a short description with parameters commonly used in searches: size ranges, standard (GOST/ISO), strength class, thread type, voltage/power. Example: instead of “Power cable” use “Power cable, Cu, 3x2.5 mm2, 0.66 kV, non‑propagating flame”. This reduces duplicates and speeds up verification during requests.

Manufacturer and parameters: keeping important details

In the registry “similar” items may differ by part number, class, material or even country of origin. If these details aren’t recorded, procurement delivers the wrong thing, the warehouse records it inconsistently, and the technical team spends time selecting the right part.

Manufacturer: which fields and when they are mandatory

Separate “manufacturer” and “brand.” Brand can be the trade name; manufacturer is the plant or legal entity responsible for production.

A typical set of fields: manufacturer, brand, country, catalog number (part number). Make fields mandatory by rule:

• part number is mandatory for catalog purchases, especially in electronics, bearings and automation;
• manufacturer is mandatory when warranty, certification or compatibility matter;
• country matters when there are supply restrictions, localization or origin requirements;
• if there are multiple manufacturers (OEM/contract manufacturing), store “actual manufacturer” and “brand owner” as separate attributes.

Parameters: “catalog” and “operational”

Store technical parameters structurally, not inside a single text field. The minimal set depends on MRO class but commonly repeats: dimensions, material, class/version, power/voltage, temperature range, degree of protection.

It helps to separate:

• catalog parameters (as in the datasheet) — to buy correctly and verify delivery;
• operational parameters (for maintenance) — life, allowable loads, lubrication requirements, mounting conditions, compatibility with assemblies.

Attach documents as card attributes (for example, “datasheet”, “certificate”, “declaration”, “MSDS”) with number, date and version so you can check relevance without relying on links.

If the manufacturer is unknown, honestly set status to “unconfirmed” and fill parameters by fact (measurements, markings, photos of packaging). Later replace with confirmed data without creating a duplicate.

Units of measure and packaging: aligning procurement and inventory

A common cause of differences between procurement, warehouse and accounting is inconsistent unit logic. The card needs one base unit (pc, m, kg, l), and everything else as conversion rules.

Choose the base unit according to how the material is actually consumed: cable is usually consumed in meters, lubricant in liters or kilograms, fasteners in pieces. Buying in boxes is not a reason to make “box” the base unit.

Record packaging and order multiples in separate fields: container type, number of base units per package and order unit. Then receiving and accounting become transparent: 10 boxes arrived = 10 x 100 = 1000 pcs.

Don’t hide important details in notes: record pack sizes, minimum order quantity and conversion coefficient. Prevent common mistakes like “1 pkg” without clarification, “bucket” without volume, different units across branches (one records cable in coils, another in meters), and the most dangerous case — when “1 pc” sometimes means a package.

To avoid conflicts at receiving and consumption, agree a unified set of units and forbid free input. If a branch needs an alternative view (for example “coil”), it must be strictly linked to the base unit via a coefficient and applied identically across units.

Equivalents and interchangeability: documenting without disputes

Equivalents in the registry exist not for “procurement convenience” but so maintenance and repair don’t stop due to shortages or discontinued items. Disputes start where a card lacks clear replacement conditions.

Instead of a single generic “equivalent” link, distinguish types of interchangeability: full equivalent (1:1), allowed replacement (with limitations), temporary replacement (for the shortage period), recommended equivalent (better on availability or lead time). Make links directional: what can replace what, not just “they are similar.”

Applicability conditions and priority

A replacement link must have conditions: for which equipment or assembly, under which parameters (size, accuracy class, power, temperature, connector, material, standard). If conditions are not specified, branches will interpret them on their own.

For scarce items set priorities: what to buy first and what only if the primary is unavailable. This removes uncertainty for procurement and warehouse.

Restrictions and decision history

Record explicit prohibitions: what must not be replaced due to safety, warranty, certification or regulator requirements. A short reason is better than reconciling an incident later.

Keep a history of replacement decisions: who and when added the replacement, why (discontinued, shortage, price), for how long and who approved it. This keeps order between branches and allows quick rollback of disputed replacements.

Criticality: linking the registry to real operation

Criticality is an assessment of business risk if an MRO item is missing or unsuitable. People usually consider three things: safety of people and equipment, production or service downtime, and direct financial losses (penalties, missed deadlines, expensive emergency purchases).

A simple A/B/C scale stored in the card works well:

• A (critical): affects safety or stops a key process; no substitute or substitution requires lengthy approvals.
• B (important): downtime is possible but there is a workaround or replacement; losses are noticeable but not catastrophic.
• C (non‑critical): does not affect continuity of work; easily replaceable and can be bought off the shelf.

Criticality should be enforced by rules. For A items set higher minimum stocks, tighter control of lead times, mandatory checks of equivalents and packaging, and higher procurement priority. B and C get lower stocks and can be handled by regular planning.

Not everyone should be able to change criticality. A practical scheme: the initiator (operations/maintenance/warehouse) suggests a change with a brief justification, the registry owner reviews the card and history, and the final approval is given by the responsible person for reliability or production risk. Record reason and date.

The same MRO item may differ in risk across sites. Keep two fields: default criticality and local criticality per branch. This lets a 24/7 plant use different rules than an infrequently used office location.

Change approvals: step-by-step process and recordkeeping

To keep the registry consistent, changes must follow the same workflow across branches. Any creation or edit begins with a request and ends with publication plus a clear history of who and why.

A request should require the minimally sufficient data:

• proposed name and class (group, subgroup);
• manufacturer and base parameters (those affecting applicability);
• units and packaging (how it is bought and how it is accounted);
• proposed equivalents or a note “no equivalents”;
• attachments: datasheet, photo of nameplate or packaging, invoice/quotation if available.

Then a short flow mitigates risks at each step:

• initial data steward check: completeness, format, duplicate search by code, name, parameters and manufacturer;
• technical expertise: applicability, critical parameters, allowed equivalents and replacement limits;
• procurement and warehouse check: units, packaging, multiples, storage/transport conditions, “how it actually arrives”;
• registry owner approval: decision, status assignment, activation date;
• publication: notify branches and record the date from which the card is mandatory.

To prevent lost changes, record card version, author, reason and source (document, request). For disputed edits keep a short comment stating what changed: parameter, packaging, manufacturer, equivalent status.

Schedule regular reviews: quarterly or semi‑annually mark obsolete items, move them to “do not use”, assign replacements and close the possibility of creating new duplicates for decommissioned cards.

Controlling duplicates between branches: practical setup

To prevent the registry from spreading across branches decide early where cards are created and where branches only choose existing ones. The “single master” model usually works: a central team (or designated registry owner) creates cards while branches submit requests and use approved items.

Discipline in duplicate search is essential. Before creating a card the requester checks the registry by several attributes and the system helps: normalizes text (case, spaces, punctuation), uses a synonym dictionary (for example “bolt” and “screw” per your standards) and compares key parameters (type, size, material, manufacturer, part number).

A practical scheme:

• the request must include: proposed name, manufacturer, model or part number, 3–5 parameters, unit, packaging;
• an automated search for “similar” items with a similarity threshold and candidate suggestions;
• a manual review by a registry master if any close candidate is found;
• decision: create new, link to existing, or register as an equivalent.

If a duplicate already exists it should not be deleted. Merge it correctly: move stock, open orders, warehouse bin links and transaction history to the main card. Mark the duplicate as “closed” with a note to which item it was consolidated.

To prevent recurrence run regular duplicate reports and review them by roles (registry owner, procurement, warehouses) at least monthly and weekly for active branches.

How the registry works with ERP, procurement and warehouse

The registry pays off when it becomes the source of truth for ERP, procurement and warehouse. Then the same material is named, measured and consumed consistently across systems and branches.

ERP must align on base fields: code (or unique identifier), name, group/class, card status, base unit and packaging conversion rules. If the registry says “pc” and accounting uses “pkg”, procurement and warehouse will quickly diverge.

The most common source of duplicates is manual creation of nomenclature in ERP “for an urgent request.” A practical rule: block manual creation for most users; exceptions go through a short request with mandatory fields and a duplicate check.

Statuses must be visible to procurement: “obsolete”, “prohibited for purchase”, “stock-only”, “allowed only from approved manufacturers”. This reduces the risk of buying items the warehouse or maintenance can’t accept.

Minimal recurring reports: new cards and initiators in a period, changes and approvers, disputed equivalents, potential duplicates between branches, items “prohibited for purchase” but with active requests.

Example scenario: adding a new MRO item without creating duplicates

A branch services a pump assembly and needs a bearing not present in the registry. The requester files a new item request via a form that requires identifying fields.

They fill in: a temporary code (permanent code assigned by admin), clear name, manufacturer, part number, key parameters (type, size, accuracy class), unit, packaging (e.g., 1 pc; box of 10), and mark criticality for the assembly. Importantly they indicate how it’s actually bought and consumed: “pc” in accounting and “box” in procurement must be linked.

Before submission the system searches for matches: part number + manufacturer, similar parameters, similar names. It finds a “almost identical” bearing from another branch entered as “box of 10” with unit set to “box”. Essentially it’s not a new item but a different packaging and accounting logic.

The technical expert reviews both and confirms it’s the same model with different supply variants. They record replacement rules (if compatible manufacturers exist) and set priority: “primary — OEM, allowed equivalent — brand B if lead time > 20 days.” The registry admin keeps a single card, adds correct packaging and conversion coefficients, and assigns a final code.

Result: one registry item, clear packaging, consistent units, criticality reflecting real operation, and interchangeability documented so procurement and maintenance don’t argue.

Common mistakes and pitfalls in managing the directory

The first mistake starts at card creation: instead of structured parameters people write free text “as they are used to.” The same item is described differently, search fails, and comparison becomes manual work.

The second trap is the “universal” card. When multiple similar items are lumped into one “just in case” card, procurement cannot know what to order, the warehouse can’t track stock correctly, and maintenance isn’t sure the part fits.

Another big pain in large companies is inconsistent units and packaging across branches. One branch records cable in meters, another in coils, a third in kilograms, and there are no agreed conversion coefficients. Reports show spikes and combined requests compare incomparable quantities.

Equivalents are often added as “seems to fit” without applicability conditions and without an owner. Example: a bearing of the same size may only be equivalent under certain load and temperature conditions. Without that note they’ll buy a cheaper part and downtime will cost more.

Ensure the registry forbids:

• changing criticality without approval and a history record;
• adding equivalents without applicability conditions and an owner;
• changing units and packaging without approved conversion rules;
• merging different items into a single card;
• storing key parameters only in the description.

A good habit: any edit affecting procurement, warehouse or safety goes through a short approval and leaves an audit trail (who, what, why, and effective date). This reduces disputes and speeds incident resolution.

Short checklist and next steps

Start with quick checks. Ensure each card describes one specific item, not “approximately the same”.

If any key field is missing or disputed, stop and clarify rather than creating a new position:

• code and clear name without excessive abbreviations;
• manufacturer, part number and primary parameters (what distinguishes it from similar items);
• unit and packaging (how it’s bought and how it’s accounted);
• criticality (does absence affect downtime, safety, quality);
• equivalents and interchangeability with application rules (what can be replaced and when it cannot).

Then assess registry quality with numbers. Useful minimum metrics: share of duplicates, share of empty key fields (manufacturer, part number, parameters), median approval time. These metrics quickly show whether the issue is data discipline or the approval process.

Before launch agree rules and document them in one place: abbreviation dictionary, code mask, roles (registry owner, expert, procurement, warehouse), card statuses and a unified change request template. For branches the main rule is: a new item is created only after searching by code, name, part number and parameters.

A typical rollout plan: pilot on one MRO group (fasteners or spare parts), set up approvals and duplicate control, clean existing cards, connect 1–2 branches and test inter‑branch control, then expand to other groups and sites.

If you need a partner for integrating the registry with ERP and building data management processes, system integrators often take this on. In Kazakhstan such projects, including infrastructure and support, are provided by GSE.kz (gse.kz) — as a manufacturer and integrator that covers the full cycle from architecture to maintenance.