Should an MRO Shop Automate Work Order Intake Before or After Fixing Its Parts Master Data?

Everyone says data first. Check who is saying it.

You run a repair station or a component shop. Work orders arrive as emails, portal exports, PDF repair orders and the occasional phone call. Someone in customer service re-keys each one into your maintenance system, looks up the part, guesses at the description when the customer's part number does not match yours, and moves on. It takes hours a day, it is the first thing a new hire is handed, and it is the obvious place to put automation.

Then you search the question and the answer comes back unanimous: fix your parts master data first. Every result on page one says it. Every result on page one also sells master data cleansing.

That does not make the advice wrong. It makes it unexamined. Nobody on the sell side tells you how to find out whether your parts master is actually the constraint, because the honest answer is often that it is not, and there is no product in that answer.

Why the advice exists at all

The mechanism behind "data first" is real and worth understanding before you decide whether it applies to you.

Automated intake works by matching what the customer sent to what your system knows. When the incoming record carries a clean part number your master recognises, matching is trivial. When it carries a free-text description, a superseded number, or a customer's internal code, the automation has to match on description. Description matching against an uncontrolled parts master does not find the right record. It finds the nearest one, which in a master with duplicates is frequently a second copy of the same part under a slightly different name.

A person doing intake by hand notices this. They see two candidate records, recognise them as the same part, pick the one with the stock, and maybe mention it to someone. An automated process does not notice. It picks one, creates a work order against it, and does the same thing again tomorrow. The duplicates were already there; the automation just starts building work history on top of them faster than anyone can see it happening.

So the sequencing warning is legitimate. Automating intake against a bad master does not surface the mess. It propagates it. That is the part the vendors have right.

The part they leave out

What they do not say is how bad the master has to be before this matters, or how much of it has to be fixed.

The published figures on duplicate rates come from inventory cleansing projects, and they are consistent. Reliable Plant's analysis of a multi-site MRO inventory program reports duplicates typically running five to fifteen percent of items at a single site once the data has been cleansed, with around nine percent found in their four-site pilot. SPARETECH, a master data vendor, cites a seven percent duplicate rate cleaned out of one automotive supplier's global material master. Industry estimates for large multi-site networks run higher, in the ten to twenty percent range.

Take those figures at face value and you have a parts master where somewhere between one in twenty and one in seven records is a duplicate. That is a real problem for inventory value. Whether it is a problem for intake automation depends on a different question entirely: are the duplicated part numbers the ones your work orders actually touch?

In our experience they usually are not. Duplicates accumulate in the long tail. They come from a one-off job three years ago, a plant that was consolidated, a buyer who could not find the record and created a new one. The parts that carry most of a shop's work orders are the parts everyone knows. They get looked up daily, they are the ones an experienced intake clerk can type from memory, and they are the ones that have already had their duplicates noticed and worked around, because someone hit them repeatedly.

The mismatch is between the scope of the fix being sold and the scope of the fix intake needs. A master data program cleans the whole master because that is what the product does. Intake automation only needs the records that intake will hit.

The concentration test

Before you commission anything, run one query. Take the last twelve months of work orders and count how many distinct part numbers account for most of them.

We cannot give you a public figure for what that concentration looks like across the industry, because none exists, and a number we made up would be worth less than the query you can run this afternoon. What we can tell you is what it looks like from the inside. In component shops with a defined capability list, the concentration is steep. A few hundred part numbers carry the bulk of the volume, and the master has tens of thousands of records. In shops with broader scope, or with a lot of one-off customer-furnished parts, the tail is fatter, and the test tells you that too.

The result decides the sequence. If a few hundred part numbers carry most of your intake, then the master data work that intake automation depends on is a few hundred records. That is a week for a quality engineer and a spreadsheet, not a program. Clean those, put a rule in front of new-record creation so the list does not regrow, and automate intake against the cleaned core. Route anything that falls outside it to a person, which is what already happens today.

If the test comes back flat, with no concentration and a long tail of parts each seen a handful of times, then description matching is going to be the automation's main job rather than an edge case, and the master data warning applies in full. In that shape we would usually tell a client to leave intake manual for now and look at where the hours actually go, because it is often not the lookup.

The concentration test is less than an hour of work. It is the difference between a scoped cleanup and a master data initiative, and no vendor will suggest it because the initiative is the sale.

What actually goes wrong at intake

There is a second reason to be sceptical of "data first," which is that parts master quality is rarely the largest source of intake errors. It is the most visible one, because a wrong part on a work order is easy to point at. It is not the most frequent.

The intake failures we see most often in repair stations are upstream of the part lookup. The customer's repair order references a serial number that does not match the unit in the box. The requested workscope is ambiguous, "repair as necessary" against a component with three levels of overhaul. The purchase order arrives after the unit, so the work order is opened without commercial terms and someone has to go back and fix it. The customer's portal export has a field mapped wrong and every order from that customer has the same defect.

None of those are master data problems. All of them are the reason intake takes the hours it takes. An automation project that treats intake as a parts-lookup problem will fix the lookup and discover that turnaround did not move, because the units are still sitting in receiving waiting for someone to resolve a workscope question. We wrote about the same pattern in manufacturing, where exception handling is the automation blind spot and the exceptions are what consume the people.

This matters for the sequencing question because it changes what "fix the data" means. If your intake delays are workscope and paperwork problems, cleaning the parts master will not shorten them. The data you would need to fix is the customer-facing intake form and the mapping from each major customer's system, which is a smaller and different project than anyone is quoting.

Why this is a live question now

Turnaround is the number your customers are watching. Oliver Wyman's 2026 MRO survey, drawn from more than 150 aviation professionals, reports narrowbody engine turnaround times regularly at 180 to 200 days or more, with piece part availability, repair capacity and labour the leading causes. Intake is a small slice of that, but it is the slice a shop fully controls, and shaving days off the front of the process is cheaper than buying capacity at the back.

The same survey found more than half of respondents describe their companies as stuck at the experimental stage with AI, and only around a third plan to invest in the IT infrastructure that would let the experiments run on real data. That is the parts master problem stated from the other direction. A shop that automates intake on top of an unexamined master is running an experiment that will produce confident wrong answers, and the survey suggests most of the industry is currently doing exactly that.

The honest reading is that the data warning is correct, the scope being sold under it is not, and the shops that get this right will have done the concentration test before they took a meeting. Automating intake before the master is ready is a bad idea. Cleaning the entire master before you automate anything is a different bad idea, dressed better. We have written before about the cases where a process fix beats a tool, and this is one where the process fix is a few hundred records and a creation rule.

Rebuilding a parts master from scratch is, after all, a very long way to go to find out you already had the part.

The question we would actually ask

Not "should we fix the data first." The question is: which records does intake depend on, how many of them are wrong, and what is causing intake delay that the part lookup does not explain. Those three answers set the sequence, the scope, and the budget, and none of them are on page one because none of them sell software.

Getting them takes a week inside your work order history and your intake queue, and an honest read on which of your delays are data and which are process. Shops in regulated aerospace already carry a heavy fixed cost in compliance hours that come out of the same headcount. Spending more of that headcount on a master data program that intake did not need is the failure we are trying to help you avoid.

If your intake team is spending its day on lookups and re-keying and you are deciding whether the parts master has to come first, talk to us. We will tell you which part of it actually does.