Successful migration to S/4HANA

左手的ㄟ右手 2022-10-19 00:45 15阅读 0赞

**[Migration from SAP ERP to S/4HANA][Migration from SAP ERP to S_4HANA] is an inevitable project for companies using SAP. Whether our goal is simply to secure manufacturer support beyond 2027 or to sail into the wide waters of business transformation and new technological and functional capabilities, we must start by choosing the optimal project timing and conversion method. Greenfield, Brownfield, or maybe Bluefield? The SNP does projects in every color.**

Many SAP customers breathed a sigh of relief after the system vendor extended the support period for old SAP versions until 2027. However, more and more companies are becoming convinced that sticking with SAP ERP in the face of such dynamic market changes, numerous transformation projects and growing reporting and performance needs may be an inhibiting factor for their businesses. The cloud model of maintaining systems is gaining in popularity, and combining conversion with cloud migration seems like a reasonable option.

The choice of a convenient time to carry out this type of project is, on the one hand, limited by the cut-off date of 2027, but on the other hand, in planning we should take into account the IT budget (project investment, but also the state of the technical infrastructure and possible investments in this area). The migration must also fit well with other IT/SAP project plans, including, for example, rollouts, transformations related to business requirements (including, for example, acquisitions of new entities or spinning off parts of the system).

When embarking on a conversion project, we also need to properly prepare the system to meet the prerequisites (such as Unicode encoding). It’s worth applying yourself to the pre-migration analysis and thinking carefully about your project approach.

### **Prerequisites** ###

The prerequisites for [SAP S/4HANA][SAP S_4HANA] address licensing, technical, and functional (application) prerequisites.

Regarding formal requirements (licenses), SAP offers two options:

*  Changing the licensed product to S/4HANA
 *  Converting the current contract (new licensed BoM).

Another obvious and mandatory point is **the technical requirements** that must be met before migrating to S/4. The source system should be in the SAP ECC 6.0 version with EHP 0-8 and have appropriate component adaptations (according to 2943206 SAP note). Also, be sure to expand your hardware and software platform in accordance with SAP S/4 technical requirements. The appropriate dimensioning of parameters can be done using the SAP Quick Sizer tool.

The last group of requirements – important because of the choice of further migration steps – **are functional adjustments related to the operation of the application**. First of all, it is an adaptation to Unicode (if your system is not already in this standard, a conversion project is necessary). Another necessary action is to launch the Business Partners functionality (the role of business partners deeply interferes with the structure of the master data of vendors and customers, so we recommend performing this adjustment before the main conversion project). Similarly, we recommend early adjustments in finance, including migration to the New General Ledger and new functionality for fixed asset management.

**While licensing issues and technical requirements do not leave much room for interpretation, functional requirements can be quite challenging when preparing for conversion and when choosing a migration approach.** So it’s worth devoting a little more space to them.

### **Goals and expectations** ###

As with any IT project, it is useful to identify the most important project goals when converting to S/4. For many companies, the main and obvious goal will be to secure the system manufacturer maintenance beyond 2027.

Other questions to answer are:

*  do we want to introduce major changes (or, on the contrary – limit changes) in the current configuration and course of business systems;
 *  do we want to enable new functionality available in S/4;
 *  do we seek to retain all historical data or use the project to clean up and remove unnecessary data;
 *  do we plan to reorganize our organizational structure;
 *  do we plan enhancements to reduce the number of custom programs and replace them with standard SAP S/4HANA solutions;
 *  how much system unavailability time we can afford during the conversion.

**The primary approaches to implementing the S/4 migration project are: Greenfield, Brownfield and Bluefield.**

### **Greenfield** ###

**Greenfield is the de facto implementation of a system into a new one**, with all the elements that come with such a project. So you will need an implementation concept, there will be a system configuration phase, testing, data migration and finally go-live. Reimplementation requires a certain amount of time, cost, and development of a production launch strategy (in an organization with multiple business units). An important aspect of this type of project is the development of a historical data migration concept. Finally, the challenges of post-launch system stabilization remain.

The Greenfield approach may be beneficial for companies interested in harmonizing business processes and quickly launching new functionalities. Also companies that plan to significantly reduce client extensions may consider such a strategy as optimal. Reimplementation is recommended when the launch of a new system is one of the elements of a major reorganization of the company’s organizational structure.

### **Brownfield** ###

**Brownfield is a typical conversion of an existing SAP ECC 6.0 (as-is) system to SAP S/4HANA**. Changes to configuration and extensions are made only in those situations that are required by S/4. The design is quite similar to a technical upgrade, with the difference that it is known in advance that some adjustments will be required, followed by testing and a production launch.

