jivs imp transformation platform [shutterstock: 1725113818, Song_about_summer]
[shutterstock: 1725113818, Song_about_summer]
Blog SOH and S/4

Transformation: New And Radically Simple

It is imperative that SAP customers start their S/4 transformation in the coming years, especially because desperately needed consulting resources are lacking in the market. Although S/4 transformation is a golden opportunity to help organizations gain a competitive advantage, it must be effective and radically simplified.

Demand for SAP transformation projects is growing exponentially – at least in theory. But in practice, existing SAP customers are encountering a key obstacle: the lack of human capital. The too-scarce supply of SAP consultants and migration specialists has unfortunately now reached global proportions. There are already reports from the market that some SAP migration companies will not be able to accept new transformation projects for at least another year. The fear is that by 2025 at the latest, every available SAP migration specialist would have to work around the clock to keep up with demand.

Of course, that won’t happen. But what will happen instead is clear: daily consultant rates will rise dramatically, and project durations will become much longer. This is a sub-optimal starting point for the digital transformation of large SAP customers in German-speaking countries, for whom the switch to the new software generation from Walldorf is at the core of their digitization strategies.

Color theory of S/4 conversion

In addition to consultant capacities, companies also must choose a suitable transformation approach. In recent years, it has become convention to assign colors to the various options. The color spectrum ranges from brownfield to greenfield with many different shades in between. At one end of this spectrum is brownfield. The term refers to a complete transfer of previous data structures, business objects, and individual customizations as well as in-house developments, including all legacy data.

At the other end, greenfield beckons. With this approach, companies start fresh with data structures, business objects and customizations as they see fit for their respective business future. If companies want to transfer data from legacy systems, they have two options: Either they transform all the data with great difficulty and expense, or they transform only a subset – the master data and open items. In both cases, however, the original data accumulated to date remain in the legacy systems which needs to be operational in parallel for longer periods of time due to compliance and business reasons.

Brownfield dilemma

Both extremes have their benefits, but also considerable disadvantages. Companies with a homogeneous system landscape, i.e., without third-party systems and different release statuses, who do not want to change their existing business model and therefore consciously forego changes and innovations, will find their optimal method for transformation to S/4 Hana in brownfield. In the case of large SAP customers, however, the system landscapes are usually so heterogeneous and the databases so extensive that their conversion to brownfield only appears to be technologically straightforward. As is often the case, appearances are deceptive, because many prerequisites have to be created in the source systems, in some cases in time-consuming preliminary projects. This includes, among other things, getting rid of customized processes or activating new business logic.

Exorbitant costs included

In addition, many test runs involving different departments are necessary to avoid (often costly) mistakes. Furthermore, the conversion of the usually very large volumes of data requires immense computing capacities, exorbitant costs included. Against this background, it is no longer surprising that many existing SAP customers have difficulty justifying the business case for an SAP transformation project.

Even more critical from a business perspective, however, are the difficulties between internal environments – dependencies between the data, their structures and source systems, but also from interfaces between different systems. Complexity of data set inclusion poses many challenges. Incidentally, this also includes data that might be unfortunately hardwired to obsolete business processes, data collection and collaboration from numerous organizational units, and document types and processes that are no longer relevant to current business operations. In many cases, this immaterial data unfortunately can account for up to 90 percent of the total data inventory. In fact, the interdependencies are so intricate and insurmountable that the opportunity for a fresh start or the foundation for new business models and processes, which management in most cases associates with the S/4 conversion, is destroyed.

Minimal chances of success

Unfortunately, solving this fundamental problem of dependencies has only minimal chances of success, regardless of whether companies try to solve it in the source system, i.e., before the transformation, or afterwards. It is virtually impossible to clean up master data with dependencies to outdated data structures, let alone create a harmonized (meaning cross-system) view of master data, which is usually distributed across several different source systems. The reason is SAP legacy customers have to deal with extreme dependencies in this process, such as thousands of documents that are not closed. In other cases, it may not even be possible to get the data out of archives because their underlying technology dates back to circa 1990.

