An Experts Guide to ERP Success

By Eric Kimberling, Managing Partner Panorama Consulting Solutions

Introduction
ERP implementations are tough. Despite the best intentions and the amazing potential of modern ERP systems, most deployments take longer than expected, cost more than expected, and fail to deliver at least half of the business benefits that are expected. In fact, consider the following data from Panorama Consultings 2012 ERP Report, an independent study of nearly 300 ERP implementations across the globe: 54% of implementations take longer than expected 56% cost more than expected 50% fail to deliver at least half of the expected business benefits

Add to this data the fact that the industry has more than its share of high-profile ERP failures in recent years such as Hersheys, Waste Management, and a host of others and it becomes clear that ERP implementations are no walk in the park. For years, executives, consultants, project team members and academics across the globe have asked one simple question with no good answer: What is the difference between a successful implementation versus a failure? The intent of this book is to provide a deep-dive analysis of the best practices and critical success factors required to make any ERP initiative successful. The analysis and recommendations provided in this book are based on years of the Panorama Consulting teams ERP implementation experience, our firms quantitative research of thousands of ERP implementations across the globe, and my personal experience spanning 15 years of ERP implementation consulting, organizational change management, and providing expert witness testimony to some of the worlds highest profile ERP failures and lawsuits. Whether you are a C-level executive, project manager, team member, student or an aspiring ERP practitioner, the best practices outlined in this book will help you better understand and internalize the factors required for successful ERP initiatives.

Page 1 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

ERP Implementation Overview

Before beginning our overview of implementation best practices, lets first define what exactly we mean by ERP software. Enterprise resource planning (ERP) software integrates the data, business processes and work functions performed by an organizations employees into a single system. In general, ERP systems have several components or modules to provide functionality to various departments within an organization, including accounting, sales, manufacturing and warehouse management. In the early days of enterprise software, ERP systems were used in larger, manufacturing-focused companies to plan how to deploy resources throughout the organization. Today, ERP systems have evolved dramatically and are used by companies of all types and sizes in many different industries. In order for a software system to be considered ERP, it must provide an organization with functionality for two or more systems. While some ERP packages only cover two functions of an organization (e.g., QuickBooks: payroll and accounting), most ERP systems address a wide range of functions, including human resources, payroll, finance, supply chain management, customer relationship management, scheduling, quality and more. By combining these once stand-alone functions into a single unified database, ERP systems provide a useful and cohesive structure for many companies. There are dozens of providers of ERP software, including both global outfits and small, industry-specific vendors. Well-known providers include SAP, Oracle, Microsoft, Infor, CDC, NetSuite and Epicor. The demands of the global market place, increased competition, and the changing economy have all created the need for all organizations to streamline business processes and efficiencies. Today, companies are complex and require powerful and flexible ERP systems to remain viable. The ultimate goal of an ERP implementation is to improve an organizations efficiency and effectiveness; it is less about technology and more about creating better business efficiencies. The software being implemented is simply the tool for the organization to build and improve business processes. ERP systems enable organizations to make informed and timely decisions by providing real time access to integrated information in sourcing, production, marketing, sales and other key areas in the company. The top challenges that companies face during an ERP implementation are lack of employee buy-in, lack of ERP expertise, lack of project resources and lack of appropriate budgeting. Employees are often reluctant to embrace a new system for a variety of reasons, including fear of change, fear of being replaced, and fear about giving up the comforts of the old system. When employees are hesitant, the implementation can become more difficult and less efficient than anticipated. The amount of time and resources required for a successful implementation are frequently underestimated by organizations, which often lack the expertise to fully understand the impact and importance of an ERP implementation. While ERP may seem to be of interest or use only to technical managers, it affects business managers in an equally profound way. ERP is more than just computer software; it's also a way of transforming and optimizing an entire business. Therefore, business owners and managers should be involved in the purchase decision and the implementation. To ensure a successful implementation, the organization needs to have full commitment to the project from senior executives to front-line employees. In addition, companies must define their future business processes to help select the appropriate ERP software. Once the software is implemented and the business processes are in place, the systems need to be monitored and improved on a continual basis. These processes provide the structure for the business to run effectively. If not used properly, technology alone does little to improve an organizations business. Of course, ERP isn't for every company. Though the software has become more accessible to more organizations in recent years, it still carries a hefty price tag. In addition to the base software licensing costs, it often requires hardware upgrades, training for employees, implementation costs, and other direct and indirect
Page 2 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

