SERGAM-Xpert vous présente son pôle d'expertise

Business Analysis

Préambule

Cet article n’a pas pour vocation d’être un cours sur ce sujet qu’est « Business Analysis », mais plutôt de proposer une série de précisions pour les personnes désireuses d’approfondir leurs connaissances des acteurs d’un projet informatique et de leurs activités.

En aucun cas, il se prétend être LA définition ou L’explication exacte. Il est la résultante de retours d’expériences en tant que spécialiste du sujet, car ce poste est celui du rédacteur de l’article depuis de nombreuses années.

Plusieurs points sont présentés afin d’éclaircir certains angles de vue ou sources d’ambigüité.

Comme pour les autres métiers, ce document ne présente pas comment les activités et actions sont réalisées mais ce qu'elles contiennent. Voici un échantillon de l'expertise de SERGAM-Xpert dans le domaine de l'AMOA transverse.

Pour tout renseignement sur les savoir-faire, veuillez vous rapprocher de SERGAM-Xpert qui répondra à vos question.

Création : SERGAM-Xpert !2014)

Sources : SERGAM-Xpert

Définition

« Business Analysis » ou « l’analyse fonctionnelle » en français, consiste à comprendre comment des entités fonctionnelles ou des métiers fonctionnent. Il s’agit aussi de comprendre les interactions entre les Acteurs, les données utilisées et en tenant compte de toutes les règles de gestion. Cette activité est réalisée par le Business Analyst (l’analyste fonctionnel).

Elle concerne les analyses qui vont permettre de comprendre et d’appréhender les modes opératoires, les relations et les échanges qui existent entre les différents Acteurs directement concernés par le projet informatique. Ce projet qui concerne l’évolution du système d’information que ces Acteurs fonctionnels doivent utiliser pour leurs activités quotidiennes.

Le Business Analyst réalise les actions nécessaires à la compréhension des métiers et des échanges entre les Acteurs, en tenant compte des données et des règles de gestion à respecter. Proche de l’AMOA (quand il n’est pas cette même personne), le Business Analyst va analyser, comprendre et modéliser (voire spécifier) les échanges d’informations dans les processus fonctionnels – existant ou devant exister – entre les différents acteurs présents dans la MOA ou la MOE cliente.

Actions confiées au Business Analyst

Très proche des activités de l’AMOA, celle de l’analyste fonctionnel se concentre sur la compréhension des modus operandi existant ou prévus en cible, lorsque le système d’information aura évolué. Elles se répartissent autour de plusieurs axes majeurs :

• Organiser les ateliers avec les Acteurs fonctionnels.
• Recueillir les besoins fonctionnels (à partir de l’existant).
• Analyser les modus operandi des unités fonctionnelles, les Acteurs avec les étapes, les données utilisées et les règles de gestion.
• Modéliser les processus fonctionnels.
• Modéliser les workflows fonctionnels.
• Spécifier les processus et/ou les workflows.
• Intervenir pour conseiller et impacter les évolutions fonctionnelles.
• Faire le relai avec l’AMOA pour la poursuite du projet.

NOTA : cette énumération d’actions devra bien entendu être adaptée au contexte et aux contraintes imposés par le projet à réaliser.

Détails des axes d'actions du Business Analyst

Organiser les ateliers avec les Acteurs fonctionnels

Le Business Analyst consultera les différents Acteurs afin d’en connaître et d’en comprendre les modes opératoires dans leur ensemble. Ces consultations pourront s’organiser lors d’ateliers de travail afin de comprendre l’ensemble du périmètre à analyser et connaître les intrications d’actions entre les Acteurs. L’ensemble des informations recueillies sera consigné dans des documents à faire valider par les Acteurs présents lors des ateliers afin de confirmer ou infirmer ce qui a été compris. Plus tard, cette somme d’information sera la base des études, analyses et des réalisations qui seront réalisées pour le projet.

Recueillir les besoins fonctionnels

Cet axe est prépondérant pour que le projet se réalise selon les attentes du client.

Pour ce faire, le Business Analyst (ou accessoirement, l’AMOA) doit recueillir les processus et modus operandi existants puis, les besoins fonctionnels des différentes entités métiers ou de celles effectuant des actions fonctionnelles. Cet existant servira de socle d’étude pour comprendre les évolutions dictées dans les nouveaux besoins.

