Business analyst definition

http://www.latribune.fr/opinions/tribunes/20130919trib00078...

OPINIONS

17

Business Analyst, le métier que vos parents
ne comprennent pas

Daniel Tourre. DR
inShare31

Tweet

21

J’aime

82

2

2

Daniel Tourre | 19/09/2013, 15:21 - 2168 mots

Business analyst, c'est le métier qui est à la mode dans le monde de la finance. Daniel
Tourre, qui l'exerce pour les banques de marchés, explique en quoi consiste cette fonction
qui est en train de prendre une part prépondérante dans les activités du financement et de
l'investissement du secteur bancaire.
Vous êtes business analyst pour les banques de financement et
d'investissement. Lors d'un apéritif avec de nouvelles
connaissances, la question traditionnelle surgit : "Et vous ?
Qu'est ce que vous faites ?". Vous vous crispez un peu, votre
métier est une énigme pour 90% de vos relations. Vous
marquez tout de même un temps d'arrêt en essayant d'évaluer
si votre interlocuteur a une chance, même faible, de
comprendre "ce que vous faites" sans un discours de 10
minutes qui vous donnera le statut du type le plus ennuyeux de
la soirée.
La tentation de botter en touche avec une définition vague mais
compréhensible
est
forte
:
"Je
travaille
dans

SUR LE MÊME SUJET
Marchés de dérivés de
gré à gré : une
réglementation claire en
théorie, floue en pratique
Produits dérivés : une
règlementation "à la carte"
Quels sont les meilleurs
produits dérivés pour se
couvrir contre le risque?
La Deutsche Bank aurait
dissimulé des milliards de
pertes sur des dérivés de
crédit


l'informatique bancaire". Finalement, vous prenez le risque et dites :

" Je suis business analyst pour les banques de financement et d'investissement ".
Votre interlocuteur se contracte, plisse légèrement les yeux avec le petit sourire forcé de celui qui
n'a pas compris mais ne veut pas passer pour un imbécile. C'est le moment où vous regrettez
de ne pas être pompier, policier ou instituteur, enfin un de ces métiers que tout le monde
comprend du premier coup, qui ont déjà fait l'objet de cinq séries télé. Vous tentez de soulager
votre interlocuteur:
"En fait, je suis un peu l'interface entre les opérationnels dans une banque, les informaticiens et
l'encadrement pour les projets initiés afin de répondre à des changements ….".
Le sourire se force davantage. Votre interlocuteur craint déjà de passer un quart d'heure
ennuyeux au milieu d'une soirée amusante. Pour le soulager vous enchainez immédiatement
"enfin bref, je travaille dans l'informatique bancaire" et passez vite à autre chose.

Un métier en pleine structuration
Votre interlocuteur avait tort de se contracter, on peut ignorer ce que veut dire business analyst
sans être un imbécile. C'est un métier qui commence seulement à gagner une existence
officielle, même s'il a été pratiqué depuis que les entreprises existent - comme Jourdain faisait


de la prose, sans le savoir. La première norme (commerciale) définissant les pratiques et le
savoir-faire d'un business analyst, BABOK de l'IIBA (International Institute of Business Analysis),
ne date d'ailleurs que de 2005 et beaucoup considèrent qu'elle est encore immature par rapport
aux autres normes professionnelles ou méthodologiques (PmBok, Prince2 , CMmi, TOGAF, etc.).
En théorie, un business analyst aide les organisations à définir et implémenter la solution
optimale pour couvrir leurs besoins compte tenu d'une série de contraintes (calendrier, budget,
réglementations, etc.). Pour les banques de marché, aux systèmes d'information très complexes,
le travail du business analyst porte donc le plus souvent sur l'implémentation de nouvelles
fonctionnalités dans le traitement informatique d'un des métiers de l'investissement.

