Test Insight Accordion component - Provide id field in the backend

1. Establishing a program management office (PMO), starting with the designation of a competent and experienced program manager 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, 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 or group who owns the project. This is usually a function or an executive committed to the program’s success who has enough clout and authority within the organization to secure necessary resources and remove roadblocks.
2. 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 a 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, communicate updates to stakeholders, oversee working groups and resolve issues.
3. 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 or 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….? 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.
4. Establishing continuous risk monitoring and communication of critical program risks. This process should include establishing a risk score card as well as a methodology for regular/continual assessment of risk factors and risk mitigation efforts. Risk management also must be embedded across all functional areas within the program (e.g., UAT, data validation).
5. 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 business. 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 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 is properly validated and will support the company and all stakeholders as envisioned, and (3) users will be familiar with the solution and ready to use it effectively upon go-live.

Tasks for the business during the solution design phase include:

o Align 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 contains all the data that will power any AI tools the business is developing now or in the future.

· Develop process models. The process models represent the conceptual representation of processes and should identify:

o Which activities will be performed entirely by the system using automation and AI

o Which activities will require human interaction with the system

o Which activities will continue to be purely manual

o Who will execute the activities that are not performed automatically by the system

o In addition, manual workarounds must be thoroughly evaluated to ensure future processes do not end up broken, incompletely automated or otherwise suboptimal.

· Document business rules. 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 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. The solution design should also serve to guide testing plans, and the applicable documentation can be leveraged for training purposes.

As the technical 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.

Security and compliance workstreams should be part of any ERP implementation design and be accompanied by appropriate budgeting, reporting and accountability. Key business stakeholders within the organization, such as the chief financial officer, the chief information 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 “famous” 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 security and compliance checkpoints throughout the project timeline, starting no later than the blueprint phase. It is critical to develop strong collaboration with the 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, relevant corporate policies, and a knowledge transfer plan. 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 the sign-off by security and controls subject-matter experts on all final business process blueprint documents. Requiring sign-off on final blueprint documents from key business and IT process owners will ensure the business requirements and objectives have been included. Participation of information security, financial compliance and internal audit personnel in the blueprint workshops will ensure the solution design is influenced by a control mindset. For example, segregation of duties should be addressed in the security role design, and automated preventive controls should be incorporated in the design to enable compliance efficiencies.

· Document security operating policies and procedures. Develop detailed procedures (e.g., role, user access and emergency access management) that govern all security administration processes for both production and non-production systems in scope. This activity can save the security and controls workstream a tremendous amount of time communicating common security processes to a multitude of project and non-project resources and ensure that the user experience is not compromised by lack of clarity.

· 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. Confirm testers are using security access that resembles 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.

· Implement an enterprise GRC solution. A versatile GRC tool can automate user access requests, analyze access risk (including SoD and sensitive access) and manage the IT firefighter process to allow for maximized control over users who have been granted temporary elevated access within the system. Additionally, it can provide powerful reporting insights to a broad range of internal and external audit and compliance stakeholders, monitor configurable controls and provide evidence for many more detective controls.>

Note: There is extreme value of utilizing GRC tools that incorporate user access request and firefighter processes early on, since during testing and post-go-live there will be a large volume of such requests. Incorporating GRC early in the process can save time as well as ensure proper compliance during the sustain phase.

As early as the solution design stage, the business must assess the organizational impact of the system and the process changes, and create a plan to ensure that the anticipated benefits are realized. As a first step, the changes must be inventoried and their impact evaluated, which will inform the need for additional resourcing during transition and training, for example. It is also important to perform an analysis of stakeholders and their needs and to develop change enablement strategies that are suitable and will lead to a successful adoption..

A comprehensive change enablement plan should include the following:

· Analysis of the impact on stakeholders early in the project life cycle

· Development of strategies to address barriers and ensure effective adoption

· 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

· Plan for a post-go-live support, not necessarily in the traditional sense but to see what is working (effective adoption), and identify remaining optimization opportunities.

· 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.

Early in the implementation planning stages, 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. Note that after 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.

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 earlier 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, 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 repetition of CRP or SIT testing that provides some end-to-end validation but ultimately falls short of the validation business process owners require. 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 play leading role in 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 and Execution

1. Create a UAT management team, led by an experienced project manager, to oversee planning and execution. The team should include members whose roles are focused on metrics and defects.

2. Draft test scenarios, based on the solution design, that cover all business processes end-to-end. Be sure to 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, the data points that have been processed in the existing systems should be used as data points to support the test cases. This approach makes it possible to use the data in the existing systems as a baseline to assess test 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.

