Quand on parle de Business Analysis, on pense souvent aux besoins, aux exigences, aux User Stories ou encore aux spécifications fonctionnelles.
Mais avant de commencer à rédiger tout ça, il y a une question que je pose très souvent :
Dans quel processus s’inscrit le besoin de changement ?
Cette question peut sembler simple, mais elle permet de remettre le besoin dans son contexte. Et surtout, elle nous oblige à comprendre comment les choses fonctionnent réellement avant de chercher à les modifier.
Un processus, c’est quoi exactement ?
Pour faire simple, un processus, c’est une suite d’étapes qui permet d’atteindre un objectif.
On part d’une situation, on réalise différentes activités, plusieurs personnes peuvent intervenir et, à la fin, on obtient un résultat.
Dans le cadre de la Business Analysis, l’analyse de processus consiste à comprendre et représenter cet enchaînement d’activités : qui fait quoi, dans quel ordre, avec quelles informations et dans quel objectif.
Pour représenter un processus, il existe différentes méthodes. BPMN (Business Process Model and Notation) est notamment une notation couramment utilisée pour modéliser les processus métier.
Mais pour moi, le plus important n’est pas de savoir dessiner un diagramme parfaitement conforme à une notation. C’est de représenter le processus de manière compréhensible et adaptée aux personnes qui vont l’utiliser.
Un diagramme peut être très propre et pourtant ne pas représenter correctement la réalité. Et c’est là que le travail du Business Analyst commence vraiment.
Comprendre l’existant avant de vouloir le changer
Le Business Analyst est là pour comprendre le besoin et contribuer au changement. Pour cela, il doit comprendre les activités des parties prenantes et la manière dont elles s’articulent.
Quand j’analyse un besoin, j’essaie donc de comprendre le processus actuel, ce qu’on appelle souvent l’AS-IS. Une fois cette compréhension établie, on peut réfléchir au processus cible, le TO-BE, et identifier les améliorations possibles.
Pourquoi procéder dans cet ordre ?
Parce qu’on ne peut pas améliorer quelque chose qu’on ne comprend pas.
Un utilisateur peut nous demander de modifier un logiciel parce qu’il ne fonctionne plus correctement ou parce qu’il ne répond plus à ses besoins. Mais le problème vient-il vraiment du logiciel ? Est-ce lié à une étape du processus, à une responsabilité mal définie, à une information qui arrive trop tard ou à une dépendance avec un autre service ?
Sans analyser le processus, on risque de se concentrer directement sur la solution demandée sans avoir compris le problème dans son ensemble.
L’analyse permet justement de prendre du recul, de repérer les points de blocage et de comprendre les conséquences d’un changement sur les autres activités.
Un processus ne se résume pas à la vision d’une seule personne
J’ai rencontré ce cas dans un contexte industriel.
En analysant un processus, un interlocuteur du département Qualité m’explique que le processus commence au moment du « feu vert Qualité ».
Je commence donc à représenter le processus à partir de cette information.
Mais comme pour tout processus, il faut ensuite faire valider le schéma par les différentes parties prenantes.
C’est à ce moment-là que je découvre que le feu vert Qualité n’est qu’une partie du dispositif. En réalité, le feu vert global repose sur trois validations, impliquant trois interlocuteurs différents.
Mon premier schéma était donc incomplet.
L’utilisateur ne m’avait pas menti. Il m’avait expliqué ce qu’il connaissait et ce qui relevait de son périmètre. Mais il n’avait pas nécessairement une vision complète du processus dans son ensemble.
C’est précisément pour cette raison qu’il faut confronter les points de vue et valider le processus avec les personnes concernées. On ne peut pas simplement prendre ce qu’une personne nous raconte et le retranscrire dans un diagramme en considérant que le travail est terminé.
Un processus bien dessiné n’est pas forcément un processus juste.
Et c’est un point important : le Business Analyst ne connaît pas nécessairement le quotidien des personnes qu’il rencontre. Il doit donc laisser ses a priori de côté, poser des questions et chercher à comprendre avant de tirer des conclusions.
J’aime bien l’idée de la feuille blanche : arriver avec une première compréhension du sujet, mais sans supposer que l’on sait déjà comment les choses fonctionnent.
Même lorsqu’on a de l’expérience ou qu’on connaît un secteur d’activité, chaque organisation a ses particularités. Il faut rester ouvert à ce que les utilisateurs nous apprennent, y compris lorsque cela remet en question notre première représentation.
Un processus juste, c’est quoi ?
Pour moi, un processus juste est avant tout un processus qui représente suffisamment bien la réalité qu’on cherche à comprendre, ou la réalité future qu’on souhaite mettre en place.
Et il doit être adapté à son public.
Un diagramme destiné à une direction n’a pas nécessairement besoin du même niveau de détail qu’un diagramme utilisé par une équipe technique pour implémenter une solution.
De la même manière, il existe différentes façons de représenter un processus. Si l’entreprise dispose déjà de conventions, il faut évidemment en tenir compte. Sinon, BPMN est une option intéressante à connaître.
Mais il ne faut pas perdre de vue l’objectif : permettre aux personnes concernées de comprendre les activités, leur enchaînement et les points qui méritent d’être discutés.
L’objectif n’est pas de produire le diagramme le plus détaillé possible. C’est de produire une représentation utile.
Et cette représentation peut évoluer au fil de l’analyse. Le premier schéma ne sera pas le bon. C’est justement en posant des questions, en confrontant les informations et en faisant valider le résultat qu’on améliore notre compréhension.
Et lorsqu’aucun processus n’existe ?
C’est un conseil très personnel : lorsqu’aucun processus n’existe ou n’est décrit, je considère que c’est un red flag.
Pas parce qu’il y a nécessairement un problème. L’absence de documentation ne signifie pas automatiquement que l’organisation fonctionne mal.
Mais cela peut vouloir dire que les activités n’ont jamais été formalisées, que les responsabilités ne sont pas clairement partagées ou que certaines questions d’organisation n’ont jamais été posées collectivement.
Qui intervient réellement dans cette activité ? Qui est responsable de quoi ? Tout le monde a-t-il la même compréhension du fonctionnement ? Certaines étapes existent-elles simplement parce qu’elles ont toujours été faites ainsi ?
Ce sont autant de questions que le Business Analyst peut soulever.
L’absence de processus décrit n’est donc pas seulement un manque de documentation à combler. C’est aussi un point d’attention qui peut révéler des choses intéressantes sur le fonctionnement de l’organisation.
Ce qu’il faut retenir
L’analyse de processus est au cœur du métier de Business Analyst. Notre rôle est de comprendre les besoins et d’accompagner le changement. Pour y parvenir, nous devons comprendre comment les activités se déroulent réellement et comment les parties prenantes travaillent ensemble.
Cela demande de laisser ses a priori de côté, d’écouter les personnes concernées et de ne pas prendre une première explication pour une vérité complète.
Il faut aussi accepter qu’un processus ne soit jamais représenté de manière parfaitement universelle. Le bon niveau de détail dépend de l’objectif et du public. Ce qui compte, c’est que la représentation soit suffisamment juste et compréhensible pour être utile.
Enfin, tout cela s’apprend avec le temps et l’expérience. Une heure d’entretien avec un utilisateur ne suffit pas à comprendre un processus. Il faut observer, rencontrer plusieurs interlocuteurs, confronter les points de vue, corriger son schéma et le faire valider.