The S/4 bridge
To build the bridge between ECC 6.0 and S/4 Hana, it is first necessary to look at the system characteristics and the possible conversion paths.
There are currently two very different versions of ECC: ECC with Any DB and ECC on Hana (SoH). The difference between the variants lies in the underlying database.
SAP sees ECC on Hana as the first step in the conversion to S/4. From the point of view of archiving and especially the management of original documents, both variants are identical. Both versions make the familiar ArchiveLink and BC-ILM interfaces available without restriction.
A change from ECC with any database to ECC on Hana is not critical in this area and does not require any adjustments to be made to the project. From the archive provider's point of view, this step is transparent, as KGS' experience also shows.
Another important aspect is that the familiar interfaces such as BAPI, BADI, OLE and above all RFC are still available. Thus, the supplementary products around the archive functionalities also function without restriction.
Especially the widely used functions such as barcode processing and also early archiving with SAP workflow thus function as usual without any adaptation effort.
It should be noted, however, that with the use of the Hana database, the issue of "housekeeping" by means of data archiving, i.e., the reduction of active data in the database, becomes more important.
From ECC on Hana to S/4
S/4 comes in two very different flavors, namely on-premise and S/4 in the cloud. These variants differ in the components and, of course, also in the place of execution.
With S/4 - regardless of the variant - the data model changes in large parts. If you want to exploit performance advantages under S/4, you cannot avoid adapting the coding of your own enhancements, such as function modules, to the new data model and, at least in the medium term, moving away from Abap.
In addition to the new data model, the use of ERP functions will also be fundamentally changed. Whereas today's ECC is a powerful, almost monolithic server application that can be individually extended via transactions, modules and functions, S/4 is a service-oriented architecture.
User-side enhancements are thus implemented and made available as services or as separate Fiori applications. This also has an impact on the SAP transport system, which is also changing fundamentally with regard to the new technologies.
In the future, in addition to the possibility of providing applications via the Hana interface, there will be a GIT (distributed version control system); this will be part of the Web IDE in the future.
For developers who have previously avoided SAP, this offers an attractive platform that our developers find well thought-out and attractive. It must be mentioned, however, that the changes described refer only to the native S/4 part.
The NetWeaver stack with Abap will remain in place until at least 2025 and can continue to be used as usual. However, this means that the advantages of Hana can only be used to a limited extent.
In addition to the innovations on the backend side, the interface to the user is also changing. Currently, the familiar SAP GUI can continue to be used (at least as long as the NetWeaver stack is available, i.e. at least until 2025), but the goal is to switch to the new technologies based on SAP UI5 and Fiori.
For the first time, the new interfaces enable a consistent function/process-related view of the ERP system, completely eliminating the transactional view.
This transformation requires a change in thinking, as each user is only presented with the applications required for his or her particular work environment. The applications are structured thematically.
The personal applications are launched via an easy-to-use and clear tile interface in the browser. The Fiori applications available to date, unlike the classic GUI, do not offer simple integration for original documents. New solutions are needed here.
As always with new technologies, "research" is needed here to find a good way of integrating original documents into process applications.
DMS in S/4 with Fiori
To this end, KGS has a team of developers working to create an easy-to-use document management system in S/4 with Fiori. The results of this will be shown at this year's DSAG annual conference.
Integration into existing applications is achieved by providing services to be included, which then branch out into their own Fiori application. The function-based view of Fiori makes it possible for the first time to make real document management similar to an ECM (Enterprise Content Management System) available in SAP.
In our view, this leads to a further focus on the core system, since all tasks can be performed here. Redundant data storage as well as a redundant authorization system are also no longer necessary if ECM-typical business processes are to be supported.
Document and data archiving is also affected by all the changes. The good news first: The basic interface SAP-ArchiveLink also exists in the S/4 world, at least in combination with the NetWeaver stack, and according to current knowledge it will continue to exist.
The same applies to the SAP BC ILM solution, which is based on a specialized Web DAV implementation: it will also continue to be offered.
In addition to the familiar interfaces, there are also new features: S/4 offers a "Service Name Document Service" with a complete CMIS interface (Content Management Interoperability Services) for storing and retrieving archive objects, an archive store for any archive objects called Document Repository, and a specialized storage area for mobile data called "Mobile Storage" with an integrated PDF reader for displaying mobile documents in the browser.
Especially with the support of the open CMIS standard, SAP is clearly moving in the direction of an ECM system. This is because, in addition to the actual storage and retrieval of archive objects, additional metadata for archive objects can now be transferred to the SAP context and managed for the first time.
A dedicated, complex external ECM system is therefore no longer necessary in many cases with S/4. However, a lean and legally secure external archive remains indispensable.
Fiori app from KGS
The new applications under Fiori cannot inherently handle original documents that have already been stored in an electronic archive for some time. The "services to the object" known for this purpose from ECC are not available in the previous Fiori applications.
There is a need for action here and KGS fills this gap. How can the transition from SAP ECC to S/4 be completed with regard to document archiving?
From KGS' point of view, the topic of document archiving is redefined with S/4, because S/4 offers essential functions for managing unstructured content. This is good for customers who are planning to implement S/4 for the first time and have not operated SAP before.
On the other hand, there are the existing SAP customers who have already filled digital archives in their SAP history. These existing customers need to take different approaches.
On the one hand, it is possible to retain the existing archive integration and continue to use it under S/4. This provides peace of mind in the area of document storage for the time being, but does not protect against a later migration to the new interfaces and integrations.
On the other hand, the big bang approach can also be chosen, in which all archives are already migrated to the new standard with the transition to S/4. This approach involves many risks, since it is not yet clear today whether all old archive scenarios can be easily converted from the outset.
That leaves a third way: the hybrid approach. This means that during the transition from ECC on Hana to S/4, the existing archive is retained unchanged. All new archive requirements are connected via the current S/4 technologies, if this is already possible at this point.
This path offers the advantage that experience with the new interfaces and archives can be gained right from the start, but not all processes have to be adapted. The old archives are then gradually dissolved and transferred to the new world. This also offers the possibility of cleanup.
Hybrid archive strategy
KGS is currently clearly pursuing the hybrid strategy, since in our view an ad hoc conversion of archives is not easily possible and always requires significant project planning. The hybrid path can also be technically supported and secured with special tools such as an archive proxy server.
In addition, the migration of ArchiveLink-based archives to CMIS is possible in an automated manner with corresponding software products. The essential question that must always be answered in advance of a migration project to S/4 is:
Does the old archive structure fit the new way of working? Only those who deal with this question in a meaningful way will be able to satisfy the users following the migration. In contrast to the archive migration in ECC 6.0, where only one provider is exchanged for another, this is about process issues that must be taken into account in the S/4 implementation project in order to be able to work successfully with the archive later on.
The changeover to S/4 also requires adjustments in the area of "storage and archiving of original documents". The new interfaces and services allow S/4 to provide a holistic view of all structured and unstructured data in a company using a corresponding Fiori app.
When using the hybrid approach pursued by KGS, the transition to S/4 can be made simply and elegantly, as the existing archives remain usable. S/4 claims to be a comprehensive information and control platform for a company. This can be achieved with the consistent integration of unstructured content into the system.