How MRO repair shops source parts from a work order


TL;DR

A repair can sit still while its information moves through teardown, purchasing, receiving, and quality. Several operators showed us the same problem from different shops: parts were requested, but nobody could see the full sourcing picture from the work order. We listened and built rapid intake, a digital BOM, and work-order sourcing to keep the repair and its material connected.


Every time we sit down with a repair shop, I ask them to show us the work. Skip the presentation and the clean audit map. Show me the box arriving, the technician tearing down the unit, and what happens when they need parts they don’t have.

That’s usually where the real story begins.

The names and parts change. The burden doesn’t. From receiving to release, people carry the job between departments because the system doesn’t carry enough of it for them.

The conversation excerpts below are taken from the calls and lightly cleaned for readability. Names and company identities have been removed.


The repair starts before the repair

A customer sends in a unit. One operator told us that 90% to 95% of their repairs begin before a formal quote. Receiving opens the box, verifies the part and serial numbers, checks for damage, records the instructions, prints the paperwork and tags, and routes the unit into the shop.

The technician hasn’t touched the repair yet, and several people have already touched the information.

The unit moves into inspection, pretest, or teardown. Somebody records the findings, labor, and parts. Familiar language gets typed again. Status changes depend on memory. Pictures get uploaded later. The physical packet becomes the shop-floor record while the system waits.

These are experienced aviation people doing what the process requires. Too much depends on a person carrying forward information the system already had.


Two repair shops, two variations of the same burden

One shop was small and specialized. Its technicians wanted to work on parts, not explain at a computer what they had just done with a wrench. The operator said it plainly:

“Technicians hate to do paperwork. Technicians hate to use software. Technicians just want to work on a part.”

Repair operator B

The shop used printed packets, barcoded forms, and people updating the system as work moved. That affected reporting:

“There’s a lack of system discipline on our side of when things are moved and making sure that step is changed in the system. We’re very small. We don’t have somebody to sit there doing transactions, and not everybody always remembers it.”

Repair operator A

The other shop had a larger procurement problem. Teardown produced long parts lists, including stock, sourced material, and outside processing. The operator described it from the work-order screen, where his team lives:

“We may have two different part numbers, and those part numbers have 30 different parts that we’re procuring for each one. The purchase team needs to be able to see what’s coming in, when it’s coming in, in a quick manner, without printing all these different things.”

Repair operator B

Both operators wanted the same thing: a clear next step for technicians, full demand for purchasing, a complete record for quality, and a status management could trust.

That’s what we hear over and over again.


Follow one missing part through the company

Imagine the technician tears down a unit and finds four parts that have to be replaced. One is in stock. Three need to be purchased. This is how one operator walked us through what happens next:

“She has to go out, get each one of these part numbers, put them in ILS, and run them. She grabs all these part numbers, goes into ILS or the marketplace, gets the pricing, comes back here, and puts it in. Then we add the labor and markups and create the actual quote that’s going out to the customer. If and when they approve it, she has to create the purchase order manually.”

Repair operator C

The other operator showed the same handoff from the work-order side:

“I can see requested, requested, issued, issued, issued, requested. Some of these we’ve issued to the work order. Some of these we’re still sourcing. But I don’t have any idea where we are in sourcing. We went out to ILS, the vendor quoted us $69, and now I’m just entering that back in. I still have no visibility on the work-order screen.”

Repair operator B

One missing part crossed operations, purchasing, the vendor, receiving, inspection, inventory, accounting, and the repair floor. Each handoff created another chance to re-enter or reinterpret its cost, certificate, due date, or status.

And the repair sits while all of that happens.

This is why repair shops export to Excel despite having an ERP. The spreadsheet shows which jobs await parts, which PO is late, which vendor answered, and which customer date is at risk. Excel is evidence that the operation needed another view of the same work.


We challenged the process, then we listened

The question underneath every call was simple: why is a person doing work the system already knows enough to do?

If receiving entered the customer, unit, repair order, requested work, and condition, why rebuild the record? If teardown identified the parts, why should purchasing recreate the demand elsewhere? If the BOM knows the labor, material, tooling, and sequence, why start from a blank page? If the vendor quote includes price, condition, trace, and documents, why type it into a quote and then a PO?

The operators were showing us the problem. One described purchasing in plain language:

“We’re super manual with sourcing. We add all the parts, and we print off some type of parts availability list that shows what we have in inventory and what we don’t have. We could have 20 of these units that need 10 different parts. We’re trying to keep track of that so the team can source efficiently, buy efficiently, and when quotes are approved, buy them and issue them to the work order.”

Repair operator D

Their requested future state was just as specific:

“If we make an RFQ for however many parts are in a work order, that could translate into multiple vendor RFQs through ILS that go out and come back into the system. That’s going to save so much time.”

Repair operator C

I didn’t want that request translated into a generic feature list. I said so on the call:

