BPMN, la norme du BPM

1. Introduction – BPMN ?

BPMN (Business Process Model Notation) est une norme de notation pour la modélisation de processus. BPMN est soutenu par l'OMG/BMPI (Object Management Group/ Business Process Management Initiative) depuis leur fusion en 2005.

Son objectif est de fournir un cadre permettant de décrire un processus d'une manière commune à tous les utilisateurs et ce, indépendamment de l'outil utilisé. L'outil étant bien sûr censé supporter la norme.

Le but de l'OMG dans la définition de BPMN était d'être simple et c'est pourquoi il n'existe que 3 objets de base : les tâches, les évènements et les branchements. Ces objets font partie de la catégorie objets de flux.

3 autres catégories existent :

- les objets de connexion contenant les enchainements d'activité, les messages et les associations

- les couloirs (swimlanes) contenant les lignes et les groupements

- les artefacts contenant les objets de données, les groupes et les annotations.

Mais simple ne veut pas dire simpliste, BPMN définit des sous-types pour chacun des objets et rend donc possible la description de processus de manière détaillée.

Les objets structurants sont les groupements qui servent à définir les frontières d'un processus. Cela a 2 conséquences :

- un enchainement d'activité ne peut pas se faire entre 2 groupements

- un message ne peut être qu'entre 2 groupements.

Un diagramme peut donc contenir plusieurs groupements différents.

Les groupements peuvent être découpés en ligne. Ces lignes peuvent représenter des rôles ou le service d'une entreprise. L'utilisation des lignes est libre et ne répond à aucune contrainte de la part de la norme. Les enchainements d'activités sont utilisés librement entre les lignes.

2. Avancement de la norme et présence dans les outils de modélisation

Actuellement la version 1.1 est sur le point d'être rendue publique et, à ce jour, BPMN est la norme de notation la plus utilisée. Les travaux sur la version 2.0 ont d'ores et déjà commencé mais aboutiront d'ici 1 à 2 ans.

Mais bien qu'étant la plus utilisée, son intégration dans les outils de modélisation est inégale. Certains outils ne l'intègrent pas du tout. D'autres ont affiché le support de BPMN mais ne supporte pas correctement la norme et dans certains cas il arrive même que l'intégration soit en opposition avec la norme. Enfin, et heureusement, une dernière catégorie d'outil supporte BPMN correctement.

Un point à prendre en compte : la norme ne définit pas l'apparence graphique d'un processus. Ainsi il est tout à fait possible de modéliser un processus en BPMN dans un outil A, d'arriver à le transférer dans un outil B et que ce processus n'ait pas le même aspect (icône, couleur).

Ce problème de rendu sera certainement corrigé dans une version future.

Aujourd'hui, plus de 43 outils de BPM (Business Process Management) revendiquent le support de BPMN, ce qui représente une très large proportion des outils de BPM.

3. BPMN, qu'est ce que c'est exactement ?

3.1 - Le découpage de processus

La norme BPMN définit 2 concepts pour organiser les processus :

- les orchestrations

- les chorégraphies.

Les orchestrations sont internes, elles définissent ce qui se passe à l'intérieur d'un groupement. Les chorégraphies sont interprocessus, elles définissent les communications entre groupements (entre processus).

Les échanges internes à un processus BPMN sont effectués au travers d'enchaînements d'activités. Ils signifient qu'un enchainement entre les différentes tâches du processus est effectué. Les échanges entre les processus sont eux représentés par des messages et répondent au nom de chorégraphie.

Le découpage hiérarchique s'effectue par l'intermédiaire de tâche que l'utilisateur désigne comme élément à détailler. La tâche servira donc également d'interface entre les 2 processus. Comme dans l'utilisation de notations propriétaires, cela permettra de décharger un modèle ou de faire abstraction d'un fonctionnement non connu au moment de la modélisation.

