lundi 14 juillet 2014

A quoi sert Solution Manager ?

Depuis quelques années, SAP nous a imposé la mise en place d'un serveur spécifique : Solution Manager (SolMan). Jusqu'à la version 7.0, la plupart des entreprises voyaient en SolMan plus une contrainte qu'un atout. Mais avec la version 7.1, cette perception a commencé à changer ...

Un outil d'installation
A la base, SolMan est l'outil indispensable pour les installations et les montées de version. C'est grâce à cet outil et à la fameuse "MOPZ" ou "Maintenance optimisation" que vos administrateurs téléchargeront les objets nécessaires à votre installation ou montée de version. L'objectif  pour SAP est de vous fournir juste les composants nécessaires en comparant votre demande de mise à jour avec les composants déjà installés. Mais SolMan peut être beaucoup plus que cela.




Une solution Ambitieuse
L'ambition de SolMan est de fournir aux clients SAP tous les outils pour gérer le cycle de vie des applications SAP et de proposer des outils pour "gérer SAP comme une usine". Traduit en language commun, SolMan est une boîte à outil pour aider vos équipes techniques et fonctionnelles à gérer votre Solution SAP. La façon la plus simple de vous présenter Solution Manager est encore de vous présenter quelques outils intégrés dans la solution :

Gestion des demandes et des incidents.
Ainsi, SolMan intègre un outil de gestion des demandes, des incidents (ITSM) ou des problèmes certifié ITIL. Vos utilisateurs, vos équipes pourront créer des tickets pour déclarer des incidents techniques ou fonctionnels. Vous pourrez faire des demandes à votre centre de compétence SAP qui pourra regrouper les incidents en problèmes, suivre les demandes ou déclarer des incidents auprès de vos partenaires ou du support SAP. Vous pourrez aussi vous créer votre propre base de connaissance afin que votre support de premier niveau puisse répondre plus rapidement à vos utilisateurs. L'outil vous fournit également des états afin d'analyser vos demandes ou incidents en fonction des axes les plus importants pour vous : modules, composant, serveurs, utilisateurs, équipes ... Enfin, cette solution couvre gratuitement tous vos équipements en lien avec SAP. Donc, potentiellement, vous pouvez gérer avec l'outil, vos imprimantes, vos PC, vos équipements réseaux, vos bureaux, ...

Gestion de projet
Dès que vos équipes auront commencé à utiliser la gestion des demandes et des incidents, la suite logique est d'utiliser la gestion de projet (PPM). L'objet de cet outil est de vous fournir une solution afin de mieux planifier vos projets, suivre l'utilisation de vos ressources et éventuellement les coûts associés. Ce module peut s'interfacer avec PS qui est l'outil de suivi de coûts et de revenus des projets dans ECC et vous permettra donc d'immobiliser certains projets ou certaines phases de projet. PPM a une vision plus opérationnelle, plus planning que PS, avec un suivi de l'utilisation des ressources qui vous permettra, par exemple, de générer les fameux diagrammes de Gantt de Microsoft Project et de suivre l'avancement de vos projets en identifiant rapidement les retards ou vos besoins tout au long des phases d'un projet. Vous identifierez plus facilement les interactions entre vos projets et les membres de vos équipes qu'ils soient interne ou externe, en sur ou sous activité.

Documentation
Le module "SOlution DOCumentation Assistant" ou SODOCA est le module qui va vous aider à gérer la documentation de vos projets, de vos paramétrages et de vos développements. La bonne idée, c'est que l'outil dispose d'un outil de "documentation à partir de l'existant". Des programmes vont "lire" vos paramétrages et générer des entrées pour mettre à jour votre documentation. L'objectif sera de pouvoir maintenir votre documentation au moment ou vous modifierez votre paramétrage, le tout en un minimum de clic, les écrans pour accéder au paramétrage et à la documentation se trouvant sur un même écran SolMan. Mon regret est que les entrées de documentation sont assez formatées et sont liées à une transaction. Le problème est que, selon les profils des utilisateurs, une même transaction peut avoir plusieurs fonctions et donc plusieurs documentations. SAP a annoncé de grandes améliorations sur ce module l'année prochaine (2015) avec la sortie de la version Solution Manager 7.2 D'ailleurs, cette version devrait également apporter des améliorations notable dans la modélisation des processus. La gestion de la documentation est un point central dans Solution Manager car beaucoup de sous-modules y font référence.

 Les tests
Ainsi, la gestion des tests dans SolMan, qui vous permet se suivre l'avancement des tests et d'en automatiser certains, pourra faire référence à la documentation de vos transactions en plus de la documentation spécifique à vos plans de test. Or, la gestion des tests est un autre point critique de la gestion de projet et du maintien en condition opérationnel des solutions SAP. SAP avait déjà offert deux licences HP Quality Center pour ceux qui préféraient gérer les tests avec des outils externes, ce qui, à mon sens, peut être pertinent si vous devez gérer des tests également dans des systèmes non SAP. SAP se devait de proposer une solution afin de réduire et optimiser les tests. C'est l'objectif du module "Scope and Effort Analyser" ou SEA de SolMan. SEA permet de comparer les objets actifs standards ou spécifique de votre solution SAP avec ceux d'un support package ou d'un enhancement package que vous souhaiteriez implémenter. L'enjeu ? Vous fournir la liste des objets, transactions, programmes standard ou spécifiques impactés, un plan de test et même une estimation de la durée de vos tests.

Gestion des changements
Au delà, d'avoir la capacité à anticiper les impacts des changements, il est essentiel pour un centre de compétence de maîtriser les évolutions et de tracer ces évolutions afin de limiter les effets de bord. C'est l'objectif du module ChaRM (Change and request Management). Le but est de lier les transports de paramétrage, de programmes avec des tickets d'incidents, des demandes ou des projets déjà gérés dans Solution Manager. ChaRM met également en place des Workflow de validation, des statuts, des trains de maintenance, des versions majeures et mineures afin de faciliter les mises en production et les tests sur des solutions cohérentes. Il s'agit d'un module phare de Solution Manager 7.1 avec la mise à disposition de fonction "Retrofit", c'est à dire d'intégration entre des lignes de projet et la ligne de maintenance principale.

