Business Accent

ERP implementation failures and the Philosopher’s Stone

Ipshita Basu examines ‘failures’ in ERP deployment and suggests how they can be addressed.

Ipshita Basu Guha

The term “Philosopher’s Stone” is a symbol related to Alchemy (meaning the way in which two individuals relate to each other) and it is a quest for transformation and spiritual illumination. Hypothetically it is a substance that the alchemists believed to be capable of changing base metals into gold. And yes, many of you have heard the term before in J K Rowling’s works. Well, alchemy is nothing but chemistry. ERP is also all about chemistry. It is how well people and processes are able to gel with each other. ERP applications come in diverse varieties with varying degrees of complexity from a number of vendors who are marketing their solution for a range of industries or for specific niches. Lots of ERP implementations are going on across the world in organizations of different dimensions and attributes.

One stark reality is that many of these ERP implementations end up being termed as failures. There are number of reasons for this and most can be avoided. Most commonly the failure can be attributed to human aspects. A Robbins-Gioia (provider of management consulting services located in Alexandria – Virginia) Survey stated that 51 percent “viewed” that their ERP implementation as unsuccessful. A Standish Group Study of ERP Implementations mentioned that 35 percent of projects are canceled and that 55 percent have overrun their budgets. Gartner also mentions that the industry success rate is 30 percent. The statistics are not very impressive for organizations especially SMBs where the resources are scarcer.

This article is aimed at informed top management personnel who wish to turnaround a failed implementation instead of scrapping the whole project, writing off the investment as sunk cost and trying to find a scapegoat. It is easy to pinpoint a problem but it takes a leader to resolve it. I am deeply influenced by the writings of Eliyahu Goldratt author of the famous book The Goal and believe that by performing a detailed analysis of a problem one can come up with a feasible solution for the same; one that is a win-win for all the concerned parties.

Suppose (unfortunately) your organization falls in that segment of a “failed implementation”, is it the end of the road? What recourse do you have? Can you salvage parts of the project and bring it back on track? Can you transform a failed implementation? If yes, then how? These are the questions that come to one’s mind and general pessimism surrounding the endeavor cloud our thoughts. But a failed implementation is not the end of the road. The war to conquer is not yet over. The failure can be turned around and you can succeed to a certain extent. However, this is not an easy task. The path ahead is uphill and full of obstacles, turbulence and major upheavals.

Most often the reason for failure in these cases is human—resistance to change. Oft repeated this is the truth and nothing but the truth. If you do an in-depth analysis, you will find primarily human causes. This does not mean that I am ignoring the technical causes entirely. I am not giving them greater relevance in this article simply because when the applications were evaluated at the initial stages of the project, one had all the opportunity to determine the technical requirements, its pros and cons—a process that is mandatory. Sometimes certain applications are selected or rejected on the basis of technical necessity. Implementation partners are also aware of the integration needs of their clients at the outset. Hence, the chances of technical upheavals springing up in the later stages of implementation are comparatively lower.

An organization should evaluate why it terms an implementation as a failure. This brainstorming session should be initiated by top management because they are the biggest stakeholders. Goldratt advocated that if you really want to solve a problem then you need to roll up your sleeves and get your hands dirty. Certain issues cannot be visualized or simulated sitting in an air conditioned room. The best way is to communicate one-on-one. The message should go out loud and clear that it is not a witch hunting session but a mission to find an amicable solution. The team should include implementation personnel, external consultants (if any), representatives from the implementation partner company and the all important end-user group. It is essential to gather why each of these groups feels that the implementation is a failure. Although it might sound prudish, the communication should be free flowing cutting across ranks. A good solution or advice is not the sovereign forte of the top management. Sometimes the best solutions come from the least expected corner.

Considering the team is in place, let us look at probable causes. Reflecting back on Goldratt’s Theory of Constraints—an organization needs to “identify the constraints first”. What are the issues that are making this implementation a failure? Where are the bottlenecks? Is it based on quantitative or qualitative factors? (For e.g. 1.567 mg of Cyanocobalamin or the tablet should be purplish yellow in appearance). Is the entire thing a reality or is it a problem of “perception”? Is the concept of failure a figment of the imagination? Usually a company should have a list of success parameters and metrics which is compiled at the beginning of the implementation. It is important that we do not get confused with perceptions and personal assumptions. If one perceives that the ERP package will display a tallied balance sheet at the click of a button, then it will not do so, but, that should not be the basis for adjudging it as inefficient. It is easier to infer based on quantitative parameters. But ERP has a human aspect too where people perceive that the product will function in a certain way and if it does not then it is concluded that the whole thing is a failure. The outcome of this evaluation should be candid and shared amongst all and most importantly open to meaningful debate.

