Addressing the most common misconceptions that lead to mistakes in SAP S/4HANA transformations

Misconception #1:

    “SAP S/4HANA is just an ERP system on a faster database.”

What Scheer’s experts say:

SAP S/4HANA is a completely new ERP application that is based on the SAP HANA in-memory database. As such, it opens up completely new possibilities in ERP. Based on this new technology, simplifications and standardizations within SAP S/4HANA can be used to model entirely new processes, applications, and process and business areas. This was not possible in the past using SAP's classic ERP software, for example. SAP S/4HANA offers a combination of hyper-modern technology as the foundation for its ERP system and a completely new software application that has been fully adapted to this technology.

The end of maintenance also plays an important role here: SAP S/4HANA will be supported by SAP until December 31, 2040 (as of June 2022). This means customers have 18 years of planning security. As such, implementing SAP S/4HANA represents a lasting investment for customers. This isn't the case with older ERP software solutions such as the classic SAP Business Suite, for which the end of maintenance is scheduled for 2027 (plus extended maintenance).

Misconception #2:

    “Our processes are ideal and don’t need improving.”

What Scheer’s experts say about this claim:

We often hear this misconception in customer projects. In addition, different departments often have different opinions when it comes to processes: Some classify certain processes as appropriate, while others do not. In the context of SAP S/4HANA and transformation projects in general, it's nonetheless important to know that there are always weak points in a given system. They often involve processes that are underperforming. Luckily, SAP S/4HANA and its technology can help bring them up to speed. There may also be highly complex processes (read: custom developments) in the system that can be replaced by a standard process. This is interesting with regard to ease of maintenance and sustainability, as well; after all, it's much easier to install new releases in the system when following the software's standard methodology.

Other important topics include comparing and adapting components during every release upgrade. Here, making targeted adjustments to a variety of processes (always with an eye on the standard) can reveal the true potential of the system at hand. Besides simplifying maintenance, this facilitates less complex system support and more efficient system handling for the customer and their end-users.

Another important aspect: SAP S/4HANA is the most integrated ERP system on the market, even compared to platforms from other vendors or other ERP systems. Manual maintenance activities – that is, exporting data to Excel and importing it again – can be optimized directly during the SAP S/4HANA transformation. In this case, an attempt is made to keep the data in the SAP environment (that is, in the SAP S/4HANA core) or in surrounding cloud applications.

Misconception #3:

    “Greenfield isn’t for us. We need to keep all the things we've bought.”

What Scheer’s experts think of this topic:

We understand why customers want to protect their prior investments. It's understandable that they don't want to write off all the time and money they have put into their ERP (business suite) implementation.

However, it's also important to note that a decision can't be made until a dedicated roadmap has been drawn up or an assessment has been conducted. It's possible that a customer's old system has been highly modified, that much of the data is legacy data, and that there are unnecessary objects that shouldn’t be stored in a new in-memory database. In such cases, the transformation itself is often too complex.

For example, think of a transformation project in which 20,000 simplification objects have to be taken into account. In this scenario, you'd want to consider whether a highly complex transformation project (brownfield/BLUEFIELD™) should be conducted or a new greenfield implementation would be better. The advantage of the latter is that you can streamline the entire system and only keep the data you really need – for legal reasons, for example.

In addition, there are customers for whom the truth lies somewhere in the middle. This is the case when the customer wants to migrate certain applications or process areas because they have been tailored to their needs, work very well, and can still be used in SAP S/4HANA. However, there can also be circumstances in which the customer wants to stay closer to the standard or capture potential improvements, which makes BLUEFIELD™ the best approach. It enables customers to migrate the legacy content of their systems while still enriching them with new content. BLUEFIELD™ thus represents a happy medium between the brownfield and greenfield approaches.

Misconception #4:

    “We're very familiar with our system and current situation. We know what approach we need and can start with the transformation straight away.”

What Scheer’s experts say about this topic:

For us, it's important to ensure from the very beginning that the customer really knows their situation and their systems and can appraise them accurately. One of the ways we verify this is with an assessment (a preliminary study). If one has already been conducted, we take a close look at the results. SAP provides a full set of possible tools and reports that support such assessments, and they can also be performed with SNP Crystal Bridge Analyzer.

We recommend using all the tools available for analyzing the current system at hand to truly and objectively ensure that it can be transformed, as well as to identify the legacy data that has to be removed from the system ahead of time. These facts must be known before the transformation. A rough estimate isn’t enough here because the customer will quickly reach the point where they start the transformation, click something in the system, and watch as the process is terminated. It's often impossible to correct the error at this point, which means you have to restore the system and start over. In the past, if you had problems installing an update, you could simply correct the relevant errors and keep the system running. That no longer works today.

That’s why one thing is essential for an SAP S/4HANA transformation: the right preparation. You have to analyze your systems and know exactly what to expect. Only then will you know what the right transformation approach is and be properly prepared to get started.

Misconception #5:

    “Brownfield is always faster.”

What Scheer’s experts say about this claim:

This is a relatively easy one to answer: It's generally correct. However, if your preparations don't go smoothly, you run into obstacles, or the process flow is disturbed, you have to restore the system and start over from the beginning. If this happens more frequently, after the third or fourth iteration of a failed brownfield transformation, you've already taken so much more time that a greenfield approach would have been the better option.

