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).
Une relation statique est par exemple le fait que les sorties d'un processus P1 sont les entrées d'un processus P2 (relation spatiale).
Une relation dynamique est par exemple le fait que le processus Pa se lance quand le processus Pb est à la moitié de sa durée (relation temporelle).
L'organisation pensée et mise en place s'incarne par ses processus métier (et leurs interrelations et interactions). En d'autres termes, elle se distingue d'une autre organisation par la spécificité de ses processus (et leurs interrelations et interactions) : nature, finalité, complexité versus simplicité et dépendances (ordres, réactions, routages, synchronisations…).

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.

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 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 business 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.” (gras ajouté)

Un développement de cette idée est ici

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 besoins vise à atténuer l'aspect rebutant de l'informatique pour les béotiens et foncièrement 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 strictement la même chose mais « plus tendance ».

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.

Quelques uns d'entre eux :

BPMN - plateformes


Une platforme 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.

Quelques unes d'entre elles :

BPMN - concepts cœur


ici

BPMN - plus loin dans les concepts


ici

Merci de votre confiance et attention.

© Franck Barbier