Sadzīviski jau folklorizējies ir bēdu stāsts par vienīgo nekustamo īpašumu, krīzi un cilvēku likteņiem. Mazāk publiski ir stāsti par uzņēmumu stila automašīnām, līzingiem un to sekām. Un tā var saukt dažādas kārotas lietas vēl un vēl. Kas te kopējs un kas atšķirīgs ar Biznesa Vadības sistēmu, turpmāk ERP (Enterprise Resource planning), iegādi?

Kopējais ir lēmumu pamatojošā finanšu aplēse. Tipiski pie mums, iegādājoties jaunu preci vai pakalpojumu, izmaksas tiek vērtētas uz darījuma slēgšanas brīdi, savukārt aprēķins par saistītiem un nākotnes maksājumiem netiek veikts. Apsverot mājokļa iegādi, hipotekārā kredīta mēneša maksājumam vismaz vajadzētu pievienot īpašuma uzturēšanas izmaksas vasaras un ziemas apstākļos, ikdienas transporta un citus jaunus sadzīves izdevumus, ar hipotēku saistītus nākotnes izdevumus juristiem, ilgtermiņa procentu likmes un faktiski novērtēt arī īpašuma dzīves ilgumu un potenciālo atjaunošanas vai likvidācijas vērtību.

Šajā aspektā ne ar ko neatšķiras ERP sistēmu iegāde. Lēmumu pamatojošā finanšu aplēsē neiekļautie izmaksu posteņi arī ir tipiskākais problēmu cēlonis.

Atšķirīgais ir attieksme, kā mēs preci izvēlamies (kā) un formulējums, kas ir prece (kas). Te ievērojami labāk uzvedas nekustamo vai ‘taustāmo’ īpašumu pircēji. Izvēles metode (kā): prece vienmēr tiek apskatīta, tiek vērtēts tās funkcionālais piedāvājums un salāgots ar prasībām – mēs taču nepērkam automašīnu, kurai nav apsildāms sēdeklis, ja mūsu komforta sajūta to pieprasa. Izvēles formulējums (kas): vienmēr tiek skaidri nosaukta prece, un cena satur visas tās sastāvdaļas. Piemēram, iegādājoties māju, tiek ņemta vērā tai pieguļošā zeme, jo mājā taču ir jāiekļūst. Pērkot ERP sistēmas, ’kā’ un ‘kas’ bieži atšķiras. Izvēles metode ‘kā’: pircējs neapzina savas prasības pirms sistēmas izvēles un viņam nav skaidra biznesa ‘komforta sajūta’, kam precei būtu jāatbilst, tātad tā arī netiek vērtēta un prece netiek apskatīta. Protams, piegādātāja goda prāts prasītu klienta ‘komforta sajūtas’ vērtējumu pirms pozitīva lēmuma pieņemšanas. Jābūt gan pietiekamai pieredzei, lai atļautos pateikt, ka klientam nav taisnība, un arī vēlme saņemt pasūtījumu mudina teikt, ka visu piegādās. Izvēles formulējums ‘kas’: tipiski par preci uzskata ERP sistēmu, nevis biznesa risinājumu, kuru tā atbalstīs – mājas cena ir iekļauta rēķinā, taču, kā tajā iekļūt, nav zināms. Mierinājumam, problēma ir universāla visā pasaulē.

Runājot par ERP sistēmu izmaksām, noteikti ir jāmaina preces formulējums un jārunā vismaz par ERP risinājuma izmaksām, ja nerunājam par IT bāzētu biznesa vadības risinājumu izmaksām, kur ERP risinājums ir viena no sadaļām. Projektu budžetu risku sarakstā nepareizs preces formulējums arī ir viens no galvenajiem problēmu avotiem, kādu savā praksē esmu satapusi.

Runājot par izmaksām ilgtermiņā, tehnoloģisko risinājumu un programmproduktu ieviešanā pasaulē plaši lieto finanšu aprēķinu, kas pazīstams ar nosaukumu Total Cost of Ownership (TCO) jeb Īpašuma summārās izmaksas. TCO analīzi kā koncepciju nozarē sāka izmantot Gartner Grupa 1987. gadā. Metodes pamatā ir īpašuma summāro izmaksu novērtējums dzīves cikla laikā, apskatot gan tiešās, gan netiešās izmaksas.

