Le cadrage est la phase ultime de traduction des besoins métiers en contraintes techniques sur un périmètre fonctionnel cohérent.

La phase de cadrage est un facteur clé de réussite du projet décisionnel. La vraie signification de cette phrase est moins poétique : un projet lancé sans phase de cadrage (ou mal cadré) aura toutes les difficultés à respecter le triptyque coût/délai/qualité.

La principale valeur ajoutée du consultant réside dans sa capacité à comprendre et challenger les besoins des utilisateurs clés (sans être là pour leur apprendre leur métier) tout en ayant un background technique lui permettant de transmettre les bonnes informations à la maîtrise d’œuvre.

Le principal outil (utilisé dans tous les types de missions, d’ailleurs) est l’analyse de la valeur qui permet pédagogiquement de prioriser les besoins et donc de définir les lots du projet :

l'analyse de la valeur

Pour illustrer la possibilité de créer ses propres outils, l’analyse de la valeur s’est vue ajouter une troisième dimension dans le cadre d’une mission en particulier :

l'analyse de la valeur "en trois dimensions"

Le cadrage lance ensuite « concrètement » le projet avec les phases de spécifications qui permettront d’affiner et de sceller les décisions prises.

Ces trois posts avaient pour but de dresser un (très rapide) portrait des offres en amont des projets décisionnels capitalisées chez Homsys Consulting. Ces trois types de mission présentent l’avantage de n’être ni purement technologique, ni purement fonctionnelle… Un bon résumé de ma vision du décisionnel en somme !

Si vous avez des remarques ou souhaitez voir approfondi un des sujets, n’hésitez pas.

Je vais donc aborder ces différents points avec vous.

1-    Qu’est-ce que les données de référence dans l’entreprise ?

Les données de référence sont les données pivot dans l’entreprise. Elles sont :

• Partagées par les métiers et le S.I.
• Généralement stables dans le temps.
• Pas ou peu modifiées par les systèmes transactionnels et décisionnels.

Quelques exemples …

Exemples de données référentielles

En complément à ces données de référence transverses, on peut aussi avoir des données de référence sectorielles (Pharma, Transport, Assurances, ..).

2-    Qu’est-ce que le MDM ?

Le Master Data Management (Gestion de Données de Référence) est une discipline visant à mettre en place les processus, les organisations et les outils pour rassembler, gérer et partager, de manière transverse, les données de référence. La réussite d’une telle initiative passe par une approche qui fait intervenir deux aspects : le métier et la technologie.

3-       En quoi le MDM est-il une solution ?

Très souvent, l’entreprise a conçu son Système d’Information de manière cloisonnée, en silos, s’alignant ainsi parfaitement au business. Cette urbanisation du S.I. s’est vue, au fil du temps, au fur et à mesure de la croissance de l’entreprise, confrontée à des problèmes de qualité et de fraîcheur de données, de redondance de référentiels métier, de collision sémantique, de désynchronisation de silos et de consolidation cross-silos difficile voire impossible. Le processus de prise de décision faisant les frais de ces « douleurs » amenant ainsi les métiers vers une défiance dans la qualité des données délivrées par le S.I.

Face à tout cela, la  valeur ajoutée du MDM est dans l’intégration des différents référentiels de données entre eux pour satisfaire à des challenges divers :

• Conformité réglementaire (Bâle 2, …)
• Time To Market
• Agilité du S.I.
• Certification des résultats
• Efficacité opérationnelle
• Confidentialité et sécurité
• Consolidation
• …

4-       Quels sont les objectifs du MDM ?

Trois types d’objectifs ressortent :

• Organisationnels :
  • Aligner l’organisation sur le nouveau modèle de gouvernance
  • Permettre aux métiers de se réapproprier leurs référentiels
• Fonctionnels :
  • Uniformiser les concepts métiers
  • Rationaliser les processus d’administration
• Techniques :
  • Améliorer la qualité des données de référence
  • Synchroniser les applicatifs autour d’un seul point de vérité
  • Assurer la traçabilité
  • Sécuriser l’accès aux données de référence

5-       Les fonctions du MDM

Fonctionnalités du MDM

6-       Les architectures du MDM

Architectures du MDM

Dans l’architecture de coopération, les S.I. amont et le MDM s’échangent un certain nombre de données référentiels. Les S.I. aval sont eux dépendants du MDM pour ce qui est des données de référence.

Dans l’architecture de réconciliation (ou de consolidation), le MDM joue le rôle d’arbitre et de réconciliation lors de conflits ou de rejets dans le processus d’amélioration de la qualité des données.

7-       Les acteurs du marché

Big 4 : Microsoft, SAP, Oracle, IBM

