The 7 Sins of SAP Adoption
The #1 factor for SAP Success?
In 2018 Resulting published a vital piece of SAP Research - the SAP Success Report.
It looked at the driving factors behind the success, or failure, of SAP projects. To this day, it’s still regarded as a must read for organisations planning to embark on an SAP project.
The key finding was that those with a “high adoption focus” were the most successful, and that this factor alone had the biggest impact on the success of SAP projects.
So why do so many implementations still fail to focus on adoption?
It’s an important question.
All too often Adoption or Change Management (more on that debate later) is an afterthought. People don’t think about it until too late in the programme.
And, when they do finally think about proper training and adoption, they’ve run out of time, budget, and resources.
So what’s going on?
It sounds obvious, but to deliver any form of benefit from your new SAP solution, your business people need to actually use it as intended.
In reality though, it’s not black and white. People often wind up using your solution because they have to. But they won’t necessarily use it in the way you intended.
That’s why Adoption is such a critical factor.
Lots of organisations think that they need a change strategy when they actually need an adoption strategy.
Don’t trick yourself into thinking that change management is the same as focusing on adoption.
Adoption Focus is a mind set - one that doesn’t merely train your users on the new system - it gets them to embrace it.
Adoption is often thought of as something that happens after the initial go-live of an SAP solution - but that’s a dangerous misconception.
Do you want to know where Adoption really starts? And, where it ends?
There are 7 crucial components to a well thought through SAP adoption strategy.
Read on and find out which of the 7 Deadly Sins of SAP Adoption is most likely to trip up your SAP project success.
1. Lack of SAP Programme Sponsorship
How to do you get people to do something new?
To start with, you’ve got to tell them what you want them to do.
Problem is, your business people have lots of people telling them things.
Customers tell them things, managers tell them things, colleagues tell them something different.
If there’s one thing modern employees aren’t short of, it’s confusing communications.
If you want people to listen, you need a clear message. And it needs to come from someone important - that means an Exec or a member of the C-suite.
Sounds simple enough, right? Choose a member of the board to be the face and sponsor of your project.
Truth is, our research says that it’s rarely this straight forward.
Oftentimes, neither the business nor the project team know who their Exec sponsor is.
Sometimes the Exec themself doesn’t know they’re the sponsor.
So what should you do?
How to ensure strong SAP Project Sponsorship
Great SAP system adoption starts with great programme sponsorship. It’s impossible to overstate the importance of sponsorship. Leadership leads – simple.
Strong SAP programme sponsorship is:
Visible
Whether it’s ‘town halls’, talking head videos, blogs or podcasts - your sponsors need to be visible in their support.
Active
Sponsorship is not ‘in name’ or a one off activity, it’s active throughout the project.
Your sponsors should be in the thick of it updating, reminding, encouraging, and challenging the business and the project team to drive the right outcomes.
Specific
‘This project is crucial because…’ Your Sponsor should be able to communicate the ‘why’ of the project as well as the ‘what’. Explaining the project’s priority in respect to other initiatives can also be very useful.
Actionable
Sponsors are busy people, but when it counts they roll their sleeves up. They should be early adopters and advocate adoption. Actions speak louder than words - and this is especially true when it comes to using your new SAP system.
It’s only when you can say yes to all 4 of these do you have strong and clear project sponsorship.
2. Poor Alignment between the SAP Project and your business strategy
SAP is a big box of business processes.
Your business processes are the day-to-day actions that run your business.
But the way that you assemble your process, technology and people is what underpins your business strategy.
In other words, your SAP solution is probably a key ingredient in your business strategy.
So, why are so few SAP projects linked clearly to a business strategy?
Every project should begin with a business case that clearly outlines what the benefits will be for the business.
Sounds obvious, but you’d be surprised how many SAP projects either don’t have a business case, or the business case becomes ‘lost’ in the cut and thrust of implementation.
But this is only half the problem.
Even when a project does have a visible business case, scope creep and a commercially-minded systems integrator can easily lead you astray from your original vision.
You don’t just need to start with a business case, you need to refer back to the business case throughout the project to make sure you’re still delivering what the business needs at every stage gate. And well after the last one.
But how does a business case affect adoption?
If you’re asking “what does a business case have to do with adoption?”, you’re asking a good question - after all, providing you train people, won’t they simply use the system if they’re told to?
If only that were true.
The reality is people only do things if they understand why it’s important and are motivated to act - it’s classic Hoshin Kanri.
And, they only use software that makes their lives easier.
Your business case is vital because it ties your project to your business strategy.
It makes sure your project will deliver what the business needs - and it’s the first step to explaining why the new system is really important.
Getting both of these things right is fundamental to adoption.
You can find out how to create your business case for S/4HANA or any other SAP or ERP project here.
3. Lack of commitment and clarity from leadership
Explaining SAP to the business
So you've established who your sponsors are and your business case.
But ask yourself this:
Can you clearly and concisely explain your SAP project scope, the benefits it will deliver, and who your sponsors are?
If you can - congratulations!
But if you truly can, you’re in the minority.
Even when an SAP project has solid sponsorship and a clear business case, many projects fail to capture this in a single, clear document.
If you can’t easily explain it, how will your business people understand it?
This will lead to chaos and confusion when you try and explain it to the wider business.
So what can you do?
Create a Pact to get everyone on the same page
If you can't explain it to a six year old, you don't understand it yourself.’
The best way to define the purpose of a project is to write a Pact.
Your Pact will explain the project’s business case, the scope, and the sponsors. A great Pact will be no more than one page and written in a way that everyone will understand.
It makes it crystal clear who is behind the project, what they expect to achieve, and how the project supports your business strategy.
And remember a Pact is like a promise - it states what the project will give to the business, and what the business will give in return.
So you can also explain what you expect from the business in terms of attitude, ways of working and commitment to the project.
Then - you include the Pact in all of your communication and documentation.
- Make it part of the standard presentation template.
- Make it the first slide in the report pack
- Print it to posters and decorate the walls with it.
There should be no excuses.
Everyone should know what you are doing, why you’re doing it, how it will be done and what they need to do to support it.
4. Poor business engagement
Communicating your SAP project to the business
Your Pact defines exactly what you want to achieve. Now it’s time to let the business know.
So how are you going to do it?
Often, organisations show a grudging acceptance that they need to “do some comms”.
But the bigger question - is communication even enough?
Why settle for communicating with the business when we could engage them instead?
How to engage the business on your SAP project
Most SAP projects succeed in communicating but fail to engage.
What’s the difference?
Think about marketing - let’s say software marketing.
You don’t sell software by listing its features. You sell software by showing how it makes life easier - and by making it look cool. Why can’t we do this with our new SAP system?
Also, there are always multiple similar versions of a category of product - but people become fans of one particular brand. Are you an Apple person or an Android person?
Engagement is about creating fans.
So how do we apply this to adoption?
A multichannel approach to engagement and adoption
Engaging the business is all about “marketing” your project.
Different groups in the business have different preferences, needs, and capabilities. These are your target audiences. Defining and understanding these audiences is crucial.
Then, you need to hit different audiences with the right messages at different stages in their ‘adoption journey’.
Your Pact is just one communication tool.
Think about:
- Town hall meetings
- Talking head videos from influential people
- Youtube style content
- Focus groups
- Interactive content and surveys
- Building a strong Network of Excellence or Super Users
And use these as forums to start a discussion, not to issue diktats.
An important part of engaging business people is allowing them to ask questions and have a real input into your SAP project. Then showing that their input is being taken seriously.
Just because people accept something doesn’t mean they like it. To get the business to really engage with the project you need to make them superfans of your new SAP system.
5. An Ineffective approach to enabling business users
The challenge of SAP training
Enabling the business to use the system often comes down to training. That makes training and adoption the same thing, right?
Not really - so what’s going wrong?
The reality is training is never as simple as just “training”.
Getting training right is a complex process and can be fraught with problems.
Give too much training and you’re wasting time, money and sapping people’s sanity. Give too little training and they simply won’t be ready to use the system.
And that doesn’t even cover how you’re going to create, maintain and improve your training assets after go-live.
But really for users to adopt the system they don’t just need to be trained - they need training that meets their specific needs.
How to enable the business - not just train them
Business people perform a myriad of different roles, often in different environments.
They will approach training from varying levels of capability, experience, aptitude and attitude.
Their knowledge of, and even their access to, technology may differ significantly.
So why is it we often treat them as one amorphous mass under that ‘user’ label?
Our goal should be to enable business people to perform their new roles, using their new systems and processes.
Fingers crossed by now we have done a good job of motivating and educating them in the ‘what’ and the ‘why’. We now need to help them develop the ability to be able to take on this new challenge.
Then, at a point of need we need to prompt them to act.
That might be a video, a simulation, a guide, or a work instruction. It might be as simple as being able to see and play in an environment that resembles the new systems - a clone or a ‘dummy’ system.
What’s the point of training someone six weeks before go-live on a transaction they may not use until six months after?
Where we often go wrong is focusing on the activity of training when we should be focusing on the outcome for the individual - being able to transact and do their new job, when they need to do it. That’s about having ability and feeling enabled.
We need to be more sophisticated than completing a Training Needs Analysis.
How about Enablement Needs Analysis?
6. Lack of focus on driving adoption
Change Management vs Adoption in SAP
Lots of organisations think that they need a change strategy when they actually need an adoption strategy.
Adoption is all about accepting or starting to use something new. It’s about motivating and prompting your business people to put their new found skills to use.
Let’s be clear, not all projects or programmes have the same level of impact on the business.
For truly transformation change there will be some significant ‘change interventions’ required.
But for many projects, if you’ve followed the steps in this guide, by now your users should understand what you're trying to do.
If you’ve engaged with them, not just communicated to them, they should feel a sense of involvement in, and ownership of, the changes.
But it’s once you’re live that the real work starts. Your adoption strategy should focus on:
- encouraging use through messaging;
- fixing issues as they arise;
- providing process support;
- addressing gaps/delays in adoption;
- celebrating success
And this doesn’t just apply for the weeks and months after go-live. Driving adoption is something you must remain focused on throughout the life of your SAP solution.
The question is how do you know if people are adopting the system and where you should focus your efforts?
How to measure SAP Adoption
To really measure adoption you can’t just rely on anecdotal evidence, you need data.
You need Adoption Analytics.
Adoption analytics is all about using the data that is freely available to you in SAP to track that people are using the system in ways you intend them to.
This can be at a company or department wide level - for example making sure an activity is being executed with the same frequency as it was in the old system.
But it can also be done at an individual level - looking at the transactions someone uses over the course of a month and comparing and contrasting that with a model business person within the same role.
Sure — immediately after go-live you might see some drop off in usage. But, strong adoption analytics let’s you understand why - and understand if it’s a normal post go-live dip or something bigger and more serious.
Find out how you can use adoption analytics and visualise the data with FusionGraph here.
7. No continuous improvement or adaptation mindset
SAP adoption and training in the years after go-live
No that’s not a typo - it does say adaptation.
Probably the biggest sin that a project or a sponsoring organisation can commit is to think that adoption finishes with hypercare. It doesn’t. In fact, that’s where the fun really starts.
Why? Consider this.
Your solution will be out of date even as it goes live. While you were designing, building, testing and training, the world moved on.
Your business always wants something new to stay ahead of the competition.
Your system will always be changing and improving. There will always be people coming, going and moving around within your business.
Because of this adoption never ends.
Make sure you continue to support adoption after go-live by answering these questions:
- Do you have an adoption plan that goes on beyond the end of hypercare?
- Is there an established Network of Excellence, managed by the business for the business, that you will hand over to?
- How are you managing benefits realisation and reporting?
- What is your governance process for continuous improvement of your shiny new system and processes?
- Who will maintain the training and adoption content in BAU?
- How will you deal with Joiners, Movers and Leavers post go live? How will they get trained?
Ensuring adoption for the life of your SAP Solution
The benefits identified in your business case only get delivered when the project is live and is transitioned into BAU.
Adoption Analytics will help tell you whether the system is being used the way you expected, but so what?
The question is - post hypercare - who does that information go to and under what goverance do decisions get made?
Time and again after all the effort that goes into delivering a project, no one thinks about who is going to govern and manage it.
Who will own and measure benefits? How will continuous improvements and updates to training content and documentation be managed?
Depending on the scale of your project, this might not be a big deal.
But it’s worth thinking about.
If you are delivering something significant, managing SAP in BAU is a big deal.
If you need some ideas of what you should be thinking about why not check out our Ultimate SAP CoE Guide.