les enjeux de la business analysis, le rôle du business analyst

Qu’est-ce qu’un business analyst ?

Il n’y a pas si longtemps, j’avais quelques difficultés à faire comprendre, et ce, même dans le milieu professionnel, les tenants et les aboutissants de mon métier de Business Analyst. Ma grand-mère, par exemple, est persuadée, du fait de mes études, que je suis informaticien, jusque-là, tout va bien, mais elle pense aussi qu’un informaticien branche des claviers, des écrans et des souris, et là forcement elle n’est plus dans le vrai. J’ai donc décidé de mettre en ordre quelques idées, avec l’objectif premier de faire comprendre à ma grand-mère en quoi consistait mon job. Et pourquoi pas, pour aller plus loin, comprendre les enjeux du positionnement d’un business analyst dans une organisation, quoique sur le second point, je ne suis pas certain que ça intéresse beaucoup mon aïeule, mais peut être le lecteur éclairé de cet article.

L’activité de business analyst, avec quelques explications bien choisies, n’est pourtant pas si compliquée à appréhender. Je vous propose donc une série d’articles concernant la business analysis, afin d’y voir un peu plus clair et de répondre aux questions concernant la business analysis et le rôle du business analyst. Je vous invite dans un premier temps à faire un saut dans le passé pour mettre en avant les aspects historique du métier qui nous aideront à le positionner dans ses activités actuelles ; puis, dans un second temps, nous découvrirons les domaines de compétences, d’activités,  ainsi que les enjeux de la business analysis.

En France, tout du moins, l’expression de « business analyst », qui nous vient d’outre atlantique, est souvent substituée par « assistant à maîtrise d’ouvrage ». A titre personnel, je trouve qu’il manque le côté « business » dans l’expression française, l’International Institute of Business Analysis (IIBA) utilise l’expression « d’analyste d’affaires », qui met en avant la création de valeur ajoutée, nous reviendrons sur l’IIBA un peu plus tard dans l’article. La traduction mot pour mot de business en affaires est bien entendu valable, je préfère cependant une variante qui serait « analyse métier », car c’est bien auprès des métiers de l’organisation que travaille le business analyst. Nous aborderons plus tard les termes synonymes de business analyst, ou assistant à maîtrise d’ouvrage, pour le moment, faisons un retour dans le passé.

Rappels sémantiques

Historiquement, la maîtrise d’ouvrage (ou MOA), tout comme la maîtrise d’œuvre (ou MOE), sont des termes issus du domaine de la construction.

L’ouvrage, i.e. le produit fini :

  • Répond à aux exigences du maître d’ouvrage
  • Est financé par le maître d’ouvrage
  • Est réalisé pour le maître d’ouvrage
  • Est réalisé par le maître d’œuvre

 
 

Quid de l’assistance à maîtrise d’ouvrage dans ce cas de figure ? De prime abord, il ne semble pas nécessaire d’ajouter un nouvel acteur dans ce schéma, et pourtant, à  l’aide d’un exemple nous allons illustrer l’intérêt de positionner un intermédiaire entre nos deux parties prenantes.

Une explication par l’exemple

Continuons dans le domaine de la construction, nous souhaitons faire construire une habitation pour nous loger ce qui nous positionne dans le rôle de maîtrise d’ouvrage. Nous choisissons donc de faire construire une maison, dans laquelle nous pouvons vivre, dormir, manger. Pouvons-nous lancer la construction de la maison avec de telles exigences ? Rien n’est moins sûr. Concernant l’habitation, sommes-nous réellement capables d’exprimer ce dont nous avons réellement besoin, et sommes-nous certains que ce qui est – pour nous – implicite le sera pour celui qui va réaliser l’ouvrage ?

D’autre part, d’un point de vue technique, sommes-nous à même de trancher sur le meilleur choix de matériaux pour les murs, les cloisons, la toiture ? Ou encore sur la manière dont tous les éléments seront assemblés pour faire le produit fini ?

 

Possédons-nous donc ces compétences ?

  • Oui, mais disposons-nous du temps de formaliser nos besoins et choix techniques ?
  • Non, disposons-nous du temps pour les acquérir ?

 

Sans dire que nous soyons incapables d’exprimer ce dont nous avons besoin, ou incapables de trancher entre l’utilisation de briques, de ciment ou de parpaings, nous nous posons tout de même les questions suivantes :

  • Quelles tâches nous sommes à même de prendre en charge nous-même ?
  • Lesquelles nous souhaitons voir réalisées par un tiers et pourquoi ?

 

Forts de nos interrogations, pourquoi choisissons nous de faire appel à un architecte ? Non seulement, l’architecte va comprendre nos besoins réels, ainsi que ceux que nous n’avons pas su exprimer, ceux que nous avons mal exprimés, ceux qui nous semblent implicites. De plus il est capable de formaliser les exigences de façon à les rendre intelligibles par le maître d’œuvre, via la réalisation de plans par exemple. Dans les faits, l’architecte peut traduire « Nous voulons un salon très lumineux » par une pièce exposée au sud avec de grandes fenêtres, alors le maître d’œuvre aurait pu réaliser, en répondant parfaitement à nos exigences, une grande pièce en sous-sol avec de puissants éclairages…

