Composition de l’équipe projet Business Intelligence (décisionnel)

0
658
La vocation et la raison d’être d’un projet de data warehousing et de Business Intelligence est de transformer les données en information et ensuite en connaissance afin de faciliter la prise de décision. Il va donc de soit que les ressources humaines requises à la mise en place d’un tel projet soient multidisciplinaires et émanent tant de la business que des TI. Il est aussi commun qu’une seule ressource occupe plusieurs rôles au sein de l’équipe.

Il faut bien noter qu’il est difficile de cerner chacun des rôles dans le détail. La ligne de séparation est très mince et le chevauchement dans les rôles est coutume dans les projets de data warehousing. Par ailleurs, il existe deux scénarios lors de la mise en place d’une équipe du data warehousing, dépendemment de la culture BI de votre organisation :

  • Le scénario de l’utilisateur actif : L’utilisateur final peut créer ses propres analyses et dans certains cas ses cubes, ses propres rapports et tableaux de bord. Il a accès à toute l’information dont il a besoin et beaucoup plus.
  • Le scénario de l’utilisateur consommateur : L’équipe BI crée les cubes, les analyses complexes, les tableaux de bord complexes, les rapports et donne accès aux utilisateurs pour pouvoir effectuer des requêtes Ad-Hoc Seulement.

Et selon le contexte et la maturité BI de votre entreprise, les rôles et les responsabilités peuvent changer considérablement.

Le sponsor

Le sponsor du data warehouse est le client ultime du data warehouse et son farouche avocat. C’est la personne qui fait la promotion de la solution BI dans l’organisation, et si celle-ci est large, on peut imaginer un groupe de personnes effectuer ce rôle, on parlera alors d’une sorte de comité de coordination de la solution au complet. Il doit être au courant de tout même des lacunes de la solution, ceci vous évitera de le perdre !

Les utilisateurs

Il s’agit des utilisateurs finaux de la solution BI. Ils doivent être impliqués le plus souvent tout au long du projet et surtout lors de la définition des besoins d’affaires. C’est eux qui vont utiliser la solution et sans leur approbation du contenu, la solution n’est en soit qu’un exercice technique voué à l’échec. Selon le premier scénario, l’utilisateur crée ses applications analytiques, ses rapports… Il doit être bien formé et disposer d’une expertise assez avancée dans le domaine.
Par contre dans le cas du deuxième scénario, l’utilisateur ne fait que consommer ce qui a été produit par l’équipe BI et c’est au développeur BI de concevoir et réaliser les applications et les rapports.

Le Chef – Directeur de projet

Ce rôle est critique. La personne doit être respectée par les membres de l’exécutif de la compagnie et elle doit aussi être crédible. Ses qualités de communication et de gestion de projet sont primordiales.
C’est cette personne qui gère le projet, elle effectue toutes les tâches de planification, contrôle, organisation et de dotation en personnel. Elle effectue aussi le suivi du projet, négocie les échéanciers, le contenu et la qualité des livrables.

Analyste d’affaires

Ce rôle permet de déterminer les besoins d’affaires et de les traduire en besoin en architecture (Portail), en données (Ad-hoc) et en analyse (Olap). En ayant une bonne connaissance des données et des affaires, il sera en mesure de traduire les besoins d’affaires en terminologie BI (Dimension, fait…) Sans pour autant être un modélisateur de données. Il devrait cependant être dans la mesure de distinguer ce que l’on doit mesurer, comment et dans quel contexte le mesurer. Il doit distinguer les différentes modules de restitution à savoir les rapports (Statiques ou dynamiques), les analyses, les tableaux de bord…

Développeur BI

Si l’on est dans le premier scénario, ce rôle se restreint à la conception et la réalisation des premiers « templates » pour la restitution, telles que définies par l’analyste d’affaire. Il passera par contre beaucoup de temps à supporter les utilisateurs lors de la création de leurs rapports, Cubes, Tableaux de bord et analyses.
Concernant le deuxième scénario, ce rôle s’occupe de concevoir et développer les tableau de bord, rapports, cubes et analyses avancées, le tout clé en main. L’utilisateur final peut utiliser la solution et si le besoin de changer de quoi se fait sentir, une demande est faite à l’équipe BI pour réaliser le développement.

