Où s’arrête le rôle du Business Analyst (et où commence celui de l’équipe technique)

Voici une question intéressante que j’ai trouvée sur un forum, posée par Stephen M., Business Analyst dans une grande entreprise américaine :

Veuillez excuser ma naïveté. Mais j’ai du mal à comprendre l’étendue précise du périmètre du BA dans un projet. En tant que Business Analyst, je suis censé m’occuper du « Quoi » des exigences. Mais si dans un projet technique, il est nécessaire d’identifier un filtre de l’interface permettant d’éviter la duplication des résultats et des rapports, qui est responsable de cette identification ? Le BA ou l’architecte ?

Merci beaucoup pour votre aide !

Stephen M.

Dans cet article, je vais donc tenter de vous donner des pistes de réflexion pour identifier de la manière la plus précise votre rôle en tant que Business Analyst (BA).

En effet, même si la valeur ajoutée d’un BA est généralement à peu près bien comprise par la majorité des professionnels, pour d’autres son rôle demeure ambigu. Chaque organisation et chaque secteur d’activité étant relativement unique, les besoins et les attentes liés au rôle du Business Analyst peuvent considérablement varier. Cependant, ses compétences-clés, son cœur de métier, restent heureusement constantes.

Le but de cet article est de donner aux Business Analysts (surtout à ceux qui débutent dans le métier) une approche pour déterminer ce que leur organisation attend d’eux.

Voici donc les 4 étapes que vous pouvez suivre afin de définir votre rôle au sein de votre organisation.

1^ère étape : maîtriser le corpus de connaissance de l’analyse métier

J’enfonce peut-être une porte ouverte pour certains, mais pour la grande majorité des Business Analysts formée sur le tas, ce conseil n’est pas inutile.

En effet, contrairement aux développeurs ou aux chefs de projets informatiques qui bénéficient de formations nombreuses et exhaustives, avec diplômes et certifications à la clé, le Business Analyst francophone se forme souvent sur le tas. Il n’a souvent jamais appris les bonnes pratiques et les méthodologies, et a rarement connaissance de l’existence d’un corpus de connaissances décrivant son métier.

Il est vrai que cela commence doucement à changer, certaines (rares) écoles ou cursus universitaires proposant enfin des spécialisations en Business Analyse.

L’International Institute of Business Analysis (IIBA^®) a permis de faire des progrès significatifs dans la définition de la profession de BA grâce à son BABOK^® (Business Analysis Body Of Knowledge). Ce guide décrit les pratiques générales de l’analyse métier, et aide les BA à comprendre l’ensemble des activités et des compétences requises pour exercer leur rôle. L’IIBA^® est l’association historique de la Business Analyse ; cependant, d’autres schémas de certification ont émergé depuis 10 ans, amenant également dans leurs bagages leur propre corpus de connaissances.

Première recommandation : lisez-en un, imprégnez-vous du périmètre de l’analyse métier, de ses activités, livrables et bonnes pratiques.

Voir aussi: mes recommandations de lecture.

2^ème étape : prendre en compte l’organisation spécifique de l’entreprise

Le rôle d’un BA peut varier considérablement selon le secteur d’activité et l’organisation interne de l’entreprise dans laquelle il intervient.

Par exemple, les entreprises des secteurs industriels fortement réglementés (aérospatiale…) attendent de leurs Business Analysts une prise en compte des contraintes d’audit. Même chose pour des départements du type comptabilité ou finance, qui doivent se conformer aux législations nationales et internationales.

Un Business Analyst doit donc se familiariser avec l’organisation du travail découlant des contraintes internes et externes de l’entreprise. Il peut acquérir ces connaissances organisationnelles de plusieurs façons, par exemple :

• L’observation (du poste de travail) est une technique qui permet de s’approprier la manière dont l’utilisateur fonctionne dans le cadre de son environnement de travail réel. Idéalement, cet exercice d’observation devrait être effectué pour tous les contributeurs clés du projet.
• L’analyse systémique, c’est à dire la compréhension des liens et interactions entre les rôles et services de l’organisation. Les processus métiers sont bien entendu au centre de l’analyse, mais il faut répertorier également tous les éléments qui peuvent être impactés par / impacter le projet.

3^ème étape : recueillir les attentes liées à votre rôle de Business Analyst

Si vous êtes salarié, vous avez sans doute une fiche de poste qui décrit ce que l’Organisation attend de vous. C’est donc un bon point de départ.

Si vous être prestataire, le contrat décrit normalement, plus ou moins en détail, votre périmètre, vos missions et vos objectifs.

Néanmoins, les activités décrites ne correspondent pas toujours à ce que vous ferez au quotidien. Il vaut mieux dans ce cas discuter avec votre manager direct pour comprendre de quelle manière vous pouvez apporter de la valeur ajoutée à votre organisation.