“Before anything gets lost in translation, I want our next call to be about your process. I want to visualize what you’ve talked about. I want to visualize what we can do to mirror something that you like or something that you need.”

Ralph

Those requests didn’t go into a someday file. We built them.


What changed after those calls

Repair intake can now create the connected records the process requires and take the user directly into the work order. The follow-up demonstration showed the change:

“When we click submit, it validates the data, creates the sales order, pulls all the details into it, creates the part transfer, and completes all the steps the system requires to proceed. It completes it with a single button, and once you’re done, you get redirected directly to the work order.”

Post deployment call

Receiving enters the operational facts once. Inspection, work request, teardown, and pretest can use controlled clauses while preserving unit-specific detail.

The digital BOM carries repair knowledge forward: parts, labor, operations, prerequisites, technical documents, tooling, authorizations, checklists, and certification. The work order no longer starts from memory. It carries assigned tasks, sequence, progress, and material requirements.

Most important for the repair shops we heard from, sourcing can begin from the work order. The demonstration followed the exact handoff they had described:

“You select the valid vendor quotation for this part, and once you click create, it generates the purchase order. That purchase order and that particular line are linked to the work order. Within the work order, you can see that the part is already on order.”

Repair operator G at Deployment

The buyer can see inventory, prior pricing, and outside availability, send RFQs, receive responses, select a source, and generate the PO with each line tied to the repair. Purchasing can see combined demand instead of buying one job at a time.

When material arrives, receiving and inspection update the same transaction. It moves from ordered to delivered, inspected, and issued without another tracking sheet.

The upgrade keeps judgment with people and removes work created by disconnected information.


The supply side and the repair side are one operating chain

Repair sourcing uses the same supply-side workflow that handles a normal parts RFQ.

An RFQ can come from email, ILS, PartsBase, another marketplace, a website, or a person on the phone. The supply-side demonstration made that entry point explicit:

“All of your RFQs from all of the sources, from email, from PartsBase, from ILS, from all of the marketplaces, are going to come in here.”

Repair operator F

The user sees vendor history, marketplaces, inventory, incoming material, catalogs, consignment, alternates, kits, and repair BOM demand. They can quote, carry documents and trace forward, create the PO, receive and inspect, ship, invoice, and preserve the history.

For a repair shop, the chain continues through intake, teardown, sourcing, approval, purchasing, receiving, issue, repair, test, certification, 8130, shipment, and invoice. Each department sees the same job and its next requirement.

People call this automation. The larger issue is connectedness. The next step should know what happened in the previous one.

That’s what the operators were asking us to build. They weren’t asking for software to repair the unit for them. They were asking it to stop losing the repair between departments.

If you run an MRO or repair shop, show me the transaction. Start with the box. Walk through teardown, sourcing, purchasing, receiving, repair, release, and shipment. We’ll count how many times your people carry the same information twice.


I’m Ralph Merhi. At ERP.Aero, I ask repair shops to walk us through the actual transaction, from the box at receiving to the 8130 and invoice. Those conversations shape what we build: intake that starts the work, a digital BOM that carries the scope, and sourcing tied to the work order. If your team still has to translate a repair between departments, show us that handoff.


2252 Hayes Street, Hollywood, FL 33020
Unsubscribe · Preferences

Ralph Merhi,

Practical insights for aviation suppliers, distributors, brokers, and manufacturers who refuse to settle for inefficiency. I believe in cutting through the noise—delivering real strategies to make things better. No fluff, no wasted time, just the knowledge, both business and personal, and tools to help you succeed. If you want my newsletter, drop your email below 👇 or feel free to look as much as you want.

Read more from Ralph Merhi,

The cost of less. Run one real RFQ before you compare ERP prices Imagine this. A customer sends an RFQ by email with 18 line items, different conditions, a requested delivery date, and a note asking for trace documentation. Your salesperson opens it, and right there, before a single price is built, you're going to find out whether the system carries the transaction or whether the team carries it. If the salesperson has to read every line, then re-enter the part numbers, create or match the...

If People Are the Integration Layer, the Workflow Is Not Native The Sentence That Won't Leave Me Alone I've been saying this to myself for weeks now, so I might as well say it out loud. If people are the integration layer, the workflow is not native. Say it again slower. If a human being is the thing standing between one system and another, copying a number from here to there, retyping what somebody already typed, carrying an answer from one inbox to another inbox because the two inboxes...

Best ACPC yet!

ACPC - Best One Yet. What If AI Didn’t Have to Fix Your ERP First? TL;DR This article builds on a previously published story about a question I keep coming back to: what if AI didn’t have to fix your ERP first? ACPC 2026 gave that idea new weight. People are not tired of AI, they are tired of being told they need AI to compensate for workflows that should have been sophisticated from the start. This piece looks at what becomes possible when intelligence inherits connected transactions,...