ERP risinājuma ieviešanas gadījumā tiešās izmaksas ir viegli saprotamas, un to pamatā ir tehniskais nodrošinājums un programmatūras licences, abi izmaksu posteņi ir jāvērtē, arī apskatot ārpakalpojumu piedāvājumus. Šobrīd Latvijā divdomīgi manipulē ar Software as a Service (SaaS) piedāvājumu, kas, reaģējot uz ‘karsto’ pieprasījumu, dod maldinošu piedāvājumu, kurš pēc būtības ir hosting pakalpojuma kombinācija ar dempinga cenu ERP sistēmas licencei.

Problēmas tipiski sagādā netiešo izmaksu novērtējums, un tās saistās ar risinājuma ieviešanu un dzīves cikla uzturēšanu. Sistēmas uzturēšana ir visskaidrākais izmaksu postenis (vidēji 20% no licences vērtības). Katrs uzņēmums, protams, veido savu TCO netiešo izmaksu sarakstu, bet galvenās ‘aizmirstās’ pozīcijas ir: biznesa prasību definīcija, risinājuma dizains, risinājuma ieviešana un izmaiņu procesa vadība, lietotāju apmācība, risinājuma dzīves cikla uzraudzība un izmaiņu kontrole. Ieviešanas procesa aprēķinā noteikti ir jāņem vērā sistēmu migrācijas un iespējamas dīkstāves izmaksas. Šo posteņu iekļaušana risinājuma budžetā bieži vien no Latvijas uzņēmēju puses tiek uztverta kā ‘naudas izspiešana’ un valda uzskats, ka konsultants papildus vērtību nepievieno un uz šiem izdevumiem noteikti var ietaupīt. Tomēr maldīgi ir uzskatīt, ka uzņēmuma iekšējie resursi ir bezmaksas un TCO aprēķinā tos var neiekļaut. Noderīgi arī paturēt prātā, ka saskaņā ar NIST (National Institute of Standards and technology, ASV) 70%  piegādāto programmu defekti rodas projekta prasību definīcijas un dizaina etapā.

Aberdeen Group savā pētījumā par ERP sistēmu TCO vidēja izmēra uzņēmumos (35 lietotāji) “The Total Cost of ERP Ownership in Mid-Size Companies, August, 2008” netiešo izmaksu vērtējumu dod ap 1178 dolāru par lietotāju gadā, rēķinot trīs gadu periodu. Pēc manas pieredzes, Latvijā vidēji klasisku ERP risinājumu projektos, izmantojot standarta starptautiskās ERP sistēmas, papildus tehnoloģiskajai platformai jeb ‘dzelžiem’ tiek tērēts ap divdesmit tūkstošiem eiro tiešajās izmaksās (10-15 lietotāji), savukārt netiešās izmaksas sasniedz ap 50% vienkāršākam risinājumam un ap 80% sarežģītās ieviešanās no licenču vērtības summā trīs gadu laikā. Aprēķinus veicot, jāņem arī vērā, ka, izmantojot parametrizējamas sistēmas, tiešo izmaksu īpatsvars būs lielāks salīdzinājumā ar netiešajām izmaksām, savukārt programmējamām sistēmām lielāku procentu jāparedz netiešajām izmaksām.

Patīk vai nē, tomēr prakse rāda, ka uzņēmumi būtisku izmaksu samazinājumu un kontroli var panākt, pieprasot projektam izmaiņu vadības metodikas klātbūtni, kas paredzētu veiktspējas rādītāju noteikšanu biznesa prasību paketē un striktu izmaiņu vadības kontroli ieviešanas gaitā. Un šeit ir runa par profesionāla konsultanta klātbūtni. Iekļaujot TCO aprēķinā uzņēmuma iekšējo resursu izmaksas un neveiksmes riska cenu, pietiekami skaidri var redzēt konsultanta faktisko atdevi un izmaksu attaisnojumu.

