By Berend Booms, Associate Editor | Future of Assets
In June 1990, British Airways Flight 5390 left Birmingham Airport and was headed toward Málaga with 81 passengers and 6 crew on board. At 17,000 feet, the left cockpit windscreen blew out. The captain was sucked halfway through the opening, initially only kept in place by his seatbelt. A flight attendant grabbed his legs and held on for twenty minutes while the co-pilot managed to land the plane. The captain survived, frostbitten and bruised.
The windscreen had been replaced the day before. The investigation later found that the replacement bolts were nearly identical to the ones the job called for, with the maintenance failure stemming from 84 undersized A211-8C bolts and 6 too-short A211-7D bolts, instead of the correct A211-8D. While the spec said like for like, what went in was close enough to pass a glance, but not close enough to hold.
This incredible story was shared with me by Conrad Greer. He tells it because it is the clearest illustration of a problem he has spent most of his career trying to solve: what happens when the identity of a physical part gets lost between the person who knows exactly what they need and the software record that is supposed to represent it.
What the Navy Got Right
Conrad started his career in the Navy, spending 20 years operating and maintaining industrial systems, steam plants and generators among them. It’s a straightforward ordeal as far as strategy is concerned: you run the ship's plant yourself, and you maintain it yourself. If something broke in the middle of the ocean, the Navy had already thought that through. Critical spares were carried on board, well identified, ready to go. It worked so well that the beauty of it was invisible. It was only outside of the Navy the challenge of getting spare parts right became apparent.
When his commission ended at the close of the Cold War, Conrad moved into enterprise software as a functional consultant, occupying a space he identified as belonging to the person who sits between whoever has the business problem and whoever writes the code. He landed in the province he grew up in, home to a concentration of oil and gas headquarters, and spent years on ERP implementation projects with maintenance and supply chain teams. This is where his interest in spare parts management surfaced, as he witnessed how the supply chain teams he now worked with bought and warehoused parts in a way that felt “not very good.”
Twenty Years of Learning What Doesn’t Work
Understanding what “not very good” looked like came in stages, each one offering a more direct lesson than the last. Early in his consulting career, he watched a client wrestle with consolidating parts records from seven independent systems into one new ERP. The client's own material master owner had no tool and no method for matching parts records to each other across those systems, even though that had been a significant premise of the sales pitch: visibility across every plant. From the outside looking in, it was possible to discuss field definitions and data structure, but the underlying problem with unmatchable data sets was one that was unsolvable by anyone in the room.
Yet another project revolved around the merger of two refineries running the exact same control systems. Conrad recalls how he expected real overlap in their spare parts, but ultimately found little. Frustratingly, even though the parts were the same and the plants were similar, the records had no way of telling him that.
The real turning point came when Conrad was hired by a firm to be their material master subject matter expert, on a mandate to build enterprise-wide data standards. He found that the team was scoring spare parts records on how many mandatory fields were filled in, a measure that said nothing about whether anyone could actually find or manage the part it described. When he pushed on the quality of the descriptions themselves, Conrad was told that the descriptions were too far gone to fix, so they would simply be ruled out of scope. Not willing to put his name on a project that had decided to look away from the one thing that mattered the most, Conrad quit or got fired from the assignment that same day, depending on who tells the story
That’s the moment studying turned into building: Conrad poured his time and energy into developing a way to address the problem properly, before he started figuring out how to bring it to the people who needed it, which is the work he is doing now.
Findability and Comparability
I asked Conrad what tips him off walking into a new organization, and he explained it’s seeing them generating hundreds of new spare parts records a month, while the plant has run on the same equipment for decades. That, for him, is the signal that the real source of the mess is upstream, baked in from the moment a part finds its first use in the business.
He reduces the whole problem to two words: findability and comparability. Findability is what a maintenance planner or technician might run into at the search bar, typing in a size and a pressure class and getting nothing back, only to realize the same two attributes were entered in reverse order when the record was created. Comparability is the deeper failure underneath it: the hidden duplicate. A field like manufacturer part number, a key identity may sit blank on 40 to 50 percent of legacy records in some organizations. Blank fields never produce a match, so the system logically assumes every new part is unique. That's how a warehouse ends up holding seventeen of the same item, yet the technician still can't find one when it’s needed for an urgent repair.
None of this is anyone’s fault in particular; according to Conrad, it is traceable to how enterprise software itself was built. The vendors behind modern ERP systems have come to be very good at standardizing operational workflows, business processes, purchase orders, receipts of goods: the connective tissue of running a company. Master data has always been treated as the client’s problem and responsibility, something that’s theirs to understand and own. Putting spare parts into a shared, enterprise-wide database with useful identification rules is not a problem organizations have expertise in, and that gap has been compounding since systems first started centralizing data beyond a single plant.
The costs go well past the dollar figure a finance director tracks in rising inventory value. Conrad points to the daily friction between maintainers and buyers, with warehouse staff caught in the middle, all pushed into avoidable opposition over a problem none of them created. When the boiling point is reached, the consequences turn into front-page headlines, as Conrad illustrates by telling me about the British Airways windscreen failure and a refinery explosion that was traced back to a drain line built from the wrong-spec material. In both cases, a wrong-spec part slipped through the system.
A Part Is Not Inventory
Conrad’s real argument moves beyond ‘just tidying up’ descriptions. According to him, a spare parts record is more than an inventory record. Although most spare parts will have a count, a bin location, and a reorder point, treating them as inventory misses what they actually are: the item record is a stand-in for a real-world object in system run business processes that the plant depends on to run. A camshaft or a pulley on a shelf is the physical thing the record represents, and every business function that touches that record needs it to represent that thing correctly to do its own job well.
If we start to understand spare parts records this way, taxonomy becomes necessary – although it will not be sufficient. A taxonomy gives similar parts a consistent structure, the same identity attributes in the same order, using the same units. Going back to the two problems Conrad outlined, this does wonders for findability, but comparability requires something more: a governance layer built around the relationships between records. This creates consistency in understanding the records, and moves that understanding from “what is this spare part called” to “do we already have this spare part somewhere else.” It’s essentially the missing link in the chain you’re building, which consists of one clear record for every real-world spare part the business depends upon.
Why AI Won't Fix What Taxonomy Hasn't
It has become increasingly difficult to have a conversation without touching upon the topic of artificial intelligence, and my conversation with Conrad was no exception. Asked about where AI fits into this, he explains that it all comes down to the data. Point a large language model at a pile of badly structured spare parts data and ask it to clean things up, and it will guess, because a model built to predict the next likely word has no deterministic way to confirm that two records describe the same physical object. This ‘data cleanse’ isn’t a new concept per se, and without the underlying structure and taxonomy applied, it tends to leave every record starting with a noun and not much else improved. Looking back at findability and comparability: searches still fail, while duplicates still hide.
Machine learning earns its keep once there is a taxonomy to learn against. Entity recognition can parse a sloppy legacy description and correctly infer that a word buried in position four is the part type the record is missing, but only because there's a defined structure telling it what a correct answer looks like. Applied without that structure, the same technology just becomes a more expensive way to produce a plausible-sounding guess.
Today’s Fix, Tomorrow’s Record
I asked Conrad what ‘doing it right’ looks like, and for him, the best way of going about things is to build spare parts identification correctly from the design and construction phase of an asset, before it reaches operations. That's when a project team should decide how a piece of equipment will be repaired, what its criticality is, compile the bill of materials for each asset, and what needs to sit in inventory versus what can be sourced same-day, and of course writing the material descriptions according to the identity taxonomy. When done right the first time of asking, the resulting records can remain usable for the entire asset lifecycle.
In reality, most organizations don’t have the luxury of ‘doing it right’ from the beginning; it’s impossible to go back to the design and construction phase for the trillions of dollars in physical assets that are already in service. The practical answer to this conundrum, according to Conrad, is implement the taxonomy: it’s a practical way to retrofit what should have been built in from the start. This, to me, implies that the challenges around spare parts management require more than a purely technical fix, as it’s not inherently about the data, but more so about governance. Conrad explains this expertly: what he’s observed is the tension between doing it right, and doing it right now. It’s the duality of the maintenance planner who needs a part this afternoon and the governance process meant to make sure that part's record can be found and reused five years from now. The key to success is fostering collaboration between the people involved, so that they actually work with each other, instead of around each other. Implementing the taxonomy helps bridge the gap.
Closing the Hole
Conrad has been publicly making this argument for four or five years now, and he's watched the conversation shift under him. Item identification, once an underappreciated and underdiscussed subject in maintenance or procurement circles, is starting to show up in how software vendors and consultants try to differentiate their products. When I asked him about what the future has in store for us, rather than a big breakthrough moment, he is expecting a slow correction to a hole that has sat in the foundation of enterprise business systems since spare parts data first went digital, one that gets more urgent as maintenance leans further into predictive, sensor-driven work that depends on trusting the data underneath it.
Spare parts management continues to be a time sink for many roles in maintenance, procurement and warehouse. Usually, the record will exist; it’s just impossible to trace back to its physical counterpart in the warehouse. It is no secret that a large portion of the average Mean Time To Repair is spent walking a warehouse aisle for something you could find in the system, but not in real life. All of those hours logged for time that went missing is a big price to pay. While Conrad is not claiming to have solved this challenge, he is proposing that the fix starts with taxonomy and identification done right, instead of with more horsepower thrown at data that was never structured to be understood properly in the first place.