CASE STUDY QUESTIONS. EACH QUESTION NEEDS TO BE APA CITED AND REFERENCED ON THAT QUESTION. I DO NOT NEED A REFERENCE PAGE BUT A PROPER APA REFERENCE AT THE END OF THE QUESTION. Read "Successfully Navigating the Turbulent Skies of a Large Scale ERP Implementation" by Benoit, A. A. & Bourdeau, S. See link on your syllabus for download. This is a purchased case. Once you have read the case, answer the following questions. Note: These answers must be in a Word Processed document with all references cited in APA format. In order to receive full credit, these must be thorough answers. Must be Times New Roman, 12, double spaced. Due 11/15/17. PLEASE ENSURE YOU CITE WITHIN THE TEXT AND PROVIDE REFERENCES. YOU ONLY NEED TO DO THE QUESTIONS. I WILL PUT IT IN APA FORMAT, ETC. A REFERENCE PAGE IS NEEDED OR JUST PLACE THE REFERENCES IN APA FORMAT AND I CAN MAKE THE REFERENCE PAGE. I HAVE MADE THE APA REFERENCE FOR THE CASE STUDY References Aubert, B. A., Bourdeau, S., & Walker, B. (2012). Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation. International Journal of Case Studies Management, 10(1). 1.) What are the current challenges faced by Bombardier? 2.) What are the challenges associated with integration? What are the benefits expected from integration? 3.) How was the project team managed and is the project team's pace sustainable in the longer run? 4.) How were the processes defined to ensure a global vision and how should this vision be HEC035 Volume 10 Issue 1 February 2012 Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation1 Case prepared by Professor Benoit A. AUBERT,2 Simon BOURDEAU3 and Brett WALKER4 This case presents two phases of a large business transformation project involving the implementation of an ERP system with the aim of creating an integrated company. The case illustrates some of the challenges associated with integration. It also presents the obstacles facing companies that undertake projects involving large information technology projects. Bombardier and Its Environment Joseph-Armand Bombardier was 15 years old when he built his first snowmobile by propelling a farm sleigh across snow with the engine from a Model T Ford (CBC Archives). From these humble beginnings, Bombardier went on to become a key player in the transportation industry. It entered the rail transportation market in 1974, with a contract to produce 423 subway cars for the City of Montreal. A contract to supply New York City with 825 subway cars followed eight years later (CanadianBusiness.com). Bombardier’s desire to diversify led it to enter the aerospace industry in 1986, when it purchased Canadair, the leading Canadian aircraft manufacturer. Bombardier acquired Short Brothers plc, a manufacturer of civil and military aircraft based in Northern Ireland, in 1989, and Lear Jet Corporation in 1990 (Koselka, 1992). Bombardier made its final major acquisition in the aerospace industry in 1992, with the purchase of the de Havilland Company from Boeing (a timeline is provided in Appendix 1). For the year ending January 31, 2007, Bombardier Limited reported revenues of $14.8 billion. The Aerospace and Transportation divisions contribute fairly equally to total revenues. 1 The authors would like to thank all the people at Bombardier who participated in the case study, with special thanks to Souad El Mallem and Robert Proulx for their exceptional contribution. The authors would also like to thank Nicolas Perreault and Alexander Schnepel for their help in conducting this study. This research was supported by the CEFRIO. 2 Benoit A. Aubert is a Professor in Governance and Information Technologies at HEC Montréal. 3 Simon Bourdeau is a Ph.D. candidate at HEC Montréal. 4 Brett Walker is a Business Information Manager at Astellas Pharma Europe Ltd. © HEC Montréal 2012 All rights reserved for all countries. Any translation or alteration in any form whatsoever is prohibited. The International Journal of Case Studies in Management is published on-line (www.hec.ca/revuedecas/en), ISSN 1911-2599. This case is intended to be used as the framework for an educational discussion and does not imply any judgement on the administrative situation presented. Deposited under number 9 65 2012 001 with the HEC Montréal Case Centre, 3000, chemin de la Côte-Sainte-Catherine, Montréal (Québec) Canada H3T 2A7. This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Bombardier Transportation posted revenues of $6.6 billion for the period ending January 31, 2007. This represented 45% of Bombardier Limited’s revenues. Bombardier Aerospace reported revenues of $8.2 billion for the same period, or 55% of total revenues. Bombardier Aerospace Bombardier Aerospace is now the third largest designer and manufacturer of commercial aircraft in the world, after Boeing and Airbus, and the leading producer of regional aircraft. It is one of the two largest manufacturers of business aircraft in the world (Hoovers Online), with the widest range of business jets in the market (Canadian Business Resource). The Montreal-headquartered Aerospace division employs more than 27,130 people across 13 facilities worldwide (Bombardier – About Us). Six facilities are located in Canada, six in the United States, and one in Northern Ireland (Bombardier – About Us). The division’s management and administration employees are predominantly based in Montreal, Canada. Bombardier Aerospace’s various plants have specific roles in the completion of different aircraft. These roles include component manufacturing, component assembly, final assembly, painting and interior completion, and pre-flight testing and delivery. [See Appendix 2 for a list of Bombardier’s various facilities, their locations, and roles.] Bombardier Aerospace’s products Bombardier Aerospace is organized into four product and service lines: business aircraft, regional aircraft, amphibious aircraft and defence services. Within each of these lines, there are different families of aircraft, each with several aircraft programs (an aircraft program involves the design and production of one version of aircraft). The company has introduced 15 new aircraft programs in 15 years, and it certified a new aircraft every year from 1992 to 2000. Additionally, Bombardier Aerospace offers services such as aircraft charter, fractional ownership of business jets, aircraft maintenance and pilot and maintenance training. Bombardier Regional Aircraft consists of the CRJ Series of regional jets (which seat between 50 and 86 passengers) and the Q-Series of regional turboprops (which seat between 37 and 78 passengers). There are four aircraft programs within the CRJ Series and three aircraft programs within the Q-Series. Based on order intake, Bombardier’s regional aircraft held 50% of the market share for the 20-90 seat segment of the regional aircraft market in 2005. Bombardier Aerospace firmly believes that a larger regional jet is necessary to compete with the range of 100-seat planes that its nearest rival Embraer is introducing to the market. The C-Series was launched during the Farnborough Air Show in July 2008. These highly fuel efficient jets will carry between 110 and 130 passengers and will have the ability to fly transcontinental routes. Bombardier’s competition Bombardier’s closest competitor is Brazilian-based Embraer, the next largest aircraft manufacturer after Bombardier. Embraer focuses on regional aircraft, but also produces military © HEC Montréal 2 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation aircraft and one corporate model. Its range of 8 regional aircraft consists of both turbo-prop and regional aircraft. The Brazilian government owns more than 20% of Embraer (Hoovers Online). Boeing and Airbus occupy the top tier of aerospace manufacturers. Their focus is on the production of large commercial jets. The passenger capacity of Boeing and Airbus jets generally ranges from 110 to 400 passengers. In addition to producing commercial aircraft, Boeing is also one of the world’s largest defence contractors. Gulfstream is Bombardier’s main competitor in the market for business aircraft. The American-based company had revenues of $3.4 billion in 2005. Gulfstream offers seven models of business aircraft as well as operating a fractionalownership program similar to the service offered by Bombardier Aerospace. Conditions in the aerospace industry The willingness of the public to purchase airline travel is subject to economic conditions and the socio-political climate. This, in turn, directly impacts the performance of airline carriers and the aerospace manufacturers that supply them with aircrafts. The terrorist attacks of September 11, 2001 had an adverse effect on the airline industry. The detrimental impact of 9/11 was worsened by the outbreak of Severe Acute Respiratory Syndrome (SARS) and the war in Iraq (Federal Aviation Association, 2004). The combination of these events led to reductions in passenger numbers for large carriers. Continuing a trend that has been ongoing for several years, regional and low-cost carriers grew much faster than their legacy carrier counterparts. In 2005, the domestic market share for these carriers increased 2.2 points to 45%, up from a 30% share in 2000 (Federal Aviation Association, 2006). For this reason, the focus on regional aircraft means that Bombardier is well positioned to survive the adjustments occurring in the airline industry. Business problems While it now has a comprehensive range of aircraft and a global presence, the company’s strategy of growth by acquisition has generated some challenges. A senior project manager at Bombardier Aerospace commented that the organization has become a ‘textbook silo organization’ as a result of its acquisition strategy. Bombardier Aerospace inherited the data, processes and systems of each company it acquired. This created problems and inefficiencies, as systems did not communicate with each other effectively. It was difficult to share data between manufacturing facilities, labour mobility suffered due to the fact that the skills required to operate information systems were not transferable between facilities, and the cost of information systems ownership was multiplied by the number of systems maintained. Several problems related to the operation of the Aerospace division were beginning to concern management. These included process delays, sequential activities, low inventory turns, supplier proliferation and price inconsistency, and multiple bills of material. Bombardier Aerospace believed the biggest problem it faced was low visibility of inventory and lack of integration between its legacy systems. © HEC Montréal 3 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Legacy information systems The group of information technology applications that had been supporting Bombardier Aerospace’s manufacturing activities since the early 1990s was known as the Bombardier Manufacturing System (BMS). It was based on a MACPAC platform. This system had served the company well, but it had not evolved to cope with the changes the business had undergone and with the challenges it was now facing. Among other things, the BMS was struggling to cope with increasing inter-site dependencies, persistent pressures on costs, the rapid introduction of new products and a greater need for integration with business partners. According to the VicePresident of Operations and Project Sponsor, “MACPAC was showing a great deal of ageing. It was becoming increasingly difficult to operate, the data accuracy was appalling, and, indeed, the future development of the Company was being impaired by the system.” The BMS capabilities had become limited and the future development of the company would have been constrained if manufacturing systems had not been updated. According to the VicePresident of Operations, the production of the 90-seat CRJ900 aircraft would not have been possible using the company’s legacy platform. Employees had created a proliferation of stand-alone, user-developed databases throughout the company which were being used to maintain data on operations specific to their function. This fostered a culture where employees were unaware of the implications of data errors or omissions on the rest of the organization. Poor data management could hinder future initiatives such as the planned business-to-business procurement portal. For the past 12 years, Bombardier Aerospace had been trying to align the operations of its acquired companies by implementing common roles and responsibilities and common company values, and by introducing Six Sigma tools for the evaluation of processes. The Vice-President of Operations and Project Sponsor was acutely aware of the challenges and created a vision for Bombardier Aerospace that he termed ‘One Company.’ The desired outcome of this vision was an integrated organization in which employees would seamlessly share common data across sites and products using a single set of unified systems and processes. However, the project was more of a business transformation than a mere technology implementation, and it was critical that the project be grounded in a strong business foundation. He realized from the outset that altering decades of tradition was going to be an enormous challenge. The BMIS Project An Enterprise Resource Planning (ERP) system was considered by Bombardier Aerospace as the best way to realize the strategic vision. It was well aware of the risks associated with implementing an ERP system. A first ERP implementation at Bombardier Aerospace was discontinued mid-project in 2000 after $130 million had been spent. Various factors were subsequently identified by the company as having contributed to its failure. They included focusing the implementation on inappropriate business processes, an outdated company vision, a weak sponsorship model and insufficient involvement of internal employees. © HEC Montréal 4 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation In 2001, the process of establishing the need for a new integrated manufacturing system was headed by a group of senior managers from Bombardier Aerospace’s Irish facilities. The Senior Project Manager authored a project charter for the Bombardier Manufacturing Information System (BMIS) in October 2001. This document outlined the motivation for the project and a proposed plan for realizing project goals. The detailed analysis presented in the charter was used to secure ongoing approval and funding for the project. A BMIS steering committee chaired by the Project Sponsor was put in place in order to focus the project within the wider context of the business. At monthly meetings, the committee would make decisions on the direction of the project, review the status of the implementation and resolve issues that had been brought to its attention. BMIS was the first project launched to realize a wider ERP strategy and a vision of an integrated organization (One Company). This system was intended to support Bombardier Aerospace’s operations; it would focus on the processes that support manufacturing, procurement, finance and the engineering data required to support these processes. The amount budgeted to implement the BMIS across all facilities was $363 million. Once completed, it would support 9,500 users over seven sites. Its development required 400 people. The SAP enterprise system was selected. It would have to interface with 63 other systems, some of which were developed during the project. Bombardier Aerospace estimated that the successful implementation would result in savings of $1.171 billion, including a one-time reduction in material inventory of $219 million. Creating a vision The Project Sponsor mandated the establishment of a series of functional councils early in the project. These councils consisted of senior employees who represented the core functions at each of the company’s main production facilities across the world. These councils were to determine the role and direction of their respective functions within the proposed organization, participate in the review of processes and make rapid decisions on issues that affected their functions. Five functional councils were established: Methods, Quality, Production, Work and Material Planning, and Procurement. The Sponsor required the councils to formally report to him on a monthly basis throughout the project. Functional councils were an important means of achieving what the Project Sponsor termed ‘inclusivity.’ This entailed a large commitment by management and ample opportunity for all of Bombardier’s facilities to express their opinions and ideas. Other opportunities for site involvement included participation on the BMIS project team and sign-off on visioning and process documentation. As the Vice-President Operations and Project Sponsor explains: One of the big issues I had was inclusivity. I wanted most of the sites to be involved, because I wanted the ability to roll it out without a “not invented here” or a “Montreal-only” solution. I talked a lot about inclusivity to make sure all the sites were putting their views and their opinions forward and were involved in the definition of the processes. Once the project had received approval, the Senior Project Manager asked each of the functional councils to undertake a visioning process in which the different functions could propose their © HEC Montréal 5 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation prospective form in an ERP environment and outline the benefits they expected from the BMIS implementation. The output of this process was a visioning document that defined a model organization and that identified the key performance indicators required to successfully run the business and the skill set required for the functions to realize their proposed vision. Visioning workshops were conducted with the functions to facilitate this visioning process. The value management lead facilitated workshops and coached Business Project Managers (BPMs) on how to develop business cases, what benefits to expect and how to assess those benefits. BPMs acted as process owners and were responsible for decisions regarding processes. A small team consisting of the champion and senior project directors reviewed the outputs of the visioning process to ensure that it was aligned with the overall project vision. They examined how the functional organizations proposed by the functions would interact together and discovered that the proposed visions and key performance measures were misaligned. This resulted in the review team challenging the nature of the organization. For example, Procurement would practise strategic sourcing and evaluate purchasing decisions based on total acquisition cost. Quality conformance processes would be pushed to all stages in the manufacturing process, rather than in a final inspection. Finance would have the ability to track the cost of each aircraft manufactured. One of the primary objectives of the BMIS implementation was to reduce the clerical tasks performed by Bombardier Aerospace’s employees. It was anticipated that the automation of manual tasks would give their jobs a more analytical focus. It was also expected that an automated and highly integrated system would dramatically reduce the amount of paper used, the ultimate goal being a paperless workplace. The Vice-President of Operations and Project Sponsor was considered by Senior Managers to be an influential figure. He continued to show strong support for the project even as aerospace manufacturers were facing an uncertain environment. According to the BMIS Project Manager: He is a very ardent supporter of what he calls the One-Company approach. He was an ardent supporter that we all have a pay cheque that says the word Bombardier on it and we shouldn’t forget that. It is true in everything he did. He felt very passionately about it. How successful was he in creating change in the business? I think as successful as any human being could be without taking a baseball bat to everybody. The Sponsor began to communicate the overall vision for BMIS via a number of ‘road-show’ presentations at the company’s various facilities. These presentations also explained how the implementation of the BMIS would impact the everyday lives of employees. Even if the information was considered high level, it was perceived to be a very effective way of informing users. Messages promoting the One-Company vision were also included in company newsletters, broadcast in emails and posted on the company’s Intranet. All levels of management were responsible for passing on to their staff information regarding the project vision and progress. The Senior Project Manager emphasized to the Business Process Managers that communication was 80% of their job during the implementation. Managers used different means to communicate project information to their employees. Some managers held © HEC Montréal 6 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation regular meetings with their staff, some forwarded presentations and some made no specific effort to ensure employees were informed of progress. The BMIS project team A project team was established which focused on the preparation and deployment of BMIS. This team was located in the same building as Business Transformation Services (BTS), Bombardier Aerospace’s IS services group. Members of the BTS team made up the majority of the project team. The remainder of the team consisted of employees from the business who were recruited as business analysts. The BMIS project team requested that the business provide them with its most experienced employees. They were selected to represent their function’s point of view and to provide hands-on knowledge about the business. Employees who were recruited from the business were relocated so they could work full-time with the BMIS project team. Bombardier Aerospace was wary of employing too many consultants to assist in the project. The failure of a previous large-scale ERP system implementation was partly attributed to having too many third-party consultants employed on the project, and those consultants having a limited knowledge of the business. The ratio of employees to consultants was reversed from 1:10 on the previous failed implementation to 10:1 on the BMIS project. A stand-alone team was established to handle change management activities. At its peak, this team consisted of 50 people. Their responsibilities ranged from assisting in the preparation of functional business cases to managing project communications and training users. An employee from each function was transferred to the change management team for the duration of the project to represent the function’s interests and to liaise with the business. In most cases, the members of this team learned about change management on the job. Creating a blueprint The purpose of the design phase was to prepare a detailed design of the system that would meet the business requirements stipulated in these visions. The ‘to-be’ processes were designed by the project team and presented to the relevant functional councils for approval. It was intended that the project would be organized according to major processes. However, this was abandoned during the blueprint phase and the project reverted to a functional organization. The Senior Project Manager said that the business found it too difficult to communicate in process terms: “When we tried to do it process-wise, we practically couldn’t communicate with the business. So you ended up having to translate it into their language all the time.” An integration team was formed to validate the design carried out by the various functions and, as the Senior Project Manager put it, to “cut a line through the processes horizontally.” Their role was to identify integration points where a process crossed functional boundaries, and independently resolve integration points that could potentially cause disagreements. High-level decisions regarding the design of the project were made by the functional council responsible for the area of the business affected by a particular issue. More specific design issues were dealt with in design workshops that were held during the design phase. Managers from the business were invited to participate in these workshops. Scheduling difficulties and pressure in © HEC Montréal 7 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation the business environment (unrelated to the project) meant that attending workshops was not always possible for some managers. In some instances, they either did not show up or they delegated a lower-level manager; hence making it difficult for the project team to confirm the appropriateness of their design decisions and whether the business agreed that the proposed processes were aligned with their functional visions. As explained by a BMIS Project Team member in Procurement: “For example, at the start when we were sending invitations to workshops, Directors would delegate to a Manager, and the Manager would delegate to a Buyer. At the end, we had four or five buyers in the room.” The BMIS team requested that the plants provide them with experienced employees to participate in the design phase. The Mirabel Plant Manager1 said that he provided employees to work on the design of the system, but also stated that he believed you cannot participate in the design of a system unless you are committed 100% of the time. Mirabel sent three business analysts to participate in the design phase; one each from Methods, Engineering and Logistics. Members of the project team at all levels agreed that the Mirabel plant was not as involved in the project as other plants. Some managers and users from the Mirabel plant felt that the system belonged to the project team and was being imposed on them. On the other hand, there was a feeling on the project team that users and managers from the Mirabel plant were waiting for the system to be delivered by the project team. In their opinion, the business side was reluctant to take ownership of the system. Furthermore, the project team was located approximately 50 km from the plant. The BMIS Project Manager was concerned that there was a lack of strong business employees involved in the design of the project. Other senior project members echoed this concern, with one Project Manager saying: We had a number of problems resolving design issues on the project because the people, although empowered to make decisions and to complete the design, I think struggled with resistance both within themselves and back with the business, because they were constantly having to go back to the business in order to validate. On several occasions, the business asked the BMIS team to provide it with documentation illustrating the high-level processes that were to be included in the system. The Director of Procurement said that they received hazy answers and were not provided with the documents that they requested. Some people from the business suspected that the project had not always completed the design. The design phase ran over schedule by several months. As a result, the realization and integration testing activities became overlapped and the time available for testing was under pressure. Progressive implementation Bombardier Aerospace decided not to implement such an extensive system using a ‘big bang’ approach. Full implementation of the system was to take six years. BMIS would be implemented one plant at a time, beginning with the company’s newest facility. Assembly of the CRJ700 and CRJ900 aircraft is done at the Mirabel plant, located near Montreal. The Project Manager said 1 Within the Bombardier Aerospace hierarchy, the general manager of a plant has the title of vice-president inside the organization. Therefore, the terms “Vice-President, St-Laurent” and “Plant Manager” are used interchangeably. © HEC Montréal 8 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation that Mirabel was selected because the CRJ700 is very much a ‘manufactured’ plane, and this model of plane is expected to drive Bombardier Aerospace’s growth in the future. As stated in the BMIS Project Charter, “This [phased implementation] will allow the necessary business evaluation and also perfect the roll-out processes, techniques, and tools, prior to subsequent rollout activities.” A ‘vanilla’ approach to system design was identified as a critical success factor for the project. Bombardier Aerospace believed it was important that minimal modifications or enhancements be made to processes in SAP. Senior project and business management considered the first roll-out at the Mirabel plant to be a controlled pilot implementation. Bombardier limited the scope of the first implementation in order to get the system operational in a restricted production environment and identify lessons for subsequent roll-outs. The Mirabel Plant Manager believed that the scope of the pilot implementation could have been even further limited to one part of the Mirabel plant: “I would not implement wall-to-wall. I would isolate a section, prototype the thing there, and then develop the proper material to train the rest of the shop. I would do the proper adjustments to the system and then I would do the entire shop.” Inventory management was positioned at the core of BMIS. The Vice-President of ERP stressed this was important, as at least 75% of the cost of manufacturing an aircraft can be attributed to material spending. The first roll-out was limited to the implementation of SAP modules that were considered essential for improving operations and inventory management. Modules that were deemed more strategic would be brought online once a foundation of core modules had been established. The focus on inventory management was not endorsed throughout the company. Some managers considered this focus to be misguided. Restructuring of the Procurement function Bombardier Aerospace’s Procurement function has an important role in realizing the vision of the Bombardier Manufacturing Information System. The primary goal of the system was to improve the visibility and reduce the value of inventory held by Bombardier Aerospace. Reduced product costs of $22 million per year and reductions in procurement overhead of $7.1 million per year were anticipated at the outset of the project. Inventory is the most significant cost for an aircraft manufacturer. Reductions in inventory levels would improve liquidity and reduce cycle time. In the legacy environment, Procurement employees were being rewarded for purchasing inventory at low prices. This encouraged bulk purchasing. Total acquisition cost was not being considered when making purchasing decisions. Additional objectives for the Procurement function were to move towards a policy of global strategic sourcing, eliminate all clerical activities, automate as many processes as possible and improve supplier compliance. It was decided mid-project that restructuring the Procurement function would help to achieve these objectives. Senior project management had been considering a reorganization of Procurement for some time, but it was not announced to the rest of the organization until April 2003, during the realization phase. The restructuring was undertaken in parallel with the © HEC Montréal 9 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation implementation of the BMIS, but was completed as a separate initiative. This entailed changes to processes and employee roles and responsibilities. Modifications to roles and responsibilities in Procurement were confirmed a few months before the Go Live. Prior to the reorganization of the Procurement function, employees were either planners or buyers. Planners were responsible for determining the inventory required for a particular aircraft based on production planning. Planners did not interact with the suppliers who provided these parts. Buyers would coordinate purchase requisitions issued by planners, create purchase orders based on these requisitions and send them to the relevant suppliers. New roles and responsibilities were developed. Employees in the post-BMIS Procurement function would become sourcing agents or logistics agents. Sourcing agents concentrated on centralized and strategic sourcing of inventory for all internal customers. This involved negotiating contracts that would minimize the total acquisition cost and overall procurement costs. Several buyers were joined by planners in the role of logistics agent. This role would oversee the acquisition process. It was necessary to bring these buyers up to speed on planning processes, as this was not part of their previous role. The Material Resource Planning technology implemented creates almost all of Bombardier Aerospace’s purchase requisitions for the CRJ700/900 program when lead time criteria are met, and automatically sends them to suppliers by fax. This effectively substitutes a lot of the work previously done by planners in the legacy environment, creating more time for analytical activities. It was difficult to explain the changes to users when exact details were still being defined in the final months of the project. Management was aware of the substantial magnitude of the change that users were about to face. A newly appointed Director of Procurement at the Mirabel plant likened it to taking 60 new employees from outside the company and having them ready to use the system in three weeks. Even if employees were very familiar with the business, their roles and responsibilities were completely new. Procurement employees were confronted with a new system, new roles, new processes, new management, new supplier files and, in some cases, new colleagues. Data management Data management was organized as a separate, parallel project consisting of two broad sets of activities: data cleansing and data preparation. The Sponsor advised senior project management that he was willing to establish a distinct organization to manage data cleansing and preparation at any stage during the project. This was an indication of the importance he placed on data management. Data cleansing was identified as a major risk at the outset of the project. During project planning, it was decided that the business would be responsible for cleansing its own data under the guidance of a data cleansing team. Data was shared amongst the business and the BMIS team. The BMIS team was responsible for the preparation and conversion of cleansed data. This involved the extraction, mapping, staging and consolidation of data required for the implementation before uploading it to the target systems. The BMIS project team put in long hours leading up to the Go Live in order to have the data ready and loaded into the system. Users from Procurement spent the first few weeks following the Go Live cleaning data relating to the buyers and parts they were responsible for maintaining. In the first week following Go Live, © HEC Montréal 10 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation one user had to begin cleaning data on 20 suppliers and 1,200 parts. This involved reorganizing and cleansing data from hundreds of separate files using a system with which the sourcing agent was not familiar. The Mirabel Plant Manager said, “Because some of the quality of the work that was done during the data clean up was questionable, we had to redo a lot of the data clean up. We just finished three months ago, nine months after the Go Live.” Late decision to go with Workbench Bombardier Aerospace made a decision late in 2002 to change the Methods and Engineering function’s software supplier. HMS Software had been mandated from the beginning of the project to provide its Computer-Aided Process Planning (CAPP) product, a process planning system for managing manufacturing information and work instructions. This was one of several systems that would interface with SAP. SAP had been developing its Workbench module since the BMIS project had commenced. SAP Workbench served the same purpose as the HMS CAPP product. Bombardier Aerospace thought the improvements to the SAP Workbench product were significant enough to warrant a major change to system architecture at that stage of the project. This decision met the company’s criterion that called for implementing SAP unless there was an alternative solution significantly more capable of meeting business requirements. A third-party consulting firm working on the project was not convinced that SAP would commit to implementing the Workbench module within such a tight schedule. Bombardier Aerospace was aware that configuring the module within a three-month timeframe was a significant undertaking and represented a risk to rolling out BMIS within the deadline. The decision would send the Methods function back to the beginning of the blueprint phase and on the project’s critical path. The project’s Business Process Manager for Methods believed that working closely with SAP, seeking a lot of feedback from it and having an SAP representative on-site would enable them to successfully implement SAP Workbench within the overall BMIS deadline. Integration testing All of the integration testing cycles were based on cross-functional business scenarios created by analysts appointed by the business. A number of work steps were established and documented for each scenario. The scenarios and work steps used in integration testing were derived from the system design created in the blueprint phase. After establishing a high-level cross-functional scenario, business analysts would work in smaller teams to create the part of the scenario and the work steps relevant to their particular function. Cross-functional teams would then reassemble to make sure these distinct sections of the scenario would work together. The BMIS Project Manager used the analogy of preparing a ship for battle to describe the process of implementation testing, which involves four cycles. The first cycle tests the activities within a sub-area of the system, such as purchasing or preparation of the general ledger. This initial cycle makes sure everything is working well within the functions. This is the equivalent of testing the separate components of a ship in dry dock. During the second cycle, members of the integration testing team went through previously created scenarios using manually created data. The ship has now been taken out of dry dock, steered around the harbour, and parked back at the dock to © HEC Montréal 11 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation ensure that its components work together in an integrated way. The work steps established in cycle two are tested using converted data during the third cycle of integration testing. The ship has now participated in war games with friendly fire. The fourth cycle uses the established work steps and converted data to carry out user acceptance testing. The ship should now be ready to go into battle. The outcomes of all testing cycles were documented and stored in a database. The first cycle of integration testing was carried out according to plan and on schedule. However, problems arose during the second cycle. The integration testing team discovered that the business people involved in writing the work steps and scenarios did not know the business as well as was necessary. There were several cases of disagreement during the writing of the scenarios and work steps. Resolving these disagreements caused delays in the completion of the testing phase. The project team became frustrated when the business questioned processes that it had approved during the design phase. A business analyst said that some directors would agree to the propositions put to them in design and then complain that the system did not meet their needs when it was deployed. Tracking project status A scorecard system was used throughout the implementation to track project status. Monthly status report scorecards were completed by the project team and submitted to the Vice-President of ERP and the company’s Project Review Board. These scorecards presented information on key activities completed, key upcoming activities, project risks and high-level issues. Important project indicators were allocated a status of green, yellow or red according to the urgency of the problem and the attention required by management to resolve any issues. As the Go Live date loomed closer, senior project management requested that the project team include more detail in these reports. Daily status meetings were held in the final months leading up to the Go Live. The Business Project Managers would meet with the Senior Project Manager each afternoon in a project ‘war room.’ The purpose of these meetings was to resolve issues related to integration testing, development requests, change requests, and any other escalated issues that warranted their attention. The First Roll-out Preparing the users The use of power users was an important component of the company’s knowledge transfer strategy. The primary role of power users is to prepare end users for use of the system on Go Live. Power users trained end users in a classroom environment. Originally employees of the business, they were recruited for their knowledge of business processes and the system. They became full-time members of the BMIS project team before training commenced in order to develop an understanding of BMIS and the knowledge required to deliver training. In preparation for the Mirabel roll-out, 29 power users delivered 102 training sessions to approximately 1,400 users. © HEC Montréal 12 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Power users brought themselves up to speed for their courses by talking to business analysts, looking over process models and experimenting with SAP. Several power users felt they had to seek information about new processes and transactions themselves in order to feel competent enough to deliver training. The availability of these resources was often limited. In some cases, there was not enough process documentation or system functionality available to effectively prepare themselves to deliver training. One power user commented that she did not feel competent enough to deliver training until the day before giving her first course. Bombardier Aerospace hired a third-party to prepare training material. Power users and employees who received training expressed dissatisfaction with the training material produced by the consultants. It relied on tables and descriptions instead of relying on screen shots of the system. The training material did not reflect an understanding of the business and it was not userfriendly. Users found the descriptions and exercises too detailed and difficult to follow. Several power users and super users made significant efforts to adapt the training material in order to bring it to a satisfactory standard. Trainers often provided the first real contact between the users and the project. Users were generally satisfied with the trainers. However, they expressed reservations about the timing, material and focus of the training. There were a few cases of training sessions being cancelled due to users not understanding why they were attending. Some Procurement employees were given inadequate notice by their managers that they would be attending training. Presentations explaining the purpose of the system and its anticipated effects had been delivered prior to training, but many of the users who attended these meetings left more confused and bewildered than when they arrived. As the Change Management Lead explained: “People were sent to training at a few days notice, and it was not explained by their management that there was going to be a change in the organization. So you’re from Procurement, you’re being sent to the training, but you do not understand why.” Users felt that the e-learning module gave a good overview of high-level processes, but that there was no tool supporting a detailed view of the processes (linking the high-level view and related transactions). There was too much focus on exceptions and details. For many users, training provided too much information in a short period of time. They mentioned that some of the exercises were too complicated and detailed. The training documentation was not specifically targeted to the work users had to do on a regular basis (or on their first day of work on the new system). Training focused primarily on transactions, not on the roles. In some cases, roles were still being defined as training was being delivered. A small amount of background information on the concepts of ERP and MRP was communicated to users through e-learning tools prior to training sessions and was reviewed briefly by some power users during the training sessions. The process flows were not explicit and trainers were unable to explain changes to business processes to the users. Several trainers commented that the focus of the transactional training was too broad. Rather than focusing on the most common transactions, the training material attempted to include all of the transactions a user would be required to complete. There were no tools supporting the detailed view of processes (linking the high-level view and the transaction). This meant that users were not fully aware of the impact of their tasks on those of other people. © HEC Montréal 13 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Some users felt that their new roles and responsibilities might be less prestigious than they were previously. Some users resisted the new system because they were experts in the old system and would become regular users in the new one. Other users thought that the new system would make their tasks easier (or faster to complete). This was not necessarily the case. Tasks were different, sometimes more analytical, but not necessarily easier. Data preparation and conversion had not been completed when training began. Data used in the training environment were not always correct and complete. Actual production data were not always available, so manually created data were used as a substitute. Trainers found it difficult to present a realistic experience of the system without production data. As one user in Procurement stated: “When you have buyers who have been here for 20 years working in one way and you try to make them change into a new culture, and you bombard them with new acronyms and new definitions, it’s very overwhelming.” An atmosphere of scepticism existed amongst many users concerning the system delivery and, during the training sessions, some expressed doubts about what BMIS was intended to achieve and the impact it would have on their everyday lives. Power users often found that it was necessary to include explanations of the wider role and consequences of BMIS in their training schedules. Power users were often criticised by users, and there were cases of training sessions being delayed while users vented their frustrations about the system. A lot of people had a hard time understanding the urgency. People were thinking “Why do we have to do BMIS all of a sudden? Why do we have to implement SAP by the fourth of August? Why the rush all of a sudden?” There was a lot of resistance towards it because we’ve been told for years that SAP is coming. The same thing happened with MACPAC implementation. (Power User, Procurement) Schedule pressures resulted in training being delivered to users in a shorter period of time than was originally planned. The duration of training varied across functions and roles depending on their usage of the new system. Users had to attend training while performing their everyday activities. A Director from Mirabel felt that transmitting such a large amount of information to users in such a short period of time had a ‘brainwashing effect.’ The pressure to meet production deadlines resulted in some managers and supervisors instructing their employees not to attend training sessions. Users were given access to practice environments within SAP called ‘sandboxes’ to practise the transactions they were learning during training. Many users did not have enough time available in their normal working day to devote to practising outside of the training sessions. Go Live A calendar hanging in the cafeteria reminded the project team of the days remaining before the deadline of August 4, 2004. Members of the BMIS project team put in long hours and worked on weekends as the deadline loomed. They continued to work during the shutdown period while the rest of the business was on vacation. Senior project management was adamant that the deadline not be pushed back. As the Project Sponsor explained: “I took the decision to implement at Mirabel knowing that they were not quite ready for that deployment. I was more interested strategically in the lessons learnt, because I was confident that we would not lose production, and we would make more progress by going ahead with the implementation.” © HEC Montréal 14 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation During the shutdown period preceding the Go Live, the BMIS project team executed the cutover plan and prepared help desk facilities. Their efforts were focused on ensuring the ERP environment was ready for the return of users and the continuance of Bombardier Aerospace’s normal production schedule. The dedication and hard work of the BMIS project team leading up to the Go Live date paid off. The system was online for users on the first day back from their shutdown vacation period and production was not disturbed. Users at Mirabel began using the system after returning from a three-week vacation period that was necessary to carry out the cutover to the BMIS. A Go Live support pack was awaiting users when they returned to their desks, and support staffs were present on-site to help resolve queries from users. Power and super users were present at the Mirabel plant to provide on-site support following the Go Live. Power users stayed at the site temporarily to transfer their knowledge to super users in an informal one-on-one fashion. Super users remained on-site permanently to provide ongoing support to their peers while carrying out their everyday roles. They also acted as a liaison between their business unit and members of the BMIS project team if problems they could not solve had to be escalated. The Mirabel Plant Manager noted that challenging problems tend not to be discovered in the weeks immediately after the Go Live. Rather, they become apparent months after an implementation. Users and management at Mirabel were disappointed at how quickly the support staff were withdrawn from the business. As he pointed out: There were too many people at the beginning, and then suddenly you go down to a very small amount of people too rapidly. The problem is you don’t find problems in a new system the week after the implementation. You usually find problems three, four, or five months later. In some departments, questions from users in the first weeks after the Go Live were focused on trying to understand their new roles and responsibilities rather than how to complete transactions. This was especially true for employees in the reorganized Procurement function. Several users agreed that there should always be at least one power user available on-site to resolve queries from users and to act as a link between the business and technical support staff. However, knowledge of support staff was valuable to the project team and, therefore, required for the upcoming roll-outs. It quickly became apparent which support employees were more knowledgeable, and the most competent ones were soon targeted and bombarded with user queries. Some were terrified that they would be unable to resolve users’ problems. The frustration of users increased when support staff could not solve their problems, and frustration at being unable to complete transactions would often lead to users placing the blame on the system. According to a super user in Procurement: We had twelve people on-site ready for support and everyone was terrified, because they knew if they were asked a question on contracts and they were a supplier expert they wouldn’t be able to answer the question. They [the users] realized very quickly within a couple of weeks who they could rely on. The problem was that everyone was chasing the people who were reliable. © HEC Montréal 15 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Users from various functions complained that they sometimes experienced significant delays in getting answers to their queries. The project team established a help desk and its services were available to all users at Go Live. Users had to leave a recorded message describing their problem and they did not always receive an immediate response to their query. Delays were problematic when employees had to perform tasks in the system very regularly or when other employees were waiting on them to complete a task. Legacy systems were still accessible to users after the Go Live. Several users said that they were still using legacy systems for some aspects of their work. Users took advantage of the availability of legacy systems if they could not complete a task in SAP. It was possible to bypass SAP, enter information into legacy systems and, thereby, solve a problem. Some managers gave permission, and even encouraged users to utilize legacy systems as a workaround to problems that could potentially cause production delays. Problems were encountered during the roll-out, as in any new technology implementation. For instance, SAP had a functionality to automatically fax purchase orders to suppliers. This created problems as the MRP engine, which generates production requirements, was updated once a day. This meant that the new system created purchase orders and suppliers received new orders every time the MRP engine was updated. Suppliers pleaded with sourcing agents to stop sending so many faxes. The problem was remedied by holding purchase orders in a pool and sending them in bulk once a week, unless the order was urgent, in which case a sourcing agent could send a purchase order separately. On the other hand, at one stage, purchase orders were not sent to certain vendors for one month. The functionality required to automatically fax purchase orders to suppliers was trapping purchase orders in the system. Management told the BMIS team that they were the ones who had to deal with the problem. BMIS team members spent three weeks printing, stapling and mailing purchase orders to suppliers. Procurement was not the only department that experienced problems at Go Live. A full general ledger had not been implemented in SAP. Finance was still using legacy systems to maintain Bombardier Aerospace’s general ledger, and it had not achieved its goal of completing the month-end accounts in one day. Employees in Finance were making manual corrections to the general ledger if materials were issued incorrectly. Employees from the Finance function were used to correcting accounting anomalies in the legacy environment. Their management had to impress upon them that SAP is an integrated system and that they had to let mistakes show to encourage the rest of the business to enter all the required information in the correct manner. Prior to the BMIS, data concerning materials had been managed by Methods. After the implementation, the material master was managed by the separate and centralized Master Data group. Methods had to complete and send forms to the Master Data group if they needed to make additions or modifications to a bill of materials. Methods employees were initially frustrated by this process. Delays in entering the information in the Bill of Materials were common, and it took some time before Methods employees understood what information the newly formed Master Data group required from them. © HEC Montréal 16 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Managers were not using the reporting functionality available in the system. Information was being requested in the same way it had been before the system was implemented. Several managers were still asking their employees to print information or prepare summaries for them that they could have retrieved from the system. This limited use of the system by managers became very apparent to one BPM who used the new system to see which managers had logged on. He discovered that none of the directors or managers in their functions had accessed SAP during the previous 90 days. Stabilization A dedicated BMIS project team delivered the Bombardier Manufacturing Information System by the August 4 deadline and below budget. The project’s number one critical success factor of not disrupting production schedules was met. There was a strong sense of pride throughout the project, as Bombardier Aerospace delivered one more plane than was scheduled during the Mirabel implementation. There was a general consensus across the company that meeting these constraints meant that the initial roll-out could be deemed a success. Less than one year after the Go Live, the Mirabel implementation of BMIS had already contributed to a reduction in inventories of $1.2 billion across Bombardier Aerospace. The company had successfully implemented a complex ERP system without jeopardizing the system’s operation or production. This was a significant achievement in an industry that has experienced several ERP implementation failures. Initial training was supplemented with additional courses and training material. One-day refresher courses were provided for several users. The change management team developed ‘Day in the Life’ training documents following the Go Live. These documents provide a walk-through of a typical day for a particular role and focus on the most commonly executed transactions. They were well received by users, who often found it difficult to retain all of the information transmitted to them during the initial training sessions. Increasing numbers of users were starting to see how the system made their lives easier. This, in turn, was improving their attitude toward the system. Several Senior Project Managers stressed the importance of the business taking ownership of the system as early as possible. Many members of the BMIS project team felt that the business was reluctant to assume ownership of the system, and to promote the monitoring of benefits within the business. After the deployment of the system at Mirabel, the Plant Manager stated that he wanted to understand the system before trying to track key performance indicators. The Business Process Manager for Methods believed that the project had to communicate with the business in a way that encouraged it to own the deployment and delivery date. A team had been established within the BMIS team to develop an appropriate set of indicators for measuring the impact of the system on business performance. This initiative was supported by the Plant Manager, who acknowledged that the business needed to become much more disciplined in the measurement of performance. He believed that information systems, to some extent, had encouraged complacency in measurement because of the large volume of data that they made available to businesses. While he thought the system had the potential to overwhelm © HEC Montréal 17 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation users with data, he agreed that it should be used to provide the data for measurement. He strongly believed that the business had to agree on a limited set of indicators that would be applied across the business. Many users felt that the new system had not affected their own work as much as employees in other areas of the business. The majority of users felt that the Procurement function experienced the most extensive changes. Several users said that there had been little transformation of processes and they were simply using a new system to carry out the same business processes. As one user in Methods stated: “For Methods, there is not that much of a difference. The impact of the implementation was not in our department. It’s pretty much all the same. It’s just the software that has changed.” The new system had not streamlined all processes. One sourcing agent said she had become more restricted because of a new and exhaustive approval process. Sourcing agents could not approve a purchase order for any part if its contract did not contain a price or if the current price was different from that stated in the contract. She described the approval process as a nightmare, with all parts requiring five levels of authorization, right up to the vice-president level. A purchase order could not be generated and sent by the new system until it had been approved at every level. To get around this problem, the sourcing agent would generate a print screen showing the purchase order and fax it to the supplier. Prior to the introduction of the BMIS, the same sourcing agent had the authority to approve any purchase order up to a value of $65,000. Some system functionalities were de-scoped in order to deliver the system for the August 4 deadline. Users were disappointed when they realized that some of the functionalities that had been promised were not delivered at the first Go Live. A lot of the finance functionalities were de-scoped and a portal for interacting electronically with vendors was not implemented. Functionalities that had been promised to Procurement after the Go Live were postponed twice. Completion of new procurement functionalities was scheduled for January 2004, but was delayed until March and then again to June. Several users who considered themselves to be specialists in their own processes complained that they were not involved in design, implementation or validation activities. This was especially frustrating for users when the system was deployed and they had to face problems they believed could have been avoided had they been consulted during the design phase. As one user in Procurement explained: The concern of the buyers was that the people who were giving us PowerPoint presentations, with the nice version of what will happen, never consulted the actual soldiers. We would look at these nice concepts and think “How will that apply to my reality?” Nobody came to ask me what my reality was. When considering the overall picture, business processes in Procurement had become more efficient and integrated as a result of the implementation. In the legacy environment, planners used charts detailing the manufacturing schedule to determine parts requirements. Once planning was complete, the planner would enter all the necessary information to create a purchase requisition. A purchase requisition would be assigned to a particular buyer after it had been created. Buyers would print out all outstanding purchase requisitions in their queue and sort them by supplier and then by manufacturing facility. A buyer would enter additional information and © HEC Montréal 18 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation assign it to a supplier to transform the requisition into a purchase order. Once completed, purchase orders were printed and faxed to suppliers. Purchase requisitions were now automatically generated by the system’s MRP engine when the lead time for a part was met. All the information surrounding different materials, including lead times, was maintained in the material master. SAP converted all outstanding purchase requisitions into purchase orders once a day and electronically faxed them to suppliers once a week, unless they were manually activated in the meantime. There was a lot of buffer in the old system, and it was easy for planners to create purchase orders. To avoid problems, planners could order more stock than was required. It was very difficult to do this in the new system because a request had to be submitted to create a purchase requisition that was not generated by MRP. A purchase requisition would be created this way in the case of urgent or unplanned production requirements. SAP ‘flags’ a user if required information is missing and guides users to enter the required information. For example, users would be flagged if they attempted to order a part that is not used at a particular plant. Therefore, the opportunity for human error was reduced. Looking ahead The Vice-President, Operations and Project Sponsor shared his assessment of the project’s success in the following terms: Has BMIS been a success? I have to say an absolute outstanding success in terms of the financial performance of the Company. It’s been one of the key things in getting [Bombardier] Aerospace through in a very, very tricky period of the business. Is it perfect? No, far from perfect. The Project Sponsor was confident that Bombardier Aerospace could successfully roll out BMIS to other facilities if the major lessons from the pilot implementation were applied to the next rollouts in a disciplined manner. Two Years Later… The BMIS project continued after the Mirabel implementation. In December 2005, two additional programs were included in the scope of the project: the Challenger 300 and Global Express Cockpit. This deployment took place at Bombardier Aerospace’s Saint-Laurent plant. This plant does not assemble a specific model of aircraft; rather, it is responsible for assembling different components (like cockpits) for a variety of aircraft. Preparing the users Significant lessons had been learned during the first phase of the project. The importance of user preparation was well recognized. Moreover, the managers of the Saint-Laurent plant were convinced that, in order for the project to succeed, it had to be their project, not the IT department’s project. They organized this phase of the project accordingly. © HEC Montréal 19 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Sponsorship The project champion for this second roll-out was the Vice-President at Saint-Laurent. He firmly believed in the necessity of the BMIS for Bombardier’s future growth. He advocated strongly for the system and was the one who brought senior management at Saint-Laurent on board. The change leader was also a strong advocate of the system. He pushed the deployment and change within the plant. In addition, the CEO of Bombardier Aerospace was leading the change from the top level of management. The Vice-President at Saint-Laurent made sure the message was conveyed across the organization by holding senior management meetings, attending and playing an active role in project kick-off and progress meetings, conducting the opening and closing of user education sessions, participating in the management training ‘How to Accept Change,’ etc. The presence of the Vice-President during these activities sent a very strong signal to the employees. The VicePresident explained that the project was essential to ensure the growth of the company, as the legacy systems were unable to support Bombardier’s development. At the same time, he insisted that his directors and managers take the lead in the project in order to be clearly responsible for what was happening in the plant. This behaviour induced similar behaviour among the directors and managers. They set aside time for training for their employees and made participation a priority. They helped review mapped processes and they took the lead in the implementation, knowing that their participation would have an influence on the final product Saint-Laurent would receive. Senior management at SaintLaurent made the project a clear priority and communicated this to their employees. Even power and super users fulfilled change leadership roles among their peers. The vision was communicated through different media to ensure that the message was understood by everyone. Change leadership A need for change was perceived among most employees throughout the Saint-Laurent plant. The information relayed highlighted Bombardier’s position with respect to the ERP strategy in comparison to competitors. A video by the CEO of Bombardier Aerospace sent a clear message from top management on the rationale for the change. The overall vision for the BMIS project was now clearly delineated and was well understood across all levels and functions. Most directors at Saint-Laurent took visible actions to increase the understanding of the vision within their functions, such as requesting vision presentations on the BMIS project. These vision presentations preceded the actual training and enabled the users to develop a good understanding of the changes introduced by the new processes. The vision was supported by well-designed tools. Since 2003, several tools had been developed to present an overview of the project, the processes, the roles and how all these elements were tied together. This meant that all these tools (BMIS Roadmap, BMIS Essentials, ‘The 5 Mega Processes,’ etc.) were provided by the project team to ensure a smooth deployment within the business. The education tool ‘BMIS Essentials’ was especially appreciated by the users. © HEC Montréal 20 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation User preparation and training Education and training messages were tailored to the specific needs of the different hierarchical levels. Managers and directors attended training sessions, notably the ‘BMIS Essentials’ and the ‘How to Accept Change’ sessions. Users received more extensive (and more detailed) training. By 2005, the trainers had gained experience and their credibility with the users was good. When surveyed, the majority of users mentioned they appreciated the quantity and quality of the training. Users also thought that the timing of the training was appropriate. Employees were given the time required to attend training and management made it clear that attendance was a priority. Changes in the various roles and responsibilities were implemented before the deployment of the new system. Users felt that having these changes in place before the introduction of the system facilitated the change, because they had time to adapt to the new roles before having to adapt to the new system. This way, they were better able to cope with the changes. A variety of channels such as meetings, presentations, posters, and newsletters were used to communicate messages, depending on the situation and the targeted audience. In general, users were positive about the expected outcome of the project. They thought that the project would benefit Bombardier Aerospace and improve their own work environment at the same time. Project management By 2005, the project team members were able to use the valuable skills and expertise they had acquired to ensure the project was developed according to high standards. The project team used the SAP methodology and employed certified SAP developers. The project was still organized by functions and not by processes. However, the project team had gotten used to the structure and roles were clear. Any issue raised could be dealt with and technical problems were assigned clear contact points in the help desk or the SAP Competency Centre. Nevertheless, the project structure was not always understood by the business side and was often perceived as overly complicated. Project team The project team members formed a dedicated group. Most of them had participated in the first roll-out at Mirabel. There was a positive atmosphere among the project staff. People mentioned they liked to work on the project and enjoyed working with their colleagues. The staff were highly motivated to make the project successful. This was seen as a personal challenge that all employees wanted to tackle. The dedication of the project team was manifest. On-time delivery was the highest maxim. The project deliverables were planned with an aggressive – and perhaps even, according to some members, unrealistic – schedule. Consequently, overtime was an intrinsic part of the schedule and plan. Team spirit was encouraged by the project management group. The project management people stayed with their staff during the overtime work periods. This sent out positive signals. © HEC Montréal 21 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Employees felt it was a collective effort and that everyone was contributing to attaining the project goals. This pressure on delivery meant that there was very little slack in the utilization of human resources. There were no buffers in place for potential contingency events. This created a situation in which several key individuals had no shadows – i.e., people who could replace them in case of emergencies or who could share some of the workload. This was a challenging issue. The specialized knowledge was concentrated in a few individuals. However, it was not simply a question of hiring more people. The knowledge transfer to new team members was not simple and required the availability of key individuals who were already working intensively on the next deliverable and who felt that the time investment required for knowledge transfer would jeopardize the project schedule. This created a vicious circle. Since they were in limited supply, there was strong pressure for these knowledgeable people to spend all their time on project activities. If they stepped back to transfer their knowledge to colleagues, they felt they were slowing down the project’s progress. However, failure to transfer this knowledge threatened the continuity and sustainability of the project. It was acknowledged that no project should be overly dependent on a few key resources. Relationship between the business and the project Top management clearly communicated the importance of the project for Bombardier and there was a common understanding of the objectives and anticipated benefits throughout the hierarchy on both the project and the business side. The project’s progress was assessed through meetings, project status reports and scorecards. These reports and scorecards were given to the management at Saint-Laurent and circulated in the plant. The business was kept informed of the project’s progress in biweekly meetings. If managers or directors were not able to attend any of these meetings, they sent knowledgeable delegates with the authority to make decisions, thus avoiding any delays in the project. These delegates would then report back to the managers and directors on the meeting results. Therefore, management was always informed. This procedure signalled interest from the business and indicated that the project was regarded as important. In some instances, the business side felt that the communication with the project team could have been a bit more transparent. There were a few times, early in the project, when scorecards were ‘embellished’ a little bit to veil some issues with which the project side was struggling. This was done to prevent the business side from worrying about the project. As could be expected, the information could not be hidden for long. Go Live The project went live on the planned date and there were no significant disruptions to normal operations. The Challenger 300 and Global Express Cockpit deployment represented another key step of the BMIS implementation. This particular phase of the larger project could be rightly considered a success, both in terms of results and the deployment process. © HEC Montréal 22 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation The Go Live went very well. The business had a contingency plan to keep production running in case of problems. However, there were no real problems during the Go Live. Moreover, a very high rate of data accuracy was achieved (97%). The stabilization phase was shorter than expected. There was a slightly different perception between the project team and the business about the support during the weeks after Go Live. The project team felt that its support was not needed for a longer period of time, because there were not many problems. However, the business perceived the situation differently. There were some problems, but the support provided by the project team was not completely adequate. In some cases, the business felt that a gap had emerged between the business knowledge of the support staff on the project team (people had been transferred to the project team years earlier) and what was really going on in the business today. In other cases, the business perceived the procedures for receiving support to be unnecessarily complicated. In a few cases, there were complaints about the passiveness of support staff, seen in their failure to proactively approach the users and offer help. It was difficult to draw the line between ‘being available without being intrusive’ and ‘being passive.’ In the end, the project team was released from support duties by the business. Power and super users were able to deal with the majority of user questions and provided most of the user support. It is important to note that some power and super users had been involved in SAP deployments since Mirabel and had acquired valuable knowledge and expertise about the system and its capabilities. If users had a question that could not be answered by their power or super users, business analysts from the project team could be contacted. Finally, co-workers supported each other in case of problems as well. Power and super users noticed that over time the users’ questions had become less general and more specific. Reactions from the employees were almost all positive. Employees used various systems. The BMIS was used in virtually all cases where the tasks were in scope. There were almost no workaround solutions. Most users felt the new system made their job easier. Users would have liked to have a larger portion of their job supported by SAP. There were some complaints from the business regarding the deployment strategy. The first was very specifically related to contract management. There was some resistance towards the system in Supply Chain / Sourcing because SAP did not provide all the detailed contract options that they wanted to negotiate with suppliers. Contract agents were rewarded for the cheapest contract, not for contract compliance with SAP’s options. Therefore, contracts were negotiated with some specific terms that were not included in the options provided in SAP. Consequently, these contracts had to be entered manually and in different ways in Logistics, causing more work and costs later. There was a contradiction between local savings (cheapest contract) and global savings (having the whole process automated). It was unclear which solution was best. More standardized contracts would have increased the costs of some contracts (although not tremendously). On the other hand, allowing more options in the contract module increased development costs and entering contracts manually increased processing costs. The other complaint was of a totally different type and, in a way, it showed that the project team was a victim of its own success. The users complained that the scope of the project was too small. They would have liked all their activities to be supported by SAP. They wanted all the programs © HEC Montréal 23 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation to be supported by the BMIS. Most users wanted all their tasks in the new system as soon as possible so that they would not have to deal with two or more systems. In conclusion, after the Go Live, the majority of users considered the new system was important for them and that it would make their job easier. They had the impression that their input was taken into account in the various activities they participated in, such as data cleansing, meetings, and validating and reviewing training material or processes. Among the users, there was very low resistance and the new system was used in virtually all instances where the task was in scope. Post-Implementation Considerations When taking stock of the latest implementation, the Bombardier Technology Services group noted several elements that needed to be discussed. These elements were not seen as pivotal, but were questions raised in the course of the project. They were elements that would either facilitate further implementations or increase the value obtained from the system. In order to maximize value, the system had to be used and users had to take ownership of the new technology. Users were still in the process of exploring the full capabilities of SAP. Some managers mentioned that many of their supervisors using the new system were very enthusiastic about its possibilities in terms of information. Some were literally ‘little geniuses’ who could understand the system faster than anyone and pull out innovative solutions. They increased department performance. How could these individuals be identified and how could this appropriation process be facilitated? Users did not have many ways to measure their contribution to the realization of the objectives. Some key performance indicators (KPI) had been developed, but they were not used often. In some instances, the business users were not aware of the KPIs that already existed. It seemed that the business was waiting for the appropriate KPIs to be developed and the developers were waiting for input, requests and requirement specifications from the business. Training was another interesting component to assess. When reflecting on the last deployment, some users mentioned that they would have preferred to receive less training before the Go Live and more advanced training shortly after the Go Live to learn about some of the advanced SAP functions once they were familiar with the tool. While this request was perfectly feasible, its net impact had to be measured. Other elements concerned the management of post-implementation issues. Many users made requests for change (RFC) after the implementation of the system. Users mentioned they felt they were not being sufficiently informed about the progress of their request or about the feasibility of RFCs. For the project team, this issue was part of a larger dilemma. Each new implementation generated several requests for change. Some of them were important and needed to be addressed. Others stemmed from a desire on the part of users to re-create in the new systems the processes they had in the old system. This was not desirable. Therefore, sorting out the RFCs that had to be implemented from the complete list was difficult. © HEC Montréal 24 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation The project personnel had to be managed with caution. While benefits were highly desirable and depended, in part, on the pace of deployment, this pace had to be steady but sustainable for the project staff. Peaks are an intrinsic part of major projects and could not be avoided. However, there was a balance to maintain between the short-term and long-term objectives. The short-term objectives concerned the next delivery (at any point in time), while the project as a whole was the long-term objective. Activities had to be conducted in parallel, skills had to be available for each phase and it was often difficult to retain resources for long-term objectives when short-term deliveries were approaching. A last issue requiring analysis concerns user expectations. As was mentioned earlier, the project had been very well received and users wanted faster implementation, with a wider scope. This posed a challenge. There was an inherent compromise between the allocation of efforts to continue the deployment of the system across sites and the maintenance efforts dedicated to sites that were already using the system. A middle ground also had to be found between the scope of the project and the deadlines. In several instances, elements could be removed from the scope of the project to enable an earlier delivery. Was it better to deliver a smaller portion of the scope very quickly? Or should the team have targeted larger deliveries even if this generated longer delays? The project was conducted with virtuosity. The vision was translated into practical elements and communicated efficiently across the business. Training, delivery and support were performed flawlessly. Similarly, the business side put forward the required efforts in the project. The team has the required tools and skills to pursue the project. From the results obtained, the BMIS team should now move from a state of skills/expertise development to consolidation. 2012-01-25 © HEC Montréal 25 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. 26 © HEC Montréal Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Appendix 1 Bombardier Aerospace’s History Timeline This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation Appendix 2 Bombardier Aerospace’s Manufacturing Facilities MANUFACTURING FACILITIES Canada Saint-Laurent, Quebec Saint-Laurent, Quebec Dorval, Quebec Dorval, Quebec Mirabel, Quebec Downsview, Ontario North Bay, Ontario Component manufacturing for various aircraft models including the Bombardier 415, Challenger 604, Challenger 800 and Global Express Production of structural components for other aircraft manufacturers such as Boeing and Airbus Component assembly for the Bombardier 415 Final assembly for the Challenger 604 and CRJ200 Interior completion of the Global Express Final assembly of the CRJ700 and CRJ900 Manufacture and final assembly of the Q-Series turboprop family of aircraft Manufacture of components and final assembly of the Global series Production of structural components for the Learjet 45 Final assembly, pre-flight and delivery centre for the Bombardier 415 United States Witchita, Kansas Tuscon, Arizona Northern Ireland Belfast Manufacture of the Learjet series Manufacture of the Challenger 300 Flight test centre for various Bombardier aircraft Interior completion, maintenance and refurbishment of Bombardier business aircraft Production of components, engine parts and spare parts for Bombardier aircraft Production of components for other aircraft manufacturers including Boeing, Rolls-Royce Deutschland, General Electric, and Pratt and Whitney SERVICE FACILITIES Canada Mirabel, Québec Technical support, including support for the CF-18 military aircraft Painting and interior completion of the CRJ series United States Southport, Manitoba Bridgeport, West Virginia © HEC Montréal Management of basic pilot training for the Canadian Forces Maintenance, modification, painting and refurbishing service center for civil and military aircraft Contractor Logistics Support for the C-23 aircraft fleet with the USAF and USARNG 27 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation References AIRBUS WEB SITE (2007). http://www.airbus.com BOEING (2005). The Boeing Company 2005 Annual Report. BOMBARDIER INCORPORATED (nda). About us. Retrieved June 18, 2007, from: http://www.bombardier.com BOMBARDIER INCORPORATED (nda). History. Retrieved April 28, 2004, from: http://www.bombardier.com BOMBARDIER (2006). Annual Report, year ended January 31, 2006. BOMBARDIER (2007). Annual Report, year ended January 31, 2007. CANADIAN BROADCASTING CORPORATION (1990). Bombardier buys Learjet Corp. CANADIAN BROADCASTING CORPORATION (2004). Bombardier: The snowmobile legacy Retrieved April 27, 2004, from: http://archives.cbc.ca/IDD-1-73-362/politics_economy/bombardier/ CANADIAN BUSINESS RESOURCE (2004). Bombardier. Retrieved April 27, 2004, from: http://www.cbr.ca/CompanyProfile.aspx?CompanyID=2559 EMBRAER WEB SITE (2007). http://www.embraer.com. FEDERAL AVIATION ADMINISTRATION (2004). FAA Aerospace Forecasts – Fiscal Years 2004-2015. FEDERAL AVIATION ADMINISTRATION (2005). FAA Aerospace Forecasts – Fiscal years 2006-2017. GENERAL DYNAMICS (2005). Annual Report, 2005. GOAD, G. Pierre (1989). “Bombardier to buy Short Brothers PLC from British government for $50 million,” The Wall Street Journal, June 9, p. 1. GOAD, G. Pierre (1990). “Bombardier Inc. agrees to buy assets, operation of Learjet for $75 million,” The Wall Street Journal. KOSELKA, Rita (1992). “Let’s make a deal,” Forbes, 149, April 27, p. 62-63. SIMONETTA, Joe (2004). Embraer-Empresa Brasileira de Aeronáutica S.A. Hoover’s Online. Retrieved May 12, 2004, from: http://www.hoovers.com/embraer/--ID__95436--/free-co-factsheet.xhtml SIMONETTA, Joe (2004). The Boeing Commercial Airplanes. Hoover’s Online. Retrieved May 12, 2004, from: http://www.hoovers.com/boeing-commercial-airplanes/--ID__107287--/free-cofactsheet.xhtml © HEC Montréal 28 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation SIMONETTA, Joe (2004). Airbus S.A.S. Hoover’s Online. Retrieved May 12, 2004, from: http://www.hoovers.com/airbus/--ID__40566--/free-co-factsheet.xhtml SIMONETTA, Joe (2004). Bombardier Inc. Hoover’s Online. Retrieved May 12, 2004, from: http://www.hoovers.com/bombardier/--ID__42381--/free-co-factsheet.xhtml SIMONETTA, Joe (2004). Gulfstream Aerospace Corporation. Hoover’s Online. Retrieved May 12, 2004, from: http://www.hoovers.com/gulfstream-aerospace/--ID__40194--/free-co-factsheet.xhtml THE DE HAVILLAND DEAL (1993). The Wednesday Report, 7, June 23. © HEC Montréal 29 This document is authorized for use only by AUSTIN BRENTS (msmarisa@hotmail.com). Copying or posting is an infringement of copyright. Please contact customerservice@harvardbusiness.org or 800-988-0886 for additional copies.