Avec l’avènement du "Business Process Management" (BPM), le marché, les utilisateurs, les consultants, les fournisseurs de technologies, arrivent aujourd’hui à une telle maturité qu’il est possible de proposer une notation standard de représentation des diagrammes des processus métier, agréée par le plus grand nombre et implémentée par la plupart des éditeurs de logiciels du secteur.

C’est l’objectif de BPMN, Business Process Management Notation (BPMN).

Une norme qui s’érigera vite en standard
Les travaux sur BPMN ont été initiés et sont toujours conduits par la Business Process Management Initiative (BPMI), organisme voué à la spécification de normes dans le domaine du BPM. Les principaux acteurs du marché proposant des solutions de modélisation des processus métier contribuent à ces travaux : ils font bénéficier le groupe de travail de leurs années d’expérience auprès de leurs clients pour élaborer une norme qui soit orientée vers les besoins des utilisateurs en matière de conception de processus métier.

La version 1.0 de la norme est aujourd’hui disponible (depuis mai 2004) : c’est une version déjà très aboutie, à tel point qu’elle est déjà supportée par des produits logiciels du marché, et que bon nombre d’éditeurs se sont engagés à l’implémenter dans leurs offres.

Une notation simple pour un exercice complexe
Le résultat est remarquable. La spécification allie simplicité des concepts et puissance d’expression de constructions complexes (car, comme chacun sait, même le processus le plus simple cache des cas complexes). Elle permet, à partir d’éléments de base, simples et en nombre limité, de dessiner le diagramme d’un processus métier (en créer le modèle graphique).

Les éléments de base sont de quatre types : les "Couloirs" (Swimlanes), les "objets de flux" (Flow Objects), les "objets de relation" (Connecting Objects), et les "objets symboliques" (Artifacts).

Les couloirs sont utilisés pour organiser graphiquement le diagramme du processus, de façon à regrouper dans un "pool" tous les processus et activités concernant un même participant, et à organiser les processus et activités au sein d’un "pool" à l’aide de "bandes" (Lanes)

Le diagramme d’un processus est conçu en connectant entre eux des "objets de flux" à l’aide d’ "objets de relation". Il n’y a que trois types d’ "objets de flux" : des activités, des événements et des "portes" (Gateways), et il n’y a que trois types d’ "objets de relation" : des flux séquence, des flux message et des associations.

Les activités représentent des actions à réaliser, et peuvent-être simples (tâches) ou complexes (sous-processus); les événements sont ce qui peut arriver dans le cours de l’exécution d’une instance et influencer son déroulement : début et fin, arrivée d’un message, échéance d’un « timer », exception, nécessité de mettre en œuvre une compensation (défaire ce qui a été fait précédemment pour "revenir" dans un état stable), etc. ; les "portes" sont des points de synchronisation et/ou de décision dans le processus où les flux convergent ou divergent en une ou plusieurs branches : un tel point du diagramme possède des "portes d’entrée" et des "portes de sortie", qui donnent chacune sur un flux séquence : si la condition associée à un flux séquence est évaluée à vrai, la porte s’ouvre !

On l’a compris, les flux séquence relient entre eux les objets de flux, pour définir leur ordonnancement. Les flux message, quant à eux, relient entre eux des participants aux processus, et précisent les messages échangés. Enfin, une association relie des données, un texte ou un objet symbolique à un objet de flux, essentiellement pour désigner ses entrées et ses sorties. Les objets symboliques viennent compléter la palette des éléments disponibles à des fins de précision et de documentation : regroupement d’activités dans un fragment de processus, annotation explicative, précision des données attendues en entrée ou produites en sortie.

Comme on peut le constater, les éléments de base, qui sont comme les couleurs d’une palette, sont en nombre réduit, et offrent un pouvoir d’expression infini, à l’instar des œuvres d’art.

La nouveauté de BPMN
On peut se poser les questions : pourquoi ne pas l’avoir inventé plus tôt ? qu’apporte BPMN de nouveau ? La maturité atteinte dans la modélisation des processus métier et dans leur transcription dans le système d’information rend aujourd’hui la standardisation possible.

Les avantages de BPMN sont énormes, et seront perçus de plus en plus avec le temps. BPMN constitue la seule notation résultant d’un effort collectif des experts du marché qui permet un vrai dialogue entre maîtrise d’ouvrage et maîtrise d’œuvre pour la mise au point des modèles de processus métier : c’est l’ "esperanto" du processus.

La spécification de BPMN hérite de tant d’expérience et émane de telles fondations qu’elle offre une puissance d’expression infinie : elle supporte tous les "workflow patterns" aujourd’hui recensés (micro- modèles typiques de processus) et s’applique à la fois aux processus privés (internes à une organisation ou à une entreprise) ou collaboratifs (collaborations entre deux organisations ou deux entreprises). Un des objectifs de la norme BPMN est aussi de permettre la traduction automatique d’un processus modélisé graphiquement dans un format compréhensible par un moteur d’exécution de processus ; le standard émergeant dans le domaine de l’exécution des processus est aujourd’hui BPEL (Business Process Execution Language) et la norme BPMN spécifie la correspondance entre BPMN et BPEL. Grâce à BPMN, le BPM peut garantir à une organisation la parfaite adéquation et synchronisation des modèles de processus décrits dans une documentation et exécutés de façon opérationnelle.

BPMN suffit-elle ?
L’avènement d’une notation standard et partagée constitue en soi une avancée significative, et manifeste la maturité du marché du BPM. Mais une notation ne suffit pas à la réussite de la modélisation des processus métier : elle doit s’accompagner d’une méthode de modélisation et d’une politique organisationnelle pour être mise en œuvre avec succès. Il faut en effet définir des règles pour la collaboration entre maîtrise d’ouvrage (MOA) et maîtrise d’œuvre (MOE), entre personnes de la MOA et entre personnes de la MOE, quand des équipes contribuent à la modélisation des mêmes processus. Il faut aussi définir la méthode de modélisation, car même si la notation canalise le travail, la méthode en garantit le résultat. Les consultants proposeront de telles méthodes, ou adapteront leur méthode à cette notation : leur rôle d’accompagnement et de "garant" n’est pas à négliger dans cet exercice.

Allez-y !
Il n’y a pas de véritable alternative à BPMN, dans son objectif de cibler à la fois les personnels métier et informatique. La norme est disponible, dans une version déjà aboutie : les principaux acteurs du domaine y ont contribué. Des éditeurs supportent déjà des implémentations de BPMN, et de plus en plus d’éditeurs annoncent son support. La question n’est donc plus "faut-il y aller ?", mais "quand ?". Pour sécuriser et pérenniser un travail de modélisation de processus métier, pour entrer d’emblée dans une démarche de capitalisation, pour échanger des modèles de processus avec d’autres organisations, avec des partenaires, BPMN est une excellente solution. Le site www.bpmn.org propose, en plus de la spécification de la norme, des documents utiles à la compréhension et la mise en oeuvre de BPMN.