BPMN: un premier processus
Un diagramme BPMN décrit le déroulement d'un travail: ce qui le déclenche, les étapes qui s'enchaînent et l'état dans lequel il s'achève. Ce chapitre construit le plus petit diagramme qui mérite le nom de processus, un symbole à la fois, et pose le vocabulaire dont tous les chapitres suivants se servent.
Quatre symboles suffisent à écrire un processus complet. Ce chapitre les prend un par un et les assemble.
Le modèle et l’instance
Un processus mène un cas particulier d’un état initial à un état final défini1. Le diagramme représente tous les chemins que ce cas pourrait suivre.
Le modèle est le dessin, valable pour toutes les commandes que l’entreprise traitera. L’instance est un parcours individuel: la commande reçue mardi, vérifiée mercredi, expédiée jeudi. Une organisation exécute chaque jour un grand nombre d’instances du même modèle, indépendantes les unes des autres2.
Tout ce qu’un diagramme affirme se vérifie donc instance par instance.
L’événement de début (start event)
L’événement de début indique où un processus commence3. Il se dessine comme un cercle au centre vide, tracé d’un seul trait fin.
La notation est publiée par l’Object Management Group, et cette référence suit la version 2.0.2 du standard3.
La finesse du trait est normative. Le standard exige que l’événement de début soit tracé d’une seule ligne fine, afin qu’il se distingue de l’événement intermédiaire et de l’événement de fin3. Ces trois symboles partagent le même cercle au centre vide; l’épaisseur du trait se lit avant l’étiquette.
Aucun flux de séquence ne peut se connecter à un événement de début3.
Un événement de début sans déclencheur défini s’appelle l’événement de début neutre (none start event), et le standard impose alors qu’il soit affiché sans marqueur3. Les quatre figures de ce chapitre en portent un. Les autres déclencheurs, un message, une échéance ou un signal, occupent ce centre avec leur propre marqueur, et le chapitre sur la grammaire des événements les traite tous.
L’étiquette décrit un état atteint, « Commande reçue ». Un événement marque un fait qui survient à un instant, et l’étiquette gagne à le nommer comme tel. La section sur les règles de début et de fin revient sur ce que le standard exige de ce symbole.
La tâche (task)
Une tâche est une activité atomique: on l’emploie quand le travail ne se décompose pas à un niveau de détail plus fin4. Elle se dessine comme un rectangle à coins arrondis, tracé d’une seule ligne fine.
Le caractère atomique se lit relativement au diagramme. « Vérifier la commande » recouvre sans doute plusieurs opérations chez celui qui l’exécute; ce diagramme s’arrête à ce niveau. Le chapitre sur les sous-processus montre comment descendre d’un cran quand ce choix cesse de tenir.
Les autres bordures sont réservées et portent chacune un sens: un trait épais pour l’activité d’appel (call activity), un pointillé pour le sous-processus événementiel, un double trait pour le sous-processus de transaction4.
Bruce Silver demande que l’étiquette d’une activité prenne la forme verbe puis nom5. « Vérifier la commande » se lit comme un travail que quelqu’un accomplit. « Vérification » nomme une fonction et « Commande vérifiée » nomme un état, deux choses que le diagramme confie à d’autres symboles. Le standard lui-même n’impose aucune forme d’étiquette.
Le flux de séquence (sequence flow)
Le flux de séquence montre l’ordre des éléments dans un processus. C’est la flèche déjà présente sur la figure précédente: une ligne pleine terminée par une pointe pleine6.
Chaque flux de séquence a exactement une source et exactement une cible, à choisir parmi les événements, les activités et les passerelles (gateway)6. Une flèche partant d’un pool ou d’un objet de données serait donc autre chose qu’un flux de séquence: ces éléments se connectent selon leurs propres règles, que les chapitres correspondants détaillent6.
Un flux de séquence peut porter une condition, auquel cas le jeton ne l’emprunte que si cette condition est vraie6. Le chapitre sur les passerelles y revient. Sur les figures de ce chapitre les flux sont inconditionnels, ce qui est le cas par défaut.
Le sens de lecture
Un flux de séquence peut se connecter n’importe où sur un objet de flux, à gauche, à droite, en haut ou en bas, et un flux de message en fait autant7.
Le standard recommande de choisir une direction pour les flux de séquence, de gauche à droite ou de haut en bas, puis de diriger les flux de message à 90 degrés, pour la lisibilité du résultat7.
Les figures de cette référence se lisent de gauche à droite. C’est la convention la plus répandue en Europe, et celle que retiennent les outils de modélisation quand ils disposent les éléments automatiquement. Un diagramme qui se lit de haut en bas reste conforme, à condition de s’y tenir partout.
L’événement de fin (end event)
L’événement de fin indique où un processus se termine8. Il se dessine comme un cercle au centre vide, tracé d’un seul trait épais.
Le trait épais est imposé pour que l’événement de fin se distingue des deux autres symboles8. Aucun flux de séquence ne peut en partir8.
Un même niveau de processus peut porter plusieurs événements de fin8. C’est le moyen usuel de distinguer les issues: une commande peut se terminer expédiée ou refusée, chaque issue portant son propre événement de fin étiqueté. Silver fait de la lisibilité de ces états finaux l’un des objectifs de sa méthode: un lecteur doit voir d’un coup d’œil comment le processus peut se terminer9.
Comme pour l’événement de début, le centre vide correspond ici à l’événement de fin neutre, sans résultat défini8.
Le jeton (token)
Le standard décrit le comportement d’un processus à l’aide d’un jeton qui parcourt les flux de séquence et traverse les éléments3. Le jeton est un concept théorique: il ne figure pas dans le diagramme et sert à définir ce que chaque symbole fait quand le flux l’atteint.
Sur la figure précédente, un jeton naît à l’événement de début quand une commande arrive. Il emprunte le flux de séquence et rend la tâche active, puis repart quand elle s’achève. Il atteint l’événement de fin, qui le consomme8.
Une passerelle parallèle crée plusieurs flux qui progressent ensemble10, ce que le dessin seul ne distingue pas d’un simple embranchement. Dumas et ses coauteurs représentent l’état de plusieurs instances simultanées en posant des jetons de couleurs différentes sur le même modèle2.
Tous les jetons produits dans un processus doivent être consommés par un événement de fin avant que le processus soit achevé8. Une instance dont un jeton reste bloqué est en cours.
Les règles des événements de début et de fin
L’événement de début est optionnel: un niveau de processus peut s’en passer3. L’événement de fin l’est également8. Le processus possède alors un début implicite, sans déclencheur3. Les objets de flux qui n’ont aucun flux de séquence entrant sont instanciés au démarrage du processus, sauf trois cas que les chapitres correspondants traitent: les activités de compensation, l’événement intermédiaire de lien en réception et le sous-processus événementiel3.
Deux règles lient pourtant ces libertés:
- s’il y a un événement de fin, il doit y avoir au moins un événement de début3;
- s’il y a un événement de début, il doit y avoir au moins un événement de fin8.
Omettre les deux est donc permis. En omettre un seul est interdit. Le standard recommande d’utiliser un événement de début dès que le processus est complexe ou que ses conditions de démarrage manquent d’évidence3.
Cette référence dessine systématiquement les deux.
L’ordre des tâches
Avec une seule tâche, le flux de séquence n’affirme pas grand-chose.
L’étiquette de l’événement de fin a suivi: elle nomme l’état dans lequel l’instance se trouve quand elle s’achève, et cet état a changé.
Dans chaque instance, « Vérifier la commande » s’achève avant que « Préparer l’expédition » commence6. Le jeton quitte la première tâche pour entrer dans la seconde, de sorte qu’une seule des deux est active à un instant donné.
C’est souvent la première erreur de modélisation: enchaîner en séquence des travaux qui, dans la réalité, se déroulent en même temps ou dans un ordre indifférent. La passerelle parallèle existe pour ce cas; son chapitre la traite.
Le nommage des éléments
Les étiquettes de ce chapitre suivent trois conventions.
- Les activités portent un verbe suivi d’un nom: « Vérifier la commande », « Préparer l’expédition »5.
- Les événements portent un état: « Commande reçue », « Commande expédiée ». L’étiquette nomme le fait qui survient plutôt que l’action qui l’a produit.
- Le processus porte le nom de ce qu’il accomplit pour une instance: « Traiter une commande ». Ce nom appartient au modèle et n’apparaît sur aucune des figures de ce chapitre, faute de pool pour le porter. Le chapitre sur les pools et les couloirs montre où il se lit.
Le standard n’impose aucune de ces formes. Elles viennent de la pratique et de la méthode de Silver. Un diagramme dont toutes les activités commencent par un verbe se relit sans effort, et une étiquette qui s’y refuse signale souvent que le symbole choisi demande à être reconsidéré. Le chapitre sur le style y revient avec les autres conventions.
Qui accomplit le travail
Une question reste entière à la fin de ce chapitre: le diagramme montre le travail sans dire qui l’accomplit. Les pools et les couloirs portent cette information, et les échanges entre plusieurs organisations passent par des flux de message.
Le chapitre suivant
BPMN: les tâches et leurs types. Les huit types de tâche BPMN, du travail humain à l'appel de service, et les marqueurs de boucle, d'instances multiples et de compensation qui s'y ajoutent.
Notes et références
Bruce Silver, BPMN Method and Style, 2e édition, Cody-Cassidy Press, 2011: un processus BPMN est une suite d’activités menant d’un état initial de l’instance à un état final défini. ↩︎
Marlon Dumas, Marcello La Rosa, Jan Mendling et Hajo A. Reijers, Fundamentals of Business Process Management, 2e édition, Springer, 2018, §3.1. Le jeton y sert à représenter l’état de plusieurs instances simultanées d’un même modèle. ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.5.2 « Start Event ». Cette clause porte la définition de l’événement de début, l’obligation du trait fin, l’interdiction des flux entrants, l’événement de début neutre affiché sans marqueur, le caractère optionnel de l’événement, la règle liant sa présence à celle d’un événement de fin, l’instanciation des objets de flux sans flux entrant avec ses trois exceptions, et l’introduction du jeton. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.3.3 « Tasks ». ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, règle de style: étiqueter les activités sous la forme verbe puis nom, parce qu’une activité est un travail accompli. ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §8.4.13 « Sequence Flow », complété par §7.6.1 « Sequence Flow Connections Rules » pour le tableau des connexions autorisées, où le pool, le couloir, l’objet de données, le groupe et l’annotation textuelle sont absents. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §7.6 « Flow Object Connection Rules »: un flux peut se connecter sur n’importe quel côté d’un objet de flux, et il est recommandé de choisir une direction unique pour les flux de séquence, puis de placer les flux de message à 90 degrés. ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.5.3 « End Event ». L’interdiction des flux sortants y est posée sans exception. La même clause réserve un cas où les jetons sont consommés ailleurs: un sous-processus interrompu avant son terme par un événement intermédiaire attaché à sa frontière, mécanisme que le chapitre sur les événements de bord traite. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition: la méthode vise un modèle dont on lit d’un coup d’œil ce que représente l’instance, comment le processus démarre et quels sont ses états finaux possibles. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.6.4 « Parallel Gateway »: la passerelle parallèle sert à créer des flux parallèles et à les synchroniser. ↩︎