Un des aspects inévitables de la gestion des services TI (ITSM) est le changement. Les demandes de changements se produisent que vous le vouliez ou non, et ça peut même être une bonne chose. Les changements en ITSM sont une partie saine et nécessaire des affaires de toute entreprise publique ou privée.
Par contre, si les demandes de changement ne sont pas traitées adéquatement, elles peuvent engendrer des problèmes non négligeables pour votre équipe ou même votre organisation complète. Nous avons aussi remarqué que souvent, ce n’est pas le changement ITSM en soi qui cause des problèmes. C’est plutôt un processus peu fiable de la gestion des demandes de changements qui fait plus souvent dérailler vos opérations. Le changement fait partie de toutes les industries, du transport au commerce, municipales ou l'éducation, chaque organisation fait face aux changements constants du monde d’aujourd’hui.
Heureusement, vous n’avez pas besoin d’une politique de gestion du changement d’une centaine de pages pour bien faire les choses. En fait, le plus simple, le mieux.
Explorons ce qui constitue une bonne demande de changement et découvrons notre processus de demande de changement en cinq étapes qui peut s’adapter aux besoins de tous, peu importe l’organisation.
Une demande de changement est une proposition formelle de modification d’un aspect d’un projet convenu, d’un service TI ou de toute autre opération d’affaires. Les demandes de changement peuvent provenir de vos équipes internes, de vos clients, de vos partenaires d’affaires ou d’autres parties prenantes.
Un processus de demande de changement (RFC ou « request for change ») fiable vous permettra d’améliorer votre efficacité interne, de réduire les risques pour votre organisation et de mieux aligner vos unités d’affaires. Les demandes de changement (article disponible en anglais seulement) sont un élément essentiel de la gestion du changement, le principe au cœur de l’ITSM. La demande de changement est la première étape de documentation qui vous aide à établir une trace écrite numérique. Celle-ci vous permet de garder un œil sur les changements apportés à des systèmes complexes qui pourraient avoir des conséquences inattendues, mineures ou majeures, à long terme.
Vous pouvez choisir de créer vos propres catégories, mais en général, selon les meilleures pratiques de l’ITSM, les demandes de changement sont catégorisées comme étant standards, normales ou urgentes.
Les changements standards ont des conséquences bien maîtrisées, généralement soit parce qu’ils sont de faible envergure et que toutes les variables sont prises en considération, soit parce qu’ils sont récurrents, à faible risque et bien documentés. Ainsi, les changements standards peuvent souvent être traités immédiatement et ne nécessitent pas d’autorisation supplémentaire.
Par exemple, demander une plus grande capacité de stockage dans l’environnement cloud de votre entreprise est souvent une requête standard. Tous les systèmes impliqués sont bien maîtrisés, ainsi que l’envergure et les conséquences de ce changement.
Les changements normaux peuvent être planifiés selon un ou plusieurs facteurs et nécessitent toujours une autorisation. Ils impliquent des changements nouveaux ou à grande portée affectant vos opérations ou votre infrastructure. Ils sont « normaux » dans le sens qu’ils doivent passer à travers le processus habituel de gestion de demandes de changement, soit la révision, l'analyse et l’autorisation.
Par exemple, acquérir une nouvelle infrastructure cloud pour soutenir de nouvelles opérations d’affaires serait une demande de changement normale. L’ajout de ce nouveau service pourrait avoir des conséquences importantes et se doit donc d’être examiné par les principales parties prenantes de l’organisation.
Un changement urgent doit être traité immédiatement, et l’autorité requérante au sein de votre organisation autorise que la situation ne peut pas attendre le processus de gestion du changement habituel. Par exemple, l’application de correctifs de sécurité imprévus aux serveurs de production en raison d’une faille « zero day » récemment découverte est une demande de changement urgente courante en TI.
Votre processus de demande de changement devrait être approfondi, mais il n’a pas à être compliqué. En fait, le moins de place à l’erreur humaine, le mieux. Voici un processus simple de demande de changement en cinq étapes que toute organisation devrait être en mesure d’adapter à ses besoins.
Comme nous l’avons mentionné, les changements peuvent avoir des impacts à long terme importants et inattendus s’ils ne sont pas gérés correctement. Cela signifie que les utilisateurs ne devraient pas entreprendre de changements sur un coup de tête. Mettez plutôt en place un formulaire de demande de changement (RFC/DDC) exigeant les soumissionnaires à documenter toute l’information essentielle dont les agents ordonnateurs auront besoin pour analyser la demande.
L’information bien spécifique dont vous aurez besoin peut varier, mais pour la plupart des changements, vous ne pouvez pas vous tromper en exigeant que le demandeur documente les 7 R de la gestion du changement :
Cette étape est critique, car elle aide votre équipe à définir les exigences et à établir les attentes du client. Les équipes responsables devraient évaluer toutes les demandes récemment reçues. Évidemment, cela s’applique aussi aux changements standards. Leur évaluation est simplement effectuée en avance.
Évaluez le niveau d’effort nécessaire pour chaque demande de changement selon l’information reçue. Posez des questions complémentaires si nécessaire, puis estimez l’effort requis pour mettre en œuvre la demande de changement.
Avant de mettre quoi que ce soit en place, analysez l’impact potentiel de ce changement. Pour y arriver, nous utiliserons l’information fournie dans la demande afin d’identifier les risques aux niveaux suivants :
Il est souvent une bonne idée de catégoriser les risques à l’aide d’une matrice simple qui prend en considération leur probabilité et leurs conséquences. Cela vous permet de réellement considérer les avantages de cette demande de changement en fonction de ces facteurs de risque.
Jusqu’à maintenant, vous n’avez que collecté et analysé des données en fonction d’un changement potentiel. Il est maintenant temps de l’autoriser et de le mettre en place. Cela nécessite plus qu’un oui ou un non de la part d’un directeur.
À ce stade, vous devriez présenter la RFC au conseil consultatif de changement (ou CAB, « Change Advisory Board »). Ce conseil est composé des parties prenantes concernées par la demande de changement. Par exemple, un changement à l’infrastructure devrait être présenté aux membres seniors de votre équipe d’infrastructure présents au conseil.
Ils décideront si le changement est approuvé ou non. Si la réponse est positive, vous pouvez ensuite suivre votre processus établi de mise en œuvre. C2 vous recommande de suivre ces étapes précises de mise en œuvre :
Il y a encore du travail à faire suite à la mise en œuvre. Effectuer un suivi du ou des systèmes changés évite des problèmes imprévus. Si un problème survient, vous devrez tenter de le résoudre et déterminer si une solution est possible ou s’il faut renverser le changement. Il est aussi important, suite à l'étape d’implémentation, d’identifier les leçons apprises pour mieux en informer les mises en œuvre à venir.
Mettre en place un processus de demande de changement fiable, cohérent et facile à suivre est essentiel pour toute organisation suivant les meilleures pratiques de gestion des services TI. Un outil fiable de gestion des demandes de changement, tel que C2 ITSM, peut aider à ce que chaque demande soit facilement évaluée, programmée et exécutée.
C2 vous aide à gérer chaque RFC entrante, petite ou grande, standard, normale ou urgente. Chaque action est automatiquement enregistrée, vous permettant ainsi un regard complet sur tout ce qui se passe au cours du processus.