Diagramme des exigences de décision

Objectif

Le diagramme sert à cartographier une décision métier complexe et à la décomposer en un réseau de sous-décisions dont chacune se décrit, se gouverne et se maintient séparément. Il répond à une question que la logique d'une seule règle laisse de côté: de quoi cette décision a-t-elle besoin pour se prendre, quelles données, quelle connaissance, quelle autorité et comment ces pièces s'emboîtent. Le livrable est le diagramme lui-même, la couche des exigences d'un modèle de décision, sur laquelle viennent ensuite se greffer les logiques de détail.

Sa valeur se concentre sur deux fronts. Il sépare la logique de décision du flux de processus, ce qui permet de gouverner l'une sans toucher à l'autre. Et il fournit l'ossature d'un modèle exécutable, le point de départ d'une automatisation par les règles.

Usage

Quand l'utiliser

• Décision complexe à décomposer: la scinder en un réseau de sous-décisions décrites et gouvernées séparément.
• Grand nombre de règles à organiser: les grouper par décision pour la réutilisation et l'analyse d'impact plutôt qu'en une table ingérable.
• Décision enfouie dans un processus BPMN: extraire la logique du flux pour qu'une tâche de règle métier l'appelle.
• Cible d'automatisation par les règles: le DRD est la couche structurelle d'un modèle qu'un moteur de décision exécute.
• Image partagée d'une décision à obtenir: un dessin lisible par les parties prenantes qui porte l'analyse d'impact au-delà des frontières.

Quand ne pas l'utiliser

• Décision atomique unique: une table de décision seule la capte, le réseau n'apporte rien, prendre la table de décision.
• Décision simple et soudée au processus: la garder dans le flux, un modèle à part n'ajoute que de la complexité, prendre BPMN.
• Règles surtout comportementales (conduite, obligation): le cadre du DRD ne les adresse pas, prendre l'analyse des règles métier.

Description

Le graphe des exigences et le diagramme

DMN distingue deux objets. Le graphe des exigences de décision (DRG) est le modèle complet: l'ensemble des décisions, des données, des connaissances et des dépendances qui les relient. Le diagramme des exigences de décision (DRD) en est une vue, complète ou partielle, celle qu'on dessine et qu'on partage. Le DRD est l'une des trois notations que le BABOK regroupe sous la modélisation des décisions, celle qui opère au niveau du réseau plutôt qu'au niveau d'une règle.

Quatre nœuds et trois liens

Le dessin repose sur quatre formes, chacune portant un type d'élément.

• La décision, un rectangle: elle prend un jeu d'entrées et en tire une sortie parmi un ensemble défini, en appliquant une logique de décision. C'est ce qui se décide.
• La donnée d'entrée, un ovale: une donnée fournie au diagramme, le fait brut qu'une décision consomme, un revenu, un âge, un montant.
• Le modèle de connaissance métier (business knowledge model, BKM), un rectangle aux deux coins supérieurs coupés: un bloc de logique réutilisable, un ensemble de règles, une table ou un arbre de décision, voire un modèle prédictif, qui décrit précisément comment décider.
• La source de connaissance, un rectangle à base ondulée en forme de document: l'autorité d'où la logique est tirée, un document, un règlement ou une personne.

Trois liens expriment les dépendances, et c'est ce qui fait de ce dessin un diagramme d'exigences.

• L'exigence d'information, une flèche pleine, relie une donnée d'entrée à une décision ou une décision à une décision de niveau supérieur qu'elle alimente. C'est l'épine dorsale qui décompose une décision complexe en sous-décisions.
• L'exigence de connaissance, une flèche en tirets, relie un modèle de connaissance métier à la décision qui l'invoque: cette décision se prend au moyen de cette logique.
• L'exigence d'autorité, une flèche en tirets à tête ronde et pleine, relie une source de connaissance à une décision ou à un modèle de connaissance: ce document ou cette personne fait autorité sur la logique.

Construire le réseau

On part de la décision de tête, celle que le périmètre demande de prendre, puis on la décompose: chaque sous-décision qui l'alimente devient un nœud relié par une exigence d'information, jusqu'à des décisions assez élémentaires pour se décrire d'une seule logique. On rattache à chaque décision les données d'entrée qu'elle consomme, puis la connaissance métier qui la gouverne et enfin la source dont cette connaissance tire son autorité. Le réseau obtenu décompose la décision complexe en blocs plus simples, chacun descriptible et gouvernable à part.

Le DRD s'arrête au niveau du réseau. La logique d'une décision élémentaire, les règles qui font correspondre des valeurs d'entrée à une sortie, se loge dans une table de décision ou un arbre de décision rattaché sous le nœud. Dessiner ces conditions dans le DRD lui-même est l'erreur la plus courante: elle confond les deux niveaux et sature le diagramme d'un détail qui n'est pas le sien. À l'inverse, ouvrir un DRD pour une décision atomique qu'une seule table capte coûte sans rien apporter: le réseau ne se justifie que par la décomposition ou l'automatisation.

Séparer la décision du processus