Formateur

Le formateur doit être très intime avec les données, les applications et les outils de restitution, du fait que les utilisateurs finaux n’arrive généralement pas à différencier entre ces différents livrables. Ceci dépend bien-sur de la maturité analytique de ces derniers.

Architecte technique

C’est le responsable de l’architecture technique et de la sécurité de tout l’environnement. il s’occupe de l’installation du matériel et du logiciel. il doit aussi être au courant des tendances et des meilleures pratiques du marché concernant les systèmes d’exploitation, les stratégies de backup… et spécialement coté back-room (ETL et Datawarehouse).

Modélisateur de données et de métadata

En général les modélisateurs de données dans un entrepôt de données arrivent d’un environnement transactionnel ou l’on normalise tout ! Cependant afin de réussir son modèle de données destiné à une utilisation différente des OLTP, le modélisateur de données BI doit maîtriser les concepts de la modélisation dimensionnelle.
Selon votre approche et la suite BI que vous avez choisie, le modélisateur de données doit aussi effectuer de la modélisation du métadata, le référentiel auquel accèdent les utilisateurs finaux et les développeurs BI. Vu que le modélisateur de données maîtrise son modèle et en connaît les lacunes, il est préférable que ce dernier participe aux premiers développements des différentes composantes de la restitution (Tableaux de bord, Rapports, Cubes, Analyses…). Ceci lui permettra de tester son modèle et de le mettre à l’épreuve.

Support du Data warehouse

Il s’agit d’un autre rôle clé dans l’équipe du projet. Cette personne s’occupe du support de tout l’environnement que ce soit la partie Datawarehouse/ETL ou encore la partie Restitution. L’idéal serait une personne qui a déjà travaillé sur le projet dans le passé.

Gestionnaire ETL

Le rôle du gestionnaire ETL est de gérer quotidiennement l’équipe ETL, définir les standards et procédures de l’environnement de développement ETL (Règles de nomenclature, Meilleures pratiques…) et de superviser le développement, les tests et l’assurance qualité.

Architecte ETL

L’architecte ETL doit concevoir l’architecture et l’infrastructure de l’environnement ETL, le mapping logique de données. Pour ce faire il soit bien appréhender les besoins émis par le modélisateur de données, et il doit aussi avoir une bonne connaissance des systèmes sources. C’est lui qui prend en charge la livraison des routines ETL en prod et de résoudre les problèmes techniques complexes.

Développeur ETL

C’est au développeur ETL de développer et tester les routines ETL, de s’assurer que les résultats du processus ETL répondent aux besoins d’affaires (Collaboration étroite avec l’architecte ETL). Une bonne maitrise de SQL, des outils ETL et des techniques telles que la technique de gestion des dimensions à évolution lente (SCD), le parallélisme des traitements, les différentes techniques de chargements de données (incrémental, Truncate and reload again…). Il doit aussi veiller à l’utilisation des fonctionnalités de l’ETL et éviter de tout faire par SQL.

Spécialiste qualité de données

Ce qualiticien doit s’assurer de la qualité des données dans l’entrepôt de données en entier et que les règles d’affaires (transformations) sont bien implantées par les processus ETL (en collaboration avec l’analyste d’affaires et l’architecte ETL)

Administrateur de Bases de Données (DBA)

Vu qu’il est question de base de données (Entrepôt de données), l’équipe projet doit absolument intégrer un bon DBA. Malgré que le rôle d’un DBA soit évident il est important de mentionner qu’un DBA de bases de données OLTP devrait absolument adhérer aux concepts de la modélisation dimensionnelle et en particulier la dé-normalisation ou encore ce que j’appelle la déformation de la troisième forme normale.