Les demandes de changement sont partie intégrante des projets et de leur gestion. Dans cette tourmente, les TI s’efforcent de déployer des efforts colossaux pour assurer le bon fonctionnement des services de soutien. Aussi, pourquoi négligent-elles régulièrement les bonnes pratiques en matière de gestion opérationnelle et stratégique des demandes de changements ?
La problématique
La plupart des offres de services émanant des TI reposent sur l’exploitation de systèmes informatiques, souvent dépendants ou intégrés aux systèmes d’information des organisations. Ces systèmes se composent généralement d’un ensemble d’applications, qu’il a fallu développer ou intégrer et mettre en exploitation. À tous les stades de sa vie, tout service, quel qu’il soit, doit inexorablement faire face à une multitude de demandes de changement. Ces dernières relèvent d’un fonctionnement inadéquat ou d’un résultat qui ne satisfait pas totalement l’utilisateur. Cela peut-être, par exemple, un bogue informatique ou une incompatibilité des logiciels, mais aussi une évolution des besoins de l’utilisateur.
Le traitement de chacune des demandes acceptées sera à l’origine de l’implantation d’un changement. De plus, tous les changements sont susceptibles d’entraîner à leur tour d’autres demandes de changements. C’est l’envers de la médaille des demandes de changement.
Les faits
Ce lien entre les nouvelles demandes et les changements opérés précédemment est évident, naturel et humain. Le lien entre les changements pratiqués aujourd’hui et les demandes futures est par conséquent logique. Les sources des demandes sont multiples, mais elles ne sont pas toutes inévitables. La plupart même pourraient être anticipées. Parmi les principales sources de demande se trouvent : une négligence, un manque de ressources, une préparation insuffisante, une mauvaise analyse d’impacts, des tests mal adaptés, une analyse non exhaustive des besoins ou l’apparition de nouveautés technologiques.
L’évolution
Il est impératif, pour tout fournisseur de services informatisés, de prendre rapidement le contrôle sur le chapelet déferlant des demandes de changement. Il s’agit d’un passage critique et certainement pas trivial dans le cycle de vie des TI, d’autant que tout échec risque de provoquer une propagation des demandes de changement au sein de l’organisation. Cette affluence de demandes, qui peut parfois ressembler à un véritable casse-tête, devra être gérée avec efficacité.
Étendue du phénomène
Le processus de gestion des demandes est extrêmement vaste, puisque tous les changements en relèvent. Sa frontière commune avec le processus de gestion des configurations des TI est tout aussi capitale, de même que sa base de données informationnelle. Par mesure d’efficacité et pour garantir la synergie souhaitable et nécessaire entre la gestion des configurations des TI et la gestion des changements, toutes les informations relatives aux demandes doivent y être répertoriées.
Avec l’expérience, les traitements de certaines demandes de changement concernant des événements simples, fonctionnels, et répétitifs sont généralement bien maîtrisées. Leurs impacts s’en trouvent donc amoindris. C’est le cas très simple, par exemple, du changement régulier des bandes magnétiques des systèmes de sauvegarde. Un tel événement devrait relever, par sa définition, d’une demande de changement. Toutefois, cette opération pourrait aussi être considérée comme une demande de service de base dans le processus de gestion. Aussi, il est toujours avantageux pour une organisation de procéder à une analyse de ses actions de routine, afin d’en classifier certaines comme des services de base régulier et ainsi éviter que la gestion des changements ne devienne un méli-mélo de bureaucratie.
Les composantes du processus
Le processus de gestion des changements est composé de plusieurs activités :
La demande : Il s’agit de l’activité initiale du processus. Pour qu’un changement puisse exister, il faut qu’une demande de changement soit déposée et consignée dans la base de données, ainsi que toutes les informations afférentes.
L’approbation : Toutes les demandes de changement doivent être analysées et approuvées, afin d’en poursuivre le processus. Toutes les demandes incomplètes, imprécises, non justifiées ou irréalisables sont rejetées.
La priorisation : C’est lors de cette activité qu’un niveau de priorité est accordé aux demandes de changements, par le processus. L’échelle despriorités devrait con-te-nir seulement qua–tre niveaux, telsque : faible; cou–rante; élevée; urgente. La -catégori-sa–tion : Il s’agitde l’attribu-tionde la catégorieà la-quelle estrattachée la de–mande de changement. Ces catégories devraient refléter le type d’impact anticipé par le changement. Le nombre de catégories devrait être limité à trois, soit : faible; important; crucial.
L’échéancier : Le processus de gestion des changements doit fonctionner suivant une classification chronologique planifiée. L’échéancier dispose de toutes les informations relatives à chacun des changements et à leur planification. C’est un véritable tableau de bord.
Le suivi : C’est en quelque sorte la gestion de projet de la réalisation des changements dont les demandes ont été autorisées.
Le contrôle : Il s’agit de l’évaluation finale de la demande de changement. C’est l’étape ultime qui conduit à l’autorisation nécessaire pour permettre la réalisation du changement. C’est une étape de « Go / No Go ».
La réalisation : C’est la mise en œuvre du changement concerné.
La mise en exploitation : C’est l’étape ultime de la gestion des changements. Les changements visés sont maintenant réalisés, validés et acceptés. Il ne reste plus, à cette étape, qu’à les intégrer aux opérations.
Structure organisationnelle
Le processus de gestion des changements devrait rassembler deux niveaux fonctionnels. D’une part, il y a un « gestionnaire des changements », qui est l’organisateur en chef de tous les changements. Il a pour prérogative de voir à l’ensemble des activités du processus. C’est un réel directeur de projets spécialisés. D’autre part, un « comité de validation » doit être disponible pour certaines demandes de changements. Ce comité consultatif peut disposer de prérogatives décisionnelles, selon le cas. Il est réuni régulièrement, à des dates fixes et planifiées, pour procéder aux validations nécessaires. Pour des raisons d’efficacité, le comité ne traite que les demandes de changements importants en temps, en budget ou en risques inhérents pour l’organisation. En outre, il devra parfois siéger à des réunions d’urgence, lorsque nécessaire pour l’organisation. La composition du comité est ad hoc et pourra comprendre le gestionnaire des changements, comme président, et des représentants de la direction informatique, de la gestion des incidents, du développement des applications, des infrastructures, de la gestion des services, des logiciels et des systèmes, des utilisateurs, de la direction d’affaires concernée, du groupe de service à la clientèle et des fournisseurs, si l’organisation a recours à des services externes.
La conclusion
Il faut faire la différence entre la gestion des changements, issus des demandes de changement et la gestion du changement en général. Ces deux expressions sont bien proches, cependant. Ce qui différencie ces deux contextes est une différence de paradigme. En effet, les différents aspects de la gestion des changements sont des actions qui se réalisent en mode réactif, à la suite d’une demande et relevant d’un événement intervenu précédemment. La gestion du changement se réalise quant à elle en mode proactif et prospectif. La gestion du changement vise à identifier et à anticiper les actions potentiellement à risques, pouvant provoquer, dans un futur proche ou lointain, un problème, aussi minime soit-il. Les interventions du premier sont en mode redressement, et celles du second sont en mode prospectif.
Gestion des changements
• La demande • L’approbation • La priorisation • La catégorisation • L’échéancier • Le suivi • Le contrôle • La réalisation • La mise en exploitation
Gérard Blanc est associé principal d’une firme conseil en gestion et en systèmes d’information.
