Archive

Posts Tagged ‘BI’

Congrès Big Data Paris: le concept devient réalité!

April 2nd, 2013 No comments

Demain aura lieu le lancement de la 2nde édition du Congrès Big Data Paris  ! Le programme est foisonnant, prouvant ainsi que le stade du concept « buzz » s’est suivi de réalisations concrètes et d’une adoption large du sujet par le monde du Business.

En ce qui me concerne, mes attentes se focalisent autour de 3 thèmes :

  • Des retours d’expérience concrets afin de mesurer à mon niveau les réelles applications projets. J’espère qu’au cours de ces REX, sera également mise en lumière, de manière chiffrée, la valeur ajoutée économique de la réalisation d’un projet Big Data.
  • La compréhension fine des technologies du Big Data et surtout quelles sont les articulations d’architectures techniques possibles pour optimiser une plateforme Big Data.
  • En troisième attente mais pas des moindres, je souhaite pouvoir mieux appréhender, aux termes de cette conférence, ce que le Big Data change à la Business Intelligence ; et ceci autant sur la façon d’aborder les problématiques décisionnelles que sur les aspects évolutions des technologies de la BI.

Vivez Grimm m’accompagnera dans le cadre de nos actions de veille et de montée en expertise et s’interressera particulièrement à :

  • l’évolution de la BI grâce au Big Data. Pourquoi et comment le système de BI actuellement utilisé doit évoluer ? Les intérêts sont-ils uniquement sur les performances ?
  • les projets qui marchent : quels sont-ils ? Pourquoi ont-ils fonctionné ? Et comment sont-ils implémentés ?
  • d’éventuelles comparaisons techniques des technologies.

Les attentes sont donc à la mesure du sujet : Big! Nous partagerons nos découvertes via le fil Twitter Novediagroup.

Envoyer des IDOC SAP avec BODS

August 7th, 2012 No comments

Retour d’expérience sur le projet GASPAR pour le groupe PVCP (Pierre & Vacances – Center Parcs).

Dans ce projet le challenge était d’utiliser BODS comme middleware pour envoyer à SAP des écritures (pièces) comptables via la technologie IDOC.

Le contexte :

  • Un système Tiers dépose un fichier plat contenant la facturation client et les comptes d’imputations correspondants,
  • BODS charge ce fichier,
  • BODS traduit les imputations comptables du système tiers en code d’imputation comptable SAP,
  • BODS poste la pièce comptable dans SAP au format IDOC en mode message.

Les solutions :

  • Les utilisateurs métier maintiennent dans SAP des tables de correspondance entre compta système tiers et compta de SAP (hors périmètre de ce post),
  • BODS traduit via des lookup_ext les données d’imputation comptables (hors périmètre de ce post),
  • BODS envoi un IDOC par pièce comptable à SAP en utilisant l’IDOC ACC_DOCUMENT003.

La difficulté majeure résidait dans la génération des IDOC. Un fichier plat pouvant contenir jusqu’à 34000 documents comptables générant autant d’IDOC.

Un IDOC SAP ce présente sous un format de type xml. L’ACC_DOCUMENT003 simule la saisie d’une pièce comptable, il y a de nombreux champs à remplir pour satisfaire SAP, et de nombreux contrôles sont réalisés pour que la pièce comptable soit considérée comme juste.

Ce qui nous intéresse ici est la partie génération de l’IDOC.

Génération massive d’IDOC :

1. Structurer les données pour ce rapprocher du schéma cible :

Deux méthodes ont été utilisées sur le projet, création d’une table par segments d’IDOC, ou division de la table source en autant de query que de segments d’IDOC

Chaque IDOC est référencé par un Identifiant unique, un IDOC peut contenir plusieurs lignes, qui doivent être référencées de manière unique par IDOC.

La table/query d’en-tête ne doit comporter qu’une seule ligne par identifiant d’IDOC, les autres tables/query peuvent contenir plusieurs lignes.

A l’image d’un modèle en étoile les données sont réparties entre : la table d’en-tête (Fait) et les tables de lignes (Dimension).

ci-dessous des données en exemple :

2. Lier les Tables/Query à une en-tête pour générer tous les IDOC en une passe. 

(Dans l’exemple précédent : la query “QRY_MATCH_IDOC”)

La query en amont de l’IDOC (query_2) place les segments dans l’IDOC.

Chaque Tables sources doivent être insérées dans la cible comme schéma.

2.1 L’en-tête :

La clause FROM est déterminante pour structurer l’IDOC. La clause FROM de query_2 aura pour valeur la table d’en-tête.

Puis tous les segments d’en-tête auront comme valeur dans la clause FROM le “Row_Generation”. Cela permet de ne remplir l’en-tête qu’une seule fois. Dans l’exemple ci-dessus les segments EDI_DC40, E1BPACHE09 et E1BPACEXTC

