SAP Business Information Consulting

Depuis peu, SAP a enfin livré sa roadmap concernant le futur produit BI qu'il comptait sortir.

Pas ou peu de surprises, on garde bien sur le datawarehouse SAP BW (pour la partie Netweaver BI) et on migre doucement vers les outils Crystal pour la restitution.

Bien sur, il y a une nouvelle couche qui est la version premium avec l'intégralité des fonctions Crystal.

Le schéma ci-desous représente les actuelles et futures gammes de produit.

Source: SDN
Les nouveaux produits attendus sur les 2 prochaines années sont :

Crystal Reports light et standard pour remplacer le Report designer
Pionneer pour remplacer le Bex Analyzer
XCelsius + pour remplacer le Web Application Designer
BI Mobile pour les applications mobiles

Conclusion : Beaucoup d'améliorations à prévoir et SAP BW a encore pas mal de jours devant lui
L'arrivée des technologies Flash pour la présentation (déjà avec Visual Composer)
Pas encore de news pour les applications de budget et de CPM ...

La présentation complète est disponible sur SDN SAP BW.

Comme à l'acoutumée, Gartner publie pour chaque année son tableau de tendance appelé le magic quadrant dont on vous fait profiter.



Pour résumer ce qui nous intéresse,

SAP n'est pas encore reconnu comme un leader par le Gartner car il ne dispose pas de références sur l'intégration de données non-SAP (ce qui devrait bien sur s'arranger avec leur dernier achat)

Microsoft pointe en tête, avec leur produit star de CPM PerfomancePoint Server.
C'est pas cher, bien intégré à Office mais doit faire face à la mégaconsolidation du marché.

Hyperion, la société est dans le processus de consolidation du groupe Oracle. Donc wait & see.

BO, est devenu un produit standard avec XI dans les sociétés mais doit faire face au vote le moins bon en terme de support (ce qui devrait bien sur s'arrange avec leur dernière revente)

Nous avons vu il y a quelques mois une première approche sur le design des cubes (cf article)

Interessons nous maintenant aux requêtes.

Le design des requêtes est une source fréquente de non performance... et bonne nouvelle, c'est aussi le plus facile à améliorer.

Voici quelques règles générales a appliquer :

1 - ne montrez que ce qui est necessaire. D'un point de vu performance, l'adage 'qui peut le plus, peut le moins' est une catastrophe.

Pour ce faire, utiliser au maximum les variables et les sélections en début de requête. Evitez autant que possible les exclusions, qui sont très pénalisantes.

2 - commencez par une vue aggrégée.

un risque fréquent lorsque l'on met en place un outil de BI, est la bonne vieille habitude des utilisateurs des listings... Beaucoup de gens sont convaincus qu'il ne peuvent pas bosser sans la liste des commandes sur 37 pages !

C'est ici qu'intervient le rôle de conseil du consultant. Faire de la BI, ce n'est pas lister les commandes (ou autre), c'est analyser de manière dynamique les données...

Il convient d'utiliser les possibiliter de drill down, d'alertes... afin d'avoir une vision claire des données (quitte à descendre au niveau de détail pour une sélection restrainte) et d'amener les utilisateur à cette nouvelle manière de travailler.

3 - utilisez 0INFOPROVIDER pour filtrer.

Nous avons vu dans notre article précédent qu'il était judicieux de toujours utiliser des multiproviders. Cependant, dans certain cas, une requêtes ne va utiliser qu'un nombre restreint de providers. Il convient alors de signaler ces cubes dans une selection sur l'objet 0INFOPROVIDER, de manière à ce que le système n'aille lire que les providers utiles.

4 - utilisez les statistiques BW

L'optimisation des requêtes doit êtres sélective, il n'est pas très utile d'optimiser une requête peu utilisée, alors qu'un gain de temps sur une requête lancée plusieurs dizaine de fois par jour sera indispensable.

Pour se faire, regardez les statistiques, surveillez l'utilisation des espaces, discutez avec les users.

5 - utilisez les aggrégats et maintenez les !

Un aggrégat est un très bon accélerateur de requête. Cependant, un système BI est un système vivant, qui évolue avec les besoins de l'entreprise et son de marché.

Par conséquent, vérifiez régulièrement que vos aggrégats répondent toujours aux besoins et qu'ils sont utiles. Remplacez les par des nouveaux si nécessaire.

****

Bien sûr, chaque cas est un peu particulier et demande une réponse adaptée, surtout dans le domaine de l'optimisation... mais ces quelques points vous aideront à vous faire une idée sur votre solution.

Si vous avez des questions, ou si vous souhaitez que nous procédions à un audit plus complet de votre solution, n'hésitez pas à nous contacter.

Plus d'infos sur notre site

Mail

Au sein d’une organisation, la gestion budgétaire et les simulations sont des facteurs clés de structuration entre la réalisation des stratégies et la mise en œuvre opérationnelle. Or le temps est souvent passé à collecter et homogénéiser les informations, effectuer les boucles de validation, communiquer les états produits, etc. le tout au détriment de l’analyse et la compréhension, valeurs ajoutées indéniables pour une entreprise. Hors, à ce jour SAP propose deux solutions financières pour répondre à ces besoins : BPS (Business Planning & Simulation) et BI-IP (Business Intelligence Integrated Planning). Pourquoi choisir BPS à l’instar de BI-IP ou vice versa ? Quelles sont les différences ? [et bientôt 3, nous verrons cela dans un article à venir]

Faisons tout d’abord un point historique.

En 2003, la solution financière SEM-BPS 3.1 sort (SEM = Strategic Enterprise Management). Celle-ci est la première version « correcte » qui a fait le succès de ce produit. Fin 2004, SAP BPS est intégré dans la version BW 3.5.

Netweaver 7.0 sort fin 2006 et intègre un nouvel outil, BI-IP tout en maintenant le produit BPS.

Passons maintenant à la présentation de BPS, suivi de celle de BI - Integrated Planning pour ensuite les comparer.

Qu’est ce que BPS ?

Initialement, SAP BPS était intégré à la solution financière SEM, et était peu orienté sur le Web. SAP a préféré mettre l’accent sur la création de transaction ALV « budget » et sur l’interface Excel. Face au succès de BPS, SAP a décidé de le livrer avec la version 3.5 de BW alors que l’intégration technique n’était pas davantage poussée avec BW.

BPS se définit comme un outil de simulation et de saisie budgétaire permettant de saisir les données directement dans des cubes BW. Les données du budget sont donc immédiatement disponibles pour le reporting. En plus de la saisie, BPS propose diverses fonctions de calculs et de simulation, pour notamment gérer plusieurs versions de budget (souvent réclamé par les contrôleurs de gestion).

Les interfaces étant peu orientées Web, SAP a décidé depuis 2004 d’y concentrer ses efforts. Par conséquent, les possibilités en Web sont aujourd’hui plus nombreuses qu’en Excel avec, par exemple, une intégration partielle du reporting sur l’écran de saisie.

Comment se passe la modélisation avec BPS ? BPS utilise des cubes BW dit « transactionnels », et peut, en l’occurrence, ajouter des lignes dans le cube en permanence. Une fois le cube transactionnel généré dans BW, le paramétrage pour la mise en page des écrans de saisie se fait alors dans BPS via la transaction BPS0.

Par ailleurs, BPS propose également divers panels de fonctions de planification à utiliser pour créer tous les traitements nécessaires, tels que la copie, la conversion de devises, la réévaluation, l’éditeur de formule Fox Formula, etc.

Passons à présent à BI-IP.

Depuis fin 2006, SAP a sorti sa nouvelle solution de Business Intelligence (BI) via la plateforme SAP Netweaver 7.0 (ex 2004s), version de SAP répondant aux critiques émises par les utilisateurs à l’encontre de BW 3.5. Le développement des fonctionnalités du datawarehouse et du reporting sont les principales nouveautés.

SAP a pour objectif, avec SAP Netweaver 7.0, de conquérir de nouvelles parts de marché. Pour ce faire, il offre une solution BI plus complète et plus performante, ajoute de nouvelles fonctionnalités, plus orientées utilisateur, garantit une meilleure intégration de ses solutions, et améliore la compatibilité avec d’autres applicatifs, SAP et non-SAP.

Lors de la sortie de Netweaver 7.0, SAP a intégré BI-IP, son nouvel outil de planification et de simulation.

En comparaison à son prédécesseur, BPS, BI-IP possède divers avantages tels que :

• l’intégration des simulations et des planifications à l’outil de reporting et l’intervention directe sur le reporting, pour une prise de décision plus rapide
• l’amélioration des structures techniques pour obtenir une plus grande facilité et de possibilités dans la gestion de la simulation et de la planification
• l’ajout de fonctionnalités techniques
• une meilleure intégration avec le Web
• la gestion via les formules Excel

BI-IP présente une interface unique pour analyser les données et planifier : l’interface utilisateur et l’outil de conception sont réunis dans une seule et même interface. De plus, son intégration avec BW permet d’utiliser les fonctionnalités telles que les hiérarchies, les variables, les ratios calculés, les ratios restreints, les fonctions de planification (les mêmes que BPS) etc. dans les écrans de saisies. La mise en place des simulations et reporting avec BI-IP sera donc plus rapide, la majorité des objets étant en commun.

Maintenant que BPS et BI-IP ont été présentés, lequel serait à choisir si les financiers de mon entreprise recherchaient un outil capable de réaliser des budgets, des simulations de ces budgets, et du reporting ?

BPS et BI-IP ont des différences en termes d’architecture. BPS fait une distinction entre le reporting et la planification, d’où des zones de stockage distinctes, des fonctionnalités en double, etc. BI-IP va, au contraire, réunir ces deux outils en un.

Architecture BPS

Architecture BI-IP

En ce qui concerne les avantages, BPS est une solution robuste qui a d’ores et déjà fait ses preuves et qui n’a pas besoin de migration pour la version Netweaver 7.0. BI-IP, par contre, s’intègre totalement dans les outils de reporting BW, avec davantage de possibilités et de flexibilité dans le paramétrage, d’où une accélération dans les processus de décision et une gestion de la conduite du changement moins importante.

Au sujet des risques, de nombreuses fonctionnalités avancées pour BPS ne sont uniquement disponibles que via l’environnement Web et la mise en page des écrans de saisie est plutôt laborieuse. Par ailleurs les évolutions de ce produit se sont arrêtées, sa maintenance standard se finit dans deux ans et sa migration automatique vers BI-IP est impossible. BI-IP étant un produit relativement récent, son risque en termes de bug au cours d’un projet est plus important que pour BPS, bien que BW 7.0 en est au support package (SP) 13 et que nombreux sont les clients à travailler en production en SP 12 sans le moindre souci.

Après un comparatif des avantages et risques de BPS et BI-IP, allons voir ce qu’en dit l’éditeur, lui-même.

Sur le site help.sap.com, SAP recommande d’utiliser le nouvel outil BI Integrated Planning lors de la mise en place de nouveaux scénarios.

De plus, concernant la montée de version pour l’existant, il faut savoir que Netweaver est capable d’émuler les anciennes versions 3.x pour en assurer la compatibilité. Cependant, quelques éléments devront être mis à jour pour pouvoir profiter des nouvelles fonctionnalités, comme par exemple les requêtes pour accéder à BI reporting suite.

Au regard de toutes ces informations recueillies, ainsi qu’aux recommandations de SAP, BI- Integrated Planning est aujourd’hui l’outil à privilégier tant pour ses nouvelles fonctionnalités que pour le potentiel d’évolution du produit.

Article rédigé par Caroline T.

Il y a quelques jours, SAP jetait le pavé dans la marre en chageant sa stratégie pour acheter Business Objects. Evidemment, beaucoup d'interrogations peuvent se poser sur les avantages et incovénients d'un tel rachat, ainsi que ses conséquences malheureuses. SAP a promis d'en dire plus après que la fusion soit effective. Néanmoins, on sait déjà que BO serait une entité "indépendante" dans le groupe, au moins pour assurer la maintenance de ses produits existants, tel que son dernier BO XI. Ce rachat n'est pas anodin et a plusieurs objectifs : - se renforcer et accélérer le développement des outils analytiques et autres CPM en effet, le transactionnel étant moins à la mode, SAP cherche à s'imposer comme un des leaders des outils nouvelles générations - se positionner sur le marché de la PME en offrant une version de BO accompagné de son dernier outil destiné au PME : SAP Business ByDesign. - et bien sûr converger les carnets clients pour essayer d'imposer SAP aux entreprises qui ne l'auraient pas encore Alors qu'est ce qu'il faut attendre des prochains mois ? Qu'est ce que SAP va faire des SAP BW (Netweaver BI), Integrated Planning, Outlooksoft, BO XI, Crystal reports, Acta et Cartesis ? (tous quasiment indépendants et pas encore vraiment compatibles à 100%) La tâche de SAP sera difficile pour organiser son offre logicielle et nécessitera de longs mois afin de définir une stratégie et sa roadmap associée. Il est à parier qu'il va y avoir de nombreux changements. La politique de SAP a toujours été de vendre sa plateforme d'intégration Netweaver. On peut sans doute deviner dans quelques années une fusion BW/BO avec le meilleur de chaque monde incluant l'intégration des dernières acquisitions. De même, SAP ne se séparera pas des clients BO non SAP. Il y aura un BW/BO spécial sans SAP. En attendant, les applications actuelles ne devraient pas être obsolètes (en parlant de BW et BO XI). Le gain pour les 2 clientèles devrait être notable puisque l'on devrait assister à une meilleure convergence des 2 univers. Évidemment, on peut parier que SAP offrira une migration moins douloureuse dans le futur que si ses clients (BO et SAP) utilisent les dernières versions de chaque monde. Et bien sûr vous avez tous fait récemment la difficile migration vers BO XI ou Netweaver 7.0 ! Bien sûr, tout cela n'est qu'un pari et reste le chemin le plus logique vers la consolidation des applications de Business Intelligence. Alors attendons la prochaine roadmap SAP. De toute façon, vous n'avez pas encore tous forcément besoin, aujourd'hui, d'outils de CPM complètement intégrés avec la BI et tous les gadgets qui s'en accompagnent. Et rappelons qu'il y a beaucoup de chances qu'il faille attendre quelques années avant de voir tout ça, donc la vie continue !

Quelques petits trucs pour auditer - et améliorer en conséquence votre solution BW

1 - les cubes :

Pour les cubes, c'est assez simple : Exécuter le prog. SAP_INFOCUBE_DESIGNS sur votre système de production.

Ce programme bien utile, liste pour chaque cube un résultat de ce genre :

Mon_Cube rows: 3.027.600 density: 0,0 %

Mon_Cube /BIC/DMon_Cube1 rows: 38.417 ratio: 1 %

Mon_Cube /BIC/DMon_Cube6 rows: 522.950 ratio: 17 % ...

Mon_Cube /BIC/EMon_Cube rows: 0 ratio: 0 %

Mon_Cube /BIC/FMon_Cube rows: 3.027.600 ratio: 100 %

En orange : le nombre de lignes du cube. Ce nombre doit rester raisonnable. De manière générale, si on dépasse 20 millions de lignes, il est conseillé de couper le cube et de faire un multi-cube.

En Bleu : Pour chaque dimension, le nombre de lignes et le ratio dimension / table des faits. Attention, si ce chiffre dépasse 10%, vos performances diminueront... Il est peut être alors utile de regarder comment mieux définir les dimensions.

Que faire si le résultat n'est pas très bon ?

La réorganisation des dimensions ne peut se faire que sur un cube vide... première étape, si ce n'est déjà fait, créer un multi-provider et y transférer vos requêtes.

Ensuite, vous pourrez créer un second cube optimisé, le charger et faire un échange entre l'ancien et le nouveau cube au sein de votre multi-provider 'ni vu, ni connu'...

En Mauve : Les tables des faits E et F (la table F est la table classique, la table E est la table compressée).

Si votre table E est à 0 ligne, mettez en place la compression... vous gagnerez du temps !

****

Bien sûr, chaque cas est un peu particulier et demande une réponse adaptée, surtout dans le domaine de l'optimisation... mais ce petit test peut vous permettre de vous faire une idée du bon design de vos cubes.

Si vous avez des questions, ou si vous souhaitez que nous procédions à un audit plus complet de votre solution, n'hésitez pas à nous contacter.

Plus d'infos sur notre site

De nombreuses possibilités sont offertes pour améliorer les performances d’une solution BW (Datawarehouse et requêtes). De l’optimisation à l’utilisation des fonctionnalités, le panel de possibilités est assez large.

Intéressons nous aux requêtes BW avant d’acheter des solutions de type BI Accelerator !

Vos requêtes sont longues à exécuter et vous ne savez pas comment et quoi faire pour diminuer les temps d’exécution.

1) Une requête web va plus vite qu’une requête Excel

En effet, une partie du calcul de l’affichage se fait sur Excel alors qu’en mode Web, le serveur prend la totalité des calculs.

2) Plus il y a d’éléments à afficher et plus c’est long !

