BPMN 2.x

Business Process, késako


Toute organisation (entreprise, administration, service, relation client -e.g., customer relationship management-, relation fournisseur -e.g., supply chain-, interaction avec l'extérieur -business-to-business en général-) est fondée sur des processus opérants (système d'opération), des processus informationnels (système d’information) et des processus décisionnels (système de décision).
Que ce soit des produits ou des services, le système opérant s'incarne dans des flux « matière ». Le système de décision a vocation à piloter (observer et agir sur) le système opérant. Quant au système d'information, il véhicule de l'information capturée, calculée et restituée. Cette information, par sa qualité (actualité, interprétabilité, représentativité…), est un support d'aide à la décision. Le système d'information est critique par son statut d'interface entre opérations et décisions.
Tout flux (ou « flot ») n'existe que par les interrelations (statiques) et interactions (dynamiques) entre processus (suite d'activités dans une logique de découpage fonctionnel et comportemental : conditions internes, événements externes…).

Strates système d'opération/système d’information/système de décision


L'information (objet artificiel -artefact- ou immatériel) image la « matière » (objet naturel ou « matériel »). Décrire des flux opératoires signifie la capacité et la disponibilité d'information sur eux.

Processus, interrelations et interactions


Management


La complexité de l'organisation résulte du nombre de ses processus, des nombreuses dépendances entre eux, des ressources nécessaires à leur déroulement : intervenants, infrastructures… Le management des processus passe donc par :

  1. la faculté de les appréhender et de les comprendre
  2. la capacité (si 1.) de les changer lorsqu'ils dysfonctionnent ou de les améliorer (simplification, accélération, augmentation du niveau et de la qualité de service…)
  3. le pouvoir (si 2.) de les concevoir ou les re-concevoir dans une logique d'innovation
  4. l'obligation (si 3.) de les informatiser pour rendre le management possible et réaliste au regard de la complexité de l'organisation

Exemple de
processus
métier

Articulation Business Process Management (BPM) et informatisation


L'esprit même de BPM n'est pas l'informatisation à tous crins. Une organisation peut s'appuyer sur un système d'information tout ou partie « manuel ». L'informatisation facteur d'accélération de l'exécution des processus informationnels change toutefois fondamentalement nos capacités à opérer et décider, et donc le « métier » lui-même (ex. : Big Data versus not not Big Data) !

De l'informatisation à la digitalisation : “In the beginning, businesses considered software as a way to automate processes, contributing to productivity by speeding up what was already being done. But over time, software became recognized not just as an automation tool but more broadly as a strategy for providing products and services not yet offered.” (rouge ajouté)

Un développement de cette idée est ici

Modélisation, késako


