Forum ITIL France / Audit gestion des incidents et préconisations ITIL

KARAELO · 10-07-2009 16:43:57

J’ai suivi la formation de certification ITIL Foundation V2 et V3.
Mais je n’ai jamais participé sur le terrain à des mises en place ITIL.

Actuellement ma mission est de faire un audit sur une infogérance pour un de nos clients. (Assistance et support aux utilisateurs bureautiques et exploitation du parc informatique) :
Le but étant de faire le delta entre l’existant et ce que préconise ITIL. Et de proposer des axes d’amélioration avec des préconisations ITIL.

Je n’ai qu’une vue théorique d’ITIL et je me lance donc , pour travailler sur du concret !

Une petite questions parmi d'autre :

En plus des incidents qui peuvent faire l'objet d'appel, il y a aussi toute une série de demandes diverses peuvent etre demandées au centre d’appel :
- Installation d’un poste de travail
- Installatiion d’un logiciel sur un poste de travail
- Interventions sur un serveur
- ETC…

Ces demandes bien répertoriées sont prises en compte dans le processus des incidents. (ITIL)

Chaque demande correspond t-elle a un (processus ou sous-processus) ? si oui le processus doit-il être décrit ? sous quel formalisme ?
Chaque demande est-elle un service (répertorié dans le catalogue des services) ?

cordialement

AdBot · 10-07-2009 16:43:57

yvmarchand · 15-07-2009 08:39:31

Bonjour,

Une première précision sur ces types d'appels, ils ne sont pas gérés au travers du processus Incident. roll

En effet, ce n'est pas un dysfonctionnement mais une demande formulée (plus ou moins clairement) par un utilisateur ou un client.
Pour les gérer, la V3 propose le processus "Request Fulfillment". Dans la V2 cette différence n'était pas si évidente.
Ces "Request Fulfillment" sont des sortes de changements préformatés disponibles dans le catalogue de service. L'impact client/business est connus et maitrisé, les délais de réalisation sont également connus et maitrisés.

En général, dans les outils de Service Desk, il est possible de différencier les types de ticket (incident, information, demande, …). Ainsi, lors de l’appel, le Desk identifie la nature de l’appel afin d’identifier au plus tôt le cheminent à suivre et fournir les informations nécessaires à la réalisation du ticket.

Donc au final, pour chaque demande répertoriée dans le catalogue de service les informations nécessaires à la réalisation du service doivent être identifiées et le canal de suivi de la demande doit permettre de stocker ces informations.

Est-ce plus clair ? Est-ce que je réponds à vos questions ?

Bonne journée

KARAELO · 20-07-2009 15:38:29

Merci Yves pour ta réponse ! c'est très sympa.

Ce que je voudrais savoir : c'est si toutes les demandes doivent être définies d'une manière exhaustive. ?
Sont-elle repertoriées dans le catalogue de service? Ou se situe physiquement le catalogue de service? quel format?

dans mon cas précis (Assistance et support aux utilisateurs bureautiques et exploitation du parc informatique) Quelles sont les types de SLA à mettre en place. doit t-il y avoir une OLA pour chqaque type de demande ? Chaques demandes doit-elle faire l'objet d'une documentation. (Check Liste de mise en place).

j'aurais aimé voir aussi un formalisme de OLA. ou un exemple de OLA.

Cordialement

Peter Gerritsen · 20-07-2009 22:11:05

Mefier vous de tous documenter de facon exhaustive, vous alez n'importe comment dans le futur rencontrer des demandes que n'etaient pas encore documenté et dans ce cas quoi faire avec...? Vous allez finir avec un paquest des documents ingerables

Pareil pour catalogue de services, SLA et OLA.

ITIL ne dit nulle part qu'il faut être au millimetre précis. Revenons au but d'une telle exercise.

On se met d'accrod avec le client (qui donne l'ordre, qui paye ou fournit au moins le budget) qu'on veut rendre service aux utilisateurs.