Les banques de marché, des raffineries informatiques complexes
Car les banques de marché sont d'immenses raffineries informatiques pour traiter, stocker et
restituer les centaines de milliers de traitements quotidiens liés à leur activité. Les opérations
financières sont réalisées au front office par les traders de la salle des marchés ou par des
commerciaux. Il y a donc des systèmes informatiques capables de donner les informations
nécessaires pour faire une opération (cours des actions, obligations, des taux, des cours de
changes, calculs pour évaluer le prix théorique de différents produits (produits dérivés..), limites
des opérations fixées par les banques par chaque contrepartie). D'autres systèmes permettent
d'enregistrer ces opérations, ce sont des applications évidement différentes suivant le type
d'opérations (achat de titres actions/obligations, produits dérivés, contrats plus sophistiqués).
Les opérations vont ensuite vers le middle office avec une "tuyauterie" appropriée. Le middle
office d'une banque retraite et vérifie les opérations effectuées par le front office. Il calcule les
risques qu'elles peuvent induire pour la banque et pour chaque portefeuille, calcule les profits ou
pertes potentielles de chaque opération, vérifie les caractéristiques de chaque opération avec la
contrepartie concernée, fixe des limites aux traders, produit les différents rapports
règlementaires et assure la conformité avec les nombreuses réglementations en vigueur. Là
encore, c'est une immense tuyauterie fonctionnelle et informatique qui assure, avec des
contraintes horaires souvent fortes (souvent moins de 24 heures), l'ensemble des traitements.
Les opérations sont ensuite transmises au back office qui assure les paiements, les
encaissements et la comptabilité tout au long de la vie de chaque opération (paiements initiaux,
intermédiaires et finaux).

Un budget considérable en technologies de l'information
L'activité bancaire dépend donc de cette raffinerie informatique ultra-complexe dans laquelle
chaque opération -de la saisie initiale jusqu'aux multiples restitutions- circule, se dédouble,
fusionne, d'applications en applications, de calculs en calculs et d'interface en interface. Cette
importance des technologies de l'information est visible dans les dépenses engagées pour ce
secteur. L'industrie bancaire dépense 7,3% de ses revenus dans les systèmes d'information
(contre 3,7% pour les autres secteurs en moyenne) c'est-à-dire suivant les estimations, entre
270 et 460 milliards de $. Le système d'information bancaire connait des évolutions


permanentes et rapides liées soit à des contraintes externes (règlementations) soit à des
objectifs internes (nouveaux types d'opérations, traitements améliorés des opérations…).
Un business analyst peut intervenir à deux niveaux. Parfois de manière macroscopique pour
définir et clarifier les changements souhaitables, mais le plus souvent à une échelle beaucoup
plus fine pour définir, analyser et suivre les changements de structure, de processus ou de
périmètre induits par des objectifs fixés préalablement. Ces changements s'effectuant dans le
cadre très informatisé de la banque, la composante IT est souvent très présente. La complexité
du système d'information et l'interconnexion entre chaque sous-structure dans une banque sont
telles que tout changement a un impact sur des sous-structures adjacentes, impact qu'il faut
prévoir, éviter ou accompagner. Les missions d'un business analyst dans une banque de marché
sont donc le plus souvent la mise en place ou la modification d'une application, d'une nouvelle
interface entre deux applications ou une modification du périmètre (ajout de nouvelles
opérations, de nouvelles informations…).

Première tache : Définir la méthodologie
La première tache d'un business analyst est de proposer la méthodologie à employer pour le
projet à venir. Il s'agit de définir le mode de suivi des actions ou la fréquence des comités de
suivi. Il s'agit aussi de définir quels types de documents de travail seront utiles en évitant des
recouvrements obligeant à des redites (L'art du Ctrl C ; Ctrl V n'étant détaillé par aucune norme
en vigueur). Puis pour chaque document quelle forme sera utilisée. En général chaque entreprise
a déjà une charte en interne imposant les modèles types de documents afin d'uniformiser et
faciliter le suivi documentaire. Ce souci louable donnant lieu ultérieurement à la traditionnelle
peur du vide du business analyst confronté à un modèle type très général.
"Qu'est-ce que je mets dans cette rubrique puisque j'ai déjà dit ça ailleurs ?" ou "On a le droit de
laisser vide cette section parce que là, vraiment je ne vois pas ce que je peux mettre ?".

Deuxième tache : l'Expression de besoin
Une fois le périmètre défini, il s'agit de spécifier puis de hiérarchiser les besoins exprimés
auxquels doivent répondre les changements à venir. C'est " l'étude de besoin " qui passe par
des réunions avec les utilisateurs, par l'étude des documents de référence (la réglementation à
implémenter, le contrat type des nouvelles opérations ou la documentation). Après les
traditionnelles ronchonneries accompagnant souvent l'annonce d'un changement :
" Si on m'avait écouté à l'époque, on n'aurait pas besoin de faire ça aujourd'hui "
" Mais on ne sait même pas si cet autre changement urgent va aboutir, donc je ne peux rien dire
tout de suite"
"On a décidé de ce changement sans me consulter alors que hein hein hein j'ai des idées qui
changent la donne."


