Un plan d'intégration issu d'une transaction précédente est souvent encore disponible. La structure fonctionnait, la répartition des fonctions et des systèmes était correcte, et il est tentant de le réutiliser. Mais réutiliser un plan est différent de répéter un résultat. La question n'est pas de savoir si le plan était complet, mais si les hypothèses qu'il contient valent encore pour cette transaction-ci, ces deux organisations-ci et ce marché-ci.
La réutilisation fonctionne au niveau de la question, pas au niveau de la réponse. Un plan précédent comportait un ordre pour les systèmes, une répartition des fonctions qui fusionnaient ou non, et une liste de dépendances. Cet ordre est utilisable comme liste de contrôle pour ne rien oublier. Il n'est pas utilisable comme résultat à copier, car la raison pour laquelle quelque chose a fusionné la fois précédente en dit peu sur si cela doit aussi se produire cette fois-ci.
Il y a quelques signaux à vérifier avant qu'un ancien plan ne serve de base.
Premièrement : les deux organisations précédentes étaient-elles comparables aux deux actuelles, en taille, en paysage systémique, dans la mesure où les clients perçoivent la différence. Un plan pour deux parties équivalentes ne convient pas à une acquisition où l'une des parties est une petite équipe complémentaire.
Deuxièmement : sait-on pourquoi certaines composantes sont restées séparées à l'époque. Si cette raison n'est pas consignée, il est impossible d'évaluer si elles doivent désormais fusionner. Un plan qui montre seulement ce qui a été fusionné, sans l'arbitrage expliquant pourquoi quelque chose est resté séparé, vaut moins pour la réutilisation qu'il ne le paraît.
Troisièmement : le paysage systémique sous-jacent est-il comparable. Fusionner deux systèmes ERP est une tâche différente de faire coexister deux outils de planification. Ce qui était l'une des premières étapes la fois précédente pourrait cette fois mieux rester de côté parce que les systèmes eux-mêmes ne sont pas comparables.
Qu'un plan soit nouveau ou réutilisé : chaque composante doit être accompagnée de la question de savoir si la fusion apporte de la valeur en premier lieu. Ce n'est pas une question d'exception pour les cas douteux. C'est une étape fixe, même pour les composantes qui, à première vue, semblent évidemment devoir fusionner.
La raison est que l'intégration entraîne des coûts qui ne sont pas toujours visibles à l'avance : du temps de personnes qui, sinon, travailleraient pour les clients ou pour la croissance, des systèmes temporairement moins fiables, des équipes qui deviennent incertaines quant à leur rôle. Si aucun bénéfice démontrable ne compense cela, la fusion est un poste de coût sans compensation. Quand l'intégration détruit de la valeur n'est donc pas un cas marginal mais un risque structurel pour tout plan repris sans ce test.
Il y a des composantes qui, dans la plupart des cas, restent mieux séparées : une marque avec sa propre relation client, une équipe avec une culture qui était la raison de l'acquisition, un système qui vient d'être remplacé et ne doit pas être modifié à nouveau. Ce que vous laissez délibérément séparé n'est pas une liste de tâches en retard mais une décision avec sa propre raison, et cette raison doit être documentée tout autant que la raison de fusionner quelque chose. Voir ce que vous laissez délibérément séparé pour voir à quoi ressemble ce choix.
Il est rare qu'une acquisition entière doive intégralement s'intégrer ou non. En général, le résultat est un mélange : centraliser le reporting financier, laisser séparés les systèmes clients, fusionner partiellement la politique RH. Chaque composante requiert son propre arbitrage, avec son propre calendrier et son propre risque. Comment décider par composante d'intégrer ou non est ainsi moins un plan par étapes qu'une question fixe posée séparément pour chaque composante, avec sa propre réponse.
Cet arbitrage diffère également selon le secteur. Dans la construction, une intégration se heurte souvent à l'administration de projets et aux relations avec les sous-traitants qui ne se transfèrent pas facilement vers un autre système ; voir où une intégration se heurte-t-elle dans la construction. Dans le secteur de l'installation, ce sont plus souvent les systèmes de planification et les contrats de service qui ne fusionnent pas un à un ; voir où une intégration se heurte-t-elle dans le secteur de l'installation. Un plan réutilisé qui ignore ces différences manque précisément la composante où cela a posé problème auparavant.
Les générateurs pour la ligne de base des synergies, le plan Day 1 et le plan Day 100 ne se construisent pas sur un modèle de la transaction précédente, mais sur la situation introduite : quelles composantes existent, quelles sont les dépendances, et quelle raison existe par composante de fusionner ou non. Le bureau d'intégration tient ensuite à jour quels avantages ont été identifiés, quelles dépendances restent ouvertes, et quelles composantes ont délibérément été maintenues séparées. Ce n'est pas une preuve que cela fonctionne — il n'y a pas de trajectoire réalisée à laquelle se référer — mais c'est bien une structure qui force à poser la question par composante plutôt que de la sauter.
Mergerintegration.net est en construction. Ceux qui souhaitent travailler avec cet outil dès qu'il sera disponible peuvent s'inscrire sur la liste d'attente.
La question de savoir quelle partie de ce travail coûte du temps en propre et quelle partie peut être reprise ne se pose pas seulement dans la planification d'intégration. Le scan de travail de FTE TO AI calcule par tâche quelle part du travail peut être reprise par l'IA, donnant ainsi une image de l'endroit où de la capacité se libère avant qu'une trajectoire d'intégration ne démarre.
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.