Modèle de diagramme de processus de base
Modèle de diagramme de processus de base, de la demande à la clôture : un début, quatre décisions nommées, une boucle de reprise plafonnée au second échec, et trois issues distinctes. Le plus petit flux complet à copier et renommer.
Qu'est-ce que le processus modèle de diagramme de processus de base ?
Chercher un modèle de diagramme de processus de base donne généralement deux résultats : une toile vierge avec une forme de départ posée dessus, ou la procédure en vingt étapes de quelqu'un d'autre pour une activité qui n'est pas la vôtre. Ni l'un ni l'autre n'est un point de départ. La toile vierge ne donne aucune structure à discuter, et un schéma achevé pour un autre processus doit être démonté avant qu'on puisse en réutiliser quoi que ce soit. Ce qui est utile se situe entre les deux : un squelette assez court pour se lire d'un coup d'œil et qui démontre déjà chaque idée structurelle dont vous aurez besoin. C'est ce qu'est ce modèle : une demande générique, soumise, revue, traitée, vérifiée et clôturée.
Les erreurs structurelles d'un premier diagramme sont presque toujours les mêmes quatre. Il y a plus d'un point de départ, si bien que personne ne peut dire ce qui déclenche le travail. Les flèches de décision ne sont pas étiquetées, si bien qu'un losange à deux sorties indique au lecteur qu'un jugement a lieu, mais pas la direction à prendre ensuite. La boucle de reprise n'a pas de plafond, si bien que tout ce qui échoue à la revue est renvoyé pour correction indéfiniment, sans issue. Et il n'y a qu'une seule issue, en général une case appelée Terminé, qui rend invisibles toutes les demandes retirées, abandonnées et non résolues. Le travail s'arrête de plusieurs façons différentes. Un schéma qui n'en admet qu'une seule décrit un processus que personne n'a jamais vraiment suivi.
Le schéma ci-dessous est dessiné comme cinq phases sur trois rôles, car un diagramme de processus reste honnête lorsque les colonnes disent quand et les couloirs disent qui. Il va d'un seul début à trois issues distinctes, et il y parvient grâce à quatre décisions nommées. Deux d'entre elles sont celles que l'on omet généralement : un retour au demandeur lorsqu'une demande arrive sans assez de détails, et une boucle de reprise plafonnée, si bien qu'un premier échec à la revue est renvoyé pour être refait et qu'un second est escaladé plutôt que renvoyé encore une fois. Chaque branche rejoint le flux ou se termine à un terminateur nommé. Supprimez ce que vous ne faites pas, renommez le reste, et c'est votre processus.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq colonnes de phase (Demande, Revue, Réaliser le travail, Vérifier et Clôturer) croisées avec trois couloirs de rôle : Demandeur, Responsable du processus et Relecteur.
- Un seul début, « Soumettre une demande », immédiatement suivi de « Décrire le besoin et l'échéance », de sorte que le déclencheur et le détail minimal qu'une demande doit porter figurent tous deux sur le schéma plutôt que d'être supposés.
- Un portail « Assez d'informations pour commencer ? » dont la branche Non mène à « Ajouter le détail manquant ? », qui renvoie la demande vers « Consigner la demande dans la file » ou la termine à « Demande retirée ».
- Des critères d'acceptation fixés dans le couloir Relecteur à « Convenir des critères d'acceptation » avant que « Réaliser le travail » ne commence, avec « Consigner ce qui a été fait » situé entre le travail et la revue afin que le relecteur ait quelque chose à examiner.
- Une décision « Répond aux critères d'acceptation ? » avec trois sorties nommées plutôt que deux : une réussite, un premier échec qui retourne à « Réaliser le travail », et un second échec qui sort de la boucle vers « Escalader l'échec répété au responsable du processus ».
- Trois issues distinctes : « Demande clôturée » après « Confirmer l'issue avec le demandeur », « Demande retirée » lorsque le détail manquant n'arrive jamais, et « Clôturée sans satisfaire les critères » lorsque « Changer d'approche ou clôturer la demande ? » résout l'escalade dans l'autre sens.
Quand utiliser ce modèle
- On vous a demandé de documenter un processus pour la première fois, et tout ce que vous avez trouvé jusqu'ici est soit une toile vide, soit un flux en vingt étapes pour une activité qui n'est pas la vôtre.
- Un processus existe déjà et fonctionne globalement, mais n'a jamais été dessiné, si bien que chacun peut décrire sa propre partie sans que personne ne puisse décrire les transmissions entre elles.
- Vous formez quelqu'un à dessiner des diagrammes et voulez un petit exemple complet montrant un seul début, des sorties de décision nommées, une boucle plafonnée et plusieurs issues.
- Les demandes arrivent à la personne qui réalise le travail à moitié précisées, et vous devez montrer où elles sont renvoyées plutôt qu'absorbées silencieusement.
- Le travail tourne sans cesse dans la boucle de revue et personne ne peut dire à quel moment il devrait être escaladé plutôt que corrigé à nouveau.
Comment cela fonctionne
Renommer les cinq phases selon vos propres étapes
Demande, Revue, Réaliser le travail, Vérifier et Clôturer sont des espaces réservés pour l'accueil, le tri, l'exécution, la vérification et la clôture. Remplacez-les par les noms d'étapes que votre équipe utilise déjà à l'oral. Si vous n'avez aucune étape de vérification, fusionnez Vérifier avec Réaliser le travail plutôt que de laisser une colonne vide qui laisse entendre une revue que personne n'effectue.
Nommer les trois rôles, et garder le relecteur distinct
Renommez Demandeur, Responsable du processus et Relecteur selon vos rôles réels : un couloir par décideur, pas par personne. La fusion à éviter absolument est de placer le relecteur et la personne qui réalise le travail dans le même couloir. S'il s'agit de la même personne, l'étape de vérification n'est que de la décoration, et vous devriez l'indiquer sur le schéma plutôt que de dessiner une revue qui n'échoue jamais.
Inscrire vos champs de demande minimaux à la deuxième case
« Décrire le besoin et l'échéance » est volontairement vague, car vos champs ne sont pas les nôtres. Listez-les explicitement : ce qui est souhaité, pourquoi, la date à laquelle c'est nécessaire, à qui s'adresser en retour. Cette même liste est ce que « Assez d'informations pour commencer ? » teste deux cases plus loin, donc rédigez-la une fois dans le champ commentaire et réutilisez-la aux deux endroits.
Fixer votre propre plafond de reprise
La décision de revue escalade au second échec. Si votre processus autorise réellement trois tentatives avant escalade, ajoutez une branche et indiquez-le ; s'il n'en autorise aucune, supprimez la flèche de retour vers « Réaliser le travail » et envoyez chaque échec directement à l'escalade. Ce qui compte, c'est que la boucle ait une issue déclarée, car une boucle sans plafond est la façon dont le travail disparaît pendant un trimestre.
Décider qui reçoit l'escalade, et ce qu'il peut faire
« Changer d'approche ou clôturer la demande ? » suppose que quelqu'un est autorisé à clôturer une demande non résolue. Si personne dans votre organisation ne l'est, supprimez « Clôturée sans satisfaire les critères » et faites en sorte que l'escalade retourne toujours à « Convenir des critères d'acceptation » : soyez alors honnête sur le fait que le processus n'a aucun moyen de s'arrêter, et nommez qui porte ce risque.
N'utiliser que les formes dont vous avez réellement besoin
Ce schéma utilise six types de case et pas plus : un début, de simples étapes de processus, des décisions, une étape d'enregistrement, et deux types de terminateurs couvrant ses trois issues. C'est délibéré. La documentation de Microsoft pour son propre modèle Basic Flowchart indique qu'une forme peut porter n'importe quel sens convenu par les personnes qui créeront et liront les diagrammes, et que la plupart des diagrammes n'utilisent en général que trois ou quatre formes. Convenez d'un petit ensemble, écrivez ce que signifie chacune, et arrêtez-vous là.
Questions fréquentes
Quelles sont les étapes d'un diagramme de processus de base ?
Cinq, dans le cas général. L'accueil, où le travail est demandé et décrit. La revue, où quelqu'un décide si la demande est assez complète pour agir. L'exécution, où le travail est réalisé et consigné. La vérification, où une deuxième personne teste le résultat par rapport à des critères convenus au préalable. La clôture, où l'issue est confirmée et la demande formellement fermée. Le schéma ci-dessus utilise exactement ces cinq étapes comme colonnes de phase (Demande, Revue, Réaliser le travail, Vérifier et Clôturer), car presque tout processus opérationnel, d'une intervention de maintenance à une modification de document, s'inscrit dans cette ossature dès lors qu'on cesse de nommer les étapes d'après le service qui les possède.
Qui possède un processus dessiné de cette façon ?
Trois rôles, avec trois choses différentes à posséder. Le demandeur possède l'information : si la demande est incomplète, le processus ne peut pas démarrer, et le schéma la renvoie plutôt que de deviner. Le responsable du processus possède le flux lui-même : la file, l'attribution, l'échéance, et l'escalade lorsque la revue échoue deux fois. Le relecteur possède les critères et les applique, ce qui explique qu'ils soient convenus dans le couloir du relecteur avant que le travail ne commence, plutôt qu'inventés à l'étape de vérification. Donnez au responsable du processus la responsabilité de bout en bout. Sans responsable nommé, une demande qui s'enlise entre deux couloirs n'appartient à personne, ce qui est la façon la plus courante dont le travail se perd.
Que doit-il se passer quand le travail échoue deux fois à la revue ?
Il doit cesser de tourner en boucle. Le premier échec est ordinaire : le relecteur liste les lacunes précises et le travail est renvoyé pour être refait. Un second échec sur la même demande signifie qu'autre chose que l'effort ne va pas : les critères étaient flous, l'approche ne peut pas les satisfaire, ou la demande elle-même n'était pas réalisable. La renvoyer une troisième fois répète le même résultat, plus lentement. Dans ce schéma, le second échec escalade vers le responsable du processus, qui choisit entre changer d'approche, ce qui revient au point où les critères d'acceptation sont convenus, et clôturer la demande non résolue. Les deux issues sont consignées. Aucune ne laisse le travail en suspens.
Les formes de diagramme ont-elles des significations standard ?
Moins que ce que la plupart des gens supposent. Il existe des conventions répandues (une case arrondie pour un début ou une fin, un rectangle pour une étape, un losange pour une décision), et les suivre rend un schéma plus facile à lire pour un étranger. Mais la documentation de Microsoft pour son propre modèle Basic Flowchart indique clairement qu'une forme peut porter n'importe quel sens convenu par les personnes qui créeront et liront les diagrammes, et note que la plupart des diagrammes n'utilisent en général que trois ou quatre formes. Il n'y a donc aucune bibliothèque de formes à apprendre avant de pouvoir commencer. Choisissez-en une poignée, définissez-les dans une légende, et restez cohérent. La clarté vient de l'étiquetage des sorties de décision, pas de la géométrie.