CONSULTING
S/4HANA mixed model conversion | Greenfield and Brownfield
Julio de Miguel Calleja
SAP Business Development Director | Linkedin
Over the years, our SAP system has become a legacy system comprising multiple developments and modules that are no longer supported by the new S/4HANA product. Developing the right strategy for the conversion may involve reimplementing certain processes with new functionalities and deciding what to do with all our old developments.
Let’s consider an extreme example that we have encountered in several projects. We implemented SAP R/3 in the nineties, migrated to SAP ERP or SAP ECC at the turn of the century, and upgraded it using successive enhancement packages (EHPs) and patches (SPs). Until now, SAP has maintained backward compatibility, which has allowed us to continue working with the old functionalities.
With the advent of S/4HANA and its principle of simplicity, the first step is assessing our current situation. We run the simplification list, which provides an initial overview. After analyzing the document, we identify the add-ons and business functions that we have activated that are incompatible with our installation. This is relatively easy to solve since each add-on manufacturer usually has a conversion or uninstallation strategy. Additionally, we must address technical aspects, such as whether we are using UNICODE and if our JAVA and ABAP stacks are combined.
Next, we create a customized list of simplifications, identifying the functionalities to be replaced. The most common ones include:
- New data structure for accounting and controlling
- Asset Management Process
- Activate Material Ledger
- Activate planning areas
- Management of customer, supplier and employee master data (Business Partners)
- Integration with CAD systems via synchronization tools (eCAD – ECTR)
Finally, we determine when and whether to incorporate process improvements and other elements, such as archiving outdated data.
Project organization
After identifying what we want to do, we must consider how to carry out the project. We can opt for a minimal project—converting and implementing what we have—or we can take advantage of the innovation process to improve our processes.
First, we must ensure the technical aspects of the conversion are executed properly, such as converting to Unicode and separating the Java and ABAP stacks. Typically, we use the need to upgrade operating systems as an opportunity to reinstall the system to meet the initial technical requirements.
Setting aside the technical aspects, we focus on the functional process. We organize our project to execute it efficiently and renovate everything effectively.
Prioritisation of objectives in a Greenfield and Brownfield project
We have identified what we must and want to do to take advantage of the momentum. Now, we must prioritize and determine the timing of each action.
SAP tells us when to perform the mandatory actions detected in the simplification list: before, during, or after the migration process and whether they are mandatory or optional. After analyzing them, we determine the exact order and execution strategy for each one. One aspect common to almost all projects is the activation of Business Partner synchronization. We recommend separating these actions from the main conversion process and putting them into production beforehand.
Along with activating Business Partners synchronization and making other mandatory improvements before converting to S/4HANA, we can use this period to implement small improvements (quick wins) that we can activate within two to three months. Thus, during the innovation process, users will detect small successes, and the project will become one of innovation, not only technology.
Once the conversion process starts, some processes are converted through the processes established by SAP and some customizing, as outlined in the simplification list. This includes basic activation of the Material Ledger and planning areas, which will prepare our system to work with S/4HANA.
To improve these basic activations, establish more complex definitions, and replace tools such as eCAD with ECTR, we must implement our “brownfield + greenfield” model. We must implement these functionalities as a small project within the conversion project and plan it in a coordinated way to avoid interference.
Additional improvements: When to plan them?
In project planning, since we are defining an innovation process, there will be improvements that are not dependent on the conversion process. The question is when to address these improvements. The simple answer is to address them after the conversion, which is an appropriate strategy for non-urgent improvements.
For urgent improvements, IDOM proposes preparing them on an additional server (SANDBOX). As the conversion processes are tested, they will be tested and transported in these test environments. Once the productive server has been converted, the improvements will be defined, activated, and tested in the integration server. This allows for a quick GO-LIVE, for example, one month after the launch of the main conversion project. We consider changes to processes of a certain entity, actions related to costs or accounting processes, and the implementation of new modules that substantially improve our processes.
Custom Code
Executing such a project is an opportune time to redefine our development strategy. First, we will take an inventory of each development and evaluate its utilization level to determine if it can be replaced by standard functionality. Adapting in-house developments to S/4HANA requires significant effort, and cleaning up our custom code base is crucial.
SAP’s current philosophy, CLEAN CORE, advocates keeping S/4HANA free of developments and leveraging BTP capabilities to keep additional applications out of the core. This allows us to optimize the development and streamline the maintenance of these functionalities using LOW CODE capabilities.
You can approach planning a S/4HANA conversion process as a technology refresh to adopt new innovations once the corresponding version has been implemented. Alternatively, you can opt for a more ambitious project that leverages existing equipment to implement new processes.
So, what would be the best strategy? Unfortunately, there is no single strategy that is best for all cases. Each situation must be analyzed based on available resources and the degree to which the ERP has evolved in recent years. At IDOM, we recommend avoiding overly ambitious projects. Clearly measuring the objectives to be achieved and ensuring you have the necessary resources to achieve them is crucial.