Conseil TI, Formation & Placement

L’agilité en gestion des services informatiques – Étape 1 : Simplifier

La semaine dernière nous avons découvert comment s’articule l’agilité en gestion des services informatique. Cette semaine nous détaillons la première des trois étapes pour arriver à faire de l’agilité en gestion des services informatiques (ITSM).

Étape #1 : Simplifier

L’approche du Lean IT, permet de simplifier les processus de gestion informatique et surtout de les remettre au goût du jour en devenant compatibles avec les modèles de livraison Agile. Par exemple, dans la nouvelle pratique d’habilitation des changements de ITIL® 4, nous disposons d’un processus de gestion du cycle de vie des changements qui fait la distinction entre les changements normaux ou manuels, et les changements standards sur logiciels qui proviennent des équipes d’ingénierie et qui sont gérés de manière automatisée.
 
Une autre manière de simplifier serait d’utiliser la technique de l’essaimage (swarming en anglais) pour le Centre de service, afin de pouvoir résoudre plus rapidement les incidents, en particulier les majeurs. Cette technique consiste à faire venir tous les experts ensemble au même endroit (un pont téléphonique par exemple), puis après avoir effectué le diagnostique initial, ne garder que ceux qui seront directement impliqués dans la résolution de l’incident.
 
Pour simplifier les étapes d’approbation des changements, ITIL® 4 préconise de définir une autorité des changements à qui déléguer les approbations, plutôt que de s’appuyer sur un Comité consultatif des changements (le fameux CAB) rigide.
 
L’autorisation peut alors se faire dès que le changement sera prêt à être évalué, et que les tests auront été terminés. Les approbations sont collectées au fil de l’eau, par exemple, auprès des propriétaires de produit (Product Owner) qui pourront approuver les changements standard logiciels au cours de la journée. Les changements de faible priorité peuvent alors être approuvés par un gestionnaire des changements (Change Manager), ou s’il s’agit d’un changement plus large, par le propriétaire du service lui-même.
 
ITIL® 4 préconise d’utiliser des modèles de changement afin de faciliter et de standardiser la saisie et le traitement de tels changements. Ceci, toujours dans un soucis d’efficacité et d’industrialisation afin d’éliminer le gaspillage (l’équivalent du Muda en Lean IT).
 
Les modèles de changements, qui seront configurés dans l’outil ITSM, combinent formulaire et flux de travail (workflow). Ainsi, par exemple, pour qu’un propriétaire de produit puisse pré-approuver un changement logiciel standard qui viennent de DesOps, le changement devra avoir été vérifié comme :
  1. Contenant du code certifié en provenance de l’équipe d’ingénierie du produit;
  2. Ayant un impact limité sur les autres composantes ou produits (la CMDB y aidera);
  3. Ayant une preuve de réussite des tests d’assurance qualité.
Cette approche favorise la « confiance à priori » et la « vérification à postériori », ce qui permet au Product Owner ou au Service Owner d’approuver le changement tant qu’il demeure à l’intérieur des limites convenues (ex : temps de réponse du système < 1 sec.).
 
Dans une approche agile, le CAB n’a plus sa place comme approbateur. Par contre, il peut agir comme comité de surveillance des changements, déterminer les raisons d’un échec et déclencher le processus d’amélioration continue.
 
Les changements doivent être saisis dans l’outil ITSM, qui devrait lui-même avoir une interface automatique avec l’outil DevOps. Deux outils populaires tels que ServiceNow (ITSM) et Jira (DevOps) ont des interfaces natives qui leur permettent d’échanger de l’information.
Pour rationaliser les pratiques ITSM il faut adopter une approche coordonnée. En particulier, veiller à ce que les processus clés, tels que la gestion des incidents, des requêtes, des changements, soient aussi simples que possible. Pour simplifier, ITIL® 4 nous enjoint d’utiliser la technique de cartographie de la chaîne de valeur qui permet d’identifier les goulots d’étranglement ainsi que les contraintes, puis d’éliminer les étapes et activités inutiles.
 
Il faudra ensuite mener des ateliers pour identifier les préoccupations sur la façon dont chaque processus est exécuté. Ces préoccupations peuvent porter sur l’organisation elle-même, sa culture, la présence (ou l’absence) d’outils, les processus comme tels, etc.
 
Puis il faudra régulièrement s’assurer que les pratiques ITSM reflètent la réalité du terrain, qu’elles soient bien gouvernées (ex: les politiques sont à jour et communiquées), et que la discipline d’amélioration continue soit en place.
 
Dans notre prochain article, nous détaillerons en quoi consiste la seconde étape d’arrimage entre ITSM et agilité, c’est à dire lorsqu’il s’agit de résoudre les problèmes inter-culturels entre les équipes DevOps et ITSM !
Vous souhaitez en savoir plus sur le Lean IT ? Venez vous certifier Lean IT Foundation avec IT Chapter.
 
Votre organisation désire simplifier ses processus de gestion des services TI, ou sélectionner puis implémenter un nouvel outil ITSM ? Faites appel aux consultants ITSM d’IT Chapter, c’est une garantie pour le succès de votre initiative ITSM.
 

PARTAGER CE POST

Partager sur facebook
Partager sur google
Partager sur twitter
Partager sur linkedin
Partager sur pinterest
Partager sur print
Partager sur email

Références

  • My AXELOS / Best Practices / ITIL® – IT Service Management
  • PeopleCert DevOps Fundamentals
  • Inspiration et traduction libre de l’article de Mark Cleary « 3 Steps to Agile IT Service Management » Gartner – 27 mai 2020.