Can Do Consulting

Can Do Consulting For the past 30 years, Can!do has improved the performance of businesses by driving user adoption.

For the past 30 years, Can!do has worked with some of South Africa’s leading organisations to improve the performance of their businesses by driving user adoption of new business processes and systems.

Go-live is a milestone that's easy to celebrate. The system is live, the project team moves on, and everyone's attention...
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.

When change communication doesn't land, the instinct in most organisations is to send more of it – more updates, more ch...
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.

For most of ERP history, the go-live date was the milestone that everything built toward. You planned for it, trained to...
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.

A 92% training completion rate looks good on a report, but it doesn't tell you whether anyone changed how they work – an...
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.

The go-live date tells you nothing about whether the ERP investment worked.The project closed on schedule, the system is...
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/

A new screen layout is one of the most underestimated friction points in an ERP rollout. Users know how to do the work, ...
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. ⬇️

Some ERP transactions carry real consequences when they go wrong. A duplicate payment, a goods receipt captured against ...
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/

When people resist a new ERP workflow, the instinct is to push harder. But resistance is rarely about the system, but al...
15/07/2026

When people resist a new ERP workflow, the instinct is to push harder. But resistance is rarely about the system, but almost always about how the change was introduced.

Three approaches that address the root cause:

➡️ Explain the reason before the requirement. People accept new ways of working far more readily when they understand why the workflow exists. And “Because the system requires it” is not a reason. Connect it to something that matters to them.

➡️ Involve people before the workflow is final. The teams using the process daily will spot gaps that project teams may miss. Involvement creates ownership – and ownership is the fastest route to adoption.

➡️ Every new workflow replaces something that worked, at least partially. Acknowledging that makes people feel heard rather than overruled, and that shift changes the conversation.

Resistance handled early costs far less than resistance handled after go-live.

Which of these do you find hardest to get right? Let us know in the comments.

Go-live day is not when people need more training, but when they need answers – fast, in the moment, without having to s...
08/07/2026

Go-live day is not when people need more training, but when they need answers – fast, in the moment, without having to stop and ask.

The teams that handle go-live well are not always the best-trained. They are usually the ones who had the right support in place before the pressure hit.

Here is what belongs in a go-live survival kit:

✅ Quick Reference Guides – one task, one page, no jargon. Built for the moment someone forgets a step mid-transaction.
✅ A process deviation guide – a short reference covering the most likely exceptions and the correct steps to handle each one for when things do not go as expected and there is no time to guess.
✅ A known issues log – the edge cases and exceptions surfaced in testing, documented before they become surprises.
✅ Role-specific cheat sheets – not everything for everyone. The most critical tasks for each role, on a single page.
✅ A clear escalation path – not a generic help desk, but a named person, a response time, and a clear scope for each type of issue.

The kit only works if people know it exists, so distribute it before go-live, walk teams through it, and make sure it is within reach on the day.

🌐 cando.co.za

Address

142 Western Services Road
Johannesburg
2191

Website

Alerts

Be the first to know and let us send you an email when Can Do Consulting posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

Share

Category