Implémenter ITIL V2

 Pour obtenir une version PDF de ce document, envoyez moi un mail à info@smartin-conseil.ch.

1    Introduction

2    Organisation du projet

3    Rôle à prévoir

4    Communication du projet

5    Accompagner le changement

6    Administrer son environnement

1                   Introduction

Mettre en place une approche de Service Management est un projet différent des autres. En effet, au delà de mettre en place un outil de support, cette réalisation impacte les processus de travail de l’IT. L’équipe en charge de l’implémentation est donc confrontée à de nombreux enjeux simultanément dont tous doivent être prise en compte :

Technique : il s’agit le plus souvent d’intégrer une application de support dans l’infrastructure existante

Organisationnel : l’objectif est de rationnalisé les processus de travail et va donc impacter les habitudes et la culture des collaborateurs.

Dans ce document, nous allons aborder l’ensemble des points à prévoir pour faciliter le projet et anticiper les difficultés futures. La gestion de projet à proprement parlé n’est pas abordée. Elle reste évidemment nécessaire, un accent est mis ici sur les spécificités de ce type de projet.

2                   Organisation du projet

Suivant la taille du projet, plusieurs interlocuteurs interviennent dans le projet

2.1     Rôle du consultant ITIL

Souvent en amont du projet, le rôle du consultant est de comprendre les enjeux écrits ou non du client. En effet, en tenant compte des objectifs de gouvernance à atteindre, de la culture de l’entreprise, de la maturité existante et du coefficient de l’acceptation du changement, il doit émettre des recommandations aussi bien sur le type d’outil qui pourra supporter les processus que de leur définition.

Il doit donc accompagner le client et être le référent du référentiel. Dans ce cadre la, il doit pouvoir systématiquement proposer des améliorations organisationnelles et être moteur du changement chez le client.

2.2     Rôle de l’éditeur

L’éditeur du logiciel qui va supporter les processus a un rôle primordial. En effet, souvent choisi par appel d’offre, il s’est battu et a souvent du prouver ses capacités. Il peut souvent être un frein dans le projet tout en restant un élément nécessaire.

En effet, il faut sans cesse se rappeler que l’objectif du projet est d’améliorer les processus métiers de l’IT, pas uniquement d’implémenter un nouveau logiciel. C'est-à-dire que le temps passé doit servir à accompagner le client, à répondre à ses attentes. Or, dans de trop nombreux projets, la première utilisation du temps alloué est de configurer l’outil, de l’interfacer voir pour certains de les debugger. Le logiciel doit donc rester un outil du changement, pas la raison du changement.

Inversement, il est nécessaire que le consultant ITIL et le client assume ses responsabilités : l’accompagnement du changement auprès des opérateurs ne doit pas se justifier à cause de l’outil.

2.3     Rôle de l’intégrateur

L’intégrateur est souvent le représentant de l’éditeur. Dans ce cadre là, il a la même position que l’éditeur. Il est nécessaire de bien s’assurer que leur relation est parfaite. Le consultant doit donc connaître parfaitement l’outil, mais aussi l’environnement ITIL car il doit pouvoir discuter d’égale à égale avec le consultant ITIL. Ainsi, il comprend les objectifs de tels ou tels fonctionnalités nécessaire et pourra la traduire au travers des possibilités offertes par l’outil. L’éditeur et l’intégrateur ne doivent pas non plus se renvoyer les responsabilités en cas de dysfonctionnement car cela aurait un impact important pour le projet.

C’est aussi la raison pour laquelle, il est très courant que l’éditeur propose ses propres consultants. L’intégrateur et l’éditeur ne font alors plus qu’un. Et le client a la satisfaction de savoir qu’un dysfonctionnement, une évolution nécessaire sera convenablement défendu.

2.4     Périmètre du client

Le rôle du client est de trouver le juste milieu entre défendre sa culture, son historique et être moteur du projet. Il est le seul dans le projet à connaître le niveau de tolérance au changement de son entreprise et s’est à lui que la responsabilité de vendre ses améliorations dans l’entreprise doit se faire. Bien évidemment, le chef de projet doit avoir le soutien de sa direction.

