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!

Communication is not the message sent but the message received. But when the receiver reacts opposite to our expectations we tend to blame the receiver. You are right and they are wrong. There is a name for this game;  it’s called "game over".

But hang on – here is the good news: if you to stop being right and start to investigate the choice architecture of your message, there is a great chance for you to improve your communication.

In a recent book called Nudge: Improving Decisions About Health, Wealth, and Happiness, economist Richard Thaler and legal scholar Cass Sunstein explore the psychology of our every day decision making and argue that we make poor decisions due to the architecture of how choices are presented to us.

This includes food decisions, investment decisions and all kinds of well-informed decisions (that’s the frightening part!).

Choice Architecture and Door Handles

Below is a excerpt from chapter 5 explaining the core ingredient of their book "Choice Architecture"

"Early in Thaler’s career he was teaching a class on managerial decision making to business school students. Students would sometimes leave class early to go for job interviews (or a golf game) and would try to sneak out of the room as surreptitiously as possible. Unfortunately for them, the only way out of the room was though the double door in front in full view of the entire class (though not directly in Thaler’s line of sight). The doors were equipped large handsome wood handles, vertically mounted with cylindrical pull about two feet in length. When the students came to these doors, they were faced with two competing instincts.
One instinct says that to leave a room you have to push the door. The other instinct says, when faced with large wooden handles that are obviously designed to be grabbed, you pull. It turns out that the latter instinct trumps the former, and every student leaving the room began by pulling on the handle. Alas, the door opened outward."

Further in that chapter the authors continue:
"At one point in the semester, Thaler pointed this out to the class as one embarrassed student was pulling the door handle while trying to escape the classroom. Thereafter, as a student got up to leave, the rest of the class would eagerly wait to see whether the student would push or pull. Amazingly, most still pulled!"

With this example Thaler and Sunstein point out that the doors display bad choice architecture because they violate a simple psychological principle called Stimulus Response Compatibility (SRC). SRC means that you want the signal you receive (the stimulus) to be consistent with the desired action. Flat plates say "push me" and big handles say "pull me". So don’t expect people to push big handles! This is a failure of architecture to accommodate to the basic principles of human psychology.

From Handles to Heamophilia

Saying "red" when you see a red light go on is an example of high compatibility. Having to say "green" when a red light goes on is an example of low compatibility. This has far reaching consequences, even in the medical world. Below is an example that I have experienced multipe times.

Patients with haemophilia A cannot produce a protein known as factor VIII (FVIII) and must get it from somewhere else. KOGENATE® Bayer is a FVIII product that a patient can use instead of natural FVIII. KOGENATE® Bayer is a great product which improves the lives of many haemophilia patients. But it’s also an expensive product, burdening social security with more than 100.000,- Euro per patient per year.

Needless to say: we better don’t waste a drip of this precious and expensive product! Yet, this is precisely where the engineers of Bayer have failed to cater for some SRC into the design of their injection bottles. Have a closer look at the instructions below: the fluid (drawn in black) is in one part and needs to be mixed with the powder in the other part. Movements A to J must be performed a few minutes prior to injection.

To cut a long story short: figure C and D is where it mostly goes wrong – even with well trained nurses, parents and patients. The normal way of using ‘fluid-and-powder’ products is to screw on and inject. That is what the design communicates: "screw and inject". Yet – as you can see in C and D, there need to be two separate pushes (followed by a ‘click’) prior to adding the fluid. The latter is so counter intuitive that I have literally seen thousands Euros being flushed onto the ground before my eyes.

Even trained parents and nurses who are familiar with this product need their full attention or they miss the crucial C and D.

OK for door handles. Not OK for social security.

From Heamophilia to SAP

