Lost among the fifty fields of SAP S/4HANA transformation approaches

Publish date:

What is the right approach for SAP S/4HANA transformation?

I was talking with some people from a customer organization recently about their SAP S/4HANA transformation strategy, and it was obvious that the differences between the various options were far from clear. This was not the first time this has happened to me, and it’s understandable. It’s very easy to get lost among all the different “fields” that are used as proxies to reduce often very complex topics into single words. Greenfield, brownfield, blackfield, bluefield, grayfield – soon all the colors of the spectrum will be in use. When you combine this with the somewhat-blurry definitions and (intentional or unintentional) shaky use of the terms, it’s likely that when two people talk about, let’s say, brownfield, they are not talking about the same thing.

This blog post consists of two parts. In this first part, I’ll try to bring some clarity to the different scenarios and the terminology used. In the second blog, I will share my views on how to choose the right approach – namely how to make sure you are playing on the right field.

From a technical perspective, SAP S/4HANA transformations can be divided into three categories:

  1. New implementation
  2. System conversion
  3. Landscape transformation.

New implementation

In a new implementation, the SAP S/4HANA application is technically installed from scratch. The system is then configured, interfaces and other developments are built, data is migrated, and subsequently the solution is deployed to the business. Most people associate the term greenfield with this scenario.

Variations come, for example, from the approaches to solution implementation (build and deploy the full solution at once, or build and deploy the solution in incremental releases); from business deployment (big bang or phased); from the extent of the data migration (ranging from migration of open transactions only, to migration of full historical data); and, in particular, from the possible re-use of processes, configurations, and custom development from the “legacy” SAP ECC system(s).

System conversion

In a system conversion, the existing ECC system is technically transformed into an SAP S/4HANA system. Depending on the circumstances, technically this transformation can involve, for example, a Unicode conversion, a database migration (to HANA), a cloud migration (to a public cloud IaaS such as Azure or AWS), and always includes the conversion of the ECC application into SAP S/4HANA – including the conversion of all of the existing data into the new SAP S/4HANA data model. Since current ECC production is converted into new SAP S/4HANA production, it is by definition a big bang deployment. Most people associate the term brownfield with this scenario.

Variations in a system conversion are quite numerous. One can do a technical in-place conversion with minimal changes in processes and functionality, driven by mandatory SAP S/4HANA changes (simplifications) and data model changes, or a much wider and comprehensive redefinition of the business processes and functionality, employing a wide set of SAP S/4HANA new features and simplifications, including Fiori. Alternatively, these two approaches can be combined (technical in-place conversion followed by a systematic implementation of the SAP S/4HANA new features in subsequent releases). It’s worth noting that a complete redesign of the solution, and in particular, the information model, is in practice not possible, so system conversion is more an evolutionary than revolutionary approach.

Often even massive clean-up activities in the source system are undertaken to prepare for the conversion, including data archiving, data clean-up, deletion of unused custom code, and the migration of custom code from the ECC into a cloud platform (such as the SAP Cloud Platform) using modern microservices architecture. These primarily serve two purposes: reducing the downtime as a result of the smaller amount of data, and reducing the among of custom code in the core, making it possible to move much closer to the SAP standard.

Landscape transformation

In a landscape transformation, the existing SAP ERP landscape (possibly a heterogeneous combination of multiple ECC and S/4HANA instances and even non-SAP ERPs) is selectively transformed into a new single-instance SAP S/4HANA system, using the SAP Landscape Transformation solution. The tooling enables heavy restructuring of the SAP organization and data, to support mergers, carve-outs and internal reorganization (use cases such as company code deletion and company-code merge, or chart of accounts conversion or cost-center conversion).

In short, the single target system can effectively be a composition of organizations and data from multiple source systems, with the needed data converted as part of the process. Technically, the target system is created via system conversion from a selected source system, followed by selected migration (and conversion) of data. A process and functional harmonization under this scenario is therefore very similar to process and functional improvements executed under a normal system conversion scenario. The extent to which the tooling supports automated data restructuring is limited to predefined scenarios focused around financials data, so universal restructuring and merging of any data is not possible.

An important variation of this scenario is the empty-shell approach, where a single source system is first copied with configuration and customization (i.e., no data) and then converted to SAP S/4HANA, followed by subsequent selective migration of data, and deployment to business (possibly in a phased approach).

Depending on the speaker, the landscape transformation scenario is often called either a blackfield, bluefield, grayfield, or hybrid approach.

 

Real-life scenarios

The world is seldom black and white. The reality is that every company must choose the right approach for their S/4HANA transformation – in other words, to choose the field that suits them best. This “rightfield” approach in most cases combines elements and aspects from all three of the theoretical models defined and discussed above, selected to optimally match specific circumstances and requirements.

In the next post in this blog series, I will consider how to choose the right approach.

Stay tuned for more and reach out to me if you want to discuss the fifty fields of SAP S/4HANA transformation approaches.

Related Posts

A designer’s view on AI ethics (part 2 of 3)

Reinoud Kaasschieter
Date icon November 22, 2019

A designer’s view on AI ethics – AI used in products (and services)

automation

Smart Factories and Industry 4.0 – Is it really about human interaction?

Nigel Thomas
Date icon November 22, 2019

In an intelligent enterprise of the future where IT (the ability to provide increasingly...

Is the future truly digital or is it something else?

Grant Volker
Date icon November 22, 2019

When combined with the masses of data each of us generates, are we not already becoming...

cookies.

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.

Close

Close cookie information