This series is available as PDF download at the bottom of the page.
Should you go around the mountain, never look back, and start over on a green field? Or should you mine the parts you want and take them with you? And how do you make sure that the mountain doesn’t just collapse in on itself, making its precious ores and other contents unobtainable?
SAP customers know: the migration to S/4 and subsequent digitalization projects can only realize their full potential if the new software generation only operates with the most recent data and documents necessary in day-to-day operations. However, SAP customers often do not know how they can rid themselves of the mountain of legacy data and documents.
Housekeeping
The right approach to this problem would be to manage legacy information independently of systems. Data Migration Services has a solution to this problem which does just that: JiVS, a platform for information management. JiVS allows for the management of data and documents including their business contexts which are not necessary in day-to-day operations throughout their entire lifecycle, ranging from their transfer from operational systems all the way to legal retention and their eventual deletion.
More than 1,000 JiVS implementations worldwide have shown us that this concept of an information management platform independent of the underlying system works. The operational costs for the JiVS platform are usually much more efficient, and up to 80 percent less than those of the continued operation of legacy systems. The information is not changed in any way when transferred from legacy systems, making it tamper-proof. Auditors will recognize its authenticity, and therefore the legal compliance regarding financial authorities is guaranteed.
What is more, JiVS is a Java-based platform, making it independent of the systems it operates on. Consequently, there is no trouble concerning hardware – something especially legacy systems often deal with. As a living – meaning ever-changing – system, JiVS allows for regular security updates and checks, practically eradicating the risk cyber attacks and espionage pose in the long-term. Once the information including corresponding business context is transferred to JiVS, the legacy systems can be completely shut down and decommissioned.
This finishes up housekeeping, or so to speak. The most important thing about these basic preparations leading up to the migration to S/4 is that the historicized information is always accessible. This way, companies can migrate only the part of the data volume that they really need in day-to-day operations, for example open orders.
The experience of previous JiVS projects shows: that the data volume that has to be migrated can be reduced by 50 to 80 percent is not only possible, but also realistic! Even though customers have to invest some time for the analysis of the data and the selection of the information that has to be migrated, the overall effort of migration is actually reduced by up to 50 percent, sometimes even more.
However, whoever is historicizing and migrating is already right in the middle of a project, meaning that everything has been planned, budgeted, analyzed, and decided. Before this execution phase can happen, however, there are still two steps to be taken in a S/4 project: Identify and Design. JiVS can handle them as well.
Identify
Before SAP customers can reduce data volumes that have to be migrated, they have to first evaluate which data they need in S/4 Hana and which they don’t. For this purpose, JiVS offers an analytics tool with numerous different possibilities for parameterization.
For example, the information stored in the legacy systems allows for the selection of orders which are older than six months and therefore usually already completed, or business units or subsidiaries which do not exist anymore. Of course, the analytics tool is subject to adaptation and improvement through more and more specific filter criteria.
This analysis of potential is not 100 percent accurate – but meticulous accuracy is not the primary focus of the Identity phase. The focus of this step is instead to give customers a solid foundation on which they can base their decision of whether or not to use JiVS for the migration to S/4 and Hana on.
Because of the vast number of already successfully completed SAP projects, JiVS is familiar with the data structures of different SAP releases, ranging from R/3 in the version 3.0 all the way to SAP ERP/ECC 6.0. The criteria for selection and filtering therefore do not have to be developed, but rather merely configured.
Design
If the customer has made their decision, the next step is Design, the finetuning of data selection and migration. This step is not happening in the legacy environment anymore, but already on the JiVS platform. For this to happen, 100 percent of the existing information is transferred to the platform. The selection or filter criteria we defined in step one are finetuned and tested again. This allows for the automated selection and filtering through software.
The Design phase has even more benefits, however. Customers can reconsider if the number of business objects in S/4 could maybe be reduced massively by changing processes or returning to the SAP standard – from the maximum of 180 to perhaps a mere 40 or 50. Furthermore, this step is the ideal opportunity in the course of the migration project to optimize the data quality.
Over the years, erroneous, redundant, and incomplete data sets accumulate in legacy systems, making Master Data Management acutely necessary, but also very complex to do in the legacy systems themselves. Before migrating to S/4 Hana, these data sets can be cleaned up, gotten rid of, or be enriched by information from other sources, like address directories, on the JiVS platform. This is necessary because companies who want to successfully tackle digitalization need high data quality. Not to mention that highly automated processes based on erroneous data sets are a contradiction and lead to wrong or inadequate decisions as well as missed sales opportunities.
Transform
After completing step two, JiVS will provide customers with exact, precise, and evaluated filter criteria as XML file. Therefore, customers are free to choose if they want to use the JiVS tool for extraction, transformation, and (down-)loading (ETL) for selected data in S/4 Hana, or if they’d rather use solutions from third parties, for example SAP’s own conversion tool. To keep customers’ options open, JiVS can provide third-party conversion tool providers with the complete data set in XML format.
If the conversion of data to the new S/4 Hana data structures happens through JiVS ETL, the data can be automatically integrated into the new environment using SAP’s migration cockpit. Regardless of whether or not SAP customers return to the SAP standard in the course of their migration, downtimes should then not be longer than a typical weekend – even if working with huge SAP landscapes.
Operate
After the migration is over, when S/4 has already been booted up successfully and legacy systems have been decommissioned, one question arises: which role does JiVS play in day-to-day operations, or in our fourth step, Operate? Because the platform can only realize its full potential when it is used for more than just accessing data, when it is treated like something other than an archive.
Many problems usually typical for SAP environments can be avoided in the new world of S/4 Hana with JiVS right from the start. This includes the continuously increasing resource requirements. Data and documents that are not necessary in daily operations anymore can be regularly historicized using JiVS. S/4 remains lean and agile, which reduces operational costs in the long-term.
Furthermore, the information on the JiVS platform is not only valuable because of legal, but also of economic reasons. It is correct that the number of times non-operational information is accessed is limited, but this only answers the question of frequency, not of value. Quite on the contrary, actually: if industries have longer runtimes for orders and projects, users have to access older information more frequently.
Furthermore, companies only gain a holistic view of their customers if they know which information has already been stored on their servers. But they don’t want to switch between different environments; this is now frowned upon in the cloud era.
This is precisely the reason why Data Migration Services also focuses on integration, so that JiVS does not merely play the role of an archive that users only access when they absolutely have to. Regardless of the interface – whether it is SAP Fiori, S/4, or C/4 – the SAP users should be able to access information. Furthermore, they should also be able to navigate without ever leaving the SAP interface. This is not only beneficial for the users’ productivity, but also their satisfaction with JiVS.
Besides these frontend integrations, Data Migration Services also focuses on important integrations in the backend. That’s because data structures will still change constantly in S/4 or C/4. For the data transfer to S/4 or C/4 from less structured non-SAP systems to happen automatically, the mapping rules in JiVS have to be dynamically adapted. For this to happen, the changes of the data structures per interfaces have to automatically transferred to the platform.
What is more, JiVS works perfectly well with various cloud and big data strategies of SAP customers. That’s because the platform can be implemented in the data center of companies as well as on all relevant, major cloud platforms like Amazon Web Services, Google Cloud Platform, or Microsoft Azure. The information stored on the JiVS can also always be incorporated into big data scenarios. For this purpose, they can be accessed directly through the application layer of the platform, or can also be exported as proper data set and then processed in big data systems – giving customers freedom of choice.
JiVS editions S/4 and C/4
Existing tools and new developments planned for 2019 will be combined to special JiVS editions: to the S/4 edition for ERP migration and to the C/4 edition for CRM migration. Both editions are optimized through AI algorithms and are supposed to hit the market in fall 2019. Data Migration Services will showcase demo versions of both editions first at SAP NOW, 3rd and 4th of April in Basel, Switzerland, and then at Sapphire, 7th to 9th of May in Orlando, Florida.
Add Comment