To me the link with communication in big organizational change projects is obvious: communications are vital and precious for the health of an organization. And expensive too. Nevertheless communication sometimes turns out in the opposite direction. This is mostly due to failed choice architecture and untested stimuls response compatibility. When respondents fill out the wrong details, use the wrong settings or insert their card upside-down, it is easy to call them ’stupid users’ or to tell them RTFM (this stands for "Read The F** Manual").

I still remember the day that the logistics responsible typed the article number in the weight field when we were implementing SAP in a large chemical plant. The automatic interface that we were so proud of automatically blocked all the transports available of our 51 neighbouring plants. We had to write a program to unlock all those transports. And guess what we said: ’stupid user’. However, this did not prevent other users from committing that same mistake.

From SAP to Traffic

Next time you build a survey or a communication, a note or a manual requiring your receivers to fill out something, to use a system or to take an action of any kind, consider how SRC-proof your communication is by testing its usability at full length PRIOR to sending it out.

As a final thought I could easily link this idea to the communication articles I have written before. Whenever I talk about communication I tend to use the metaphor of traffic and this one fits in pretty well; If communication would be a mission to bring a vehicle (i.e. your message) from point A to point B, then you want this vehicle to be equipped with an SRC button. SRC will avoid your vehicle from going in the opposite direction when you accelerate.

Last Friday I was at the VOV beurs  - one of the big events on training and development  in Belgium. Starting from my experiences in SAP projects I shared my thoughts on bicycles, hunger, interaction and PowerPoint.

The video is in Dutch (with my own Flemish accent ) and you will find the English transcript below. So there you go: my thoughts on film and a free language course in one article!

Less training, more learning

I have an SAP background and some experience in large scale SAP projects. SAP is software that typically impacts the complete organization and a lot of users at the same time, and there is a great need for training. Last year the plant manager of a big plant came to see me. The fact that the return for the people on the SAP training sessions was disappointingly low caused some frustration.
What happened here? The organization thought that sending people to the SAP training was enough in order for them to be prepared for the day-to-day work with SAP. Together with that plant manager I discovered that people remember maximum 10% of what was taught in the training sessions.

In my opinion that’s normal because 90% of the things you need to know in order to perform your work cannot be taught in the classroom; you learn it when you need to solve a problem, when you receive the right communication and whenever you are obliged to take some actions in practice. Training managers need to be aware of that. 90% of what is needed for my job is situated in the field, so as a training manager I need to be in the field.

Bicycle?

Let’s suppose that we agree on me teaching you to ride your bicycle. I will prepare thoroughly and I will tell you all about the mechanical aspects of a bicycle. Next, I will tell you all about the laws of gravity. Then I will tell you about the organ of balance because it is the critical success factor for riding a bicycle without falling over. Finally, I will even make the training practical by showing you a real bicycle and I will even ride some laps so you can see what cycling is.

At the end of the day I expect you to be capable of riding a bicycle because you know all about cycling from A to Z.

This may sound absurd but is the current state of training and development: we teach people how to ride a bicycle by showing them PowerPoint slides. When they come out of the classroom we are surprised that "the thing isn’t working".

Cause?

What went wrong with the bicycle training? I made the mistake of looking at the training as a purpose in itself:
- I prepared the best materials;
- I showed the most beautiful bicycle;
- I may even have invited Lance Armstrong as a guest speaker.

While doing so I focus too much on the satisfaction of the participants. And what happens when the participants are happy? All of a sudden the training was brilliant in achieving its goals! All of a sudden whether or not you are able to ride a bicycle has become irrelevant. That’s immensely frustrating.

Solution

How are we going to solve this bicycle problem? I will alter my starting point towards what is needed for you in order to cycle. As a consequence:
- I will ask you to bring your own bicycle;
- Instead of preparing manuals, I will prepare a safe trail for you to drive around;
- Instead of standing in front the whole day animating and telling you how to ride a bicycle, I will be standing behind you to catch you if you fall.

Hunger

