Deliver

8. Build

The agreed ERP design is configured in various test environments in preparation for testing. Documenting how this is done can be highly valuable when planning the production environment configuration. Also, any automated configuration comparison or deployment tools can save a lot of time and are best used from the start. Synthetic or obfuscated data is loaded in preparation for testing, and in some cases real data may be migrated, provided all security and legal conditions are met.

9. DM optimisation

Moving sufficient and accurate data from ‘source to target’ systems is known as Data Migration (DM). This must cover static and dynamic data, including in-flight transactions. Also consider feeding downstream systems and archiving.

DM optimisation is usually carried out with full volume, real data over several cycles to gradually achieve sufficient speed and data accuracy. The environments and transfer methods used must meet all security and legal conditions. Taking a fresh extract from the source system for each cycle is ideal to prove the process is ready for cutover and to address any up-to-date errors that may appear due to new records.

Key points:

1. Data migration must be optimised to ensure it can be done within cutover time constraints.
2. Data must be validated by Data Owners (often delegated to Functional Leads) at its destination to make sure it’s correct.

Information needed in data migration:

• ETL (Extract, Transform, Load) logic
• Data source list
• Data mapping document
• Data reconciliation reports
• Data cut-offs (last entries to source system)
• Data protection documentation
• Target migration duration – based on cutover window constraints
• Actual migration duration

Common pitfall: Taking a low-cost data migration proposal without delta migrations.

‘No-delta’ approaches often rely on the manual capture and load of data off-system, or even dual keying. This can be a huge undertaking.

Solution: In the strategise task, determine whether the data migration strategy will work for cutover. Consider delta or ‘top-up’ migrations to minimise any data freeze periods.

10. Test

Testing comprises several test phases depending on scope (e.g. payroll testing is only needed if payroll is in scope); these are typically:

1. Unit Testing – checking localised configuration works
2. System Integration Testing (SIT) – ensuring data passes to other components of the architecture correctly.
3. User Acceptance Testing (UAT) – business leads confirm the solution supports agreed processes and acceptance criteria.
4. End-to-end testing (E2E) – demonstrating that the sequential steps of a process work, e.g. onboarding a new employee
5. Payroll Comparison Testing – this is checking that pay will be accurate compared to a pay run from the previous system
6. Parallel Payroll Testing – running the two payroll systems together and checking the output is correct
7. Penetration Testing – security testing the new solution, usually carried out by a separate and specialist third party.
8. Operational Acceptance Testing – confirms the solution can be operated, monitored, supported, secured and recovered in the live environment.

Testing should happen alongside rehearsal and DM activity as there are several interdependencies.

Key enablers for testing are:

• Environment plan, specifications, build plans
• Environment booking table
• Technical skills matrix
• Delivery plan

These are created in the testing workstream:

• Test plans
• Workflow management setup
• Release process
• Non-production access control
• Code/config management process
• Code documentation/config workbooks
• Code/config in the system
• End-to-end test scenarios
• Live proving scenarios – needed for rehearsals
• Defect and workaround tracker – needed for deployment
• Testing sign-off
• Regression test pack
• End of Test Report

Common pitfall: Not carrying out E2E testing, assuming that SIT and UAT are sufficient.

E2E can often reveal errors that only occur when a transaction is processed downstream. Finding this out at go-live will likely block operations.

Solution: Define the essential E2E business processes and operations to test in a suitable environment. A subset of these can also serve as live proving scenarios to be carried out in production at go-live.

Common pitfall: Waiting until the end of testing to set up workarounds

Complex manual workarounds may require a long setup time.

Solution: Watch for critical and major defects in the weeks leading up to the end of testing. Start preparing workarounds well before testing ends.

Common pitfall: Looking at workarounds in isolation.

This will mask where the same team is needed to execute multiple workarounds. They may not have the capacity for all of them.

Solution: Call out the resources needed and examine the combined list of workarounds and the aggregated effort.

11. Business change

This is where the main value of an adopt-not-adapt transformation is realised. The new operating model, roles, training needs and staffing changes are implemented. Key interdependencies exist with BAU teams and the programme to set up new business processes, provide training, and carry out consultation where role and position changes are required.

