La bascule de SAP BW vers BW/4HANA ne consiste pas à convertir une base SAP HANA et à relancer les chaînes de processus. Elle impose de retirer des objets non compatibles, de reprendre les flux d’extraction, de requalifier les requêtes et d’accepter des écarts documentés avant la mise en production.
En bref.
- Un système SAP BW 7.5 sur SAP HANA peut suivre une conversion système, mais les objets incompatibles avec BW/4HANA doivent être traités avant la bascule.
- Les DataSources, extracteurs et transformations liés à SAP S/4HANA demandent une revue détaillée, notamment autour d’ODP, des vues ABAP CDS et du modèle ACDOCA.
- La modélisation des données doit être simplifiée sans effacer les règles de gestion que les utilisateurs attendent encore dans leurs requêtes BW.
- La recette ne vise pas une identité automatique des chiffres, mais des écarts mesurés, expliqués et validés selon une tolérance définie.
- Pour un parc volumineux, la conversion peut coûter moins cher qu’une reconstruction ; si une grande part du contenu n’est plus utilisée, l’arbitrage peut s’inverser.
Ce contenu s’adresse aux responsables BI, chefs de projet décisionnel et équipes SAP BW qui préparent une migration vers BW/4HANA depuis BW 7.5. Il traite la reprise du socle décisionnel, des flux et de la recette ; les clauses de contrat SAP, la sécurité des infrastructures et la protection des données personnelles relèvent de vos équipes juridiques, sécurité et DPO.
Pourquoi la migration SAP BW vers BW/4HANA commence par un tri des objets
Le premier sujet n’est pas la durée technique de l’installation. Le premier sujet est la compatibilité réelle de votre patrimoine BW. BW/4HANA repose exclusivement sur SAP HANA et abandonne plusieurs objets historiques de SAP BW, notamment les InfoCubes classiques, MultiProviders, DataStore Objects standard ou objets 3.x encore présents dans les environnements les plus anciens.
SAP décrit les scénarios de conversion et les restrictions d’objets dans sa documentation BW/4HANA, consultée le 18 mars 2026 : documentation officielle SAP BW/4HANA. Cette documentation doit être rapprochée de votre version exacte de BW 7.5, de votre niveau de Support Package et de la version SAP HANA utilisée. Une réponse valable pour BW 7.5 sur HANA ne l’est pas pour BW 7.5 sur une autre base.
La conversion demande en pratique un inventaire qui ne se limite pas aux objets techniques. Un InfoProvider peut ne plus être alimenté tout en restant utilisé comme source d’une requête BEx, d’une requête consommée dans Analysis for Office ou d’un rapport Web Intelligence. Supprimer cet objet parce qu’il paraît ancien peut casser un indicateur financier sans que l’erreur soit visible lors du premier chargement.
Les objets qui bloquent la conversion ne sont pas toujours ceux qui coûtent le plus
Les contrôles de compatibilité identifient les objets qu’il faut convertir, remplacer ou retirer. Cela ne dit pas quelle charge métier se trouve derrière eux. Un MultiProvider peu complexe peut être remplacé par un CompositeProvider. À l’inverse, une requête BEx courte peut contenir des variables clients, des exits ABAP, des restrictions de devise et des calculs de période dont personne n’a formalisé les règles.
La bascule devient risquée lorsque le projet traite l’incompatibilité comme une liste de tâches purement techniques. Le chantier doit croiser quatre informations : l’objet BW concerné, son niveau de compatibilité BW/4HANA, son usage réel et le propriétaire métier capable de valider le résultat. Sans ce croisement, vous obtenez un système techniquement converti, mais difficile à faire accepter.
| Objet SAP BW observé | Situation dans BW/4HANA | Travail de reprise attendu | Risque de recette |
|---|---|---|---|
| InfoCube classique | Non retenu comme modèle cible | Reprise vers un modèle Advanced DataStore Object et CompositeProvider | Élevé si les agrégats ou calculs historiques sont peu documentés |
| MultiProvider | À remplacer | Reconstruction dans un CompositeProvider et vérification des jointures | Élevé sur les clés de jointure et les enregistrements non appariés |
| DataStore Object standard | À analyser selon l’usage | Conversion ou refonte en Advanced DataStore Object | Moyen si les transformations et clés techniques sont maîtrisées |
| Requête BEx avec variables et exceptions | Conservable sous conditions | Tests fonctionnels et contrôle des restrictions de calcul | Très élevé pour les indicateurs financiers et de contrôle de gestion |
Ce tableau reprend les familles d’objets documentées par SAP dans le guide de conversion BW/4HANA, consulté le 18 mars 2026 : SAP BW/4HANA conversion guide. Il ne remplace pas le résultat de vos checks de préconversion, car les add-ons, développements ABAP et objets spécifiques modifient le périmètre réel.
Le tri doit aussi intégrer les objets inutilisés. Les logs d’exécution de requêtes sur douze mois, les statistiques d’usage des rapports et les historiques de planification permettent de sortir du périmètre les contenus qui n’ont plus de lecteur. Une requête ouverte une fois par an peut rester nécessaire pour une clôture. Elle doit toutefois être confirmée par son propriétaire avant d’entrer dans la charge.
Sur un parc de moins de cent requêtes dont une moitié n’est plus exécutée et dont les règles sont connues, la reconstruction ciblée mérite d’être comparée à la reprise complète. Au-delà de plusieurs centaines de requêtes contenant des variables, exceptions et structures non documentées, préserver le patrimoine existant devient souvent moins risqué que réécrire chaque logique.
Le livrable à exiger avant tout calendrier est donc une matrice de décision objet par objet, pas une liste d’objets convertibles. Elle doit nommer ce qui est repris, ce qui est abandonné, ce qui doit être redessiné et la personne qui validera chaque ensemble fonctionnel.
Comment SAP S/4HANA modifie les flux qui alimentent BW/4HANA
Une migration BW/4HANA menée en parallèle d’un programme SAP S/4HANA cumule deux changements. Le premier porte sur la cible décisionnelle. Le second porte sur les données extraites depuis l’ERP. C’est ce second mouvement qui explique une part importante des écarts constatés en recette, surtout sur la finance, la logistique et les données de référence.
Le Universal Journal, matérialisé notamment par la table ACDOCA dans SAP S/4HANA, modifie la manière dont les écritures financières et de contrôle de gestion sont structurées. Les rapports qui rapprochaient historiquement FI, CO et CO-PA doivent être relus. La logique qui fonctionnait avec plusieurs extracteurs et des rapprochements dans SAP BW peut devoir être déplacée, refondue ou explicitement conservée.
SAP documente les mécanismes d’extraction basés sur Operational Data Provisioning et les contextes de réplication dans son portail d’aide, consulté le 18 mars 2026 : documentation SAP sur Operational Data Provisioning. Le point de contrôle n’est pas de savoir si ODP existe dans votre paysage. Il faut vérifier quelles sources l’utilisent, quels deltas sont produits et quels traitements BW reposent encore sur un extracteur historique.
Les extracteurs doivent être relus flux par flux
Une DataSource ne se remplace pas uniquement par une vue ABAP CDS portant un nom proche. Le périmètre fonctionnel, les champs fournis, les filtres disponibles et la logique de delta doivent être comparés. Un flux peut charger le même nombre de lignes tout en ne portant plus le même statut, la même unité ou la même clé de partenaire.
Le modèle Business Partner mérite une attention particulière. Dans SAP S/4HANA, plusieurs rôles précédemment séparés peuvent être gérés autour du partenaire commercial central. Les dimensions clients, fournisseurs, groupes de comptes et attributs associés doivent être contrôlés dans la modélisation des données BW. Sans cette revue, les hiérarchies commerciales et les segmentations financières peuvent changer de comportement.
- Recensez chaque DataSource, vue CDS et fournisseur ODP utilisés par les chaînes de processus productives.
- Mesurez les volumes chargés, les taux de rejet et les délais de traitement sur plusieurs cycles réels.
- Comparez les clés fonctionnelles, les longueurs de champs et les domaines de valeurs entre source ancienne et nouvelle.
- Testez les deltas sur une séquence complète comprenant création, modification, annulation et suppression logique.
- Faites valider les hiérarchies de centres de coûts, centres de profit, produits et partenaires avant de comparer les indicateurs.
L’allongement de certains champs, notamment autour des identifiants de matériels ou de documents, paraît technique. Il peut pourtant provoquer une troncature dans une transformation, une clé composite invalide ou un regroupement erroné dans une requête. Les contrôles doivent suivre la donnée depuis la source S/4HANA jusqu’à l’écran de restitution. Tester seulement l’infoprovider ne suffit pas.
La conservation de l’historique impose également un arbitrage. Dans plusieurs programmes S/4HANA, seules certaines données transactionnelles sont reprises dans le nouvel ERP, tandis que SAP BW conserve des périodes antérieures. Les requêtes doivent alors combiner historique et données récentes sans double compte ni rupture de hiérarchie. Cela demande une règle temporelle écrite, par exemple une date de coupure, un périmètre de sociétés et un traitement explicite des corrections tardives.
Une autre difficulté apparaît lorsque les autorisations BW reposent sur des caractéristiques dont le codage évolue dans S/4HANA. La reprise de droits doit être testée à part. La question de la sécurité applicative dépasse le périmètre de cet article ; le contrôle fonctionnel des valeurs autorisées dans les requêtes, lui, fait partie de la recette décisionnelle.
La bonne séquence consiste à sécuriser les flux avant d’accélérer les rapports. Un CompositeProvider bien conçu ne corrige jamais une donnée extraite avec une clé, une hiérarchie ou un delta mal interprété.
Quelle modélisation des données conserver après la bascule vers BW/4HANA
BW/4HANA pousse à revoir des couches de modélisation accumulées au fil des projets. Le risque est double. Conserver chaque couche historique revient à transporter des redondances et des temps de traitement inutiles. Réduire brutalement le modèle peut faire disparaître des contrôles de gestion, des réconciliations ou des règles de calcul qui ne sont écrites nulle part ailleurs.
L’optimisation attendue ne se mesure donc pas au nombre d’objets supprimés. Elle se mesure à la capacité du nouveau modèle à expliquer l’origine d’un indicateur, à charger les données selon une cadence maîtrisée et à répondre aux requêtes critiques dans le délai attendu. SAP HANA apporte des capacités de calcul en mémoire ; elle ne dispense pas de construire des jointures cohérentes ni de traiter les doublons en amont.
Les Advanced DataStore Objects ne remplacent pas une règle de gestion
Les Advanced DataStore Objects permettent de couvrir différents usages, de la couche d’acquisition à la couche de reporting. Leur emploi doit répondre à une fonction identifiable. Une couche peut exister pour gérer un delta, historiser un changement, isoler une correction manuelle ou préparer un jeu de données stable pour les requêtes. Si aucune de ces raisons n’est formulée, l’objet est probablement une duplication à challenger.
Les CompositeProviders concentrent souvent la difficulté. Ils remplacent des MultiProviders, mais la reprise des jointures doit être vérifiée avec les données réelles. Une jointure interne peut exclure des lignes auparavant visibles. Une jointure gauche peut au contraire faire apparaître des enregistrements sans correspondance qui étaient écartés par l’ancien modèle. L’écart ne constitue pas automatiquement une erreur. Il doit être qualifié et accepté.
La performance dépend aussi de la manière dont les requêtes consomment le modèle. Une requête qui charge des milliers de membres de hiérarchie, applique ensuite des filtres et calcule des ratios sur un large périmètre restera coûteuse. La migration doit identifier les requêtes exécutées en clôture, leurs volumes, leurs variables obligatoires et leurs temps de réponse réellement observés.
La documentation SAP BW/4HANA présente les objets de modélisation disponibles et les principes de construction sur SAP HANA ; cette référence a été consultée le 18 mars 2026 : documentation SAP sur la modélisation BW/4HANA. Elle décrit les possibilités du produit, pas la valeur métier de vos couches existantes. Cette valeur doit être établie avec les responsables des domaines finance, ventes, achats ou logistique.
Un chiffrage utile sépare conversion, reprise et recette
Une estimation globale de charge masque les postes qui dérapent. Prenons un périmètre de 240 requêtes BW. L’hypothèse de travail distingue 150 requêtes standard, 60 requêtes avec variables et structures complexes, puis 30 requêtes critiques avec sorties de devise, exceptions, hiérarchies et validation métier renforcée.
En appliquant un ratio de 2 heures de reprise technique par requête standard, 6 heures par requête complexe et 12 heures par requête critique, la reprise des requêtes représente 300 + 360 + 360 heures, soit 1 020 heures. Ce calcul couvre l’analyse de l’objet, son adaptation et un test technique initial. Il exclut la recette métier, la reprise des autorisations, les ajustements de flux, la formation et la correction des anomalies détectées après les premiers tests.
Ces ratios ne sont pas un tarif SAP ni une norme universelle. Ils servent de base de cadrage pour rendre le périmètre discutable. Si les règles sont déjà documentées et si les requêtes ont peu de variables, le ratio peut diminuer. Si le patrimoine contient beaucoup de code ABAP, de routines de transformation et de structures de reporting financières, il doit augmenter.
Le même raisonnement vaut pour les chaînes de processus. Une chaîne courte peut dépendre d’une variante de chargement, d’une étape ABAP et d’une alerte d’exploitation oubliée dans les documents projet. Compter les chaînes sans examiner leurs dépendances produit un budget qui paraît précis mais ne l’est pas.
La modélisation des données doit donc être arbitrée sur l’usage, la traçabilité et la charge de maintenance future. Une réduction d’objets n’a de valeur que si elle laisse intacte la capacité à expliquer le chiffre produit.
Comment organiser la recette BW/4HANA sans promettre des chiffres identiques
La recette de migration ne doit pas promettre que chaque total sera identique entre SAP BW et BW/4HANA. Cette promesse est rarement tenable. Les changements de source, de hiérarchie, de conversion de devise, de calendrier fiscal, de statut métier ou de gestion des valeurs nulles produisent des écarts. Le travail sérieux consiste à les isoler, à les expliquer et à décider lesquels sont acceptables.
Un double run reste le dispositif le plus utile lorsque les indicateurs alimentent des décisions financières ou opérationnelles. Pendant une période définie, l’ancien SAP BW et la cible BW/4HANA exécutent les mêmes sélections sur une extraction de données stabilisée. Le comparatif porte sur les agrégats, mais également sur les détails nécessaires pour remonter à l’origine d’un écart.
Une tolérance ne doit jamais être fixée sans périmètre. Un écart de 0,2 % peut être acceptable sur une estimation commerciale agrégée. Il peut être refusé sur une balance comptable, un rapprochement intersociétés ou une déclaration réglementaire. La tolérance doit donc être liée à l’indicateur, à la période, au niveau de détail et au propriétaire qui signe la validation.
La réconciliation doit partir du détail et non du tableau de bord
Un tableau de bord constitue un mauvais point de départ pour investiguer un écart. Il additionne souvent plusieurs transformations, filtres et calculs. La comparaison doit commencer sur un jeu de données identifiable : société, exercice, période, compte, centre de profit, document ou autre clé de rapprochement adaptée au domaine.
Le protocole doit séparer les écarts de données des écarts de restitution. Un montant différent peut venir d’une extraction S/4HANA incomplète, d’une transformation BW, d’une jointure dans un CompositeProvider ou d’une restriction de requête. Les quatre hypothèses ne se corrigent pas au même endroit. Chercher d’abord dans le rapport ralentit l’analyse.
- Figez une date d’extraction et documentez les sociétés, périodes, devises et versions incluses dans la comparaison.
- Comparez les enregistrements détaillés avant les agrégats, en conservant les clés nécessaires à l’analyse.
- Classez chaque écart entre périmètre, transformation, hiérarchie, règle de calcul, devise ou défaut de chargement.
- Associez un responsable métier et un responsable technique à chaque anomalie encore ouverte.
- Conservez les preuves de validation, les requêtes exécutées et les résultats chiffrés dans un dossier de recette versionné.
La bascule ne devrait pas dépendre d’un simple pourcentage global. Un taux de rapprochement satisfaisant peut masquer un unique indicateur de marge erroné sur une population limitée, mais financièrement significative. À l’inverse, une différence connue sur des données archivées peut être acceptée si elle est tracée et si les utilisateurs concernés disposent d’une consigne claire.
Les écarts de performance doivent être testés séparément des écarts de chiffres. Une requête peut retourner une valeur validée tout en dépassant le temps de réponse admissible lors d’une clôture. Les scénarios de charge doivent refléter les usages réels : exécution simultanée, rafraîchissement de rapports, chargement nocturne et reconstruction d’agrégats métier.
La documentation SAP sur les outils de migration et de conversion BW/4HANA, consultée le 18 mars 2026, doit être utilisée pour préparer les contrôles techniques : référence SAP sur la migration vers BW/4HANA. Elle ne définit pas votre seuil d’acceptation fonctionnel. Ce seuil appartient au projet et doit être approuvé avant la recette finale.
Une mise en production refusée à quinze jours de l’échéance provient souvent d’un écart non expliqué, pas d’un défaut de conversion visible. Le comité de validation doit donc recevoir les écarts ouverts, leur poids financier, leur cause probable et la décision attendue, plutôt qu’un statut global rassurant.
Avant toute date de bascule, exigez un double run sur le cycle métier le plus sensible. Une démonstration sur un mois calme ne prouve rien sur une clôture, une régularisation ou une campagne commerciale à fort volume.
Quand choisir une conversion BW/4HANA plutôt qu’une reconstruction ciblée
La conversion vers BW/4HANA est souvent présentée comme la suite naturelle d’un SAP BW sur SAP HANA. Cette lecture est trop courte. Elle peut être pertinente lorsque le socle porte des centaines de requêtes actives, des règles de gestion anciennes mais toujours utiles et un historique que l’entreprise ne peut pas reconstruire à coût raisonnable. Elle peut être mal adaptée à un environnement surchargé de rapports non consultés et de flux dont les sources ont disparu.
La date de maintenance doit entrer dans l’arbitrage. SAP indique, dans sa stratégie de maintenance produit consultée le 18 mars 2026, que les échéances dépendent de la version exacte et des engagements publiés dans le Product Availability Matrix : SAP Product Lifecycle. Pour SAP BW 7.5, le calendrier de maintenance doit être vérifié dans ce référentiel au moment de votre décision, car SAP publie et met à jour les périodes de support par produit, niveau de version et contrat applicable.
Une date de fin de maintenance ne signifie pas que le système s’arrête ce jour-là. Elle change les conditions de support, de correctifs et de capacité à faire traiter un incident. Pour un socle qui sert la clôture financière, cette contrainte pèse plus lourd que pour une plateforme déjà programmée pour extinction à court terme.
Le périmètre de la migration doit être comparé à la durée de vie attendue
Une conversion complète mobilise les équipes techniques, les référents métier et les responsables d’exploitation. Si le système doit être conservé plusieurs années, cette charge peut être justifiée par la continuité des rapports, de l’historique et des règles existantes. Si la majorité des usages doit migrer vers d’autres restitutions ou si les sources sont déjà remplacées, reprendre chaque couche BW peut créer une double charge inutile.
La présence d’un programme SAP S/4HANA modifie encore l’arbitrage. Refaire des flux BW avant que les extracteurs, les hiérarchies et les données de référence S/4HANA soient stabilisés expose le projet à des reprises successives. Il faut alors séquencer le travail : identifier les flux gelés, isoler les domaines encore mouvants et réserver la recette finale aux données réellement représentatives.
Le terme de transformation digitale apparaît souvent dans les présentations de programme, mais il ne fournit aucun critère de décision pour un socle décisionnel. Les critères utiles sont plus concrets : volume de contenus actifs, qualité de la documentation, compatibilité des objets, dépendance à l’historique, échéance de maintenance et disponibilité des personnes capables de valider les chiffres.
BW/4HANA peut aussi coexister avec l’analytique embarquée de SAP S/4HANA. Les analyses opérationnelles proches de la transaction peuvent être traitées dans l’ERP, tandis que SAP BW conserve les consolidations multi-sources, les historiques et les indicateurs transverses. Cette répartition doit être écrite rapport par rapport. Déplacer une restitution dans S/4HANA sans vérifier les besoins d’historique et de consolidation crée souvent une régression fonctionnelle.
La question de SAP Datasphere peut apparaître dans votre feuille de route. Elle relève d’un choix de cible distinct et d’une analyse de licences, d’exploitation et de reprise des modèles. La documentation SAP présente BW Bridge comme un mécanisme de transition pour certains scénarios ; elle est accessible depuis l’aide SAP, consultée le 18 mars 2026 : documentation SAP Datasphere. Cette piste ne rend pas inutile l’inventaire BW/4HANA, car il faut d’abord savoir quels modèles et flux ont encore une valeur à transférer.
À votre place, un parc de plusieurs centaines de requêtes actives avec un historique financier long, des règles stables et des utilisateurs identifiés justifierait une conversion BW/4HANA structurée. Un parc peu utilisé, mal documenté et déjà largement remplacé par de nouvelles restitutions justifierait plutôt une reconstruction limitée aux usages confirmés, après validation écrite des propriétaires métier.
SAP BW 7.5 peut-il être converti directement vers BW/4HANA ?
Une conversion système est envisageable pour un SAP BW 7.5 reposant sur SAP HANA, sous réserve de traiter les objets non compatibles identifiés par les contrôles de préconversion. Les détails dépendent du niveau exact de BW 7.5, des add-ons et des développements spécifiques.
Les requêtes BEx doivent-elles toutes être réécrites lors d’une migration BW/4HANA ?
Non. Certaines requêtes peuvent être reprises, mais elles doivent être testées avec leurs variables, restrictions, exceptions, structures, conversions de devise et autorisations. Une requête techniquement disponible peut produire un résultat fonctionnellement différent après la bascule.
Pourquoi ACDOCA impose-t-il une revue des rapports financiers BW ?
Le Universal Journal de SAP S/4HANA change la structuration et l’intégration des données financières et de contrôle de gestion. Les rapports BW qui rapprochaient auparavant plusieurs sources FI, CO ou CO-PA doivent être revalidés sur leur périmètre, leurs clés et leurs règles de calcul.
Comment prouver que les chiffres BW/4HANA sont acceptables avant la mise en production ?
Organisez un double run sur un cycle métier représentatif, comparez les données détaillées avant les agrégats, classez chaque écart par cause et faites signer les tolérances par les responsables métier. Le but est de documenter les différences admises, pas de promettre une identité automatique avec l’ancien système.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