costs. ERP implementation also can be incredibly risky. The media have covered several instances of companies that had to shut down entire operations briefly because of botched implementations. And when there is a halt in operations, lawsuits often follow. But when the right system is implemented correctly and supported with the proper people systems ERP can transform a companys operational abilities by improving efficiency, providing access to real-time data, and streamlining customer service management. Despite the global economys signs of recovery, capital information technology budgets and technology investments continue to be scrutinized. Although there is never an ideal time to implement ERP because of the hours and resources required to make a project successful, the more forward-thinking strategic companies are finding that current conditions are ripe for an implementation. Despite the economic headwinds, many companies are experiencing significant growth and need new systems to handle their increased demands. Some simply want to have ERP in place when the economy picks up again so they can leverage new technology to enjoy a steeper recovery in revenue and profit. Others recognize that now is a perfect time to negotiate with ERP vendors and reduce the total cost of ownership. If implemented correctly, ERP should increase revenues and decrease costs, which is the perfect reason to implement during times of economic strife. The problem, of course, is that many companies fail to select and implement their ERP system in a way that delivers measurable results. The ones that do are finding that ERP is an extremely powerful tool in this global economy. Next, well summarize some of the best practices surrounding implementation planning, or those activities that should be completed before your implementation begins in earnest.

Implementation Planning
I'm a huge fan of professional football (American football, that is). Perhaps the thing that fascinates me most about the sport is how much each play matters, and how within each play, every little thing matters. If an offensive lineman protecting the quarterback is just one inch too far off his position on just one play, it can be the difference between a touchdown and the quarterback being sacked for a loss. When an offense is moving down the field, one key block that pushes a defender just one inch further downfield can be the difference between keeping the drive alive with a first down or having to punt to the other team. And we've all seen many episodes of Sports Center where the receiver makes a spectacular catch in the end zone, only to have one foot just one inch too far over the line. Sixty minutes may seem like a long time to play a game (especially if you don't like football), but it's often not enough time to overcome a mistake of inches from earlier in the game. ERP implementations are much the same way. The average deployment takes 18 months from start to finish, which seems like plenty of time to make and overcome a mistake or two. But that is not the case. Every little thing counts, from the way you choose your software to the way you design your system to the way you communicate changes to employees. Ive seen projects fail because the project team forgot to define that one little critical requirement during the ERP software selection process, only to find that the software chosen couldn't handle the functionality needs. This creates a domino effect of customization, cost overruns and ultimate project failure. And just like football, ERP implementations are a brutal contact sport. Facilitating business changes, managing organizational resistance, controlling project scope creep, and trying to work with software that doesn't always fit your exact needs can take its toll. By the end of the game, you're just glad to have survived the whole thing in one piece. ERP projects may be like football games in many cases, but they are different in one way: football has a clearly
Page 3 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

defined goal-line and scoring process, while no one has created a universal definition for ERP implementation success. In other words, where is the goal line and when do we declare victory? How do we define go-live? Are we done once the system is up and running? Which business processes do we have to have addressed in the new system before we call it a day? How do we know when the business has fully adopted the software? And how will we know that the business has realized a strong return on investment (ROI) from the expenditure? The problem is that most people, including the ones running the project, probably don't have answers to these and other key questions, which can lead to big issues later on. Following are some key tips, definitions and best practices to get your team started towards the goal line. Roles and Responsibilities During a Typical ERP Initiative When developing an ERP implementation plan, organizations need to first define the key roles and responsibilities of the major players during an implementation. Purchasing Company The purchasing company is responsible for conducting due diligence to select the software vendor, the implementation approach and the internal implementation team. The company also should have policies in place to govern the implementation. The governance of the project generally covers changes to the original scope, customizations, additional resources, and configuration and set-up decisions. The company must decide what mix of people will make up the implementation team from within their organization, the vendor organization and any third-party professional services firm they plan to hire. These roles include a project manager, an executive steering committee (that the project manager reports to), a senior executive sponsor (that is on the executive steering committee), a core team of functional experts dedicated to the project and any necessary subject matter experts (SMEs). While the size and scope of the project determines the extent of people required on the implementation team, the best approach for a large company is to make the implementation project the full-time job of every team member. Software Vendor The software vendor is responsible for delivering the software and working with the company to determine the most relevant implementation approach. While the vendor should assist the company and provide guidelines whenever possible, the decisions are ultimately up to the company. The level of involvement and responsibility of the software vendor during implementation varies from company to company and depends on what is negotiated in the contract. Software Vendors Professional Services Team, Value Added Reseller (VAR) or System Integrator The software vendors professional services team is typically responsible for assisting the company with the implementation. These services also may be provided by a value-added reseller (VAR), system integrator or other third-party consulting firm. The teams make-up is dependent on the clients determinations, and typically includes an executive sponsor for the implementation, a project manager, team leads and functional and technical consultants. Since the purchasing company is paying for these resources, it is the companys ultimate responsibility to manage them just as they would any vendor or contractor.

Page 4 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

Best Practices in ERP Management Statement of Work, Implementation Plan and Scope The scope of the implementation project should be determined before the project begins and should be outlined in the statement of work (SOW). The SOW is accompanied by an implementation plan which outlines the estimated costs and time associated with the scope outlined in the SOW. To complete the work detailed in the SOW, clearly established roles and responsibilities must be in place within the client company and implementation partner. More often than not, these key individuals are in place before the SOW is finalized and have some input in shaping the SOW. The establishment of these key individuals with their corresponding authorities is considered best practice. Acceptance of Deliverables The company should review and accept or deny all deliverables in a timely fashion to keep the project on schedule. It is the companys responsibility to ensure that vendor deliverables meet their quality and timeliness expectations. Examples of vendor deliverables include software configuration and documentation and training documentation and materials. Remediation of Issues No matter how well-managed an ERP implementation is, issues are common. Projects of this magnitude require companies to make key decisions about how they wish to run their businesses. Leading ERP systems are flexible, so it is typically up to the implementing company to determine how the software is going to be used. Unresolved issues should follow the remediation process outlined in the projects governance and controls. The company is ultimately responsible for ensuring that risks and issues are addressed to their satisfaction prior to moving to subsequent phases of implementation. Executive Sponsorship, Involvement and Support Executive involvement is critical to any ERP implementation and especially so in organizations with complex business requirements. An executive steering committee typically meets at least one or two times a month to review both project results to date, as well as issues, risks and resource needs. In addition, the executive steering committee should be involved in making and supporting key strategic and business process decisions as they relate to the project. Although the core implementation team is responsible for making as many design and implementation decisions as possible, some broader decisions will inevitably need to be escalated to the executive team. Large implementations that cross geographies frequently involve political battles in terms of how the business will operate in the post-implementation world. Executives often need to be the ones to resolve such issues, so their involvement is important in this regard as well. During an IT project, they are often called upon to make tough decisions regarding changes to operating models, business processes, organizational structures, and other sensitive topics that will not be adequately resolved without their involvement. ERP projects also require heavy involvement from internal employees. Executives are the ones that can ultimately make these resources available to the project. Without executive support, it can be very difficult to procure the employee resources that are needed to make a project successful. Only by having true buy-in to the project will executives understand the importance of ensuring the right people are available to make the project successful. Executive sponsorship, involvement and support are arguably the most important aspects of an ERP implementation because they enable the best practices outlined in this book. Without executive support, it is extremely unlikely that an implementation team will be able to effectively address the areas critical to
Page 5 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

implementation success. Implementation Initiation ERP projects should include a functional and technical manager that supports the project manager with the core team and SMEs underneath this management structure. These individuals should be actively involved in all ERP-related issues, including establishing and validating processes and training employees across all functional areas. The SMEs should be valued members of the organization.

Implementation
Project Governance and Control The management of any project requires proper project governance and controls. An ERP implementation project is no exception. Effective processes and procedures must be established and clearly communicated at the start of the project. They also must be consistently adhered to throughout the project with an audit trail that catalogs all activity. All elements of the project should be controlled, particularly the following: scope, costs, time, quality and communication. Best Practice: Institute strong project governance prior to the start of any ERP implementation. Scope As mentioned above, the scope of an ERP project is layered with assumptions that support the SOW. Changes to the scope of an ERP project increase the overall cost and the risk of successfully completing the ERP implementation within the defined time frame. This occurs because an increase to the scope results in a material increase in the effort and dollars necessary to complete the work, which puts the original timeline at risk. Likewise, a decrease in the scope results in a material decrease in the work and cost necessary to complete the project, which gives the original timeline a higher likelihood of succeeding. As a result, scope management is critical to the projects overall success. The governance and controls of the project should outline how scope changes are handled. Typically, any changes or customizations that are not in scope warrant a corresponding change order and approval from the companys steering committee and executive sponsors. Unapproved scope creep in a project can pose significant risk. The companys project manager is responsible for keeping the project in scope and adhering to project time lines. Best Practice: Ensure that scope and related decision processes are tightly managed as part of the overall project governance. Costs Because changes to the scope have a material impact on cost, managing costs in an ERP project should be done through change controls. These controls are similar to traditional accounts payable processes and include an approval process for costs at certain levels, manager sign-offs, audit trails and executive oversight. As a general rule, ERP projects that do not have effective change controls have higher implementation costs. Best Practice: Institute change controls at the start of the ERP project.
Page 6 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

Time Traditionally, time is managed through a project plan that outlines a set of tasks within clearly established milestones. The tasks themselves are managed through specified resources and/or personnel within the projects management structure. Best Practice: Use a project plan to manage time (as well as tasks). Quality Quality controls for an implementation project include procedures to validate all configurations and customizations. These controls should be managed through an approval process. The approval of any customizations should be considered critical to their associated value because their development is expensive. Additionally, configurations and customizations are often outside the scope of the original SOW. Likewise the work must be validated through testing procedures with real data prior to go-live. Best Practice: Define project stage gate reviews at key pre-defined milestones throughout the project in order to mitigate risk. Communications The management of communications is critical to the success of an implementation project. Communications between the vendors and the project team must be organized and consistent with clear authority. If the vendor is receiving multiple or conflicting directives, then costs can increase. Best Practice: Establish directives between the vendor and project team at the start of the implementation. Senior management must be actively engaged and resources must be readily available. Internal communications should provide key, branded information about the implementation project to employees through newsletters, intranets, posters and the like. Communication plans should include a messaging strategy that targets specific departments of the organization as well as the organization on a whole. Consistent messaging will help to ensure that employees support the project, understand the companys objectives and are prepared for changes. All messaging regarding the ERP implementation should be planned according to organizational and project objectives and must be consistent through go-live. Best Practice: Ensure your communication materials encourage dialogue between end-users and management. Risk Management Planning Every ERP project has a set of critical tasks that must be completed before a successful implementation can occur. These include functional, technical and project turnover issues. These risks should be identified at the beginning of the project. In theory, if the risks to critical tasks are identified quickly, then the management team should be able to arrange resources and strategic measures for
Page 7 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

these critical tasks so that the project is not jeopardized if problems do occur. This practice is the best way to effectively manage the risks associated with completing an ERP project. Best Practice: Build a risk mitigation strategy that outlines resolution alternatives for tasks along the project timeline. Commitment of User Community There is no disputing that a lack of end-user involvement can pose a serious risk to the implementation of an ERP system. However, the reverse also is true. Too much end-user involvement or unstructured end-user involvement can quickly overwhelm a project. In my experience, end-user communities are not particularly strategic and tend to look at an ERP project through a narrow and highly personal lens. Uncontrolled end-user involvement can result in a derailed timeline due to the endless gathering of conflicting requirements with no cut-off date and/or the addition of costly requirements that are of little or no value to the ERP project or the overall business. Best Practice: Solicit the opinions of strategic members within the end-user community (traditionally managers) that can represent the opinions of a broader functional area during the blueprinting phase. (Blueprinting is the phase of process mapping and decision making for determining when the system will be used.) Complexity of Operations Many organizations that implement ERP do so in order to simplify their complex operations. Companies that have multiple offices or business areas or who have grown through acquisition generally have inconsistent and non-standardized business operations. One of the key values of ERP software is that it helps companies perform their operations in a more consistent way across different concerns. Best Practice: Insist that standardized processes are defined across an entire company early in a design phase and then conduct a phased roll-out of that standard software functionality to geographic offices. Cooperation of the Divisions In a large, multi-office ERP implementation, cooperation and involvement from various divisions and departments is critical to success. Input from these teams is extremely important if a company is attempting to standardize processes and corresponding software functionality across multiple business units, offices and departments. The value of this involvement is twofold: 1) it ensures that a companys entire business processes are considered while defining requirements and designing the system, and 2) it builds employee buy-in and support of the project so that they will not fear or resist the corresponding changes from the new system. Best Practice: Cooperation between divisions is best enabled with a robust organizational change management (OCM) plan, which should be incorporated into the overall implementation plan. Interfaces The value of ERP systems is that they eliminate the need for multiple software systems and keep most or all of a companys operational data on one platform. In rare instances, however, companies decide to leverage one
Page 8 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

