Can Do Consulting, 142 Western Services Road, Johannesburg (2026)

10/09/2026

The same ERP rollout produced strong adoption in one region and quiet non-compliance in another. Same system, go-live date, and training deck.

The gap wasn't the technology, but rather the assumptions built into how the training was delivered: how much context people needed before they'd act, whether a group session felt collaborative or like a performance in front of colleagues, and how directly a concern could be raised and to whom.

Some teams want the full case before they'll act on a change, asking why this system, why this process, and what alternatives were ruled out. Others will move readily on a clear instruction from someone they trust, while a long justification can come across as a lack of confidence in the decision.

None of this means rebuilding the rollout five times. The process, configuration and go-live timelines can stay fixed. What should change by design is the tone, format, language and training delivery for each region the rollout reaches.

We break down what to keep standard and what to adapt in our latest article: cando.co.za/how-to-train-a-global-workforce-across-different-cultures/

09/09/2026

Super users are one of the most valuable investments in an ERP or change project. They learn the system deeply, support colleagues through training, answer the questions that don't make it to the service desk, and provide a practical link between the project team and the people doing the work.

The problem is what happens to that network when the project ends.

In most cases, the project board closes, the super user role is formally ended, and everyone's time goes back to business-as-usual. A network that took months to build is effectively disbanded just as the organisation enters a different phase of change.

The need for super users doesn't disappear at go-live. New employees will join who weren't part of the project, teams will find their own workarounds when something isn't working as expected, and system updates will change workflows that people have only just become comfortable with. During hypercare, those issues might have been picked up quickly. Once the project team has moved on, the same questions can become quiet, persistent frustrations.

A continuing super user network gives the organisation somewhere for those issues to go. It can catch workarounds early, help new starters find their feet and give teams a familiar point of contact when the next system update lands.

It doesn't need to become a major ongoing programme. A named structure, a communication channel and regular check-ins can be enough to keep the network active.

The investment in building your super user network has already been made. Don't let the return on that investment disappear when the project does.

02/09/2026

Go-live is a milestone that's easy to celebrate. The system is live, the project team moves on, and everyone's attention shifts to the next priority.

The harder question is whether the system has actually become part of how people work. That doesn't become clear on go-live day. It shows up in the operational data over the weeks and months that follow.

There are five signals worth watching:

1️⃣ Recurring support tickets
If the service desk keeps receiving the same questions about tasks that were covered in training, something hasn't transferred from training into day-to-day work. People may have completed the modules, but that doesn't necessarily mean they feel confident applying what they learned.

2️⃣ Shadow spreadsheets
If people are still keeping spreadsheets open alongside the new system to manage the same work, they've probably found the old way faster or more reliable. The system has become an additional step rather than replacing the old process.

3️⃣ Growing approval queues
A growing backlog after go-live can point to unclear ownership, incorrect routing or access issues. Whatever the cause, it's a sign that something in the new process isn't working as intended.

4️⃣ A slower month-end close
Month-end is a useful test of whether new finance workflows have really been embedded. If the close is taking longer than it did before, the team may still be working out the process under pressure.

5️⃣ Overtime creep
When teams start working longer hours after cutover, look at what's happening underneath. They may be completing work in the new system while still relying on the workaround they trust more.

None of these signals require a formal adoption measurement programme. They're already sitting in the data. The important part is knowing what to look for, and paying attention before small problems become established habits.

26/08/2026

When change communication doesn't land, the instinct in most organisations is to send more of it – more updates, more channels, more frequency, more change champions reinforcing the message. In the majority of cases, that response makes the problem worse rather than better.

The failure is rarely in the content of the message. It's in the conditions the message lands in, and there are four causes that come up consistently across change projects of every size and complexity.

1️⃣ Communication sent too early, before people can see how the change affects them concretely, feels abstract and is easy to set aside. People don't engage with information they can't act on yet, however accurate or well-written it is. By the time the change becomes real and immediate, the message has been forgotten, and the communication team wonders why awareness is so low despite all the effort that went in.

2️⃣ When every project update goes to every person in the organisation regardless of relevance, people develop a habit of skimming or ignoring the communications entirely. The intention – to keep everyone informed – produces exactly the opposite effect. Distinguishing what matters from what doesn't requires effort that people won't consistently make, and so they stop making it at all.

