Elicitation et collaborationTechniques et méthodes

Réussir une séance de recueil des besoins [7 erreurs à éviter]

Besoin de conseils pour réussir une séance de recueil des besoins ou pour vous aider à poser les bonnes questions lorsque vous interviewez vos contributeurs?

Le recueil des besoins est l’une des activités phares de la Business Analyse, et l’un des socles de la réussite des projets, qu’ils soient informatiques ou non.

Il est en effet hasardeux et difficile d’accompagner les organisations dans la mise en œuvre d’un changement si l’on n’est pas capable d’identifier et d’analyser la problématique racine. 

Le travail de Business Analyst consiste ainsi non seulement à recueillir des informations auprès des contributeurs du projet, mais également à s’assurer que celles-ci sont exhaustives, fiables, vérifiées et consensuelles.

 Le rôle du Business Analyst

Ceux d’entre vous qui pratiquez déjà des activités d’analyse métier le savent : le périmètre d’intervention au sein d’un projet – surtout agile – n’est pas toujours très précis.

De manière générale, les organisations font appel aux Business Analysts dans le cadre de la mise en place ou de l’adaptation à un changement. Le Business Analyst intervient alors pour analyser les activités de l’organisation cliente dans l’objectif de recommander et de définir précisément la meilleure solution possible, qu’elle soit en Systèmes d’Information ou non.

Une fois la solution réalisée par les équipes techniques (s’il s’agit d’un projet de S.I.) ou opérationnelles (s’il s’agit d’un produit, d’un service ou d’un processus), c’est à nouveau au BA de la vérifier et de valider son adéquation avec les objectifs métiers, pour qu’elle soit finalement mise en place à l’échelle de l’organisation cliente. 

Quelques exemples de nécessité ou désirs de changements qui conduisent à l’intervention d’un Business Analyst:

  • Lancement d’une offre concurrente sur le marché de la téléphonie qui contraint une entreprise téléphonique à restructurer son offre
  • Mise en place de nouvelles réglementations comme le RGPD obligeant une entreprise à changer entièrement de business model
  • Adaptation économique à un changement des quotas douaniers des USA
  • Réorganisation des entreprises après la crise sanitaire du Covid-19
  • Obsolescence applicative et nécessité de remplacer le système d’information vieillissant par un autre plus moderne et maintenable
  • Nouveau service ou produit s’appuyant sur une application web
  • Rachat ou fusion de deux organisations, et adaptation des systèmes d’information, processus, et cultures d’entreprise
  • Arrivée d’un nouveau P-DG avec une nouvelle stratégie à mettre en oeuvre…

Qu’ils soient internes ou externes, ces changements déclenchent un besoin de mettre en place des solutions, sous la forme de Systèmes d’Information (SI) ou non. C’est là qu’intervient le Business Analyst avec pour première mission : recueillir les besoins métiers et la vision stratégique.

 >> Lire aussi: Savez-vous gérer les changements de périmètre de votre projet?

 

Importance du recueil de l’information et notion d’élicitation

Recueillir de l’information est le prérequis à toutes les activités de l’analyse métier. Pour analyser, recommander, définir, et mettre en place des solutions, il faut de l’information. 

On parle souvent de « recueil de l’information » ou de « recueil des besoins » mais personnellement, je préfère la notion d’« élicitation » – qui nous vient du BABOK® de l’International Institute of Business Analysis (IIBA) – qui est moins ambiguë pour décrire cette étape clé de l’analyse métier.

Néanmoins, comme ce terme est moins répandu, il m’arrive d’utiliser le terme de « collecte de l’information » dans mes articles pour que cela parle au plus grand nombre.

>> Lire aussi Les 5 choses que vous auriez aimé savoir avant de devenir Business Analyst

 

D’où vient le terme « élicitation » ?

Le terme « élicitation » a été initialement utilisé dans le BABOK de l’IIBA ([EN] Business Analysis Body Of Knowledge) en lieu et place de la simple “collecte” des besoins. L’IREB parle de son côté d’”élucidation”, mais il s’agit bien du même concept.

Éliciter ne consiste pas à lister les informations collectées auprès des contributeurs: ce n’est pas une simple checklist, bien que ce soit une confusion fréquente chez les Business Analysts débutants. Réussir une séance de recueil des besoins demande beaucoup de planification et de patience.

  