C’est normal, entre une requête agrégée et une requête de type liste et détails, BW va mettre plus de temps. En cause : la lecture des différentes tables du schéma en étoile et le temps d’affichage des données. Pour expliquer le fonctionnement, lorsque vous exécutez une requête, BW va créer un fichier texte de l’ordre de quelques kilo octets lisibles l’outil de requêtage. Le temps sera bien plus long lorsqu’une liste de détails sera demandée. D’où la sempiternelle réflexion qui est : BW n’est pas optimisé pour faire de l’affichage de liste.

3) Le cache

Avez-vous déjà remarqué qu’une requête va plus vite à s’exécuter lorsque cela a déjà été fait une fois ? BW gère une mémoire cache en conservant les résultats de la dernière exécution lorsque bien sûr les informations n’ont pas été modifiées par un nouveau chargement. En version 2004s, il y a même la possibilité de gérer des caches delta. Pour obtenir les options, transaction RSRT, puis propriétés. Suivant la configuration de la taille de la mémoire cache, il y a plusieurs options :

- pas de cache Pour versions 3.x, si vous effectuez des chargements fréquents (ex 1 fois par heure), il vaut mieux désactiver le cache. - cache sans swap Lorsque le cache est plein, certaines informations sont retirées du cache par un algorithme particulier. Pour accéder aux informations supprimées, BW doit réalimenter le cache. - cache avec swap Lorsque le cache est plein, certaines informations sont sauvegardées dans un fichier et peuvent être rappelées ultérieurement.

