Un Service Desk est-il toujours au niveau 1 ?

Couramment, une correspondance se fait entre niveau 1 de support => Service Desk. Cela est juste mais l'inverse ne l'est pas toujours. En effet, dans des organisations importantes, il est difficile pour un opérateur de connaître toute la structure de support informatique. C'est pourquoi, il est tout à fait possible pour un ensemble de groupe de niveau 3 de mettre en place un service desk. Ainsi, lorsqu'un incident vient du niveau 2 et doit être escaladé sur un niveau supérieur, il passera par ce Service desk de niveau 3. Ce dernier pourra alors soit le traiter, soit le dispatcher sur le bon groupe.

Mettre en place cette logique apporte de nombreux avantages dans les grandes organisations :

1. Réduction du taux d'erreur de dispatch sur des groupes de niveaux 3
2. Traitement de cas de niveau 3 de manière transverses. En effet, ce service desk va pouvoir également traiter des cas tel que affecter des droits, faire des tests afin de s'assurer que cela concerne bien le domaine correspond...

Nous avons bien dans ce cas la un Service Desk car il a les mêmes fonctionnalités mais son périmètre technique est limité et il n'est pas accessible par les utilisateurs Business.

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

Quelle différence entre une KB et une gestion documentaire ?

Dans les entreprises, les deux concepts sont souvent mélangés. Sous couvert d'écrire de la documentation dans le cadre d'un projet, les développeurs considèrent que le travail de transfert de compétence est fait.

Pensez vous qu'un opérateur du Service Desk a le temps de fouiller la documentation à la recherche d'une information pour traiter un incident ?

Les deux concepts sont nécessaires mais sont complémentaires, pas superposables.

La base documentaire va être gérée dans une GED avec les fonctions de suivi, de versionning. Son objectif est de garder une trace des décisions et des développements réalisés dans le cadre d'un projet. Elle est donc alimenté par des développeurs (souvent le troisième niveau de support) pour des développeurs
La base de connaissance va comporter les solutions des erreurs connues. Son objectif est de faciliter le traitement d'incident et de réduire leur temps de traitement. Elle est alimentée par des développeurs pour permettre au Service Desk d'être autonome dans le traitement des incidents et ainsi éviter leur escalade vers des niveaux supérieurs.

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

Comment faire vivre la base de connaissance ?

La mise en place de la base de connaissance nécessite d'étudier le processus d'intégration de données. Mais cela ne suffit pas. En effet, les changements de technologies, le traitement de nouveau incident oblige de faire vivre la base de connaissance.
Cela veut dire que les informations contenues dans cette base doivent être actualisée.
Par exemple, si un opérateur cherche une solution sur une problématique liée à Windows et qu'il trouve un article présentant des copies d'écran plus à jour, la solution décrites dans une version plus utilisée, pensez vous qu'il reviendra dans la base de connaissance ?

C'est pourquoi, la mise en place d'une procédure d'actualisation doit se faire. C'est à dire que chaque information doit avoir une date de fin de validité comprise entre 1 et 2 ans. A cette date, il faut forcer la relecture par un expert du domaine qui va pouvoir redonner une date de validité.

Garantir une information fiable et plus important que de garantir une grande quantité d'information. Ce processus doit donc s'initier dès le départ pour garantir son bon fonctionnement lorsque les premières mises à jour devront se faire.

Quelle structure de la base de connaissance ?

Deux approches existent dans la mise en place d'une base de connaissance :

• Approche structurée : les contributeurs et les lecteurs sont clairement définis
• Approche Wiki : tous les lecteurs sont contributeurs.

Dans le cadre d'une base de connaissance, je préconise d'utiliser la première approche.

Comme dans le démarrage de cette base, il est nécessaire de convaincre les opérateurs de la plus-value, il est préférable de s'assurer que les informations contenues sont justes et utilisables. Il est donc préférable de vérifier l'utilité et la structure des informations.