3️⃣ A newsletter, a SharePoint post, or an all-staff email cannot carry the weight of a significant change in how people work. Some changes require a direct conversation – a team meeting where people can ask what this means for their role specifically, and where a manager can provide a real answer. Choosing a low-friction channel for a high-impact change signals, whether intentionally or not, that the change isn't serious enough to warrant the time for a proper discussion.

4️⃣ Most change communication explains what is changing. Very few pieces of change communication explain what that change means for a particular person's work on a normal day. That is the question people actually need answered, and until it is answered, no amount of well-crafted messaging will produce genuine engagement. Communication that doesn't answer "what does this mean for me, specifically" will be filed or deleted – and that is a design failure, not a people failure.

19/08/2026

The conversation about AI and jobs tends to focus on headcount: which roles will disappear, which will be created, and how many positions are at risk. That framing captures some of what is happening, but it misses where most of the practical risk sits in the near term.

In the immediate future, AI doesn't eliminate roles at scale in most organisations. What it does is redistribute tasks within them. The job title stays the same, the person stays in the role, and the content of the job shifts – sometimes significantly – often without any formal acknowledgment that the role has changed at all.

In practice, this is what that shift tends to look like. An AI feature automates the high-volume, repeatable portion of a workflow: routine data entry, standard approvals, straightforward routing decisions that follow predictable patterns. The person in that role now spends less time on those tasks, which sounds like a gain. What they spend more of their time on are the exceptions, the judgement calls, and the decisions that carry real accountability. Those are the tasks that require understanding the underlying process and its logic well enough to know when something has gone wrong – and that is, in many respects, a harder job than the one it replaced.

The risk sits in the gap between the capability the AI assumes and the capability the person actually has. When the AI makes an error on a task it was supposed to handle, the person reviewing it needs to be able to catch it. That requires understanding what correct looks like, which requires training on the process itself and not just on how to operate the feature. Most current training programmes are not designed for this, because they were designed before the task profile of the role changed.

The role-impact conversation – which tasks are shifting, which skills now matter more, and who is responsible when the AI gets something wrong – needs to happen before any AI feature is switched on. Activating that capability without having had that conversation is not acceleration. It is a risk that has simply not been named yet.

12/08/2026

For most of ERP history, the go-live date was the milestone that everything built toward. You planned for it, trained toward it, and once the cutover weekend was done, you moved into hypercare and then business as usual. Change was a project with a beginning, a middle, and a clearly defined end.

Cloud ERP has fundamentally changed that model, and most organisations haven't yet adjusted how they manage change to reflect it.

Quarterly release cycles mean the system your people trained on in January looks different by October. New features appear, interfaces shift, existing workflows get updated, and some of those changes directly affect how specific roles complete specific tasks. Most of them arrive without a formal project, without a training plan, and without anyone having assessed who is affected and what they need to know.

The result is a slow, quiet drift. People discover changes when something stops working the way they expected. Workarounds develop. Questions accumulate at the service desk. And the organisation that invested heavily in go-live readiness finds itself losing ground on adoption not because of one significant failure, but because nobody built a process to absorb the continuous change that followed.

The organisations handling this well have made one important shift in how they think about change capability. They've stopped treating it as something that activates for a project and then switches off and started treating it as a standing operational function.

In practice, that means someone has a recurring responsibility to read release notes for workflow impact, assess which roles and processes are affected, decide what needs to be communicated or trained, and keep job aids and support materials current before each release lands – not after the first support ticket arrives.

That is not a large team. In many organisations, it is one person with a clear remit and a quarterly calendar slot. The point is that it is deliberate rather than reactive. The go-live date is no longer the milestone that matters. The capability to absorb what comes after it is.

05/08/2026

A 92% training completion rate looks good on a report, but it doesn't tell you whether anyone changed how they work – and that distinction is one of the most consequential blind spots in ERP and change projects.

Completion data is easy to collect, easy to present, and easy to misread as evidence that a change has landed. What it actually measures is whether someone was present for training, digitally or physically. It says nothing about whether the system is now being used correctly, whether old habits have been replaced, or whether the change has genuinely taken hold in day-to-day operations.

