Les techniques d’analyse et de modélisation

(temps de lecture moyen : 2 m 45 s)

Analyser et modéliser sont des compétences professionnelles incontournables en business analyse.

Il existe de nombreuses techniques, méthodes, méthodologies et outils empruntées à des domaines aussi variés que l’industrie, le marketing, les ventes, l’informatique, ou le management (liste non exhaustive) que le Business Analyst peut utiliser pour analyser les informations recueillies lors de l’élicitation.

Vous trouverez dans cette page un simple aperçu de certaines des techniques d’analyse et de modélisation utilisables en Business Analyse pour décrire de manière pertinente, complète et non ambiguë la future solution (avec un focus sur les systèmes d’information, qui représentent 80% des missions des business analysts).

Je vous conseille de faire régulièrement de la veille informationnelle, car ce domaine est en constant renouvellement.

En réalité, toutes les nouvelles techniques d’analyse émergentes ne sont pas nouvelles. Ce sont souvent d’anciennes méthodes remises au goût du jour pour des besoins précis (projet, secteur…) et  qui font tâche d’huile par le biais d’internet. Ce media accélère de facto leur application à de nombreux secteurs d’activités dans le monde entier, le point de départ étant fréquemment les pays anglo-saxons ou le Japon.

Prenez l’exemple du Kanban. Initialement pensée pour optimiser la production en flux tendu des usines Toyota dans les années 1960, la logique a été reprise et appliquée à la refonte des processus métier en entreprise, y compris du secteur tertiaire.

D’autre part, de nombreuses techniques ont leurs variantes (à l’exemple des méthodes agiles comptant une dizaine de représentantes, dont les célèbres SCRUM et XP).

Aussi, un conseil : si vous arrivez dans une organisation qui applique une méthode particulière, vérifiez-en le degré de personnalisation. Cela vous évitera de tomber dans les écueils de l’ambigüité et vous permettra de parler le même langage que vos interlocuteurs.

Voici 4 exemples de techniques et méthodologies de modélisation utilisables en Business Analyse des systèmes d’information et en analyse des processus.

UML (Unified Modeling Language)

L’UML – Unified Modeling Language –  est clairement « le » standard de référence, la technique la plus connue et enseignée à ce jour. Il est vrai qu’elle permet de visualiser et de conceptualiser à peu près toutes les facettes d’une demande de changement, et qu’elle est compréhensible autant par les interlocuteurs métier que technique.

En business analyse, cette boîte à outils permet de modéliser les cas d’utilisation, les fonctionnalités, les processus, de représenter les interactions entre composants, acteurs, de préparer la stratégie de déploiement de la solution cible…

Bien entendu, il faut en apprendre la syntaxe, mais même sans l’appliquer stricto sensu, ses diagrammes et vues permettent au Business Analyst d’analyser et de rédiger la plupart de ses livrables.

MERISE

Merise est une méthode séquentielle, par opposition aux méthodes itératives et incrémentales (RUP, SCRUM…)

Je l’ai apprise en Master 2 de la bouche même d’un de ses pères fondateurs, ce qui en fait, en quelque sorte, ma « madeleine de Proust »…

La méthode Merise d’analyse et de conception propose une démarche articulée simultanément selon 3 axes pour hiérarchiser les  préoccupations et les questions auxquelles répondre lors de la conduite d’un projet:

  • Cycle de vie : phases de conception, de réalisation, de maintenance puis nouveau cycle de projet.
  • Cycle de décision : des grands choix (GO-NO GO : Étude préalable), la définition du projet (étude détaillée) jusqu’aux petites décisions des détails de la réalisation et de la mise en œuvre du système d’information. Chaque étape est documentée et marquée par une prise de décision.
  • Cycle d’abstraction : niveaux conceptuels, logique/organisationnel et physique/opérationnel (du plus abstrait au plus concret) L’objectif du cycle d’abstraction est de prendre d’abord les grandes décisions métier, pour les principales activités (Conceptuel) sans rentrer dans le détail de questions d’ordre organisationnel ou technique.

