Du périmètre validé à GO-LIVE READY.

Parce que le prix découle du périmètre, et que celui-ci n'est validé qu'à l'issue d'Assess. Ensuite, UN seul montant Implement fixe est approuvé et apparaît dans votre compte. Un chiffre publié à l'avance serait une promesse sur un périmètre inconnu.

Non. Mesurer un système en production n'impose aucun projet de suite ; la mesure peut conclure qu'aucune action n'est nécessaire. Implement n'est pas l'étape suivante par défaut.

Les budgets dérapent rarement à cause d'une grosse erreur, mais par la répétition d'un même mécanisme : le travail est chiffré avant que le périmètre ne soit écrit. Le contrat engage de la capacité (jours-homme) alors que le périmètre se révèle au fil du projet ; chaque découverte devient une demande de changement, chaque demande devient des jours en plus. Trois sources typiques : (1) des processus non consignés — tableurs annexes, validations informelles, un flux différent à l'entrepôt ; (2) la migration de données — les données historiques ne sont pas au format attendu, ce qui se voit en phase de test ; (3) les décisions en attente — une décision métier non tranchée fait refaire le même travail une fois le développement lancé. Les trois remontent à une cause commune : le périmètre a été découvert APRÈS l'engagement. MindDX inverse cet ordre — le prix se construit sur un périmètre validé.

Cinq préparations précèdent toute installation technique. (1) La propriété des décisions : qui tranche pour chaque processus doit être écrit ; un processus sans nom associé bloque en milieu de projet. (2) L'état des données : les données de base (clients, articles, stocks, fournisseurs) doivent être dédoublonnées et leurs champs manquants connus à l'avance — la migration se mesure en préparation, pas en phase de test. (3) L'inventaire des processus : le fonctionnement réel d'aujourd'hui, écrit, flux non consignés compris. (4) Les décisions de périmètre : chaque écart déjà tranché en « adapter / changer le processus / hors périmètre ». (5) La préparation des utilisateurs : quel rôle utilise quel écran et comment, réglé avant la formation. Sans ces cinq points, le projet démarre quand même — mais le périmètre apparaîtra plus tard. Chez MindDX, les quatre premiers relèvent d'Assess et le cinquième d'Implement.

Un Blueprint est la réponse écrite à la question « que construisons-nous exactement ? » dans un projet ERP : l'état cible des processus, la fonction système qui couvre chaque étape, les décisions fit/gap et la justification de chacune. Ce n'est pas une liste de fonctionnalités — les listes disent ce qui sera demandé, un Blueprint dit COMMENT les choses fonctionneront. Un bon Blueprint porte trois choses à la fois : (a) le flux de processus cible, (b) la configuration système correspondante, (c) ce qui a été mis hors périmètre et pourquoi. Le troisième point est le plus souvent omis et le plus coûteux à omettre : un « hors périmètre » jamais écrit revient plus tard en « exigence oubliée ». Chez MindDX, le Blueprint est le résultat de Discover et l'entrée d'Implement — non pas une présentation, mais le document sur lequel repose la mise en œuvre.