Labai dažnai sistemos užsakovo (organizacija, kuri perka sistemą) ir diegėjo dėmesys skiriasi sistemos įsigijimo ir diegimo etapuose ir tai, manau, yra viena iš pagrindinių  priežasčių, kodėl sistemos diegimas neįvyksta taip sėkmingai, kaip norėtume. Užsakovo iniciatyvos ir dėmesio trūkumas nulemia, kad ne užsakovas nusprendžia, kas (sistemos apimtis), kada (laikas)  ir už kiek (biudžetas ir mokėjimo sąlygos) turi būti įdiegta, o diegėjas.

 

 

Taigi, užsakovas pačioje pradžioje,  poreikio iniciavimo metu, kai reikia gauti vadovų/akcininkų pritarimą projekto iniciavimui, yra aktyvus, stengiasi, kad poreikis būtų išgirstas ir sprendimas daryti pokyčius įvyktų. Tačiau vėliau, apimties nustatymo metu, jo dėmesys sumažėja, nes vairą aktyviai perima diegėjas. Diegėjas matydamas pardavimo galimybę, domisi klientu ir pasisiūlo padėti suformuoti apimtį, ką sistema turės daryti ir kaip bus įgyvendintas projektas. Dažnai pasiūlo tai, kokius sprendimus pats turi ir moka įdiegti, bet tai nebūtinai atitinka tai, ko užsakovui iš tiesų reikia. Čia kaip su namo statyba, jeigu ateitų darbų vykdytojas ir sakytų: „aš žinau, ko jums reikia, viską padarysiu, niekuo nereiks rūpintis, Jūs pabaigoje ateisit tik raktelius pasiimti ir sumokėt“.  Ne visuomet rezultatas nudžiugina...

Taigi, nustačius apimtį, atranka dažnai teįvyksta tarp tų diegėjų, kurie aktyviai vykdė pardavimo veiksmus ir žinojo apie planuojamą pokytį. Bet tai nebūtinai visi potencialūs diegėjai ar geriausi sprendimai rinkoje. Vėlgi, dažnai užsakovas nepasidomi, kas dar galėtų suteikti tokias paslaugas, ar diegia panašius sprendimus.

Čia kaip su namo statyba, jeigu ateitų darbų vykdytojas ir sakytų: „aš žinau, ko jums reikia, viską padarysiu, niekuo nereiks rūpintis, Jūs pabaigoje ateisit tik raktelius pasiimti ir sumokėt“.

Sutarties sudarymo metu užsakovas kiek padidina savo dėmesį, nes kalba pakrypsta apie pinigus ir įsipareigojimus, tačiau vėlgi daugiau pastangų šiame etape skiria diegėjas. Tvarkaraštis, detali projekto apimtis, baudos ir netesybos taip ir lieka už sutarties sąlygų ribų.

Sistemos kūrimo ir diegimo metu abiejų dėmesys krenta. Užsakovas mato, kad kažkas iš diegėjo komandos vaikšto į organizaciją, klausinėja, siunčia dokumentus patvirtinti. Ne visuomet tie dokumentai suprantami, bet užsakovas ne visada išdrįsta paklausti, jei ko nesupranta, jei neaiški diagramų notacija ar per daug techniniai tekstai. Po kiek laiko diegėjas atneša paruoštą sistemą ir sako, kad jau galima naudotis, sistema paruošta.

Tada užsakovo dėmesys pakyla, nes reikia išmokti naudotis, pereiti prie naujos sistemos. Ir prasideda konfliktai: nepatogu, ne taip, kaip norim, reikia keisti procesus, mes veikiam ne visai standartiškai, kaip sistemoje numatyta, mes procesų dėl sistemos nekeisim ir pan. Prasideda pakeitimai. Čia diegėjo dėmesys vėl pakyla, natūralu, nes nauji užsakymai, kurie nebuvo numatyti pirminėje apimtyje. Taigi biudžetą viršijam, laike taip pat nepradedam dirbti su sistema, laukiam pakeitimų, kad sistema atitiktų tai, dėl ko pradėjome projektą.

Jei užsakovas padidintų dėmesį tose vietose, kur diegėjas itin aktyvus, kad ne diegėjas nuspręstų dėl apimties, geriausio sprendimo (produkto) bei sutarties sąlygų, galėtume sustiprinti savo pozicijas ir įsidiegti sprendimą, kuris būtų toks, kokiam ir turėjome poreikį.

 

Šią temą pratęsiu kitoje įžvalgoje,  į ką atkreipti dėmesį iki sistemos įsigijimo ir į kokius klausimus atsakyti užsakovui.