or more third-party systems to increase the functionality of the core ERP system. This elevates implementation risk and necessitates both more technical skills and overall system testing. Best Practice: Fully test interfaces with other systems as part of a comprehensive business, functional and integration-testing plan. Effect on Information Technology (IT) Operations ERP implementations have a tremendous effect on the IT department. IT staff needs to be trained on how the software works, how to both maintain and continuously improve the software, and how to provide corresponding help-desk support to employees to enable them to use the new system. In addition, IT operational staff need to understand configuration and customization tools so they can maintain and support the system in the long-term without reliance on outside consultants or technical staff. Best Practice: Ensure a robust organizational change, training and skills migration plan for your internal IT group. ERP System Personalization, Configuration and Customization While some ERP packages are advertised as out of the box (i.e., to be used as delivered with only the configuration and set-up required by every ERP software package), most ERP software requires at least some changes or adjustments in order to perform optimally. ERP software is a highly configurable solution. The potential usage of an ERP system is determined through configurations or changes to the system. There are three different levels of change to ERP systems during the implementation process: 1. Personalization. The first and simplest level of change, personalization includes the options for the look and feel of the system that available. Personalization includes choices like the color, font, background, logos, screen and dashboard layout of the system. 2. Configuration. The second level of change, configuration, refers to the options for process flow, data flow, calculation and data association that the system provides. The configuration choices are available as a part of the systems flexibility and do not require any changes in the program code. 3. Customization. The third level of change is customization or modification. Customization refers to changes required by the client that the systems design does not support and therefore require a change in the program code. Changes of this type represent a significant investment in time and cost. They can make acceptance and testing of later releases of the software another customization project. Most large companies request changes to their ERP software to address particular requirements, business processes and workflows. This can include functions such as check printing, custom purchase orders and invoice creation. In general, the more complicated the company, the more complicated the configuration and the more likely that change will be needed. Further, every company has a unique need for their logo and other information on some documents, which generally requires configuration or enhancements. Production and Test Environment Architecture and Build-Out All configurations and customizations must be fully tested prior to introducing the system to employees. To conduct these tests and go live safely, ERP systems are deployed in multiple environments. Each
Page 9 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

