Permettez moi quelques présisions

Comme ITIL expert dit, l'activité de changer du materiel defectueux doit entre consideré comme changement.

Cela serait typiquement un changement standard si......de tels changements ont été definie comme changement standard avant. Si non, c'est un changement normal.

La plupart des changements normaux peuvent être approuvés par le change manager, donc il n'y pas besoin d'un CAB.

Le CAB intervient si le changemanager ne peut plus decider tout seul parce que il ne peut pas lui-même evaluer le risque de faire versus ne pas faire le changement. Le but principal du CAB est de conseiller le changemanager sur la décision a prendre. On peut assister a planifier le changement mais cela est la responsabilité du change manager, bien evidement en communication avec celui qui demandé le changement.

L'idée serait que 60% sont des changements standards (donc pre-approuvés par le changemanager), 25% des changements normal, approuvé par le changemanager, 10% des changements via le CAB 'standard" et le restant sont des changements ou le PDG doit assister au CAB ou des changement urgents, (CAB-EC). Les pourcentages sont bien sur pas fixes mais c'est pour indiquer un peu les volumes.

Si on veut faire passer toutes les changements normuux par defaut via le CAB, changemanagememt devient un processus très lourde. Il faut faciliter les choses, pas freiner.

Bonjour,

D'accord avec MVBP, c'est juste un problème de cohérence au moins entre les processus, a minima sur le périmètre de ceux-ci.

Quel intérêt de gérer le changement d'une carte-mère sur un pc par une même carte-mère dans le processus, si vous avez décidé que votre plus petit composant dans votre CMDB est le poste de travail ? Alourdir le processus, le rendre indigeste et impopulaire, perdre du temps.

Question : et si je n'ai pas (encore) implémenté un processus de gestion des configurations ? Cas que l'on retrouve souvent . Souvent la gestion de parc ou d'inventaire fait office de (en attendant). Il est d'autant plus important de prendre conscience qu'une gestion fine des composants est impossible dans ce cas. Je vous conseille de gérer vos changements en fonction de la granularité de vos inventaires ou votre gestion de parc. Même si ce n'est pas optimum, cela permettra de mettre en place votre processus et de roder vos procédures dans tous les cas.

Faire avec ce que l'on a, et améliorer vers ce que l'on veut.

A plus

@MVBP. T'as raison. Je avait choisi de me pas ajouter ce niveau de détail dans ma reposne pour ne pas compliquer le choses ;-) En consequence ce que tu dit: si on decide de pas mettre plus de detail dans la CMDB qu'au niveau ou on intervient on change donc pas la carte dans le PC mais on change tout l'unité central

@Yves: Autrement dit: on applique la gestion de changement en conséquence du risque associé. Pas de risque --> processus très leger, beaucoup de risque --> processus lourde et etendue (donc inclu CAB). Ce que j'aime que vous essayer quand même de tracer tout demande.

@tous: dans ce cadre. Comment voyez vous la modification des parametres de (par ex) un router. Changement ou pas? Les consequences d'une re-parametrisation peuvent être importantes (ou juste pas important)

Bonjour,

réponse un peu tardive peut-être ....

La notion de changement ou non-changement peut effectivement être argumentée sur un plan théorique (c'est un élément décrit dans la CMDB ou pas ) , mais il me parait important de prendre en compte les considérations pratiques.

La gestion des changements peut être (est?) perçue comme une mécanique administrative, lourde et qui fait perdre du temps. Ce n'est pas l'objet de l'argumentation: la vocation de la gestion des changements est de garantir la stabilité de la production et la consistance des services fournis.

Ainsi, il me semble nécessaire de prendre en compte les aspects suivants pour déterminer si un type d'opération est géré en mode changement ou pas:
- impact: toute opération en prod devrait faire l'objet d'une analyse d'impact technique, organisationnel et financier ainsi que du risque (selon gartner 70% des incidents sont liés à des changements => nécessité de contrôler les changements ce qui est le but du processus de Gestion des Changements) et être approuvée par le responsable du service fourni ;  c'est le processus de gestion des changements qui porte cette activité
- traçabilité: afin de répondre à des contraintes réglementaires la traçabilité des opérations , de leurs justifications et d'une approbation appropriée est de plus en plus requise: la RFC et la décision du CAB sont donc indispensables
- exploitabilité: il n'est plus possible aujourd'hui de sauvegarder tous les jours les données et les paramètres des différents élements; des sauvegardes (ou mesures équivalentes) sont faites de façons espacées => c'est la traçabilité assurée par la gestion des changemenst qui permet de garantir la capacité à reconstruire un environnement à l'identique de ce qu'il était. Exemple: utiliser la dernière sauvegarde de l'item X permet de reconstruire X tel qu'il était à la date de la sauvegarde; l'ensemble des RFCs passées depuis cette date permet d'identifier ce qu'il reste à reconstruire pour remettre X dans l'état où il doit être....les modifications apportées sans RFCs seront perdues...ou alors on joue au bricoleur.
- risque : complément de l'analyse d'impact , l'analyse du risque à faire ou à ne pas faire fait partie des évaluations à soumettre au CAB et des questions qui devraient être évaluées avant de lancer les opérations.


Pour ma part, j'ai l'habitude de considérer que toute opération/modifcation sur un élement en production ou un élément qui contribue à la fourniture d'un service EST un changement (et ça inclut aussi bien de la doc type procédure, liste de contacts, que les changements d'organisation) => forte volumétrie de changements, certes. Ce qui compte c'est d'organiser la gestion des changements pour traiter efficacement ces flux. Ce qui peut se faire , par exemple en:
* définissant des catégories de changement préévalués et préapprouvés, exécutables immédiatement (mais tracés par RFC) , changements standards ou demandes
* définissant des catégories de changements en fonction de paramètres pertinents pour l'entreprise qui seront traités différemment (fonction du périmètre, de la volumétrie, etc....) par des workflows et potentiellement des CABs différents.

La charge de traitement des incidents et problèmes liés  à des changement non ou mal contrôlés est bien supérieure à la charge additionnelle générée par un contrôle de la gestion des changements. C'est ce qui a fait de la gestion des changements au sens ITIL une "bonne pratique".
Ca n'a pas été inventé dans un bureau d'études...