L’élicitation : les objectifs

L’élicitation sert à collecter des informations ou des besoins dans le but de proposer une solution cible en réponse à une nécessité de changement, tout en prenant en compte les contraintes internes et externes de l’organisation et du projet.

Je me répète, mais il est important de comprendre que le travail du Business Analyst n’est pas de prendre des notes sans se poser de questions, car il ne collectera dans ce cas que les besoins explicites des parties prenantes. Or, beaucoup de besoins peuvent être cachés, non exprimés, ou inconscients. Et ce sont même les plus importants à connaître pour sécuriser la réussite du projet. 

Le rôle et la valeur ajoutée de l’élicitation consiste donc à s’assurer que les informations recueillies sont:

  Exhaustives : l’information doit être aussi complète que possible

  Fiables : l’information doit provenir de sources fiables

  Vérifiées : l’information doit être vérifiée — le processus  de vérification peut d’ailleurs être plus long que de recueillir les données elles-mêmes

  Consensuelles: les besoins et informations émanant de contributeurs différents sont parfois contradictoires, et ils doivent donc faire l’objet d’un consensus entre ces derniers avant de pouvoir être utilisés pour recommander une solution

Ces informations doivent permettre au Business Analyst de préparer ses analyses, de recommander une solution et ses alternatives, de décrire les fonctionnalités logicielles, ou encore de mettre en place une stratégie de gouvernance pour s’assurer que la solution satisfait les besoins métier.

>> Lire aussi: La collecte de l’information

L’activité d’élicitation n’est pas restreinte à la phase amont de recueil des besoins métier; elle a lieu tout au long du projet, qu’il soit informatique ou non.

 

Pour réussir une séance d’élicitation, il faut planifier

L’élicitation est une activité qui prend du temps, et elle n’est pas toujours planifiée à sa juste mesure dans les feuilles de route des projets. Les activités de préparation et de restitution notamment sont souvent sous-estimées.

Il existe des dizaines de techniques possibles, qui ne requièrent pas forcément une interaction physique avec les parties prenantes. Par exemple, les sondages et questionnaires, le data mining, l’analyse des interfaces, etc. 

Je me focalise dans cet article sur les techniques qui impliquent un face-à-face, comme les interviews et les ateliers de travail.

Recueillir des besoins n’est pas simplement faire la conversation avec ses contributeurs. En fonction de la technique d’élicitation utilisée, le Business Analyst a recours à des questions ouvertes, fermées, des reformulations, des questionnements appropriés qui suivent une approche réfléchie.

Il est donc nécessaire de bien préparer et de planifier les séances de collecte de l’information, pour optimiser les résultats et ne pas repartir avec des tonnes de données inutiles.

 

1. Se fixer un objectif pour la séance.

L’objectif d’un interview ou d’un workshop dépend de la phase du cycle de vie de la solution pendant laquelle vous êtes amené(e) à collecter l’information. En avant-projet, l’objectif n’est évidemment pas le même que pendant la conception fonctionnelle d’une solution informatique.

Il faut donc se demander si l’objectif est de :

  • Collecter l’information pour la phase de pré-projet, c’est-à-dire par exemple pour réaliser le cadrage ou l’étude d’opportunité
  • Recueillir des chiffres, des estimations et des hypothèses de travail pour compléter le Business Case d’une analyse plus financière
  • Comprendre la vision générale ou stratégique de l’entreprise
  • Identifier les besoins des utilisateurs finaux dans le but de réaliser la conception fonctionnelle d’un logiciel cible
  • Préparer la conduite du changement
  • Etc…

La détermination de l’objectif de vos séances d’élicitation dépend également de la méthodologie de gestion de projet utilisée, puisque celle-ci affecte le périmètre à étudier.

En méthode agile, le recueil des besoins n’est pas le même qu’en méthode traditionnelle: l’élicitation est focalisée sur une portion très restreinte de la solution cible (le sprint). Au contraire, dans le cadre d’une méthode traditionnelle, elle analyse généralement le périmètre entier de la solution ou d’un lot du projet.

>> Lire aussi: Comment décrocher son premier job de Business Analyst?

 

2. Identifier les contributeurs et les contraintes du projet