In short, interdependencies between master data, transaction data, and customizations in legacy systems prevents or at least massively complicates their harmonization. Since relevant master data are usually found in not just one, but several different systems, the problem becomes even more severe. This is because different master data from different systems would first have to be harmonized before the conversion – which is prevented by the dependencies. The vicious cycle is brutal. Often, the associated effort for both the business departments and IT is practically unjustifiable for such a transformation.

Lack of skills and resources

Existing SAP customers who, in a classic brownfield scenario, nevertheless attempt to at least clean up their master data after switching to S/4 will have to enlist the help of their business users to do so. However, that is not a viable solution, either. If we assume that a business user needs ten minutes to check and clean up one master data record and works eight hours a day, the company will have to plan for more than 10,000 working days for a master data inventory of 500,000 individual data records. Of course, you could enlist the help of many, many business users. Nevertheless, the effort involved remains considerable. Whether these attempts at manual data cleansing will be crowned with success is only written in the stars. There wil be problems linking different types of data with each other, not only with the systems that reside in the existing source systems, but also in the target systems. Solving this problem is hardly possible as well.

Things don’t look much better when it comes to transaction data. The ERP landscapes of major SAP customers in German-speaking countries have grown over the past ten to twenty years. If we assume that companies only need data from the entire past year in S/4 for further processing, they convert 90 to 95 percent of the data in a brownfield approach for nothing. What’s more, this represents a crushing legacy for the new system, tying up enormous computing and storage resources, leading to poor runtimes and driving up maintenance and operating costs – especially for updates or new upgrades. Overall, the possibility of optimizing data quality on the one hand and modernizing processes on the other is almost nonexistent.

Greenfield dilemma

In contrast, greenfield does have undeniable advantages. Especially companies with a very heterogeneous system landscape and large databases benefit from it. For example, if they completely turn their business model upside down and start over – almost like a startup; or when they fundamentally transform their structures and processes from a centralized to a decentralized organization.

But here, too, appearances are deceiving. Best-practice approaches that promise extensive standardization are tempting, but many existing SAP customers also fear them. They threaten to devalue the high investments made in the customized versions of their legacy systems, including customer-specific developments and optimized processes. After all, SAP customers have made these investments to gain a unique competitive advantage. The effort required to replicate these in the new software generation is enormous. Here, too, the business case usually does not pay off unfortunately.

The alternative would be to choose a greenfield approach and simply transfer the open items and master data. However, this very often leads to a massive acceptance problem within the company. This is because users at all levels, up to the CFO, want easy access to all legacy information for various business reasons, and on two inclusive conditions: They want to access it from “their” interface and not toggle between different solutions, and they want the legacy information to look exactly as if they had created it in the new system. Both conditions are better achieved with a brownfield approach, which CIOs and their management colleagues would usually prefer to avoid in favor of change and innovation.

Selective data transition

Between brownfield and greenfield, a wide variety of color shades have now established themselves in terms of transformation. What they all have in common, however, is the fact that only part of the legacy data is transformed and transferred to the new world. In principle, this approach is the right one to reduce the effort involved in both the transformation and the migration. Furthermore, it offers the flexibility to optimize the future system independent of master and transaction data. Selective data transition is certainly the right thing for those SAP legacy customers with a large system landscape who, despite some necessary adjustments, want continuity and to build the new landscape largely on predecessor systems.

However, business departments usually want to see and access all historical data in the new system as well. And rightly so! Companies have never needed access to their historical information, sometimes for decades, more than they do today. Digitization means that new offerings are making way for new products, complementary services, and maintenance services. Such complex offerings have lifecycles of ten to fifty years. Historical information, even if it dates back many years and is no longer changed in day-to-day business, thus acquires the same relevance as operational information for product development and the continuous optimization of offerings and their quality based on data analyses.

Migration versus transformation

From the perspective of project managers responsible for SAP transformation, this wish of “migration” of the business departments is unachievable. More than the transfer of data from the last two or three years is not even possible to retain the flexibility to at least partially adapt and optimize the new system.