Les membres de l’équipe de projet et de l’équipe technique sont une autre source précieuse d’information sur les attentes qu’ils peuvent avoir envers le Business Analyst. N’hésitez donc pas à leur demander les inputs dont ils ont besoin de votre part, et ce qui leur pose actuellement problème. J’ai déjà entendu des développeurs dire : « Les spécifications fonctionnelles détaillées, ça ne sert à rien. De toute façon, on doit tout refaire derrière ». Creusez-donc de toute urgence les besoins sous-jacents, plutôt que de reproduire aveuglément ce qui a été fait jusqu’à présent.

S’il y a d’autres Business Analysts dans votre organisation, n’hésitez pas à les impliquer, pour que tout le monde participe à un effort collectif de délimitation des rôles et responsabilités. C’est également primordial pour obtenir l’approbation et l’adhésion de votre hiérarchie et de vos collègues.

Bien entendu, ne confondez pas la collecte des attentes avec une liste au Père Noël à respecter à la lettre. Il s’agit simplement d’un effort pour comprendre les besoins, échanger sur les périmètres respectifs, et arriver à un consensus qui permette d’apporter de la valeur à l’organisation.

4^ème étape : exploiter le retour d’expérience (« lessons learnt »)

Malheureusement, le Retour d’Expérience (RetEx) est l’une des techniques les moins utilisées. Alors bien sûr, de nombreuses entreprises organisent des séances ayant pour objectif de tirer des leçons d’un projet terminé. Mais combien sont-elles à s’y référer ultérieurement ? Objectivement, très peu.

C’est vraiment dommage, car l’utilisation efficace des « lessons learnt », et la manière dont la correction des problèmes a été réalisée, permet d’économiser du temps et de l’argent en évitant de répéter indéfiniment les erreurs commises.

En tant que Business Analyst, sachez tirer profit du RetEx. N’hésitez pas à demander et à lire attentivement la documentation existante. Selon les entreprises, l’accès à cette documentation varie beaucoup. Certaines organisations sont en effet très structurées autour de bases de connaissances, et il vous sera facile d’obtenir des informations écrites. Pour d’autres, cela peut dépendre de bonnes volontés ponctuelles et individuelles, avec des documents stockés sur des espaces aux droits restreints, dans le répertoire du projet terminé, voire même uniquement « dans la tête » du Chef de Projet.

Et ensuite ?

Une fois que vous aurez pris connaissance des bonnes pratiques du Business Analyst (lu le BABOK^® ou tout autre corpus de connaissances), compris l’organisation de l’entreprise et ses contraintes internes et externes, identifié les attentes de votre manager et de vos collègues liées au rôle de Business Analyst, et examiné le retour d’expérience tiré des projets antérieurs, vous serez prêt à analyser votre rôle dans le contexte de votre organisation et du projet sur lequel vous travaillez.

N’hésitez pas à synthétiser, valider auprès de votre manager ou de votre client, puis à diffuser la définition de votre périmètre et de vos responsabilités. Car, de même qu’un Business Analyst doit identifier les rôles et responsabilités des contributeurs et les acteurs avec lesquels il va travailler, il est important que son propre rôle et ses responsabilités soient comprises sans ambiguïté par tous (et pas uniquement par lui-même…).

Que répondre à Stephen ?

Pour en revenir avec la question posée par Stephen en début d’article, que pourrions-nous donc lui répondre ?

• Tout d’abord, qu’un BA a comme responsabilité de décrire les fonctionnalités de manière exhaustive, claire et non ambiguë. Il s’agit d’un aspect fondamental et constant de la valeur ajoutée d’un Business Analyst.
• Partant de là, Stephen vérifiera si le système cible doit être conforme à des règles d’organisation et à des contraintes externes. Par exemple, respecter des règles comptables ou de consolidation financière. Cela se fait dans une démarche globale d’élicitation des règles métier. Peut-être que le fait de pouvoir filtrer ses données de manière à exclure les doublons en est une – à la lecture de sa question, difficile de trancher.
• Stephen doit également être conscient de son rôle au sein de l’équipe projet ou du département. Qui sont les autres acteurs qui utiliseront ses analyses et ses spécifications fonctionnelles détaillées ? Il pourrait par exemple discuter avec le leader technique, l’architecte, les développeurs, pour comprendre les limites et les contraintes de l’outil (admettons qu’il s’agit d’une solution de Business Intelligence pre-packagée à configurer). Quoi qu’il en soit, s’il pense que le moindre risque d’ambiguïté subsiste, il doit la lever explicitement. Il ne s’agit bien entendu pas de décrire la solution technique, mais de définir la règle de gestion. Notez cependant que dans le cas d’un projet de BI ou d’ERP, le Business Analyst a une compétence technico-fonctionnelle. Il a été formé sur la solution d’éditeur choisie, et si les filtres font partie de la configuration, il décrira clairement comment doit fonctionner le filtre en question.
• Enfin, si Stephen a la chance de disposer d’une base de connaissances des « lessons learnt », il pourra aussi compléter sa compréhension sur le niveau de détail attendu par les équipes techniques et être alerté sur les erreurs commises sur des projets similaires, pour éviter de les commettre à son tour.

Et vous, avez-vous déjà eu à gérer des problèmes liés à la limite floue et ambiguë de votre périmètre de Business Analyst ? N’hésitez pas à partager votre expérience en commentaire 😊.