Engine Shop Visit Management Software: Why Teardown Findings Destroy Your Quote and Your Turnaround Time

Why an engine shop visit is a project, not a work order

A customer engine arrives on a stand with a quoted workscope: performance restoration, one module, a target turnaround of ninety days, a not-to-exceed number the customer signed. Teardown starts. By day nine the induction borescope findings have become hardware findings: HPT blade distress worse than expected, a combustor liner beyond repair limits, a compressor case crack needing a repair scheme nobody quoted. The workscope you sold and the workscope the engine needs have separated, and the person who knows by how much is a foreman with a clipboard.

Meanwhile forty-odd piece parts have gone to specialist vendors for plating, welding and coating, each with its own promise date, tracked by a planner on a spreadsheet with a phone in the other hand. Three LLPs have enough stub life to be worth a great deal to somebody, but they will be replaced anyway because reissuing them means a paperwork chain nobody has time to build. And when the engine ships, someone constructs an invoice separating quoted work, approved additional work, warranty and vendor pass-through from records captured on paper across ninety days.

Ramco Aviation Suite, TRAX, Component Control Quantum Control and IFS Maintenix all appear in engine shops and all do real work. The consistent gap is not quality, it is shape. Those systems were built around aircraft-level maintenance and component repair, where the unit of work is a task on a part. An engine shop visit is a project with a bill of work that changes daily, a serialised genealogy several levels deep, a supply chain of outside processors, and a contract wrapped around all of it. The suites hold the parts and the labour. The project lives on the clipboard.

Problem 1: the workscope decision has no model, so it has no history

Deciding a workscope is the highest value judgement in the building. You balance what the customer will pay, what the engine needs to reach its next interval, what LLP cycles remain, margin restoration targets, and what the operator plans to do with the aircraft. Senior engineers make the call from experience, and the reasoning disappears the moment they make it. Six months later, when an engine comes back early, nobody can reconstruct what was considered and rejected.

The incumbents record the workscope as a task list, which is the output of the decision rather than the decision. They do not hold the alternatives, the assumptions about remaining cycles and margin, or the commercial constraint that shaped the choice. So the same shop makes the same judgement thousands of times and never accumulates evidence about which judgements were right.

What a custom build does: capture the workscope as a versioned document with the inputs attached, meaning incoming condition, LLP cycles remaining by part, customer intent for the asset, and the commercial envelope. Every later change references the version it changed from. Two years in you have something no vendor product can give you, which is your own shop's history of workscope decisions against actual outcomes, and that is what lets you quote the next one with confidence instead of instinct.

Problem 2: piece part routing to outside vendors is run by spreadsheet and telephone

A single visit can send hundreds of piece parts through outside processors: plating, brazing, welding, coating, machining, NDT. Each has a router with sequenced steps, some in-house and some out. The parts that come back late are the parts that hold the build, and the build holds the engine, and the engine holds the turnaround commitment you are contractually on the hook for.

Repair station software handles a vendor repair order as a single line. That works for a component shop where a unit goes out and comes back. It does not work for engine overhaul, where the question is which of the two hundred parts in the LPT module build set are still out, who has them, whether the promise date slipped, and whether the build can start without them. Quantum Control does purchasing and repair orders competently, and it remains a purchasing view rather than a build readiness view.

What a custom build does: model the router properly, with each part carrying its sequence of operations and its current location, in-house station or named vendor. Then build readiness becomes computable. The kitting screen shows the module build set with everything green except the three parts still at the coating vendor, with the promised date and the days it has slipped. Shortage escalation stops being an act of individual heroism by a planner who happens to remember.

Problem 3: LLP genealogy and stub life is money sitting in a box

Life limited parts carry cycles, and cycles are money. A disc with substantial life remaining is a valuable asset, and reissuing it requires an unbroken back to birth record: every operator, every shop visit, every cycle accumulation, supported by the tags. When the chain is doubtful, the part becomes scrap in practice even when it is serviceable in fact.

The suites track LLP cycles at part level. What they handle poorly is genealogy across ownership and installation history, particularly when the engine has passed through several operators and the trace arrived as a folder of scans. Nor do they model stub life as an inventory position you can market, which is what it is.

What a custom build does: LLP records that carry the full installation history as an append-only chain, with the supporting document attached to each cycle accumulation event rather than filed separately. The system knows the difference between cycles it can prove and cycles it inherited from a statement, and it says which is which, because that distinction is exactly what a buyer or a lessor will challenge. Stub life becomes visible as a position: which discs are coming out of which visits, with how much life, and what that is worth against your own pool requirements.

