Kennisbank

Lorsque Day 100 n'est pas atteint

Day 100 est une date que les équipes d'intégration s'imposent elles-mêmes, pas une loi de la nature. Lorsque cette date approche et que le plan n'est pas terminé, une certaine agitation apparaît généralement : quelque chose s'est-il mal passé, faut-il accélérer, quelqu'un doit-il rendre des comptes ? Ces questions sont compréhensibles mais rarement les bonnes. La première question est plus précise : quelle partie du plan n'a pas été réalisée, et qu'est-ce que cela signifie pour le reste.

Chaque élément manqué n'a pas le même poids

Un plan Day 100 se compose de décisions qui dépendent les unes des autres et de décisions qui n'en dépendent pas. Si une migration informatique prend du retard mais que le reste de l'organisation n'attend pas cette migration, c'est un problème différent du cas où une décision relative au personnel prend du retard alors que cinq autres équipes attendent cette décision pour pouvoir avancer. Avant de conclure que Day 100 a échoué, il est utile d'examiner quelles décisions initiales se trouvaient réellement sur le chemin critique et qui en assurait le suivi. Un délai manqué sur une décision qui ne bloquait rien n'est pas une crise. Un délai manqué sur une décision dont tout dépendait, en est une.

Cette distinction est rarement établie clairement à l'avance. Les plans sont rédigés comme une liste de dates, pas comme un réseau de dépendances. Celui qui doit déterminer après coup ce qu'un retard coûte réellement découvre souvent que les dépendances n'ont jamais été consignées explicitement. C'est précisément pour cela qu'il est utile de déterminer à l'avance quelles dépendances bloquent le reste du parcours et qui en assure le suivi. Sans cette cartographie, chaque retard est une surprise plutôt que le résultat attendu d'un risque connu.

Le coût de l'attente est rarement réparti de manière égale

Toutes les décisions reportées ne coûtent pas autant les unes que les autres. Une décision relative à un système CRM commun peut attendre sans que grand-chose ne soit perdu, tandis qu'une décision relative à qui gère la relation client se joue dès le premier jour, et un report se fait alors immédiatement sentir auprès des clients et des collaborateurs. La distinction entre ce qui peut attendre et ce qui ne peut pas attendre n'est pas fixe : elle dépend du secteur, de l'ampleur du chevauchement entre les organisations, et de l'incertitude qu'un délai d'attente plus long suscite chez les personnes qui attendent une décision.

Pour établir cette distinction, il est utile de classer les décisions selon ce que l'incertitude coûte réellement, et non selon ce qui est le plus facile à traiter en premier. Certaines équipes s'attaquent d'abord aux décisions les plus rapides à prendre, alors que l'incertitude la plus coûteuse se situe ailleurs. Une manière d'éviter cela consiste à classer les décisions selon ce que coûte l'incertitude par jour de report d'une décision. Cela donne un ordre différent d'une planification qui vise simplement à tout achever en cent jours.

Il y a aussi un autre aspect : chaque décision ne doit pas nécessairement être prise en cent jours, et forcer les choses peut causer plus de dégâts que de reporter. Certains choix d'intégration se prennent mieux après une période d'observation, lorsqu'il est plus clair comment les deux organisations collaborent réellement. Il est donc tout aussi important de savoir ce qui peut attendre après Day 100 sans que le parcours ne se bloque que de savoir ce qui ne peut pas attendre. Un délai manqué sur une décision qu'il valait mieux prendre plus tard n'est pas un échec — c'est une correction.

Ce qu'un Day 100 manqué révèle réellement sur le bureau d'intégration

Lorsque Day 100 n'est pas atteint, la question ne concerne souvent pas la décision elle-même, mais la structure qui aurait dû en assurer le suivi. Un bureau d'intégration qui se contente de tenir à jour des dates sur une liste ne voit un délai manqué qu'une fois celui-ci déjà dépassé. Un bureau d'intégration qui suit les dépendances et les coûts d'incertitude voit un retard arriver et peut déterminer à temps s'il faut réajuster ou si un report est acceptable.

Cela touche à une question plus large sur la manière dont le bureau d'intégration lui-même est organisé. Un bureau surchargé de mises à jour de statut et de rapports perd la vue d'ensemble précisément au moment où elle est nécessaire. Il est donc pertinent de réfléchir à comment le bureau d'intégration reste gérable et qui en assure le suivi, afin qu'un délai manqué devienne un signal plutôt qu'un bruit de fond dans une boîte de réception surchargée.

Il n'existe également jamais une seule réponse à la question de ce qu'il faut faire lorsque Day 100 n'est pas atteint : la réponse dépend de la décision concernée, de ce qui en dépend, et si le retard coûte réellement de la valeur ou préserve au contraire de la valeur en évitant un choix précipité. Celui qui cherche à ce sujet une structure plutôt qu'une réponse toute faite trouvera une approche détaillée sur la page consacrée spécifiquement à ce qu'il faut faire lorsque Day 100 n'est pas atteint et qui assure le suivi de ce processus.

Intégrer n'est pas toujours le bon choix

À chaque élément manqué d'un plan Day 100 s'ajoute aussi la question sous-jacente de savoir s'il était réellement nécessaire de fusionner cet élément. Certains systèmes, équipes ou processus ne gagnent rien à l'intégration et perdent au contraire du temps et de l'attention nécessaires ailleurs. Un délai manqué est un bon moment pour reposer cette question, pas seulement pour pousser plus fort vers la date initiale.

Pour déterminer quelle partie du travail lié à un tel parcours d'intégration doit être effectuée par des personnes et quelle partie peut être soutenue par l'IA, FTE TO AI propose un scan de travail qui calcule, tâche par tâche, quelle part peut être reprise. Pour les équipes qui, après un Day 100 manqué, souhaitent savoir où la capacité se bloque et où elle peut être libérée, c'est un point de départ concret.