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...

Qui compose le CAB ?

Le CAB, pour rappelle (Change Advisor Board) est le bureau en charge de valider les demandes de change.

Sa composition ne peut pas être figée et dépend nécessairement du contenu et des probables impactes des changes à valider.

Ainsi, autour d'un noyau systématique :

• Change manager pour coordonner, suivre les délibérations et s'assurer que le processus est respecté ;
• Le responsable technique impacté pour étudier quel impact et quel risque sont encourus ;
• Le responsable du Service Desk pour se préparer à recevoir les incidents en cas de dysfonctionnement et organiser les risques de charge
• Le représentant du client (le SLM, par exemple) pour représenter le client et faire valoir son avis

on peut aussi retrouver des invités. En effet, afin que le CAB soit le plus efficace possible, il doit être nécessaire de convier toutes personnes pouvant apporter sa compétence pour que la décision soit prise en connaissance de tous les risques.

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

Existe-t-il un mode opératoire pour concevoir un Catalogue de service ?

Pour ma part, je ne pense pas, cela va dépendre du niveau de maturiré de l'entreprise et des objectifs de la mise en place.

En effet, mettre un catalogue de service peut servir à :
- Améliorer la relation entre l'IT et le métier en mettant plus de transparence
- Mieux connaitre ses processus de travail IT et les responsabilités des différentes équipes
- Préparer un plan de sourcing pour externaliser certains services ou simplement les faire supporter par des compétences externes.

Voici deux méthodes que j'ai déjà testé et qui marche :

Méthode A

1. présenter le projet aux différents manager de l'IT et leur demander les demandes utilisateurs auxquelles ils font face quotidiennement
2. compiler et organiser les résultats

Cette solution est faisable si la structure de l'entreprise est limitée car elle reste assez empirique.

Méthode B

1. Partir sur les OLA, si existant, afin de partir sur la base des services fournis par les différentes équipes.
2. Développer le OLa et son périmètre pour ensuite détailler le service.


Beaucoup plus pratique pour une grande structure car cela peut se faire périmètre par périmètre

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