Les règles métier passent en premier

Récemment, des collègues et moi-même avons discuté avec le développeur de logiciels en chef d’une grande organisation cliente des progrès réalisés dans le cadre d’un important effort de réingénierie. Notre préoccupation était de savoir si les membres de l’équipe de projet pouvaient respecter un délai d’environ neuf mois pour la livraison d’un prototype à grande échelle. Nous venions de passer plusieurs mois intensifs à développer un modèle commercial complet, et il leur restait encore plusieurs mois de conception du système à terminer.

Ce développeur en chef est très pointu — pas du genre à s’engager à répondre à la légère. Pendant longtemps, il n’a rien dit, perdu dans ses pensées. Enfin, en regardant les diagrammes commerciaux détaillés plâtrés sur les murs tout autour, il a déclaré: “Si nous avions déjà commencé à coder, je dirais que nous n’avions aucune chance. Mais comme nous n’avons pas encore commencé à coder, je dirais que les chances sont plutôt bonnes.”

J’ai dû courir cela plusieurs fois dans mon esprit avant de comprendre son sens. “Si nous avions déjà commencé à coder, je dirais que nous n’avions aucune chance.”

Je savais qu’il pensait que le codage de l’application lui-même allait être assez difficile. Cela impliquerait l’utilisation d’un moteur de règles, d’un réseau de distribution mondial, d’interfaces utilisateur graphiques et d’un middleware important.

Il disait que s’ils devaient résoudre tous les problèmes commerciaux pendant le codage, ils ne le réussiraient jamais à temps — ou probablement jamais. Cependant, étant donné que l’équipe du projet s’attaquait dès le départ aux problèmes métier difficiles (y compris la spécification des règles métier), il pensait qu’ils avaient de très bonnes chances de terminer le code à la date cible.

Dans une large mesure, l’approche des règles métier consiste simplement à poser les bonnes questions aux bonnes personnes. Il n’y a qu’une seule façon de respecter honnêtement un délai — et c’est de résoudre d’abord le problème de l’entreprise.

IT axée sur l’entreprise

Dans les premiers jours de la construction de systèmes d’entreprise, le côté commercial pouvait essentiellement s’asseoir et simplement les laisser se produire. Les avantages de l’automatisation étaient si convaincants que vous ne pouviez pratiquement pas vous tromper. Maintenant, à toutes fins pratiques, les affaires et l’informatique fonctionnent de manière indissociable. Lors de la réalisation de projets, l’étape logique serait alors de mettre en place des équipes de projet métier / TI transparentes et de les faire suivre une approche orientée métier pour développer les exigences. Pourtant, de nombreuses entreprises sont loin de le faire aujourd’hui.

Trop souvent, le côté commercial produit encore des “exigences” floues et mal ciblées, et le côté informatique continue de faire des “exigences” seulement un cran ou deux au-dessus de la programmation. Comment éliminer cet écart entre les professionnels de l’entreprise et les professionnels de l’informatique dans le développement des exigences?

La réponse est relativement simple. L’entreprise a besoin d’une approche organisée qui permet aux professionnels de piloter le développement des exigences. Cette approche doit fournir une feuille de route qui montre comment poser les bonnes questions sur les bonnes choses au bon moment. Ce qu’il faut, c’est une approche axée sur l’entreprise.

Dans les approches de développement traditionnelles, beaucoup de choses sont généralement perdues dans la traduction des exigences initiales au système en cours d’exécution. Mais la rédaction d’un ensemble de règles métier claires améliore les communications entre le côté métier et l’informatique, et fournit un pont entre l’analyse métier et la conception du système. L’approche des règles métier permet de combler l’écart d’exigences entre le côté métier et le côté informatique.

Alors, qu’est-ce qu’une règle métier ? Du point de vue commercial, il s’agit d’une directive destinée à influencer ou à guider le comportement. Les règles métier sont littéralement la connaissance codée de vos pratiques commerciales. D’un point de vue informatique, une règle métier est un élément atomique de logique métier réutilisable.

D’une certaine manière, tout le monde sait ce que sont les règles métier — ce sont elles qui guident votre entreprise dans la gestion de ses opérations quotidiennes. Sans règles métier, vous devrez toujours prendre des décisions à la volée, en choisissant entre des alternatives au cas par cas. Faire les choses de cette façon serait très lent.

Les règles nous sont familières dans la vraie vie. Nous jouons à des jeux selon des règles, nous vivons dans un système juridique basé sur un ensemble de règles et nous fixons des règles pour nos enfants. Pourtant, l’idée de règles dans les systèmes d’entreprise est ironiquement étrangère à la plupart des professionnels de l’informatique. Dites “règles” et de nombreux professionnels de l’informatique pensent vaguement aux systèmes experts ou à l’intelligence artificielle. Il y a peu de reconnaissance de la façon dont les règles centrales sont réellement aux opérations quotidiennes de base de l’entreprise.

Ce n’est pas une coïncidence, de nombreux travailleurs et gestionnaires du secteur des affaires sont devenus si bien endoctrinés dans des vues procédurales pour développer des exigences que penser en termes de règles peut sembler étranger ou abstrait. Pratiquement toutes les méthodologies sont coupables à cet égard, que ce soit pour la réingénierie des processus métier, le développement de systèmes ou la conception de logiciels.

