Qui doit créer un problème ?

A cette question, il n'existe pas de réponse unique. Cela va dépendre de plusieurs critères :

     • Maturité du processus dans l'entreprise. Si le processus n'a jamais été défini, il sera préférable de le faire accepter par les équipes de niveau 3 des incidents avant de leur présenter l'utilisation de l'outil de support. Sinon, ils risqueraient de faire un rejet du processus simplement parce qu'il aura été identifié à la probable complexité de l'écran à renseigner.

    • Outil utilisé. Si un outil pour supporter ce processus, si l'outil est trop proche ergonomiquement du processus des incidents, il risque d'avoir une confusion et un amalgame de ces deux processus.

    •  Implication du problem manager. Si ce dernier est impliqué et le souhaite, il peut être possible de lui déléguer cette tâche, au moins dans le démarrage du processus. Il pourra ainsi aider les opérateurs à spécifier les cas dans lequel il s'agit bien d'un problème.

Ainsi, il peut facilement être défini plusieurs étapes en fonction de la maturité du processus et cette responsabilité peut, par exemple démarrer au problem manager afin de soutenir les opérateurs. Et lorsque le processus est accepté et intégré, la création du problème peut s'ouvrir à toutes personnes.

Concernant les utilisateurs, ils doivent évidemment passer par le Service Desk et ne devraient pas demander la création d'un problème directement. En effet, un problème est directement un dysfonctionnement de l'infrastructure dont on veut chercher la cause. Or les utilisateurs ne devraient déclarer que des dysfonctionnements dont ils perçoivent la conséquence.