Durant la Master Class BPM du FAN (j’en parle ici et là), nous avons abordé la problématique de Gestion de la Décision dans le cadre des applications de BPM et de Case Management. Je souhaitais revenir sur ce point pour présenter ma vision des choses.

On entend par Gestion de la Décision la capacité donnée au métier de déterminer ses règles sans forcément passer par l’IT (cf. la note d’Olivier Rafal à ce sujet). C’est du BPM ? Pas tout à fait. Le BPM présente les informations nécessaires et suffisantes pour traiter une activité métier donnée, à un instant donné, sans tenir compte de la capacité du traitant à apporter son expertise personnelle. Pour autant, ces informations ne suffisent pas toujours au gestionnaire pour décider de la suite à donner au dossier. En effet toute décision fait appel à des informations mais aussi à des règles, des façons de procéder qui sont propres à l’entreprise et découplées du contexte métier, du processus, de l’IT. Comment faire pour que ce gestionnaire puisse exploiter les informations reçues, intégrer les règles d’entreprise et prendre la bonne décision si on ne lui fournit pas une solution pour gérer ce contexte ?

C’est là qu’interviennent les outils de gestion des règles (BRMS – Business Rules Management System), qui permettent de générer un contexte (ce n’est pas que de l’information, j’y inclus le cadre d’exécution particulier lié à l’instance du processus en cours de traitement) et de le passer au moteur de règles qui sait l’exploiter. Ce moteur interprète le contexte, applique l’ensemble des règles modélisées au préalable et en tire une ou plusieurs décisions possibles. La suite ? Retour à l’envoyeur, à savoir le gestionnaire qui va se voir proposer une ou plusieurs alternatives pour décider. C’est là que rentre en jeu la notion de compétence ou d’expertise, il ne s’agit plus de dicter un choix à l’utilisateur (ce qui serait plus dans l’esprit du BPM) mais bien de lui laisser la liberté de choisir parmi les possibles en fonction de son expérience personnelle et d’en tirer la conclusion (lire « décision ») qui convient.

Mais encore ? Pourquoi ne pas intégrer ces règles dans la modélisation BPM ?

Il est préférable d’exporter ces règles car elles sont transverses à l’organisation de l’entreprise et pas nécessairement liées au processus en question. D’autre part les règles changent, évoluent et sans refaire l’histoire de la gestion des règles, il est important de pouvoir les faire évoluer sans remettre en cause les définitions de processus. C’est une véritable problématique métier et non IT. Ainsi nous sommes assez d’accord pour dire que ce sont des utilisateurs ou analystes métiers qui vont saisir ces règles alors que ce sont des informaticiens qui vont coder les règles « en dur » dans les processus. Deux mondes différents donc.

Les règles une fois externalisées peuvent également être réutilisées. Il n’y a pas qu’un seul processus dans l’entreprise, je vous le souhaite, aussi dissocier règles et processus permet de faire l’économie de la ressaisie et permet surtout de rester le plus en cohérence possible avec le modèle. Moins il y a de ressaisie, plus c’est simple à maintenir.

En conclusion, que penser de tout ça ? Que la gestion des règles métier et la gestion des processus sont bien deux domaines indépendants, ou doivent l’être. Pour autant ils interagissent, ou doivent interagir le plus souvent possible dès lors qu’il y a exécution des processus. Les solutions de Case Management qui arrivent sur le marché tiennent compte de cette problématique et intègrent la délégation à un moteur de règles de la prise de décision. Ou doivent l’intégrer.

Pour réagir à cette note ou apporter un complément de vue, laissez un commentaire !

Illustration (C) Matthew Loberg