La modélisation est l'art d'abstraire un système (mise en exergue de propriétés au détriment d'autres délibérément omises). Ce système existe ou est à construire ou un peu des deux ! Pour faire simple, en informatique, programmer c'est modéliser. La complexité des applications informatiques oblige toutefois à créer une strate entre, d'un côté, contraintes et besoins et, de l'autre, solution informatique. Cette strate est le champ d'action des langages de modélisation dont les plus connus sont UML, SysML, ArchiMate ou encore BPMN.

Un modèle au sens UML, SysML, ArchiMate ou encore BPMN est une histoire de types alors que son exécution est une histoire d'instances. En d'autres termes, naturellement, sans s'en rendre réellement compte, on décrit des interrelations et interactions 1-à-1 au niveau modèle alors que l'exécution est n-à-n (at large).

Pratiquement, dans BPMN par exemple, il est difficile d'exprimer des collaborations entre un nombre variable d'« intervenants ». C'est encore pire si ce nombre varie en fonction du comportement antérieur du processus ! Un autre genre de problème est l'instanciation d'un processus (exécution), l'instanciation d'un événement (occurrence), etc. Il est difficile d'exprimer qu'il faille n occurrences d'un événement pour avancer dans le processus (n == 100 par exemple ou n variant en fonction du comportement antérieur du processus).

Modélisation, enjeux et attendus


BPMN - langage de modélisation


En tant que langage de modélisation graphique (ou d'expression graphique), BPMN dispose d'un vocabulaire, i.e., un ensemble de termes* (e.g., BPMN pool , BPMN message event , BPMN event subprocess ), dont le sens (« la sémantique ») est bien déterminé. « Les phrases » (« modèles ») BPMN sont des assemblages (graphiques) de ces termes.

La difficulté première de former des phrases provient des règles d'assemblage (syntaxe) fixées dans le méta-modèle BPMN. Toutefois, respecter la syntaxe ne garantit pas de réussir à créer du sens, voire d'empêcher de créer plusieurs sens. Idéalement, c'est un sens unique que l'on veut produire (déterminisme et donc exécutabilité). Sous l'hypothèse d'atteindre un tel déterminisme, la possibilité de dire la même chose de façon différente est aussi parfois déstabilisant. A ce titre, BPMN est plutôt verbeux ; il offre des « sucres syntaxiques »** dont l'usage immodéré et/ou incontrôlé diminue le caractère « formel »*** des modèles.

*Une revue générale des principaux termes BPMN est ici ou (on peut remarquer qu'il y a des légères variations).
**Cela accroit le pouvoir d'expression mais n'apporte rien à l'exécutabilité des modèles BPMN.
***Interprétation unique et non « à géométrie variable »

BPMN - langage de modélisation exécutable


BPMN est réputé être un langage « exécutable » d'où l'idée de process engine (e.g., jBPM). Par analogie, si une carte routière est un modèle, un voyage ou une navigation GPS sur la base de cette carte est une exécution de modèle (l'instanciation de processus en BPMN).

L'ingénierie des exigences vise à atténuer l'aspect rebutant de l'informatique pour les futurs utilisateurs de la solution informatique. Par expérience, les modèles ne concourent pas à cela malgré ce que disent les évangélistes du Model Driven Software Development.

BPMN - Business Analysis*


Dans une approche fonctionnelle « classique », le principe (cartésien) de décomposition fait avancer la connaissance en partant** de processus macroscopiques ou abstraits pour aller vers des processus plus microscopiques ou concrets (et informatisés au final).

Le contenu d'un processus est un ensemble d'« activités » perçues soit comme des fonctions « atomiques » (« tâches »), soit comme des fonctions encore décomposables (« sous-processus »).

*L'expression « analyse fonctionnelle » a peu à peu disparu des usages au profit de celle de Business Analysis qui est vraisemblablement la même chose mais « plus tendance ».
**Certaines méthodes de Business Analysis procèdent a contrario en bottom-up.

Métamodèle BPMN, méta-type « processus »


Métamodèle BPMN, méta-type « activité »


“The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, (…)” (ver. 2.0.2 - January 2014 - PDF, p. 179)

BPMN - éditeurs


Nombreux sont les éditeurs de modèles BPMN. Selon le niveau de support qu'ils offrent du langage (souvent des symboles BPMN ne sont pas ou mal supportés), ils révèlent la difficulté certaine à comprendre (et surtout exécuter) le langage dans son ensemble et ses subtilités. Il faut donc faire clairement la différence entre la doc. officielle normative (ver. 2.0.2 - January 2014 - PDF) et la compréhension qu'ont eu les concepteurs de tels outils, d'une telle spécification.

BPMN - plateformes


Une plateforme sous-entend l'offre d'un process engine (synonyme : workflow engine) BPMN. L'idée est de proposer une architecture informatique ad hoc en mesure de réaliser les modèles et s'interfaçant avec le système d'information notamment en termes d'exploitation des données capturées, calculées et restituées.

Plateforme, l'exemple de Java Business Process Management (jBPM)


Le principe discriminant d'une plateforme technologique comme jBPM est de fixer un univers technologique, i.e., Java, Java EE (serveur d'applications WildFly, a.k.a. JBoss), Java Persistence API - JPA, Java Transaction Service - JTS en relation avec Java Transaction API - JTA, Java API for RESTful Web Services - JAX-RS, Java Message Service - JMS, Docker (virtualisation), Drools (business rules engine), etc.

Ainsi, jBPM « fait l'effort » d'être compatible avec le niveau conception*, en l'occurrence le langage de modélisation BPMN. Cette compatibilité ne repose que sur le caractère exécutable de ce dernier (process engine). En clair, le process engine a la capacité d'interpréter des modèles BPMN conformes à la XML Schema Definition (XSD) associée à BPMN (XML Model Interchange - XMI pour BPMN) en opérations Java.

*Morale de l'histoire : l'impact sur la productivité est grand car l'effort « gaspillé » en conception (modèles) est grandement récompensé en programmation (code conforme aux modèles). Le retour sur investissement est effectif contrairement au Model Driven Software Development « standard » où la réalité contredit souvent la littérature !

Quiz : bien comprendre BPM et BPMN

Question 1/10


Dans l'entendement commun, un sous-processus est manifestement un cas particulier de processus… Est-ce vrai dans BPMN ?

Question 2/10


Un usage de BPMN circonscrit à une démarche de Business Analysis fait plutôt appel à un outil logiciel de type « éditeur » ou « plateforme » ?

Question 3/10


La modélisation BPMN par essence vise à la représentation de tous les détails de fonctionnement de « l'organisation » ?

Question 4/10


Tâche et activité se caractérisent comme suit dans BPMN :

Question 5/10


BPMN est par essence une méthode informatique où les processus modélisés sont dérivés en composants applicatifs dans un système d'information ?

Question 6/10


Quelles sont les bonnes affirmations concernant la notion de Business Process dans BPMN ?

Question 7/10


La notion d'événement existe dans le vocabulaire BPMN ?

Question 8/10


Prendre un ticket pour faire la queue dans une boucherie (puis se faire servir) est un Business Process ?

Question 9/10


Un modèle BPMN garantit systématiquement :

Question 10/10


Sous l'hypothèse de l'existence à t de 10 instances d'un (même) processus (type) BPMN, est-il possible que 5 instances échangent des informations entre elles alors que les 5 restantes ne le font pas ? Indication : une boucherie innovante a mis en place la possibilité d'échanger des tickets d'attente entre clients…

BPMN - concepts cœur


ici

BPMN - plus loin dans les concepts


ici

Etude de cas étalon, Business Analysis


Etude de cas étalon, implémentation et exécution


© Franck Barbier