Navigate the Transition: Strategies for ERP Cutover and Stabilisation

You’ve completed testing, got rid of all those pesky bugs, checked all the requirements are covered, and trained your teams. How exactly do you transition from a test environment to a live one?

?What is cut over?

A cutover plan is a detailed timeline outlining the steps needed to transition an organisation’s current enterprise resource planning (ERP) system to a new one. This plan is put together by the cut over manager and input from the project team.

It typically includes tasks such as data migration, system integration, training, and testing and getting the Production (live) environment ready. The key objective of a cutover plan is to ensure a smooth transition from test environment to Production and eliminated any disruptions to the customers, employees, and stakeholders.?

How do I go about it? - Here are my practical tips on how to go about cut over planning.

As the Cut Over Manager on a recent SAP S4 Hana implementation for a global insurance client my first step is to make sure I understand if there are an open design issues or testing issues remaining.

If there are, I make a plan with the solution architect, business architect and client to close them out in parallel, if needed, to cut over commencing. This is not ideal, but we do not always live in an ideal world so when faced with such issues I always urge pragmatism.

I prefer to start my cut over plan with a nice large Visio diagram that covers all the workstreams in scope of the ERP Programme. Having worked on Finance Transformation and ERP implementations for a number of years I take pride in my exceptional Visio skills!

In no particular order the workstreams that encompassed this Programme were:

• Change management and business readiness (including comms)
• Technical cut over (build cut over and config transportation from test environments to Prod)
• ?Organisational Design (People and role changes)
• Testing, Integrations and Environments?
• Data Transformation (extracting, cleaning and enriching data ready for the new system)
• Data Migration
• IFRS 17 (Conversion from IFRS 4 to IFRS 17 for local stat reporting in Europe)
• US GAAP (Conversion from IFRS to US GAAP for Group Reporting)
• IT (System archiving and licence planning activities)

Having been the workstream lead during the project of the technical build, design of the new Accounting Data Model, the data transformation, data migration and US GAAP Conversion, I already had a good oversight of where 50% of the project was and had weekly updates at the workstream’s leads meetings for the other 50% that I was not leading.

I had sufficient knowledge of the overall programme to map out what I thought should be happening and when. In order to decide the timings I always start with the target go live date and work back.

By discussing the technical cut over with the SAP developers and consultants, I could understand the timings and activities involved in the technical cut over. All the other workstreams had dependencies on the timing of the technical cut over and by understand that could adjust the timings of these activities for the rest of the workstreams.

Then with some nice large print outs of my Visio we could have two working group sessions to finalise the plan. As a Programme team we came together with the client and the SAP consultants to review. I like doing it this way as we can come together and discuss face to face and annotate the printed plan with our feedback and open queries.

Once I was happy with that my Visio was 95% accurate and had most key activities in, it was converted to a MSP plan for the PMO (project manager) to govern at daily cut over check point calls. The other 5% could be finessed as some of the open queries were closed out and the plan crystalised. All tasks in the plan had an owner and we monitored task percentage complete daily to see if any activities were behind plan or dependencies impacted.

What is the typical timeline?

The timeline of a cutover plan will vary depending on the size and complexity of the ERP system as well as the time it takes for the team to develop, test and deploy it. In general, the cutover period should begin at least 3 months before the new system is set to go live. During this time, the project team will analyse the current system, develop a cutover test plan and create migration strategies for any data and applications that need to be transitioned from the old ERP system to the new one.

Throughout the cutover plan, the team should consider and identify any potential issues that could arise. Perform a brainstorming exercise in possible risks that might arise and what the mitigation strategy to reduce that risk. E.g. key person could be off sick?- who will cover them? ?

There are other issues to consider, this may include cloning the system, environment backups, setting up communication protocols and data validation. They should also set up monitoring tools, such as dashboards, to ensure any changes to the system are tracked and addressed efficiently.

Upon completion of the implementation and testing phase, the team should hold a ‘go-live’ meeting to review the plan and establish a communication point for any questions, problems or unexpected outcomes. After the new system is deployed and tested, the team should have a debriefing session to assess the cutover plan and discuss any changes, improvements or lessons learned that could help with an easier and smoother transition in the future.

A cutover plan is essential to the successful implementation of a new ERP system. It outlines the tasks and steps necessary to transition from the old system to the new one and can help ensure that any disruptions are minimized. The cutover plan should be put together well in advance of the go-live date and the project team should remain vigilant throughout to ensure all issues are spotted and addressed in a timely manner.

What are the roles and responsibilities for a successful cut over?

These are generic roles in each cut over. Each programme can have different workstreams in scope. For instance, above I talked about how we were also doing a IFRS to US GAAP conversion for group reporting as part of the go live.

1. Establish team – Gather the right personnel for each role, such as ERP consultants, system analysts, IT personnel, and business managers.
2. Create timeline – Develop a timeline detailing the various steps of the cutover process and identify which tasks will be completed by when.
3. Data migration – Ensure that all data is correctly migrated to the ERP system, that it is complete and accurate, and eliminate any data silos.
4. Train users – Provide training for all users on how to use the new ERP system and ensure that the technology can be readily accessed.
5. Test the system – Perform system testing and confirm that the new software is functioning properly.
6. Monitor – Monitor the data and system performance post-cutover to ensure that any issues are quickly addressed.
7. Communicate – Communicate with internal and/or external stakeholders throughout the cutover process to ensure that everyone is aware of any changes.

What are the key elements of a business focused ERP cut over calendar?

• System Freeze Date: Establish a date by which the business must freeze all changes in the system.
• Data Extraction: Extract all data needed in the cutover process from all relevant sources and save in the appropriate format.
• Cutover Configuration: Configure the new system and set up user access levels.
• ?System Training: Train all users in the ERP system and familiarize them with operational processes and procedures.
• Test Cutover: Perform a series of tests to ensure that the system is working as expected.
• Go-Live Date: Schedule and launch the new system to the production environment.
• ·Post Go-Live Support: Provide post-cutover support and troubleshooting to users as needed. This is normally split into stabilisation support (to help people as they get up to speed with new technology and roles) and hyper-care which is tech support in case of issues using the new software.
• Post-Go-Live Audit: Audit the system to ensure that all data was successfully migrated to the new system.

Why is stabilisation important?

Companies often overlook or don’t fully comprehend the importance of stabilisation after go live and the need for stabilisation resource. It can often take people three times as long to perform their role in the first months of a new system implementation. Doesn’t matter how much training they did, everything will be different, and there will be a learning curve.

Post go live checklist

1. Confirm that all required tasks have been completed.
2. Confirm the ERP system is stable and the performance of the system is acceptable.
3. Provide any additional user training.
4. Ensure the system meets user needs and expectations.
5. Make any necessary system configuration changes.
6. Address any open issues and escalate as needed.
7. Monitor system usage.
8. Proactively address any potential system issues.
9. Establish a feedback loop with users and implement requested changes as appropriate.
10. Document any changes to the system.

If you are thinking about starting on a finance transformation journey, please get in touch for a chat and follow me for more content on transformation discussions.

Copy right???Clair Green