mergerintegration Įtraukite mane į laukiančiųjų sąrašą

Kennisbank

Sprendimas kiekvienai daliai: integruoti ar ne

Po parašo seka prielaida, kad visa turi būti sujungta. Sistemos, komandos, procesai, prekių ženklai — sukurti vieną visumą atrodo kaip logiška sandorio pabaiga. Ta prielaida ne visada teisinga, ir dalys, kuriose ji neteisinga, dažniausiai atpažįstamos iš anksto.

Klausimas, kuris kartojasi su kiekviena dalimi

Integravimas yra pasirinkimas, ne automatizmas. Su kiekviena dalimi — sistema, komanda, kliento ryšiu, produktų linija — kyla klausimas, ar sujungimas kuria vertę, ar ją kainuoja. Šis klausimas nėra išimtis sunkiems atvejams. Tai standartinis klausimas, taikomas ir toms dalims, kurios atrodo savaime aiškios.

Priežastis, kodėl tai nepavyksta, dažniausiai nėra nenoras pažiūrėti. Tai laiko spaudimas. Turi būti Day 1 planas, sinergijos skaičiavimas turi susidėlioti, ir „integruoti“ yra trumpiausias kelias prie atsakymo, kuris popieriuje atrodo išsamus. Ko trūksta — momento, kai kas nors kiekvienai daliai fiksuoja: šitą sujungiame, šitą paliekame, ir kodėl.

Kur integravimas naikina vertę

Yra dėsningumai, kurie pastebimi iš anksto, ne tik po fakto. Dvi sistemos, atliekančios tą pačią funkciją, bet sukurtos skirtinga logika, sujungiant dažnai kainuoja daugiau konvertavimo ir mokymo laiko, nei duoda administravimo patogumo. Komanda, kuri veikia sparta ir trumpais bendravimo kanalais, praranda šią savybę, kai įsilieja į didesnę, sluoksniuotą struktūrą. Kliento ryšys, kuris priklauso nuo konkretaus žmogaus ar konkretaus darbo būdo, formaliai išgyvena integraciją, bet praktikoje dažnai ne.

Klausimas kada integravimas naikina vertę turėtų būti vietoje šalia kiekvieno sinergijos skaičiavimo, o ne po jo. Sinergijos skaičiavimas, kuris skaičiuoja tik sujungimo pelną, o ne dezintegracijos kaštus — vėlavimą, darbuotojų kaitą, klientų praradimą — yra tik pusė istorijos.

Sistemos: dalis su daugiausiai apgaulingo tikrumo

Sistemos yra ta dalis, kur integravimas dažniausiai laikomas savaime suprantamu dalyku, ir kur tai dažniausiai neteisinga. Sistema, kuri veikia gerai, yra įsišaknijusi komandoje, kuri ją naudoja, ir neduoda skubaus pagrindo pakeitimui, neprivalo išnykti tik todėl, kad priklauso kitam subjektui. Klausimas kurias sistemas geriau palikti kaip yra ir kaip tai atpažinti iš anksto priklauso kiekvienai IT inventorizacijai, o rezultatas kartais yra: nedaryti nieko, leisti dviem sistemoms egzistuoti greta, arba sprendimą priimti tik po metų.

Skirtumas tarp buy-and-build ir vienkartinių įsigijimų

Sprendimas integruoti ar ne taip pat priklauso nuo sandorio rūšies. Platformoje, kuri auga per keletą įsigijimų, integracijos modelis skiriasi nuo vienkartinio įsigijimo. Tai, ką buy-and-build reiškia jūsų integracijos strategijai ir kaip tai atpažinti yra kitas klausimas nei tas, kurio reikalauja vienkartinis įsigijimas: platformoje svarbu nuoseklumas per kelis įsigijimus, ir tai kartais tiesiog pasisako už integraciją tų dalių, kurios vienkartinio sandorio atveju geriau būtų paliktos kaip yra.

Tai taip pat susiję su ankstesnių planų pakartotiniu naudojimu. Platforma, kuri vykdo trečią ar ketvirtą įsigijimą, jau yra priėmusi sprendimus, kas buvo ir kas nebuvo sujungta ankstesniuose. Klausimas kaip pakartotinai naudoti integracijos planą ir kaip atpažinti, kurioms dalims tai veikia nustato, ar tie anksčiau priimti sprendimai yra pradžios taškas, ar spąstai — planas, kuris veikė ankstesniame sandoryje, automatiškai nebūtinai veiks šiame.

Nuo sektoriaus priklausantys sunkumai

Kur integracija užstringa, skiriasi pagal sektorių. Statybų sektoriuje sunkumai dažnai kyla projektų administravime, subrangovų ryšiuose ir leidimuose, priklausančiuose nuo konkretaus subjekto — žr. kur integracija užstringa statybų sektoriuje. Įrengimo pramonėje dažniau kalbama apie paslaugų sutartis, įrangos valdymą ir žmones, kurie praktiškai palaiko kliento ryšį — žr. kur integracija užstringa įrengimo pramonėje. Abu pavyzdžiai rodo, kad sprendimų sąrašas skirtingiems sektoriams į viršų kelia kitas dalis.

Ką čia daro įrankis

Sprendimas integruoti ar ne netampa patikimesnis, jį įtraukus į skaičiuoklę, tačiau tampa atsekamas. Sinergijos bazinė linija, Day 1 planas ir Day 100 planas yra generatoriai, kurie tam sprendimui duoda struktūrą: kiekvienai daliai fiksuojama, kokia yra prielaida, nuo ko ji priklauso, ir kada ji peržiūrima. Integracijos biuras seka priklausomybes ir laiko sprendimų sąrašą — kas taip, kas ne, ir kodėl — greta naudos sekimo, kad prielaida, kuri jau neatitinka tikrovės, matytųsi anksčiau, nei ji taptų brangi.

Tai nėra atliktų darbų sąrašas. Nėra užbaigto proceso, į kurį daroma nuoroda, ir įrankis nepretenduoja, kad integravimas vyksta geriau tik dėl to, kad jis struktūruotas. Ką jis daro — vėl kelia į darbotvarkę klausimą, kuris kitu atveju būtų praleistas, kiekvienai daliai atskirai.

Įrankis kuriamas. Kas norėtų naudoti generatorius ir integracijos biurą, kai jie bus pasiekiami, gali užsiregistruoti laukimo sąraše.

Klausimas, ką sujungiate ir ko ne, yra glaudžiai susijęs su kitu klausimu: kuri darbo dalis tam tikroje dalyje iš tikrųjų priklauso nuo užduočių, kurias galima automatizuoti, nepriklausomai nuo to, kuriam subjektui ta dalis galiausiai priklausys. FTE TO AI darbo skenavimas kiekvienai užduočiai apskaičiuoja, kokią darbo dalį gali perimti AI, ir taip suteikia kitokio pobūdžio bazinę liniją nei patį integracijos sprendimą — tokią, kuri parodo, kur atsiranda laisvos pajėgumo dalies, nepaisant to, kaip organizaciškai nusprendžiate.

Visionde assistent van het integratiekantoor

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.