- cache persistent Les informations de requêtes sont stockées dans une base de données ou un fichier.

- cross application cache persistent Les informations sont stockées sur un fichier dans le réseau informatique.

Ces 2 dernières options sont à considérer lorsque vous utilisez notamment plusieurs serveurs d’applications.

Bien sûr, il est possible d’industrialiser le lancement des requêtes pour que les utilisateurs aient accès directement aux données disponibles dans le cache soit via par le pré calcul de requêtes, soit par le broadcast.

4) Les modes de lecture

Dans la même lignée, on peut aussi modifier le volume de lecture des informations. Toujours dans la même transaction, il est possible de :

- Lire la totalité des informations relatives à une requête - Recalculer les informations à la navigation - Recalculer les informations au changement d’un nœud de hiérarchie

5) L’ordre des modes de lecture

Evidemment BW ne va pas utiliser toutes ces options à la fois. Il existe un ordre prédéfini d’ « essai » d’utilisation des options :

- Lecture du cache - BI Accelerator - Recalcul de la requête depuis un agrégat - Recalcul de la requête

Le constat est que dans un cadre BI 2004S, BI Accelerator n’est pas systématiquement la meilleure solution au niveau de l’optimisation et des coûts !

Une bonne optimisation du cache peut déjà permettre de faire des gains substantiels en temps de calcul des requêtes.

