Ankstesnio sandorio integracijos planas dažnai jau yra parengtas. Struktūra veikė, funkcijų ir sistemų suskirstymas buvo tinkamas, ir kyla pagunda jį panaudoti pakartotinai. Tačiau plano pakartotinis naudojimas skiriasi nuo rezultato kartojimo. Klausimas nėra, ar planas buvo išsamus, o ar jame esančios prielaidos vis dar taikomos šiam sandoriui, šioms dviem organizacijoms ir šiai rinkai.
Pakartotinis naudojimas veikia klausimo lygmenyje, ne atsakymo lygmenyje. Ankstesnis planas turėjo sistemų eiliškumą, funkcijų suskirstymą, kurios jungiamos, kurios ne, ir priklausomybių sąrašą. Tas eiliškumas naudingas kaip kontrolinis sąrašas, kad nieko nepamirštumėte. Jis nenaudingas kaip rezultatas, kurį galima nukopijuoti, nes priežastis, kodėl kažkas buvo sujungta praeitą kartą, mažai pasako, ar tai reikia daryti ir šį kartą.
Yra kelios požymiai, kuriuos verta patikrinti prieš senąjį planą naudojant kaip pagrindą.
Pirma: ar tos dvi ankstesnės organizacijos buvo panašios į dabartines dvi – dydžiu, sistemų architektūra, tuo, kiek klientai pastebi skirtumą. Planas, sukurtas dviems lygiavertėms šalims, netinka įsigijimui, kai viena šalis yra nedidelė papildoma komanda.
Antra: ar žinoma, kodėl tuomet kai kurios dalys buvo paliktos atskirai. Jei ta priežastis nebuvo užfiksuota, neįmanoma įvertinti, ar jas dabar reikia sujungti. Planas, kuris parodo tik tai, kas buvo sujungta, bet neatskleidžia svarstymo, kodėl kažkas buvo paliktas atskirai, pakartotiniam naudojimui yra mažiau vertingas, nei atrodo.
Trečia: ar pagrindinė sistemų architektūra yra panaši. Dviejų ERP sistemų sujungimas yra kitokia užduotis nei dviejų planavimo įrankių palikimas veikti paraleliai. Kas praeitą kartą buvo vienas iš pirmųjų žingsnių, šį kartą gali geriau likti neliestas, nes pačios sistemos nėra panašios.
Nesvarbu, ar planas naujas, ar pakartotinai naudojamas: kiekvienai daliai turi būti keliamas klausimas, ar sujungimas iš viso pridės vertės. Tai ne išimtinis klausimas neaiškiems atvejams. Tai nuolatinis žingsnis, taip pat ir toms dalims, kurios iš pirmo žvilgsnio akivaizdžiai turėtų būti sujungtos.
Priežastis ta, kad integravimas susijęs su sąnaudomis, kurios ne visada iš anksto matomos: žmonių laikas, kuris kitu atveju būtų skirtas klientams ar augimui, sistemos, kurios laikinai mažiau patikimos, komandos, kurios pradeda nerimauti dėl savo vaidmens. Jei tam nėra pagrįsto naudos priešpastatymo, sujungimas yra sąnaudų punktas be kompensacijos. Kada integravimas naikina vertę tuomet nėra pakraštinis atvejis, o struktūrinė rizika kiekvienam planui, kuris perimamas neatlikus šio patikrinimo.
Yra dalių, kurias dažniausiai geriau palikti atskirai: prekės ženklas su savo kliento santykiu, komanda su kultūra, kuri buvo įsigijimo priežastis, sistema, kuri tik ką pakeista ir jos vėl keisti nereikia. Tai, ką sąmoningai paliekate atskirai, nėra neatliktų darbų sąrašas, o sprendimas su savo priežastimi, ir ta priežastis turi būti dokumentuota lygiai taip pat, kaip priežastis kažką sujungti. Žr. ką jūs sąmoningai paliekate atskirai, kaip toks pasirinkimas atrodo.
Retai pasitaiko, kad visas įsigijimas kaip visuma turėtų būti integruotas arba ne. Dažniausiai rezultatas yra mišinys: finansinė atskaitomybė centralizuojama, kliento sistemos paliekamos atskirai, personalo politika sujungiama iš dalies. Kiekviena dalis reikalauja savo atskiro svarstymo, su savo laiko juosta ir savo rizika. Kaip nusprendžiate kiekvienai daliai integruoti ar ne tuomet yra mažiau žingsnių planas, o daugiau nuolatinis klausimas, keliamas kiekvienai daliai atskirai, su savo atsakymu.
Šis svarstymas skiriasi ir pagal sektorių. Statybų sektoriuje integracija dažnai užstringa dėl projektų administravimo ir subrangovų santykių, kurie nesikeičia vienareikšmiškai į kitą sistemą; žr. kur integracija užstringa statybų sektoriuje. Įrangos montavimo sektoriuje dažniau tai yra planavimo sistemos ir paslaugų sutartys, kurios nesijungia tiesiogiai; žr. kur integracija užstringa įrangos montavimo sektoriuje. Pakartotinai naudojamas planas, kuris ignoruoja šiuos skirtumus, praleidžia tiksliai tą dalį, kur anksčiau kilo problemų.
Sinergijos bazinės linijos, Day 1 plano ir Day 100 plano generatoriai nesikuria pagal ankstesnio sandorio šabloną, bet pagal įvestą situaciją: kokios dalys egzistuoja, kokios yra priklausomybės, ir kokia priežastis kiekvienai daliai sujungti ar ne. Integracijos biuras toliau seka, kokia nauda buvo įvardyta, kokios priklausomybės neišspręstos, ir kokios dalys sąmoningai paliktos atskirai. Tai nėra įrodymas, kad tai veikia — nėra atlikto proceso, į kurį galima remtis — tačiau tai yra struktūra, kuri priverčia klausimą kiekvienai daliai keliamą, o ne praleidžiamą.
Mergerintegration.net yra kuriamas. Kas norėtų su tuo dirbti, kai jis bus prieinamas, gali užsirašyti į laukiančiųjų sąrašą.
Klausimas, kuri dalis šio darbo pati sunaudoja laiką, o kurią dalį galima perimti, kyla ne tik integracijos planavimo atveju. FTE TO AI darbo skanavimas apskaičiuoja kiekvienai užduočiai, kokią darbo dalį gali perimti DI, ir taip parodo, kur atsiranda laisvas pajėgumas prieš integracijos procesui pradedant.
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.