L’ensemble des besoins – qui généralement seront recueillis lors d’ateliers (voir paragraphe précédent) – devra présenter les actions prévues en cible avec leurs articulations, les données utilisées et les règles de gestion qui les régiront.

Les documents – qui pourront être des livrables attendus par le Client – créés (détails des processus existant et les besoins prévus en cible) devront faire l’objet d’une série de relectures par les MOA et les Acteurs afin de la valider ou les invalider en y reportant les corrections à apporter pour qu’ils soient valides.

Dès lors que les documents sont validés par le client, le Business Analyst pourra les utiliser pour construire ses référentiels de travail et poursuivre ses actions d’analyses fonctionnelles.

Analyser des modus operandi des unités fonctionnelles

Les documents construits lors des précédentes actions et validés par le Client constituent désormais une base référentielle de travail.

Avec les informations qui y figurent, le Business Analyst pourra commencer à circonscrire les périmètres à analyser.

Les analyses consistent à détailler les processus qui existent ou qui devront exister dans l’organisation prévue pour les entités fonctionnelles et / ou le système d’information cible. Il s’agira de présenter les différents Acteurs présents dans le périmètre étudié avec leurs métiers, les actions qu’ils devront réaliser, les données et informations utilisées et manipulées, les règles de gestion qui conditionneront les activités. Ces analyses permettront de servir de base de travail pour les modélisations et les spécifications et autres reports des évolutions attendues.

Modéliser les processus et les workflows

À l’aide d’outils de modélisation (par exemple, Microsoft Visio), le Business Analyst pourra modéliser le résultat des ses analyses de l’existant et de la cible attendus cartographiera l’ensemble des Acteurs appartenant au périmètre d’étude et il modélisera les actions et les flux d’informations naviguant entre eux.

Comme il est très difficile de tout modéliser sur un même graphique, le Business Analyst pourra représenter les différentes phases des processus sur différents calques qui pourront se superposer pour montrer une vision d’ensemble. Également, il pourra se focaliser sur certaines sections afin d’en montrer les spécificités (Acteurs, flux de données, règles de gestion, évolutions, etc.).

Des codes de couleurs pourront être utilisés pour distinguer les sens des flux et leurs natures. Par exemple, on pourra utiliser la couleur verte pour signifier les flux de données en validation ou allant naturellement dans le sens départ vers l’arrivée ; on pourra aussi utiliser la couleur rouge pour signifier les refus ou les annulations de traitements ou de données ; etc. Chaque couleur pouvant correspondre à un type de traitement, on pourra les isoler dans des calques spécifiques pour ensuite avoir une vision globale de tous les traitements en superposant tous les calques. Cela permettra de simplifier la lecture et de se focaliser sur certains traitements pour en préciser les fonctionnements.

Spécifier les processus et/ou les workflows

Une action complémentaire à la modélisation concerne l’explication détaillée des schémas. Ces explications vont reprendre tous les détails présents dans chacune des étapes qui concernent les Acteurs impliqués dans les processus et les workflows.

En fonction des calques et du type de traitement qu’ils regroupent, le Business Analyst pourra créer des documents de spécifications dédiés.

La mise en forme des documents de description des traitements est également importante. Ils doivent être faciles à lire et respecter un format qui pourra être standard entre tous les documents de spécifications. Ainsi, il sera facile de passer d’un document à l’autre, sans perdre de temps dans le déchiffrage de sa nature.

Tous comme les analyses de l’existant et les recueils des besoins, il faudra prévoir la validation des spécifications par les MOA ou le client. Car il ne faut pas oublier que ces documents, une fois validés, deviendront les références pour les actions techniques des MOE.

Intervenir pour conseiller et impacter les évolutions fonctionnelles

Dans certains projets, les évolutions demandées par les Clients ou les MOA parviennent au fil de l’eau. Ces contraintes sont à prendre en considération car ils auront un impact important sur les éléments livrés et sur leurs possibles évolutions. Aussi, le Business Analyst devra avoir parfaitement acquis et intégré les modus operandi cibles afin de mesurer les possibles évolutions qui seront demandées. Il devra être en mesure de comprendre les sensibilités des évolutions, d’en prioriser les prises en compte et d’en comprendre avec précision les impacts positifs ou négatifs (par exemple, l’ajout de règles de gestion peuvent révéler des actions ne respectant pas les lois de ségrégation des droits ou mettre en évidence des informations toxiques pour le bon déroulement des actions).