La méthode Merise, très analytique (attention méthode systémique),  distingue nettement les données et les traitements, même si les  interactions entre les deux sont profondes et s’enrichissent  mutuellement (validation des données par les traitements et  réciproquement). 

Il faut bien entendu en apprendre la syntaxe, tout comme l’UML, mais sa maîtrise en fait un outil puissant et rigoureux si elle est partagée entre développeurs et Business Analysts.

Cependant, elle est de plus en plus rarement enseignée en école d’ingénieur ou en master informatique, au profit de l’UML, et sa « lourdeur » ne se prête pas forcément aux projets agiles.

Pour en savoir plus: site de Techno-Science

RUP (Rational Unified Process)

Je suis une grande fan de la méthodologie RUP (Rational Unified Process), qui est générique, itérative et incrémentale (par opposition, vous l’aurez compris, aux méthodes séquentielles comme Merise).

L’intérêt de cette méthodologie, pour le Business Analyst, est qu’elle permet de penser « objet » tout en analysant les besoins du point de vue utilisateur et en restant centré sur l’architecture de la future solution.

Les statistiques démontrent que les échecs des projets informatiques sont majoritairement liés à une mauvaise compréhension et restitution des besoins métiers, ainsi qu’à une architecture inappropriée et non évolutive.

La méthodologie RUP améliore donc considérablement les chances de succès, puisqu’elle encadre les activités (voir la rubrique Contexte du projet) en se focalisant sur ces deux axes.

Bien qu’étant incrémentale et itérative, comme le requièrent les projets agiles, il ne s’agit pas faire de l’analyse métier « agile ». En effet, la méthode RUP conserve les caractéristiques d’un projet en V (phase de Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment). Le rôle du Business Analyst y est donc clairement identifié et central, contrairement aux projets en contexte agile.

BPMN 2.0 (Business Process Modeling Notation)

BPMN 2.0 est une notation graphique exécutable, qui permet à la fois de modéliser des processus métier et, au travers d’un schéma d’échange standard basé sur XML, d’échanger des modèles BPMN entre différents outils. Ainsi, un Business Analyst peut modéliser des processus métiers dans un outil informatique utilisant le système de notation BPMN 2.0, et les transférer à des équipes de développeurs travaillant également avec des outils de développement compatibles avec BPMN 2.0.

La notation BPM permet de représenter de manière graphique n’importe quel processus, “des recettes de cuisine au processus d’affectation du Prix Nobel, de la gestion des incidents aux systèmes de vote électroniques, ou encore les procédures de réservation de voyages, pour n’en nommer que quelques-uns. ” (Chinosi and Trombetta, 2012).

Selon la norme BPMN publié par l’OMG (Object Management Group): “L’objectif principal de BPMN 2.0 est de fournir une notation qui est facilement compréhensible par tous les utilisateurs professionnels, des analystes d’affaires qui créent la version initiale du processus, aux développeurs techniques chargés de l’application de la technologie qui va exécuter ces processus, et finalement, les personnes qui permettront de gérer et de contrôler ces processus. Ainsi, BPMN crée un pont standardisé pour l’écart entre la conception des processus d’affaires et l’implémentation des processus. Un autre objectif, mais non moins important, est de s’assurer que les langages XML conçus pour l’exécution des processus métiers, tels que WSBPEL (Web Services commerciaux Process Execution Language), peuvent être visualisées avec une notation axé sur les processus métiers.”

Voilà pour la présentation de quelques méthodes et méthodologies utilisées en Business Analyse – mais je vous invite à parcourir mes nombreux articles et vidéos YouTube qui vous feront découvrir régulièrement des outils et techniques spécifiques ou plus génériques en analyse et modélisation.

3.7 6 votes
Évaluation de l'article
3
0
Would love your thoughts, please comment.x