Let's cut to the chase: the business owns adoption. There is no other way. A delivery partner can build the system and train people to use it, but changing the way an organisation works has to be led from inside the organisation. That needs business leaders who own the change, support from people who have done it before, and a start date long before go-live.
Most programmes agree with this on paper. In practice however, adoption often ends up owned by nobody. The delivery partner is contracted to deliver a working system. The business assumes that training will take care of the rest. Then when budgets come under pressure, change is often the first line to be scrutinised and cut, because its cost is visible today but yet its value arrives later.
The result is a familiar problem seen worldwide: the system works, but the business has not changed around it. People find workarounds and the old spreadsheets come back. Over time, the benefits in the business case slip away, and nobody can point to the moment it happened.
There are three such points in every programme. Adoption is won or lost at each of them.
1 - Design
Design is where the programme decides what will be different for people on the ground. A new approval route, a new screen for a warehouse picker, a new way of handling customer returns. Each of these is a change somebody will have to make in their working day.
If the people affected are not represented when those decisions are made, two things happen. The design misses details only they would know. The first time they then meet the change for the first time is then in training, months later, as something 'done to them.'
The fix is simple to describe and harder to do. Every design decision should carry a short note on who it affects and how. Those notes become the change impact for each role. A head of function should be able to see, early, exactly what will change for their team.
2 - Testing
User acceptance testing is often treated as a technical gate. It is also the first time many business users see the new system doing their real work. That makes it one of the best adoption opportunities in the whole programme, and one of the most often missed.
When testing is done by the people who will use the system, using their own scenarios and their own data, they start to trust it. They also find the problems that matter to them, while there is still time to fix them. When testing is left to the programme team, the business arrives at go-live as strangers to its own system.
This is also the moment for super users to step forward. A super user who has tested the system is a credible guide for colleagues. One who has only attended training is not much further ahead than everyone else.
3 - The first month after go-live
This is where adoption is decided for good. Every new system is slower at first. If people are supported through that, they adjust. If they are left alone with a backlog and unfamiliar screens, they build workarounds, and workarounds are very hard to remove once they have settled in.
Good support in the first month looks like super users with time to help, a clear route for problems, and leaders who keep explaining why the change matters. Success should be measured by how the system is actually used, rather than by how many people attended training or how many support tickets are closed.
Line managers matter more here than anyone. People listen to their own manager long before they listen to a programme email. A manager who says "we are doing it the new way" and means it does more for adoption than any amount of communication material.
What a head of function can do this month
- Ask for the change impact for your area, by role. If it does not exist yet, raise it with the programme now.
- Make sure someone from your team is in the design sessions that affect your processes.
- Name your super users, and agree in writing how much of their week the programme will have.
- Ask for your own people to run user acceptance testing for your area, with their own scenarios.
- Agree what support your team will have for the whole first month, including the first month-end.
If you are choosing outside help for this work, our guide How to choose an SAP change management partner sets out what to look for.
Where Limelight fits
We lead business change on the client side of SAP programmes, separately from the delivery partner and working alongside them. The business keeps ownership of its change, and the delivery partner can concentrate on the system.
If you are worried your team will be asked to adopt a system they had no part in shaping, book a Readiness Review. It is a 45-minute conversation with one of our directors.