Uzziņai: ERP (Enterprise Resource palnning) ir integrēta IT bāzēta sistēma, kuru izmato, lai vadītu uzņēmuma iekšējos un ārējos resursus, ieskaitot pamatlīdzekļus, finanšu aktīvus, materiālus un cilvēkresursus. Tā ir programmatūras arhitektūra, kuras mērķis ir sekmēt informācijas plūsmas starp visām biznesa funkcijām uzņēmuma iekšpusē un vadīt saskari ar ārējiem tirgus dalībniekiem. ERP sistēmas konsolidē visas biznesa operācijas vienotā visu uzņēmumu aptverošā vidē.

Priekšnieks, kā ierasts, sapulču telpā ienāca ar savu standarta desmit minūšu nokavēšanos. Visus nopētījis ar stingru skatienu, viņš ķērās lietai pie ragiem:

- „Kas mums šodien darba kārtībā?”

-  „Ražošanas un pārdošanas rādītāju analīze, un uzņēmuma tālākās attīstības stratēģijas definēšana,” noskaldīja finanšu direktors.

-  „Un kādi tad mums ir tie ražošanas un pārdošanas rādītāji, kur redzami?”

-  „Nu man ir daži Excel faili , kur šo to sarēķināju. Preces saražotas par 5% vairāk, kas naudas izteiksmē sastāda 16 200 latus. Pārdošana arī ir OK, bet peļņa nav tāda, kā bijām plānojuši. Izejvielas palikušas dārgākas, piegādātāju pakalpojumu cenas augušas. Šajās svārstībās grūti sarēķināt pašizmaksu un  pārdošanas cenu,” paziņoja finanšu direktors.

Iestājās zināma neērta pauze. Priekšnieks izskatījās diezgan sabozies:

- „Par ko es jums maksāju algu, ja nevarat visu sarēķināt un prezentēt man ticamus skaitļus?”

- „Redziet, eksistē tādi „Key Performance Indicators” jeb „uzņēmuma veiktspējas rādītāji”, bet mēs tādus nelietojam” nedroši ieminējās plānošanas un attīstības nodaļās vadītajs.

-„Un kā tos var aprēķināt?”

- „Pastāv „Enterprise Resource Planning (ERP)” jeb „uzņēmuma vadības” sistēmas. Tā ir programmatūra, , ar kuru strādā visas uzņēmuma nodaļas –. Strādājot ar sistēmu, tajā uzkrājas ikdienas aktivitāšu dati, piemēram, ražošanas pasūtījumi un to izpilde, pirkšanas un pārdošanas pasūtījumi, preču kustība noliktavās u. c. Visas šis operačijas gala rezultātā tiek pārvērstas finanšu datos un,  izmantojot datu analīzes rīkus, iespējams precīzi noteikt visus rādītājus,” paskaidroja zinošākais darbinieks.

- „Cik maksā?”

- „Mūsu uzņēmumam pati sistēma un ieviešana varētu būt robežās no 15 līdz  25 tūkstošiem latu.”

Priekšnieks, manāmi pārsteigts, noteica: „Tādu naudu par kaut kādu tur programmu! Un, kur garantija, ka tā mums vispār derēs? Ko, Jāni, tu par to saki?”

Jānis bija uzņēmuma mīlulis, datorspeciālists. Veikli saveda kārtībā jebkuru datoru, ierādīja kā ērtāk darboties ar uzņēmuma datorprogrammām Jānis bija uzveidojis elegantu uzņēmuma mājas lapu ar dažādiem video materiāliem. Noliktavas darbiniekiem bija izstrādājis programmu preču uzskaitei un grāmatvežiem vienmēr palīdzēja „atrast” vajadzīgos ciparus. Faktiski, uzņēmums bez Jāņa būtu iestrēdzis.

- „Paklau, Jāni, tu varētu uztaisīt šādu sistēmu, lai visi būtu apmierināti? Cik laika tas tev prasītu?” jautāja priekšnieks.

Jānis nedaudz apdomāja un atbildēja: „ Divus, trīs mēnešus!”

-„Labi, tad tā arī darīsim! Sāc darbu pie šī projekta jau šodien,” paziņoja priekšnieks.

Pēc gandrīz gada.

