BPM & BRMS : effet de mode ou nécessité?

Mauro_Scantaburlo.JPGLe BPM (Business Process Management) et le BRMS (Business Rules Management System) sont mentionnés dans de nombreux articles de la presse spécialisée. Effet de mode ?… nouveau créneau pour relancer les affaires en ces temps moroses ?… ou est-ce une nécessité ? Essayons d’y voire un peu plus clair en nous rappelant l’apport de l’approche processus pour l’industrie du logiciel.

L’établissement des spécifications métier est le premier livrable issu de la collaboration entre les représentants du Métier et de l’IT ; inutile d’insister sur le danger encouru par un développement informatique se basant sur des spécifications incomplètes.

Esquissons les avantages de l’approche processus dans le façonnage de ce document d’analyse :

♦ Le processus fait partie du vocabulaire du Métier

L’activité d’une entreprise est souvent découpée en :

     o Processus de réalisation : ils interviennent dans la réalisation d’un produit ou d’une prestation ;
     o Processus de support ou de soutien : ils fournissent les ressources (humaines, matérielles…) nécessaires aux autres processus ;
     o Processus de pilotage ou de management : ils donnent les directives (organisation, performance attendue…) aux autres processus.

L’utilisateur exprime ses besoins à l’aide d’un langage qui lui est familier.  

  Le processus exprime un besoin Métier

L’approche processus se focalise sur les besoins réels des utilisateurs et donc sur la valeur réelle de l’application qu’ils demandent.

  Le processus permet une analyse fonctionnelle Métier

La démarche processus ne se focalise que sur les connaissances métier des utilisateurs ; elle n’a pas pour but de recueillir les exigences techniques.

  Le processus permet une validation du Métier

La description d’un processus – sous forme textuelle ou graphique – recèle la logique fonctionnelle du Métier et, de ce fait, il peut être validé par le Métier.

La valeur ajoutée de conduire des projets informatiques en se basant sur la connaissance et l’analyse des processus métier semble ainsi prouvée. Ce constat n’a pas échappé au BPMI – qui a fusionné avec l’OMG (Object Management Group qui diffuse le standard UML) en 2005 – qui a sorti la norme BPMN (Business Process Modeling Notation) en 2004 dont l’un des objectifs était de : 

Proposer un moyen simple et visuel de communication entre les différents intervenants chargés de mettre en oeuvre une approche de gestion des processus métiers. 

Soulignons au passage que les processus décrits à l’aide de la norme BPMN peuvent ensuite être traduits en code exécutable (BPEL, XPDL…) afin de permettre leur exécution par un moteur d’exécution de processus

 D’aucuns verront un conflit « programmé » avec UML et se demanderont : que choisir entre UML et BPMN ? UML et BPMN ne sont pas des antagonistes ; ils s’inscrivent dans la continuité car ils sont chargés de modéliser des aspects différents du logiciel : 

  BPMN, pour l’expression des besoins utilisateurs ;
♦  UML, pour les spécifications techniques du logiciel.  

Un processus métier peut donc être défini comme un ensemble d’activités corrélées dont le déroulement est conditionné par des événements internes ou externes au processus et est régi par les règles métier. 

 Les règles métier s’intègrent et se combinent tout naturellement aux processus dans la mesure où elles apportent un surplus d’information et permettent d’affiner, d’améliorer la compréhension du processus

les règles métier gouvernent le déroulement des activités du processus ;
les règles métier remontent des alertes dans le déroulement du processus (ex. : si le retrait d’argent dépasse la limite autorisée, alors refuser le montant demandé) ;
les règles métier prennent des décisions de manière automatique (ex. : si le demandeur de crédit est un Client de la banque et que sa demande de crédit est inférieure à 10’000 CHF, alors octroyer automatiquement le crédit).

Des systèmes de gestion de règles (BRMS – Business Rules Management System) sont déjà présents sur le marché avec lesquels il est possible : 

d’écrire ces règles en langage naturel, puis
de traduire ces informations en code exécutable.  

Clio_dessin.jpg

La connaissance du Métier obtenue ainsi par le cumul des informations récoltées lors de l’identification des processus et des règles métier nous amène logiquement à la question suivante : 

Faut-il fusionner ces informations au sein d’un même référentiel ? 

Au vu de notre expérience, nous privilégions la gestion de ces informations dans des référentiels distincts car elle apporte des avantages notables : 

maintenance : une règle métier est plus sujette aux modifications qu’un processus ; en recourant à deux référentiels distincts, il est dès lors possible de modifier une règle sans avoir à toucher au processus dans lequel elle est implémentée.
réutilisation : une règle métier peut être utilisée dans des applications différentes ; un référentiel dédié aux règles métier permet d’éviter de multiplier une même règle.  

La combinaison de l’approche processus et d’un système de gestion des règles métier apparaît comme une solution dont les caractéristiques principales sont : 

la simplicité : les processus et les règles métier sont exprimés dans des langages proche du langage naturel ; les modèles et les règles peuvent être validés par les utilisateurs ;
la communication : elle permet un langage commun entre le Métier et l’IT avec, comme corollaire, moins d’incompréhensions entre ces deux partenaires ;
la pérennité : la mise en place de référentiels basés sur les processus et les règles métier contribuent à la sauvegarde du savoir-faire de l’entreprise, ainsi qu’une meilleure réutilisation de ces informations lors de passages de relais (turn over) ;
la productivité : les outils actuels permettent une génération automatisée des processus et des règles métiers sans engager de développements spécifiques.

Auteur : Mauro Scantamburlo (photo)

Share this post:
BPM & BRMS : effet de mode ou nécessité?