This Special Report is available as PDF download at the bottom of the page.
The scope of migrating to S/4 goes beyond a technical and functional change of release. In recent months SAP has put much effort in the switch from ERP/ECC 6.0 and the SAP Business Suite 7 to Hana and S/4 for its customers. This switch must be shaped in a way that is as transparent, escalation-free and as safe as possible. Yet the typical in-house challenge is not so much getting the technical tools in order, but rather the lack of experience with transformation projects like this and with the sheer volume of data.
For the community it is often seen as almost impossible to come up with a Hana and S/4 roadmap without an experienced SAP Partner. Unfair, perhaps, but that is the practical reality. Understandably, goodwill towards the SAP team in Walldorf is not particularly high at present. For months, the German ERP provider has faced pressure to justify itself in that regard. The helper at a time of distress is the international SAP partner community. In recent years a lot of experience and knowledge has been gathered on how to best customize Hana and S/4. By now, users applying IT tools from the partner community are able to finish most migration projects stably and without errors. In this E-3 special report, Thomas Failer and Tobias Eberle of Data Migration Services state the most important parameters for successful S/4 transformation.
Deadline and master data
ꞌEach firm must ultimately decide for itself when the time is right to switch to S/4,ꞌ Administrative Council member Thomas Failer noted at the start of the discussion. ꞌPreparing the switch, cleaning up the master data and improving that data’s quality are important measures, if not indeed mandatory ones, for advancing the digitization with S/4 in the best way possibleꞌ, he emphasizes, thus focusing on the data to be migrated from the SAP system.
Another purposeful preparation task is to reduce the data volume in the current SAP systems by archiving or by a right-sizing operation. ꞌIn this way, the data volume of SAP systems can be cut significantly, by around 70 per cent, making the switch afterwards much easier,ꞌ Failer pointed out, based on numerous successful projects, adding: ꞌThere is another preparatory measure that we see as extremely important, namely shutting down legacy systems, also known as historicization or Application Retirement. Often such systems continue to be run, to satisfy the legal data-access requirements. Effective and efficient application retirement, using our IT tool, JiVS, can cut the current running costs by up to 80 per cent, while continuing to satisfy legal requirements.ꞌ
Data quality for S/4
Data Migration Services emphasize data quality and data management. CEO Tobias observes: ꞌOften the focus in the S/4 roadmap is on functionalities or the use of new possibilities with S/4. It is easy to overlook that the data quantity and its quality play a key role when introducing S/4. It is mostly also overlooked that, after S/4 is introduced, the legacy SAP systems remain present and continue to be run. Here it is advisable to include consistent application retirement into an S/4 roadmap.ꞌ This now prompts a question: In the context of the S/4 migration, how can users identify and eliminate weaknesses regarding data retention, data quality, data growth, and configuration errors?
Thomas Failer, owner of Data Migration Services, takes this view: ꞌYes, the switch to S/4 offers a chance to check the data stocks with regard to data retention, data quality and data growth, and to identify and eliminate configuration errors. The brownfield or the greenfield approach are suitable for this. As a matter of principle, these migrate solely the data that is essential to the target system. Cleaning up the data before the migration, especially the master data, makes it possible to correct any configuration errors and to improve the data quality. Data Migration Servicesꞌ JiVS platform provides support to the customer, by simply analysing the data stocks and exposing weaknesses that way.ꞌ
Before migration
ꞌPreparing the master data absolutely must take place before the migration to S/4,ꞌ Tobias Eberle re-emphasizes. Data Migration Servicesꞌ experience indicates that the master data should be adapted to address the following issues: extracting unused master data that is no longer needed; cleaning up duplicates; applying standardization and norms to master data, and also adding S/4-relevant information to the master data. ꞌIdeally, the master data is processed before S/4 is introduced. That process can be started separately from the migration, today or at any time the SAP customer wishes,ꞌ Thomas Failer explains.
Without SolMan
This might immediately prompt many SAP customers to think of the standard tool SolMan, that has acquired a vast enhancement in its functions and capabilities in Version 7.2. However, ꞌAs we see it, SolMan is not an option for data maintenance and data quality. We rather use of the SAP Migration Cockpit for the consistent import of the data into the S/4 environment, ꞌ Eberle points out, based on many successful client projects. For each migration project, the suitable approach to infrastructure is also discussed.
What are the advantages and disadvantages of a greenfield and brownfield approach respectively? ꞌThe two basic migration paths, greenfield and brownfield, each have specific advantages and disadvantages that need to be evaluated individually for each SAP client.ꞌ Thomas Failer is convinced, explaining in the E-3 discussion: ꞌWhile the greenfield approach demands a new implementation, a rearrangement of brown ꞌinherited burdensꞌ offers the clients the prospect of investment protection for what are usually expensive, laborious adaptations of SAP systems.ꞌ
Greenfield or brownfield
CEO Tobias Eberle warns that there is something more important than recommending one migration path or another. It is understanding that, with both variations, a clean, predictable calculation will not work. ꞌBecause in all cases the companies must make extra investments in SAP S/4; after all, they have to get new licenses and buy costly hardware or enter into subscriptions, ꞌ Data Migration Servicesꞌ CEO explains. The data volume from the legacy systems is indeed reduced when switching to the Hana database. However, the demand on infrastructure is much greater, because the combination of classical infrastructure and archiving solutions becomes obsolete.
ꞌIt is particularly the migration in one’s own datacenter, as favored by most SAP customers, that proves to be a huge cost-driver, whether step-by-step or as a one-off move,ꞌ Thomas Failer stresses. Yet the two managers have a solution. The problem is that the SAP customersꞌ planned increases in budget will not be enough to make the necessary resources available for modernization and a greater level of digitization. So for both migration paths, the recommendation is thus to shutdown legacy systems made obsolete by the migration, resulting in huge savings on running costs.
Cleaning and shutdown
Accordingly, time and time again, components no longer active and needed are found in SAP systems; this applies to ꞌforgottenꞌ Abap functions from the Z-name area and to settings in the FI/CO area.
What possibilities exist for identifying unused company booking codes and shutting them down? ꞌCompany booking codes no longer needed are an unnecessary load carried by an SAP system; itꞌs a good idea to remove them,ꞌ Tobias Eberle notes, explaining many customersꞌ situation. ꞌFor legal reasons, company booking codes cannot be deleted without further ado. Yet the JiVS solutions mean that these circles can be deleted securely in SAP. The first step is to copy the data from SAP to JiVS. Then the JiVS system is set up for access to the data. Here JiVS offers 700 predefined business items for SAP FI, CO, MM, SD, HR, etc., meaning that access to the data can be set up to be fast. Using SAP or other resources, the company booking code in the SAP system can now be deleted. The data access then follows using the JiVS web user interface.ꞌ
A slim archive
So how do users keep ꞌlegacy systemsꞌ small as a cost factor? And keep the archive slim and agile? Tobias Eberle: ꞌThe cost involved in operating the legacy systems must be reduced permanently. The preferred way to do this is by consolidation and shutdown. The application users have known this for years but they flinch, daunted by the costs involved.ꞌ Here too, Thomas Failer has a logical reply for the SAP community: ꞌStandardization and automation are prerequisites for a solution suitable for shutting down the legacy systems. The solution amortizes the required investment quickly and then achieves consistently lower operating costs.ꞌ The JiVS solution from the Swiss company offers precisely these strengths, owing to numerous successful projects involving data migration and shutdown of legacy systems.
In practice, after shutting down the legacy system, JiVS has demonstrably cut the running costs by 80 to 90 per cent. With the remaining 10 to 20 per cent, customers can continue to use the legacy data that must be retained for compliance purposes, including the SAP business logic. Tobias Eberle adds: ꞌBefore historicization of the data and documents, duplications are purged. Usually this leads to a clear reduction of the data-storage volume. At the same time, it reduces the amount of information to be taken over into the live system.ꞌ
Current master data
An S/4 roadmap must also inlcude infrastructure. Which questions must be clarified on the subject of hardware sizing and licenses with regard to Hana and S/4? Tobias Eberle: ꞌUsers must clarify which data must be migrated to S/4, and what data volumes result from this migration. Specifically this raises the question of whether historical data must be migrated to a new S/4 system.ꞌ Ideally, S/4 can be used to make a greenfield start, with only the current master data being loaded to S/4. ꞌThat way, you can shake off the whole burden of historical data from past years. This has a positive effect on the hardware sizing and licences,ꞌ Failer explains. Data Migration Servicesꞌ view is that there should be an amortization of investments in licences and hardware after three years, at most.
ꞌFaster amortization can be achieved through lower acquisition costs for licences and hardware, for instance. Users can do this by reducing the data volume, by right-sizing and by cutting the running costs for legacy systems, by applying the application retirement that was mentioned,ꞌ Tobias Eberle notes, summarising his experience from successful projects with clients. Of course, a comparison can be made with the costs of the SAP Cloud Platform – something each company must ultimately face when asking itself: on-premise or cloud? It is worth mentioning, when switching to the cloud model, that the question more in need of an answer is: which data volume is initially loaded?
General Data Protection Regulation (GDPR)
The S/4 roadmap is crucially shaped by the SAP customerꞌs data management; this also makes the forthcoming GDPR relevant. ꞌIn implementing the GDPR, we, as a specialist in historicization, focus on legacy systems,ꞌ Thomas Failer notes, summarising the scenario. Lots of customers run SAP systems but not yet ‘old’ SAP systems, to ensure compliance with the legal framework for data access. Tobias Eberle stresses that the new GDPR also involves deleting certain data upon demand.
ꞌOn legacy systems, this requirement is especially hard to fulfil, or even impossible,ꞌ he points out from experience. ꞌEither because the old systems do not support deletion or implementing it demands so much effort. That is why we at Data Migration Services recommend consistent historicization of all legacy systems, by using JiVS. This stores all data on one platform where it can be managed centrally. JiVS Retention Management now makes it possible to delete data in a selective, targeted way, thus meeting the GDPR’s requirements.ꞌ Up to now, only every second company in Germany has obtained help from external experts in implementing the GDPR. No more than 48 per cent of all firms with 20 or more staff state that they have brought in specialists from outside their firm, as a representative survey among more than 500 firms, on behalf of Bitkom, the digital-business trade association, shows.
External help with the GDPR
Most frequently it was external lawyers who were consulted regarding the GDPR, by roughly every third company (35 per cent). 29 per cent of all firms brought in external auditors, whereas external consultation on data protection took place in every fifth company (21 per cent). ꞌBy companiesꞌ own evaluation, only roughly every eighth company will have fully met the GDPR’s requirements by the deadline. Considering this low proportion and the size of possible fines involved, this rather low level of use of external help with implementation is quite surprising, ꞌ says Susanne Dehmel, Bitkom manager responsible for law and security. ꞌThe EU rulings affect practically all companies, because they apply to all firms that process personal data. For those that have not yet done anything, time is gradually running out.ꞌ
As of May 25, 2018, the time has come, and the two-year transitional period ends for implementation of the EU General Data Protection Regulation. A survey among DSAG members shows that only little more than a half of the firms surveyed have developed an approach (a roadmap) for implementing the GDPR in their firm.
Only Live Data for S/4
When I comes to data management, how does the SAP community see the situation? Thomas Failer: ꞌWe think that the survey’s results are truly representative of the situation. It will be hard to comply with the Regulationꞌs rulings if the companies do not end the wild growth in their application landscape and centralize their data retention. Putting both issues together means centralization both on the level of systems and of information. Only live data are to be taken over into the new central application platform; the remainder belongs in the data platform. Thinking in platforms like this is the precondition for changing the situation fundamentally. This way, users can harmonize the necessary modernization and the enhanced compliance requirements. Even if, at first glance, the new regulation seems to be a new and heavy burden imposed by the state, it can ultimately prove to be helpful in speeding up innovation in SAP customersꞌ IT landscape.ꞌ
Saving and deleting
What significance does the data deletion (referred-to above) have in general, and specifically regarding the GDPR? In the E-3 discussion Thomas Failer describes it as follows: ꞌThe ability not only to store and retain information safely but also to delete it safely, is decisive for master data management worthy of that name.ꞌ He adds: ꞌConsistently high quality in master data is ensured only by users who can purge the duplicated data sets they hold, often with small deviations from one another, and delete redundant data sets or those with errors.ꞌ
Likewise, CEO Tobias Eberle stresses that there are more and more requirements that explicitly demand this ability to delete. ꞌFor instance, for some time now job applications made to companies may no longer be retained indefinitely. Instead, they must be deleted irrevocably after several years. The new EU General Data Protection Regulation is introducing a decisive change here. From now, companies must be able to identify and delete each personal-data set. And do this not only when retention deadlines set by law are reached (though these must of course continue to be kept). Rather the new regulation means that a company must remove data if it can no longer prove a legitimate purpose for retaining it. This flexibility, enabling individual data-sets to be recognized and deleted at the press of a button, is best offered by a central data-management platform. This uses built-in functionalities for retention management, including a deleting function,ꞌ Eberle pointed out, summarizing the future’s scenario.
Continue reading by clicking on the arrow on the right side of the screen.
Add Comment