Quand on débute en tant que Business Analyst, il faut bien se l’avouer, on avance en terre inconnue. À mes débuts, je comprenais vaguement un mot sur deux quand on m’adressait la parole, que ce soit le chef de projet, le client, mes interlocuteurs métiers ou encore mes collègues développeurs. OK, j’exagère (à peine), mais ce qui est sûr, c’est que je n’étais pas du tout dans ma zone de confort.
Dans cet article, je souhaite donc aider les business analysts débutants à mieux s’approprier leur nouveau métier, qui commence bien souvent par la description de la solution informatique cible.
Voyons ensemble la différence entre ces deux expressions très proches mais néanmoins bien distinctes : conception fonctionnelle vs. spécifications fonctionnelles détaillées.
La reconversion: voyage en terre inconnue
C’est un réel défi de se reconvertir en tant que Business Analyst après une première carrière dans un autre métier, car étant à la croisée des chemins, l’analyste métier ( = consultant fonctionnel, AMOA etc – tous ces intitulés de fonctions sont proches) doit avoir une compréhension globale des enjeux stratégiques, métiers, techniques, tout en étant capable de plonger dans les profondeurs des détails pour recommander et définir précisément la meilleure solution possible.
Ni expert métier, ni expert technique, ni expert en pilotage de projet, mais un peu tout cela à la fois, le Business Analyst est un couteau suisse qui doit continuellement affûter ses compétences.
>> [VIDEO] « Doit on avoir des compétences en informatique pour être BA
>> Lire aussi : Doit-on être expert métier quand on est Business Analyst ?
Une discipline qui demande de la maîtrise
La première chose pour garder son énergie dans la découverte d’un nouveau projet et de l’Organisation cliente, est donc de maîtriser sa discipline, la Business Analyse.
Or, 99% des Business Analysts francophones ne sont pas non plus formés à leur métier. Celui-ci s’apprend généralement sur le tas. Rien d’étonnant donc que leur premier écueil soit lié à la terminologie employée sur les projets de systèmes d’information. Et, comme en terre inconnue, le BA doit d’abord apprendre à communiquer avec ses interlocuteurs avant de livrer ses inputs au client et au chef de projet.
Qu’attend-on de lui ou elle quand on lui dit de s’occuper de la conception fonctionnelle ? Est-ce la même chose que le livrable à rendre dans 6 semaines au chef de projet et qui s’intitule « Detailed Functional Specifications » / Spécifications Fonctionnelles Détaillées / Business Requirements Document ?
>> Lire aussi : Quelles certifications pour devenir Business Analyst?
Terminologie du Business Analyst: le contexte
Avant de vous expliquer ce que ces notions recouvrent, je voudrais m’arrêter sur le contexte de leur utilisation.
Les Business Analysts travaillent pour 80% d’entre eux dans le cadre de projets de systèmes d’information, tous secteurs confondus, soit en tant que prestataires externes soit en tant que collaborateurs salariés du « client ».
Les termes de conception fonctionnelle et de spécifications fonctionnelles détaillées se rencontrent donc dans les projets de systèmes d’information et de développement logiciel.
Les activités de l’analyse métier peuvent être regroupées en 8 catégories principales :
- L’analyse stratégique d’avant-projet
- La planification et le monitoring de l’analyse métier
- La gestion du cycle de vie des exigences
- L’élicitation
- Les analyses
- La conception fonctionnelle (on y vient 😊)
- L’évaluation de la solution
- La conduite du changement
>> Voir aussi: Terminologie du Business Analyst
1) L’analyse stratégique
L’objectif ici est de comprendre ce qui a motivé le besoin de changement de l’Organisation, d’analyser l’intérêt de lancer le projet, et de cadrer son champ d’application. Le Business Analyst qui intervient ainsi en phase d’avant-projet sera amené à réaliser par exemple une étude d’opportunité, une analyse des risques, une analyse financière ou encore un cadrage, et équipera le Top Management de suffisamment d’informations étayées pour lui permettre de prendre une décision.
>> Lire aussi: Pourquoi le document de cadrage est-il si important ?
2) La planification et le monitoring de l’analyse métier
Ça y est, le projet est lancé. Qu’il soit géré de manière traditionnelle ou agile, il faut se préparer minutieusement pour être efficace et pertinent.
Dans cette activité, le Business Analyst va s’occuper de la gouvernance de l’analyse métier, il va planifier à plus ou moins long terme ses activités, identifier et se familiariser avec les livrables ou artefacts attendus, affiner sa compréhension des rôles et responsabilités projet, et sélectionner les méthodes et outils applicables au contexte du projet et de l’organisation. C’est un travail collaboratif avec le chef de projet.
>> Lire aussi: 5 étapes pour identifier les contributeurs d’un projet
3) La gestion du cycle de vie des exigences
L’analyse métier ne s’arrête pas à la fin du projet, elle continue tout au long du cycle de vie de la solution. Le « Go Live » du projet est effectivement un jalon fondamental puisqu’il signe la « naissance » du logiciel, mais après la période de garantie, il y aura une phase très longue de maintenance pour adapter continuellement l’application aux nouveaux besoins métier et corriger les inévitables bugs.
Il est donc nécessaire de mettre en place une base de gestion du cycle de vie des exigences, afin d’être en mesure de tracer le lien entre les besoins métiers et les caractéristiques de la solution technique.
>> Lire aussi: Comment décrire les exigences non fonctionnelles
4) L’élicitation
Ce terme est tiré du BABOK, le corpus de connaissance de l’International Institute of Business Analysis (IIBA®).
Le recueil d’une information exhaustive, fiable, consensuelle et vérifiée est une activité centrale et continue en analyse métier. Le BA manipule l’information sous toutes ses formes, les analyse, puis recommande et détaille la solution préconisée.
Il y a de nombreuses techniques d’élicitation qui ont chacune leurs avantages et leurs inconvénients. Charge au BA de les sélectionner avec pertinence, puis de préparer et de réaliser le recueil de l’information à proprement parler.
>> [VIDEO] La collecte de l’information : techniques d’élicitation (Part 2)
5) Les analyses
L’activité d’analyse est un prérequis incontournable qui sécurise le succès d’un projet ou d’une demande d’évolution applicative. Partir bille en tête dans le développement logiciel sans avoir pris le temps de vérifier que la solution envisagée répondra réellement aux besoins métier et aux objectifs stratégiques de l’Organisation fait porter au projet un risque inutile et facile à éviter.
>> Lire aussi : Pourquoi 83% des projets informatiques échouent-ils?
Différents types d’analyses existent, en fonction de l’objectif recherché par le business analyst : compréhension de la vision et des objectifs métiers, identification des besoins utilisateurs, définition des caractéristiques du logiciel cible, vérification et recherche de consensus, validation des livrables etc…
6) La conception fonctionnelle
Nous voilà dans le cœur du sujet de cet article.
La conception fonctionnelle permet de décrire comment la solution informatique va répondre aux besoins métier préalablement identifiés.
Elle s’effectue en trois étapes :
- Tout d’abord, on identifie précisément les besoins et contraintes de la maîtrise d’ouvrage et des utilisateurs.
- Ensuite on définit, on structure, on hiérarchise et on valide la vision de la solution globale.
- Enfin, on décrit de manière détaillée les fonctionnalités et le comportement du système cible (les exigences de la solution).
La conception fonctionnelle est donc une activité composée de tâches, d’échéances, et de résultats à produire. Le Business Analyst utilise à cet égard les activités décrites précédemment soit comme données entrantes (par exemple, les résultats de l’élicitation), soit comme contraintes pesant sur la conception fonctionnelle (résultats des analyses, planification etc).
7) L’évaluation de la solution
Dans cette activité, le Business Analyst vérifie que le logiciel développé par l’équipe technique correspond à ce qui a été décrit lors de la conception fonctionnelle. Dans les projets agiles, il s’assure également de la valeur ajoutée délivrée par le logiciel aux utilisateurs et au client.
L’évaluation de la solution passe par la préparation et le déroulement des tests fonctionnels, puis par l’assistance à la maîtrise d’ouvrage lors de la phase de recette.
8) La conduite du changement
Enfin, l’activité de conduite du changement a pour objectif d’aider l’Organisation cliente à effectuer sa transition vers la nouvelle solution informatique.
Le Business Analyst en systèmes d’information sera quant à lui focalisé sur les activités de formation puis d’assistance aux utilisateurs. Ce sera plutôt le rôle du BA métier ou gouvernance (non-IT) d’aider l’Organisation cliente à anticiper les résistances au changement et à préparer un plan stratégique pour les comprendre et les accompagner.
>> [VIDEO] Quelle est la différence d’approche entre un BA IT et un BA métier ou gouvernance?
Conception fonctionnelle vs. Spécifications Fonctionnelles Détaillées
Dans les projets gérés de manière traditionnelle, les Spécifications Fonctionnelles Détaillées sont un livrable de la phase de conception fonctionnelle, dont je viens de vous parler précédemment.
Ce document – en réalité un ensemble de documents comportant en outre le glossaire, les règles métier, éventuellement les maquettes et modélisations complémentaires – décrit très précisément les fonctionnalités et les exigences non-fonctionnelles de l’ensemble de la solution cible.
>> [VIDEO] C’est quoi, les Exigences Non Fonctionnelles ?
Les SFD n’existent en revanche pas en tant que telles dans les projets gérés de manière agile.
En effet, ces derniers ont une documentation très légère, et les résultats de la conception fonctionnelle sont essentiellement le Product Backlog et les User Stories, enrichis, comme les SFD, des modélisations, maquettes, glossaire et autres règles métier complémentaires.
En résumé
La Conception Fonctionnelle Détaillée est une activité et une étape cruciale de tout projet de S.I., pendant laquelle le BA réfléchit, analyse, recommande puis décrit ce que fera le logiciel cible.
Les Spécifications Fonctionnelles Détaillées, quant à elles, sont le livrable clé qui matérialise la fin de la conception fonctionnelle sur les projets gérés de manière traditionnelle. Elles n’existent pas dans les approches agiles.
J’espère que cet article aura éclairé un maximum de Business Analysts en reconversion ou en poste, et n’hésitez pas à me laisser vos impressions en commentaires !
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
