You should never be implementing SAP for the sake of SAP. The investment should be directly linked to the realization of business benefits over the course of a payback period. Without benefits, SAP is just a stopgap. An expensive stopgap.

Stop-gap / stäp.gap/
noun. a temporary way of dealing with a problem instead of satisfying the real need.

More often than not, project managers find themselves in the situation that their organization ‘is going wall-to-wall SAP,’ and they are then left to implement the chosen application without a clear understanding of the expected benefits and the organizational changes that will be required.

The Formula

Here is what happens next as the project managers work their way out: NT + OO = EOO (New Technology + Old Organization = Expensive Old Organization)

Any SAP implementation should be embedded in a fundamental business initiative to transform the business. You are not implementing SAP for the sake of SAP or because of its features like multi- currency, the ability to define sales organizations, reporting, etc.  Good old Michael Hammer knew this as no other.

You are doing so because you want to gain benefits that are essential for the survival of the organization. Technology is an enabler on that path. But if you fail to paint a clear picture of the destination it is a stopgap. The technology is rolled out, there is a successful go-live; pizza, party and then everybody goes home.

It ain’t over ’till it’s over

Benefits formulate the goal of a program in terms of the success of your organization. These are the beacons, guiding the program to develop in the right direction. Benefits are the basis of the business case to justify the cost of the SAP implementation. They make outcomes concrete, measurable and above all: actionable.

The point is that the project ain’t over till the benefits are realized! Implementing SAP is just a step on the path towards realizing the benefits.

Destination Postcard

In an ideal world, the decision to implement SAP fits in an overall business strategic program derived from the company’s business vision. In many cases, however, the decision to implement SAP is based upon a combination of less compelling operational features, listed below:
- Legacy systems need to be replaced;
- More integration of information is required;
- Better integration of the IT landscape is needed;
- The current version of SAP will no longer be supported;
- Common ways of working need to be implemented;
- The supplier of current systems doesn’t provide proper support, or worse, is no longer financially stable;
- Data integrity;
- Improved continuity and enhanced disaster-recovery planning

Yawn

Yawn-provoking indeed. But here’s the thing: unless you are able to convert the above mentioned reasons into benefits that serve the organizations strategy, you will not be able to win the hearts of your stakeholders. This means: a compelling vision AND actionable benefits that will prevent to see the SAP implementation as an end in itself.

In short: If you are unable to come up with quantifiable benefits, you should consider not moving forward with the SAP implementation. If you do, you risk getting lost in the fog without a beacon to steer for.

Outcomes are the destination postcard (you can see the picture and you want to go there), and benefits are the black-and-white writing on the back of the postcard (the exact coordinates). SAP is a fuel station on the way to the destination. If SAP is figuring either on the front or the back of your postcard you’d better cancel your travel plans. It’s not about stopgaping symptoms with SAP, it’s about treating the real causes with benefits realization!

The majority of the projects I am involved in are SAP implementations and most of the times we face the issue of explaining the impact of SAP to the future users, their bosses or their bosses’ boss. I grab the attention fairly easily by saying ‘this is not just a software implementation‘, but as soon as I mention ‘process thinking‘, ‘integration‘, ‘standardized methods of working‘ or ‘uniform master data‘ the message does not seem to land.  People are confused and the communication breaks down.

So I have to find better ways of getting our point across about the impact of SAP. The best way of doing that is to have someone who’s ‘been there and done that‘ to share experiences and stories. And that works. This is because people (that includes you and me) absorb stories far better than concepts, facts and figures. It’s our our human nature to be more compelled by bush-fire war stories than by accurate statistics and plain facts.

For that same reason metaphors work really well; a metaphor is a lively comparison that allows you to get your point across. Good metaphors stimulate the ’story’ part of the brain in different steps: first by highlighting a certain aspect that is abstract; second: by comparing it with a familiar element; third: by highlighting straightforward characteristics for this familiar element, and finally: retrofitting these characteristics to the abstract element. 

Here are some metaphors that have helped me to get my point across for audiences that are new to SAP. I have collected them from al kinds of clever people that I have worked with so far.

