Le pont S/4

Pour jeter un pont entre ECC 6.0 et S/4 Hana, il faut d'abord considérer les caractéristiques du système et les chemins de conversion possibles.

Actuellement, ECC existe sous deux formes très différentes, d'une part comme ECC avec Any DB et comme ECC on Hana (SoH). La différence entre ces variantes réside dans la base de données sur laquelle elles reposent.

SAP considère ECC on Hana comme la première étape de la transition vers S/4. Du point de vue de l'archivage et plus particulièrement de la gestion des documents originaux, les deux variantes sont identiques. Les deux versions mettent à disposition sans restriction les interfaces connues ArchiveLink et BC-ILM.

Dans ce domaine, le passage d'ECC avec n'importe quelle base de données à ECC on Hana n'est pas critique et ne nécessite aucune adaptation à projeter. Du point de vue du fournisseur d'archives, cette étape est transparente, c'est aussi ce que montrent les expériences de KGS.

Un autre aspect important est que les interfaces connues comme BAPI, BADI, OLE et surtout RFC sont toujours disponibles. Ainsi, les produits complémentaires autour des fonctionnalités d'archivage fonctionnent également sans restriction.

Les fonctions les plus répandues, comme le traitement des codes-barres et l'archivage précoce avec SAP Workflow, fonctionnent ainsi comme d'habitude sans nécessiter d'adaptation.

Il convient toutefois de noter qu'avec l'utilisation de la base de données Hana, le thème du "housekeeping" au moyen de l'archivage des données, c'est-à-dire la réduction des données actives dans la base de données, gagne en importance.

De ECC on Hana à S/4

S/4 existe sous deux formes très différentes, à savoir on-premise et S/4 dans le cloud. Ces variantes se distinguent par leurs composants et, bien entendu, par leur lieu d'exécution.

Avec S/4 - quelle que soit la variante - le modèle de données change en grande partie. Celui qui veut exploiter les avantages de performance sous S/4 ne peut pas éviter d'adapter le codage de ses propres extensions, comme par exemple les modules fonctionnels, au nouveau modèle de données et de se détacher d'Abap, du moins à moyen terme.

Outre le nouveau modèle de données, l'utilisation des fonctions ERP est également fondamentalement modifiée. Si l'ECC actuel est une application serveur puissante, presque monolithique, qui peut être étendue individuellement par le biais de transactions, de modules et de fonctions, avec S/4, on a affaire à une architecture orientée services.

Les extensions côté utilisateur sont donc implémentées et mises à disposition sous forme de services ou d'applications Fiori propres. Cela a également un impact sur le système de transport SAP, qui change également radicalement en fonction des nouvelles techniques.

A l'avenir, outre la possibilité de mettre à disposition des applications via l'interface Hana, il y aura un GIT (distributed version control system - système de contrôle de version distribué) ; celui-ci fera partie intégrante de l'EDI Web à l'avenir.

Les développeurs qui évitaient SAP jusqu'à présent disposent ainsi d'une plateforme attrayante, que nos développeurs jugent bien pensée et attrayante. Il faut toutefois préciser que les changements décrits ne concernent que la partie native de S/4.

La pile NetWeaver avec Abap sera maintenue au moins jusqu'en 2025 et pourra continuer à être utilisée, comme d'habitude. Cela ne permet toutefois de profiter des avantages de Hana que de manière limitée.

Outre les nouveautés du côté du backend, l'interface avec l'utilisateur change également. Actuellement, il est certes possible de continuer à utiliser la SAP GUI connue (du moins tant que la pile NetWeaver est présente, c'est-à-dire au moins jusqu'en 2025), mais l'objectif est de passer aux nouvelles technologies basées sur SAP UI5 et Fiori.

Les nouvelles interfaces permettent pour la première fois d'avoir une vue fonctionnelle/processus de bout en bout du système ERP, la vue transactionnelle étant totalement supprimée.

Cette transformation nécessite un changement de mentalité, car chaque utilisateur ne se voit présenter que les applications dont il a besoin pour son environnement de travail. Les applications sont ainsi classées par thèmes.

Les applications personnelles sont lancées via une interface en tuiles facile à utiliser et claire dans le navigateur. Contrairement à l'interface graphique classique, les applications Fiori disponibles jusqu'à présent n'offrent pas d'intégration simple pour les documents originaux. De nouvelles solutions sont donc nécessaires.

Comme toujours avec les nouvelles technologies, un "travail de recherche" est ici nécessaire pour trouver une bonne manière d'intégrer les documents originaux dans les applications de processus.

DMS dans S/4 avec Fiori

Pour ce faire, KGS a mis en place une équipe de développeurs qui crée une gestion de documents facile à utiliser dans S/4 avec Fiori. Les résultats seront présentés lors de la conférence annuelle DSAG de cette année.

L'intégration dans les applications existantes se fait par la mise à disposition de services à intégrer, qui se ramifient ensuite en une application Fiori propre. Grâce à la vue fonctionnelle de Fiori, il est pour la première fois possible de mettre à disposition une véritable gestion de documents similaire à un ECM (Enterprise Content Management System) dans SAP.

De notre point de vue, cela permet de se concentrer davantage sur le système central, car toutes les tâches peuvent y être effectuées. Une gestion redondante des données ainsi qu'un système d'autorisation redondant ne sont plus nécessaires, même si les processus commerciaux typiques de l'ECM doivent être pris en charge.

