Qui valide la publication d'un article de connaissance ?

Dans la théorie, il devrait avoir deux intervenants :

un intervenant technique qui va valider si la solution est techniquement juste. Est-ce qu'elle est claire ? Est-ce qu'elle est exploitable (au sens littéraire : est ce qu'elle peut être utilisé pour l'exploitation ?). Lorsque le contenu technique est validé, une deuxième validation est nécessaire.
un intervenant fonctionnel va valider la forme et la présentation de l'article de connaissance. Il va s'assurer que la mise en place a été respectée : Présentation des symptômes, présentation du workaround, présentation de la solution définitive... Cette validation doit également permettre de s'assurer que cet article n'est pas un doublon d'un autre.

Dans la pratique, cela dépend beaucoup de l'organisation et de la volonté d'implémenter une base de connaissance. Comme très souvent, il est nécessaire de convaincre les équipes lors du démarrage de ce processus, il est difficile de mettre en place une organisation qui répond parfaitement à la théorie. C'est pourquoi il est possible de travailler en plusieurs temps.

Dans un premier temps, la validation technique peut se faire par l'opérateur qui a écrit l'article. Certes il va s'auto-valider mais par la suite, il sera possible de déléguer cette validation technique. Pour la validation fonctionnelle, elle peut être faite centralement : par un knowledge manager, décentralisé : par chaque service owner.

Comment expliquer la différence entre un request et un incident à un utilisateur ?

Avant de répondre à cette question, il faudrait déjà se poser la question pourquoi expliquer la différence. En effet, il apparait qu'il n'est pas nécessaire de prendre ce temps pour expliquer cela à l'utilisateur. Si vous présentez sur votre catalogue de service des formulaires d'incidents et des formulaires de requests, il ne semble pas nécessaire d'expliquer que l'objet et le processus sera différent. Le titre du formulaire doit permettre de guider le demandeur afin que celui-ci se pose la question non pas : Est ce que je dois faire une demande ou un incident ? mais plutôt : ou est le formulaire car quelque chose ne fonctionne pas ? je souhaite une nouvelle application ou est le formulaire ?...

Ainsi, le travail de communication ne doit pas se focaliser sur l'explication des types de processus mais simplement sur l'utilisation du portail self-service. Si vous souhaitez faire ça, cliquer sur le formulaire qui s'appelle demande de "faire cela"

Pourquoi différencier les request des incidents

De nombreuses entreprises traitent le processus de request avec les mêmes outils que le processus d'incident. C'est bien de traiter des requests mais c'est dommage de ne pas optimiser les request.

En effet, les incidents concernent un perte de service, sa restauration est donc difficilement prévisible, tandis que les request concernent le traitement de de besoin récurrent. On sait (ou devrait savoir) qui doit les valider, qui doit les traiter. On sait également quelles sont les informations dont on a besoin de la part du demandeur.

Traiter ces request dans un workflow, avec un formulaire spécifique permet donc d'industrialiser leur traitement. Cela veut dire moins de temps perdu, moins de répétition et plus d'efficience, aussi bien pour les utilisateurs que l'informatique.

Faut il une cmdb pour un processus de change ?

Et bien aussi surprenant que cela puisse paraitre, j'ai decouvert chez un client un processus de change très mature qui tourne régulirement sur des CI générique. En effet, ce processus a un fort pouvoir de standardisation dans la planification et la réalisation de l'infrastructure.
Mais j'ai fait remarqué qu'une part importante de la plus value de ce processus était perdue : l'historique. En effet, faire un changement sur un serveur ou une application permet de garder un historique des modifications. Ne pas lier le change sur un CI précis ne permet donc d'avoir ce suivi dans le temp.

Un incident lié à un problème doit-il être résolu ?

Détaillons tous les cas de figure :

• Le service es restauré et la root cause est trouvé. Cas idéal, on peut donc résoudre le problème et les incidents liés
• Le service est restauré mais la root cause n'a pas été trouvé. Dans ce cas, nous aurons donc des incidents résolus mais le problème lié reste ouvert.
• Le service est n'est pas restauré mais la root cause est trouvé. Posé comme cela, il apparait concrètement surprenant qu'on puisse se retrouver dans ce cas. En effet, la connaissance de la root cause doit au moins permettre d'avoir un workaround.

C'est pourquoi, il peut arrivé d'avoir des incidents résolus liés à un problème en cours mais il n'y a pas d'obligation. Cela dépend de la situation dans lequel on se trouve.

Combien d'étape dans un request ?

On retrouve généralement trois étapes dans une request :