3. 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).

4. Plan the UAT execution schedule, identifying individual testers and the sequence of scenarios, to ensure efficient use of the testers’ time. UAT planning should accommodate potential inefficiencies relative to prior phases of testing because it requires cross-functional participation in near-real time to simulate the future-state process effectively.

5. Identify dependencies on other tracks of the implementation (see further information below on data conversion and system testing) 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.

6. 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.

7. Facilitate logistical preparations, including facilities and travel for out-of-state or international testers. It is critical to collocate testers involved in common processes.

8. Define the reporting metrics required to track progress during UAT execution.

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/steering committee

Stay Engaged in System Testing Cycles Prior to UAT

UAT 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:

1. Verify that the overall test plan is comprehensive and covers all business requirements (i.e., tying the testing schedule to a requirements traceability matrix).

2. Achieve consensus among the process owners, the system integrator and the external auditor on documentation standards for testing.

3. Sample the testing documentation pre-emptively for each process, checking for:

o Quality (Does the test scenario cover the business requirement comprehensively?)

o Consistency of the recorded results with the supporting evidence (evidence must be retained)

o Sign-off on test results by the appropriate stakeholders

4. Monitor progress by reviewing the tracker of open testing issues on a periodic basis.

5. Ensure regression testing is performed consistently to assess the impact of fixes for failed tests on test cases already passed.

Configuring the new system to automate and optimize 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. Typical challenges at this stage are 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.

The business must establish strong data governance that not only supports the data conversion and testing activities but persists beyond the implementation. 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 of data.

The data conversion and data governance aspects of an implementation are often ignored by the business, but the risks are as serious as those related to configuration. In particular, if the data work stream is started too late, unanticipated system design and data design impacts might also be discovered too late, which can lead to 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. 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.

To avoid complications, the business should take control of the following activities:

1. In the early phase of the implementation program, clearly define the scope and strategy for data conversion, and any data rules and validation criteria. Secure sign-off from business owners of the data, as well as from the system integrator and the IT department.

2. 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. 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.

3. Perform data validation multiple times (see Audit Considerations below)

4. Assess the timeline and resources required to convert and validate data. Utilize or build tools, including AI tools, to automate these procedures.

5. While it is generally preferred to check data populations completely, large data sets might require checksums or selective sampling. Assess these decisions diligently on a case-by-case basis.

6. To ensure the conversion process does not miss key data, establish an effective fallout (defect) management process. This process should include fallout handling procedures. These procedures become 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.

Audit Considerations

Typically, 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 organizations attempt to achieve this standard in one or more testing cycles prior to go-live. The external auditor will require:

· Formal sign-offs from management on the data conversion strategy and plan

· Data conversion designs and attribute-mapping documents in sufficient detail

· Validation procedures for each conversion object

· Validation of the conversion results for completeness and accuracy in both the pre-production (UAT) and production environments

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. The business and 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:

· 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 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

· Developing documentation that shows that the company followed a sound and comprehensive data conversion process

One of the key benefits of modern ERP systems is the ability to use data, AI and machine learning for predictive analytics, infinite report customization and proactive risk management through leading indicators. Business owners should be able to access real-time insights and combine new sets of data to create reports and dashboards spontaneously to meet the reality of today’s fast-changing economic environment. These capabilities should be considered upfront at the blueprint stage and embedded in the ERP solution design. Broad stakeholder participation, including by AI enablement teams throughout the enterprise, is key to getting this right.

The business can achieve these goals by:

· Understanding and educating stakeholders on the opportunities

· Setting up a process to gather and document requirements for future-state intelligence and reporting and including them in the solution design.

· Creating a complete inventory of key reports, verified by stakeholders, and planning for them to be ready and available at go-live.

· Reviewing and validating the overall architecture and the tools or technologies in place for reporting to ensure they will meet future business needs

· Reviewing and validating the process for developing additional reports immediately after go-live (months 1 to 3)

Key reports should be identified and planned to be available immediately upon go-live. This will ensure that key business functions will continue uninterrupted and reduce compliance

and reporting risk. A process should be in place to deliver the additional capabilities soon after. The whole business intelligence environment should be sufficiently flexible to meet long-term needs, not just those of today.

Lastly, the business should consider implementing a formal governance program to sustain the business intelligence environment. This program should include demand management and prioritization so that the business can avoid report proliferation and ensure that reports generated align appropriately with business goals.