BPMN 2.0 : quelle utilité pour le Business Analyste ?

Cédric AdemainL’an passé, BPMS.info vous annonçait que l’OMG allait commencer à valider les spécifications définissant la notation BPMN 2.0. Il aura fallu une année pour que la notation soit officiellement finalisée. Qu’en ressort-il ?

BPMN 2.0, une notation complexe

Lorsque l’on prend connaissance de l’illustration qui représente BPMN 2.0, la 1ère réaction est de trouver cela compliqué et peu lisible, en particulier si vous commencez à vous intéresser à la déclinaison d’événements et le nombre de connecteurs (branchements) disponibles. Rappelons que l’enjeu est de taille : définir et mettre à disposition une convention de modélisation unique (indépendant de l’outil et de la population utilisatrice) !

Fig 1_CA_BPMS.jpg

Alors que la première version de BPMN avait pour objectif de normaliser la notation, BPMN 2.0 s’est clairement concentré sur la partie exécutable à en voir le travail réalisé sur la portabilité.

BPMN 2.0 : un langage d’exécution

Parmi les principaux sujets traités par L’OMG, définir un schéma d’échange standard basé sur XML pour l’échange de modèles exécutables, en était le principal. Le format XML défini est un enjeu important car BPMN 2.0 a la volonté de devenir un langage de modélisation exécutable en remplacement de BPEL. L’intérêt étant bien sûr d’être en capacité d’exécuter directement les modèles dans un moteur d’exécution. Pour mémoire, avant, il fallait « mapper » manuellement BPMN 1.x avec BPEL pour exécuter les processus modélisés.

Portabilité entre outils

Avant, échanger un modèle d’un outil à un autre signifiait devoir tout reprendre et pourtant BPMN est supposé être un standard : le schéma d’échange standard basé sur XML répond en partie à ce manque. Malheureusement la portabilité au niveau graphique risque d’être décevante (perte de la mise en forme).

Enrichissement de la bibliothèque d’objets

BPMN 2.0 se propose d’ajouter des événements appelés « événements de non interruption ». Concrètement, vous voulez simplement envoyer un rappel ou envoyer une notification à un manager tout en laissant la tâche se dérouler. De la même façon, si un client met à jour une commande, il n’est pas nécessaire d’abandonner la préparation de la commande, mais simplement y ajouter d’autres articles.

Un autre événement fera également son apparition : escalation en anglais. Il se traduira par un signal qui est généré dans le processus. Un événement de ce type au niveau d’une tâche manuelle signifie que, pendant que la tâche est exécutée, si l’événement survient, cela déclenchera, soit l’annulation de la tâche pour réaliser autre chose ou commencer une autre série d’activités en parallèle.

Pour faciliter la prise en compte d’exceptions, un événement appelé événement sous processus sera créé. Un sous processus lié à l’événement encapsulera le traitement exceptionnel quand l’événement surviendra.

A noter également qu’une tâche « règle de gestion » est désormais disponible pour identifier une tâche soumise à une règle métier. Les relations entre les processus et les règles de gestion sont indispensables pour décrire le métier d’une entité, on ne parle pas ici des règles de routage qui clarifient le gateway mais bien de règles qui expliquent les différentes sorties possibles.

Détail des éléments principaux de la notation

Le diagramme de collaboration permet de modéliser les processus et les interactions entre 2 entités au minimum.

Fig 2_CA_BPMS.jpg

Activités
Ce type d’objet permet d’identifier un processus, un sous-processus, une tâche. Un icône présent sur l’activité permet de comprendre visuellement à quel niveau nous sommes. Des icones complémentaires permettent de distinguer les différents types de tâches (manuel, automatique, soumis à une règle métier, envoi, réception…)

Fig 3_CA_BPMS.jpg

Bassin et couloirs
Un diagramme de collaboration ne peut contenir qu’un seul bassin (département, service). Ce bassin peut contenir plus d’un couloir (qui correspondent à des rôles : manager, assistante, collaborateur). Pour chaque couloir des activités sont définies. Pour illustrer les échanges entre 2 couloirs, on utilise des liaisons spécifiques appelées flux de message.

