One of the scary topics we get asked about is how to apply changes to a live system. It’s a common requirement and – particularly for larger always-on users – is an area not to mess up. The key, as with so many things, is adequate preparation, and we’ve put together a checklist of items that, in our experience, are sometimes missed or left too late
Considering these properly and in a timely manner reduces the risk of adverse events and improves the chance of delivering successful change.
We’ll be doing sessions on this on more detail in future, so if it’s of interest, let us know and we’ll make sure we let you know when the sessions are scheduled
Project planning
- Make sure you procure and resolve supplier/environment (on-premise/cloud) contracts and terms at any early stage: these can take ages and you do not want to be pressured to agree terms
- Do define acceptance criteria at an early stage: this helps the project team align with what you want to achieve
- Don’t forget to involve those responsible for middleware!
- The Basis team will be crucial and may well be able to add more value to the planning: involve them from the start
- It is vital to consider the impact on your users at the beginning. Can you enthuse them about the changes? Early buy-in and feedback from Superusers is very valuable, especially about timelines
- You can reduce later support and user frustration issues by optimising the timing of training and building in-context help
- It pays to design the BAU operations and processes well ahead of cutover – especially if your have third party managed services for the environment, IT and/or business process operations or support
- Regression testing for changes to a live system is critical: think into the corners and think what the risks are
- Testing on live systems is harder and testing/changes take longer. Make sure those involve in testing are briefed and scheduled in at an early stage
- Take data more seriously that you may have thought! It is the no1 cause of project failures. Your data is one of your most valuable business assets and drives insight, is the basis for predictive analytics, and is the essential asset for AI
- Encourage everyone to contribute their view on the risks they see: you can then assess which are most relevant and will be less likely to miss high chance/impact risks
Cutover planning
- Do start to plan cutover from the start. Who will own cutover, who will you need there (often out of normal hours), who do you need available on standby/in-case? Make sure they have it in the diaries
- The closer your QA/Test environment matches your Production environment, the lower the chance of unexpected issues blowing up
- Beware the cutover impact of full Production data volume: test cutover with sample data can quickly become almost never-ending live cutovers…
- Do look to use CHaRM (Change Request Management) to reduce the risk of errors and improve the chance of success
Do consider all of these items for any SAP related project: achieving project goals safely whilst avoiding any unexpected issues to your live SAP operations is the goal, whether a minor apparently trivial change or a major transition