Le DRD se marie avec la notation BPMN, et la répartition des rôles est nette: BPMN modélise le flux, la suite des activités, tandis que DMN modélise la décision que le flux invoque. Dans le processus, une tâche de règle métier appelle la décision, qui vit dans son propre modèle DMN au lieu de se disperser en une grappe de branchements dans le flux. L'intérêt tient à leurs rythmes de changement: la logique de décision évolue bien plus souvent que la structure du processus, et l'extraire du flux permet de la modifier et de la gouverner sans toucher au processus.

Vous trouverez plus de détails dans notre tutoriel BPMN.

Cette structure sert aussi l'automatisation. Un modèle DMN est conçu pour être lu par le métier et exécuté par une machine: le DRD en donne l'ossature, et les tables sous-jacentes, écrites dans le langage d'expression FEEL, portent une logique qu'un moteur de décision déroule directement. C'est ce qui rend DMN solide pour l'automatisation par les règles, sans exclure la décision manuelle ni l'analyse prédictive.

Trois pièges s'ajoutent à la confusion des niveaux et à la sur-modélisation. Un modèle documenté peut donner le sentiment trompeur que l'organisation décide de façon cohérente alors qu'elle ne le fait pas. Comme une décision traverse souvent plusieurs frontières organisationnelles, faire approuver le modèle demande un effort qu'il faut prévoir. Enfin, une automatisation n'est fiable que si la terminologie métier est définie clairement et communément: des termes flous se propagent en défauts de qualité des données dont le moteur héritera.

Considérations IA

Deux usages tiennent. Le premier est l'ébauche: à partir d'un règlement ou d'une politique écrite, un modèle de langage propose une première décomposition, des décisions candidates, les données qu'elles semblent consommer et les sources citées, que l'analyste corrige plutôt que de partir de la page blanche. Le second est la vérification de forme, mécanique et déléguable: chaque décision reçoit-elle ses données d'entrée, chaque modèle de connaissance métier est-il rattaché à une décision et à une autorité, le graphe est-il acyclique, une donnée d'entrée reste-t-elle inutilisée?

Ce qui ne se délègue pas tient au sens. Trancher qu'un élément est une sous-décision plutôt qu'une simple donnée engage une compréhension du métier. Identifier la source qui fait autorité, distinguer le règlement applicable d'un document qui n'en est qu'un commentaire, demande de connaître le cadre. Et décider qu'une décision doit être automatisée ou rester à un humain est un choix de responsabilité qu'aucun modèle ne porte à la place de l'organisation.

Exemples

Le concept que le dessin rend visible est l'assemblage des quatre formes et des trois liens sur un seul petit réseau: une décision, ses données d'entrée, la connaissance qui la gouverne et la source de cette connaissance. La décision retenue est l'éligibilité d'un ménage à la réduction individuelle des primes d'assurance-maladie, le subside cantonal prévu par la LAMal.

La décision « Déterminer l'éligibilité au subside » se trouve au centre du réseau. Elle consomme deux données d'entrée, le revenu déterminant en CHF et la taille du ménage, et s'appuie sur le « Barème cantonal des subsides », un modèle de connaissance métier. Ce barème est lui-même une table de décision, un seuil de revenu par taille de ménage, dont la logique se détaille dans une table de décision rattachée sous le nœud plutôt que dans le DRD: c'est la séparation des niveaux, le diagramme porte le réseau et le nœud renvoie à sa logique. Le barème tient son autorité du « Règlement cantonal sur la réduction des primes », la source de connaissance du réseau, ce qui rend l'analyse d'impact immédiate: un changement du règlement se répercute le long des liens jusqu'à la décision. Cinq nœuds suffisent à porter les quatre types d'éléments et les trois types de liens.

Visualisations

La forme porte le sens. Le type d'un nœud se lit dans sa silhouette, le rectangle pour une décision, l'ovale pour une donnée d'entrée, le rectangle aux coins coupés pour un modèle de connaissance métier, la base ondulée pour une source. Le type d'une dépendance se lit dans le trait, plein pour une exigence d'information, en tirets pour une exigence de connaissance, en tirets à tête ronde pour une exigence d'autorité. Un lecteur qui connaît DMN lit le réseau sans légende.

Coût

Outils

Un tableau blanc suffit à une première ébauche: quelques nœuds et leurs liens tiennent sur une feuille et se corrigent debout. Les outils de schéma généralistes, diagrams.net, Lucidchart ou Visio, portent des gabarits DMN et donnent un dessin propre, mais ils s'arrêtent au dessin: le lien vers les tables de logique et l'exécution reste à faire ailleurs. Les plateformes DMN dédiées, comme l'éditeur DMN open source de Camunda, Trisotech, Signavio ou Red Hat Decision Manager, tiennent le DRD comme la couche haute d'un modèle exécutable: on descend d'un nœud de décision vers sa table, on valide le modèle, puis on le déploie vers un moteur de décision qui l'exécute. Ces outils s'articulent en général avec un modeleur BPMN, de sorte qu'une tâche de règle métier du processus appelle directement la décision modélisée.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.17: le diagramme des exigences de décision parmi les trois notations de la modélisation des décisions, la liste de ses éléments et les forces et limites énoncées de son emploi.
• OMG (Object Management Group), Decision Model and Notation (DMN), version 1.5, Clause 6 (Requirements): le graphe et le diagramme des exigences de décision, les quatre types d'éléments (décision, donnée d'entrée, modèle de connaissance métier, source de connaissance) et les trois exigences (information, connaissance, autorité) qui les relient.