Le changement est prêt, les ingénieurs ont une fenêtre de maintenance, et tout ce qui manque est l'approbation pour la panne. Mais qui devrait signer ? Le propriétaire du service d'origine a rejoint un autre département, son successeur ne sait pas qu'il a hérité du rôle, et le chef d'équipe dit que ce n'est pas son appel. La demande voyage de boîte de réception en boîte de réception, et la fenêtre expire.
La même chose se produit avec les incidents, les demandes et les audits. Un auditeur demande qui a approuvé une intervention particulière, et la réponse est retrouvée dans d'anciennes discussions de courriel. Pour le personnel opérationnel, cela signifie une attente inutile et le sentiment de porter une responsabilité que personne n'a déléguée formellement. Pour les propriétaires de services, cela signifie le risque d'apprendre que des travaux ont été effectués sur leur service après coup.
Pourquoi la responsabilité est floue
La plupart des organisations ont un document qui décrit qui est responsable de quoi. Le problème est qu'il vit à part du outil où le travail se fait réellement.
- Une matrice RACI dans un tableur n'est pas reflétée dans les autorisations. La personne marquée « responsable » ne peut souvent approuver quoi que ce soit dans le système, et vice versa.
- La propriété est ambiguë. Parfois, le propriétaire est enregistré sur le service, parfois sur l'application, parfois sur l'équipe, et chaque processus en choisit un différent.
- Il n'y a pas d'approbateur de secours. Lorsqu'un propriétaire est absent ou non attribué, le processus s'arrête.
- Les autorisations sont trop larges. Les gens voient soit tout, soit rien, de sorte que les rôles sont accordés plus largement « au cas où ».
Une meilleure façon de penser à la propriété
La responsabilité n'est utile que lorsque le système en est conscient et l'applique. Nous suggérons quelques principes :
- Une règle de propriété pour chaque processus. Approuver une panne, une demande ou une liste de prix devrait suivre la même logique.
- Il y a toujours un décideur de secours. Si aucun propriétaire n'est attribué, il est clair à l'avance qui décide.
- Les rôles ont une portée. Une autorisation s'applique à un client spécifique, une équipe ou un élément, et non à l'ensemble du système.
- RACI et autorisations doivent correspondre. Quiconque est responsable de quelque chose a besoin des droits pour agir sur cela, et personne d'autre ne devrait les avoir.
- Chaque décision est traçable. Qui, quand et pourquoi.
Comment Eywo Stratum gère cela
Dans Eywo Stratum, chaque service a un propriétaire, et une règle détermine qui est le propriétaire. La même règle s'applique à tous les processus qui nécessitent un consentement : pannes dans les changements, demandes, accords de correctifs et propositions de liste de prix. Tous ces éléments atterrissent dans une seule file d'attente « En attente d'approbation ». Si un service n'a pas de propriétaire, le gestionnaire des changements décide en tant qu'approbateur de secours, de sorte que rien ne se bloque. Un rejet est toujours accompagné d'une raison.
Les autorisations sont basées sur 14 rôles avec une portée : tout, un client, une équipe ou un élément spécifique. Les gens ont exactement les droits que leur rôle nécessite. Stratum comprend également une matrice RACI avec une vérification de cohérence par rapport aux autorisations. Elle signale quiconque est répertorié comme responsable dans la matrice qui n'a pas le rôle correspondant dans le système, et vice versa.
Chaque décision est écrite dans un journal d'audit conservé pendant cinq ans. Lorsqu'un auditeur demande qui a approuvé quelque chose, la réponse prend des moments, et non des jours. Lors du déploiement, la vérification de l'état de préparation opérationnelle vérifie, entre autres choses, que les services ont des propriétaires attribués et que les rôles sont en place.
Conclusion
La propriété claire n'est pas de la bureaucratie. Elle protège les gens. Les ingénieurs savent qui demander. Les propriétaires de services savent que rien ne se passe sur leur service sans leur connaissance. Et l'organisation peut montrer à tout moment qui était responsable de quoi. Tout ce qu'il faut, c'est que la responsabilité vive à l'intérieur du système plutôt que dans un tableur à côté.
La propriété du service, les rôles avec une portée, la vérification de cohérence RACI et le journal d'audit font partie de l'édition Standard.
Eywo Stratum Standard
Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés.