Uma equipa de negociação que já integrou uma aquisição anteriormente tem frequentemente um plano à mão. Uma checklist do Day 1, uma lista de categorias de sinergia, um cronograma de comunicação. A tentação de retirar esse documento da gaveta, alterar nomes e números, e avançar é grande. Isso poupa tempo. Também poupa trabalho de reflexão, e é precisamente aí que está o problema.
Um plano de integração não é um modelo para uma organização, é o resultado de escolhas feitas numa combinação diferente de empresas. Que sistemas se juntam, que equipas se fundem, que relações com clientes permanecem separadas — essas escolhas dependiam do que eram as duas empresas anteriores, não do que são estas duas empresas. Reutilizar um plano sem voltar a testar essas escolhas subjacentes significa assumir uma estrutura que foi construída para outra situação.
O risco não está na forma. Faseamento, um rastreador de benefícios, uma lista de dependências — esses componentes são frequentemente bem reutilizáveis. O risco está no conteúdo que viaja junto sem ser notado: o pressuposto de que o departamento X se junta sempre, que o sistema Y é sempre descontinuado, que a integração cultural é sempre abordada da mesma forma. Esses pressupostos não são neutros. São precedente, e o precedente parece prova quando não o é.
Três coisas geralmente viajam bem de um projeto para outro:
Estes componentes são método, não resultado. Dizem-lhe como chegar a uma resposta, não qual é a resposta. Essa distinção é o cerne da reutilização responsável: assumir o processo, não as conclusões.
Torna-se arriscado no momento em que um plano anterior ignora a própria pergunta. Se o projeto anterior determinou que duas equipas de vendas se juntam, e isso é automaticamente assumido porque "é assim que funciona", a probabilidade de estar certo também desta vez depende do acaso, não da análise. Mais sobre quando fundir destrói valor e como o reconhece pode ler noutra página, mas a pergunta fixa regressa aqui: será que este componente poderia ter ficado melhor separado.
Isso aplica-se fortemente aos sistemas. Uma migração de TI que fazia sentido no negócio anterior — porque a empresa adquirida tinha uma plataforma desatualizada — não faz automaticamente sentido numa empresa com um sistema recentemente renovado e que funciona bem. Que sistemas é melhor deixar como estão e como se reconhece isso é uma consideração separada por situação, não uma regra que se herda do negócio anterior.
Também a estrutura organizacional é sensível à reutilização cega. Se o plano anterior determinou que os departamentos financeiros se fundem sempre, esse automatismo faz desaparecer a pergunta sobre se isso também se aplica aqui. Numa estratégia buy-and-build, em que uma plataforma acrescenta empresas repetidamente, a tentação de aplicar um único modelo é ainda maior — e a necessidade de voltar a avaliar cada componente ainda mais urgente. O que uma abordagem buy-and-build exige da sua estratégia de integração e como se reconhece isso merece, por isso, uma avaliação própria por aquisição, não um plano recorrente.
Uma abordagem viável é usar o plano anterior como uma checklist de perguntas que deve voltar a colocar, não como uma lista de respostas já definidas. Para cada componente que foi integrado no plano anterior, volta a colocar a pergunta se isso também se aplica aqui. Para cada componente que ficou separado, pergunta-se se essa razão também se aplica aqui. Como estrutura essa decisão por componente — integrar ou não, e com base em que critérios — determina, no final, mais sobre o resultado do que a rapidez com que o plano fica no papel. Veja também como constrói essa decisão por componente e como se reconhece isso: como decide por componente sobre integrar ou não.
O que fica deliberadamente separado merece, no plano reutilizado, tanta atenção quanto o que se junta. Um plano que contém apenas passos de integração e nada diz sobre o que explicitamente não é fundido perde metade da decisão. Tornar visível de antemão o que fica separado e porquê evita que essa escolha seja explicada mais tarde como um erro. Mais sobre isto: o que deixa deliberadamente separado e como isso se registra de antemão.
Os três geradores e o gabinete de integração da mergerintegration.net foram construídos com base nesta distinção: estrutura que viaja junto, não conclusões que viajam sub-repticiamente. Uma linha de base de sinergias, um plano do Day 1 e um plano do Day 100 são reconstruídos por situação a partir das mesmas perguntas, com um rastreador de benefícios e uma lista de decisões que obrigam a uma resposta por componente. Esta é uma ferramenta que estrutura, não uma experiência que garante — a ferramenta está em construção e quem quiser utilizá-la pode inscrever-se na lista de espera.
Um plano de integração trata de quem faz que trabalho, que departamentos se juntam e que processos continuam a existir. Sob essa pergunta encontra-se uma pergunta mais precisa: quanto do trabalho que em breve será feito em conjunto ou separadamente é, na verdade, trabalho de tarefas que se pode automatizar. O werkscan da FTE TO AI calcula, por tarefa, que parte desta pode ser assumida pela IA, e assim dá uma base numérica a uma escolha que de outro modo continua assente em pressupostos — precisamente o risco que também está latente nos planos de integração reutilizados.
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.