Minotauromaquia
Le programme de gestion du changement (CMP), plus communément appelé processus de contrôle des modifications ou processus de gestion du changement, est un processus formel utilisé pour garantir que les modifications apportées à un produit ou à un système sont contrôlées et coordonnées (conformément à la norme ISO 20000). CMP ne doit pas être confondu avec la gestion des changements organisationnels (OCM), qui gère les impacts des nouveaux processus commerciaux, y compris ceux résultant des déploiements de systèmes et des initiatives informatiques, des modifications de la structure organisationnelle ou des changements culturels au sein d'une entreprise. En bref, OCM gère l'aspect humain du changement.
L'objectif du PGC est de minimiser l'impact négatif des modifications apportées au système informatique d'une entreprise en utilisant un processus de gouvernance standardisé. Certaines modifications ne sont pas facultatives. Si, par exemple, la norme de code à barres change, vous devez vous adapter. si une structure de retenue d'impôt change, vous devez avoir une modification. Néanmoins, tous les changements de ce type sont encore soumis à la gouvernance.
Il ne faut jamais que des modifications ponctuelles soient apportées au système ou à des procédures sans surveillance. Cette idée doit provenir de la haute direction et être transmise sans exception à tous les membres de l'entreprise. Sans un soutien au plus haut niveau, le CMP est une perte de temps et d’argent inutile. Avec un support adéquat, ce programme permettra à votre entreprise d’économiser des erreurs très coûteuses.
Pas
-
1 Dé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 sont identifiés et un changement atténuant est nécessaire pour prévenir (ou minimiser) les effets futurs. La RFC peut également provenir d'une décision commerciale nécessitant certaines modifications (ajout, suppression, modification) de la technologie de prise en charge. Une RFC peut également être nécessaire en raison d'influences extérieures (par exemple, réglementations gouvernementales ou modifications apportées par des partenaires commerciaux). -
2 Obtenir l'acceptation du changement d'entreprise: La décision de faire un changement est généralement une décision commerciale où les coûts et les 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 arrive que des procédures soient élaborées à l’avance pour autoriser des modifications telles que la maintenance du système d’urgence, mais quelle que soit la date de l’autorisation, la décision incombe toujours à la direction de l’entreprise. -
3 Initier 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 le service informatique, la conception est approuvée par les partenaires commerciaux (utilisateurs), développés par le service informatique, testés par une combinaison d’informatique et d’utilisateurs, et le produit final est approuvé par les deux. Une attention particulière doit être accordée aux effets accessoires que le nouveau changement peut avoir sur les systèmes existants. -
4 Passez la porte de gestion des modifications: Le Comité consultatif de changement (CAB) examine tous les changements avant de pouvoir les mettre 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 (ce qui pourrait aller mal). 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 avec les parties prenantes concernées, les plans de sauvegarde et le suivi post-implémentation sont des éléments sur lesquels le CAB doit se concentrer. Le CAB est ne pas responsable de déterminer si le changement est approprié - cette décision a déjà été prise. L'ACR n'est pas non plus responsable de déterminer si le changement est rentable. Encore une fois, c'est strictement une décision commerciale. -
5 Implémenter le changement: Si le CAB n'approuve pas le changement, les raisons sont répertoriées (ceci est toujours dû au fait 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 . Si la modification est approuvée, la mise en œuvre est planifiée. Il n’est pas normal que l’ACR soit représenté à la mise en œuvre bien qu’il soit possible que certains membres de l’ACR aient une expertise nécessaire pendant la mise en œuvre, mais qu’ils ne soient pas présents en tant que représentants officiels PME) La façon dont la modification est mise en œuvre, la liste de contrôle et les étapes, sont prédéfinies et présentées à l’ACR et approuvées par ce dernier. L'ensemble du processus doit être soigneusement documenté et le processus approuvé doit être suivi avec précision. -
6 Signaler les résultats: Soit le changement a été mis en œuvre avec succès sans problèmes, le changement a été mis en œuvre avec des problèmes corrigés au cours de la mise en œuvre, les modifications ont été jugées acceptables, des problèmes inacceptables et le changement a été annulé ou pire. 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, cela est documenté et renvoyé au CAB. Il incombe ensuite à l’ACR de diffuser cette information aux parties prenantes et de stocker et de conserver ces résultats dans le système de gestion du changement (qui peut être une base de données automatisée ou un système de classement papier, mais les documents doivent être vérifiés). -
7 Lier la gestion des problèmes aux modifications: Les problèmes qui se posent doivent être comparés à la documentation de l'ACR sur les changements, de manière à pouvoir isoler tous les effets négatifs imprévus d'un changement. Il arrive souvent que les effets indésirables d'un changement ne soient pas immédiatement constatés, mais sont 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 une incidence sur les performances du réseau, ce qui serait évident pour les autres utilisateurs qui ne sont pas directement impliqués dans le système modifié. -
8 Vérification périodique du CMP: Au moins une fois par an, un audit du PGPC devrait être effectué pour s'assurer que toute la documentation relative au changement 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.
1 Dé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 sont identifiés et un changement atténuant est nécessaire pour prévenir (ou minimiser) les effets futurs. La RFC peut également provenir d'une décision commerciale nécessitant certaines modifications (ajout, suppression, modification) de la technologie de prise en charge. Une RFC peut également être nécessaire en raison d'influences extérieures (par exemple, réglementations gouvernementales ou modifications apportées par des partenaires commerciaux). 
2 Obtenir l'acceptation du changement d'entreprise: La décision de faire un changement est généralement une décision commerciale où les coûts et les 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 arrive que des procédures soient élaborées à l’avance pour autoriser des modifications telles que la maintenance du système d’urgence, mais quelle que soit la date de l’autorisation, la décision incombe toujours à la direction de l’entreprise. 
3 Initier 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 le service informatique, la conception est approuvée par les partenaires commerciaux (utilisateurs), développés par le service informatique, testés par une combinaison d’informatique et d’utilisateurs, et le produit final est approuvé par les deux. Une attention particulière doit être accordée aux effets accessoires que le nouveau changement peut avoir sur les systèmes existants. 
4 Passez la porte de gestion des modifications: Le Comité consultatif de changement (CAB) examine tous les changements avant de pouvoir les mettre 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 (ce qui pourrait aller mal). 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 avec les parties prenantes concernées, les plans de sauvegarde et le suivi post-implémentation sont des éléments sur lesquels le CAB doit se concentrer. Le CAB est ne pas responsable de déterminer si le changement est approprié - cette décision a déjà été prise. L'ACR n'est pas non plus responsable de déterminer si le changement est rentable. Encore une fois, c'est strictement une décision commerciale. 
5 Implémenter le changement: Si le CAB n'approuve pas le changement, les raisons sont répertoriées (ceci est toujours dû au fait 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 . Si la modification est approuvée, la mise en œuvre est planifiée. Il n’est pas normal que l’ACR soit représenté à la mise en œuvre bien qu’il soit possible que certains membres de l’ACR aient une expertise nécessaire pendant la mise en œuvre, mais qu’ils ne soient pas présents en tant que représentants officiels PME) La façon dont la modification est mise en œuvre, la liste de contrôle et les étapes, sont prédéfinies et présentées à l’ACR et approuvées par ce dernier. L'ensemble du processus doit être soigneusement documenté et le processus approuvé doit être suivi avec précision. 
6 Signaler les résultats: Soit le changement a été mis en œuvre avec succès sans problèmes, le changement a été mis en œuvre avec des problèmes corrigés au cours de la mise en œuvre, les modifications ont été jugées acceptables, des problèmes inacceptables et le changement a été annulé ou pire. 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, cela est documenté et renvoyé au CAB. Il incombe ensuite à l’ACR de diffuser cette information aux parties prenantes et de stocker et de conserver ces résultats dans le système de gestion du changement (qui peut être une base de données automatisée ou un système de classement papier, mais les documents doivent être vérifiés). 
7 Lier la gestion des problèmes aux modifications: Les problèmes qui se posent doivent être comparés à la documentation de l'ACR sur les changements, de manière à pouvoir isoler tous les effets négatifs imprévus d'un changement. Il arrive souvent que les effets indésirables d'un changement ne soient pas immédiatement constatés, mais sont 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 une incidence sur les performances du réseau, ce qui serait évident pour les autres utilisateurs qui ne sont pas directement impliqués dans le système modifié. 
8 Vérification périodique du CMP: Au moins une fois par an, un audit du PGPC devrait être effectué pour s'assurer que toute la documentation relative au changement 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.