Comment développer un programme de gestion du changement informatique?
Dois-je créer un programme pour développer un programme de gestion du changement informatique?
Le programme de gestion des changements (CMP), plus connu sous le nom de processus de contrôle des changements ou processus de gestion de contrôle des changements, est un processus formel utilisé pour garantir que les changements apportés à un produit ou un système sont introduits de manière contrôlée et coordonnée (tel que défini par ISO 20000). La CMP ne doit pas être confondue avec la gestion du changement organisationnel (OCM), qui gère les impacts des nouveaux processus métier, y compris ceux résultant des déploiements de systèmes et des initiatives informatiques, des changements de structure organisationnelle ou des changements culturels au sein d'une entreprise. En bref, OCM gère le côté humain du changement.
Combien de temps faut-il pour créer des programmes de gestion du changement informatique?
Le but du CMP est de s'assurer que l'impact négatif des modifications apportées au système de technologie de l'information d'une entreprise est minimisé en utilisant un processus normalisé de gouvernance. Certains changements ne sont pas facultatifs. Si, par exemple, la norme de code à barres change, vous devez vous adapter; si une structure de retenue d'impôt change, vous devez effectuer un changement. Néanmoins, tous les changements de ce type sont encore soumis à la gouvernance.
Obtenir l'acceptation du changement commercial: la décision d'apporter un changement est généralement une décision commerciale où les coûts vs.
Il ne doit jamais arriver que des changements ad hoc soient apportés au système ou aux procédures sans un certain contrôle. Cette idée doit émaner de la direction générale et être transmise, sans exception, à tout le monde dans l'entreprise. Sans soutien au plus haut niveau, le CMP est une perte inutile de temps et d'argent. Avec un support approprié, ce programme sauvera votre entreprise de certaines erreurs très coûteuses.
- 1Développer une demande de changement (RFC): Cela peut provenir de la gestion des problèmes où un problème, ou une série de problèmes connexes, est identifié et un changement d'atténuation est nécessaire pour prévenir (ou minimiser) les effets futurs. La RFC peut également provenir d'une décision commerciale qui nécessitera une certaine modification (ajouter, supprimer, modifier) la technologie de support. Une RFC peut également être nécessaire en raison d'influences extérieures (c'est-à-dire des réglementations gouvernementales ou des modifications apportées par des partenaires commerciaux).
- 2Obtenir l'acceptation du changement commercial: la décision d'apporter un changement est généralement une décision commerciale où les coûts par rapport aux avantages sont évalués. Même dans les situations où le changement est strictement axé sur l'infrastructure (défaillance d'un composant ou d'un système), la décision de dépenser de l'argent appartient à l'entreprise et non au service informatique. Il y a des occasions où des procédures sont élaborées à l'avance pour autoriser des modifications telles que la maintenance du système d'urgence, mais quel que soit le moment de l'autorisation, la décision appartient toujours à la direction de l'entreprise.
- 3Lancer le projet de développement: Le développement du changement (y compris les tests) est une fonction guidée par l'informatique. En cas de changement d'urgence (le serveur est en panne), ces fonctions sont généralement prédéterminées. Lorsqu'un nouveau système doit être développé, il y a un effort de collaboration entre les utilisateurs métier et l'équipe informatique. Les systèmes sont conçus par l'informatique, la conception est approuvée par les partenaires commerciaux (utilisateurs), développée par l'informatique, testée par une combinaison de l'informatique et des utilisateurs, et le produit final est approuvé par les deux. Une attention particulière doit être accordée aux effets secondaires que le nouveau changement peut avoir sur les systèmes existants.
- 4Passer la porte de la gestion du changement: le Comité consultatif du changement (CAB) examine tous les changements avant qu'ils ne puissent être mis en production. Normalement, le CAB sera composé d'un groupe de personnes ayant des perspectives, des antécédents et des domaines d'expertise différents. Leur fonction est d'examiner le changement du point de vue du processus et de la gouvernance pour s'assurer que tous les risques prévisibles ont été identifiés et atténués, et que des techniques compensatoires sont en place pour tout élément d'exposition (choses qui pourraient mal tourner). L'équipe de développement et le sponsor du changement présenteront le changement au CAB. L'évaluation du risque sera au centre des préoccupations. Les stratégies de mise en œuvre, la communication aux parties prenantes concernées, les plans de sauvegarde et le suivi post-mise en œuvre sont des éléments sur lesquels le CAB doit se concentrer. Le CAB n'est pasresponsable de déterminer si le changement est approprié - cette décision a déjà été prise. Le CAB n'est pas non plus responsable de déterminer si le changement est rentable. Encore une fois, c'est strictement une décision commerciale.
- 5Mettez en œuvre le changement: Si le CAB n'approuve pas le changement, les raisons sont énumérées (c'est toujours parce que certains risques n'ont pas été atténués ou que les communications n'ont pas été planifiées) et l'équipe de développement aura le temps de résoudre ces problèmes et de reporter une réunion avant le CAB.. Si la modification est approuvée, la mise en œuvre est planifiée. Normalement, le CAB n'est pas représenté lors de la mise en œuvre, bien qu'il soit possible que certains membres du CAB aient l'expertise nécessaire lors de la mise en œuvre, mais ils ne seront pas présents en tant que représentants officiels du CAB, mais plutôt en tant qu'experts en la matière (PME). La façon dont le changement est mis en œuvre, la liste de contrôle et les étapes, sont prédéfinis et ont été présentés et approuvés par le CAB. L'ensemble du processus doit être soigneusement documenté et le processus approuvé doit être suivi avec précision.
- 6Signaler les résultats: Soit le changement a été mis en œuvre avec succès sans problème, soit le changement a été mis en œuvre avec des problèmes qui ont été corrigés pendant la mise en œuvre, le changement a été mis en œuvre avec des problèmes jugés acceptables, des problèmes sont survenus qui étaient inacceptables et le changement a été annulé, ou dans le pire des cas, le changement a été mis en œuvre avec des problèmes inacceptables et n'a pas pu être annulé. Quel que soit le résultat, celui-ci est documenté et renvoyé au CAB. Le CAB est alors responsable de la distribution de ces informations aux parties prenantes et du stockage et de la conservation de ces résultats dans le système de gestion du changement (qui peut être soit une base de données automatisée, soit un système de classement papier., mais les documents doivent être conservés à des fins d'audit).
- 7Lier la gestion des problèmes aux changements: les problèmes qui surviennent doivent être comparés à la documentation CAB des changements afin que tout effet indésirable imprévu d'un changement puisse être isolé. Il arrive souvent que les effets indésirables d'un changement ne soient pas immédiatement remarqués, mais identifiés par l'apparition de problèmes dans les systèmes auxiliaires. Par exemple, l'ajout de plusieurs champs à une base de données pourrait ne pas avoir d'effet négatif direct sur les utilisateurs, mais pourrait avoir un impact sur les performances du réseau qui seraient apparentes aux autres utilisateurs qui ne sont pas directement impliqués dans le système modifié.
- 8Auditer périodiquement le CMP: au moins une fois par an, un audit du CMP doit être effectué pour s'assurer que toute la documentation des modifications est conservée et disponible. Chaque document d'approbation de changement doit être examiné pour s'assurer que les signatures appropriées sont en place et que les résultats de la mise en œuvre sont correctement documentés.
- La maintenance périodique standard doit être approuvée au préalable. S'il s'agit d'un processus normal de redémarrer un serveur le dimanche matin à 2h00 du matin, il n'est pas nécessaire de soumettre une RFC à chaque fois, mais ce processus doit être approuvé à l'avance.
- La maintenance ad hoc doit adhérer au CMP. Incluez des éléments tels que le test des systèmes d'extinction d'incendie, le nettoyage du sous-plancher du centre de données, l'inspection et les tests CVC et même la maintenance de la lutte antiparasitaire. Certaines entreprises vont jusqu'à exiger un RFC si une ampoule est changée dans le centre de données (l'échelle est tombée et a endommagé le réseau).
- Les procédures doivent être soumises à la gestion du changement. S'il y a un changement dans la planification de la sauvegarde du système, cela doit passer par la gestion des changements. Analysez chaque changement de quelque nature que ce soit (système ou procédure) pour déterminer s'il existe un risque possible.
- Dans les systèmes matures où les changements sont plus courants, l'examen du CAB peut être effectué par voie électronique en demandant aux membres du CAB «d'approuver» ou non la mise en œuvre. Cela peut réduire le besoin de réunions coûteuses, car il n'y a pas de changements inhabituels associés à la mise en œuvre à venir.
Passer la porte de la gestion du changement: le Comité consultatif du changement (CAB) examine tous les changements avant qu'ils ne puissent être mis en production.
- Faites fréquemment tourner les membres du CAB. Le fait d'avoir toujours les mêmes membres peut conduire au favoritisme, et cela peut conduire à l'épuisement professionnel. Vous voulez que votre CAB soit frais, attentif et ne soit pas soumis à des influences politiques extérieures.
- La politique peut souvent nuire au CAB. «Ce changement est nécessaire» peut être vrai, mais cela pourrait aussi être un agenda personnel de l'un des dirigeants. Le CAB doit avoir le pouvoir ultime de prendre des décisions sur la mise en œuvre.
Questions et réponses
Questions sans réponse
- Combien de temps faut-il pour créer des programmes de gestion du changement informatique?
- Dois-je créer un programme pour développer un programme de gestion du changement informatique? Y en a-t-il déjà un? Et si je dois écrire le code, quelle langue dois-je utiliser?
Les commentaires (1)
- M'a aidé à obtenir une compréhension préliminaire de CMP. Un bon point de départ.
Lisez aussi:
Avertissement légal Le contenu de cet article est pour votre information générale et n'est pas destiné à se substituer à des conseils professionnels en droit ou en finance. De plus, il n'est pas destiné à être utilisé par les utilisateurs pour prendre des décisions d'investissement.
En parallèle
