Forum ITIL France

Bonjour Gesmil et bienvenue sur le Forum,

Un schéma valant mieux qu'un grand discours, voici le fonctionnement d'une demande de changement (RfC) et son cycle de vie entre la Gestion des changements et la Gestion de projet.



On voit bien que la RfC entre par la Gestion des changements.

- Si dans ton cas la demande de changement est à l'origine de la Gestion de projet, une fois rédigée elle passe par le CAB ou le Gestionnaire des changements pour approbation, puis revient dans le giron de la Gestion de projet.

- Si la demande provient de la MOA ou d'un Client, la RfC passe par le CAB ou le Gestionnaire des changements pour approbation puis est réalisée par le Gestion de projet.

Le projet n'est pas un changement, c'est la conséquence du projet qui doit provoquer un changement. La définition d'un changement est : "L'ajout, la modification ou la suppression d'un élément de configuration (CI) approuvé"

Quant à la question faut-il une ou plusieurs RfC cela dépend de l'étendue de la demande de changement. Si il s'agit d'un ajout de serveur il y aura une RfC. Si il s'agit de l'ajout d'une application, couplée à l'installation de 1 ou "n" serveurs, ainsi que des postes de travail, il est peut être plus logique de faire 2 ou 3 RfC.

Que doit contenir la RfC ?

Une description précise du changement. Suffisamment précise pour que le Gestionnaire des Changements et le CAB puissent évaluer et approuver la RfC.

Encore une fois il faut faire simple, et mettre en œuvre une méthode qui ne "révolutionne" pas inutilement les équipes.

L'objet de la gestion des changements est de s'assurer que les changements sont contrôlés et qu'ils n'impactent pas les opérations.

Ai-je répondu à toutes tes attentes ?

Merci Gesmil pour ce cas très classique dans les discussions au tour des logiciels, des projets, la gestion IT quotidienne et les changements.

Il n'sxiste pas une seule reponse pour ce cas. Je vais essayer de vous donner les réflexions (aussi de mon experence dans la passé) pour et contre des differents approches:

Etant donné que les départements d'études et le DSI sont assez souvent bien "eloigné" l'un de l áutre (si c'est pas "geographique" c'est au moins dans les "sentiments") le premier besoin est de la communication et de la compréhension entre les metiers (MOA), les études et al DSI.

Les DSI ont màre que les études "lancent" souvent leur "dernier née" (donc un application ;-) ) par dessus le "mur" qui sépare les études et la DSI. Les études ont màre du fait que la DSI souvent refuse ou ne veut pas coöperer dans l'installation d'une nouvelle application.

Le but du processus de la gestion des changements est de preserver l'integrité de l'ensemble des services opérationelles (sachant que souvent pas loins de 80% des incidents sonts causés/provoqués par les changements, source: Gartner) et de s'assurer que les changements sont déroulés 'une façon qualitative.

Souvent on ne prévient la DSI (en donc gestion des changements) que quand l'application est prêt à être installée. La gestion des changements va tester si l'application en question se "comporte" correctement sur un environnement de test de pre-production et si cela se passe sans problème planifier l'installation. Après l'installation la gestion des operations doit gérer l'application en production et le servicedesk reçoit les appels et les incidents concernant cette application. Mais......... quoi faire si:
- la gestion des changements refuse l'application à cause de mauvaise fonctionnement
- la gestion des changement n'arrive pa à planifier le changement selon les desirs des MOA parce que il y a d'autres changements déjà planifié qui
  interferrent avec l'implementation de cette application
- la gestion des opérations refuse de gérer l'application en operation parce que il ne sonts pas formés ou ils ont pas la capacité
- le servicedesk et la gestion des incidents refusent de s'occuper de cette application parce que ils en savent rien du tout

j'ai connu la situation de chez Telecom aux Pays Bas ou meme les petits changements applicatives prenait facilement 3 mois pour être installées sur les 30.000 postes de travauil (après que les études les avaient realisées).

Apres un changement d' approche on à pu installe le meme genre des applications dans les 3 semaines.