Cette première liste d'outil, à part l'optimisation de la maintenance, avait pour but de vous aider à gérer le cycle de vie de vos solutions ou application SAP et font donc partie intégrante de la solution ALM de Solution Manager. La seconde famille d'outil doit vous permettre de suivre, valider, contrôler le bon fonctionnement de vos systèmes et applications SAP.

Surveillance
Solution Manager va grâce à "Monitoring Alerting Infrastructure"  ou MAI vous aider à surveiller le bon fonctionnements de vos serveurs. Le principe est de déployer des agents depuis SolMan vers vos différents serveurs afin de collecter et de consolider des informations sur la bonne santé de vos différents systèmes. Solution Manager devient ainsi la tour de contrôle au centre de votre paysage SAP. L'outil permet d'émettre des alertes, de créer des incidents et donc de faire le lien avec le module ITSM. Vous avez ainsi une traçabilité complète vous permettant d'analyser les causes d'un problème que les remontées d'infotrmation proviennent de vos utilisateurs, de vos systèmes ou des deux.
Afin de compléter sa solution de surveillance technique, Solution intègre également un module de surveillance de l'espace disque des serveurs : "Data Volume Management". Cette solution peut vous fournir des informations sur l'évolution de vos solutions en vous indiquant l'espace occupé par module, la croissance et autres informations utiles pour un éventuel archivage.

Optimisation
Après vous avoir aidé à installer vos solutions SAP, à vous aider à contrôler vos systèmes, Solution Manager avec le BPmon ou "Business Process Monitoring" vous propose de surveiller le bon fonctionnement de vos processus et de surveiller l'impact de vos plans d'action afin que vos processus fonctionnent de façon optimale. Ce module vous aidera à détecter de façon proactive vos erreurs de paramétrage, vos besoins en formation en mettant en évidence les problèmes dans vos flux fonctionnels.
Riche ?
Comme vous avez pu le voir, Solution Manager est un outil riche. Cette richesse fonctionnelle se traduit également au niveau technique. En effet, SolMan est à la fois un CRM et un serveur BW consolidant les informations techniques et fonctionnelles au centre de votre paysage SAP. Solution Manager est une solution moderne qui se connecte à tous vos serveurs SAP. Vous pourrez vous y connecter en Web ou même avec des applications mobiles fournies gratuitement par SAP.

Gratuit ?
SolMan est une solution gratuite ou plus exactement incluse dans votre maintenance si vous avez au minimum une maintenance de type "Enterprise Support".  Si vous devez traiter avec Solution Manager d'objets ou de solution sans rapport avec SAP, vous devrez vous acquitter d'une licence spécifique. Cependant, comme nous l'avons vu, SAP est assez tolérant sur la notion de "en rapport ou non" avec SAP.

Solution Manager est un concentré de technologie SAP. A partir de la version 7.2 disponible fin 2015, il sera même compatible HANA, SAP vous offrant la licence HANA pour ce serveur. Il s'agit en tout cas d'un outil dont les bénéfices vont bien au delà d'un simple outil d'aide à l'installation de solution SAP. Il peut vous permettre de maximiser votre investissement SAP par la mise en place de projets avec un ROI rapide grâce à la "gratuité" des licences et donc de la maintenance.

Voir ici pour d'autres informations complémentaires...
Publié par à Aucun commentaire:
Libellés :

samedi 28 juin 2014

Tour d'horizon des outils décisionnels SAP

En marge des grands Salon SAP américains tel que le Sapphire ou le Teched qui maintenant s'appelle le D-Code, l'ASUG, l'association des utilisateurs SAP Anglophone donne sur une journée des formations sur les différents sujets d'actualité SAP. L'intérêt principal de ces formations est qu'elles sont données par des gourous SAP, le plus souvent accompagné ou en relation avec les chefs de produits SAP. Il s'en suit un mélange de formation à la fois pointue et accessible à la majorité des utilisateurs mais toujours très riche en information. Cette année, j'ai pu assister à la formation sur SAP BusinessObjects BI 4.1 avec SAP NetWeaver BW et SAP NetWeaver BW sur SAP HANA. Je vous propose donc un retour d'expérience sur les informations que j'ai pu collecter à cette occasion.

Le contenu
Cette formation a été présentée par Ingo Hilgefort membre de SAP Canada, SAP Mentor particulièrement actif sur les domaines BI 4 et les interactions avec BW et BW sur Hana. L'objectif de cette formation était de faire une présentation exhaustive de tous les outils de la BI 4.1, les possibilité de connexion avec les systèmes SAP, une prise en main des outils Webi, Analysis for Office, Analysis for Olap, SAP BusinessObjects Design Studio, Lumira Desktop et Predictive Analysis. Pour rappel, la BI 4.1 est la version qui remplace BI 4.0 et BO XI 3.1, cette dernière version n’étant plus supportée.

Rappel sur les outils décisionnels
Quand on voit la liste à la "Prévert" des outils décisionnels que propose SAP, on peut rapidement être perdu. Ce qu'il faut d'abord comprendre c'est que ces outils peuvent se regrouper dans trois grandes familles.

Reporting
La famille des outils de "Reporting" tel que Web Intelligence (Webi) ou Crystal Report constitue un premier ensemble. Ces outils servent à produire des états. Webi est une solution orientée vers les utilisateurs finaux qui peuvent créer leur propres états. Crystal est un outil "Pixel Perfect" qui peut créer des états à l'identique de ce que vous souhaitez. Crystal est plus adapté pour des états institutionnels, des états à imprimer, créé le plus souvent par le département informatique. Les deux outils ont leur aficionados et des communautés très étendues. Ils permettent également de générer des fichiers Excel et PDF. Cependant, ces deux outils ne sont pas des outils multi-dimensionnels. Ils récupèrent des données via des requêtes SQL et beaucoup de traitements restent exécutés au niveau du serveur applicatif (Serveur BO). L'impact ? Si vous souhaitez avoir un état sans faire apparaitre les lignes avec des zéros, ce traitement se fera au niveau du serveur BO et pas du serveur de base de données. Les données avec ou sans zéros sont envoyées au serveur BO qui n'affichera ensuite que les données sans zéros. Donc si vous espérez que votre super serveur HANA accélère vos états favoris qui comporte des millions de lignes avec des zéros, dans ce cas ci : Mauvaise pioche !!! Pour répondre à cette problématique, utilisez plutôt Analysis.

