E. Renaux

1) BPMN, Késako

Conçu par le BPMI (Business Process Management Initiative) en 2004, le BPMN (Business Process Modeling Notation) a été élaboré dans le but de standardiser les systèmes de notation utilisés à des fins professionnelles, et ainsi présenter les processus des entreprises d’une manière graphique. Cette modélisation est compréhensible par tout utilisateur professionnel quel que soit son profil : de l’analyste métier chargé de concevoir la première ébauche d’avant projet en processus, jusqu’au développeur technique responsable de l’implémentation de la technologie adaptée au projet, et enfin le manager veillant à mettre en place ces processus.

En effet, le BPMN crée une relation standardisée entre l’architecture des processus métier et l’implémentation de ces derniers. On entend par là la présentation  d’un diagramme de processus basé sur la création d’un modèle graphique schématisant les processus. Tout modèle serait donc un ensemble d’activités représentées par des objets graphiques dont l’ordre d’exécution est défini par un contrôle de flux.

2) Les objectifs du BPMN

La modélisation des processus métier BPMN est un type d’approche assez révolutionnaire adopté de plus en plus par les entreprises. Il permet de modifier en profondeur la méthodologie de travail des collaborateurs, mais aussi les technologies et les outils utilisés, ainsi que leurs objectifs de performance.

En effet, grâce à l’émergence d’un langage commun univoque, nous aboutissons à une meilleure compréhension des mécanismes de l’activité de l’entreprise ainsi qu’une bonne communication entre les collaborateurs quel que soit le profil.

Par ailleurs, le BPMN simplifie la transcription des processus métier vers les outils permettant de configurer leur exécution (BPEL Business Process Execution Language) que nous évoquerons plus loin dans cette étude. Ceci améliore considérablement la compétitivité par la réduction des coûts, la productivité et la capacité de répondre rapidement aux évolutions du marché.

La notation BPMN est basée sur différents symboles classés en plusieurs catégories présentées ci-dessous :

Un évènement est quelque chose qui se produit lors d’un processus. Les évènements incluent le début et la fin d’une activité, et tout autre phénomène intermédiaire (comme un changement d’état ou la réception d’un message) qui va affecter la chronologie ou la durée. On peut créer des évènements dans les diagrammes de collaboration, de processus et de chorégraphie.

Les types d’évènement suivants sont disponibles :

• Aucun – Évènements sans type, qui indiquent les points de départ, les changements d’état ou les états finaux.

• Message – Réception et envoi de messages.

• Minuterie – Evénements cycliques, points dans le temps, durées ou délais.

• Escalade – Passage à un niveau supérieur de responsabilité.

• Conditionnel – Réaction à des conditions métier modifiées ou intégration de règles de gestion.

• Lien – Connecteurs de page. Deux évènements de lien correspondants équivalent à un flux de séquence.

• Erreur – Réception ou émission d’erreurs nommées.

• Annulation – Réaction à des transactions annulées ou déclenchement d’annulations.

• Compensation – Gestion ou déclenchement de compensations.

• Signal – Signalisation sur différents processus. Un signal envoyé peut être reçu plusieurs fois.

• Multiple – Réception d’un évènement faisant partie d’un jeu d’évènements  L’envoi de tous les évènements est défini.

• Parallèle multiple – Réception de tous les évènements d’un jeu d’évènements.

• Arrêt – Déclenchement de l’arrêt immédiat d’un processus.

Les activités

Les activités sont les travaux effectués au sein d’un processus. Ces activités peuvent être des tâches de plusieurs types (tâche utilisateur, lancement d’un service, script, envoi d’un email…). Le type de la tâche apparaît en haut à gauche de l’activité. Une activité peut également être un autre processus (sous-processus), un + est alors affiché en bas de l’activité. Enfin une activité peut être lancée en boucle (séquentielle, parallèle, while).

Les connecteurs

Les connecteurs contrôlent le flux de séquence du processus et peuvent fusionner ou scinder le flux en fonction des conditions de branchement.

Exemple : Commande de pizzas

4) L’utilisation du BPMN

Le BPMN a pour vocation de faciliter la communication des informations variées destinées à différentes cibles professionnelles. Il a été conçu pour différents types de  modélisation de bout en bout de processus métier que nous pouvons regrouper en deux modèles :