Fig 4_CA_BPMS.jpg

Evénements
Un événement est quelque chose qui survient. Il déclenche une action ou est le résultat d’une action. BPMN met à disposition 3 catégories d’événements, événement de début, de fin et intermédiaire, qui sont enrichis par une icône permettant d’illustrer le type d’événement (message, temporel, regroupant un sous-ensemble d’événements, …).

Fig 5_CA_BPMS.jpg

Connecteurs
Les connecteurs permettent d’interpréter les flux : ET, OU exclusif, OU inclusif… L’objet est représenté sous forme de diamant et sa signification est illustrée par l’icône à l’intérieur.

Fig 6_CA_BPMS.jpg

Artefacts
Ce sont des objets additionnels utilisés pour mieux comprendre le schéma BPMN : comme les activités de même catégorie, les données traitées ou bien des commentaires ou annotations.

Fig 7_CA_BPMS.jpg

Illustration en modélisant les processus de commande et de livraison d’une pizza :

Fig 8_CA_BPMS.jpg

L’illustration précédente semble accessible mais la notation offre désormais plus de 100 éléments pour permettre l’exécution des processus dans un outil de BPM. Peu d’experts du domaine maitrisent et maitriseront la totalité de la notation. De plus un modélisateur travaille avec des utilisateurs, ces experts métier qui fournissent la matière à modéliser, comment communiquer avec eux sans les perdre ?

Restons sur l’exemple des événements à disposition, il parait peu probable de pouvoir tous les retenir sans garder la convention à portée de main. Comme le dit Sandy Kemsley dans How to Explain BPMN to Business Users, cette complexité rappelle un peu le développeur qui parfois ne se rappelle plus quelle est la syntaxe exacte à utiliser en programmation et doit se référer à l’aide dédiée. BPMN 2.0 devient alors un langage de programmation graphique qui permet de définir des processus exécutables sans codage.

Je partage cet avis, je suis moi-même Business Analyste et modélise régulièrement : par expérience, je sais qu’un projet de modélisation des processus prend du temps, le modélisateur ne peut pas se permettre de chercher quel symbole correspond à quoi : la convention doit être simple pour qu’elle ne soit pas un frein à l’élaboration des diagrammes.

Les experts BPMN préconisent donc de décomposer la notation en fonction de la population qui va l’utiliser.

BPMN 2.0, à chaque type de population son niveau de complexité

Tous les experts du domaine convergent sur un point, il convient de catégoriser les utilisateurs en 3 groupes et d’y associer un niveau d’expertise :
– Utilisateurs métier, niveau standard
– Analystes métier, niveau avancé
– Développeurs, niveau expert

Sans entrer dans les polémiques concernant des objets que certains experts proposent à un niveau moins avancé que d’autres experts, voici comment ils sont le plus communément définis :

Niveau standard
Les experts métier avant tout pour décrire leur métier et dans ce but, on peut établir une liste d’éléments qui suffiront à la modélisation :
– Diagramme de collaboration
– Organisation (pool, swimlane)
– Activités : activités, tâches, sous-processus, tâche soumise à une règle de gestion, tâche manuelle, tâche automatisée
– Liaisons : flux de message, flux conditionnel, flux de séquence, liaisons vers les données et les annotations
– Connecteurs logiques : connecteur ET, connecteur OU exclusif
– Objet de données
– Dépôt de données
– Evénements : événement de début, de fin, messages, temporel
– Eléments d’information supplémentaires : annotation, regroupement

A l’aide de ces éléments, un modélisateur peut formaliser un processus commençant par un événement de début ou un événement temporel, enchainer un certain nombre d’activités séquentiellement ou en parallèle, préciser qui réalise(nt) ces activités, identifier les messages transmis entre les différents participants, conditionner le flux en fonction d’une règle de gestion, zoomer sur une activité en la décrivant comme sous-processus, de terminer les flux par des événements de fin.

Niveau avancé
Le niveau standard auquel on ajoute :
– Activités : tâches d’envoi, de réception
– Connecteurs logiques : connecteur OU inclusif, connecteurs basés sur les événements
– Evénements : événement signal début et fin, événement de fin ERREUR, événement d’escalade et tous les événements intermédiaires

