Hana, la base de données en mémoire de SAP
Hana signifie High-Performance Analytic Appliance. Le principe est simple : plutôt que de stocker les données dans des disques durs lents et volumineux, pourquoi ne pas les stocker directement en mémoire ? En bénéficiant de surcroit d’algorithmes de compression et de structures de base “en colonne”, les gains en temps de réponse seront considérables.
Il existait déjà des solutions de stockage des données en mémoire pour la Business Intelligence. Par exemple, BW Accelerator, avait pour vocation d’optimiser le reporting avec SAP NetWeaver BW. Des concurrents de SAP avait également utilisé les possibilités de mise en mémoire (IBM, Qliktech…) ou sont en cours de développement.
La différence majeure avec HANA est que cette base de données en mémoire sera utilisable par tous types de solutions, celles de SAP dans un premier temps puis, à terme, quelle que soit l’application.
Son développement aujourd’hui provient de la conjonction de deux facteurs : la baisse du coût de la mémoire, qui rend ce type de stockage de données beaucoup plus accessible, et la position forte de la Business Intelligence dans l’offre de SAP. La premiere version est déjà disponible et sera suivie en juin par une version compatible avec BW.
Quelle utilité ? En effet, on considère en général que les solutions “transactionnelles”, de type ERP, utilisent pour chaque traitement une faible quantité de données avec des temps de réponse acceptables. Certes, certains traitements (MRP, répartitions de centres de coûts, états dynamiques des stocks, etc) sont parfois ralentis par la quantité de données à utiliser.
L’innovation principale de SAP est de remettre en cause l’approche courante de la Business Intelligence, dont l’objectif est de donner accès à l’information selon différents formats (tableaux de bord, états formatés, moteurs de recherche, etc). La Business Intelligence traditionnelle extrait les données “brutes” des bases de données opérationnelles, les transforme pour leur donner une forme compréhensible par les utilisateurs, puis les stocke de telle sorte qu’elles sont rapidement accessibles par le reporting. Les ETL (extraction, transformation, loading) s’occupent des flux, et le DataWarehouse est dédié au stockage.
Une remise en cause de la Business Intelligence traditionnelle
Mais voilà : si les données d’un ERP sont déja dans le format souhaité et sont accessibles rapidement, alors pourquoi s’encombrer d’un ETL et d’un DataWarehouse ?
On le comprend bien : ce que SAP propose c’est une remise en cause de la manière de concevoir les solutions BI (notamment la couche “basse”), qui était rendue nécessaire le plus souvent par des contraintes techniques. Ceci est rendu possible par le leadership de SAP sur les ERP et la BI. Au fond, SAP ne fait que répondre à une demande des utilisateurs : une interface unique pour tous les usages, du reporting en temps réel, l’interaction entre l’analyse et l’action. Et SAP est l’un des rares éditeurs qui peut se permettre d’avoir une vision large, toutes solutions confondues.
En termes d’interface utilisateur, les solutions qui effacent les frontières entre les plateformes existent déjà : NetWeaver Business Client combine l’opérationnel et la Business Intelligence sur un même écran, le portail web SAP le permet depuis plusieurs années déjà (du Visual Composer jusqu’aux développements Web Dynpro), des états de reporting basés sur BO (Xcelsius ou Crystal) sont déjà inclus dans l’ERP, etc.
On peut bien entendu émettre certaines réserves. Dans de nombreux cas les données transactionnelles “brutes” ne sont pas exploitables en l’état, et SAP n’est pas toujours la seule source de données. Un ETL sera encore nécessaire pour transformer des données trop techniques et alimenter des tables avec les données transformées. Par ailleurs, il est évident qu’on ne pourra pas utiliser une table isolée comme source unique pour le reporting du fait de la modélisation relationnelle classique qui sépare les données entre plusieurs tables : par exemple, les données de base (les textes des articles) et les données transactionnelles (les pièces de ventes).
L’essor d’une Business Intelligence intégrée
Ceci démontre qu’il sera encore nécessaire d’utiliser un ETL comme BusinessObjects DataServices pour transformer et stocker certaines données. Il sera tout autant nécessaire de créer des univers ou d’utiliser une vue analytique (prévue dans HANA) pour formaliser les liens entre les tables et rendre les zones techniques plus explicites pour les utilisateurs. Cependant, la cible de l’ETL ne sera plus un DataWarehouse séparé, mais de simples tables dans la base en mémoire. Le nouveau concept d’univers apporté par BO 4.0, qui permet de lire simultanément plusieurs systèmes, ne permettra pas d’éviter cette recopie des données vers HANA (car si on analyse en même temps des données de deux systèmes on peut craindre que le temps de réponse final soit celui du plus lent).
Que devient SAP NetWeaver BW dans tout cela ? L’avantage de BW consiste aujourd’hui dans la capacité à extraire et préparer les données de toutes les solutions de SAP rapidement. Les exemples récents démontrent que ceci n’est pas remis en cause par SAP : les dernières versions de la gamme EPM (BPC, PCM…) ont renforcé les possibilités d’échange avec BW, et la dernière version de BO (4.0) permet de lire très facilement des queries BEX et des cubes BW. Par ailleurs, compte tenu des investissements des clients dans BW (dont Integrated Planning pour l’élaboration budgétaire), il n’est pas question pour SAP, semble-t-il, de remettre en cause l’utilisation de BW. La proposition faite au client est plutôt d’utiliser HANA comme base de données en mémoire également pour leurs installations BW.
Dans sa version actuelle HANA est une base de données en mémoire alimentée de manière asynchrone avec les données de SAP ERP, et par BO DataServices pour toutes autres données, et analysée par les outils de reporting de BusinessObjects.
A terme, on peut facilement imaginer les architectures nouvelles qui seront proposées aux clients : les outils de reporting SAP BusinessObjects liront directement les tables de la base en mémoire des solutions de SAP, via les Univers ou les Analytic Views (dont certains seront livrés par SAP). Ces tables seront, soit les tables standards de SAP contenant des données “brutes”, soit de nouvelles tables contenant des données transformées de SAP ou chargées d’autres systèmes, grâce à BO DataServices. Pour ces données, transformées ou chargées, il sera tout aussi possible d’utiliser une instance BW.
Cette vision de l’avenir, apportée par SAP avec HANA, efface la séparation technique qui existe entre les solutions transactionnelles et décisionnelles. Ceci aura pour conséquence de permettre une approche essentiellement fonctionnelle aux projets BI, et d’y impliquer davantage des compétences “métier” (correspondant aux solutions ERP, CRM, SRM, etc..).
Les besoins de reporting ont toujours fait partie des projets de mise en oeuvre des solutions SAP. Pour l’ERP ils furent d’abord couverts par des outils intégrés (Report Painter, LIS, EIS…) puis par des solutions séparées de Business Intelligence (BW, BusinessObjects). Désormais, des consultants ERP (FI-CO, SD…) pourront créer naturellement des états de reporting, avec BusinessObjects, comme ils le faisaient déja avec les anciens outils de reporting intégrés. Les utilisateurs finaux créeront leurs propres états temps réel personnalisés avec Interactive Analysis ou trouveront l’information requise par le moteur de recherche Explorer. HANA, loin de sonner le glas de la BI, la rend beaucoup plus accessible en l’intégrant dans les systèmes opérationnels, et offre de nouvelles perspectives aux clients de SAP et à leur partenaires.
Commentaires récents