• Processus collaboratif  public B2B (Business to Business)

Il s’agit d’une modélisation de point de vue global des interactions entre deux ou plusieurs entités. Celles-ci sont représentées sous forme d’une séquence d’activités abstraites, traduisant l’échange des messages visibles par le public entre les entités. Pour ce faire, le processus de collaboration B2B contient moins d’activités que ce qu’il est susceptible d’avoir dans un processus interne.

Exemple de processus collaboratif B2B : Consultation chez le médecin

Le diagramme ci-dessus modélise le processus collaboratif B2B d’une consultation chez un médecin. Sur cet exemple sont représentées les interactions entre deux entités : le patient et le cabinet du médecin que nous séparons en deux pools différents contenant chacun des sous activités uniques. Les échanges entre les deux entités sont représentés par des messages liant deux activités appartenant à deux pools différents.

• Processus de métier interne privé

Contrairement au processus de collaboration B2B, le modèle de processus de métier interne se concentre généralement sur une entité unique. Bien qu’il représente les interactions des intervenants extérieurs avec l’entité, les activités dites privées, sont généralement invisibles par le public.

Certes, il est possible d’avoir plusieurs swimlanes dans un diagramme, cependant un processus interne n’est défini que par un seul pool. Ceci explique qu’un schéma de processus de métier interne inclut plusieurs processus privés. 

Exemple de processus interne : création d’un catalogue

Le diagramme ci-dessus modélise le processus interne de la création d’un catalogue. Sur cet exemple, nous visualisons deux entités différentes : le client et le magasin. A la différence de l’exemple étudié juste avant, les interactions entre les sous-entités internes (présentées chacune dans un swimelane) sont représentées par des flèches de séquence. Tandis que les échanges entre les entités sont modélisés par des flèches de message.

5) BPMN et UML

De l’intérêt croissant pour la modélisation des processus a découlé l’apparition de multiples notations. Event-driven Process Chain (EPC),  Integrated DEFinition Methodsont, BPMN et UML sont quelques exemples parmi d’autres, utilisés selon la culture de l’entreprise et les spécificités désirées.

Nous allons ici nous attacher à distinguer les différences qui séparent BPMN et UML.

Concrètement, l’UML est le standard utilisé dans la modélisation de la plupart des aspects logiciel et métier alors que le BPMN est le standard utilisé uniquement dans la modélisation des processus métier. Tandis que l’UML est constitué de 9 diagrammes assez disparates (diagrammes de classes, d’objets, de cas d’utilisation, de composants, de déploiement, d’états, d’activités, de séquence et de collaboration), BPMN n’en propose qu’un seul, très proche du diagramme d’activités.

Stephen A. White a effectué des recherches sur les similarités qui lient le diagramme d’activités UML v2.0 et le BPMN. Pour ce faire il modélise 21 workflow patterns, définis par la Workflow Patterns Initiative en 2003, via le diagramme d’activités et le standard BPMN.

Un workflow décrit une suite de tâches ou d’opérations effectuées par un ou plusieurs acteurs, en spécifiant quelles tâches sont attribuées à quels acteurs, en précisant le délai et le(s) mode(s) de validation. Les workflow patterns font donc référence aux solutions habituellement apportées à des problèmes récurrents. Le plus simple exemple de workflow pattern que l’on peut donner étant la Sequence. Le pattern Sequence permet de modéliser des activités en série, une activité après l’autre. Milestone est un autre exemple de workflow pattern qui permet à une activité de se poursuivre tant qu’une condition n’est pas vérifiée ou qu’un événement n’a pas eu lieu.

Les travaux de Stephen A. White concluent que, sur les 21 workflow patterns, presque tous peuvent être représentés adéquatement que ce soit via des diagrammes d’activités ou via le standard BPMN. La seule exception se situe au niveau du workflow pattern appelé Interleaved Parallel Routing dont les activités sont exécutées en série et dans n’importe quel ordre. Pour ce workflow pattern uniquement, le diagramme d’activités ne peut représenter graphiquement le fait que les activités sont réalisées sans ordre particulier.

