By early 2000 the ERP revolution1 generated over $20 billion in revenues annually for suppliers and an additional $20 billion for consulting firms. However, for many organizations ERP represents the return of the old IT catch-22 with a vengeance: competitively and technically it's a must-do, but economically there is conflicting evidence, suggesting it is difficult to justify the associated costs, and difficult to implement to achieve a lasting business advantage.
Critical success factors, and reasons for failure in ERP implementations, have now been widely researched . However, what is more noticeable is how the difficulties experienced in ERP implementations and with their business value are not atypical of most IT projects, especially when they are large and complex, expensive, take over a year or more to install, use new technology, and impact significantly on the organizational culture and existing business processes [5, 6, 10, 11]. Our own work on ERP success and failure factors differs in one essential respect from all previous studies. We have identified serious neglect in ERP implementations in securing the most effective roles for the CIO and IT function.2 Moreover, in case studies we have found failures in this area to be correlated strongly to subsequent difficulties in achieving delivery and business value.
This article spells out the several ways in which we have found the CIO and IT function (and relatedly it must be said, often senior business executives), asleep at the wheel on ERP. We then detail the more effective capabilities and organizational and cultural practices that explain ERP, and indeed wider IT, success. In practice, irrespective of the differing technologies being implemented, we have indeed found that there are still consistent IT management principles to be applied to ERP, and many lessons to be had from history.
The roots of the ERP revolution technologically are twofold: prewritten software available off-the-shelf with sufficient flexibility to match most needs; and an underpinning of data structures shared across many applications (so that data on a given invoice was not passed step-to-step but accessed from a common data structure). The first step promised a great improvement in software implementation productivityno time wasted reinventing the wheel and writing endless new software. Seen in that particular IT context, the promise has been delivered, but the context has been one of IT resource productivity alone.
The real value-adding opportunity has been to radically reshape how business is done and exploit the new automated, seamless ERP capabilities in the process. This is where the failure to deliver begins to be realized in many organizations. Improving "how business is done" is not just about integrating and creating more efficient transactional processesthe ERP route to business value is dependent also on major human, cultural, and organizational changes. Simply stated, effective ERP is about a transformation involving clarifying business strategy and objectives, and designing integrated processes, technologies, information systems and skills to deliver on these (see Figure 1).
In this context, on what occasions, and in what ways can it justifiably be said that the CIO and IT function have been, on ERP, "asleep at the wheel"? Our research identified three "asleep" modes and one main "wide-awake" set of capabilities and practices in ERP implementations, which we describe here.
Scenario 1: Technological determinism. ERP software has particularly lent itself to the notion of being a packaged total solution to a range of technical and business problems. This itself has become a problem when the CIO is technologically focused, the IT function's skill base is technical, and the organization is functionally driven, with the IT function seen by itself and the rest of the business to be the prime "owner" of IT issues. A relatively mediocre previous IT track record on business systems delivery and value becomes the basis on which ERP is handled and implemented. Invariably ERP is regarded as a new software system and the change equation that results, typically and disappointingly, is that shown in Figure 1.
In our study we found examples of such outcomes, especially in the early implementations in the 19951997 period in two banks, an aerospace company, and several manufacturing companies and public sector organizations. As one example a senior business executive in a U.K.-based multinational manufacturing company commented on a two-year ERP project started in 1996: "When I think back, the whole thing was seen as a technology infrastructure development. We were also promised a solution to Y2K problems. I recall the business case premised on infrastructure renewal, there was little there on business benefits ... it was assumed they would come ... (but) a lot on streamlining of technical functionality, indeed on a global basis."
In such examples, typically, the ERP project is abandoned into the often eager hands of the IT function, whose view is to deliver technical capability on time and within budget. The change equation posited is the first shown in Figure 1. In itself, this often proved more difficult than at first appeared, because of lack of relevant in-house IT skills, attempts to customize the ERP, and the complexity of linking with legacy data, systems, and technologies.
Scenario 2: Supplier/Consultant driven. A second scenario has been where senior business executives have taken the significant decisions without meaningful CIO and IT input, either because they see ERP as too important and enterprise-wide for the IT function to be left with the responsibility, or because the IT function has a poor track record and ERP is seen, somewhat like large-scale IT outsourcing, as both a way of replacing the IT headache with a packaged solution, and also a way of giving substantial IT work to external suppliers and consultants whose core capabilities lie in this area. This tendency has often been fueled by suppliers and consultants increasingly selling ERP not into the IT function, but into the boardroom itself. One noticeable feature of this scenario is how far the CIO is not regarded either as a peer within the top team or as an ally with loyalty to the business rather than to the IT function and to the technology.
Too often an outcome here is considerable cost overruns: one respondent mentioned the cost being 10 times that posited in the first feasibility study with suppliers. A second is lack of buy-in by the organization. The ERP gets implemented but the reengineering and training necessary becomes subsequently long and painful, while the continued use of external contractor staff causes a sharp rise in the maintenance and development budgets for ERP. While change equation 2 is posited (see Figure 1), the means to deliver it are not really present. Respondents in two-fifths of our case studies recognized this scenario in various degrees. As one example, in one U.S.-based manufacturing company operating globally, the ERP expenditure between 1997 and 2000 was estimated to be $500 million. The Board made the decision to launch a so-called global business integration project largely in negotiations with suppliers and consultants. Subsequently the IT function was supplying some 300 staff to the project, believed little in its value, but was receiving a high level of complaints from business units for their lack of ability to deliver on other pressing IT-related business requirements.
Scenario 3: Outdated relationships and capabilities. All too many IT functions and CIOs have not been in a sufficiently prepared state to step up to the admittedly difficult business challenges represented by new technologies, increased competitiveness, and changing and ever-pressing requirements from the business. Quite often, the business itself has not set a suitable context in which CIOs and IT functions can flourish. Where IT is seen as a cost to minimize, and as a cost efficiency tool and not as a potential strategic resource, and where the CEO and/or senior business executives are permanently disengaged from a business transformation agenda through IT, there is in fact little chance for the IT function to contribute significantly to business imperatives. Inflexible human resource policies on pay, career, and contracts also exacerbate the skills shortage problems many, including larger corporations, face in today's volatile IT labor markets.
Translated into ERP development and implementation, it can be seen how a third scenario has developed. Either change equation may be posited. In either case, the IT function is largely responsible for ERP, but is in no real state to be successful. It lacks the technical skills, but it also lacks the capabilities needed to manage the external suppliers hired to fill the planning and operational skills gaps. It also has not managed to build the relationships with the business side at CIO and operational levels, or helped to reorientate business thinking and motivation sufficiently to cause the business to step up to their key responsibilities in the reengineering, change and transformation aspects of ERP implementations.
In practice this scenario was the most common, even to certain degrees in the ERP implementations that were proving successful. As one CIO in an insurance company commented: "In the last three years I have not had time to rethink the skills base ... it's been one thing after another ... in some ways ERP was a blessing, there were so many problems I could shovel into it, but I can't say we were ready for it, the complexity, the management of the suppliers, the problems with the business...".
In practice, the need to identify and build key in-house IT capabilities before entering into ERP projects emerges as one of the criticaland neglectedsuccess factors we identifed throughout our practical and research experiences. Earlier research has been strongly indicative on this issue [2, 10], and the relevance of the capabilities displayed in Figure 2 for ERP implementation has been confirmed both in the multinational organization where one of the authors was CIO for six years, and with respondents in the organizations whose ERP projects we have studied. Thus Feeny and Willcocks  have identified the following nine core IT capabilities:
The need to identify and build key in-house IT capabilities before entering into ERP projects is one of the critical success factors.
These nine core IT capabilities must be retained in-house. Where, as frequently is the case in ERP projects, these key skills may be lacking one solution is to build them over time by insourcingbuying human resources off the market to work closely with the in-house team and ensuring that a transfer of learning takes place. These capabilities represent the minimal IT function needed to plan for and implement ERP for business advantage.
Once these capabilities are in place, the overriding factor then becomes the implementation process adopted. The main features of difficult projects, ERP or otherwise, continue to be large size, long time scales, complex, new or untried technology, and lack of clear, detailed project staffing and management structure. Moreover, traditional waterfall methods of systems development seem particularly inappropriate for implementing ERP-type projects if they are to be genuine business innovations. For these reasons, in highly competitive sectors, many organizations such as Ford Europe, Daiwa, British Airways, Woolwich Bankboth with ERP and for other IT-based projectshave moved to a different "time box" approach with very positive results. There are four main components of this wide-awake mode.
User vs. specialist focus. Projects like ERP that hope to embody IT-based business innovation are firstly, business projects, and secondly are inherently unstable. Detailed business requirements, as opposed to the overall objective, are unclear and subject to rapid change. Flexibility for further learning and innovation is required. Additionally, the technology itself (less so the ERP software) may be underdeveloped, lacking stability and detailed technical specification. Increasingly in fast-moving business environments, as IT becomes more organizationally pervasive, and in situations of low technology maturity , development can no longer be left primarily to IT specialists or external IT suppliers. If second-wave ERP is to happen then ERP-based business innovation requires a user-focused approach involving multifunctional teamwork, personal relationships, and business goals. Only when technology maturity is high, and a detailed contract and deliverable can be pre-specified does it become low risk to hand over those aspects of development and operations to in-house IT specialists or outsource to external IT suppliers.
Governance and staffing. Our present ERP study and earlier IT-related studies consistently show that effective IT-based business innovations require a high-level sponsor and a project champion, both taken usually from the business, not the IT side. The former will provide only up to 5% of his/her time, but will be involved in initiating the idea, underwriting the resources required, and protecting the project into business adoption and use. The project champion will provide between 20%60% of his/her time. The role involves communicating the vision, maintaining motivation in the project team and the business, fighting political battles, and remaining influential with all stakeholders, including senior management.
A small "dolphin" team is needed to implement the time box philosophy described here. Effective project managers have three distinguishing characteristics: credibility with the salient project stakeholders, a track record of success with this size and type of project, and skills in controlling the detailed actions needed to keep a project on its critical path. The multifunctional team will include full-time, high performing users, in-house IT specialists, people with bridge-building interpersonal skills, and fill-in external IT staff and knowledgeable users/managers as needed.
Time box philosophy. The primary discipline here is that the ERP-based business innovation must be delivered within a six- to nine-month period. Moreover the IT must be developed within the overall IT architecture for the organization. If on close examination this cannot be achieved the project does not start. However, it can be decomposed into smaller projects, each of which will deliver tangible business benefits. Time discipline reduces the risks of the project not meeting business requirements, ensures that big projectsor "whales"are reduced to a series of more manageable "dolphins," means that business benefits flow regularly rather than being delayed, and ensures the team has to remain focused and fully staffed over a more realistic, limited period.
Development proceeds by prototyping on the basis of the 80/20 rule, with the business accepting in advance that the first systems release may well only provide 80% of the functionality originally demanded. As the marketing director for Ford Europe described it: "80% systems are OK is now part of the culture round here."
The supplier/consultant role in ERP. External perspectives and knowledge can contribute much to the process of technical and business innovation. Furthermore, with the need for rapid delivery of systems to the business and all too typical in-house shortages of both routine and key skills, suppliers can perform an important "fill-in" role. More routine, easily defined tasks within the overall project can be outsourced. With IT-based innovation suppliers are most effectively utilized as resources brought in to work under in-house direction and control. The alternativeof outsourcing to a third party the management and resourcing of IT-based business innovationcan place the external supplier in an invidious position. Thus one European insurance company largely abandoned project management, driving out business requirements, and risk to its supplier. After one year the insurance company invoked penalty clauses for nondelivery to cancel the project, with the supplier incurring significant costs.
Compare this with the ERP implementation at ICI Polyurethanes between 1993 and 1998. The company started with a complex series of operations across Europe and a complex customer base covering, for example, auto manufacturers, shoe manufacturers and white goods makers. A clear change program was led by a very systems-literate CEO and backed by a very IT-literate finance director. The internal IT function was heavily involved in what was conceived as a business reengineering project from the start. The main steps were:
In practice the business has grown strongly in a very competitive marketplace. ERP achieved considerable business advantages including allowing vital tax negotiations to take place and enabling the eradication of 125,000 internal transactions involving the company doing business with itself. The IT function's role was integral to this success, and it followed many of the effective practices on in-house capabilities, user focus, governance and staffing, time box philosophy, and use of external supply emerging from our study.
Much of this, of course, assumes that the business itself has matured in its ability to manage ERP and similar IT-based business innovations, thus setting the context in which the CIO and IT function can thrive. In these circumstances there emerges from our study eight critical enabling factors if ERP-supported business innovations are to stand a chance of succeeding:
4. Holland, C., Light, B., and Gibson, N. A critical success factors model for enterprise resource planning implementation. In Proceedings of The European Conference in Information Systems, Copenhagen, (June 1999).
6. Parr, A., Shanks, G. and Darke, P. The identification of necessary factors for successful implementation of ERP systems. In Ojelanki, N., Introna, L. et al. Eds. New Information Technologies in Organizational Processes, Kluwer Academic, Boston, 1999.
1In our view an accurate term, which we borrow from .
2Our own ERP research, on which we draw here, is based firstly on acting as IT vice-president throughout the 1990s in a major multinational organization with multiple ERP implementations, and secondly on interviewing during 1999 senior business and IT and supplier executives participating jointly in 24 ERP projects in organizations throughout the U.S., Europe, and Australia.
©2000 ACM 0002-0782/00/0400 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.
No entries found