As mentioned before, the prerequisite before starting the conversion is to adapt the old system to the technical requirements, i.e. convert to Unicode and implement the functionality of Business Partners.

In this approach, we keep the current solutions. And we introduce changes in functionalities only where S/4 requires it. The main risk associated with conversion is the long time of unavailability of the production system (the determinant here is the size of the database).

In the analysis and preparation phase of the conversion project, we plan the work and perform a series of analyses using SAP Readiness Check and Simplification Item catalog tools. We can also use SNP’s proprietary CrystalBridge Analysis tool. The purpose of the analyses is to identify places to change, assess inconsistencies, and plan necessary adjustments. In the implementation phase, we perform system conversion and previously identified customizations. Finally, we proceed to test and convert the production system.

### **Bluefield** ###

**Bluefield is SNP’s proprietary approach to the implementation of the S/4HANA project,** the essence of which is to separate system conversion from data migration, possible thanks to the use of tools from the [**SNP CrystalBridge** ][SNP CrystalBridge]platform.

The system conversion is based on creating a so-called **Empty Shell**, a copy of the production SAP ECC system, but without the core and transactional data. In the next step, we perform the migration to S/4HANA – without data, this task is relatively easy and does not take much time. Then we move on to the customization stage – implementing Business Partner functionality, fixed assets, and other new functionality (e.g., New Ledger). And in the next step, automated data migration with conversion takes place, in appropriate sequences, during various stages of testing. Master and transactional data from the old system is cleaned “on the fly" and adjusted to the new system – for which CrystalBridge tools are used. The testing phase is followed by a production launch.

The Bluefield approach allows the required solutions to be implemented in a single project (e.g. business partners, Unicode). We can keep not only the current solutions, but also make modifications and implement new tools available in SAP S/4HANA. When migrating data, it’s a good idea to do a cleanup and reorganization to fill the new system with only the necessary data without burdening it with unnecessary archival data. Conversion is also a good opportunity to make organizational changes in the system (company mergers, structure changes, etc.).

The most important feature of this approach is to minimize the unavailability time of the production system (possible variant **near zero downtime**).

### **Analysis and its tools** ###

Regardless of the chosen approach, the first step should be a pre-implementation analysis, and if this is not clear – the analysis should also include the conversion method itself (in-depth analysis).

The primary objectives of a pre-implementation analysis are:

*  Identify and plan necessary changes (e.g., Business Partners, programming adjustments),
 *  selecting the improvements that will be enabled (depending on the method),
 *  detailed project planning,
 *  estimation of the necessary time of unavailability of the production system,
 *  dimensioning the target system,
 *  reducing the risk associated with unexpected mismatches of the current solutions to S/4HANA.

The basic tools used during the pre-conversion analysis are the SAP Readiness Check solution provided by SAP and – in the Bluefield approach – the Analysis module of the SNP CrystalBridge platform.

The most important SAP Readiness Check tools:

*  Simplification Items & Consistency Check (identification of changes important for the conversion project, information on the details of the change, verification of the significance of changes for a given system)
 *  Custom Code (identifies which extensions may need to be adjusted in the conversion project),
 *  Other analyzes (e.g. identification of BW interfaces, functioning IDOCs, compatibility testing of add-ons and dedicated extensions, recommendations for Fiori applications, sizing, Process Discovery, FI data quality analysis).

**SNP Analysis CrystalBridge** – in cooperation with standard SAP tools – allows for more precise and efficient analysis and determination of preconditions for conversion, and additionally the result will be presented in a convenient way. Multidimensional and transparent data visualization is a big advantage of the SNP tool.

### **In-depth analysis** ###

**An in-depth analysis** may be performed prior to the project implementation. Its purpose is not to define the technical aspects of conversion, but to support the business justification for using new SAP functionalities. It can be useful to convince management of the need to migrate and identify potential business benefits. The SAP Process Discovery tool is used for this purpose, which, based on data from the system, develops recommendations for this specific SAP installation. These recommendations help answer the following questions:

*  What is the added value of converting to S/4 for each business area?
 *  What is new in S/4 compared to the current solutions implemented in SAP?
 *  How can we direct and support the automation of business processes.

[Migration from SAP ERP to S_4HANA]: https://www.snp-poland.com/en/offer/migration-to-s-4hana/
[SAP S_4HANA]: https://www.snp-poland.com/en/offer/sap-s4hana/
[SNP CrystalBridge]: https://www.snp-poland.com/en/offer/crystalbridge/