BI Agile, Data Mining, Visualisation de données.

La seconde famille d'outils concerne les outils dit de "BI Agile". Le principe est ici, d’analyser, de visualiser soi même les données à partir de sources sur le serveur et en local. Les outils de référence sont ici Analysis dans ses deux versions Microsoft Office et Web et le petit nouveau Lumira.
 Lumira est l'outil SAP pour contrer des outils concurrents tels que Qlikview.  L'outil est récent (2 ans) encore perfectible notamment sur la partie échange et collaboration (view / stories) mais possède un beau potentiel. A aujourd'hui, imposer un serveur HANA différent de BW on HANA pour partager ses analyses me parait rédhibitoire sur l'aspect collaboration. Une évolution de la solution Lumira, Predictive Analysis permet sur le même outil d'effectuer des analyses de tendance ou des prévisions.

Analysis est l'outil qui a vocation  à remplacer l'outil historique de reporting de SAP BW : le Bex. Pour rappel, le Bex est désormais en maintenance, mais il sera supporté au moins pendant 9 ans. Analysis for Microsoft Office ne peut fonctionner en même temps que le Bex sur le même Excel. Les deux peuvent être installé sur le même poste mais pour en utiliser un vous devez désactiver l'autre. Dans sa dernière version, l'outil intègre par exemple un outil de conversion des Workbook Bex ou encore le support tant attendu des graphiques Waterfall. D'une façon générale, SAP a décidé que Analysis for Microsoft Office serait son outil décisionnel intégré à la suite Office. Ainsi, après la mort annoncé du Bex, un autre outil est également appelé à disparaître l'EPM Add-in. Une partie des fonctionnalités de ce dernier devrait être intégré dans Analysis dans sa version à paraître en décembre 2014. J'ai personnellement hâte de voir cette version car si j'ai souvent été frustré par l'utilisation d'Analysis (dans ses premières versions), l'EPM Add-in est un outil aux fonctionnalités impressionnantes. L'EPM Add-in permet via des formules auto-générées de récupérer des données de cubes, de requêtes et donc une mise en forme dans Excel très très souple. C'est également l'outil qui vous permettra de saisir des informations dans Excel et de les stockées dans des cubes BPC et sous certaines conditions dans des cubes BI-IP. Juste une petite parenthèse, même s'il est possible de se connecter à un cube, préférez toujours la connections via une requête. La connections a un cube en direct implique notamment la perte de tous les mécanismes d'autorisations. Analysis est un des outils décisionnel SAP qui évolue le plus. Il y a en général deux versions par an et celle de décembre s'annonce donc comme un must avec donc la possibilité de saisir des données dans des cubes, le support amélioré des commentaires Excel ... Il y a bien évidement plusieurs raisons à cette rationalisation  et à ces ajouts de fonctionnalités. Il ne faut pas oublier que Analysis est un outil payant (au même prix que l'EPM Add-in) alors que le Bex est un outil gratuit. Évidemment, pour passer d'un outil gratuit à un outil payant, il faut un certain nombre d'apports fonctionnels pour franchir le pas. Avoir moins d'outils avec des fonctionalités étendues permet également à SAP d'avoir une solution décisionnelle plus simple et efficace, tout en facilitant et réduisant la maintenance.
 
Tableaux de bord
La dernière famille concerne les Dashboard ou tableaux de bord. L'outil de référence, dans cette famille, est SAP Design Studio. C'est un outil basé sur HTML5 qui a pour vocation à remplacer Xcelcius qui était basé sur une technologie Flash. Concernant les licences, si vous avez des licences Xcelcius, vous avez des licences SAP Design Studio. La fin de maintenance de Xcelcius n'est pas encore annoncée mais les développements sur cet outil sont désormais stoppés. SAP Design Studio remplace également un ancien outil SAP, le Web application Designer (WAD). Cet outil était le pendant web du Bex.  Comme le WAD, SAP Design Studio permet désormais de saisir des données dans des cubes BI-IP et la saisie dans des cubes BPC sera sans doute possible avec l'arrivée de la solution "Unified Model" qui va regrouper les solutions BPC et BI-IP. Ce regroupement mérite à lui seul un futur article :-)
SAP Design Studio progresse à un rythme comparable à Analysis avec au minimum une version majeure par an. C'est un outil également destiné à publier des applications sur mobile ou tablette. Il est même possible de transférer des vues Analysis vers SAP Design Studio pour les publier vers des mobiles, le tout de façon presque automatique. C'est un point important car si demain voir ses tableaux de bord sur tablette sera de plus en plus courant, pouvoir le faire sans développement spécifique me semble être un point essentiel afin de limiter la maintenance et les développements.

Pour conclure, sur les outils décisionnels SAP, voici un petit tableau comparatif qui vous donnera une idée des forces et faiblesses de chaque outil. Évidement, comme nous avons pu le voir les fonctionnalités de certains outils évoluent beaucoup, n'hésitez donc pas à vérifier ces évolutions par vous mêmes.
 
Connectivité
Un outil décisionnel n'est rien s'il n'a pas accès à des données. C'est pourquoi, il est tout aussi important de bien comprendre les possibilités d'accès aux données car malheureusement, tout n'est pas possible. Ainsi, dans le cadre de l'intégration des outils BusinessObjects, SAP a développé une couche d'interface entre les outils BI4 et BW appelée BICS. Ce moyen d'accès permet d'éviter d'avoir à créer des univers pour les clients issus du monde SAP. Il était en effet un comble d'avoir à créer un "univers" alors que vous gériez déjà des cubes et des requêtes. Mais au delà de cette évidence, le passage par la couche BICS a apporté un meilleur support des fonctionnalités propre à BW telle que les hiérarchies ou les variables. Ces fonctionnalités puissantes sont liées aux requêtes crées avec le SAP Query Designer. Cet outil historique SAP, qui permet de créer des requêtes, est lui bien vivant.
Ainsi, un client historique BO travaillant avec des "univers" peut donc voir des fonctionnalités apparaitre dans les outils de restitution sans qu'il lui soit possible de les mettre en œuvre car liées à des requêtes BW. De la même façon, un client BW pourrait avoir des fonctionnalités impossible à mettre en œuvre tant que la source des données ne sera pas gérée sous HANA (BW ou Business Suite).
Au delà de la capacité à faire ou ne pas faire, la capacité d'accéder à vos données peut avoir des impacts multiples. Si depuis BI4, je peux accéder directement à mes données dans ECC sur HANA pourquoi les recopier dans BW ? Ai je besoin de BW ? Si je veux croiser des données stockées uniquement dans BW sur HANA avec des données dans ECC sur HANA, BW peut y accéder et me les présenter via une seule requête ? Si je n'ai plus besoin "d'univers", quelle compétence dois je acquérir ? 