Malgré ce problème, on remarque que les deux notations partagent de grandes similitudes tant par la représentation que par la signification. En effet, on retrouve des formes, semblables dans les deux standards, ayant le même sens : les rectangles arrondis pour les activités, les losanges pour les décisions, etc.

On notera cependant que le standard BPMN propose moins de formes graphiques différentes que le diagramme d’activités. En contrepartie, le standard BPMN utilise une plus large gamme de variations de ces formes de base. En effet, BPMN utilise des représentations graphiques semblables pour modéliser les différents types d’évènements (dont la forme de base est le rond) ou les connecteurs (dont la forme de base est le losange) par exemple.

Les terminologies utilisées changent également d’un standard à l’autre : un diagramme d’activités a un noeud de départ alors qu’un diagramme en BPMN a un événement de départ.

Les similarités qui rapprochent les deux diagrammes s’expliquent par le fait qu’ils ont tous les deux été conçus pour modéliser des processus métier. Pour comprendre certaines des disparités il faut connaître la genèse des deux standards. Le standard BPMN a été imaginé pour être utilisé par des analystes métier. Malgré ses efforts dans ce sens (il est à noter que le diagramme d’activités fait partie des efforts déployés) l’UML reste très orienté technique car plutôt destiné aux développeurs.

D’autres travaux plus récents (2010), menés par Dominik Birkmeier, confirment que le diagramme d’activités a peu à envier au BPMN que ce soit en termes d’efficacité ou d’utilisation.

Les travaux de Daniela C. C. Peixoto, quand à eux, tendent à prouver que le diagramme d’activités est aussi lisible et compréhensible que le diagramme BPMN pour l’utilisateur final.

Afin de vérifier cette hypothèse, 35 étudiants en première année d’informatique ont participé à une petite expérience. Ils ont d’abord répondu à un questionnaire visant à recueillir leurs connaissances sur le sujet des diagrammes, à savoir le processus de retraite du gouvernement. Chaque étudiant s’est ensuite vu confié, au hasard, une version des diagrammes (BPMN ou diagramme d’activités) avec un questionnaire portant sur la sémantique du diagramme. Il est à noter que les diagrammes ont été élaborés par une équipe ayant 5 ans d’expérience dans la modélisation de processus et que le processus en question était un cas bien réel.

Les réponses au premier questionnaire montrent que les étudiants n’avaient aucune connaissance préalable sur le processus de retraite du gouvernement. De plus, étant en première année d’étude, les élèves n’étaient pas des habitués des concepts NPMN et UML v2.0.

On s’attendait à ce que les résultats montrent que le diagramme BPMN était plus facilement compréhensible que son homologue UML car offrant une plus large palette d’éléments de modélisation. Cependant il est apparu qu’il n’en est rien. L’expérience a prouvé que du point de vue des utilisateurs finaux la lisibilité d’un diagramme d’activités équivaut à celle d’un diagramme BPMN.

Peut-on pour autant dire que ces deux standards sont rivaux ? La version 1.0 du standard BPMN a été publiée en mai 2004 par le BPMI (Business Process Management Initiative). Quelques mois plus tard, en novembre de la même année, sortait la version 2.0 de l’UML défini par l’OMG (Object Management Group). Depuis 2005 et la fusion de BPMI et OMG, BPMN est maintenue par l’OMG, ce qui semble indiquer une complémentarité et non une concurrence.

5) BPMN et BPEL

Qu’est-ce que le BPEL ?

Le BPEL, Business Process Execution Language, est une représentation XML utilisée dans le cadre de la mise en place d’une architecture orientée services (SOA) en entreprise. Concrètement, dans cette architecture SOA, les applications de l’entreprise sont réunies au sein d’un socle commun afin de favoriser le dialogue entre applications et consolider l’existant. BPEL organise justement le dialogue entre les différentes applications de l’architecture SOA.

Il se présente sous la forme d’un fichier XML lisible par des moteurs de gestion des processus métier, ces derniers se chargeant d’appliquer les règles du fichier en question. Sans BPEL, les services Web ne pourraient pas dialoguer entre eux. BPEL est donc un langage d’orchestration des différents services afin d’obtenir un bon déroulement du processus métier (workflow). Le fichier BPEL agit donc sur des éléments comme la transformation de données, l’envoi de messages ou l’appel d’une fonction.

