Say you’ve introduced software that automatically orders stock for your stores. The orders go out, but staff still spend every morning comparing what the warehouse dispatched with what stores recorded as received. They correct the inventory records so the next orders use the right quantities.
Now you want to bring more stores onto the system. Do you need more people doing those checks? Should you wait until IT finishes linking the warehouse and store systems?
I’d start by sitting down with the people making the corrections. They’re seeing where the process breaks every day. Before we decide how to support a bigger rollout, I want to understand what they keep having to repair.
Human checking is useful, particularly when a system is new. If the same discrepancies keep appearing, though, each morning’s work ought to teach us something. Which records need changing? Are the errors concentrated in certain stores? Is inventory being updated too late, or is the ordering system failing to pick up the update?
Take a delivery that reaches a store before its receipt is entered. The ordering system may make its next decision using a stock balance that is already out of date. Correcting that balance fixes today’s number. We still need to know why the receipt wasn’t available when it was needed.
At that point, I’d consider concentrating the trial on one or two stores where the recurring problem is visible. Follow it from the warehouse dispatch through to the store receipt and the next order. Get the people who handle those steps involved, work through a change, and see what happens on the next delivery.
That’s work we can begin while a larger integration is being planned. We may still need that integration, but a delivery date a year away doesn’t explain the errors happening today.
I’d look for useful changes we can make now: a clearer receiving procedure, a report that puts discrepancies in one place, or an automated check that flags missing updates. Those are possibilities to investigate once we understand the cause.
The people from stores, the warehouse and IT also need enough authority to agree and test the changes. If every small fix requires another chain of meetings, even a trial in one store can drag on.
Before expanding, I’d want to see what happens over several replenishment cycles. Are the records more reliable? Does the team spend less time correcting them? Are stores still getting the stock they need? Then we can identify what other stores would need to achieve the same result.
Start with a correction your team made again this morning. Work out what would have prevented it, test that change, and check whether the correction comes back. That gives you something concrete to build the next stage of the rollout around.