En effet, trop souvent, cette responsabilité est reportée sur le consultant ITIL : « C’est ITIL qui le dit, donc on doit faire comme cela » ou sur l’éditeur « C’est l’outil qui ne peut pas faire autrement ». Si cette solution au court terme s’avère souvent la plus simple, elle génère une rancœur aussi bien contre les bonnes pratiques proposées que contre l’outil choisi. C’est alors ces éléments là qui incarne les raisons pour laquelle chaque opérateur est bousculé dans ses habitudes. Le rejet se focalise donc dessus et cela bloque le projet complètement le projet.

Il serait donc plus cohérent et plus courageux que les vrais raisons soient présentés et les vrais objectifs. En effet, dans le cadre de la mise en place des processus ITIL, une confiance doit se créer avec les opérateurs. S’agissant d’activités transverses, il faut trouver les motivations pour que chacun prenne ses responsabilités sans créer de contraintes hiérarchiques. Pour créer cette relation, il faut commencer par l’appliquer au projet.

2.5     Moteur et frein de chacun dans le projet

Pour chaque intervenant, voici les moteurs et freins à chacun. Les objectifs et les enjeux du projet sont très différents pour chacun. Il faut trouver les dénominateurs communs pour garantir le succès du projet.

Acteur	Moteur	Frein
Consultant ITIL	Etre au plus près des recommandations Sentir le soutien du client dans l’organisation proposée Positionner le logiciel comme un outil de support au processus	Subir les contraintes de l’outil dans l’organisation qu’il propose Voir une prise de distance entre les propositions exprimées, validés par le client puis non soutenu
Intégrateur	Tenir les engagements de jours Etre au plus près du standard de l’outil Comprendre l’organisation proposée par le consultant ITIL pour apporter les réponses dans l’outil	Revenir sans cesse sur les spécifications validées Modifier le périmètre de son intervention
Editeur	Avoir un consultant ITIL prenant en considération les contraintes techniques Prouver que les engagements pris lors de la signature sont tenus	Renvoyer les changements organisationnels aux contraintes de l’outil Remise en question du choix de l’outil
Client	Tenir les délais, les engagements et les coûts Garder le soutien de la direction et des équipes Sentir l’implication de tous les partenaires	Perdre la visibilité du projet Être mis en défaut face à sa hiérarchie Perdre la confiance aux intervenants externes

3                   Rôle à prévoir

Décider d’améliorer son organisation en se reposant vers les bonnes pratiques nécessite de définir des rôles et des responsabilités très tôt dans le projet.

En effet, plus rapidement ses managers sont intégrés dans le projet, plus rapidement, ils vont pouvoir proposer leur vision du processus et s’impliquer dans leurs responsabilités et vivre le processus dont ils ont la charge.

Pour chaque processus mis en place, un manager doit être défini. La charge de travail dépend du processus et de la taille de l’entreprise. Certains rôles peuvent être cumulés.

Voici une présentation des principaux managers de processus rencontrés dans les projets.

3.1     Manager de processus

3.1.1     Incident

Son rôle est donc de garantir que non seulement le processus d’incident répond aux attentes et aussi d’améliorer le fonctionnement.

Il doit donc dans un premier temps s’assurer que les incidents sont traités convenablement. Il peut pour cela :

Surveiller des indicateurs : fond de roulement en fin de journées, temps moyen de traitement, Nombre de ticket en retard par groupe…

Rencontrer des responsables d’équipe : s’assurer que les opérateurs se retrouvent dans le processus, que le temps imparti pour le traitement des incidents correspond aux objectifs fixés.

Rencontre avec des utilisateurs : s’assurer que les utilisateurs sont satisfaits, que les informations transmises correspondent aux attentes.

Il doit aussi améliorer le processus d’incident. Et pour cela :

Surveiller des indicateurs : Temps de traitement par état, Nombre d’incident escaladé, Qualité de saisie des informations, nombre de groupe impactés…

