Facteurs de succès importants pour la transition et l'exploitation de S/4 Hana

Lors de la transition vers S/4 Hana, il y a beaucoup de choses à prendre en compte au préalable

Le passage à S/4 Hana doit être bien préparé, car il est parsemé de nombreux défis - en ce qui concerne l'architecture, le modèle d'exploitation, le support de la base SAP ou la méthode de passage et les exigences correspondantes de la base SAP, comme la surveillance SAP ainsi que la gestion du cycle de vie des applications (ALM) ou la sécurité SAP, pour n'en citer que quelques-uns. 

Le manque de personnel freine la transition vers S/4-Hana

Cela donne des sueurs froides aux DSI et aux responsables informatiques qui planifient une transition. Ils sont souvent confrontés à une situation tendue en matière de personnel au sein de leur organisation informatique et le recrutement de personnel informatique qualifié s'avère extrêmement difficile en raison du manque de personnes sur le marché du travail. Dans de nombreux cas, un changement de génération se prépare au sein de l'équipe SAP, ce qui entraîne une perte importante de savoir-faire SAP. Cette situation contribue souvent à retarder le passage à S/4 Hana. 

La préparation est un facteur de réussite essentiel

Pour que le passage à S/4 Hana se fasse en douceur, une préparation optimale avec une procédure clairement structurée est indispensable. Le plus important est d'obtenir une vue d'ensemble détaillée de tous les domaines de l'environnement SAP actuel, à savoir : Les versions de SAP, les extensions, les add-ons et les bases de données (SAP/Non SAP), mais aussi les interfaces RFC, les certificats SAP et surtout la charge du système. 

Intégrer les données de suivi SAP 

Un outil de monitoring SAP complet fournit à cet effet des données importantes en amont, indique les états d'erreur, surveille les IDocs, les jobs SAP (LongRunners), les logs système, les paramètres selon SAP Security Baseline, le cryptage, les autorisations et signale les problèmes de manière automatisée en temps réel, de sorte que l'exploitation de base SAP interne ou externe puisse les résoudre directement. Le monitoring devient donc une discipline importante. Le paysage SAP et l'infrastructure doivent être surveillés sans faille, non pas en silos, mais de manière centralisée dans une solution unique. C'est là qu'intervient une solution de surveillance SAP comme Scansor (www.scansor.com ; module complémentaire SAP pour PRTG de itesys AG, professionnel de la base SAP). 

Elle montre le statu quo en temps réel, clairement visualisé dans un tableau de bord, et fournit en amont de la transition S/4 une base solide pour toutes les décisions concernant la conception et le dimensionnement de la future architecture. Il est également recommandé de l'utiliser après la réussite de la transition, car le monitoring contribue à ce que l'environnement S/4 fonctionne de manière performante et fiable. La base SAP peut ainsi se concentrer sur les tâches ou activités importantes liées à l'application.

Trois points faibles fréquents lors de la transition vers S/4 

Malheureusement, la préparation et la vue d'ensemble de l'environnement SAP sont souvent mauvaises. Les trois points faibles suivants sont particulièrement fréquents :

1er formulaire : une multitude de formulaires accumulés qui ne sont plus tous utilisés ou nécessaires. Les transférer un à un dans S/4 Hana demande beaucoup d'efforts et d'énormes coûts. Il est préférable de vérifier à l'avance quels formulaires seront nécessaires à l'avenir et de supprimer ceux qui ne le sont pas. 

2. les add-ons : En ce qui concerne les add-ons, les développements propres et les extensions individuelles, on en exploite souvent plusieurs centaines, bien que la licence ne soit accordée que sporadiquement ou pas du tout. C'est un poids inutile. Il est donc préférable d'épurer et de rendre plus rentables les modules complémentaires qui ne sont plus utilisés, de les identifier et de les bloquer ou de les supprimer. Attention : les modules complémentaires qui continuent à être utilisés doivent être validés pour la nouvelle version cible de S/4 Hana, sinon la transition sera retardée de plusieurs semaines dans le pire des cas et coûtera cher. 

3. dimensionnement : Si la mémoire de travail en mémoire de la base de données SAP Hana est surdimensionnée, les coûts d'exploitation et de maintenance augmentent inutilement. Si elle est trop petite, la performance et la satisfaction des utilisateurs en pâtissent, et dans le pire des cas, il y a un "out of memory" et le système s'arrête automatiquement. Le bon dimensionnement du futur système S/4-Hana est difficile. Un monitoring préalable de la charge de travail est donc vivement recommandé. 

Méthode de migration et préparatifs

Pour l'essentiel, deux voies mènent au but : l'approche brownfield, c'est-à-dire une conversion du système existant, ou l'approche greenfield, une nouvelle mise en œuvre. La méthode la plus appropriée dépend de chaque cas et les différences sont bien connues. Ceux qui optent pour une conversion de système - la majorité des clients SAP selon le rapport d'investissement 2022 de DSAG - doivent toutefois effectuer un certain nombre de travaux techniques préalables : 

