Sandorio komanda, kuri anksčiau integravo įsigijimą, dažnai turi paruoštą planą. Pirmos dienos kontrolinį sąrašą, sinergijos kategorijų sąrašą, komunikacijos grafiką. Pagunda didelė – išsitraukti tą dokumentą, pakeisti pavadinimus ir skaičius ir judėti toliau. Tai taupo laiką. Tai taupo ir apmąstymus, ir tai yra tiksliai ta problema.
Integracijos planas nėra organizacijos šablonas, tai yra rezultatas sprendimų, priimtų dėl kitokios įmonių kombinacijos. Kurios sistemos susijungia, kurios komandos susilieja, kurie klientų ryšiai lieka atskirti – tie sprendimai priklausė nuo to, kokios buvo ankstesnės dvi įmonės, o ne nuo to, kokios yra šios dvi įmonės. Pakartotinis plano naudojimas be pakartotinio šių pagrindinių sprendimų patikrinimo reiškia, kad perimate struktūrą, sukurtą kitai situacijai.
Rizika slypi ne formoje. Etapų suskirstymas, naudos sekimo priemonė (benefit-tracker), priklausomybių sąrašas – šios dalys dažnai visiškai tinka pakartotiniam naudojimui. Rizika slypi turinyje, kuris nepastebimai keliauja kartu: prielaida, kad X skyrius visada susijungia, kad Y sistema visada nutraukiama, kad kultūrinė integracija visada vykdoma tuo pačiu būdu. Šios prielaidos nėra neutralios. Jos yra precedentas, o precedentas jaučiasi kaip įrodymas, nors juo nėra.
Trys dalykai paprastai gerai persikelia iš vieno projekto į kitą:
Šios dalys yra metodas, ne rezultatas. Jos parodo, kaip prieinate prie atsakymo, o ne kas tas atsakymas yra. Šis skirtumas yra atsakingo pakartotinio naudojimo esmė: perimti procesą, ne išvadas.
Tai tampa rizikinga, kai ankstesnis planas apeina patį klausimą. Jei ankstesniame projekte buvo nustatyta, kad du pardavimų komandos susijungia, ir tai automatiškai perimama, nes „taip jau įprasta daryti“, tikimybė, kad tai teisinga ir šį kartą, priklauso nuo atsitiktinumo, ne nuo analizės. Daugiau apie tai, kada sujungimas naikina vertę ir kaip tai atpažinti, skaitykite kitame puslapyje, tačiau pastovus klausimas sugrįžta ir čia: ar šią dalį galbūt geriau būtų buvę palikti atskirai.
Tai ypač taikoma sistemoms. IT migracija, kuri buvo logiška ankstesniame sandoryje – nes įsigyta įmonė turėjo pasenusią platformą – nėra automatiškai logiška įmonei, kurios sistema tik ką atnaujinta ir gerai veikia. Kurias sistemas geriau palikti nepakeistas ir kaip tai atpažinti – yra atskiras svarstymas kiekvienai situacijai, ne taisyklė, perimta iš ankstesnio sandorio.
Organizacinė struktūra taip pat pažeidžiama aklo pakartotinio naudojimo. Jei ankstesniame plane buvo nustatyta, kad finansų skyriai visada sujungiami, tuomet su šiuo automatizmu dingsta klausimas, ar tai teisinga ir čia. Vykdant pirkimo ir plėtros (buy-and-build) strategiją, kai platforma pakartotinai prijungia įmones, pagunda taikyti vieną šabloną yra dar didesnė – ir būtinybė kiekvieną dalį pervertinti iš naujo tampa dar skubesnė. Tai, ko pirkimo ir plėtros metodas reikalauja iš jūsų integracijos strategijos ir kaip tai atpažinti, todėl nusipelno atskiro sprendimo kiekvienam įsigijimui, ne vieno pasikartojančio plano.
Veiksmingas metodas yra naudoti ankstesnį planą kaip klausimų kontrolinį sąrašą, kuriuos reikia užduoti iš naujo, o ne kaip jau nustatytų atsakymų sąrašą. Kiekvienai daliai, kuri ankstesniame plane buvo integruota, iš naujo užduodate klausimą, ar tai taikoma ir čia. Kiekvienai daliai, kuri liko atskira, klausiate savęs, ar ta priežastis taikoma ir čia. Tai, kaip struktūruojate šį sprendimą kiekvienai daliai – integruoti ar ne, ir kokiais kriterijais grindžiant – galiausiai nulemia rezultatą labiau nei tai, kaip greitai planas atsiduria popieriuje. Žr. taip pat, kaip sukurti šį sprendimą kiekvienai daliai ir kaip tai atpažinti: kaip nusprendžiate kiekvienai daliai, integruoti ar ne.
Tai, kas sąmoningai lieka atskira, pakartotinai naudojamame plane nusipelno tiek pat dėmesio, kiek ir tai, kas sujungiama. Planas, kuriame yra tik integracijos žingsniai ir nieko nepasakoma apie tai, kas aiškiai nesujungiama, praranda pusę sprendimo. Iš anksto aiškiai parodyti, kas liks atskira ir kodėl, apsaugo nuo to, kad šis pasirinkimas vėliau būtų aiškinamas kaip klaida. Daugiau apie tai: ką sąmoningai paliekate atskirai ir kaip tai iš anksto užfiksuojate.
Trys mergerintegration.net generatoriai ir integracijos biuras yra sukurti remiantis šiuo skirtumu: struktūra, kuri keliauja kartu, ne išvados, kurios slapta keliauja kartu. Sinergijos bazinė linija, Pirmos dienos planas ir 100-osios dienos planas kiekvienai situacijai kuriami iš naujo pagal tuos pačius klausimus, naudojant naudos sekimo priemonę ir sprendimų sąrašą, verčiantį duoti atsakymą kiekvienai daliai. Tai yra įrankis, kuris struktūruoja, ne patirtis, kuri garantuoja – įrankis yra kūrimo stadijoje, ir tie, kas norėtų juo pasinaudoti, gali registruotis į laukiančiųjų sąrašą.
Integracijos planas nusako, kas atlieka kokį darbą, kurie skyriai susijungia ir kurie procesai tęsiasi. Už šio klausimo slypi tikslesnis klausimas: kiek darbo, kuris bus atliekamas kartu ar atskirai, yra iš tikrųjų užduočių darbas, kurį galima automatizuoti. FTE TO AI darbo skenavimas (werkscan) apskaičiuoja kiekvienai užduočiai, kokią jos dalį galėtų perimti dirbtinis intelektas, ir tuo suteikia skaitmeninį pagrindą sprendimui, kuris kitaip būtų remiamas vien prielaidomis – tiksliai ta rizika, kuri tyko ir pakartotinai naudojamuose integracijos planuose.
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.