Communications of the ACM

Communications of the ACM

Enterprise Resource Planning: The Role of the CIO and IT Function in ERP

By Leslie P. Willcocks, Richard Sykes
Communications of the ACM, April 2000, Vol. 43 No. 4, Pages 32-38
10.1145/332051.332065
Comments

By early 2000 the ERP revolution¹ 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 [4–8]. 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.² 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.

Back to Top

Asleep at the Wheel

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 productivity—no 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 processes—the 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 1995–1997 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...".

Back to Top

On Being Wide Awake: Key IT Capabilities

In practice, the need to identify and build key in-house IT capabilities before entering into ERP projects emerges as one of the critical—and neglected—success 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 [2] have identified the following nine core IT capabilities:

• IT leadership to devise the strategy, structures, processes, and staffing to ensure the IT function delivers value for money. Our own work on ERP supports that of Ross and Feeny [9]. In successful ERP the CIO must at least be able to build strong relationships with her/his business executive peers, must behave as a knowledgeable strategic partner with the business, and be able to align investments in IT with strategic business priorities. The IT function will have built, and will continue to strive to retain credibility for its ability to deliver on promises.
• Business systems thinking to ensure IT capabilities are envisioned in every business process. In the ERP context the failure to have integrated business, process, technology, and skills thinking and planning at what Markus has called the Chartering phase has frequently been a reason for suboptimal ERP business performance.
• Relationship building to establish understanding, trust, and cooperation among the business users and IT. ERP potential cannot be leveraged without strong coordination of effort and goals across business and IT personnel.
• Architecture planning to create the technical platform to meet current and future business needs. Again, this cannot be abandoned to ERP suppliers despite the seeming attraction as a total packaged solution. The client organization needs to maintain control over its IT destiny and its ability to plan for future technology requirements of the business while retaining the ability to have informed discussions with ERP suppliers.
• Technology fixing to rapidly troubleshoot problems and to create workable IT solutions to business needs. This capability to handle nonroutine technical problems as they are disowned in the technical supply chain must be retained in-house. Ross reports this happened at Dow Corning, and we saw it also in several of our examples of success. With ERP, suppliers and consultants cannot be expected to have the commitment or the specific business and technical knowledge to deal with the unusual company-specific problems that arise.
• Informed buying to develop a sourcing strategy and to evaluate and negotiate sound contracts with suppliers. This and the remaining three core capabilities are vital in ERP implementations, where so much use of external contractors, supplier staff, and consultants is made.
• Contract facilitation to ensure success of existing contracts through user-supplier management and multi-supplier coordination.
• Contract monitoring to hold suppliers accountable to existing service contracts and to the developing performance standards of the market through benchmarking and other means.
• Supplier development to identify and seek added value from supplier relationships by looking beyond contractual arrangements to explore long-term mutual benefits.

---

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 insourcing—buying 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.

Back to Top

On Being Wide Awake: Managing ERP Implementations

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 Bank—both with ERP and for other IT-based projects—have 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 [11], 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 projects—or "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 alternative—of outsourcing to a third party the management and resourcing of IT-based business innovation—can 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:

1. A revisioning planning exercise to position the business as a single pan-European operation;
2. Negotiation with many national tax authorities to allow the business to operate as a single legal entity across Western Europe;
3. A change plan to revise the "footprint" of manufacturing plants, systems, and processes;
4. The human dimension tackled as an integral component of the plan;
5. Business processes redesigned to align with the new streamlined business footprint; and
6. SAP R3 implemented to support and underwrite the new processes. Heavy emphasis was placed on training and implementation exercises. Very strong focus throughout was placed on delivery on business performance metrics.

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.

Back to Top

Conclusion

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:

• Senior-level sponsorship, championship, support and participation;
• Business themes, new business model and reengineering drives technology choice;
• "Dolphin" multifunctional teams, time box philosophy, regular business benefits;
• CIO as strategic business partner;
• Nine core IT capabilities retained/being developed in-house;
• In-house and insourcing of technical expertise preferred;
• Supplier partnering—strong relationships and part of team; and
• ERP perceived as business investment in R&D and business innovation rather than primarily as a cost-efficiency issue.

Back to Top

Back to Top

Back to Top

Back to Top

Back to top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.

---

No entries found