Spécialistes BI/EIM : SAS, Information Builder, Dataflux

Pure Player : Orchestra, Kalido

Leader Middleware : Informatica, TALEND, TIBCO, ..

Perturbateurs : Cegedim, Exalead

8-       L’offre Microsoft en MDM

Microsoft propose avec la suite BI SQL Server 2008 R2 un module prenant en charge la gestion de référentiels de données. Ce module est Master Data Services.  La démo n’a pas été déroulée au cours de la session à cause d’un problème de projection. Des copies d’écrans ont été présentées à la place et commentées.

Cette cession avait pour objectifs de montrer par l’exemple, les apports de SharePoint 2010 dans l’intégration des données métiers. Les points abordés ont été les suivants :

• Business Connectivity Service
• Mode Offline
• Reporting
• Workflow

1-    Business Connectivity Service (BCS)

Remplaçant des BDC dans Moss 2007, ce nouveau service est doté d’une interface facile à manier. En quelques clic vous voilà connecté à une base de données, vous permettant ainsi d’avoir un accès en lecture et écriture (et oui ça marche dans les deux sens) aux données des produits, contacts, … dans une liste SharePoint. De là, vous avez la possibilité d’éditer en mode formulaire un enregistrement, apporter une modification à un libellé par exemple et hop… celle-ci est automatiquement visible dans le système source. A contrario, vous modifiez dans votre système source une donnée, elle est visible quasi-instantanément dans la liste SharePoint.  Avec MOSS 2007, il fallait passer par l’écriture d’un fichier XML pour se connecter à source applicative externe…

2-    Mode Offline

En s’appuyant sur l’exemple précédent, il s’agit ici d’utiliser le WorkSpace dans SharePoint 2010 qui permet, où que l’on soit, de travailler en mode déconnecté. Ainsi, vous accédez à un Site SharePoint off-line dans lequel vous retrouvez votre liste dont le contenu est accessible en lecture et en écriture. Dès que le Workspace détecte une connexion réseau, le Site SharePoint et la base de données source, à partir de laquelle le BCS a été défini précédemment, sont automatiquement synchronisés. 

3-    Reporting

La démo ici consistait à utiliser Excel Services en publiant un fichier Excel contenant un tableau dans une bibliothèque de documents sur un site SharePoint 2010. Rien de neuf par rapport à MOSS 2007 jusque là ! Sauf qu’à partir de cette bibliothèque, il est possible d’ouvrir le fichier Excel en mode édition et de modifier son contenu : ajouter des formules, des graphes, … mais aussi, grâce à l’API REST, nouveauté de SP2010, de prendre ce dont on a besoin (plage de cellules, graphe, …) dans le classeur est mettre tout cela en affichage sur une page d’accueil, pour illustrer les principaux indicateurs d’une BU par exemple.

SP 2010 intègre aussi une ChartPart qui offre un certain nombre de graphes qu’il est possible d’utiliser pour illustrer le contenu d’une liste SharePoint. Pour compléter notre exemple, il est question ici d’utiliser cette ChartPart avec la liste précédemment créée pour illustrer sous forme graphique son contenu.

4-    Workflow

Avec Moss2007, les workflow étaient modélisables notamment depuis SharePoint Designer. SP2010 permet aussi de mettre en place un workflow avec Visio. Il suffit dans Visio 2010 d’utiliser le template « Microsoft SharePoint Workflow ». Toute la partie modélisation peut ainsi être faite facilement depuis Visio, en utilisant les objets appropriés (procédé, décision, condition,…) en drag and drop, d’importer ensuite le workflow dans SharePoint Designer pour le finaliser avec les actions et les connexions adéquates.

Homsys

Un programme de 3 conférences plénières et plus de 300 conférences techniques et workshops attend les quelque 16 000 visiteurs attendus.

La journée du mardi 9 sera plus particulièrement consacrée à la Business Intelligence. Durant la session du début d’après-midi ’PowerPivot révélé‘ (14h30-15h30), Alexis Sacksteder, directeur technique Homsys IDF, abordera en détail la conception des tableaux de bord grâce à l’add-in PowerPivot pour Excel, le nouvel outil Business Intelligence en mémoire de Microsoft. Créer un modèle à partir de sources de données hétérogènes, ajouter simplement des calculs métiers complexes avec le nouveau langage DAX et pourquoi pas utiliser le datamining avec PowerPivot… Cette session sera l’occasion également de partager avec l’assistance les bonnes pratiques d’utilisation de PowerPivot.
En savoir plus.

Informations et inscriptions aux Microsoft TechDays 2010 sur le site officiel de l’événement : www.mstechdays.fr.