Le niveau avancé permet d’ajouter des conditions supplémentaires au niveau des flux, de préciser la nature des flux en utilisant les événements intermédiaires : une tâche génère un message qui conditionne l’exécution de la tâche suivante. A noter qu’un événement message peut générer un événement signal.

Niveau expert
Le niveau avancé auquel on ajoute :
– Activités : activité de boucle, multi instance, de script
– Connecteurs logiques : connecteur OU inclusif, connecteurs basés sur les événements
– Evénements : événement de lien, annulation, compensation, multiple, multiple parallèle, événement de fin ERREUR et tous les événements intermédiaires qui correspondent

Le niveau expert correspond au niveau de cohérence nécessaire à l’exécution sur une plateforme BPM : il permet la définition de l’ensemble des scénarios possibles et la façon de les traiter au travers du processus.

BPMN 2.0, quelles perspectives ?

Voila donc un tour d’horizon de ce qui est disponible et j’avoue être perplexe : je suis moi-même business analyste et je vois bien l’intérêt d’une notation poussée pour faciliter le dialogue avec les architectes métier. Pourtant, je ne peux pas venir avec une notation aussi complexe devant des experts métier : sur tous les projets auxquels j’ai participé, nous sommes partis de la description métier en travaillant de pair avec les experts métier.

Sans même entrer dans le détail méthodologique de la modélisation, ils doivent se soustraire à un exercice difficile :
– Être capable d’expliquer/de décrire son métier
– Être capable de conceptualiser et trouver ensemble le bon niveau de granularité
– Admettre que son métier peut se résumer en « quelques boites qui se suivent »
– Intégrer un postulat primordial : par essence, la modélisation est une vision simplifiée de la réalité, la modélisation implique donc des choix entre la lisibilité d’un diagramme et la représentation graphique du processus dans toute sa complexité

Je me vois mal ajouter à ces points une convention de modélisation proposant plus de 50 éléments pour modéliser les subtilités (parfois uniquement techniques) du processus.

Le découpage de la notation par population préconisé par plusieurs serait donc une réponse mais concrètement, qu’est-ce que cela signifie ? Devoir créer deux diagrammes, le 1er simplifié à l’usage du métier et l’autre, plus complexe, pour les développeurs ? Le travail peut sembler redondant mais il me parait indispensable pour proposer des diagrammes lisibles pour chaque population. Au final, cela permet d’implémenter ses processus dans un outil d’exécution SANS PASSER PAR DU CODE, que de temps gagné, surtout si la mise à jour du processus modélisé actualise automatiquement la partie exécutable !

Pourtant, n’oublions pas les éditeurs, qui maintenant doivent intégrer la notation dans leurs outils, que vont-ils faire, intégrer la totalité de la notation et les règles de modélisation qui en découlent ou simplifier la notation selon leurs besoins ?

Pour palier à ce problème, L’OMG, après des mois de lobbying de Bruce Silver, acteur incontournable dans l’élaboration des spécifications de BPMN 2.0, a défini différents niveaux d’intégration de la notation, l’intérêt principal étant la portabilité d’un diagramme d’un outil à un autre.

De plus, il semblerait que les éditeurs aillent dans le bon sens : selon Bruce Silver, l’outil Oracle BPM Suite 11g, qui est le 1er à intégrer la notation 2.0, n’est pas décevant. L’idée à retenir est que Oracle BPM intègre la norme BPMN 2.0 et peut se substituer à BPEL ; le moteur d’exécution est capable d’interpréter les deux.

Fig 8 corr_CA_BPMS.jpg

Espérons que les autres acteurs du marché iront dans le même sens.

Pour terminer, rappelons que côté métier, en ces temps de crise, on sent une volonté accrue de modéliser et gérer les risques (risques, contrôles, plans de test…), piloter la performance (objectifs, indicateurs…) et même simuler ses processus, BPMN ne permet pas encore de créer un référentiel d’entreprise complet. La version 3.0 de BPMN ira-t-elle dans ce sens ?

Auteur : Cédric ADEMAIN (photo)

BPMN 2.0 : quelle utilité pour le Business Analyste ?