La dette opérationnelle dans un paysage SAP s’accumule une décision raisonnable après l’autre. La route de transport hotfix a été créée pendant une urgence et elle était justifiée à ce moment-là. La connexion RFC directe a été ajoutée lorsque le middleware était indisponible. Elle fonctionnait, donc elle est restée. Le rôle d’autorisation a été copié à partir de celui configuré par le consultant précédent, parce qu’en reconstruire un aurait demandé une semaine supplémentaire.
Pris séparément, aucun de ces choix n’était nécessairement une erreur. La dette vient de leur accumulation au fil des années.
Les signes ci-dessous ne correspondent pas à des défaillances catastrophiques. Ce sont des schémas d’architecture qui augmentent progressivement le coût opérationnel, ajoutent des heures d’investigation à chaque incident et rendent chaque changement système plus complexe qu’il ne devrait l’être.
Ils sont tous facilement reconnaissables. La plupart des paysages SAP en présentent au moins trois.
Signe 1. SM59 contient des destinations RFC qui échouent au test de connexion et personne ne sait si elles sont encore nécessaires
Ouvrez SM59 dans votre système de production. Lancez le test de connexion sur chaque destination RFC de type 3. Comptez celles qui échouent. Puis demandez à l’équipe lesquelles peuvent être supprimées sans risque.
Dans la plupart des paysages exploités depuis plus de quatre ans, la réponse la plus honnête est : nous n’en sommes pas certains.
Des connexions ont été ajoutées lors de projets, d’intégrations urgentes, de migrations ou de missions de conseil terminées depuis plusieurs années. Le système cible a peut-être été décommissionné. Mais il peut aussi exister encore et recevoir activement des appels provenant d’un programme que le test de connexion ne permet pas d’identifier.
Le problème opérationnel ne vient pas directement de ces connexions mortes. Il vient du réseau de dépendances invisibles qu’elles représentent.
Lorsqu’un système connecté est décommissionné, les personnes qui prennent la décision ne savent pas nécessairement que trois destinations RFC en production pointent encore vers celui-ci. Elles le découvrent lorsqu’une interface tombe en panne et que l’investigation remonte jusqu’à une destination qui tente toujours de contacter un serveur qui n’existe plus.
Un audit SM59 documentant chaque destination, son propriétaire, la date de son dernier appel réussi et le processus métier qu’elle supporte demande environ une demi-journée. Il permet d’éliminer durablement cette ambiguïté et de distinguer les connexions pouvant être supprimées des véritables dépendances opérationnelles qui doivent être monitorées.
Signe 2. Le planning des batchs existe dans SM36, dans un fichier Excel et dans l’outil de gestion des services, mais aucune version ne correspond
C’est l’une des formes les plus courantes de dette opérationnelle dans la gestion des batchs SAP.
Le planning officiel se trouve dans SM36. Un projet a créé un fichier de suivi parallèle il y a trois ans, qui n’a plus été mis à jour depuis le changement de consultant. L’ITSM contient des tâches récurrentes pour les jobs les plus critiques, ajoutées pour suivre les SLA, mais elles reflètent le planning tel qu’il existait lors de leur création, et non aujourd’hui.
Lorsqu’un job est modifié, une ou deux de ces trois sources sont mises à jour. Les autres dérivent.
Un job déplacé de 3 h à 2 h peut toujours disposer d’une tâche ITSM vérifiant son achèvement à 4 h 30, simplement parce que personne ne l’a mise à jour. Le contrôle passe donc chaque matin sur la base d’une heure de référence qui n’est plus la bonne.
Le coût opérationnel apparaît lorsqu’un problème survient.
L’investigation utilise le fichier Excel ou la tâche ITSM comme référence plutôt que SM36, parce que c’est plus rapide à consulter. La référence est incorrecte. L’analyse part dans la mauvaise direction.
Quarante-cinq minutes d’investigation supplémentaires peuvent sembler anecdotiques sur un incident isolé. Elles deviennent beaucoup plus visibles lorsqu’on additionne toutes ces heures sur un trimestre.
Signe 3. La route de transport « hotfix » est utilisée plus souvent que le parcours standard développement vers production
Chaque paysage de transport SAP possède, ou a possédé, une route hotfix. Elle permet de transférer rapidement un transport depuis un système de correction vers la production en contournant le passage habituel par la QA.
Cette route existe pour de vraies urgences : une note SAP à appliquer immédiatement, une évolution réglementaire avec une date d’effet fixe ou une correction qui ne peut pas attendre le prochain cycle de release.
Le signe de dette opérationnelle apparaît lorsque cette route devient le chemin utilisé par défaut pour une part importante des transports.
L’équipe cesse de suivre le parcours développement, QA, production pour la majorité des changements parce que la QA a trois versions de retard, parce que le cycle de test est plus long que ce que le métier accepte d’attendre ou parce que le processus de validation de la route standard est devenu un goulot d’étranglement.
À ce stade, le quality gate n’est plus réellement un gate. Il devient une étape facultative pour les changements considérés comme non urgents, ce qui, dans la pratique, finit souvent par représenter très peu de changements.
La conséquence n’apparaît pas directement dans le système de transport, qui indique simplement que les transports ont été approuvés et importés.
Elle apparaît lors des incidents de production, lorsqu’un changement n’a pas été testé dans un environnement suffisamment proche de la production et qu’une erreur qui aurait dû être détectée en QA l’est finalement par un utilisateur.
Signe 4. Les systèmes de qualité et de production utilisent des versions HANA différentes ou leurs volumes de données diffèrent de plus d’un ordre de grandeur
La QA existe pour détecter les problèmes avant qu’ils n’atteignent la production. Sa valeur dépend donc directement de sa capacité à représenter les conditions réelles de production.
Un système QA utilisant une version plus ancienne de HANA, ou contenant seulement 15 % du volume de données de production, n’offre pas le même niveau de validation qu’un environnement proche de la production.
Le scénario classique est celui du problème impossible à reproduire en QA.
Une dégradation de performance qui n’apparaît qu’avec les volumes de données réels ne peut pas être testée sur une copie contenant seulement 15 % des données. Un changement de comportement lié à une différence de version HANA entre QA et production n’apparaît qu’après la mise à jour de la production.
Dans les deux cas, il faut un incident en production pour découvrir le problème.
La réponse organisationnelle est alors : « cela aurait dû être détecté en QA ». La réponse technique est : « cela ne pouvait pas être détecté avec la configuration actuelle de la QA ».
Maintenir les environnements hors production suffisamment proches de la production demande du budget, de la planification et une vraie discipline opérationnelle.
Les budgets consacrés aux copies régulières des systèmes et à l’alignement des versions sont pourtant souvent réduits au profit de dépenses projet plus visibles.
La dette augmente chaque fois qu’un incident de production aurait pu être détecté dans un environnement QA correctement maintenu et ne l’a pas été.
Signe 5. Les rôles d’autorisation sont des copies de copies et personne ne sait expliquer pourquoi certaines transactions y figurent
Demandez à l’administrateur des autorisations pourquoi un code transaction spécifique est inclus dans un rôle critique.
Si la réponse est « il était déjà présent lorsque nous avons copié le rôle » ou « je pense qu’un consultant l’avait ajouté pour un besoin particulier », votre paysage présente une dette liée aux autorisations.
Le mécanisme est simple.
Un rôle est créé en copiant un rôle standard SAP. Il est ensuite modifié pour répondre à un besoin spécifique. Plus tard, quelqu’un a besoin d’un rôle similaire et copie le rôle modifié au lieu de repartir du standard.
Cette copie hérite de tous les ajustements précédents, y compris des autorisations qui correspondaient au premier cas d’usage mais qui sont inutiles pour le second.
Le deuxième rôle est ensuite copié pour un troisième besoin.
À la quatrième génération, le rôle contient des autorisations provenant de trois cas d’usage différents, qui ont eux-mêmes évolué depuis leur création, et personne n’est réellement capable d’en retracer toute la logique.
Ce n’est pas nécessairement une faille de sécurité au sens d’un accès non autorisé.
C’est une défaillance de gouvernance qui rend les revues d’accès moins fiables et les constats d’audit presque inévitables.
Le rôle contient davantage d’autorisations qu’il ne devrait, pour des raisons que personne ne peut documenter, dans un système qui traite potentiellement des transactions financières critiques.
Signe 6. Les développements ABAP spécifiques ne sont pas documentés et la personne qui les a créés n’est plus dans l’entreprise
L’enhancement existe. Il modifie le comportement standard de SAP. Il fonctionne en production depuis quatre ans.
Puis un nouvel Enhancement Package ABAP est installé et une fonction standard SAP évolue. L’enhancement cesse de fonctionner.
L’équipe ouvre le code pour le corriger et découvre qu’il ne contient aucun commentaire, utilise des techniques non standard et accède directement aux tables de la base de données alors que les API SAP standard auraient permis de le faire autrement.
La correction demande trois fois plus de temps que sur un développement correctement documenté, parce que l’équipe doit d’abord reconstruire l’intention initiale avant même de pouvoir concevoir le correctif.
Le risque du correctif est également plus élevé puisque les contraintes de conception originales sont inconnues.
Ce problème s’aggrave à chaque upgrade du paysage, à chaque changement dans un programme standard dont dépend l’enhancement et à chaque fois qu’un nouveau consultant découvre dans le code un comportement non documenté dont le métier dépendait sans même savoir qu’il était spécifique.
La dette opérationnelle n’est pas l’existence de développements ABAP custom.
C’est l’existence de développements ABAP custom sans documentation.
Le premier est un choix d’architecture. Le second est une dette de maintenance dont le coût augmente à chaque changement du système.
Signe 7. La liste des « problèmes connus » s’allonge chaque trimestre depuis deux ans et ne diminue jamais
Toutes les équipes SAP Operations ont une liste de problèmes connus.
Elle peut contenir l’historique des jobs SM37 en échec provenant d’un projet de migration annulé en 2021 qui devrait être nettoyé. Une destination RFC qui pointe encore vers un CRM décommissionné et apparaît toujours dans SM59. Un client de développement ouvert accidentellement six mois plus tôt et jamais reverrouillé. Un job de fond annulé manuellement pendant un incident et jamais replanifié.
La liste grandit parce que la résolution de ces éléments demande du temps et qu’ils sont toujours moins prioritaires que le travail en cours.
Chaque problème est suffisamment petit pour être reporté.
Pris ensemble, ils constituent le registre explicite de la dette du paysage : une liste documentée de situations connues comme incorrectes que l’équipe a fini par accepter comme du bruit de fond permanent.
Le coût opérationnel ne vient pas seulement des problèmes eux-mêmes.
Il vient de leur impact sur les investigations.
Lorsqu’une panne apparaît dans un environnement avec 40 problèmes connus, l’une des premières questions est de déterminer si le nouvel incident est lié à l’un d’entre eux.
Cette étape de désambiguïsation, vérifier si le nouvel incident est lié à un problème existant, ajoute du temps à chaque investigation lorsque la liste est devenue suffisamment longue pour servir de véritable référentiel plutôt que de courte liste d’exceptions.
| En pratique : une liste de problèmes connus qui n’a pas diminué depuis deux ans n’est plus réellement un backlog. Elle signifie que ces situations sont devenues permanentes. La bonne approche n’est pas nécessairement de tout résoudre immédiatement, mais de décider explicitement quels éléments peuvent être tolérés durablement, avec une justification documentée, et lesquels doivent être corrigés selon un calendrier défini. Une liste activement gérée, même lentement, génère moins de friction opérationnelle qu’une liste qui s’allonge indéfiniment parce que son contenu est progressivement considéré comme normal. |
|---|
La dette opérationnelle dans un paysage SAP n’est pas un accident et ne résulte généralement pas de mauvaises décisions.
Elle est le résultat cumulé de choix raisonnables pris sous de vraies contraintes, puis conservés au fil du temps sans mécanisme permettant de les réévaluer et de les corriger avant qu’ils ne s’accumulent.
L’audit permettant d’identifier ces signaux ne nécessite pas nécessairement une longue mission d’architecture.
Il suffit de regarder le paysage avec une question différente : quels schémas augmentent réellement le coût opérationnel, plutôt que quels éléments sont parfaitement élégants d’un point de vue architectural ?
La plupart des signaux décrits ici sont visibles en une demi-journée en consultant les bonnes transactions : SM59, SM36, SE01, PFCG et la propre liste de problèmes connus de l’équipe.
L’essentiel est ensuite de traiter les constats comme des éléments exploitables, et non comme l’état normal d’un système exploité depuis plusieurs années.
La dette opérationnelle ne cesse pas de s’accumuler d’elle-même.
Redpeaks fait remonter en continu plusieurs de ces indicateurs de dette opérationnelle : état des connexions RFC, intégrité des plannings batch, changements d’autorisations et dérive de configuration par rapport aux baselines documentées.
Voir les fonctionnalités de monitoring de la santé du paysage SAP