Homsys fera gagner une XBOX 360 Elite Value ! Rendez-vous « au village SQL Server » dans la zone « Développement et base de données » : stand D29.

 Homsys et Prelytis organisent en partenariat, aujourd’hui à Lyon, des ateliers Business Intelligence personnalisés : « Découvrez comment construire votre premier tableau de bord sur vos données en deux heures seulement ! »

Objectifs de ces ateliers animés par un expert Prelytis : réaliser un prototype d’application décisionnelle web 2.0 prête à l’emploi avec la solution LiveDashBoard, à partir des données apportées par l’utilisateur… Et découvrir comment transformer en temps réel les données en tableaux de bord clairs, interactifs et collaboratifs.

Plusieurs solutions permettent de répondre à ce besoin de suivi :

1. La méthode manuelle : Management Studio propose un historique d’exécution des jobs
2. L’utilisation de tâches SQL permettant de renseigner une table de log
3. L’utilisation des logs standards SSIS

La solution 2. est très souvent rencontrée sur les projets par simple méconnaissance de la 3.

Cet article décrit donc comment mettre en place en quelques minutes un suivi des traitements SSIS performant.

L’activation des logs s’effectue pour chaque package dans le menu SSIS\Enregistrement (Logging en version anglaise)

Les étapes à réaliser sont les suivantes :

1. Choisir dans la liste déroulante type de fournisseur, où seront stockés les logs (base de données, fichier XML,…) puis cliquer sur le bouton Ajouter. Personnellement, je préconise le stockage SQL Server qui permet une exploitation aisée de ces données
2. Cocher la case à cocher devant le nom du package
3. Activer la case à cocher devant le fournisseur SQL Server
4. Sélectionner la base de données hébergeant la table de log

Remarque : Il n’est pas possible de choisir le nom de la table dans laquelle les logs seront stockés. SSIS 2005 les stocke dans la table sysdtslog90, SSIS 2008 dans sysssislog.

L’onglet Détails permet ensuite de spécifier le niveau de finesse dans le suivi des traitements :

Afin d’éviter des logs trop volumineux, je recommande de tracer uniquement les événements suivants :

• OnPreExecute : Trace le début d’exécution des différentes tâches présentes dans le niveau Flux de Contrôle
• OnPostExecute : Trace la fin d’exécution des différentes tâches présentes dans le niveau Flux de Contrôle
• OnError : Trace toutes les erreurs survenues aux niveaux Flux de contrôle et Flux de données

Les principaux champs de la table de logs sont les suivants :

• Event : événement qui a généré le log (OnPreExecute, OnPostExecute ou OnError)
• Computer : ordinateur qui l’a exécuté
• Operator : utilisateur qui l’a exécuté (permet par exemple de différencier une exécution automatique effectuée par l’agent SQL Server d’une exécution manuelle de rattrapage)
• Source : étape du flux qui a généré le log
• SourceId : Identifiant de l’élément (package, tâche de contrôle…) ayant généré le log
• executionId : identifiant unique de l’exécution
• Starttime : début de l’événement qui a généré le log
• Endtime : fin de l’événement qui a généré le log
• Message : détails de l’événement (notamment les messages d’erreurs sur l’événement OnError)

En quelques clics nous avons ainsi paramétré le stockage de l’information relative à l’exécution des flux SSIS. Ces données peuvent maintenant être requêtées en SQL ou utilisées via du reporting.

A noter qu’une ligne est écrite dans la table de log pour chaque événement: début d’une tâche, fin d’une tâche ou erreur. Les données doivent donc être manipulées pour obtenir une ligne du type: nom de la tâche, date de début, date de fin et statut d’exécution.

Homsys propose ainsi un ensemble de tableaux de suivi développés sous Reporting Services. Cet aspect sera présenté dans un prochain article…

Pourquoi utiliser des modèles de package :

Un modèle de package pourra par exemple contenir les éléments suivants :

• Cartouche d’en tête documentant le flux (description du flux, date de création, auteur…)
• Activation des logs d’audit des traitements
• Connexion vers les bases de données du projet
• Variables communes (nom du serveur DWH, chemin de stockage des fichiers sources, chemin de l’archivage…)
• Utilisation du fichier de configuration qui permet l’alimentation dynamique des variables communes
• Propriété delayValidation valant True afin d’éviter les ralentissements à l’ouverture des packages

La mise en place de ces éléments permet ainsi un gain de temps intéressant, une homogénéisation des différents développements (les variables communes auront le même nom dans l’ensemble des packages) ainsi qu’un risque d’anomalie réduit (erreur de paramétrage des connexions, du fichier de configuration…).

Comment développer un package modèle ?

