Lundi matin, la boîte de réception du gestionnaire des changements contient des dizaines de messages. Certains sont des demandes d'approbation pour des interruptions, d'autres sont des réponses à celles-ci, et encore d'autres sont des questions transmises du type « pourriez-vous jeter un œil ? ». Certains propriétaires de services ont répondu « OK », d'autres n'ont pas répondu du tout, et un a répondu à seulement la moitié des destinataires. La fenêtre de maintenance est jeudi, et personne ne sait avec certitude quels changements sont approuvés.
Pour les ingénieurs, cela signifie une incertitude quant à savoir s'ils peuvent procéder. Pour les propriétaires de services, cela signifie un flux de messages sans contexte : ils ne savent pas exactement ce qui va se passer ou ce que cela signifie pour leur service. Et si quelque chose ne va pas plus tard, déterminer qui a approuvé quoi et sur quelle base devient un travail de détective.
Pourquoi l'e-mail est le mauvais outil pour les approbations
L'e-mail est bien pour la communication. Il est un mauvais outil pour les décisions qui doivent être traçables.
- Pas de vue d'ensemble. Personne ne peut voir en un seul endroit ce qui attend qui et depuis combien de temps.
- Pas de contexte. L'approbateur reçoit une description du travail, mais pas des informations sur les services qui seront indisponibles.
- Destinataire incertain. Qui devrait approuver l'interruption : le propriétaire de l'application, le chef d'équipe ou quelqu'un de l'entreprise ?
- « OK » n'est pas une décision. Une approbation par e-mail n'a pas de lien clair avec une version spécifique du changement, et les refus sont souvent simplement absents. La réponse ne vient jamais.
- Processus différents, chemins différents. Les changements sont approuvés d'une manière, les demandes d'une autre, et la gestion des correctifs d'une troisième.
Une meilleure façon de gérer les approbations
Un processus d'approbation sain répond à trois questions : qui décide, sur quelle base, et qu'est-ce qui se passe s'ils ne le font pas. Nous recommandons :
- Un seul endroit pour chaque demande d'approbation, quelle que soit la procédure dont elle provient.
- Le consentement vient de celui qui est affecté : le propriétaire du service impacté, et non celui qui a été simplement en copie de l'e-mail.
- L'approbateur voit l'impact. Il sait quels services seront indisponibles ou dégradés, et quand.
- Un refus a une raison. Le demandeur sait quoi changer sans avoir à poursuivre qui que ce soit.
- Une rigueur proportionnée. Les changements de routine ne nécessitent pas de CAB ; les changements risqués si.
Comment Eywo Stratum gère cela
Eywo Stratum rassemble chaque demande d'approbation dans une seule file d'attente « En attente d'approbation ». Elle contient les interruptions provenant des changements, des demandes de service, des accords de correctifs et des propositions de liste de prix. Une seule règle détermine qui est le propriétaire pour tous ; si un service n'a pas de propriétaire, le gestionnaire des changements décide.
Avant qu'un changement ne soit soumis, Stratum calcule son impact : quels services et applications seront indisponibles ou dégradés. L'interruption est alors approuvée par le propriétaire du service affecté, avec une connaissance complète de ce que implique le travail. Un changement ne peut être planifié que dans une fenêtre de maintenance, en dehors des gels de changements et sans conflit avec d'autres changements.
Le niveau de scrutiny est défini par des modèles de changement :
- changements standard pré-approuvés pour les travaux de routine récurrents,
- changements normaux approuvés par le propriétaire du service, le gestionnaire des changements et, si nécessaire, le CAB,
- changements d'urgence pour les situations qui ne peuvent pas attendre.
Chaque refus est accompagné d'une raison, afin que le demandeur sache quoi corriger. Chaque décision est écrite dans la traçabilité, et les notifications sont envoyées par e-mail ou à Slack selon les règles. L'e-mail devient un moyen d'alerter les gens, et non l'endroit où les décisions sont prises.
Conclusion
L'approbation des changements n'a pas à être un échange interminable de messages. Lorsque chaque demande est regroupée en un seul endroit, l'approbateur peut voir l'impact et chaque refus a une raison, les décisions sont prises plus rapidement et avec plus de confiance. Les ingénieurs savent où ils en sont, et les propriétaires de services peuvent être sûrs que rien n'arrive à leur service sans leur connaissance.
La file d'approbation unique, les modèles de changement, le calcul de l'impact et l'approbation des interruptions par les propriétaires de services font partie de l'édition Standard.
Eywo Stratum Standard
Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés.