Seng est consultant décisionnel. Ici il nous raconte ses projets Business Analytics au sein d’une grande entreprise de l’aéronautique et comment il est revenu du côté obscur de la technique pour devenir un jedi métier…
Découvrez ici plus de témoignages de projets
« Au début, il y avait un besoin technique au sein du contrôle de gestion achats.
Un outil décisionnel d’élaboration budgétaire et de prévisions était déjà implanté (parmi tant d’autres) mais, devant une grosse boîte noire, le client commençait à mal dormir au vu des risques techniques et de l’inquiétude grandissante des utilisateurs.
Je suis entré dans le projet pour rationaliser l’application et déployer un module web inexploité dans le but de faciliter la collecte de données par les contrôleurs de gestion. Ces derniers interviennent en appui des acheteurs lors des phases de négociations. Les prévisions, basées sur les conditions contractuelles en cours, permettent d’estimer le prix d’achat des pièces : la simulation sur des hypothèses de risques et opportunités achats (hausse fournisseur ou hausse des matières premières, par exemple) sont modélisées afin d’estimer le coût des ventes d’un avion de façon précise. J’ai passé environ un an sur ce projet purement technique.
Les prévisions du contrôle de gestion achats étaient jusqu’ici établies à l’aide de trois applications différentes (sans parler du nombre de fichiers Excel complémentaires). Il a donc fallu, dans un second temps, migrer vers une solution unifiée afin de centraliser les données et enfin…respirer ! Dans ce cadre, je suis intervenu en assistance à maîtrise d’ouvrage. J’ai commencé par aider le métier à exprimer et formaliser les besoins des utilisateurs et j’ai poursuivi cet accompagnement tout au long des différentes étapes du projet (spécifications, dossier d’architecture, plans de tests, plan de migration des données, …). En bref, j’ai été l’interface entre les métiers et l’intégrateur durant les 1 an et demi d’accompagnement.
Le consultant décisionnel : une vision technique mais aussi fonctionnelle
Dans cette seconde partie de projet, j’ai dû rajouter une casquette métier à ma casquette technique.
C’est un peu mon terrain de prédilection, la technique. Je suis ingénieur de formation et en tant que consultant décisionnel, j’avais une vision centrée sur l’outil. Mais à force de projets, j’ai été amené, au fil de l’eau, à maîtriser les problématiques métiers… Il faut dire que dans ce contexte-là, ma première expérience dans l’industrie automobile s’est avérée utile. J’avais passé 3 ans sur des problématiques de planification financière.
En fait, mon job c’est d’être l’interface entre le métier et l’équipe de développement. Ces derniers sont souvent loin des problématiques des uns et des autres. Concrètement, je « soulage » le métier en répondant en son nom aux questions de l’équipe de développement, en qualifiant les règles de gestion et données de l’application avant que celles-ci ne se retrouvent entre les mains des experts fonctionnels pour validation ou en faisant monter en compétence les ressources clés de l’équipe de développement sur les aspects fonctionnels.
Une double compétence qui facilite la prise de décisions
Mes compétences techniques sont un avantage lorsqu’il s’agit de traduire une information de l’équipe technique. C’est également le cas quand il s’agit de mettre en garde le métier contre des choix de modélisation. En effet, ils pourraient s’avérer trop contraignants à mettre en œuvre et/ou à utiliser. Ou de simplement leur faire prendre conscience du caractère impossible de certaines demandes. (Non, on ne peut pas toujours avoir des réponses en « temps réel ». Même avec l’outil le plus puissant au monde, même en combinant BI et finance).
Mes compétences métier sont un plus pour le client et l’équipe de développement car, elles permettent un gain de temps non-négligeable pour les experts métier dont l’agenda est très chargé. Par exemple, j’ai formé, depuis le début du projet « au métier » 5 architectes applicatifs successifs – 4 d’entre eux ayant jeté l’éponge.
La double compétence technique et fonctionnelle présente un avantage certain pour l’ensemble des parties prenantes. Un seul interlocuteur pour deux visions d’un même projet. C’est surtout l’assurance d’une bonne traduction pour un livrable adapté. Sinon, le projet risque d’échouer. Puisque les utilisateurs peuvent abandonner l’outil et les processus par la suite.
Nos consultants décisionnels sont sur LinkedIn, suivez nous sur @Intis Outperform