A quoi correspond une demande d'information ?

J'entends par demande d'information des questions tel que "Comment imprimer dans cette application ?" ou "Qui dois-je contacter pour obtenir les informations suivantes ?"... Il ne s'agit pas d'incident car il n'y a pas de perte d'information.

Pour ma part, je recommande de pouvoir les traiter au niveau du Service Desk. En effet, en plus de pouvoir catégoriser les contacts entrants comme incident, demande, erreur... il doit exister une type information. Et la base de connaissance doit être suffisamment complète pour que l'opérateur puisse répondre directement.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Comment justifier le processus de problème ?

On vient de voir à quoi peut servir ce processus.

Pour justifier son implémentation, il est possible de commencer par regarder les incidents dont la date d'échéance est passée depuis plusieurs jours, voir souvent plusieurs semaines. Lorsqu'on creuse ces cas, on se rend compte qu'ils sont restés ouvert car on attend une migration, on n'est pas sûr de la résolution apportée... Il s'agit de toute évidence de problème géré dans le processus d'incident. Démarrer par ses cas le processus de problème permet de présenter l'avantage de ce processus : supprimer ces incidents dont l'impact sur les niveaux sont effroyables.

Par cette démarche, les opérateurs vont alors commencer à comprendre l'utilité du processus de problème pour sa part réactive.

Traiter les problèmes pro-actifs devra se faire dans une seconde étape. La maturité du processus aide alors et la mise en place est naturelle.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

A quoi sert le processus de problème ?

Si les processus d'incident  et de change sont devenus naturels dans les entreprises, le lien entre les deux est souvent flou. En effet, le processus de problème est souvent difficile dans son appréhension. Et pourtant lorsqu'on creuse le sujet, il apparait qu'entre un incident déclaré par un utilisateur dont l'origine est inconnue et la mise en place du changement pour corriger, une étape est évidente : la recherche de l'origine et la définition des modifications nécessaires à apporter.

Et bien le processus de problème permet justement de traiter cette phase.

Le processus d'incident a des exigences fortes en terme de délai de traitement pour remettre à niveau le service, le temps imparti ne permet donc pas de prendre le temps pour rechercher la cause.
Le processus de changement se concentre sur l'opportunité ou non de réaliser cette modification. Le détail du changement est donc déjà connu.

Le processus de problème a donc un objectif de mettre en place une Task Force qui va rechercher les origines techniques (ou fonctionnelles suivant le cas) pour présenter les bons changements à mettre en place.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Que valide-t-on dans le CAB ?

Pour rappel, le CAB est le Comité de Consultation des Changes. Un client m'a présenté un double processus de change afin de valider dans un premier l'acceptation ou non du point de vue fonctionnel ; ensuite pour valider la planification.


Cela génère un double change et donc une surcharge du processus. Dans le processus de change, on valide le change durant le CAB. Celui-ci est d'ailleurs constitué d'un représentant du Business et de technicien afin de pouvoir juger l'importance fonctionnelle des risques à prendre. La planification est simplement en avant de la réalisation et permet de traiter la file d'attente et de trouver un créneau sur les plages de maintenance pour positionner le change. En aucun cas, la planification n'a la possibilité de refuser un change, elle va au pire le planification pour une date très lointaine.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Quel indicateur pour la CMDB ?

Cette question a été posé dans un environnement particulier car un processus d'incident relativement bien maîtrisé fonctionnait tandis que nous mettions la gestion de la configuration. Il fallait prouver que la CMDB pouvait participer au traitement des incidents.
Pour cela, j'ai proposé trois niveaux d'indicateurs :
Déploiement de la CMDB : s'assurer que le périmètre prévue des CIs s'intègre convenablement dans la base.
Utilisation de la CMDB : s'assurer qu'elle est mise à jour régulièrement et que ses informations sont utilisées dans le traitement des incidents
Avantages de la CMDB : regarder quelles sont les gains sur le traitement des incidents de la mise en place de la CMDB.
Dans ce dernier cas, il sera très difficile d'isoler l'origine des améliorations constatées si d'autres actions sont en cours. Il faudra alors regarder par comparaison : sur un même type d'incident. Est ce que les incidents dont les CIs sont renseignés ont été traités plus rapidement ?

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Quelle logique pour sa base de connaissance ?

Démarrer sa base de connaissance n'est pas chose aisée. En effet, il est rare qu'une entreprise ait déjà ce processus en place. Et les opérateurs ont plutôt tendance à penser que transmettre leur connaissance déstabiliserait leur position dans l'entreprise. Il arrive aussi que la réaction soit de rappeler que les éléments de l'infrastructure sont déjà présenté dans X documents écrits durant le projet.


Mais la question qu'il faut se poser réellement est :  est ce que cette information est disponible rapidement pour le Service desk ?

Une méthode de mise en place de la base de connaissance est de créer, une fois plus, un cercle vertueux dont les protagonistes seraient gagnants et l'entreprise pourraient agréger ses connaissances.

En effet, il est alors présenté au Service Desk que si l'information se trouve dans la base de connaissance, ils ont alors la responsabilité de la rechercher puis de résoudre eux-même l'incident. Et aux équipes des niveaux suivants, il est rappelé que si l'information est facilement disponible dans la base de connaissance, les incidents ne leur seraient plus transmis.
Avantages :

• Création d'une responsabilité partagé entre le Service Desk et les équipes suivantes
• Création d'un référentiel commun de partage d'information entre les différentes équipes
• Réduction du nombre d'incident transféré aux équipes de niveaux 2 et 3
• Réduction des coûts car les incidents sont traités plus rapidement et par moins d'opérateurs.
  Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Qui saisit dans la KB ?

J'ai dit précédemment que la KB devait être remplie par les 2eme et les 3emes niveaux. Mais il est vrai que cette étape est difficile à faire accepter par ces opérateurs. En effet, ils considèrent souvent que la KB ne sert qu'au Service Desk donc ce n'est qu'a eux de la remplir.


Proposition faite pour mettre en place la KB sans que cette question soit un frein. Il a été posé sur la fiche de l'incident un flag permettant de notifier que la solution apportée pourrait être intégrable dans la KB. Ainsi le KB Manager pourra reprendre les informations et la charge demandée aux opérateurs est minime car il s'agit de remplir un champ type liste déroulante ou case à cocher.

Plus tard, lorsque la KB aura fait la preuve de son fonctionnement, si on souhaite réduire la charge du KB manager, présenté cette responsabilité aux niveau 2 et 3.