La plupart des discussions sur le monitoring S/4HANA commencent la semaine qui suit le go-live. Le système est en production, les utilisateurs signalent des lenteurs et l’équipe projet tente de comprendre ce qui se passe sur une plateforme qu’elle exploite pour la première fois sous charge réelle. À ce stade, le monitoring est forcément réactif. La fenêtre permettant de mettre en place une supervision proactive est déjà fermée.
Les décisions de monitoring qui déterminent si vos premières semaines sur S/4HANA seront stables ou chaotiques se prennent plusieurs semaines avant le cutover, pas après. Elles concernent ce qu’il faut mesurer sur le système legacy avant l’ouverture de la fenêtre de migration, ce qu’il faut surveiller pendant le cutover technique lui-même, comment vérifier que le nouveau système est sain avant la première connexion utilisateur et à quoi doivent ressembler les opérations de production du premier mois avant de pouvoir déclarer le go-live stable.
Ce guide couvre chacune de ces phases dans l’ordre. Il s’adresse aux personnes responsables de la préparation technique de la migration : les équipes SAP Basis, les architectes monitoring, les MSP et les responsables IT operations qui seront d’astreinte pendant le week-end de cutover et les semaines qui suivront.
Le manque de visibilité que l’on retrouve dans la plupart des projets S/4HANA
Pourquoi la fenêtre de cutover est-elle la période la plus risquée et la moins visible ?
Regardez ce qui se passe pendant un cutover technique S/4HANA classique. Le système source ECC est verrouillé pour les transactions métier. Un outil comme SUM avec DMO, pour Database Migration Option, ou une procédure d’export/import est en cours d’exécution. HANA est chargé avec les données migrées. Le processus peut durer de 12 heures à plusieurs jours selon le volume de données et l’infrastructure matérielle. Et pendant la majeure partie de cette fenêtre, la visibilité de l’équipe opérations se limite à quelques écrans de progression périodiques et à l’espoir que rien d’inattendu ne se produise.
Il n’y a pas de charge dialog à observer, puisque les utilisateurs ne sont pas dans le système. Les jobs batch sont gelés. Les interfaces sont arrêtées. La discipline de monitoring qui couvre habituellement les opérations de production n’a donc pas d’application évidente. L’équipe regarde la barre de progression de l’outil de migration et attend.
Ce qui n’est pas monitoré pendant cette fenêtre, c’est l’instance HANA elle-même : la consommation mémoire pendant le chargement des données de migration, la croissance du volume de logs pendant la phase de chargement, la saturation I/O au niveau du stockage pendant les migrations de grandes tables avec écriture soutenue à fort débit. Ce sont précisément ces conditions qui provoquent l’arrêt ou l’échec de certaines phases de migration. Elles sont pourtant rarement surveillées de manière proactive. Le premier signe d’un problème est souvent une phase qui n’avance plus, ce qui déclenche une investigation manuelle qui aurait pu être remplacée par une alerte préconfigurée.
Le coût des angles morts de monitoring lors de la première semaine de production
La première semaine sur S/4HANA a une dynamique opérationnelle très particulière. L’équipe projet est épuisée par le week-end de cutover. L’équipe opérations découvre un nouveau système. Les utilisateurs métier rencontrent une interface différente, des noms de transactions différents et des comportements différents pour des processus qu’ils exécutent de la même manière depuis des années. Tout est observé de près.
Lorsqu’un problème de performance survient dans ce contexte, la pression pour l’identifier et le résoudre est immédiate. Si l’infrastructure de monitoring n’est pas en place, l’investigation repart de zéro : extraction de données Basis dans SM50, requêtes HANA ponctuelles pour contrôler la mémoire, vérification manuelle des logs de jobs batch. Les outils qui permettraient de réduire une investigation de 90 minutes à 10 minutes sont précisément ceux qui auraient dû être configurés avant le go-live.
Le manque de monitoring pendant la première semaine n’est pas seulement une gêne technique. Il affecte la confiance. Lorsqu’une entreprise qui vient d’investir dans une migration S/4HANA subit des lenteurs inexpliquées dès la première semaine, sans explication technique claire, elle commence à remettre en question les décisions projet qui l’ont conduite là. Un bon monitoring ne réduit pas seulement le temps de résolution des incidents. Il fournit les données nécessaires pour expliquer ce qui se passe et pourquoi, ce qui représente une valeur projet à part entière pendant la phase de stabilisation.
Phase 1 : établir des baselines sur le système source avant le début de la migration
Que mesurer sur ECC avant l’ouverture de la fenêtre de migration ?
L’activité de monitoring la plus sous-estimée dans une migration S/4HANA consiste à capturer une baseline sur le système source avant le démarrage du projet. Pas un simple instantané, mais un enregistrement continu sur une période représentative : au minimum huit semaines, incluant des jours ouvrés normaux, une clôture mensuelle et tout autre événement batch périodique propre à l’organisation.
Les métriques de baseline qui comptent pour la comparaison post-migration sont les temps de réponse dialog par code transaction, la charge moyenne des work processes en arrière-plan selon l’heure de la journée, les temps de réponse base de données pour les principales requêtes SQL par fréquence d’exécution et les profils de charge globale du système pendant les pics d’activité. Ces données, capturées de manière systématique avant la migration, deviennent le référentiel utilisé pour évaluer les performances S/4HANA après le go-live.
Sans cette baseline, les discussions sur la performance post go-live reposent sur des impressions. Dire « le système semble plus lent » n’a pas le même poids que dire « le temps de réponse moyen de la transaction VA01 était de 1,2 seconde dans ECC ; il est actuellement de 2,8 secondes dans S/4HANA avec le même volume transactionnel ». La deuxième conversation ouvre une piste de résolution. La première non.
Timing : démarrez la collecte de baseline au moins 8 semaines avant la fenêtre de migration prévue. Deux semaines de données ne suffisent pas pour capturer le comportement de fin de mois. Or, la clôture mensuelle dans ECC révèle souvent des profils de charge invisibles dans les opérations quotidiennes.
Capturer les profils de jobs batch et les baselines de débit des interfaces
Les jobs en arrière-plan ne migrent pas automatiquement d’ECC vers S/4HANA. Ils sont recréés manuellement par l’équipe Basis, soit via une saisie manuelle dans SM36, soit via un transport contenant la configuration de planification des jobs. Dans les deux cas, cette recréation introduit des risques d’erreur : mauvaise affectation à un groupe de serveurs, paramètres d’étape manquants, références de variantes incorrectes.
Avant le début de la migration, documentez chaque job batch de production avec sa fréquence de planification, son temps d’exécution attendu en volume normal et en volume de clôture mensuelle, le groupe de serveurs ou le serveur nommé sur lequel il s’exécute, ainsi que ses relations prédécesseur/successeur. Cette documentation permet à l’équipe Basis de vérifier la bonne recréation des jobs dans S/4HANA avant le go-live. Elle permet aussi à l’équipe opérations de configurer des seuils d’alerte sur les durées d’exécution dans le nouveau système.
Les baselines de débit des interfaces suivent la même logique. Chaque interface de production dans ECC possède un volume moyen quotidien de messages, un temps de traitement normal et un taux d’erreur qui décrit ce qu’est un fonctionnement normal. Capturer ces chiffres avant la migration fournit les données de comparaison nécessaires pour confirmer que les interfaces traitent correctement dans S/4HANA, et pas seulement qu’elles sont techniquement actives.
La baseline de performance qui rend la comparaison post-migration réellement utile
Il existe une configuration de monitoring qui rend la comparaison post-migration beaucoup plus simple, mais qui est presque toujours oubliée : faire tourner l’outil de monitoring en parallèle sur le système source ECC et sur la cible S/4HANA pendant la période de validation, avant le go-live. Cela suppose que la plateforme de monitoring soit connectée à ECC dans le cadre du projet de migration, et pas uniquement à S/4HANA après le go-live.
Lorsque les deux systèmes sont monitorés par la même plateforme, la comparaison entre la baseline de performance ECC et les performances S/4HANA pendant les tests de charge et les tests utilisateurs repose sur les mêmes métriques, les mêmes seuils et le même format de tableau de bord. Identifier une régression devient une question de lecture de deux courbes sur le même graphique, plutôt qu’une comparaison de chiffres issus de sources différentes avec des méthodes de collecte différentes.
Le prérequis pratique de cette approche consiste à connecter l’outil de monitoring tôt, pendant la phase projet où ECC reste le système de production, puis à le configurer pour capturer les métriques spécifiques qui seront utilisées pour la comparaison post-migration. C’est un travail de configuration de trois à quatre semaines que beaucoup de projets dépriorisent, parce que le monitoring est traité comme une tâche de go-live plutôt que comme un prérequis de migration.
Phase 2 : couverture de monitoring pendant le cutover technique
Que surveiller pendant la phase de migration des données ?
La phase de migration des données, qu’elle utilise SUM avec DMO, un export/import classique ou une conversion shell, impose au système HANA une charge d’écriture soutenue qui ne ressemble à aucun profil de production normal. De grandes tables sont insérées en masse. Le delta store de HANA accumule des entrées plus vite que l’auto-merge ne peut les traiter. Le volume de logs augmente à une vitesse dictée par la migration, et non par le volume transactionnel habituel.
Trois métriques méritent une surveillance continue pendant cette phase. La consommation mémoire HANA par rapport à la limite d’allocation, car les insertions massives consomment plus d’espace en mémoire par ligne que les opérations en régime stable pendant que les opérations de merge traitent et compressent les données. L’utilisation du volume de logs, car les sauvegardes de logs pendant une fenêtre de migration exigent une configuration spécifique facile à oublier dans la checklist pré-cutover. Et la durée des phases de l’outil de migration par rapport au planning attendu, car une phase qui dure 40 % plus longtemps que pendant la répétition générale est un point de décision, pas une simple observation.
L’alerte sur la durée par phase de migration est précisément la capacité que la plupart des équipes projet n’ont pas configurée, car elles n’ont jamais pensé les phases d’un outil de migration comme des événements monitorables. Les outils SUM et DMO produisent des fichiers logs contenant des données de timing par phase, qui peuvent être lus par des agents de monitoring ou par un simple script personnalisé. Déclencher une alerte lorsqu’une phase dure plus de 50 % au-delà du timing observé pendant la répétition générale crée une donnée actionnable pendant la fenêtre de migration, au lieu d’obliger quelqu’un à vérifier manuellement l’outil toutes les 30 minutes.
Erreur fréquente : le mode log HANA pendant DMO ne doit être défini sur « overwrite » que pour les migrations hors production où la restauration à un point dans le temps n’est pas requise. Pour les migrations de production où le RPO compte, le mode log doit rester sur « normal » et les sauvegardes de logs doivent fonctionner pendant toute la fenêtre de migration. Vérifiez ce point dans la revue de configuration avant l’ouverture de la fenêtre de migration, pas pendant.
Monitoring du gel des interfaces : à quoi ressemble vraiment le silence
Le gel des interfaces avant le cutover est un concept bien connu dans les migrations. Tous les flux entrants vers ECC sont arrêtés. Les messages en cours sont traités et les files sont vidées. Le système source atteint un état propre avant le début de la migration.
Ce qui est moins bien compris, c’est la manière de confirmer que ce gel est complet. Arrêter une interface au niveau middleware empêche l’envoi de nouveaux messages. Cela ne vide pas immédiatement tous les messages déjà présents dans la file ou en cours de traitement. Un message arrivé deux minutes avant l’ouverture de la fenêtre de gel peut encore être dans la file IDoc ou qRFC, partiellement traité, au moment où la migration des données commence. Si ce message termine son traitement après le début de la capture de l’état des données, il crée un écart de réconciliation.
Le monitoring de la profondeur des files jusqu’à zéro est l’étape de vérification. Il ne s’agit pas seulement de confirmer que la configuration de l’interface est en état arrêté, mais de confirmer que les files de messages sont vides. SM58 pour le RFC transactionnel, SMQ1/SMQ2 pour qRFC, BD87 pour le traitement IDoc, ainsi que tout monitoring de files côté middleware pour la couche d’intégration, doivent tous confirmer qu’il n’y a aucun élément en attente avant le début de la migration des données. Cette vérification doit figurer dans la checklist de cutover go-live comme un point signé, pas comme une hypothèse.
Le dernier batch close : monitorer la dernière exécution sur le système source
Les jobs batch qui s’exécutent sur ECC dans les jours précédant le go-live portent un vrai risque métier. Un job de clôture de période en échec, une erreur de prétraitement paie ou une facturation qui ne se termine pas correctement laisse le système source dans un état incohérent, qui se transmet à S/4HANA sous forme de problème de qualité de données.
Les dernières exécutions batch sur ECC doivent être monitorées avec la même attention qu’une clôture mensuelle, et non comme un traitement d’arrière-plan de routine qui finira par se régler seul. Cela signifie vérifier non seulement le statut du job, FINISHED, mais aussi le contenu du spool pour détecter les erreurs applicatives, contrôler la génération des fichiers de sortie lorsque c’est applicable et confirmer que les jobs dépendants en aval se sont bien terminés dans l’ordre prévu.
Un scénario spécifique mérite une attention particulière : les chaînes de jobs prédécesseur/successeur qui chevauchent la fenêtre de gel des interfaces. Si un job qui génère une sortie pour un système externe devait s’exécuter pendant la période de gel, cette sortie n’a peut-être pas été livrée avant le gel. Le responsable du processus métier doit confirmer explicitement que l’état des données dans ECC au moment de la migration est complet et propre pour son domaine, sur la base d’éléments de monitoring, pas sur une hypothèse.
Phase 3 : les premières heures après le go-live sur S/4HANA
Mémoire HANA et performance dans les premières 24 heures
La première fois que des utilisateurs métier sollicitent un système S/4HANA fraîchement mis en production, l’instance HANA est dans un état froid par rapport à la charge de production. Les données du column store chargées pendant la migration n’ont pas encore été consultées par de vraies transactions. Les premières requêtes utilisateurs obligent HANA à charger des partitions du column store qui n’ont pas été touchées depuis la migration, ce qui génère de l’I/O sur le volume de données et augmente la consommation mémoire.
Ce comportement de cold start signifie que les premières heures d’exploitation en production sont différentes des performances observées pendant les tests de charge, même lorsque ces tests ont été bien conçus. Les temps de réponse pendant les 30 à 60 premières minutes sont généralement plus élevés qu’ils ne le seront une fois que le jeu de données de travail sera chaud en mémoire. L’équipe opérations doit le savoir à l’avance afin de ne pas interpréter un comportement normal de cold start comme un problème système exigeant une intervention immédiate.
Ce qui exige en revanche une intervention immédiate, c’est une consommation mémoire qui approche la limite d’allocation avant que le jeu de données de travail ne soit totalement chargé. Si la mémoire HANA est déjà à 82 % après deux heures d’activité utilisateur au jour 1, alors que des données continuent d’être chargées en cache, le système présente probablement un problème de sizing qui s’aggravera à mesure que le jeu de données se réchauffera. Monitorer la consommation mémoire par rapport à la limite d’allocation dès la connexion du premier utilisateur, et non au moment où la première alerte se déclenche, donne à l’équipe opérations les données de trajectoire nécessaires pour évaluer la situation.
En pratique : définissez un seuil d’alerte mémoire temporaire et plus sensible pendant les 48 premières heures suivant le go-live : 75 % au lieu de 85 %. La période de cold start est celle où apparaissent les schémas de consommation mémoire inattendus. Un seuil plus bas donne à l’équipe le temps d’investiguer avant que la situation ne devienne critique.
Planification des jobs batch : vérifier que le calendrier a été correctement transféré
La recréation des jobs dans S/4HANA est un processus manuel et une source fréquente d’incidents post go-live. Les trois modes d’échec les plus courants sont les jobs qui n’ont pas été recréés du tout, donc absents du planning, les jobs recréés avec de mauvaises affectations de groupes de serveurs, donc exécutés sur un serveur incapable d’absorber la charge ou ne disposant pas des autorisations nécessaires, et les jobs dont les dépendances prédécesseur/successeur n’ont pas été correctement configurées, donc lancés indépendamment au lieu de s’exécuter en séquence.
Le processus de vérification ne consiste pas à regarder une liste de jobs et à confirmer que les noms correspondent. Il consiste à lancer la première exécution planifiée de chaque job critique, à l’observer dans SM37 sur S/4HANA, à confirmer qu’il s’exécute sur le serveur attendu, qu’il se termine dans une plage de durée cohérente avec la baseline ECC et qu’il produit la sortie attendue. Pour les jobs Tier 1, cette vérification doit avoir lieu avant que les utilisateurs métier ne soient informés que le système est pleinement opérationnel.
Les jobs quotidiens peuvent être vérifiés dans les 24 premières heures. Les jobs moins fréquents, comme les jobs de reporting hebdomadaire ou les préparations de clôture mensuelle, sont plus difficiles à vérifier avant leur première vraie exécution. Pour ceux-ci, la vérification repose sur la documentation : confirmer que la configuration SM36 correspond à la spécification documentée lors de la capture des profils de jobs avant migration.
Les premières transactions métier : quoi surveiller et à quoi s’attendre
Les codes transaction les plus utilisés pendant les premières heures après le go-live sont ceux qui existaient dans ECC et dont le comportement a changé dans S/4HANA. VA01 pour la création de commandes clients, ME21N pour les commandes d’achat, FB60 pour les factures fournisseurs : ce sont des transactions que les utilisateurs métier connaissent par automatisme et dont ils remarqueront immédiatement tout comportement différent. Les régressions de temps de réponse sur ces transactions précises généreront des appels au help desk en quelques minutes.
Monitorer le temps de réponse dialog par code transaction, non pas sous forme de moyenne globale mais segmenté par transaction spécifique, est la vue de performance la plus utile opérationnellement pour le premier jour. Elle indique à l’équipe opérations quelle activité métier précise est lente, plutôt que d’indiquer que le système est globalement sous charge. Cette précision fait la différence entre une investigation de 15 minutes et une investigation de deux heures.
L’équipe opérations doit disposer avant le go-live d’une liste des 10 à 15 codes transaction les plus critiques pour le métier, avec leurs temps de réponse de référence dans ECC, et d’un monitoring configuré pour déclencher une alerte si l’un d’eux se dégrade de plus de 50 % par rapport à la baseline pendant les 48 premières heures.
Phase 4 : monitoring de stabilisation pendant les 30 premiers jours
Première clôture mensuelle sur S/4HANA : pourquoi elle exige un monitoring spécifique
Une clôture mensuelle sur un système en production depuis moins de quatre semaines est fondamentalement différente d’une clôture mensuelle sur un système de production stable. Les jobs batch s’exécutent pour la première fois dans S/4HANA avec des volumes réels issus d’un mois complet de transactions de production. Le système HANA traite des requêtes qu’il n’a jamais vues auparavant. Les temps d’exécution des jobs n’ont pas encore de baseline S/4HANA, seulement des données historiques ECC capturées avant migration.
Deux risques spécifiques sont plus élevés pendant la première clôture mensuelle qu’à tout autre moment par la suite. Le premier concerne la durée des jobs batch : des jobs qui duraient 45 minutes dans ECC peuvent prendre 25 minutes dans S/4HANA, ce qui est fréquent grâce aux avantages de performance in-memory de HANA, ou au contraire durer beaucoup plus longtemps à cause de différences de modèle de données ou de statistiques base de données manquantes sur le nouveau système. Sans monitoring, l’équipe ne découvre les écarts de durée que lorsqu’un job dépasse sa fenêtre d’exécution. Le second concerne la mémoire HANA : la clôture mensuelle génère des jeux de données de travail plus volumineux que les opérations quotidiennes, en chargeant des données qui n’ont peut-être pas été consultées depuis le go-live. La consommation mémoire pendant le traitement batch de clôture peut être nettement supérieure à celle observée pendant les premières semaines d’exploitation quotidienne.
La recommandation est de traiter la première clôture mensuelle comme un événement piloté, avec une surveillance monitoring explicite : des personnes assignées au suivi de la progression des jobs batch par rapport au planning, des métriques mémoire et I/O observées en temps réel et un processus d’escalade défini pour les jobs qui dépassent de plus de 30 % leur durée attendue.
Transférer le monitoring de l’équipe projet aux opérations : le handover qui échoue trop souvent
Dans presque tous les projets S/4HANA, il existe une période pendant laquelle l’équipe projet et l’équipe opérations gèrent le système simultanément. L’équipe projet a construit la configuration de monitoring, comprend pourquoi chaque seuil a été défini à ce niveau et sait quelles alertes risquent d’être de faux positifs pendant la fenêtre de stabilisation. L’équipe opérations exploitera le système à partir du troisième mois, mais elle est encore en phase d’apprentissage pendant les semaines une à huit.
Le handover qui échoue est celui où l’équipe opérations reçoit un accès à l’outil de monitoring et une courte démonstration, puis doit le gérer sans la connaissance institutionnelle qui a guidé la configuration. Les seuils définis de manière conservatrice pour la période de go-live ne sont jamais ajustés pour le régime stable. Les alertes pertinentes pendant la stabilisation restent configurées après la fin de cette phase et commencent à générer du bruit. L’équipe opérations finit par ignorer certaines catégories d’alertes, car elle ne sait plus si elles sont réelles ou héritées de la période projet.
Un document de handover utile pour le monitoring comprend trois éléments : la justification de chaque seuil, par exemple pourquoi 75 % a été choisi pour la mémoire plutôt que 85 % et quand ce seuil doit changer, la liste des alertes configurées pour la période de stabilisation et à revoir au jour 30, ainsi que les chemins d’escalade pour chaque catégorie d’alerte. Ce document n’a pas besoin d’être long. Il doit exister.
Checklist de préparation monitoring : quoi mettre en place avant le cutover ?
Le tableau ci-dessous organise les points de contrôle de préparation monitoring à travers les quatre phases du projet. Chaque point précise ce qu’il faut vérifier et pourquoi cette vérification est importante. Utilisez-le pendant les revues de préparation pré go-live afin de confirmer que la couverture de monitoring est en place avant l’ouverture de la fenêtre de migration.
| Point de contrôle readiness | Ce qu’il faut vérifier | Pourquoi c’est important |
|---|---|---|
| BASELINE PRÉ-MIGRATION, 6 à 8 semaines avant cutover | ||
| Baseline ECC/système source capturée | Temps de réponse dialog, charge moyenne des work processes, mémoire HANA, top 20 des transactions par nombre d’exécutions | Nécessaire pour valider les performances S/4HANA après le go-live. Sans cela, vous n’avez aucun point de comparaison. |
| Profils de durée des jobs batch documentés | Données historiques SM37 pour tous les jobs Tier 1 et Tier 2, y compris les variantes de clôture mensuelle | Les durées des jobs S/4HANA seront différentes. Vous avez besoin de baselines pour distinguer l’anormal de l’attendu. |
| Baselines de débit des interfaces capturées | Volume, fréquence et taux d’erreur de toutes les interfaces de production sur une période de 30 jours | Permet de détecter les régressions dans la couche d’intégration après le cutover. |
| Outil de monitoring connecté au système source | Connexion sans agent, utilisateur RFC autorisé, collecte de données active | Le monitoring doit tourner sur ECC avant le début de la migration afin que les données de baseline soient dans l’outil, pas dans un tableur. |
| MONITORING DE LA FENÊTRE DE CUTOVER, de T-48h à T+0 | ||
| Dernière clôture batch monitorée sur le système source | Tous les jobs batch Tier 1 sur ECC terminés avec statut FINISHED et spool vérifié | Le dernier run batch ECC est un jalon. Tout échec à ce stade affecte l’état d’ouverture des données dans S/4HANA. |
| Gel des interfaces confirmé et monitoré | Toutes les interfaces entrantes vers ECC arrêtées, files de messages vidées à zéro | Les messages résiduels en cours pendant le cutover créent des problèmes de réconciliation après le go-live. |
| Configuration du mode log HANA vérifiée | Mode log correctement défini pour la phase de migration selon les recommandations SAP | Un mode log incorrect pendant la migration peut générer des volumes de logs qui saturent avant la fin du cutover. |
| Progression de l’outil de migration SUM/DMO suivie | Monitoring actif des phases SUM ou DMO avec seuils de durée par phase | Les phases de migration longues sans monitoring sont des boîtes noires. Les alertes de durée permettent des décisions go/no-go. |
| Test de connectivité technique S/4HANA | Outil de monitoring connecté au système cible S/4HANA avant le go-live métier | La première alerte sur S/4HANA ne doit pas se produire directement en production. Testez la connexion pendant la phase de cutover technique. |
| GO-LIVE, de T+0 à T+24h | ||
| Profil mémoire HANA à la première connexion utilisateur | Mémoire utilisée vs limite d’allocation au moment où les premiers utilisateurs métier accèdent au système | Cold start, chargement initial des données et premières vraies requêtes créent un profil mémoire différent de tous les tests. |
| Planning des jobs batch vérifié dans S/4HANA | Tous les jobs Tier 1 et Tier 2 présents, libérés et planifiés avec les bonnes affectations serveur | Les jobs ECC ne se transfèrent pas automatiquement. La recréation manuelle introduit des erreurs qui n’apparaissent que lorsqu’un job manque sa fenêtre. |
| Premiers temps de réponse des transactions dialog | Comparaison à la baseline ECC capturée avant migration | La première heure d’activité utilisateur sur S/4HANA révèle les écarts de performance les plus critiques. |
| Monitoring des interfaces actif sur S/4HANA | Toutes les interfaces entrantes et sortantes reconnectées, premiers flux de messages confirmés | La réactivation des interfaces après cutover est manuelle et séquentielle. Le monitoring confirme que chaque interface traite réellement. |
| Routage des alertes vérifié | Alerte de test déclenchée et réception confirmée par l’équipe d’astreinte | Le routage configuré en environnement de test peut ne pas correspondre à la production. Vérifiez son bon fonctionnement avant le premier vrai incident. |
| FENÊTRE DE STABILISATION, de T+1 à T+30 jours | ||
| Premier run MRP monitoré | Durée, consommation mémoire, complétion du job batch et volume de sortie comparés à l’attendu | Le premier MRP de production sur S/4HANA est imprévisible. Il s’agit souvent du premier vrai test de charge du nouveau système. |
| Première clôture mensuelle monitorée | Tous les jobs batch de clôture suivis par rapport aux durées de baseline ECC | La clôture mensuelle sur un nouveau système est fondamentalement différente des opérations quotidiennes. Elle exige une attention monitoring spécifique. |
| Backlog de delta merge HANA suivi | Nombre de delta merge en attente et taux d’échec dans M_DELTA_MERGE_STATISTICS | Le volume d’insertions post go-live accélère souvent la croissance du delta store dans les premières semaines. Il faut le détecter avant que cela n’affecte les performances de requêtes. |
| Handover monitoring aux opérations documenté | Runbooks, justification des seuils et chemins d’escalade transmis à l’équipe opérations | Un handover projet sans justification documentée du monitoring laisse les opérations gérer des seuils qu’elles ne comprennent pas. |
Le monitoring est un livrable projet, pas une tâche post go-live
Les projets SAP qui connaissent les go-lives les plus fluides ont souvent un point commun : ils ont traité l’infrastructure de monitoring comme un livrable projet, avec son propre calendrier, ses propres critères d’acceptation et son propre point de validation. Pas comme quelque chose que l’équipe opérations installe après la mise en production métier du nouveau système.
L’argument en faveur de cette approche est simple. La fenêtre de go-live elle-même, le week-end de cutover, est le moment où vous avez le plus besoin de visibilité et celui où vous en avez le moins. La première semaine de production est le moment où les questions de performance sont les plus urgentes et où les données de comparaison avec la baseline sont les plus précieuses. Ces deux périodes nécessitent un monitoring construit, testé et validé avant le début de la migration.
Une plateforme de monitoring connectée à ECC six semaines avant le go-live, qui capture les baselines, apprend les durées normales des jobs et vérifie le routage des alertes, devient un outil radicalement différent pendant le go-live par rapport à une plateforme configurée pour la première fois le jour où les utilisateurs métier accèdent au nouveau système. L’effort technique nécessaire pour la connecter tôt est faible au regard de la valeur opérationnelle qu’elle apporte lorsque le système est sous pression et que l’équipe a besoin de réponses.
Redpeaks se connecte aux systèmes source ECC et cible S/4HANA sans agents ni transports, capture les baselines pré-migration et fournit une visibilité côte à côte pendant le go-live. Déployé dans les environnements RISE with SAP et on-premise.
Découvrez comment Redpeaks accompagne les migrations S/4HANA