(détail d’un segment)

2.2 Les lignes :

Les autres segments sont rempli par les tables correspondantes, avec en clause FROM la table, et en clause WHERE le lien vers l’identifiant de l’en-tête

En exemple le segment E1BPACGL09 :

2.3 Cas particulier d’une duplication de segment :

Dans certains cas un segment doit être répété. Lors de la première itération le segment est paramétré à l’identique des autres, et la deuxième itération la clause FROM prendra pour valeur un “ROW_GENERATION”.

 

3. Paramétrage de l’envoi d’IDOC

Afin d’optimiser l’envoi des IDOC en mode message la fenêtre suivant permet de modifier le nombre d’envoi simultané d’IDOC. Deux solutions, par paquet ou par division chronologique.

La solution d’envoyé les IDOC par paquet de 100 a été choisi compte tenu du paramétrage de SAP chez le client.

Conclusion

Cette méthode permet d’envoyer en masse en quelques minutes des milliers d’IDOC.

Certes BODS est détourné de son utilisation première (ETL) pour devenir un modeste intégrateur, néanmoins les performances sont très bonne.

Aujourd’hui la moyenne est : 1 min / 1000 IDOC de type ACC_DOCUMENT003.

Boostez votre rentabilité avec SAP HANA et COPA !

May 2nd, 2012 No comments

Séminaire co-organisé par Viseo (Homsys), HP et SAP le 12 juin à l’hôtel Concorde Lafayette Paris (9h à 12h).

SAP-HANA, « Appliance In-Memory », est une véritable révolution dans la façon de traiter les données, tant d’un point de vue de l’écriture, que du stockage ou de la lecture des informations des applications SAP.

  • Vous passez plus temps à analyser vos données qu’à prendre des décisions ?
  • Vous n’avez pas accès aux bonnes données aux bons moments ?
  • Votre applicatif ne permet pas d’adresser pleinement vos besoins métiers ? (manque de granularité, temps de réponse)…

SAP HANA EST FAIT POUR VOUS !

Au cours de ce séminaire, nous vous présenterons dans un premier temps les différentes opportunités de SAP HANA pour votre SI.
Nous ferons ensuite un focus sur le Rapid Deployment Solution (RDS) pour COPA, qui vous permettra de passer de l’analyse au pilotage de vos activités, et ce dans un temps record !
Notre présentation sera illustrée d’un retour d’expérience concret.

Informations et inscription sur notre site www.homsys.com

Le passage Projet Produit, étape clé dans le succès des projets BI

December 5th, 2011 No comments

Imaginez… Un matin, vous êtes sereinement en train de travailler sur un nouveau projet… Jusqu’à ce que l’on vous téléphone. C’est un ancien client affolé, qui vous appelle parce que l’application que vous avez livrée 9 mois auparavant est tombée en rade au cours de la nuit. Il vous faut alors vous dégager du temps en urgence, pour vous replonger en catastrophe dans un contexte que vous avez largement eu le temps d’oublier,… et en plus les conditions de votre intervention « pompier » n’ont pas été définies au préalable… Le cauchemar !
Si au moins une partie de ce scénario sonne comme un air de déjà-vu pour vous, cet article consacré à la gestion du passage en maintenance pourrait vous intéresser 😉

Le cas de figure évoqué en introduction est volontairement caricatural, mais c’est pour mettre en lumière la nécessité de bien gérer le passage projet produit dans les projets BI dès qu’ils atteignent une certaine taille.
Le décisionnel n’échappe pas à la règle propre à tout projet informatique ou industriel : quel que soit la technologie utilisée, il faut consacrer du temps à la transformation du projet en produit. Cette étape est indispensable au succès du projet et à son bon ressenti par le client.
Elle permet en outre de clarifier le rôle de chacun et donne l’opportunité à l’équipe projet de « passer le relais » proprement aux personnes qui auront le produit en charge.

Trois bonnes pratiques permettent de préparer « en douceur » le passage en maintenance tout au long du projet :

  1. Anticipation des problématiques maintenance
  2. Rédaction et validation du contrat de maintenance
  3. Période de transition projet-produit

1/ Anticipation des problématiques maintenance

Il est toujours bon d’aborder la problématique maintenance le plus tôt possible dans le cycle de vie du projet. Elle doit faire partie de la phase d’étude et idéalement elle est même évoqué en avant-vente.

