As organisations implement new enterprise resource planning (ERP) systems to automate processes, it is becoming increasingly critical not just for IT, but also for the business units themselves, to understand their central role in the overall success of these initiatives. The implementation of an ERP system or any other major IT system should never be viewed as just an IT project because, ultimately, it is a business project with business objectives. Show
ERP systems must be designed from the outset to support the business. Organisations cannot expect system integrators to develop these designs alone. Integrators are technical experts – not business process experts. This is why the business should be responsible for, among other things, defining the vision and operational expectations for the future state of each business process that the new system will impact. If the business fails to fully embrace its role in a system implementation, it can potentially face significant and costly risks. Interminable project delays and budget overruns, business disruption post go-live and insufficient user adoption are just a few common examples. Even when the project is supported by a strong system integrator, it is critical for the business to assume responsibility for key activities before, during and after the implementation. The seven areas below are the responsibility of the business. We discuss each of them in the sections that follow.
This paper outlines the steps that a business can and should take in each of these seven areas. These actions will help to ensure that, once implemented, the new system will achieve the level of process improvement and automation, data quality, reporting and user enablement required to meet the needs and expectations of the business process owners. We anticipate ERP business sponsors will be able to use this document in designing and planning their ERP implementation programmes and, at minimum, leverage it as a checklist for taking the essential steps to make their ERP programme a success. It is an opportunity to learn from others, who themselves have learned these lessons the hard way. Programme Management and GovernanceAt a Glance
Key tasks for programme management and governance include the following:
Most system integration firms will provide project management capabilities to oversee their teams’ activities, but many will stop short of providing the level of management needed to oversee the end-to- end implementation. Common gaps in a system integrator’s management structure include oversight of internal business and IT resources, management of other vendors, and open engagement with company leadership (e.g., on risks and issues). Achieving the proper level of implementation oversight requires a more robust programme management approach. Companies should also institute a comprehensive governance structure for the entire programme. Key programme management and governance tasks for the business include:
The bottom line: A typical ERP implementation is complex and cross-functional. It therefore requires a comprehensive programme plan, clear assignment of responsibilities to competent and accountable work stream leads, and an effective, real-time governance process that facilitates tracking of commitments and identification and resolution of programme risks and issues. Business Process Readiness and Solution DesignAt a Glance
To meet operational expectations for the new system, the business should design process models for the end- to-end future state of each business process that the new system will impact. This overarching business process vision is called the “solution design.” The process models and underlying solution designs from the business will help system integrators focus on system blueprinting rather than designing future processes, which typically is not their core area of expertise. The system integrator is usually a technical expert and not a business process expert. Therefore, the business must be responsible for defining the vision and operational expectations of the new system with regard to each business process. Specifically, the business must ensure that the technical solution the system integrator proposes will satisfy the business process vision and future-state goals. This requires the business to design process models for the end-to-end future state – ideally, prior to the system integrator’s arrival on-site. This is what we call business process readiness. The process models represent the conceptual representation of processes and should identify:
Any business rules (e.g., customer price calculation, cost allocation, tax computation) governing the above activities must be detailed. If the future system will be integrated with other existing systems, the data attribute requirements and event triggers for these integrations should be documented. The business should also outline any contingencies or exception workflows, and determine which people in the organisation will be responsible for taking action when something goes wrong. In short, a design process model provides the solution to carry out future process activities and defines the related organisational structure. This overarching business process vision is the “solution design.” At the outset of the implementation, the process models and underlying solution designs will help the system integrator to focus on system blueprinting rather than trying to design future processes, which is not their core expertise. While the solution design provides the components of the future system architecture, business process readiness presents the process models, including the activities and their organisation along with data flows and controls. During the implementation phase, the solution design should serve as a reference for evaluating the technical designs produced by the system integrator during the early stages of the implementation. In addition:
The solution design should also serve to guide testing plans, and applicable documentation can be leveraged for training purposes. Preparing the solution design up front helps to ensure that (1) the system integrator is building the system according to management’s vision, (2) the system is properly validated and will support the company as envisioned, and (3) users will be familiar with the solution and ready to use it effectively upon go-live. Potential Mid-Implementation ChallengesMany companies expect the system integrator to lead business process readiness and solution design as part of the blueprinting phase during implementation. Often, business process owners begin to raise concerns midway through the implementation life cycle because they don’t see a detailed future business process, or they perceive a disconnect between the solution and required business process activities, or they see gaps in the end-to-end design, or they simply don’t understand the solution yet due to its technical complexity. How does the business mitigate the inherent risks of this situation in which business owners justifiably lack confidence that the system will meet their needs? In these situations, we often recommend that the business take time to create the business process models and related solution design, even though the implementation is at an advanced stage. This is an essential exercise, as it will help to ensure that business process owners have a reliable and understandable reference to review as well as an opportunity to provide feedback on and approve the system integrator’s recommended technical design.The exercise also provides a sound basis for subsequent user acceptance testing. This corrective action may meet significant resistance given the perceived delay in the project. It requires strong sponsorship by executive management, buy-in from the process owners and consensus from the system integrator. Organisational Change EnablementAt a Glance
System integrators typically train only a key subset of users toward the end of a system implementation. Therefore, the business must plan for and address other critical activities, such as developing policies and procedures and defining the roles and responsibilities of individuals across the organisation. Additionally, the business must deliver practical training to the remaining user community, using a comprehensive enablement plan that:
The business must also be prepared to monitor user adoption and process efficiency once the new system goes live. As the solution design is established, the organisational impact of system and process changes must be determined, assessed and planned for to ensure that the anticipated benefits are realised. As a first step, the changes must be inventoried, and the impact to the organisation must be assessed. It is also important to perform an analysis of stakeholders and their needs and to develop change enablement strategies and activities to ensure changes are implemented effectively. Ultimately, the goal is the development of a change enablement plan that will raise awareness with key stakeholders, obtain their buy-in, and ensure their commitment to support the changes and the performance improvement objectives of the initiative. Typically, a system integrator’s vision of organisational change enablement is limited to “system training.” Training alone, however, is not sufficient, as it does not address the required activities that must be performed to support critical changes, including those related to the development of policies and procedures and definition of the roles and responsibilities of individuals across the organisation. Early in the implementation planning stages, the business should review the system integrator’s plans for supporting the user community. This should include activities planned during the implementation (e.g., communications and training) and activities subsequent to go-live, such as go-live support. Support can be provided through documentation (e.g., policies, procedures, job aids) or specialised tools. Even though system integrators usually will train a key subset of users toward the end of an implementation, the business must still plan for and deliver training to the remaining user community. This training must fall within a comprehensive change enablement plan that:
Note: Post go-live, the business is solely responsible for monitoring user adoption and the efficiency of the resulting processes. Any process breakdowns must be remediated only after a thorough root-cause analysis. User Acceptance Testing (UAT)At a Glance
UAT is the final and most important phase of system testing, and it is designed to ensure the new system will support the business. It begins with a comprehensive solution design that serves as the blueprint for testing. A specific population of real data points must be incorporated into test cases and made available for test execution. The business must assume responsibility for UAT and follow a number of critical steps in the UAT preparation and execution phases. The business also must be engaged in testing cycles prior to UAT, even though the system integrator is primarily responsible for those testing phases. The purpose of UAT is to test business processes end-to- end after system configuration is complete. A focused UAT phase that goes beyond prior functional and technical testing phases helps ensure the implemented system design can support the business effectively post go-live. UAT differs substantially from prior phases of system testing, such as the conference room pilot (CRP) or system integration test (SIT) phases, which are more focused on configuration validation and development of specific functional and technical requirements. These earlier testing phases do not typically provide the user base with a complete view of the end-to-end, future-state processes that the new system supports. Effective UAT starts with a comprehensive solution design that serves as a blueprint for testing. The solution design should form the basis for defining the test scenarios, cases and data variations used within the UAT phase. Without a design-centric approach, UAT often devolves into a fragmented repetition of CRP or SIT testing that provides some end-to-end validation, but ultimately falls short of the validation business process owners require. Similarly, UAT progression should be measured and reported in business terms (i.e., orders and phase gates vs. functional points). Without question, UAT is vitally important. The business must assume responsibility for UAT planning and execution. To do so, it should follow a number of critical steps throughout the UAT preparation and execution phases outlined below. UAT Preparation
UAT Execution
Stay Engaged in System Testing Cycles Prior to UATUAT represents the final and most important testing gate for a system implementation. However, the business cannot afford to disengage during previous system testing cycles, even though they are primarily the system integrator’s responsibility. At minimum, the business should:
Data ConversionAt a Glance
Business processes cannot be tested end-to-end without realistic data, and successful UAT hinges on data quality. To avoid potential delays in the UAT cycle, the business should treat data conversion design and data cleansing as a top-priority work stream, not an afterthought. To avoid data-specific issues that can create complications before and after go-live, the business must take operational and audit considerations into account from the outset of the system implementation project. Configuring the new system to automate and optimise the firm’s business processes is only half of the challenge. The other half is converting master, reference and transactional data into the eventual production environment. No two systems are alike, and data from one system will not map over directly or cleanly into a new system. Further, data quality issues in legacy systems can significantly delay the implementation programme. The data conversion aspect of an implementation is often ignored by the business, but its risks are as serious as those related to configuration. In particular, if the data conversion work stream is started too late, unanticipated system design and data design impacts might also be discovered too late. This can lead to a longer data conversion cycle, causing delays in building and validating the various implementation environments. Moreover, since a business process cannot be tested end-to-end without realistic data, the successful completion of UAT depends on the quality of the data available in the system. Data conversion design and data cleansing are therefore essential to enabling UAT efforts and achieving confidence that the system will function in production as desired. System implementers often plan for a very limited role in data conversion beyond running tools to insert data into the new ERP system, and they typically leave the design, mapping, enrichment and cleansing activities to the client. Again, if this critical work stream is treated as an afterthought, it can create data-specific issues that cause delays in the UAT cycle. It can also lead to work overload and time constraints for team members critical to testing activities. To avoid these
Audit ConsiderationsTypically, the company’s external auditor will be concerned about aspects of the system implementation that could potentially result in significant disclosure errors due to data integrity issues. Data conversion and system testing are primary focal points. The auditor will seek to confirm that the business has tested data conversion comprehensively in the production environment as part of go-live. Given the potential severity of the impact of an unsuccessful conversion for the production environment, most organisations attempt to achieve this standard in one (UAT) or more (CRP) cycles prior to go-live. The external auditor will require:
In general, the auditor will select a sample of transactional objects – and potentially, master data objects – to perform detailed analysis of the data conversion validation and reconciliation. Typically, the system integrator is responsible for performing the data conversion. The system integrator must maintain an audit trail of the reconciliation between the source system files, the conversion files resulting from any manipulation of the source files, and the target system files. The business, meanwhile, is responsible for managing the overall data conversion process by:
Data GovernanceAt a Glance
The business must establish strong data governance that extends beyond successful rollout of the new system. It must also support data conversion and testing activities. To ensure master data and transactional data are employed appropriately and consistently throughout the organisation, the business should develop a comprehensive data governance programme that includes:
The business must establish strong data governance prior to go-live to support the data conversion and testing activities outlined above. This entails:
Building a Comprehensive Data Governance ProgrammeData governance does not end with the successful rollout of a new system. Post go-live, the business must ensure that both master data and transactional data are employed appropriately and consistently throughout the organisation. The business can achieve this by establishing accountability for the accuracy, completeness and availability of data through a comprehensive data governance programme. This entails the following steps:
Business Intelligence and ReportingAt a Glance
To ensure key reports are available immediately upon go-live of the system, and that the overall business intelligence environment is flexible in meeting both immediate and long-term needs, the business should:
Establishing a robust reporting and analytics solution is often an afterthought in a system implementation. This results in business users struggling to piece together reports at the last minute, even with the new system in place. Key reports should be available immediately upon go-live. A process should be in place to deliver additional reports post-implementation, and the overall business intelligence environment should be sufficiently flexible to meet long-term needs. The business can achieve these goals by:
Lastly, the business should consider implementing a formal governance programme to sustain the business intelligence environment. This programme should include demand management and prioritisation so that the business can avoid report proliferation and ensure that reports generated align appropriately with business goals. ConclusionThe role that the business plays in an ERP implementation is at least as critical as that played by IT and system integrators. Business leaders should understand that role, the choices to be made in how they prepare to execute it and the implications of choosing to delegate or deprioritise certain aspects of the role. This paper seeks to provide business leaders with a frame of reference in defining their role during an ERP implementation. No two ERP projects are exactly the same, and how an implementation will be organised will depend on a several factors, including past experience, partner methodologies and much more. However, all of the concepts presented here apply in one form or another. ERP systems can bring remarkable efficiencies and return on investment to an organisation, or be a massive failure – and the business, not the integrator or IT, is ultimately responsible for the outcome. |