Le Business Analyst assure l’interface entre le service informatique et les services opérationnels. Découvrez tout ce qu’il faut savoir sur ce métier
C'est quoi un Business Analyst ?
Un Business Analyst est ce que l’on peut aussi appeler un AMOA (Assistant à Maitrise d’Ouvrage), qui va s’assurer que les processus métier s’intègrent bien au système d’information.
Il a donc un métier hybride avec d’un côté la compréhension du métier et de ses enjeux ; et de l’autre la retranscription en objectif techniques de ces mêmes enjeux auprès du service informatique.
Quel est le rôle d'un Business Analyst ?
Le rôle du business Analyst est de servir de lien entre, d’un côté le métier, de l’autre les équipes de développement ou l’éditeur de logiciel.
Le business Analyst se doit d’être force de proposition que ce soit auprès du métier ou auprès des équipes de développement.
Il peut aussi assister le Product Owner du fait de son expertise métier et technique dans la priorisation des besoins et les choix d’architecture.
Quelles sont les missions d'un Business Analyst ?
Recueil du besoin
Si vous vous engagez dans une carrière de Business Analyst, l’une des premières phases de votre travail consistera à recueillir le besoin auprès du client.
Il vous faudra pour cela organiser des réunions en précisant à chaque fois le ou les sujets qui seront à aborder. Vous devrez inviter les bons interlocuteurs, animer la réunion, puis réaliser un compte rendu qui retranscrira les décisions et les questions en suspens qu’il faudra aborder dans de futures réunions.
Ce travail nécessitera donc plusieurs échanges, soit en réunion, soit de façon plus informelle par mail pour se faire préciser certains points techniques.
Lors de vos échanges il est important de ne pas se contenter de ce que vous racontera l’utilisateur :
- Demandez-lui s’il dispose d’un support décrivant ses processus métiers actuels
- N’hésitez pas à lui poser des questions afin d’aller au bout des choses. Certains faits pourront sembler des évidences à votre client, qui les omettra dans ses explications.
- N’hésitez pas à préparer votre questionnaire en amont des échanges en suivant une trame similaire :
1. Qui : Quels sont les utilisateurs, leurs profils, …
2. Que : Que viennent chercher les différents utilisateurs ?
3. Quoi : Détailler les règles de calculs, …
4. Où : Ou doit se retrouver l’information ?
5. Quand : Quand l’information dit-elle être mise à disposition ?
6. Comment : Le format, le support, …
Rédaction des spécifications et des Users Stories
Une fois cette phase de recueil du besoin réalisé il vous faudra retranscrire cela dans un format qui pourra être utilisé par vos équipes.
Dans un Cycle en V on pourra utiliser comme support :
- Un Cahier des charges,
- Des Spécifications fonctionnelles par grandes thématiques.
Dans une organisation en agilité, vous rédigerez plutôt vos spécifications sous ce format :
- Une EPIC
- Des User story associées à cette EPIC
Puis des tâches que vous pourrez attribuer à vos équipes de développement.
Attention, travailler en agilité ne signifie pas ne pas tenir de documentation à jour. Il reste pertinent de tenir des spécifications centralisées à jours par EPIC. A ces documents, la création d’un schéma d’architecture global propre à votre applicatif métier est un plus non négligeable.
Rédaction des tests fonctionnels
Lorsque les livrables auront été mis à disposition par les équipes de développement, il vous faudra tester ceux-ci. Ces tests, s’ils peuvent être réalisés par des équipes dédiés à cette tâche sont néanmoins souvent réalisés par le Business Analyst.
La rédaction des cas de test pourra se faire dans des outils dédiées (SQASH TM, HP ALM, XRAY sous jira, …). Cela vous permettra de cataloguer vos tests afin de les rejouer plus facilement.
On distinguera souvent deux phases dans les tests :
- Tests des nouvelles fonctionnalités
- Tests de non-régression sur tout ou partie de l’applicatif
Dans certaines organisations il pourra vous être demandé de participer à la mise en place de tests automatisés avec une ressource dédiée à leur développement.
Assistance auprès des utilisateurs
Une fois le livrable mis à disposition de votre client, il vous faudra dans un premier temps le former sur l’outil et expliquer au client les éventuels changements en termes de processus induits par cette livraison.
Dans les premières semaines suivant la mise à disposition des livrables, cette assistance pourra aussi prendre la forme d’une phase de support afin de suivre au mieux les corrections d’éventuelles anomalies et guider les utilisateurs dans l’utilisation de l’outil.
Par la suite vous pourrez transmettre cette tâche à des équipes support dédiées.
Comment devenir Business Analyst ?
Il est recommandé d’avoir effectué un Master/maitrise (Bac +5) en système d’information et idéalement avec une spécialisation sur un domaine métier dans le cadre de son cursus ou d’un stage de fin d’étude.
Vous pouvez aussi devenir business Analyste après une première expérience en tant que développeur / intégrateur de progiciel. Vous aurez ainsi déjà acquis les connaissances du métier pour lequel vous allez ensuite analyser le besoin.
Quelles qualités pour devenir Business Analyst ?
- Être à l’écoute du client : pour prendre en compte les différents besoins exprimés par le client ainsi que les problèmes qu’ils peuvent rencontrer au quotidien dans l’utilisation des outils. Le Business Analyst doit donc savoir prendre du recul dans ses échanges avec le métier.
- Esprit de synthèse : le Business analyst doit donner forme aux besoins exprimés par le client qui ne sont pas nécessairement structurés. Dans ses échanges il se doit d’être force de propositions et de poser plus de questions techniques afin de bien identifier les règles de gestions qui ne seront pas forcément transmises par le métier (Absence de documentation, culture orale, …).
- Savoir prioriser : conscient des capacités des équipes de développement ou de l’éditeur/intégrateur, le Business Analyst doit définir avec le Product Owner les priorités en termes de développement et prioriser lui-même les sujets qu’il a à traiter en fonction de l’impact/volumétrie métier.
- Connaissance techniques et d’architecture : le Business Analyst, s’il n’est pas développeur doit idéalement avoir quelques connaissances techniques pour spécifier le besoin auprès des équipes de développement et comprendre leurs contraintes. Le Business Analyst doit aussi intégrer le schéma d’architecture global de son périmètre afin de connaitre quel logiciel est maitre sur la donnée et comment faire évoluer le SI sans le complexifier et perdre en efficience. Cela lui permettra aussi de mieux analyser les éventuelles anomalies remontées par le métier afin de demander des corrections aux bons interlocuteurs.
Quel est le salaire d'un Business Analyst ?
Le salaire d’un Business Analyst va évoluer au fil de sa carrière et en fonction de sa région.
En France vous pourrez prétendre selon votre expérience à un salaire brut annuel de :
- Débutant : 34K à 38 K
- Confirmé (3 à 7 ans d’expérience) : 39K à 46K
- Expert (7 ans et +) : 47K et +
Comptez sur une majoration à cette fourchette de rémunération dans certaines régions « tendues » (Ile de France, Lyon, Nantes, Annecy, …)
Différence entre un Business Analyst et un Data analyst
Business Analyst
Le Business Analyst travaille directement avec les équipes métier. Il a donc une approche plus « terrain » pour optimiser les processus métier.
Data Analyst
Le Data analyst va recueillir/structurer puis étudier les données existantes pour en extraire des tendances et des chiffres. Il utilisera souvent un ou plusieurs outils de Business Intelligence (Talend, Power BI, …)
Les deux métiers peuvent néanmoins être amenés à travailler ensemble afin de structurer sous forme de tableaux de bord/d’indicateur les données demandées par le métier selon les besoins spécifiés par le business Analyst. En résumé le Data Analyst aura des connaissances en développement plus marqué que le Business Analyst ainsi que de bonnes connaissances en mathématique.
Business Analyst : les évolutions de carrière possibles
- Devenir un Business Analyst Expert dans son domaine métier :
Le business analyste peut tout à fait choisir de se spécialiser dans un domaine/secteur d’activité précis (Banque, mutuelle, SIRH, …) afin de faire profiter son expertise à ses clients.
- Devenir Business Analyst sur un autre domaine métier :
Il peut être intéressant pour un business Analyste de changer de domaine métier afin de diversifier ses compétences et d’avoir par la suite plus de choix dans ses missions. Cela lui permettra de découvrir d’autres organisations /façon de travailler.
- Devenir Product Owner :
Grâce à votre proximité avec le Product Owner, vous allez acquérir au fil des années la connaissance et l’expérience nécessaire pour occuper ce poste.
- Devenir Chef de projet :
Ce rôle peut s’apparenter à celui de PO, mais peut aussi avoir sa place côté Client afin de centraliser les demandes d’un service ou encore sur un projet de grande envergure dont certains sujets et leur coordination dépasse le périmètre du Product Owner. Cette opportunité peut s’offrir à vous après de nombreuses années d’expérience et votre participation avec succès à plusieurs projets menés de bout en bout.
- Devenir Scrum Master :
Vous avez l’âme d’un manager ? Vous connaissez par votre expérience l’ensemble des processus Agile, Kanban, … ? Alors pourquoi ne pas tenter l’aventure et faire ressortir le meilleur de vos équipes ?