Whenever I conduct a training I ask the participants to state their personal objectives in the beginning of the day: ‘what is it exactly that you want to be better at when the day is over?’. At the end of the day we turn back to these objectives on the whiteboard and we evaluate whether the participants reached their goals.

The message here is clear: as a participant it is your responsibility to use me as a trainer in order to reach your objectives. That’s the best way of going through the day. It’s important to sharpen the training hunger so the participants are fully aware of what they want to get out of that day.

Interaction

I am aware that participants only remember about 10% of what I tell them or show them and therefore I trigger their own experiences as much as I possibly can.

My task is to ask the right questions and then to frame the answers that I receive. So I will not be standing in front too much of the time. Rather, I will be standing behind the participants to motivate them to come up with those answers.

Island

I often come across project managers complaining that people are stupid. When I ask them why they think so, they show me their slides and then they say: ‘my slides are very clear, don’t you think? I couldn’t possibly be clearer that that?’

But it’s not about the slides! At best those slides contain 10% of what a participant needs in order to perform his job in practice. The last 90% is situated in the field: in the middle of conflicts and problems. That’s where we need to be heading. That is exactly the reason why we are standing next to this lifebuoy: for the project leaders and training managers who desperately need to leave their PowerPoint Island.

_________________
Related articles:

- Knowledge = a Social Fabric – September 13th, 2009
- Return-on-Training? Wrong Question! – January 18th, 2009
- Do I need to paint a picture? SAP and Learning! – December 20th, 2008
- The End of Teaching – November 2nd, 2008
- Teaching versus Learning – May 13th, 2008
- How do you learn? – September 23rd, 2007
- It’s About Involvement, Stupid! – June 1st, 2007
- Learning and Resistance – May 22nd, 2007

Last week the manager of a plant involved in a major organizational change project claimed that the return-on-training of his classroom training courses was disappointingly low. Over the past weeks they have been switching over to SAP, by far the most popular platform in the segment of so-called ERP (Enterprise Resource Planning) software.

We have been preparing the users of his plant by means of extensive classroom trainings, both on process knowledge and systems skills. From his gut feeling he told me that his people demonstrated at best 10 to 15 percent return (i.e.: what they effectively remember and use in their jobs).

Training is the smallest part of Learning

I will not argue about the percentages. The point is that I obviously did not create the right expectations: he should be looking for the return-on-learning instead of the return-on-training! On this same blog I already announced the end of teaching and I also proclaimed that teaching is placebo. I even painted a picture about it in order to demonstrate what this means for SAP implementations specifically.

In retrospect the 10 to 15 percent reported by the plant manager is fairly high compared to what I always have been saying: 99% of what ‘Learning’ really is occurs outside of the classroom. The bottom-line is that training alone is not enough in order to make an organizational change happen. Increasing the quality of your training sessions will not leverage the return-on-training to the same extent. At the very best it is a starting point. From there on you will need to coach your way to the future state. The drawing below is taken from John Seely Brown (again!) and clearly depicts how learning really occurs

Now back to the return-on-training question. What could be the best way to increase that return? The answer is simple: this return can only increase if workplace learning has already occurred BEFORE the training session (in action, action through participation, participation with the world, participation with the problem and participation with other people, i.e., practices). Involvement, participation and ownership are key. 

The concept of Time-to-task is another way to look at it. Normally we use that term to describe that the training should occur as closely as possible to the task at hand. The only way return-on-training can increase is when time-to-task is negative. In plain English this means: people will get more out of a classroom training when they have been frustrated by real-life problems form the task at hand; they will posses an enormous learning pull and they will ask for and absorb every detail that is needed for the job at hand.

Here is a quote from David Maister to support that view:
"A good test for the timing of training would be as follows. If the training was entirely optional and elective, and only available in a remote village accessible only by a mule, but people still came to the training because they were saying to themselves, “I have got to learn this – it’s going to be critical for my future,” then, and ONLY then, you will know you have timed your training well. Anything less than that, and you are doing the training too soon."