Les lecteurs seront principalement des opérateurs du Service Desk. Il parait peu probable que si une erreur est rencontrée dans une information, ils prennent le temps de la corriger. L'information restera alors fausse et la confiance dans cette base baissera d'autant plus vite qu'il y aura d'information fausse.

La recherche doit garantir de trouver la bonne solution. C'est pourquoi les outils de recherches minimum doivent permettre le full-text, les mots clés, la classification des CIs, la classification des incidents. Garantir ces informations correctes (parfois simplement en corrigeant les fautes d'orthographes) garantie une réelle utilisation des informations.

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

Comment démarrer sa base de connaissance ?

Si l'entreprise n'a aucune base de connaissance, il est nécessaire de démarrer petit à petit. Il serait illusoire de penser démarrer sa base de connaissance déjà remplie.

Pour cela, je propose d'ajouter sur l'écran des incidents un champ de type case à cocher et un champ commentaire spécifique.
Le champ commentaire permet à l'opérateur de renseigner la solution technique mise en place et la case à cocher permet d'informer que le KB manager que cette solution devrait être reprise dans la base de connaissance.

Si les opérateurs jouent le jeu et le KB manager arrive à traiter le flux entrant, la base de connaissance va grossir et contenir toutes les informations nécessaires.

Avantages :

• Pas de remise en cause des processus existants
• Facilité pour les opérateurs de proposer des solutions
• Informations décrivant une solution à un incident et non la description d'une infrastructure, comme beaucoup de documents de projets
  Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Un problème est-il simplement un regroupement d'incident ?

Evidemment non. Il ne faut pas confondre le master incident et le problème. En effet, si cette notion de master incident n'existe pas dans les livres ITIL, elle est important dans un objectif de simplicité de traitement dans l'outil de Service Management.

Un master incident est donc défini comme un regroupement d'incident en cours et dont l'objectif est de simplifier la saisie des informations. Les données mises à jour sur ce master incident sont répercutées sur l'ensemble des incidents liés.

Un problème possède lui aussi un ensemble d'incidents lié, en cours ou non. Mais, et c'est la que réside la plus grande différence : le travail sur le problème n'impacte en aucun cas le délai de résolution des incidents. Son objectif est bien de traiter la cause technique.

Même dans un souci de simplification dans l'outil de Service Management, la notion de problème ne doit pas être galvaudée au risque de perdre le bénéfice rendu par ce processus.

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

Comment valide le CAB ?

Le nombre d'intervenant au CAB ne doit pas être limité pour des raisons d'organisation. En effet, il est important que tous les collaborateurs qui peuvent être impactés par le change puissent participer au CAB.

Mais pour cela, il ne faut pas imaginer le CAB uniquement sous forme de réunion répétitive dans lequel les intervenants vont patienter que le sujet qui les intéresse soit abordé. cela couterait bien trop cher.

C'est pourquoi, il est conseillé d'organiser le moyen de valider par le CAB en fonction du niveau de chaque changement.

En effet, pour rappel, il existe au moins trois types de changement et pour chacun d'eux, je propose une validation différente :

Change mineur : le change manager a procuration pour valider, il informe simplement les membres du CAB de la décision et leur permet la possibilité de réagir dans un certain délai. Dans le cas d'une objection, le CAB peut être requalifié pour alors changer de type.

Change significatif : une validation type Doodle peut être organisé. Pour cela, les participants recoive un mail avec un lien URL permettant d'accéder à une page. Celle-ci doit contenir au moins :

• Le nom du valideur
• Le rôle tenu par le valideur
• L'avis position ou négatif
• L'explication de son avis
• Une vue des autres avis du membre du CAB

Si une discution s'engage entre deux participants, il est, là aussi, toujours possible de requalifier le change

Change majeur : une réunion doit alors s'effectuer pour que chaque avis puisse s'exprimer et se confronter.

Dans cette approche, seul les changements majeurs nécessitent une réunion. Cela fluidifie grandement le processus et réduit d'autant l'effet d’entonnoir que la validation CAB génère souvent.

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