Un piano di integrazione di una deal precedente spesso è ancora lì. La struttura funzionava, la suddivisione in funzioni e sistemi era corretta, ed è tentante riutilizzarlo. Ma riutilizzare un piano è diverso dal ripetere un risultato. La domanda non è se il piano era completo, ma se le ipotesi che contiene valgono ancora per questa deal, queste due organizzazioni e questo mercato.
Il riutilizzo funziona a livello della domanda, non a livello della risposta. Un piano precedente aveva una sequenza per i sistemi, una suddivisione delle funzioni che si univano o non si univano, e un elenco di dipendenze. Quella sequenza è utile come lista di controllo per non dimenticare nulla. Non è utile come risultato da copiare, perché il motivo per cui qualcosa la volta scorsa si univa dice poco sul fatto che debba farlo anche questa volta.
Ci sono alcuni segnali da verificare prima che un vecchio piano serva da base.
Primo: le due organizzazioni precedenti erano comparabili alle due attuali, per dimensione, per panorama di sistemi, per il grado in cui i clienti percepiscono la differenza. Un piano per due parti equivalenti non si adatta a un'acquisizione in cui una parte è un piccolo team aggiuntivo.
Secondo: è noto perché determinati componenti a suo tempo sono rimasti separati. Se quel motivo non è documentato, non si può valutare se ora debbano invece essere uniti. Un piano che mostra solo cosa è stato unificato, senza la valutazione del perché qualcosa è rimasto separato, vale per il riutilizzo meno di quanto sembri.
Terzo: il panorama di sistemi sottostante è comparabile. Unificare due sistemi ERP è un compito diverso dal lasciare coesistere due strumenti di pianificazione. Ciò che la volta scorsa era uno dei primi passi, questa volta può essere meglio lasciato da parte perché i sistemi stessi non sono comparabili.
Indipendentemente dal fatto che un piano sia nuovo o riutilizzato: per ogni componente deve porsi la domanda se unificare aggiunga comunque valore. Non è una domanda eccezionale per i casi dubbi. È un passaggio fisso, anche per componenti che a prima vista sembrano ovviamente destinati a unirsi.
Il motivo è che integrare comporta costi non sempre visibili in anticipo: tempo di persone che altrimenti lavorerebbero per i clienti o per la crescita, sistemi temporaneamente meno affidabili, team che diventano incerti sul proprio ruolo. Se a fronte di questo non c'è un beneficio dimostrabile, l'unificazione è una voce di costo senza compensazione. Quando l'integrazione distrugge valore non è quindi un caso limite ma un rischio strutturale in ogni piano che viene adottato senza questa verifica.
Ci sono componenti che spesso è meglio lasciare separati: un marchio con una relazione propria con i clienti, un team con una cultura che era il motivo dell'acquisizione, un sistema appena sostituito che non deve essere modificato di nuovo. Ciò che si lascia deliberatamente separato non è un elenco di compiti in sospeso ma una decisione con una propria motivazione, e quella motivazione deve essere documentata allo stesso modo del motivo per unificare qualcosa. Vedere cosa si lascia deliberatamente separato per come si presenta questa scelta.
Raramente un'intera acquisizione deve integrarsi nella sua totalità o per nulla. Di solito il risultato è un mix: centralizzare la rendicontazione finanziaria, lasciare separati i sistemi dei clienti, unificare parzialmente la politica HR. Ogni componente richiede la propria valutazione, con la propria tempistica e il proprio rischio. Come decidere per componente se integrare o no è quindi meno un piano d'azione che una domanda fissa posta separatamente per ogni componente, con la propria risposta.
Questa valutazione varia anche per settore. Nel settore delle costruzioni un'integrazione spesso si blocca sull'amministrazione di progetto e sui rapporti con i subappaltatori che non passano facilmente a un altro sistema; vedere dove si blocca un'integrazione nel settore delle costruzioni. Nel settore degli impianti sono più spesso i sistemi di pianificazione e i contratti di servizio che non si uniscono uno a uno; vedere dove si blocca un'integrazione nel settore degli impianti. Un piano riutilizzato che ignora queste differenze manca esattamente il componente in cui prima è andato storto.
I generatori per la baseline delle sinergie, il piano Day 1 e il piano Day 100 non si basano su un modello della deal precedente, ma sulla situazione inserita: quali componenti ci sono, quali sono le dipendenze, e quale motivo esiste per componente per unificare o no. L'ufficio di integrazione tiene poi traccia di quali vantaggi sono stati individuati, quali dipendenze sono ancora aperte, e quali componenti sono stati deliberatamente mantenuti separati. Questo non è una prova che funzioni — non c'è un percorso realizzato a cui fare riferimento — ma è una struttura che costringe a porre la domanda per componente invece di saltarla.
Mergerintegration.net è in costruzione. Chi desidera lavorarci non appena sarà disponibile può iscriversi alla lista d'attesa.
La domanda su quale parte di questo lavoro richieda tempo in prima persona e quale parte possa essere delegata non si pone solo nella pianificazione dell'integrazione. La scansione del lavoro di FTE TO AI calcola per ogni compito quale parte del lavoro può essere svolta dall'IA, offrendo così un quadro di dove si libera capacità prima che inizi un percorso di integrazione.
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.