Building Cross-Unit Inventory Visibility

The Challenge

A STOROB is a cross-platform stock reallocation, where stores are taken from one platform to support another. It is a routine part of keeping ships in upkeep moving when the alternative is waiting weeks for fresh procurement. It is also, if it is not tracked properly, an easy way to lose sight of what has actually moved from where, and what that is costing.

Across the upkeep units I supported, STOROB tracking was spread across various different spreadsheets, each maintained separately, with no single source of truth the project manager could rely on to see the full picture. A predecessor had already started building a fix that fed into the data platform, intended to give the project manager one place to load, view and compare STOROB data across units. When I took over the account, that build was incomplete and not working as intended.

Context & Stakes

Upkeep periods run to tight timelines, and a STOROB is often the fastest legitimate way to keep a job moving when the part needed is sitting unused on another platform rather than weeks away in the supply chain. That makes STOROBs valuable. It also makes them a control risk: an untracked STOROB is an asset that has moved without the paperwork that would let anyone reconcile it later, or spot that the same gap keeps recurring somewhere it could be fixed at source.

Each unit's own spreadsheet was internally consistent but told nobody outside it what had actually moved, or what it was worth. Without a shared view, the project manager had no way to compare STOROB activity across units, spot a pattern worth acting on, or know whether a reallocated item had already been accounted for somewhere else.

The fleet's data platform was already where the wider team had chosen to load, view and compare this kind of data. My part sat upstream of that: getting the underlying spreadsheet right so that what fed into it was accurate and structured to answer the questions stakeholders actually had, rather than continuing to patch a build that had stalled before it worked.

Approach

Taking Over an Incomplete Build

My predecessor had already started work towards a data-platform-fed solution before I took over the account. It did not work as intended, and rather than starting again from a blank page, I reviewed what existed against what the project manager actually needed and decided what to keep, what to rebuild, and what to drop.

Reconfiguring the Spreadsheet

The fix sat upstream of the data platform itself. I reconfigured the source spreadsheet so it captured STOROB activity consistently across units, in a structure that could be loaded cleanly rather than requiring manual cleanup every time. Getting that structure right meant working through what each stakeholder needed to see, and what "consistent" actually had to mean across units that had never recorded the same information the same way.

Working With the Data Platform Build

Loading, viewing and comparing the data inside the data platform itself was built and administered by the technical team responsible for it. My role was the data and requirements side: making sure what went into it was correct and fit for the questions the project manager needed answered, and testing the output against real STOROB cases to confirm it worked before treating it as done.

What the Tool Does

A Single Source of Truth for STOROB Activity

Instead of each unit keeping its own separate record, STOROB activity is captured in one consistently structured spreadsheet, loaded into the data platform so the project manager can view and compare it across units in one place rather than reconciling separate files by hand.

Comparison Across Units

Because the data is structured the same way regardless of which unit it came from, it can be compared directly: what has been reallocated, from where, for what and what it was worth, without the manual translation work that separate spreadsheets used to require.

Who I briefed and what they decided

I presented the rebuilt tool and its findings to the regeneration project manager who owned the requirement, and to BAE Systems' stock-transfer lead. Both backed rolling it out beyond the units it was built for: it went to an adjacent unit first, and inventory managers elsewhere in the fleet have since adopted it themselves.

Outcomes

• Incomplete Build Completed and Working – Took over a stalled predecessor attempt and delivered a version that worked as the project manager expected
• £8,000 and 50 Man-Hours Identified Within Days – The first use of the tool after rollout identified a complex STOROB worth that value, proving the concept in practice rather than in theory
• Rolled Out to an Adjacent Unit – The tool's success on the original units led to adoption by an adjacent unit
• Adopted by Inventory Managers Elsewhere in the Fleet – Beyond the original rollout, inventory managers elsewhere in the fleet have taken up the approach

Lessons Learned

Completing a Stalled Build Is a Different Skill Than Starting One

Picking up a predecessor's incomplete work means diagnosing what already exists before deciding what to change. Starting again from scratch would have felt faster in the short term, but reviewing what was already built, and being honest about what of it was salvageable, avoided repeating the same false starts that had stalled it the first time.

The Data Structure Matters More Than the Platform

The data platform could only compare across units because the spreadsheet feeding it captured every unit's STOROB activity the same way. Getting that structure right, working through what "the same way" actually meant for stakeholders who had never recorded it consistently before, was the harder and more valuable part of the work, ahead of whatever platform sat downstream of it.

A Fast, Concrete Result Builds Adoption Faster Than a Business Case

The tool spread to an adjacent unit and beyond because it found £8,000 and 50 man-hours within days of going live, not because of a rollout plan. A concrete result someone can check against reality does more to earn adoption than an argument for why the approach should work.

Requirements Ownership and Platform Ownership Can Sit With Different People

I owned the data and the requirement; the technical team owned the data platform itself. That division worked because each side understood what the other needed, rather than treating the boundary as a handover point where responsibility for the result stopped.