(temps de lecture moyen: 3 min)

La Business Analysis en fonction du modèle conceptuel de gestion de projet
Le cas des projets d’implémentation d’outils ERP, de BI et de PLM
Le Business Analyst sur les projets Big Data et Data Sciences

L’analyse métier est une activité exercée quel que soit le modèle conceptuel de gestion de projet utilisé. Cependant, sa pratique et son calendrier peuvent différer sensiblement.

D’autre part, certaines solutions clé-en-main (ERP, BI) sont déjà packagées par leurs éditeurs. Dans ce cas, le travail du Business Analyst consistera d’avantage à configurer le logiciel cible selon les fonctionnalités existantes qu’à imaginer une nouvelle solution.

La pratique de la Business Analysis a donc quelques variantes, liées :

• d’une part au modèle de gestion de projet utilisé,
• d’autre part, à la solution applicative éventuellement déjà choisie par le Client (ERP, PLM, BI).
• Enfin se pose la question des évolutions technologiques, comme le Big Data et les Data Sciences, qui refondent partiellement le rôle du Business Analyst.

La Business Analysis en fonction du modèle conceptuel de gestion de projet

Gestion de projet en “en cascade”

Le premier modèle conceptuel standard issu du monde du BTP est dit « en cascade » (Waterfall en anglais). Le hic… Le client découvrait la solution à sa livraison par le maître d’œuvre. L’effort de correction pour rectifier les écarts par rapport à ses attentes était bien souvent considérable. Le client se retrouvait donc dans au moins 80% des cas avec :

• une couverture non conforme de ses besoins fonctionnels;
• et un produit dont l’architecture technique ne permettait pas de répondre à une évolution ultérieure de son activité.

Gestion de projet “cycle en V”

Voir : La Business Analysis dans le cycle en V

Dans les années 1980 est apparu le modèle dit « cycle en V ». Issu cette fois du monde de l’industrie, il permettait de s’assurer, avant la livraison, de la cohérence fonctionnelle de la solution cible. On y a vu l’émergence des rôles pour partager et désigner les responsabilités. Le modèle en V s’est également adapté au génie logiciel, lequel gagnait en maturité à cette époque.

Ainsi, l’introduction de tests fonctionnels avant la livraison avait pour objectif de fiabiliser le cadre contractuel. Ceux-ci étaient répartis entre la maîtrise d’œuvre (MOE – le Réalisateur) et la maîtrise d’ouvrage (MOA – le Client).

Les inconvénients de ce modèle tenaient de la manière de corriger les anomalies relevées en phase d’acceptance par le Client. Tant que le produit n’était pas conforme aux attentes du client, celui-ci ne payait pas le solde. Or, les projets s’étalant sur plusieurs mois voire plusieurs années, il était fréquent que le contexte métier et donc les besoins du Client évoluent en parallèle.

Beaucoup de projets se sont donc retrouvés avec des dépassements de coûts et de délais considérables.

Il devenait urgent de gérer les projets informatiques en sécurisant à la fois le maître d’ouvrage et le maître d’œuvre.

Gestion de projet itérative, méthodologie “Agile”

Voir: La Business Analysis en contexte Agile

C’est ainsi que, dans les années 2000, est née la méthodologie dite « Agile », basée sur des cycles d’itération très courts. La gestion projet devenait itérative et adaptative, afin d’être flexible face à une évolution rapide des besoins du Client, tout en sécurisant le cadre contractuel du maître d’œuvre.

Vous vous en doutez, cette méthode a également ses inconvénients… Citons entre autres la nécessité d’avoir un niveau d’implication important de la part du client, la formation impérative des équipes, ou encore l’organisation du travail rendue de facto plus complexe. Sans compter que le concept d’agilité est de plus en plus dévoyé depuis quelques années, agilité devenant synonyme de rapidité (à tort, bien sûr).

Le Business Analyst ne travaille donc pas de la même manière selon le modèle choisi. C’est ce que je vous propose de lire dans les sous-chapitres de cette section.

Le cas des projets d’implémentation d’outils ERP, de BI et de PLM

Voir aussi: Les spécificités des ERP et de la BI et Le rôle ambigu du Business Analyst dans un projet d’ERP ou de BI

• Il existe de nombreux progiciels de gestion intégrés (encore appelés PGI ou ERP en anglais), tels SAP, SAGE ou encore JD Edwards. Leur particularité est qu’ils sont développés et distribués par un éditeur unique et qu’ils intègrent au sein d’un même logiciel l’ensemble des fonctions des entreprises. Celles-ci sont libres de n’acheter des licences que pour une partie des fonctions (par exemple, la fonction Logistique ou Comptabilité).
• Une autre catégorie de logiciels concerne l’aide à la prise de décision: les outils de Business Intelligence (Business Object, Cognos, Hyperion Essbase pour n’en citer que quelques uns). Ces logiciels agrègent une grosse quantité de données pour en extraire des indicateurs pertinents, que les décideurs pourront exploiter pour gérer leur activité.
• Les outils de PLM (Product Lifecycle Management) servent à gérer le cycle de vie des produits. Ils sont destinés aux industriels au sens large (manufacturing, systèmes complexes, BTP, agroalimentaire…) et ont pour but d’optimiser la gestion des produits tout au long de leur cycle de vie, depuis la création jusqu’à la fin de vie (et donc lancement de l’affaire, étude, conception, industrialisation, exploitation, démantèlement). Ils sont souvent confondus avec les ERP, mais leur positionnement est pourtant différent. En effet, l’ERP est focalisé sur les biens physiques et les flux d’articles, tandis que le PLM est centré sur la composition et l’interdépendance entre les différents éléments composants les produits, ainsi que la gestion de « l’environnement produit ».

Dans tous les cas, le Business Analyst devra être formé au logiciel en question. Son travail consiste en effet à proposer les configurations adéquates pour répondre aux besoins du client.

Le Business Analyst sur les projets Big Data et Data Sciences

Enfin, il y a le cas des projets Big Data et Data Science. Comme toute évolution technologique, les bonnes pratiques mettront des années à se diffuser. Le rôle du Business Analyst sur de tels projets reste encore à définir clairement, mais nous pouvons déjà nous inspirer très fortement du retour d’expérience de nos amis anglo-saxons, en avance sur nous de quelques années…

Quand on voit que certains confondent Data Analyst et Business Analyst, on se dit tout-de-même que des progrès restent à faire!