TFL Vsebine / TFLGlasnik

1. UVOD

Avgusta 2021 je EFRAG (2021) objavil dokument za razpravo, s katerim je strokovno javnost zaprosil za predloge za izboljšave pri pripoznavanju oz. razkrivanju neopredmetenih sredstev v letnih poročilih organizacij. EFRAG je poziv objavil na podlagi analize rezultatov raziskav, ki kažejo na to, da se informacijska vrednost računovodskih poročil znižuje. EFRAG (2021) meni, da je to posledica tudi tega, da računovodski izkazi ne vsebujejo informacij o vrsti neopredmetenih sredstev, ki niso izdelana za nadaljnjo prodajo,¹ ampak so nepogrešljivi pomočniki pri izvedbi poslovnih procesov organizacije. Zato jih čedalje več organizacij ima oz. uporablja. Ker pa ne izpolnjujejo pogojev za pripoznanje, jih ni moč najti v njihovih računovodskih izkazih.

Izziv predstavljajo predvsem tista neopredmetena sredstva, ki jih organizacija ustvari oz. razvije sama skladno s svojimi potrebami. Če ne izpolnjujejo pogojev za pripoznanje, torej če ne izpolnjujejo pogojev razpoznavnosti, če jih organizacija ne obvladuje in/ali če ni verjetno, da bi od njih pridobila gospodarske koristi, je treba vse stroške v zvezi z njeno pridobitvijo pripoznati kot odhodek tako po Slovenskih računovodskih standardih kot tudi po Mednarodnih standardih računovodskega poročanja (glejte SRS 2.12 oz. MRS 38.51).

Eno izmed področij, ki je EFRAG spodbudilo k temu pozivu, so poslovne računalniške aplikacije, in sicer tiste, ki jih organizacija za lastne potrebe razvije sama. Spremembe v poslovnem okolju, nastale kot posledica razvoja novih tehnologij, naraščajočih potreb po digitalizaciji poslovanja in posledično hitrega razvoja najrazličnejše programske opreme, vodijo k temu, da postajajo poslovne računalniške aplikacije čedalje pomembnejše za uspešnost delovanja. A informacij o programskih rešitvah, ki jih je organizacija izdelala sama, v letnih poročilih praviloma ni, kar njihovim bralcem otežuje sprejemanje poslovnih odločitev. Razlog se skriva v doslednih pravilih usredstvenja neopredmetenih sredstev, ki jih organizacija izdela sama. Njihov namen je povečati zanesljivost računovodskih informacij, a kritiki trenutne ureditve trdijo, da gre to povečanje na račun ustreznosti informacij, saj ima čedalje več organizacij različna neopredmetena sredstva, ki so za njeno poslovanje pomembna in od katerih pritekajo koristi, vendar niso pripoznana v bilanci stanja.

Pričujoči prispevek predstavlja trenutno računovodsko ureditev tega področja ter izzive pri pripoznavanju lastne poslovne računalniške aplikacije kot neopredmeteno sredstvo. Zato najprej predstavlja najpogostejše metode izdelave lastnih računalniških aplikacij, saj te neposredno vplivajo na sposobnost organizacije, da izpolni pogoje za usredstvenje lastnih računalniških aplikacij tako po SRS-jih kot tudi po MSRP-jih. Podamo tudi napotke, kako izmeriti tovrstno sredstvo ob prvem pripoznanju in kako v nadaljnjem merjenju.

2. OPREDELITEV RAČUNALNIŠKE PROGRAMSKE OPREME

Čeprav človek za svoje preživetje od nekdaj potrebuje informacije in je imel zato vedno vzpostavljen, čeprav zelo preprost informacijski sistem za njihovo zagotavljanje, smo nanje postali pozornejši šele v zadnjem času z razvojem t. i. informacijsko- komunikacijskih tehnologij – IKT (angl. Information and communications technology). Te so v zadnjih petdesetih letih tako zelo napredovale, postale cenejše, zmogljivejše in posledično vseprisotne, da danes pomembno vplivajo na delovanje praktično vseh družbenoekonomskih procesov in institucij.

