Vous n'êtes pas identifié.
1 - Un changement standard est pré autorisé par le CAB et le Change Manager.
Malgré cela, lorsque l'on fait ce type de changement, sommes nous obligés de levée une RFC pour tenir informé le change manager et garder une trace.
Si c'est la cas, étant donnée que le changement est préautorisé, le RFC est-il différent?
2 - Par quelle source un client peut-il et doit-il émettre une demande de changement évoluée (non standard). Les utilisateurs peuvent-ils aussi en faire.
Je m'explique:
Un client souhaite disposer d'une nouvelle fonctionnalité dans un de ses outils métiers (donc impact).
Doit-il faire la demande via le CS qui émettra une RFC et communiquera l'info au SLM?
Ou le client doit contacter directement le SLM car c'est une évolution d'un service. C'est ensuite le SLM qui émettra la RFC.
Un utilisateur peut-il contacter le CS pour émettre une RFC.
Dans mon esprit, l'utilisateur contact le CS pour sa demande. Le CS vérifié le SLA afin de savoir quelles sont les demandes comprises dans le contrat.
Si c'est Ok, émission d'une RFC sinon le CS indique qu'il ne pourra pas répondre à la demande, clôture le ticket et remonte l'information au SLM afin qu'il se rapproche du client pour faire évoluer le SLA si nécessaire (opportunité business).
Ai-je bien compris ces notions.
3 - Incident de capacité - RFC
Le gestionnaire de capacité constate qu'il pourrait se produire prochainement des Incidents car la capacité va manquer.
Un Incident étant notamment un événement pouvant provoquer une interruption de la qualité du service.
dans notre cas, le gestionnaire de capacité doit-il :
- créer un incident via le CS. Le CS créera une RFC.
- Ou il lève directement la RFC sans créer d'Incident.
Merci de vos réponses
Hors ligne
1 - Oui vous devez avoir des RFC "standard" allégé puisque il ne passera pas par le CAB.
2 - Il fait une demande via le Centre de Service ou le HelpDesk (pas la peine d'expliquer ce qu'est une RFC à votre client) et vos équipes la qualifie en RFC. C'est à vous de déterminer si la demande à un impact sur le SLA, et à votre SLM de contacter le client le cas échéant. Ne déplacez pas la complexité de la gestion de votre SI chez votre client, c'est contraire à la démarche ITIL.
3 - Faites au plus simple ! Chez nous nous ouvrons systématiquement des incidents. Cela nous permet, au travers de tableaux de bords, de les comptabiliser. Puis ils sont catégorisés en incident de capacité, sécurité, etc. Du coup rétrospectivement vous pouvez savoir si vous avez été proactif sur la capacité par exemple. Si l'on s'en tient à la théorie il faut ouvrir un incident, qui va déclencher une RFC, mais vous restez libre de faire ce qui convient le mieux à votre activité, organisation et à la taille de vos équipes.
ITIL_expert
1- La RFC standard est allégée du fait de sa pré autorisation et elle est pre remplie car sont deja insrits sur la fiche toutes les informations suivantes :
Risques et impacts : ils sont repertoriés et connus
Procedures de mise en oeuvre et de retour arriére sont disponibles.
Les acteurs sont identifies
La periode d'execution est predefinie et reccurente
Hors ligne
D'abord,
- il y a des RFC qui passent pas via le change manager parce qu'il les a pre-approuves, ce sont les fameuses changements standard. Dans le SLA (ou dans un document annex) on a une liste que mentionne les changements standards et notament qui est habilite a les demander et quel serait le procedure (voir formulaire) pour les demander. Ce formulaire est considere comme RFC et le changement doit etre enregistre dans la base des donnees de Changements pour assurer la tracabilite. Habituelllement les changements standards sont prise en charge par le service desk
- il y a des changements qui passent via le change manager mais pas via le CAB. Ce sont des changement ou le change manager peut lui meme (ou le cas echeant, avec son equipe) decider de les faire ou pas.
- il y a des changements qui passent via le CAB parce que le change manager ne peut pas decider lui meme sur le risque de oui ou non faire le changement. il faut essayer de restreindre au maximum les changements qui passent via le CAB pour ne pas trop alourdir le processus de Changement.
C'est à l'organisation de definir comment quil type de changement doit etre demandé et qui en decide.
Detail: selon ITIL V2 c'est dans tout les cas le change manager qui decide. Selon ITIL V3 c'est le change autorité qui decide (et c'est a l'organisation de decider qui serait le change autorite dans quel type de changement).
Dans le cas d'une necessite de changer qq chose pour garantir la capacite c'est bien le gestionaire de la capacite qui doit declencher le changement, sachant qui assez souvent il se fait epauler par le Problem Manager. Pas mal des problemes se produsent dans les domaines de Capacite, Disponibilite et Securite
Hors ligne