In this lesson, we will cover the specifics of SAP S/4HANA on-premise implementations. It’s the most common example for implementation projects on the existing customer base. And, for a customer already running SAP ERP, the first question will be, new implementation versus system conversion.
The SAP readiness check allows you to identify the most impacted areas and can be useful to estimate the cost of conversion versus the benefits of new implementation.
The SAP readiness check for SAP S/4HANA focuses on high level findings, for example:
Simplification Item Relevance
Custom Code
Recommended SAP Fiori Apps
SAP S/4HANA Sizing
Add-on Compatibility
Business Functions
When you run an SAP on-premise implementation for products like SAP S/4HANA, you have different transitions paths (for more information, refer to Unit 5). Amongst the possible transitions, you will find greenfield (new) implementation and system conversion.
System conversion is one of the examples where development and code review activities take a fundamental role, and the older the history of the SAP system in the organization, the more relevant they became.
Think about this example. A customer started its ERP implementation back in the mid 90s when the SAP ERP solution was still called SAP R/3. It upgraded later to SAP ERP and now is converting the system into an SAP S/4HANA. You have almost 30 years of development history there and take into consideration that the functionality you find nowadays is quite different from 30 years ago. Many processes didn’t exist or didn’t provide enough coverage for the organization needs. SAP solution matured over time. If in this 30 years no major code overhauling took place, then you will find that one of the most critical tasks for your system conversion project is related to Custom Code. You need to evaluate the impact of custom code, access its quality, phase out obsolete code, and replace nonstandard code with standard functionality when it’s possible.
Historically the importance of reviewing custom code can be characterized has a long and intensive task, starting in Explore phase, where you understand how much you should keep, deprecate, or remove and later in Realize phase, you perform the adjustments. In the diagram, notice the CC: Custom Quality task.
For those familiar with the history of SAP over the last 30 years, it’s easy to find examples where major changes took place. Some examples could be real estate or treasury, even human resources is quite different from what was available in the earlier editions of SAP R/3.
As-Is analysis: Gain full transparency on your custom code situation in the productive SAP ECC.
Decommission unused custom code: Decommission custom code which is not in use. This activity may start long time before a system conversion, during conversion, and should continue afterwards.
Back-to-Standard where possible: Try to replace custom code with SAP or partner code. This holds true for modifications, clones and so on, and for custom code areas which are impacted by simplifications.
Adjust custom code for SAP S/4HANA (re-design/re-platform): Many existing custom code objects will run on SAP S/4HANA without any need for adjustment. However, some code objects must be adjusted. (for example, by using 'Quick Fixes'), and some should be adjusted according to the extensibility concept for SAP S/4HANA (in-app, side-by-side).
Make yourself familiar with the extension concept of SAP S/4HANA. Please see the document 'Custom Extensions in SAP S/4HANA Implementations - A Practical Guide for Senior IT Leadership' in the accelerator section.
Make yourself familiar also with the topic of custom code migration. SAP recommends the following information sources:
You should start with the SAP Blogs 'SAP S/4HANA System Conversion – Custom code adaptation process' and 'Semi-automatic custom code adaptation after SAP S/4HANA system conversion', and the 'FAQ document on custom code adaptation'.
Another good starting point into the topic is given in the SAP White Paper 'Custom Extensions in SAP S/4HANA Implementations'. This white paper is about the essential concepts for a modern enterprise application’s extensibility, guides through the key aspects of dealing with custom code during a system conversion, and offers practical advice for customers who run a new implementation of SAP S/4HANA or launch new SAP technologies.
Another good overview document (with many links included) is 'Custom Code Management during an SAP S/4HANA Conversion'.
Another workstream with a much larger presence in on-premise systems, is operations and support. Moving to a new solution, even if you are just converting from an older SAP ERP system, brings new challenges and the need for new skills. In this example, your SAP ERP was running with SAP ASE database and your developers were working with ABAP WebDynpro technologies. Now you move to SAP S/4HANA and you have a new technologies to support and troubleshoot SAP HANA and SAP Fiori. You have code being moved to the database and you have OData Services side by side with Web Services. One critical task is related to accessing the impact on operations.
During the operations impact evaluation activity, the SAP S/4HANA project scope is analyzed to evaluate potential operational risks and areas in the support framework that need to be looked at and modified or implemented prior to the go-live. The aim is to define the list of operational activities which:
Need to be newly set up. For example, in case SAP Fiori Apps are newly introduced, the administration and operation of the front-end server needs to be defined and set up and resources need to be trained on the systems involved and their configuration. In addition, support processes like incident management need to be able to handle the new component.
Are existing but must be modified. For example, daily backup routines need to be adjusted to properly fit the new SAP S/4HANA solution. Support tools like monitoring, troubleshooting, or software logistics tools need to be in place. Processes like master data management need to be revisited to define new policies required by the major changes in the master data structure.
Can be retired. For example, DB routines and scripts for AnyDB can be retired. AnyDB monitoring set up should be retired as well.
All the relevant support areas need to be analyzed in a comprehensive manner that is analyzing all the roles and skills required for the support of the SAP S/4HANA solution, the processes and procedures, the operations documentation, and the enabling support tools.
SAP can support you in all these activities with a systematic approach to operational activities, which will ensure you analyze all the changes in IT operational activities caused by the new solution.
Once the affected support areas are analyzed in a systematic way, a roadmap is defined that includes the key activities for IT to fill the gaps and prepare the future IT support framework. The key activities required are many, and include:
Defining the sourcing strategy for a new role. Project resource moving to operations, ramp up of a current resource to support the new solution, hiring, or handover of activity to partner.
Setting up and configuring tools and where SAP will be engaged to support.
Documenting operating procedures by project resources or by operational resources.
Organizing for knowledge transfer to ensure the future operational resources have the required knowledge and skills. This includes formal education of current operational resources, training, hands on and shadowing on new solutions. It also includes training of all the IT support resources involved in the support of the new solution like the service desk.
Operations cutover activities (team access, roll over of open defects, and so on).
Retirement of some part of the current support framework.