Bieži sastopamies ar situāciju, kad jaunas programmatūras, tai skaitā IT bāzētu biznesa vadības programmu (ERP), ieviešana uzņēmumā beidzas ar fiasko. Problēma nav vietēja, tā ir labi pazīstama jebkur pasaulē un vienmēr šī neveiksme nozīmē lielas izmaksas.
Šveicē praktizējošais nozares profesionālis Avigdors Lutingers (Avigdor Luttinger) atzīst: „Liekas, kaut arī skaitļošanas un izstrādes rīki ir kļuvuši ievērojami labāki gadu gaitā, projektu fiasko proporcija tomēr paliek neadekvāti augsta, kas padara IT projektus sevišķi nepievilcīgus organizācijām, kuras cenšas uzlabot konkurētspēju šodienas recesijas klimatā."
Kādēļ veidojas šāda situācija, un kā izvairīties no fiasko? Programmatūras izvēle, pielāgošana uzņēmuma korporatīvajām prasībām un standartiem un ieviešana ir arvien lielāks izaicinājums, kas bieži vien jau sākotnēji tiek uzskatīts par nenovēršamu ļaunumu. Tipiski, projekta neveiksmes pamatā ir pārāk ilgs ieviešanas laiks, budžeta pārtēriņš, vai arī funkcionālā neatbilstība prasībām.
Līdzīga statistika par Latvijas uzņēmumiem šobrīd nav apkopota, tomēr nozares pārstāvju pieredze liecina, ka projektu fiasko iemesli visbiežāk ir tieši tādi paši. Tomēr nav pareizi uzskatīt, ka IT projekta neizdošanās risks vienmēr ir tik liels, lai nemaz neizvērtētu iespējamu ieguvumu no jaunā risinājuma ieviešanas. Risks ir jāapzinās, un jau pirmsprojekta etapā skaidri jādefinē saistītās izmaiņas.
Programmatūras ieviešanas galvenais uzdevums ir biznesa prasību apmierināšana. Līdz ar to, sākot IT projektu (arī jebkuru citu projektu), uzņēmumam ir skaidri jāzina, kādu problēmu tas grib risināt, un kas ir jauninājuma galvenais uzdevums. Šajā rakstā apzināti tiek runāts par „projektu” nevis „programmatūru”. Prakse liecina, ka pirmā un vissmagākā kļūda IT projektu jomā ir lēmums pirkt vai izstrādāt programmatūru, kaut arī pareizi būtu realizēt noteikta risinājuma ieviešanu. Aplami ir domāt, ka ar programmas iegādi ir atrisinātas visas problēmas. Lai programmatūra kalpotu biznesa mērķiem un pildītu konkrētu uzdevumu, ir jāiegulda apjomīgs darbs, kas neizbēgami rosina izmaiņu procesu uzņēmumā. Protams, programmatūras funkcionālā atbilstība prasībām ir svarīga, tomēr, ja aplūkojam standarta vadības sistēmas, to ir visvieglāk novērtēt.
Pieredze atklāj, ka Latvijas uzņēmēju pieeja IT risinājumiem pārsvarā atbilst modelim „pirkt programmu”. Rezultātā netiek pareizi sastādīts budžets un netiek iekļautas visas izmaksu pozīcijas. Papildus licenču cenai, budžetā ir jāparedz līdzekļi biznesa prasību aprakstam, esošo biznesa procesu aprakstam un izmaiņu vadībai, personāla apmācībai, tai skaitā uzvedības modeļa maiņai, risinājuma prototipa izstrādei un testēšanai, esošo sistēmu un datu migrācijai un lietotāju atbalstam darbu uzsākot. Tāpat budžetā ir jāiekļauj līdzekļi projekta vadībai un izmaiņu procesa uzraudzībai. Ja šīs pozīcijas nav paredzētas, tad projekts un ieviešanas process visticamāk apstāsies budžeta pārtēriņa dēļ un radīs reālus zaudējumus uzņēmumam. Saskaņā ar Gartner Research, „testēšana patērē 25% līdz 50% no vidējā programmatūras izstrādes cikla un bieži tiek uzskatīts, ka tā nepievieno biznesa vērtību”.
Te vietā ir uzsvērt, ka biznesa vadītājam arī ir jāpieņem lēmums, vai izvēlēties kādu no lielajām, pasaulē izplatītajām standarta vadības sistēmām, vai pasūtīt programmētājiem izstrādāt speciālu, īpaši piemērotu, programmatūru konkrētajam biznesam. Skatot un pārrunājot iepirkuma prasības Latvijā, šī diskusija ir neizbēgama, tāpat kā padoma prasīšana labākajam draugam, nevis speciālistam. Vienīgais pluss speciālai izstrādei varētu būt visu iedomāto prasību īstenošana, kam pretī, protams, ir jāliek riska aprēķins izstrādes fiasko procentam, atkarībai no programmētāja un produkta uzturēšanas un attīstības iespējām.
Savukārt, izvēloties tirgū aprobētu, standartizētu sistēmu, jārēķinās ar uzņēmuma procesu izmaiņām. Tiesa, šeit ieguvums ir labākās prakses procesu piedāvājums, kas ir apkopots un izstrādāts liela skaita lietotāju pieredzes rezultātā. Pirms lēmuma pieņemšanas svarīgi ir painteresēties gan par programmatūras ražotāja finanšu stāvokli, gan par zināšanu resursu pieejamību biznesa darbības tirgos. Abi faktori ir svarīgi risinājuma uzturēšanas un attīstības drošumam. Iepriekš minētās testēšanas izmaksas vairāk atbilst programmas izstrādes scenārijam, standarta programmatūras gadījumā tās būs mazākas.
Veicot konkrētas programmatūras vai ERP sistēmas piemērotības novērtējumu, noteikti ir jāpārliecinās par zināšanu pieejamību (izmaksas un sasniedzamība) gan programmatūras funkcionalitātes ziņā, gan ieviešanas projekta un izmaiņu procesu vadības jomā. Nav jākautrējas jautāt pēc pieredzes un atsauksmēm. Projekta vadības veiksme lielā mērā ir atkarīga no atrastā konsultanta spējām, lietotās metodikas un pieredzes. Atlikušo daļu pieliek uzņēmuma vadības tieša iesaistīšanās projektā.
Vietējos uzņēmumos valda pārliecība, ka ārējo resursu piesaiste ir nevajadzīgas virsizmaksas un biežas ir situācijas, kad konsultanta norādījumi netiek uzklausīti no vadības puses. Sadursmes parasti ir par izmaiņām procesos un uzvedības modelī. Var aplūkot reāli eksistējošu uzņēmumu X, kurš, investējot sistēmas iegādē milzīgas summas, cietis lielus zaudējumus, nespējot projektu novest līdz galam. Uzņēmuma īpašnieks, kurš ikdienā atradās uzņēmumā, no projekta norobežojās, tehniski atbildība tika deleģēta finanšu vadītājam, bet praktiski lēmumus pieņēma IT nodaļas vadītājs, jau sākot ar nepamatotu licenču skaita iepirkumu. Projekts tika apturēts burtiski pirms risinājuma palaišanas darbā. Realitāte bija tāda, ka, ieviešot vienu no lielajām vadības sistēmām, IT nodaļas darba apjoms un kontrole pār ikdienas darbībām būtiski būtu samazinājies, un dabiska reakcija uz izmaiņu bija pretestība. Šajā gadījumā projekta fiasko nebūtu noticis, ja uzņēmuma īpašnieks būtu iesaistījies projekta vadības grupā, uzticējies konsultantam un pieņēmis biznesam kopumā izdevīgu lēmumu.
Pieminēšanas vērts projekta fiasko cēlonis ir arī uzņēmuma nevērība iekšējo resursu plānošanā. Risinājuma ieviešanas process, neskatoties uz ārēju speciālistu piesaisti, noteikti prasa ievērojamus iekšējos resursus. Prasību definīcija, procesu izmaiņas, prototipa testēšana, datu sagatavošanas sistēmu migrācijai – tie visi ir darbi, kurus var veikt tikai kopīgi ar uzņēmuma personālu. Programmatūras projekti šodien iesaista praktiski visas uzņēmuma nodaļas un pieprasa dažādu biznesa nodaļu un IT profesionāļu nepārtrauktu sadarbību. Tikai saņemot pilnvērtīgu izpratni, uzticību un vēlmi sadarboties no pasūtītāja puses, projekta ieviesējs var garantēt rezultātu. Pretējā gadījumā jau laikus jāsāk gatavoties nepatīkamam zaudējumu sadaļas papildinājumam.
