Pasirašius sutartį prasideda laikotarpis, kuriame priimama dauguma neatšaukiamų sprendimų: kurios sistemos susijungia, kas kam atsiskaito, kurie klientai pastebi pokyčius pirmiausia. Kyla pagunda šį laikotarpį pavadinti vykdymo laikotarpiu, tarsi planas jau būtų sudarytas. Dažniausiai jis nėra sudarytas. Pirmosios šimtas dienų yra sprendimų priėmimo laikotarpis, ir šių sprendimų kokybė nulemia daugiau nei greitis, kuriuo jie įgyvendinami.
Ne kiekvienas sprendimas tinka šiam laikotarpiui. Kai kurie klausimai gali palaukti, kol atsiras daugiau informacijos; kiti tampa brangesni, kuo ilgiau laukiate. Šis skirtumas savaime yra sprendimas, ir jį dažnai praleidžiama, nes visi mieliau imasi darbo, nei iš pradžių išsiaiškina, ką tas darbo pradėjimas iš tikrųjų reiškia.
Eiliškumas, kuriuo priimami sprendimai, dažnai yra svarbesnis nei patys sprendimai. Sprendimas dėl klientų valdymo sistemos, priimtas per anksti, kol nėra aišku, kuris verslo modelis išlieka, gali padaryti vėlesnį sprendimą neįmanomą. Sprendimas dėl atskaitomybės linijų, priimtas pernelyg vėlai, palieka organizaciją savaitėms be aiškumo, kas dėl ko sprendžia.
Naudinga rikiuoti sprendimus ne pagal tai, kas atrodo skubiausia, o pagal tai, kas taps brangiausia, jei liks neaišku. Kai kurie neaiškumai kainuoja nedaug, jei liks neišspręsti kelias savaites; kiti kainuoja pinigus ar žmones kiekvieną dieną. Norintiems tai susisteminti, verta pažvelgti į kaip rikiuoti sprendimus pagal neaiškumo kaštus, nes šie kaštai nebūtinai atitinka tai, kaip svarbiai sprendimas atrodo popieriuje.
Prie kiekvieno sprendimo dėl integracijos priklauso pirminis klausimas, kuris dažnai praleidžiamas: ar šią dalį iš tikrųjų reikia sujungti. Dviejų pardavimų komandų sujungimas, nes tai skamba logiškai, gali sutrikdyti sklandžiai dirbančią komandą, o kita pusė iš to nieko nelaimi. Dviejų IT sistemų sujungimas, nes tai atrodo paprasčiau, gali sukurti metų metus trunkančią techninę skolą dėl sutaupymo, kuris niekada neatsiranda.
Klausimas, ar kažkas iš tikrųjų turi susijungti, nėra išimtis, kurią keliate abejotinais atvejais. Tai standartinis klausimas kiekvienai daliai, ir atsakymas gali būti tiek „palikti atskirai“, tiek „integruoti“. Sinergijų bazinė linija, Day 1 planas ir Day 100 planas yra įrankiai šiam klausimui atsakyti kiekvienai daliai, o ne būdas iš anksto patvirtinti integraciją kaip pradinę prielaidą.
Kai kurie sprendimai blokuoja kitus. Sprendimas dėl ERP sistemos gali nulemti, ar finansinę atskaitomybę galima sujungti. Sprendimas dėl prekės ženklo pavadinimo gali nulemti, ar marketingo komandos gali pradėti darbą. Kas šių blokavimų nesuplanuoja iš anksto, aptinka jas tada, kai komanda įstringa ir niekas negali pasakyti, kodėl.
Todėl kokios priklausomybės blokuoja likusią proceso dalį susiplanuoti nėra vėlesnis administracinis žingsnis, o eiliškumo nustatymo dalis. Popieriuje mažas sprendimas gali būti šliuzas, nuo kurio priklauso dešimt kitų sprendimų.
Šimtas dienų yra svarbus etapas, ne terminas su bauda. Kai kurie sprendimai per šimtą dienų vis tiek nebūna sunokę, nes trūksta informacijos arba nes pirmosios savaitės reikalauja kitų prioritetų. Tai savaime nėra nesėkmė, bet ja tampa, jei niekas nenustato, kas tada vyksta.
Kas norėtų žinoti, ką daryti, jei Day 100 planas neįgyvendintas, turėtų šį scenarijų apsvarstyti iš anksto, o ne atrasti jį devyniasdešimtąją dieną. Tai vienas iš nedaugelio momentų, kai integracijos biuras turi pats save pataisyti, ir tai neturėtų būti vertinama kaip nesėkmė.
Integracijos biuras, kuris norės detaliai stebėti kiekvieną priklausomybę, kiekvieną sprendimą ir kiekvieną sinergiją, paskęs savo pačiu administravime. Klausimas nėra, kiek daug reikia sekti, o kiek daug turi likti sekama, kad pats sekimas nepavirstų projektu. Norintiems rasti šią pusiausvyrą, tai susiję su kaip išlaikyti integracijos biurą valdomą, kur sekimas tarnauja sprendimams paremti, o ne pats save pagrįsti.
Trys generatoriai ir integracijos biuras suteikia struktūrą: sinergijų bazinę liniją, nuo kurios matuoti, Day 1 planą pirmajai savaitei, Day 100 planą vėlesniam laikotarpiui ir vietą priklausomybėms ir sprendimų sąrašui, ką integruoti, o ko ne, sekti. Jie nepakeičia patirties ir negarantuoja rezultato. Jie susistemina, ką reikia nuspręsti, kad žmonės, priimantys sprendimus, tai darytų turėdami bendrą vaizdą, o ne pavienius užrašus iš pavienių susitikimų.
Šis įrankis kuriamas. Norintys pirmieji gauti prieigą, kai jis taps prieinamas, gali užsirašyti į laukimo sąrašą.
Kai aišku, kokie sprendimai priimami per pirmąsias šimtą dienų, savaime kyla klausimas, kas atlieka tolesnį darbą: kas migruoja sistemas, kas sujungia ataskaitas, kas rašo komunikaciją klientams. Dalis šio darbo yra pakankamai pasikartojanti, kad į ją būtų galima pažvelgti kitaip. FTE TO AI darbo skanavimas apskaičiuoja pagal užduotį, kokią darbo dalį galima perduoti AI, kad likusi pajėgumo dalis atitektų sprendimams, kuriems iš tikrųjų reikia žmonių.
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.