Benjamin Franklin once said that in this world only two things are certain; death and taxes. Were he alive today, he would probably have added a third: continuing analysis of ERP project failure.
We had hardly moved on from the Anchorage disaster before we read about the National Grid SAP failure, and that was quickly followed by the Lidl ERP debacle. Every time there is a failure, many knowledgeable people get down to analyzing everything that is known in order to try to identify lessons. Almost always, though, the answers are the same and fingers point at things like ineffective change management and poor project management. And next month there is another big failure to analyze.
What's going on? I contend that inadequate change management and poor project management are only symptoms and not fundamental causes. We can usefully remember the old Japanese saying, “Ask 'why' seven times”. So:
Q. Why did the project go wrong?
A. Ineffective change management.
Q. Why was it ineffective?
A. Because we didn't realize how important it was.
Q. Why didn't you realize how important it was?
I'm going to stop there, because you get the gist.
Incidentally; seven is just a suggestion and not a hard rule: the point is to continue asking questions, like peeling an onion, until you get to the real answer. Time and again, such analysis ends up with the same three root causes: failures in education, consultancy and training. In reality, of course, the three overlap and it is not always clear where education ends and consultancy begins, or where consultancy becomes training, and the borders blur even more when the same person or organization provides more than one. Nevertheless, they are all key to success.
Why do we need education and ERP training? Because it is essential for the C-level, for mid-level managers and for front-line operatives, although for different reasons. The C-level needs to understand what ERP can do and also what it can't do. They need this knowledge so that they can know what they should expect from an ERP implementation and what they should demand from an ERP implementation.
It is as damaging to set the bar too low as it is to set it unrealistically high. The C-suite needs to be challenging their managers and consultants at every step of the way and they simply cannot do that if those people have a better understanding of ERP than they do (notice that we said 'understanding' and not 'knowledge'; something we'll come back to).
The next step for the C-level is understanding why they want to implement ERP. An ERP implementation in even a small organization will take several months whilst, in a large organization, it can take several years. During that time, there has to be a clarity and continuity of the vision that only the C-suite can provide. If they are not clear about why they need ERP, then they can't be certain that they want ERP, and that uncertainty will permeate the entire project.
But senior management also needs to understand how an ERP project affects the organization and everyone in it. It is not just an IT project: it is a business transformation project (and, if it is not, then it's probably not worth doing). It is going to change how departments interact, it is going to change how people do their jobs and it is going to change what jobs they do.
Some organizations, such as start-ups, positively thrive on change but others, such as those operating multi-nationally and having to cope with differing cultures, are challenged. The upheaval to the way that the company operates has to be properly understood so that it can be minimized and so that there are no unpleasant surprises downstream.
The next questions to answer are: how much education do they need and who should do it? It is clearly impossible to turn people into ERP experts (i.e. to give them detailed knowledge) by sending them on a course but it is certainly possible to give them a good understanding of ERP within a day. A one-day overview will allow them to learn enough to ask intelligent questions and to understand the answers that they are given.
Because an ERP implementation is a very significant investment for any company, many of them feel that taking their executive team off-site to spend a day with experts is well worth the effort, even if it has to be done on a weekend (your core implementation team will be working weekends at key points in the project and will appreciate your example).
Moving down the organization chart, mid-range managers will need very similar information, but it is preferable for them to have separate sessions for a number of reasons. Firstly, there may well be things that the C-level wants to openly debate without causing unnecessary ripples and, secondly, mid-range management needs to have answers to different types of questions, such as, what will this mean to my department, what support can I expect to get and what do I need to tell my staff?
In getting answers to these questions, it is essential that they have confidence that senior management understands ERP and what they are asking for. If the messages coming down from above are not consistent, if the objectives and priorities seem to be continually changing, then it becomes impossible for them to hide that uncertainty from the implementation team and from their staff. At a very basic level; when the team comes across something difficult, they will be tempted to ignore it because the next set of objectives may lead in a different direction anyway!
The mid-tier of management also needs to understand that successful ERP implementations need compromise. No system is ever going to be a perfect fit, so the 'best' system will be the one that is best for the company overall and not necessarily the best for every department. That is one reason why an ERP implementation that is led by one specific department will always be second rate (at best) - experienced managers know that passive resistance is often just as effective as active resistance.
The best way to approach middle management education depends very much on the size of the organization. Ideally, they should all attend an off-site course as one group; again, at a weekend and definitely without their cell phones! In large organizations that might not be practical, so a more pragmatic approach would be to split them up into groups according to their operational interests (the networking and cross-fertilization of ideas that this affords should be maximized).
At the bottom end of the organization chart, the staff cannot be ignored if the organization wants the system to be as good as it can be. Luckily, today the fear of job losses following the introduction of new computer systems is largely gone, but staff still need to understand what is happening, and why. An ERP project, as was said, is a business transformation project that is going to make fundamental changes to the way that they work and interact with other departments.
Some companies have a culture that makes it easy for individuals to accept and embrace change but, in others, there is a real fear of change; in part because individuals do not have confidence in their ability to cope with change and fear the consequences. So, again, they need to know what is going to change (and what is not going to change!) because, at their level, they are thinking, “How does this affect me?”
They also need to understand that ERP is an integrated system in which their actions, and inactions, will be visible but they also need to know that management realizes that key to success is a well thought through program of training so that nobody will be asked to do anything that they cannot do and have not had sufficient training for. A valuable 'plus' is that people who understand the system will use it more intelligently, more effectively and more productively than those who don't.
Staff will obviously need comprehensive training so that they know what buttons to press, and why they are pressing them. But, for ERP overview education, an initial 1-hour briefing is adequate, especially if this is followed-up (as it should be) by weekly or monthly newsletters to everyone in the company, advising them of the progress being made and the challenges yet to come. These departmental level briefings should be carried out by the same managers who underwent the 1-day course because they can allay any fears or misconceptions before they get a chance to take hold.
For a successful ERP project, companies need two different types of ERP consultants; generic and software-specific (we could also use the terms strategic and tactical). Whilst in theory both types could be carried out by the same people, in practice this is a bad idea for several reasons; the most important being that generic consultancy is required before software is chosen and, aligned to that, some generic consultants belong to organizations that are also system integrators (SIs) which have very close links to particular ERP companies. So, any advice that they give cannot possibly be impartial.
Generic consultancy has a distinct over-lap with education and the two can often be carried out by the same people. Building on the initial education, generic ERP consultants can help with several things. Education gives an essential base but, in the next phase, companies need to know:
There is great value in retaining the consultants used in this phase to oversee and periodically review the actions of the SIs, and this adds to the argument for having separate consultants for the two phases, as it is unrealistic to expect people to monitor their own work objectively.
Whilst generic consultancy helps identify what should be done, a software-specific consultancy is needed to help identify how to do it. Although all full-function ERP systems do the same things, they frequently do so in different ways. Add to that the fact that all such systems have their unique strengths and weaknesses, and the availability of an expert guide becomes clear.
But product knowledge alone is not sufficient for these people, because they need the ability to think their way around problems - “The system doesn't do that, but if you do this, you'll get the same result”. In similar vein; a poor implementation consultant might reply to a question by saying, “There are three ways of doing that” but a good one will be capable of adding, “but this is the best way for you because...”.
Clearly then, ERP systems integrators and consultants need to be very knowledgeable of both the software and the business areas that it is being applied to. You don't want your sales processes specified by an accountant, your accounts system set up by a production manager and your production systems designed by a sales person.
Three mistakes regularly occur when planning training. With Tier 2 and Tier 3 systems, it is common for ERP suppliers to allocate just one consultant to do the entire implementation. The reason for this is that, although Tier 1 ERP systems require a large number of consultants, making it easy to cover all disciplines, most (though not all) Tier 2 & 3 suppliers are relatively small outfits with small consultancy teams. If they only have a handful of consultants, it's impossible for them to have specialists in each and every area. So, they put in an all-rounder; a jack of all trades although, to be fair, a jack who is usually master of one trade, whist perhaps being moderately competent in the others.
The second problem is that not every company has a bottomless pit of money. So, the ERP project has a budget that senior management wants to stick to. But the temptation to go out and buy the biggest, best and most expensive system that they can afford will be strong. Then the consultancy costs start to mount (they can easily total several times the software costs) and, when the budget is threatened, something has to give. Hardware and software costs are already committed, and most of the consultancy costs also, so training is left to take the hit (the author was present at an ERP kick-off meeting where the client's CFO arbitrarily halved the training plan with the justification, “We can't afford all that”. Was the project a success? I'll let you guess!).
So, quality of training can be suspect, and quantity of training can be inadequate, but there is one more point to consider. Many companies adopt a train-the-trainer approach in which the ERP supplier's consultants train a core team of client staff who then replicate that training throughout the organization.
In itself, this is a great idea: Confucius taught us that 'to teach is to learn twice', so the core team soon increase their knowledge and understanding of the system and, because they are seen by their peers within the company as being experts, communication improves; not least because in-house experts can use in-house terms to explain things. It is also of no small value that, after go-live, hard-earned and expensive knowledge stays within the company and doesn't leave when the consultants depart.
It is important, though, to recognize that they ability to train is not a skill that everybody has; regardless of their intelligence and level of knowledge. It might be necessary to send some people on courses to learn that skill, and it might be necessary to restrict training roles to those who have demonstrated that they can do it well.
So, there we have it: asking why seven times has identified that the things we need to get right are:
The next step, before initiating an ERP project, is to take the information in this article and to dive deeper. There are multiple blogs on the Third Stage Consulting website that will you do that and, if you need more help, it is just a phone call away.
