Différence entre workflow et moteur de règles

Une petite note traitant de la différence entre moteur de workflow et moteur de règles car je vois que certains visiteurs de ce blog se posent la question, je vais donc tenter d’apporter quelques éclaircissements.

Un moteur de workflow est un outil logiciel qui permet de faire transiter des tâches à accomplir d’une corbeille électronique à une autre. C’est assez réducteur comme définition mais je vais à l’essentiel. Ces corbeilles peuvent servir des utilisateurs (acteurs humains) ou des applications (acteurs applicatifs, robots). Pour plus de précisions concernant les moteurs de workflow, je vous renvoie vers ma série de notes sur l’historique du BPM sur ce blog.
Le routage d’une corbeille à l’autre est fait en suivant un processus défini par ailleurs dans l’outil de conception des processus qui accompagne généralement le moteur de workflow. Ce routage est soit parfaitement séquentiel et non conditionné, soit il est conditionnel et se base donc sur un jeu de règles définissant les conditions de branchement.

Les outils de workflow permettent la définition de règles plus ou moins évoluées mais restant d’une manière toujours générale assez simples et peu nombreuses : opérateurs booléens, champs de données du processus, valeurs saisies par les opérateurs, propriétés des documents éventuellement associés au processus, etc. De même ces règles sont généralement « incluses » dans la définition du processus et il faut versionner ce dernier pour les modifier ce qui nécessite des opérations d’administration sur le moteur de workflow.
A la différence du moteur de workflow, le moteur de règles permet de définir des règles de routage très élaborées. Complémentaire au moteur de workflow, le moteur de règles permet d’exposer aux utlisateurs des interfaces simples de génération de ces règles, en langage naturel, et traduit ensuite ces informations en code exécutable.

Le moteur de workflow peut alors se connecter au moteur de règles pour « savoir » quelle route prendre lors du déroulement d’un processus et dans le cas de conditions de routage particulièrement complexes et difficiles à paramétrer dans l’outil de conception disponible avec le moteur de workflow.

L’apport du moteur de règles est évident : gestion de règles complexes, changeantes, nombreuses, saisies en langage naturel (le moteur de workflow nécessite d’écrire des expressions qui peuvent ne pas être à la portée des utilisateurs métier).

A noter également que si le moteur de règles vient complémenter le moteur de workflow, il peut aussi être employé seul dans le cadre d’applications ne nécessitant pas nécessairement de gestion des processus.

En résumé, considérer un moteur de workflow et un moteur de règles dans une seule et même application, c’est séparer la logique métier du processus métier.
A titre d’illustration je citerai une application qui m’est chère dans le secteur public et dont le processus nécessite la définition de quelques 6500 règles dont près de 20% changent tous les ans. L’utilisation d’un moteur de règles couplé à un moteur de workflow a permis de réduire le temps nécessaire à la modification d’une seule règle de 3 semaines à quelques heures et bien évidemment le cycle du processus associé s’en est trouvé fortement réduit.

Je terminerai en citant les principaux moteurs de règles du marché que sont JRules d’Ilog, moteur généraliste et leader sur son marché, Fair Isaac, Corticon ou encore Resolution.

Lire la suite :

• Exemple de mise en oeuvre du BPM : comment faire simple et efficace …
• Du Workflow au BPM
• Glossaire BPM : quelques définitions / Partie 1
• L’évolution du BPM, ce n’est pas qu’une question de logiciel …
• Découvrir la valeur du BPM orienté Contenu pour mettre en oeuvre l’innovation – 2
• 26 définitions pour comprendre le monde de l’ECM et du BPM -1/2
• Case Management Workshop – Day 2
• Rendez-vous à Culture SOA – IBM Paris – 7 Juillet 2009
• Pourquoi intégrer la Gestion de la Décision au Case Management ?
• Projets BPM/Workflow : quelques erreurs à éviter