Informacijsko-komunikacijska tehnologija je skupen izraz za nabor najrazličnejše strojne opreme (tj. računalniških, informacijskih in komunikacijskih naprav oz. strojev), programske opreme (računalniških aplikacij), omrežij (internet) in storitev (Inštitut za informatiko, 2024). Uporaba IKT-ja je v našem vsakdanjem življenju tako vseobsegajoča, da se je posledično pojavil nov pomen izraza informacijski sistem: če smo še pred desetletji z izrazom informacijski sistem vsi razumeli najrazličnejše oblike zajema (ne zgolj s pomočjo stroja), obdelave (tudi zgolj s pomočjo svinčnika in papirja), shranjevanja (tudi v obliki ročno popisanih dnevnikov), pretvorbe in uporabe najrazličnejših podatkov oz. informacij, pa danes pod tem izrazom večina razume kombinacijo programske opreme, ki deluje na nekem računalniškem sistemu in/ali drugih informacijsko-komunikacijskih napravah in je namenjena uporabnikom za učinkovito obdelovanje informacij v najrazličnejše namene, najsi bodo poslovni ali zasebni (npr. za učenje ali za zabavo).

Temelj sodobnega informacijskega sistema tako danes predstavljata ustrezna strojna in programska oprema. Strojna oprema (angl. computer hardware) so računalniški stroji (tj. osebni računalniki, računalniški strežniki, tablični računalniki, pa tudi pametni telefoni) in z njimi povezana stvarna (fizična) oprema, vključno s pomnilniki, kabli, polnilnimi enotami, perifernimi napravami (npr. zasloni in tiskalniki) in tiskanimi vezji (encyclopedia Britannica, 2024). Strojna oprema torej določa zmogljivost računalniškega informacijskega sistema. Njena posebnost je, da je za njeno delovanje poleg električne energije nujno potrebna tudi programska oprema, ki narekuje, kaj naj računalniški stroj počne.

Računalniška programska oprema oz. računalniška aplikacija (angl. computer software) je programska oprema, zasnovana za pomoč uporabnikom pri izvajanju vnaprej določenih nalog (encyclopedia Britannica, 2024). Računalniška aplikacija torej usmerja računalnik, da izvede ukaze uporabnika. Sem spadajo programi za obdelavo baz podatkov, urejevalniki besedil in izdelavo preglednic, programi za računovodsko in poslovno spremljanje in usmerjanje poslovanja organizacije, programi za izvedbo plačilnega prometa, programi za predvajanje medijskih vsebin, za spremljanje nakupnega vedenja potrošnikov, za uporabo elektronskih vozovnic, programi, ki so v uporabi dejavnosti iger na srečo, in vrsta drugih. Računalniške aplikacije se od sistemskih programov (angl. system software) razlikujejo v tem, da slednji predvsem prek operacijskega sistema usmerjajo notranje delovanje računalnika, pa tudi delovanje perifernih naprav, kot so zasloni, tiskalniki in naprave za shranjevanje. V to skupino spadajo tudi t. i. programske platforme (ang. software platform), na primer skupek odprtokodne programske opreme s kratico lAMP (angl. Linux Appache MySQL PHP), ki predstavljajo osnovno ogrodje, na katerem delujejo razne računalniške aplikacije. Na tovrstnih platformah delujejo tudi družbena omrežja.

Izzivov, s katerimi se računovodje soočajo pri računovodskem evidentiranju računalniške programske opreme, še posebej tiste, ki jo je organizacija za svoje potrebe razvila sama, je tako veliko.

Povezani so tako z izpolnjevanjem sodila razpoznavnosti (identificiranosti) kot tudi z obvladovanjem in merjenjem tovrstnih neopredmetenih sredstev.