environment is a separate location for the software and data and is used for different purposes. As a form of best practices, three environments are set up during implementation: production environment, test environment and development environment. Although some organizations choose to combine the testing and development environment for cost reasons, the production environment should be separate from untested software or development efforts. This is because the combined environments can create erroneous practices such as conducting acceptance testing simultaneously with development efforts. Consequently, ERP systems are best deployed in the three distinct environments mentioned above. The design and development of a separate production environment architecture creates a secure environment, separate from testing, development, and current production, to control the system modules that are ready for production after the go-live. An established testing environment with defined controls for validating processes and procedures is critical. This practice clearly identifies key issues prior to going live. These issues can be resolved in the development environment and retested until the issue is corrected and ready for a production environment. Best Practice: Include user sign-offs to validate both modified and unmodified elements of software functionality during testing. Software Testing and Conference Room Pilots Testing is a critical component of a successful ERP implementation. There are different types of tests. At the most basic level, an ERP system should include the following: performance testing, functional testing, and integration testing. Performance Testing A key goal of ERP implementations is technical performance, which is usually not known until after the go-live. Performance testing mitigates some of the performance risk associated with going live. Converting software often results in an overhaul of the entire IT platform (including infrastructure). ERP systems have minimum requirements to function properly. These requirements include limits for capacity, bandwidth, load parameters and so forth. The minimum requirements for the functionality must be tested prior to go-live to catch any issues early. In addition to load-related testing activities, performance testing also includes stress testing of system overload to identify points at which the system could potentially crash. Best practice is to conduct performance tests in a testing environment prior to go-live. Functional Testing Process customizations and configurations are natural parts of an ERP implementation. Functional testing validates the accuracy of the processes within the system. These tests can take different forms, such as acceptance testing for a particular process or scenario testing for a particular situation. Best practice includes functional tests for all processes, particularly configured or customized processes. This is a critically important method of early detection to avoid finding the same errors after go-live. Functional testing should be conducted with real (historic) data, even if data conversion is not complete. Validating the accuracy of real data is easier for end-users than validating the accuracy of unfamiliar data. Integration Testing Although an ERP system should be used throughout the organization, specific legacy or third-party solutions are sometimes necessary to address a particular function. If multiple systems are used, integration testing is necessary to ensure connectivity between the systems. This is particularly important if interfaces are developed between two systems. ERP software testing is not limited to performance, functional and integration testing. It is critically important to
Page 10 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

