Vous n'êtes pas identifié.
Bonjour,
Je reviens à nouveau pour détailler une action importante dans le rôle du gestionnaire du changement: mettre en place un catalogue des changements standard. Partir d'une page blanche et en mettre un catalogue en place.
Quelle est la meilleure methode ?
Comment qualifier un changement de changement Standard ?
Dans un contexte IT où les changement sont peu standard, comment identifier les changements standards.
je donne par exemple:
==> Les maj de Patch de securité.
==> les maj d'antivirus
==> les ouvertures de flux réseau
==> augmentattion taille BD
==> Maintenance matérielles: Changement de Disque Dur, Carte, ....
Peut on les qualifier des changements standard ? faut il soumettre une RFC pour chaque changement standard ? qui valide ?
Marci par avance pour votre réponse.
Hors ligne
Bonjour Gesmil,
Les changements standards sont tous les changements pré-autorisés, c'est à dire pré-approuvés/validés par le CAB (Change Advisory Board) dès lors qu'ils sont documentés, c'est à dire qu'une procédure détaillée de mise en œuvre existe, et a été elle-même visée par le CAB ou Gestionnaire des Changements.
Le mot standard n'a pas le sens que l'on veut bien lui donner en français. Donc tout changement, pour peu qu'il soit "procédurable/documentable" à l'avance peut-être classifié comme standard.
Logiquement cela écarte les changements dits "importants" (normaux et urgents) qui pourraient avoir un impact plus sévère sur le Service. Ces deux catégories nécessitent l'approbation par le CAB ou le Gestionnaire des changements.
Pour reprendre votre exemple, une augmentation de taille de base de donnée, nécessite d'être gérée par la Gestion des Changements, pour prévenir les utilisateurs, il y a donc bien une RfC de créée. En revanche l'opération ne nécessite pas la validation du CAB, car la procédure doit être maitrisée par les DBA.
Quelle méthode ? Identifiez les changements qui ont générés des incidents lors de leur mise en œuvre et analyser la cause de l'incident, ces changements devront être gérés en "normaux". Ceux qui sont maitrisés, commencez à les documenter et classez les en "standard". Une autre approche consiste à standardiser les changements qui ne touchent qu'un CI, ce qui rejoint vos exemples.
Enfin notez qu'un changement devient "standard", bien souvent après avoir été traité en "normal" pour la première fois.
En espérant avoir répondu à vos attentes. N'hésitez pas à nous questionner davantage si nous n'avons pas été complet.
Bonjour ,
Merci bcp pour ces clarifications pertinentes.
J'ai besoin d'une précision pour être sûre d'avoir compris:
Si j'ai bien compris, Un changement standard doit avoir une procedure de mise en place maitrisée, cette procedure doit être documentée et presentée au CAB pour approbation.
Dés que le CAB approuve ce changement comme etant standard, celui-ci devra faire partie du catalogue des changements standards
Même si un changement est connu par le demandeur de changement comme étant un changement standard, il doit tout de mêm soumettre une RFC au Gestionnaire de changement qui validera ce changement (sans l'approbation du CAB) et le souemttra pour réalisation
2 questions:
1- Sur le plan de impact et Risque utilisateur, est ce que le changement standard doit avoir un impact zéro et risque zéro pour les utilisateurs ? est ce que avec un impact et risque sur le service un changement peut tjs être considéré comme standard ?
Je reprends mon exemple. pour une augmentation de taille de BD, ce changement a une procedure maitrisée documentée, cependant cela necessite un arrêt d'instance BD pour réaliser l'opération. ceci implique une interruption de service pour les utilisateurs.
Peut on qd même standariser cette opération ?
Si la réponse est tjs oui, cela veut dire, le demandeur doit soumettre la RFC, le gestionnaire de changement devra prevenir les utilisateurs des creneaux d'intervention et attendre leur validation. Dans ce cas là, je ne vois pas trop l'intérêt du changement standard ?
2- est ce que tous les changements standards doivent passer par le gestionnaire du changement ou peuvent ils être délégués complétement à un autre service par exemple le service Desk ?
Gesmil
Hors ligne
Bonjour,
1) De mon point de vue, l'impact zéro et le risque zéro n'existent pas. Dès qu'il y a changement, il y a un risque.
Dans le cas d'un changement standard qui est documenté avec une procédure détaillée, le risque est maîtrisé.
Mais des évènements extérieurs peuvent se produire (coupure réseau, coupure de courant, ...) ou encore une erreur humaine.
Ces évènements empêchent alors la mise en place du changement et obligent éventuellement à un retour arrière.
Dans le cas d'un changement standard, le CAB a déjà validé le type de changement et n'a plus à le faire à chaque changement du même type.
C'est un gain en réactivité qui permet de déployer le changement plus rapidement.
2) Le Service Desk est le point d'entrée unique pour enregistrer les différentes demandes, rapporter un incident ou suivre l'évolution d'un incident.
Il n'a pas les ressources pour évaluer un changement.
Le gestionnaire du Changement doit être informé de chaque changement, même standard.
C'est indispensable pour lui permettre:
- d'avoir une vue complète sur les évolutions des infrastructures,
- d'évaluer les impacts,
- d'affecter les priorités des changements,
- de préparer le planning des changements (FSC)
Hors ligne