3. RAČUNOVODSKO EVIDENTIRANJE STROŠKOV IZDELAVE LASTNE POSLOVNE RAČUNALNIŠKE APLIKACIJE

Pri računovodski obravnavi stroškov, nastalih pri izdelavi lastne računalniške programske opreme, mora organizacija odgovoriti na dve vprašanji:

• Ali je tako nastalo računalniško programsko opremo računalniško aplikacijo moč razvrstiti med neopredmetena sredstva skladno z določili SRS-ja 2 oz. MRS-ja 38?
• Ali tako nastala računalniška aplikacija izpolnjuje kriterije za pripoznanje in merjenje, ki so določeni v SRS-ju 2 MRS-ju 38?

Na ti dve vprašanji pa je mogoče odgovoriti zgolj iz natančnega poznavanja procesa izdelave lastne računalniške aplikacije.

3.1. Potek lastne izdelave računalniške aplikacije

Računalniško programsko opremo oz. računalniško aplikacijo lahko organizacija pridobi z nakupom ali jo izdela sama. Če se odloči, da bo opremo izdelala sama, se tega običajno loti na enega izmed naslednjih načinov:

• računalniško aplikacijo v celoti izdela sama oziroma njeni
• zaposlenci;
• računalniško aplikacijo po navodilu in v imenu organizacije
• izdela zunanji izvajalec;
• organizacija kupi oz. pridobi obstoječo programsko opremo, ki pa jo pred začetkom uporabe prilagodi svojim potrebam, kar od zaposlencev zahteva pomemben napor.

Izdelava lastne programske opreme je za organizacijo pogosto velik izziv, saj nanjo pomembno vplivajo stalno spreminjajoče se zahteve, pogosta tehnološka nadgradnja že obstoječe informacijske infrastrukture in potrebe po povezanosti nove računalniške aplikacije z že obstoječimi.

3.1.1. OSNOVNI KORAKI IZDELAVE LASTNE RAČUNALNIŠKE APLIKACIJE

Ker se informacijske tehnologije spreminjajo zelo hitro, je priporočljivo, da organizacije pri izdelavi računalniških aplikacij uporabijo sistematičen pristop. Ta v idejni fazi zahteva izvedbo drugačnih nalog kot pa v fazi zrelosti ali opustitve neke računalniške aplikacije, zato zelo spominja na življenjski cikel proizvoda. T. i. metodologija življenjskega cikla razvoja programske opreme (angl. software development lifecycle – SDlC) vključuje niz aktivnosti, potrebnih za zamisel, načrtovanje, implementacijo, testiranje, prenos v uporabo in vzdrževanje programskega sistema (Ieee, 2024). Z njimi se zagotavlja sistematičen in merljiv pristop k izdelavi (gradnji) in delovanju programskih sistemov, da bi dosegli učinkovitost, zanesljivost in stroškovno učinkovitost tako procesa izdelave kot tudi delovanja programske opreme oz. računalniške aplikacije.

S pomočjo t. i. metod SDlC se izdela načrt za izdelavo nove računalniške aplikacije, tako da se celoten proces razdeli na kratke, natančne in med seboj soodvisne naloge, ki jih je v nadaljevanju možno dodeliti v izvedbo, zatem spremljati njihovo izpolnitev in na koncu oceniti uspešnost izvedbe (AWS, 2024). Načrt torej predstavlja orodje, s katerim se poveča preglednost procesa izdelave nove računalniške aplikacije, učinkovitost njenega načrtovanja in izvedbe, olajša upravljanje tveganj, možnih pri tem procesu, ter omogoči natančnejša ocena stroškov izdelave. Glavna prednost klasičnih metod SDlC je, da vse v razvoj vpletene deležnike (od vodstva organizacije do lastnih ali zunanjih izvajalcev – programerjev) sili, da se vnaprej uskladijo tako glede ciljev kot tudi glede zahtev, ki naj bi jih izpolnila nova računalniška aplikacija, in da se šele po tako doseženem soglasju izdela načrt njene izdelave, ki v nadaljevanju omogoča sistematično spremljanje rezultatov v vsaki fazi izdelave računalniške aplikacije.