test every aspect of functionality and connectivity prior to going live to identify any issues as early in the process as possible. Defining Business Requirements The definition of business requirements is a fundamental milestone and an absolute necessity to realize any form of success with an ERP implementation. If business requirements are constantly added to an implementation, then the scope of the implementation will grow beyond resource constraints and will become increasingly difficult to complete. Best Practice: Create an end-to-end model with sign-offs from authorized managers to establish buy-in and to verify the accuracy of the requirements. The documentation of the business processes and workflows should be developed with SMEs that are key system users and functional process owners to include their valuable insight into the system functionality needs. The business process and workflow reconciliations migrate as is business requirements to to be business requirements. Best practice for this effort is a gap analysis that outlines the functional gaps between current and future states. Best Practice: Conduct a gap analysis that outlines the functional gaps between current and future states. Once a gap analysis is conducted, planning to address functional gaps can begin. This is primarily managed through conference room piloting and end-user acceptance testing. Given that ERP software is configurable, all business processes and workflows must be defined within the system. These definitions should be finalized prior to any configurations because any change to the definitions has a corresponding impact on the configurations. The development, review and finalization of business process and workflow definitions are fundamental implementation deliverables. This effort lays the foundation for all gap analysis and reconciliation work and ultimately produces a static definition for to be business processes. In the softwares methodology, defining business processes and workflows within a future state occurs during the blueprinting phase. In addition to process mapping, the blueprinting phase includes future interfaces and data mapping. (For clarification, all implementations require process mapping for as is processes, gap analysis, and to be processes to configure the ERP systems.) After blueprinting is completed, the realization phase begins, which involves creating baseline configurations required for to be process functionality, interfaces and conversion development. All configurations and any customizations must be reviewed and tested to validate that the delivered changes address the desired business processes and requirements. Additionally, the methodology uses pre-configured processes to expedite the delivery of the ERP system. As a result, the blueprinting phase simultaneously defines and reconciles functional gaps for business processes and workflows because the to be processes are suggested through pre-configured processes and either used or altered. If pre-configured processes are not used, then the software is either configured or customized to meet the desired needs. The implementation team must understand all functional areas of the business prior to implementing the software. This practice helps to identify areas of uniqueness within the business as well as competitive advantages. The practice also helps to qualify the functionality of a system and can serve as a baseline for detailing a final set of requirements for the implementation of the system. If a company does not define all
Page 11 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