Rencontrer des opérateurs : lorsqu’un incident n’est pas convenablement traité et que ses répercutions sont importantes, une réunion de débriefing est nécessaire. En effet, il est nécessaire de comprendre ce qui n’a pas fonctionné et pourquoi cette situation de crise s’est créée. L’objectif de trouver la faille du processus et de proposer une adaptation du processus, non le coupable.

Rencontre avec des utilisateurs : cela peut se faire au travers de sondage de qualité afin de mesurer la qualité du service rendu.

Pour toutes ces activités et plus encore lorsqu’il traite avec les équipes IT, l’incident Manager sera confronté au manque de temps des opérateurs, aux priorités affectés sur autre chose que le traitement des incidents, parfois même de la mauvaise volonté. C’est pourquoi, sans obligatoirement avoir un poste de responsabilité, il doit avoir une légitimité reconnu par la direction et son appui.

Ainsi, lorsqu’un opérateur ne tient pas le rôle qu’on attend de lui dans le processus, l’incident manager discute et essaie de comprendre les raisons : trop de travail, pas d’information sur l’outil de support pour traiter les incidents, pas compétent pour résoudre l’incident… et va lui proposer une solution :

Discussion avec son responsable pour comprendre les priorités de travail, propose une formation sur l’outil de support, propose des référents techniques suivant le domaine traité.

Si cette situation perdure, que les engagements d’amélioration pris n’ont pas été respectés, l’incident manager doit alors se tourner vers la direction car cela peut devenir de la mauvaise volonté, voir un refus d’assumer ses responsabilités dans le processus. Ce désaccord doit alors se traiter au travers de la hiérarchie qui sera à même de lui rappeler le cahier des charges du poste ou lui changer ses responsabilités.

L’incident manager est très souvent confronté à ce type de cas. Le traitement des incidents est souvent une tâche d’exploitation pour les niveaux 3, notamment, et est traité comme tâche de fond, leurs responsables leur affectant alors des projets. Une satisfaction se créé : les projets du responsable avancent et vont lui garantir un succès en fin d’année, l’opérateur est stimulé intellectuellement sur des améliorations à mettre en place. Il est souvent nécessaire de rappeler l’importance des incidents et que derrière chacun d’eux, il s’agit d’un utilisateur qui ne peut pas faire son travail.

3.1.2     Changement

Le rôle du change manager est principalement dans l’opérationnel. En effet, au delà de devoir étudier les améliorations de son processus et les mettre en place. Son rôle est souvent déterminant dans le processus.

Tous les changements sont qualifiés dès leur création par le change manager. Il doit donc avoir les informations les plus pertinentes afin de mesurer l’impact, l’importance et la nécessité du changement, C’est la raison pour laquelle, les champs de type :

·         Raison du changement

·         Impact si non réalisé

·         Eléments impactés…

Sont des champs présents dans le formulaire de déclaration.

En fonction des informations fournies et basé sur ses expériences, le change manager va :

·         Valider ou le refuser le changement

·         Convoquer ou informer le CAB (conseil de validation des changements)

Lors de cette séance, le rôle du CAB est de conseiller le change manager pour accepter ou non le changement.

La décision finale est donc prise non pas la majorité mais par le change manager. C’est lui qui porte la décision, lui-même appuyé par les avis d’expert présent.

Ainsi, si un change dysfonctionne, le change manager est responsable de la décision. Si cette dernière a été prise sur des avis et des conseils mal avisés, les experts deviennent alors coresponsables.

Dans la suite du processus, le change manager a plus un rôle de supervision afin de garantir :

·         Le change est effectué dans les règles de l’art, au travers du processus de mise en production si nécessaire

·         Les modifications sont répercutées dans les autres processus : configuration, connaissance…

·         Le changement est correctement documenté dans le PIR (Post Implementation Review)

Le change manager a donc un rôle beaucoup plus opérationnel que l’incident manager.

3.1.3     Connaissance

Ce rôle complète souvent le rôle d’incident manager ou de Service Desk manager. Il ne s’agit pas là de renseigner la base de connaissance mais de s’assurer que ses informations vivent.

Ainsi, il doit valider les données entrantes afin de :

