ODM (IBM)
ODM ou Operational Decision Manager est un système de gestion de règles métier développé par l'entreprise IBM permettant la prise de décisions opérationnelles intelligentes en combinant l'utilisation de règles métier automatisées et la détection de changement[1].
Il est utilisé dans de nombreux secteurs, notamment la finance, la santé, les télécommunications et les services publics, où les décisions rapides sont essentielles pour maintenir une position concurrentielle et garantir la conformité réglementaire.
Règle et événement métier
[modifier | modifier le code]Règle métier
[modifier | modifier le code]Une règle métier est une déclaration de logique utilisée pour prendre une décision métier, souvent sous la forme d'un énoncé si-alors. Cet énoncé de logique fait généralement partie d'une politique commerciale.
Exemple : Si l'utilisateur est une femme, alors accorder les adjectifs au féminin.
Les règles peuvent être déclinées sous la forme d'un tableau décisionnel ou encore d'un arbre de décision (selon la structure la plus adaptée). Elles sont organisées sous la forme de flux de règles (ruleflow en anglais) afin de déterminer l'ordre et les conditions de déclenchement.
Événement métier
[modifier | modifier le code]Un événement métier est un signal ou un ensemble de signaux indiquant qu'un changement d'état s'est produit. Le traitement des événements permet de déterminer si une action doit se produire en conséquence d'un évènement, et éventuellement l'exécution de cette action.
Exemple : Si l'événement de retrait d'un client sur son compte fait chuter le solde en dessous de zéro, une action est alors entreprise pour informer ce client.
Fonctionnement du système
[modifier | modifier le code]ODM est une implémentation d'un système de gestion de règles métier. Il permet la création, la gestion, le test et la gouvernance de règles métier et d'événements et les stocke dans un référentiel central où ils peuvent être consultés par plusieurs personnes ou logiciels. Le stockage central des règles et des événements signifie qu'ils peuvent être modifiés sans avoir à reconstruire le logiciel, et avec un cycle de test réduit, et les différents produits logiciels prendront cette modification simultanément.
Les éléments principaux sont :
Les règles d'action : une règle de base exprimée sous forme logique, indiquant que si une condition se produit, une action doit en résulter.
- Exemple : Si une transaction par carte de crédit se produit en dehors du pays du client, alors le client doit être appelé pour confirmer que la carte n'est pas utilisée frauduleusement.
Les tables de décision : un tableau qui permet de déterminer la valeur de sortie d'une règle en fonction de différents critères d'entrée.
- Exemple : Une entreprise de prêt détermine le taux d'assurance d'un prêt en fonction du montant et de la cote de crédit du client. Si un client du groupe B demande un prêt de 250 000 $, la règle indique que le taux d'assurance doit être de 0,002%
Les flux de règles : les règles à exécuter dans un ordre précis.
- Exemple : Une compagnie d'assurance veut déterminer si un conducteur devrait recevoir une police d'assurance particulière. La décision dépend de l'âge du demandeur, de l'historique des infractions au code de la route et des accidents passés, ainsi que d'autres facteurs. Les règles doivent être définies dans un ordre spécifique pour prendre la décision appropriée.
Les fiches de notation : un modèle statistique qui attribue une partition numérique à un objet, tel qu'un client ou un compte.
- Exemple : Un score est attribué à un emprunteur en fonction de son âge, de sa nationalité et de sa cote de crédit. Le score détermine si l'emprunteur peut être approuvé pour un prêt.
Les événements : si un changement d'état spécifique se produit, un message est émis qui a provoqué la survenue d'un événement.
- Exemple : Si un client essaie de retirer des fonds, mais que cela fait tomber son compte en dessous de 0 € et que cela est autorisé, la transaction sera autorisée. Sinon, la transaction sera refusée et un événement sera émis, ce qui nécessitera l'envoi d'un message au client pour l'informer qu'il a été refusé et indiquer la raison.
En combinant les règles métier et les événements au sein du même système, deux technologies complémentaires sont utilisées pour automatiser les décisions en temps réel. Un événement peut déclencher l'exécution d'une règle, et inversement, le résultat d'une décision prise par une règle peut émettre un événement.
Composants du système
[modifier | modifier le code]Les deux composants principaux du système sont :
- Decision Center : c'est l'interface graphique de conception et de gestion des règles métier. Il permet aux utilisateurs de créer, tester et définir des règles métier à l'aide d'une interface intuitive.
- Decision Server : c'est le composant exécuteur du système ODM. Il prend en charge l'évaluation des règles métier et leur exécution dans des applications métier.
Ces deux composants sont essentiels pour la mise en œuvre d'un système de gestion des décisions basé sur les règles métier. Avec Decision Center, les utilisateurs peuvent concevoir et gérer les règles métier, tandis que Decision Server fournit une exécution rapide et efficace des règles métier dans les environnements de production. En plus de ces composants, ODM peut être étendu avec d'autres composants selon les besoins des utilisateurs.
Notes et références
[modifier | modifier le code]- (en-US) « What is Operational Decision Manager », sur www.ibm.com (consulté le )
Liens
[modifier | modifier le code]- Site d'IBM
- Documentation officielle d'ODM, documentation en anglais.
- IBM Operational Decision Management, page Wikipédia en anglais.