Avec l'arrivée de HANA dans votre paysage , vous pourrez également vous connecter au niveau des vues HANA. Il est possible d'envoyer dans HANA des infoset ou des résultats de requêtes et d'y accéder directement depuis BI4. (L'intérêt ici est de descendre des calculs au niveau de la base de données pour accélérer les traitements ou pour utiliser des fonctions de "prédiction" disponible au niveau du moteur HANA.) Toutes ces options, si elles enrichissent la solution, la complexifie également.


Je suis conscient d'avoir perdu la moitié de mes lecteurs sur le dernier paragraphe. L'objectif  est juste d'essayer de vous faire prendre conscience que le décisionnel ce n'est pas uniquement comment vous présenter des données mais aussi comment vous y accéder, comment vous les stocker ... 
Cependant, ne perdez pas de vue le plus important : quel est votre objectif final ? Que vous voulez faire ?
Quand vous échangez avec vos utilisateurs ne vous concentrer pas sur la technique mais sur les besoins. Un bon décisionnel est un décisionnel qui répond simplement à une question complexe. La plupart du temps pas la peine d'en faire des tonnes. Un simple histogramme en noir et blanc est généralement plus efficace qu'un camembert bariolé de couleurs. Les écrits et les exemples de Stephen Few (à chercher sur google) sont, en la matière, particulièrement intéressant.













Publié par à Aucun commentaire:
Libellés : ,

dimanche 15 juin 2014

Archivage avec HANA, de grands changements à venir

Durant des années, les limites techniques, nous ont dictés l'obligation de limiter les données dans les systèmes transactionnels. Afin de limiter ces données, les process traditionnels incluaient la mise en place de processus d'archivage, de transfert vers des systèmes d'archivage électronique (SAE) et le plus souvent des transferts vers des systèmes décisionnels, la manipulation des données dans les SAE étant généralement très limitée. 

La révolution "Big Data"
Sauf que le "Big Data" et HANA remettent en cause ce modèle traditionnel et ce pour deux raisons principales. D'abord, quand vous traitez du "Big Data", gérer quelques Terra-octets de données supplémentaires n'est pas un problème critique. Ensuite, HANA, à la différence des systèmes traditionnels, est un système transactionnel ET un système décisionnel. Or, dans un système décisionnel, plus vous avez de données, plus vos analyses seront précises. Des analyses précises mènent à de meilleures décisions. De meilleures décisions mènent à l'efficience opérationnelle, à des réductions de coûts et à des réductions de risques. Sur un système HANA, vous avez donc tout intérêt à conserver les informations de détail le plus longtemps possible. Bon, vous me direz pourquoi pas mais l'objectif de l'archivage était à la fois supprimer des données pour gagner en performance mais aussi transférer des données sur des systèmes moins cher pour diminuer le coût total de possession (TCO). Et à priori, ce n'est pas avec HANA que le TCO va se réduire.

 Tout est dans la gestion de la température !
SAP est bien évidement conscient de cette objection et travaille a une solution : la température des données ! Le principe est simple. Adapter, le stockage des données en fonction de leur utilisation. Les données les plus utilisées ou données chaudes doivent se situer en mémoire. Les données utilisées ponctuellement ou données tièdes doivent se situer sur disque sur le serveur HANA. Enfin, les données rarement utilisées ou données froides devront être stockées sur SAP IQ ex Sybase IQ. Avec ce principe, plus besoin d'archivage, vous stockez vos données sur un serveur qui a une très grande capacité de stockage, de très bon temps de réponse aussi bien en chargement qu'en lecture et ce qui ne gâche rien il suffit d'un serveur standard pour héberger une solution SAP IQ. 
 
 Vitesse et Performance
Hasard vous me direz, SAP vient juste de battre deux records du monde avec une base SAP IQ. Le premier concerne le chargement et l'indexation de données à une vitesse de 33,4 terabytes par heure. Le second concerne la création d'une base de donnée de 12,1 petabytes. L'objectif de ces deux records me semble clair : nous prouver que SAP IQ a la capacité de stocker nos archives "Big Data" ou pas "Big Data". Cela sans compter que SAP IQ est une base en colonne et que donc la compression des données est très bonne et l'accès en lecture bien meilleur que sur les bases de données relationnelles traditionnelles.

 L'archivage en ligne
SAP a donc les moyens de stocker les données. La question qui reste en suspens est donc comment stocker les données dans cette base. C'est ici qu'intervient la technologie "Near-line Storage" ou NLS. NLS est une technologie qui permet de stocker des informations issues de SAP BW dans différentes bases de données dont SAP IQ. L'avantage de NLS sur de l'archivage classique, c'est que, lors d'une requête, le serveur BW sera capable de rapatrier les données stockées via NLS. NLS est donc une technologie d'archivage transparente pour les utilisateurs qui peuvent accéder à leurs données via leur outils habituels, sans savoir que les données ont été archivées. 

Les seules "faiblesses" de cette technologies étaient: 
  • Les données stockées via cette technologie n'étaient pas modifiables.
  • Les données sont stockées via des règles implémentées par les administrateurs généralement en fonction de la durée de rétention des données. 
  • Cette technologie n'existe que pour BW.

