A Critical Spare at the Wrong Site Is Still a Stockout

How oil and gas maintenance teams should evaluate inventory systems across remote locations

I spend a lot of time looking at how multi-site operations track their spare parts, and one scenario keeps coming up.

A compressor fails at a remote site. The maintenance team searches the company’s inventory system for the required component and finds it there. The part exists. On paper, there is no problem.

Then the details arrive. The available unit is at another site, several hundred miles away. Or it is on hand locally but already reserved for a planned job next week. Or it is in transit. Or it sits in a storeroom under a slightly different description, so the search almost misses it.

The company owns the part.

Operationally, it still has a stockout.

That gap is the entire problem, and it is why the most common question in an inventory software evaluation. “Does your system support multiple locations?” is not enough to make a good decision.

Recording a part at multiple locations indicates the part exists somewhere. It does not tell you whether that part can reach a failed asset before downtime becomes expensive. Those are two different capabilities. One is enterprise stock visibility. The other is maintenance-ready visibility.

For an operator running twenty or more remote sites, the difference between them is the difference between a parts list and a supply network.

Twenty locations should not create twenty versions of inventory truth

When stock data is unreliable, the instinct is to centralize it. Put every site on one platform, build one dashboard, and assume the numbers will line up.

But a centralized dashboard cannot correct inconsistent source data on its own. If the records feeding it were captured differently at each location, the consolidated view is both precise and wrong.

In practice, the inconsistencies are familiar:

• The same component is recorded under different names.
• Duplicate part records for a single item.
• Inconsistent units of measure.
• Issues and returns that were never recorded.
• Parts stored outside the formal storeroom.
• Manual transfers between sites that never entered the system.
• Stock informally set aside for upcoming work.
• Reorder rules based on local judgment rather than shared logic.
• Consumption that is never linked to a work order.

Each of these is understandable at the site level. Together, they mean the enterprise has consistent fields but inconsistent facts.

This is the part most evaluations skip. Before choosing a system, an organization has to decide which inventory rules must be enterprise-wide (catalog structures, criticality definitions, and what “available” means) and which can legitimately vary by location. A platform cannot make that decision for you. It can only enforce the decision once you have made it.

Critical spares cannot be managed like ordinary consumables

Quantity on hand is a reasonable way to manage gloves and filters. It is a poor way to manage the parts that actually stop production.

Spare parts are not one category. They range from routine consumables, standard replacement parts, repairable spares, and rotating equipment components to insurance or emergency spares and serialized or regulated items. Each has different consequences when missing.

For a critical spare, the number in the “quantity” column is one input among many. The decision should also account for:

• Asset criticality and the consequence of failure.
• Supplier lead time.
• Substitution options.
• Repair turnaround time for repairable spares.
• Location and transportation time.
• Shelf life and storage requirements.
• Planned maintenance demand already on the calendar.
• Whether another site can release its stock without exposing itself.

A count tells you how many you have. It does not tell you how much risk you are carrying. Those are not the same measurement, and a system that treats them as equivalent will make critical spares appear safer than they are.

Evaluate the parts network, not each storeroom on its own

The requirement that follows from all of this is deceptively simple to state and difficult to deliver: the system has to provide local control and network-wide visibility at once.

A storeroom lead needs to run their own site. A maintenance planner needs to see across every site. Both are looking at the same parts, and they need answers that agree.

When a critical asset goes down, the team should be able to determine quickly:

• Quantity on hand by site.
• Quantity available after reservations are subtracted.
• Parts already allocated to work orders.
• Parts in transit.
• Parts awaiting inspection or repair.
• Reorder status.
• Supplier and lead-time information.
• Compatible assets and acceptable substitutes.
• Which site can release stock?
• Whether transferring or purchasing will be faster.

This is the point at which “one supply network” stops being a phrase and becomes a set of concrete features. If the system cannot answer these questions in one place, then the network exists only on paper.

Eight capabilities worth testing before you buy

Rather than comparing feature lists, it is more useful to test whether a platform can support the way a multi-site operation actually moves parts. Eight capabilities matter most.