Metode SDlC vsebujejo več faz, ki jih je treba opraviti pri izdelavi računalniške aplikacije. Načrt se začne z idejno zasnovo oz. ugotovitvijo potreb, ki naj bi jih računalniška aplikacija reševala, in konča z vzdrževanjem, ko je aplikacija že v rokah uporabnika. Običajno vsebuje naslednjih pet faz (Ieee, 2024, AWS, 2024, Fakulteta za računalništvo in informatiko Ul, b. l.):

1. Analiza zahtev in specifikacija sistema (angl. Requirements analysis and system specification phase, Requirements engineering)

V tej fazi mora organizacija odgovoriti na vprašanje: Kaj potrebujemo oz. kaj naj bi nova računalniška aplikacija zagotavljala? Cilj te faze je natančno razumevanje problema, ki ga organizacija skuša rešiti z računalniško aplikacijo, ter funkcionalni opis zahtev, ki naj bi jih nova računalniška aplikacija izpolnjevala.² Običajno ta faza vključuje analizo stroškov in koristi, oblikovanje časovnice izdelave računalniške aplikacije, oceno potrebnih sredstev in razpoložljivih virov ter izvedbeni načrt za dosego ciljev. Tu se izvede tudi analiza zahtev, ki morajo biti izpolnjene, če želimo, da bo nova računalniška aplikacija izpolnila svoj namen. Če npr. organizacija želi izdelati (razviti) lastno računalniško aplikacijo za spremljanje gibanja zalog proizvodov in bo to gibanje spremljala s črtno kodo, mora (pol)izdelke najprej opremiti s tako kodo, za kar pa seveda potrebuje drugo računalniško aplikacijo, ki bo črtne kode izdelala (generirala) in hkrati oblikovala začetno bazo podatkov.

2. Načrtovanje oz. oblikovanje sistema in komponent (angl. Softwaredesign phase)

V tej fazi vsi v razvoj vpeti deležniki odgovorijo na vprašanje: Kako bomo izpolnili v prejšnji fazi ugotovljene zahteve? Tu programski inženirji analizirajo zahteve ter iščejo najboljše tehnične in programske rešitve za računalniško aplikacijo, tudi tako, da se v njeno izdelavo vključijo že obstoječi moduli in razna razvojna orodja. Preveri se, ali potrebna tehnologija za izdelavo že obstaja. Na primer, če je programska rešitev, ki jo organizacija potrebuje, sestavljena iz delnih programskih rešitev (t. i. modulov), pri čemer z nekaterimi delnimi rešitvami organizacija že razpolaga, nekatere pa so na voljo na trgu, se preveri, ali npr. Vse delujejo v ustreznem okolju, ali pa bi njihova usposobitev za delovanje in povezovanje v celovito lastno računalniško aplikacijo zahtevala pomemben napor zaposlencev. Na primer, računalniški programi organizacije delujejo v Microsoftovem okolju, potencialna rešitev pa je pripravljena zgolj za okolje linux, zato bi jo bilo treba prilagoditi. Ta faza običajno obsega dva koraka:

• Načrtovanje arhitekture programa (angl. Software architectual design)

Tu se načrtovana računalniška aplikacija razčleni oz. razgradi na posamezne komponente oz. module, vsakemu se določi naloge, način komunikacije in način povezovanja z drugimi moduli.

Preuči se tudi, kako računalniško aplikacijo najbolje vključiti v obstoječo informacijskotehnološko infrastrukturo organizacije.

• Podrobno načrtovanje računalniške aplikacije (angl. Detailed software design phase)

