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