SAP BRIM a la réputation d’être complexe. En réalité, il est flexible, parfois au point qu’il existe trop de chemins de configuration valides. La complexité n’est généralement pas l’outil lui-même, mais les décisions de conception prises autour de celui-ci.
La plupart des organisations mettent en œuvre la gestion des revenus et de la facturation intelligente (BRIM) pour résoudre un problème urgent (par exemple, la fuite de revenus, la facturation manuelle, la mise à l’échelle des modèles d’abonnement). La rapidité semble essentielle, mais 12 mois plus tard, elles redessinent la logique de tarification, les structures d’événements ou les modèles d’intégration qu’elles jugeaient « suffisants ».
Ce n’est pas parce que BRIM est défectueux. C’est parce que BRIM impose des décisions architecturales difficiles à annuler une fois en production.
Dans la vidéo ci-dessous, Nitish Puttur, architecte en chef des revenus de CLARITY, compare BRIM à une loupe. Il ne crée pas de complexité, mais il révèle des problèmes structurels dans votre modèle de commande-encaissement qui étaient auparavant cachés. Cet article explore les raisons pratiques de cette analogie et ce qu’il faut faire à ce sujet.
Les 3 causes profondes de la complexité de la mise en œuvre de SAP BRIM
Une fois que vous regardez au-delà de la surface, la complexité de la mise en œuvre de SAP BRIM est généralement due aux mêmes schémas sous-jacents. BRIM ne crée pas ces problèmes. C’est là qu’ils deviennent impossibles à cacher parce qu’il se situe au cœur du flux de commande à encaissement.
1) Les équipes conçoivent localement sans alignement de bout en bout
Même avec une architecture propre, les projets BRIM peuvent devenir difficiles lorsque les équipes n’optimisent l’environnement qu’à partir de leur propre bulle opérationnelle.
La Finance se soucie naturellement de la conformité et de la vérifiabilité. Les Ventes se soucient de la rapidité, de la flexibilité et de la conclusion des affaires. L’informatique se soucie de la stabilité et de la réduction des risques. Chaque point de vue a du sens isolément, mais BRIM les connecte, et c’est là que les problèmes commencent.
Un schéma courant consiste à essayer de reproduire la logique traditionnelle des commandes clients au sein d’un modèle de facturation basé sur les événements. BRIM ne regroupe pas tout en un seul « document » comme le font les modules de vente ERP classiques. Il fonctionne en traitant et en regroupant les événements en résultats facturables. Concevoir BRIM comme s’il s’agissait d’un système de commande client est l’un des moyens les plus rapides d’introduire une complexité inutile.
En pratique, l’optimisation locale peut se transformer en complexité globale de plusieurs manières courantes :
- Un modèle tarifaire qui a un sens commercial parfait crée des exceptions de facturation que l’équipe financière ne peut pas gérer facilement
- Un workflow qui aide les ventes à évoluer rapidement introduit des variations difficiles à tester ou à concilier en aval
- Un modèle d’intégration élégant sur le plan technique ajoute une surcharge opérationnelle et ralentit les changements une fois le système en production
C’est pourquoi BRIM bénéficie d’une propriété au niveau de l’architecture, et pas seulement de la gestion de projet. Quelqu’un doit unifier l’ensemble du plan afin que les décisions de chaque équipe fonctionnent ensemble de bout en bout, plutôt que de produire une collection de solutions cloisonnées techniquement « correctes » mais opérationnellement incompatibles.
2) Choix de conception effectués sans vision de l’état futur
Une raison essentielle pour laquelle BRIM peut sembler trop complexe est qu’il offre plusieurs façons d’atteindre le même résultat. Les équipes choisissent naturellement l’option qui correspond le mieux aux exigences actuelles, au budget et aux délais.
Mais comme l’a dit Nitish, un client média pourrait servir un million de clients dans une région aujourd’hui, rendant un choix de conception rentable parfaitement valable. Mais si l’entreprise passe à dix millions de clients dans plusieurs régions au cours des 6 à 12 prochains mois, la refonte sera bien plus coûteuse que de concevoir avec les bonnes garde-fous dès le départ.
La réflexion sur l’état futur ne signifie pas construire pour chaque scénario hypothétique. Cela signifie poser quelques questions disciplinées tôt dans la mise en œuvre de SAP BRIM :
- Qu’est-ce qui change au cours des 12 à 24 prochains mois? (régions, canaux, acquisitions, volume de clients)
- Le mix produit va-t-il changer ? (abonnement + utilisation + offres groupées, nouveaux modules complémentaires monétisés)
- Quelles décisions sont intégrées une fois que BRIM est opérationnel ? (modèles de tarification, gestion des événements, modèles d’intégration, flux de travail de gouvernance)
Les équipes de projet qui évitent la complexité incontrôlée ne sont pas celles qui tentent de concevoir le système parfait dès le premier jour. Ce sont celles qui font des choix de conception délibérés avec une compréhension claire de ce qui doit être mis à l’échelle.
3) Votre architecture existante est déjà trop complexe
BRIM se situe généralement entre plusieurs systèmes en amont et en aval : des outils de front-office qui capturent les commandes et les contrats. Cela fait de BRIM le point où les incohérences finissent par se rencontrer.
L’analyse sectorielle des programmes “order‑to‑cash” met en évidence le même schéma : les silos système et les données fragmentées sont constamment cités comme les principaux points faibles, aux côtés des problèmes de facturation complexe et des modifications de contrat en cours difficiles à concilier entre les plateformes CRM, de facturation et financières.
Si les systèmes en amont produisent des données de contrat incohérentes par marché, ou si les événements d’utilisation arrivent dans des formats différents, BRIM devient le premier endroit où ces différences doivent être réconciliées en résultats facturables.
C’est pourquoi les équipes décrivent souvent des problèmes liés à SAP BRIM qui donnent l’impression que BRIM ne fonctionne pas, alors qu’en réalité, BRIM expose des différences de données, de définitions et de propriété qui existaient bien avant son introduction.
Une façon utile de l’appréhender est de considérer les symptômes par rapport aux causes :
- Symptôme: Les factures ne correspondent pas aux attentes
- Cause probable : la logique de tarification existe en dehors d’un système gouverné (feuilles de calcul, étapes manuelles), ou les définitions de produit/contrat diffèrent selon la région/le canal.
- Symptôme : Les changements prennent une éternité, même lorsqu’ils semblent « petits »
- Cause probable : trop de dépendances entre les systèmes intégrés, des droits de décision peu clairs ou des modèles de conception qui nécessitent des modifications à plusieurs endroits.
- Symptôme : La première version fonctionne, mais la mise à l’échelle échoue
- Cause probable : la solution a été conçue pour le volume/les marchés d’aujourd’hui, sans tenir compte de la croissance future.
C’est pourquoi ce que les clients appellent la « complexité SAP BRIM » est généralement une complexité de paysage. BRIM est le système qui impose une réponse de bout en bout à des questions telles que : où se trouve la logique de tarification ? Qui est propriétaire des définitions de produits ? Quelle est la source de vérité pour l’utilisation ? Si ces questions ne sont pas claires, BRIM transforme cette incertitude en friction opérationnelle.
Une liste de contrôle pratique pour réduire la complexité de BRIM avant qu’elle ne s’aggrave
Si votre programme SAP BRIM vous semble trop complexe, le moyen le plus rapide de reprendre le contrôle est de cesser de traiter la complexité comme un problème de configuration BRIM et de commencer à la traiter comme un problème de conception de bout en bout et de modèle opérationnel.
Cette simple checklist est conçue pour faire exactement cela. Vous pouvez l’utiliser au début d’un programme BRIM, ou en cours de projet si vous constatez des signes avant-coureurs.
1) Vérifications de l’architecture et de la propriété (obtenir le plan détaillé, pas seulement le plan)
Les projets BRIM rencontrent des difficultés lorsque les décisions sont prises de manière isolée.
Avant la finalisation du design, assurez-vous de pouvoir répondre à la question suivante :
Qui possède l’architecture de la commande à l’encaissement de bout en bout ?
Pas « qui dirige le projet », mais qui a les droits de décision sur les systèmes et les équipes
Où les limites système sont-elles définies (et acceptées) ?
Ce qui appartient au front-office (CRM/CPQ/commerce), ce qui appartient à BRIM et ce qui appartient à la finance
Qui approuve les changements qui affectent les résultats de facturation ?
Tarification, structures de produits, plans tarifaires, définitions d’événements, règles de facturation et la gouvernance qui les entoure
À quoi ressemble le « bon » fonctionnement une fois en service ?
Qui gère la tarification ? Qui gère les exceptions ? Quel est le processus de modification ?
Attention à ce signe d’alerte :
si le seul mécanisme d’alignement est les mises à jour de statut hebdomadaires, vous avez probablement un plan de projet, pas un plan d’architecture.
2) Barrières de l’état futur
Vous n’avez pas besoin de prévoir toutes les exigences. Mais vous avez besoin d’une vue partagée de ce qui est susceptible de changer afin que les choix de conception précoces ne deviennent pas des contraintes coûteuses plus tard.
Utilisez ces invites :
- Échelle : Qu’adviendra-t-il des volumes au cours des 12 à 24 prochains mois ? (clients, événements d’utilisation, factures)
- Marchés : De nouvelles régions sont-elles prévues ? Existe-t-il des exigences différentes en matière de conformité ou de facturation par marché ?
- Modèle commercial: La tarification va-t-elle évoluer ? Des offres groupées, des modules complémentaires ou des éléments basés sur l’utilisation sont-ils probables ?
- Gamme de produits : Restez-vous « logiciel uniquement », ou le matériel, les services et les partenaires intègrent-ils le modèle ?
- Modèle opérationnel : Davantage d’équipes devront-elles apporter des changements plus fréquemment ?
Ensuite, traduisez ces réponses en simples règles de prudence :
- Qu’est-ce qui devra évoluer sans refonte
- Qu’est-ce qui peut être intentionnellement simple pour la phase un
- Ce qui doit rester réversible
C’est ainsi que vous réduisez la complexité de la mise en œuvre de BRIM à partir de zéro, sans sur-ingénierie.
3) Réalisme des données et de l’intégration
BRIM est souvent là où les problèmes de données deviennent visibles, car c’est là que des entrées disparates se transforment en sorties facturables. Si vous voulez moins de problèmes SAP BRIM, traitez la qualité des données en amont et la conception de l’intégration comme des flux de travail de premier ordre.
Vérifications clés :
- Source de vérité : Pour chaque domaine (produits, contrats, clients, utilisation/événements), existe-t-il une source de vérité claire ?
- Définitions des données : Les champs clés et les concepts sont-ils cohérents entre les marchés/canaux (ID de produit, attributs de prix, conditions contractuelles) ?
- Validation : Où validez-vous et rejetez-vous les données erronées; en amont, lors de l’intégration ou dans BRIM ?
- Complexité de l’intégration : Construisez-vous uniquement ce dont vous avez besoin ? Ou sur-ingénieriez-vous (services, couches et dépendances supplémentaires) ce qui ralentira le changement plus tard ?
- Gestion opérationnelle : Lorsque quelque chose ne va pas, qui le répare — et à quelle vitesse pouvez-vous identifier la cause profonde ?
Méfiez-vous de ce signal d’alarme : si un système ne peut pas « réagir à la volée » aux changements de schéma ou aux entrées incohérentes, vous avez besoin d’une gouvernance en amont. Sinon, BRIM devient l’endroit où vous découvrez les problèmes trop tard.
4) Respect des délais de livraison
Même avec une bonne conception, la complexité s’accroît lorsque le changement n’est pas géré. Deux domaines pratiques à stabiliser rapidement :
- Gouvernance des prix et des taux :
Évitez la prolifération incontrôlée (par exemple, des dizaines se transformant en centaines de grilles tarifaires/plans tarifaires). Définissez des normes de dénomination, la propriété, les flux d’approbation et les cycles de publication.
- Discipline des tests :
Parce que BRIM a un impact sur les flux de trésorerie, les tests ne sont pas facultatifs. Alignez les données de test, les scénarios et la validation entre les équipes métier et informatique, en particulier en ce qui concerne les changements de prix et les exceptions.
C’est là que débutent de nombreuses histoires à problèmes d’implémentation de SAP BRIM : non pas parce que la solution est mauvaise, mais parce que le modèle opérationnel ne peut pas la modifier en toute sécurité.
La complexité s’accroît lorsque des décisions sont prises sans appropriation partagée, sans définitions communes et sans garde-fous pour l’état futur. Mettez-les en place tôt, et BRIM deviendra beaucoup plus facile à mettre en œuvre, à faire évoluer et à exécuter.
Comment garder SAP BRIM simple
S’il y a une idée à retenir de l’analogie de la loupe, c’est que la complexité de SAP BRIM n’est pas toujours causée par BRIM lui-même. Lorsque BRIM est invité à s’asseoir sur des frontières floues, des données incompatibles, des prises de décision en silo et des choix de conception qui n’ont pas été faits pour une mise à l’échelle future, c’est là que les fissures apparaissent.
L’avantage est que la flexibilité de BRIM le rend extrêmement réparable. Mais vous ne le réparez pas en y ajoutant plus de configuration. C’est ainsi que vous aggravez les choses. Vous le réparez en étant plus réfléchi lors de l’élaboration de votre plan, en définissant la propriété et en modifiant la discipline.
Un plan d’action simple que vous pouvez utiliser immédiatement
1) Établissez le plan avant que la construction ne se rigidifie
Faites ceci en premier, même si vous êtes déjà en plein milieu d’un projet :
- Écrivez les limites du système en langage clair : ce qui appartient au front office, ce qui appartient à BRIM et ce qui appartient aux finances
- Désigner un propriétaire d’architecture de bout en bout unique (droits de décision, pas seulement de coordination)
- Convenir de la « source unique de vérité » pour les produits, les contrats, les clients et l’utilisation/les événements
2) Mettre en place des garde-fous autour des décisions à fort enjeu
Considérez-les comme des engagements à long terme sur lesquels il est plus difficile de faire marche arrière :
- Modèles de tarification/notation
- Structure de l’événement + approche de validation
- Modèles d’intégration (les maintenir aussi simples que le permet le modèle opérationnel)
- Gouvernance des modifications de prix/catalogue/plan tarifaire
Si un changement nécessite plusieurs équipes, plusieurs systèmes ou plusieurs approbations à chaque fois, vous créez une complexité future pour vous-même.
3) Ajuster le modèle opérationnel pour éviter la complexité
BRIM échoue généralement sur le plan opérationnel lorsque le changement n’est pas géré. Mettez de la discipline autour de :
- Gouvernance des tarifs : propriété, désignation, versioning, cadence de publication (éviter l’étalement des grilles tarifaires)
- Discipline des tests : approbation interfonctionnelle des changements ayant un impact sur la facturation (les changements de prix ne devraient pas être une question d’« espérer et déployer »)
- Gestion des exceptions : définir qui résout les problèmes de données en amont et où ils sont résolus. Ne laissez pas BRIM devenir un dépotoir
N’oubliez pas : vous n’avez pas besoin de tout résoudre en une seule fois. La meilleure chose à faire est d’identifier la catégorie qui vous pose le plus de problèmes, puis de traiter la cause, et non le symptôme.
Prêt à réduire la complexité de SAP BRIM ?
Si BRIM semble trop complexe, la meilleure façon d’avancer est d’identifier l’origine de cette complexité. S’agit-il de l’architecture, des données, de la propriété ou des choix de conception ? Vous devez trouver et corriger la cause profonde avant qu’elle ne s’aggrave.
Vous ne savez pas par où commencer? Réservez un examen de la complexité de BRIM avec un expert CLARITY.