6) Création de requêtes sur un multiprovider

Lorsque vous faites une requête sur un multi-cube, BW va tenter de lire parallèlement les différentes sources.

Evidemment pour que ça aille plus vite, il serait sympathique d’aider BW pour qu’il trouve le chemin plus facilement en :

- rajoutant de manière explicite le nom du cube où est présent l’information - rajoutant via un user exit la manière de retrouver le cube où est présent l’information

N’oubliez pas que BW lance en parallèle la lecture des différentes informations mais lorsque c’est trop long, il abandonne et lance séquentiellement la lecture. Il est donc, évident qu’il faut désactiver la lecture parallèle lorsque le calcul est trop long. Petit test simple, voir comment se lit une requête à l’exécution via la gestion des processus dans SM50.

Il existe bien des moyens pour optimiser le calcul des requêtes. Malheureusement, cela restera toujours long si la partie datawarehouse est mal paramétrée et d’autres solutions peuvent alors intervenir : redimensionnement des cubes, partitionnement des cubes, découpage des cubes par pays jusqu’à la refonte de vos requêtes.

Evidemment, lorsque vous n’avez plus de solutions du tout et que vous êtes en 2004s, vous avez toujours la possibilité d’acheter un serveur dédié avec la solution BI-Accelerator. Son fonctionnement est quasi identique au mode cache, si ce n’est à la différence qu’il utilise un arbre de recherche de type TREX pour ranger les fichiers issus du calcul. Malheureusement, son coût n’est pas à la portée de toutes les bourses.