A noter, la présence d'un modèle dans la norme permettant de faire une description sous forme de liste de tâche ad hoc. Ce modèle n'est pas très utilisé mais il permet de mettre côte à côte des tâches sans pour autant les relier entre elles (inventaire). Pour dérouler ce sous-processus, aucun ordre particulier n'est requis entre les tâches et toutes les tâches ne doivent pas être déroulées.

3.2 - Les types d'objets

Les tâches

Une tâche est un élément indivisible. Elle représente une action. Chaque tâche a un début et une fin et donc une tâche ne peut débuter que si la tâche précédente est terminée.

Une tâche à un type permettant de préciser son fonctionnement :

- un service

- un envoi

- une réception

- une tâche utilisateur

- un script

- une tâche manuelle

- une tâche référence

- aucun de tous ces choix.

Un sous processus est une tâche qui est décomposée. Elle est représentée par une tâche avec un petit + permettant d'accéder au détail. Un double clic sur une tâche ayant le signe + permet d'ouvrir le modèle détaillé de la tâche.

C'est la manière dans BPMN de définir des abstractions et de choisir la granularité de l'information représentée. Cela peut aussi être utilisé comme élément de base pour représenter des services de type SOA (Services Oriented Architecture) ou pour définir un contexte de traitement pour la gestion des exceptions.

Les branchements

Le branchement est un objet essentiel dans la norme BPMN. Il sert à représenter la condition de routage entre le(s) flux en entrée et le(s) flux en sortie. Le branchement n'est pas une tâche et n'effectue aucune action. Lorsque le losange est vide, chaque sortie est une alternative et il n'y a pas de différenciation entre les sorties. Le losange vide est utilisé lorsque le niveau d'abstraction du modèle est élevé et que l'on ne désire pas compliquer une vue ou bien lorsque la règle de traitement n'est pas connue.

Il est donc possible de définir un comportement de traitement précis.

Les branchements sont autant utilisés pour diviser un flux en plusieurs flux que pour réunir plusieurs flux en un seul.

Les différents branchements possibles dans BPMN 1.1 sont :

- les branchements exclusifs

- les branchements parallèles

- les branchements conditionnels

- les branchements de synchronisation.

Le symbole à l'intérieur du losange sert à identifier le comportement du branchement.

Si le branchement contient un lien entrant et plusieurs liens sortants, il s'agira d'une décision. Dans le cas contraire il s'agira d'une jointure.

Par défaut, une branche est indiquée par un petit trait barrant la flèche. Il permet de donner la marche à suivre si jamais la condition n'est jamais vraie.

L'utilisation des branchements doit être réfléchie pour ne laisser aucune ambigüité dans le modèle c'est pourquoi, sur un modèle, l'arrivée ou le départ de plus d'un flux doit passer par un branchement et ne pas être directement relié à une tâche.

Par exemple si vous utilisez un branchement conditionnel pour indiquer que l'un, l'autre ou les 2 branches sont exécutées, vous devez à un moment donné faire rejoindre les flux avec le même branchement (et non pas un branchement de synchronisation, signifiant que les 2 flux sont obligatoirement nécessaires).

L'utilisation d'un branchement conditionnel posera des problèmes lors de la conversion BPEL : la transformation ne permet pas de définir en langage exécutable cette représentation. Elle demandera une correction/adaptation.

Dans BPMN 1.1, l'utilisation de la décision complexe permet de représenter le fait que le premier flux arrivé est accepté et équivaut donc à un Ou exclusif.

L'utilisation des branchements est un peu délicate au début mais permet de décrire très précisément un processus. Il faut bien garder à l'esprit qu'un branchement n'effectue aucune tâche, c'est juste un lieu où une décision est prise en fonction du flux d'entrée. La bonne pratique consiste donc à éviter de faire comme si le branchement est une tâche de contrôle.

Les objets de connexion

Il existe 3 types de connexions possibles.