BPMN n’est pas un standard reconnu par un organisme de normalisation. Toutefois, une procédure est en cours auprès de l’organisme OASIS, dont la mission est de standardiser les formats de fichiers basés sur XML. Mais s’il n’a pas le statut de standard, BPEL l’est de fait par le support de grands noms de l’industrie informatique comme Adobe, BEA Systems, HP, IBM, Oracle, JBoss, Sun, Tibco, Webmethods, Microsoft, qui l’utilisent dans leurs logiciels.

De BPMN à BPEL?

Si l’on considère que les activités BPMN sont appelées par des services WEB dans une architecture orientée services, le langage BPEL peut donc orchestrer et faire communiquer ces services WEB. Il serait donc intéressant de pouvoir générer du code BPEL à partir d’une modélisation BPMN. L’outil professionnel Oracle Business Process Analysis Suite le permet. Ainsi en respectant quelques conventions de nommage propre à l’outil en plus de la norme BPMN, il est possible de créer une application workflow au sein d’une architecture orientée services à partir d’un schéma BPMN.

6) Comparaison de deux outils du marché

Les outils de modélisation de processus métier s’étoffent chaque année et les suites logicielles sont de plus en plus nombreuses. Actuellement, il existe 76 outils conçus pour la modélisation BPMN dont l’usage et les fonctionnalités diffèrent d’un périmètre à un autre, selon le besoin de l’entreprise. En effet, il n’existe pas un seul meilleur outil, mais le choix de ce dernier est basé sur différents paramètres liés à l’environnement technico-commercial de l’évolution du projet de l’entreprise, notamment la méthodologie, la technologie, les parties du projet à modéliser, la collaboration entre les membres et le niveau d’autonomie souhaité par le système.

Dans cette étude, nous avons choisi deux outils de modélisation de processus métier différents que nous allons comparer : BPMN Composer et Business Process Visual Architect.

a) BPMN Composer

BPMN Composer est un outil de modélisation de processus métier conçu spécialement pour être adapté à la norme BPMN v2.0. Celle-ci a été officialisée en 2010,  permettant de mieux comprendre la complexité des interactions entre les processus au travers du concept de chorégraphie.

Cet outil de modélisation est gratuit. Nous avons donc pu le tester grâce à une version Beta disponible sur le site du constructeur.

Ci-dessous une capture d’écran du logiciel :

Avantages :

• Gratuit
• Interface intuitive
• Mises à jour automatiques et régulières (pour garder la compatibilité avec le standard BPMN)

Inconvénients :

• Outil restreint au standard BPMN v2.0
• Outil non collaboratif

b) Business Process Visual Architect

Business Process Visual Architect est un logiciel payant (version d’essai gratuite pendant 10 jours), destiné aux professionnels.

Ci-dessous une capture d’écran du logiciel :   

Avantages :

• Outil collaboratif
• Interface intuitive

• Outil très complet : génération automatique d’un rapport, possibilité de création d’éléments de modélisation personnalisés, traduction automatique des diagrammes en différentes langues

• Mises à jour automatiques et régulières (pour garder la compatibilité avec le standard BPMN)

Inconvénients :

• Outil de base payant
• Modules comportant des fonctionnalités supplémentaires payantes

Conclusion

BPMN est donc un relativement jeune standard permettant la modélisation des processus métier, conçu pour être compréhensible tant par les analystes métier que par les développeurs. De plus, couplé avec le langage de programmation BPEL, il permet l’exécution des procédures. En outre, ce standard ressemble par de nombreux aspects au diagramme d’activités du standard UML. De nombreux outils de modélisation BPMN, aussi bien gratuits que payants, sont d’ailleurs disponibles sur le web.

Articles :
Stephen A. White, 2004. Process Modeling Notations and Workflow Patterns.
Daniela C. C. Peixoto, 2008. A Comparison of BPMN and UML 2.0 Activity Diagrams.
Dominik Birkmeier, 2010. Empirical Comparison of the Usability of BPMN and UML Activity Diagrams for Business Users.

Sites web :
Le site officiel du BPMN : http://www.bpmn.org/
L’encyclopédie en ligne Wikipedia : http://en.wikipedia.org
Site expliquant les processus de management : http://www.allaboutbpm.com/