Si vous avez des questions ou besoin de conseils, n’hésitez pas à faire appel à Censio pour un audit rapide de vos solutions SAP BI.

Pour plus d'informations, http://www.censio.fr

Beaucoup d’interrogations se posent pour une montée de version vers BI 7.0. En effet, les fonctionnalités décrites par l’éditeur sont plutôt alléchantes : outils de reporting désormais fonctionnels, fonctions d’éditions et intégration web, BIIP, Webdynpro….

Il faut tout de même avant de se lancer dans une telle opération, se poser la question des pré-requis et des impacts de la montée de version. Et ce sont aussi également les questions que vous devez certainement vous poser sans avoir une idée précise des réponses, étant donné la sortie récente du produit.

Evidemment, nous n’allons pas détailler l’ensemble des points à vérifier mais parcourir les grandes lignes des pré-requis et changements.

1^er point : Hardware

Netweaver 2004s est un concentré de produits contenant plusieurs outils assez gourmands qu’il vous appartient d’installer ou non. Outre le BW classique, il comporte aussi des nouveautés indispensables : Entreprise portal (pour l’utilisation des requêtes en 7.0), J2EE (serveur Java pour l’utilisation des nouveautés), WAS (Web application server) … C’est à dire, beaucoup de produits et de puissance à fournir au niveau de votre système. Certains recommandent même un serveur "stand alone" rien que pour la mise en place du J2EE (option offerte lors de l’installation)

