The Storeroom Accuracy Problem

The Storeroom Accuracy Problem: How Bad Parts Data Kills Maintenance Programs

The system said three bearings on the shelf. Shelf B-14, bin 3, quantity three — right there in the CMMS, clear as anything. The planner pulled the work order, walked to the storeroom, and found a curled pick ticket from eight months ago and nothing else.

The bearing wasn't missing because someone stole it. It wasn't missing because the system glitched. It was missing because at some point, someone pulled it without logging the transaction, the count never got corrected, and the data sat there looking accurate until the moment it mattered.

That's the storeroom accuracy problem. And it doesn't start with bad software.

What Phantom Inventory Actually Is

Phantom inventory is any parts record that doesn't match physical reality — a part the system says exists but doesn't, or a part sitting on the shelf that the system shows as zero because it came back from a job and never got logged as a return.

Both are accuracy problems. Both are trust problems. And both are almost always the result of process failure, not system failure.

The most common cause is the pull without a transaction. A technician needs a part. Logging it in the CMMS takes ninety seconds. Getting back to the line takes thirty. So the part gets pulled, the ticket doesn't get written, and the count is wrong before anyone notices. Multiply that by a shift. Multiply that by a year. The storeroom count becomes a historical artifact — a record of what was there when someone last bothered to count, not what's actually on the shelf today.

The second cause is the return that never gets logged. A PM gets canceled. The part comes back to the storeroom. Somebody sets it on a shelf — maybe the right bin, maybe not — and walks away. The system still shows zero. The part is physically present and functionally invisible.

The third cause is bin location drift. Parts get moved. Shelves get reorganized. New stock comes in and gets put wherever there's space. The system still points to B-14, but B-14 now holds something else entirely.

None of these failures require negligence. They require nothing more than a process that makes accurate transactions harder than inaccurate ones, which describes most storerooms.

How Phantom Inventory Kills Technician Trust

The first time a technician walks to the storeroom and finds an empty bin where the system promised a part, he assumes it's a one-off. The second time, he starts to wonder. The third time, he stops checking the system first.

This is the most expensive thing phantom inventory does — not the missed parts, but the behavioral change it produces.

A technician who doesn't trust the CMMS parts data doesn't file a formal complaint. He adapts. He starts pulling extra parts "just in case" on planned work. He holds onto returns instead of bringing them back. He builds a small inventory of commonly needed items in his toolbox or in the back of his van. None of it gets logged, because the whole point is to avoid depending on a system he doesn't trust.

This behavior looks like hoarding. It's actually rational. If the storeroom has been wrong enough times, self-insurance is the logical response.

The downstream effect is compounding. The unofficial inventory that technicians carry isn't visible to the system, so the system's data gets worse. Parts that should be showing as consumed stay on the books. Parts that are physically present don't appear anywhere. The planner, who relies on what the system shows, plans based on data that's increasingly disconnected from reality.

The storeroom didn't break the CMMS. The storeroom is the problem the CMMS is now accurately reflecting — a floor-level reality that nobody built a process to capture.

What Phantom Inventory Actually Costs

Most plants can tell you the cost of a bearing. Very few can tell you the cost of not having a bearing when a PM comes due.

Here's the actual cost chain.

A PM is scheduled. The planner checks the system, sees the part is on hand, and issues the work order. The tech gets to the job, walks to the storeroom, and finds nothing there. Now the PM can't be completed as planned.

The planner spends the next hour — sometimes longer — trying to figure out what happened to the part, calling suppliers, checking if another site has stock, pricing expedited shipping. The emergency buy comes in at two to three times the standard contract price. Overnight freight adds another layer. The job that should have been a thirty-minute PM during a planned window turns into a full-day scramble.

But that's not the end of the cost. The asset was supposed to get that bearing replaced because the failure data said the current one had reached its useful life. If the PM slips two weeks while the part gets sourced, the asset runs for two more weeks on a bearing that's past its change interval. If it fails in that window, the cost of the unplanned repair is an order of magnitude higher than the cost of the original PM — and the downtime cost on top of it can dwarf both.

Emergency procurement is a symptom. The unplanned failure that follows is the actual cost. Most plants see them as separate events. They aren't.

The Ownership Problem

Ask most maintenance managers who owns the storeroom data. You'll get one of three answers: the storeroom attendant, the CMMS administrator, or a pause that answers the question better than any name would.

Storeroom data accuracy doesn't fail because people don't care. It fails because nobody's job description includes owning it continuously.

The storeroom attendant processes transactions. The CMMS admin configures the system. The planner uses the data. The maintenance manager watches the budget. Nobody is accountable for the gap between what the system shows and what's physically on the shelf — which means the gap grows until someone audits it and finds out how bad it's gotten.

