Fondamentaux de l'analyse d'affaires
Définition
L'analyse d'affaires (Business Analysis) est l'ensemble des activités permettant d'identifier les besoins métier, de recommander des solutions et de faciliter la livraison de valeur aux parties prenantes. Dans le contexte du CAPM, elle couvre le pont entre la stratégie organisationnelle et l'exécution du projet.
| Concept | Description |
|---|---|
| Besoin métier (Business Need) | Problème ou opportunité justifiant le projet |
| Analyse d'affaires | Processus de compréhension, documentation et validation des besoins |
| Business Analyst (BA) | Rôle responsable de l'analyse (peut être le PM sur petits projets) |
| Domaine de solution | Périmètre dans lequel la solution sera implémentée |
Contexte
Le CAPM inclut un domaine dédié à l'analyse d'affaires depuis sa mise à jour. Le PMI considère que comprendre le « pourquoi » du projet est aussi important que le « comment ». L'analyse d'affaires intervient avant, pendant et après le projet — de l'identification du besoin à la validation de la valeur livrée.
Détails techniques
Cycle de l'analyse d'affaires
Stratégie organisationnelle
│
▼
1. Évaluation des besoins (Needs Assessment)
Quel problème résoudre ? Quelle opportunité saisir ?
│
▼
2. Analyse de rentabilité (Business Case)
Le projet vaut-il l'investissement ?
│
▼
3. Élicitation et documentation des exigences
Que doit faire la solution ?
│
▼
4. Analyse et traçabilité des exigences
Les exigences sont-elles cohérentes et complètes ?
│
▼
5. Évaluation de la solution
La solution livrée répond-elle aux besoins ?
│
▼
6. Mesure de la valeur et des bénéfices
Le projet a-t-il livré la valeur attendue ?
Rôle du BA vs PM
| Aspect | Business Analyst | Chef de projet |
|---|---|---|
| Focus | Le « quoi » — que faut-il construire | Le « comment » — comment le livrer |
| Responsabilité | Exigences, solutions, valeur | Périmètre, délais, coûts, qualité |
| Parties prenantes | Utilisateurs, métier, experts domaine | Sponsor, équipe, fournisseurs |
| Livrables | Business case, exigences, prototypes | Plan de management, échéancier, budget |
| Temporalité | Avant → pendant → après le projet | Initiation → clôture du projet |
Niveaux d'exigences
| Niveau | Description | Exemple |
|---|---|---|
| Exigences métier | Objectifs stratégiques de l'organisation | Réduire le temps de traitement des commandes de 40% |
| Exigences des parties prenantes | Besoins des utilisateurs et autres PP | Le commercial doit voir le statut commande en temps réel |
| Exigences de solution | Fonctionnelles et non-fonctionnelles | Le système affiche le statut en < 1 seconde |
| Exigences de transition | Besoins de passage ancien → nouveau système | Migration des 50 000 commandes en cours |
Compétences clés en analyse d'affaires
| Compétence | Application |
|---|---|
| Pensée analytique | Décomposer un problème complexe en éléments gérables |
| Communication | Traduire le langage métier en exigences techniques |
| Facilitation | Animer des ateliers de recueil d'exigences |
| Modélisation | Créer des diagrammes, prototypes, modèles de processus |
| Négociation | Arbitrer entre besoins contradictoires des PP |
| Pensée systémique | Comprendre les impacts d'une solution sur l'ensemble |
Exemple concret
Hôpital souhaitant réduire les erreurs de prescription médicamenteuse :
| Phase BA | Activité | Résultat |
|---|---|---|
| Évaluation besoin | Analyse des incidents : 120 erreurs/an, coût moyen 8 000 € | Besoin identifié : système de vérification automatisée |
| Business case | ROI calculé : investissement 200K €, économie 960K €/an | Projet approuvé par la direction |
| Élicitation | Ateliers avec médecins, pharmaciens, infirmiers | 45 exigences documentées |
| Analyse | Priorisation MoSCoW : 20 Must, 15 Should, 10 Could | Périmètre V1 défini |
| Évaluation | Tests utilisateurs après 3 mois de production | Erreurs réduites de 85% |
| Bénéfices | Mesure à 12 mois | Économie réelle : 816K € — ROI confirmé |