Migration vers SAP S/4 Hana : quelle est la bonne approche ?

Les clients existants de SAP doivent migrer vers la nouvelle génération de logiciels S/4 Hana d'ici 2025. Ce n'est que jusqu'à cette date que SAP a donné une garantie de support pour ERP/ECC 6.0, la dernière fois lors du congrès annuel 2018 de DSAG. La plupart des clients existants de SAP associent la migration à l'objectif d'un environnement applicatif agile qui leur permettra de relever les défis de la numérisation.

Mais attention : ce qui est tout à fait correct en tant qu'objectif au niveau des applications ne peut pas être transposé tel quel au niveau des données. En effet, les données des applications d'entreprise se trouvent toujours dans un contexte commercial qui, pour des raisons juridiques, doit être conservé avec les données pendant la durée des délais de conservation prescrits par la loi. En outre, ce contexte commercial contient des informations supplémentaires importantes, par exemple sur l'historique et la qualité d'une relation commerciale avec un client ou un fournisseur, qui peuvent être précieuses pour l'entreprise concernée même des années plus tard.

Au niveau des données, il s'agit donc moins d'agilité que de stabilité. C'est la raison pour laquelle, à chaque migration vers de nouvelles générations de logiciels - au sein ou en dehors de SAP - de gros volumes de données s'accumulent dans les centres de données des entreprises, qui, en raison du contexte commercial, sont conservés et entretenus avec les anciennes applications - et ce, parfois pendant plusieurs décennies et à un coût considérable.

Lors du passage à S/4, le problème de l'exploitation des anciens systèmes se pose à nouveau et de manière encore plus aiguë. D'une part, le transfert de toutes les données et de tous les documents des systèmes existants vers la base de données Hana n'a aucun sens, ne serait-ce que pour des raisons de coûts.

Certes, les supports de stockage sont devenus globalement beaucoup moins chers, mais la mémoire principale et les ressources de calcul nécessitent toujours des investissements sensibles. D'autre part, la structure des données est massivement modifiée lors du passage à SAP Hana. Ainsi, pour les grandes installations, le nombre de tables passera de plus de cent mille à quinze mille ou vingt mille au maximum. Les entreprises s'exposent ainsi à d'énormes risques juridiques si elles ne trouvent pas de solution raisonnable pour leurs anciens systèmes et données.

Une question d'architecture

La question cruciale est donc la suivante : comment concilier les objectifs opposés d'agilité et de stabilité ? À l'aide d'une nouvelle approche : une architecture différente du paysage applicatif, qui sépare les données et documents anciens des applications agiles du futur. Les anciens systèmes peuvent ainsi être désactivés et les nouvelles générations de logiciels peuvent rester durablement légères et agiles.

L'élément clé de cette nouvelle architecture est un environnement propre, indépendant du système, pour les données, les documents et leur contexte commercial qui ne sont plus nécessaires dans les systèmes opérationnels.

Un tel environnement assure la stabilité requise au niveau des données. En même temps, il renforce la sécurité juridique et informatique. En effet, contrairement à de nombreux anciens systèmes, il est possible de continuer à appliquer des correctifs et à sécuriser les données. En outre, il permet de gérer sans faille l'ensemble du cycle de vie des données et des documents existants au niveau des enregistrements et des documents individuels grâce à des fonctionnalités de gestion de la rétention. Cela inclut expressément la suppression ciblée de données et de documents - l'une des principales exigences du règlement européen sur la protection des données (EU-DSGVO).

Une certification selon la norme IDW PS 880 de l'Institut des commissaires aux comptes garantit que les commissaires aux comptes et les services fiscaux ont eux aussi confiance dans cet environnement en ce qui concerne l'inaltérabilité des données et des documents repris des systèmes opérationnels ainsi que leur contexte commercial.

Économisez jusqu'à 80

Conséquence : les anciennes applications peuvent être désactivées, ce qui permet de réaliser des économies opérationnelles pouvant aller jusqu'à 80% - et parfois même plus - par rapport à la poursuite de leur exploitation. Mais ce qui est au moins aussi important dans le contexte de la migration imminente vers S/4 :

Si les données et documents commerciaux sont transférés dans cet environnement dès qu'ils ne sont plus nécessaires sur le plan opérationnel, les applications et systèmes actuels restent légers et agiles à long terme. En règle générale, le volume des données opérationnelles peut être réduit de 50 à 75 %. Tout poids inutile est ainsi évité.

Un simple calcul montre pourquoi cela est si important : environ 10 000 clients SAP existants ont leur siège dans l'espace germanophone. Même si l'on se base sur une valeur moyenne de 2000 jours-personnes par projet, il en résulterait un besoin en capacité de 20 millions de jours-personnes sur le marché DACH d'ici 2025, soit environ 3,2 millions par an.

Même si tous les experts en migration de données, dont le nombre est estimé à 2000, travaillaient 365 jours par an dans les pays germanophones, ils ne disposeraient que de capacités équivalentes à 730.000 hommes-jours par an.

En tenant compte des congés et autres temps morts, il faudrait cinq fois plus d'experts en migration qu'il n'y en a réellement pour réaliser les projets d'ici 2025. Selon Adam Riese, cela ne sera tout simplement pas possible.

