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"