J’ai toujours trouvé étrange et ambigu ce métier hybride de consultant technico-fonctionnel. Pourtant, après ma reconversion professionnelle en 2008, j’ai moi-même fait partie de cette « famille » en intervenant notamment sur des projets de Business Intelligence.
En tant que consultant technico-fonctionnel, on se sent flotter entre deux eaux : ni complètement développeur, ni complètement « métier », et pourtant maillon incontournable de l’organisation des projets de BI, ERP, PLM et autres CRM.
Ne serait-ce pas mieux de différencier ces deux facettes pour apporter encore plus de valeur aux utilisateurs finaux et aux clients ?
En d’autres termes, est-ce que le consultant technico-fonctionnel est un mouton à 3 pattes qui comble le fossé entre les besoins métier et la solution technique, sans toutefois être en mesure de jouer pleinement son rôle de conseil auprès du client et des utilisateurs ?
Ou est-il ce mouton à 5 pattes, dont l’expertise conjointe en business analyse et en solution logicielle lui permet d’accompagner ses clients de A à Z ?
Un consultant technico-fonctionnel intervient dans le cadre de projets de systèmes d’information, et plus spécifiquement dans la mise en place de solutions d’éditeurs – aussi appelées COTS pour « Commercial off-the-shelf ».
Il est essentiellement spécialisé dans des domaines comme la Business Intelligence (BI), les ERP (Enterprise Resource Planning), les PLM (Product Lifecycle Management) et les CRM (Customer Relationship Management).
Le consultant technico-fonctionnel est appelé ainsi car il doit posséder à la fois des compétences de Business Analyst (consultant AMOA, fonctionnel, analyste d’affaires etc) et des compétences techniques pour être en mesure de configurer le logiciel d’éditeur au plus près des besoins de ses clients.
Il peut ainsi être amené à réaliser les activités suivantes :
- Participation à la phase d’avant-vente afin de définir et de proposer plusieurs solutions possibles en réponse à une nécessité de changement ;
- Analyse des besoins métier et de la vision stratégique du client ;
- Organisation et animation des séances d’élicitation (recueil des besoins) ;
- Rédaction des spécifications technico-fonctionnelles du logiciel COTS, c’est-à-dire la description des paramètres à configurer pour répondre aux besoins métiers ;
- Modélisation des processus métier pour définir comment la solution s’intégrera dans la chaîne de valeur de l’organisation ;
- Définition et exécution des tests technico-fonctionnels ;
- Assistance du client lors de la phase d’acceptance ;
- Formation des utilisateurs pour les aider à la prise en main du logiciel.
Le contexte : les logiciels d’éditeurs
Les logiciels sur étagère (COTS) sont conçus et développés par des éditeurs spécialisés. Ils répondent à des besoins standards et communs aux acteurs d’un même marché, d’un même secteur, ou partageant une activité commerciale similaire.
La Business Intelligence (BI)
Les logiciels de Business Intelligence sont des systèmes d’information permettant la collecte, l’analyse, la restitution et l’exploitation d’un très grand nombre de données, dans le but de faciliter la prise de décision des managers.
Il n’y a pas « un » mais « des » consultants technico-fonctionnels en BI. En effet, on distingue ceux qui travaillent sur l’architecture et la collecte des données, de ceux qui travaillent sur la partie avale de restitution des données (framework et reporting).
Les ERP
Les ERP sont un groupe de modules indépendants reliés à une base de données unique, permettant de gérer l’ensemble des processus opérationnels d’une entreprise – achats, production, finance, RH, ventes etc.
Outre la maîtrise du fonctionnement générique de l’approche ERP, un consultant technico-fonctionnel ERP a une formation complémentaire à un logiciel précis, voire même souvent un ou des modules spécifiques de ce même logiciel.
Par exemple, le consultant technico-fonctionnel SAP FI est spécialisé dans les processus métier de la comptabilité. S’il est « labellisé » SAP MM, c’est qu’il est expert sur les modules SAP des achats et des stocks, etc.
Les PLM
Les PLM sont des logiciels qui gèrent le cycle de vie d’un produit manufacturé.
Ils sont parfois confondus avec les ERP, car ils fonctionnent eux aussi avec des modules reliés à une base de données, mais leur objectif est différent.
En effet, leur raison d’être est de permettre à l’entreprise de s’adapter aux évolutions des marchés internationaux en réduisant le time-to-market, et en étant capable de gérer des produits toujours plus nombreux et variés, un grand nombre de versions, et avec des équipes de conception dispersées dans le monde entier.
Dans le secteur PLM, il existe également de nombreux éditeurs spécialisés par marché, produit ou service.
Être consultant technico-fonctionnel PLM implique donc, comme pour les ERP ou la BI, de maîtriser l’architecture et l’approche générique des PLM, tout en étant formé à la solution d’éditeur en particulier.
Les CRM
Les logiciels de CRM ont pour objectif de gérer la relation client de l’entreprise, ils sont principalement utilisés par les départements Ventes et Marketing.
Tout comme pour les COTS précédemment cités, le consultant technico-fonctionnel CRM aura là aussi la connaissance générique de ce qu’est l’approche CRM, des processus métier impactés au sein de l’organisation, et bien entendu, une connaissance particulière de la solution d’éditeur CRM choisie par le client.
Il existe bien d’autres logiciels d’éditeurs sur le marché, chacun dédié à un secteur économique, un marché, ou autres fonctions d’entreprises. Et donc, autant de consultants technico-fonctionnels spécialisés.
L’expertise métier (MOA) et fonctionnelle (MOE)
Reprenons maintenant les activités du consultant technico-fonctionnel qui correspondent à une expertise dite « fonctionnelle » quand il est rattaché à l’équipe réalisatrice de la solution (la maîtrise d’oeuvre, ou MOE), ou encore « métier » quand il est rattaché au porteur du besoin (la maîtrise d’ouvrage, la MOA).
Dans cette catégorie, on retrouve les compétences professionnelles qui lui permettent de comprendre la vision stratégique du client et les besoins opérationnels des utilisateurs métier.
Il s’agit donc des activités suivantes :
- Analyses d’avant-vente : étude d’opportunité, analyse de faisabilité, analyse de rentabilité (business case), cadrage
- Elicitation des besoins métier: recueil exhaustif, fiable, clair, non ambigu et consensuel
- Analyse des besoins métier ;
- Modélisation des processus métiers;
- Définition des règles métier et du glossaire ;
- Analyse des risques ;
- Assistance auprès du client lors de la phase de recette ;
- Formation des utilisateurs pour les aider à la prise en main du logiciel COTS.
Parallèlement à ces activités traçables dans la gestion de projet, on retrouve d’autres activités fondamentales et transverses que sont :
- L’organisation, l’animation et la restitution des séances d’élicitation (recueil des besoins) ;
- La présentation des résultats d’analyse et la recommandation de solutions ;
- L’ingénierie des exigences.
L’expertise technique
Passons à présent à l’expertise technique du consultant technico-fonctionnel.
Mais, finalement, que signifie l’expression « expertise technique » ? Parce que, en matière de systèmes d’information, c’est tellement vaste qu’on ne peut pas être expert en tout…
Sans vouloir trop généraliser, les compétences techniques requises ici sont :
- La connaissance de l’approche PLM / BI / ERP ou CRM : le consultant technico-fonctionnel doit s’approprier l’architecture du système d’information et comprendre le parcours de la donnée qui « traverse » cette architecture, depuis sa captation jusqu’à sa restitution sous forme de reporting par exemple.
- La connaissance pointue de la solution d’éditeur choisie : on l’a vu plus haut, si vous êtes consultant SAP ou Power BI, vous devrez être formé(e) au préalable à ces outils d’éditeurs pour être en mesure de les configurer de manière pertinente, pour satisfaire les besoins métiers.
- Des notions (voire plus…) en base de données, SQL et autres langages utilisés dans les interfaces et transferts de données comme le XML. Tout dépend de la solution technique choisie.
- En matière ce conception fonctionnelle, il faut savoir que les spécifications fonctionnelles détaillées sont en réalité très techniques, rien à voir avec leurs équivalents rédigées dans les projets de SI sur mesure (logiciels codés à partir de zéro). En effet, le consultant technico-fonctionnel ne dit pas ce que le logiciel doit faire, mais comment paramétrer les fonctionnalités natives pour atteindre le résultat par les pôles métiers. Les spécifications technico-fonctionnelles du logiciel COTS décrivent donc précisément la configuration, et sont très orientées données, attributs et autres formats de nombres.
- Enfin, les compétences requises pour définir et exécuter les tests sont également techniques : le consultant technico-fonctionnel doit être autonome pour requêter en base, faire du data mining, modifier le paramétrage technique, et autres tâches habituellement dédiées aux développeurs.
Peut-on maîtriser et exercer simultanément ces deux expertises ?
J’ai été assez générale dans la description des compétences du consultant technico-fonctionnel, malgré le fait que celui-ci puisse être parfois extrêmement spécialisé. Mais je pense que la « big picture » est assez ressemblante à ce qui se voit généralement pour ce genre de profil.
Dans la réalité, les consultants technico-fonctionnels qui maîtrisent réellement ces deux facettes sont rares, et il s’agit exclusivement de profils expérimentés.
Les consultants technico-fonctionnels débutants, « juniors » ou ayant une expérience intermédiaire sont donc, à mon sens, des consultants techniques, car ils ne maîtrisent pas les subtilités de la business analyse.
Dans la réalité, la grande majorité d’entre eux se concentre sur les activités à compétence technique décrites ci-dessus. Pour ce qui est de la partie relative au recueil des besoins, elle est la plupart du temps réalisée avec les moyens du bord, à l’instinct, sans avoir même la connaissance des techniques d’élicitation existantes.
Les activités « fonctionnelles » sont souvent réalisées par d’autres consultants ou collaborateurs que le consultant technico-fonctionnel, ou encore par le chef de projet (qui n’est pas non plus formé à l’analyse métier). Ou par personne.
Depuis quelques années, j’ai eu vent de certaines bonnes initiatives provenant d’ESN spécialisées en BI / ERP / CRM / PLM, qui, conscientes des lacunes organisationnelles en matière d’analyse métier, ont décidé de séparer ces deux rôles : un consultant métier « business analyst » et un consultant technique orienté paramétrage de la solution, au lieu du trop rare mouton à 5 pattes « technico-fonctionnel ».
Les résultats sont mitigés, notamment pour les cas de figure où le consultant métier n’était pas formé à l’approche ni au logiciel COTS, et qui se retrouvait à recommander des solutions métiers inapplicables techniquement.
Les succès enregistrés sont du côté des entreprises qui ont su séparer les deux compétences métier et technique, tout en ayant formé au préalable leurs consultants métiers à la solution technique. Attention, je ne parle pas d’une formation pointue, mais bien d’une introduction, d’un « vernis » qui leur est en général suffisant pour comprendre les contraintes de la solution, les enjeux technologiques et les attentes des équipes techniques.
En conclusion
Pour conclure, je dirais donc que dans la plupart des cas, les consultants technico-fonctionnels marchent sur 3 pattes, car ils sont presque exclusivement orientés solution, et non pas besoins métiers et vision stratégique. Seuls les profils expérimentés ont cette compétence, or ils sont rares.
La solution ? Ni 3 pattes, ni 5 pattes : n’oubliez pas de former vos consultants technico-fonctionnels à la business analyse, et ne faites pas non plus intervenir des Business Analysts sans aucune notion informatique, ni formation aux approches et aux logiciels COTS.
Un mouton à 4 pattes, c’est finalement l’idéal pour sécuriser vos projets en BI, ERP, PLM et autres CRM.