Un package modèle est un package SSIS standard dans lequel les éléments communs auront été implémentés. Ce package doit ensuite être copié dans le répertoire :

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems

Comment utiliser un package modèle :

L’utilisation du modèle de package s’effectue via les étapes suivantes :

Cliquer droit sur le projet puis Ajouter\Nouvel Element :

Utiliser un modèle de package Etape 1

Ajouter l’élément Package_model_SSIS :

Utiliser un modèle de package Etape 2

S’il fallait le résumer en trois points :

• Ces missions durent de quelques semaines à quelques mois et s’appuient sur l’analyse de l’existant, l’analyse des besoins et notre expertise du décisionnel pour livrer nos recommandations.
• Ces études commencent par une phase d’interviews de la DSI et des directions métiers (pour donner un ordre d’idée, il nous est arrivé, sur un projet, de mener jusqu’à 40 interviews pour couvrir la quinzaine de directions métier concernées). C’est après cette phase de collecte d’informations que notre expertise entre en jeu puisqu’il faut rapidement trouver :
  • les grands axes d’amélioration qui permettent de préciser une cible
  • les bons critères de priorisation pour dresser la trajectoire
  • nos retours d’expérience pour donner une macro estimation de l’investissement nécessaire.
• Que le client les aborde ou pas, les trois dimensions d’analyse interviennent dans la réflexion. Les directions métiers ne sont parfois impliquées qu’après une première analyse technologique. Les problématiques ayant leurs tenants dans l’organisation autour des projets sont souvent identifiées en deuxième partie de réflexion.

« Un schéma vaut mieux qu’un long discours » aurait pu dire l’homme de Cro-Magnon. Dans mon immense mansuétude, je vais en utiliser plusieurs.

Un des principaux justificatifs de l’architecture cible que nous allons proposer réside dans la capacité de croisements demandée par les différentes directions. Toujours dans une démarche de communication facilitée avec les interlocuteurs de la mission, le schéma suivant permet d’illustrer la valeur ajoutée que va présenter le datawarehouse, en présentant les croisements majeurs qui seront proposés.

Valeur ajoutée d'un datawarehouse

La trajectoire pour aller de l’existant à cette cible s’appuie sur une synthèse des besoins exprimés, leur estimation et leur priorisation. Ça peut donner ce genre de planning (dans le cas présent, un extrait de planning sur 5 ans avec un code couleur pour l’estimation des projets) :

Exemple de macro planning

Encore une fois, en guise de conclusion, je vais m’appuyer sur le retour d’expérience du consultant sur ces missions :

• Ce qui est dur dans ces missions :
  • Je vois plusieurs  éléments de complexité dans ces missions. Tout d’abord, de par la construction de ces missions, on commence par voir le client très fréquemment lors de la phase de collecte d’informations. On le met fortement à contribution puisqu’il passe du temps avec nous pour nous expliquer son contexte. Vient ensuite une étape au cours de laquelle le client ne voit plus les choses avancer : les idées se forment dans la tête du (ou des) consultant(s) mais n’étant pas formalisées, le client exprime assez souvent son inquiétude sur la capacité à tenir les délais… et pourtant, c’est la phase au cours de laquelle on avance le plus.
  • Autre point délicat, le contenu d’une telle mission n’est que rarement clair (et partagé) pour tous les interlocuteurs. A l’heure actuelle, s’appuyer sur le plan type de livrable de ces missions reste la solution la plus efficace pour donner en donner une idée :

Plan type d'un livrable final

• Mon principal intérêt dans ces missions :
  • On rencontre énormément de gens.
  • On a une vision de l’avenir et pas seulement une vision de « ce qui marche pas ».
  • On a la sensation d’être là pour amener des réponses aux attentes de tous les interlocuteurs.
  • On peut s’appuyer sur une méthodologie et des outils déjà existants mais on doit toujours réinventer l’outil adapté à ce client et à cette mission en particulier.

Après avoir rapidement identifié les axes d’amélioration d’une situation existante (phase d’audit), nous venons de réfléchir à la stratégie que l’on veut donner à notre SID  (la présente phase d’urbanisation du SID). Nous allons bientôt pouvoir entamer la réalisation des premiers projets (savoir lesquels lancer à court terme étant défini par la trajectoire). Mais avant de se plonger fébrilement dans la définition des flux, des rapports, des cubes …  nous allons cadrer le projet ; nous terminerons notre plongée dans l’univers merveilleux du conseil en amont des projets décisionnels avec cette dernière étape (avant le projet à proprement parler) : la phase de cadrage. Nous verrons en particulier que c’est – de notre point de vue – le facteur clé de succès du projet décisionnel.