Pourquoi l’analyse du métier ?

Il règne une instabilité du vocabulaire dans ce domaine ; ainsi, ce domaine peut couvrir (et être nommé) : analyse d’entreprise, analyse d’affaires, business analysis. L’assistance à maîtrise d’ouvrage (AMOA) comprend un volet d’analyse, ainsi que la fonction d’architecte d’entreprise, qui se préoccupe plus globalement de l’adaptation continue de l’outil SI au métier de l’entreprise, ainsi qu’à sa stratégie.

L’analyste du métier (ou analyste métier) peut intervenir à deux moments :

lors de la phase dite d’analyse des projets ;
comme analyste de l’entreprise, de manière récurrente, afin de préparer sa transformation en lançant lesdits projets.

Le but de cet ouvrage est de montrer en quoi l’analyste peut tirer des avantages nombreux et convaincants de la formalisation des résultats de ses analyses. Cette formalisation sera exprimée à l’aide du langage dédié UML. Il ne s’agira pas d’expliquer dans sa globalité le rôle de l’analyste dans l’entreprise, même si celui-ci sera bien entendu évoqué.

Le métier de l’analyste du métier en entreprise a été formalisé pour la première fois en 2003 en vue de sa professionnalisation à l’initiative de l’International Institute of Business Analysis (IIBA).

1. Les compétences de l’analyste du métier

Le rôle de l’analyste du métier est sensible. Ses compétences sont les suivantes :

Apporter son savoir-faire dans l’identification et l’énoncé des difficultés à aplanir, qui peut (et qui doit) différer de celui des utilisateurs.
Décrire les problèmes en les formalisant.
Proposer une ou des solutions de la manière la plus conceptuelle possible, c’est-à-dire en laissant de côté toute considération technique.
Tracer les objectifs stratégiques de l’entreprise de façon qu’ils soient pris en compte par chaque unité organisationnelle ; pour cela, il faut décliner ces objectifs stratégiques en exigences opérationnelles....

Les changements et les adaptations de l’entreprise par les projets

1. Adapter l’entreprise

La plupart des projets logiciels menés en entreprise visent à moderniser les processus opérationnels ; les autres sont destinés soit à satisfaire de nouveaux besoins, soit à implémenter des outils tactiques ou stratégiques. Les vastes programmes de transformation visant à aligner structure et moyens de l’entreprise sur l’évolution de son modèle économique deviennent rares. Ceux qu’on rencontre sont provoqués par des fusions/acquisitions d’entreprise.

a. Améliorer en profitant des nouvelles technologies

Des améliorations peuvent être supportées par des outillages nouveaux qui sont développés ou implémentés par la direction du système d’information (DSI). Parfois, elles font suite à une initiative métier. Les gens des métiers souhaitant faire évoluer les processus de manière continue exigent que les techniques sous-jacentes ne soient pas un frein mais sachent s’adapter sans refonte, par simple paramétrage rapide, à de nouvelles configurations.

Deux réponses sont possibles à cette demande de souplesse adaptative :

Mettre à disposition une architecture générique.
Déployer des progiciels de gestion dont les capacités de paramétrage et d’adaptation par scripts devront être évaluées.

Une architecture générique du système d’information vise à construire un outil apte à s’adapter à des évolutions futures qui, pour l’heure, restent inconnues. Ces évolutions seront acceptées par le système d’information dans la mesure où le modèle conceptuel du système n’est pas contesté ; un modèle conceptuel robuste est directement inspiré du métier de l’entreprise.

Qui provoque les changements ? Les métiers de l’entreprise sont inducteurs de changements et en principe prescripteurs, mais il faut savoir que les nouvelles technologies portent des changements majeurs qui peuvent échapper aux métiers et que la direction des systèmes d’information perçoit...

L’International Institute of Business Analysis (IIBA)

Fort de 29 000 membres, dont 260 entreprises, répartis parmi 116 sections locales (chiffres 2016), l’IIBA se veut l’organisme de référence au service des professionnels de l’analyse du métier («With over 29,000 Members, over 260 Corporate Members and over 116 Chapters, International Institute of Business Analysis™ (IIBA®) is the recognized, non-profit association for business analysis professionals around the world.»www.iiba.org).

Il fut fondé en 2003 au Canada (Ontario).

Sa mission étant de professionnaliser une discipline, cette association (sans but lucratif) publie le Business Analysis Body of Knowledge (BABOK), corpus des connaissances nécessaires à l’analyse du métier, et propose des certifications.

Des groupes d’études sont organisés autour de la version 3 du BABOK, aidant à sa mise en œuvre.

Les francophones bénéficient de chapitres francophones au Canada, en France, en Suisse.

