Contexte du projet

Gestion de projet

(temps de lecture moyen: 3 min)

La Business Analysis en fonction du modèle conceptuel de gestion de projet
Business Analysis: le cas des projets d’implémentation d’ERP ou de Business Intelligence

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, outil de BI).

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

Projet suivant un modèle « 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é.

Projet suivant un modèle « 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.

Projet suivant un modèle itératif ou une 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.

Le Business Analyst ne travaille 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.

Business Analysis: le cas des projets d’implémentation d’ERP ou de Business Intelligence

Voir: Les spécificités des ERP et de la 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é.

Dans les deux cas – ERP ou BI, 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.

Poster un Commentaire

avatar
  S’abonner  
Notifier de