Informācijas sistēmas ir sarežģītas kā no tehnoloģiskā un organizatoriskā, tā arī no ekonomiskā viedokļa, tādēļ ir grūti novērtēt šādu sistēmu ieviešanai un uzturēšanai nepieciešamo finansējumu un iegūto rezultātu. Tiek uzskatīts, ka 50%–70% IT projekti izgāžas, jeb neizpilda sākotnējo mērķa definīciju.
Šajā rakstā esmu apkopojis galvenās konceptuālās kļūdas, kas noved pie IT projektu neveiksmēm un veidu kādiem aspektiem pievērst uzmanību, lai šo risku ietekmi minimizētu.
Mēs pērkam produktu, kas paaugstinās mūsu biznesa procesu produktivitāti vai kvalitāti
Piemēram, gadās ka pasūtītājs informācijas sistēmas izveides projektu uztver vienkāršotā veidā un sagaida, ka projekta rezultātā tas saņems kaut kādu gatavu tehnisku produktu – tādu kā ledusskapi, ko vienreiz nopērk un tad tas 10 gadus pilnīgi vienādi funkcionē.
Taču informācijas sistēma nav tāds produkts kā ledusskapis, bet gan drīzāk tāds veidojums kā pilsēta. Pilsēta, kura attīstās, un kurā notiek pārbūves, ir jāveic remonti, jāļauj iebraukt svešiniekiem un jāseko līdzi vai tiek ievēroti noteikumi. Visiem šiem pilsētas izmantošanas, attīstības un uzturēšanas darbiem nepieciešams noteikts daudzums un specialitātes cilvēku, kas ir neatņemama šīs pilsētas sastāvdaļa, jo bez tiem pilsēta nefunkcionē.
Kam ir jāuzņemas atbildība par IT projektu?
Bieži vien var novērot, ka IT projekta vadība, lēmumu pieņemšana vai sagatavošana tiek nodota IT speciālistiem. Turklāt šādu pieeju realizē ne vien mazas organizācijas, bet arī lielas un pat valdības.
Lai arī IT speciālisti ir nozīmīgi IT projektā, taču ir jāņem vērā dažādu interešu savstarpējais līdzsvars, lai radītu tādu sistēmu, kas ilgtermiņā nodrošinās izvirzītos mērķus.
Kad veido projekta komandu ir jābūt pārstāvētām šādām lomām, kompetencēm un interesēm:
- Projekta vadītājs – lai cik apjomīgs nebūtu projekts, galvenajam izpildītājam un atbildīgajam ir jābūt vienai personai, jo kolektīvā atbildība ir daudzkārt pierādīts kā neefektīvs mehānisms.
- IT direktors – persona vai grupa, kas atbild par infrastruktūras attīstību, konkrētām tehnoloģijām un to dzīvotspēju ilgtermiņā, par sadarbību ar citām sistēmām, par tehniskā personāla un ārpakalpojumu piesaisti.
- Izstrādātājs – persona vai organizācija, kam piemīt tehniskās spējas izveidot programmatūras produktu, kā arī sniegt konsultācijas biznesa pārstāvjiem par labāko praksi un izmaksām.
- Biznesa pārstāvji – biznesa analītiķi, sistēmanalītīki, procesu atbildīgie. Šie ir galvenie prasību definētāji un tādēļ tie faktiski nosaka to, kāda sistēma tiks veidota. Taču šī nav viendabīga un vienprātīga cilvēku grupa, un šo personu iekšienē ir jāveido lēmumu pieņemšanas process. Tipiski tiek noteikta atbildīgā persona vai organizācija, kas izlemj prioritātes un to kuras prasības vispār nepieciešams realizēt.
- Uzturētāji – šīs ir personas, kas nodrošinās un koordinēs kā tehnisku, tā arī funkcionālu un saturisku sistēmas darbību, kā arī nodrošinās izmaiņu vadību. Kļūdaini ir šīs personas pieslēgt projektā vēlu sistēmas ieviešanas ciklā, jo tad bieži vairs nav iespējams kvalitatīvi realizēt daudzas uzturētāju prasības. Turklāt jābūt mehānismam, kā uzturēšanas, izmaiņu vadības un investīciju lēmumu pieņemšanu nodot augstākstāvošām instancēm.
- Finanses un izmaksas – grāmatvedība uzskaita faktus, taču investīciju atdevi, izmaksu kapitalizēšanas un nolietojuma apmērus definē kāds, kurš domā par projekta ekonomisko izdevīgumu. Bieži vien nav šādas atsevišķas lomas projektā un tādēļ arī ekonomiskais izdevīgums ir tik neskaidrs, turklāt šādam ekonomistam būtu jāpārzina konkrētā biznesa un izmantoto tehnoloģiju nozares, lai spētu izdarīt nākotnes prognozes. Ja šīs lomas pienākumus neviens neveic, tad pastāv risks, ka izmaksas apjomus nevarēs laicīgi prognozēt un kontrolēt.
- Sadarbības partneri – resursu apmaiņas partneri, likumdošanas procesa partneri un citi, kas var būtiski ietekmēt projekta rezultātu, taču uz tiem nav tiešas ietekmes. Risku vadības pasākumu plānā ir jāparedz, ko darīt situācijās, tad kad šie partneri neveiks no tiem sagaidīto. Risku mazināšanas pasākumu plāns var būtiski mainīt iecerēto projekta gaitu vai pat mērķi.
Varētu domāt, ka mazos projektos nav visu šo lomu, taču pat ja atbildīgais par visu sistēmu ir tikai viens cilvēks, tāpat ir jāpārliecinās, kā tiks realizētas šīs dažādās pieejas un pārstāvētas šīs atšķirīgās intereses. Taču liela apjoma projektos, veidojot projekta komandu un nospraužot mērķus, ir jācenšas panākt interešu līdzsvaru, pienākumu un tiesību līdzsvaru, ambīciju un iespēju līdzsvars.
Projekta mērķu izvirzīšana
Atgriežoties par līdzību ar ledusskapi un pilsētu, varam viegli iztēloties kādas būs ledusskapja funkcijas, kad tas tiktu uzstādīts, taču pilsētas, katra ir savādāka, piemēram, viena ir pie upes, bet cita kalnā, vienā ir veselīgi iedzīvotāji, bet citā ir liegums būvēt namus augstākus par 5 stāviem. Tātad pielietojamie risinājumi un pat rezultāti ir atšķirīgi katrā konkrētajā gadījumā. Mūsdienās ir izplatīta Agile metožu izmantošana projektu vadībā, kas ļauj definēt un realizēt īstermiņa mērķus. Tas ļauj arī laicīgi reaģēt un pielāgoties dažādiem informācijas sistēmas attīstības pavērsieniem. Kas ir ļoti adekvāta pieeja mūsdienu mainīgajā ikdienā. Taču nedrīkst šo Agile attīstības procesu atstāt bez ilgtermiņa vīzijas un investīciju uzraudzības, jo investētais apjoms rada saistības nākotnē, jeb jo vairāk investē, jo lielākas ir sistēmas atjaunošanas un uzturēšanas izmaksas.
Uzturēšanas izmaksas
Bieži vien Eiropas Savienības finansētos projektos redzu, ka informācijas sistēmai ir piešķirts dāsns finansējums un valsts pārstāvji cenšas izdomāt maksimāli daudz funkciju, ko šīs sistēma varētu nodrošināt, lai tikai apgūtu visu pieejamo finansējumu. Taču līdzīga pieeja var arī būt tad, ja nav pieejams dāsns finansējums, piemēram, mazais uzņēmējs, kas grib vienā investīciju reizē atrisināt vairākas problēmas un tādēļ izvirza vairākus mērķus ar domu, “lai vēlāk pie šī jautājuma nebūtu jāatgriežas”. Taču jo vairāk finansējuma tiek ieguldīts un vairāk funkciju nodrošināts, jo augstākas ir [kapitāla] atjaunošanas un uzturēšanas izmaksas. Sistēmas īpašnieki cer, ka šīs izmaksas kaut kā uzsūks jau eksistējošais finansējums un biznesa procesi. Taču tā ir ilūzija, kas nestrādā ilgtermiņā.
Ja sistēmai nav pietiekams uzturēšanas budžets, tā strauji zaudē savu vērtību un pakāpeniski arī nodrošināto produktivitāti. Šo vērtības kritumu bieži sākotnēji pamana tikai eksperti un tādēļ viņu pieprasījumi pēc papildus finansējuma bieži tiek noraidīti, jo šos papildus tēriņus grūti sasaistīt ar konkrētu labumu nodrošinātajiem biznesa procesiem. Taču šis neredzamais parāds uzkrājas, un ar laiku izpaužas kā ilga un dārga izmaiņu ieviešana vai nepietiekams, noslogots vai nepieredzējis atbalsta personāls.
Tātad investējot informācijas sistēmā, jātiecas uz to, lai mazinātu investīciju apjomu un uzturētu atbilstošu atjaunošanas un uzturēšanas finansējuma līmeni, kas ir proporcionāls kopējam investīciju apjomam, jeb noteikts procents no kopējās ieguldītās summas. Jāņem vērā, ka atjaunošanas un uzturēšanas budžeta proporcija pret ieguldījumiem ir nemainīga, bet nomināli tā ir nemitīgi pieaugoša summa, ko nepieciešams ieplānot kā pieaugošas izmaksas. Ir jāievieš arī process, kas nodrošina kapitāla un funkcionalitātes samazināšanu. Piemēram, ja sistēmā kādu reģistru vai funkciju vairs nelieto tādā apjomā kā agrāk, tad iespējams to var likvidēt.