Les règles de gestion enfouies dans un univers BO se retrouvent en croisant la structure de l’univers, les objets utilisés par les rapports Web Intelligence, les conditions SQL et les écarts constatés lors des réconciliations. La documentation technique seule ne suffit pas : une règle peut résider dans un objet, un contexte, une jointure ou un filtre invisible au lecteur du rapport.
En bref
- Un univers BO ne traduit pas seulement des tables en libellés métier : il porte souvent des filtres, des calculs et des restrictions qui modifient directement les chiffres publiés.
- La priorité consiste à identifier les objets réellement consommés dans les rapports Webi, plutôt qu’à relire l’intégralité d’un univers devenu trop vaste.
- Une condition d’objet, un contexte de requête ou une jointure externe peuvent expliquer un écart de chiffre d’affaires, de marge ou de volume sans apparaître dans le rapport final.
- La règle retrouvée doit être réécrite en langage métier, reliée à son implémentation technique et validée sur un échantillon de données daté.
- Une reprise vers Power BI ou une autre cible ne doit pas viser une identité théorique des chiffres, mais une tolérance d’écart documentée et acceptée.
Ce dossier s’adresse aux responsables BI et chefs de projet qui doivent auditer un parc SAP BusinessObjects 4.x avant une reprise d’univers ou de rapports. Il traite des univers relationnels créés dans Universe Design Tool ou Information Design Tool, et non de la négociation de licences, de la protection des données personnelles ou du paramétrage d’une architecture cloud.
Où les règles de gestion se cachent-elles dans un univers BO ?
Dans Business Objects, une connexion décrit l’accès technique à une source relationnelle ou OLAP. L’univers se place au-dessus de cette connexion et fournit la couche sémantique utilisée par les concepteurs de rapports. Cette séparation explique une difficulté récurrente en audit : le libellé d’un objet paraît métier, alors que sa définition peut contenir une logique SQL qui limite, transforme ou exclut une partie des données.
Un objet nommé « Chiffre d’affaires net » peut, par exemple, soustraire des avoirs, ignorer certaines écritures provisoires ou ne retenir qu’un statut de facture donné. Le nom de l’objet ne dit pas quel statut est exclu, ni quelle date de référence est utilisée. La règle existe pourtant, active à chaque extraction, tant que l’objet reste employé dans un rapport.
La documentation officielle SAP consacrée à la plateforme BI et à ses composants reste le premier point de contrôle pour identifier les fonctions disponibles selon la version installée. La documentation produit publiée sur SAP Help Portal, consultée le 12 mars 2026, distingue bien les univers, les connexions et les fonctions d’administration du référentiel. Elle ne remplace pas la lecture de votre fichier UNV ou UNX.
Les objets, les conditions et les contextes portent des décisions métier
Une règle de gestion est une contrainte ou une logique opérationnelle qui conditionne un calcul, une sélection ou une action. Dans un univers BO, elle n’est pas nécessairement identifiée comme telle. Elle peut être répartie entre une condition prédéfinie, une expression SQL d’objet, une clause WHERE, une fonction de base de données ou une table dérivée.
Les conditions d’objet constituent le premier point à examiner. Lorsqu’un filtre de statut client est posé dans la condition de l’objet et non dans le rapport Webi, le lecteur ne le voit pas dans les filtres du document. Il constate seulement que la population affichée est plus faible que celle extraite directement depuis la table source. C’est le type d’écart qui fait croire à une erreur de modélisation alors qu’il s’agit d’une décision fonctionnelle ancienne.
Les contextes jouent un rôle différent. Ils déterminent le chemin de jointure à utiliser lorsqu’un univers contient plusieurs chemins possibles entre des tables. Un univers de vente peut proposer un contexte « commande », un contexte « facture » et un contexte « livraison ». La mesure retenue change alors avec le contexte actif. Une addition de montants facturés dans le contexte commande peut multiplier les lignes si la granularité n’est pas maîtrisée.
Les jointures externes doivent être relues avec la même prudence. Une jointure gauche peut conserver les ventes sans référentiel client complet. Une jointure interne les écarte. Ce choix est rarement neutre dans une analyse de portefeuille ou de chiffre d’affaires. Il faut donc relever la jointure exacte, son sens, les clés utilisées et le comportement attendu pour les lignes orphelines.
| Emplacement dans l’univers BO | Règle potentiellement enfouie | Effet observable dans un rapport | Vérification à mener |
|---|---|---|---|
| Objet mesure | Calcul de montant net ou arrondi appliqué en SQL | Écart entre total Webi et somme brute de la table source | Comparer la formule SQL de l’objet à la définition financière validée |
| Condition d’objet | Exclusion d’un statut, d’une société ou d’une période | Population réduite sans filtre visible dans Webi | Exporter la clause WHERE et tester sa suppression sur un jeu borné |
| Contexte | Choix du chemin entre commande, facture et livraison | Doublons ou variation de granularité | Tracer les jointures activées pour chaque requête utilisée |
| Table dérivée | Pré-agrégation, filtre historique ou consolidation | Impossible de rapprocher directement le résultat d’une table physique | Conserver la requête complète et sa date d’exécution |
Ce tableau a été construit à partir des mécanismes documentés pour les univers relationnels SAP BusinessObjects et des contrôles de reprise habituellement nécessaires sur les univers UNV et UNX. Il doit être appliqué avec la version exacte de votre plateforme, car le mode de conception diffère entre Universe Design Tool et Information Design Tool.
La CMC donne une vue utile sur les univers et connexions publiés dans le référentiel. Elle ne donne pas une explication métier de leurs objets. Les connexions relationnelles sont créées dans UDT ou IDT, tandis que la CMC permet notamment d’administrer les éléments publiés et de créer certaines connexions OLAP. Cette distinction évite de chercher une règle dans la console alors qu’elle se trouve dans le fichier de conception local.
Comment repérer les rapports qui révèlent les règles de gestion cachées ?
La bonne unité de départ n’est pas l’univers entier. C’est le rapport effectivement consulté, puis la requête qui l’alimente, puis l’objet d’univers appelé par cette requête. Un univers peut contenir plusieurs centaines d’objets, dont une part n’est plus utilisée. Documenter tous les objets avant de connaître les usages conduit à consacrer des semaines à des classes abandonnées.
Commencez par obtenir les traces d’usage sur douze mois glissants. Les logs d’audit permettent de distinguer un document ouvert chaque jour d’un rapport trimestriel. Ils doivent toutefois être interprétés avec prudence. Une rétention limitée à quatre-vingt-dix jours rend invisibles les documents utilisés lors des clôtures, des campagnes budgétaires ou des contrôles annuels.
Il faut donc compléter les statistiques techniques par les calendriers métier. Un rapport consulté trois fois par an peut porter une règle plus sensible qu’un tableau ouvert quotidiennement. Les documents de consolidation, de budget ou de calcul de provisions entrent souvent dans cette catégorie. Leur faible fréquence ne justifie pas leur abandon.
Relier l’usage Webi à la structure de l’univers
Pour chaque rapport retenu, établissez une fiche courte. Elle comporte le propriétaire identifié, la fréquence de consultation, la requête Webi, les objets sélectionnés, les filtres visibles, les invites et la sortie attendue. Il faut y ajouter le nom de l’univers, sa version publiée, la connexion utilisée et la date du dernier rafraîchissement significatif.
Le rapport ne doit pas être lu comme une page mise en forme. Il doit être lu comme une chaîne de décisions. Une variable Webi peut masquer une transformation effectuée après l’extraction. Une rupture ou une section peut agrandir artificiellement une impression de total. Un filtre de rapport peut s’ajouter à une condition définie dans l’univers. La règle réelle est la combinaison de ces niveaux.
Les objets de type dimension demandent autant d’attention que les mesures. Une dimension « Client actif » peut être fondée sur une date de dernière commande, une segmentation marketing ou un statut administratif. Si cette définition est reprise sans analyse dans un nouveau modèle sémantique, la cible reproduira une étiquette sans savoir quel comportement elle désigne.
Les invites sont également déterminantes. Une invite sur la période peut imposer une liste de valeurs qui exclut les périodes de régularisation. Une invite sur la société peut être liée à une sécurité de profil. L’utilisateur croit choisir librement un périmètre, mais l’univers peut limiter la liste avant même que la requête parte vers la base.
- Extrayez les statistiques de consultation et conservez la période de rétention des logs dans le dossier d’audit.
- Classez les rapports par fréquence, propriétaire, criticité de décision et dépendance à une clôture ou à un cycle budgétaire.
- Relevez les requêtes Webi des documents conservés, sans vous limiter aux objets visibles dans le tableau final.
- Remontez de chaque objet vers sa définition dans l’univers, sa table dérivée éventuelle, ses jointures et son contexte.
- Rédigez la règle en termes métier avant de décider si elle doit être reprise, modifiée ou abandonnée.
Cette démarche révèle souvent des rapports fantômes. Ils possèdent une planification active, une instance historique ou un propriétaire disparu, mais aucun usage décisionnel démontrable. Ils ne doivent pas être migrés par défaut. L’archivage du document, de ses instances et de son SQL est souvent préférable à la reprise d’une logique devenue incompréhensible.
Le même tri s’applique aux sorties vers une cible différente. La question de la reprise des documents Web Intelligence dans un format paginé mérite un traitement spécifique, car la mise en page et les invites ne se convertissent pas mécaniquement. Le dossier consacré au passage de Webi vers les rapports paginés Power BI permet d’isoler ce chantier de la seule récupération des règles contenues dans l’univers.
Le classement des usages n’autorise pas à conclure qu’un rapport peu consulté est inutile. Il permet de décider quels documents méritent une analyse complète avant la reprise. Le rapport qui déclenche une écriture comptable ou valide un budget reste prioritaire, même si trois personnes seulement l’ouvrent.
Comment extraire et documenter une règle de gestion depuis un objet BO ?
Une règle retrouvée n’est exploitable que si elle existe sous deux formes. La première est métier, lisible par le contrôle de gestion, la finance ou le responsable opérationnel. La seconde est technique, reliée à l’objet, à la condition, à la jointure ou à la variable qui la met en œuvre. Sans ce double enregistrement, la règle disparaît à la prochaine évolution de l’univers.
La formulation doit être non ambiguë. « Le chiffre d’affaires net exclut les factures annulées et les avoirs, et retient la date de comptabilisation pour le mois de clôture » est vérifiable. « Le chiffre d’affaires est nettoyé » ne l’est pas. Une documentation utilisable indique aussi les exceptions et le propriétaire qui peut confirmer ou faire évoluer la règle.
Construire une fiche qui survive au chantier de migration
Chaque fiche peut commencer par un identifiant stable, tel que RG-VENTE-014. Elle porte ensuite le libellé métier, la population concernée, la formule attendue, les sources utilisées, les exclusions, le niveau de granularité et le responsable de validation. La référence technique vient après : univers, classe, objet, condition, contexte, variable Webi et rapport consommateur.
La non-redondance doit être vérifiée. Deux objets de noms différents peuvent appliquer le même filtre de société, avec une syntaxe SQL légèrement distincte. Inversement, deux objets nommés « Marge nette » peuvent utiliser des coûts de référence différents. Le rapprochement des libellés ne suffit pas. Il faut comparer le SQL généré et les résultats sur le même périmètre de données.
La stabilité compte aussi. Une règle budgétaire peut changer à chaque cycle annuel, tandis qu’une règle de rattachement comptable peut rester stable plusieurs années. Mélanger les deux dans une même expression SQL rend les évolutions difficiles à tracer. Il est préférable de documenter la date de validité et la source de la décision, même si la mécanique reste dans l’univers historique pendant la transition.
| Champ de documentation | Contenu attendu | Preuve associée | Risque si le champ manque |
|---|---|---|---|
| Définition métier | Formulation testable, avec inclusions et exclusions | Validation du propriétaire fonctionnel datée | Interprétations divergentes pendant la recette |
| Implémentation BO | Nom de l’univers, classe, objet, condition ou contexte | Export de la définition SQL et version publiée | Impossible de localiser la logique à reprendre |
| Granularité | Facture, ligne, commande, client ou mois | Jeu de test identifié et requête d’extraction | Doublons ou pertes lors de l’agrégation |
| Cas d’exception | Statuts exclus, valeurs nulles, ajustements manuels | Résultat comparé avant et après application de la règle | Écart découvert après la bascule |
Les contrôles de cohérence fournissent de bons candidats de règles à documenter. Un total par département qui doit correspondre à un total global, une alerte sur un écart inhabituel par rapport à l’historique ou une conversion de devise à un taux déterminé relèvent tous d’une logique explicite. Dans un univers BO, cette logique peut être répartie entre des objets de mesure, des variables Webi et des traitements en amont.
Les contrôles de droits doivent être distingués des règles de calcul. Une restriction de sécurité peut empêcher un utilisateur de voir une société sans changer le total technique de la requête exécutée par un compte d’administration. Pendant l’audit, il faut donc conserver l’identité ou le profil utilisé pour chaque test. La protection des données personnelles et la sécurité des accès dépassent ce dossier : elles relèvent de votre DPO et de votre responsable sécurité.
La documentation doit aussi nommer ce qui n’a pas été établi. Lorsqu’aucun propriétaire métier ne confirme le sens d’un objet, la fiche doit porter le statut « à arbitrer ». Reprendre une règle non validée comme si elle était certaine revient à déplacer l’incertitude dans le nouveau socle. Le coût de cette décision apparaît rarement dans le budget initial, mais il se retrouve dans les anomalies de recette.
La règle documentée ne doit pas être confondue avec la requête SQL qui l’implémente. Une requête peut changer de forme lors de la migration, tandis que la décision métier doit rester identifiable, testable et rattachée à un propriétaire.
Comment vérifier qu’une règle d’univers explique réellement un écart de données ?
Une hypothèse technique ne devient pas une règle validée parce qu’elle paraît plausible. Elle doit expliquer un écart mesuré sur un périmètre fixe. La méthode la plus sûre consiste à choisir une période close, une ou plusieurs sociétés, une granularité précise et un jeu de documents connus. Le résultat historique, le résultat obtenu sans la règle et le résultat obtenu avec la règle sont alors comparés.
Le double run reste la méthode la plus lisible pour un comité de pilotage. L’ancien rapport et la cible sont exécutés sur la même extraction figée, avec des filtres datés et une liste d’exceptions. L’objectif n’est pas de promettre que chaque cellule sera identique. Il est de distinguer les écarts attendus, les écarts expliqués et les écarts qui bloquent la bascule.
Calculer une charge de récupération sans masquer la recette
Le volume d’objets ne donne pas à lui seul une charge de travail. Une classe peut contenir vingt objets descriptifs très proches, ou cinq mesures portant chacune une logique SQL complexe. Il faut classer les éléments par complexité, puis chiffrer séparément l’inventaire, la lecture, la rédaction, la validation et les tests.
Un exemple borné permet de rendre le budget discutable. Prenons un univers contenant 180 objets réellement appelés par des rapports actifs. L’hypothèse de travail retient 110 objets simples à 45 minutes de lecture et documentation, 50 objets intermédiaires à 1 heure 30, et 20 objets complexes à 4 heures, notamment lorsqu’ils mobilisent une table dérivée, un contexte ou une condition imbriquée.
Le calcul donne 82,5 heures pour les objets simples, 75 heures pour les objets intermédiaires et 80 heures pour les objets complexes. La récupération initiale représente donc 237,5 heures. Il faut y ajouter 30 % pour les validations métier, les corrections de documentation et les tests d’extraction, soit 71,25 heures. L’enveloppe devient 308,75 heures, arrondie entre 300 et 320 heures, hors reconstruction des rapports, reprise des droits, formation et recette complète de la cible.
Ces ratios sont une hypothèse de chiffrage pour cet exemple, pas un tarif ni une norme éditeur. Ils sont pertinents lorsque le SQL généré est accessible, que les propriétaires métier sont disponibles et que les rapports actifs ont été identifiés. Ils deviennent insuffisants si les logs sont incomplets, si la base source a été remplacée plusieurs fois ou si les objets appellent des procédures stockées non documentées.
| Catégorie d’objet | Volume retenu | Ratio de récupération | Charge calculée |
|---|---|---|---|
| Objet simple sans condition intégrée | 110 | 0,75 heure par objet | 82,5 heures |
| Objet intermédiaire avec calcul ou filtre | 50 | 1,5 heure par objet | 75 heures |
| Objet complexe avec contexte, table dérivée ou SQL imbriqué | 20 | 4 heures par objet | 80 heures |
| Validation et tests ciblés | Ensemble des 180 objets | 30 % de la charge d’analyse | 71,25 heures |
Le résultat ne permet pas de décider que les objets complexes doivent tous être repris. Il permet de poser une question plus utile : quel rapport les utilise, quel processus métier en dépend et qui confirme encore son utilité ? Lorsque vingt objets complexes ne servent qu’à quatre rapports non consultés depuis un cycle annuel complet, leur archivage peut être plus raisonnable qu’une reconstruction.
Les écarts doivent être consignés par type. Un écart de population provient souvent d’un filtre ou d’une jointure. Un écart de montant peut venir d’un arrondi, d’une devise, d’une date de référence ou d’une agrégation. Un écart de doublon signale fréquemment une granularité différente. Cette classification accélère l’analyse et évite de corriger une mesure alors que le défaut vient du modèle de jointure.
La reprise d’un parc BusinessObjects vers une cible Microsoft sépare deux dépenses souvent mélangées : la charge de récupération et le coût des licences. Le calcul des heures ne dit rien du prix de la cible. Pour ce second arbitrage, l’analyse du coût d’une migration BusinessObjects vers Power BI doit être menée à part, avec l’unité de facturation et les tarifs publics relevés à la date de décision.
Dans quel ordre reprendre les règles de gestion avant une migration Business Objects ?
La récupération des règles ne doit pas attendre la phase de recette. À ce stade, les développeurs ont déjà construit une partie de la cible et les responsables métier découvrent trop tard les exclusions portées par l’univers BO. L’ordre de travail doit partir des sorties consommées, remonter vers les objets, puis revenir vers des cas de test approuvés.
La première décision concerne le périmètre. Un univers avec 900 objets n’impose pas la reprise de 900 objets. Les objets non consommés, les classes doublonnées et les rapports abandonnés doivent être identifiés avant tout travail de modélisation. À l’inverse, un objet peu visible peut alimenter plusieurs documents stratégiques et mérite une priorité élevée.
Traiter les objets selon leur risque de réconciliation
Les mesures financières, les règles de période, les statuts de gestion et les conversions de devises passent en premier. Elles ont une incidence directe sur les totaux comparés pendant le double run. Les dimensions descriptives viennent ensuite, sauf lorsqu’elles déterminent une sécurité, une segmentation ou une hiérarchie utilisée pour les agrégations.
Les règles qui contrôlent les étapes d’un processus métier doivent être isolées. Une séquence de validation budgétaire, une restriction de modification après soumission ou une répartition de coûts indirects peuvent être implantées dans un flux amont, dans l’univers ou dans un rapport. Le nouvel outil ne doit pas recevoir une spécification vague du type « reprendre le contrôle existant ». Il doit recevoir une condition vérifiable, son action attendue et son traitement d’exception.
Une matrice de priorité aide à éviter les arbitrages au fil de l’eau. Les règles à priorité haute combinent un impact financier, une forte consommation ou une difficulté technique. Les règles à priorité moyenne peuvent être traitées dans la vague suivante. Les règles non confirmées restent hors périmètre de reconstruction jusqu’à décision explicite, avec conservation de la preuve issue du socle historique.
- Traitez d’abord les mesures de clôture, les calendriers de gestion et les filtres qui modifient la population analysée.
- Reprenez ensuite les contextes, les jointures et les tables dérivées qui déterminent la granularité de l’extraction.
- Documentez séparément les variables Webi, car elles peuvent compléter ou contredire la logique contenue dans l’univers.
- Placez les objets non utilisés dans un registre d’archivage, avec leur définition et leur dernière trace de consommation.
- Faites valider chaque règle prioritaire sur des données de référence avant de construire le test de recette complet.
La cible ne doit pas reproduire les défauts du socle précédent sous prétexte de continuité. Une condition créée en 2009 pour contourner une anomalie source peut ne plus avoir de raison d’être. Pourtant, la supprimer sans validation peut modifier un indicateur suivi depuis des années. La bonne décision consiste à qualifier l’origine de la règle : règle métier toujours valable, contrainte technique disparue, contournement temporaire ou logique non attribuée.
Sur un parc de moins de cent rapports, dont une grande part n’est plus consultée, la reconstruction d’un modèle sémantique limité est souvent préférable à la reprise exhaustive d’un univers BO. L’arbitrage s’inverse lorsque plusieurs centaines de rapports actifs dépendent de règles non documentées et de calculs déjà validés par les métiers. Dans ce cas, la récupération structurée réduit le risque de découvrir les écarts après la bascule.
Le choix de la cible reste distinct de cette analyse. Si une partie du parc dépend de BW, la reprise des définitions et des objets doit être coordonnée avec le chantier de passage de SAP BW vers BW/4HANA, sans confondre les règles portées par les requêtes BW avec celles qui résident dans l’univers Business Objects.
Avant d’ouvrir un chantier de conversion, exportez les univers publiés, les requêtes des rapports réellement consommés et les logs d’audit sur douze mois glissants. Vérifiez surtout leur durée de rétention. Toute estimation de charge et toute stratégie de recette dépendront de ce périmètre réel.
Le dossier complet Recette & réconciliation : prouver que les nouveaux chiffres valent les anciens