Il s’agit de se poser à chaque étape significative du projet les questions indispensables sur le devenir du projet que l’on développe. Par exemple (liste non exhaustive) :

  • Sur quelle plate-forme sera déployée l’application ?
  • Existe-t-il une équipe de maintenance pour cette plate-forme?
  • Ou bien le projet en est-il le « pilote » ? (Auquel cas il va probablement “essuyer les plâtres” de sa mise en place et ce surcoût devra être anticipé)
  • Quel sera le “running cost” (coût d’exploitation) du produit une fois passé en exploitation ?
  • Ce coût a-t-il été budgété lors de l’évaluation du projet ?
  • Cette équipe de maintenance a-t-elle la bande passante pour gérer une application de plus ?
  • Cette équipe est-elle suffisamment formée aux technologies utilisées par le futur produit ?
  • Etc…

Le suivi de ces questions doit être effectué en continue à mesure que le projet progresse. A la manière d’une analyse de risque, il faut réévaluer régulièrement la situation de façon à s’assurer que les choix et les aléas du projet permettent de rester en phase avec les objectifs pour le passage en maintenance.

2/ Contrat de maintenance

Une autre bonne pratique pour envisager sereinement le passage en maintenance, est de se mettre d’accord sur un contrat de maintenance (parfois appelé « maintenance charter » ou « maintenance agreement ») avec l’équipe qui aura en charge l’exploitation du projet devenu produit.
Le meilleur moment pour commencer à rédiger ce contrat est souvent lorsque l’on passe en phase de recette de l’application. A ce stade le projet est suffisamment avancé pour se consacrer de façon efficace au contrat de maintenance, et il reste encore du temps à chaque partie pour préparer ensemble la mise en production.

Le contrat de maintenance est destiné à permettre :

  • A l’équipe de maintenance de valider la documentation livrée par l’équipe projet (avec des aller/retour possible, si elle ne lui parait pas suffisamment complète) :
    • Doc technique de l’application
    • Fiches d’exploitation
    • Procédures de maintenance
    • Doc de reprise en cas de panne (“what if”)
    • Etc…
  • De définir le périmètre de ce qui relève de la maintenance et de l’évolution. C’est à dire qui prendra en compte tel type de demande utilisateur (équipe de maintenance ? nouvelle version ? ou nouveau projet ?)
  • De nommer des key-users fonctionnels qui serviront de référents en cas de panne nécessitant un arbitrage « métier »
  • De définir des référents techniques (souvent issus de l’équipe projet) si l’équipe de maintenance ne parvient pas à se dépêtrer d’une panne, qui pourront intervenir au titre d’une prestation exceptionnelle

Le key-user fonctionnel et le référent technique sont des partenaires essentiels de l’équipe maintenance. En fonction du degré d’autonomie de la maintenance, on devra s’assurer qu’ils aient une disponibilité suffisante pour l’assister.

3/ Période de transition projet-produit

Il est aussi fortement recommandé de prévoir une période de transition durant laquelle l’équipe projet et l’équipe de maintenance travaillent ensemble à la fin du projet. Cela permet d’assurer un transfert de compétence efficace. La durée de cette période dépend à la fois de la complexité du projet et de l’expérience de l’équipe en charge du produit une fois livré.
Durant cette phase l’équipe projet laisse progressivement la main à l’équipe de maintenance et gère avec elle les évènements les plus épineux. C’est une façon de s’assurer que la transmission de connaissance a été réellement efficace.

On peut imaginer cette coopération sur un environnement de production ou un environnement de « pre-prod » (si par exemple la sécurité ne permet pas à l’équipe projet d’avoir les droits d’accès nécessaires). L’essentiel étant de le faire sur un environnement représentatif, dans un contexte aussi proche du réel que possible, et de ne pas laisser la maintenance seule « du jour au lendemain ».
C’est aussi souvent l’occasion de compléter la documentation avec des cas réels de maintenance gérés par les deux équipes.

Enfin, en BI, par manque de ressource, on confie souvent – à tord – la maintenance à l’administrateur de base de données (DBA), alors que les rôle sont quand même sensiblement différents. D’une part le DBA est sans doute surqualifié pour la plupart des tâches de maintenance (ou au moins pour le premier niveau d’intervention), et d’autre part il a souvent un niveau de disponibilité trop faible pour s’en occuper efficacement. Le choix et la composition de l’équipe de maintenance a donc toute son importance.

Ainsi donc se termine cet article qui a tenté de recenser les bonnes pratiques en matière de passage projet produit. N’hésitez pas à laisser des commentaires si vous avez vous aussi des leviers pour faciliter la transmission d’un projet à la maintenance.

Nouveautés Power Pivot-Vue diagramme

September 13th, 2011 No comments

Le décisionnel Microsoft s’oriente vers le BISM (Business Intelligence Semantic Model) en fusionnant le modèle de PowerPivot et celui, plus classique, d’ Analyses Services (UDM). C’est dans ce contexte que l’on trouve une des grandes nouveautés de powerPivot : la vue diagramme ! bien plus pratique pour réaliser nos modèles d’analyse.

Retour vers la synthèse des nouveautés de Powerpivot V2.

D’autres articles à venir sur les autres nouveautés…