Pirmosiomis šimtu dienų po sandorio problema dažnai atrodo kaip sprendimų trūkumas. Dažniau problema yra eiliškumas. Sprendimas dėl bendros ERP sistemos blokuoja atskaitomybės linijų sutvarkymą. Sprendimas dėl to, kas gauna komercinį mandatą, blokuoja kiekvieną pokalbį su bendrais klientais. Kol niekas neįvardija šios priklausomybės, dvi komandos vienu metu laukia vienos kitos, ir niekas to nepastebi.
Ne kiekvienas atidėtas sprendimas yra problema. Kai kurie dalykai gali palaukti, kad likusi dalis nesustotų — kurie tai dalykai ir kas gali tai nuspręsti, aprašyta puslapyje apie tai, kas gali palaukti iki 100-osios dienos. Blokuotas sprendimas yra kitas dalykas: tai sprendimas, nuo kurio priklauso kiti sprendimai, ir kuris tuos kitus sprendimus akivaizdžiai sulaiko. Šis skirtumas ne visada matomas iš vienos komandos perspektyvos. Finansų skyrius nemato, kad jo laukimas dėl sistemos pasirinkimo taip pat sustabdo HR integraciją, nes atlyginimų lapeliai priklauso nuo tos pačios sistemos. Šie ryšiai tampa matomi tik tada, kai kažkas juos aiškiai susisteminimas, nepriklausomai nuo to, kurio skyriaus eilė atsitiktinai yra paskutinė.
Blokuoto sprendimo kaina retai būna fiksuota suma per savaitę. Ji priklauso nuo to, kas sustojo: kainos susitarimas, kurio negalima peržiūrėti, kol produktų portfelis nesujungtas, pagrindinis darbuotojas, kuris palieka organizaciją, nes niekas nepaaiškina jo vaidmens, klientas, kuris pereina pas konkurentą, nes dvi klientų aptarnavimo komandos vienai kitai prieštarauja. Tai nėra skaičiai, kuriuos galima iš anksto apskaičiuoti. Tačiau juos galima sisteminti: koks sprendimas paveikia kiek kitų sprendimų, ir kokia yra žalos prigimtis, jei tai užtrunka ilgiau. Šis sisteminimas — pagal neapibrėžtumą ir pasekmes, o ne pagal tai, kas garsiausiai šaukia — aprašytas puslapyje apie sprendimų rikiavimą pagal neapibrėžtumo kaštus.
Sisteminant blokuojančius sprendimus, yra klausimas, kurio negalima praleisti: ar šią dalį iš tikrųjų reikia integruoti. Priklausomybės sprendimas, sujungiant dvi sistemas, nėra automatiškai geresnis nei jų egzistavimas lygiagrečiai. Kartais greičiausias būdas pašalinti blokadą yra nuspręsti, kad integracija tame punkte nesukuria vertės. Šis sprendimas neturėtų būti priimtas tyliai, nes niekas neuždavė klausimo; jis turėtų būti aiškiai keliamas ant stalo, kartu su klausimu, kada ir kokia eilės tvarka tai daryti.
Blokuojančių sprendimų sąrašas jau integracijos pirmąją dieną yra neišsamus, ir tampa toks tuo greičiau, kuo daugiau sprendimų priimama. Naujos priklausomybės atsiranda tuo pačiu metu, kai sprendžiamos senos: sistema pasirinkta, ir dabar paaiškėja, kad įgyvendinimas priklauso nuo dar veikiančios sutarties su tiekėju. Kažkas turi šį žemėlapį nuolat atnaujinti, ne kaip vienkartinį pratimą pirmąją savaitę, o kaip nuolatinę užduotį — kitaip blokada tiesiog persikelia į kitą vietą. Kas atlieka šį vaidmenį ir kaip šis asmuo užtikrina, kad žemėlapis pats netaptų vilkinančia biurokratija, aprašyta puslapyje apie integracijos biuro veiksmingumo palaikymą.
Blokuoti sprendimai dažnai yra priežastis, kodėl 100-osios dienos planas nepasiekiamas — ne dėl to, kad planas buvo klaidingas, o dėl to, kad priklausomybė buvo nuvertinta. Kurie sprendimai bet kuriuo atveju turi būti priimti per pirmąsias šimtą dienų ir kas užtikrina, kad jie tikrai būtų priimti, aprašyta puslapyje apie sprendimus pirmosiomis šimtu dienų. Ką daryti, jei terminas visgi nepasiekiamas — kurie sprendimai tada iš naujo prioritetizuojami ir kas tai sprendžia — aprašyta puslapyje apie 100-osios dienos termino nepasiekimą. Blokados signalizavimas nėra tas pats, kas jos sprendimas, tačiau nesignalizuojant, vėlavimas išlieka nematomas iki tos akimirkos, kai ataskaita turi būti pateikta.
mergerintegration.net generatoriai ir integracijos biuras sistemina šias priklausomybes: jie nustato, kuris sprendimas laukia kito sprendimo, ir kuri organizacijos dalis dėl to sustoja. Tai nėra atliktų darbų sąrašas — nėra įvykdyto projekto, kuriuo šis įrankis remtųsi, ir čia tai nėra teigiama. Tai būdas aiškiai užduoti klausimą, prieš vėlavimui tampant matomam skaičiuose, kurių niekas negalės pataisyti. Kas norėtų su tuo dirbti, gali užsiregistruoti į laukiančiųjų sąrašą; įrankis kuriamas.
Dalis laiko, prarasto dėl blokuotų sprendimų, sunaudojama darbui, kurį žmonės daro ranka, nors jį galima automatizuoti: klientų sąrašų sujungimui, sutarčių sąlygų palyginimui, priklausomybių žemėlapio, kuris kinta po kiekvieno susitikimo, atnaujinimui. FTE TO AI darbo skanavimas apskaičiuoja kiekvienai užduočiai, kokią jos dalį gali perimti dirbtinis intelektas, ir taip parodo, kur atsiranda laisvų pajėgumų, kurie kitu atveju būtų buvę skirti pačiai integracijai.
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.