Etape de validation : on va transmettre la request aux différents personnes dont leur décision doit permettre la réalisation de la demande. En principe, on a la dans un flux séquentiel.
Etape de traitement : c'est ici que ce situe la connaissance du processus. En effet, cette partie de flux correspond à l'organisation de l'informatique. Bien des cas, la définition de ce workflow permet de rationaliser considérablement le fonctionnement car l'entreprise prend souvent conscience du nombre incroyable d'exception à traiter et décide de standardiser.
Etape de clôture : une confirmation de l'utilisateur explicite ou implicite (on laisse un délai de garantie de quelques jours avant clôture définitive) est nécessaire afin de rester à l'écoute de l'utilisateur.

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

Comment gère-t-on les externes dans le processus incident ?

Il est possible de retrouver deux types d'externes :

End user externe : il s'agit de personne étrangère à l'entreprise mais qui utilise son système d'information. Il doit donc pouvoir déclarer des incidents. C'est pourquoi la liste des utilisateurs contenus dans la CMDB ne doit pas s'arrêter à la liste des salariés mais bien à la liste des utilisateurs du système d'information.

Intervenant externe : il s'agit de fournisseur du service informatique. Si l'outil de Service Management le permet, il est bien de les intégrer au même niveau que tout équipe d'intervention interne. Sinon, l'incident doit être sous la responsabilité d'une équipe interne qui a la responsabilité de ce fournisseur.

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

Combien de niveau d'intervention pour traiter un incident ?

En règle générale, on a trois niveaux :

1. Service Desk dont l'objectif est de qualifier l'appel. C'est à dire de définir quelle est sa priorité, le service impacté... Il doit aussi trouver des solutions pour restorer le service, même de façon très provisoire. C'est la que la base de connaissance prend tout son sens
2. niveau intervention dont l'objectif reste assez généraliste mais peut se déplacer sur site si nécessaite
3. niveau expert dont l'objectif est de restaurer le service quoi qu'il en soit. Si un transfert de compétence est bien réalisé de ce dernier niveau sur les précédents, le nombre d'incidents traité à ce niveau doit être très faible.

Il arrive de trouver plus de niveau suivant la complexité de l'organisation.

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

Existe-t-il différents types de services dans un catalogue de service ?

Pour ma part, je préfère catégoriser les services en deux domaines bien distincts :

• Business Services
• Technical services

Leurs structures et leurs attributs sont les mêmes. Seul change les consommateurs des services. Pour le premier, on aura des clients Business et pour les seconds, on aura uniquement des clients techniques (du service informatique).

Différentes remarques :

1. Les collaborateurs du service informatique peuvent consommer des services des deux types, suivant si les raisons proviennent du fait de leur travail spécifique dans l'IT ou du fait d'être collaborateur. Par exemple, un responsable Citrix sera client Business pour User Environment et technical service pour Hosting Server.
2. Les Business Services auront des SLAs associés entre les clients et l'IT tandis qu'on parlera de OLA pour les technical services puisqu'il régit la relation entre deux services IT.

Voici un schéma représentant la différence entre les deux et leur connexion.

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

Est ce que "Messagerie" est un service distinct du service "Environnement client" ?

Pour cette question, pas de réponse franche. En effet, cela va dépendre de l'approche choisie de l'entreprise. Pour ma part, je serai plutôt rétissant de le proposer dans un Business service indépendant.

J'aurai tendance à l'intégrer comme un service technique qui supporte le Business Service "Environnement client". En effet, la messagerie est une clé de voute de l'infrastructure. Mais cel n'est pas une application métier en temps que tel sinon une application bureautique.

Voici les raisons qui justifie ce choix :

1. L'ensemble des utilisateurs de l'IT ont un accès à la messagerie (il est rare de fournir un acces au système d'information sans fournir une adresse e-mail)
2. Ce service doit être géré au même titre que l'image fournie sur le poste (contenant le système d'exploitation), ou le réseau, également indispensable pour l'utilisateur.
   Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Est-ce que les Business Services sont dans la CMDB ?

Les Business sont dans deux référentiels :

• Le catalogue de service : en effet, ils peuvent être commandé par un ou plusieurs utilisateurs. Ce sont donc intégralement des éléments du catalogue
• La CMDB : comme tout élément décrivant l'infrastructure informatique, on doit les retrouver dans la base des configurations afin de pouvoir leur rattacher les utilisateurs qui les consomment, les éléments logiciels et matériels sur lequel repose le service.
  Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Est-ce qu'un Workaround génère toujours une erreur connue ?

Dernièrement, la question s'est posée lors de la configuration du processus de problème. En effet, il était nécessaire de savoir si le renseignement d'un workaround (solution de contournement) devait obligatoirement définir le problème comme une Known error (erreur connue).

