L'écart entre un MVP et un système provisoire
Deux projets peuvent être lancés avec le même nombre d'écrans ; l'un servira de base à la croissance, l'autre deviendra une dette technologique à éliminer. La distinction ne réside pas dans l'étendue, mais dans la nature du compromis.
La règle d'or : Lors de la première itération, il faut réduire l'étendue fonctionnelle, et non la profondeur architecturale. Il est acceptable de restreindre le nombre de processus, d'unités ou de types de clients pris en charge. En revanche, il est impératif de ne pas sacrifier le modèle de données central, le modèle d'autorisations, ni la définition de la source de vérité unifiée. Ces éléments doivent être construits correctement dès le départ, même s'ils ne desservent initialement qu'une cinquantaine d'utilisateurs.
Celui qui réduit la profondeur plutôt que l'étendue se retrouve avec un système fonctionnel pour un trimestre, avant de devoir être entièrement reconstruit. Le cadre plus large des phases de projet est détaillé dans le Guide d'implémentation Salesforce.
Trois définitions souvent confondues
| Terme | Ce que c'est en pratique | Quand est-ce approprié | Risque principal |
|---|---|---|---|
| Preuve de Concept (PoC) | Validation technique d'un composant unique | En cas de doute réel sur la faisabilité d'une fonctionnalité | Tendance à le faire évoluer vers la production |
| Pilote | Déploiement complet auprès d'un groupe restreint | Solution connue, l'enjeu est l'adoption | Le groupe n'est pas suffisamment représentatif |
| MVP (Minimum Viable Product) | Première version en production générant une valeur réelle | Volonté d'apprendre de l'utilisation concrète | Devient permanent sans décision explicite |
Le choix entre ces trois approches n'est pas qu'une question de sémantique. Un PoC peut être abandonné, ce qui n'est pas le cas d'un MVP. C'est pourquoi un MVP doit être construit selon les standards d'un produit en production.
Les décisions qu'il est impératif de ne pas reporter
Un ensemble de décisions ont un coût de modification qui augmente de manière exponentielle une fois que des données sont en production. Ces décisions doivent être prises dès la première itération, même si elles ne desservent qu'une petite partie du tableau général :
- L'objet central qui gère le processus métier et sa relation avec les entités clés.
- La clé unique identifiant un client vis-à-vis des systèmes externes.
- La visibilité par défaut de chaque objet principal.
- La structure de propriété des enregistrements – qui est le propriétaire et que se passe-t-il en cas de départ d'un collaborateur.
- La définition de la source de vérité pour chaque entité synchronisée avec un autre système.
En revanche, les décisions qu'il est permis et même recommandé de reporter sont les suivantes : la conception de rapports avancés, les automatisations de commodité, l'intégration de canaux secondaires, la localisation d'unités non concernées par la première itération, et les intégrations qui ne sont pas nécessaires à une prise de décision en temps réel.
Comment choisir le processus de la première itération
Il ne s'agit pas de choisir le processus le plus simple ni le plus problématique. Il s'agit de sélectionner un processus qui répond simultanément aux trois conditions suivantes : il a un propriétaire unique et disponible, il génère un résultat visible par la direction, et il représente le modèle de données central. Un processus qui satisfait deux de ces trois conditions reste envisageable ; un processus qui n'en satisfait qu'une seule conduira à une première itération qui n'apportera aucun apprentissage significatif.
Une autre considération est le volume : un processus qui se produit dix fois par mois ne générera pas suffisamment d'utilisation pour en tirer des enseignements dans un délai d'un trimestre.
Critère de sortie – Qu'est-ce qui indique qu'une itération est réussie ?
Un MVP sans critère de sortie devient un statut permanent. Le critère doit être mesurable, de courte durée et défini à l'avance. Exemple de structure :
- Le pourcentage de processus du type sélectionné qui sont effectivement exécutés dans le système et non en dehors.
- Absence de panne bloquante ouverte au-delà d'un nombre de jours spécifié.
- Les données générées pendant la période respectent le seuil de qualité prédéfini.
- Le propriétaire du processus confirme par écrit que le processus fonctionne sans contournement permanent.
Notez qu'aucun de ces critères n'est "le système a été mis en ligne". Cette date est le point de départ de la mesure, et non sa fin.
Le coût du report – L'outil décisif dans les discussions sur le périmètre
Lorsque l'on discute de l'inclusion d'une fonctionnalité dans la première itération, la question pertinente n'est pas : combien coûte sa construction maintenant, mais combien coûte sa construction plus tard. Le tableau suivant sert d'outil de travail lors des réunions de définition du périmètre :
| Type de fonctionnalité | Coût de construction en première itération | Coût de construction en deuxième itération | Conclusion |
|---|---|---|---|
| Modification de la structure d'un objet central | Faible | Très élevé – inclut la migration | Inclus dans la première itération |
| Nouveau modèle d'autorisations | Moyen | Élevé – l'exposition a déjà eu lieu | Inclus dans la première itération |
| Rapport de gestion | Faible | Faible | Reporté |
| Automatisation d'alerte | Faible | Faible | Reporté |
| Intégration requise pour une décision en temps réel | Élevé | Élevé + contournement ancré | Inclus si le processus en dépend |
| Intégration pour la seule génération de rapports | Moyen | Moyen | Reporté |
Exemple illustratif : Une entreprise de logistique internationale
Ce scénario est hypothétique et à titre d'illustration. Une entreprise d'expédition opérant dans trois pays souhaitait lancer un MVP en onze semaines. La première proposition consistait à inclure les trois pays, mais uniquement la phase de devis, sans la phase de commande.
L'équipe a inversé la délimitation : un seul pays, mais le processus complet, du devis à la commande confirmée, y compris l'intégration qui récupère les tarifs. La raison était simple : tronquer le processus à mi-chemin aurait obligé les utilisateurs à continuer sur l'ancien système pour la phase de commande, c'est-à-dire à saisir les données deux fois. Au lieu d'apprendre si le système aidait, l'entreprise aurait appris que le système était contraignant.
Le périmètre global en semaines est resté similaire. Ce qui a changé, c'est qu'après la première itération, l'entreprise disposait d'un processus complet et fonctionnel, et non d'un demi-processus dans trois pays.
Signes qu'un MVP est devenu un système provisoire
- Il existe un processus manuel permanent destiné à "faire le pont jusqu'à la prochaine itération" et en place depuis deux mois.
- Un champ a été convenu pour servir deux fonctions différentes par manque de temps pour le dédoubler.
- Un groupe d'utilisateurs travaille en parallèle sur deux systèmes.
- Il n'y a pas de date de décision pour l'itération suivante, seulement une liste d'attente.
Ces schémas, ainsi que d'autres échecs courants, sont détaillés dans le Guide des erreurs fréquentes d'implémentation de CRM.
Intégration au calendrier global
La définition du MVP influence directement la durée du projet, parfois à l'inverse des attentes : une première itération trop étroite prolonge le projet global, car chaque itération entraîne un coût fixe de tests, de formation et de mise en production. Comment traduire cela en une planification réaliste et détaillée est expliqué dans le Guide de la durée d'un projet Salesforce, et, dans le cas d'un remplacement de système existant, également dans le Guide de migration vers Salesforce.
Prochaine étape
Décrivez en une phrase le processus de la première itération, son propriétaire, et le critère qui indiquera dans un trimestre qu'il est réussi. Si l'une de ces trois phrases ne peut être formulée actuellement, c'est votre point de départ, et non la liste des fonctionnalités.