If the preparations are sound, the customer will only need one or two iterations at most to complete a brownfield transformation and declare their project a success. If the transformation hasn’t been prepared well, however, four, five, or even six iterations could be needed. This puts the customer on a protracted, cost-intensive, and frustrating path. If a transformation project requires more than six iterations, it's a clear sign that the assessment should have been carried out more diligently or that the customer would have been better off choosing a greenfield approach. The latter would be roughly equivalent in terms of effort, if not even faster and less expensive. That’s why it’s important to know the differences between the different transformation approaches. The brownfield approach involves transforming the legacy system into a new system. By contrast, the greenfield approach gives you the chance to build and run a new system that's leaner, more efficient, and more standardized. It presents an opportunity to explore all the potential the new software has to offer right away.

Misconception #6:

    “Greenfield always requires the most work.”

The opinion of Scheer’s experts:

We generally agree with this statement because system customizing requires more effort under the greenfield approach. The system is built from scratch and the data migration takes place later.

But is that ALWAYS the case? If the customer has a highly complex, modified legacy system, for example, but prefers a brownfield transformation, you first have to examine how expensive a transformation would be under these circumstances. If the expected effort exceeds a certain amount, a greenfield approach would be more logical. It would be faster to build everything from scratch than to examine, modify, and ultimately transform everything in the legacy system separately. Therefore, a greenfield transformation would be faster and require less effort than the brownfield approach.

While the brownfield approach can be executed more quickly than greenfield in principle – and this is a very important point – it always depends on the initial situation in the customer's system.

Misconception #7:

    “SAP S/4HANA is only good for financial processes.”

What Scheer’s experts say:

It's true that S/4HANA Simple Finance was the only solution available initially; SAP starts with the financial processes in every ERP software suite they develop. It's also true that much of the optimization potential lies in the financial processes, but the logistics solutions have also been mapped completely (or close to it) in SAP S/4HANA and also have to be taken into account. SAP S/4HANA has since grown into a full-fledged ERP system that covers the processes in all enterprise areas. The statement above would be valid if we were still in the year 2015, but SAP S/4HANA has come a long way since then.

Misconception #8:

    “Our user interface runs much faster on SAP S/4HANA.”

What Scheer’s experts say:

The speed of the UI has nothing to do with SAP S/4HANA directly. SAP S/4HANA offers the option of using a new UI. Is it fundamentally faster as well? There is no universal answer to this question. Of course, the SAP HANA database does offer an exponential increase in speed in terms of the process steps within the application – that is, between the application and database. However, if you have a poorly configured IT infrastructure between the back-end system of SAP S/4HANA, including the database and the UI (which is somewhere on the client side and may also have notebooks, networks, gateway servers, web dispatchers, and so on connected in between)  the UI will be excruciatingly slow even with the ultra-fast SAP S/4HANA system running in the back end. And it doesn't matter if the infrastructure is in the cloud, at a data center, or on-premise. In other words, a fast back-end system doesn't automatically mean a fast UI. It's very important to have a sensible system architecture to ensure that the back end, including the network components involved, works fast together with the peripheral systems.

Misconception #9:

    “We don’t need an assessment.”

What Scheer’s experts say about this claim:

Our experience shows that while many customers share this opinion, it only holds true for a small minority of them. This can be best illustrated based on an example: If a customer only just implemented their ERP/ECC system a few years ago, the system is very close to the standard, the customer is familiar with it, and the system isn't too large or too heavily modified, the customer can complete a successful transformation to SAP S/4HANA with just a few rudimentary checks. No in-depth assessment would be needed in this case.

Does it still make sense to carry out an assessment in a streamlined form? We think so! First of all, a brief analysis of the current situation helps verify that the transformation project will be successful. Second, you might also find one or more processes that can be simplified, standardized, or otherwise optimized. All this can be done with SAP S/4HANA, which is why we recommend conducting a brief assessment in this case, as well.

In short: An assessment is always a good idea in principle, but we do check whether the customer only needs a brief overview to ensure that everything works or if they require a detailed assessment down to the object level in their system. That’s also why the duration of an assessment varies so widely: Some can be completed in six or seven days, while others take 300 days or more.

Misconception #10:

    “Brownfield is suitable for any company.”

What Scheer’s experts say:

Brownfield is particularly interesting for some companies, just like greenfield or BLUEFIELD™ could be interesting for others. None of the colors is always the right choice. There are, however, situations in which one transformation approach is better suited than others.

If the customer wants to perform a merge, implement new processes, or optimize existing ones, for example, or a project involves standardization or extensive changes to system logic, the brownfield approach isn't the right way to go. Here, you first migrate as much as you can and then start thinking about what you can optimize. That would be the key criterion for choosing a transformation approach in this case.

In summary, when customers approach us and ask us to migrate everything from their current system just as it is, brownfield is a good option. As soon as you start changing the application logic, however, you should give more consideration to BLUEFIELD™ or even greenfield. The only exception is if the customer prefers a two-stage procedure in which they'll first migrate everything as-is, then examine the potential and start optimization projects later. The brownfield approach would also work here.

If you decide to use a brownfield approach, however, there's some important data that requires special attention. Eventually, you'll need to make customizing changes and adjust or modernize/harmonize your charts of accounts. Ideally, you'll be able to implement these changes immediately following a fiscal year change. This entails doing a very good job of timing the corresponding project. 

Misconception #11:

    “Testing isn’t needed for all transformation approaches.”

What Scheer’s experts say:

In customer projects, we often hear that the brownfield approach requires much less testing than the greenfield approach. We generally don't agree with this statement because some changes are necessary even in the brownfield approach: In principle, every layer in the system is changed, including the user interface, the software, the database, the database technology, the corresponding infrastructure components, and the deployment model. As we see it, this automatically means that tests are required. Ideally, a test management tool (and maybe even test automation) will be available to provide support and help speed up the procedure. That’s why we maintain that tests are essential under all transformation approaches.