The output should be a focused and valid list of pain points which need to be addressed and a collection of perception mismatch. One will find many instances of issues which are interlinked. When one is resolved, the others also fall in place. This list should segregate main issues and subsets thereof. This will infuse clarity. Organizations have dependent and independent variables. One should be able to segregate them in order to adopt a multi-pronged approach to deal with them. Events also occur in relation to one another. Let me refer back to Goldratt at this juncture. Whenever you want to change any system (which you will be doing in order to salvage the implementation) you need to be clear about three main things—what to change, what to change to and how to bring about that change. That is exactly what we are expected to do at this instance.

Let us assume that you have arrived at a list of pointers which define the causes of the failure in the implementation. This list should now act as your broad map to chart your course to steer towards the right direction. One can never say that an implementation will have no problem at all. Murphy’s Law is all encompassing. It can manifest itself anywhere in any proportion. The faster it is detected and rectified the lesser its impact.

The probable issues can be that the implementation team was not working smoothly with process owners and users or that the configuration of the application was improper and it was not able to bridge the gap mentioned in the Gap Analysis (As-Is To-Be Gap), the organization is still trying to map old business systems to the new application instead of the other way round which is recommended or even that the vendors and customers are not aligned to this new system and are acting as a deterrent to its success. They should have been brought into sync right from the initial phase and educated about how adopting this application is going to prove beneficial to them. It is all about how effectively you can market your ERP project to them. Instances of resistance are widespread from the logistics, finance-accounts, and materials management functions though the same is not enunciated. Most often the reason is hangover of the existing legacy application which became comfortable even though it might be inefficient and cumbersome. The materials management process has been streamlined in most ERP applications using industry vertical best practices. It makes more sense to adopt the same rather then distort the application beyond recognition and performance. The same argument holds true for the finance and accounts users. ERP is more about using and learning day by day rather then being straightforward like buying a shoe and wearing it. Inadequate ROI, cost and time overruns are also dominant causes. Well they are common in most projects but if the quantum is high then there is definitely a problem. Time overrun is basically due to bad project management and control. You simply need a stronger and disciplined person at the helm of affairs than the one that you have got. Maybe a change of personnel handling the PM role is indicated. Somewhere the project tracking was not adequate or simply put it was not good enough. Cost overruns happens since we cannot budget for each needle or pin. Costs crop up in the lifecycle of the implementation many times due to reasons beyond our internal locus of control. In many organizations problem occurs when there is a change of implementation consultant or process owner during the key phases of the project. Though unavoidable it is extremely undesirable. Users start considering the application to be a failure since it cannot be customized to their liking should be explained that ERP applications are generic for an industry and not custom-made for them hence they cannot function “very specifically for the organization”. One has to change the way they perceive the application or success or failure of any application because perception is never right or wrong—it is just a “perception”. One must employ more then one way of analysis and evaluation.

End users initially perceive ERP more as a threat rather than an opportunity. For them it is like revisiting the learning curve all over again. Sometimes the organization lacks in constructive and focused communication owing to which there is general confusion about the whole implementation and adding to that, negativity and disinclination.

Finally I would like to draw your attention towards Stephen Covey’s idea and views in relation to “turning around” a failed endeavor. An organization has to be proactive in willing to accept that there has been a failure (if it is justified) and then to analyze and rework the implementation instead of sitting and blaming the entire world for the debacle and doing nothing constructive about it. Things cannot change absolutely and overnight hence we should have achievable milestones defined for all the affected parties. Once you have the list of issues to be tackled, prioritize them in terms of their severity and urgency. If there are dependent events then they should be sequenced as per their dependency. Try and understand the situation and absorb what are the problems, why they have occurred and what should be done to resolve them before giving a half-baked solution. Covey says think win-win. This mantra can earn you a whole lot of convergence of thought and resolve of each and every personnel involved in the project. Working together as a unit will help resolve resistance and obstructions. Most often failures occur in team events when there are opposing views and stakes. And last but not the list, instill confidence in your team that all is not lost and everyone can still swing around and bounce back through this failure and make the ERP initiative work for the organization.

In case of a failed ERP implementation which can be compared to any base metal one should always be on the lookout for that idea(s)/ person(s)/ event(s) which can act as the “Philosopher’s Stone” to turn failure into gold.

The author works with a pharmaceutical company as Business Systems Analyst. The views expressed here are her own and not necessarily those of her employer. She may be reached at ipbasu@rediffmail.com