1. A standardized parts catalog: This means consistent part numbers, descriptions, units of measure, categories, manufacturer references, compatible equipment, criticality classifications, and active prevention of duplicate records across locations. The catalog is the foundation; everything downstream inherits its errors.
2. Site-level and network-level availability: Stock should be viewable by storeroom, site, region, vehicle, or field location, and also as a consolidated total. Critically, the system should distinguish on hand, available, reserved, in transit, and under repair. A single “quantity” figure hides most of what a planner needs.
3. Work order integration. Parts should be plannable against upcoming work, reservable to a work order, issuable directly to a job, returnable if unused, included in maintenance cost history, and able to trigger replenishment. Inventory and maintenance should not operate as two separate ledgers that occasionally agree.
4. Inter-location transfers. A team should be able to request stock from another site, route the request for approval, record dispatch and receipt, track the part in transit, preserve an audit trail, and prevent two locations from counting the same unit as available, a common oversight.
5. Location-specific replenishment. Each site should be able to hold its own minimum and maximum levels, reorder points, reorder quantities, preferred suppliers, lead times, and approval thresholds. A remote site with a two-week supplier lead time should not carry the same stock levels as a central facility next to a distributor.
6. Mobile scanning and field transactions. Technicians and storeroom staff should be able to receive, issue, return, count, and transfer parts via barcode or QR code scan, and link each transaction to a work order. One caution: test this under weak or intermittent connectivity. “Has a mobile app” is not the same as “works at a site with no reliable signal.”
7. Procurement and supplier workflows. Low stock should flow into purchase requests, approvals, purchase orders, receiving, cost updates, and supplier performance records. Determine what is native, what depends on an integration, and what depends on your ERP—those are very different commitments.
8. Auditability and permissions. The system should record who issued or transferred a part, which work order consumed it, what quantity changed, when it happened, who approved an adjustment, and why stock was written off. Permissions should be separable for technicians, storeroom staff, planners, buyers, supervisors, and administrators.

Real-time inventory is a claim about software, not about accuracy

Nearly every platform advertises real-time visibility. The phrase deserves more scrutiny than it usually gets.

A system can update a record the instant it captures a movement. But it can only update after it captures the movement. If someone pulls a part off a shelf without scanning it, recording an issue, or assigning it to a work order, the software has no way to know the physical stock changed.

Real-time software does not create real-time accuracy when field transactions go unrecorded.

This is not an argument against real-time systems. It is an argument for evaluating them honestly. The right system makes capturing a transaction fast enough that people actually do it, and enforceable enough that gaps are visible. But process discipline still carries part of the load, and no platform removes that entirely. A tool that makes recording easy and a process that expects recording are two halves of the same requirement.

Match the platform category to your operating model

No single system is best, because operators do not share a single operating model. It is more useful to sort platforms by the kind of operation they suit, and to know what to verify in each case.

Whatever category fits, separate four things during the evaluation: native functionality, optional modules, integrations, and custom development. They carry very different costs and risks, and it’s easy to blur the lines between them in a demo.

Give every vendor the same remote-site test

A scripted demonstration proves that a vendor can configure a workflow. It does not prove the platform can handle a bad day. So give each vendor the same scenario and ask them to run it live.

A remote site has one critical compressor offline. Its local storeroom has no replacement bearing. Another site appears to hold two units, but one is already reserved for planned work.

Ask each vendor to demonstrate, in order:

• Finding the part across every location.
• Distinguishing available stock from reserved stock.
• Viewing asset compatibility.
• Requesting an inter-site transfer.
• Routing that transfer for approval.
• Tracking dispatch and receipt.
• Reserving the received part against the work order.
• Issuing it via barcode or QR code scan.
• Updating the job’s parts cost.
• Triggering replenishment at the supplying site.

Running that sequence tells you far more than the answer to “Do you support multi-location inventory?” ever will. It shows whether the parts, assets, work order, and transfer actually connect, or whether they are separate features standing side by side.

Measure whether the network is working, not just whether stock is falling

The goal is not to minimize inventory. It is to reduce downtime risk without duplicating expensive spares across twenty or more sites. The metrics should reflect that.

Worth tracking: critical spare availability, stockout frequency, emergency purchase rate, parts-related maintenance delays, transfer fulfillment time, inventory accuracy, inventory carrying value, obsolete or slow-moving stock, planned versus emergency parts consumption, the percentage of parts issued against work orders, and supplier lead-time variance.

Read these numbers carefully, because a good-looking metric can mean two opposite things. A site with almost no recorded stockouts may have an excellent process. Or it may have incomplete records. The number alone does not tell you which. Review it alongside the underlying transactions before drawing an operational conclusion.

The system should tell you what is available, not just what exists

Go back to the compressor at the remote site.

The part was in the system the whole time. That was never the problem. The problem was that “in the system” and “able to fix the asset today” were different states, and nothing connected them.

A strong platform closes that gap. It tells maintenance teams not only what the organization owns, but what is available, where it is needed, who can release it, and whether moving it will beat the downtime clock. This is the principle I would apply when evaluating EZO EAM or any other multi-site system: establish what is genuinely available before trusting the platform to guide a transfer, a reservation, or a purchase.

That is the line between tracking spare parts and operating a spare-parts network.

So before asking a vendor how many locations their system supports, ask the harder question:

When a critical asset goes down at your most remote site, can your system tell you not just that the part exists, but whether it can get there in time?