Problem 4: non-routine growth runs ahead of customer approval

The commercial risk in an engine shop is concentrated in the gap between finding something and getting paid to fix it. Findings arrive continuously through teardown and inspection. Customer approval arrives in batches, by email, sometimes days later. Work often starts before approval because the turnaround clock is running, and then the argument happens at invoice time.

No off-the-shelf system we have seen makes this loop first-class, because it is half technical and half commercial. The technical side sits in the MRO suite, the commercial side in email and a quoting spreadsheet, and the join is a planner copying between them.

What a custom build does: a finding becomes a structured record at inspection, with photographs, disposition, repair scheme, estimated hours and material, and a price. It reaches the customer through a portal with a visible clock, and the shop sees work performed without approval as a live number rather than a quarterly surprise. Shops discover two things: approval turnaround is slower than they believed, and some performed work was never billed because the approval email existed but the invoice line did not.

Problem 5: back to back warranty terms nobody can apply at speed

You warrant your work to the customer. Your vendors warrant theirs to you. The OEM warrants some parts. When a part fails during a subsequent visit, whether it is chargeable depends on which of those terms applies, and that answer is buried in a contract PDF and the previous visit's records.

What a custom build does: encode warranty as structured terms attached to the work performed and the part serial, so that when a serial reappears the system already knows the shop visit that touched it, the vendor who processed it, the applicable period and the remaining coverage. This does not remove the negotiation, it means you enter it with evidence in an hour rather than a week, and shops recover materially more vendor warranty once they can see it without digging.

What this costs and how long it takes

A first release covering teardown findings at module and part level, workscope control against the quote with customer approval, and piece part routing with build readiness runs $90,000 to $200,000 and ships in 14 to 20 weeks. A full platform adding LLP genealogy with back to birth evidence, warranty terms, vendor management, turnaround analytics and customer portal runs $300,000 to $750,000 phased over 9 to 18 months.

What drives cost up in engine shops: the number of engine families, since module structure, LLP list and workscope logic differ by family. Integration to an existing suite you keep for materials and finance. Vendor connectivity, because every outside processor is a separate conversation. Test cell data capture, if performance results should attach to the visit rather than sit as a PDF. And customer contract variety, because a lessor, an operator and a pooling arrangement carry different approval and billing rules. What holds cost down: one engine family and the visits you run most, leaving the rest on your current process until the model has earned trust on the floor.

Build versus buy, and when buying is right

Buy if you are an operator who removes engines and sends them out. Your need is removal tracking, cycles and invoice reconciliation, and TRAX or Quantum Control will cover that. Buy if you run a component shop where the unit of work is a single accessory in and out, because that is precisely the shape repair station software was designed for and you will fit it well.

Build when two or more of these are true. You run enough shop visits a year that turnaround performance is a commercial differentiator rather than an operational detail. Your workscope quotes are regularly overrun by teardown findings and you cannot show a customer a clean audit trail of what changed and when they approved it. Your piece part flow through outside processors is tracked in a spreadsheet that one planner owns. You are scrapping or writing down LLP stub life because the genealogy is doubtful. Or you carry back to back warranty exposure between customers and vendors that is currently settled by argument rather than by record.

Our honest position: engine shops are one of the few places where a serious custom build is usually correct rather than a vanity project, because the unit of work differs from what the market builds for. A shop visit is a construction project with a serialised bill of materials and a contract attached, and software built around aircraft tasks will always model that at one remove.

How to choose a developer for engine shop software

Ask them to draw the data model for a shop visit before you sign anything. The right answer has engine serial, module, sub-assembly, serialised part, LLP with cycle history, router operation, vendor repair order, finding, workscope version and customer approval, and they will know that the finding and the approval are the commercially dangerous pair. A developer who draws work orders and parts has built a repair shop system and does not yet know what a module build set is.

Ask how they will represent stub life and back to birth evidence, and specifically how they will distinguish cycles you can prove from cycles you inherited on a statement. If that distinction does not occur to them, it will not exist in the system, and it is the first thing a buyer challenges.

Ask what they have integrated, naming the specific system and interface: test cell output, a materials system, vendor portals and finance are four different problems.

Ask who owns the code and settle it before kickoff. You should hold the repository, the infrastructure accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. In an engine shop the system ends up holding the evidence behind asset values in the millions, and any arrangement where a vendor controls access to that is not a commercial risk you should accept.