The min/max problem is a version of the same issue. Min/max levels get set during an initial CMMS implementation or a storeroom organization project. Someone runs the numbers, sets the reorder points, and moves on. Two years later, the asset mix has changed, failure rates have shifted, contract lead times are different — but the min/max levels are still set to what made sense in 2021.

Nobody changed them because nobody owns them. Nobody reviews them on a schedule. The system is reordering parts based on stale assumptions, and the storeroom is either overstocked on things that never move or consistently short on things that move fast.

Cycle counting is the discipline that catches this. Not an annual physical inventory — a rolling count where a small portion of the storeroom gets verified against the system every week, discrepancies get investigated, and the data gets corrected before the errors compound. Plants that do this consistently have storeroom accuracy above 95 percent. Plants that don't are typically somewhere between 70 and 80 percent, which sounds adequate until you understand that 20 to 30 percent of your parts data is wrong and you don't know which 20 to 30 percent.

What a Well-Run Storeroom Looks Like

The difference between a storeroom with 95 percent accuracy and one with 75 percent accuracy is rarely the software. It's almost always the process and the ownership.

A well-run storeroom has a single point of accountability for data accuracy. Someone's job includes reviewing discrepancies, managing the cycle count schedule, and flagging when min/max levels need to be revisited. That person isn't necessarily a dedicated storeroom manager — in smaller plants it might be a senior planner or a maintenance supervisor — but it's a named person with a defined responsibility.

Transactions are enforced, not suggested. Parts don't leave the storeroom without a work order number and a logged transaction. Returns come back through a defined process. The rule isn't complicated; the enforcement is what makes it work.

Cycle counts happen on a schedule and discrepancies get investigated. Not just corrected — investigated. If bin B-14 keeps coming up short, someone figures out why. Bad bin location in the system, a pickup point that got moved, a supplier shipping the wrong quantity — the root cause matters because the same root cause will produce the same discrepancy next cycle if nobody addresses it.

Min/max levels get reviewed at least annually, and more often when the asset mix or maintenance strategy changes. A bearing that used to turn over three times a year and now turns over monthly needs a different reorder point. The system won't tell you that. Someone has to notice.

None of this requires a new CMMS. It requires ownership, process, and the discipline to maintain both.

The Diagnostic: Process Gap or System Gap?

When a maintenance team is dealing with chronic storeroom accuracy problems, the instinct is to blame the CMMS. The data is wrong, the system is showing things that aren't there, the reports don't match reality — it must be a system problem.

Sometimes it is. Data migration errors, configuration issues, integration failures between the CMMS and the procurement system — these are real and they happen.

But most of the time, the system is working exactly as designed. It's recording what it's been told. The problem is that what it's been told doesn't match what's happening on the floor, because the process for capturing floor-level activity is broken or missing.

Before assuming the CMMS needs to be replaced or significantly reconfigured, answer these questions honestly:

Do technicians consistently log transactions at the time of the pull, or does logging happen after the fact — or not at all?

When parts come back from jobs, is there a defined return process, or do they go back to "wherever there's room"?

Is there a named person accountable for storeroom data accuracy, with a defined review schedule?

When was the last time min/max levels were reviewed against actual consumption data?

If the answers to those questions reveal process gaps, the CMMS isn't the problem. The storeroom created this. The CMMS is just reflecting it accurately.

Fix the process first. Then evaluate whether the system needs to change.

The Real Cost of Getting This Wrong

A storeroom with 75 percent accuracy feels manageable until you run the numbers. If you carry 2,000 unique parts and 500 of those have inaccurate counts, you're making planning decisions — PM scheduling, reorder decisions, budget forecasting — based on bad data for 25 percent of your inventory.

That shows up as emergency buys. As PMs that slip and become corrective work. As technicians who stop trusting the system and start working around it. As a maintenance program that looks functional on paper and consistently underperforms in practice.

The storeroom is the foundation the maintenance program sits on. If the parts data isn't accurate, the PM schedule built on top of it isn't reliable. The budget projections built on top of that aren't accurate. The reliability metrics built on top of those don't mean what you think they mean.

It starts with a curled pick ticket and an empty bin. It ends with a maintenance program that costs more than it should and delivers less than it could.

The fix isn't complicated. But it requires owning the problem — and most plants are still blaming the software.

If this sounds like your storeroom, Millwright Media produces technical content for CMMS software companies, MRO suppliers, and reliability consulting firms — written by someone who has been on the floor when the system said three and the shelf said zero. Visit millwright-media.com to learn more.

Previous
Previous

The Difference Between Busy and Productive in Maintenance

Next
Next

Why Most CMMS Implementations Fail Within the First Year (And How to Make Sure Yours Doesn't