·         Corriger les fautes de grammaires et d’orthographe pour faciliter la recherche full texte notamment

·         Vérifier que l’information proposée ne génère pas un doublon dans la base

·         Compléter les attributs de l’information : classification, mot-clé, date de fin…

Ensuite, pour assurer la pérennité des données, une revue par périmètre technique de cette base de connaissance doit être organisée avec l’expert référent du domaine.

Enfin, il doit s’assurer que la base proposée aux opérateurs est bien utilisée. En effet, une base de connaissance non utilisée devient obsolète et les informations contenues se perdent.

3.1.4     Service Manager

Ce rôle est souvent mis au deuxième plan car il est mois opérationnel que les précédents et nécessitent plus de stratégies. Il pourrait se comparer au rôle de chef de projet dans d’autres cas. On a attend  du Service Manager :

Stratégie  afin de définir les améliorations globales à mettre en place : nouveau périmètre, nouveau processus…

Coordination afin définir avec précision les périmètres de chaque processus et de simplifier les interactions entre chaque processus.

Conviction afin de soutenir la mise en place effectuée auprès des opérateurs, de justifier le bien fondée de cette démarche et de montrer la plus-value quotidienne de cette confiance.

3.2     Administrateur applicatif

Ce rôle est beaucoup plus technique car il s’agit de savoir configurer parfaitement l’application supportant les processus.

En effet, il est important que ce rôle soit bien défini ou pour une personne interne ou sur un externe très disponible. Les processus sont continuellement en amélioration continue, il est donc nécessaire régulièrement d’adapter la configuration de l’outil afin de répondre à ces changements.

Et face à des difficultés d’amélioration, il doit être un référent capable d’apporter une réponse claire de la faisabilité ou non dans l’outil. En effet, bien qu’on s’interdise souvent dans les projets d’IT Service Management des contraintes liées à l’outil, il est difficile d’aller à l’encontre. Et une gouvernance IT recommande toujours d’être au plus standard des outils choisis pour une optimisation des coûts. C’est pourquoi, chaque amélioration souhaitée dans l’outil pour le bien d’un processus doit être présenté et validé par cet administrateur applicatif. Ce dernier pourrait même proposer d’autres solutions techniques plus appropriées.

4                   Communication du projet

Comme cela était préciser précédemment, un projet de Service Management impacte la culture d’entreprise et les habitudes de travail. C’est pourquoi, à l’instar de nombreux projets informatiques, la communication est une part importante du projet ; et cela, durant la phase de projet, le démarrage et l’accompagnement. Seul les messages et les interlocuteurs changent entre ces différentes phases.

4.1     Avec la direction

Il s’entend par direction aussi bien la direction du SI que celle de l’entreprise. Cette communication se passe généralement en amont du projet. Voici les axes de présentation du projet à mettre en exergue :

Réduction des risques : risque technologique et risque humain : simplification dans la gestion des risques

Amélioration des services rendus aux utilisateurs : augmentation de la stabilité du SI, transparence…

Meilleure maitrise des coûts : répartition des charges, prévision des coûts…

Mesure de la performance : mise en place d’indicateurs permettant le pilotage par indicateur et démarche d’amélioration continue

Alignement de l’IT au besoin métier : l’IT doit répondre aux attentes et proposer une facilité sans devenir une charge ou un frein au développement métier de l’entreprise.

C’est pourquoi, il est nécessaire de mettre en place une démarche en spirale afin de revenir régulièrement et présenter des résultats concrets.

La mise en place de tel processus ou telle organisation doit se justifier. Il est important de rappeler que les bonnes pratiques ITIL sont un moyen pour obtenir des résultats à des objectifs de gouvernances IT. Le résultat ne peut donc pas être le processus en lui-même.

Par exemple, la mise en place du processus de configuration ne peut pas simplement proposer la mise en place d’une CMDB comme résultat attendu. Il est plus important de présenter les plus-values comme :

·         Faciliter dans la budgétisation de l’infrastructure

·         Suivi des licences

·         Faciliter dans la préparation d’une migration applicative ou matérielle

