Comment créer un organigramme de processus

En bref

• Corrigez d'abord le déclencheur et la ligne d'arrivée ; tout le reste est au milieu.
• Une action par case, formulée en premier : « Capturer la facture dans le système AP », et non « Facturation ».
• Chaque décision est une question, et chaque sortie porte une étiquette.
• Chaque branche rejoint le flux ou se termine par son propre terminateur, sans qu'aucune ligne ne s'arrête en plein air.
• Le chemin d’exception est la partie qui permet au diagramme de conserver sa conservation.

Qu'est-ce qui fait d'un organigramme un organigramme

La plupart des premières tentatives d'élaboration d'un organigramme de processus ne sont pas des organigrammes. Il s'agit d'une rangée de rectangles reliés par des flèches, décrivant la version du processus où tout se passe bien. Ce dessin est une liste de contrôle avec des étapes supplémentaires, et c'est pourquoi tant de diagrammes de processus sont réalisés une seule fois, imprimés et ne sont plus jamais revus. Tout le monde connaît déjà le chemin heureux. La valeur réside dans ce que dit le graphique sur les autres chemins.

Un organigramme fonctionnel a une grammaire réduite et stricte. Un départ. Une action par case, formulée avec le verbe en premier pour qu'il soit clair qui fait quoi. Une décision rédigée sous forme de question avec chaque sortie étiquetée, afin que le lecteur puisse savoir dans quelle direction il va. Et chaque branche soit rejoint le flux principal, soit se termine par son propre terminateur, car une ligne qui s'arrête en plein air signifie que personne ne sait ce qui se passera ensuite, ce qui est exactement la situation que le graphique était censé corriger.

L’exemple ci-dessous est un véritable processus d’approbation de facture, construit en cinq étapes. Regardez ce qui se passe chez chacun : le graphique devient utile justement lorsque les exceptions arrivent : la facture en double, le prix qui ne correspond pas au bon de commande, la requête qui remonte au fournisseur et réintègre le flux plus haut. Ces trois branches sont la seule raison pour laquelle le diagramme vaut plus que la liste de contrôle.

Comment cela fonctionne

1. Notez d'abord le déclencheur et la ligne d'arrivée

   Avant toute case : quel événement déclenche ce processus et quel état signifie qu'il est terminé ? Ces deux phrases définissent la portée, et la plupart des arguments sur un organigramme se révèlent être des arguments sur les limites plutôt que sur les étapes. Écrivez la ligne d'arrivée sous forme d'état ("fournisseur payé"), et non sous forme d'activité.

2. Répertoriez les étapes sous forme de lignes, pas sous forme de dessin

   Dans QueryChart, ouvrez un nouveau graphique et saisissez les étapes dans la colonne de texte de la zone de texte, une par ligne. Résistez à exposer quoi que ce soit. Une liste est plus rapide à discuter qu'un diagramme, et la mise en page est générée pour vous : le routage est effectué par l'application, donc rien de ce que vous faites à la main ici ne survit de toute façon.

3. Reliez les lignes par numéro

   La colonne Ligne vers prend le numéro de ligne de l'étape suivante, donc la ligne 2 pointant vers 3 dessine la flèche. Tapez plusieurs nombres séparés par des virgules lorsqu'une étape mène à plusieurs endroits. C'est l'ensemble de la connexion d'un organigramme dans QueryChart, et c'est pourquoi le graphique peut être modifié par quelqu'un qui n'a jamais utilisé d'outil de création de diagrammes.

4. Transformez chaque « si » dans vos notes en une décision

   Partout où vos notes disent « si », « à moins que » ou « selon », définissez la forme de cette ligne sur Décision et réécrivez l'étiquette sous forme de question. Ensuite, placez les réponses dans la colonne de texte de la ligne ("Oui", "Non", "Plus de 10 000 £"), afin que chaque sortie indique de quel cas il s'agit. Un fork non étiqueté est la raison la plus courante pour laquelle un organigramme ne peut pas être suivi.

