MRO Spare Parts Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the material master cleanup swallow the whole project?

Almost every maintenance, repair and operations (MRO) optimisation project is scoped as an analytics build and delivered as a data remediation programme with analytics bolted on at the end. The proposal says twelve weeks to stocking recommendations. Week five arrives and the team is still arguing about whether BRG BALL 6205 2RS and BEARING,BALL,SKF 6205-2RS are the same item.

This happens more in MRO than in any other inventory domain because item creation is decentralised by design. A contractor needs a part on site today, cannot find the existing record in thirty seconds, and raises a new one so the purchase order can go through. Nobody is doing anything wrong. The purchasing process rewards speed and the master data process rewards nothing at all. Multiply that by twenty years and two acquisitions, and you have several material masters wearing a trench coat.

The fix is to fund normalisation as a named workstream with its own budget line, not as a preparation task. Give it a decision owner with authority to approve merges, a review queue with confidence scoring, and reversible merges with full provenance so a wrong call can be undone. Then narrow the target: your two largest storerooms and your highest spend categories usually cover most of the value and produce a result inside one release. Attempting the entire master in one pass is the single most reliable way to run out of sponsor patience before anything ships.

What goes wrong when you migrate storeroom data out of SAP or Maximo?

Extraction looks trivial until the numbers stop reconciling. Five specific things bite in this vertical, and they bite quietly.

• Unit of measure. The same gasket is stocked as EA at one site and as a box of 100 at another. Any quantity mathematics run before normalising this produces recommendations that are wrong by two orders of magnitude, and they look plausible enough to be approved.
• Consignment and vendor managed stock. Material physically in your storeroom that the supplier still owns will appear as your inventory unless ownership is carried through. Optimising stock you do not own wastes the analysis and embarrasses you in the review.
• Rotables and repairables. A serialised pump that cycles between service, workshop and store is not a consumable. Treated as one, it inflates demand history and the system recommends buying more of something you already have four of, in rotation.
• Truncated issue history. Many extracts default to two or three years. For a population where a large share of items issue once in five years, two years of history says almost everything is dead stock.
• Equipment hierarchy without parentage. Exporting functional locations or asset records without their parent relationships gives you a flat list, and criticality inheritance, which is the whole point, becomes impossible.

Reconcile extracted stock value back to the general ledger before anyone runs an analysis. If the two numbers do not agree, the extract is wrong and every recommendation built on it is wrong too.

Why does writeback into SAP or Maximo break after go live?

Reading from the enterprise resource planning (ERP) or enterprise asset management system is the easy half. Writing an approved minimum, maximum and reorder point back into it is where projects stall, and the breakage almost always appears after launch rather than during testing.

Three causes recur. First, min and max are plant specific fields, not global ones. A single recommended number written to the wrong organisational level either fails validation or silently applies somewhere it should not. Second, master data changes are governed. Your data governance team may require an approval path, and field level authorisations may block the service account the interface uses. This is discovered in production because the sandbox had permissive settings. Third, interface failures queue silently. A rejected message sits in a queue nobody watches, the app shows the change as approved, and the storeroom keeps ordering to the old level for four months.

Build writeback in the first release, even if only for one pilot storeroom. Use the vendor supported interface rather than direct table writes, monitor the failure queue with an alert that goes to a person, and run a daily reconciliation that compares what the app believes it set against what the system of record actually holds. If writeback is described as a later phase, assume the project will end as a dashboard nobody acts on.

What happens when insurance spares and criticality are not covered?

The long tail is where MRO differs from every other inventory problem, and it is the part generic software handles worst. A spare transformer winding, a bespoke gearbox for a single line, a control card for equipment the manufacturer no longer supports. These items issue once a decade or never, and the entire reason to hold them is that not holding them costs weeks of lost production.

Two failures follow from leaving this uncovered. If criticality is set to high on every record, which is what happens when a cleanup exercise five years ago made high the safe default, the optimiser recommends holding everything and delivers no savings. If the model instead trusts demand history alone, it recommends disposing of the exact part that stops the plant. Both outcomes destroy trust, and once the storeman stops believing the recommendations he stops opening them.

The fix is a criticality model with a defensible derivation. Link every item to the equipment it serves, through the equipment bill of materials where one exists and through issue history where it does not, then inherit criticality from the equipment, adjusted for whether an alternative part exists and how long a replacement takes to arrive. Give insurance spares their own class with a documented risk decision, an owner and an annual review, so they are excluded from statistical logic rather than mangled by it. Drive obsolescence from equipment status instead of movement, because spares for a pump decommissioned in 2019 will never move and will never be flagged by a movement rule alone.

Should you build custom or configure what you already own?

Some readers should stop here and configure. If you run one plant, a few thousand stock keeping units and one storeman who knows the racks, a disciplined review of min and max levels plus a description cleanup will get you most of the benefit for the cost of a contractor for a quarter. Custom software will not beat a competent person with local knowledge at that scale.

If you already run IBM Maximo and your equipment linkage is reasonably intact, look hard at IBM MRO Inventory Optimization before commissioning anything. Its stocking analytics are real and the integration burden is far lower than a build. The honest caveat is that it assumes a level of data quality and equipment linkage that many organisations do not have, so audit your linkage first rather than after signing. If your problem is specifically duplicate materials across systems at large scale, Verusen is built for that harmonisation job and will find candidates faster than a custom matcher written from scratch.

Build when the governance loop is the problem rather than the analysis. Two or more enterprise resource planning systems after acquisitions that will never be merged. Pooling rules between sites that involve who owns the stock and who pays the freight. Approval paths that have to survive an audit. Those are your organisation's rules, and no product ships with them.

How do hidden costs get into the quote?

Six items are routinely priced at zero and are not free.

• Human review effort. Merge confirmation and criticality assignment are labour, measured in hours per week from people who have other jobs. This is a client side cost that never appears in the vendor quote and is the most common reason timelines slip.
• Source system count. Each additional enterprise resource planning or enterprise asset management instance is a fresh extraction, a fresh field mapping and a fresh set of conventions. Two systems is not twice one, but it is not 1.2 either.
• Unit of measure remediation. Usually discovered mid build and usually a multi week correction across thousands of records.
• The second storeroom. Pilots are run on the best storeroom because it is the easiest to get access to. The messier ones cost noticeably more per item, and the rollout budget was set from the pilot.
• Writeback governance. Approval workflow design, authorisation changes and audit trail requirements are organisational work that quotes rarely include.
• Ongoing normalisation. New duplicate records will be created next month. If nobody owns the queue after launch, the master decays back to where it started within about two years.

What separates a build that works from one that fails here?

The successful ones share five traits. Writeback into the system of record ships in the first release rather than being promised later. Every merge is confirmed by a person and is reversible, because automatic merging of material masters eventually deletes a record somebody had reserved against a shutdown. Every recommendation shows its reasoning, the downtime exposure against the holding cost, so the storeman with twenty years of context can disagree and often be right. Reliability engineering signs the criticality model before it drives any policy, because they will be asked to defend it. And scope starts with two storerooms and the top spend categories, so results arrive early enough to fund the rest.

One contractual point matters more here than in most categories. Settle ownership of the code, the cloud accounts and the cleansed master data in writing before kickoff. At Digital Heroes the client owns all of it from the first commit. The harmonised material master is the most valuable output of the entire programme, and it must never sit inside a platform you are only renting.