Rethinking Knowledge Management

Participation, involvement and enculturation (i.e.: "belonging to") lies at the heart of learning. It also lies at the heart of knowing. Knowing has as much to do with picking up the genres of that particular sub-profession as it does with its conceptual framework. For example, how do you recognize whether a problem is an important problem, or a solution an elegant solution, or even what constitutes a solution in the first place?

Jerome Bruner made a brilliant observation some time ago when he said that we can teach people about a subject matter, for example, physics. That is, we can teach them the concepts, conceptual frameworks and facts of physics – the explicit knowledge of physics. But that does not make the student a physicist. To be a physicist he must also learn the practices of this profession. As he continues:
"We teach a subject not to produce little living libraries on that subject, but rather to get a student to think mathematically for himself, to consider matters as an historian does, to take part in the process of knowledge-getting."

So here we are. Now what? All the evidence tells us that learning is a social thing. It exists in action, participation with the world, participation with the problem and participation with other people, i.e., practices. A lot of the knowledge comes into being through the practices of the people and the environment you’re working in. The return-on-learning question reveals the challenge we face today for rethinking knowledge management:

1. shift our mindset from "pushing knowledge to people" (authority based and explicit) to "supporting people to participate in their productive inquiry" (situational based and on-the-fly)

2. Shift from tools to increase the individual knowledge stock to tools which support relationships and interaction. 

3. Shift rigid structures from managing an academy (where knowledge gathers dust) to facilitating an ecology of different communities-of-practice (where knowledge lives and evolves).

4. Do everything we possibly can in order to introduce Web 2.0 thinking in the boardroom. Think: collaboration and moments of truth instead of teaching!

Talking about organizational change management… there is work to do!

When it comes to implementing SAP, there is a large gap between what users need and what consultants think they need.  The drawing points out the difference between Training (restricted to the classroom) and Learning (anything that is needed to prepare a user) by looking at the question: “Where is the knowledge users need when they start using SAP from scratch?” (Click on the drawing to enlarge.)

Regular readers of this blog know that you can’t blame the consultants for missing out the largest part of the iceberg… after all, they are only ducks – unable to spot what could possibily be going on below the surface.

This was just a thought that came to my mind while we were discussing the priority of a key user during the delivery phase of an ERP program: should it be classroom training attendance or acceptance testing? One would say: for the sake of the quality of the system it should be attendance to the testing session; and for the sake of learning the key user should attend the training session. I say: NO WAY – testing is the main event for both quality assurance AND learning!

As I mentioned earlier, teaching is placebo in order for learning to occur. A Classroom training is at best a moment of truth in which the participants flip over the decision switch that says: "as of now I will be capable".  Learning occurs AS OF that pivotal moment – not ‘during’ and not ‘before’.

On the other hand: in testing you want to find something out or get something done. As John Seely Brown notes: it is about doing stuff; and then getting stuck while you’re trying to do something generates the passion to find out more about it. In testing you don’t get to build up an inventory of knowledge and skills. Learning happens on the fly, but you have to be willing to be confused, you have to be willing to make errors.

And there is more news: the digital divide between generations that we once thought of as being isolated to a group of nutcase computer engineers, introvert and pale skinned; has now gotten mainstream. Young employees, average IQ’ed moms and pops and even early adopters of the grey-haired generation are now subscribing to this new world of learning.

The Web 2.0 has a side effect on learning  and it’s a big one: throw away those expensive manuals and get out of that classroom! John Seely Brown refers to it as Learning 2.0 – day by day classrooms are becoming obsolete and social spaces – most of them virtual spaces – are finally being recognized as learning environments. In the below drawing I have taken a slide of John Seely Brown and fitted in where I think ‘Classroom Training’ and ‘Acceptance Testing’ belong.