Izdelujejo se prototipi različnih modulov in izvaja se sprotna analiza. Opredeli se vsak modul in izdela njegova natančna dokumentacija, tj. opisani so vhodi, izhodi, pomembnejši algoritmi, uporabljene podatkovne strukture in funkcije preoblikovanja podatkov. Lahko se pripravijo tudi usmeritve za pisanje programske kode. Izdela se natančen načrt konfiguracije (tj. prilagoditve) obstoječe programske opreme in programskih vmesnikov, s katerimi se bo nova računalniška aplikacija povezala z obstoječimi programskimi rešitvami.³

3. Implementacija in testiranje posameznih komponent (modulov) sistema (angl. Software implementation phase) Izvede se kodiranje (t. programiranje): v načrtu (tj. v dokumentaciji) opisani algoritmi, podatkovne strukture in funkcije se transformirajo v računalniku razumljiv jezik z upoštevanjem postavljenih usmeritev za pisanje programske kode. Izvede se prilagoditev obstoječih programov in programskih vmesnikov. Izvede se testiranje funkcionalnega delovanja posameznih modulov, da se odpravijo napake na ravni posameznega modula. Če nova računalniška aplikacija za svoje delovanje potrebuje vhodne podatke (npr. register transakcijskih računov, registrskih številk vozil, sezname dobaviteljev in podobno), se v tej fazi lahko izvaja tudi že pretvorba obstoječih podatkov v obliko, ki jo bo nova računalniška aplikacija lahko uporabljala pri svojem delovanju.

4. Testiranje računalniške aplikacije (angl. Software testing phase)

V tej fazi že preverjene module povežemo (integriramo) v enotno programsko strukturo in jih celostno testiramo, tj. preverimo, ali se celotna računalniška aplikacija, postavljena v izbrano strojno okolje, obnaša ustrezno zahtevam, podanim v prvi fazi. Na tej točki se vključijo tudi ključni predstavniki uporabnikov, ki potrdijo ustreznost delovanja računalniške aplikacije (angl. User acceptance testing).

5. Prenos v ciljno okolje (angl. Software deployment phase) Računalniška aplikacija in pripadajoča dokumentacija se izročita uporabnikom: namesti se v ciljno produkcijsko (uporabniško) okolje, opravijo se vse potrebne prilagoditve, tako da jo uporabniki lahko začnejo v tej fazi se lahko izvede tudi t. i. faza vzporedne obdelave podatkov, ko se podatki obdelujejo tako z novo računalniško aplikacijo kot tudi s starimi sistemi, ki naj bi jih nova aplikacija nadomestila. Ob odkritih napakah in/ali pomanjkljivostih se izvedejo popravki, ki lahko pomenijo tudi razvoj dodatnega modula ali celo dodatne (nove) računalniške aplikacije.

Po usposobitvi računalniške aplikacije za uporabo se začne t. i. vzdrževanje računalniške aplikacije (angl. Software maintenance). Celotno življenjsko dobo računalniške aplikacije se namreč pojavljajo različne potrebe po spremembah in izboljšavah njenega delovanja ter posledično po izvedbi najrazličnejših popravkov. Vso življenjsko dobo računalniške aplikacije se izvajajo posodobitve in izboljšave zmogljivosti, pa tudi odpravljanje različnih, šele po usposobitvi ugotovljenih napak. Če je npr. nova računalniška aplikacija namenjena računovodskemu spremljanju vrednosti finančnih naložb, se mora njeno delovanje sproti prilagajati vsakokratni spremembi računovodskih pravil. Izvede se lahko tudi opustitev nekaterih funkcionalnosti, praviloma tako, da organizacija opusti tekoče vzdrževanje teh funkcionalnosti, ob zaključku življenjske dobe pa tudi celotne računalniške aplikacije.

