In five steps to S/4: Housekeep, Identify, Design, Transform, Operate
Should it be bypassed, left behind and started anew on a greenfield site? Or should only parts be removed and carried along? And with all these alternatives, how do you ensure that the mountain does not collapse during the work and remains accessible?
SAP's existing customers know: Migration to S/4 and digitization projects based on it succeed best when they start the new software generation with only the most current data and documents needed in day-to-day business. But they don't know exactly how to free themselves from the burden of legacy data and documents.
Housekeep
Managing legacy information system-independently: With JiVS, a platform for information management, Swiss Data Migration Services has the solution to this problem on offer.
JiVS allows the management of data and documents that are no longer required for operations, including their business logic, throughout their entire lifecycle: from their transfer from the production systems to legally compliant storage and final deletion.
Over 1,000 JiVS implementations worldwide have shown that this concept works. The costs for operating JiVS are usually 80 percent lower than the expenses for continuing to operate the legacy systems.
The fact that the information is transferred unchanged from the legacy systems and stored in an audit-proof manner is recognized by the auditors, so that legal certainty vis-à-vis the tax authorities is guaranteed.
What's more, as a Java-based platform, JiVS is independent of the systems on which it runs. Consequently, there is no spare parts problem with the hardware, as can certainly happen with legacy systems.
As a living system, JiVS also allows regular security updates, so that the risk of cyber attacks and espionage is contained in the long term. Once the information, including the underlying business logic, has been transferred from the legacy systems to JiVS, they can be completely switched off and disposed of.
This takes care of the housekeeping, so to speak. However, the most important aspect of this basic preparatory work for the changeover to S/4 Hana is that the historized information always remains accessible.
This allows companies to migrate only that part of the data to S/4 that they actually still need in their day-to-day business, for example, open orders.
Experience from previous JiVS projects has shown that reductions in the volume of data to be migrated of between 50 percent and 80 percent are not only possible, but also realistic!
Despite the extra effort required to analyze the data inventory and select the information to be migrated, the migration effort usually drops by 50 percent, and sometimes even more.
But if you have already reached the point of historization and migration, you are already in the middle of the project, i.e. when everything has already been planned, budgeted, analyzed and decided.
Before this implementation phase, however, there are two more phases in a migration project to S/4 Hana: Identify and Design. These can also be covered with JiVS.
Identify
Before they can reduce the volume of data to be migrated, existing SAP customers must first determine whether and which data they need in S/4 and which they do not. For this purpose, JiVS offers an analysis tool with a wide range of parameterization options.
For example, the information stored in the legacy system can be selected according to orders that are older than six months and have therefore usually already been completed, or according to company codes and plants that no longer exist. Of course, this analysis can be iteratively refined by further and ever more stringent selection criteria.
Even if the accuracy of the potential analysis is not 100 percent and this value is not even aimed for in the Identify phase, customers receive a very good basis for deciding whether and to what extent the switch to S/4 and Hana is worthwhile with the help of JiVS.
Thanks to the large number of successfully completed SAP projects, JiVS is familiar with the data structures of a wide range of SAP releases, from R/3 version 3.0 right up to SAP ERP/ECC 6.0. This means that the selection criteria no longer have to be developed, but only configured.
Design
Once the decision has been made, the next step is the design phase, i.e. the detailed planning of the data selection and migration. This no longer takes place in the old environment, but already on JiVS. For this purpose, 100 percent of the existing information is transferred to the platform.
The selection criteria from phase one are then refined and tested once again so that the cut can be automated in the dataset by software.
But the design phase also offers other advantages: It not only allows decisions to be made about whether the number of business objects in S/4 cannot be massively reduced by process changes or a return to the SAP standard - from the 180 maximum possible to perhaps 40 or 50.
In addition, this is the ideal project stage for optimizing data quality. Over the years, incorrect, redundant and incomplete data records accumulate in the legacy systems. These can now be cleaned up, eliminated and supplemented by means of third-party sources such as external address directories before the transfer to S/4.
After all, digitization requires high data quality. After all, highly automated processes based on faulty data records are a contradiction in terms and lead to incorrect or inadequate decisions as well as missed sales opportunities.
Transform
At the completion of phase two, JiVS provides accurate and tested filter rules as an XML list. This gives customers the choice of using JiVS' own tool for extraction, transformation, and loading (ETL) of the selected data into S/4 Hana or third-party solutions, including SAP's conversion tool.
Alternatively, JiVS can transfer the complete data package in XML format to third-party ETL or transformation tools. If the data is converted to the new S/4 Hana data structures using JiVS ETL, it can be automatically imported directly into the new environment via the SAP Migration Cockpit.
Regardless of whether existing SAP customers revert to the SAP standard during migration or not, downtime should no longer exceed the duration of a weekend, even for very large SAP environments.
Operate
Once the migration has taken place, S/4 has been successfully launched and the legacy systems have been switched off, the question arises as to what role JiVS should play in the operating phase (Operate).
This is because the platform unfolds its full potential precisely when the information stored there is not only accessed occasionally. In fact, many problems typical of existing SAP environments can be avoided in the S/4 Hana world right from the start by means of JiVS.
This includes, for example, the continuously increasing demand for resources. For example, data and documents that are no longer needed in day-to-day business after a certain point can be regularly historized using JiVS. As a result, S/4 remains permanently lean, which reduces operating costs over time.
Beyond that, however, the information in JiVS remains of high value not only for legal but also for business reasons. While the number of accesses to non-operational information is lower than for operational information, this is only a question of frequency, not of usefulness - on the contrary:
The longer the duration of orders and projects in an industry, the more regularly business users need to access information from further back in time. In addition, they can only obtain an all-round view of a customer or project if they know what information exists about it as a whole.
To this end, however, they do not want to switch back and forth between different environments; after all, media breaks are taboo in the cloud age.
For this reason, Data Migration Services is increasingly working on integrations so that, from the point of view of business users, JiVS does not just assume the role of an archive that is only accessed when absolutely necessary.
Regardless of the interface, whether SAP Fiori, S/4 or C/4, SAP users should be able to see the information that belongs to a business case. In addition, they should be able to navigate directly to this content from the respective SAP interface and also open it.
This not only increases productivity, but also user satisfaction when working with JiVS.
In addition to these front-end integrations, other back-end integrations play an important role for Data Migration Services. This is because data structures will continue to change again and again, even with S/4 or C/4.
To ensure that the transfer of data to S/4 or C/4, for example, from less structured non-SAP systems is automated, the mapping rules in JiVS need to be adapted dynamically.
To do this, the changes to the data structures must be automatically transferred to the Swiss manufacturer's platform via an interface.
What's more, JiVS is a perfect fit for the cloud and big data strategies of SAP's existing customers. The platform can be implemented both in the company's data centers and on all common cloud platforms such as Amazon Web Services, Google Cloud Platform or Microsoft Azure.
In addition, the information stored in JiVS is available for Big Data scenarios at any time. It can be accessed directly via the platform's application layer, but can also be exported as a separate data set and then processed in the Big Data systems.
JiVS Editions S/4 and C/4
The existing tools and new developments planned for 2019 will be bundled in two special JiVS editions, once in the S/4 edition for ERP and once in the C/4 edition for CRM migration.
Both editions will be optimized using AI algorithms and are expected to be ready for the market by fall 2019. Data Migration Services will showcase the first demo versions of both editions first at SAP Now on April 3 and 4 in Basel and then at Sapphire from May 7 to 9 in Orlando, Florida.
