An oil and gas inventory pilot: reconcile one storeroom end to end

Topics: oil and gas inventory management; MRO inventory pilot; oilfield stores integration; spare stock accuracy.

A materials manager can obtain a stock balance from the ERP, a repairable list from the maintenance system and a count sheet from the warehouse. The difficulty is explaining why they differ. Buying another dashboard will not resolve an issue transaction that was entered twice or a returned unit whose condition was never confirmed.

The pilot should follow one storeroom from opening stock through issues, returns, repairs and holds. At the end, stores and finance should be able to explain the closing position and name the person resolving each remaining difference.

Define a sample that can reveal failure

Choose a bounded population with the warehouse, maintenance and finance owners. Illustrative pilot scope: 50 item codes in one storeroom over an agreed two-week transaction window. Include serialised repairables, partial issues, unused returns, inspection holds and vendor-held units. The number and period are planning examples, not a recommended statistical sample for every site.

Record why the items were selected. A sample consisting only of clean, frequently moving consumables cannot establish performance on repairable exceptions. Keep normal cases and deliberately difficult cases separate in the evaluation results.

The opening pack needs item and unit definitions, location and condition codes, serial references where applicable, reservations, source transaction identifiers and a documented cutoff. Use authorised extracts with unnecessary personal or commercial information removed. A reviewed count observation is evidence to investigate; it is not permission to post an adjustment.

For systems that track reusable assets individually, check the relationship between inventory identity and asset identity. IBM provides one example of that distinction. IBM asset documentation

Agree who owns the answer

The analyst should be able to point to an owner when a record conflicts. “The system says so” is not a resolution reason. When two systems claim authority over the same status, resolve that ownership before implementing a synchronisation rule.

Keep this pilot on business-record interfaces. A later connection to operational technology requires its own architecture and security assessment; NIST SP 800-82 Rev. 3 is relevant background for that boundary. NIST OT security guidance

Work through the discrepancy instead of adjusting it away

Illustrative example. Item K-20 opens with 12 accepted units. The physical movement evidence shows an issue of three units and an unused return of one. The return has also passed the required acceptance review. All quantities use the same unit of measure and cutoff.

The expected closing quantity is 12 − 3 + 1 = 10. The ERP shows six because the issue was recorded twice and the return was omitted: 12 − 3 − 3 = 6. The count observation also shows ten.

The four-unit difference has two causes. It should generate two linked exceptions: a duplicate issue of three and an omitted return of one. The finance and warehouse owners choose the supported correction route. The pilot retains both original records, the decision and the resulting correction reference. It does not post a generic increase of four and mark the investigation complete.

Reconciliation does not end with the quantity of ten. Suppose one of those units is subsequently put on hold and two other units are reserved for a job. Under a rule that excludes both groups from free stock, seven are available: 10 − 1 − 2 = 7. The held and reserved groups are distinct in this example. A hold changes availability without changing physical quantity; a reservation changes allocation without creating a stock issue. Test those events separately so an integration does not subtract them twice.

A second item, serial R-77, is recorded at the repairer while a receipt names R-78. That conflict cannot be solved with quantity arithmetic. The repair coordinator must establish whether it is an exchange or an error. Until then, neither record should acquire an unsupported available status.

Measure the manual process before changing it

For each sampled case, record the time spent finding evidence, the number of unresolved discrepancies, their age and the eventual resolution category. Distinguish active handling time from waiting for another owner. Record the denominator: a result for 50 item codes is different from a result for 200 events.

Then compare the pilot with the same task performed through the current process. Use separate cases for configuration and evaluation so that the team is not simply replaying examples it has already fixed. Freeze the evaluation set and acceptance definitions before seeing the final results.

Suitable measures include events linked to a valid source and destination reference, discrepancies correctly classified, serial conflicts preserved for review and reviewer handling time. Report unresolved cases rather than deleting them from the denominator. Set any speed or accuracy improvement target after establishing the baseline, with the operational owners.

Write the acceptance sheet as decisions the owners can sign: every sampled movement is either reconciled or in a named exception; replay creates no additional business movement; held items remain excluded under the agreed availability rule; and every proposed adjustment has supporting evidence. Report slow or unresolved cases even if the overall handling time improves. This makes the expand-or-fix decision much clearer than a single stock-accuracy percentage.

Choose the simplest implementation that can explain the sample. Existing ERP reports and a controlled reconciliation sheet may be enough when the event history is complete and the review is infrequent. A staging ledger is useful when repeat extracts, serial states or duplicate deliveries make that history hard to reconstruct. Test those deterministic checks before adding document extraction; the owners still resolve unsupported movements and acceptance questions.

Rehearse recovery as part of the demonstration

Stop processing if access controls fail, source provenance is lost or a connector unexpectedly writes to a production system. Isolate the affected batch and retain its inputs. The warehouse continues its approved process while the team investigates. After correction, replay into staging from the retained source events and compare the result before resuming evaluation.

A failed pilot can still be useful if it identifies a missing state definition or unreliable extract. The appropriate decision may be to repair those foundations rather than expand the software.

Summary and next actions

The pilot succeeds when people can explain the closing position, trace the explanation and handle the exceptions without unapproved stock changes. Expansion should follow demonstrated control over the chosen record flow, not the number of items displayed.

1. Nominate one storeroom and the warehouse, technical, finance and integration owners.
2. Capture an opening snapshot and baseline the current reconciliation effort.
3. Agree the evaluation sample, exception cases and acceptance thresholds before the final run.
4. Demonstrate recovery, then document an expand, revise or stop decision.

For a focused assessment, start with the storeroom scope, current ERP/CMMS, transaction types and unresolved discrepancy categories. A synthetic sample and state map are enough to design the first workshop; confidential asset records are unnecessary at that stage.