En fait, tout réside dans l'adverbe. En effet, dans de très nombreux cas, un workaround sera trouvé lorsque l'origine du problème aura été défini et donc l'un devient la conséquence de l'autre. Mais cela n'est pas obligatoire.

Dans de nombreux cas, un workaround sera trouvé sans qu'on puisse déterminer l'origine. En voici quelques exemples :

• ordinateur plante régulièrement, je reboot. On n'a bien un workaround mais on ne sais pas pour autant la raison du plantage.
• un batch plante une fois sur 10. Relancer le batch si tous les tests ne sont pas valides. Même chose, on a bien un workaround mais on ne sait toujours pas pourquoi il lui arrive de planter.
   

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

Comment mettre en place le PIR du processus de change ?

Pour rappel, le PIR correspond au Post Implementation Revivew. A chaque début de CAB, il doit être pris 10 minutes afin d'étudier les changes réalisés 3 ou 4 semaines plutôt. Il suffit alors de répondre à quelques questions dessus tel que :

• Réalisé dans les délais annoncés ?
• Utilisateurs impactés ?
• Incident généré depuis le change ?
• Dysfonctionnement résolu ?
• Autres remarques ?

Des statistiques issues de ces résultats servent alors au pilotage de ce processus et de s'assurer qu'il répond au besoin premier : permettre de modifier l'infrastructure en maîtrisant les impacts aussi bien techniques que des utilisateurs.

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

Pourquoi plusieurs processus suivant le type de changement ?

Dans la mise en place du processus de changement, il arrive qu'on ne mette en place qu'un processus de changement quelque soit son type. Pour rappel, un changement peut être majeur, significatif, normal ou urgent.
Dans de nombreux cas, le change urgent reste relativement indépendant des autres car il est souvent traité hors outil, pour son caractère urgent,

Pour les autres types, il est conseillé de mettre en place des processus différents, notamment pour la validation du CAB (change Advisory Board). En effet, mettre en place un processus qui répond au processus majeur sera lourd et cher pour les changes normaux. De l'autre, un procesuss simple risque de décider des changes significatifs sans avoir pris en considération tous les paramètres.

C'est pourquoi, un unique processus peut faciliter la mise en place de ce processus, mais il est nécessaire rapidement de déployer tous les cas adaptés à chaque type.

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

A quoi sert le PIR du processus de change ?

Pour rappel, le PIR correspond au Post Implementation Review. Il s'agit après chaque change de faire un bilan. Cela doit se faire , que le change est réussi ou non.

En effet, si le change a bien fonctionné, il est nécessaire de savoir si le dysfonctionnement a bien été résolu. Un change qui se passe bien ne corrige malheureusement pas toujours un dysfonctionnement ! Simplement parce qu'un change qui se passe bien correspond au fait que l'infrastructure fonctionne toujours après mais peut-être que cela n'a servit à rien.

Si le change s'est mal passé, il est plus courant de mettre en place ce bilan. Il s'agit de comprendre l'origine des difficultés rencontrés. Il ne s'agit pas évidemment de trouver le coupable mais de trouver ou le processus a failli : CMDB pas à jour (et donc impact sur l'infrastructure non prévu), représentant du CAB absent (revoir la sélection des opérateurs du CAB).

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

Comment optimiser les resets de mot de passe sans donner tous les droits au Service Desk ?

De nombreux incidents concernent des Reset de mot de passe ou des demandes de droits. Ces incidents et request doivent être traités par le Service Desk. Cela permet d'être réactif vis-à-vis des utilisateurs et la procédure répétitive ne nécessite pas de grandes connaissances pour répondre au besoin. Et pourtant, il arrive souvent que cela soit traité, pour un certain nombre d'application au moins, par un opérateur de niveau 3. Cela est souvent dû à l'application elle-même car la gestion des droits se fait dans les fonctions d'administrations et donner cet accès aux opérateurs du Service Desk ne correspond au critère de sécurité.

Pour répondre à cette difficultés, deux solutions peuvent être envisagées :

1. Mettre en place une gestion centralisé des accès : une application dans lequel un opérateur du Service desk va chercher un utilisateur et voir la liste des applications et lier l'un à l'autre. Dans un environnement Single Sign On (login/mot de passe unifié), c'est la meilleur solution mais cela nécessite un travail technique important.
2. Mettre en place une équipe de gestion des droits. Tous les besoins d'accès et de reset sont transférés dans une même équipe. Cette dernière va pouvoir se connecter dans les applications et faire les manipulations nécessaires. Cette équipe peut alors être constitués de spécialistes applicatifs tournants.

Dans tous les cas, il est nécessaire que ces cas n'arrive pas au niveau 3 car le coût de traitement peut être important et le temps de traitement long pour l'utilisateur.

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

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