Deploy

16. Contingency

Building contingency (or tolerance) into the plan is almost always essential to meet a go-live date without slippage. This time can be used for a third rehearsal, defect remediation or setting up workarounds.

17. Train users

Use the tailored training materials and drop-in sessions to prepare people for the new ERP.

18. Roll out comms

As the programme has committed to the deploy stage, comms need to be sent out to reaffirm that the cutover is happening and to ensure wider groups know what to do.

19. DM and cutover

Kicking off DM and cutover is governed by a fact-based cutover entry call. This call is to get the Heads of each function and technology capability together and confirm a) all readiness criteria have been completed or mitigated and b) you can enter cutover.

Cutover execution: Everything that has been rehearsed now happens for real. This will vary in each cutover. The main steps are:

• • Warm up comms to users
  • Cutover kick-off call
  • Enable cutover team access
  • Tech go-live (enable integrations and processing in the new ERP)
  • Hypercare starts to support the new system
  • Connectivity checks
  • Migrate bulk real data to the new ERP and check it
  • Confirmation comms to users: ‘last entries in the legacy ERP’
  • Source systems frozen
  • Process in-flight transaction data
  • Migrate the delta data to the new ERP and check it
  • Check functionality that can be reversed, if needed
  • Cutover exit call – get a fix-forward or backout decision
  • Point of no return
  • Functional go-live (enable a small set of users for live proving)
  • Live proving (carry out a small set of critical operations)
  • Business go-live (enable all remaining users)
  • Run the system and manage updates

These steps, with dependencies and assigned people, will be fully documented in the detailed cutover plan.

Useful terminology:

‘Tech go-live’ This is where the new production system is connected to other systems that are operational. Often, this is done before the system is to be used so connectivity issues can be resolved.

‘Fix-forward only ’: The new ERP becomes the system authority and single source of truth for data. If issues arise, they must be fixed rather than returning to the previous system.

‘Point of no return’: The latest point at which the backout plan can be comfortably initiated to return to the previous system, without impacting business operations.

‘Functional go-live ’: The production system is now live for a small set of users to prove critical functionality by carrying out a prescribed set of real transactions – the live proving scenarios.

 
‘Business go-live’ This is the exciting part. All remaining users are enabled, and communications are sent to announce the go-live. The new solution is now operational and the source of truth for data.

Deciding which checks are reversible and therefore can be carried out before a fix-forward decision requires thorough review and agreement with both business and technical leads. Bringing checks before the fix-forward can increase confidence and reduce risk to operations during the cutover. However, these should be kept manageable.

Common pitfall: Expecting unresolved readiness criteria to be resolved during the cutover entry call.

It is risky to enter cutover with unresolved readiness criteria. Any exception should be supported by a documented mitigation, named risk owner and explicit acceptance by the authorised decision-makers before the entry call.

Solution: Hold readiness checkpoints in the run-up to the cutover entry call, to drive inspection and resolution of incomplete tasks.

20. Hypercare

In hypercare, the solution is now processing live transactions. However, the programme team continues to assist by participating in daily (or more frequent) calls to capture and resolve issues. Key activities and information in hypercare:

• Hypercare incident report
• Daily / twice daily incident call
• First occurrence monitoring results
• Usage telemetry
• Hypercare exit criteria (results)

Hold a hypercare exit call to make sure the solution works well and the support teams can comfortably look after the new system. Hypercare should span critical activities like month-end and potentially the first platform update.

Common pitfall: Not rehearsing hypercare

The team may struggle to turn around a fix with fresh, unfamiliar ways of working.

Solution: Rehearse assessing and fixing incidents using the hypercare model.

This brings us to the final stage gate: Hypercare exit

The implementation is now complete. The system, people, and processes (the holistic solution) are now live and supported without assistance from the programme team.

What happens next? Following hypercare exit, the focus shifts to benefits realisation, continuous improvement, ongoing release management and solution optimisation. A post-implementation review should capture lessons learned for future programmes.