BusinessObjects conserve sa place dans SAP lorsque les univers, les rapports Web Intelligence et les droits CMC portent encore des règles de gestion utilisées. SAP Analytics Cloud constitue la cible privilégiée pour certains usages SAP, mais il ne reprend pas automatiquement le patrimoine existant. La décision dépend d’abord de l’usage réel, puis de la charge de reconstruction et de recette.
En bref
- BusinessObjects BI 4.3 reste une plateforme de reporting et de diffusion adaptée aux parcs où Web Intelligence, Crystal Reports et les univers IDT sont encore fortement sollicités.
- L’intégration avec SAP BW, SAP HANA et les bases relationnelles explique la persistance de nombreux socles, mais elle crée aussi des dépendances techniques qu’il faut inventorier avant toute bascule.
- SAP Analytics Cloud répond mieux aux besoins de planification et de tableaux de bord connectés aux produits SAP récents, sans constituer une reprise automatique des univers BusinessObjects.
- Power BI, Qlik Sense, Cognos Analytics et Oracle Analytics peuvent être des alternatives, à condition de comparer les fonctions de reporting, le modèle sémantique, les droits et le coût de reconstruction.
- Un parc peu consulté ne mérite pas toujours une migration. La suppression documentée et la reconstruction ciblée coûtent parfois moins que la reprise de chaque rapport.
Ce contenu s’adresse aux responsables BI, aux DSI et aux chefs de projet qui doivent arbitrer l’avenir d’un environnement SAP BusinessObjects. Il traite du reporting, des modèles sémantiques et de la recette décisionnelle ; les sujets de sécurité, de protection des données personnelles et de négociation contractuelle relèvent respectivement de vos équipes compétentes.
Quelle place BusinessObjects conserve-t-il dans l’écosystème SAP ?
BusinessObjects occupe encore une place opérationnelle dans de nombreux systèmes SAP, même lorsque la feuille de route applicative s’oriente vers des services plus récents. Cette place ne tient pas seulement à l’ancienneté de la plateforme. Elle tient aux objets que les équipes ont construits autour d’elle : univers, classes, objets, conditions, contextes de requête, documents Web Intelligence, publications, profils de sécurité et planifications.
Dans un environnement BI 4.3, Web Intelligence reste fréquemment le point d’accès à des rapports de gestion produits à partir de sources SAP BW, SAP HANA ou relationnelles. Crystal Reports conserve également un rôle particulier pour les documents mis en page, les éditions réglementaires ou les sorties très formatées. Lumira, lorsqu’il est encore présent dans un parc, doit être distingué de Web Intelligence : les usages, les dépendances et les possibilités de reprise ne sont pas les mêmes.
La plateforme BusinessObjects ne se réduit donc pas à des tableaux de bord. Elle constitue souvent une couche de diffusion entre le système source et des utilisateurs qui ne connaissent ni les structures BW ni les tables relationnelles. L’univers masque la complexité technique, impose des jointures, expose des dimensions et porte parfois des règles métier. Un filtre de statut client posé dans une condition d’objet, et non dans le rapport Web Intelligence, peut modifier le chiffre visible sans apparaître dans la liste des filtres du document.
Cette mécanique explique pourquoi le remplacement d’un outil ne doit pas être confondu avec le remplacement d’un écran. Reproduire une visualisation est une tâche. Retrouver les règles enfouies dans un univers IDT, dans une requête BEx ou dans une variable BW en est une autre. Les deux charges ne se calculent pas avec le même ratio.
Les composants qui rendent une sortie plus ou moins coûteuse
La Central Management Console, ou CMC, est souvent le premier élément sous-estimé. Elle organise les utilisateurs, les groupes, les niveaux d’accès, les dossiers, les connexions et les planifications. Une cible peut proposer une gestion des droits solide, mais son modèle d’autorisation ne correspond pas nécessairement aux objets techniques de BusinessObjects. Il faut donc rapprocher les rôles existants des rôles futurs, et non seulement exporter une liste d’utilisateurs.
Les univers constituent le second point de vigilance. Un univers UNV historique et un univers UNX conçu dans Information Design Tool ne se reprennent pas de manière identique. Le premier peut contenir des conventions anciennes, des listes de valeurs et des restrictions dont la lecture est plus difficile. Le second formalise mieux certains éléments, sans empêcher l’existence de dépendances non documentées.
Une revue des dimensions dans BusinessObjects aide à établir la différence entre une colonne affichée et une dimension réellement gouvernée par le modèle sémantique. Cette distinction devient déterminante lorsque l’équipe envisage Power BI, Qlik Sense ou SAP Analytics Cloud. Une dimension commerciale, par exemple, peut être calculée dans un objet d’univers, dérivée dans BW ou matérialisée dans une vue HANA. Le rapport ne donne pas toujours la réponse.
La documentation officielle de SAP distingue les informations techniques et les produits couverts par le support à travers son portail SAP Support. Relevé le 18 juin 2026 sur ce portail, le statut de maintenance doit être vérifié à partir de votre produit exact, de son niveau de support package et de votre droit d’accès. Une réponse valable pour SAP BusinessObjects BI 4.3 ne doit jamais être appliquée mécaniquement à BI 4.1 ou BI 4.2.
| Composant BusinessObjects | Fonction dans le socle BI | Point de reprise à vérifier | Risque si l’objet est ignoré |
|---|---|---|---|
| Univers IDT au format UNX | Couche sémantique et accès aux sources | Jointures, contextes, listes de valeurs, restrictions | Mesures recalculées sur un périmètre différent |
| Web Intelligence | Reporting ad hoc, documents diffusés et analyse de données | Variables, requêtes, filtres de rapport, sections et ruptures | Rapport visuellement repris mais fonctionnellement incomplet |
| CMC et sécurité | Gestion des droits, dossiers, planifications et publications | Groupes, héritages, destinataires et profils d’accès | Utilisateurs privés d’un rapport ou exposés à un mauvais périmètre |
| SAP BW ou SAP HANA | Source SAP et logique de calcul amont | Variables, autorisations analytiques, hiérarchies et agrégats | Écart de chiffre attribué à tort à l’outil de restitution |
Le tableau croise les composants, leur fonction, les contrôles de reprise et les conséquences d’une omission. Il repose sur les périmètres fonctionnels décrits dans la documentation SAP consultée le 18 juin 2026 via le portail de support. Il ne remplace pas l’inventaire de votre CMC, qui reste la seule source fiable pour mesurer vos dépendances.
BusinessObjects garde donc une fonction précise : il sert de socle de reporting lorsqu’il porte à la fois la diffusion, la sécurité et une partie de la sémantique. La question suivante porte moins sur la modernité de l’interface que sur le nombre d’objets encore réellement utilisés.
Comment mesurer l’usage réel de vos rapports BusinessObjects avant de décider ?
Le nombre de documents présents dans la CMC ne constitue pas le périmètre d’un chantier. Un dossier peut contenir plusieurs versions d’un même rapport, des essais de recette, des publications abandonnées ou des documents trimestriels invisibles si les logs ne couvrent que quelques semaines. La mesure doit partir de l’usage, mais aussi de la périodicité et de la criticité métier.
Un rapport ouvert tous les jours n’a pas le même poids qu’un document annuel utilisé pendant une clôture. À l’inverse, un document consulté plusieurs fois peut n’être qu’une extraction transitoire créée pour contourner un manque de données dans un autre rapport. Les logs d’audit donnent un signal ; ils ne suffisent pas à décider seuls.
Le premier travail consiste à sortir les événements d’ouverture, d’actualisation, d’export et de diffusion sur douze mois glissants. Cette durée couvre les rapports mensuels, trimestriels et annuels. Si la rétention des données d’audit est inférieure à douze mois, le fichier doit le préciser dans le dossier d’arbitrage. Un taux de consultation calculé sur quatre-vingt-dix jours ne permet pas de déclarer mort un rapport annuel.
Un protocole d’inventaire qui sépare l’usage de la dépendance
Chaque document peut être classé selon quatre critères : activité observée, fréquence attendue, propriétaire métier et dépendance technique. L’activité observée provient des logs. La fréquence attendue est confirmée par le responsable fonctionnel. Le propriétaire désigne la personne ou le service qui accepte la suppression, la reprise ou la réécriture. La dépendance décrit l’univers, la source, la planification et les autres rapports qui réutilisent le même objet.
Un rapport non consulté peut néanmoins être planifié et envoyé à une liste de diffusion. Un rapport non ouvert dans le portail peut être exporté automatiquement vers un répertoire partagé. Un rapport peu ouvert peut aussi fournir les données d’une publication destinée à des destinataires externes au portail. L’analyse des seules ouvertures conduit alors à une suppression erronée.
La démarche détaillée dans cet article sur les rapports BI non consultés fournit un cadre utile pour rapprocher logs, périodicité et validation métier. Le point délicat n’est pas de produire une liste. Il est d’obtenir une décision traçable pour chaque élément qui ne sera pas repris.
- Conservez les rapports dont l’usage est observé et dont le propriétaire confirme le besoin, même si leur présentation doit être reconstruite.
- Mettez en quarantaine les documents sans usage mesuré, mais associés à une diffusion planifiée, à un export ou à une obligation de clôture identifiée.
- Supprimez après validation les doublons, les essais de recette et les rapports sans propriétaire, en gardant une archive exploitable pendant la période convenue.
- Traitez séparément les univers et les connexions partagés, car un rapport supprimé peut dépendre d’un objet encore utilisé ailleurs.
- Inscrivez les règles de gestion récupérées dans un registre, avec la source, la formule, le périmètre et le responsable de validation.
La plupart des erreurs de périmètre viennent d’un inventaire confondu avec une extraction technique. Le propriétaire métier doit être sollicité sur les rapports à faible usage, mais il doit répondre à une question précise : « ce document doit-il être maintenu, et pour quelle échéance ? » Une demande générale de validation produit des réponses générales.
Il faut aussi distinguer le document de son contenu. Dix Web Intelligence peuvent reposer sur le même univers et appeler les mêmes objets. La suppression de neuf d’entre eux ne diminue pas automatiquement la charge de reprise du modèle sémantique. Inversement, plusieurs univers très proches peuvent être fusionnés si les règles sont réellement identiques et validées comme telles.
La consolidation n’est pas toujours souhaitable. Lorsque deux directions utilisent la même mesure avec des calendriers, des périmètres ou des règles de reconnaissance différents, une fusion précipitée fabrique un conflit de gouvernance. Le projet doit exposer l’écart, le faire arbitrer et documenter le résultat. Il ne doit pas masquer la différence derrière une mesure portant le même nom.
Un inventaire utile transforme ainsi un parc technique en portefeuille de décisions. Vous saurez alors si l’alternative retenue doit absorber des centaines de documents ou seulement un noyau réellement actif.
Comment l’intégration de BusinessObjects avec SAP BW et SAP HANA influence-t-elle le choix ?
L’intégration entre BusinessObjects et les produits SAP explique une large part de la stabilité des parcs en production. Web Intelligence peut consommer des données issues de SAP BW, de SAP HANA ou de bases relationnelles exposées à travers une connexion. Cette capacité ne garantit pas que chaque source se comporte de la même manière dans une nouvelle cible. Les variables, les hiérarchies, les autorisations et les agrégats doivent être examinés objet par objet.
Dans un environnement SAP BW, un rapport peut dépendre d’une requête BEx, d’une variable obligatoire, d’une hiérarchie temporelle et d’autorisations analytiques. Si la cible interroge un autre niveau de données, la mesure obtenue peut rester plausible tout en couvrant une population différente. Le risque est plus élevé quand la source est remplacée en même temps que l’outil de restitution.
SAP HANA introduit un autre type de dépendance. Les vues de calcul, les colonnes calculées, les invites et les privilèges analytiques peuvent porter des éléments qui n’apparaissent pas dans le document Web Intelligence. Une migration de tableaux de bord doit donc séparer le sujet de la restitution de celui de la préparation des données. Une cible moderne ne corrige pas une règle métier absente ou ambiguë.
Les univers restent une frontière fonctionnelle à cartographier
L’univers est souvent présenté comme une couche technique. Dans les faits, il organise l’accès des utilisateurs à un vocabulaire métier. Une classe « Ventes » peut réunir des objets issus de plusieurs tables. Un contexte de requête peut empêcher des boucles de jointure. Une condition d’objet peut exclure certains statuts. Ces choix ont des effets sur les montants, les volumes et les listes disponibles.
Lors du passage vers un modèle sémantique différent, le travail consiste à identifier ce qui doit être reproduit, ce qui doit être corrigé et ce qui doit être abandonné. La reprise à l’identique n’est pas une règle saine. Une règle créée en 2009, dont le propriétaire n’est plus identifié, mérite une validation avant toute reproduction.
Le contrôle doit porter sur un jeu d’échantillons représentatifs. Il faut sélectionner des périodes ouvertes et clôturées, des populations normales et marginales, des unités organisationnelles actives et inactives, ainsi que des cas avec valeurs nulles. La comparaison ne se limite pas au total général. Elle descend jusqu’aux dimensions qui expliquent l’écart.
Une tolérance chiffrée doit être fixée avant la recette. Elle peut être nulle pour un compteur ou une somme provenant de la même table et du même périmètre. Elle peut être différente lorsque les deux systèmes n’interrogent pas la donnée au même instant ou n’appliquent pas le même niveau d’arrondi. Cette tolérance doit être écrite par mesure, avec son responsable de validation.
| Élément source | Ce qu’il peut porter | Contrôle de recette | Décision possible |
|---|---|---|---|
| Requête SAP BW | Variables, hiérarchies, filtres et calculs | Comparer les sélections, les valeurs de variables et les agrégations | Reprendre, adapter ou retirer après validation métier |
| Vue SAP HANA | Colonnes calculées, jointures et privilèges | Tracer le niveau de détail et les filtres appliqués | Conserver la vue ou déplacer une règle documentée |
| Univers UNX | Objets, contextes, listes de valeurs et restrictions | Relire les définitions et rejouer les requêtes critiques | Recréer un modèle sémantique ciblé |
| Document Web Intelligence | Variables locales, sections, filtres et formats | Comparer le résultat détaillé avant la mise en forme | Reconstruire ou supprimer le document |
Ce tableau ne suppose pas que tous les objets doivent survivre au projet. Il sert à rendre visible le point où se trouve une règle. Le coût de la migration dépend moins du nombre de graphiques que du nombre de règles à comprendre et à faire valider.
La documentation de SAP disponible via SAP Help Portal, consultée le 18 juin 2026, doit être rapprochée de votre version exacte et de vos connecteurs réellement activés. Aucun environnement BusinessObjects n’a été ouvert pour cette analyse. Les contrôles proposés s’appuient donc sur la documentation éditeur et sur les objets qu’un inventaire de plateforme doit produire.
Quand l’intégration SAP est dense, le choix de la cible ne peut pas être réduit à une comparaison d’écrans. Il faut d’abord décider quelle couche portera demain les règles qui sont aujourd’hui réparties entre BW, HANA, univers et documents.
Dans quels cas SAP Analytics Cloud remplace-t-il utilement BusinessObjects ?
SAP positionne SAP Analytics Cloud comme une plateforme SaaS destinée à l’analyse, aux tableaux de bord et, selon les licences et scénarios retenus, à la planification. Cette orientation ne signifie pas que SAP BusinessObjects devient immédiatement inutilisable ou que les rapports Web Intelligence peuvent être convertis automatiquement. Les deux plateformes répondent à des besoins proches sur certains périmètres, mais leurs objets et leurs modèles de travail restent différents.
SAP Analytics Cloud est cohérent lorsque l’organisation souhaite rapprocher analyse de données, planification et connexion aux systèmes SAP récents. Une connexion directe à SAP HANA ou à BW/4HANA peut réduire certaines extractions intermédiaires, à condition que les modèles, autorisations et performances soient validés. Ce bénéfice éventuel ne dispense pas de la recette. Il déplace le point de contrôle.
BusinessObjects garde une meilleure continuité lorsque le parc repose fortement sur Web Intelligence, sur des documents très formatés ou sur une diffusion industrielle déjà stabilisée. Une bascule vers SAC demande souvent de reconstruire les tableaux de bord, de redéfinir les modèles de données et de reformer les utilisateurs. L’univers BusinessObjects ne devient pas, par conversion automatique, un modèle prêt à exploiter dans SAP Analytics Cloud.
La planification justifie parfois un chantier, pas toujours l’ensemble du parc
La planification est l’un des cas où SAP Analytics Cloud peut apporter une réponse fonctionnelle différente. Lorsqu’une direction utilise des fichiers, des exports ou des traitements annexes pour collecter des hypothèses, consolider des versions et suivre un cycle budgétaire, un outil réunissant saisie et analyse peut modifier l’organisation du processus. Le sujet dépasse toutefois la reproduction d’un rapport.
Il faut alors isoler le périmètre concerné. Migrer vingt tableaux de bord de pilotage peut être justifié par un besoin de planification documenté. Migrer quatre cents documents Web Intelligence uniquement parce que la nouvelle plateforme existe ne l’est pas automatiquement. La charge de reconstruction, la formation et la recette doivent être comparées au besoin réellement couvert.
Les coûts de licence SAC dépendent des métriques et des contrats SAP. Aucun tarif public universel et exploitable pour tous les environnements n’est présenté ici, car la valeur dépend des droits acquis, de l’unité de souscription et du périmètre de service retenu. La négociation et l’interprétation contractuelle relèvent de vos achats et de votre direction juridique. Le dossier de décision doit néanmoins isoler le coût récurrent des licences, le coût de construction et le coût de maintien en double run.
Un double run ne consiste pas à afficher deux écrans. Il consiste à exécuter, pendant une période convenue, les rapports source et cible sur des dates, filtres et jeux de données comparables. Les écarts sont relevés, classés et attribués : règle métier changée, filtre absent, donnée chargée à une heure différente, arrondi, droit d’accès ou défaut de conception. Une bascule ne doit intervenir qu’après acceptation formelle des écarts résiduels.
Un calcul de charge peut être posé sans promettre un résultat. Sur un parc de 240 documents, supposons que 60 % soient des Web Intelligence à faible complexité, 25 % des rapports intermédiaires et 15 % des documents complexes ou très diffusés. Avec une hypothèse de 2 à 4 heures de reconstruction fonctionnelle pour un document faible, 6 à 10 heures pour un document intermédiaire et 16 à 28 heures pour un document complexe, la reprise des documents représente entre 936 et 1 704 heures.
Le calcul est visible : 144 documents multipliés par 2 à 4 heures donnent 288 à 576 heures ; 60 documents multipliés par 6 à 10 heures donnent 360 à 600 heures ; 36 documents multipliés par 16 à 28 heures donnent 576 à 1 008 heures. Cette fourchette exclut l’inventaire, la reprise des droits, la reconstruction des modèles, la recette, le double run, la formation et la conduite du changement. Les ratios sont des hypothèses de cadrage, non un engagement de projet.
À ce volume, une migration intégrale vers SAC doit être découpée par usage. Il est plus défendable de reconstruire un périmètre de planification et de conserver temporairement les rapports opérationnels dans BusinessObjects que de promettre une conversion uniforme du parc.
Quelles alternatives à SAP BusinessObjects comparer pour le reporting et les tableaux de bord ?
Les alternatives à BusinessObjects doivent être évaluées à partir du patrimoine à reprendre, et non à partir d’un classement de produits. Un outil peut être convaincant pour les tableaux de bord interactifs tout en restant moins adapté à un reporting paginé, à une diffusion planifiée complexe ou à une sécurité fondée sur des groupes très détaillés. La cible doit être comparée à vos usages, vos sources et vos règles de gestion.
Power BI apparaît souvent dans les consultations lorsque l’organisation utilise déjà l’écosystème Microsoft. Il couvre la restitution interactive et propose des rapports paginés dans certains scénarios. La comparaison avec BusinessObjects doit porter sur le modèle sémantique, la distribution, les capacités nécessaires et l’effort de réécriture des variables Web Intelligence. Un rapport qui dépend de plusieurs requêtes, de ruptures, de sections et de calculs locaux ne se transpose pas par copier-coller.
Qlik Sense constitue une autre option lorsque les équipes recherchent une exploration associative et un modèle de données différent. Le choix doit être testé sur des cas concrets : analyse de données par les métiers, diffusion encadrée, volumétrie, actualisation et droits. Une démonstration produit ne révèle pas les écarts entre une condition d’univers BusinessObjects et une règle reconstruite dans une application Qlik.
IBM Cognos Analytics, Oracle Analytics et WebFOCUS peuvent aussi entrer dans le périmètre d’une consultation, notamment quand le besoin porte sur du reporting d’entreprise structuré. La lecture de l’architecture et des fonctionnalités de WebFOCUS peut aider à distinguer un outil de diffusion de rapports d’un outil orienté exploration. Cette comparaison ne dispense pas de vérifier la compatibilité avec vos sources SAP et avec vos pratiques de sécurité.
Le comparatif doit partir des objets actifs, non des fonctionnalités annoncées
| Cible envisagée | Usage à tester face à BusinessObjects | Objet source à examiner | Cas où le choix doit être reconsidéré |
|---|---|---|---|
| SAP Analytics Cloud | Tableaux de bord SAP, planification et connexions aux produits SAP récents | Univers UNX, documents Web Intelligence et processus de planification | Parc dominé par le reporting formaté et les publications complexes |
| Microsoft Power BI | Analyse interactive, diffusion et rapports paginés selon le périmètre souscrit | Mesures, variables WebI, droits et besoins de capacité | Modèle sémantique non documenté ou exigences de diffusion non testées |
| Qlik Sense | Exploration, applications analytiques et usages associatifs | Dimensions, hiérarchies, scripts de préparation et règles d’accès | Besoin prioritaire de documents figés très mis en page |
| Cognos Analytics ou Oracle Analytics | Reporting d’entreprise et modèle gouverné | Rapports critiques, sécurité et connectivité aux sources | Écart de licence ou de reprise supérieur au périmètre réellement actif |
Le comparatif entre Power BI, Qlik Sense et BusinessObjects doit donc être lu comme un point de départ pour cadrer les critères, pas comme une réponse unique. Les tarifs publics, lorsqu’ils existent, doivent être relevés sur les pages éditeurs à la date de votre consultation, avec l’unité de facturation, la capacité concernée et la mention « hors remise négociée ».
Un test de cible pertinent porte sur un petit lot contrasté. Il doit inclure un tableau de bord fréquemment consulté, un rapport Web Intelligence à variables, un rapport contenant une hiérarchie, une diffusion planifiée et un document dont le résultat est contrôlé par la direction financière. Ce lot expose les difficultés réelles sans engager immédiatement tout le parc.
Le coût de migration ne se limite pas à la construction. Il comprend l’analyse des univers, les mappings, la reprise des droits, la recette, la documentation, la formation et la période de coexistence. Un chiffrage qui oublie ces postes est trop bas par construction. L’article consacré au coût d’une migration de BusinessObjects vers Power BI permet d’isoler plus finement les postes à mettre dans un budget.
Sur un parc inférieur à cent rapports dont une large part n’est plus consultée, la reconstruction ciblée est souvent plus défendable que la reprise exhaustive. Au-delà de trois cents documents actifs, avec des règles de gestion peu documentées et une diffusion stabilisée, conserver temporairement BusinessObjects pendant une migration par vagues devient plus prudent. L’arbitrage s’inverse lorsque les dépendances métier sont plus coûteuses à redécouvrir qu’à maintenir.
Dans quel ordre organiser une migration BusinessObjects sans fragiliser le reporting ?
Le premier livrable utile n’est pas une maquette de tableaux de bord. C’est un périmètre signé, fondé sur l’inventaire des documents, des univers, des sources, des planifications et des propriétaires. Sans ce point de départ, le projet additionne des demandes de reprise au fil de l’eau et ne peut plus mesurer son avancement.
Le second livrable est un registre de règles de gestion. Chaque règle doit indiquer où elle a été trouvée, quel objet elle affecte, quelle population elle exclut, qui la valide et dans quelle cible elle sera implantée. Une formule repérée dans une variable Web Intelligence n’a pas le même statut qu’une règle validée par le métier. Cette différence doit apparaître dans la recette.
Une migration par vagues facilite la preuve et l’arbitrage
- Extrayez les logs d’usage sur douze mois et contrôlez leur durée réelle de rétention avant de qualifier les rapports inactifs.
- Rapprochez chaque rapport actif d’un propriétaire, d’une source, d’un univers et d’un mode de diffusion documenté.
- Classez les documents par complexité fonctionnelle, non par nombre d’onglets ou par qualité graphique.
- Construisez un lot pilote contenant des cas représentatifs, y compris un document financier et un rapport à diffusion planifiée.
- Réalisez la recette détaillée, mesure par mesure, avant de comparer la mise en forme ou l’ergonomie.
- Organisez un double run avec des critères de bascule écrits et des écarts expliqués, acceptés ou corrigés.
La recette doit produire un dossier lisible par la finance comme par l’équipe BI. Pour chaque mesure critique, il faut conserver le résultat ancien, le résultat cible, l’écart absolu, l’écart relatif, la période, les filtres et l’explication. Un écart de 0,4 % n’est ni acceptable ni inacceptable par nature. Il doit être rapporté au montant, à la règle concernée et à la tolérance approuvée.
Une situation fréquente survient lorsqu’un total est exact au niveau global mais faux par dimension. Une jointure dupliquée peut être compensée par un filtre au total, alors que le détail par client ou par produit reste erroné. C’est la raison pour laquelle la recette doit descendre à des échantillons détaillés. Un contrôle limité au chiffre de synthèse ne protège pas la bascule.
La documentation des versions constitue également un point de calendrier. Avant toute décision, vérifiez votre produit, son support package et l’échéance correspondant à votre contrat dans les versions et dates de support SAP BusinessObjects. La page doit être revue régulièrement, car les conditions de maintenance publiées par l’éditeur peuvent évoluer. Une date affichée dans un ancien dossier projet ne doit pas servir de référence sans vérification.
Les alternatives ne doivent pas être jugées sur une promesse d’identité parfaite des chiffres. Elles doivent être évaluées sur leur capacité à produire des résultats réconciliés, avec des écarts identifiés et acceptés. Cette discipline protège autant le futur outil que la crédibilité de l’équipe qui le déploie.
Avant de lancer une consultation ou de demander un budget, sortez les logs d’audit, recensez les univers et faites confirmer les rapports de clôture par leurs propriétaires. Tout le dimensionnement du chantier dépend de ces trois éléments.
SAP BusinessObjects est-il remplacé automatiquement par SAP Analytics Cloud ?
Non. SAP Analytics Cloud et BusinessObjects ne partagent pas le même modèle d’objets. Les univers, rapports Web Intelligence, droits et planifications doivent être analysés puis reconstruits ou retirés selon leur usage et leur criticité.
Pourquoi un univers BusinessObjects doit-il être audité avant une migration ?
Un univers peut contenir des jointures, des contextes, des conditions d’objet, des listes de valeurs et des restrictions qui influencent directement les résultats. Ces règles ne sont pas toujours visibles dans le rapport Web Intelligence.
Peut-on supprimer un rapport BusinessObjects non consulté ?
Pas sur la seule base d’un log récent. Vérifiez la durée de rétention, les diffusions planifiées, les exports et la périodicité annuelle ou trimestrielle. La suppression doit être validée par un propriétaire métier identifié.
Quelle alternative choisir entre SAP Analytics Cloud, Power BI et Qlik Sense ?
Le choix dépend des rapports actifs, des sources SAP, de la planification, des exigences de diffusion, des droits et de la charge de réécriture. Un lot pilote comprenant des documents critiques est plus fiable qu’une comparaison de fonctionnalités génériques.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
