Rendre vos processus de changement plus Agile

Selon l’approche ITIL, le processus de gestion des changements se révèle utile, mais également laborieux et rigide. Comment s’y prendre pour le rendre plus Agile ? Dans cet article, je traite de la première partie du processus de gestion des changements, à savoir la manière d’aborder plus intelligemment les demandes de changement.

Agile, pour des changements standard ou non standard ?

Tout d’abord, une méthode Agile apportera un peu moins de valeur ajoutée à des changements standard qu’à des changements non standard. L’idée de la méthode Agile, c’est de permettre de gérer l’imprévisible. Or, les changements standard sont justement conçus dans la plus grande prévisibilité.

Prenez une demande pour un ordinateur portable : vous allez en chercher un dans le stock, vous installez le système d’exploitation et un certain nombre d’applications et vous le livrez. Aucune surprise.

Par contre, pour les changements non standard, la méthode Agile peut être salutaire. C’est pour cette raison que je me concentrerai, dans ce blog, sur les changements non standard.

Quel est le problème lié à la gestion des changements ITIL ?

La gestion des changements a été conçue pour assurer le contrôle de l’exécution des changements dans une infrastructure IT. Elle empêche, par exemple, une perturbation du réseau lors du remplacement d’un serveur. Le processus intègre ainsi toutes sortes de vérifications et de mécanismes de contrôle.

Ces contrôles sont bien sûr utiles, mais ils alourdissent considérablement le processus des changements non standard et présentent des désavantages pour de nombreuses entreprises :

L’introduction d’une demande de changement exige beaucoup de travail. Il faut alors penser à une solution technique, analyser les répercussions, évaluer les risques et estimer des coûts. Sans savoir si le changement sera effectivement bien exécuté, ni si les données seront encore d’actualité le jour de l’implémentation du changement.
Le CAB perd beaucoup de temps à évaluer les demandes de changement. Dans certaines entreprises, le CAB passe en revue toutes les demandes de changement, peu importe leur dimension ou leur degré d’urgence. Parfois, six à huit membres du CAB se retrouvent à discuter d’une demande pourtant relativement simple.
Le processus de changement est un travail à sens unique. Avant d’introduire une demande de changement, celle-ci doit être parfaitement cadrée. Après approbation, la seule option est de mettre le projet à exécution. S’agit-il d’une perspective novatrice ? Un changement de cap en cours de route n’est pas vraiment envisageable.
Le processus de changement dure plus longtemps que nécessaire. Ces mécanismes de contrôle sont autant de sources de retard dans le processus. Parfois, tout est prêt pour opérer un changement, mais vous vous souvenez alors qu’il faut « encore obtenir l’approbation du CAB, qui ne se réunit pas avant mercredi prochain. »

Une demande de changement, mais alors sans formalités administratives superflues.

Je ne suis pas en train de dire que ces processus et contrôles ne sont pas nécessaires. Bien au contraire, je conseille souvent aux organismes d’utiliser des formulaires de demande de changement. Il est toujours judicieux d’effectuer une forme d’analyse des répercussions sur les activités pour éviter les dérapages éventuels lors de la mise en place des changements.

Mais est-il nécessaire de remplir systématiquement tout le formulaire de demande de changement ? A priori, non. Il convient de trouver le juste équilibre entre le besoin de couvrir les risques majeurs et la confiance à accorder au service IT dans les décisions à prendre dans le cadre de son travail. Une approche agile de la gestion des changements pourra aider sur ce plan.

Vous voulez adopter une méthode plus agile face à vos nombreuses demandes de changement ? Il convient donc essentiellement d’adapter le rôle du gestionnaire des changements et du CAB.

Le gestionnaire des changements est le responsable du carnet reprenant les demandes de changement.

Généralement, le gestionnaire des changements est avant tout un gestionnaire de processus. La méthode Agile implique que le gestionnaire des changements intervienne davantage sur le fond et ait un rôle plus social. Les tâches d’un gestionnaire des changements Agile sont les suivantes :

Il dresse un inventaire et établit les priorités des souhaits des parties prenantes. Il inscrit ces demandes de changement dans un carnet. Ce carnet n’est autre qu’une liste de travaux établie selon leur priorité. Pour établir correctement les priorités, il convient d’avoir une représentation correcte de l’entreprise. Il approfondit ses connaissances relatives aux différentes demandes de changement et compare les intérêts et les problèmes. Il revoit régulièrement les priorités, par exemple une fois toutes les deux semaines.
Il s’assure que toutes les demandes de changement soient suffisamment bien décrites. Il n’est pas nécessaire de remplir totalement un formulaire pour chaque demande de changement. Il veille à disposer de suffisamment d’informations pour pouvoir prioriser les demandes de changement. Il se pose les questions suivantes : quel problème la demande de changement doit-elle résoudre ? Quelles sont les solutions envisageables ? Quel est le champ d’application estimé ? Les éléments à ne pas encore déterminer à ce stade sont la solution, le plan d’exécution et le budget détaillés.
Il veille à ce que les cinq principales demandes de changement soient détaillées. Il utilise le principe selon lequel plus la tâche se trouve loin dans le carnet, moins sa description sera détaillée. Il ne conviendra d’établir une description approfondie de la demande que pour les demandes de changement à traiter à courte échéance. Seules ces demandes de changement devront être expliquées au CAB.

Le CAB : un contenu moins approfondi, mais plus stratégique.

Si le gestionnaire de changement consacre davantage de temps à l’inventaire et à la priorisation des demandes, il convient de se demander quelles seront les tâches du CAB. Ce dernier continuera à jouer un rôle important, mais davantage stratégique dans le processus. Les tâches du CAB sont les suivantes :

Évaluer les demandes de changement les plus importantes. En substance, cette tâche reste la même : le CAB analyse si les demandes sont complètes et peut refuser certaines demandes de changement. La différence vient du fait que le CAB n’aura sous les yeux que les demandes de changement dont le niveau de priorité est le plus élevé, ce qui lui fera gagner énormément de temps.
Se mettre d’accord sur les priorités établies dans le carnet. Le gestionnaire de changement a déjà priorisé les demandes de changement. Il appartient ensuite au CAB de déterminer s’il est d’accord avec les priorités établies. Si le travail a été bien préparé, le CAB apportera peu de modifications.
Donner ou non le feu vert aux échéances. Dans le cas des processus classiques, le CAB approuve ou refuse le projet avant son lancement, par exemple lors de la phase de test. La méthode de travail Agile implique la livraison d’un nouveau service en différentes parties pour ne plus se heurter à un « big bang ». Quand le CAB doit-il donc donner son accord ? Le moment diffère en fonction de chaque livraison. L’équipe IT et le CAB se concertent dès lors pour connaître le moment d’implication du CAB dans la mise en place des changements.

Mettre en place des changements de manière Agile

Une demande de changement a été approuvée et reçoit le niveau de priorité le plus élevé. Tout est prêt. Comment mettre en place un changement de manière Agile ? Vous en apprendrez davantage à ce sujet dans mon article Mettre en place une gestion Agile des changements.

Lire la suite ?

Téléchargez gratuitement l’e-book et découvrez ce dont vous aurez besoin pour améliorer la flexibilité de votre service IT.