business requirements across all the functional areas of the business prior to implementing an ERP system, then critical components can get overlooked, not installed, or installed poorly during the implementation. This lack of definition can also lead to additional requirements during an implementation, which can be costly and dangerous because development efforts have already begun and will require rework. Data Migration The migration of a companys data history from its original systems to a new ERP system is one of the most fundamental tasks of an implementation. All data being migrated to the new system including live data entered on or during the go-live and legacy data must be cleaned (or standardized) before it is introduced. Migrating clean data has both organizational and implementation ramifications. Within an organization, critical data may be stored differently. For example, a customers address may be recorded as 2900 Franklin Way or 2900 Franklin Way, Ste. 200 or 2900 Franklin Way Unit 200. All three references identify the same customer. Data cleaning involves the standardization of data fields, values, tables and so on across all functional areas throughout the systems for all the history being migrated into the new system. It is important to note that each functional area may have a compelling reason why they classify data in their respective ways. Best Practice: Define clear rules and formats for the data being migrated. Defining these rules may require executive decision-making to settle functional disputes. Completing data cleaning efforts may require external experts to hasten the process. A key part of data cleaning is also getting rid of or junking old or useless data. Simply put, the more data you bring over, the more you need to sort through at conversion and the more likely to impact go-live. What is junk? Well, how about an item that has not been sold in the last five years? The last three years? How about an item that you no longer manufacture? A customer that has gone out of business or not bought anything from you for the last three years? All closed sales and purchase orders? Determining the data that needs to be kept can be quite arbitrary and dependent on the industry and purpose the data provides. Forecasting needs to be considered as well. There are no hard and fast rules, but management needs to come to firm agreement on what does or does not need to be kept as decisions can span several departments. Bear in mind that different industries have different regulatory requirements that may need to be considered. Some regulations restrict the ability to change certain kinds of data records, such as HIPAA with Electronic Medical Records (EMR) or PCI DSS with credit card data and transactions. Some govern the length of time records need to be kept, such as for auditing purposes. However, most of these might be addressed using paper records, thereby lowering the required data needed for migration and cleaning. There is a range of quality tools (typically provided by software vendors) that are designed to quickly migrate data into an ERP system. Companies are responsible for cleaning the data so that it can be converted. As a result, data migration is oftentimes a burdensome task during an implementation. There is a general misconception that the IT team can handle all of the cleaning. While there is data cleaning software, these packages can only help identify potential areas and records to be cleaned. Someone still needs to know, for example, which is the correct out of two different address records for a company. Or someone knowledgeable needs to be able to verify that the closing balance is in fact correct. It is this data integrity and accuracy that a company must seek. In most cases, the owner to clean these records is not the IT department, but the actual functional departments or users. However, both need to work together to ensure success.
Page 12 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