Au niveau de l’espace disque, SAP porte à 20% d’espace supplémentaire à fournir par rapport à un volume existant.

2^ème point : Les postes clients

Là aussi, une attention est à fournir, les outils type Bex, Wad nécessitent l’installation de programmes (type .Net) et des versions de Microsoft Office assez récentes. Il ne va pas sans dire que les postes clients doivent aussi être plus musclés pour accueillir ces nouvelles applications.

3^ème point : La migration

Que provoque la migration en terme d’impacts et que doit-on prendre en compte dans tout chiffrage ? Plusieurs points à ce niveau :

Mise à jour de votre base BW (pre-requis) Kernel, Oracle et plug-ins à mettre à jour. Pas de modifications de vos structures existantes.

Netweaver 2004s comprend une version émulée des versions 3.x. Vous pouvez donc conserver les structures actuelles ainsi que leurs fonctionnements. Néanmoins, si vous aviez, au prélable, des soucis de performance, il peut être intéressant de prévoir de refaire les flux en version 7.0 afin de bénéficier des optimisations possibles.

En résumé, si vous n’avez pas besoin des fonctionnalités 7.0, il est possible de continuer tel quel

Migration des requêtes.

Pour bénéficier des fonctionnalités de construction de requêtes, il est nécessaire de migrer les requêtes, cela consiste à ouvrir les requêtes une par une et à les resauvegarder. Cela permet de compiler le programme se cachant derrière en version 7.0. (Il en est de même pour les web templates) Vous pourrez alors passer par Entreprise portal pour accéder aux requêtes.

Migration des autorisations.

SAP a décidé de changer sa stratégie sur l’implémentation des autorisations. Outre de nouveaux objets d’autorisation, la limitation à des valeurs de caractéristiques a aussi changé. Il faudra donc prévoir lors de votre migration, un budget refonte des autorisations et recettes.

4^ème point : Après la migration

Autant le dire, il y a encore quelques bugs dans le système. Mais, à partir, du SP10, le système commence à être fiable. Il ne faut pas négliger de passer les support packages.

En conclusion, la migration vers Netweaver 2004s n’est pas une opération neutre, contrairement à un passage 3.0 vers 3.5. Il n’en reste pas moins vrai que bien budgété et bien planifié, le projet de migration peut aller vite !

Pour plus d’informations, n’hésitez pas à nous contacter.

http://www.censio.fr

contact@censio.fr