To achieve the proper level of control over an ERP implementation program, the business must take a robust program management approach. Ideally, an organization will establish a program management office (PMO) to manage the day-to-day implementation, a steering committee to provide strategic inputs and resourcing, and working groups comprised of key process owners and subject-matter experts who will play an active role in designing and testing the solution (inclusive of process, functionality and data components). Both the steering committee and working groups need to have cross-functional representation — not just to ensure the needs of all functions are represented in the design, but also to help drive the broader organization toward the intended future state via these change champions.

Key program management and governance tasks for the business include:

• Defining the overall program governance structure. The governance structure should encompass the business units, IT, and any vendor personnel involved in the implementation. It’s a good idea to establish an executive steering committee for the program to oversee critical governance functions. The committee will define areas for oversight and monitoring and set up a regular cadence for meetings to track progress, consider change requests to scope or resourcing, communicate updates to stakeholders, oversee working groups and resolve issues.
• Establishing a program management office (PMO), starting with the designation of a competent and experienced program manager/director and supporting project manager(s) to oversee the implementation. A critical step in this is defining the reporting structures and responsibilities expected of everyone, including vendor-supplied project managers. The PMO’s main responsibility is to maintain and continually evaluate the program plan throughout the implementation and oversee risk management and change control. It’s the PMO’s responsibility to estimate and plan for the impact and effort required for such critical tasks as user acceptance testing (UAT) and data validation, for example. The PMO needs to report to the program sponsor/steering committee. This is usually an executive or a function committed to the program’s success who has enough clout and authority within the organization to secure necessary resources and remove roadblocks.
• Identifying resources for different stages of the project. Different stages of the project will require the participation of different groups within the organization. For example, during the data conversion process, data owners from finance and operations will need to be involved closely, and during the UAT phase, a group of champions or early adopters will be needed to test the system. Specific subject-matter experts throughout the organization may need to be involved for specific tasks, such as defining process scenarios, cleansing old data, validating data and contributing to training content. All of these participants should be identified upfront and their time planned for, including who would perform their routine tasks while they are engaged with the implementation.
• Establishing continuous risk monitoring and communication of critical program risks. Another PMO task is establishing a risk score card as well as a methodology for regular/continual assessment of risk factors and risk mitigation efforts. Risk management must also be embedded across all functional areas within the program (e.g., UAT, data validation).
• Defining a “single source of truth” for program status communication. This single source of truth should integrate perspectives from business, IT and vendor teams to provide a true picture to management of project health.

The overarching business vision for how the ERP will enable business functions is called the “solution design,” or business process readiness.

The solution design stage is foundational to the ERP program and guides all subsequent phases. It should be a cross-functional collaboration, with representation of key functions such as Finance, IT, HR, Operations, Sales and Marketing, and possibly others depending on the scope of the implementation. This will ensure that the perspectives and needs of all users of the system are part of the solution and allow for the design of enterprisewide process flows that don’t get stuck in departmental or business-unit silos.

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 can be specifically and properly validated as envisioned, and (3) users will be familiar with the future-state target operating model (end-in-mind solution) and ready to use it effectively upon go-live.

Tasks for the business — often taken on by designated members of the working group, or a separately commissioned process architect/team — during the solution design phase include:

• Aligning the ERP solution design with other initiatives and the strategic goals of the organization. During the solution design stage, the business should look outside of the ERP implementation to see how it fits with other strategic initiatives within the organization and create synergies between them. Many businesses are developing AI strategies, for example, which should be considered during the ERP implementation. In fact, an ERP system is foundational to AI projects because it generates much of the data that will power AI tools the business is developing now or in the future.
• Developing process models. The process models represent the conceptual representation of processes and should identify:
  • Which activities will be automated, and by what modules, systems or AI components
  • Which activities will require human interaction with the system, and which roles will be responsible for them (who will do them)
  • What system hand-offs will be necessary to integrate an end-to-end set of transaction cycles
• Documenting business rules. This is a task for the working groups; they must detail any business rules (e.g., customer price calculation, cost allocation, tax computation) governing the above activities. 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 working groups should also outline any contingencies or exception workflows, and determine which people in the organization will be responsible for taking action when something goes wrong.