In-System vs. Excel There are pros and cons for both methods of data cleaning and I often use both. In-system cleaning is to correct the data in the legacy system database. This method is good especially if you intend to keep a final snapshot of the legacy system for your records. Downloading data and changing it in Excel is often used when there are fields that are not in the legacy system. The time associated with this process is dependent on the amount of data being converted and the team of individuals migrating the data. Because an organization cannot go live until the history is properly migrated, the process can significantly delay an ERP implementation. Additionally, all converted data must be tested in the new ERP system. Early efforts must define how much data will be migrated and how the data will be migrated (standardized numbers, addresses, etc.). There also should be training or procedures put in place to ensure minimal cleaning is needed moving forward. These efforts should begin as soon as possible, particularly in organizations where structured approvals are necessary. Additionally, the data migration process should include the use of tools that simplify the export of data from the legacy system. A resource assessment also should be done to identify if additional resources (e.g., temporary employees) are needed to support the effort. Best Practice: Implement a clear strategy at the beginning of the project and use a dedicated team and team manager to achieve it. Business Process Reengineering Modern ERP systems are configurable and require defined processes and workflows. As a result, business process reengineering is unavoidable during an ERP implementation. The reengineering process is an iterative process during an implementation that includes the following steps: define requirements/processes, configure solution, run tests, perform gap analysis, and address gaps. Companies must repeat steps three through five until system is ready to go live. Best Practice: Begin business process mapping, improving and re-engineering prior to implementation, defining more detail as the software is designed and configured.

Systems Go-Live
Preparation for the go-live begins well before the actual go-live date. A series of steps needs to take place prior to going live. These steps include validating final processes and verifying the organizations readiness through process manuals, support structures, and the like. The organizations final processes within the system should be validated through associated approved tests at the end-user level. These tests should validate that the system can operate without system errors that could lead to business interruptions. Best Practice: During go-live, combine on-site assistance and documented processes and procedures for end-users. To ensure both go-live and post-go-live success for end-users, there must be a step-by-step manual of the processes and procedures outlining how each employee will perform their jobs in the new system. These manuals serve as useful tools both in training new users and helping all employees retain knowledge after training.
Page 13 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

