Comment visualiser un processus métier

En bref

• Demandez à quelle question le diagramme doit répondre avant de choisir un format.
• Séquence → organigramme. Propriété → couloirs. Modes de défaillance → décisions abouties.
• Le timing appartient aux transferts, pas à un diagramme séparé.
• Conservez une source et produisez des vues à partir de celle-ci ; quatre diagrammes deviennent quatre vérités.
• Si un diagramme a besoin d’une légende pour expliquer sa propre légende, il en contient trop.

Choisissez la vue de la question

« Pouvons-nous avoir un schéma de cela ? » n'est jamais vraiment une demande de diagramme. Il s’agit d’une demande de réponse, et la première étape utile est de découvrir laquelle : si la séquence est correcte, qui est responsable, où passe le temps ou que se passe-t-il en cas d’échec. Chacun d’eux veut une visualisation différente, et produire une mauvaise visualisation est la façon dont les organisations se retrouvent avec un mur de diagrammes que personne ne consulte.

Les questions séquentielles nécessitent un organigramme. Les questions de propriété veulent des voies. Les questions d’exception veulent que les décisions et leurs chemins malheureux soient menés à leur terme. Les questions de timing nécessitent des annotations sur les transferts plutôt qu'un nouveau diagramme du tout. L’erreur est de répondre aux quatre à la fois : un tableau contenant la séquence, les propriétaires, les systèmes, les timings et les références de contrôle est techniquement complet et pratiquement illisible.

La bonne nouvelle est qu’il s’agit ici d’opinions sur une seule chose et non de quatre documents. L'exemple ci-dessous est un processus de contrôle de qualité (inspection via des tests jusqu'à la libération ou au rejet), et il comporte une répartition en trois points d'inspection, une enquête hors spécifications et une décision du comité d'examen des matériaux avec trois résultats. Un seul graphique, mais vous pouvez le lire pour connaître la séquence, la propriété ou savoir où un lot peut rester bloqué.

Comment cela fonctionne

1. Écrivez d'abord la question

   Une phrase : que pourra répondre quelqu’un après avoir regardé ceci ? "Où une commande passe-t-elle son temps ?" et "qui approuve une libération de lots ?" produisez différents diagrammes, et poser la question en premier est ce qui vous empêche de produire les deux et de ne satisfaire ni l'un ni l'autre.

2. Choisissez la plus petite vue qui y répond

   Les questions séquentielles ne nécessitent pas de couloir. Les questions de propriété nécessitent des voies mais pas des horaires. Résistez à l'ajout d'une dimension car l'outil le prend en charge : chaque couche supplémentaire coûte au lecteur l'attention dont la réponse avait besoin.

3. Construisez-le sous forme de lignes pour que les vues soient bon marché

   Dans QueryChart, le graphique est un tableau : étapes, connexions, formes et deux colonnes de voies. L'ajout ou la suppression de la dimension de propriété est une modification de colonne, pas un redessinage, ce qui rend la production d'une deuxième vue plus judicieuse qu'un projet.

4. Mettez du temps sur les transferts

   Lorsque la question porte sur la durée, annotez les croisements entre les voies plutôt que chaque étape. Le temps d'attente entre les équipes domine le temps de travail dans presque tous les processus métier, et le fait de placer les chiffres là où se trouvent les files d'attente rend cela visible immédiatement.

5. Montrez les exceptions ou dites que vous ne l'avez pas fait

   Si vous dessinez délibérément uniquement le chemin heureux (pour un deck d'entraînement, par exemple), étiquetez-le comme tel. Un diagramme du chemin heureux sans étiquette est utilisé plus tard comme s'il s'agissait du processus, généralement par quelqu'un qui décide d'un effectif.

6. Publiez un lien, pas cinq exportations

   Partagez le graphique plutôt que de coller une image dans un deck. Les images exportées sont le mécanisme par lequel quatre vues deviennent quatre versions, chacune figée le jour où quelqu'un en avait besoin.

Erreurs à éviter

• Répondre à quatre questions à la fois

  Un diagramme contenant la séquence, les propriétaires, les systèmes, les timings et les références de contrôle est complet et illisible. Réparti par question, à partir d'une seule source.

• Des diagrammes comme décoration

  Une image de processus dans un diaporama sur laquelle personne ne peut agir est une photo d'archives avec des rectangles. S’il ne répond pas à une question, il n’est pas nécessaire qu’il existe.

• La couleur porte ce qui signifie que personne n'a été informé

  Si le rouge signifie quelque chose, dites-le sur le tableau. Les conventions de couleurs vivent dans la tête de l'auteur et y meurent.

• Exportations au lieu de liens

  Dès qu’un diagramme devient un PNG dans un deck, il cesse de suivre la réalité et il circulera toujours un an plus tard.

Questions fréquentes

Quelle est la meilleure façon de visualiser un processus métier ?

Partez de la question. Si la réponse nécessaire concerne l’ordre, un organigramme suffit. S'il s'agit de responsabilité ou de transferts, utilisez des couloirs. S’il s’agit de modes d’échec, tirez le chemin malheureux de chaque décision vers une véritable conclusion. S'il est temps, annotez les transferts plutôt que de dessiner quelque chose de nouveau. La meilleure visualisation est la plus petite qui répond à la question posée, construite à partir d'une source à partir de laquelle vous pourrez produire d'autres vues ultérieurement.

Dois-je utiliser BPMN pour visualiser un processus ?

Seulement si quelque chose en aval le consomme. La précision de BPMN (événements typés, passerelles, flux de messages) est précieuse lorsqu'un moteur de workflow ou un projet d'intégration va lire le modèle. Pour un diagramme que les gens lisent, cette précision est un impôt : la notation doit être enseignée, et les lecteurs qui ne l'ont pas appris la devinent. La plupart des processus métiers sont mieux servis par des voies, des formes simples et des décisions étiquetées.

Comment puis-je créer un diagramme de processus que les gens utiliseront réellement ?

Conservez-le sur un seul écran, répondez à une question et placez-le là où le travail se déroule plutôt que dans un dossier de documentation. Alors gardez-le à jour : la raison pour laquelle les diagrammes de processus ne sont pas utilisés est presque jamais la compréhension, c'est que les gens ont appris que le diagramme est obsolète. Un graphique édité lorsque le processus change est consulté ; celui qui était parfait en mars ne l’est pas.

Quel niveau de détails une visualisation de processus doit-elle contenir ?

De quoi répondre à la question et pas plus, à un grain cohérent. Quinze à vingt-cinq étapes tiennent sur un écran et tiennent dans la tête d'un lecteur. Lorsqu'il y a vraiment plus à dire, liez un sous-processus plutôt que de réduire la police : un diagramme qui doit être zoomé pour être lu a déjà cessé d'être une visualisation.