Réf. ITSM_M0410-V010-001
Ambition (goals) du processus #
L’ambition du processus au sein de la gestion des services est de :
répondre aux évolutions des besoins d’affaires des clients tout en maximisant la valeur (des services) et en réduisant les nuisances dues aux incidents, dysfonctionnements et au travail à refaire ( re-work).
répondre aux demandes de changement des organisations d’affaires et de l’organisation informatique qui vont aligner les services sur les besoins d’affaires.
Objectifs (objective) du processus #
Pour réaliser cette ambition, le processus a pour objectif concret de :
s’assurer que les changements sont enregistrés puis évalués, autorisés, classés par priorité, planifiés, testés, implantés, documentés et revus de manière contrôlée.
Objet (purpose) du processus #
Pour atteindre cet objectif, le processus a pour objet de :
s’assurer que des méthodes standardisées et des procédures sont utilisées pour un traitement efficient et rapide de tous les changements.
s’assurer que tous les changements sur les items de configuration et les actifs de service sont enregistrés dans le système de gestion des configurations (CMS = Configuration Management System).
s’assurer que les risques encourus par les affaires sont optimisés de bout en bout.
Réf. ITSM_M0410-V010-002
Ce qui est dans le périmètre #
Le périmètre inclut tout changement sur un service, ce qui veut dire : l’ajout, la modification ou le retrait d’un service ou d’un composant de service autorisé, planifié ou supporté, avec la documentation associée.
Ce qui est hors périmètre #
Aux deux extrémités de l’échelle de taille des changements, il y a ce qu’on appelle communément des changements qui sont hors périmètre du processus ITIL :
« changements » ayant un impact beaucoup plus large que les changements de service (tel que définis au-dessus) : ces « changements » seront gérés généralement au niveau de la direction générale et déclencheront des demandes de changement pour les services informatiques impactés dans le projet
« changements » au niveau opérationnel (réparation d’imprimantes par ex.) : ces « changements » seront traités sous la forme d’incidents incidents ou dans des procédures d’exploitation
Réf. ITSM_M0410-V010-003
Voici, au travers des indicateurs de risque suivants, quelques risques pouvant entraîner l’échec ou de mauvais résultats sur le fonctionnement du processus :
Changements non autorisés : une valeur différente de zéro est inacceptable.
Interruptions non planifiées
Faible taux de succès des changements : une méthodologie défaillante, absente ou mal appliquée peut être à l’origine de mauvais résultats, de même que des technologies mal maîtrisées
Nombre élevés de changements urgents : beaucoup de demandeurs arrivent à faire passer leurs changements en urgence et l’organisation informatique accepte l’urgence de telles demandes
Livraison des projets en retard : une méthodologie inexistante ou mal appliquée ou simplement une charge de travail trop élevée sur les équipes de développement par rapport au nombre de ressources sont souvent à l’origine de ce symptôme
Réf. ITSM_M0410-V010-004
Lorsqu’il s’agit d’initialiser une démarche ITIL®, la distribution des rôles de propriétaire de processus prend parfois des airs de remise de médaille. Or, il est un processus très difficile à concevoir si on veut un processus efficace dans toutes les situations : la gestion des changements. Son propriétaire ne va pas être à la fête. Mais personne ne lui a encore rien dit.
Le processus doit rester efficace et ne pas être un parcours du combattant bureaucratique quel que soit son utilisation : grands et petits projets, modifications non traitées en mode projet, modifications techniques ou applicatives, modifications de l’environnement de production comme modifications sur n’importe laquelle des aptitudes de service.
Bref, les occasions et les prétextes seront nombreux dans l’utilisation au quotidien pour ne pas respecter le processus.
Voici ce qu’ITIL® recommande : déterminer rapidement si une procédure spécifique existe pour traiter la demande de changement que l’on vient de recevoir.
Une démarche en arbre de décision alliant deux processus #
La nature des demandes de changement est très variée : du projet stratégique initié par la gestion du portefeuille de services (Change Proposal) en passant par des évolutions de service, voire même lorsqu’un utilisateur appelle l’informatique pour demander à changer quelque chose (son écran ou la cartouche de toner de l’imprimante qui est vide).
Le premier niveau de tri permet de savoir s’il s’agit d’un changement standard (fréquent, bien maîtrisé et facile à traiter pour peu qu’il existe une procédure rôdée), d’un changement urgent ou d’un changement normal.
Un changement standard ne passe pas par le processus de gestion des changements, désolé #
Un changement standard possède sa procédure de traitement et peut être exécutée par du personnel ne nécessitant pas de compétences techniques pointues sur le domaine. Et pour cause, la procédure a été conçue, développée et testée auparavant et la gestion des changements a pré-autorisée toute utilisation de cette procédure par le personnel exploitant. Cette demande sera donc traitée directement par le processus ITIL® d’exécution des requêtes (appelée aussi fréquemment gestion des demandes utilisateurs ou des demandes de service).
Changement urgent : ne posez pas la question au demandeur, vous connaissez déjà la réponse #
Le critère urgent d’un changement s’évalue par rapport à des préoccupations business ou d’affaires et pas uniquement des préoccupations du demandeur par rapport à son travail.
Le constat est simple : si on doit respecter normalement le processus, il est à peu près certain que sa mise en production sera hors délai et cela pourra causer un tort important au business.<
Dans ce cas, il faudra utiliser une procédure spécifique pour traiter ce changement urgent. Oui, il vaut mieux être organisé dans ce cas-là et avoir préparé un certain nombre d’éléments histoire de ne pas perdre de temps sur des choses évidentes (comme, par ex. pré-réserver des salles de réunion prioritairement à toute réunion en cours).
Changement normal : on passe normalement par le processus, eh oui, il en reste #
Tous les autres changements, et ils sont encore très divers et variés, passent normalement par le processus.
Dans ce cas, le processus doit continuer à dérouler un arbre de décision pour mettre la main sur la procédure adaptée à chaque cas, si elle existe.
ITIL® suggère de sous-classifier en changement majeur, significatif et mineur. Il s’agit-là d’un exemple proposé par ITIL® mais on peut faire autrement : patch technique, patch applicatif, projet applicatif sans comité de pilotage, avec comité de pilotage, etc.
Ensuite, il est possible d’utiliser des ramifications supplémentaires permettant d’aboutir à des procédures spécifiques comme : « montée de version du micro-logiciel d’un routeur réseau de modèle XXX ». Celle-là ne sera jamais traitée en changement standard (essayez de deviner pourquoi).
Enfin, certaines demandes de changement, inédites, rares ou complexes à traiter, ne seront pas servies par une procédure et devront être traitées de manière génériques en respectant les activités décrites dans le processus.
Procédure oui mais, depuis 2007, cela s’appelle un modèle de processus #
L’irruption des concepts ISO/IEC 9000 dans ITIL® 2007 a apporté son lot de termes, dont celui de « modèle de processus ». Ici, en l’occurrence, le modèle de changement.
Un modèle de changement permet de décrire de manière spécifique les activités du processus à mener pour un type particulier de demande de changement. L’utilisation d’un modèle de changement permet de gagner du temps, de la précision et de diminuer les risques car les activités du processus sont décrites de manière plus concrète.
Définitions #
Demande de changement #
Une demande de changement est une communication formelle visant à modifier un ou plusieurs éléments de configuration. En clair, c’est le livrable qui va initier le processus de gestion des changements.
Une organisation doit s’assurer que les procédures et formulaires appropriés couvrent les demandes prévisibles. Il sera moins risqué et plus rapide de traiter de manière procédurée des demandes de nature identique plutôt que d’étudier et de planifier chaque demande de manière individuelle.
Même s’il est impératif de traiter tous les changements par le processus et de remplir par conséquent une demande pour chaque changement, il reste néammoins impératif d’éviter une approche bureaucratique sous peine de rejet par les intervenants. Tout l’art du propriétaire de processus va consister ici à mettre en place progressivement les contraintes et le niveau de bureaucratie en prenant en compte le retour d’expérience et les avis des intervenants.
Modèle de changement #
Manière de pré-définir des étapes à suivre pour conduire un processus pour traiter un type particulier de changement.
En clair, il s’agit d’écrire et de valider une procédure de traitement qui particularise et détaille les activités du processus pour un type de demande qui arrive de manière fréquente. La procédure étant plus détaillée, les acteurs cités dans la procédure doivent respecter la procédure et n’ont plus à se préoccuper du processus général de gestion des changements.
Le traitement de ces demandes particulières reste néammoins sous le contrôle du processus de gestion des changements.
Réf. ITSM_M0410-V010-005
Changement standard #
Un changement standard est le résultat de la logique du modèle de changement poussée à l’extrême : il ne passe plus par le processus de gestion des changements. Il s’agit, en effet, d’un changement dont la procédure de réalisation est connue, maîtrisée et validée.
Pour certains types de changement qui reviennent souvent et qui ne sont pas des changements importants, il peut être intéressant de développer une procédure de réalisation, de la valider puis de l’appliquer de manière répétitive à chaque fois qu’une demande de ce type de changement est initiée.
C’est le processus de gestion des changements qui identifie de tels cas et qui décide de la mise en place de procédures standard de réalisation.
A partir du moment où une telle procédure est en place pour un type de changement, ces changements sont dits standard.
Pour résumer, un changement standard sur un service ou une infrastructure possède les caractéristiques suivantes :
son approche est pré-autorisée par la gestion des changements
il dispose d’une procédure reconnue et établie (éprouvée)
il est associé à un risque et un impact habituellement faibles
les implications budgétaires sont connues
Voici quelques exemples de changements standard :
l’installation d’un poste de travail
la mise à jour d’une application avec un impact mineur
Approbation de la demande : l’autorité est déléguée, par ex., au client (poste de travail) ou à un ingénieur d’une tierce partie (remplacement d’une imprimante en panne)
Dès identification, un modèle de changement standard doit être développé et communiqué
Les changements standard seront traités dans le cadre du processus d’exécution des requêtes par le centre de services.
Réf. ITSM_M0410-V010-006
Changement urgent #
Il s’agit d’un changement à implanter aussi rapidement que possible en raison des exigences de délai de la part du client.
Exemple : déployer un patch de sécurité.
Changement normal #
Tout changement qui n’est ni standard ni urgent est un changement normal.
Il passe « normalement » par le processus de gestion des changements.
Réf. ITSM_M0410-V010-007
Les points importants à retenir sur les activités sont les suivants :
Estimer et évaluer : définition de l’impact, de la priorité et de l’autorité du changement (rôle du processus)
Planifier : le résultat de l’activité est la publication des dates du changement dans les deux livrables :
CS (Change Schedule) : calendrier des changements
PSO (Projected Service Outage) : calendrier des interruptions planifiées de service
Cette activité doit aussi penser aux plans de retour arrière !
Coordonner : inclut la construction du changement (développement, acquisition) et les tests
Réf. ITSM_M0410-V010-008
Une grande partie des réponses à ces questions peut être apportée par l’initiateur de la demande au travers du formulaire de demande de changement par exemple. Le reste des réponses doit absolument être apporté avant évaluation et estimation du changement.
Sans ces informations, la prise de décision par le comité consultatif des changements devient aléatoire en terme de risques et de résultats.
Réf. ITSM_M0410-V010-009
CAB = Change Advisory Board
ECAB = Emergency Change Advisory Board
Rôle de gestionnaire des changements #
Ce rôle est associée à une personne précise dans l’organisation et ce rôle gère la totalité des changements.
Il a les caractéristiques suivantes :
il est gestionnaire du processus de gestion des changements
il est l’autorité sur les changements
il se fait conseiller par le comité consultatif des changements (CAB) pour l’évaluation, la priorisation et la planification des changements (d’où probablement l’adjectif consultatif pour le CAB car le CAB conseille le gestionnaire des changements mais c’est ce dernier qui a le dernier mot)
il préside les réunions du CAB
Réf. ITSM_M0410-V010-010
Rôle d’autorité de changement : les différents niveaux #
Il existe différents niveaux d’autorité de changement.
Le schéma présente ces différents niveaux (ce schéma doit être adapté à l’organisation dans lequel le processus est prévu d’être mis en place), y compris les deux extrêmes qui sont hors périmètre du processus de gestion des changements.