In addition, business change covers role mapping. This is key to ensuring testing is carried out with the correct permissions applied and that roles can be assigned at go-live, protecting data and enabling processes.

Key information to be produced:

• User list
• Role mapping (which job types get which system role/permissions)
• Training material
• Business process changes
• Ways of working changes
• Business readiness criteria

12. Prepare training

Based on the new operating model created during design and the new ERP taking shape during testing, develop and tailor training materials. Also, set up a training environment that mirrors the test environment and populate it with suitable data for end users to train with.

13. Engagement

End users, customers and suppliers will need to be kept informed about the new ERP go-live. This will build excitement about the changes, build support, and help people prepare. Users will have many questions about how the new ERP will affect their day-to-day activities. Note: In many cases, the business and technical leads who own the relationship will handle communications with customers and suppliers. However, it is sensible to record and track these as part of the communications and engagement activities. Key documents to be produced:

• Communications plan
• Supplier list
• Customer list
• Mailing groups

14. Service transition

Service Transition provides an independent operational-readiness challenge and coordinates the criteria that must be satisfied before the new solution enters live service.

• Service transition criteria
• Service transition plan
• Hypercare support model
• Hypercare entry/exit criteria
• Support model
• Knowledge transfer
• Knowledge articles
• ITSM (IT Service Management) tool setup
• Production change order
• Support team impact analysis
• Support team skills matrix
• Up-skilling and resourcing plan
• Monitoring and alerting setup
• Disaster recovery arrangements
• Update and evergreening model
• Change Approval Board (CAB) setup
• First occurrences to be monitored
• Usage telemetry
• Hypercare exit criteria

15. Cutover preparation

Setting up and carrying out rehearsals prepares for deployment; however, this preparation needs to begin early in delivery, as key interdependencies exist. Also, the team and organisation need to be ready to deploy by the end of delivery so resources can move straight into deployment activities.

A cutover strategy should already be in place. Develop this into a cutover Plan on a Page, including business, technical, and full-scope production data migration activities.

These documents are needed in preparation for rehearsal and cutover:

• Deployment plan
• Readiness criteria
• Readiness report
• Rehearsal scope
• Entry and exit criteria
• Cutover PoaP (Plan on a Page)
• Runbook template
• Runbooks
• Detailed cutover plan (ready for rehearsal)
• Backout plan (to get services back online if the cutover fails)
• Cutover sitrep (situation reports)

Runbooks

The cutover manager will use the cutover PoaP to lead a ‘familiarisation campaign’ to:

• Get people on board
• Recommend a cutover format
• Introduce runbook templates
• Begin population of the runbooks

The hierarchy of cutover planning artefacts is usually like this:

> Plan on a Page – visual, key events

> Cutover plan – mid-level showing core tasks and times

> Detailed cutover plan – all runbooks combined

> Runbooks – individual team tasks

Walkthrough: Runbooks are combined to create the detailed cutover plan. This is then checked in a ‘walkthrough’ where all team members talk through the tasks from start to finish. Remember also to include the backout plan.

Rehearsals: The goal of rehearsals is to demonstrate that the team can successfully execute the cutover as planned, given the time and resources available. They also identify unknown factors that would derail a cutover, e.g., out-of-hours resource power-downs.

Rehearsal 1 (RH1): This is a technology-focused rehearsal to prove:

• The main components of the system can be connected
• Representative data sets migrated (not necessarily full volume)
• Key user group representatives given access

There will be many challenges and lessons to be learnt in R1, so set aside plenty of time. Lessons from R1 should be captured and applied to the next rehearsal.

Rehearsal 2 (RH2): Full dress rehearsal; this should include:

• The full, actual team that will execute the cutover
• Full volume data migration
• Timings as they would be on the actual cutover
• Entry and exit calls should be included to familiarise senior decision-makers with the decisions they will be asked to make, and the information they will be provided

The full rehearsal is conducted to prove the cutover is logistically feasible and to identify any unknown factors that could derail the event. The list is long and unknown until you try it.

Rehearsal 3 (RH3): Contingency rehearsal; it’s prudent to plan an additional contingency rehearsal, known as RH3.

This brings us to the third stage gate: Ready to deploy

The new system has passed testing, people are ready, and the cutover has been successfully rehearsed. The programme can redirect its resources towards making the new system operational.