ITIL.FR - Portail Francophone des Meilleures Pratiques
Vous n'êtes pas identifié.
- Pour participer aux échanges, pensez à vous Enregistrer sur le Forum -
Bonjour
Je viens vers vous pour solliciter votre aide en tante qu'expert !!
D'apres mes connaissances :
Processus-->Sous processus-->Activités-->Procedures ou Bonne pratique--> Instructions de travail
J'ai appliquer ce cheminement pour mon processus Gestion des Changements.
Exemple : Procedure de l'Activité Approuver le Changement majeur de mon sous processus Approuver et valier le Changement.
D'apres des retours de collegues et consultants experts, je fais fausse route : ce que j'ai fais ne sera pas Utile/Itil.
J'aurai du faire des procedures en fonction de la "typologie" du Changement ex : IPL et non en fonction de la "Qualification" du Changement (Majeur, Normal, Standard, Urgent).
Apres reflexion, je me dis que ce serait en effet plus productif de suivre leurs conseils. La procedure sans pour autant qu'elle soit technique se basera sur des elements concrets. Ma procedure fera référence à un mode opératoire qui lui sera technique et se basera pas exemple les etapes à executer sur l'outil pour realiser la tache.
J'aurai au travers de ca, un complete adhérence des operationnelle.
J'espere etre tres precis sur mon probleme.
Qu'est ce que vous en pensez ?
Et si cela est possible, auriez vous des modeles à me fournir ?
Merci d'avance pour votre aide.
MJ
Hors ligne
Je prefere les grande lignes, ne pas trop detailler le choses donc:
Processus -> Phases ou etapes(ou procedure si on veut) -> activités (qui son decrive dans des instructions de travail si besoin)
Dans l'idee qu'on ne peut pas approver un changement sans le connaitre en detail il faut d'abord savoir de quel genre de changement il s'agit. Pour moi cela se decompose en:
- categorie de changement: harware, software, procedure, etc donc: qu'est ce qu'on va changer
- l'urgence de changement: urgent*, haute, moyenne, basse
- impact du changement: mega* haute, moyenne, basse, standard*
En effet ces donnés te montrent également quel niveau organisationelle doit prendre la decision finale pour faire le changement (en V2 toujours le Change Manager, en V3 le niveau hierarchique approprie. Ceci montre aussi la necessité d'un CAB et qui doivent assiter au CAB.
* il est bonne pratique qu'un changement urgent suit une procedure à part, y compris decision, designe pour ce genre de changement (voir ECAB). Pour les changements standard (qui ne demandent pas un autorisation pontule di changemenager parce que ils sont déjè pre-autorisées) on utilise ;egalement une procedure à part. ITIL dit très peu sur les changements avec un impact "mega", mais je conseille de definier une procedure à part aussi
Toutes les autres changememts suivent la procedure normale.
Je deconseille de classer les changements selon leur nature technique tres detaillé. En revanche pour certain changements d'un même nature technique on peut definir un "model de changement" que est en fait l'approche standard pour un tel changement bien connue que se repete regulierement.
Hors ligne
Merci de m'avoir répondu avec autant de precisions.
Je vais analyser ce que tu m'as ecris.
Hors ligne