Les messages, représentés par un trait en pointillés, servent à décrire les échanges entre processus.

Les messages représentent un lien entre des processus. Ils ne sont qu'un signal entre 2 processus et ne déclenchent rien de particulier.

Le seul cas où un message a un effet sur un processus est lorsqu'un évènement du processus qui reçoit quelque chose attend ce message, il sera alors attrapé par l'évènement déclencheur.

Les enchainements d'activité, trait plein, représentent le flux entre 2 tâches.

Les associations servent comme support de rattachement entre une tâche et un objet de données ou avec une activité de compensation. Elles sont représentées par un trait en pointillé.

Les évènements

Les évènements servent à identifier un état particulier dans le processus. Ils n'effectuent aucune tâche. Dans BPMN 1.0 il existe 3 types d'évènements :

- début

- intermédiaire

- fin

Les évènements de début et de fin doivent toujours être présents sur un processus BPMN. Ils sont le squelette du processus.

De même lorsqu'une tâche débouche sur une exception, l'évènement de fin doit aussi être représenté pour le cas où la tâche se déroule normalement.

BPMN 1.1 sépare en 2 catégories les évènements :

- les évènements d'attente symbolisés par un fond blanc

- les évènements de lancement sur fond noir

Les premiers donnent le type d'évènement que le processus est en mesure de traiter alors que le deuxième définit le type d'évènement en sortie du processus.

Un nouvel évènement fait son apparition : Signal. C'est un évènement générique pour représenter un flux, il doit porter à lui tout seul l'ensemble des possibilités d'envoi/réception.

Dans les modifications mineures, le symbole de l'évènement multiple a légèrement été modifié.

Les outils n'encadrent pas strictement l'utilisation des évènements, il conviendra donc de définir dans la convention de modélisation les évènements à utiliser ainsi que la manière de les utiliser.

La description suivante bien que correspondante à la version 1.0 de BPMN permet surtout de comprendre l'utilisation des évènements au niveau méthodologique. Leurs utilisation avec BPMN 1.1 sera donc différente puisque la distinction début/ intermédiaire/ fin sera légèrement différente : début et intermédiaire est équivalent à « Attente », intermédiaire et fin est équivalent à « Lancement ».

L'évènement de début est représenté par un cercle fin.

Il indique le point de départ et ne symbolise aucune tâche. Il peut recevoir un évènement de départ.

L'évènement intermédiaire est symbolisé par un double trait. C'est une partie importante de BPMN.

Il peut être utilisé de 2 manières : au milieu d'un flux pour signaler l'attente d'un type d'évènement ou rattaché à une tâche pour faire apparaître une exception au traitement de la tâche.

Evènement d'attente :

Evènement d'interruption :

Si l'évènement se produit, la tâche en cours s'arrête et la tâche suivante démarre.

Les évènements intermédiaires peuvent être utilisés pour faire apparaître une étape importante dans un processus. Entre 2 tâches, un évènement intermédiaire sans aucun type particulier (cercle vide), il signale qu'une étape est franchie.

Il est déconseillé d'utiliser les évènements intermédiaires comme source de messages (les messages doivent être envoyés depuis une tâche) car c'est une source d'ambigüité.

Le support des évènements intermédiaires est un élément discriminant pour sélectionner un outil annonçant le support de BPMN. La plupart du temps l'outil qui ne supporte pas les évènements intermédiaires ne le fait pas à cause de l'interface avec un outil d'exécution qui lui-même ne supporte pas ce type d'objets.

L'évènement de sortie est représenté par un cercle épais.

Il indique la fin du processus et ne symbolise aucune tâche. Il peut envoyer un évènement de sortie.

Les types d'évènement de sortie les plus importants sont :

- l'évènement de fin simple : aucune indication particulière n'est donnée.

