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:

Realize

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.

Deploy

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.

 Run

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.

Final considerations:

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.

Fiori:

The cloud still has some apps that are old-school Sap Guis. 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.

Integration options:

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:

Business scenario recommendations

S/4HANA Journey Map

SAP Help Portal

S/4HANA Cookbook

SAP Learning Hub

Consider also following @SDenecken and  @janmusil to stay up to date on the latest news regarding S/4HANA Cloud and PM methodologies. Here you can find a couple of useful links:

SAP Activate Enables Adoption of SAP #S4HANA Cloud

SAP Activate – what is the methodology story?

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:

SAP Advanced Data Migration by BackOffice Associates

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!

  http://bit.ly/2y9hrY7 #SAP #SAPCloud #AI

Eventing and Bulk With Cloud Elements

Integrations are all about enabling communication between your disconnected APIs. So, when building a new integration, one of your top priorities should be to create frameworks for data transfer. Specifically, methods for detecting events in your endpoints and for sending and receiving new data rapidly.

Luckily, we like to give your integrations superpowers, so every single one of our elements comes with pre-built, standardized event handling and bulk action frameworks. If you use Cloud Elements, you can take advantage of these frameworks out of the box to get your integrations ready to go faster than ever. https://goo.gl/CTFYEj #DataIntegration #ML

Apache Camel Route Coverage Tooling on the Way

Last weekend, I found some time to hack new tooling for Apache Camel route coverage reports. The intention is to provide APIs and functionality out of the box from Apache Camel that other tooling vendors can leverage in their tooling, e.g. to show route coverage in IDEA or Eclipse tooling, or to generate SonarType reports, etc.

I got as far as building a prototype that is capable of generating a report which you run via the camel-maven-plugin. Having a prototype built in the camel-maven-plugin is a very good idea as it’s neutral and basically just plain Java. It makes it possible for other vendors to look at how it’s implemented in the camel-maven-plugin and be inspired as to how to use this functionality in their tooling. https://goo.gl/syZqEX #DataIntegration #ML