·         Réduction des risques dans le suivi du versioning de l’anti-virus….

La mise en place d’un catalogue de service va lui permettre :

·         Augmenter la transparence des services fournis aux utilisateurs et donc simplifier les demandes aussi bien dans la définition des besoins que sa réalisation

·         Faciliter de mise en place du sourcing map

·         Simplification dans la mise en place de budget prévisionnel.

·         Management des besoins des utilisateurs et suivi du changement de besoin : connaissance des services en forte demandes et des services désuets

4.2     Avec les participants du projet

La communication doit être transparente avec tous les membres du groupe projet défini précédemment. Cela permet déjà d’attendre une réciprocité.

Il est donc claire que les objectifs, les risques du projet, les responsabilités de chacun soient clairement annoncés et connu.

Pour cela, il est proposé d’utiliser un outil : le PAQ : Plan d’Assurance Qualité. En effet, celui-ci peut servir de document de référence présentant les membres du projet, le périmètre des lots prévu, les procédures de travail…

Ce document ne doit pas être statique, bien au contraire. Il peut servir d’outil d’apprentissage d’utilisation du processus d’amélioration continue :

·         Une première version est écrite et proposée pour validation

·         Chaque remarque des parties prenantes est validée et intégré au document

·         Chaque dysfonctionnement ou erreur dans la gestion du projet et la source d’amélioration du document

4.3           Avec les utilisateurs

La communication doit se faire lors du démarrage en production. En effet, il est important de présenter les améliorations proposées à chaque mise en production.

Communiquer sur ces avancées permet de mettre en avant la volonté du service IT de vouloir progresser.

Si les résultats sont visibles, ils pourront alors être mis en avant afin de négocier des SLAs.

Dû au changement de relation entre l’IT et les utilisateurs, aucun changement pouvant être vu comme contraignant ne pourra être imposé.

Si un changement d’habitude est recherché chez l’utilisateur comme :

·         Utilisation d’un Self-service

·         Recherche dans une base de connaissance avant appel

·         Suivi on line de l’avancement d’un incident…

Il sera nécessaire de vendre cette amélioration à l’utilisateur. Et pour cela, les bonnes pratiques utilisées dans la grande distribution sont de bonnes idées :

·         Offre promotionnelle : temps de résolution raccourci en passant par le Self-service

·         Garantie de données actualisées : situation en direct des indisponibilités en première page de la base de connaissance

·         Simplification d’utilisation : Catalogue de service présentant l’offre transparente des besoins auquel le service informatique peut répondre

·         Engagement ferme et tenu : comme dans la grande distribution, si les promesses faites ne sont pas tenues, il sera alors beaucoup plus difficile de convaincre par la suite.

Le canal de communication et la forme sont aussi des éléments à prendre en compte. Privilégié une méthode ludique au traditionnel mail de plusieurs dizaines de mails.

4.4     Avec les opérateurs

La communication avec les opérateurs doit être transparente et doit commencer suffisamment en amont du projet.

Elle doit être personnalisée le plus possible à chaque profil d’opérateurs. En effet, le réflexe de chaque opérateur confronté à un changement de ses habitudes va vouloir savoir quel sera l’impact pour son travail.

Lorsque ce message sera acquis et intégrée, le besoin portera alors sur le pourquoi. C’est la raison pour laquelle, le message doit présenter les objectifs et les orientations de façon transparentes.

Il est préférable de communiquer par le biais de réunion et de rencontre qu’uniquement par moyen électronique. A cela plusieurs avantages :

·         La communication sera bidirectionnelle : l’information transmise sera évaluée et des précisions pourront être apportées directement

·         La communication sera plus impactant : le message reçu sera plus important que par un mail

·         La communication sera moins formaliste : il va s’agir de les convaincre de la plus –values de ces changements.

Dans cet exercice, plusieurs pièges sont à éviter :

·         Les opérateurs ont naturellement plutôt tendance à voir l’ajout de travail que sa simplification. C’est pourquoi, il est important d’insister sur les échanges de charges effectuées comme :