Le changement d'approche? Les MOA demaindait au gestionaire des changements de changer quelque chose dans un application. Le gestionaire des changements faisait un premier elaboration de risque pour ce changement (ensemble avect les MOA ét les études) et puis nommait un chef de projet pour realiser le tout. Le chef de projet avait donc comme client le change manager qui lui à son tour assurait que tout le monde (études, gestion des opérations, servicedesk etc) etait au courrant, contribuait ét communiquait.

Cela peut seulement bien marcher si:
- le comité de direction donne son support
- le change manager se trouve assez "haut" dans l'hierarchie
- DSI et les études comprennent très bien que eux ils sont lá pour servir les métiers et qu'ils ont meilleur temps de se mettre ensemble pour realiser ce service aux metiers
- gestion des changement est apercu comme facilitateur (analyse de risque, planification, tests et surtout communication!!!) et non comme "monsieur NON"

Bonjour Learner et bienvenue sur le forum,

A la lecture de ton contexte, je traduit EB en "Étude du Besoin ou plutôt Expression de Besoin". En clair, quels sont les besoins du client (MOA) et comment les présenter afin de rédiger un cahier des charges.

J'avoue ne pas savoir si il existe des méthodes pour faciliter l'expression de besoin, en revanche une première approche consistera pour toi à qualifier les attentes, tant d'un point de vue métier (ce pour quoi ils veulent initier le projet) que d'un point de vue technique et fonctionnel (comment ils veulent se servir de ce nouveau "projet" et comment il sera conçu techniquement).

Si le client peut te répondre sur ces aspects cela te permettra de déceler ses attentes, ses besoins, ses contraintes, etc.

Il faut peut-être approfondir tes recherches sur "l'expression de besoin"

Bonjour Peter Gerritsen,

Je te remercie pour ta réponse.
Je te partage complétement les reflexions soumises.  Selon ITIL, la changement n'est construit par la MOE qu'après son approbation par le CAB / gestionnaire des changements. Cependant , dans un contexte IT, et concretement cela ne se passe pas ainsi. Le Gestionnaire reçoit la RFC après que le changement soit déjà construit et testé par la MOA et c'est lors de son passage au four " en prod" qu'ils se trouvent obliger de passer par le service des changements. A mon sens, pour un contexte IT,  ITIL decrit un processus gestion de changement ideal auquel les entreprises devraient atteindre mais le chemin est long pour avoir l'adhésion de tous les MOE et les MOA.
La difficulté est plus dans la conduite de changement que la gestion des changements !

Je souhaite rebondir sur ce message, car j'ai vécu une expérience très délicate autour de ce sujet.

Notre client était le Responsable de Production. Nous n'avons pas eu de contact avec la Direction des Etudes (grave erreur, les experts l'auront déjà compris !).

Lorsque nous avons commencé à aborder la gestion des changements, j'ai utilisé le schéma présenté plus haut (cf. ITIL_EXPERT). Chacun a approuvé le principe. Quelques jours plus tard, j'ai commencé à entendre des bruits relayés par le Responsable de Production : il se dit qu'ITIL essaie de donner le pouvoir à la production sur les études !

Les chefs de projet étude, informés des compte-rendus de nos travaux,  avaient réagi fortement à la phrase : Si la demande de changement émane de la Gestion de projet, une fois rédigée elle passe par le CAB ou le Gestionnaire des changements pour approbation, puis revient dans le giron de la Gestion de projet.

En effet, il existait déjà un comité d'approbation pour les demandes émanant de la gestion de projet. Quel était donc ce nouveau comité (CAB), voire Gestionnaire (un seul homme, qui plus est, issu de la production !) qui aurait autorité sur nos projets !!?

J'ai essayé de désamorcer la bombe, en précisant bien que les comités existant n'étaient nullement remis en cause, mais qu'il y avait lieu de voir plus large, et de considérer tous les changements dans ces  comités, au lieu de traiter d'un côté les projets, et de l'autre les changements initiés par le reste du monde, que le CAB n'était pas une instance inféodée à la production, mais bien une instance commune à toute la DSI.

A la réflexion, je pense que chaque parti avait conscience de la nécessité de cette instance commune d'approbation ... mais certains n'étaient pas disposés à partager leur pouvoir ...

Erreur de debutant du consultant ... mais grande leçon apprise ! Depuis, je m'assure toujours du soutien de la direction des études et je m'attache à les rassurer et impliquer dès le départ.