S/4HANA In-Place System Conversion Blog Series 02/10 : How to prepare before you start ?

[satinder_singh]

I am S/4HANA evangelist and support customers on their HANA journey. Recently I completed a project for S/4HANA conversion and through this blog series I want to take you through my project life-cycle; How to start, plan and execute; What to keep in mind and watch out for. This is topic #2 of 10 part blog series.

As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you. Before you start your S/4HANA conversion program, there are few organizational things you need to set in motion that will set you up for success.

First and foremost, we need to organize our team right. A conversion project requires 4 core skills ABAP, Basis, Finance and Logistics. In addition you might need part time resources for "other" impacted modules like HCM, International Trade, Condition Contracts, FSCM and Security & Performance Testing. As Conversion is primarily a technical project, its important that your technical team has basic understanding of the modules (it comes handy while remediating the code else it creates too much of dependency on functional resources) and your functional team can debug the code so they are not dependent on ABAP team for basic tasks. In addition, if FIORI implementation is part of the project scope then basic FIORI activation and troubleshooting must also be part of the on-boarding.

If the in-place conversion is being delivered by SI partner, another important question to consider is when to involve the customer's IS / AMS team so they are prepared to take up the support upon go-live. Typically a conversion project will consist of 5-7 SUM DMO conversion cycles which will translate to 10+ months project. So, while the IS/AMS team need not have any prior knowledge before starting conversion project, it is a good practice to share the progress and outcome of each phase of SUM DMO conversion for each system on monthly basis, so they get enough time and cycles to become comfortable with S/4HANA system and troubleshooting and this will also be handy during the post go-live support phase.

That brings us to the next important topic of OCM. While user training will happen around UAT phase, it is important to communicate any changes to the end user facing applications (which will mostly be limited to obsolete/deprecated and new transactions) on regular basis leading to the end user training, so they have an idea what will change post go-live and this will again avoid user training type of issues (which forms a major percentage of post go-live support issues).

After you have put the above in place, keeping the following in mind while setting up the team processes will be important:
#1 S/4HANA conversion requires a different mindset from the team. Like waterfall and agile are very different project approaches, greenfield and conversion are as well. Your team's understanding of the in-place conversion process, deep understanding of the tools provided by SAP, ability to stick to like for like approach and not gravitate towards design discussions at every stage (unless mandatory) will save time and effort for you.

In fact, I would strongly recommend that each core member of the identified project team go through product page and must read 'What's New Viewer ' and 'Simplification List '. Functional Teams to additionally read the 'Feature Scope Documentation' and Technical team to read the 'Conversion Guide', 'Custom Code Migration Guide' and 'UI Technology Guide' (if you are considering FIORI) and Basis team to read the 'SUM DMO Guide'. From the assessment report (as discussed in TOPIC 01) you have access to SAP Business Scenario Recommendation Report, SAP Readiness Check Report and Custom Code Impact ATC Report. The project team should be comfortable reading those reports (must know what impact information to find where !!!).

#2 One of the first roadblocks you will hit in your project will be around add-ons. Based on the impact assessment, you would have understood the impacted business functions and add-ons. So, plan for sufficient time for the add-on related activities and also have the add-on vendor prioritize the tasks based on your project schedule. Waiting for a fix for non-compatible add-on could add significant delay but that should not be a reason for you to choose earlier S/4HANA version. SAP releases a major version of S/4HANA every year and it is important that you are planning your go-live for the most recent major version and FPS (Feature Pack Stack).

#3 Similarly you will come across SAP product issues while converting. So, its important to align with SAP HANA Movement Program to get quick support on SUM DMO and Finance Migration Tool issues. Otherwise, getting priority support from SAP Primary Support for non-production systems is not possible. Also, for some issues SAP Primary Support team will need access to the SAP product development teams. Having access to S/4HANA Value Assurance (Safeguarding your Digital Transformation) or Customer Care program can ease lead times there.

Multiple SAP customers who embarked on the S/4HANA Conversion journey have confirmed that partnering with SAP Value Assurance team for 'Safeguarding the Digital Transformation' was a definite plus. This includes 'Technical Integration Check Extended', ;Business Downtime Optimization', 'Go-Live Service' & 'Volume Test Optimization' among others and gives you access to 'Experts on Demand' too.

#4 After identifying the SPOCs in #2 and #3, it is important to have a few good consultants in your team who can articulate the problem, analysis and current situation in a precise way, so when a processor is assigned to your incident (which itself can take up to 3-4 days) you do not loose further time in interaction because the processor is not able to understand the issue. Also, as a habit, add the steps to replicate the issue and open the system for SAP login proactively. You will be raising multiple OSS incidents especially in the sandbox conversion.

#5 In my experience, before you decide to raise OSS incident (#4 above), it is a good idea to have SAP notes expert in your team. In rare scenario, you will be in a situation where a new issue is identified with the SAP product as a result of your incident. For majority of your incidents the resolution suggested by SAP will be an existing OSS Note. So ability to search the right OSS Note in the first place will save a lot of time. Also remember that different access levels can be assigned to different OSS IDs. So it is important to get one OSS ID for your customer account as well (apart from your SI partner OSS ID). Also note:
1. OSS Notes can have dependencies which are not called out in the main description or note dependencies. So do a thorough search for your issue and evaluate all the OSS Notes.
2. OSS Notes have attachments too and some include critical guides to be used during conversion process. Do not miss them.
3. OSS Notes are regularly updated, so once you have implemented an OSS Note, keep a watch on the same till go-live if a new version is released (maybe because another customer faced additional issues even after implementing the earlier version). I recommend creating a small utility to check the newer note versions (of implemented OSS Notes) on monthly basis.
4. Assuming you will be using SNOTE to implement the OSS Notes, do not de-implement an older version and download a new version unless you have validated that the current version is not being updated by SAP else it will block your ability to even read the note for older version. You will have to wait till SAP completes the OSS Note update and sometimes it could be 2-3 days.
5. If the OSS Incident you have raised in the above step is about OSS Note itself, do not always wait for the OSS Incident to be updated but continue to monitor the OSS Note directly. SAP Note is managed by a different team and OSS Incident is managed by Primary Support hence the updates are not always in sync.
6. OSS Note 2081285 has handy tips on how to search OSS Notes better !!!!

In my case, we started our program with version 1809 and it was a 12+ month program. In those 12 months, more than 31K OSS Notes were released by SAP for 1809 version. It will be prudent for the team to proactively check that list and implement the OSS Notes relevant to the project scope. We implemented 300+ OSS Notes during project duration and raised 200+ OSS Incidents.

Someone once asked what is the difference between successful and failed projects and the answer was "Doing the common tasks with uncommon discipline". While all the above points sound mundane but a good team structure, right on-boarding and right process will go a long way in avoiding schedule slippages later on.

In TOPIC 03 we will discuss "Performing Simplification Item and ATC Pre-Checks".