During the implementation phase, the solution design will serve as a reference for evaluating the technical designs produced by the system integrator during the early stages of the implementation. Further, the solution design should serve to guide testing plans, and the applicable documentation can be leveraged for training purposes. 

As the design of the system progresses, the PMO should watch for critical gaps and address them immediately with the integrator. The PMO should track open questions from process owners and make sure they are resolved throughout the course of the implementation. This should be done in partnership with the system integrator’s solution architect.

Designing the new system to automate and optimize the organization’s business processes is only part of the challenge. Another essential but often overlooked ingredient is converting master, reference and transactional data into the eventual production environment. In an integrated modern ERP system, there is particular dependence on a clean chart of accounts and accurate supplier, customer and item masters.

The data conversion and data governance aspects of an implementation are often under-resourced and started too late, causing unanticipated system design and data design impacts to remain hidden until shortly before or even after go-live. Moreover, since a business process cannot be effectively tested end-to-end without realistic data, the successful completion of UAT depends on the quality and completeness of the data available in the system. Data conversion design and data cleansing are therefore essential to enabling testing efforts and achieving confidence that the system will function in production as desired. Note that system implementers typically play a very limited role in this workstream beyond running tools to import data into the new ERP system. This leaves the design, mapping, enrichment and cleansing activities, as well as any data governance overall, the responsibility of the business.

The PMO is responsible for managing the overall data conversion process by:

• Achieving consensus among the process owners, the system integrator and the external auditor on the format of the data conversion documentation and results
• Ensuring the completeness of the plan and the scope for the data validation process
• Training, guiding and supporting the process owners/data stewards responsible for performing the validation
• Monitoring resolution of data conversion errors for both the UAT and the production conversion runs
• Performing a review of the validation results prior to handoff to the external auditor

Typical challenges within this workstream include data mapping discrepancies (from one system to another) and data quality issues in legacy systems. Both can significantly delay the implementation program if not started early.

To avoid these complications, business stakeholders such as process owners and data stewards should take control of the following activities:

• In the early phase of the implementation program, clearly define the scope and strategy for data conversion of necessary data elements, and any data rules and validation criteria. The system integrator will define the end state and required criteria for the data the new system needs. However, the business ultimately owns the quality and completeness of the data and therefore should weigh in on how much is converted and how it will be enriched in the process as well as confirm the validity of the conversion activities. It is recommended that data stewards (which could be process owners or a designee who is very familiar with and “owns” key data elements) sign off on the conversion scope, mappings and, ultimately, validation completion.
• Assess the quality of the source data early in the program and assign clear responsibilities to data owners for cleansing and validating this source data. Clean-up priorities can center on duplicates, aged information, obsolete data, and reorganization (such as parent/child relationships for suppliers). If data quality issues are identified for the first time later in the project life cycle, there is no shortcut for corrective action and the implementation program will be delayed.
• Perform data validations/mock conversions multiple times (see “Audit Considerations” below), ideally coordinated alongside the testing events such as conference room pilot, system integration, and user acceptance testing.
• Assess the timeline and resources required to convert and validate data. These will likely involve process and data subject-matter experts from the business who also have day jobs, so plan accordingly. To help relieve that burden on individuals, it is recommended to leverage analytics and AI tools to accelerate finding quality issues, remedying those gaps, and reconciling results.
• To ensure the conversion process does not miss key data, establish an effective fallout (defect) management process to quickly log load errors, assign accountability for corrections, and monitor progress. These procedures become particularly critical during cutover when fallout data must either be reloaded on short notice or added to a backlog to be addressed later in the production environment, post go-live.

One final note on the subject of data — to unlock the full value of a transformation, the business must establish strong data governance that not only supports the data conversion and related testing activities but persists beyond the implementation to maintain integrity for accurate decision-making. A comprehensive data governance program should define a data framework, data roles and responsibilities, a “data dictionary” and data quality metrics, and document policies related to data creation, validation, conversion, securing and archiving.

The purpose of UAT is to test business processes end-to-end after system configuration is complete. A focused UAT phase helps ensure the implemented system design can support the business effectively post go-live.

