BPMN: style, conventions et erreurs fréquentes
Le style est l'ensemble des conventions qui s'ajoutent au standard pour qu'un diagramme se lise sans commentaire. Le standard de l'OMG dit ce qu'un symbole signifie et impose peu de choses sur la façon de l'employer. Deux corpus comblent l'écart, la méthode de Bruce Silver et, pour l'administration publique suisse, les conventions eCH; Dumas et ses coauteurs fournissent le cadre qui les ordonne. Ce chapitre les rassemble en nommant chaque fois leur auteur, et distingue ce qui rend un modèle illisible de ce qui le rend faux.
Un modèle peut satisfaire le standard et n’apprendre rien à personne. Silver ouvre son chapitre sur le style par un diagramme valide dont les activités, la passerelle, ses sorties et ses états finaux sont sans étiquette: aucune règle officielle n’est enfreinte et l’information utile est nulle1.
Trois sources de règles
Le standard de l’OMG définit la sémantique des symboles et pose des exigences de connexion et d’apparence. Il n’énumère pas ses propres règles: Silver relève l’absence d’annexe récapitulative et compte trois sources de vérité, le métamodèle en diagrammes de classes UML, le schéma XSD qui en est une seconde formulation, enfin le récit de la spécification, où les règles propres à chaque type d’élément sont dispersées sur cinq cents pages. Les trois sont censées concorder, ce qui n’est pas toujours le cas, de sorte que chaque outil se constitue sa propre liste de validation2.
La méthode de Silver ajoute des conventions qu’il appelle des règles de style. Son principe tient en une phrase: la logique du processus doit se lire sans ambiguïté à partir du seul diagramme1. Il les a formulées en règles pour qu’un outil puisse les valider, après avoir constaté que les mêmes conventions présentées comme de bonnes pratiques étaient ignorées dès que le modélisateur était pressé1.
Les conventions eCH engagent l’administration publique suisse. eCH-0158 fixe les conventions élément par élément, avec pour chacun ses conventions de nommage, ses attributs et ses conventions de modélisation, illustrées par un exemple conforme et un exemple non conforme3. eCH-0074 pose les principes qui les précèdent, dont le principe de justesse, qui exige une saisie métier exacte et une application sans faute de la syntaxe du standard, le principe de clarté, qui veut qu’un modèle soit lisible et compréhensible d’emblée par le métier, et le principe de comparabilité, qui fait de l’unité de méthode le moyen d’harmoniser des processus de structure voisine4.
Dumas et ses coauteurs jugent un modèle sur trois qualités: la qualité syntaxique, sa conformité aux règles du langage, vérifiée par une vérification; la qualité sémantique, son adéquation au processus réel, établie par une validation avec les experts métier; la qualité pragmatique, son utilisabilité, mesurée par l’usage qu’en font ses lecteurs5. Les conventions de ce chapitre servent la troisième.
Le nommage des activités
Silver demande la forme verbe puis nom, parce qu’une activité représente un travail accompli: « Vérifier le dossier ». « Contrôle du dossier » nomme une fonction et « Dossier contrôlé » un état, deux choses que le diagramme confie à d’autres symboles6. Le chapitre 1 pose déjà cette règle sur le premier diagramme.
Dumas la confirme par la mesure: le style verbe-objet est jugé nettement moins ambigu et plus utile que le style action-nom, et il en fait la sixième de ses sept lignes directrices de modélisation7. Il montre aussi ce que coûte le mélange des styles: dans un modèle où voisinent « Get approval for expenses », « Cost planning » et « Recalculation of costs », l’étiquette « Plan data transfer » devient indécidable, puisqu’elle peut signifier planifier un transfert de données ou transférer des données de plan8.
eCH-0158 aboutit au même résultat une fois traduit: les activités sont toujours nommées d’un substantif antéposé et d’un verbe à l’infinitif, « Korrekturen begründen », ce que le français rend par « Justifier les corrections ». La même règle vaut pour le nom du diagramme9. Quatre conventions générales l’encadrent: tenir les termes dans une seule langue, renoncer autant que possible aux abréviations, préférer un terme unique par notion en s’appuyant sur un glossaire ou sur la banque de données terminologique de l’administration fédérale, enfin laisser les étiquettes sans mise en forme10.
Silver demande enfin de donner des noms différents à deux activités d’un même modèle qui diffèrent, et de passer par une activité d’appel référençant la même tâche globale lorsqu’il s’agit du même travail11.
Le nommage des événements
Les événements de début
Silver emploie l’étiquette de l’événement de début pour dire comment le processus démarre: un événement de début de message porte « Recevoir [nom du message] », une minuterie porte la périodicité, du type « Tous les lundis à 8 heures », et un événement de début neutre, qui signale un démarrage manuel par un exécutant, peut rester sans étiquette12.
eCH-0158 répartit l’information autrement. L’événement de début neutre n’est pas décrit, puisqu’il sert au sous-processus démarré par l’appel du niveau supérieur. L’événement de début de message n’est pas décrit non plus lorsque le flux de message entrant, obligatoire, porte la désignation. L’événement de début de condition porte sa condition dans son nom, et s’il correspond à l’événement de fin d’un autre processus, il est nommé à l’identique. La minuterie contient le moment du démarrage, « le 1er du mois » ou « 09h00 »13.
Les deux conventions se rejoignent sur le fond: le déclencheur est lisible une fois sur le diagramme. Elles divergent sur le porteur de l’information, l’étiquette de l’événement chez Silver, le flux de message chez eCH.
Les événements de fin
Silver et eCH-0158 conviennent que l’événement de fin porte l’état final de l’instance; le standard n’en dit rien. Silver en fait la marque distinctive de sa méthode: il conseille un événement de fin par état final à distinguer, chacun étiqueté de cet état, et observe que la plupart des modélisateurs se contentent d’un événement unique, ce qui dissimule une information de valeur et complique la traçabilité de la logique d’un niveau de processus à l’autre14. Deux événements de fin d’un même niveau portant le même nom sont à fusionner s’ils représentent le même état, à renommer sinon15.
eCH-0158 étiquette les événements de fin du statut de la prestation fournie, « Rapport établi », « Commande erronée », et note que ce statut peut servir d’événement de début à un autre processus. Dumas rejoint les deux par sa troisième ligne directrice, un événement de début par déclencheur et un événement de fin par issue, appuyée sur des études empiriques reliant le nombre de ces événements à la probabilité d’erreur7.
Le nommage des pools et des couloirs
Le standard décrit le pool comme la représentation graphique d’un participant, lequel est soit une entité partenaire précise, une entreprise par exemple, soit un rôle partenaire, un acheteur ou un fabricant16. Son unique exigence sur l’étiquette porte sur la mise en page: elle peut occuper n’importe quel emplacement et n’importe quelle direction à l’intérieur du pool, à condition d’être séparée du contenu par un trait; un pool boîte noire, qui ne contient pas de processus, s’en dispense16.
Silver va plus loin et demande d’étiqueter un pool de processus du nom du processus, réservant
aux pools boîte noire les noms de rôle ou d’entité. L’identifiant d’un élément sémantique est son
attribut id, invisible au diagramme, tandis que l’étiquette rend le name. Deux pools nommés
« Notre entreprise » désigneraient donc des participants distincts sous un même nom, et les relier
par un flux de message reviendrait à suggérer que la source et la cible sont le même participant.
Il note que la spécification elle-même encourage l’usage qu’il déconseille17.
eCH-0158 admet cet usage. Les pools y désignent des participants à une collaboration, qui peuvent être des unités d’organisation, des participants au processus au sens de rôle ou d’autres processus; les unités d’organisation et les rôles reçoivent un substantif, les processus la forme substantif plus infinitif. La convention ajoute que chaque pool ne figure qu’une fois par diagramme, que l’étiquette d’un pool ouvert est pivotée de 90 degrés vers la gauche, que les pools sont empilés sur toute la largeur du diagramme, que la hauteur d’un pool ouvert suit son contenu et qu’un pool fermé porte au moins un flux de message entrant ou sortant18.
Pour les couloirs, eCH-0158 demande une désignation de rôle au singulier, interdit qu’un couloir porte le même nom que son pool, pivote de même son étiquette et limite l’imbrication à trois niveaux19. Le chapitre sur les pools et les couloirs traite ces symboles en détail.
La règle la plus lourde de conséquences est celle de Silver: modéliser les unités d’organisation internes comme des couloirs d’un pool de processus unique, puisque des pools séparés signifient des processus indépendants. Il réserve les pools multiples au cas où les instances ne se correspondent pas une pour une, l’exemple étant une facturation mensuelle en regard d’un traitement de commande20. Le client ou tout autre demandeur extérieur reçoit un pool boîte noire, parce que sa logique interne échappe au modélisateur21.
Un processus par pool
Le pool contient entièrement le processus et ses flux de séquence, lesquels traversent les frontières entre couloirs16. Silver en tire deux règles qu’il range parmi les officielles, sa lecture de ce que la spécification exige: les éléments d’au plus un processus figurent dans un pool, et un pool n’en contient pas un autre, une expansion de sous-processus enfermée dans un pool devant référencer le même participant et le même processus que le niveau parent22. eCH-0158 formule la même exigence par l’affirmative: dans chaque pool ouvert est modélisé exactement un processus complet18.
La frontière du pool
Un flux de séquence ne traverse pas la frontière d’un pool, et les objets contenus dans un sous-processus développé ne se connectent pas à des objets situés au dehors23. Un flux de message ne relie pas deux objets situés dans le même pool24. Silver reprend les deux dans sa liste et les reformule: un message BPMN est par définition échangé entre le processus et une entité extérieure, de sorte qu’un courriel entre deux tâches d’un même processus n’en est pas un25.
eCH-0158 précise le tracé. Les flux de message se connectent sur le côté supérieur ou inférieur des éléments, leurs désignations se placent entre les pools, ils ne se superposent pas, et un flux de message représenté à un niveau de processus inférieur n’est pas répété aux niveaux supérieurs26. La désignation elle-même porte l’information transmise, « Commande », ou le support de la transmission, « Courriel »26. Silver demande la première: l’étiquette d’un flux de message est le nom du message27. Le chapitre sur les flux et les artefacts détaille ces deux traits.
L’étiquetage des passerelles
C’est le point où les trois sources s’écartent le plus.
Silver étiquette la division d’une question et chacune de ses sorties de la réponse correspondante. Deux de ses règles de style le formalisent: une division exclusive comporte au plus une sortie sans étiquette, et une division exclusive ou inclusive est étiquetée dès qu’une de ses sorties ne l’est pas28. Une règle supplémentaire assure la traçabilité entre niveaux: lorsqu’un sous-processus est suivi d’une passerelle étiquetée d’une question, ce sous-processus porte plusieurs événements de fin, dont l’un reprend l’étiquette de la passerelle29.
Dumas préfère l’inverse. Il demande d’annoter chaque flux sortant d’une division exclusive de la condition qui le fait emprunter, avec des conditions mutuellement exclusives30, et juge préférable de laisser la passerelle sans étiquette: une étiquette de passerelle du type « Acceptable ? » dissimule une activité de décision, et des sorties nommées « plan acceptable » et « plan inacceptable » disent plus que « oui » et « non »8.
eCH-0158 se tient près de Dumas et va plus loin sur les flux. Les passerelles de division ne sont étiquetées que si cela améliore la teneur informative du diagramme; les passerelles de fusion, événementielles et parallèles ne le sont pas. Les flux de séquence sont par principe sans étiquette, à une exception près: les flux issus d’une passerelle exclusive ou inclusive doivent porter la décision correspondante, ou les états finaux du sous-processus qui précède immédiatement31.
Le marqueur, lui, relève du standard: la croix de la passerelle exclusive est facultative, et un diagramme se tient à un usage constant, avec ou sans32. Cette référence la dessine partout, comme l’explique le chapitre sur les passerelles.
eCH-0158 encadre encore l’amont et l’aval de la division. Une activité est obligatoire avant une passerelle exclusive ou inclusive, et elle détermine l’embranchement sur la base d’une règle de gestion; la passerelle événementielle fait exception, et deux passerelles peuvent se suivre avec prudence, l’enchaînement de deux passerelles événementielles ou de deux passerelles parallèles restant exclu33. Une division de flux de séquence part toujours d’une passerelle plutôt que directement d’une activité, laquelle est suivie d’exactement un flux de séquence34. Enfin, au delà de deux passerelles exclusives ou inclusives consécutives, il s’agit le plus souvent d’une règle de gestion, que la convention suggère de représenter autrement, en DMN, en prose, en SBVR ou en liste de contrôle, et de remplacer dans le diagramme par une activité portant la description correspondante35.
La division et la fusion
Dumas apparie la division et la fusion dans la structure en bloc, un fragment à entrée unique et sortie unique délimité par une division et une fusion, chaque chemin de l’une menant à l’autre. Lorsque les deux passerelles sont de même type, aucune anomalie de comportement ne peut naître du bloc; lorsqu’elles diffèrent, apparaissent l’interblocage (deadlock), le défaut de synchronisation (lack of synchronization) ou l’activité morte (dead activity)36. Sa quatrième ligne directrice demande de modéliser aussi structuré que possible, la cinquième d’éviter les passerelles inclusives là où c’est possible, la sémantique de la fusion inclusive étant complexe et les modèles limités aux passerelles parallèles et exclusives se révélant moins sujets à erreur7.
eCH-0158 en fait une obligation: la fusion des flux de séquence divisés se fait sur la même ligne horizontale que la division. Deux exceptions sont prévues, le flux divisé par une passerelle exclusive ou événementielle qui rencontre un événement de fin avant la fusion, et le flux qui appartient à une boucle de contrôle et retourne au début de l’activité de contrôle lorsque la condition n’est pas remplie37. Silver est ici plus permissif: des chemins alternatifs se rejoignent directement sur l’activité suivante, et il réserve la passerelle exclusive de fusion au cas où la fusion débouche sur une autre passerelle, dont le comportement serait sinon ambigu à la lecture38.
La mise en page
Le sens de lecture est le premier réglage. Le standard recommande de choisir une direction unique pour les flux de séquence puis de diriger les flux de message à 90 degrés39, ce que le chapitre 1 applique à toutes les figures de cette référence. eCH-0158 le pose en convention de représentation: les modèles se lisent de gauche à droite40.
La taille du diagramme vient ensuite. eCH-0158 demande le format paysage, A3 au maximum, quinze activités par diagramme au plus, des symétries graphiques rendant la structure du déroulement visible, et les seuls éléments des participants extérieurs indispensables à la compréhension du travail propre41. Silver obtient le même résultat par la hiérarchie: chaque niveau de processus tient sur une page, le niveau supérieur portant le processus de bout en bout et ses échanges avec l’extérieur, chaque sous-processus étant développé sur un diagramme enfant42. Dumas chiffre le seuil: au delà de trente éléments, la probabilité d’erreur grimpe fortement et le modèle est à décomposer; ses deux premières lignes directrices demandent d’employer le moins d’éléments possible et de limiter le nombre de chemins par élément7.
Restent les détails de tracé, tous chez eCH-0158. Les activités et les événements se relient horizontalement, les retours en arrière et les croisements sont à éviter, les passerelles admettant une connexion par le haut ou par le bas; les flux de séquence ne se superposent pas, sauf sur une passerelle portant plus de quatre flux de même sens ou sur une activité portant plus de deux flux entrants34. Tous les éléments d’un même type gardent la même taille et la même forme43. Les couleurs sont à éviter, ce qui accroît l’uniformité et donc la comparabilité des diagrammes, réduit les barrières liées aux déficiences de la vision des couleurs et assure une impression correcte en noir et blanc; lorsque la lisibilité y gagne, une couleur peut être attribuée avec retenue selon un concept clair44. Dumas confirme par la mesure que la cohérence entre structure visuelle et structure logique, obtenue par une orientation du haut à gauche vers le bas à droite et par l’absence d’arcs croisés, améliore la compréhension45.
eCH-0158 recommande enfin, au besoin, de numéroter les processus d’un numéro unique, invariable et continu à l’échelle du système de processus de l’organisation, la numérotation étant réglée centralement, et de renoncer idéalement à numéroter les activités. La même clause met en garde contre les numérotations hiérarchiques, qui entraînent de vastes renumérotations dès que la structure ou l’ordre des processus change, et contre l’intégration de caractéristiques supplémentaires dans un identifiant, sigle d’organisation ou type de processus, qui deviennent problématiques quand elles changent46.
Les erreurs qui rendent le modèle faux
Les conventions qui précèdent règlent la lisibilité. Les trois constructions qui suivent enfreignent une exigence, et le modèle est faux au sens de la qualité syntaxique de Dumas, celle qu’une vérification établit sans rien savoir du processus réel5.
Le jeton qui n’atteint aucun événement de fin
Le standard définit l’achèvement d’une instance par trois conditions: les événements attendus d’une éventuelle passerelle parallèle instanciante sont survenus, aucun jeton ne subsiste dans l’instance et aucune activité n’est encore active. Pour qu’une instance s’achève, tous ses jetons doivent atteindre un nœud terminal, c’est-à-dire un nœud sans flux de séquence sortant47.
Dumas nomme les façons de manquer cette condition. L’interblocage bloque un jeton dans un état d’où il ne progresse plus; la boucle infinie (livelock) l’y fait tourner sans issue; l’activité morte est celle qu’aucune instance n’exécute jamais. Il ajoute une règle structurelle au niveau du modèle, tout nœud de flux se trouve sur un chemin allant d’un événement de début à un événement de fin, et définit la solidité (soundness) par trois propriétés, la possibilité d’achèvement, l’achèvement propre, où chaque jeton se trouve au moment de l’achèvement sur un événement de fin distinct, et l’absence d’activité morte48. eCH-0158 obtient le même résultat par une convention d’une ligne: chaque branche du processus mène à un événement de fin49.
La passerelle employée comme une activité
Une passerelle doit comporter soit plusieurs flux de séquence entrants, soit plusieurs sortants, autrement dit fusionner ou diviser le flux50. Une passerelle munie d’un flux entrant unique et d’un flux sortant unique enfreint donc une exigence du standard. Elle est en outre sans effet: les passerelles ne représentent aucun travail et sont réputées sans incidence sur les mesures opérationnelles du processus, coût ou durée51. Silver reprend la contrainte du côté de la division: une passerelle de division comporte plus d’une sortie52.
Le flux de message à l’intérieur d’un pool
La table des règles de connexion du standard interdit qu’un flux de message relie deux objets d’un même pool24. Le tracé fautif et sa correction figurent plus haut, dans la section sur la frontière du pool.
Les constructions valides au comportement non voulu
Le standard admet la construction qui suit et lui donne une sémantique. Elle produit rarement ce que le modélisateur voulait dire, et eCH-0158 l’écarte en rendant la fusion obligatoire.
Une activité cible de plusieurs flux de séquence participe à ce que le standard appelle le flux non contrôlé: chaque jeton arrivant sur l’un des flux entrants active la tâche indépendamment de l’arrivée des autres, et la présence de plusieurs flux entrants se comporte comme une passerelle exclusive. Pour contrôler l’arrivée des jetons, le standard demande d’insérer avant la tâche une passerelle d’un type autre qu’exclusif53. Silver donne son nom à cette construction, le multi-merge, et observe qu’elle déclenche l’activité suivante une fois par flux entrant, ainsi que toutes les activités en aval, ce qui est presque toujours autre chose que ce que le modélisateur voulait dire54.
La question se pose dès qu’une division inclusive ouvre des chemins conditionnels: une fusion parallèle attendrait un jeton sur les chemins que l’instance n’a pas empruntés et interbloquerait. La fusion inclusive est la construction qui convient: sa condition d’activation revient à attendre les branches entrantes qu’un jeton en circulation peut encore atteindre55, de sorte qu’elle ignore les flux qui ne sont pas activés pour l’instance en cours56. Le chapitre sur les passerelles traite ce comportement en détail.
Le désaccord entre les sources
| Point | Silver | Dumas | eCH-0158 |
|---|---|---|---|
| Étiquette de la division | La question sur la passerelle, la réponse sur chaque sortie | Passerelle muette, conditions détaillées sur les sorties | Sorties obligatoirement étiquetées après une passerelle exclusive ou inclusive, passerelle au choix |
| Étiquette du pool de processus | Le nom du processus | Sans position | Une unité d’organisation, un rôle ou un processus |
| Fusion des chemins divisés | Les chemins alternatifs rejoignent directement l’activité suivante | Division et fusion appariées en type | Convergence obligatoire, sur la ligne horizontale de la division |
| Étiquette d’un événement de début de message | « Recevoir [nom du message] » | Sans position | Aucune, dès que le flux de message entrant porte l’information |
Le standard, lui, laisse ces quatre points ouverts. L’ordre de préséance est clair. Les exigences du standard engagent tout le monde. eCH-0158 engage l’administration publique suisse et quiconque déclare s’y conformer. Les règles de Silver engagent qui adopte sa méthode. Reste le cas ordinaire, une organisation qui n’est soumise à aucun des deux corpus: eCH-0074 lui demande de consigner ses propres conventions dans un règlement BPMN interne, conventions de nommage des activités comprises, et d’y définir les caractéristiques à saisir ainsi que l’organisation du processus de validation57. Le choix compte moins que sa constance.
Au-delà du style
Le style dit comment écrire; les motifs courants rassemblent les assemblages qui reviennent d’un modèle à l’autre. Les conventions eCH prennent leur sens complet dans le chapitre qui leur est consacré, et ces règles s’appliquent dans la palette des niveaux de modélisation.
Le chapitre suivant
BPMN: la chorégraphie et la conversation. Les deux types de diagramme que BPMN 2.0 définit à côté du processus et de la collaboration: la chorégraphie, la conversation, leurs éléments et leur rareté.
Notes et références
Bruce Silver, BPMN Method and Style, 2e édition, Cody-Cassidy Press, 2011, chapitre 6 « BPMN Style »: les conventions supplémentaires nécessaires au partage de la compréhension, que ni la spécification ni la méthode ne procurent, appelées style; leur enseignement d’abord sous forme de bonnes pratiques puis leur formulation en règles de style validables par un outil, motivée par le constat que les bonnes pratiques sont ignorées dès que le modélisateur est pressé; le principe de base selon lequel la logique du processus doit être sans ambiguïté à partir du seul diagramme; enfin la figure 6-1, valide au sens de BPMN 2.0 et sans information utile, dont les activités, la passerelle, ses sorties et ses états finaux sont sans étiquette, et le rapport de validation qui en relève six violations, toutes liées à l’étiquetage. ↩︎ ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 11 « The Rules of BPMN », section « Sources of BPMN Truth »: l’absence d’énumération des règles et d’annexe récapitulative dans les cinq cents pages de la spécification, les trois sources de vérité que sont le métamodèle en diagrammes de classes UML sérialisé en XMI, le schéma XSD et le récit de la spécification, leur concordance imparfaite, la dispersion des règles propres à chaque type d’élément dans le récit, enfin l’obligation faite à chaque outil de se constituer sa propre liste de règles de validation. ↩︎
eCH-0158 version 1.2, Conventions de modélisation BPMN pour l’administration publique, §3.1 « Introduction »: la table de lecture des chapitres suivants, avec pour chaque élément BPMN sa description, ses variantes, ses conventions de nommage complétant le chapitre 2, ses attributs requis et optionnels, enfin ses conventions de modélisation illustrées par un exemple conforme à eCH-0158 et un exemple non conforme. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
eCH-0074 version 2.2, Principes de modélisation graphique des processus métier, §2.2.1 « Principe de justesse », §2.2.4 « Principe de clarté » et §2.2.5 « Principe de comparabilité »: la double exigence d’une saisie et d’une représentation métier exactes et d’une application sans faute de la notation du standard de modélisation imposé, avec le renvoi aux conventions de modélisation eCH-0158 comme moyen d’une application uniforme; l’exigence que les modèles soient clairs, lisibles et compréhensibles d’emblée pour les utilisateurs du côté métier; enfin la comparabilité obtenue par la fixation d’une méthode unique, qui permet d’harmoniser des processus de structure voisine. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0074/2.2 ↩︎
Marlon Dumas, Marcello La Rosa, Jan Mendling et Hajo A. Reijers, Fundamentals of Business Process Management, 2e édition, Springer, 2018, §5.4 « Process Model Quality Assurance », avec §5.4.1 « Syntactic Quality and Verification », §5.4.2 « Semantic Quality and Validation » et §5.4.3 « Pragmatic Quality and Certification »: les trois qualités d’un modèle de processus, syntaxique, sémantique et pragmatique, avec les trois activités qui les assurent, la vérification, la validation et la certification, et la mention des lignes directrices et conventions de modélisation comme moyen d’atteindre la qualité dès le départ. La vérification porte sur des propriétés formelles vérifiables sans connaître le processus réel. ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 8 « Label activities VERB-NOUN »: les activités, sous-processus compris, représentent un travail ou une action accomplis dans le processus, d’où la forme verbe puis nom, avec les exemples Check credit comme action en regard de Credit check comme fonction et de Credit OK comme état. ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §5.4.4 « Modeling Guidelines and Conventions », les sept lignes directrices de modélisation de processus: G1 employer le moins d’éléments possible, G2 minimiser le nombre de chemins par élément, G3 un événement de début par déclencheur et un événement de fin par issue, appuyée sur les études empiriques reliant le nombre de ces événements à la probabilité d’erreur, G4 modéliser aussi structuré que possible, G5 éviter les passerelles inclusives là où c’est possible, les modèles limités aux passerelles parallèles et exclusives étant moins sujets à erreur et la sémantique de la fusion inclusive étant complexe, G6 employer des étiquettes d’activité en verbe-objet, jugées significativement moins ambiguës et plus utiles que les étiquettes action-nom, G7 décomposer un modèle de plus de trente éléments, seuil au delà duquel la probabilité d’erreur grimpe fortement. La même sous-clause distingue les lignes directrices, qui sont des suggestions, des conventions, qui sont des règles obligatoires, et énumère les quatre aspects sur lesquels elles portent, le vocabulaire, la structure, la sémantique et l’apparence. ↩︎ ↩︎ ↩︎ ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §5.4.3 « Pragmatic Quality and Certification »: le second contrôle de compréhensibilité porte sur des étiquettes signifiantes; l’exemple de la figure 5.17 mêle le style verbe-objet (« Get approval for expenses ») et le style action-nom (« Cost planning », « Recalculation of costs »), d’où l’ambiguïté de « Plan data transfer », qui peut signifier planifier un transfert de données ou transférer des données de plan, ainsi que l’emploi concurrent de costs et expenses faute de glossaire commun; la même page relève que l’étiquette de l’événement de fin « Approved » manque d’objet métier et que l’étiquette « Acceptable ? » de la division exclusive dissimule l’existence d’une activité de décision « Check plan acceptability », d’où la préférence pour des divisions non étiquetées et des conditions plus explicatives que « oui » et « non » sur leurs sorties. ↩︎ ↩︎
eCH-0158 version 1.2, §3.6 « Activité »: le terme activité couvre la tâche comme le sous-processus; les activités sont toujours nommées d’un substantif antéposé et d’un verbe à l’infinitif, avec l’exemple « Korrekturen begründen »; les sous-processus sont représentés fermés et décrits dans un diagramme propre; une activité est suivie d’exactement un flux de séquence; une activité comportant un contrôle est toujours suivie d’une passerelle. La même convention de nommage vaut pour le diagramme (§3.2 « Diagramme »). Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
eCH-0158 version 1.2, §2.2 « Conventions de description », avec §2.2.1 « Langue », §2.2.2 « Abréviations », §2.2.3 « Ontologies » et §2.2.4 « Formatage »: tenir les termes autant que possible dans une seule langue et éviter les mélanges, l’exemple étant d’écrire Sitzung plutôt que Meeting dans un modèle allemand; renoncer autant que possible aux abréviations, quitte à les consigner dans un glossaire à côté des désignations longues; préférer un terme unique par notion, tenir un glossaire de projet ou d’entreprise ou recourir à la banque de données terminologique multilingue de l’administration fédérale suisse, l’emploi de terminologies fixées augmentant la compréhensibilité et facilitant la traduction; enfin renoncer aux mises en forme dans les étiquettes, et proscrire les sauts de ligne et les traits d’union manuels en cas d’emploi conjoint avec une notation d’architecture. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle 15, et chapitre 11, règle de style 2: deux activités d’un même modèle ne portent pas le même nom; s’il s’agit de la même activité, employer une activité d’appel référençant la même tâche ou le même processus global, sinon leur donner des noms différents. La règle du chapitre 11 réserve le cas où les deux sont des activités d’appel. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 9, et chapitre 11, règle de style 3: employer le déclencheur de l’événement de début du processus de niveau supérieur pour indiquer comment le processus démarre, l’événement de début de message étiqueté « Receive [nom du flux de message] », l’événement de début de minuterie étiqueté de la périodicité, du type Monthly ou Mondays at 8am, l’événement de début neutre signalant un démarrage manuel par un exécutant et pouvant rester sans étiquette; la règle du chapitre 11 ajoute le signal, étiqueté du nom du signal, et la condition, étiquetée de la condition de déclenchement. ↩︎
eCH-0158 version 1.2, §3.5.1 « Événement de début »: l’événement de début neutre n’est pas décrit, le sous-processus étant démarré par l’appel du niveau de processus supérieur; l’événement de début de message n’est pas décrit lorsque le message entrant est visible sur le flux de message obligatoire; l’événement de début de condition porte la condition dans la désignation de l’élément, et est nommé à l’identique s’il correspond à l’événement de fin d’un autre processus; l’événement de minuterie contient le moment du démarrage, avec les exemples « le 1er de chaque mois » et « 09h00 ». Les conventions de modélisation associées: les événements de début neutres ne sont employés que si le processus est démarré par l’appel du niveau supérieur, un processus a au moins un événement de début, plusieurs événements de début sont immédiatement réunis par la passerelle qui convient, et les événements de début sont représentés à l’intérieur d’un pool. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 7: indiquer les états finaux de succès et d’exception d’un processus ou d’un sous-processus par des événements de fin distincts étiquetés de l’état final; l’attention portée aux états finaux des activités et du processus distingue l’approche Method and Style plus que toute autre caractéristique; la plupart des modélisateurs emploient un événement de fin unique quel que soit l’état final, ce qui dissimule une information de valeur et rend plus difficile le suivi de la logique du processus depuis le niveau supérieur dans un modèle hiérarchique. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle 14, et chapitre 11, règle de style 15: deux événements de fin d’un même niveau de processus ne portent pas le même nom; s’ils représentent le même état final, les combiner en un seul, sinon leur donner des noms distincts. La règle de style 11 du chapitre 11 demande qu’un événement de fin soit étiqueté du nom de l’état final. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §9.3 « Pool and Participant »: le pool comme représentation graphique d’un participant à une collaboration, ce participant pouvant être une entité partenaire précise ou un rôle partenaire plus général; le pool tracé en rectangle à angles droits d’un trait plein unique; l’étiquette du pool admise à n’importe quel emplacement et dans n’importe quelle direction à l’intérieur du pool, à condition d’être séparée de son contenu par un trait unique, cette séparation tombant pour un pool boîte noire; un seul pool d’un diagramme admis sans bordure; le pool comme conteneur des flux de séquence entre les activités du processus qu’il contient, ces flux traversant les frontières entre couloirs sans traverser celles du pool, le processus étant entièrement contenu dans le pool et l’interaction entre pools passant par les flux de message. ↩︎ ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 6: étiqueter les pools de processus du nom d’un processus et les pools boîte noire d’un rôle de participant ou d’une entité métier; l’élément sémantique référencé par une forme de pool est un participant, associé à au plus un processus, de sorte qu’un pool représente à la fois un participant et un processus; l’identifiant unique d’un élément sémantique étant son attribut
id, invisible au diagramme, tandis que l’étiquette rend lename, un modèle ne doit jamais comporter deux pools de même nom désignant secrètement des entités distinctes; l’observation que la spécification BPMN 2.0 elle-même encourage l’étiquetage d’un pool de processus par le nom d’une organisation ou d’un rôle. La règle 17 du même chapitre étend le raisonnement au pool éventuellement dessiné autour de l’expansion d’un sous-processus, qui porte le nom du processus de niveau supérieur. ↩︎eCH-0158 version 1.2, §3.3 « Pool »: les processus sont modélisés dans des pools ouverts, les pools fermés ne contenant aucun élément et servant à représenter les participants; les pools désignent des participants à une collaboration, qui peuvent être des unités d’organisation, des participants au processus au sens de rôle ou d’autres processus; les unités d’organisation et les participants sont désignés par un substantif, les processus par un substantif antéposé et un verbe à l’infinitif; en règle générale, seul le pool propre est représenté ouvert; chaque pool ne figure qu’une fois par diagramme; l’étiquette d’un pool ouvert est pivotée de 90 degrés vers la gauche; dans chaque pool ouvert est modélisé exactement un processus complet; les pools sont représentés empilés sur toute la largeur du diagramme; la hauteur d’un pool ouvert suit son contenu; un pool fermé porte au moins un flux de message entrant ou sortant. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎ ↩︎
eCH-0158 version 1.2, §3.4 « Lane »: les couloirs représentent des rôles et des responsabilités à l’intérieur d’un processus et peuvent être imbriqués; ils sont le plus souvent étiquetés d’une désignation de rôle au singulier; un couloir ne peut pas porter le même nom qu’un pool; les étiquettes des couloirs sont pivotées de 90 degrés vers la gauche; les couloirs sont représentés empilés sur toute la largeur du pool; la hauteur d’un couloir suit son contenu; l’imbrication est représentée sur trois niveaux au maximum. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 5: modéliser si possible les unités d’organisation internes comme des couloirs d’un pool de processus unique, des pools séparés impliquant des processus indépendants; représenter chaque unité qui exécute des activités du processus par un pool distinct est généralement incorrect, puisque cela affirme que le processus de chaque unité est indépendant des autres au lieu d’être un fragment d’un processus unique de bout en bout; l’impossibilité de le faire tient d’ordinaire à une absence d’alignement des instances entre unités, l’exemple étant une facturation fondée sur des relevés mensuels en regard d’un traitement par commande, cas où deux pools communiquant par un magasin de données partagé conviennent. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 3: employer un pool boîte noire pour le client ou tout autre demandeur ou fournisseur de service extérieur; insérer des activités dans le pool du client est une erreur fréquente du débutant, puisque la logique du processus du client est inconnue, que l’échange ne s’arrête pas à la soumission de la commande et qu’un flux de message ne peut pas se connecter à la frontière d’un pool de processus. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 11, règles officielles 38 et 39, la règle 37 voisine voulant par ailleurs qu’un processus contienne au moins une activité: un processus contient au moins une activité; les éléments d’au plus un processus figurent dans un pool unique; un pool n’en contient pas un autre, et si l’expansion d’un sous-processus de niveau enfant est enfermée dans un pool, ce pool référence le même participant et le même processus associé que le niveau parent. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §7.6.1 « Sequence Flow Connections Rules »: le tableau 7.3 des connexions autorisées entre objets de flux, avec la note précisant que les objets contenus dans un sous-processus développé à l’intérieur d’un diagramme ne peuvent pas être connectés à des objets situés en dehors de ce sous-processus, et qu’un flux de séquence ne peut pas traverser la frontière d’un pool; le pool, le couloir, l’objet de données, le groupe et l’annotation textuelle sont absents du tableau. Voir aussi §8.4.13 « Sequence Flow », qui exige que la source et la cible d’un flux de séquence appartiennent aux événements, aux activités, aux activités de chorégraphie et aux passerelles. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §7.6.2 « Message Flow Connection Rules »: le tableau 7.4 des connexions autorisées par flux de message à l’intérieur d’un diagramme de collaboration, avec la note précisant que les flux de message ne peuvent pas se connecter à des objets qui sont dans le même pool. ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règles 21 à 25, et chapitre 11, règles officielles 4, 5 et 9: un flux de séquence ne traverse pas la frontière d’un pool ni celle d’un sous-processus, tous les flux de séquence de l’expansion enfant devant être entièrement contenus dans la forme du sous-processus; un flux de message ne relie pas deux nœuds du même pool, un message BPMN étant par définition échangé entre le processus et une entité extérieure, de sorte qu’un courriel entre deux tâches d’un même processus n’en est pas un; un flux de séquence ne se connecte qu’à une activité, une passerelle ou un événement, ses deux extrémités devant être connectées; un flux de message ne se connecte qu’à une activité, à un événement de message ou multiple ou à un pool boîte noire. ↩︎
eCH-0158 version 1.2, §3.9 « Flux de message »: les déroulements métier avec des participants extérieurs, représentés en pools séparés, sont figurés par des flux de message, déclenchés par des activités, une activité pouvant déclencher plusieurs flux sortants; le flux de message peut être étiqueté de la description de l’information, avec l’exemple « Commande », ou du support de la transmission, avec l’exemple « Courriel »; les flux de message se connectent sur le côté supérieur ou inférieur des éléments; ils ne se superposent pas; les désignations se placent entre les pools; un flux de message représenté à un niveau de processus inférieur n’est pas répété aux niveaux supérieurs, sauf redondance choisie pour la compréhension, à charge d’en répercuter les changements. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 13, et chapitre 11, règle de style 19: étiqueter le flux de message directement du nom du message, du type Rejection notice, à l’exclusion d’un nom d’état comme Rejected ou d’une action d’envoi comme Send rejection; laisser le flux de message sans étiquette en identifiant le message par un objet de données associé est incorrect, un objet de données ne pouvant pas être associé à un flux de message en BPMN 2.0. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 11, règles de style 12 et 13: une passerelle exclusive de division comporte au plus une sortie sans étiquette; une passerelle exclusive ou inclusive de division est étiquetée dès que l’une de ses sorties ne l’est pas. La règle de style 1 du chapitre 6 demande d’étiqueter toutes les activités, les états finaux, les flux de séquence issus d’une passerelle exclusive, les pools et les flux de message, et de recourir à une annotation textuelle lorsqu’un aspect de la logique ne peut pas être transmis sans ambiguïté par les seuls éléments BPMN. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 10, et chapitre 11, règle de style 16: lorsqu’un sous-processus est suivi d’une passerelle étiquetée d’une question, ce sous-processus porte plusieurs événements de fin dont l’un reprend l’étiquette de la passerelle; autrement dit, la passerelle est étiquetée « [état final 1] ? » et ses sorties « oui » et « non », les instances atteignant l’état final 1 empruntant la sortie « oui ». La règle sert la traçabilité descendante de la logique à travers la hiérarchie des diagrammes. ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §3.2.1 « Exclusive Decisions »: annoter chaque flux de séquence sortant d’une division exclusive d’une étiquette portant la condition à laquelle cette branche est empruntée, et employer toujours des conditions mutuellement exclusives, une seule pouvant être vraie chaque fois qu’un jeton atteint la division; le flux par défaut, marqué d’un trait oblique, a le sens de sinon et peut rester sans étiquette, les auteurs choisissant néanmoins de l’étiqueter pour la lisibilité; la clause se termine sur le conseil de toujours achever un modèle par un événement de fin, même lorsque la façon dont le processus s’achève est évidente. ↩︎
eCH-0158 version 1.2, §3.7 « Gateways » et §3.8 « Flux de séquence »: les passerelles de division ne sont étiquetées que si cela améliore la teneur informative du diagramme; les passerelles de fusion, les passerelles événementielles et les passerelles parallèles ne sont pas étiquetées; la désignation d’une passerelle est un attribut optionnel. Côté flux, les flux de séquence ne sont par principe pas étiquetés, à une exception près: les flux issus d’une passerelle exclusive ou inclusive doivent être étiquetés de la décision correspondante ou des états finaux du sous-processus qui précède immédiatement. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.6.2 « Exclusive Gateway »: le marqueur en forme de X placé dans le losange est facultatif, et un diagramme devrait être constant dans son usage, sans mêler des passerelles avec indicateur et des passerelles sans; la note ajoutant que les exemples du document lui-même sont dessinés sans l’indicateur interne. La même clause décrit la division exclusive comme une question posée en un point du processus, dont l’ensemble des réponses possibles est défini, chaque réponse étant associée à une expression de condition portée par un flux sortant. ↩︎
eCH-0158 version 1.2, §3.7 « Gateways », conventions de modélisation: une activité est obligatoire avant une passerelle exclusive ou inclusive, et cette activité détermine l’embranchement sur la base d’une règle de gestion; première exception, la passerelle événementielle; seconde exception, des passerelles peuvent se suivre, à l’exclusion de deux passerelles événementielles et de deux passerelles parallèles, avec la mise en garde que la lisibilité en souffre et le renvoi au §2.4. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
eCH-0158 version 1.2, §3.8 « Flux de séquence », conventions de modélisation: les activités et les événements sont reliés horizontalement par des flux de séquence, les retours en arrière et les croisements étant à éviter, les passerelles admettant en outre une connexion par le haut ou par le bas; les divisions de flux de séquence issues d’une activité passent par une passerelle plutôt que directement; les flux de séquence ne se superposent pas, sauf pour des flux de même sens sur une passerelle portant plus de quatre flux entrants ou sortants, et pour des flux entrants sur une activité en portant plus de deux. La règle voisine de §3.6 veut qu’une activité soit suivie d’exactement un flux de séquence. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎ ↩︎
eCH-0158 version 1.2, §2.4 « Règles de gestion »: lorsque plus de deux passerelles exclusives ou inclusives se suivent dans la représentation d’un déroulement, il s’agit le plus souvent d’une règle de gestion; il convient alors de la représenter d’une autre manière appropriée, en DMN, en prose, en SBVR ou en liste de contrôle, et de remplacer la suite de passerelles par une activité portant la description correspondante. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §5.4.1 « Syntactic Quality and Verification »: la structure en bloc définie comme un fragment de modèle à entrée unique et sortie unique dont les points d’entrée et de sortie sont deux passerelles, une division et une fusion, chaque chemin de l’une menant à l’autre; l’absence d’anomalie de comportement lorsque les deux passerelles sont de même type et l’apparition d’anomalies lorsqu’elles diffèrent; les anomalies elles-mêmes, l’interblocage, la boucle infinie, le défaut de synchronisation qui met deux jetons ou plus sur le même flux de séquence faute de synchronisation à une fusion, et l’activité morte; la remarque que ces anomalies peuvent aussi surgir en dehors des structures en bloc, où elles sont plus difficiles à repérer. ↩︎
eCH-0158 version 1.2, §3.7 « Gateways », conventions de modélisation: la fusion des flux de séquence divisés est obligatoire et s’effectue sur la même ligne horizontale que la division; première exception, un flux divisé après une passerelle exclusive ou événementielle rencontre un événement de fin avant la fusion; seconde exception, le flux fait partie d’une boucle de contrôle et retourne au début de l’activité de contrôle lorsque la condition n’est pas remplie. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 9 « Process Splitting and Merging », section « Merging Alternative Paths », et chapitre 6, règles de style 19 et 20: si les chemins à fusionner sont des alternatives exclusives, les fusionner directement, ce qui se reconnaît en remontant à leur division, une passerelle exclusive, une passerelle événementielle ou un événement de bord interruptif; une passerelle exclusive employée comme fusion équivaut à l’absence de passerelle, puisqu’elle laisse simplement passer chaque flux entrant à son arrivée, ce qui la rend redondante pour fusionner vers une activité; elle garde son utilité pour fusionner vers une autre passerelle, dont le comportement avec plusieurs entrées et plusieurs sorties serait ambigu à la lecture; enfin la règle 20, aucune fusion parallèle vers un événement de fin neutre, une fusion y étant toujours implicite. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §7.6 « Flow Object Connection Rules »: un flux de séquence entrant comme sortant peut se connecter sur n’importe quel côté d’un objet de flux, un flux de message également, avec la note recommandant de choisir une direction unique pour les flux de séquence, de gauche à droite ou de haut en bas, puis de diriger les flux de message à 90 degrés, ce qui rend les diagrammes bien plus faciles à comprendre. ↩︎
eCH-0158 version 1.2, §2.3.1 « Direction de modélisation »: conformément au flux de séquence traité au chapitre 3.8, les modèles sont à modéliser de gauche à droite. La convention est reprise en §3.2 parmi les conventions de modélisation du diagramme. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
eCH-0158 version 1.2, §3.2 « Diagramme »: le diagramme décrit intégralement le processus du point de vue de l’unité qui modélise; format paysage, A3 au maximum; les diagrammes contiennent des symétries graphiques et la structure du déroulement y est visible; les éléments des participants extérieurs, hors de la sphère d’influence propre, ne sont représentés que s’ils sont indispensables à la compréhension du travail propre, sans que l’exhaustivité et la justesse du déroulement du participant extérieur aient à être assurées; modéliser de gauche à droite; de neuf à quinze activités au maximum par diagramme. La clause énumère par ailleurs les attributs, la désignation étant requise, l’état IST ou SOLL, le propriétaire du processus, la prestation fournie, l’auteur, le statut et la classification étant optionnels. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 6, règle de style 2: rendre les modèles hiérarchiques en faisant tenir chaque niveau de processus sur une page; le diagramme de niveau supérieur porte le processus de bout en bout sur une page et montre ses interactions avec les entités extérieures au moyen de flux de message; chaque sous-processus d’un niveau est développé dans un diagramme enfant distinct, l’imbrication pouvant descendre aussi profond que voulu; avec la modélisation hiérarchique, l’ajout de détail au niveau enfant ne demande aucun changement aux diagrammes parents. ↩︎
eCH-0158 version 1.2, §2.3.2 « Taille »: tous les éléments BPMN sont à tenir dans la même taille et la même forme par type d’élément, l’exemple donné étant que toutes les activités sont de la même taille. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
eCH-0158 version 1.2, §2.3.3 « Couleur »: les couleurs sont par principe à éviter, ce qui accroît l’uniformité et donc la comparabilité des diagrammes, réduit les barrières liées aux déficiences de la vision des couleurs et assure une représentation correcte sur les impressions en noir et blanc; lorsque la lisibilité y gagne, des couleurs peuvent être attribuées avec retenue aux types d’éléments ou à des éléments particuliers selon un concept de couleur clair. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §5.4.3 « Pragmatic Quality and Certification »: la qualité pragmatique porte sur l’utilisabilité du modèle, avec la compréhensibilité, la maintenabilité et l’apprentissage comme aspects, et la taille, la complexité structurelle et la mise en page graphique comme caractéristiques qui l’influencent; le premier des deux contrôles de compréhensibilité porte sur la cohérence entre structure visuelle et structure logique, obtenue par une disposition des éléments du haut à gauche vers le bas à droite et par l’absence d’arcs croisés, la mise en blocs y contribuant également; un modèle structuré, outre qu’il est toujours solide, s’est montré souvent plus facile à comprendre que son équivalent non structuré. ↩︎
eCH-0158 version 1.2, §2.1 « Conventions de numérotation »: les systèmes de numérotation servent l’identification univoque des processus et des activités dans les grandes organisations; intégrer d’autres caractéristiques dans un identifiant univoque, sigle d’organisation ou type de processus, devient problématique quand ces caractéristiques changent; les systèmes hiérarchiques, où chaque niveau est séparé du précédent par un point, sont appréciés mais entraînent de vastes renumérotations quand la structure ou l’ordre des processus change, et deviennent très longs dans les grandes organisations; au besoin, les processus reçoivent donc à l’échelle du système de processus de l’organisation un numéro univoque, invariable et continu, les vues différentes d’un même processus pouvant être séparées par un point, l’attribution des numéros étant réglée centralement; pour les activités, il convient idéalement de renoncer à toute numérotation. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §13.2 « Process Instantiation and Termination »: chaque événement de début qui survient crée un jeton sur ses flux de séquence sortants; une instance de processus est achevée si et seulement si les événements consécutifs à une éventuelle passerelle parallèle instanciante sont tous survenus, qu’aucun jeton ne subsiste dans l’instance et qu’aucune activité du processus n’est encore active; pour qu’une instance s’achève, tous ses jetons doivent atteindre un nœud terminal, c’est-à-dire un nœud sans flux de séquence sortant; un jeton atteignant un événement de fin déclenche le comportement associé au type de l’événement, et un jeton atteignant un événement de fin de terminaison met fin anormalement au processus entier. ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §5.4.1 « Syntactic Quality and Verification »: les règles structurelles au niveau des éléments, dont l’obligation faite aux activités d’avoir au moins un flux entrant et un flux sortant, l’interdiction des flux entrants sur un événement de début et des flux sortants sur un événement de fin, l’exigence faite à une division d’avoir exactement un flux entrant et au moins deux sortants et à une fusion d’avoir au moins deux flux entrants et exactement un sortant, enfin l’obligation faite aux arcs sortants d’une division exclusive ou inclusive de porter des conditions; la règle structurelle au niveau du modèle, tout nœud de flux se trouve sur un chemin allant d’un événement de début à un événement de fin; les anomalies de comportement, interblocage, boucle infinie, défaut de synchronisation et activité morte; enfin la définition de la solidité par trois propriétés, la possibilité d’achèvement, l’achèvement propre où chaque jeton se trouve au moment de l’achèvement sur un événement de fin distinct, et l’absence d’activité morte. ↩︎
eCH-0158 version 1.2, §3.5.3 « Événement de fin »: les événements de fin sont étiquetés du statut de la prestation fournie, avec les exemples « Rapport établi » et « Commande erronée », statut qui peut servir d’événement de début à un autre processus; la convention de modélisation associée tient en une phrase, chaque branche du processus mène à un événement de fin. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.6.1 « Sequence Flow Considerations »: une passerelle peut être la cible d’un flux de séquence et en porter zéro, un ou plusieurs; elle peut en être la source aux mêmes conditions; elle doit comporter soit plusieurs flux de séquence entrants, soit plusieurs flux de séquence sortants, c’est-à-dire fusionner ou diviser le flux; une passerelle dont l’attribut
gatewayDirectionvaut converging comporte plusieurs flux entrants sans porter plusieurs flux sortants, l’inverse valant pour diverging, tandis que mixed exige les deux pluriels. ↩︎OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.6 « Gateways »: les passerelles contrôlent la façon dont les flux de séquence convergent et divergent, et une passerelle n’est pas nécessaire là où le flux n’a pas à être contrôlé; la passerelle est un losange qui doit être tracé d’un trait fin unique; les passerelles peuvent consommer ou produire des jetons, à la différence près qu’elles ne représentent aucun travail accompli et sont considérées comme sans effet sur les mesures opérationnelles du processus exécuté, coût, durée et autres; chaque type de passerelle porte un marqueur interne indiquant son type; la clause note enfin qu’une même passerelle peut porter plusieurs entrées et plusieurs sorties, et que modélisateurs comme outils peuvent souhaiter imposer la bonne pratique d’une passerelle n’assurant qu’une des deux fonctions, deux passerelles successives servant alors à fusionner puis à diviser. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 11, règles officielles 33 à 36: une passerelle ne porte ni flux de message entrant ni flux de message sortant; une passerelle de division comporte plus d’une sortie; les sorties d’une passerelle événementielle ne comportent que des événements intermédiaires en capture ou des tâches de réception. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §13.3.1 « Sequence Flow Considerations »: une activité cible de plusieurs flux de séquence participe au flux non contrôlé, ce qui signifie que pour chaque jeton arrivant sur l’un des flux entrants la tâche est activée indépendamment de l’arrivée de jetons sur les autres, la présence de plusieurs flux entrants se comportant comme une passerelle exclusive; si le flux de jetons doit être contrôlé, des passerelles d’un type autre qu’exclusif sont à inclure explicitement avant la tâche pour lever toute ambiguïté sémantique; symétriquement, plusieurs flux sortants d’une activité se comportent comme une division parallèle, et plusieurs flux sortants conditionnels comme une division inclusive. Le terme lui-même est défini au tableau 7.2 de §7.3.2 « Extended BPMN Modeling Elements », le flux non contrôlé étant celui qui n’est affecté par aucune condition ou ne passe par aucune passerelle. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 9, sections « AND Gateway Join » et « Multi-Merge »: si les chemins sont inconditionnellement parallèles, on veut d’ordinaire les réunir par une passerelle parallèle portant plusieurs flux entrants et un seul sortant, qui attend l’arrivée de tous les flux entrants; la passerelle est facultative pour la division et à conserver pour la fusion, la spécification admettant techniquement son omission sous le nom de multi-merge, lequel déclenche l’activité suivante une fois par flux entrant, ainsi que toutes les activités en aval; une passerelle exclusive employée comme fusion laisse passer chaque flux à son arrivée, exactement comme l’absence de passerelle, de sorte qu’avec des entrées parallèles elle signifie elle aussi un multi-merge; l’auteur recommande d’éviter cette construction, qui n’est presque jamais ce que le modélisateur veut dire. Une fusion reste inutile vers un événement de fin neutre, où elle est implicite. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §13.4.3 « Inclusive Gateway », tableau 13.3: la condition d’activation exprimée sur les chemins dirigés, qui revient à attendre les branches entrantes qu’un jeton en circulation peut encore atteindre. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, chapitre 9, section « OR Gateway Join »: si certains des chemins parallèles à réunir sont conditionnels, donc pas activés dans chaque instance, la fusion se fait par une passerelle inclusive, qui se comporte comme une fusion parallèle en ignorant les flux entrants non activés pour l’instance en cours; les trois cas de figure donnés sont la fusion de flux de séquence conditionnels, la fusion d’une division parallèle inconditionnelle dont deux sorties seulement peuvent aboutir dans une instance donnée, et la fusion du chemin d’exception d’un événement de bord non interruptif avec le chemin normal, ces deux flux étant conditionnellement parallèles. ↩︎
eCH-0074 version 2.2, Principes de modélisation graphique des processus métier, §2.2.8 « Principe de règles et de conformité à la méthode »: les processus d’une unité administrative sont à modéliser de manière uniforme et à documenter systématiquement; les états de traitement et de validation des modèles doivent pouvoir être documentés par des concepts d’approbation; les conventions de modélisation nécessaires à une représentation uniforme sont à consigner dans un règlement BPMN interne à l’organisation, par exemple les conventions de nommage des activités, règlement qui doit aussi définir quelles caractéristiques de prestation ou de processus sont à saisir et comment le processus de validation des descriptions est organisé, avec renvoi aux conventions de modélisation BPMN de eCH-0158. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0074/2.2 ↩︎