Kennisbank

Kai Day 100 nepasiekiama

Day 100 yra data, kurią integracijos komandos nustato pačios, o ne gamtos dėsnis. Kai ta data artėja ir planas neįgyvendintas, dažniausiai kyla sąmyšis: ar kažkas nepavyko, ar reikia spartinti, ar kas nors turi atsiskaityti? Šie klausimai suprantami, tačiau dažnai netikslūs. Tikslesnis pirmasis klausimas yra: kuri plano dalis nebuvo įvykdyta ir ką tai reiškia likusiai daliai.

Ne kiekviena neįvykdyta dalis sveria tiek pat

Day 100 plane yra sprendimų, kurie priklauso vienas nuo kito, ir sprendimų, kurie ne. Jei IT migracija užsitęsia, bet likusi organizacijos dalis dėl to nelaukia, tai kitokia problema nei tuomet, kai personalo sprendimas užsitęsia, o penkios kitos komandos jo laukia, kad galėtų tęsti darbą. Prieš nuspręsdami, kad Day 100 nepavyko, verta pažvelgti, kurie iš pradinių sprendimų iš tiesų buvo kritiniame kelyje ir kas tai stebėjo. Praleistas terminas sprendimui, kuris nieko neblokavo, nėra krizė. Praleistas terminas sprendimui, kurio visi laukė, yra kitas reikalas.

Šis skirtumas retai iš anksto aiškiai apibrėžiamas. Planai rašomi kaip datų sąrašas, o ne kaip priklausomybių tinklas. Kas vėliau turi išsiaiškinti, kiek iš tiesų kainuoja vėlavimas, dažnai atranda, kad priklausomybės niekada nebuvo aiškiai užfiksuotos. Todėl verta iš anksto nustatyti, kurios priklausomybės blokuoja likusią proceso dalį ir kas tai stebi. Be tokio žemėlapio kiekvienas vėlavimas yra netikėtumas, o ne tikėtina žinomos rizikos pasekmė.

Laukimo kaina retai paskirstoma tolygiai

Ne visi atidėti sprendimai kainuoja tiek pat. Sprendimas dėl bendros CRM sistemos gali palaukti, ir daug kas nepraras, tuo tarpu sprendimas, kas valdo klientų ryšius, veikia nuo pirmos dienos, ir atidėjimas ten iškart pastebimas klientams ir darbuotojams. Skirtumas tarp to, kas gali palaukti, ir to, kas ne, nėra pastovus: jis priklauso nuo sektoriaus, organizacijų sutapimo apimties ir kiek netikrumo ilgesnis laukimas sukelia žmonėms, kurie sprendimo laukia.

Siekiant nustatyti šį skirtumą, naudinga sprendimus rūšiuoti pagal tai, kiek iš tiesų kainuoja netikrumas, o ne pagal tai, kurį lengviausia pirmą imtis. Kai kurios komandos pirmiausia sprendžia tai, ką greičiausia priimti, tuo tarpu didžiausias netikrumo kaštas slypi visiškai kitur. Vienas iš būdų tai išvengti – rikiuoti sprendimus pagal kiek netikrumas kainuoja per kiekvieną dieną, kol sprendimas neprimtas. Tai duoda kitokią eilę nei planas, kuris tiesiog siekia visą darbą baigti per šimtą dienų.

Yra ir kita pusė: ne kiekvienas sprendimas turi būti priimtas per šimtą dienų, ir jo forsavimas gali pridaryti daugiau žalos nei atidėjimas. Kai kurie integracijos sprendimai geriau priimami po stebėjimo laikotarpio, kai aiškiau matoma, kaip dvi organizacijos iš tiesų dirba kartu. Todėl lygiai taip pat svarbu žinoti, kas gali palaukti po Day 100, kad procesas dėl to nesustotų, kaip ir žinoti, kas laukti negali. Praleistas terminas sprendimui, kurį geriau buvo priimti vėliau, nėra nesėkmė — tai korekcija.

Ką neįvykdyta Day 100 riba iš tiesų sako apie integracijos biurą

Kai Day 100 nepasiekiama, klausimas dažnai nesusijęs su konkrečiu sprendimu, o su struktūra, kuri turėjo stebėti sprendimus. Integracijos biuras, kuris seka tik datas sąraše, praleistą terminą pamato tik tada, kai jis jau praleistas. Integracijos biuras, kuris stebi priklausomybes ir netikrumo kaštus, vėlavimą pamato iš anksto ir gali laiku nuspręsti, ar reikia koreguoti kursą, ar atidėjimas yra priimtinas.

Tai susiję ir su platesniu klausimu, kaip organizuotas pats integracijos biuras. Biuras, perkrautas statuso atnaujinimais ir ataskaitomis, praranda apžvalgą tiksliai tuo metu, kai ji labiausiai reikalinga. Todėl verta apsvarstyti, kaip integracijos biuras išlieka funkcionalus ir kas tai stebi, kad praleistas terminas taptų signalu, o ne triukšmu perpildytoje pašto dėžutėje.

Be to, nėra vieno atsakymo į klausimą, ką daryti, kai Day 100 nepasiekiama: atsakymas priklauso nuo to, apie kokį sprendimą kalbame, kas jo laukia, ir ar vėlavimas iš tiesų kainuoja vertę, ar priešingai – apsaugo vertę, leidžiant išvengti skubotai priimto sprendimo. Kas šiuo klausimu ieško struktūros, o ne paruošto atsakymo, ras išsamų požiūrį puslapyje, kuris konkrečiai aptaria, ką daryti, kai Day 100 nepasiekiama, ir kas stebi šį procesą.

Integracija ne visada yra teisingas pasirinkimas

Su kiekviena neįvykdyta Day 100 plano dalimi susijęs ir esminis klausimas – ar tą dalį iš tiesų reikėjo sujungti. Kai kurios sistemos, komandos ar procesai iš integracijos nieko nelaimi, o tik praranda laiką ir dėmesį, kurio reikia kitur. Praleistas terminas yra geras momentas iš naujo užduoti šį klausimą, o ne tik stipriau stumti į pradinę datą.

Siekiant nustatyti, kurią integracijos proceso darbo dalį turi atlikti žmonės, ir kurią gali paremti DI, FTE TO AI pasiūlo darbo analizę, kuri kiekvienai užduočiai apskaičiuoja, kokią dalį galima perimti. Komandoms, kurios po neįvykdytos Day 100 ribos norėtų sužinoti, kur strigsta pajėgumai ir kur juos galima atlaisvinti, tai konkretus pradžios taškas.