Blog

Ton meilleur copain dans ta transfo data : l’analyste fonctionnel

Bon, on ne va pas se mentir : « De la data, de la data, vite de la data !!! Il faut faire de la data ! » c’est ce qu’on entend partout !

Ton meilleur copain dans ta transfo data : l’analyste fonctionnel

Crédit photo : Freepik

– « T’as fini ton reporting ? »
– « ben non, ça me prend au moins 3 jours le temps de tout récupérer. »
– « Mais, demande à la data, ils vont te faire un truc »

Eh oui, tout le monde a bien compris que la data était un levier de croissance énorme. On parle souvent de chiffre d’affaires additionnel, mais la data peut également permettre d’optimiser le récurrent de certains collaborateurs, ou même, de faciliter certaines organisations. Enfin, bref, on le dit depuis le début, et là, le message est passé, il y a une multitude de taches pour lesquelles la data peut aider.
(et je ne parle pas du décisionnel des entreprises, qui, ayant quelque peu été détourné de son usage initial, se retrouve rigide, lent, et incertain car on ne sait plus trop ce qu’il y a dedans et ce que les choses veulent dire… oui, j’avoue, je ne suis pas fan de BO).

Alors maintenant, on parle de data client (ça, si vraiment vous êtes embêté et que vous n’avez pas pensé à nous : « Know Your People »… et ben… bouhhhhh !!! 👻), data supply, data produit, data offre, data RH…
La bonne nouvelle, c’est qu’en général, les métiers ont les idées assez claires et savent sur quoi la data peut aider ! Les sujets sont relativement bien identifiés, et les plus-values bien définies. 

Et après ? Et bien après… on parle d’expert métier, qui sait ce qu’il veut, mais qui :
– Ne sait pas si c’est réalisable
– Ne sait pas comment s’y prendre
– Ne sait pas les méandres qui se cachent derrière les données qu’il exploite habituellement
– Ne sait pas s’il pourrait aller plus loin avec les données dispos dans l’entreprise
(Alors oui, y’a une liste non exhaustive de ce qu’il ne sait pas, mais je serais bien incapable de lister tout ce qu’il sait, et vous n’avez pas le temps pour ça 😉)

Et là, tout mon article prend son sens, puisque je vais vous parler du rôle de l’analyste fonctionnel ! Le functional analyst ! Celui qui est à vos projets data ce que Alfred est à Batman, ce que le docteur Watson est à Sherlock, ce que Sam Gamegie est à Frodon Sacquet… normalement, là, vous avez au moins une réf !

 

Comprendre le besoin métier…

Le premier rôle de l’analyste fonctionnel va être de discuter avec le métier. C’est assez logique quand on y pense, mais c’est à remettre comme LA priorité. L’analyste fonctionnel doit comprendre le besoin, anticiper les contraintes et avoir une vision claire de l’attendu.

Qu’est-ce qui se fait aujourd’hui ? Pourquoi le métier a identifié un besoin data ?
Pour le moment, ce sont principalement les métiers du contrôle de gestion qui font appel à la Data pour optimiser leur quotidien. On ne peut pas dire qu’ils ne maîtrisent pas leurs données. Ils en maîtrisent surtout les contraintes d’ailleurs.

« Dans l’idéal, il me faudrait un parc complètement comparable, avec une notion de disponibilité des produits pour chaque mag, mais comme je ne l’ai pas, je travaille en base 100 »

Alors… c’est quoi ta base 100 ?
C’est quoi ta notion de parc comparable ? Un mag ouvert en N-1 ? Un mag ouvert en N-1 avec au moins 6 mois d’activité ?
Qu’est-ce qui défini la disponibilité des produits ? Le produit a été envoyé au mag ? Il est en surface de vente ? Il y en a au moins 3 ?
Oui, l’exemple est peut-être bête, mais c’est ce genre de contraintes que l’analyste fonctionnel doit capter, mettre en avant et traduire.
C’est également lors de ces « discussions » que l’analyste fonctionnel va comprendre d’où vient le problème : disponibilité des données, outils inadaptés, …

… Et l’expliquer aux équipes Techniques !

Maintenant que l’analyste fonctionnel sait de quoi il parle, il va devoir l’expliquer aux équipes techniques (IT, DSI, … et plein de trucs en « i », ceux avec qui on communique avec des 1 ou des 0 😉).

On rentre alors dans la phase « travail de fourmis » : documenter l’existant, rédiger le besoin, chercher les sources de données manquantes, les outils les plus adaptés. Dans cette phase, l’analyste fonctionnel travaillera en étroite collaboration avec l’équipe technique pour trouver la ou les solutions les plus adaptées tout en respectant « l’univers » informatique de l’entreprise. Ben oui, on ne peut pas demander à Google Map de créer de nouvelles routes pour simplifier l’itinéraire. Il va falloir jongler avec les contraintes existantes. 

Alors, je blague beaucoup sur les « informaticiens », les gens qui parlent en « binaire » mais j’adore travailler avec eux. Beaucoup de dirigeants ont tendance à reprocher à leurs collaborateurs de raisonner en mode « contrainte ». Dans nos métiers (la data, l’IT…), c’est un impondérable. On ne peut pas y échapper, alors, plus les contraintes seront identifiées, plus la solution sera fiable. Sans compter que, dans ce type de projet, nos équipes IT y voient un réel défi, et que le challenge, ça motive.

C’est ainsi que notre analyste fonctionnel va pouvoir nous concocter un brief aux petits oignons, avec un contexte, un objectif, des contraintes, un livrable attendu… tout ce qu’on aime. Et, cerise sur le gâteau, parfois, un rétroplanning.

 

T’as vraiment cru que c’était fini ?

On pourrait penser que la mission de l’analyste fonctionnel s’arrête là. Un rôle assez proche du chef de projet en quelque sorte, avec un peu les mains dans le cambouis pour réduire les interlocuteurs de la chaîne. Mais que nenni !

Il n’existe pas de diplôme d’analyste fonctionnel à ma connaissance, et s’il en existait un, je ne suis pas certain que ses titulaires soient vraiment opérationnels. 

En général, ce que j’aime bien trouver dans le CV de l’analyste fonctionnel (oui oui, c’est très perso comme input), c’est une expérience en datamining, une expérience en analyses statistiques, une expérience en chef de projet, une expérience en dataviz … une multitude d’expériences, qui, mises bout à bout, vont nous donner un profil très « couteau suisse » et autonome.

Alors notre analyste fonctionnel (je vais l’appeler Kevin, parce que j’ai trop écrit « analyste fonctionnel » 😉 ) …

Alors notre Kevin, il va suivre le projet dans toutes sa durée. Travailler avec l’équipe technique pour qualifier la donnée, la valider, vérifier que les formats de restitution permettront d’obtenir le résultat attendu, valider les granularités des données…. Kevin, il sait ce qu’il veut, il sait ce qu’il a demandé et il sait expliquer ce qui ne va pas quand ça ne va pas. Kevin, c’est le Jarvis de vos projets data (pour info, Jarvis, c’est l’ordinateur hyper omniscient d’Iron Man…).

Kevin, il connait tellement bien le projet, qu’une fois livré, c’est lui qui va former le métier. Lui réexpliquer ce qu’il a demandé et comment l’avoir, l’aider à manipuler sa dataviz, le former sur ces nouveaux outils, réécrire ses règles de gestions….

Kevin, c’est ton meilleur copain dans ton projet data ! Et Kevin travaille chez Know Your People !