20799337954_ac5e09d7df_b

La priorité des incidents est souvent un souci dans les organisations. Si l’organisation n’est pas très mature, cela peut provoquer des frictions peu agréables au sein de l’informatique. J’ai souvent des clients qui me disent « nous avons une majorité de faux P1 ». Cela signifie qu’ils ont beaucoup d’incidents de forte priorité, mais qu’ils sont généralement requalifiés en incidents de faible priorité. Ce type de situation n’est pas totalement anormale, car la priorité d’un incident peut sans problème évoluer avec le temps. Le point qu’il est nécessaire d’améliorer et de comprendre est : « pourquoi autant d’incidents sont identifiés comme étant de forte priorité alors qu’ils ne le sont pas réellement ».

Qu’est-ce que la priorité ?

En fait la priorité est l’interprétation d’un SLA au niveau de l’informatique. Avec nos clients (internes ou externes), nous mettons en place un accord ou un contrat qui va codifier notre relation (horaires de service, type de fournitures, limites du service, etc.). Dans ce SLA nous allons aussi retrouver les performances que nous devrons fournir au niveau des services (temps de réponse, délais d’intervention, délais de remise en service, etc.). Cependant, si nous fournissons des SLAs aux différents acteurs de notre chaine de fourniture de service, il va être relativement difficile pour eux de comprendre si on est dans les délais ou hors délais de ce qui a été négocié. On doit donc transcrire ces SLA sous la forme d’une priorité, qui pourra aisément être comprise par tous les membres de l’informatique.

La priorité s’étale souvent de 1 (le plus prioritaire) à 5 (le moins prioritaire). Il est indispensable de lier chacune de ces priorités à un niveau de service. Par exemple nous pouvons trouver :

Priorité

Niveau de service

1

2 heures (24x7)

2

4 heures (24x7)

3

4 heures ouvrées

4

Jour ouvré suivant

5

Sur planification

Il est vital d’avoir ce lien entre la performance est priorité, sinon seuls les incidents de niveau 1 et 2 seront traités. On va repousser les incidents de niveaux inférieur à une date ultérieure qui n’arrivera qu’en cas d’escalade (donc, généralement dans la douleur et le conflit).

Mais comment est-il possible de déterminer cette priorité ? En fait nous utilisons deux éléments importants : l’urgence et l’impact. Ces deux axes sont souvent assez difficiles à différencier, car ils sont pleins d’ambiguïté. L’impact est l’effet négatif de l’incident sur le métier. L’urgence est le délai avant que l’impact ne devienne significatif. Pour bien comprendre, utilisons une métaphore. Imaginez que j’ai en main une bombe ACME de petite taille (comme celles utilisées par le Coyote pour essayer d’attraper le Road Runner) ayant une mèche de 30cm. L’impact de l’explosion est fort (car je vais être tout grillé comme le Coyote) et l’urgence est forte aussi, car je n’ai rien de mieux à faire que de tenter d’éviter cette situation. Imaginez maintenant qu’il y a deux bombes : 1 de grande taille ayant une mèche de 90cm et une de petite taille ayant une mèche de 2cm. L’impact de la bombe de grande taille est fort, car cela va volatiliser tout le quartier. Par contre l’urgence va être à éteindre la mèche la plus courte (donc la petite bombe), car elle va exploser avant la bombe de grande taille. Une fois que l’on sait cela il est relativement facile d’identifier les priorités correspondant aux différentes situations.

Voici un exemple de matrice :

 

Impact

Fort

Moyen

Faible

Urgence

Forte

1

2

3

Moyenne

2

3

4

Faible

3

4

5

VIP

Mais dans tout ceci, comment va-t-on gérer les VIP ? Vous savez que ces derniers voudront obligatoirement avoir un niveau de service premium et ne supporteront pas de passer après les autres. Au lieu de se battre avec ces clients « particuliers », intégrons leur gestion dans nos systèmes en leur fixant la plus haute priorité possible. Après la difficulté que vous pourrez avoir sera de devoir traiter avec les clients qui se disent VIP, mais qui ne le sont pas. Mais ceci est une autre histoire…