Effective UAT starts, once again, at the solution design stage. 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 testing of processes but ultimately falls short of the complete validation business process owners require. UAT progression should be measured and reported in business terms (i.e., procure to pay effectiveness).

Without question, UAT is vitally important. Business process owners and working groups play a leading role in UAT planning and execution. To do so, they should follow a number of critical steps throughout the UAT preparation and execution phases, outlined below.

• Create a UAT management team, led by an experienced project manager, to oversee planning and execution. The team should include process owners who will play an active part in monitoring the progress, tracking results and taking action on issues. The team will also define the reporting metrics required to track progress during UAT execution.
• Draft test scenarios based on the solution design that cover all business processes end-to-end and validate their comprehensiveness with process owners. The population of test scenarios should include a subset that validates the strategic objectives of the project (e.g., specified improvements in process or system performance). A specific population of real data points (e.g., purchase orders, customer orders) should accompany each scenario and be tested end-to-end. Ideally, test data points should have been processed in the existing systems previously, which will allow test results to be assessed against real use results. To ensure it is comprehensive, the set of test scenarios and test data should also include process anomalies and exceptions. Do not test the straightforward, “happy path” cases only.
• Prepare the UAT execution materials that testers will use, incorporating specific system instructions from the system integrator. In some cases, UAT may leverage the same scripts that were used in prior testing phases. However, these scripts should be reoriented/reorganized to better align with the UAT testing execution approach (i.e., scenarios, cases and data).
• Plan the UAT execution schedule and facilitate logistics, planning for facilities and travel for out-of-state or international testers. It is critical to collocate testers involved in common processes. Identify the sequence of scenarios and prepare participants for the proper flow of transaction activities and hand-offs from department to department to simulate the future-state process effectively.
• Identify dependencies on other tracks of the implementation and the actions required to ensure efficient coordination. Availability of interfaced and converted data for UAT, and identification of that data (as well as other prepared data), are critical path items for effective UAT.
• Define the UAT entrance and exit criteria and facilitate sign-off by implementation leads and overall program leadership. The criteria should be quantified where possible; however, the team should acknowledge that the criteria serve more as guidance than hard-and-fast rules for go/no-go decisions.
  During execution, the UAT team’s day-to-day management responsibilities include daily planning and re-prioritization, monitoring risks and resolving them with business owners, and communicating the progress of UAT to the PMO. 

It is not uncommon for an ERP implementation to be technically successful, but ultimately sputter or even fail to achieve transformation objectives due to insufficient attention to people considerations. Unlocking the value of the modern ERP implementation is as much about process optimization using leading practices as it is about technical capability. Capturing the hearts and minds of the user groups that will move to new ways of working in the future state is essential to the ultimate aims of the program. To this end, a focus on change enablement priorities by the steering committee and process owners, facilitated by a change workstream lead, will go a long way.

Change management extends well beyond the traditional communications and training aspects that systems integrators may bring. As early as the solution design stage, the PMO must assess the organizational impact of the system and the process changes and create a change plan to ensure that the anticipated benefits are realized. The business should review the system integrator’s plans for supporting the user community and incorporate it into the larger change enablement plan of the business. 

A comprehensive change enablement plan should include the following:

• Analysis of the impact on individual stakeholder groups early in the project life cycle
• Development of strategies to address barriers/resistance and ensure effective adoption
• Identifying representative change champions from each function who will help carry the banner for the future state and assist those struggling with the transitions
• Outline of how the critical process changes will be adopted by the organization
• Development of policies and procedures and definition of the roles and responsibilities of individuals across the organization
• Definition of metrics for measuring adoption and its success
• Development of a communication and training strategy
• Periodic assessment of stakeholders’ concerns and commitment to changes
• A plan for a functional post-go-live support to see what is working (effective adoption), and for identifying remaining optimization opportunities
• A plan to monitor user adoption and process efficiency once the new system goes live

Ultimately, the goal is to develop 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.

