Scoping a national inventory system: discovery, data models and a statement of work

The chain had no central, real-time view of inventory across its New Zealand stores, so knowing what sold where depended on people.

• Local knowledge. To understand what sold well in a store and why, head office relied on conversations with staff who knew the area and its customers.
• Manual trend analysis. Sales and inventory information was gathered and analysed by hand to spot trends and recommend products.
• No real-time picture. There was no single, up-to-date record of stock and sales across every store.

The chain wanted a centralised inventory system so it could track stock and sales in real time, see what sells well where, and build plans for specific stores backed by data rather than anecdote.

I joined at the start of the engagement to run discovery and help build the statement of work, working with my delivery lead at the consultancy and with the client's subject-matter experts and stakeholders.

Because this was a custom build, I started with the business problem rather than the solution.

• Understanding the goal. I worked with the client's SMEs and stakeholders to pin down what they were trying to achieve and what was really causing the gaps.
• How data was gathered. I analysed how sales and inventory information was currently fetched and how inventory was managed.
• How decisions were made. I looked at how information reached head office and how it was analysed by hand to find trends and recommend products for each store.

A centralised inventory system needed a database at its core, so I built a level 2 data flow diagram to show the client how data would move through the proposed system: from sales at each store, through stock updates, to analysis and store-specific plans.

Alongside the data flow, I built an ERD showing the data the system would hold and how it relates, so the client could see how stores, products, stock and sales fit together before anything was built.

• Scope. The discovery work and data models fed into the statement of work, which set out the scope of the custom inventory system.
• Finalised. The statement of work was finalised for the initial billable hours.
• Paused. The client then put the build on hold because of budget constraints, and it moved into the consultancy's pipeline.
• Planned next steps. Detailed requirements elicitation, user stories with acceptance criteria, and working with the developers on the build. I left the consultancy before the project resumed.

• Problem first. Defining the real business problem before proposing a custom build.
• Data modelling for a non-technical audience. Using a data flow diagram and ERD to explain how a proposed system would work.
• Commercial scoping. Turning discovery into a statement of work a client can approve and budget for.