Le rôle principal du Business Analyst, c’est de comprendre les besoins. Pour cela, il doit les faire émerger, les analyser et s’assurer qu’on a bien compris le problème avant de chercher à le résoudre.
Alors, une question me vient naturellement : si le besoin émerge du métier, pourquoi le Business Analyst passerait-il autant de temps loin du terrain ?
Imaginez un Business Analyst installé dans une tour de bureaux, à plusieurs kilomètres d’une usine. Il enchaîne les réunions Teams avec les équipes de production pour comprendre leurs problèmes, rédige des comptes rendus et documente des spécifications.
Mais comment peut-il réellement comprendre ce qui se passe dans cette usine s’il n’y a jamais mis les pieds ?
À un moment, il faut poser son ordinateur, enfiler ses chaussures de sécurité et sa blouse d’atelier, puis aller voir ce qui se passe sur place.
1. Un métier historiquement proche de l’informatique
Le Business Analyst est souvent rattaché à l’IT dans les organisations. Et finalement, ce n’est pas si étonnant.
Historiquement, le rôle s’est notamment développé dans les projets informatiques, où il fallait faire le lien entre les personnes qui exprimaient les besoins et celles qui concevaient les solutions. Les difficultés de compréhension entre ces deux mondes ont contribué à faire émerger cette fonction.
Mais il y a une citation que j’aime beaucoup : « La culture mange la stratégie au petit déjeuner »
Je trouve qu’elle s’applique particulièrement bien ici. Les organisations ont leurs habitudes, leur histoire et leur manière de concevoir les rôles. Même lorsque les besoins évoluent, il n’est pas toujours évident de remettre en question une organisation qui a fonctionné pendant des années.
Si le Business Analyst a longtemps été considéré comme un profil informatique, cette représentation peut perdurer, même lorsque son rôle nécessite d’être au plus près du métier.
Le Business Analyst devait comprendre les besoins métier et les rendre suffisamment clairs pour que les équipes techniques puissent travailler dessus.
Ce rattachement à l’informatique a donc une certaine logique. Je ne pense pas que ce soit une mauvaise chose en soi.
Le problème, c’est plutôt ce qu’on peut finir par associer à ce rattachement : l’idée que le Business Analyst est avant tout un profil informatique, qui doit passer son temps à recueillir des demandes, rédiger des spécifications et transmettre des informations aux développeurs.
Or, pour moi, le métier ne se limite absolument pas à ça.
Ce qui compte, ce n’est pas tant de savoir à quelle direction le Business Analyst est rattaché. C’est de savoir s’il peut réellement faire son travail : comprendre les problématiques métier, poser les bonnes questions et aller chercher l’information là où elle se trouve.
Si son rattachement à l’IT ne l’empêche pas de travailler au contact du métier, très bien. Mais si son organisation l’oblige à rester à distance de la réalité opérationnelle, il y a peut-être quelque chose à revoir.
2. Pour comprendre le métier, il faut aller sur le terrain
Prenons un exemple.
Une personne de la comptabilité explique que son logiciel est vieux, qu’il fonctionne mal et qu’elle aimerait en changer.
Le Business Analyst pourrait simplement recueillir cette demande, la documenter et la transmettre aux équipes informatiques.
Mais est-ce vraiment suffisant ?
Qu’est-ce qui ne fonctionne pas exactement ? Depuis quand ? Comment cette personne travaille-t-elle au quotidien ? Quelles sont les difficultés qu’elle rencontre ? Existe-t-il des contraintes ou des habitudes de travail qui expliquent la situation actuelle ?
Le Business Analyst doit chercher à comprendre tout cela. Il peut faire des entretiens, organiser des ateliers, consulter la documentation existante et observer les utilisateurs dans leur environnement de travail.
Et c’est justement cette dernière possibilité qui me semble particulièrement importante.
Je suis un grand adepte du télétravail. Je ne pense pas qu’il soit nécessaire de venir au bureau cinq jours par semaine pour faire du bon travail. En revanche, je pense que certaines activités du Business Analyst gagnent énormément à se dérouler sur le terrain.
Reprenons notre exemple de l’usine qui fabrique des yaourts.
Imaginons que le problème concerne deux machines qui n’arrivent pas à communiquer correctement entre elles, ce qui perturbe la production.
On peut évidemment organiser une réunion Teams pour en discuter. Les équipes vont expliquer le problème, partager des documents et essayer de décrire ce qui se passe.
Mais il y a une différence entre écouter quelqu’un expliquer son travail et voir comment il travaille réellement.
En allant sur place, le Business Analyst peut observer les opérations, comprendre les interactions entre les équipes et les machines, voir les difficultés rencontrées et poser des questions au moment où les problèmes se présentent.
Il peut aussi découvrir des choses que personne n’aurait pensé à lui expliquer pendant une réunion, simplement parce que les personnes concernées les considèrent comme normales.
C’est là que l’observation et la mise en situation prennent tout leur sens.
Le Business Analyst n’a pas besoin de connaître la fabrication des yaourts avant d’arriver dans l’usine. Il doit justement être capable de découvrir un métier qu’il ne connaît pas, de poser des questions et de comprendre progressivement son fonctionnement.
Et pour moi, c’est l’une des parties les plus intéressantes du métier.
3. Le Business Analyst doit pouvoir aller là où le besoin émerge
Cette proximité avec le terrain pose finalement une question d’organisation.
Si le Business Analyst est considéré uniquement comme une fonction informatique, est-ce qu’on lui donnera naturellement la possibilité de passer du temps dans les ateliers de production, dans les services comptables ou auprès des équipes commerciales ?
Est-ce que les métiers penseront spontanément à le solliciter ? Est-ce qu’ils le verront comme quelqu’un qui peut les aider à résoudre leurs problèmes, ou simplement comme un interlocuteur informatique auquel ils doivent transmettre leurs demandes ?
La culture d’entreprise joue ici un rôle important. On peut très bien afficher une stratégie qui place les besoins métier au centre des projets, mais continuer à fonctionner avec des habitudes qui éloignent les personnes chargées de les comprendre du terrain.
La bonne nouvelle, c’est que j’ai l’impression que les organisations évoluent et que le rôle du Business Analyst est de mieux en mieux compris.
Au fond, je ne suis pas convaincu qu’il faille nécessairement rattacher tous les Business Analysts au métier plutôt qu’à l’IT. Ce serait remplacer une règle systématique par une autre.
En revanche, je suis convaincu qu’un Business Analyst doit pouvoir se rapprocher du métier chaque fois que cela est nécessaire, sans que son organisation ou son rattachement hiérarchique devienne un frein.
Il doit pouvoir aller voir les personnes concernées, observer leur travail, participer à leurs échanges et comprendre leurs contraintes. Et cela peut parfois nécessiter de se déplacer physiquement, même si une partie importante du travail peut parfaitement être réalisée à distance.
L’objectif n’est pas d’être présent sur le terrain pour le principe. C’est de se donner les moyens de comprendre réellement le problème.
Conclusion : c’est aussi pour ça que je fais ce métier
Après plusieurs années comme Business Analyst, et après avoir moi-même travaillé comme développeur, je suis convaincu que rien ne remplace le contact avec les personnes qui connaissent le métier de l’intérieur.
Je ne connais pas la fabrication des yaourts. Je ne connais pas nécessairement les machines utilisées dans une usine, ni toutes les contraintes auxquelles les équipes de production doivent faire face.
Mais c’est justement ce qui rend le métier intéressant : découvrir des environnements que je ne connais pas, comprendre comment les personnes travaillent, identifier leurs difficultés et les aider à trouver des solutions adaptées.
Quand je descends dans un atelier de production et qu’on m’explique qu’une machine n’arrive pas à communiquer avec une autre, ce qui perturbe toute une partie de la production, j’ai envie de comprendre. Pourquoi cela arrive-t-il ? Comment les équipes gèrent-elles la situation aujourd’hui ? Quelles sont les conséquences ? Et surtout, comment peut-on améliorer les choses ?
C’est dans ces moments-là que je trouve le plus de sens à mon travail et que je pense apporter le plus de valeur à l’entreprise.
Je ne vois pas beaucoup d’intérêt à rester dans ma cave à faire des visioconférences toute la journée et à documenter des spécifications fonctionnelles et techniques sans jamais voir ce qui se passe réellement.
Ce qui m’intéresse, c’est d’aller au contact des gens, de découvrir leur métier et de contribuer à trouver des solutions qui correspondent à leurs besoins.
Pour moi, la proximité avec le métier n’est pas simplement une bonne pratique du Business Analyst. Elle fait partie du cœur même de son métier.
Sources
- Culture VS Stratégie https://pivotis-conseil.fr/pourquoi-la-culture-mange-la-strategie-au-petit-dejeuner-selon-peter-drucker/
- Gemba Walk https://www.lean.org/lexicon-terms/gemba-walk/
- Recherche contextuelle https://www.gov.uk/service-manual/user-research/contextual-research-and-observation#examples-and-case-studies
FAQ : la proximité du Business Analyst avec le métier
Pourquoi un Business Analyst doit-il être proche du métier ?
Le Business Analyst doit comprendre les besoins, les contraintes et les pratiques réelles des utilisateurs. Être proche du métier lui permet de mieux analyser les problématiques et de contribuer à des solutions adaptées à la réalité du terrain.
Quelles techniques permettent au Business Analyst de comprendre les besoins métier ?
Les entretiens, les ateliers de travail, l’analyse documentaire et l’observation sur le terrain sont des techniques couramment utilisées en Business Analysis. L’observation permet notamment de découvrir des difficultés et des pratiques que les utilisateurs ne pensent pas toujours à exprimer spontanément.
Le Business Analyst doit-il être rattaché à l’IT ou au métier ?
Il n’existe pas de rattachement organisationnel unique qui convienne à toutes les entreprises. L’essentiel est que le Business Analyst puisse travailler avec les équipes métier et informatiques, accéder au terrain et conserver la capacité d’analyser les besoins de manière objective.