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 faciliter la prise de décision. Il va donc de soit que les ressources 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 scenarios lors de la mise en place d’une équipe du data warehousing, dépendemment de la culture BI de votre organisation :

• Le scenario de l’utilisateur actif : L’utilisateur final peut créer ces propres solutions analytiques, ses propres rapports, il a accès à toute l’information dont il a besoin et beaucoup plus.
• Le scenario de l’utilisateur consommateur : L’équipe BI crée les applications analytiques, 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 scenario, 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 scenario, 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 gestionnaire 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

Développeur BI :

Si l’on est dans le premier scenario, ce rôle se restreint à la conception et la réalisation des premiers « templates » pour les applications analytiques, telles que définies par l’analyste d’affaire. On passera par contre beaucoup de temps à supporter les utilisateurs lors de la création de leurs applications analytiques et rapports…

Concernant le deuxième scenario, ce rôle s’occupe de concevoir et développer des solutions analytiques et des rapports 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 la communauté d’affaire n’arrive généralement pas à différencier entre ces différents livrables.

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. Elle doit aussi être au courant des tendances et des meilleures pratiques sur le marché concernant les systèmes d’exploitation, les stratégies de backup… et spécialement coté back-room.

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, il 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, les développeurs BI. L’idéal est que la même personne fasse les deux activités. Le modélisateur de données maitrise son modèle et en connaît les lacunes, ceci lui permettra de réaliser un modèle de métadata avec beaucoup d’aisance et de facilité.

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 le back-room ou le front room. L’idéal est une personne qui a déjà travaillé sur le projet dans le passé.

l’équipe ETL:

L’équipe ETL se compose des rôles suivants :

Gestionnaire ETL

• 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…)
• Superviser le développement, les tests et l’assurance qualité.

Architecte ETL

• Concevoir l’architecture et l’infrastructure de l’environnement ETL.
• Concevoir le mappage logique de données.
• Livrer les routines ETL en production.
• Appréhender les besoins d’affaires.
• Connaître les systèmes source.
• Résoudre les problèmes techniques complexes.

Développeur ETL

• Développer les routines ETL.
• Tester les routines ETL.
• S’assurer que les résultats du processus ETL répondent aux besoins d’affaires (Collaboration étroite avec l’architecte ETL)

Spécialiste qualité de données

• S’assurer de la qualité des données dans l’entrepôt de données en entier.
• S’assurer que les règles d’affaires sont bien implantées par les processus ETL (en collaboration avec l’analyste système et l’architecte ETL)

DBA

• Installer, configurer, migrer et maintenir la base de données.
• Traduire le modèle logique de données en modèle physique.