L'archivage des documents et des données est également concerné par tous ces changements. La bonne nouvelle pour commencer : l'interface de base SAP ArchiveLink existe aussi dans le monde S/4, du moins en combinaison avec la pile NetWeaver, et elle continuera d'exister selon les connaissances actuelles.

Il en va de même pour la solution SAP-BC-ILM basée sur une implémentation Web-DAV spécialisée : elle continuera elle aussi à être proposée.

Mais en plus des interfaces connues, il y a aussi des nouveautés : S/4 propose un "Service Name Document Service" avec une interface CMIS (Content Management Interoperability Services) complète pour le stockage et la recherche d'objets d'archives, un stockage d'archives pour n'importe quel objet d'archives appelé Document Repository et un espace de stockage spécialisé pour les données mobiles appelé "Mobile Storage" avec un lecteur PDF intégré pour afficher les documents mobiles dans le navigateur.

Avec le soutien du standard ouvert CMIS, SAP se dirige clairement vers un système ECM. En effet, outre le classement et la récupération d'objets d'archives, il est désormais possible pour la première fois de transférer et de gérer des métadonnées supplémentaires sur les objets d'archives dans le contexte SAP.

Un système ECM externe dédié et complexe n'est donc plus nécessaire dans de nombreux cas avec S/4. Une archive externe légère et juridiquement sûre reste toutefois indispensable.

Application Fiori de KGS

Les nouvelles applications sous Fiori ne peuvent pas traiter de manière native les documents originaux qui sont déjà conservés depuis un certain temps dans des archives électroniques. Les "services à l'objet" connus à cet effet, tels qu'on les connaît de l'ECC, ne sont pas disponibles dans les applications Fiori actuelles.

Il est nécessaire d'agir et la PBC comble cette lacune. Comment passer de SAP ECC à S/4 en matière d'archivage de documents ?

Du point de vue de KGS, S/4 redéfinit le thème de l'archivage de documents, car S/4 offre des fonctions essentielles pour la gestion de contenus non structurés. C'est une bonne chose pour les clients qui prévoient d'introduire S/4 pour la première fois et qui n'utilisaient pas SAP auparavant.

De l'autre côté, il y a les clients SAP existants qui ont déjà rempli des archives numériques dans leur historique SAP. Ces clients existants doivent adopter d'autres approches.

D'une part, il est possible de conserver l'intégration d'archives existante et de continuer à l'utiliser sous S/4. Cela permet d'être tranquille dans le domaine de l'archivage des documents, mais ne protège pas d'une migration ultérieure vers les nouvelles interfaces et intégrations.

D'autre part, il est également possible d'opter pour une approche big bang, dans laquelle toutes les archives sont migrées vers la nouvelle norme dès le passage à S/4. Cette approche comporte de nombreux risques, car il n'est pas encore clair aujourd'hui si tous les anciens scénarios d'archivage peuvent être facilement convertis dès le début.

Il reste encore une troisième voie : l'approche hybride. Cela signifie que lors du passage d'ECC on Hana à S/4, les archives existantes sont conservées telles quelles. Toutes les nouvelles exigences en matière d'archivage sont connectées, si cela est déjà possible à ce moment-là, via les techniques actuelles de S/4.

Cette voie offre l'avantage de pouvoir acquérir dès le début de l'expérience avec les nouvelles interfaces et les nouveaux classements, mais ne nécessite pas l'adaptation de tous les processus. Les anciennes archives sont ensuite progressivement supprimées et transférées dans le nouveau monde. Ce faisant, il est également possible de procéder à un nettoyage.

Stratégie d'archivage hybride

Actuellement, KGS poursuit clairement la stratégie hybride, car nous estimons qu'une conversion ad hoc des archives n'est pas facile à réaliser et qu'elle nécessite toujours une étude de projet significative. Des outils spéciaux, tels qu'un serveur proxy d'archives, permettent de soutenir et de sécuriser la voie hybride sur le plan technique.

En outre, la migration des archives basées sur ArchiveLink vers CMIS est possible de manière automatisée avec les logiciels correspondants. La question essentielle à laquelle il faut toujours répondre en amont d'un projet de migration vers S/4 est la suivante

L'ancienne structure d'archivage est-elle adaptée à la nouvelle méthode de travail ? Seul celui qui traite cette question de manière judicieuse pourra satisfaire les utilisateurs à l'issue de la migration. Contrairement à la migration des archives dans ECC 6.0, où seul un fournisseur est remplacé par un autre, il s'agit ici de thèmes de processus qui doivent être pris en compte dans le projet d'introduction S/4 pour pouvoir travailler avec succès avec les archives par la suite.

Le passage à S/4 implique également des adaptations dans le domaine du "classement et de l'archivage des documents originaux". Les nouvelles interfaces et les nouveaux services permettent d'obtenir avec S/4 une vue globale de toutes les données structurées et non structurées d'une entreprise en utilisant une application Fiori correspondante.

En utilisant l'approche hybride adoptée par KGS, la transition vers S/4 peut se faire de manière simple et élégante, car les archives existantes restent utilisables. S/4 a l'ambition d'être une plate-forme d'information et de contrôle complète pour une entreprise. L'intégration systématique de contenus non structurés dans le système permet d'atteindre cet objectif.