by Prabhakar Lal, Director, SAP S/4HANA Portfolio Lead, Capgemini

When migrating your existing SAP ERP Central Component (ECC) system to SAP S/4HANA, system conversation is one approach you can take. The other option, new implementation, is not exactly new for customers. They have implemented their ERP in the past using a new implementation approach.

It is a difficult choice to make between system conversion and new implementation and there is no one answer that will fit every customer, however it’s worth noting that the data from SAP and some recent surveys by analyst organizations show that about 50% of customers will choose a system conversion approach over new implementation. This is a sizeable number of customers who will adopt SAP S/4HANA via system conversion. However, benefits of new implementation cannot be ignored.  This article aims to help customers adopt a system conversion approach that will allow them to experience some of the benefits that a new implementation approach can offer such as possibility of re-thinking process, fit-to-standard, clean core to name a few.

Why Customers Want Benefits of a New Implementation Approach

With new implementation, it is possible to go for complete process re-design and data transformation that will help the customer build the ERP for future business requirements. In the process, the customer can also update their development strategy to keep the core clean and perform any extensions on either side-by-side SAP Cloud Platform or any other platform-as-a-service options.

With new implementation, also known as a greenfield implementation, it is possible to re-think business processes through the lens of intelligent technologies such as artificial intelligence, machine learning, and predictive analytics and innovate to differentiate in the market or business operations. New implementation allows customers to move towards enterprise architecture strategy of fit-to-standard.

New implementation does come with many benefits for customers, but it isn’t possible for every customer to adopt this migration approach. For many customers who have undergone a business transformation program recently or those who are still rolling out their global template to countries or business units, starting a new implementation and going on a similar journey once again doesn’t seem to be a feasible option. High cost, longer project duration, increased engagement of users, and significant change management is also a deterrent for new implementation.

Why Many Customers Adopt a System Conversion Approach

The primary drivers for adopting a system conversion approach when migrating to SAP S/4HANA include the following:

• Feasibility of system conversion in one step
• Lack of appetite for another business transformation program
• A very recent implementation of ERP or still ongoing roll-out
• No immediate business need for process revamp and current processes aligned with business strategy

With system conversion, the customer can retain existing data, processes, and custom developments. However, customers should analyze the need for the same in the context of ever-changing business and technology landscape.

System conversion migration approach is the new experience for customers. It is not like an upgrade of SAP software, where customers have an option to not implement new functionalities. It is also not like database migration, where you only need to take care of impacts due to target database requirements and need not worry about adopting new functionalities immediately.

Recommended System Conversion Methodology

System conversion is migrating your existing SAP ERP system to SAP S/4HANA. You can choose to do a big-bang system conversion or phased roll-out using selective data transition. It is also one of the options when you are trying to harmonize processes and data from your multi-ERP landscape to a single instance SAP S/4HANA system.

Perform a Feasibility and Impact Assessment

If you are planning for SAP S/4HANA migration, the first step is to start by performing a feasibility and impact assessment. In this step, you can run SAP tools such as SAP Readiness Check, SAP Business Scenario Recommendations, and SAP Simplification Item Check in order to confirm the feasibility and identify impacts due to installed add-ons, enabled business functions, simplification list, existing custom developments, and minimum required activities to be performed before starting the conversion project. Once you have the green light on the feasibility of system conversion, it is time to start planning a preparation project to help you realize new-implementation benefits through a system conversion approach.

Re-think Your Business Processes

Like-to-like system conversion approach by design allows you to adopt mandatory changes in SAP S/4HANA such as business partner, new asset accounting, etc., but all the innovations with intelligent technologies such as SAP Cash Application and SAP Predictive Maintenance are not available to the customer unless there is a dedicated effort to plan for their adoption as part of the project. Most of these innovations require setting up additional platforms and procure additional licenses to be able to use them in day-to-day business operation.

Based on experiences of delivering many system conversion projects, I recommend leveraging assessment phase to come up with innovations relevant for your business operation and prioritize them. You can do this in one of two ways. First review the outcome of the tool in the SAP Business Scenario Recommendations report and then setup an SAP Model Company or best practices system to discover all the possibilities in the processes available as per standard.

With the SAP Business Scenario Recommendations tool, you can also identify the processes which are deviating from industry benchmarks and need re-thinking/re-designing. The report also highlights relevant SAP Fiori applications you can start using straight away post going-live.

Reviewing SAP Model Company for your industry or line-of-business will help you prepare a list of innovations you want to adopt either as part of the system conversion project or implement them in phased manner after completion of the project. With this approach, you can plan for leveraging these new functionalities or innovations in the context of your requirements together with like-to-like system conversion project.

Review Data

With system conversion it is possible to bring all the data over to SAP S/4HANA. This means you are carrying over all the inconsistencies, redundancies, and data issues to the next system. This isn’t a desirable solution when you are migrating to SAP S/4HANA with the expectations of lean target system. It is important to ask questions regarding data to assess whether you need all data or only master data and open items, or if there is a specific need for selective data transition for a business unit or special requirements, such as chart of accounts harmonization, etc. The answers to all the above will provide you with a direction on how to manage data-related transformation together with a system conversion project. You can choose a shell copy approach if it is a requirement to either have only master data and open items with SAP S/4HANA Data Migration Cockpit or selective data transition with specialized tools.