Gagner du temps et devenir agile

Si les données et les contenus inutiles des applications opérationnelles sont transférés en continu sur une plateforme juridiquement sûre et indépendante du système, l'informatique de l'entreprise devient globalement beaucoup plus agile et peut prendre en charge les scénarios commerciaux les plus divers avec très peu d'efforts.

Exemple d'achat et de vente d'entreprises et de secteurs d'activité :

Il s'agit de décider quelles applications doivent être reprises par l'entreprise rachetée parce qu'elles présentent des avantages par rapport aux siennes, et lesquelles ne sont plus utilisées. La question de savoir quelles données et quels documents doivent être migrés vers les systèmes en direct est directement liée à cette décision. La poursuite de l'exploitation des anciens systèmes dans les entreprises est une raison essentielle pour laquelle, en règle générale, 80% du budget informatique total sont consacrés uniquement à l'exploitation.

A cela s'ajoutent les risques de conformité et de sécurité lorsque les systèmes repris ne peuvent plus être entretenus de manière fiable ou sécurisés au moyen de correctifs de sécurité réguliers. Et la mise à niveau, par exemple pour répondre aux exigences de suppression du RGPD, n'est techniquement plus possible pour de nombreux anciens systèmes ou n'est réalisable qu'au prix de très gros efforts.

Exemple : consolidation d'environnements applicatifs hétérogènes sur des systèmes centraux comme SAP :

La consolidation de l'environnement système SAP n'est pas un projet purement technique. Les entreprises y associent plutôt des objectifs stratégiques et de gestion : La centralisation doit permettre de réduire la complexité, de diminuer les frais de maintenance, d'administration et les coûts correspondants et d'accélérer les innovations.

Ainsi, la consolidation d'environnements SAP répartis dans le monde entier offre la possibilité d'implémenter plus rapidement les modifications et les développements et de les mettre à disposition globalement. Ces objectifs ne peuvent toutefois être atteints que si les anciens systèmes sont mis hors service.

Exemple de consolidation de centres de données répartis dans le monde entier :

Les projets de consolidation des centres de données commencent par un inventaire et une analyse complets de l'environnement des applications et des systèmes. Lesquels peuvent réellement être déplacés vers le site central sans modifications majeures ? Y a-t-il des réglementations et des lois locales qui interdisent le déménagement parce que les données associées à certaines transactions ou personnes, comme celles de la comptabilité financière ou des ressources humaines, ne peuvent pas franchir les frontières nationales ?

Toutes ces considérations mettent en péril l'objectif même de la consolidation, à savoir la centralisation, et risquent également de rendre le déménagement partiel très complexe et donc lourd et coûteux. En effet, de nombreux sites ne peuvent pas être fermés si aucune solution n'est trouvée pour les données et documents anciens.

Facteur qualité des données

Exemple de la qualité des données : un client, de nombreux enregistrements et, qui plus est, différents, de sorte que les entreprises partent du principe qu'il y a plusieurs clients au lieu d'un seul. En effet, elles ne peuvent pas établir de relation entre les ensembles de données lors des évaluations.

C'est la situation actuelle dans de nombreuses entreprises. Or, l'analyse détaillée des données est la condition sine qua non pour optimiser les processus numériques, les nouveaux produits et services numériques. Si l'on ne dispose pas d'un aperçu correct de l'historique d'achat d'un client, on ne pourra pas l'aborder avec les bonnes offres et le bon degré de personnalisation. En bref, la base des modèles commerciaux numériques fait défaut.

Avenir

Avant et après la migration vers S/4-Hana : les systèmes SAP se développent. Après peu de temps déjà, la capacité de stockage doit être étendue et les ressources de calcul augmentées afin que les demandes des utilisateurs professionnels contre le système ne se fassent pas au détriment de la performance. Pour les clients SAP existants, un nouveau défi vient s'ajouter. En effet, leurs systèmes existants ne fonctionnent généralement pas encore sur la nouvelle base de données Hana, mais sur l'un des systèmes SGBD relationnels courants. Mais à l'avenir, ils devront acheter des licences pour SAP Hana, qui dépendront en outre du volume !

Les clients SAP existants ont donc tout intérêt à réduire leurs stocks de données avant de migrer vers la base de données Hana. La solution aux défis posés par ces scénarios d'entreprise est de déclasser les systèmes informatiques qui ne sont plus nécessaires et de transférer les données et les documents qu'ils contiennent vers une plateforme moderne afin de pouvoir gérer le cycle de vie des anciennes informations et leur contexte commercial.

Si certaines données et certains documents ne doivent pas quitter les frontières nationales, ils peuvent être conservés et maintenus sur des instances locales de la plate-forme, tout en étant accessibles dans le monde entier. En outre, il est possible de vérifier la redondance, la cohérence et l'exactitude des données et de les corriger et de les enrichir sur la base de règles.

La plate-forme JiVS basée sur Java a été développée précisément pour ces scénarios d'application et d'affaires agiles. Elle se caractérise par sa capacité à conserver les données des anciens systèmes désactivés, mais aussi les documents correspondants dans leur contexte commercial, en toute sécurité juridique. JiVS est donc l'élément clé d'un environnement applicatif agile dans les entreprises : Voilà à quoi ressemble la bonne approche.