Comment le BABOK est-il organisé ? Il réunit les meilleures pratiques acceptées par les praticiens, et son but est d’aider à la création de valeur : satisfaire les exigences, c’est avant tout dans le but d’apporter de la valeur. L’ingénierie des exigences se situe donc dans la perspective de gestion...

Le cycle de vie du projet

Le cycle de vie du projet explique l’enchaînement des tâches nécessaires à sa bonne fin.

Il y a trois familles majeures de cycles de vie des projets :

Le cycle en V classique : les phases, donc les livrables, s’ensuivent et aboutissent aux tests d’acceptation finale, prélude nécessaire au déploiement et à la mise en œuvre par les utilisateurs. Les phases en question sont très schématiquement l’analyse, la conception, la réalisation, la mise en œuvre. À chaque phase correspond une phase de tests et de vérifications. Cet ouvrage concerne l’analyse des besoins d’un projet, ainsi que l’analyse systématique du métier de l’entreprise.
Le cycle itératif : l’équipe projet fournit des livrables composés de plusieurs sous-livrables successifs, le phasage étant découpé en plusieurs étapes qui s’attaquent au même sujet à des niveaux de détail de plus en plus fins.
Le cycle incrémental : l’équipe projet construit et fournit fonctionnalité après fonctionnalité. Le livrable d’une fonctionnalité est définitif : il n’est pas revu, comme c’est le cas lors d’un cycle itératif.
Le cycle agile : les projets sont à la fois incrémentaux...

Le cycle de vie de la solution

Le cycle de vie d’une solution recouvre celui du projet ; mais elle commence en amont du projet avec l’étude d’opportunité (durant laquelle on évalue l’intérêt d’entreprendre le projet). Cette étude d’opportunité consiste en un examen macroscopique des besoins et de la solution envisagée.

Cette phase d’étude (dont le livrable pourrait être une lettre de mission, ou note de cadrage) est évoquée au chapitre Rédiger le cahier des charges fonctionnel d’un projet.

La conception débute par la remise d’un cahier des charges fonctionnel (CdCF). Ce livrable est l’objet du chapitre Rédiger le cahier des charges fonctionnel d’un projet.

La vie de la solution peut comprendre des livraisons et des déploiements partiels. Il est souhaitable qu’à chaque livrable soit fournie l’étude des besoins le concernant.

L’histoire de la solution ne s’interrompt pas avec le déploiement du livrable du projet (la solution à fournir) ; après le déploiement débute la période d’exploitation qui comprend la gestion du maintien en condition opérationnelle, pendant laquelle la maintenance corrective et/ou évolutive adapte le produit en continu aux demandes des utilisateurs. Cette période prend...

Le cycle de vie des exigences

La période d’étude des besoins doit comporter une phase d’étude stratégique où sont examinées l’insertion du livrable attendu dans le patrimoine informatique de l’entreprise, et sa réponse à la stratégie. La question importante est : dans quelle mesure le futur produit contribuera à l’atteinte des objectifs, donc comment ces objectifs trouvent leur concrétisation dans les exigences ?

Cette phase d’étude stratégique étant menée, la période d’étude comporte une analyse concrète du besoin. Cette analyse est dite concrète car elle se mène relativement au problème posé, et non plus relativement à la stratégie. Ce qui signifie que ce travail de déclinaison de la stratégie en objectifs et exigences a été fait.

Le cycle de vie des exigences revêt deux aspects :

Les exigences sont recueillies de façon progressive, au fur et à mesure que la solution s’étudie et se construit ; on est dans un phasage itératif ou agile du projet.
Chaque exigence, qui peut varier au cours du projet, peut être abandonnée ou remontée en priorité. Cela se traduit dans le cycle de vie de l’exigence.

Il faut donc administrer soigneusement les exigences...

À retenir pour la suite

1. Le cycle de vie du produit (de la fourniture)

On entend par fourniture le résultat, fini ou partiel, du projet de construction. Les étapes principales de la vie de la fourniture sont :

Analyse des besoins, construction de la solution : certaines fonctions sont livrées, recettées et déployées. Le CdCF analyse les besoins et les fonctions répondant à chaque besoin, ainsi que la description logique de la solution choisie.
Analyse des besoins, construction de fonctions supplémentaires : des fonctions supplémentaires sont livrées, recettées ; les tests de non-régression des livraisons antérieures ont permis de déployer la nouvelle livraison. Le CdCF a été complété en conséquence (analyse des nouveaux besoins implémentés, fonctions, description logique ajoutée à la description précédente).
Utilisation nominale et à pleine charge : toutes les fonctions ont été livrées, recettées, mises à disposition. Les performances sont conformes aux conditions d’utilisation spécifiées dans le CdCF.
Utilisation en conditions hostiles (mode dégradé) ; fonctionnement dégradé du produit et des supports et services compagnons. Le CdCF prévoit un mode de fonctionnement...

Ingénierie de l'analyse du métier