Po sandorio prielaida dažnai jau būna paruošta: kas gali eiti kartu, turi eiti kartu. Ta prielaida kainuoja vertę vietose, kur niekas nežiūri, nes dėmesys krypsta į matomas dalis — sistemas, atskaitomybės linijas, valdymą. Tuo tarpu komanda, kuri ką tik pradėjo gerai veikti, sujungiama su komanda, kuri dirba kitaip, ir dingsta tiksliai ta priežastis, dėl kurios sandoris buvo patrauklus.
Klausimas „ar tai turi eiti kartu“ turėtų būti keliamas kiekvienai daliai, ne tik toms dalims, kurios krenta į akis. Tai nėra išimties taisyklė sudėtingiems atvejams. Tai standartinis klausimas, kuriame integravimas yra vienas iš dviejų galimų atsakymų.
Sprendimų sąrašas išskaido integraciją į atskiras dalis — sistemas, komandas, procesus, klientų santykius, prekės ženklus — ir kiekvienai daliai priverčia priimti sprendimą: sujungti, palikti atskirai, arba kažkur tarp to. Be tokio išskaidymo integracija tampa jausmu, o ne sprendimų rinkiniu. Su išskaidymu tampa aišku, kurie sprendimai grindžiami prielaidomis, o kurie – priežastimi.
Kiekvienai daliai galioja keli fiksuoti klausimai. Ar sujungimas duoda sinergiją, kuri atsveria tai, kas dabar veikia? Ar yra priklausomybė, kuri verčia rinktis vieną sistemą, ar tai tik įprotis iš ankstesnių integracijų? Kas prisiima riziką, jei kas nutinka blogai, ir ar ta rizika didesnė nei pelnas?
Yra atpažįstami modeliai, kai integravimas nėra neutralus pasirinkimas, o kaininga klaida.
Pardavimų komanda, kuri veikia santykių pagrindu, praranda savo galią, kai ją sujungia su komanda, kuri veikia proceso pagrindu — kultūrų susidūrimas iškart paveikia apyvartą, kuri turėjo pagrįsti sandorį. Klientų sistema su sava istorija ir savais ryšiais migravimo metu dažnai sukuria didesnę riziką nei efektyvumo naudą, ypač jei ta nauda egzistuoja daugiausia popieriuje. Prekės ženklas su sava klientų lojalumu tą lojalumą praranda, kai jį absorbuoja didesnis prekės ženklas, kurio klientas neprašė.
Bendra šiuose atvejuose: sinergija, kuri užrašyta popieriuje, yra mažesnė nei trikdymas, kurį sukelia integracija. Kas tai konkrečiai reiškia sistemoms, išsamiai aprašyta kurias sistemas geriau palikti kaip yra, o platesnis klausimas, kada šis modelis atsiranda, aptariamas kada integravimas naikina vertę, kaip tai pastebėti.
Palikimas atskirai kartais suprantamas kaip atidėjimas, kaip kažkas, kas dar turi įvykti. Tai klaidingas supratimas. Sąmoningas palikimas atskirai yra sprendimas su priežastimi, lygiai taip pat, kaip sujungimas yra sprendimas su priežastimi. Skirtumas tas, kad priežastis palikti atskirai dažnai rečiau užrašoma, nes su ja nesusijęs veiksmas, kurį reikėtų planuoti.
Toks tik priežastis „palikti atskirai“ turi būti fiksuojama tiek pat aiškiai, kiek priežastis „sujungti“ — kitaip vėliau neįmanoma prie jos sugrįžti, kai situacija pasikeičia. Kur tai galima pastebėti dar prieš priimant sprendimą, išsamiai aprašyta ką jūs sąmoningai paliekate atskirai, kaip tai pastebėti iš anksto.
Atliekant vienkartinį įsigijimą, sprendimų sąrašas yra gana fiksuotas: dvi organizacijos, vienas sprendimų rinkinys. Buy-and-build atveju tai pasikeičia. Kiekvienas naujas įsigijimas prideda dalis prie platformos, kuri jau turi priimtus sprendimus, ir klausimas tampa ne tik „sujungti su platforma ar ne“, bet ir „pagal kokį modelį, ir ar šis atvejis pagrįstai nuo jo nukrypsta“.
Ankstesnio įsigijimo sprendimų sąrašas tuomet tampa pradžios tašku, ne šablonu, kuris automatiškai galioja. Kas tai reiškia požiūriui, aprašyta ką buy-and-build reiškia jūsų integracijos požiūriui, o kaip pakartotinai naudoti ankstesnį planą jo aklai nekartojant, aprašyta kaip pakartotinai naudoti integracijos planą.
Sinergijos bazinės linijos, Day 1 plano ir Day 100 plano generatoriai, kartu su integracijos biuru naudos sekimui ir priklausomybėms, struktūrizuoja šiuos sprendimus. Jie fiksuoja, kuri dalis gavo kokį sprendimą, kokia priklausomybė tą sprendimą įtvirtina ir kokia sinergija jam priešinama. Jie nepriima sprendimo už jus. Nėra atlikto projekto, į kurį būtų galima remtis kaip įrodymą, kad tai veikia — tai struktūra sprendimui, kurį reikia priimti iš naujo kiekvienai daliai, su galimybe, kad integravimas yra neteisingas sprendimas. Kas tai konkrečiai reiškia konkrečiam atvejui, išsamiai aprašyta kaip nusprendžiate dėl kiekvienos dalies integruoti ar ne, kaip tai pastebėti.
Įrankis šiuo metu kuriamas. Norintys su juo dirbti gali registruotis į laukiančiųjų sąrašą.
Kai nustatoma, kuri dalis lieka atskirai ir kuri dalis sujungiama, kyla papildomas klausimas: kas atlieka darbą, kuris kyla iš to sprendimo, ir kiek to darbo yra pakankamai rutininio, kad jį būtų galima organizuoti kitaip. Sujungiant dvi apskaitas, dvi klientų aptarnavimo tarnybas ar dvi atskaitomybės linijas, dažnai kyla dvigubas darbas, kurį galima sumažinti, kol jis nėra įtvirtintas kaip nuolatinis. FTE TO AI darbo skenavimas apskaičiuoja kiekvienai užduočiai, kurią dalį to darbo galima perduoti DI, nepriklausomai nuo klausimo, ar pati dalis turi integruotis — antras žvilgsnis į tą pačią sprendimų sąrašą, šįkart iš užduočių, kurios iš jo kyla, perspektyvos.
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.