Les réunions d'étude de besoins permettent clarifier les attentes et les objectifs. Elles sont aussi
l'occasion de bien cerner les conflits potentiels entre acteurs :
"Il n'est pas question de modifier ces flux d'opération, nous ne pourrons plus effectuer ce calcul ",
"Pourquoi acheter une application chez un éditeur, alors que nos développements en interne
répondent parfaitement aux besoins... "
"Je déteste ce chef d'équipe qui a pris la place qui me revenait de droit, mais bien sûr, bien sûr
que je vais l'aider de mon mieux…. "
Et de préparer les alternatives pour permettre à la hiérarchie de trancher...
Entre chaque acquisition d'information, le rôle de business analyst est de s'assurer que chaque
acteur a bien conscience des besoins qu'il exprime
" Vous voulez vraiment avoir le cours du taux à 11h00 plutôt que celui de 17h00 ?", "Donc dans
votre processus, vous validez d'abord le flux de paiement avec la compta puis avec la
trésorerie ?" .
Il hiérarchisera aussi les demandes suivant leur caractère obligatoire ou seulement souhaitable
par rapport aux changements envisagés.
A l'issue de ce processus, le business analyst présentera une expression de besoin formalisée
qui sera validée par tous les acteurs concernées. Elle servira de base aux spécifications
fonctionnelles et techniques.

Troisième tache : Les spécifications
La rédaction des spécifications consiste à rassembler tous les éléments qui permettront de
mettre en place les évolutions fonctionnelles (changement d'organisation, de processus ou de
métier) et techniques (développements, paramétrages des applications) et de décrire
précisément les modifications à effectuer pour les acteurs qui en auront la charge (ingénieurs IT,
opérationnels etc.). Cette partie rédactionnelle est l'occasion de valider les engagements
informels pris précédemment :
" Donc nous sommes d'accord, vous disposez bien des modifications de la liste des filiales de
chaque contrepartie, y compris en Asie ?
Avec parfois certaines déceptions :
"Donc le 12, vous avez dit que pouvoir nous donner le début de la période brisée de ce swap, le
23 finalement non, cela nous arrange pas du tout, est-ce qu'il y a un contournement possible ?" .
Pour les spécifications techniques, le business analyst échange aussi régulièrement avec les
ingénieurs IT pour connaître leurs contraintes :


"Les contrôleurs du risque ont besoin des calculs à 10h00 le matin, nous aurons le temps de
traiter les 12000 lignes par le batch de nuit de 3h00 ?"