Vos contributeurs sont le plus souvent des Subject Matter Experts (SME) : des experts ou « sachants »  (comptable, spécialiste des réglementations internationales, membre de l’administration fiscale…). Ils varient selon le secteur d’activité de l’organisation cible.

Pour planifier vos interviews et workshops, plusieurs facteurs sont à prendre en compte :

  • La localisation géographique : dans le même bâtiment, une autre région, un autre pays, un autre fuseau horaire?
  • La langue de communication: est-ce que tous les contributeurs présents (et vous-même) êtes à l’aise avec la langue utilisée pendant les sessions de travail?
  • La disponibilité : est-ce que vos contributeurs ont des contraintes opérationnelles, ou des congés?
  • La hiérarchie : est-ce nécessaire d’obtenir l’autorisation des supérieurs hiérarchiques et managers pour solliciter vos contributeurs?
  • Le budget : parfois, interviewer des contributeurs passe par une facturation interne du temps passé par ces derniers à vous aider. Vérifiez le budget alloué à l’élicitation car certains SME ‘pointeront’ sur la ligne budgétaire de votre projet pour justifier auprès de leur hiérarchie le temps passé sur des activités non -opérationnelles
  • La confidentialité : certains sujets sont confidentiels, notamment aux yeux et aux oreilles d’un Business Analyst prestataire. Assurez-vous d’avoir les autorisations nécessaires
  • Le profil : vos parties prenantes proviennent d’horizons divers. Ils peuvent être des collaborateurs internes (manager, technicien opérationnel…), ou des contributeurs externes (client, fournisseur, administration…). Leur profil peut impacter le type de questions que vous posez ainsi que les informations que vous serez autorisé(e) à révéler

>> Lire aussi: 5 étapes pour identifier les contributeurs d’un projet

 

3. Identifier la meilleure technique d’élicitation à utiliser

Il en existe plusieurs, à décliner selon les contraintes :

  • L’interview : souvent à deux, en face à face.
  • Le job shadowing (observation du poste de travail): le BA vient observer comment travaille le contributeur
  • Et beaucoup d’autres : la visite sur site, les ateliers de travail ou workshops en groupe, le brainstorming, le design thinking, les sondages, la lecture de documentation, le data mining…

Après avoir identifié les contributeurs et les contraintes pesant sur le projet et l’Organisation, le Business Analyst sélectionne la ou les techniques applicables. Parfois, un sondage bien réalisé sera plus efficace qu’un atelier de travail. Dans d’autre cas, il sera préférable de mener 4 interviews plutôt qu’un seul atelier de groupe. Dans d’autres encore, on combine la lecture de documentation, l’analyse des interfaces, le brainstorming et les interviews.

Enfin, si l’élicitation doit être planifiée, elle s’improvise également très souvent autour de la machine à café ou d’une discussion amicale officieuse avec vos contributeurs. Les “soft skills” et la capacité d’écoute d’un bon Business Analyst lui apportent souvent sur un plateau des besoins cachés ou non exprimés, alors cultivez-les !

 

Comment optimiser la séance d’élicitation

Voici quelques conseils pour bien mener une séance d’élicitation:

  1. Expliquer le contexte et le périmètre exact de la séance.
  2. Poser des questions ouvertes qui ne nécessitent pas une réponse binaire oui/non : employez la technique des ‘5 pourquoi’, commencez vos phrases par « pourquoi », « comment », « décrivez », « dites-moi », « que pensez-vous de telle chose… »
  3. Si besoin, préciser en posant des questions fermées – mais gare aux différences culturelles, par exemple en Inde ou le ‘non’ est malpoli ! 
  4. Se mettre dans la peau d’un nouvel embauché ou d’un stagiaire pour gagner en empathie et ne pas tirer de conclusions hâtives
  5. Recentrer sur l’objectif de la séance d’élicitation : le contributeur aura tendance à parler de ce qui l’intéresse ou l’importe, dans quel cas il faudra poliment le rediriger vers l’objectif
  6. Reformulez votre compréhension : vous serez surpris du nombre de fois où cette technique simple ouvre la boîte de Pandore…
  7. Faire preuve d’une grande écoute à l’égard de vos interlocuteurs, même si vous pensez très bien connaître son métier (ce qui est le cas de Business Analysts auparavant eux-même collaborateurs “métier” puis reconvertis).

