Standardized SAP Individuality

IT pioneer Thomas Failer and his company Data Migration International have broken new ground in data management for the SAP community. With his data management tool, S/4 conversion is possible without preliminary projects.

E3: Many existing SAP customers welcome SAP's standardization with the theme "Keep the Core Clean" and still do not want to do without in-house developments or industry solutions.

Thomas Failer, DMI: And they don't have to. Our JiVS platform not only supports the standard, but also individual adaptations or in-house developments. Accordingly, we are also working on facilitating and accelerating the transition from previous industry solutions to S/4 while retaining industry-specific functionality. I am thinking here, for example, of solutions in the healthcare sector or for other industries and subject areas. There are special data and data structures there. And since the migration of data on our platform always takes place via the application layer, we have to provide suitable business objects for this. We have already implemented these business objects in the real estate sector and have customers using them. And I assume that we will be able to present further such industry- and topic-specific business objects in our offering in summer 2024. Again, it's all about automation and efficiency.

E3: Keyword application layer - this clearly sets you apart in the market. What advantage does this difference offer?

Failer: The key advantage for existing SAP customers is that we can support SAP's standard migration tools, such as the Migration Cockpit, without any restrictions. This means that companies can be sure that the migrated and transformed data is correct and complete. This means that they can select which data they want to transfer to the S/4 world and at the same time avoid the risks of data transformation that can arise from writing directly to the tables. Previously, existing SAP customers who did not want to take any risks had to choose a brownfield approach and convert all data and business objects. With our approach, on the other hand, basically every transformation becomes a greenfield project.

E3: You need to explain that in more detail.

Failer: Our platform is not designed to migrate and transform data directly from the source and target systems. That would only be a one-off process and would run counter to our claim of managing the entire lifecycle of data. So we divide the migration into several steps. First of all, we extract all legacy data from the legacy systems and store it on our platform in an audit-proof manner. This allows customers to implement S/4 as an empty shell and adapt it to their needs at business object level. As a rule, perhaps half of the existing business objects, including those developed in-house, still have a meaningful use in the S/4 world. So why burden yourself with this? After all, many former plants, locations or company codes no longer exist. The introduction of S/4 offers the opportunity to cut away old habits and concentrate on innovation instead of dealing with legacy issues. At the same time and detached from the application level, customers can prepare the data migration and transformation on our platform.

E3: What does this preparation look like?

Failer: The most important step is selecting the data. How much of the legacy data do I really need? As a rule, only a very small part, perhaps 5 percent of the transaction data and 20 percent of the master data; more is not relevant for S/4. The legacy data can also be cleansed and corrected. Some customers or suppliers are managed five times in the old system due to spelling mistakes or different addresses. That is nonsense.

E3: So it's all about efficiency?

Failer: The business benefit of a new software generation such as S/4 is at its highest when it is launched with clean and correct data. All the more so if the data is perhaps even enriched from peripheral systems, i.e. is more meaningful when it is transferred to the new world. Only with carefully refined data will the digital engine run like clockwork! Raw and contaminated oil, on the other hand, cause engine damage. With our platform, it is possible to fill an optimally prepared S/4 system with optimally prepared data. This makes it easier to achieve the goal of a data-driven company. Regardless of how heterogeneous the existing system and application landscape is and what data volumes are available, existing SAP customers can start their S/4 future on a greenfield site with our approach and the JiVS IMP platform.

E3: Many existing SAP customers take a different approach and groan under the burden of projects even before the actual migration and transformation. One example of this is extensive archiving.

Failer: You are indeed addressing a very important point and the example is excellent. Of course, companies want to transform as little data as possible to S/4 and therefore try to archive as much of the old data as possible. However, this causes two major problems. On the one hand, IT is arguing with the specialist departments about which legacy data remains directly accessible and therefore needs to be migrated. And secondly, they must continue to operate the legacy systems in order to be able to call up the archived data when required. This keeps the system landscape complex and consumes time and resources for the legacy world. What's more, this legacy world is not sustainable because it cannot be operated securely in the long term. Legacy systems are no longer maintained, security patches are no longer available and cyber criminals or cyber spies have an easy time of it.

E3: So what happens to the legacy systems?

Failer: With the help of JiVS IMP, on the other hand, companies can decommission all legacy systems, usually saving 80 percent or more of operating costs. Incidentally, this also applies to existing ADK archives, as our platform transfers the data they contain directly via the application layer. And thanks to our turbo ex-tractor, this doesn't take weeks or even months, but hours or days.

E3: Are there any other preliminary projects that existing SAP customers can do without?

Failer: The simple answer is: you can basically dispense with all preliminary projects. It is understandable that companies want to bring forward projects such as the introduction of the Hana database, the Business Partner business object or the New General Ledger for purely technical reasons, thereby streamlining the transformation project, so to speak. But this is neither necessary nor sensible. IT projects should always be geared towards business benefits. Implementing S/4 and Hana using JiVS IMP with only the business objects and data that are really needed reduces complexity and massively reduces the transformation effort. This also applies to the introduction of the new general ledger or the business partner business object.

E3: How much time and effort does your approach save if preliminary projects are dispensed with?

Failer: This is indeed enormous. With our approach, the transformation effort can usually be reduced by more than
50 percent. And with the help of AI, we have set ourselves the goal of halving the time required once again. For example, by increasing the automation of data cleansing or mapping.

E3: Thank you for the interview.

jivs.com