Dans les cent premiers jours après une transaction, le problème semble souvent être un manque de décisions. Plus souvent, le problème est l'ordre. Une décision concernant le système ERP commun bloque la mise en place des lignes de reporting. Une décision concernant qui reçoit le mandat commercial bloque toute conversation avec des clients partagés. Tant que personne ne nomme cette dépendance, deux équipes s'attendent mutuellement en même temps, sans que personne ne le remarque.
Toute décision en suspens n'est pas un problème. Certaines choses peuvent attendre sans que le reste s'arrête — lesquelles, et qui peut en décider, est décrit sur la page sur ce qui peut attendre après le Day 100. Une décision bloquée est autre chose : c'est une décision dont dépendent d'autres décisions, et qui retient ces autres décisions de manière démontrable. La différence n'est pas toujours visible depuis une seule équipe. Le service financier ne voit pas que son attente d'un choix de système retarde aussi l'intégration RH, parce que les fiches de paie dépendent du même système. Ces liens ne deviennent visibles que lorsque quelqu'un les cartographie explicitement, indépendamment du service qui se trouve être le dernier concerné.
Le coût d'une décision bloquée est rarement un montant fixe par semaine. Il dépend de ce qui est à l'arrêt : un accord de prix qui ne peut être révisé tant que le portefeuille de produits n'est pas fusionné, un employé clé qui part parce que personne ne clarifie son rôle, un client qui passe à un concurrent parce que deux équipes commerciales se contredisent. Ce ne sont pas des chiffres calculables à l'avance. Ils peuvent en revanche être ordonnés : quelle décision affecte combien d'autres décisions, et quelle est la nature du dommage si cela dure plus longtemps. Cet ordonnancement — selon l'incertitude et la conséquence, pas selon qui crie le plus fort — est traité sur la page sur le tri des décisions selon le coût de l'incertitude.
Lors de la cartographie des décisions bloquantes, une question ne doit pas être omise : cette composante doit-elle réellement être intégrée. Résoudre une dépendance en fusionnant deux systèmes n'est pas automatiquement préférable à les laisser coexister. Parfois, le moyen le plus rapide de lever un blocage est de décider que l'intégration à ce niveau n'apporte pas de valeur. Cette décision ne doit pas être prise tacitement parce que personne n'a posé la question ; elle doit être mise explicitement sur la table, à côté de la question du quand et dans quel ordre.
Une liste de décisions bloquantes est déjà incomplète dès le premier jour de l'intégration, et le devient plus rapidement à mesure que davantage de décisions sont prises. De nouvelles dépendances apparaissent dès que les anciennes sont résolues : le système a été choisi, et voilà que la mise en œuvre dépend d'un contrat fournisseur encore en cours. Quelqu'un doit maintenir cette carte à jour, non comme un exercice ponctuel de la première semaine, mais comme une tâche continue — sinon le blocage ne fait que se déplacer. Qui remplit ce rôle et comment cette personne évite que la carte elle-même ne devienne une bureaucratie ralentissante, est décrit sur la page sur le maintien du bon fonctionnement du bureau d'intégration.
Les décisions bloquées sont souvent la raison pour laquelle un plan Day 100 n'est pas atteint, non pas parce que le plan était erroné, mais parce qu'une dépendance a été sous-estimée. Quelles décisions doivent absolument être prises dans les cent premiers jours, et qui veille à ce qu'elles le soient réellement, figure sur la page sur les décisions des cent premiers jours. Que faire si le délai n'est finalement pas respecté — quelles décisions sont alors reprioritisées et qui en décide — est décrit sur la page sur le non-respect du Day 100. Signaler un blocage n'équivaut pas à le résoudre, mais sans signalement, le retard reste invisible jusqu'au moment où le rapport doit être livré.
Les générateurs et le bureau d'intégration de mergerintegration.net structurent ces dépendances : ils cartographient quelle décision attend quelle autre décision, et quelle partie de l'organisation est de ce fait à l'arrêt. Ce n'est pas une référence — aucun parcours réalisé n'est invoqué par cet outil, et cela n'est pas suggéré ici. C'est une manière de poser la question avec précision avant que le retard ne devienne visible dans des chiffres que plus personne ne peut corriger. Qui souhaite travailler avec cela peut s'inscrire sur la liste d'attente ; l'outil est en construction.
Une partie du temps perdu à cause de décisions bloquées est consacrée à des tâches que les personnes effectuent manuellement alors qu'elles pourraient aussi être automatisées : fusionner des listes de clients, comparer des conditions contractuelles, tenir à jour une carte des dépendances qui change après chaque réunion. Le scan de travail de FTE TO AI calcule, par tâche, quelle part peut être reprise par l'IA, et rend ainsi visible où se libère de la capacité qui aurait autrement pu être consacrée à l'intégration elle-même.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.