Irrespective of a selective or big-bang conversion approach, it is important to archive data to reduce footprint and undergo a data cleansing exercise in order to have a smooth migration.

Keep the Core Clean

SAP has positioned SAP S/4HANA as a digital core and makes a recommendation to keep the core clean and perform all the customizations outside the core on SAP Cloud Platform. It is easier to put this in strategy with new implementation, so what do you do with existing custom developments if you have opted for system conversion? It isn’t easy to analyze all the developments and plan to replace all of them with developments in SAP Cloud Platform.

As you did with data, you do not want to take all the custom developments in target SAP S/4HANA system. A good starting point is to identify and discard all unused custom developments. You can do this by reviewing the developments together with Usage and Procedure Logging (UPL) or Work-load monitor (ST03N) data which should be made available for a minimum of one year. *

The next step is put in place a strategy for all future developments including in-app and side-by-side extension. A clear set of guidelines must be developed in the specific context of the customer and shared with enterprise architects for approval and dissemination to all the relevant stakeholders. This can be done at the time of feasibility and impact assessment.

The tough part is to identify existing developments for replacing them with development on identified extension platform. An approach must be developed for carrying out analysis of existing developments. There is no one-size-fits-all approach; what works for one customer may not work for another.

Custom development can be identified into 5 categories:

1. Unused custom developments
2. Clones of standard objects
3. Tightly integrated with business process, such as enhancements, and routines, such as pricing and VOFM routines
4. Loosely integrated with business process such as custom reports, Forms, UI apps.
5. Apps integrated with multiple data sources or systems

Unused custom developments are ideal candidates for decommissioning. The identification of the unused objects can be derived from usage data maintained in the production system. Most of the time about 30 percent of custom developments are not used. Decommissioning such unused objects will reduce the technical debt while moving to SAP S/4HANA.

Clones add up to the maintenance complexity of the SAP Enterprise Central Component (SAP ECC). The clones must be identified and reviewed with the strategy to remove them completely from target SAP S/4HANA system.

Tightly integrated custom developments need to be evaluated for move to standard. Multiple Business Add-in (BADI) implementations on same BADI definition can be analyzed and integrated into one implementation with controlled logic.

Loosely integrated development can be evaluated for a side by side extension approach in SAP Cloud Platform. Integration with core SAP S/4HANA system for data could be done through OData services. Stand-alone reports and forms can be ideal candidates for an extension approach as these developments are not tightly integrated with business process. UI apps such as custom webdynpro apps can now be replaced with SAP Fiori apps.

Applications integrated with ERP and other SAP and/or third-party systems need to be reviewed to assess if they can be replaced with microservices.

I recommend building a roadmap for simplification of the core with system conversion approach. Some of the simplification can be performed parallel to the conversion project and others can be done in a phased manner post go-live of the project.

Innovation

Innovation is a key driver behind adoption of SAP S/4HANA. SAP is developing intelligent apps on SAP S/4HANA Cloud and on-premise releases. It is easier to plan and adopt innovation with new implementation as there is enough time to review the available innovations and plan for developing required apps during the explore phase of the project. System conversion projects typically do not present any such opportunity as focus is more on migrating to SAP S/4HANA with minimum disruption and in least duration.

The impact assessment phase is critical for innovation as well and requires customer to put special attention on the needs surrounding adoption of out-of-the-box innovative apps and plan for developing custom apps.

I recommend to set-up an innovation core team focusing on this topic and come up with an action plan to adopt/develop intelligent apps in parallel with a system conversion project or in a phased manner post go-live. Developing on SAP Cloud Platform or any other open development platform using intelligent technologies and integrating with SAP will be a first for most customers. It is important to start with a pilot even before you start the realization of an SAP S/4HANA conversion project to get familiar with development paradigm and use the infrastructure efficiently.

What Does This Mean for SAPinsiders?

System conversion is not a technical upgrade and includes functional changes. To get the best out of system conversion, SAPinsiders must remember the following:

• Assessment phase plays an important role in the success of system conversion project. It is recommended to widen the horizon of the assessment from impact analysis to evaluation of new innovations in the business processes.
• Preparation projects help achieve efficiency in a system conversion project. We recommend to setup pre-projects to take care of:
  • Clean-up of data inconsistencies
  • Clean up of custom code
  • Clean-up of vendor/customer master data and activation of Customer Vendor Integration (CVI)
  • Identification of custom developments
  • Data archiving
  • New depreciation engine activation/new asset accounting implementation
  • Customizing adaptation to meet prerequisites in FI-AA etc.
  • Pilot innovation use cases
• Process and data harmonization activities are key for multi ERP landscape aiming for consolidation with migration to SAP S/4HANA.
• If usage collection is not activated in the production system, it is recommended to activate them immediately so that data can be leveraged for identifying unused objects.
• Engage with users from the assessment phase itself to understand the expectations, validation of the processes, and to sensitize them about changes management.
• SAP plays an important role in the project often to provide expedited support to product related issues and clarification on impacts or resolutions.
• Be aware of functional equivalents of functionality not available/not strategic anymore and resulting implementation effort and potential licensing in scope (cash management, planning in SAP Business Planning and Consolidation optimized for SAP S/4HANA, SAP Credit Management, etc.).
• Check the architecture that might lead to additional tasks in a project plan due to compatibility of the third-party products and technical requirements of simplification items (a need to install Adobe Document Services for advance compliance reporting, etc.).