• Passer à Unicode et au partenaire commercial central (SAP Business Partner) et migrer vers la base de données Hana (si ce n'est pas déjà fait)

• Déployer Adobe Document Services (ADS) pour la nouvelle gestion des sorties et l'adaptation des formulaires toujours utilisés

• Définir la future stratégie front-end (SAP GUI/SAP Fiori)

• Adapter les autorisations et les rôles, de préférence avec SAP Identity Management

• Archiver les données qui ne sont plus nécessaires afin de minimiser la mémoire de travail Hana coûteuse

• Définir le dimensionnement de la base de données Hana et des serveurs d'applications (RAM, espace disque, CPU) en tenant compte du cas de catastrophe et des directives SAP

• Vérifier le code (Custom-Code-Check/Abap Test Cockpit) pour clarifier le besoin d'adaptation des développements et extensions individuels 

Cas particulier des éditions cloud de S/4 Hana

Spécialement pour les éditions cloud de S/4 Hana pour le cloud public et privé, le groupe de logiciels de Walldorf attire avec son offre de services complets Rise with SAP. Mais même avec cette offre, des différences apparaissent entre l'offre standard de SAP et les exigences des clients, par exemple la génération de Certificate Signing Requests (CSR), la définition des politiques de sécurité ou la surveillance des jobs SAP. Lorsque l'on opte pour Rise with SAP, de nombreux travaux doivent également être effectués au préalable. Le système SAP existant doit être épuré et nettoyé et les développements propres qui doivent être réutilisés doivent être recréés à moyen terme sur la base de la SAP Business Technology Platform (SAP BTP) en dehors du noyau ERP. Un fournisseur de base SAP peut combler cette lacune en apportant le savoir-faire technique nécessaire et en jouant le rôle de lien et de coordinateur entre le client et le support SAP. Pour garantir que les interfaces qui contrôlent l'interaction des nouvelles fonctions et des applications mobiles avec S/4 Hana Cloud sont accessibles et fonctionnent sans problème, elles doivent également être surveillées sans faille - par exemple avec un outil de surveillance comme Scansor.

Choisir le modèle d'exploitation SAP approprié

Exploiter SAP soi-même ou l'externaliser ? Ces faits aident à la prise de décision, car la question du futur modèle d'exploitation et de la situation du personnel doit être résolue suffisamment tôt : sur site, dans le cloud privé ou public, ou hybride ? 

1. L'exploitation sur site est idéale pour les entreprises qui souhaitent ou doivent conserver la maîtrise de leur infrastructure informatique, de leur matériel et de leur réseau, parce qu'elles travaillent avec des données particulièrement sensibles qui ne doivent pas être confiées à l'extérieur. On-premises nécessite cependant des forces formées pour l'exploitation SAP, qui peuvent couvrir toute la gamme des tâches avec des connaissances spécifiques autour de Hana, de la sécurité à l'audit en passant par la maintenance régulière de l'infrastructure. Si ces ressources font défaut, l'outtasking SAP est la solution. 

2. L'exploitation en cloud privé dans le cadre de l'externalisation SAP (infrastructure SAP et exploitation de base) est le moyen de choix lorsque l'entreprise se concentre sur des processus numériques sans faille et sur une grande agilité en ce qui concerne les exigences et les développements futurs. Dans ce cas, elle a surtout besoin d'une plate-forme d'infrastructure d'hébergement intégrée, évolutive et hautement disponible. Celle-ci doit être à la pointe de la technologie et certifiée par SAP, elle doit être développée en permanence et garantir une gestion des données conforme à la législation et la continuité des activités. Le fournisseur de base SAP devrait soutenir la transition avec des prestations de conseil complètes, réaliser une architecture sur mesure et veiller à ce que le système SAP et la base de données soient configurés avec précision, que le matériel et le réseau privé virtuel (VPN) soient conçus de manière optimale et que les solutions non-SAP soient intégrées. 

3. L'exploitation en cloud public sur la plateforme d'un hyperscaler comme Google Cloud Platform (GCP), Microsoft Azure ou Amazon Web Services (AWS) est recommandée lorsqu'une entreprise souhaite mettre en réseau ses utilisateurs SAP sur plusieurs sites et qu'elle a besoin de temps de latence courts et d'une puissance de calcul évolutive à volonté. Lors du rightsizing et du rightplacing, il faut tenir compte de ces aspects : la conception du paysage cible, la mise en place de la plateforme, la transition, y compris l'installation de la zone d'atterrissage, la migration des données et l'abonnement, et l'exploitation de la base SAP. 

Conclusion 

Tous les modèles ont une chose en commun : les clients SAP existants devraient faire appel à un partenaire SAP Basis expérimenté et qualifié, d'égal à égal, qui les aide à suivre la feuille de route S/4 Hana en leur prodiguant des conseils et en leur proposant des services gérés sur mesure et des accords de niveau de service (SLA) adaptés, ainsi qu'un support 24h/24 et 7j/7, afin de garantir le bon fonctionnement de SAP. Dans le cadre de la transition S/4 Hana, la gestion du cycle de vie des applications (ALM) et la sécurité ne doivent toutefois pas être négligées. En règle générale, un service informatique interne ne dispose ni du personnel ni du savoir-faire nécessaires à un tel projet et à son exploitation. Mot-clé : manque de personnel qualifié. 

Trouver et choisir le bon partenaire

Tout cela montre que : La transition vers S/4 Hana ou S/4 Hana Cloud est une entreprise complexe. Les entreprises disposant d'un service informatique léger se heurtent rapidement à leurs limites. La mise en place d'un savoir-faire et d'un personnel internes, qui seraient nécessaires pour effectuer une transition en régie propre tout en garantissant une exploitation SAP fluide et sûre, prend beaucoup de temps et est liée à des coûts élevés. Il est préférable de collaborer avec un partenaire technologique SAP fiable qui apporte à ses clients son savoir-faire en matière de préparation, d'exploitation de la base SAP, d'ALM et de sécurité. Si le paysage SAP est surveillé de manière automatisée 24 heures sur 24, plus rien ne s'oppose à la réussite de la transition.