Dans tous les cas – acception ou refus de la prise en charge des évolutions parvenant in extremis dans les processus ou workflows – le Business Analyst consignera précisément les demandes qui lui parviennent et les décisions qu’il prendra à ce sujet.

Faire le relai avec l’AMOA pour la poursuite du projet

S’il n’est pas lui-même d’AMOA, le Business Analyst devra constamment rendre des comptes de ses activités et de ses décisions avec elle afin de maintenir une cohérence totale du projet.

En effet, il serait incohérent ou inenvisageable qu’il n’y ait aucune communication entre deux Acteurs majeurs du projet. Surtout s’agissant de relais avec la MOA ou le client.

Rappels sur la distinction entre processus et workflow et leur modélisation (exemples)

Tout au long de ce document de présentation de l’IAM, les mots « processus » et « workflow » sont employés. Il est nécessaire de distinguer l’un de l’autre car tous deux permettent de décrire un enchaînement d’actions.

Exemple de processus fonctionnel

Les processus et workflows permettent de décrire et de détailler des enchaînements d’actions. Et bien qu’ils aient à peu de chose près la même forme et peuvent être modélisés avec les mêmes outils, ils possèdent cependant une caractéristique personnelle qui fait qu’on ne pourra utiliser l’un à la place de l’autre.

Le « processus » présente un enchaînement d’actions sans précision des détails des actions réalisées mais peut présenter certains acteurs. Il montre les étapes et leurs chainages de manière rudimentaire et simplifiée sans en montrer forcément tous les sens de déroulement. Certaines règles de gestion pourront y figurer sous forme de cardinalités mais les données ne sont que simplement présentées. De même, si des conditions de tests doivent être présentées, elles le seront de manière simplifiée. Enfin, généralement, les représentations de processus utilisent une seule et même couleur pour signifier les étapes des liens.

Plusieurs types de modélisations existent et peuvent être réalisés. La priorité doit être portée à la lisibilité des enchaînements, des échanges et de l’évolution du ou des processus, depuis le point de départ jusqu’à l’arrivée.

Exemple de modélisation de processus de gestion des identités articulée avec la gestion des habilitations :

D'autres représentations et de modélisations sont tout à fait envisageables. De nombreux outils de modélisations existent sur ce thème, de même, les entreprises elles-mêmes ont parfois l'habitude d'utiliser des modèles ou des modélisations qui leur sont propres.

L'importance principale est que le processus doit présenter simplement les modes opératoires, les acteurs et les actions.

Exemple de workflow fonctionnel

À la différence, le « workflow » présente de manière claire et précise les étapes et les acteurs impliqués dans le processus et le sens des liens (orientation des flèches) qui existent entre les actions ou étapes. Pour des raisons de lisibilité et de compréhension, il est préférable de présenter un seul lien entre deux éléments (étapes vers étapes, condition de test vers étape et inversement) dans un workflow. Si plusieurs liens orientés doivent rejoindre une seule et même étape, alors il est préférable de créer une condition de test en amont afin de distinguer les liens.

Dans un workflow, les liens entre les étapes représentent les flux de données (création, modification, transmission de données, communication entre acteurs) et non simplement des enchaînements d’actions. S’il est positionné un lien entre deux étapes, cela signifie qu’un échange de donnée (un flux de données) existe. De même, toujours pour des questions de lisibilité, on pourra utiliser des codes de couleurs différents pour signifier la nature ou la provenance des flux.

Les workflows montrent également tous les flux techniques orientés tels que les envois de notifications aux différents acteurs (demandeurs, responsables hiérarchiques, bénéficiaires, etc.) ou certaines options prises par les acteurs à certaines étapes. Par exemple, on pourra faire figurer les possibilités de « retours arrière » (par exemple pour les demandes d’informations complémentaires), les annulations des demandes ou les rejets.

Il faut comprendre que la modélisation des workflows ne permettent pas uniquement de présenter comment le processus IAM sera mais il servira aussi à la rédaction des spécifications fonctionnelles détaillées qui permettront les paramétrages et les développements de la solution afin qu’elle soit bien le reflet des besoins fonctionnels exprimés.

Exemple de workflow construit sur le modèle de processus présenté plus haut (gestion des identités et des habilitations).