The Midrand brief: stock, pricing and branch visibility
The client was a fast-growing wholesaler in Midrand serving trade customers across Gauteng and beyond. Orders were coming in from multiple branches, pricing was changing often and the team had to work around stock differences between the warehouse, sales office and delivery runs. They wanted one system that could keep stock accurate, apply the right pricing rules, and give management a clear view of each branch without waiting for end of month spreadsheets.
The brief was practical. Reduce stock variances, stop price drift between sales staff, and make sure branch reporting showed the same figures as the warehouse. The business also needed a rollout that would not interrupt busy trading hours, because the team could not afford a long shutdown while orders were still being processed. We agreed early that the solution had to work for users who were already stretched, not add extra admin.
- Business type: wholesale distribution
- Town: Midrand, Gauteng
- Users affected: sales, warehouse, finance and branch managers
- Primary goals: stock accuracy, pricing control, branch reporting
What made the project tricky
The main challenge was that the business had grown faster than its systems. Each branch had its own habits for stock adjustments, customer pricing and order capture. Some records were duplicated, some item codes had been used differently over time, and a few stock items were grouped in ways that made reporting hard. The business also had to deal with load-shedding and internet interruptions from time to time, so the new setup needed clear user steps and a sensible recovery plan.
Another constraint was timing. The warehouse could not pause for long, and month-end work still had to carry on during the rollout. We therefore split the work into stages and kept testing running alongside the actual configuration. That way the team could keep trading while we cleaned the data and checked each process end to end.
- Legacy issue areas: duplicated item codes, inconsistent stock adjustments, mixed pricing rules
- Operational constraint: trading had to continue during implementation
- Local reality: power interruptions and patchy connectivity were built into the plan
Our approach from process map to go-live
We started with process mapping so we could see how the business really worked, not just how the forms were supposed to work. That covered purchasing, receiving, stock transfers, sales orders, returns, credit notes and branch approvals. From there we designed the ERP structure around the way the wholesaler handled stock and customer accounts. We also set up user roles so branch staff could only see the functions relevant to them.
Data migration was handled in stages. We cleaned supplier and customer records, standardised item master data, and matched units of measure so the warehouse team would not be fighting the system later. We then added integration points for the parts of the business that still needed to speak to the ERP, including reporting extracts and order flows from the sales side. Custom reporting gave management daily visibility on stock on hand, branch movements and slow-moving items.
- Process mapping across purchasing, warehouse, sales and finance
- Data migration with item, customer and supplier cleansing
- Role-based access for branch teams and head office staff
- Custom reports for stock, movement and pricing controls
Implementation details that mattered on the floor
Once the structure was set, we moved into configuration, testing and user training. The team needed practical screens and a simple flow for everyday work. We kept the interface clean, reduced duplicate steps and built approval paths for stock adjustments and pricing changes. That helped the branch managers keep control without slowing down the counter staff.
Training was done in small groups so people could ask questions on the actual tasks they do every day. We covered receiving, transfers, pricing updates, report reading and exception handling. We also built a simple go-live checklist for the first week, because the first few days after cutover are usually when small issues show up. A few users picked it up quickly while others needed extra support, which is normal with any change of this size.
- Implementation window: 10 weeks
- Training format: small group sessions and role-specific walkthroughs
- Go-live support: first week on call for issue resolution
- Key controls: pricing approvals, stock adjustment sign-off, exception reporting
Results after rollout
After go-live, the wholesaler had far better stock visibility across the branches and warehouse. Management could see what was on hand, what was moving and where differences were coming from. Pricing control improved because the system applied defined rules rather than relying on manual updates across different teams. That reduced errors at point of sale and cut down on queries from customers who had been quoted one thing and billed another.
Branch reporting also improved. Instead of waiting for scattered updates, managers could review performance and stock positions from one source. The finance team had cleaner data for reconciliation and the operations team spent less time chasing corrections. The real win was not just a nicer report, it was fewer arguments about which number was correct.
- Better stock accuracy across branches and warehouse
- Improved pricing control with clearer approval steps
- Cleaner branch reporting for management and finance
- Less manual follow-up on variances and corrections
Lessons we would carry into another wholesaler rollout
If we were starting a similar Midrand wholesale project again, we would keep the same staged rollout approach. Start with process mapping, then clean master data early, then test the critical paths before the wider user group is brought in. For wholesalers, the item master and pricing logic are often where projects succeed or fail, so those need proper attention from the start.
We would also keep the training close to live work. People learn faster when they can see the item codes, customer groups and stock movements they use every day. And in a trading environment where load-shedding, delivery pressure and branch queries are part of normal life, the support plan must be practical. Good ERP work is not about making the system look fancy, it is about helping the team do the job with fewer mistakes and less backtracking.
- Keep the rollout staged and tightly controlled
- Clean master data before broad user testing
- Train staff on live scenarios, not theory only
- Plan support around trading hours and local disruptions
Why this kind of project suits Bizmatics
Bizmatics works with small and medium businesses that need ERP systems and business integration without unnecessary complexity. From our Centurion base, we support clients in Midrand, Johannesburg, Pretoria, Durban, Cape Town, Gqeberha and across the East Rand and West Rand. Our team includes ERP specialists, an integration architect, a project delivery manager and support staff who stay involved from planning through to adoption.
For this Midrand wholesaler, that meant one team handling mapping, migration, integration, reporting, training and go-live support. The result was a system shaped around how the business actually runs, not how a generic package expects it to run. That is usually where the value shows up, in day-to-day accuracy, clearer decisions and fewer fire drills.
- Base: Centurion
- Coverage: Gauteng and major South African business centres
- Core services used: ERP implementation, process mapping, data migration, integration, reporting and training
Key facts
| Project type | ERP rollout for a growing wholesaler |
|---|---|
| Town | Midrand, Gauteng |
| Timeline | 10 weeks |
| Main focus | Stock accuracy, pricing control and branch reporting |
| Work delivered | Process mapping, data migration, integration, reporting, training and go-live support |
| Operating context | Multi-branch trading environment with load-shedding and time-sensitive order handling |
