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 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…
Source Article from http://www.latribune.fr/opinions/tribunes/20130919trib000786011/business-analyst-le-metier-que-vos-parents-ne-comprennent-pas.html
Source : Gros plan – Google Actualités