·         On vous demande de trouver le temps de saisir dans la base de connaissance la solution technique que vous avez mis en place MAIS cela vous permettra de recevoir moins d’incident par la suite.

·         On vous demande de transmettre cette information au processus de configuration MAIS cela sera à même de vous fournir des données fiables dont vous n’aurez plus la gestion…

·         Les opérateurs ont parfois tendance à déconnecter leur travail du premier de tous les objectifs : l’IT doit répondre aux attentes des utilisateurs. Les discutions de répartition et/ou charge entre les équipes doivent toujours se faire dans cette optique et non devant des raisons politiques ou des pré-carrés existants.

De manière plus général, cette communication est le support d’un action importante et qu’il ne faut pas négliger dans ce type de projet d’implémentation ITIL : l’accompagnement au changement.

5                   Accompagner le changement

Au risque de se répéter, un projet de mise en place des processus ITIL impactent fortement la culture et les habitudes de travail des collaborateurs car le périmètre ne s’arrête pas  à la mise en place d’un outil. C’est pourquoi, cette partie du projet ne doit pas être négligé pour se garantir les meilleures chances de réussites.

5.1     Avant le projet

Le projet doit être géré le plus transparent possible vis-à-vis des opérateurs. En effet, dès le début, il doit être présenté le planning, les objectifs, les améliorations souhaitées.

En effet, cette communication pro-active va permettre de désamorcer les risques d’incompréhension. Le projet n’a pas l’objectif principal de tout changer mais de répondre à certaines problématiques :

°         Besoins de l’utilisation non pris en compte

°         Amélioration des temps de résolution…

En communication suffisamment tôt, il est possible de faire prendre conscience que les améliorations se font dans une logique gagnant-gagnant aussi bien pour l’entreprise, le collaborateur que les utilisateurs.

5.2     Durant le projet

L’avancement du projet doit également nécessiter une communication. Dans ce cadre, il faut rappeler les étapes à franchir mais également celle déjà réalisé. En effet, de très nombreuses fois, les opérateurs critiques ce qui reste à faire mais ne prennent pas conscience du chemin parcouru. C’est pourquoi, il est toujours motivant de montrer que l’organisation s’améliore, que des objectifs sont atteints.

5.3     Après le projet

Après le projet, il y a le projet ! En effet, l’implémentation initiale permet de mettre en place une organisation différente. Et il faut continuer de promouvoir et de cultiver cette approche différente. C’est pourquoi l’accompagnement qui suit le démarrage doit insister sur :

°         Le travail réalisé : rappeler les difficultés qui ont poussé vers cette démarche et montrer qu’elles ont été surmontées

°         Le travail à fournir : s’agissant d’une démarche d’amélioration continue, le projet doit toujours être en amont des besoins organisationnels afin de tirer vers plus de maturité les équipes IT.

6                   Administrer son environnement

Il s’agit la d’administrer aussi bien l’outil que les processus. Attention, l’outil doit, comme son nom l’indique rester l’outil. C'est-à-dire qu’il est la pour rendre service et pour répondre au besoin premier : supporter l’organisation. Cela ne veut pas dire qu’il ne faut pas se soucier des possibilités de l’outil mais que les améliorations organisationnelles ne doivent pas se décider uniquement par les possibilités de l’outil ou les améliorations proposées par l’éditeur.

6.1     Pilotage par indicateur

Il est facile de décrire cet outil de pilotage car il répond à une logique simple. Lorsque vous conduisez, vous faites appel à votre connaissance pour décider ou aller et comme y aller. Mais vous avez à votre disposition, un ensemble d’indicateur qui vous permet de savoir si tout se passe bien : la vitesse pour rester la législation en vigueur, les alertes, si le moteur chauffe, si l’huile manque…

Piloter ses processus revient au même, le owner du processus sait où doit s’améliorer son organisation. Les indicateurs vont lui permettre de mettre des valeurs sur ce qu’il ressent et voir la progression.

Il ne faut pas reporter l’implémentation d’indicateurs en fin de projet car ils vont vous permettre de vendre le travail réalisé à tous les niveaux :

°         Management : confirmation des résultats attendus