However, even when IT prevails over business, selective data transition proves suboptimal in many cases: First, this approach works primarily when the source and target systems are very similar, for example when applied between the latest ECC version (Business Suite 7) and S/4. Second, the selective data transition tools that work at the table level can introduce the risk of inconsistencies. Who can guarantee that, among other things, the direct table-oriented loading of data records into 100,000 tables and more will be error-free in the case of large SAP environments?

While it is true that this risk can be mitigated by testing, this generally only helps to a limited extent cleansing the data to help optimize its quality for the new system. Accordingly, SAP legacy customers have only limited options for ensuring a harmonized database that is fed data from both SAP legacy and third-party systems.

No harmonization

The possibility of harmonization is an essential prerequisite for realizing the goal of a data-driven company – not to mention the fact that, with the selective data transition analogous to brownfield, a switch to the public cloud or even a (partial) switch to a third-party system is only possible to a very limited extent. The fact that data and their dependencies represent the fundamental challenge in the S/4 transformation is a realization that is just now gaining ground in the SAP community. So, what can existing SAP customers do? Are they forced to choose between the disadvantages of the various approaches? The ideal solution, of course, would be a transformative approach that is as technically straightforward as the brownfield approach, but also as flexible as the greenfield method, in which companies can cut off old ties, implement new business processes and models, and transfer only master data of the highest quality to the new system. But does such an approach even exist?

One Click Transformation

Yes, there is a sustainable solution that not only solves old problems but also opens new paths. However, the prerequisite is that the transformation takes place at the application layer independently of the data layer. The solution needs to extract all legacy information together with its business context completely, unchanged and, above all, efficiently and quickly, and transfer it to a separate platform. As a result, SAP customers are free to choose whether they want to opt brownfield to migrate their existing application environment with all business objects, customizations, and in-house developments with the conversion tool into the new S/4 world; or choose greenfield and start anew.

But what happens to the legacy data? Well, firstly, it would be much better to talk about historical data than legacy data, because many feel the latter might sound as if data could be stowed away in an archive somewhere and be forgotten about. However, the opposite is the case: Welcome to the world of big data and analytics, where the data-driven enterprise is almost vitally dependent!

Everything is data-driven

For this purpose, the information from the legacy systems that is also required in S/4 Hana must be filtered out on a separate platform according to business criteria. It needs to be cleaned up, enriched with data from third-party systems, and optimized. While only five to ten percent of the transaction data usually need to be transformed and migrated to S/4 after optimization, the amount of master data is reduced to an estimated twenty percent, which are then also transferred in optimal quality through standard tools such as SAP’s Migration Cockpit. Naturally, all of this should be automated.

At the same time, this new platform must be able to display the historical data in the S/4 world via SAP GUI or Fiori as if it had originally been created there. This transformation on the fly through the technical structure mapping process – of course without changing the original structure of the historical data on the platform itself – must also take place automatically. This level of automation from data extraction to display in the new environment is the essence of the One Click Transformation.

Technical structure mapping

Although not dissimilar to the selective data transition, the One Click Transformation has key additional advantages:

All information – historical and operational – can be harmonized, easily enriched with data from third-party sources, and optimally prepared for big data and analytics scenarios. Incidentally, this applies not only to movement data, but also to all master data, including the customer, supplier, article, and material master data which are all important for digital transformation.

In addition, the decision as to which information from the existing data should be transformed and migrated to S/4 Hana depends on the respective business-relevant criteria of customers. Instead of transferring all data from the last three years, for example, existing SAP customers can consciously decide to transform, and migrate only the open orders and master data for customers and suppliers with whom they have ongoing business relationships.

CFOs find this scenario very advantageous. Periodically, CFOs and business departments may disagree and are in conflict when IT colleagues state they need all the legacy data in the new system, there is often a misunderstanding. What they need is not historical data in the new system, but only access to it from the SAP S/4 interface. With the One Click Transformation approach, this is not an issue. Users don’t even notice when historical data are not stored in the Hana database.