Če sledimo pogojem pripoznavanja v organizaciji izdelanih neopredmetenih sredstev, hitro ugotovimo, da organizacija lahko usredstvi zgolj tiste stroške, ki nastajajo od faze podrobnega načrtovanja računalniške aplikacije dalje (angl. Detailed software design phase), in še to, zgolj če so izpolnjeni vsi pogoji, ki jih postavljajo Slovenski računovodski standardi oz. Mednarodni standardi računovodskega poročanja (predstavljeni v podpoglavju 3.5.2.). Faza načrtovanja arhitekture programa (angl. Software architectual design) je namreč še vedno faza iskanja ustreznih tehničnih rešitev problema, ki naj bi ga računalniška aplikacija obravnavala, in zato faza raziskovanja (kot jo orisujeta SRS 2 oz. MRS 38). Šele pri podrobnem načrtovanju računalniške aplikacije lahko govorimo, da je v fazi razvoja. A stroške, ki tu nastajajo, lahko usredstvimo, zgolj če je faza raziskovanja res popolnoma zaključena, kar se kaže tudi z zaključeno dokumentacijo, ki prikazuje arhitekturo računalniške aplikacije. Ta pa se v praksi zaradi časovnih pritiskov, velike negotovosti in/ali pomanjkanja informacij o dejanskih potrebah uporabnikov ne pripravi vedno.

3.1.2. NAJBOLJ UVELJAVLJENE METODE ZA IZDELAVO PROGRAMSKE OPREME

Metode SDlC se razlikujejo glede na izvedbo faz, opisanih v prejšnjem podpoglavju. Običajno metode SDlC res vsebujejo vseh pet faz, ki so med seboj tesno prepletene, a te faze ne bodo nujno potekale zaporedoma, niti ni nujno, da bodo natančno dokumentirane. Rezultat ene faze je resda začetek druge faze, a pogosto med fazami ni moč potegniti jasne ločnice, različni deli (moduli) računalniške aplikacije so lahko hkrati tudi v različnih fazah razvoja. Zgodi se tudi, da se izdelava nekega modula zaradi ugotovljenih pomanjkljivosti vrne v prejšnjo fazo ali da nek modul uporabniki testirajo, preden je vključen v celovito računalniško aplikacijo.

Glede na način izvajanja faz izdelave računalniške aplikacije poznamo različne metode oz. modele SDlC. Med njimi so najbolj znani (Ieee, 2024):

Zaporedni oz. kaskadni model se imenuje tudi model vodnega slapa (angl. Waterfall model). v njem si faze sledijo zaporedno in se izvedbeno skorajda ne prekrivajo, saj so zahteve, ki jih mora programska aplikacija izpolniti, v celoti določene v prvi fazi in se med izdelavo računalniške aplikacije ne spreminjajo.

V-model je podoben kaskadnemu, le da se faza dokumentiranega testiranja pojavlja že takoj pri izdelavi posameznega modula, potem pri integriranju oz. povezovanju modulov v celovito programsko opremo, nato pri prenosu računalniške aplikacije v strojno okolje ter na koncu v končnem uporabniškem okolju. Za ta model je torej značilno intenzivno dokumentirano sprotno testiranje, kar skrajša testiranje pri ključnih uporabnikih in zaključno preverjanje delovanja računalniške aplikacije v ciljnem okolju.

V inkrementalnem modelu (angl. Incremental model) se računalniška aplikacija izdeluje po korakih, tj. po posameznih modulih, in sicer tako, da gre vsak modul posebej po zaporedju faz načrtovanja, izdelave in testiranja. Ker je modulov več, te faze pa se ponovijo v vsakem od njih, se ta model pogosto imenuje tudi iteracijski model. Ko je posamičen modul izdelan, se vključi v delujočo celoto (tj. računalniško aplikacijo), lahko pa se tudi posamično preda uporabnikom v uporabo.