Cutover is the moment at which the old system ceases to be primary, and the new system is online. The golive cutover is a seminal moment in an implementation that can define success or failure. The project manager should verify all measures and adequate technical support should be available for any problems that may emerge. This should be conducted during non-working hours so that end-users can validate the systems accuracy in a low-volume environment. This precaution is necessary given that the system deals with live data after the cutover. Any bugs, discrepancies and end-user training issues must be identified and resolved immediately. Best Practice: Employ an end-user validation process during the cutover to verify success with signoffs. Go-Live Cutover Lessons Learned A large multi-site implementation plan requires a phased approach with an initial site going live on the new system, followed by rollouts to subsequent sites. Site order should be selected strategically for go-live based on the complexity and magnitude of the implementation. The first go-live offers valuable insight into potential problems for the next sites scheduled to go-live. Lessons learned should be incorporated to mitigate risks and increase the success factors for future implementations. Benefits are never guaranteed. According to research published by my company, Panorama Consulting Solutions, only half of companies surveyed realize 50percent or more of the business benefits expected from their ERP systems. A full 54-percent of ERP projects run over schedule and 56-percent of projects run over budget. A go-live should be a structured process in which errors are detected and resolved, processes are reviewed and sentiments from the end-user community are gathered and evaluated. Best practice is a post go-live audit review or assessment with recommendations.

Organizational Change Management (OCM)

Organizational change management (OCM) focuses on employee transition to the new system, including the implementation of new processes, related training, and communications. OCM is a key success factor for any ERP implementation because the software cannot be used if members of the organization cannot understand and apply it. The actions that successful OCM projects support include process development and change, role and responsibility definition, communication, training and organizational design. Organizational Readiness Assessment and Risk Migration Plans There are varying levels of readiness for an ERP implementation within an organization. A readiness assessment should be conducted to understand which areas would have the most trouble implementing an ERP system. Employee difficulty or resistance can occur when there is tenured staff, poor morale, poor technical and business resources, or limited capabilities. A company should determine where there might be employee resistance and create risk migration plans that include customized training plans, communication plans, and organized resources to address the resistance. Best Practice: Continue support after the go-live by collecting employee feedback and offering further assistance if needed.

Page 14 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

Communication and Training Plans In successful implementations, end-users are adequately trained on the new ERP system. Sufficient training is reflected by the readiness of an organization for a new ERP system. It is rare to see an ERP implementation without a significant level of employee resistance at the start of the project. Employees are typically concerned about being forced to depend on a new system without proper training. Experienced users, who gained power within the organization because of their understanding of the legacy system, are often concerned that they will lose much of their workplace prestige if a new system is implemented. Communication and training plans are essential to forming positive attitudes and a cultural acceptance towards the acquisition of the new skills needed to succeed. Best Practice: Identify and mitigate resistance through organizational assessments that segue into communication and training strategies prior to go-live.

Page 15 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

Conclusion and Summary

The above introduction provides a summary of the ways that organizations can and should leverage best practices to make their ERP implementations more successful and effective. Clearly, there is no one component that will make a project; instead, ERP success requires careful and experienced management of all of the above implementation critical success factors. An oversight or shortfall in any one of the above areas can be the difference between success and failure and there is very little margin for error. These ERP best practices and critical success factors will be covered in more detail in forthcoming chapters of this book: Chapter 1. Strategies for Preparedness Chapter 2. ERP Software and Vendor Selection Chapter 3. Analysis of Specific Systems Chapter 4. Planning for Implementation Chapter 5. Achieving Implementation Chapter 6. Organizational Change Management Chapter 7. Realizing Benefits and ROI Chapter 8. ERP Implementation Challenges . . . and Failures Chapter 9. Looking Forward

Page 16 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.

About the Author

After 15 years of ERP consulting at large firms including PricewaterhouseCoopers and SchlumbergerSema, Eric Kimberling realized the need for an independent consulting firm that really understands both ERP and the business benefits it can enable. He currently serves as the managing partner of Panorama Consulting Solutions, the worlds leading independent ERP consultant. Eric began his career as an ERP organizational change management consultant and eventually broadened his background to include implementation project management and software selection. Erics background includes extensive ERP software selection, ERP organizational change, and ERP implementation project management experience. Throughout his career, Eric has helped dozens of high-profile and global companies with their ERP initiatives, including Kodak, Samsonite, Coors, Duke Energy, and Lucent Technologies to name a few. In addition to extensive ERP experience, Eric has also helped clients with business process re-engineering, merger and acquisition integration, strategic planning, and Six Sigma. Eric holds an MBA from Daniels College of Business at the University of Denver.

Page 17 of 17 3773 Cherry Creek North Drive - Suite 720 - Denver, CO 80209 720-515-1377 Panorama-Consulting.com Copyright 2012 Eric Kimberling. All Rights Reserved.