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. Etant à la croisée des chemins, l’analyste métier ou système – aussi appelé consultant fonctionnel ou Assistant à la Maîtrise d’Ouvrage (AMOA) – 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 informatique possible.
Ni 100% expert métier, expert technique, ou 100% chef de projet, mais un peu de tout cela à la fois, le Business Analyst est un couteau suisse qui doit continuellement affûter ses compétences.
Dans cet article, je souhaite donc aider les business analysts débutants à mieux comprendre les activités phare de leur futur métier.
Se former à la Business Analyse: un réel défi
95% des Business Analysts francophones ne sont pas formés à leur métier, faute de formations académiques disponibles sur le marché. L’apprentissage et la montée en compétence se font donc dans l’immense majorité “sur le tas”.
A la difficulté que représentent la découverte et la pratique du périmètre d’activités de la Business Analyse, s’ajoutent d’autres obstacles, comme la compréhension du jargon, des processus et bonnes pratiques informatiques, métier et de la gestion de projet. Enfin, comme en terre inconnue, le BA doit d’abord apprendre à communiquer avec ses interlocuteurs pour en extraire les besoins exprimés, inconscients, cachés ou latents, et délivrer ainsi la solution la plus satisfaisante possible.
Qu’attend-on de lui ou elle quand on lui dit de faire la conception fonctionnelle, l’analyse des besoins, ou la modélisation de la solution cible? Comment s’assurer que le logiciel développé répond aux exigences métier? Comment aider les utilisateurs à s’approprier leur nouveau système d’information en les accompagnant et en les formant?
[Master Class] Devenir Business Analyst en S.I.
Les Fondamentaux de A à Z
50 heures de formation qualifiante complète en e-learning pour se professionnaliser au métier de Business Analyst en systèmes d'information.
Les activités en Business Analyse
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 activités de l’analyse métier et systèmes (business analyse) 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
- L’évaluation de la solution
- La conduite du changement
>> Lire aussi: Terminologie du Business Analyst
Voici, en synthèse, à quoi correspondent de manière pratique ces 8 activités fondamentales réalisées par le Business Analyst en SI.
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 anomalies.
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.
5) L’analyse
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.
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…
>> Lire aussi: [Tutoriel] Le Business Model Canvas
6) La conception fonctionnelle
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.
J’espère que cet article aura éclairé un maximum de Business Analysts en reconversion ou en poste, n’hésitez pas à me laisser vos impressions en commentaire !
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