Ceci est malheureux pour deux raisons:

1. Penser à toute activité organisée en termes de règles est en fait très naturel. Par exemple, imaginez essayer d’expliquer un jeu comme les échecs, les dames, le baseball ou le football sans expliquer les règles.

2. Les travailleurs et les gestionnaires du secteur commercial ont les connaissances nécessaires pour créer de bonnes règles.

Exemples de règles

Jetez un coup d’œil aux exemples de règles qui suivent et remarquez comment tous les aspects du contrôle opérationnel dans un système d’entreprise peuvent être traités par des règles:

• Restrictions: Un client ne doit pas passer plus de trois commandes urgentes imputées sur son compte de crédit.

• Heuristique: Un client avec un statut privilégié devrait voir ses commandes exécutées immédiatement.

• Calculs : Le volume annuel des commandes d’un client doit être calculé comme le total des ventes clôturées au cours de l’exercice de l’entreprise.

• Inférence : Un client doit être considéré comme préféré s’il passe plus de cinq commandes de plus de 1 000 $.

• Délai : Un client doit être archivé s’il ne passe aucune commande pendant 36 mois consécutifs.

• Déclencheurs: “Envoyer un préavis” doit être exécuté pour une commande lors de l’expédition de la commande.

Les règles s’appuient directement sur des termes et des faits. Les termes – comme le client, l’expédition et la facture — doivent avoir une définition précise et sans ambiguïté dans l’entreprise. Par exemple, le client peut être défini comme: ” Une organisation ou une personne physique qui a passé au moins une commande payée au cours des deux années précédentes.”

Les faits sont donnés par des phrases simples et déclaratives qui relient les termes à un verbe ou à une phrase verbale, telles que “Le client passe commande.”

Un “modèle de faits” est un ensemble d’énoncés de faits qui décrivent les résultats d’une opération commerciale. Un modèle de faits devrait servir de modèle initial pour un modèle de données, mais son objectif principal est de capturer les connaissances sur l’entreprise sous une forme structurée, distillée à partir des travailleurs et des gestionnaires du côté de l’entreprise qui les possèdent.

Les règles ajoutent essentiellement le sens des mots doit ou ne doit pas aux termes et aux faits, comme dans “Les commandes à crédit de plus de 1 000 $ ne doivent pas être acceptées sans une vérification de crédit.”

Les règles doivent être exprimées dans un anglais des affaires clair, sans ambiguïté et bien structuré, en commençant par un sujet explicite. Les règles ne doivent pas avoir de peluches et de faits manquants. Les règles peuvent être qualifiées, comme dans “Un envoi doit être assuré si la valeur de l’envoi est supérieure à 500 $.”Et les règles peuvent inclure des critères de calendrier, comme dans “Un étudiant doit être inscrit à au moins deux cours avant la clôture de l’inscription.”

Indépendance des règles

Une entreprise ressemble beaucoup à un corps humain. La structure de la connaissance (terme et fait) est comme le squelette; les processus sont les muscles puissants; et les règles sont le système nerveux qui contrôle les deux autres. Les trois sont essentiels et interdépendants. Mais les règles métier doivent être distinctes des deux autres. Un principe de base de cette approche est que les règles sont indépendantes des processus et des procédures. Un avantage marginal de cette “indépendance des règles” est une énorme simplification des processus.

Le résultat est un “processus mince”, un objectif de longue date de nombreux professionnels de l’informatique. En supprimant les règles des processus, vous pouvez produire des processus relativement simples et qui peuvent être modifiés selon les besoins.

Dans la Ligue nationale de football, si une pièce ne fonctionne pas pour une équipe, elle disparaîtra de son livre de jeu en quelques matchs. Les pièces sont essentiellement jetées. De même, les entreprises doivent considérer leurs propres procédures comme des déchets — suffisamment bon marché pour les jeter et les remplacer facilement lorsque les procédures ne fonctionnent plus correctement.

Les procédures jetables sont indispensables pour que l’entreprise soit adaptable et compétitive. Cette idée trompeusement simple – rendue possible par l’approche des règles métier — peut révolutionner la façon dont le travail est effectué et les systèmes sont conçus.

Réimprimé avec la permission de Principles of the Business Rule Approach, par Ronald G. Ross (Addison-Wesley, 2003). Ross est co-fondateur et directeur de Business Rule Solutions LLC et rédacteur en chef du site Web BRCommunity.com.

Modèle de fait de bibliothèque
Ce diagramme montre un modèle de fait graphique pour une bibliothèque. Le libellé de la règle est basé directement sur le modèle fact, qui est un diagramme de concepts commerciaux de base – une structure de connaissances. Un modèle factuel peut et doit fournir un modèle de première coupe pour la façon dont les données seront éventuellement organisées dans une base de données. RÈGLE: Une carte de bibliothèque ne peut être utilisée pour consulter un livre que si le livre appartient à une bibliothèque pour laquelle la carte est autorisée.