SAP BW à l'heure de Hana

Un SAP BW a été développé pour stocker des données provenant de différents systèmes SAP et non SAP de manière à permettre un accès performant pour l'analyse des données au-delà des limites des domaines spécialisés.

Historique

A l'époque, le schéma en étoile était recommandé pour gérer de telles quantités de données. Ainsi, les bases de données étaient initialement définies comme analytiques (OLAP) ou transactionnelles (OLTP) afin de permettre un accès efficace aux données. Il n'est toutefois pas plus amusant de lancer un accès analytique dans un système OLTP que de travailler de manière transactionnelle dans un système OLAP. Pour les accès analytiques, les systèmes de gestion de base de données (SGBD) orientés colonnes sont plus adaptés que les SGBD orientés lignes. Pour améliorer les accès analytiques à SAP BW, un SGBD orienté colonnes a donc été livré avec SAP BW Accelerator.

Retournement de situation

Avec une base de données Hana, les accès aux données deviennent performants grâce au stockage en mémoire des données, tant pour les accès analytiques que transactionnels. Le paramétrage de la base de données pour OLAP ou OLTP n'est plus nécessaire.

Étant donné que, statistiquement, l'accès aux données se fait beaucoup plus en lecture qu'en écriture, les données sont stockées par défaut en colonnes dans Hana. Une orientation supplémentaire des lignes est recommandée pour les tables auxquelles on accède en écriture.

Comme la BD Hana est la BD préférée de SAP pour les applications ERP, toutes les données opérationnelles peuvent désormais être utilisées immédiatement pour des analyses. Pourquoi alors avoir encore besoin d'un SAP BW ?

Vous pourriez vous passer de SAP BW à partir du moment où vous avez toutes les données - de toute l'entreprise - y compris l'historique dans cette seule base de données Hana. Techniquement, un tel scénario est réalisable. Mais malheureusement, l'informatique ne se résume pas à la technique.

Exigences d'un système central

Historique : étant donné que les données en temps réel sont surtout appropriées pour le reporting opérationnel, il convient de déterminer quelles données doivent être historisées dans la BD Hana pour les déclarations stratégiques.

Pour éviter d'augmenter inutilement les besoins de stockage et de générer ainsi des coûts de stockage et donc de licence supplémentaires, il est possible de travailler avec un stockage nearline. Malheureusement, les performances pour les rapports stratégiques sont alors affectées.

Croisement et enrichissement des données : tous les domaines spécialisés qui n'ont pas encore leurs données dans cette base de données Hana doivent être ancrés afin de mettre leurs données à disposition pour un accès multidisciplinaire à l'échelle de l'entreprise. Pour ce faire, des modélisations et des enrichissements de données doivent être effectués.

Qualité et actualité des données : les données conservées doivent constituer un point de vérité unique pour l'ensemble de l'entreprise. Pour ce faire, il convient de déterminer avec précision quelles données sont mises à disposition, à quel moment et de quelle manière elles sont calculées et limitées. Dans ce contexte, actualité ne signifie pas nécessairement temps réel.

Les autorisations : Imaginez que vous avez la responsabilité globale des données du personnel dans l'entreprise et que, dans ce rôle, vous êtes également responsable du système SAP RH.

Ils doivent maintenant stocker toutes les données des collaborateurs sur un seul système, en même temps que le SAP ERP. Dormirez-vous sur vos deux oreilles ? Aujourd'hui encore, lorsqu'il s'agit de choisir un système SAP BW-HR, on préfère avoir son propre système plutôt que d'aller dans le système BW central déjà existant, où différents services spécialisés conservent leurs données.

Même si le système d'autorisation peut être mis en place en conséquence. Il s'agit d'un sujet très sensible concernant la souveraineté des données et donc la protection des données. Le principe reste le même : plus le système est isolé, mieux c'est.

Gestion des services d'application : un système central - quel qu'il soit - doit également être géré. Quel service se déclare prêt à tenir cette instance centrale à la disposition des autres services et du comité ?

Il s'agit de thèmes tels que l'installation, la mise à niveau, l'exploitation courante, les licences, les projets, la gestion des changements, les corrections d'urgence, la conformité à la loi Sarbanes-Oxley, les self-services et bien d'autres. En bref, toute la gestion des services d'application doit être exploitée pour le système.

Coûts : L'exploitation opérationnelle d'un tel système central implique donc des efforts et donc des coûts, notamment en raison de la main-d'œuvre nécessaire. Ces coûts doivent être répartis, de préférence selon le principe de causalité.