"étaient" car au Sapphire, il y a eu plusieurs annonces autour de NLS.
  • SAP travaille à ce que les données stockées via NLS soient modifiables. L'objectif est d'éviter des rechargements dans BW à la fois pénible et long. Cette modification est annoncée pour cette année (2014).
  • SAP réfléchit à implémenter un moteur qui déterminera automatiquement quelles données devraient être déplacées vers NLS. 
  •  SAP travaille sur une nouvelle solution fonctionnant sous HANA appelée "Extended Storage". L'objectif est de pouvoir stocker des données dans SAP IQ sur le principe de la température des données.
Jusqu'à présent, je n'ai pas parlé du coût de la solution NLS. Ce qu'il faut savoir, c'est que si cette solution est payante, elle est souvent inclue dans des packages. D'autres part, certaines solutions basées sur NLS mais utilisant des bases de données concurrentes telle que DB2 peuvent être gratuite. Vous disposez donc d'un certain nombre d'argument pour bien négocier avec SAP.

En conclusion, j'ai le sentiment que même si l'archivage ne va pas disparaître, il va fortement évoluer. Vos données, même archivées, seront accessibles. Même si cet article concernait plus l'archivage des données que l'archivage légal, ce dernier sera forcément impacté par ces évolutions. En effet, comme l'administration fiscale a toujours toléré les audits sur les systèmes "live", cela pose des questions sur l'avenir des systèmes SAE ou autres "Content Serveur" pour stocker les archives de données. Enfin, comme on l'a bien vu, ces évolutions sont fortement liées à HANA. Il est donc fortement probable que SAP offre ces technologies avec HANA afin d'améliorer le retour sur investissement (ROI) de sa base de données "In-Memory". Cette option sonnerait le glas de diverses solution NLS ou de serveur de stockage de partenaires SAP.
Publié par à Aucun commentaire:
Libellés : , ,

samedi 14 juin 2014

HANA, a-t-on vraiment le choix ?

Faut-il passer sur HANA ? 
Va-t-on nous obliger à passer sur HANA ? 
Ou encore quand faudrait-il passer sur HANA ?

Toutes ces questions sont des questions récurrentes au sein des entreprises surtout au lendemain des grands salons SAP où le sujet principal de toutes les présentations reste le plus souvent lié à HANA.

Essayons d'y voir plus clair au travers de quelques faits :
  1. Les investissements SAP et les nouveaux développements sont presque tous liés à HANA.
  2. SAP a demandé à ses partenaires que leurs solutions fonctionnent sous HANA même si les volumes de données à gérer sont faibles. Ex : Opentext
  3. Les experts s'accordent sur le fait que les bases de données traditionnelles n'ont pas d'avenir et seront remplacées par des solutions "In-memory". Ex : Dr. Bjarne Berg - Cf : Qu'est ce que HANA ? Ces solutions ne seront pas forcément HANA. Par exemple, Oracle a sa propre solution avec Exalytics. Un autre exemple de cette tendance vers le "In-memory" est visible au travers les annonces HP sur les "memorystore" et l'apparition de serveurs sans disques. (voir article en Anglais ici)
  4. A l'heure actuelle, le coût des serveurs HANA est divisé par deux chaque année. Les optimisations au niveau du logiciel HANA facilitent aussi le rapprochement des serveurs HANA et des serveurs standards. Ainsi, les optimisations sur l'écriture des logs HANA rendent l'utilisation des cartes Fusion IO ou des disques SSD optionnels. Les derniers serveurs Fujitsu ne font d'ailleurs plus appel à ses technologies.
  5. SAP développe les cas d'usage de HANA pour multiplier les gains pour les clients -  CF : Article SAPPHIRE NOW 2014
  6. Le nombre d'application sur HANA uniquement croit et donc la part de maintenance sur ces applications va croissant.
  7. SAP est le premier client d'Oracle. Or, Oracle est le premier concurrent de SAP. La maintenance versée par SAP a Oracle permet donc à Oracle de développer des solutions concurrentes à SAP. Les tensions sont vives entre les deux éditeurs. De nombreux contentieux les opposent dont un procès en cours. Malgré tout, SAP a garantit le support des bases de données tierces telles que Oracle jusqu'en 2020. SAP ira t il au delà ?
  8. Maintenir plusieurs versions d'un même logiciel est très coûteux. C'est pour cela que les éditeurs limitent la période de maintenance sur leurs produits et ont tendance à consolider les solutions après des acquisitions externes.
 En route vers HANA
Avec ces quelques points, il n'y a pas besoin d'être visionnaire pour comprendre qu'à terme SAP ne maintiendra qu'une seule solution : les solutions fonctionnant sous HANA.
Maintenant, cela ne veut pas dire que SAP va forcer la bascule de ses clients vers HANA dans un avenir proche. Si SAP souhaite basculer rapidement ses clients vers HANA, il devra faire un effort significatif sur les prix et même dans ce scénario, l'expérience de BW qui a été obligatoirement intégré aux licences ECC à laisser plus d'un client insatisfait. La meilleure stratégie pour SAP  est donc de vendre la solution HANA au meilleur prix pendant la phase de transition, d'ajouter un maximum de fonctionnalités à la solution HANA pour inciter les clients à migrer, avant d'annoncer la fin de toute évolution sur des solutions non HANA puis d'annoncer la fin de maintenance standard sur les produits non HANA. Les clients pourront sans doute souscrire une maintenance supplémentaire pour le support des bases de données tierces ce qui finira par rendre le coût d'exploitation plus cher qu'une bascule sous HANA. Attention, je précise bien que SAP n'a rien annoncé officiellement et que ce déroulement n'est que mon opinion personnelle. Concernant, le planning, je pense que cela va fortement dépendre de l'adoption de HANA. Plus de client basculeront vers des solutions SAP HANA / ASE / IQ, plus la probabilité que la maintenance des bases tierces soit étendue au delà de 2020 sera faible.
 