- „Jāni finansisti sūdzas, ka pašizmaksu aprēķins vēljoprojām nav īsti korekts un pārskatos manāmas nesakritības, pārdevēji arī pārdod lētāk kā saražots, šķiet, kaut kas tavā programmā nav pareizi. Jau gandrīz gads pagājis, kad tā varētu būt līdz galam gatava un es redzēšu savus indikatorus?

 - „Zinu, ir dažas neprecizitātes. Vēl pāris mēneši, un viss būs kārtībā,” pārliecinoši noteica Jānis.

Un vēl pēc kāda laika…

- „Trīs gadi jau pagājuši! Vai zini, cik tev algā pa šo laiku ir izmaksāts? Zini, ka nepareizu ciparu dēļ mums ir bijuši baigie zaudējumi un joprojām nav īstas skaidrības par izmaksām, cenām?”, priekšnieks manāmi dusmīgs.

- „Zinu,. bet katru dienu – te vienam ko jaunu vajag, te otram, tad vajag vēl tādus ciparus ievadīt un redzēt to vairākos šķērsgriezumos. Ja godīgi, priekšniek, esmu noguris. Man arī piedāvāja labu darbu, un es piekritu, atlūgumu jau iesniedzu.”

- „Bet ko mēs tagad darīsim, sistēmas nav, lai gan tu solīji!”

- „Jā, priekšniek, bet lēmumu taču pieņēmāt jūs…”

—————-

Līdzīgas situācijas praksē novērojamas diezgan bieži. Vadītājs nevēlas iedziļināties jautājuma būtībā. Viņa izpratnē tā ir tikai “kaut kāda programma”, kuru nevar aptaustīt, tāpēc vēl jo vairāk tās cenu novērtēt ir daudz grūtāk. Tomēr uzņēmuma vadība sevī ietver ne tikai piegādātāju un noieta tirgu atrašanu, ražošanas paplašināšanu vai jaunu pakalpojumu ieviešanu. Viens no svarīgākajiem uzņēmuma vadības un darbības novērtēšanas aspektiem ir esošo datu, kuri ir apvienoti vienā sistēmā, analīze. Ne velti arvien populārāki kļūst dažādi datu analīzes rīki, kas ļauj novērtēt uzņēmuma procesu dinamiku. Risinot jautājumus par uzņēmumu vadības sistēmu lietderību, bieži netiek novērtēts datu uzticamības (nejaukt ar drošību!) faktors.  Un runa pat nav par Jāni (lai man piedod visi Jāņi!), bet par jautājuma būtību. Vai, pirms pasūtīt programmas izstrādi, uzņēmuma vadība ir izvērtējusi kādu no tālāk minētajiem riskiem:-          Programmas (sistēmas) izstrādes laiks (nauda), ieskaitot nebeidzamas testēšanas un pārbaudes, kuras jāveic uzņēmuma darbiniekiem papildus ikdienas darbiem; - “Mīļā programmētāja” nepietiekošās zināšanas biznesa vadībā, kā rezultātā rodas būtiski programmas trūkumi un datu ticamības problēmas;- “Mīļā programmētāja” uzrakstītais atlūgums;- Jauna sistēmas uzturētāja “radīšana” atlūgumu uzrakstījušā “mīļā programmētāja” vietā.  Šie visi klasificējami kā „Total cost of ownership (TCO)” posteņi, un rada lielas izmaksas ilgtermiņā. Papildus varētu runāt arī par to, ka nereti uzņēmumu IT nodaļa jūtas kā noteicēji visam, kas saistīts ar datoriem, komunikācijām. Un vēl – datu drošība klasiskā izpratnē – datu noplūde. Tas var būt gan programmētāju zināšanu pieredzes trūkums, gan tīša rīcība. Izmantojot standarta  ERP programmas riski ir būtiski mazāki un arī ir no kā prasīt atbildību. Šie risinājumi akumulē izstrādātāju gadu gaitā uzkrātās zināšanas un gūto pieredzi. Un šeit arī rodas jautājums – vai vienmēr uzņēmuma vadībai būtu jāuzticas pašu datorspeciālistu ieteiktajiem risinājumiem tikai tāpēc, ka problēmas risinājumā dominē vārds „programmatūra”?