V modelu hitre prototipizacije (angl. Rapid prototyping model) se najprej izdela osnovna oz. preprosta različica računalniške aplikacije (t. i. prototip), ki ima omejen nabor bistvenih funkcionalnosti. Uporabnik ta prototip preizkusi in poda priporočila in pripombe za nadaljnji razvoj, na podlagi katerih se prototip izboljša, nato pa se uporabniku spet preda v testiranje.

Ta krog se ponavlja, dokler računalniška aplikacija ne ustreza uporabnikovim zahtevam.

Agilni model (angl. agile model) je kombinacija inkrementalnega modela in modela hitre prototipizacije: računalniška aplikacija je razdeljena na posamezne module, ki se izdelajo ločeno, a zgolj v osnovni obliki. Ti moduli se posamično ali zgolj v neko osnovno programsko strukturo povezani predajo v preizkus uporabnikom, ti pa nato podajo predloge za nadaljnji razvoj. Na podlagi njihovih predlogov se izboljšujejo tako moduli kot tudi celotna računalniška aplikacija, dokler uporabniki z delovanjem niso zadovoljni.

Glede na to, kako hitro se lahko postopek izdelave prilagodi spremembi zahtev, ki naj bi jih nova računalniška aplikacija izpolnjevala, pa metode SDlC razdelimo v zgolj dve skupini: med t.i. napovedne metode SDlC (angl. predictive models) in med prilagoditvene metode SDlC (angl. adaptive models) (Cypress Data Defense, 2020).

Napovedni modeli (med njimi je najbolj znan kaskadni model) so uporabni, kadar je mogoče vnaprej precej natančno določiti celoten postopek izdelave računalniške aplikacije, saj ima organizacija jasno vizijo, katere naloge naj bi opravljala. Posledično je mogoče pri tej skupini metod SDLC že na samem začetku procesa izdelave (tj. v fazi analize zahtev in specifikacije sistema) natančno oceniti potreben obseg del, postaviti časovnico in posledično vnaprej določiti stroške izdelave računalniške aplikacije. Največja prednost teh metod je, da je potek izdelave vsem udeležencem enostavno razumljiv, zato je vodenje takih projektov precej preprosto, enostavno pa je tudi izvajati vsebinski, časovni in stroškovni nadzor izdelave računalniške aplikacije. Njihovi glavni slabosti sta rigidnost oz. neprilagodljivost postopka izdelave potrebam, ki bi se pokazale med izdelavo, in prepozno odkrivanje napak v izdelavi, pogosto šele v fazi testiranja nove računalniške aplikacije. Če se napaka, ki se je zgodila pri načrtovanju, odkrije šele v fazi testiranja, lahko nastanejo zelo velike zamude pri izdelavi računalniške aplikacije in pomembno večji stroški njene izdelave.

Za kompleksnejše računalniške aplikacije oz. za računalniške aplikacije, pri katerih so organizacije zaradi spreminjajočega se poslovnega okolja negotove glede natančne opredelitve nalog, ki naj bi jih aplikacije opravljale, so zato primernejše t. i. prilagoditvene metode SDlC, med katerimi sta tako agilni model kot tudi model hitre prototipizacije. Te metode omogočajo hitro spremembo postopka izdelave računalniške aplikacije, saj se osredotočajo na zadovoljitev uporabnikovih potreb, ne pa na formalno izvedbo postopka izdelave. Za te metode je značilna kratka povratna zanka, saj želijo čim prej pridobiti odziv uporabnika, ker je od tega odvisen nadaljnji postopek razvoja oz. izdelave računalniške aplikacije. Zato so prilagoditvene metode časovno in stroškovno učinkovita izbira za izdelavo kompleksnih računalniških aplikacij, katerih nalog zaradi negotovosti ni mogoče vnaprej predvideti, in tam, kjer organizacija, ki želi novo računalniško aplikacijo, ne zna oz. ne zmore vnaprej opredeliti njenih nalog. Ker je dandanes v praksi zelo malo projektov takih, da organizacija vnaprej natančno ve, kaj je namen nove računalniške aplikacije, so prilagoditvene metode SDlC pogosta izbira razvijalcev računalniške opreme, saj so hitrejše od napovednih, čeprav celoten postopek njene izdelave zahtevajo izrazito intenzivno komunikacijo tako med razvijalci kot tudi med razvijalci in uporabniki nove računalniške aplikacije.

