Si la nécessité de la fonction d’analyste fonctionnel (functional analyst) est universellement reconnue dans la sphère IT, la fonction de business analyst est plus méconnue et la distinction entre les deux fonctions souvent mal comprise.

Je vais tenter ici de la clarifier. Bien entendu, dans le cadre d’un blog, je ne peux que survoler le sujet.

La vision dégagée ici est celle mise en place dans le cadre d’une institution de Sécurité Sociale occupée à refondre son système IT et qui a mis en place une équipe de 6 business analysts. Elle est donc propre à cette organisation.  Je suis actuellement responsable du coaching de cette équipe.

Tout d’abord, il convient d’insister sur le fait que ces deux fonctions doivent être vues comme étant des rôles, une même personne pouvant, selon la phase du ou des projets en cours, occuper tantôt un de ces deux rôles et tantôt l’autre. La taille de l’organisation et donc souvent, par voie de conséquences, l’étendue des domaines fonctionnels,  est évidemment déterminante quant à la distribution ou non de ces deux fonctions sur des personnes distinctes .

Mais en tous les cas, elles doivent veiller, selon moi, à ne porter qu’une seule de ces deux casquettes à un moment donné. La raison principale est que les deux rôles ont des publics cibles prioritaires  différents.

Dans le cadre d’un premier blog sur le sujet, intéressons-nous d’abord aux responsabilités et aux outils nécessaires au business analyst. Un second blog , à paraître plus tard, explicitera davantage la distinction entre les deux rôles.

Le business analyst est responsable:

• De travailler sur les business case avec le(s) chef(s) de projet
• Une fois un projet identifié, d’établir le scope document correspondant en collaboration avec le chef de projet désigné
• Sur ce point l’établissement d’un diagramme de contexte (context diagram) est un must.
• D’identifier et formaliser  les processus métiers à haut niveau de manière transverse, internes et externes (B2B), en ce compris les traitements des exceptions (!)
• L’un de ses outils privilégié sera donc un process modeler, idéalement basé sur le langage de formalisation BPMN (dont l’utilisation sera limitée aux fonctionnalités de base). Il devra être attentif à bien identifier/distinguer les sous-processus d’un processus principal, ce afin  de préserver une vue holistique permettant la maîtrise du tout par une approche drill-down (du général vers le détail).
• Au sein des processus et sous-processus il identifiera les tâches à accomplir (un processus n’est jamais qu’une succession de tâches), soit les high level use cases. L’identification de ces tâches lui permettra de découvrir la “matière première” des traitements  à effectuer, à savoir les données.
• Sur les tâches et les données, en tant que business analyst, son rôle se limite à établir une définition high level (comprenez sans excès de détails). Ainsi, il se doit :
  • D’établir le modèle de données conceptuel
  • D’établir un glossaire des termes métiers en vue de normaliser le vocabulaire employé lors des communications entre les différents acteurs (je reviens un peu plus loin sur ce point)
  • D’identifier les acteurs, rôles et responsabilités (indispensable pour la définition de la sécurité applicative)
  • D’identifier les évènements déclencheurs des processus, les données en entrée et en sortie, les règles métiers de transition entre les tâches
• De challenger les solutions actuelles et en particulier de relever toutes les possibilités de simplification – the business analyst must be a no added value killer (lean approach) !
• De relever les opportunités de réutilisation sur base de la connaissance métier (à l’inverse des architectes qui le font plutôt sur base de la connaissance des assets techniques).
• D’établir le glossaire métier en vue de mettre en place un vocabulaire partagé entre tous les acteurs – cette activité a toute son importance : à elle seule la non standardisation du vocabulaire employé dans les discussions peut être la cause  d’opportunités de réutilisation manquées. Et, faut-il le dire, de réunions inefficaces, suite à des incompréhensions dont le plus regrettable est qu’elles ne sont que rarement avouées (sur ce point, faut-il le dire, les responsables hiérarchiques ont un rôle d’exemple à jouer).
• D’alimenter le data dictionnary (cette activité est indissociable de la précédente) – le maintien d’un data dictionnary est à mes yeux une tâche essentielle des business analysts.
• De détecter les mesures à même d’augmenter la qualité et la cohérence des données (unicité).

Le business analyst joue un rôle clé en matière d’élaboration des scénarios de test : il est responsable de vérifier que les UATs (User Acceptance Tests) garantissent le bon alignement de la solution développée sur les besoins exprimés dans la  business analysis.

La formalisation des business process, des use cases et du modèle de données conceptuel requière idéalement un outil de design BPMN/UML accompagné d’un repository permettant la gestion de version et la centralisation de tous les artefacts produits. L’outil devra permettre la génération de documents Word sur base de templates customizables. Point d’attention : la facilité de mise en oeuvre de ces templates est fort variable d’un outil à l’autre – il  s’agit là d’un différentiateur important en termes de  productivité et d’efficacité dans la communication avec les autres parties.

Le business analyst doit être capable d’élaborer tout à la fois:

• D’une part, les documents nécessaires à la validation par les expert métiers : mind maps (très utiles à la capture et la première organisation des idées), documents Word agrémentés de schémas, présentations PowerPoint,  tableaux Excels, … bref une démarche que je qualifierai de “low tech”;
• D’autre part, les documents servant à préparer le travail du functional analyst – ceux-ci font un usage plus important du formalisme UML – la démarche sera ici de type “mid tech”.

Il convient d’insister sur la nécessité des échanges fréquents entre les business analysts travaillant sur des domaines fonctionnels différents. Les optimisations doivent en effet être globales et non pas locales aux domaines fonctionnels. Un rôle de coordinateur est à prévoir (espérer ne suffit pas – il faut provoquer ce que l’on veut obtenir).

Le business analyst se doit encore d’être :

• L’aiguillon du business pour entretenir une démarche de progrès permanent dans la maintenance des processus métier et des modèles de données ;
• L’avocat du business vi-à-vis de l’IT, par l’intermédiaire de l’enterprise architect et du(des) chef(s) de projet(s).

Enfin, le business analyst doit être le bibliothécaire de la connaissance métier : il est responsable de la qualité de la documentation métier et de sa bonne gestion. Il veillera donc à la fois à la standardisation et à la qualité des documents d’analyse, de même qu’à la standardisation et à la qualité de son organisation au sein d’un (ou de plusieurs) repository. La règle en or : un artefact quel qu’il soit doit être facilement localisable et interprétable par quiconque dans l’organisation.

Dans le cadre du processus RUP (que je me refuse personnellement à oublier malgré une forme de déferlante au tout à Scrum – les deux sont en fait complémentaires), le business analyst intervient donc en amont, sur les phases d’inception et d’elaboration.