L’architecte, grâce à ses compétences et son expérience, apporte des solutions nouvelles ou éprouvées à la maîtrise d’ouvrage (il peut les formaliser avec une vue d’ensemble de la maison, une maquette) qui doit les comprendre, se les approprier et les valider. Ensuite l’architecte donne à ces exigences un formalisme intelligible à la maîtrise d’œuvre (un plan). Ceci est un exemple de ce que peut apporter une assistance à maîtrise d’ouvrage, ici représentée par un architecte, aidant aux choix de la maîtrise d’ouvrage, la guidant à travers l’expression de ses besoins, mais bien entendu les rôles d’assistant à maîtrise d’ouvrage ne se bornent pas seulement à de la traduction d’exigences.

 

Dorénavant, pour expliquer à ma grand-mère ce qu’est mon travail, je lui dis que j’aide les autres à travailler efficacement ensemble, je suis un facilitateur. Et bien qu’ayant suivi un cursus en informatique, je m’intéresse essentiellement aux problèmes non informatiques des différentes entités d’une organisation. Je m’intéresse à leurs objectifs et j’aide à faire en sorte que l’outil informatique permette de les atteindre. Maintenant que le degré de compréhension de mamie est suffisant pour la satisfaire, je vous propose de continuer, simplement entre nous, notre histoire de la business analysis.

Repères historiques

En 2003, à Toronto, création de l’l’International Institute of Business Analysis, dont l’objectif principal est de créer et développer la sensibilisation à la valeur et à la contribution de la business analysis. Pour ce faire, l’IIBA définit l’ensemble des connaissances et techniques nécessaires à l’activité de business analysis.

En 2005, l’IIBA publie la première version de son guide « Business Analyst Book Of Knowledge », autrement connu sous le nom de BABOK.

La première version est une ébauche du corpus de connaissance, qui sera vite remplacée par la V1.6, puis en 2009 par l’édition du guide BABOK V2.0, présente les domaines de compétences et les 34 techniques nécessaires à l’activité de business analysis.

En 2012, le guide BABOK V2.0 est édité en français.

En 2014 (octobre), doit paraître la V3.0, affaire à suivre…

 

Qu’est-ce que le BABOK ?

Le Guide du corpus de connaissances de l’analyse d’affaires est un ouvrage qui définit l’analyse d’affaires (d’entreprise ou métier) comme une discipline à part entière. Rédigé et approuvé par des analystes reconnus (plus de 5500 relecteurs pour la V3.0), le BABOK s’appuie sur les pratiques couramment et actuellement utilisée par les analystes. Il présente, répartis en 7 domaines de connaissances et 34 techniques, les différents domaines d’intervention de l’analyste, ainsi que ses activités et les tâches y afférentes.

Il est nécessaire de bien comprendre que le BABOK ne doit pas être positionné comme une méthode ou un manuel pour réaliser une analyse, mais comme un recueil de connaissances qui peuvent – doivent – servir de base à notre activité.

Bien que trivial, l’exemple de l’architecte met en évidence les limites du modèle d’interactions directes entre maîtrise d’ouvrage et maîtrise d’œuvre. Concrètement, dans les projets concernant la mise en place de solutions organisées autour des systèmes d’informations,  le taux de défaut est élevé de l’ordre de 61% (i.e. : projets en échec ou hors délais ou hors budget, source IIBA France Conférence Juillet 2012). Il est à noter que les projets à cycle en V sont plus concernés que les projets gérés en agile. 70% de ces défauts sont dus à un mauvais recueil, une mauvaise analyse ou à une mauvaise gestion des exigences.

 

Les enjeux de la business analysis

Les enjeux de l’utilisation de business analysis dans les projets sont de 3 niveaux :

  • Fiabilisation des exigences métier via
    • Des connaissances métier, sectorielle
    • Des compétences d’analyses
  • Facilitation des échanges entre parties prenantes via
    • Des compétences SI
    • Des compétences humaines
  • Minimisation des risques de défaut, qu’ils soient d’ordre budgétaire, fonctionnel ou de délais

 

A venir…

J’espère que dorénavant, vous avez une idée plus claire de ce qu’est la business analysis, au moins en ce qui concerne son domaine d’activité et les enjeux à l’employer. Je propose dans un second article de vous présenter le business analyst, par ses compétences et savoirs faire.

Commentaires

  1. Malheureusement souvent des candidats sont recrutés et en lieu de BA, leur activité est du codage SQL ou autre techno, sans qu’ils ne rencontrent les clients/utilisateurs.

    Et la BA est bien loin de la techno si l’on veut rentrer dans le métier du client et parler son langage.

    1. Bonjour Pascal,

      Si le recrutement d’un BA le conduit à ne faire que du SQL ou du développement, c’est que le poste était celui d’un développeur 😉

      Au-delà de cette réponse quelque peu triviale, s’il existe encore ce type d’erreurs de casting, elles sont sans doute dû au fait que la business analysis est une activité perçue différemment par encore trop de personnes, qu’ils soient clients, recruteurs, et même consultants…

      Voyons cela comme une opportunité de montrer la valeur ajoutée de notre métier, ainsi, commençons dès le premier entretien afin d’éviter les situations comme celles que vous décrivez.

      Arnaud

  2. Très belles illustrations je suis beaucoup mieux renseigné. Ce domaine m’intéresse mais j’appréhende un peu car je suis gestionnaire (Marketer) à la base, sans notions en codage ou développement. Me conseilleriez vous de m’y engager?

Laisser un commentaire

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

Voir plus
scroll to top