Enterprise Resource Planning - Research Paper Example

Enterprise Resource Planning (ERP) Enterprise resource planning (ERP) system is a type of automated information software system that enhances organizational performance by integrating business functions into a single system. A look at the past reveals ERP to be the evolved and modern form of MRP (Materials Requirements Planning) (Injazz J. Chen, 2001). Today, ERP systems have proliferated industries extensively, and have reached a stage where development has become industry specific. To give just a rough idea by the end of 1999, ERP systems accounted for over half the world's installed base of application software (Gable, van den Heever et al., 1997). The vendor organizations most prominent in this market are SAP (the market leader), Oracle, PeopleSoft, Baan and J.D. Edwards e.t.c. According to "The Conference Board" despite the expenditure of millions of dollars and the work of numerous staff people, 60% of ERP projects fail to deliver the results expected of them. This means that 6 out of 10 ERP projects are either not on time, and/or budget, and/or don't deliver the value expected from them a year or more after launch. Additionally, the study found that, in most cases, implementation costs are 25% over budget. (Dudley Cooke, 2001) This paper will review the most frequent problems encountered, recommend strategies to overcome these obstacles, and evaluate the potential to implement ERP systems in organizations. Criteria used to evaluate the effectiveness of ERP systems include benefits, functional requirements, hardware requirements, risks associated with implementing an ERP system, and cost. We have seen the industry statistics and know there are issues as well, now the pertinent question is to ask: what are the main causes of ERP failure and what can be done to prevent this from happening In this paper we will be looking at four important issues that can lead to the failure of ERP implementation: The risk of lack of top management commitment/strategy The risk of resistance to change/lack of buy-in The risk of inadequate requirements definition The risk of over-customization Lack of Top Management Commitment The implementation of an ERP project requires the acceptance, compliance, and commitment of a wide range of people: 'Implementing any integrated ERP solution is not so much a technological exercise but an "organizational revolution". Extensive preparation before implementation is the key to success' (Bingi, Sharma et al., 1999). Many experts such as King (1997) regard the need to secure a commitment to a course of action as possibly a more important issue than the determination of the most appropriate evaluation technique. The point here is that achieving positive attitudes and behaviors (especially those of the top management) directed towards a certain outcome may provide benefits that exceed those that can be attained from pushing for the optimum levels of choice. The tendency of top management to delegate the supervision of an ERP implementation to lower management levels usually results in being out of touch with critical events, or the lack of understanding of the scope, size, and technical aspects of the project, and subsequently, the proper commitment of time and resources required for a successful implementation. The result is a failure in the waiting. Involvement of the lower cadre is good but should not be at the expense of the top management being ignorant. Despite the fact that over 90% of companies that have installed ERP admit that they did not do enough to manage organizational turmoil (resulting from the implementation of ERP), most do not even have a clue as to how to minimize organizational distress nor to make it all seem worthwhile (Dudley Cooke, 2001). In my opinion it is the responsibility of the top management to take charge and manage the change. It is important for the top level management to realize that ERP will not create the wheel/cycle of business rather it will help keep the business wheel rotating efficiently, so the successful implementation of ERP is long/medium-term strategic goal of management. Since the top management is responsible for strategy formulation and implementation it is their responsibility more than anyone else's to own responsibility for the usual upheaval that ERP implementation will cause. Often ERP introduces peculiar and unique tensions that prevent the top management from getting together as one team because ERP impacts organizations in a different manner for different departments or business divisions. In most ERP scenarios, some executives will gain power, influence, and authority, and some will lose it. In other words ERP will benefit some while others might be anxious of its impact. This can be one possible reason for the top management not aligning as one single team (Jon R. Katzenbach, 1998). Management of this conflict of interest between top management usually lies with the top most authority such as the CEO. Ultimately, every employee needs to take responsibility for strategy implementation (of ERP), but an aligned senior leadership group must guide the effort, moving forward as a unified team, speaking with one voice. Resistance to Change/Lack of Buy We have just seen why and how important it is for the top management to show resolve and commitment towards the implementation of ERP. We now move on to the lower cadres, the middle and lower level management and the workers. It is important to understand that it will be these very people who will be using the new system. If for example the organization follows an authoritarian approach and simply issues an order for the implementation of ERP without consulting its employees, the employees would never accept the change. Even if the employees are forced to accept the change, the newly implemented system will never be utilized to its full potential. As already mentioned the implementation of ERP affects the organization at different levels differently, the lower strata employees are more skeptical of giant gut wrenching changes such as ERP implementation since it usually means changed job descriptions and occasionally job losses as well. This job insecurity factor tends to be the greatest apprehension point of employees, apart from the fact that people generally do not like to shift from their traditional way of doing things. Since most employees in traditional organizations do not have an understanding of ERP-driven business processes or their advantages, they cannot see how ERP fits the existing system. They can only see their own department, their job, their customer, for them the whole ERP venture may seem like an unnecessary and expensive hassle. This is where the role of effective communication comes in. We are specifically referring to vertical communication channels here, i.e. from higher to lower level and vice versa. The top management has to build a substantial case for the acceptance of ERP implementation to the employees. The advantages need to be clearly identified; each individual or groups need to be clarified about their status and responsibilities so as to remove any doubts and confusion in their minds. This lack of a change management approach as part of the ERP program can prevent it from succeeding. Resistance to change is quite often caused by: A failure to build a case for change, Lack of visible top management support and commitment, and arrogance, Lack of involvement by those responsible for working with changed processes, Inadequate communication. A lack of buy-in often results from not getting end-users involved in the project from the very start, thereby negating their authorship and ownership of the new system and processes. Also involvement of end-users ensures that any or all of the suggestions (such as for additional features, functionality e.t.c) are incorporated into the new system which is necessary for end-user ease and performance improvement. According to Bridges, transition has three phases. First, there is the process of "ending" during which employees tend to resist the change or fall into a kind of reverie as change unfolds around them. Then comes the second and the longest phase, "the neutral zone"; in which it's clear that the old ways are gone, but it is not clear what has replaced them and people yearn for the old days. Finally with careful and effective management organizations reach the "new beginning" phase. This means that the organization has found ways to enlist and engage a critical mass of employees to make them the drivers of change. (William Bridges, 1991) Inadequate Requirements Definition Surveys have shown that inadequate definition of functional requirements accounts for nearly 60 percent of ERP program failures (Dudley Cooke, 2001). This is simply a matter of not comprehensively and systematically developing a proper set of functional requirements definitions. This problem further leads to another great cause of ERP implementation failure: poor package selection. It is quite obvious that if an organization does not focus on creating a comprehensive set of functional requirements necessary for an ERP system then it might very well end up with a very good ERP system which is of no use to the organization itself. Even though many organizations have implemented ERP's but an ERP system as such is a unique endeavor of an organization. The implementation of ERP fits the description of a project. According to the PMBOK a project is: a unique and temporary endeavor to provide a product or service. (PMI, 2004) Since organizational dynamics such as organizational culture, the way of doing things, location, e.t.c can never be the same for two organizations (similarities are always possible) an ERP implementation is therefore unique. The first step in the building blocks of project phases is requirements analysis the outcome of which is requirements definition. The task in requirement analysis is that an organization identifies all possible requirements that it requires a particular ERP to have; these requirements are then detailed in the requirements definition document. In a scenario where an organization whizzes through the requirements definition part the project can never be successful, since the needful have not been identified or wrongly identified. This is usually due to: Lack/Shortage of time Failure to recognize the importance of requirements definition phase Lack of resources and technical expertise None of the above mentioned reasons justify neglecting the requirements definition phase since it is the basic building block of the edifice called ERP (or any project for that matter). Many medium-small organizations instead of having custom-made ERP go for an economical solution of using off-the-shelf and customizing it to suit their needs. Inadequate requirements definition would also mean that proper customizations will not be made to the system to suit organizational needs and the system will be quite generic. Its potential payoff in streamlining the enterprise and achieving cost savings is enormous. The loss/wastage of resources in the case of expensive custom built ERP will obviously be even greater. There are multiple ways in which an organization can proceed with the requirement Identification and definition phase. Some popular ones include: Sampling of existing documentation, reports, files, e.t.c Research of relevant literature, benchmarking of others' solution and site visits Observation of the current system in action and the work environment Questionnaire and surveys of management and end-users Interviews of appropriate managers, users and technical staff The list is not exhaustive and several techniques can be used in combination to gather the requirements. Though most of the activities might seem time consuming but as mentioned earlier it is not prudent to rush this phase due to its paramount importance. Risk of over-customization Customization is the process of fine tuning an existing system to meet specific requirements. It can include extending or changing how the system works by writing new user interfaces and underlying application code. This is usually done to tailor a system: To meet specific laws of a particular country To meet specific organizational requirements To reflect local work practices To conform to particular standards such as ISO As mentioned earlier in the requirements definition part, most small-medium sized organization and even some large ones prefer to purchase off-the-shelf ERP from vendors and then customize it. The cost differential between tailor made ERP and a customized one can be huge. Now there are usually two ways to customize an ERP. Either have it customized with the help of the vendor or customize it in-house. Another middle of the line approach is to customize the ERP with the help of a team consisting of both the vendor and organizational IT staff. The outcome of this activity is a product that meets the minimum requirements of the organization and yet is a generic solution. It is also to be kept in mind that customizing an ERP package can also be very expensive and complicated, because many ERP packages are not designed to support customization, so most businesses implement the best practices embedded in the acquired ERP system. Some ERP packages are very generic in their reports and inquiries, such that customization is expected in every implementation. Then it becomes unfeasible to customize each and every aspect of the system. In short, there are multiple trade-offs to be made in the levels and complexity of customization that an organization requires. Now let us move on to over-customization. We have already seen some trade-offs that an organization has to make in the case of customization, what if the organization forgo all the trade-off in favor of the system and customize and design the whole infrastructure of the organization so as to streamline the working of a specific ERP. This situation where the dependency of the organization on the ERP has increased to the extent that if ERP implementation fails there are good chances that the organization will be unable to switch to another ERP without incurring heavy losses is a situation described as over-customization. Apart from wasted resources both financial and non-financial that were spent in doing the "over" customization (which could have as well been spent developing an in-house ERP solution), this extremely high level of dependency on any ERP system or any system for that matter can be disastrous. Even problems such as closure of local vendor support (while the parent vendor is still operational) will then create huge problems for the organization. Over-customization will also require the organization to be more aware of the upcoming changes in the industry and the global marketplace since it will need to have time to plan beforehand if it will want to switch over to another ERP solution. In the case of a switch-over the whole set of end-users would have to be re-trained as well. References: Injazz J. Chen (2001), "Planning for ERP systems: analysis and future trend", Business Process Management Journal (MCB UP Ltd) 7: 374-386, ISSN 1463-7154 Gable G., Van Den Heever R. et al. (1997) "Large Packaged Software: the need for research",3rd Pacific Asia Conference on Information Systems, Brisbane, Australia, Information Systems Management Research Concentration, Queensland University of Technology, Queensland Australia 4001. Dudley Cooke, Lisa Gelman, William J. Peterson, "ERP Trends." (Report #R-1292-01-RR.) The Conference Board, 2001. Bingi P., Sharma M. K., et al. (1999) "Critical Issues Affecting An ERP Implementation", Information Systems Managemen,. Summer, pp 7-14. King M., McAulay L. (1997) "Information technology investment evaluation: evidence and interpretations", Journal of Information Technology, Vol. 12, pp 131-143. Jon R. Katzenbach, Teams at the Top. Harvard Business School Press, 1998. William Bridges, Managing Transitions: Making the Most of Change (Paperback), 1991. Project Management Institute (PMI), "A guide to the Project Management Body of Knowledge: PMBOK guide" - Third Edition, 2004. Read More