Qu'est qui dait être clair pour les utilisateurs?
- ou est-ce que je peux "deposer" mes demandes, questions, avertissements des pannes etc??
Reponse: un seul servicedesk, pour que 'est clair pour les utilisateurs et de sorte qu'on puisse gerer les appels/demands etc a partir d'un point
central (même si c'est virtualisé)
- pour quel genre des appels/demandes etc est ce que je peux appeler le servicedesk?
Reponse: un liste des examples ou on mentionne clair et nette que ce n'est pas exhaustive. Donne également met des exemples qu'un sercedesk IT
ne peut pas resoudre comme par ex. des asceneurs que sont HS

Ou est ce on decrit tout cela?
Reponse: dans un seul SLA que decrit l'ensemble des services

Quand est ce qu'on a besoin un OLA?
Reponse: quand un autre entité (avec un autre budget) dans votre entreprise serait responsable de resoudre les choses

mais surtout!!!!! Ne pas trop compliquer, ni trop contractualiser les choses. Simplifiez, simplifiez et simplifier, surtout au debut!

Pareil: ne dites jamais: le servicedesk va resoudres toutes les appels en 8 heures, mais le servicedesk va resoudres 80% (ou 90%) les appels en 8 heures

Bonne chance

yvmarchand · 21-07-2009 10:21:41

Bonjour,

Comme le précise Peter, l’exhaustivité n’est pas le but. L’utilisateur va évoluer, le besoin va évoluer donc le client va évoluer. Ce qui est défini aujourd’hui pour répondre à tout ne sera plus valable qu’a 75-80% dans 1 an.

A toi de définir des services génériques qui répondront toujours à 80-90% des demandes. Par exemple, fuie un service « Installation MSProject sur Vista en 3h » et privilégie « Installation d’outil bureautique » avec 2 variantes une « en télédistribution » l’autre « sur site ».

Pour définir les SLA avec tes clients, définie en amont pour chaque service 2 ou 3 SLA possibles (Glod, Silver, Bronze) suivant ce que vous pouvez faire et le cout que cela représente. Attention, je paraphrase Peter, le SLA n’est pas qu’un engagement de temps mais un accord sur des moyens, un délai et un pourcentage de qualité de réalisation.

L’aspect OLA est, de manière théorique, envisagé avant le SLA. Pour connaitre l’engagement à prendre avec le client, il est préférable de connaître les engagements réalisé et réalisable en interne smile
Mais concrètement les OLA sont parfois définis en avala des SLA.
Un OLA doit être générique et couvrir de façon simple (un A4) la relation entre 2 entités pour respecter les différents SLA. Facile à dire, plus difficile à synthétiser sad . On en revient à définir des services génériques pour simplifier tout ce qui en découle.

Le SPOC doit être le SDesk. A lui de catégoriser l’appel. Est-ce un incident ? Une demande de service référencée ? Une demande autre ?
Pour les demandes de services issues du catalogue de service les attendus sont connu, donc charge au SDesk de les demander à l’utilisateur. A terme tu peu mettre en place une IHM pour que les utilisateurs déposent leurs demandes, ensuite le SDesk les analyses et les affectes.

Selon ton contexte, tu n’es peut-être pas obligé de tous faire en même temps (SLA, OLA, CS, RFC, …). Par exemple tu peu commencer par initialiser le catalogue de service (sur des services simples de type quickwin), traiter les avec le SDesk et vérifier avec le client. Ensuite positionne des SLA (avec un délai de période probatoire) puis au fur et à mesure élargie votre catalogue de service.
En résumé, trouve une approche pas à pas qui te permet de faire grandir la solution.

Dernière modification par yvmarchand (21-07-2009 10:22:45)

KARAELO · 22-07-2009 14:15:14

Bonjour

Merci Peter et Yves pour vos précieux conseils qui permettent de passer de la théorie de la littérature à la réalité. Je vais en tenir compte.

Cordialement

Bruno.

#1 10-07-2009 16:43:57

Audit gestion des incidents et préconisations ITIL

10-07-2009 16:43:57

#2 15-07-2009 08:39:31

Re: Audit gestion des incidents et préconisations ITIL

#3 20-07-2009 15:38:29

Re: Audit gestion des incidents et préconisations ITIL

#4 20-07-2009 22:11:05

Re: Audit gestion des incidents et préconisations ITIL

#5 21-07-2009 10:21:41

Re: Audit gestion des incidents et préconisations ITIL

#6 22-07-2009 14:15:14

Re: Audit gestion des incidents et préconisations ITIL

Pied de page des forums