TAI044 Utiliser un script de questionnement et de résolution de problème

TAI044 Utiliser un script de questionnement et de résolution de problème

TAI044 Utiliser un script de questionnement et de résolution de problème

TABLE DES MATIERES

1 INtroduction 2

2 la problématique de l'utilisateur 3

2.1 Comment réagit-il face à une panne 3

2.1.1 Ceux qui savent quoi faire 3

2.1.2 Ceux qui ne font rien 3

2.1.3 Ceux qui essayent de faire 3

2.2 Comment l'information vous est restituée 3

2.3 Comment faire votre diagnostic 4

3 Les organigrammes de diagnostic 5

3.1 Contexte et principe d’utilisation 5

3.2 Les symboles utilisés 6

3.3 Comment naviguer dans un organigramme 7

3.3.1 Schéma général d'un organigramme 7

3.3.2 Organigramme à plusieurs branches 7

3.3.2.1 Les questions à deux branches 7

3.3.2.2 Les questions à "n" branches 8

3.3.3 Organigramme à plusieurs questions 8

3.3.4 Le découpage des organigrammes 9

3.4 Exemple de procédure 10

1 INtroduction

Le diagnostic et la résolution de problèmes, dans les cellules d'assistance Help Desk, sont des activités radicalement différentes de celles où c'est le technicien qui sur le site réalise un diagnostic et résout un problème.

L'approche d'un problème réseau se basera sur un diagnostic lié aux couches réseau. L'approche du même problème dans un diagnostic à distance devra tenir compte de deux paramètres :

 Nous sommes à distance

 Nous pouvons avoir besoin de l'utilisateur

Le fait d'être à distance, même dans un contexte de prise de contrôle, ne nous permettra pas de tout faire.

L'intervention d'un utilisateur nous obligera à faire beaucoup plus de vérifications et nous contraindra à avoir une approche non plus par couches mais une approche allant du plus simple au plus complexe.

Pour aider le technicien Help Desk dans cette redoutable tâche, il aura à sa disposition des procédures, qu'on peut appeler scripts, de questionnement qui vont lui permettre de ne rien oublier et le l'aider à poser des questions simples aux utilisateurs.

Un script de questionnement est une suite de questions qui s'enchaînent.

2 la problématique de l'utilisateur

2.1 Comment réagit-il face à une panne

Les utilisateurs, face à une panne, peuvent être classés en trois catégories.

 Ceux qui savent quoi faire

 Ceux qui ne font rien

 Ceux qui essayent de faire

2.1.1 Ceux qui savent quoi faire

Cette catégorie ne nous pose pas de problème, elle n'a pas besoin de nous.

2.1.2 Ceux qui ne font rien

Si vous devez choisir de quelle catégorie vous occuper, prenez celle-là. Les utilisateurs de cette catégorie ne prennent aucun risque et ne risquent pas de mettre la pagaille dans leur poste de travail.

Avec eux, il vous faudra poser des questions simples et y aller doucement. C'est une des raisons de l'existence des scripts de questionnement.

2.1.3 Ceux qui essayent de faire

C'est la catégorie la plus redoutable. Ceux-là vont essayer d'intervenir et de réparer. Leur façon de procéder est simple, ils essayent quelque chose, puis autre chose et autre chose encore… en se disant que ça finira bien par marcher.

Leurs investigations peuvent produire trois résultats :

 C'est un miracle et ça marche 

 Ca me marche toujours pas et c'est pire qu'avant

 Le problème est résolu et c'est autre chose qui ne fonctionne plus.

Si l'on exclut le premier résultat, pour les autres il vous faudra repartir de zéro et analyser le problème pas à pas. Encore une fois les scripts de questionnement vont vous aider dans cette tâche.

2.2 Comment l'information vous est restituée 

Dans la restitution que vous fera l'utilisateur d'une panne vous allez retrouver quelques constantes. Il vous dira qu'il n'a rien touché, qu'il ne sait rien passé et que le programme s'est désinstallé tout seul. 

   Un peu de vécu : Une nappe disque dur était branchée à l'envers, on m'a pourtant dit que personne n'y avait touché… si si . 

Une autre constante, c'est que l'utilisateur ne vous décrit pas la panne mais la conséquence de la panne.

Il vous dira "Je n'arrive plus à envoyer d'e-mails". Il ne s'agit pas d'une panne mais bien de la conséquence d'une panne. Nous pourrons même dire que plusieurs pannes peuvent avoir, entres autres, comme conséquence que l'utilisateur ne peut plus envoyer d'e-mails.

De même une panne peut avoir plusieurs conséquences…. Si on ne peut plus envoyer d'e-mails, il est possible que l'on ne puisse plus en recevoir….

Encore une fois pour vous aider à vous y retrouver et à ne rien oublier nous allons  utiliser un script de questionnement qui sera le même pour plusieurs symptômes.

Pour des problèmes liés à des connexions Internet, on utilisera un script qui permettre de vérifier l'ensemble des paramètres de connexion.

2.3 Comment faire votre diagnostic

La démarche de diagnostic à distance est assez simple en réalité, vous allez quelles que soient les déclarations de l'utilisateur, toujours utiliser la même démarche, poser les mêmes questions, c'est le moyen le plus sûr d'aboutir au bon diagnostic et donc de pouvoir réparer soit à distance soit en déclenchant une intervention.

3 Les organigrammes de diagnostic

3.1 Contexte et principe d’utilisation

Pour faciliter la démarche de diagnostic, il existe des organigrammes qui guident le technicien dans son investigation.

Ce type d’organigramme est souvent utilisé dans les structures Help Desk, pour optimiser et uniformiser le diagnostic des techniciens.

Pour utiliser ce type d’organigramme, il suffit de poser la première question, puis de la réponse, on se dirige vers une autre question ou une action et ainsi de suite.

Ce type d’organigramme va permettre, même à un débutant, de faire des diagnostics rapides et efficaces. Si un technicien ne parvient pas à résoudre le problème avec ce type d’algorithme, il va passer la main à un expert et ce dernier aura la certitude que les tests élémentaires ont été faits.

3.2 Les symboles utilisés

Les symboles les plus couramment utilisés sont ceux-ci :

3.3 Comment naviguer dans un organigramme

3.3.1 Schéma général d'un organigramme

Un organigramme de questionnement possède toujours un et un seul point d'entrée.

Derrière ce point d'entrée on va trouver le questionnement.

Pour terminer, il y aura au moins une fin.

3.3.2 Organigramme à plusieurs branches

3.3.2.1 Les questions à deux branches

3.3.2.2 Les questions à "n" branches

Vous remarquerez que dans l'exemple ci-dessus, nous avons trois symboles qui indiquent la fin de l'organigramme.

3.3.3 Organigramme à plusieurs questions

Il est très rare qu'un organigramme ne soit composé que d'une seule question. Dans la quasi-totalité des cas, de nombreuses questions seront incluses dans l'organigramme.

Vous allez naviguer dans cet organigramme de la façon suivante

 Vous entrez par "Début"

 Vous posez la question "Q1"

 Si la réponse est "Oui", vous faites le traitement "T1" et vous posez la question "Q2"

 Si la réponse est "Non", vous faites le traitement "T6" et vous posez la question "Q4".

 Si vous avez posé la question "Q2" et que la réponse est "Oui", vous faites le traitement "T2" et vous posez la question "Q3"

 Et ainsi de suite…….

3.3.4 Le découpage des organigrammes

Vous vous êtes sans doute aperçu qu'un organigramme prend beaucoup de place et que cela devient vite difficile à exploiter.

Pour faciliter l'exploitation d'un organigramme, on va le découper en plusieurs organigrammes plus petits.

Dans l'exemple ci-dessous, les questions et traitements qui suivaient le traitement "T1" on été intégrés dans une deuxième procédure "Procédure 2

3.4 Exemple de procédure

Le technicien Help Desk doit suivre à la lettre ce type de procédure. A titre d’exemple, vous trouverez ci-après une procédure qui pourrait être utilisée par la hot line d’un fournisseur d’accès Internet pour dépanner un particulier qui ne parvient pas à se connecter.