There are great benefits to this approach, including a clean and transparent data set for competing in the digital economy, a massive reduction in the amount of data to be transformed and migrated, and simplified migration using SAP’s standard tools. Furthermore, once the historical information has been transferred to the separate platform, legacy systems and applications can be completely decommissioned. This usually eliminates 80 percent of operating costs. The time and cost required for the actual data filtering, transformation and migration is substantially reduced, often cut in half. This highly requested, patented software platform has already been used in more than 2,000 projects worldwide.

Continuous improvement

Since the new data added to the S/4 world can be continuously transferred to a separate platform, the new environment and in particular in-memory computing database Hana can remain permanently lean. The savings potential that can be achieved through this continuous rightsizing is likely to be 25 percent or more over the entire lifecycle of the new environment.

And another crucial point: One Click Transformation can also help customers who have opted for the classic brownfield, greenfield and selective data transition approaches and have already taken initial steps, because it supplements these processes with their specific advantages, starting with the identification and design of filter rules and the historization, preparation and harmonization of data, to their integration in SAP S/4. It also enables the complete decommissioning of legacy systems, including corresponding operating cost savings.

Auditable including legacy

In all of this, compliance has to remain a priority. All historical data and documents are stored on the platform in an auditable manner. In addition, a platform that supports the One Click Transformation approach offers the possibility of managing the stored information down to the level of the individual data record or document throughout its entire lifecycle until legally compliant deletion after expiration of the applicable retention periods. This also makes it possible to meet the increased compliance requirements, such as the targeted deletion regulations of the European General Data Protection Regulation (GDPR).

The One Click Transformation approach is characterized by the consistent and continuous separation of historical data from operational data. The consistent separation between data and algorithms is also unparalleled in the market. This solves the fundamental problem of the dependencies described above. However, the massive savings in transformation and operating costs, as well as the expenses for data cleansing and harmonization, are by no means everything the solution has to offer. Additionally, the platform that supports this approach conserves the transformation knowledge, so to speak, and makes it permanently available: for accessing historical data from within SAP S/4, for accessing historical data from non-SAP systems, and for allowing data availability for third-party applications such as analytics solutions.

Transferring data to a separate and modern platform also contributes to greater security and compliance because, unlike some legacy systems, this platform can be patched in the future. This is because many legacy systems need to operate on old software releases and therefore usually needs outdated operating systems and database support. Often, the manufacturers no longer provide any security patches. In addition, such a platform can serve as a digital repository for business-relevant data and their context which are created in SaaS and other cloud solutions, but where the rights to the data do not lie with the companies but with the providers of the solutions. Consequently, access to the data is retained even after the subscriptions have been terminated. Finally, such a platform lays the foundation for future IoT scenarios or digital twins of products, machines and plants, buildings, and more, which – enriched with operational data – can decisively improve their manufacturing, operation, maintenance, and management.

One Click to your data fabric

All this becomes possible because such a platform keeps historical information together with its business context, but independent of its source systems. The large number of failed data lake projects in which the business context is missing shows that this platform approach is far better at mastering future requirements in terms of enterprise-wide data management. This brings SAP customers significantly closer to the goal of data fabric recommended by analysts. A legally compliant platform for the lifecycle management of enterprise information from SAP and non-SAP systems is the basis for the patent-pending One Click transformation to S/4 Hana and the data-driven enterprise. The platform for this is called JiVS IMP and comes from the Swiss provider Data Migration International.

Source:
E-3 Magazine March 2022 (German)

About the author

Peter M. Färbinger, Editor-in-Chief

Peter M. Färbinger is Editor-in-Chief and Publisher at E-3 Magazine, B4Bmedia.net AG, Munich, Germany. He can be reached at pmf@b4bmedia.net

Add Comment

Click here to post a comment

Social Media

Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "noreply@..", "admin@.." or similar as these may get blocked for security reasons.

We use rapidmail for dispatching our newsletter. By signing up, you agree that the data you have entered will be transmitted to rapidmail. Please take note of their terms and conditions and privacy policy. terms and conditions .


Our Authors