>> Lire aussi: Comment optimiser une séance de recueil des besoins

 

 

Sept erreurs classiques à éviter pour réussir une séance de recueil des besoins

Avant de devenir “un(e) pro” de l’élicitation, vous risquez de commettre certaines erreurs, et c’est bien normal. Voici donc 7 erreurs classiques que vous pouvez éviter facilement:

  1. Lister sans vérifier ni chercher le consensus toutes les informations fournies par les contributeurs.
  2. Chercher à tout comprendre tout de suite: si, lors d’une séance, un point semble obscur, mais qu’il n’est pas impactant pour atteindre l’objectif de la séance de recueil des besoins en cours, le noter et prévoir éventuellement une séance spécifique ultérieure, ou encore, demander à vos contributeurs de vous transmettre l’information par mail.
  3. Échanger uniquement avec les SME (Subject Matter Experts) qui participent activement à la conversation et oublier les timides qui sont moins à l’aise pendant les ateliers de groupe.
  4. Anticiper les réponses en pensant que vous en connaissez déjà la teneur : vous n’êtes déjà plus dans l’écoute et risquez de passer à côté des besoins cachés, non exprimés… voire exprimés mais que vous n’écoutez tout simplement pas 😉
  5. Manquer d’implication et d’empathie : se positionner comme un « consultant » non impliqué dans le quotidien professionnel de vos contributeurs SME diminue les chances de recueillir de précieuses informations.
  6. Poser des questions fermées : “oui / non” vous ramène des informations quantitatives, ce qui peut effectivement être un de vos objectifs. Mais dans ce cas, privilégiez d’autres techniques d’élicitation comme les sondages. La valeur ajoutée des interviews et des ateliers de groupe est de collecter du qualitatif, grâce à l’emploi de techniques de questionnement ouvert.
  7. Ne pas oser montrer son incompréhension parce que tout le monde a l’air de savoir (sauf soi-même). Un Business Analyst est curieux, il/elle pose plein de questions: si vous saviez le nombre de fois où mes “pourquoi” ont permis à de mettre sur la table des incompréhensions parfois très anciennes… Vos SME vous seront reconnaissants d’apporter de la clarté 😉 

>> Lire aussi: Business Analysts Débutants: les 7 Erreurs Classiques

Vous l’avez compris, les activités d’élicitation sont cruciales pour la réussite de vos projets. L’information exhaustive, fiable, vérifiée et consensuelle ainsi recueillie est la matière première indispensable à la mise en œuvre de la meilleure solution possible en réponse à une nécessité de changement.

Il n’y a pas de secret : recueillir des informations de qualité demande beaucoup de pratique, de compétences professionnelles et de qualités inter- et intra-personnelles.

Et vous, quels sont vos petits secrets pour recueillir les besoins métier ? Partagez-les en commentaires.

Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!

Share on facebook
Share on twitter
Share on linkedin
Alice Svadchii
Alice Svadchii
Auteure du blog et Business Analyst enthousiaste

2 réflexions au sujet de « Réussir une séance de recueil des besoins [7 erreurs à éviter] »

  1. En informatique de gestion, on considère l’analyste métier comme étant le lien entre l’utilisateur final et le chef de projet ERP. Bien sûr les responsabilités peuvent différer d’une entreprise à l’autre, mais l’objectif principal est d’analyser, d’évaluer et d’affiner les processus pour faire correspondre les fonctionnalités de l’ERP avec la réalité de l’entreprise.

    A ce titre le recueil des besoins que vous évoquez dans l’article est indispensable pour anticiper les besoins, découvrir les domaines à améliorer avec la mise en place de l’outil informatique, développer et mettre en œuvre des solutions qui aident les utilisateurs au quotidien.

    Le recueil des besoins doit aussi aboutir à partager des idées et des résultats (et pas uniquement s’assurer que les solutions répondent aux besoins et aux exigences de l’entreprise). Servir de liaison entre les parties prenantes et les utilisateurs n’est pas toujours facile, dans mon activité de chef de projet ERP j’ai souvent vu des analystes métier pris entre deux feux. Vos conseils sont excellents.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *