Organigramme du processus d'assistance informatique (incidents et demandes)
Organigramme des processus du service d'assistance informatique : une file d'attente pour les incidents et les demandes de service, avec triage, priorité, résolution de première ligne, escalade de niveau 2, exécution et clôture.
Qu'est-ce que le processus organigramme du processus d'assistance informatique (incidents et demandes) ?
Un processus de service d'assistance informatique est la façon dont un centre de services gère sa journée : une porte d'entrée pour chaque contact utilisateur, quel que soit le canal par lequel il arrive, et un itinéraire convenu depuis ce contact jusqu'à un ticket fermé. Ce qui la distingue d’une procédure à objectif unique, c’est qu’elle réalise deux types de travaux en même temps. Certains tickets sont des incidents où quelque chose qui devrait fonctionner ne fonctionne pas. D'autres sont des demandes de service, où rien n'est cassé et où l'utilisateur souhaite qu'un travail standard et convenu à l'avance soit effectué, comme une licence, un nouvel ordinateur portable ou un logiciel. Les deux ont besoin d'horloges différentes et souvent d'approbateurs différents, de sorte que le processus les divise tôt plutôt que de laisser une file d'attente traiter tout comme une panne.
Cette page couvre le flux opérationnel quotidien du bureau, et non les éléments internes d'une seule succursale. Si vous avez besoin d'une déclaration d'incident majeur, d'un gestionnaire d'incident nommé, d'appels de pont et d'une escalade de violation de SLA, ce détail appartient au processus de gestion des incidents. La compromission suspectée suit plutôt le processus de réponse aux incidents de sécurité. Un correctif qui nécessite la modification d'un service en direct passe à la gestion des modifications, et une demande d'accès au système suit le processus de demande d'accès avec sa propre chaîne d'approbation et une recertification périodique. Le travail sur les causes profondes abandonne entièrement ce processus : la branche des problèmes récurrents génère ici un enregistrement de problème plutôt que de maintenir le ticket de l'utilisateur ouvert pendant qu'un ingénieur enquête.
Le graphique cartographie cinq voies, à savoir l'utilisateur, le centre de services, le support de niveau 2, les actifs et les achats et la gestion des problèmes, à travers cinq phases, du contact à la clôture. Il attire deux éléments que les bureaux ne documentent généralement pas : la vérification de la base de connaissances qui décide si la première ligne applique un correctif documenté ou un diagnostic à partir de zéro, et la direction des achats qui décide si un article demandé est sorti du stock ou commandé. Il se termine également là où la plupart des procédures écrites s'arrêtent, avec l'utilisateur confirmant le correctif et une branche rouverte lorsqu'il dit qu'elle est toujours cassée.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq couloirs avec un propriétaire nommé pour chaque étape, à savoir l'utilisateur, le centre de services, le support de niveau 2, les actifs et les achats et la gestion des problèmes, organisés en cinq phases : contact, journalisation et tri, première ligne, escalade et exécution, et résolution et clôture.
- Prise en charge multicanal, où « L'utilisateur contacte le service d'assistance » renvoie « Recevoir un contact sur n'importe quel canal », de sorte que le téléphone, l'e-mail, le portail libre-service, le chat et la visite sans rendez-vous atterrissent tous dans la même file d'attente avant que quoi que ce soit ne soit enregistré.
- Le message « Incident ou demande de service ? fork immédiatement après « Enregistrer et catégoriser le ticket », envoyant les incidents à « Définir la priorité en fonction de l'impact et de l'urgence » et les demandes vers une branche d'exécution distincte.
- Une tentative de première ligne construite autour de « Correctif connu dans la base de connaissances ? », où oui applique le correctif documenté et non va à « Tentative de correctif de première ligne », les deux se rencontrant à « Résolu en première ligne ? avec une branche d'escalade vers « Enquêter et résoudre au niveau 2 ».
- La branche demande de service : « Le supérieur hiérarchique approuve la demande ? avec une branche refusée se terminant par « Demande refusée et fermée », puis « Article en stock ? acheminer une commande via « Soumettre un bon de commande » avant « Satisfaire la demande et mettre à jour l'enregistrement des actifs ».
- Clôture dans la dernière colonne : « Enregistrer la résolution et avertir l'utilisateur », un « L'utilisateur confirme qu'elle est corrigée ? décision avec une réouverture de branche retour à la première ligne, et "**Problème récurrent** ou connu ?" soulevant un enregistrement de problème avant « Ticket fermé ».
Quand utiliser ce modèle
- Documenter le fonctionnement réel de votre centre de services, afin qu'un nouvel agent puisse voir où va un ticket et à qui appartient chaque étape sans demander l'avis d'un collègue.
- Séparer les incidents des demandes de service lorsque les deux se trouvent actuellement dans une file d'attente indifférenciée et que tout finit par être traité comme urgent.
- Configuration d'un centre de services ou d'un outil ITSM, où les catégories, la matrice de priorités, la règle d'approbation et la mise à jour des actifs dans le graphique correspondent aux champs que vous devez de toute façon configurer.
- Déterminer où s'arrête la première ligne et où commence le niveau 2, ce qui dans la plupart des équipes est une coutume et une pratique plutôt qu'une règle écrite.
- Informer un bureau externalisé ou nouvellement embauché des transferts, des confirmations et de la tenue des dossiers que vous attendez d'eux.
Comment cela fonctionne
Renommez les voies selon vos vrais rôles
Remplacez les utilisateurs, le centre de services, le support de niveau 2, les actifs et les achats et la gestion des problèmes par les équipes dont vous disposez. Les petites organisations fusionnent souvent les actifs et les achats dans le centre de services, et la gestion des problèmes peut être confiée à une personne désignée plutôt qu'à une équipe. Gardez une voie par décideur plutôt que par individu, afin que le tableau survive à quelqu'un qui change d'emploi.
Notez le test d'incident par rapport à la demande de service
Le message « Incident ou demande de service ? fork ne fonctionne que si les agents peuvent l'appliquer en quelques secondes. Écrivez le test à côté de la décision : est-ce que quelque chose qui devrait fonctionner est cassé, ou l'utilisateur demande-t-il un travail standard et convenu à l'avance ? Faites la liste de vos véritables cas limites, comme un ordinateur portable lent par rapport à une demande pour un nouveau, et indiquez dans quelle direction chacun va.
Publiez votre matrice de priorités
Joignez vos définitions d'impact et d'urgence à « Définir la priorité à partir de l'impact et de l'urgence », en indiquant ce que signifie chaque niveau de priorité en termes d'utilisateurs concernés et de conséquences commerciales. Publier la grille là où les utilisateurs peuvent la lire est ce qui transforme la priorité en quelque chose de dérivé plutôt que de débat par ticket.
Définir la limite de première ligne et ce qu'implique une escalade
Définissez quelle première ligne est autorisée et équipée pour réparer, et ce qu'une escalade doit contenir avant que le niveau 2 ne l'accepte : étapes déjà essayées, service concerné, preuves et disponibilité de l'utilisateur. Décidez si vous souhaitez également un filet de sécurité temporel qui fait remonter un ticket qui n'a fait aucun progrès, et indiquez à qui il appartient après le transfert.
Décidez de ce qui doit être approuvé et de ce qui est pré-approuvé
Marquer les articles du catalogue à faible coût et à faible risque comme pré-approuvés afin qu'ils contournent le message « Le supérieur hiérarchique approuve la demande ? entièrement et réserver la porte aux dépenses, aux licences et à tout ce qui modifie ce à quoi une personne peut accéder. Lorsque la demande concerne l'accès au système, confiez-la au processus de demande d'accès plutôt que de l'approuver ici.
Acceptez la fermeture, la réouverture et le renvoi des problèmes, puis publiez une version
Indiquez ce qui compte comme confirmation de l'utilisateur, combien de temps un ticket résolu attend avant la fermeture automatique et les critères de « Problème récurrent ou connu ? » qui soulèvent un problème record. Parcourez ensuite le graphique avec chaque voie, corrigez les étapes qu'elles effectuent réellement et publiez-le en tant que version actuelle avec une signature enregistrée afin que tout le monde lise la même révision.
Questions fréquentes
Quelle est la différence entre un processus d’assistance informatique et la gestion des incidents ?
Le processus du service d'assistance est le flux opérationnel du bureau lui-même : chaque contact qui arrive, sur n'importe quel canal, est acheminé vers le bon type de traitement. La gestion des incidents n’en est qu’un volet, traitant uniquement des interruptions imprévues d’un service. ITIL 4 traite le centre de services, la gestion des incidents, la gestion des demandes de service et la gestion des problèmes comme des pratiques distinctes précisément pour cette raison, même si une petite équipe les gère généralement toutes à partir d'une seule file d'attente avec les mêmes personnes. Ce graphique est une vue au niveau du bureau qui montre comment les volets partagent une entrée et une fermeture, et transmet les détails approfondis de l'incident, tels que la déclaration d'un incident majeur et l'escalade d'une violation du SLA, au processus de gestion des incidents.
Quelle est la différence entre un incident et une demande de service ?
Un incident est quelque chose qui devrait fonctionner et qui ne fonctionne pas : un échec de connexion, une imprimante hors ligne, une application qui génère des erreurs. Une demande de service est un travail standard, convenu à l'avance et sans faute : un nouveau logiciel, une licence, un appareil de remplacement, une boîte aux lettres pour un nouveau démarreur. La distinction est importante car elle change presque tout en aval. Les incidents sont prioritaires en fonction de leur impact et de leur urgence et sont mesurés lors de leur restauration ; les demandes obtiennent une approbation et un chemin d’exécution et sont mesurées à la livraison. Les mélanger signifie soit que les demandes de routine restent sur une horloge de panne, soit que de véritables pannes font la queue derrière les commandes d'ordinateurs portables.
Quand un ticket du service d’assistance doit-il être transmis au niveau 2 ?
Escalader lorsque le travail a dépassé les limites des compétences, des outils ou de l'accès de première ligne, ce qui constitue une escalade fonctionnelle. C'est différent d'une escalade hiérarchique, dans laquelle un responsable est interpellé parce que l'impact ou le retard est devenu un problème commercial plutôt que technique. De nombreux bureaux ajoutent un backstop basé sur le temps afin qu'un ticket qui n'a fait aucun progrès soit automatiquement remonté, ce qui est utile comme filet de sécurité mais constitue en soi une mauvaise règle primaire. Quel que soit le déclencheur, le transfert doit porter ce qui a déjà été essayé, ou le niveau 2 passe sa première heure à répéter le travail de première ligne.
Un ticket doit-il être fermé avant que l'utilisateur ne confirme le correctif ?
Résolu et fermé sont deux états différents, et ce graphique les distingue. Un agent marque un ticket résolu lorsque le correctif est appliqué ; il n'est fermé qu'après « L'utilisateur confirme qu'il est corrigé ? » renvoie un oui. Si l'utilisateur affirme que le problème persiste, le ticket rouvre sur la première ligne plutôt que d'en démarrer une nouvelle, ce qui conserve l'historique et l'horloge d'origine. Étant donné que certains utilisateurs ne répondent jamais, la plupart des bureaux définissent une fenêtre de fermeture automatique de quelques jours ouvrables avec un rappel en premier, et indiquent cette période dans la description du service afin que la fermeture ne soit pas une surprise.
Comment les demandes de service impliquant l’achat de quelque chose s’intègrent-elles dans le processus ?
Ils suivent la branche d'exécution : approbation là où le catalogue l'exige, puis « Article en stock ? qui soit émet à partir du stock existant, soit passe une commande d'achat avant exécution. L'étape que les gens sautent consiste à mettre à jour l'enregistrement de l'actif, c'est pourquoi il se trouve ici dans le même nœud que l'exécution. Si le registre des actifs n'est pas mis à jour au moment de l'émission, le nombre de licences et la planification de l'actualisation du matériel deviennent obsolètes en quelques mois. Pour les achats plus importants ou hors catalogue, le bureau soulève le besoin et le processus de commande d'achat plus large prend le relais, avec son propre approvisionnement et rapprochement des factures.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus passe le relais à Diagramme du processus de gestion des changements (ITIL).
Suit
- Diagramme du processus de gestion des changements (ITIL) — Diagramme du processus de gestion des changements ITIL : accueil des RFC, tri standard, normal et urgence, approbation du CAB, planification, déploiement et retour arrière.
- Organigramme du processus de demande d’accès — Organigramme du processus de demande d’accès : demande basée sur un rôle, approbation du responsable hiérarchique et du propriétaire du système, contrôle de séparation des tâches, attribution et recertification.
- Organigramme du processus de réponse aux incidents de sécurité — Un organigramme du processus de réponse aux incidents de sécurité, depuis la détection et le tri jusqu'au confinement, l'éradication, la notification et l'examen des violations.