Un Dashboard à la sauce BI, pourquoi pas ?

« Carole, les données Xiti doivent remonter dans {XYZ}. Il faut aussi y mettre les données des campagnes mailing et les données de {ABC} ».

Comprenez par {XYZ} l’acronyme de l’outil de Business Intelligence utilisé dans l’entreprise et par {ABC} le cœur de nos conversions ultimes, savoureuses résultantes des actions menées via nos sites, nos campagnes, notre notoriété et tutti quanti.

Cette demande formulée par le HiPPO en personne m’a été relayée par mon manager direct il y a plusieurs mois .
Une demande positive qui permet de projeter des actions à moyen terme pour mettre en œuvre un pilotage par la donnée.

Mode projet activé

Les choses étant ce qu’elles sont, j’endosse mon costume de chef de projet.
Passage par l’étape 1 de l’identification plus précise des besoins.
J’ai la chance de pouvoir rencontrer le HiPPo en personne. Là encore, une bonne chose.

• « Les données Xiti ? »
• Desquelles parlez-vous ? »
• « Toutes ? »
• « On bascule tout dans {XYZ} ? »

Ah…

Quand on est entouré par le HiPPo et son manager direct dans ce type d’entrevue, la marge de manœuvre peut être étroite : je ne pars alors pas dans une longue allocution à propos d’une non pertinence à remonter trop d’éléments… qui ne parleront pas à tous, qui ne seront pas raccrochés à des objectifs Business… Et pas la moindre lueur de KPIs à proposer à ce moment là.

Et je suis de toutes façons confiante : j’ai tout de même des personnes un tant soit peu à l’écoute, il va être possible de « faire les choses bien ».

Donc on avance !
Modélisation des besoins dans le document qui va bien, avec de beaux schémas des différents flux de données issues de l’outil Web Analytics, certes, mais aussi de différents CRMs internalisés ou externalisés …

Puis étape d’évaluation des ressources nécessaires : humains et nature de compétences couplées avec l’indéfectible facteur budget entre autre.

Je jalonne ensuite les différentes phases nécessaires.

Bref, une gestion de projet comme une autre avec un chef d’orchestre qui coordonne un ensemble d’actions et d’individus.

L’impact de l’organisation

J’ai dit individuS ?
En l’occurrence le projet a concerné 2 personnes, un membre de la DSI et moi-même.

Dans mon terrain de jeu existe un fait, juste un : la business intelligence est un projet du service IT. Toute implémentation s’inscrit dans un système d’informations plus large. Les projets sont étroitement imprégnés d’une « vision IT ».

Il faut donc réussir à communiquer et monter un tableau de bord avec en ligne de mire deux visions différentes : traitement de flux d’information normés versus tableau de bord e-marketing par exemple.

Il faut aussi que le passage d’informations soit fluide entre les personnes.
Dans mon cas de figure je ne suis pas informée des mises à jour de l’outil de Business Intelligence, et j’ai pu voir de nouveaux types de graphiques arriver que je n’aurai pas forcément utilisés pour restituer telle ou telle donnée.

Éléments à prendre en compte

Dans ce type de projets, plusieurs points entrent en ligne de compte, ceux qui me viennent à l’esprit :

• L’organisation de l’entreprise mentionnée plus haut
• Les compétences
• La ressource (les fameux jour/homme )
• La communication
• La data au sein du système d’informations de l’entreprise :
  • Sa confidentialité
  • Sa provenance
  • Sa structuration

Pour mener à bien le tout, il faut savamment équilibrer les forces et faiblesses de l’ensemble de ces points, peser le pour et le contre de telle ou telle option.
On peut être confronté aussi à une impossibilité structurelle.

Exemple !

Mon outil de web analytics offre de superbes possibilités d’exploitation des données via une API.
Mais je n’ai pas les compétences nécessaires pour l’exploiter, mon correspondant sur le front IT non plus. Le budget pour externaliser une prestation se réduit à peau de chagrin.

Quand on ne peut pas passer par la grande porte… On doit donc emprunter l’issue de secours 😉
Et faire accepter qu’on va avancer étape par étape, sans « tout » remonter en une seule fois.

Il s’agit aussi de faire rentrer à la truelle et matcher des données qui vivent sur un cycle « année civile » avec des identifiants « saisonniers »  internes à l’entreprise, profondément liés à son cœur d’activité.

Ma sortie de secours à consisté à accueillir à ce moment là :

• des fichiers CSV par centaines, digérés et retraités par mes doigts magiques,
• le XML Power, poussé via FTP, extrait et mouliné via script interne autorisé.

Et miracle … un premier pas est franchi.

Il est beau mon tableau de bord !

Enfin arrive cet instant magique où un premier résultat est là :

• des courbes de pages vues et visites clairement corrélées à une période qui n’est pas un « simple date à date », secteur événementiel oblige  (Ai-je dit qu’elles ne sont pas si évidentes à obtenir via mon outil WA préféré ?)
• des histogrammes de conversions.

Et quelque part je suis déçue.
Déçue par ce sentiment d’être à des années lumiere du tableau de pilotage business que j’imaginais.

Mais côté utilisateurs, il y a des satisfaits, oh oh, cela donne à certains une information qu’ils n’auraient jamais été cherché directement dans l’outil d’Analytics.

Donc finalement, la déception, on la mets de côté, on garde le cap et on avance !
Les jalons suivants sont identifiés, petit à petit la restitution des données évoluera. Il y aura une V2, une V3 …

Que faut-il privilégier finalement ?
Faut-il mettre en place un rendu « pauvre » en terme de pertinence et d’actionnabilité ?

Probablement :

• Oui : mieux vaut un petit quelque chose qui évoluera dans le temps que rien du tout.
• Non : cela impacte négativement la valeur de la data.

Je n’ai pas toutes les réponses.

Un autre éclairage ? Je vous suggère la lecture d’un excellent -et récent- billet  qui traite des possibilités de reporting des outils de Web Analytics et introduit la notion de frontière à trouver avec la Business Intelligence : Le reporting : point faible des outils de Web Analytics.