Each day it is getting clearer that learning is social and that knowledge is a social thing. It exists in action, participation with the world, participation with the problem and participation with other people, i.e., practices. A lot of the knowing comes into being through the practices of the people and the environment you’re working in. When I say "the end of teaching", I mean: the end of a paradigm where we believe in knowledge as an inventory of stock – eventually gathering dust.

That’s me; I am about one inch away from being a persona non grata in the HR community. Primarily this was because I radically contradicted "the" Dave Ulrich when I stated "you are not an agent of change".  Last year, the people of HR Expert online were kind enough to publish this point of view in the article "An Organization that Is Serious about Processes Is Serious about HR".

But now there is a second reason for HR people to despise of my blunt opions on HR. In the October 2008 issue of HR Expert I now examine what it takes for HR to become a business partner. In short, the article covers a concrete three-step approach for HR to become a reliable business partner. The biggest takeaway for HR managers is an understanding about the importance of HR processes and how an ERP implementation should be used to support an HR strategy. Next to that we also outline some opportunities for managing expectations of HR.

Both articles are based on my observations as an organizational change manager on large scale ERP implementations. During those implementations one is involved in the trenches in a weird way; offering people new roles and responsibilities; focusing on processes as a new way of working and … sharing their frustration as HR is never involved and most of the times completely ignoring the changes at hand.

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!

In an earlier article I have argued that Organizational Change Management is a discipline and not a leisure activity. Here I would like to focus on the part where it gets real: execution and how to get all that stuff done in practice. In short: in order to be successful, organizational change efforts are not exercises in democracy but rather military deployments. This article builds further on that military metaphor to clarify my point.

Lessons Learned from Silicon Valley

In the chapter "On The Beach" of his 1993 book Accidental Empires, Robert Cringely talks about the three distinct groups of people that define the lifetime of a company: Commandos, Infantry, and Police. Whether invading countries or markets, the first wave of troops to see battle are the commandos. A start-up’s biggest advantage is speed, and speed is what commandos live for. They work hard, fast, and cheap, though often with a low level of professionalism, which is okay, too, because professionalism is expensive. Their job is to do lots of damage with surprise and teamwork, establishing a beachhead before the enemy is even aware that they exist. Ideally, they do this by building the prototype of a product that is so creative, so exactly correct for its purpose that by its very existence it leads to the destruction of other products. They make creativity a destructive act.

Grouping offshore as the commandos do their work is the second wave of soldiers, the infantry. On big projects these are the multitudes of ‘big 5′ consultants who get the job done: blueprinting, designing, testing, training, collecting and cleansing data, etc. The most important thing here is that an infantry takes on a structured approach. In the words of Cringely :
"While the commandos make success possible, it’s the infantry that makes success happen. These are the people who hit the beach en masse and slog out the early victory, building on the start given them by the commandos. [...] Because there are so many more of these soldiers and their duties are so varied, they require an infrastructure of rules and procedures for getting things done."

What happens then is that the commandos and the infantry head off in the direction of Berlin or Baghdad, advancing into new territories, performing their same jobs again and again, though each time in a slightly different way. But there is still a need for a military presence in the territory they leave behind, which they have liberated. These third-wave troops hate change. They aren’t troops at all but police. They want to fuel growth not by planning more invasions and landing on more beaches but by adding people and building economies and empires of scale. They can’t even remember their first- and second-wave founders.

UN Peace Keeping Troops

To my experience, this same distinction applies to big organizational change projects. However, in order to make this approach effective in that context, Cringely fails to notice that you need UN Peace Keeping Troops between the infantry and the local police.

Once your prototype is ready to be tested, you will find that UN Peace Keeping Troops are quintessential in order ‘to get organizational change management done’. This is the fragile process of handing over knowledge from project agents (infantry) to the target users (police and citizens) and to manage the process of political buy-in. 

In most of the SAP projects where I am involved we call them ‘local coaches’ or ‘transition teams’ They manage the fragile process of handing over knowledge from project agents to the target users. Their only purpose is to stabilize the new order and eventually to hand over to the local peacekeepers: the police.

