MRO Spare Parts Inventory Optimization Software: How Do You Free Up Working Capital Without Risking the One Part That Stops Production?

Six part numbers, one bearing, and nobody knows what you own

Pull your material master and search for a common bearing. In most multi site organisations you will find it at least three times. Once as BRG BALL 6205 2RS, once as BEARING,BALL,SKF 6205-2RS, once by a distributor's catalogue number from a purchase made in 2014, and often once more created by a contractor who could not find the existing record and raised a new one to get the purchase through.

Three consequences follow, and the third is the one that hurts. You are carrying more stock than you think, because each duplicate has its own reorder point. Your spend analysis is wrong, because the same item appears as three suppliers' worth of purchases. And when a line goes down at 2am and the fitter searches the system for that bearing, he finds the record with zero on hand, does not find the two records at the other storeroom holding four each, and calls out an emergency freight order for a part you already own twice over.

Underneath the duplication sits a deeper gap. Almost nobody can answer the question that actually governs stocking policy: which equipment does this part serve, and what happens to production if that equipment stops. Min and max levels in most storerooms were set once at commissioning, by whoever built the record, from a number the equipment vendor suggested. Nobody has revisited them since, and the equipment population has changed twice.

Why this problem resists off the shelf answers

Optimisation software wants clean inputs: an item, a demand history, a lead time, a criticality and a service level target. Real MRO data has none of those in usable form. Demand history is sparse, because a large share of MRO items issue once every few years, which makes standard statistical forecasting close to meaningless. Lead time is whatever the last purchase order took, and that purchase may have been expedited. Criticality is a field that is either blank or set to high on everything, because when someone ran a data cleanup exercise five years ago the safe answer was high.

So the hard work is not the optimisation. It is producing inputs worth optimising, and that work is specific to your organisation: your description conventions, your equipment hierarchy, your naming history, the way your planners actually raise a reservation. That is why this category is full of implementations that stalled at the data stage.

What IBM and Verusen actually leave you doing

IBM MRO Inventory Optimization is a serious product, particularly for organisations already running Maximo, and its analytics on stocking policy are real. The pattern we see is that it assumes an achievable level of data quality and equipment linkage. Where that assumption holds it delivers. Where it does not, the project turns into a data remediation programme with an analytics licence attached, and the remediation is the part nobody scoped.

Verusen attacks the data problem directly, using machine learning to harmonise materials across systems, which is the right target. It is genuinely useful for finding duplicates at scale. What it does not do is make the downstream decisions for you: your criticality model, your pooling rules between sites, your policy for insurance spares that will issue once in twenty years, and how a recommendation gets approved and written back to become a real min and max in your ERP (Enterprise Resource Planning). Those are governance decisions with your organisation's fingerprints on them.

The common gap in both cases is the loop. Analysis produces a recommendation. Somebody has to review it, approve it, and change the master record. If that loop runs through spreadsheets emailed to site materials managers, it runs once, for the pilot, and then stops. The recommendations age, trust collapses, and the licence gets cancelled at renewal.

What a custom build has to include

Start with normalisation, and treat it as a permanent function rather than a project. Descriptions parsed into a structured noun and modifier form with attributes: item type, size, material, rating, manufacturer and manufacturer part number. Manufacturer part number is the strongest matching key you have and it is usually buried in free text. Duplicate candidates surfaced with a confidence score and a human decision queue, because automatic merging of material masters is how you delete a record someone had reserved. Every merge recorded reversibly.

Then the equipment link, which is the piece that changes decisions. Each item connected to the equipment it serves, through the equipment bill of materials where one exists and through issue history where it does not. Once that link exists, criticality stops being a guessed field: it inherits from the criticality of the equipment the part serves, adjusted for whether an alternative exists and how long a replacement takes to arrive. That is a defensible model your reliability engineer will sign, which matters because they will be asked to.

Then policy that respects how MRO demand actually behaves. For the small number of fast movers, ordinary reorder logic works. For the long tail that issues rarely, the question is not a forecast but a risk decision: what does not having it cost, how long to get it, and what is the probability of needing it in that window. Present the recommendation as that trade off in plain terms, showing the downtime exposure against the holding cost, and let a person accept it. Recommendations that arrive as a number with no reasoning get ignored by every storeman who has been doing this for twenty years, and he is often right.

Then pooling, which is where the fastest cash release usually sits. If site A holds four and site B holds none and they are six hours apart, the network holds the right quantity in the wrong place. A pooling view with transfer suggestions and an agreed rule on who owns the stock and who pays the freight releases real working capital without adding a single stockout risk.

Then obsolescence, and this one is unglamorous and lucrative. When a pump is decommissioned, its spares stay in the storeroom for a decade. Linking items to equipment status makes the obsolete population visible in a week, and much of it is sellable or returnable.

Then, critically, the writeback. Approved recommendations must update the min, max and reorder point in the system of record, whether that is SAP, Maximo or another EAM, with an audit trail of who approved what. Without writeback the whole build is a very expensive report.

Where AI earns its place, and where it does not

Two jobs are genuinely well suited to a model. Description matching and attribute extraction across millions of free text records is a task no team will do by hand, and modern text models are good at it, provided a human confirms every merge. Second, mapping a supplier catalogue or an OEM parts list onto your master to find equivalents and alternates, which is the same problem in a different direction.

Where it does not belong is forecasting demand for an item that has issued twice in nine years. No model produces useful signal from that, and vendors who claim otherwise are selling a curve fitted to noise. The honest answer for slow movers is a risk based decision with human judgement, and any developer who tells you differently should be tested on it.

Cost, timeline and what moves them

The first release runs $70,000 to $150,000 and ships in 12 to 18 weeks. That covers extraction from your ERP or EAM, normalisation and deduplication with a review queue, equipment linkage, a criticality model your engineers agree to, and stocking recommendations with visible reasoning. The dependency that decides the schedule is access to a decision maker who can approve merges, not engineering capacity.

The full platform with pooling, obsolescence review, lead time management, consignment and vendor managed stock, and writeback to the system of record runs $180,000 to $400,000 across 6 to 12 months. What pushes it up: more than one ERP across the group, which is common after acquisitions, and storerooms with no reliable equipment hierarchy at all. What holds it down: starting with the two largest storerooms and the top spend categories, which usually covers a large share of the value.

When you should not build this

One plant, a few thousand items, one storeman who knows the racks. A cleanup exercise and a disciplined review of min and max levels will get you most of the benefit for the cost of a contractor for a quarter. The build case begins with multiple storerooms, tens of thousands of items, or an acquisition history that left you with two material masters that will never be merged manually.

How to choose a developer

Ask how they would decide whether two material records are the same part. If the answer is fuzzy text matching alone, they will merge things that should not be merged. Manufacturer part number extraction, attribute comparison and a confidence threshold with human confirmation is the shape of a correct answer.

Ask how they will forecast demand for an item that issued twice in nine years. The right answer is that they will not, and that the decision belongs to a risk model with human judgement. This question separates people who have done MRO from people who have done retail inventory.

Ask how an approved recommendation becomes a changed min and max in SAP or Maximo, and who approves it. If writeback is described as a future phase, the project will end as a dashboard.

Ask who owns the code, the repository, the cloud accounts and the cleansed master data, and settle it before kickoff. At Digital Heroes the client owns all of it from the first commit. The cleansed master is the most valuable output of the whole programme, and it must never be locked inside a vendor platform you are renting.