Lors d'une fusion ou d'un rachat, l'intégration est souvent considérée comme la norme : deux organisations, donc deux systèmes qui doivent en devenir un. Ce postulat coûte du temps, de l'argent et de l'attention, et parfois il coûte plus qu'il ne rapporte. Certains systèmes ne devraient pas être fusionnés. Pas parce que c'est techniquement impossible, mais parce que le résultat ne vaut pas l'effort qu'il demande.
La question « quels systèmes vaut-il mieux laisser tels quels » n'est donc pas une exception dans le processus d'intégration. C'est une étape fixe qui revient pour chaque composante, du CRM à la planification de production jusqu'à l'administration RH.
La fusion détruit de la valeur de plusieurs manières reconnaissables.
Si le système n'a aucun chevauchement avec le reste de l'organisation, l'intégration ne fait qu'ajouter du risque sans créer de synergie où que ce soit. Pensez à un système spécialisé qui soutient une seule équipe dans une niche que le reste de l'entreprise ne touche pas.
Si les coûts de migration pèsent plus lourd que l'avantage d'un système unique. Le transfert de données, la reconfiguration, le temps de formation et le risque d'erreurs pendant la transition sont des coûts réels. Ces coûts sont parfois disproportionnés par rapport à ce qui est gagné en facilité de gestion ou en coûts de licence.
Si le système vient d'être implémenté ou vient d'être amorti, et qu'un changement demande donc un double investissement sans que le premier ait été rentabilisé.
Si la fusion mène à un compromis où aucune des deux organisations n'obtient ce dont elle avait besoin, et que la friction opérationnelle qui en résulte est plus grande que la friction de deux systèmes coexistants.
Une analyse plus détaillée de cet arbitrage, avec les signaux visibles au préalable, se trouve sur quand l'intégration détruit de la valeur et comment le reconnaître.
Laisser un système tel quel délibérément est différent de ne pas y réfléchir. Un système que vous laissez séparé reste une composante de la décision d'intégration, seulement la conclusion « ne pas fusionner » ressort de cette décision. Cela signifie qu'il faut quand même des accords sur la gestion, sur qui est responsable de quoi, et sur la manière dont les rapports ou les échanges de données circulent entre les deux systèmes tant qu'ils coexistent.
Les signaux permettant de voir au préalable qu'un élément doit rester séparé sont détaillés sur ce que vous laissez délibérément séparé et comment le voir au préalable. Cela va au-delà des systèmes : cela vaut aussi pour les équipes, les processus et les relations clients qui ont une valeur propre tant qu'ils ne sont pas intégrés dans un ensemble plus vaste.
Pour éviter que cette question ne soit posée par hasard pour un système et oubliée pour un autre, un moment de décision fixe fonctionne mieux que des discussions isolées. Pour chaque composante — système, processus, équipe — la même question est posée : que rapporte la fusion, que coûte-t-elle, et y a-t-il une raison de la reporter ou de ne pas la faire du tout.
La structure de cette liste de décision et les critères récurrents qui s'y appliquent se trouvent sur comment décider par composante d'intégrer ou non et comment le voir. Le résultat de cette décision n'est pas toujours définitif : un élément qui reste séparé aujourd'hui peut être fusionné plus tard si les circonstances changent.
Dans une stratégie de buy-and-build, l'arbitrage est différent que pour un rachat unique. Une société de plateforme qui intègre plusieurs acquisitions successivement bénéficie de choix reproductibles : les systèmes qui restent séparés lors d'un rachat le resteront peut-être aussi lors du suivant, de sorte que le schéma devienne prévisible plutôt que chaque transaction ne donne lieu à une nouvelle discussion. Ce que cela signifie pour votre approche se trouve sur ce que le buy-and-build signifie pour votre approche d'intégration. Pour les équipes de transaction qui ont déjà élaboré un plan d'intégration auparavant, il est également utile d'examiner ce qui en est réutilisable pour la prochaine transaction, comme décrit sur comment réutiliser un plan d'intégration.
Un aperçu plus approfondi des systèmes qui, en pratique, restent plus souvent séparés, ainsi que les signaux correspondants, se trouve sur quels systèmes vaut-il mieux laisser tels quels et comment le voir.
Les générateurs de ligne de base de synergie, de plan Day 1 et de plan Day 100, ainsi que le bureau d'intégration pour le suivi des bénéfices et des dépendances, sont conçus pour structurer ces décisions. Ils ne fournissent ni antécédents ni garantie de bon résultat. Ils veillent à ce que la question « cela doit-il vraiment fusionner » soit posée pour chaque composante, plutôt que pour quelques-unes et oubliée pour les autres.
L'outil est en construction. Ceux qui souhaitent l'utiliser dès qu'il sera disponible peuvent s'inscrire sur la liste d'attente.
La question de savoir quels systèmes restent séparés est souvent liée à une autre question : quelle part du travail dans ces systèmes se fait encore manuellement, et quelle partie de celui-ci peut être reprise par l'IA. Une intégration est un bon moment pour cartographier cela, car les processus sont de toute façon déjà examinés à la loupe. Le scan de travail de FTE TO AI calcule, tâche par tâche, quelle part du travail est éligible à une reprise par l'IA, indépendamment de la question de savoir si les systèmes sous-jacents sont fusionnés ou restent coexistants.
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.