Security and compliance workstreams should be part of any ERP implementation, particularly for public companies or those with external reporting responsibilities. Key business stakeholders within the organization, such as the chief financial officer, the chief information officer/chief information security officer and the chief audit executive, can provide support for the security and compliance workstreams by sending clear signals to the project management office that getting security and controls right the first time is a priority. This is especially crucial in an age when fraud and security breaches are often front-page news. The last thing a company wants is to be in the news for is having to report material weaknesses resulting from system vulnerabilities after go-live.

The steering committee and the PMO should obtain executive support for and appropriately resource the security and compliance workstreams, and ensure there are key checkpoints throughout the project timeline, starting no later than the design phase. It is critical to develop strong collaboration with any financial compliance and internal audit teams to ensure shared responsibility for the successful completion of the security and controls deliverables.

The following are key security and controls workstreams and deliverables:

• Develop an enterprise security and internal control strategy and obtain buy-in from key stakeholders. The enterprise security strategy should include a role-based security architecture for each in-scope system, which would ensure that only the essential access required for users to perform their core business functions is granted within the system. The internal control strategy should include an IT general controls framework, a business controls framework, data privacy and protection, regulatory compliance, and relevant corporate policies. Additionally, the strategy should include evaluation of governance, risk and compliance (GRC) software solutions to ensure the organization has the capability to maintain compliance and identify risk exposures on an ongoing basis after the system goes live.
• Obtain sign-off by security and controls subject-matter experts on all final business process design documents. Requiring additional sign-off on final design documents from security/control owners will ensure these risk/compliance requirements and objectives have not been neglected. Direct participation of information security, financial compliance and internal audit personnel in the design workshops may help accelerate this process. For example, segregation of duties requirements should be addressed in the security role design, and automated preventive controls should be incorporated where possible in the design to enable compliance efficiencies.
• Document security operating policies and procedures. Develop detailed procedures (e.g., role changes, user access and emergency access management) that govern all post-go-live security administration processes for both production and non-production systems in scope. This will help sustain a compliant environment over the long term.
• Integrate security and internal controls into the integration testing plan. Confirm that agreed-to controls (e.g., three-way match) are configured correctly during integration testing to ensure business processes have the appropriate preventative controls in place. At least by the UAT stage, confirm testers are using security access that resembles final end-user access to ensure the security design being tested grants and restricts access in a real-life scenario. Review testers’ access to determine if any security access risks (e.g., SoD or sensitive access) still need to be mitigated.

Note: There is extreme value of utilizing governance, risk and compliance (GRC) tools that incorporate segregation-of-duty analysis, user access request and emergency access processes early on. Incorporating GRC early in the process can save time as well as ensure proper compliance during the sustain phase.

One of the key benefits of modern ERP systems is the availability of ready, intuitive and customizable analytics allowing businesses to run with unprecedented levels of speed and precision. The emergence of artificial intelligence capabilities embedded into today’s cloud solutions is further transforming how businesses operate. These new capabilities range from user or customer chatbots to automation shortcuts and machine learning and are becoming more advanced with each new quarterly release deployed to customers.

The business should work with the system integrator during the design phase to determine use cases for these capabilities that would contribute the most toward productivity and the business’s goals. Some use cases may be appropriate immediately upon go-live, while others can be staged progressively over time as processes, data, functionality, and user knowledge matures.

The business can achieve advances in the areas of analytics and AI by:

• Understanding and educating stakeholders on the opportunities afforded by the ERP platform and related technologies. This sometimes takes the form of “Art of the Possible” demonstrations by the systems integrator during the design phase.
• Setting up an ongoing process to gather ideas/requirements for potential analytics and intelligence use cases.
• Curating that list to prioritize and designate specific reports and dashboards to enter the development workstream at go-live. Particular attention should be given to essential operational and financial reports, including those the business relies upon for compliance purposes. A similar, ongoing approach of analytics requirement gathering can apply after go-live to serve continuous improvement objectives.
• Reviewing and validating the overall architecture and the tools or technologies in place to serve current business needs and meet new ones. Often, organizations will use a combination of technologies, such as data platforms and data lakes, visualization tools (e.g., MS Fabric), and external AI large language models (e.g., Microsoft Copilot, ChatGPT).