- l'évènement de type erreur : signale une erreur dans le processus et interrompt le processus ou le sous-processus en cours. Pour être correctement utilisé ce type d'évènement doit être traité au niveau supérieur du processus impliqué, c'est-à-dire que la résolution de l'évènement doit se faire dans le processus appelant. Un évènement servant à traiter l'ensemble des erreurs doit permettre au processus de niveau supérieur de récupérer les erreurs. C'est une vision quelque peu teintée par l'aspect exécution mais elle force à réfléchir de manière pragmatique sur le traitement des erreurs.

- l'évènement d'annulation : signale la fin du processus et annule les transactions en cours.

- l'évènement de compensation : signale qu'une tâche doit être annulée. Ce type d'évènement est utilisé dans les processus transactionnels et permet de définir la tâche qui doit être utilisée pour compenser une tâche particulière.

- l'évènement de terminaison : il ordonne la fin du sous-processus et de l'ensemble des tâches en cours qui le compose (même s'il existe des boucles). C'est donc là aussi une vision orientée exécution mais qui pourra être cependant utile dans le cadre d'une description métier précise au niveau le plus fin.

Les évènements de type « lien » permettent de découper un processus en plusieurs parties. Les objets liens pourront être attachés 1 à 1. Cela permet d'éviter de surcharger un processus.

Les activités de répétition

La boucle (équivalent du while en programmation) définit une tâche qui se répète tant qu'une condition n'est pas remplie. La condition est examinée à chaque boucle.

La tâche à instance multiple (MI) permet de représenter plusieurs exécutions de l'activité (équivalent du ForEach) en parallèle. Toutes les instances doivent se terminer pour que l'activité soit terminée.

Ex : Vérification de plusieurs chaines de production

3.3 - Les transactions

L'utilisation des évènements de compensation permet de d'assurer le support des transactions dans BPMN (commit-rollback). Il est donc possible de définir pour chaque activité, une activité de compensation. Les activités de compensation sont des tâches uniques, elles ne débouchent sur rien. La représentation permet de définir le comportement du processus si jamais la tâche en cours doit être annulée.

Ce type de tâche est couramment utilisé dans les contextes où une transaction a lieu : virement bancaire : si le débit du compte A réussit et que le compte B ne reçoit pas les fond, annuler le débit du compte A.

3.4 - Les attributs

Les attributs dans BPMN sont définis par la norme et ils concernent la représentation du processus. Cependant certains outils permettent de définir plus d'attributs (soit des attributs outils, soit des attributs personnalisés) que ceux proposés par défaut. Il y a une conséquence à cela : ces attributs seront perdus si vous changez d'outil de modélisation et ils ne seront pas utilisés dans l'outil d'exécution. L'exception est le cas où l'outil de modélisation possède une interface propre avec l'outil d'exécution, mais dans ce cas, peut-on encore parler de normes ?

La plupart du temps les attributs servent à décrire le processus en vue d'une conversion en BPEL (Business Process Execution Language), langage permettant d'exécuter dans un outil de Workflow (BPM) les processus modélisés.

Les objets de description complémentaires rattachés avec un lien d'association ne possèdent aucune utilité lors de l'exécution BPEL.

3.5 - BPMN et simulation

Même si la spécification de BPMN n'utilise pas explicitement le mot simulation (ou animation), cette fonctionnalité est devenue incontournable dans les outils de BPM.

BPMN ne permet pas de définir les paramètres de simulation car cette fonction dépend de l'outil utilisé.

Les éléments mesurés dépendent aussi de l'outil utilisé :

- permet-il de définir des indicateurs personnalisés ?

- prend-il en charge l'ensemble des objets, définir les probabilités d'occurrence ?

- les valeurs mesurées sont le minimum, maximum, temps de cycle…. ?

- comment exploiter les résultats ? sous forme de graphique, de rapport ?

BPMN se prête particulièrement au jeu de la simulation, notamment grâce aux objets définis permettant de se rapprocher d'un modèle exécutable (branchement et évènement). Un branchement pourra donc contenir avec précision les conditions d'exécution de chacune de ses branches en donnant la probabilité d'exécution de chacune de ses branches.

La plupart du temps, ce que l'on cherche à identifier une simulation est le temps de déroulement du processus. Il convient de faire le distinguo entre le temps actif et le temps d'attente. Le temps actif est le véritable temps d'exécution alors que le temps d'attente est le temps entre 2 tâches ou le temps d'attente pour qu'un évènement arrive. Ils n'auront évidemment pas le même effet sur le calcul du temps d'exécution d'un processus.

La simulation est un domaine à part entière (répartition des volumes dans le temps et disponibilité des ressources) et BPMN est un support adapté pour cela mais comme pour la modélisation, lorsqu'une simulation d'un processus est effectuée il convient de savoir pourquoi. Quel est le but de la simulation, que cherche-t-on à mesurer ?

4. Conclusion

Pour conclure cette présentation détaillée de BPMN, 2 constats :

- BPMN est la notation standard la plus adaptée pour modéliser les processus,

- et bien qu'étant presque la seule, force est de constater qu'elle n'est pas largement utilisée.

Il convient alors de se demander pourquoi !

La raison est simple. Un des grands principes de la modélisation est de toujours modéliser dans un but précis. BPMN, de par sa construction et les termes utilisés, vise un public qui n'est pas celui des business analysts ou des modélisateurs métier. Le public visé est celui qui va transformer un processus métier en processus exécutable. Dans ce domaine là, BPMN est incontournable.

Si vous souhaitez choisir un outil pour modéliser en BPMN, il y a trois critères à surveiller :

- l'outil doit supporter entièrement et correctement la norme,

- proposer des fonctions de validation des diagrammes,

- proposer un export vers un langage exécutable (BPEL).

Concernant les processus métier, et par métier j'entends processus dont on peut éditer une procédure pour des utilisateurs, BPMN est à la fois incomplet et trop détaillé.

Incomplet car les objets essentiels dans une modélisation métier manquent à l'appel : règle de gestion, organisation ou encore risque. Cela classe d'emblée BPMN comme norme plus proche de l'exécution que du métier.

Trop détaillé car l'utilisation de branchements et de messages ayant un signification précise pour le moteur d'exécution surcharge le modèle métier. Ces éléments ne sont pas utilisés voire déconseillés dans une modélisation métier (ou alors au niveau le plus bas) car ils compliquent le modèle.

Par exemple un processus modélisé avec BPMN ne pourra pas contenir les acteurs de chaque tâche (ce n'est pas compris dans la norme) et sera trop précis puisque les erreurs et leurs traitements peuvent être détaillés.

Un autre point qui doit être (et sera) amélioré sur BPMN : son méta-modèle. BPMN n'est pas très rigoureux et repose sur la manière dont il est utilisé et dont il est implémenté dans l'outil de modélisation utilisé. L'émergence d'un méta-modèle de processus métier basé sur BPDM (Business Process Definition MetaModel) résoudra ce problème et sera la garantie d'un peu plus de cohérence.

Quoi qu'il en soit, BPMN ne résoudra pas le paradoxe actuel : la modélisation universelle d'un processus n'existe pas. Si l'on souhaite modéliser une vue métier il faut modéliser suivant une méthodologie adaptée (ce que n'est pas BPMN). Si la modélisation est faite dans le but d'alimenter un moteur de Workflow, il faudra également modéliser dans ce but là (transposition du modèle métier en modèle compréhensible par un moteur de Workflow) en BPMN.

Le modèle exécutable doit-il être exécuté dans l'outil de BPA où il cohabite avec le modèle métier au sein du référentiel d'entreprise ?

L'expérience montre qu'il est plus simple de le faire directement dans l'outil d'exécution mais qu'il convient de définir des mécanismes permettant d'assurer la cohérence du modèle métier et du modèle exécutable.