°         Opérateurs : visibilité sur les efforts consentis.

Il s’agit donc de définir quels sont les dysfonctionnements à corriger. Il sera alors nécessaire de choisir quels indicateurs pertinents nous permettront de mettre en valeur ce dysfonctionnement et de voir si le travail portera ses fruits.

Après le développement des indicateurs, il s’agit de les présenter et de les utiliser pour comprendre ce qui doit se passe. C’est pourquoi, un indicateur peut être remis en cause, amélioré, adapté.

Une grave erreur consiste à développer des indicateurs qui fournissent des valeurs dont on ne sait pas à quoi elles servent et comment les lire.

Imaginer que dans votre voiture le compte-tour et le compteur de vitesse ne contiennent aucune indication. Conduiriez-vous de la même façon ?

Maintenant, un indicateur présente une valeur, il reste nécessaire de l’expliquer et de la commenter. Votre compteur de vitesse vous donne votre vitesse mais cela ne veut pas dire que vous respectez la vitesse. Cela dépend de l’environnement dans lequel vous êtes : autoroute, campagne, ville…

Un indicateur doit se traiter au même niveau. Pour le présenter, il faut donc :

°         Préciser ses raisons d’existence : réduire le temps de traitement des incidents, réduire les indisponibilités, augmenter le taux de résolution du Service Desk….

°         Préciser son calcul : il calcule telle valeur en fonction de tels critères en excluant tels cas

°         Préciser le plan d’amélioration : nous souhaitons qu’il arrive à telle valeur avec ce palier pour le mois prochain

°         Préciser le plan d’action : voici ce qui doit être fait pour le mois prochain

Il est donc important de travailler chaque indicateur plutôt que de fournir X rapports standards inutiles.

6.2     Amélioration continue

Comme présenté dans l’accompagnement, chaque cas de dysfonctionnement de processus doit être force de proposition. Prenons deux cas :

1.       Un incident a mal été traité. Il est revenu dans les sphères de la direction, l’utilisateur s’est plaint, un nombre important de personnes ont été impactés.
Il s’agit de réunir tous les intervenants du cas, du Service Desk au niveau 3 avec un membre de la direction et de comprendre ce qui s’est passé de façon factuelle. C'est-à-dire qu’il faut regarder les horaires de saisie, de transfert, des actions réalisées. Il ne s’agit pas de trouver un coupable mais une raison. C’est souvent parce que le processus n’est pas documenté pour ce cas là. Chacun pensait que c’était de la responsabilité de l’autre. La charge de travail ne permet pas d’être aussi réactif…
Enfin, il s’agit de mettre en place un plan correctif. Ce qui compte n’est pas ce qui s’est passé mais que cela ne se reproduira pas. Une charge importante peut nécessiter de mettre en place des alertes et une personne dédiée au suivi. Une mauvaise qualification peut se justifier par la méconnaissance du support et doit passer par de la formation, de l’accompagnement.

2.       Un cas de gravité 1 vient d’arriver. Il est traité dans les délais et selon les procédures. C’est aussi l’occasion de comprendre d’où il vient et si une amélioration peut être trouvée pour les autres cas. En effet, on se rend compte que ce type d’incident, la résolution se passe bien car tout le monde est sous pression. Pourquoi ne pas reporter cette situation sur les autres incidents en cohérence avec l’urgence.

Il est nécessaire de profiter de tous ses cas pour apporter des améliorations. Reposant sur des cas concrets vécus et souvent douloureux, l’apprentissage et l’amélioration des équipes est souvent plus efficace.

6.3     Administrer l’outil

Au-delà de l’administration technique liée à chaque logicielle, il s’agit bien de garder l’outil à son niveau de support. Souvent, le temps passant, l’administration des processus ITIL se résume à l’outil. Ce réflexe naturel pour un informaticien doit être combattu. L’outil propose des améliorations, des fonctionnalités. Il ne s’agit pas de les implémenter car l’éditeur ou l’intégrateur les jugent pertinente mais parce qu’elles répondent à un besoin ou vous permettent d’avancer sur le chemin de la maturité de votre IT.