Quand basculer sur HANA? 
Il y a évidement plusieurs réponses à cette question. Dans le cas, ou vous êtes un nouveau client SAP, le choix me semble plus simple. Vous avez tout intérêt à choisir une solution HANA Runtime qui vous offrira HANA pour un pourcentage appliqué sur chaque licence utilisateur achetée. C'est un modèle assez semblable à celui appliqué par SAP pour la revente d'autres bases telle que Oracle. Il s'agit d'une solution généralement assez intéressante. A vous de bien négocier le montant du pourcentage sachant que 15% est le pourcentage appliqué pour Oracle. Si le choix de "quand basculer" est donc simple (pour moi) pour les nouveaux clients, la réponse est moins simple pour les clients historiques.
    Quand c'est économiquement rentable pour vous ! 
    SAP l'a bien compris, le nerf de la guerre étant l'argent, le point critique va donc être les cas d'emploi où HANA va vous aider à dégager de la productivité et des économies. Dans certains cas, cela reste assez facile, notamment pour les entreprises gérant beaucoup de valeur en stock. Ainsi, le DSI de "Animal Health International" a fait une présentation au Sapphire (en Anglais) indiquant que HANA avait généré une économie de 10% sur la gestion des stocks et que cette économie avait largement couvert le coût d'une mise en place de la solution HANA. J'ai également assisté à une présentation du DSI de KingFisher qui gère notamment les magasins Castorama en France qui indiquait que le retour sur investissement (ROI) de la solution HANA avait eu lieu en une journée. (L'économie générée par le passage en temps réel du calcul de stock, la réduction des encours de stock sur le groupe était telle que les 3 millions de £ du projet avait été amortit en une journée.) Au-delà des gains potentiels dans la gestions des stocks, il y a des gains également dans la gestion des ventes et l'analyse instantanée des ventes. Les industries Retail sont donc de parfait candidats à la mise en place de HANA. Les industries gérant  de gros volume de données ont également potentiellement des économies à réalisées avec HANA.

    Quand c'est techniquement intéressant ! 
    Les coûts d'un projet HANA se divisent en trois partie : Les licences, le matériel et le Consulting. Force est de constater que l'écart entre le coût d'un serveur HANA et le coût d'un serveur standard ne cesse de se réduire. De plus, lors de la bascule sur HANA vous pouvez également économiser sur les coûts de maintenance des bases tierces de votre paysage SAP. Une bascule vers HANA pour des raisons purement technique n'est pas encore rentable mais entre la simplification de votre paysage (moins de serveurs, tous les serveurs basés sur la même architecture (OS, Base), les économies liées à la compression (Sauvegarde, disques), les arguments technique peuvent être un argument de poids. 

     Quand il y a un intérêt métier !
    HANA peut permettre la mise en œuvre de solution dont les gains sont plus difficilement chiffrable mais qui crée un apport métier indiscutable : répondre rapidement à des questions complexes sur des volumes de données important, laisser vos métiers faire leur propres analyses sur de gros volumes de données, faire des analyses de tendances ou prédictives, mettre à jour vos indicateurs sans rechargement des données ... Réactivité, flexibilité, autonomie, simplification généreront productivité et des gains certains. Le calcul du retour sur investissement est juste plus complexe à réaliser.

    En conclusion, vous seuls êtes en capacité de déterminer le meilleur moment  pour basculer vers HANA. Plus vous attendrez, plus négociation avec SAP seront difficiles et/ou les gains en licences attachées à la bascule limité, mais plus les gains seront faciles à identifier et les coûts techniques réduits. Restez à l'écoute, ne négligez pas la veille technologique autour de HANA afin de ne pas manquer la bonne opportunité.
    Publié par à 1 commentaire:
    Libellés :

    mardi 10 juin 2014

    Simplicité

    S'il n'y avait qu'un mot à retenir de cette édition 2014 du Sapphire Now, ce mot serait Simplicité. 

    Ainsi, il semble que tous les dirigeants de SAP AG et notamment Bill McDermott, nouveau directeur général unique de SAP, ont pris conscience que le système d'information SAP était trop complexe, pas assez flexible et trop peu ergonomique. Tout au long de ces trois jours de salon, l'équation complexité = perte de productivité = coût de possession (TCO) plus élevé = retour sur investissement incertain a été répétée dans toutes ses variantes possibles. Vous me direz que ce n'est pas vraiment une grande nouvelle pour la plupart des utilisateurs mais cette fois ci SAP semble avoir un plan pour mettre en œuvre cette simplification. 

    Un effort sur l'ergonomie.
    Côté ergonomie, les solutions s'appellent Fiori et Personas. Ces deux solutions qui étaient auparavant payantes, respectivement 100€ et 300€ prix public par utilisateur, doivent permettre à SAP et à ses clients de refondre les principaux écrans SAP. 

    Mais pourquoi deux produits ?
    Une solution SAP comporte plus de 350 000 écrans. Même si, tous ces écrans ne sont pas utilisés chez tous les clients, la refonte de tous ces écrans pourrait prendre beaucoup de temps. L'idée est donc que SAP refonde les écrans à la fois critique et les plus utilisés et crée de nouvelles application grâce à Fiori et fournisse avec Personas, un outil à ses clients pour refondre eux-mêmes les autres. SAP offre également la possibilité à ses clients de modifier ou de créer des applications avec Fiori mais la modification d'un écran avec Personas est intuitive avec un résultat rapide.

    Refondre les écrans ?
    Vous n'allez pas reconnaître votre SAP, des applications web, des écrans dynamiques et épurés, un minimum de clic jusqu'à votre information: une mini révolution.
    Vous validez des demandes d'achat dans SAP ? Vous allez avoir un choc. Vous vous connectez à SAP, un coup d’œil vous savez combien vous avez de demande en attente de validation. Un clic, vous voyez la demande d'achat à valider, un clic vous valider la demande d'achat. Wow, ça fait juste 15 ans que j'attendais ça. Le plus beau, c'est que vous pouvez visualiser l'application sur votre PC, Mac, tablette ou mobile et l'application s'adapte toute seule à la taille de l'écran. Fiori est plus qu'un simple changement d'écran. Le déroulement de la transaction est lui-même revu, simplifié et adapté au profil de l'utilisateur. 

    Cette petite révolution est maintenant gratuite et accessible à presque tout le monde ... 
    SAP livre presque tous les trimestres de nouvelles applications. Aujourd'hui, on en est presque à 400. Cependant, chaque application va avoir besoin d'un niveau de version minimum de votre serveur ECC. Si pour certaines le niveau est assez bas pour d'autres, il vous faudra un serveur ECC en 7.40 sur HANA soit la toute dernière version. De plus, cette petite merveille va nécessiter un nouveau serveur et sans doute quelques jours de paramétrage. Côté SAP Consulting, une solution de mise en œuvre rapide (RDS) existe et n'attends plus que vos bons de commande.

    Dessines moi un écran ?

    L'autre solution d'optimisation de l'ergonomie des écrans, Personas permet de redessiner un écran SAP. Ici aussi, l'objectif est de d'augmenter la productivité en modifiant l'apparence et le fonctionnement des écrans. Personas génère une page web comme surcouche par-dessus l'écran standard. Vous pouvez ainsi supprimer des champs de l'écran, mettre des images, changer des libellés regrouper des champs qui se trouvent sur plusieurs onglets sur un seul écran, le tout presque sans une ligne de code. Comme les écrans standards SAP ne sont pas modifiés, il n'y a presque aucun impact en cas de changement de versions.
    Certains d'entre vous connaissent peut être un produit d'un partenaire SAP qui s'appelle GuiXT ? Et bien en gros, Personas c'est pareil sauf que c'est fourni par SAP et que c'est gratuit. Cela pose d'ailleurs la question de la pérennité du produit GuiXT. J'ai posé la question sur le stand Synactive à Orlando et le moins que l'on puisse dire c'est que les réponses étaient évasives du genre "le produit existe depuis des années ..." Généralement, quand on parle du passé en informatique au lieu de l'avenir, c'est que cela ne sent pas bon ... La réalité, c'est que les produits ne jouent pas dans la même cour. Ainsi, les premières versions de Personas avaient un gros problème de performance. Avec Personas, les écrans s'affichaient beaucoup plus lentement. Pour résoudre, le problème, SAP a introduit des modifications dans le kernel 7.40
    Difficile de lutter dans ces conditions quand des acteurs peut changer les règles du jeux à volonté. Par contre, cela indique aussi que si vous souhaitez utiliser Personas vous devez être sur les dernières versions de SAP mais pour une fois pas obligatoirement sur HANA.

    HANA, HANA, HANA
    L'ergonomie aura été la grande gagnante de ce Sapphire Now.  Maintenant, améliorer l'ergonomie n'améliore pas vos processus, ou ne simplifie pas la gestion de vos serveurs. C'est Hasso Plattner, lui-même qui a tenté d'apporter une réponse à ces problématiques lors de sa Keynote.  Comme on pouvait s'en douter, la réponse à tous nos maux s'appelle HANA. Maintenant, il faut avouer que fidèle à son habitude M. Plattner sait se montrer convainquant. 




    Côté technique, les arguments tiennent d'abord, sur les bénéfices de la compression HANA, les bases plus petites coûtent moins en disque et en sauvegarde. Il est sûr que le passage d'un SAP de 7,1 To sur DB2 à 1,8 To sur HANA doit permettre certaines économies. Il semble, cependant,  que l'époque du "tout en mémoire" ou "Full In-memory" soit révolue du moins tant que le coût des serveurs HANA ne sera pas plus proche du coût des serveurs standards. 

    Aujourd'hui, l'objectif est d'optimiser les coûts des serveurs en optimisant la température des données. Pour résumer, les données dite "Chaudes" doivent être stockées en mémoire car elles sont les plus souvent utilisées, les données tièdes, utilisées de temps à autre doivent être stockées sur disque et les données rarement utilisées doivent être stockées sur SAP IQ qui a de grandes capacités de stockage à un coût bien inférieure à HANA tout en conservant les bénéfices de la compression. 



    Comme HANA permet d'accéder beaucoup plus rapidement aux données, il est possible de supprimer les agrégats, c'est à dire les tables de consolidations ou d'index qui était auparavant indispensable. Cette suppression des données redondantes contribue également à diminuer la taille des bases mais permet en simplifiant le stockage des informations d'avoir des programmes plus simple, plus rapide et donc plus facile à maintenir. Ainsi, SAP va proposer une nouvelle version de ses solutions basée sur HANA nommée "Simple  Suites" en commençant par la Finance avec "Simple Finance". En supprimant, les agrégats, la solution devient beaucoup plus flexible. En effet, comme les agrégats ou autres hiérarchies ne sont plus stockées dans des tables mais calculés à la volée, il devient possible de modifier ces agrégats sans traitement lourd. L'enjeu est d'avoir un système capable de simuler ou d’exécuter des changements organisationnels sans projet informatique lourd, d'effectuer des clôtures et des consolidations en temps réel ... 

     Autre tendance liée à HANA vu au Sapphire concerne la suppression des données redondantes non plus au sein d'un système tel que ECC mais au sein du paysage SAP. Si tous vos systèmes sont sur HANA, pourquoi recopier les données d'un système à un autre ? Ainsi la taille de certains systèmes pourrait être réduite de façon importante. Je pense à BW mais aussi à Solution Manager dont la version 7.2 qui tournera sur HANA pourra si elle fonctionne au sein d'un paysage HANA avoir une taille réduite de 75%.
    Avec cette volonté simplificatrice, SAP détient sans doute la clé du succès ou de l'échec de son ERP pour les prochaines années. Limité la simplification à une simple vision technique serait sans doute une erreur. SAP a également abordé lors des Keynote une volonté de simplification au sein de son organisation. Espérons que cette simplification s’étendra à d'autres domaines tels que la politique tarifaire de SAP.
    Publié par à Aucun commentaire:
    Libellés :

    lundi 9 juin 2014

    Qu'est ce que HANA ?


    HANA est un acronyme pour "High-Performance Analytic Appliance".  HANA est donc une base de données en mémoire et en colonne développée et vendue par SAP. HANA est une appliance, c'est à dire un logiciel qui fonctionne sur un serveur dont les caractéristiques sont définies par SAP et qui couvre toutes les couches logicielles (OS, Base de données, Applications). Comme HANA est une appliance, on entend souvent parler de plateforme HANA même si à la base HANA est principalement une base de données. HANA est une base de données OLAP et OLTP, c'est à dire une base de données optimisée pour des traitement transactionnels (ex: saisie comptable) et optimisée pour des traitement analytiques (ex: reporting décisionnels, calcul d'indicateurs). HANA est sortie pour la première fois sur SAP BW en Novembre 2011 et pour les solutions ERP en Janvier 2013.

    Origines 
    La création de HANA par Hasso Plattner est partie d'un constat simple sur l'évolution de l'informatique : la technologie des disques se meurt. Or, toute la gestion des systèmes de fichiers repose sur gestion des disques et les systèmes de base de données repose sur la gestion de fichiers. Les éditeurs de base de données propose de plus en plus de mettre en cache les données, c'est à dire en mémoire mais les bases du système étant mauvaises, il s'agit juste d'un contournement sur une solution mourante.
    La solution ? Changer de paradigme : avoir une base de données basée sur la mémoire et la vitesse des processeurs et ne plus utiliser les disques que pour conservation des données. Cette solution, c'est le "In-Memory".

    L'autre caractéristique de HANA est d'être à la fois une base données en colonne et en ligne alors que les bases de données traditionnelles sont des bases de données en ligne. HANA stockera en ligne ou en colonne en fonction de l'efficience pour les données stockées.

    Afin de vous expliquer de façon simple la différence entre un stockage en ligne et un stockage en colonne, voici un petit exemple.
    Dans une base de données en ligne, les données sont stockées en ligne et chaque ligne a un identifiant ou clé. Dans une base de données en colonne, les informations sont stockées en colonne et l'identifiant unique est la données elle-même. Cela a plusieurs conséquences:
    1/ Comme vous pouvez le constater dans le tableau "Données en colonnes optimisées", il y a un gain de place, il y a moins de données redondantes.
    2/ Si je dois retrouver un enregistrement à partir d'un nom, ou connaître le nombre d'enregistrement avec le prénom "Marie", avec une base en ligne, je dois lire toute la table, tandis qu'avec une base en colonne, le plus souvent une lecture simple suffit.
    3/ Ajouter un champ supplémentaire avec une valeur unique va être beaucoup plus rapide sur base en colonne.
    4/ A contrario, Modifier une base de données en colonne, par exemple changer le prénom du quatrième enregistrement de Marie en Julie est beaucoup plus compliqué.

    C'est pour cela que des bases de données en mémoire telles que Sybase IQ, maintenant SAP IQ sont très efficaces pour des bases analytiques (OLAP) alors que des bases en ligne telles que Oracle sont plus efficace sur des données Transactionnelles (OLTP). La force de SAP est d'avoir réussi à combiner le meilleur des deux mondes pour avoir une base de données plus efficace et rapide aussi bien pour du transactionnel que du décisionnel.

    Flexibilité
    D'une part, les requêtes sur une base HANA peuvent être exécutées 400 à 900 fois plus vite que sur une base de données relationnelle classique. D'autre part, les agrégats ont peu d'intérêts sur les bases en colonnes. On voit bien si on reprends l'exemple précédent qu'il est relativement facile d'obtenir la somme des salaire des prénoms "Marie". La conséquence logique est la suppression des agrégats avec HANA. Or, les agrégats s'ils permettent aux bases de données relationnelles d'être plus rapide, ils les obligent à être moins flexible. Prenons l'exemple d'un cube dans SAP BW où vous souhaiteriez rajouter un champ calculé. Sans HANA, vous devez rajouter le champ dans la structure du cube puis recharger le cube. Avec HANA, le cube qui est agrégat, n'existent plus et sont transformés en sorte de cube virtuels, les calculs sont donc effectués en temps réel à la volée sans stockage supplémentaire de données. Il n'y a donc plus de chargement de données à faire. En fonction du volume du cube,  cette opération peut durer des heures. Cette opération peut être renouvelée plusieurs fois, en cas d'erreur de calcul, de changement de règle ... On voit bien les gains potentiels d'une solution gérée sous HANA.
    De même, on voit bien les bénéfices potentiels sur l'ERP avec les possibilités de faire des clôtures, des consolidations en temps réels.

    Licences
    L'appliance HANA est plus que juste une base de données. En effet, les licences généralement incluent d'autres logiciels tels que Data Integrator, l'ETL pour Extraire, Transférer les données et Charger les données ou SLT, l'outil pour synchroniser des tables avec HANA. Deux types de licences permettent d'acheter HANA. Les licences "Runtime" ont une métrique basée sur le montant de la maintenance et sur le montant des licences achetées. Les licences "Full use" ont une métrique basée sur le volume de mémoire utilisé par HANA. Les licences "Runtime" ont un mode de fonctionnement assez similaire à ce qu'il existait si vous achetiez votre base de données Oracle ou MSSQL via SAP. Il est a noté aussi que les binaires pour la base de données ASE sont inclut, ce qui vous permettra de basculer votre paysage sur HANA + ASE et de ne plus payer de maintenance à votre éditeur de base données actuel. Cependant, SAP a décidé de ne pas appliquer les remises déjà négociées avec les clients sur les licences HANA. Le coût des licences HANA évolue presque chaque trimestre en fonction des promotions. N'oubliez pas que si la négociation des remises HANA est difficile, il est toujours possible de négocier les licences complémentaires sur les utilisateurs et les produits annexes.

    Matériel
    Plusieurs constructeurs propose maintenant des appliances HANA.On peut citer Fujitsu, HP, IBM, Hitachi, Cisco, Dell pour n'en citer que quelques un. Chaque matériel devant être certifié par SAP, les configurations restent assez similaires mais chaque constructeur peut avoir des particularités. Un serveur HANA se caractérise par beaucoup de mémoire, des processeurs avec de nombreux  cœurs, d’ailleurs SAP impose un ratio CPU / Mémoire. Chaque appliance se voit doter de nombreux disques. Si au début, les serveurs intégraient systématiquement des accélérateurs de disques (Cartes Fusion IO) ou disques SSD, certains constructeurs arrivent maintenant à s'en passer. Cela reste une bonne nouvelle car cela devrait permettre de réduire le coût des appliances. Le prix d'une appliance varie fortement en fonction de la mémoire utilisée. En 2014, il faut compter entre 70 K€ et 80K€ pour un serveur 1 To.
    Publié par à Aucun commentaire:
    Libellés :
    Inscription à : Articles (Atom)