Start with a clear reason for the change
Before any rollout, define why the change is happening in plain language. Staff need to know whether the goal is to cut manual work, improve stock control, speed up invoicing, or fix errors between departments. If the reason is vague, the project quickly turns into a rumour mill, and that slows everything down.
For SMEs in South Africa, the business case should be specific. A wholesaler in Johannesburg may need tighter warehouse checks, while a branch operation in Durban may need cleaner reporting across sites and less double entry. In Centurion we often see better results when the leadership team agrees on 3 or 4 measurable outcomes first, then communicates them consistently.
- Write down the business problem in one sentence.
- List the departments affected and what will change for each one.
- Set 3 measurable targets, such as fewer stock variances or faster month end close.
- Confirm who signs off decisions and who answers staff questions.
Map who is affected and what they need to hear
Change does not land the same way with everyone. Finance will worry about reporting accuracy, operations will worry about extra admin, and managers will worry about losing control. A good change plan groups people by role and tells each group what matters to them. That helps you avoid one generic message that suits nobody.
Think about branch managers in Pretoria, warehouse teams in the East Rand, and customer service staff in Cape Town. Each group needs a different level of detail, timing and training. If your business runs on shift work or has teams on the road, plan for short briefings and written notes they can refer back to. Load-shedding and busy season pressure can also affect attendance, so keep sessions practical and short.
- Identify champions in each department or branch.
- List likely concerns before they are raised.
- Decide what each group needs to know, do and approve.
- Plan for staff who cannot attend one long meeting.
When people feel heard, resistance drops. When they are surprised, they push back even if the system is better than what they had before.
Set expectations before the first training session
Good change management starts before training. People need to know what is changing, when it changes, what support is available and what the first few weeks will feel like. If you promise that everything will be smooth from day one, people will lose trust when the normal teething issues appear.
Be honest about the transition period. A system change can mean slower work in week one while staff learn new steps, or temporary reporting differences while data is being checked. That is normal. What matters is that people know this upfront and understand how to report issues. This is especially important for businesses with tight month end deadlines or regulated processes.
- Share the timeline in simple stages.
- Explain what will stay the same and what will not.
- Describe the support available during go-live and after.
- Tell staff how errors, questions and exceptions will be handled.
Clarity reduces anxiety. It also stops managers from having to answer the same question 20 times in different ways.
Train people for their real day-to-day work
Training should match the actual tasks people do, not only the system features. A store controller, payroll admin, buyer and branch supervisor all need different steps. Short, role-based sessions usually work better than long classroom-style presentations, especially when people are already busy.
Use real examples from the business: a sales order, a stock transfer, a service ticket, a supplier invoice or a report that management uses every Friday. People learn faster when the examples look familiar. For teams in Gqeberha or Cape Town, where humidity and site conditions can affect devices or network reliability, it also helps to show what to do when a process is interrupted and how to recover without losing data.
- Train by role, not by department alone.
- Use actual documents, screens and approval steps.
- Provide quick reference notes for common tasks.
- Repeat key steps after the first week of use.
Keep the tone practical. People do not need theory during a busy trading day, they need to know what to click, what to check and who to call when something is not right.
Use go-live support to keep confidence high
The first days after go-live are when confidence is won or lost. Staff need clear answers, visible leadership and a simple way to escalate issues. If problems sit for days without feedback, people fall back to old workarounds and the new process gets blamed for everything.
A solid support plan includes daily check-ins, issue tracking, a named support contact and clear priorities for what must be fixed first. This matters even more for multi-site businesses in Johannesburg, Pretoria and Durban where a small problem in one branch can create delays in another. Make sure managers know which issues are urgent, which can wait, and which need process correction rather than a software change.
- Run short daily review meetings during the first week.
- Track issues by department, severity and status.
- Communicate fixes back to users quickly.
- Keep a record of lessons learned for the next phase.
Good support is not only technical. It is also reassurance, structure and follow through.
Check whether the change is sticking
Once the system is live, measure whether people are using it properly and whether the expected business results are coming through. Adoption is more than login counts. You need to know if staff are following the new process, if managers are using the reports, and if the business is seeing fewer errors or less rework.
Review the numbers after 30, 60 and 90 days. Look at training gaps, repeated support requests and any process steps that still rely on spreadsheets or manual notes. If you see the same mistake across several branches, the fix may be in the process design or the training approach rather than in the system itself. That is where proper change management saves time and money.
- Measure adoption, errors and turnaround times.
- Compare actual usage against the new process design.
- Capture feedback from branch and department leads.
- Adjust training, documentation or workflow where needed.
When change is managed well, staff stop seeing it as disruption and start seeing it as part of normal business. That is the point where the project becomes real value.