5. Dessinez le chemin de l'exception

   Prenez la branche malheureuse de chaque décision et suivez-la jusqu'à une véritable conclusion : revient-elle à une étape antérieure, est-elle transmise à quelqu'un d'autre ou se termine-t-elle ? Donnez-lui une forme de terminateur à la fin. C’est la partie que les gens sautent, et c’est la partie dont les lecteurs ont réellement besoin : personne ne consulte une cartographie des processus pour savoir ce qui se passe lorsque tout fonctionne.

6. Marchez avec quelqu'un qui fait le travail

   Lisez le tableau à haute voix à la personne qui dirige le processus et demandez-lui où il ne va pas. Attendez-vous à trouver une étape qui fait en réalité trois et une branche que personne n'a jamais écrite. Corrigez-le dans les lignes, partagez le graphique et approuvez-le afin que la version que les gens consultent soit celle convenue plutôt qu'une capture d'écran dans le diaporama de quelqu'un.

Erreurs à éviter

• Décisions formulées sous forme de déclarations

  « L'approbation du gestionnaire » est une étape ; "Le manager approuve ?" est une décision. Si un diamant ne se lit pas comme une question, les deux lignes qui en sortent ne peuvent pas être étiquetées de manière judicieuse, et le lecteur doit deviner laquelle s'applique à elles.

• Des branches qui s'arrêtent dans les airs

  Chaque ligne doit arriver quelque part : une autre étape ou un terminateur. Une branche qui se termine simplement est le graphique admettant que personne ne sait ce qui se passe dans ce cas, ce qui vaut la peine d'être connu, mais devrait être corrigé plutôt que dessiné.

• Une boîte faisant trois choses

  « Examiner, approuver et classer » se compose de trois cases avec deux points de défaillance possibles cachés entre elles. Si l'étiquette d'une étape nécessite un « et », il s'agit généralement de plusieurs étapes, et le transfert que vous ne pouvez pas voir est l'endroit où se situe le retard.

• Tracer le processus que vous souhaiteriez avoir

  Cartographiez d'abord le processus tel quel, exceptions et solutions de contournement incluses, même lorsque cela est embarrassant. Un futur tableau établi avant que quiconque ne soit d’accord sur ce qui se passe aujourd’hui est une proposition, et il devrait être étiqueté comme tel.

Questions fréquentes

De quelles formes ai-je besoin pour un organigramme de processus ?

Quatre contiennent presque tout : un terminateur pour le début et chaque état final, un rectangle pour une action, un losange pour une décision et une forme de document pour une étape qui produit un enregistrement : un formulaire signé, un rapport, une entrée enregistrée. QueryChart propose également des terminateurs de rejet et de réussite, ce qui est utile car un graphique a généralement plusieurs façons de terminer et les colorer différemment rend les fins malheureuses visibles d'un coup d'œil.

Dans quelle mesure un organigramme de processus doit-il être détaillé ?

Suffisamment détaillé pour que quelqu'un qui ne fait pas le travail puisse le suivre, et pas plus. Un test pratique : si une étape peut être confiée à une autre équipe sans autre explication, elle ne constitue qu'une seule case. Si l'expliquer prend un paragraphe, il s'agit probablement d'un sous-processus qui mérite son propre tableau, lié à celui-ci. Quinze à vingt-cinq cases constituent la plage dans laquelle la plupart des processus opérationnels restent lisibles sur un seul écran.

Quelle est la différence entre un organigramme de processus et une carte de processus ?

Un organigramme montre la séquence et la logique : ce qui se passe, dans quel ordre, avec quelles décisions. Une cartographie des processus ajoute du contexte autour de cette séquence : à qui appartient chaque étape, dans quel système elle se déroule, ce qui entre et ce qui sort. Dans la pratique, la distinction concerne principalement les voies : dès que vous divisez le flux par propriétaire, vous disposez d'une carte de processus, et c'est généralement la version qui vaut la peine d'être utilisée pour tout ce qui traverse les limites d'une équipe.

Les décisions doivent-elles toujours être oui ou non ?

Non, mais ils doivent être exhaustifs et mutuellement exclusifs. Une répartition en trois types de changement (standard, normal, urgence) est acceptable tant que chaque demande aboutit exactement à l'un d'entre eux. Ce qui brise un graphique, c'est une décision dont les sorties étiquetées ne couvrent pas tous les cas, car le lecteur dont la situation est absente n'a nulle part où aller et inventera son propre chemin.