3.2 Ali je programska oprema sestavni del neopredmetenih sredstev ali opredmetenih osnovnih sredstev?

Ker računalniška programska oprema nima stvarne (fizične) oblike, lahko stroške njenega razvoja (če seveda ta programska oprema izpolnjuje pogoje za pripoznanje) tako po SRS-jih kot tudi po MSRP-jih usredstvimo kot neopredmeteno sredstvo.

Naj opozorimo na zahtevo v MSRP-jih, ki je v SRS-jih ni. V MRS- ju 38.4 se izrecno zahteva, da je treba, kadar neko sredstvo hkrati vključuje tako opredmetene kot tudi neopredmetene sestavine, presoditi, katera sestavina je pomembnejša, in nato slediti ustreznemu računovodskemu standardu: bodisi MRS-ju 16 – Opredmetena osnovna sredstva bodisi MRS-ju 38 – Neopredmetena sredstva. Primer so računalniški programi za računalniško obvladovani stroj, ki brez teh programov sploh ne more delovati (torej gre za sistemske programe, kamor spada npr. računalniški operacijski sistem): ti programi so po MRS-ju 38.4 sestavni del ustrezne računalniške strojne opreme, zato vrednost te opreme zvišujejo in se posledično obravnavajo kot opredmeteno osnovno sredstvo skladno z zahtevami MRS-ja 16. Kadar pa računalniški programi niso nujni pogoj za delovanje računalniške strojne opreme (npr. vsa računalniška programska oprema oz. t. i. računalniške aplikacije), se obravnavajo kot ločeno neopredmeteno sredstvo. Če bi na primer organizacija razvila lasten računalniški stroj in bi hkrati zanj oblikovala tudi poseben operacijski sistem, ki bi tudi sam zase izpolnjeval vse pogoje za pripoznanje in merjenje v okviru neopredmetenih sredstev, bi ga skladno z MRS-jem 38.4 morala računovodsko obravnavati kot sestavni del opredmetenega osnovnega sredstva (tj. računalniškega stroja), po SRS-jih pa je tak operacijski sistem možno pripoznati bodisi kot sestavni del računalniškega stroja bodisi samostojno v okviru neopredmetenih sredstev.

Če organizacija ugotavlja bilančni dobiček po desetem odstavku 67. člena ZGD-1, omenjena odločitev vpliva tudi nanj: če računalniško obvladovani stroj brez nekega v organizaciji razvitega sistemskega programa sploh ne more delovati (tj. brez tega programa je zgolj mrtev predmet), je po MRS-ju 38.4 ta sistemski program sestavni del tega stroja, ne pa del neopredmetenih sredstev, zato z njim povezani usredstveni stroški razvoja ne zmanjšujejo bilančnega dobička organizacije. V SRS-ju 2 taka zahteva za sistemske programe ni izrecno zapisana, zato je način pripoznavanja usredstvenih stroškov razvoja lastnih sistemskih programov prepuščen organizaciji sami. Ta sklep pa ne velja za računalniško programsko opremo oz. računalniške aplikacije, kot so razni računovodski računalniški programi, programi za spremljanje tovornega prometa, za analizo gibanja vrednosti nepremičnin, programi za izdelavo arhitekturnih načrtov ipd. Za vso tovrstno programsko opremo velja, da niso nujni pogoj za delovanje računalniških strojev (tj. računalniški stroj bo deloval tudi brez tovrstnega programa), zato so njihovi usredstveni stroški razvoja del neopredmetenih sredstev in posledično zmanjšujejo bilančni dobiček.

Celoten članek je dostopen za naročnike!