Quatrième tache : Les tests et l'accompagnement du changement
Le business analyst accompagne ensuite les tests pour vérifier que les développements sont
conformes aux spécifications et ne présentent pas de bugs -ou de régressions-. Suivant la
formalisation, il utilisera des méthodes officielles chronophages et rigoureuses puis sera parfois
forcé de les abandonner, les tests étant souvent la zone tampon des projets en retard:
"Bon, on avait prévu 3 semaines de tests, mais honnêtement, si on met en production au bout
d'une semaine de tests en vérifiant ce point là et celui là, qu'est ce qu'il peut vraiment arriver au
pire du pire ? Hein honnêtement ? ».
Au delà des méthodes, le rôle du business analyst est donc stratégique -prendre du recul et bien
comprendre un objectif donné dans un ensemble complexe-, d'investigation (rassembler, vérifier
les informations nécessaires aux prises de décision puis à la conduite du changement), de
contrôle, de formalisation et un rôle d'interface « diplomatique » entre acteurs (clarifier les
demandes des utilisateurs ou expliquer les contraintes signalées par les développeurs, avec
dans les deux cas l'avantage de ne pas être soupçonné de plaider pour ses intérêts).

Chef de projet et business analyst. Chien et chat ?
Beaucoup d'encre virtuelle a coulé pour différencier le rôle de chef de projet et celui de business
analyst et sur les conflits possibles entre ces rôles. Le rôle du chef de projet est de tenir les
objectifs en s'assurant du contenu, du budget, du planning et des ressources, et d'évaluer les
risques, celui de Business Analyst est de définir les objectifs et spécifier la cible du projet. Selon
les définitions de ces taches, les risques de superposition des tâches existent et sont source de
frictions potentielles. Cela étant, dans un grand nombre de missions, les deux rôles sont
confondus, l'hybride mi-business analyst, mi-gestionnaire de projet semblant naturel pour
beaucoup d'entreprises.

Business Analyst, pas assez Agile ?
Par ailleurs, le rôle de Business Analyst est aussi contesté par certains spécialistes du
développement Agile qui privilégient -entre autres- une relation directe entre les développeurs et
les fonctionnels ainsi qu'une expression de besoins itérative et évoluant en cours de projet. Le
business analyst n'est plus alors un facilitateur entre développeurs et utilisateurs, mais un écran
de fumée brouillant les messages et alourdissant les processus de décisions. Pour d'autres
spécialistes, dans un environnement Agile, le rôle de Business Analyst doit effectivement évoluer,
en s'intégrant à une équipe de développeurs mais ses fonctions (stratégique, investigateur,
ambassadeur des utilisateurs) restent toujours aussi utiles à l'accompagnement d'une évolution.
Cela ne devrait pas forcément d'ailleurs dépayser tous les business analyst, certains travaillent
dans un environnement Agile comme Jourdain fait de la prose, sans le savoir : beaucoup de
changements se font en pratique avec souplesse sans respecter le déroulé théorique décrit


précédemment dans cet article...
Sinon, oui « business analyst » est traduit en Français comme analyste d'affaires, mais ce terme
est très peu (plutôt pas du tout) utilisé à l'heure actuelle.

Business Analyst, le futur, même sans la télé.
Au final, par delà les débats méthodologiques parfois byzantins entre professionnels
professionnalisant la profession, le métier de business analyst n'est pas prêt de disparaître. Les
organisations complexes, en réseau, changeantes ou lourdement informatisées auront
longtemps un besoin bien réel de collecter et de formaliser des informations temporaires et
éparses afin d'accompagner les changements.
Ne restera donc qu'à créer une ou deux séries télé pour populariser ce métier injustement
méconnu (Dr House va trouver la mystérieuse maladie qui fait disparaitre les deals de cette
application) et simplifier ainsi la vie sociale des business analyst. Les pompiers n'ont qu'à bien
se tenir…
inShare31

Tweet

21

J’aime

82

2

2

Business analyst definition

Contenu connexe

En vedette

Similaire à Business analyst definition

Business analyst definition