Beaucoup de consultants fonctionnels SAP passent à côté d’un levier important développé avec S/4 HANA. Ils ignorent que cet outil les concerne directement.
Cet article te montre pourquoi BRF+ mérite une place dans ta boîte à outils.
L’essentiel
- BRF+ est un moteur de règles métier intégré à SAP, manipulable par un fonctionnel sans écrire d’ABAP
- Tu le croises déjà dans S/4HANA Output Management, FSCM, GTS, MDG, Workflow flexible
- Maîtriser BRF+ te permet d’éviter une partie significative des specs ABAP que tu rédiges aujourd’hui
- C’est un marqueur de posture senior reconnu par les architectes S/4HANA
1. Le réflexe ABAP qui coûte cher au projet
Tu es en atelier client. Le métier exprime un besoin : « selon le type de client, le pays de livraison et le montant de la commande, on veut déclencher tel ou tel circuit d’approbation. »
Beaucoup de consultants fonctionnels enchaînent automatiquement : « Ok, je rédige une spec, on demande à un développeur de coder ça. »
C’est un réflexe, pas une analyse. Et dans une majorité de cas, BRF+ aurait permis de modéliser cette logique sans dev, avec un délai de mise en oeuvre divisé par trois et la possibilité pour le métier de modifier les règles en autonomie ensuite.
Le marché attend aujourd’hui des fonctionnels qui savent identifier ce qui relève d’une règle paramétrable et ce qui relève d’un développement custom. Cette capacité de tri devient un critère de séniorité.
À éviter en mission
Demander une spec ABAP sans avoir vérifié si BRF+ couvre le besoin. Tu alourdis le projet, tu ralentis le délai et tu crées une dépendance technique pour chaque future évolution de la règle.
2. BRF+ en clair : qu’est-ce que c’est vraiment
BRF+ signifie Business Rule Framework plus. C’est un moteur de règles métier intégré au noyau SAP, accessible via la transaction BRFPLUS sur SAP GUI ou via des applications Fiori dédiées sur S/4HANA.
Pour bien comprendre ce qu’il est, le plus simple est de le situer entre deux mondes que tu connais déjà.
| Approche | Logique stockée où | Modifiable par qui | Transport requis |
|---|---|---|---|
| Code ABAP custom | Dans un programme | Développeur | Oui, à chaque évolution |
| Customizing classique (tables T) | Dans des tables de paramétrage | Fonctionnel, mais structure figée | Oui |
| BRF+ | Dans des objets de règles versionnés | Fonctionnel, structure flexible | Selon le mode (transport ou modification directe) |
BRF+ se positionne comme un compromis intelligent. Il offre la flexibilité du code (logique conditionnelle complexe, calculs, branchements) avec la maintenabilité du paramétrage (modifiable sans dev, versionné, auditable).
Le point clé à retenir : BRF+ n’est pas un module SAP. C’est un framework transverse utilisé par d’autres composants SAP pour exécuter leurs règles métier. Tu ne « fais pas du BRF+ » comme tu « fais du SD ». Tu utilises BRF+ pour configurer une partie spécifique d’un module.
3. Où tu vas le croiser en mission
Si tu travailles sur un projet S/4HANA récent, tu as déjà manipulé du BRF+ sans le savoir. Voici les terrains où il est devenu standard.
| Domaine SAP | Cas d’usage typique BRF+ |
|---|---|
| S/4HANA Output Management | Détermination des sorties (factures, bons de livraison) qui remplace NAST |
| FSCM Credit Management | Règles de scoring crédit, déclenchement de blocages |
| FSCM Dispute Management | Routage automatique des litiges selon nature et montant |
| GTS | Classification douanière, contrôle des sanctions |
| MDG (Master Data Governance) | Validations de données et workflows d’approbation |
| Workflow flexible S/4HANA | Approbation commandes, factures, demandes d’achat |
| Substitutions et validations FI | Remplaçant progressivement OB28, GGB0, GGB1 |
Cette liste n’est pas exhaustive. SAP étend l’usage de BRF+ à chaque release, dans la logique du clean core : moins de code custom, plus de paramétrage extensible.
Vu en mission
Sur un projet de migration ECC vers S/4HANA, l’équipe SD avait estimé 12 jours de dev pour reproduire les règles d’output existantes. Un consultant a proposé de tout modéliser dans BRF+ via le nouvel Output Management. Résultat : 4 jours de paramétrage, des règles modifiables par le métier ensuite, et un livrable conforme au clean core attendu par l’architecte.
4. Comment c’est structuré (sans devenir développeur)
BRF+ s’appuie sur quelques objets simples. Tu n’as pas besoin de tous les maîtriser au début. Comprendre les quatre principaux suffit pour lire et concevoir une règle.
L’Application
C’est le conteneur. Une Application BRF+ regroupe toutes les règles d’un domaine fonctionnel. Par exemple, l’Application livrée par SAP pour l’Output Management S/4HANA s’appelle FDP_OUTPUT_MANAGEMENT.
La Function
C’est le point d’entrée que SAP appelle pour exécuter la règle. Elle reçoit des paramètres en entrée (le contexte : type de document, code société, partenaire) et renvoie un résultat (le canal de sortie, le rôle d’approbation, la valeur calculée).
Le Ruleset et la Decision Table
C’est ici que se passe le vrai travail du fonctionnel. Le Ruleset enchaîne les règles, et la Decision Table est le format le plus utilisé pour les exprimer.
Une Decision Table ressemble à un tableau Excel : chaque ligne est une règle, chaque colonne d’entrée est une condition, et la dernière colonne donne le résultat.
Si tu sais lire une table V_T685A pour le pricing SD, tu sais déjà manipuler une Decision Table BRF+. La logique est la même : combiner des critères pour aboutir à un résultat.
Un fonctionnel qui maîtrise BRF+ est un consultant qui résout là où d’autres demandent un dev.
5. Un cas concret : l’Output Management S/4HANA
Prenons un besoin classique pour rendre tout ça tangible.
Le besoin : sur les commandes de vente, déclencher l’envoi par email aux clients du segment « key account » et par impression papier aux autres, en utilisant un formulaire différent pour les ventes intra-groupe.
En ECC, avec NAST : tu paramètres une procédure de message, des conditions d’accès, des tables de conditions, et tu écris souvent une routine ABAP pour les cas non couverts par les clés standards.
En S/4HANA avec BRF+ : tu accèdes à la Decision Table de l’Application Output Management. Tu ajoutes les lignes correspondantes :
- Si segment client = « key account » et type doc = « OR », canal = « EMAIL », formulaire = « STANDARD »
- Si segment client = « intra-groupe », canal = « EMAIL », formulaire = « INTRA_GROUP »
- Sinon, canal = « PRINT », formulaire = « STANDARD »
Le métier peut relire ces lignes sans formation. Si demain le segment « key account » doit aussi recevoir une copie papier, il suffit d’ajouter une ligne. Pas de spec, pas de dev, pas de transport long.
Réflexe consultant
Avant de rédiger une spec ABAP pour une règle conditionnelle, pose-toi la question : « Est-ce que cette logique pourrait tenir dans une Decision Table ? » Si la réponse est oui, BRF+ est probablement la bonne approche.
6. Ce que BRF+ change dans ta posture
L’enjeu n’est pas seulement technique. Maîtriser BRF+ change la façon dont tu te positionnes sur un projet.
Tu deviens autonome sur des sujets qui demandaient un dev. Tu ne dépends plus du planning du développeur pour faire avancer ton paramétrage.
Tu accélères les projets. Une règle qui prenait 5 jours en cycle spec-dev-test prend 1 jour en BRF+. À l’échelle d’un projet, c’est plusieurs semaines gagnées.
Tu parles le même langage que les architectes S/4HANA. Le clean core est une exigence forte chez les clients, et BRF+ est un de ses piliers. Savoir l’utiliser te rend crédible dans les ateliers de design.
Tu te différencies des fonctionnels qui restent au customizing classique. Sur un même CV, deux profils proposant le même module SAP : celui qui maîtrise BRF+ a un argument différenciant immédiat.
À éviter en mission
Sur-modéliser dans BRF+. Tout ne doit pas y passer. Une règle qui change tous les deux ans peut rester en customizing classique. BRF+ se justifie quand la logique est complexe, conditionnelle, ou amenée à évoluer souvent.
7. Plan d’action pour monter en compétence
Tu n’as pas besoin d’une formation longue pour démarrer. Suis cette progression sur quelques semaines.
- Active BRF+ sur un environnement de test. Lance la transaction BRFPLUS sur ton sandbox SAP. Vérifie que tu peux accéder à l’interface Workbench.
- Lis une règle existante. Ouvre l’Application FDP_OUTPUT_MANAGEMENT en S/4HANA, navigue dans une Function et sa Decision Table. Comprends comment SAP a structuré ses règles standards.
- Construis une Decision Table simple. Crée ta propre Application de test, ajoute une Function avec deux paramètres en entrée, modélise trois ou quatre lignes de règles. L’objectif est de comprendre le geste, pas de produire du code livrable.
- Documente ce que tu as fait. Note les transactions utilisées, les pièges rencontrés, les manipulations qui t’ont posé problème. Ce document devient ton premier livrable BRF+ référençable.
- Identifie un cas réel sur ta mission actuelle. La prochaine fois qu’une demande de spec ABAP arrive, vérifie si BRF+ pourrait couvrir le besoin. Propose-le à l’architecte. Même si ça n’est pas retenu, tu auras montré que tu sais identifier l’option.
La courbe d’apprentissage est rapide. En une dizaine d’heures de pratique, tu peux lire confortablement les règles standards SAP et concevoir des règles simples toi-même.
La question à te poser maintenant : sur ta prochaine mission, combien de specs ABAP pourrais-tu éviter en proposant une approche BRF+ ?
Tu veux savoir où tu en es sur ces sujets ?
Si tu te demandes quels sont les outils qui font vraiment la différence dans ton positionnement de consultant SAP, on peut en discuter directement. Un échange concret, sans filtre commercial, pour cadrer ce qui te ferait avancer.