La plupart des checklists de mise en production S/4HANA sont des documents de gestion de projet : responsables de tâches, dates de finalisation, colonnes de validation. Elles permettent de vérifier si les actions ont été réalisées. Elles ne permettent pas de confirmer si le système est réellement sain à chaque étape de la migration.
Cette checklist est différente. Chacun des 20 points ci-dessous correspond à une validation spécifique au monitoring : quelque chose que l’on confirme en consultant des données système réelles, et non en cochant une tâche comme terminée. Dix points s’appliquent avant le cutover technique. Dix autres s’appliquent dans les heures et les jours qui suivent la mise en production. Ensemble, ils couvrent les conditions qui provoquent les incidents les plus fréquents après une migration SAP S/4HANA.
Les points sont classés par niveau de risque dans chaque phase, et non par niveau d’effort. Ceux qui apparaissent en premier sont ceux dont l’oubli coûte le plus cher.
Avant la mise en production : 10 validations de monitoring à finaliser avant l’ouverture de la fenêtre de cutover
Ces 10 points doivent être validés pendant la phase projet, et non pendant le week-end de cutover. Plusieurs d’entre eux nécessitent plusieurs semaines de préparation pour être exécutés correctement.
01 Baseline du système source capturée sur au moins 6 semaines
Connectez votre plateforme de monitoring au système ECC ou à l’ancien environnement S/4HANA au plus tard 8 semaines avant la date de go-live prévue. Collectez les temps de réponse dialog par code transaction, les durées d’exécution des jobs d’arrière-plan, les métriques de performance HANA ou base de données, ainsi que les volumes de débit des interfaces.
Six semaines représentent le minimum, car vous devez disposer d’au moins un cycle complet de clôture mensuelle dans les données de référence. La charge de fin de mois dans ECC est souvent 30 à 50 % plus élevée que les opérations quotidiennes. Si votre baseline ne couvre que des journées normales, votre comparaison post-migration signalera les performances de fin de mois comme une régression, alors qu’il s’agit en réalité d’un comportement attendu.
Pourquoi c’est important : sans baseline du système source, les discussions sur les performances après migration deviennent subjectives. Chaque échange devient une opinion. Avec des données de référence, chaque discussion repose sur des chiffres.
02 Dimensionnement HANA validé sous charge UAT, et pas seulement sur l’estimation initiale
Le dimensionnement HANA initial pour S/4HANA repose sur le volume de données ECC et sur une estimation de la charge utilisateur. L’UAT est le seul environnement dans lequel une charge de travail S/4HANA réelle s’exécute avant la mise en production. Lancez un test de charge pendant l’UAT qui reflète les conditions de production en période de pointe, puis mesurez l’utilisation mémoire HANA au pic de charge.
Si la mémoire HANA dépasse 75 % de la limite d’allocation pendant le test de charge UAT, le système de production est sous-dimensionné par rapport à la charge qu’il devra absorber. Un sous-dimensionnement découvert pendant l’UAT peut être corrigé avant la mise en production. Découvert lors de la première clôture mensuelle en production, il ne peut plus l’être simplement.
Pourquoi c’est important : HANA est une base de données en mémoire. Un sous-dimensionnement ne produit pas une dégradation progressive. Il provoque un arrêt d’urgence lorsque la limite d’allocation est atteinte.
03 Planning des jobs d’arrière-plan documenté et vérifié indépendamment dans S/4HANA
Exportez le planning complet des jobs de production depuis SM36 dans le système source. Pour chaque job Tier 1, c’est-à-dire critique pour l’activité avec une échéance stricte, vérifiez que le job équivalent dans S/4HANA dispose des bons éléments : variante de planification, affectation au groupe de serveurs, dépendance prédécesseur-successeur et variante de sortie.
Vérifier signifie ouvrir le job dans SM36 sur S/4HANA et le comparer ligne par ligne avec la documentation source. Cela ne signifie pas demander à la personne qui a recréé les jobs si elle l’a fait correctement.
Pourquoi c’est important : les erreurs de recréation des jobs sont l’une des principales causes de défaillances silencieuses dans les premières semaines suivant la mise en production. Un job recréé avec le mauvais groupe de serveurs démarre sur la mauvaise instance. Une dépendance prédécesseur manquante provoque l’exécution simultanée de deux jobs qui devraient s’exécuter de manière séquentielle.
Point de vigilance : les jobs avec des variantes propres à un utilisateur, par exemple des variantes nommées d’après un utilisateur SAP spécifique, peuvent ne pas être transférés correctement lors de leur recréation. Si le compte utilisateur dans le système cible possède un client ou une configuration d’autorisations différente, la référence à la variante peut échouer silencieusement lors de la première exécution.
04 Inventaire des interfaces finalisé avec baseline des volumes et taux d’erreur par interface
Documentez chaque interface de production qui envoie ou reçoit des données depuis le système SAP : type de message, IDoc, RFC, REST ou SOAP, volume quotidien moyen, taux d’erreur normal et processus métier pris en charge. Pour les interfaces très critiques, capturez les schémas de volume horaire sur toute la période de baseline.
Cette documentation a deux usages. Premièrement, elle définit ce que signifie reconnecter les interfaces après le cutover : lesquelles doivent être réactivées, dans quel ordre et ce qu’un premier flux de messages réussi doit confirmer. Deuxièmement, elle établit la référence à partir de laquelle la santé des interfaces sera évaluée après le go-live.
Pourquoi c’est important : une interface sans volume après cutover peut fonctionner correctement, parce qu’aucun message n’a encore été généré, ou avoir échoué à se reconnecter. Sans baseline de volume pour cette interface, il est impossible de faire la différence.
05 Seuils d’alerte configurés par profil d’instance, et non copiés depuis les paramètres par défaut
Les seuils d’alerte par défaut de n’importe quel outil de monitoring SAP sont calibrés pour un environnement générique. Votre environnement S/4HANA possède une limite d’allocation mémoire HANA spécifique, un nombre précis de work processes dialog par instance, une fenêtre batch spécifique et des volumes d’interface propres. Les seuils par défaut généreront des faux positifs dans certaines zones et manqueront de vrais problèmes dans d’autres.
Au minimum, configurez les seuils pour l’utilisation mémoire HANA, en fonction de la limite d’allocation et non de la RAM totale, l’utilisation des work processes dialog par instance, l’utilisation du volume de logs HANA, la durée des jobs d’arrière-plan par job Tier 1 et les taux d’erreur d’interface par interface.
Pourquoi c’est important : calibrer les seuils prend une demi-journée. Gérer la fatigue d’alerte causée par des seuils mal configurés pendant une semaine de go-live prend beaucoup plus de temps et conduit souvent à ignorer de vraies alertes.
06 Intégration ITSM testée de bout en bout avec une vraie alerte, et pas seulement configurée
La plupart des intégrations entre monitoring et ITSM sont configurées dans un environnement de test, puis supposées fonctionnelles en production. Les hypothèses qui échouent le plus souvent sont les suivantes : l’instance ITSM de production possède des endpoints API ou une authentification différents de l’environnement de test, le compte utilisateur configuré pour l’intégration n’a pas les permissions nécessaires en production, ou les correspondances entre catégorie d’incident et priorité produisent des tickets mal classés.
Déclenchez une vraie alerte de test depuis la connexion de monitoring de production vers S/4HANA, puis vérifiez qu’un ticket d’incident correctement formé apparaît dans le système ITSM, avec la bonne catégorie, la bonne priorité et la bonne équipe assignée. Résolvez ensuite l’incident de test et confirmez que le système de monitoring reflète bien cette résolution.
Pourquoi c’est important : découvrir que l’intégration ITSM est cassée pendant le premier incident de production ajoute de la confusion et du retard à une situation déjà sous pression.
07 Volume de logs HANA dimensionné et configuration des sauvegardes de logs vérifiée sous charge
Le volume de logs HANA contient toutes les données de transaction non validées. Lorsqu’il atteint 100 % d’utilisation, la base de données effectue un arrêt immédiat. Les sauvegardes de logs libèrent les segments de logs utilisés et empêchent le volume de se remplir. L’intervalle de sauvegarde des logs doit être calibré sur le débit d’écriture de la charge de production.
Pendant le test de charge UAT, surveillez le rythme de remplissage du volume de logs sous charge transactionnelle maximale. Calculez la vitesse à laquelle le volume de logs se remplirait si les sauvegardes de logs s’arrêtaient pendant 2 heures. Si le volume de logs atteignait 100 % dans cette fenêtre, il faut soit augmenter sa taille, soit raccourcir l’intervalle de sauvegarde.
Pourquoi c’est important : le dimensionnement du volume de logs est souvent copié depuis des documents de dimensionnement ECC sans tenir compte des schémas d’écriture propres à HANA. C’est l’une des causes les plus fréquentes d’arrêts HANA non planifiés dans les premiers mois suivant la mise en production.
08 Configuration de l’Enqueue Replication Server vérifiée avec une panne simulée
Si le paysage S/4HANA de production dispose d’une haute disponibilité, l’Enqueue Replication Server, ou ERS, maintient une copie de la table de verrous sur une instance secondaire. L’ERS est souvent configuré mais non vérifié : l’instance existe, elle réplique la table de verrous, mais l’intégration Pacemaker censée la promouvoir automatiquement en cas de panne du nœud primaire n’a jamais été testée.
Avant la mise en production, simulez une panne du serveur enqueue primaire dans l’environnement QA ou préproduction, puis confirmez que l’ERS est promu correctement, que les sessions utilisateur actives peuvent poursuivre leurs transactions et que la promotion se termine dans la fenêtre de temps attendue.
Pourquoi c’est important : une configuration ERS jamais testée est une hypothèse, pas une capacité. Le test de promotion prend 30 minutes. Une mauvaise configuration ERS non détectée pendant un basculement en production prend beaucoup plus de temps à corriger.
09 Les responsables métier ont défini et validé les critères d’acceptation du monitoring
L’équipe SAP Basis peut confirmer que HANA est sain et que les temps de réponse dialog respectent les normes techniques. Ce n’est pas la même chose que confirmer que le processus order-to-cash fonctionne correctement, que les écritures financières se terminent dans la fenêtre attendue ou que le partenaire EDI reçoit des messages correctement formés.
Avant la mise en production, chaque processus métier Tier 1 doit avoir un responsable nommé, un critère d’acceptation défini, par exemple « tous les IDocs ORDERS05 traités dans les 10 minutes suivant leur réception », et une étape de confirmation dans le runbook post-go-live où ce responsable valide le processus à partir de données de monitoring réelles.
Pourquoi c’est important : sans critères d’acceptation définis par le métier, la validation du go-live repose sur des métriques de santé technique qui peuvent ne pas refléter la capacité réelle de l’entreprise à fonctionner sur le nouveau système.
10 Runbook de cutover incluant des checkpoints de monitoring avec responsable nommé et critères pass/fail
Un runbook de cutover qui liste des tâches sans checkpoints de monitoring suppose que tout fonctionne tant que personne ne signale de problème. Un runbook avec checkpoints de monitoring intègre de la visibilité dans le processus : à des jalons précis, une personne nommée vérifie une métrique spécifique et confirme qu’elle se situe dans la plage attendue avant de passer à l’étape suivante.
Les checkpoints de monitoring à intégrer dans le runbook de cutover sont notamment : utilisation mémoire HANA après la fin de la migration des données, utilisation du volume de logs à T+2 h pendant le cutover, disponibilité des work processes dialog avant l’ouverture du système aux utilisateurs et profondeur des files d’attente d’interface après reconnexion.
Pourquoi c’est important : les checkpoints de monitoring dans le runbook de cutover font la différence entre un cutover où l’équipe sait que le système est prêt et un cutover où le système est ouvert aux utilisateurs en espérant que tout ira bien.
Après la mise en production : 10 validations de monitoring pour les 72 premières heures
Ces 10 points s’appliquent à partir du moment où le premier utilisateur métier se connecte, jusqu’à la fin des 72 premières heures d’exploitation en production. Plusieurs nécessitent une action dans la première heure. Aucun ne doit être reporté au jour ouvré suivant.
11 Profil de démarrage à froid de la mémoire HANA capturé et comparé à la baseline UAT
Lorsque les premiers utilisateurs métier se connectent à S/4HANA après la mise en production, le système commence à charger les données du column store depuis le disque vers la mémoire à mesure que les requêtes y accèdent pour la première fois. Cette phase de démarrage à froid produit une trajectoire de consommation mémoire différente de celle d’un fonctionnement en régime stabilisé et différente des tests de charge UAT, où une partie des données était déjà chaude.
Capturez l’utilisation mémoire HANA toutes les 15 minutes pendant les 2 premières heures. Si la trajectoire suggère que la mémoire dépassera 85 % de la limite d’allocation avant que le jeu de données de travail ne soit entièrement chargé, escaladez immédiatement vers l’équipe infrastructure. N’attendez pas que le seuil de 85 % soit franchi.
Pourquoi c’est important : le comportement mémoire en démarrage à froid est le seul point de données que l’UAT ne peut pas répliquer entièrement. Les premières heures de production offrent la seule opportunité de l’observer en conditions réelles, à un moment où vous disposez encore d’une marge d’action côté infrastructure.
12 Tous les jobs d’arrière-plan Tier 1 vérifiés comme exécutés et terminés correctement au jour 1
Un job correctement recréé dans SM36 mais jamais exécuté n’est pas un job vérifié. Lors du premier jour ouvré après la mise en production, chaque job d’arrière-plan Tier 1 planifié doit être contrôlé dans SM37 : statut, heure de début, heure de fin et, pour les jobs critiques, sortie spool relue afin d’identifier les erreurs au niveau applicatif.
Portez une attention particulière aux jobs avec une planification basée sur l’heure de démarrage et configurés avant la date de go-live. Un job configuré pour s’exécuter tous les jours à 06:00 à partir d’une date antérieure au go-live peut contenir une exécution manquée dans son historique. Certaines configurations de planification l’exécutent immédiatement au prochain démarrage du système, tandis que d’autres l’ignorent complètement.
Pourquoi c’est important : un job Tier 1 qui ne s’exécute pas au jour 1 crée un déficit de données qui s’accumule. Le découvrir au jour 3 signifie qu’il faut réconcilier trois jours de données, et non un seul.
13 Reconnexion des interfaces confirmée avec les premiers flux de messages réels, et non avec de simples tests de connexion
La reconnexion des interfaces après cutover implique généralement de réactiver les connexions gelées pendant la fenêtre de migration. Un test de connexion SM59 confirme que le chemin réseau existe. Il ne confirme pas que les messages circulent, que le système destinataire les traite ou que les payloads sont générés correctement avec les types de messages S/4HANA.
Pour chaque interface Tier 1, attendez que le premier vrai message soit généré après la mise en production, vérifiez qu’il a été envoyé sans erreur, via BD87 pour les IDocs, SM58 pour tRFC ou le monitor Integration Suite pour les flux BTP, puis confirmez que le système destinataire en a accusé réception. Ce premier message end-to-end réussi est la véritable preuve de santé de l’interface.
Pourquoi c’est important : les tests de connexion réussissent. Les flux de messages échouent. Ce ne sont pas les mêmes validations.
En pratique : les interfaces qui reposaient sur un routage par IP fixe peuvent continuer à router vers l’adresse IP ECC après le cutover si les enregistrements DNS ou les destinations RFC n’ont pas été mis à jour. Cela produit un test de connexion réussi, car l’ancien système ECC répond encore, tandis que les messages partent vers la mauvaise destination. Vérifiez que chaque destination RFC pointe vers le système S/4HANA, et non vers l’ancien système.
14 Routage des alertes vérifié : alerte de test déclenchée et reçue par l’équipe d’astreinte dans la fenêtre SLA
Les configurations d’alertes testées hors production peuvent router vers des équipes ou des canaux différents de ceux prévus en production. La liste des contacts d’astreinte peut avoir changé entre la configuration et la mise en production. Le système de monitoring peut gérer différemment les emails sortants ou les webhooks sous les politiques réseau de production.
Dans les 2 premières heures suivant la mise en production, déclenchez volontairement une alerte de test : abaissez temporairement un seuil en dessous des valeurs actuelles, confirmez que l’alerte se déclenche, confirmez qu’elle arrive au bon contact d’astreinte via le canal attendu, email, SMS ou ticket ITSM, puis confirmez que l’alerte disparaît lorsque le seuil est restauré.
Pourquoi c’est important : le premier incident réel n’est pas le bon moment pour découvrir que le routage des alertes est cassé.
15 Temps de réponse dialog comparés à la baseline ECC par code transaction dans les 2 premières heures
Les temps de réponse dialog sur S/4HANA sont souvent plus rapides que sur ECC pour les mêmes codes transaction, car le traitement en mémoire de HANA élimine de nombreuses opérations de lecture base de données qui ralentissaient ECC. Lorsqu’ils ne sont pas plus rapides, ou lorsque certaines transactions régressent fortement, la cause se trouve presque toujours dans l’un de ces trois éléments : une statistique de base de données manquante sur HANA, nécessitant un UPDATE STATISTICS sur les tables concernées, un programme ABAP spécifique non adapté aux changements de modèle de données S/4HANA, ou un problème de configuration dans la couche applicative.
Comparez les 20 principaux codes transaction par fréquence d’utilisation dans la baseline ECC avec leurs temps de réponse durant les deux premières heures de production S/4HANA. Une régression de plus de 50 % sur une transaction fréquemment utilisée mérite une investigation le jour même.
Pourquoi c’est important : les régressions de temps de réponse non investiguées au jour 1 deviennent des plaintes utilisateurs établies au jour 3 et des escalades au jour 5.
16 File d’attente SM13 vérifiée pour les mises à jour en erreur dans la première heure d’activité métier
Les requêtes de mise à jour échouées dans SM13 représentent des transactions sauvegardées dont les écritures en base de données n’ont pas été finalisées. Les utilisateurs ont reçu une confirmation d’enregistrement. Les données ne sont pas dans la base. Il s’agit d’un problème d’intégrité des données, pas d’un problème de performance.
Ouvrez SM13 sur S/4HANA dans la première heure d’activité utilisateur et filtrez les entrées en statut erreur. Toute entrée nécessite une investigation immédiate avant que l’utilisateur concerné ne poursuive son travail en pensant que ses données ont été sauvegardées. Les erreurs de mise à jour dans la première heure de production sont souvent causées par une autorisation manquante pour l’utilisateur de mise à jour, une différence de configuration entre l’environnement de test et la production, ou une extension spécifique non testée dans le contexte de mise à jour.
Pourquoi c’est important : des erreurs de mise à jour découvertes 4 heures après leur apparition nécessitent une réconciliation avec les transactions suivantes qui reposaient sur l’hypothèse que l’enregistrement avait réussi. Découvertes dans les 30 minutes, elles peuvent généralement être corrigées en relançant simplement la mise à jour après correction de la cause racine.
17 Durées de fin des premiers jobs batch comparées aux durées de référence ECC
La première exécution batch nocturne sur S/4HANA est le premier vrai test du planning batch avec les volumes de données de production. Enregistrez l’heure de fin réelle de chaque job Tier 1 et comparez-la à la baseline ECC.
Les jobs natifs HANA doivent souvent s’exécuter plus rapidement que dans ECC, parfois de manière significative. Les jobs conçus pour ECC mais non adaptés à S/4HANA peuvent être plus lents à cause de l’overhead des vues de compatibilité ou des changements de modèle de données. Un job qui prenait 40 minutes dans ECC et prend 2 heures dans S/4HANA n’est pas une régression de performance à accepter. C’est un problème technique à investiguer avant la prochaine exécution.
Pourquoi c’est important : la durée de la première exécution batch nocturne établit la baseline S/4HANA pour les futures comparaisons. Si cette première exécution n’est pas mesurée précisément, toute déviation ultérieure n’aura aucun point de référence.
18 Backlog de delta merge HANA vérifié après les 48 premières heures d’activité d’écriture
Les 48 premières heures de production S/4HANA génèrent une vague d’activité INSERT : nouvelles commandes clients, nouveaux ordres de production, nouvelles écritures financières, le tout dans des tables qui étaient vides ou presque vides au go-live. Cette activité INSERT massive remplit le delta store HANA plus rapidement qu’en régime stabilisé. Si les delta merges prennent du retard, les performances de requête sur les tables concernées commencent à se dégrader.
Après 48 heures, vérifiez M_DELTA_MERGE_STATISTICS pour identifier le nombre de merges en attente et les éventuels échecs de merge. Un nombre d’échecs de delta merge supérieur à zéro nécessite une investigation. Une file de merges en attente qui augmente et ne se vide pas entre les cycles de merge indique que la configuration auto-merge ne suit pas le volume d’écriture post-go-live.
Pourquoi c’est important : un backlog de delta merge ne produit ni erreur, ni alerte, ni symptôme évident jusqu’à ce que les plans de requêtes commencent à choisir des chemins sous-optimaux. Il est invisible pour tout le monde, sauf pour la personne qui sait où regarder.
Note : les statistiques de base de données HANA sur les tables récemment alimentées peuvent également nécessiter une mise à jour après les 48 premières heures de chargement de données. Les tables nouvellement créées avec un volume important de données mais des statistiques obsolètes produisent de mauvais plans de requêtes. L’exécution d’UPDATE STATISTICS sur les tables les plus interrogées après le chargement initial de données post-go-live est une maintenance standard qui est souvent oubliée dans la checklist de cutover.
19 Les responsables métier confirment que les premières transactions sont traitées correctement, avec données à l’appui
Les métriques de santé technique confirment que le système fonctionne. Elles ne confirment pas que le système produit les bons résultats métier. À la fin du premier jour ouvré, chaque responsable de processus métier Tier 1 doit avoir examiné la sortie réelle de son processus et confirmé qu’elle est correcte.
Cette confirmation repose sur des données, pas sur l’absence de plaintes. L’équipe finance confirme que les premières écritures financières issues de l’exécution de production affichent les bons comptes et les bons montants. L’équipe logistique confirme que les premiers mouvements de marchandises ont été comptabilisés dans les bons emplacements de stockage. L’équipe achats confirme que les premières commandes d’achat créées via l’interface EDI contiennent les bons fournisseurs et les bonnes données de prix.
Pourquoi c’est important : un processus métier qui fonctionne techniquement mais produit une sortie incorrecte n’est pas un go-live sain. C’est un incident de qualité des données qui accumule des dommages à chaque transaction suivante basée sur des données préalables incorrectes.
20 Document de handover monitoring remis à l’équipe opérations avant la démobilisation de l’équipe projet
L’équipe projet qui a construit la configuration de monitoring sait pourquoi chaque seuil a été défini à ce niveau, quelles alertes risquent de générer du bruit pendant la période de stabilisation et lesquelles nécessitent une escalade immédiate. L’équipe opérations qui exploitera le système à partir du deuxième mois ne possède pas cette connaissance si elle n’est pas documentée et transférée.
Le document de handover doit couvrir : la justification de chaque seuil non standard, la liste des alertes de période de stabilisation à revoir et potentiellement ajuster au jour 30, le chemin d’escalade pour chaque catégorie d’alerte et le processus de mise à jour des baselines lorsque la charge de travail évolue. Il n’a pas besoin d’être long. Il doit simplement exister avant la clôture de l’engagement par l’équipe projet.
Pourquoi c’est important : les équipes projet se démobilisent. Lorsque cela arrive, la connaissance institutionnelle sur les raisons de la configuration du monitoring disparaît avec elles si elle n’a pas été écrite.
Utiliser cette checklist dans un vrai projet
Vingt points de validation répartis sur deux phases offrent une vision complète de la préparation monitoring pour une migration S/4HANA. En pratique, tous ne reçoivent pas la même attention. Les points les plus souvent oubliés sont ceux qui nécessitent une action précoce : baseline du système source, point 1, dimensionnement HANA sous charge UAT réelle, point 2, et calibration des seuils d’alerte, point 5.
Ces trois points doivent être protégés dans le planning projet précisément parce que leur délai de préparation ne peut pas être compressé. Une baseline exige plusieurs semaines de collecte de données. La validation du dimensionnement HANA exige un vrai test de charge UAT. La calibration des seuils exige des données de référence fiables. Les démarrer tard produit la situation que la plupart des équipes S/4HANA ont déjà connue : une mise en production avec une plateforme de monitoring techniquement connectée, mais opérationnellement non calibrée, qui génère des alertes auxquelles personne ne fait confiance.
Les 10 points post-go-live sont sensibles au temps dans l’autre sens. Les points 11 à 16 doivent être réalisés dans les toutes premières heures d’exploitation en production. Les reporter à « après le rush » revient à les reporter au-delà de la fenêtre où la détection précoce reste préventive. Une trajectoire mémoire HANA visible à l’heure 2 est actionnable. La même trajectoire à l’heure 8, lorsqu’elle a déjà provoqué une dégradation des performances, devient réactive.
Les deux phases, avant et après, partagent le même principe fondamental : un monitoring en place avant l’événement qu’il est censé détecter est du monitoring. Tout le reste n’est qu’une investigation.
Redpeaks accompagne les migrations S/4HANA avec un monitoring sans agent des systèmes source et cible, la capture de baseline avant migration et des tableaux de bord de stabilisation post-go-live. Aucun transport, aucun agent, aucune surcharge de change management. Découvrez comment Redpeaks couvre les migrations S/4HANA.