1. The Euro: one single currency
- The abstract element: getting a grip of uniform master data and what this will be like in the future state
- The familiar element: Uniform master data are like a single currency
- The straightforward thinking loop: when we changed to Euros we were able to use one single currency all over Europe. As a consequence all goods and services became comparable. The first year we kept calculating in our old currency but after a while we just got used to Euros and stopped to calculate back.
- The retrofit: Uniform master data – a single currency – will cause us tag one single article or equipment with the same identifier in all countries and all sites. As a consequence comparisons become possible and things become more transparent. In the beginning people will continue thinking in the old terms but as soon as they feel comfortable with the new ones they will let the old ones go.

2. The sports car and the racetrack
- The abstract element: understanding that processes are important in order for the system to run properly and that every user should understand them prior to using the system. 
- The familiar element: a sports car
- The straightforward thinking loop: SAP is like a beautiful and powerful sportscar with a powerful engine. However, a sports car can only race if there is a good race track and if the driver is skilled to drive it.
- The retrofit: SAP is powerful system – like a sports car, but it requires business processes - a racetrack - in order to work properly. On top of that you will need skilled users – drivers - at the steering wheel.

3. Concrete
- The abstract element: The importance of blueprinting and design before you build. 
- The familiar element: the concrete fundaments of a house
- The straightforward thinking loop: When you make the concrete fundaments of a house, you need a clear plan, the right equipment and the right construction people. Once the concrete is put in the ground it will easily fit the shape that you have dug. However, if you try to change a certain part of that concrete shape, it is very hard to do.
- The retrofit: SAP needs to be carefully planned and designed by the right people with the right equipments. If the system is not designed with the business processes in mind than the fundaments will turn out to be the wrong ones for the house that you are building – and corrections will be as difficult as changing the shape of concrete fundaments.

You will have noted that there are plenty of other metaphors that you can use and especially during SAP implementations there is a great need for making the abstract future tangible and simple. We stimulate people’s involvement and buy-in through a simple story, a straightforward comparison or a down-to-earth message. These are three things that look easy when we see or hear it from others but when it’s our turn…a writer’s block is the first thing on our path.

Do you know other good metaphors or catchphrases that relate to implementing SAP? Please share them in a comment to this article!

Here they are , in arbitrary order:
1. People don’t want to change. Not for the worse, not for the better.
2. Things will get worse before they get better.
3. Automate your project administration, not your project planning.
4. We think we see the world as it is, but in fact we see it as we are (Stephen Covey).
5. Change is in the details.
6. The real purpose of change management is to help people make sense of the change-pains – not to avoid them.
7. HR is not an agent of change but an agent of stability.
8. If integration is the destination, then make it part of the strategy and reorganize before you deploy systems.
9. The more accurate I start to plan, the more precise co-incidence will hit me (aka: ‘death by detail’).
10. Software does not replace discipline (aka: ‘the Debby rule’)
11. Legacy systems will always be better – from a rearview mirror point of view.
12. A good project manager is like a good parent: trustworthy, predictable and unpopular.
13. Real change takes time because it requires perception shifts.
14. The purpose is to make agents of your targets.
15. Uncertainty is worse than bad news.
16. Trust is the currency of change.
17. Communication will happen anyway, so better be at the steering wheel.
18. Seek first to understand, then to be understood (Stephen Covey).
19. Real participation means allowing people have a stake in the sense-making (this includes whining and letting-go rituals).
20. The essence of communication is to create community. Any exchange of information that does not accomplish this purpose is non-communication. Scan your meeting behavior as you keep this rule in mind.
21. Approach resistance with respect because it covers people’s most vulnerable and valuable part: their motivation and inspiration.
22. We choose our responses to the world – perception is a choice.
23. A vision is the shortest path between what is in my head and what people will see or hear (Bill Jensen). Compare this to your 180 slides Power Point presentation.
24. Communication is the message sent, not the message received (Bill Jensen).
25. Change all you want – but execution happens at the speed of sense making (Bill Jensen).
26. Although Organizational Change is not mathematical science, one truth stands out: OO + NT = EOO (Old Organization + New Technology = Expensive Old Organization) (Michael Hammer).
27. The bottleneck to human performance is in the limitations of available attention and learning capacity.
28. Gathering feedback and not taking action based on the findings can be more damaging than not gathering feedback at all (Naomi Karten).
29. In order to understand a system, you should try to change it (Kurt Lewin).
30. Culture is by far the best excuse for not changing. Don’t try to understand, rationalize or categorize culture. Rather, take it as a given and learn to navigate it.