A Best Practice from SAP Implementations

The below drawing shows a model that I would tag as ‘best practice’ because I have been refining it over the course of multiple projects. The yellow boxes indicate the basic principles we want to achieve.

Examples of typical coaching assignments include the following:
– Attaching people to new functional roles and having the subsequent trainings validated
– Communicating the vision and strategy and translating these to the level of the site (‘does this make sense to you?’)
– Communicating the future processes and highlighting the what’s in it for me (WIIFM)
– Local testing of processes
– Implementation and follow up of key performance indicators (KPIs)
– Following up data collection and data cleansing
– Supporting local training initiatives and evaluate the learning of the users after they went to training
– Assisting with the local technical systems deployment

The most important thing is to note that underneath these examples are some fundamental ’soft’ returns on investment:
– By their physical presence and time they spend locally the coaches can do the job of ‘handholding’ that is necessary in times of change
– They provide psychological safety by translating the central concepts to local practice
– UN Peace Keeping Troops leverage the impact of the experts in the central team on a local level because they have direct access to all implementation team members
– If you gather them on a weekly basis and if you facilitate their weekly meeting, they will accelerate best practices and stick to common standards.

UN Peace Keeping Troops need to be there to prevent simple things from going wrong and to help people make their first small victories in ‘real life’.

As I am writing this we are about to shake up a traditional organization by means of an SAP implementation. Most of the times this is regarded as a pure software implementation: design the system, configure the system, test the system and roll it out. That is how most software engineers look at it and that is what traditional managers expect of it.

Only, with SAP it’s slightly different: since the software is supposed to administer the way you get your work done inside your organization it is quite instructive as to which standards, timings, methods and data you should manage from then on. Very soon you will find that it pretty much dictates your way of working – that is – if you want to get things done you better align to the ‘way of the system’.

I’ve facilitated about five SAP implementations before from the change management side and as I am embarking upon my sixth one I am starting to see the importance of the factor time. SAP brings with it a number of changes like: different working methods, different documents, a change in an organizational structure, a change in a procedure or a dramatic change of existing SLA’s (Service Level Agreements). Some of these changes are pretty easy to sell, but others a bit tougher.

In an earlier article I presented a framework for positioning the changes accoring to two dimensions: degree of behavior change and degree of WIIFM (‘What’s In It For Me’). I borrowed it from John Gourville (Harvard Business Review 2006). However, since this week I have a bit more clarity on how to use it.

As a starting point I make a big inventory of changes. There is no structured approach to doing that apart from keeping your ears open and being there when people start to worry about the future. This inventory always comes to the surface when ‘old’ meets ‘new’. Mostly a bunch of consultants and a bunch of dedicated business people work together in blueprinting sessions and design workshops. That is when these conversations happen and that is exactly when you should have your notebook ready. Soon you will have an inventory of changes.

Next, it is time to plot them on the Gourville matrix. As a consultant, you should resist the temptation to do this task by yourself. As part of the exercise you should ask the stakeholders (mostly SAP key users or process owners) to map the changes on this matrix. This is what Edgar Schein calls a ‘diagnostic intervention’. In other words: you are surveying the stakeholders but the dignosis itself is an intervention that triggers a change process: people are forced to start thinking about the changes in terms of ‘will we resist or not?’.

Finally, when all changes are plotted you are ready to prioritize the communication in terms of timing. ‘Rough spots’ and ‘Long Hauls’ will need a lot of context (i.e. why-communication) to settle in – and this takes time. The reason is simple: you are introducing a foreign element that will shake up the way things are.

So this is what I will be kicking off next week: harvest the inventory of changes. Having them plotted on the Gourville matrix and then get to the rough spots as soon as I can. People need the time to resist, to say ‘over my dead body’, to bargain and to come to terms with the new reality. Wish me good luck!