That distinction matters because organisations that stop at completion reporting often discover the adoption gap too late – months after go-live, when support tickets are still climbing, workaround spreadsheets are still open alongside the new system, and the efficiency gains that justified the investment haven't arrived.

There are three measures that actually tell you whether adoption happened.

➡️Task usage: are people completing the tasks they were trained on inside the system, rather than finding ways around it?

➡️Shadow tools: have the workaround spreadsheets disappeared, or are they still open? If they're still open, the system hasn't replaced the habit.

➡️Support volume: ticket volumes on tasks that were covered in training should drop after go-live, and if they're flat or rising, the training didn't transfer.

None of these require expensive measurement infrastructure. They require someone to ask the right questions on the operational data that already exists. If post-go-live reporting stops at completion rates, it's measuring the input. The outcome is an entirely different number, and it's the one that tells you whether the investment paid off.

04/08/2026

The go-live date tells you nothing about whether the ERP investment worked.

The project closed on schedule, the system is technically live, and the steering committee moves on to the next priority. Whether the organisation actually changed how it operates is a different question, and no go-live checklist was built to answer it.

Real adoption shows up in three checkpoints, each measuring something different:
🚩30 days: is the system being used at all?
🚩90 days: is it being used correctly?
🚩180 days: did it move the numbers the business case promised?

Skip those checkpoints and you find out the hard way, six months in, when the manual spreadsheets are still running and nobody can say why.

We break down exactly what to check at each stage, and the shared vocabulary leaders need to avoid confusion.

Read it here: cando.co.za/did-the-system-pay-off-how-to-measure-adoption-after-go-live/

29/07/2026

A new screen layout is one of the most underestimated friction points in an ERP rollout. Users know how to do the work, but they just cannot find where to do it anymore – and that disorientation costs time, confidence, and patience.

Here are the approaches that actually help:

👉 Map new to familiar by showing users where their most-used functions live in the new layout. Something as simple as "this is where the old purchase order screen lives now" can save ten minutes of searching.
👉 Lead with the five transactions they do every day. Comfort with daily tasks builds the confidence to explore the rest, so resist the urge to cover everything at once.
👉 Use annotated screenshots in your reference materials. A labelled screenshot placed next to the task instruction reduces searching and cuts the volume of questions that escalate to managers.
👉 Give people unstructured time in a training environment before go-live. No task to complete, just the freedom to navigate. That kind of exploration builds familiarity faster than any guided walkthrough.
👉 Address avoidance early. Users who sidestep the new screen because it feels unfamiliar will develop workarounds, and early investment in familiarity is far cheaper than fixing an adoption problem months down the line.

The disorientation is temporary, but the workarounds it creates are not.

Which of these tactics has worked best in your experience? Let us know below. ⬇️

22/07/2026

Some ERP transactions carry real consequences when they go wrong.

A duplicate payment, a goods receipt captured against the wrong purchase order, or a reversal that requires multiple approvals to undo.

These are exactly the transactions that need simulation training before go-live. Here is how to build one that actually prepares people:

☑️ Identify what makes the transaction high-risk. Financial value, difficulty of reversal, downstream impact – the answer shapes how the simulation should be designed.
☑️ Build the scenario around a realistic exception. A clean walkthrough only prepares people for the easy version, so be sure to include at least one edge case or error that requires a decision.
☑️ Use a training client, not the live environment. Psychological safety is the point of this exercise, so if the stakes feel real, the learning diminishes.
☑️ Debrief after, not just before. What the user discovered during the simulation matters more than what they knew going in. Use this debriefing session to surface questions and correct assumptions.
☑️ Measure confident decision-making, not speed. A simulation is preparation, not a test, and the goal is getting the transaction right when it counts.

More on training design at cando.co.za/training-delivery/

Can Do Consulting

10/09/2026

09/09/2026

02/09/2026

26/08/2026

19/08/2026

12/08/2026

05/08/2026

04/08/2026

29/07/2026

22/07/2026

Address

Website

Alerts

Shortcuts

Share

Category

Listing takedown request