The key to a successful implementation of S/4HANA Cloud (3/3)
Lean Go-Live: Realize, Deploy and Run
This third post will cover the final phases of the S/4HANA Cloud implementation and some additional useful considerations:
The tasks expected for this phase are:
In this phase, you define the different sprints with the packages you will incrementally configure, develop and test using your detailed Backlog. This methodology is SCRUM based, so it is recommended to execute the sprints following the agile methodology:
- Plan each sprint
- Execute its activities
- Monitor the activities with the daily stand-up meetings
- Prepare the internal and external tests for validation
- Do the sprint review afterwards
From a project management perspective, use the accelerator ‘Backlog including Delta Requirements and Gaps.xlsx’ included in the Explore phase (if you haven’t used it yet). You just need to fill your Backlog activities into the file and you will have all the sprint planning and sprint burndown graphs already set up:
If every process defined fits into SAP’s standard, activating and configuring the different scope items is a fast and painless job. Once you finish, you can easily automate the testing using the “Test your processes tool” (see the first post).
I would divide the Realize phase into three main blocks:
- Iteration of the different tasks within the scope
- Completion of the migration in Q
- User management
At this point you have also to ask for the P system provision. Once you have the system ready, each scope item tested and validated can be transported to production. It is recommended to keep both systems regularly synced. There is only a single Transport order each time, therefore, at each transport everything done in Q will be updated in P. Be careful to not transport developments not meant to be in P yet! The accelerator ‘Q to P Transport Process.pdf’ explains the details.
My advice: Do not move to the next phase if you haven’t finished the whole migration in Q. Be aware that there is no ‘OBR1’- like app to reset transactional data and start again. I recommend using a dummy field in Q to keep track of the different iterations when migrating until all the data is loaded OK. If the data volume is big, I also recommend splitting the data into different excel templates. It is slower but you have more control of what is being loaded.
The last important activity during this phase is preparing the cutover plan. Consider customer’s financial and operational constraints and SAP’s release cycles (please see below ‘Last considerations’ for more info).
My takeaway: SAP provides a template to formally close each phase. It is important to formally sign-off and distribute this document to the involved stakeholders to align positions and get the formal approval to each step of the project. Once this phase is approved, all tasks from previous phases not considered, or changes in the scope should be managed as a change request in Change management.
The tasks expected in this phase are:
In this phase, you must finish all the minor items you could have left and complete all the training. As you have already migrated all the data in Q you should have all the templates ready. You just need to load the data again in P. In case you load the wrong data, you can raise a ticket and ask for a reset, but that is not the normal procedure, so make sure you load the data correctly in P the first time around!
My advice: Before loading into P, triple check (again) that everything is consistent. For example, if you have defined an internal numbering for some master data like Vendors, check that the assigned codes match with the new data created in P. That is, invoices referencing Vendors can have a different Vendor code from the Vendors created in P. Remember, you have only one shot! (or you will need to raise a ticket to SAP to reset the system)
If everything went OK, we are all set! Once we have the formal approval of the customer we can move to the Run phase.
Strictly speaking, once the project is closed, there is no project anymore. The run phase is more like an ‘Ongoing Phase’, where we can plan further trainings or extend the scope by adding new scope items if needed. Hence, once you moved to the run phase, you have done it!
According to the project’s plan, a small team can support for a period of time to consolidate the system and help the key users with some additional training.
Cloud quarterly releases:
The cloud has quarterly releases (versus the On Premise version that has yearly Innovation Cycles). It is very important to take this into account to schedule when to start or go live, as you don’t want to be stuck in the middle of a release! In addition, if a functionality is still not met, you can check if it is going to be available in the next release in the official SAP portals.
You can sign up for any of the two release waves available (two different dates) to be upgraded. The release is first installed in Q and you have two weeks to test the system before P is upgraded too. You won’t be able to transport anything from Q to P within this two-week window. As a best practice, I recommend defining all the processes that will need to be tested in advance using the Test your Processes, so in each new release, all the testing to make sure that everything is still working OK, can be automated.
Check the scheduled downtimes and let the customer know in advance before deciding, so that it doesn’t affect the company’s operations.
The cloud still has some apps that are old-school SAP Gui’s. And yes, those apps don’t have the best UX in the browser. In each release, new apps substitute the old ones. Yet, bear in mind that Fiori apps are not just a face wash, most of them are role- based. That means that we have specific apps for each role instead of one app for all. Do not expect to have the same apps with an updated UX. Some transactions will be split into different apps or integrated into a different one.
Almost 100% of SAP products (SAP Central Finance, SAP ERP, BPC, Hybris, Concur, Employee Central, Business Object Cloud, Ariba, Fieldglass…) have built-in and pre-delivered integration content (or will have it soon in subsequent releases). However, SAP S/4HANA Cloud also offers customer-driven integrations based on SAP-delivered APIs that allow more flexibility to suit specific customer needs. Before starting the project check the integration possibilities that may affect the project’s scope in the Roadmap viewer.
If you have a complex landscape, consider the best architecture option, that is, a point to point connectivity approach or include a middleware like SAP Cloud Platform Integration or SAP Process Orchestration.
Additional Information and useful links:
With the SAP activate Roadmap and SAP Best Practices Explorer you have more than enough to manage a project successfully. All the information is there and it is updated to each release. However, there are some additional links that can be useful to complement your S/4HANA Cloud knowledge:
Finally, if your project has complex data scenarios, with big data loads or different legacy systems, it is recommended defining a migration project within the whole S/4HANA implementation scope, to prepare and cleanse the data before using SAP’s Migration tools. Tools like SAP Advanced Data Migration by BackOffice Associates can make your life much easier and move your data securely and in an organized way. You can find more details in SAP’s Marketplace:
This brings ‘Lean Go-Live – Realize, Deploy and Run’ and the 3 Part series to an end! Thanks again for reading these blogs, which I hope you found informative. I would appreciate your feedback and I am always happy to answer your questions!