Pour un reporting stratégique dans une base de données Hana, il faut avant tout clarifier les deux premiers points concernant l'historique et le recoupement des données.

Reporting avec SAP BW

L'utilisation d'une BD Hana sous un système SAP BW a non seulement permis d'accélérer l'activation des pots de données et les temps de réponse des rapports, mais aussi d'intégrer les données en temps réel d'un système SAP opérationnel traditionnel (ERP, CRM, etc.) dans le système de reporting SAP BW.

Pour ce faire, les données dont la direction ou le service ont besoin sont répliquées dans la Hana de SAP BW à l'aide de SAP Landscape Transformer (SLT).

À partir du schéma Hana correspondant, les tables répliquées peuvent être affichées sous forme de vues d'information (vues analytiques ou de calcul) directement ou avec une logique supplémentaire dans SAP BW à l'aide de fournisseurs d'informations virtuels ou être intégrées dans des fournisseurs multiples et ainsi être coupées avec des rapports existants.

Les autorisations de contenu et d'analyse utilisées dans l'environnement SAP BW peuvent être utilisées de la même manière pour l'analyse de ce type de données en temps réel.

C'est un avantage non négligeable par rapport à l'analyse directe des données sur la table Hana, qui demande elle-même une autorisation propre qu'il faut gérer.

Transformation de SAP BW

Afin de préparer l'environnement SAP BW existant pour l'avenir, les étapes d'investissement suivantes sont nécessaires :

1. matériel certifié Hana.

2. les licences Hana - outre l'OEM pour une utilisation purement SAP BW, également le Hana Modeller.

3. migration vers SAP BW on Hana.

Si l'on envisage déjà d'utiliser S/4, l'étape d'investissement 1 doit également être réalisée - à une échelle légèrement différente. Si le matériel informatique doit de toute façon être modifié, cette étape peut déjà être envisagée.

Avec un BW on Hana, il est possible d'utiliser déjà les nouvelles propriétés et fonctionnalités de Hana et d'acquérir de l'expérience avec la base de données en temps réel.

De plus, SAP BW offre désormais des possibilités de modélisation plus simples (mots-clés ADSO, Composite Provider) qui - surtout avec la modélisation en amont basée sur Eclipse - simplifient considérablement l'utilisation de SAP BW.

En particulier, l'utilisation des fournisseurs composites en relation avec des workspaces spécifiques à des domaines spécialisés permet une approche BI en libre-service, grâce à laquelle les domaines spécialisés peuvent étendre leurs rapports avec leurs propres affectations et les exécuter ensuite avec les autorisations existantes.

Même si de telles extensions ne sont probablement réalisées que par un PowerUser, cela donne au domaine spécialisé une flexibilité qui correspond aux directives de gouvernance IT. L'espace de travail lui-même est mis à disposition par le service informatique.

Utilisation future de SAP BW

Il est possible, après la migration initiale du contenu SAP BW existant, de mettre en place de nouveaux contenus BW en tenant compte du modèle en couches (mot-clé LSA++, etc.) de manière à ce que le reporting soit utilisé à des fins opérationnelles et stratégiques.

Cela représente un immense avantage pour les services spécialisés. Si d'autres données sont nécessaires, l'IT peut simplement ajouter les tables/vues requises dans la réplication via SLT. Les extracteurs de données en temps réel (Realtime Data Acquisition - RDA), très coûteux, ne sont plus nécessaires et n'ont plus besoin d'être entretenus.

Il est également envisageable d'utiliser la fonctionnalité BW uniquement pour l'historisation et l'enrichissement des données et, au final, de construire les rapports directement à partir de Hana, sans utiliser la fonctionnalité OLAP.

Étant donné qu'à l'heure actuelle, la requête BEx utilise toujours le Surrogate ID (SID), environ 80 % de la durée totale d'exécution des rapports sont utilisés pour la création initiale et le mappage du SID. Avec l'utilisation directe de Hana, les rapports seraient donc globalement traités plus rapidement.

La feuille de route actuelle prévoit un S/4 qui non seulement simplifiera tous les modèles SAP connus, mais inclura également la fonctionnalité BW.

S'il s'avère que le système BW central pourrait se fondre dans un tel S/4 central - non seulement du point de vue technique, mais surtout du point de vue de la gouvernance informatique -, tous les investissements réalisés jusqu'à présent n'auront pas été faits en vain.

Au contraire, une expérience précieuse a été acquise dans la gestion d'un environnement Hana complexe, ce qui aidera à prendre la bonne décision pour ou contre un entrepôt de données central.