Pasaulinės tendencijos rodo, kad kasmet į programinę įrangą investuojama vis daugiau. Pavyzdžiui, rinkos tyrimų bendrovė „Gartner“ prognozuoja, kad šiemet įsigyti programinei įrangai bus skirta 5,6 proc. daugiau lėšų nei pernai, ir bendra išlaidų suma pasieks 332 mlrd. JAV dolerių.
Didėjančios investicijos ir lūkesčiai – svarbiausios priežastys, dėl kurių vis daugiau dėmesio skiriama informacinių sistemų vertinimo klausimams. Įvairūs atsiperkamumo ir naudos skaičiavimo metodai – populiari diskusijų tema jau ne tik tarp IT profesionalų, bet ir tarp verslo bei viešojo sektoriaus atstovų. Tačiau IT sistemos vertę ne visada paprasta paversti skaičiais. Dažnai sistemos kuriamos siekiant sunkiai pamatuojamų tikslų, pavyzdžiui, didesnio vartotojų pasitenkinimo arba organizacijos įvaizdžio pagerinimo. Nors tokių tikslų pasiekimas, be jokios abejonės, sukuria pridėtinę vertę, tiksliai ją pamatuoti – sudėtinga.
Tad apie tai, ką ir kaip skaičiuoti, vertinant IT sistemą – pokalbis su vienos didžiausių Lietuvoje programinių sprendimų kūrėjos – UAB „Blue Bridge Code“ – ekspertais: įmonės vadovu Giedriumi Slivinsku ir verslo plėtros vadovu Aivaru Liutvinu.
– Pradėkime nuo to, kas gi yra informacinės sistemos vertės matavimas?
Giedrius Slivinskas: Informacinės sistemos vertinimas dažniausiai suprantamas kaip kiekybinis procesas, kurio metu apskaičiuojama, ar sistemos įdiegimas atsipirks. Greta finansinių rodiklių labai svarbios ir sunkiau kiekybiškai pamatuojamos vertės – pavyzdžiui, išaugęs darbuotojų pasitenkinimas darbu, ir bendresnė nauda organizacijai – pavyzdžiui, netiesiogiai sutaupytas laikas arba pagerėjusios – bet nebūtinai atpigusios – paslaugos.
– Jeigu sistema – nedidelė, paprastesnė, jos naudą lengviau pamatuoti?
G. Slivinskas: Taip. Pavyzdžiui, jeigu kuriama sistema elektroninei parduotuvei, pagrindiniai vertės rodikliai aiškūs – tai gali būti vartotojų srautas, realių užsakymų skaičius ir t. t. Tačiau, jei kuriama sistema, kuri automatizuoja svarbiausius didelės kompanijos verslo procesus, pavyzdžiui, krovinių pervežimą, jos vertę apskaičiuoti sunkiau.
Pagal tai, kiek tiksliai įmanoma apskaičiuoti gaunamą vertę, išskirčiau kelias naudų grupes. Prie lengviausiai pamatuojamų priskirčiau aiškius tikslus, kurių įgyvendinimas yra svarbiausias vertės rodiklis. Pavyzdžiui, sistema įdiegiama norint pagreitinti pardavimų procesą viena valanda arba sumažinti darbuotojų skaičių. Jei šie tikslai pasiekiami – vertė sukurta. Sunkiau pamatuojamos naudos – tai kokybės pagerinimas, išaugęs pranašumas prieš konkurentus, padidėjęs pirkimų skaičius ir kiti gana abstraktūs tikslai.
– Tad konkretaus tikslo pasitelkimas – vienas paprasčiausių būdų, padedančių nustatyti sistemos vertę?
Aivaras Liutvinas: Šis būdas – iš tikrųjų vienas geriausių. Svarbu atsiminti, kad tikslas turi būti aiškus ir pamatuojamas, nes tuo aiškesni bus ir iš jo išplaukiantys rodikliai, kuriais bus vertinama sistemos nauda. Pavyzdžiui, jeigu norima pagreitinti aptarnavimo procesą viena valanda, jau po metų galėsite tiksliai žinoti, ar tikslas – pasiektas. Labai svarbu, kad šiuos tikslus žinotų ir sistemos kūrėjai.
Tačiau kai kada sistema kuriama siekiant kompleksinių, sudėtingų tikslų, kurie apima daug veiklų ir procesų. Tokiu atveju reikėtų didesnius tikslus suskaidyti į mažesnius. Juk sistemos kūrimas – ilgas procesas, ji nesukuriama vienu projektu. „Susmulkinus“ tikslus gali paaiškėti, kad pradžioje tik padėsite pamatą galutinių tikslų siekimui.
– Kokius tikslus tuomet surašyti techninėje specifikacijoje, kuria vadovausis sistemos kūrėjai? Abstraktesnius, galutinius ar konkretesnius ir mažesnius?
A. Liutvinas: Rekomenduočiau techninėje specifikacijoje nurodyti didžiuosius siekius, bet uždavinyje surašyti tik aiškiai apibrėžtus tikslus. Taip bus suprantama, ko siekiama ilgalaikėje perspektyvoje ir ko tikimasi iš šio žingsnio. Sistemos visuomet yra kuriamas turint ribotus resursus – ir finansinius, ir žmogiškuosius.
– Kaip geriausia įvertinti konkrečiausią – finansinę sistemos naudą?
G. Slivinskas: Vienas populiariausių metodų – projektų vertės nustatymas skaičiuojant investicijų grąžą, dar vadinamą ROI (angl. return on investment).
Ši grąža skaičiuojama pagal formulę ROI = (Grynasis pelnas / Investicijų dydžio) * 100 proc.
Norėčiau pabrėžti, kad vertinant ROI labai svarbu suskaičiuoti ne tik pradines investicijas, bet ir numatyti investicijas į sistemos vystymą bei priežiūrą. Dažnai apie šias išlaidas pamirštama. Sakyčiau, kad sistemos ir automobilio įsigijimas turi daug bendro. Kai nusiperkame automobilį, žinome, kad turėsime skirti pinigų kurui, padangų keitimui, rasti laiko techninei apžiūrai ir t. t. Tačiau perkant informacinę sistemą, dažnai pamirštama, kad jos išlaikymas irgi reikalauja papildomų pinigų ir laiko. Pavyzdžiui, po sistemos įdiegimo, jos veikimą turės prižiūrėti organizacijos IT specialistai. Galbūt po kurio laiko pasikeis organizacijos poreikiai, ir sistemą reikės patobulinti. Taigi – skaičiuojant atsipirkimą, negalima pamiršti sistemos išlaikymo sąnaudų. Tai labai svarbu padaryti pačioje pradžioje, nes gali paaiškėti, kad pinigų užtenka tik sistemos įsigijimui, bet ne jos išlaikymui.
– Kaip geriausia vertinti būsimos sistemos naudą, jei svarbiausią vaidmenį vaidina biudžetas – t. y. lėšos, kurias galima skirti sprendimui?
A. Liutvinas: Net jei atspirties taškas – konkreti pinigų suma, reikėtų žinoti, ką maždaug už šiuos pinigus norima įsigyti, ir kokią problemą išspręsti. Aišku, gali pasirodyti, kad išspręsti esmines problemas turint kuklų biudžetą – neįmanoma, tačiau bent jau pradėti jas spręsti – galima. Pavyzdžiui, įsivaizduokite, kad jums reikia nukeliauti iš taško A į tašką B, ir jūs žinote, kad patogiausia būtų skristi lėktuvu, tačiau neturite tam pinigų. Tačiau galbūt lėšų pakaktų dviračiui. Įsigyti bent iš dalies problemą sprendžiantį dviratį – daug racionaliau nei keliauti pėsčiomis arba įsigyti lėktuvo ratą, kuris be kitų dalių niekaip nepagelbės.
– Po kiek laiko galima tikėtis sistemos atsipirkimo?
A. Liutvinas: Grąžos galima tikėtis maždaug po 3 metų, tačiau šis laikas priklauso ir nuo organizacijos dydžio.
G. Slivinskas: Bet kuriuo atveju grąžai reikia laiko. Pavyzdžiui, nustatyta, kad pirmieji metai po sistemos įdiegimo yra „pripratimo“ prie sistemos metai. Tuo metu darbuotojai mokosi su ja dirbti, ir visi sistemos privalumai bus maksimaliai išnaudojami tik prabėgus šiam laikui.
