REPUBLIKA SLOVENIJA UNIVERZA V MARIBORU EKONOMSKO … · 2017. 11. 28. · na smeri Poslovna...

REPUBLIKA SLOVENIJA

UNIVERZA V MARIBORU

EKONOMSKO-POSLOVNA FAKULTETA

MAGISTRSKO DELO

UVAJANJE PODATKOVNIH STANDARDOV V POSLOVNE INFORMACIJSKE

REŠITVE NA PRIMERU PLAČILNEGA PROMETA

Februar, 2016 Maja Gal Ravnjak

2

REPUBLIKA SLOVENIJA

UNIVERZA V MARIBORU

EKONOMSKO-POSLOVNA FAKULTETA

MAGISTRSKO DELO

UVAJANJE PODATKOVNIH STANDARDOV V POSLOVNE INFORMACIJSKE

REŠITVE NA PRIMERU PLAČILNEGA PROMETA

Kandidatka: Maja Gal Ravnjak, uni. dipl. ek.

rojena leta 1980 v kraju Ljubljana

zaposlena v PRO-BIT d.o.o., programska oprema

kot svetovalec IT in vodja profitnega centra

absolventka podiplomskega študija programa Ekonomske in poslovne vede

na smeri Poslovna informatika

Tema odobrena dne: 02.07.2014

Z delovnim naslovom: UVAJANJE PODATKOVNIH STANDARDOV V

POSLOVNE INFORMACIJSKE REŠITVE NA PRIMERU PLAČILNEGA

PROMETA

Mentor: Samo Bobek, prof. dr.

3

Kazalo:

POVZETEK .............................................................................................................................. 6

SUMMARY ............................................................................................................................... 6

1 UVOD ................................................................................................................................. 7

1.1 Opredelitev področja in opis problematike ............................................................. 7

1.2 Namen in cilji raziskave ............................................................................................ 9

1.3 Načrt poteka raziskave .............................................................................................. 9

1.3.1 Hipoteze ................................................................................................................ 9

1.3.2 Potek raziskave .................................................................................................. 10

1.3.3 Predvidene metode ............................................................................................. 10

1.3.4 Predpostavke in omejitve raziskave ................................................................... 14

2 E-POSLOVANJE ............................................................................................................ 15

2.1 Priložnosti in ovire e-poslovanja ............................................................................ 15

2.2 Opredelitev e-računov ............................................................................................. 17

2.2.1 Preslikavanje e-računa ...................................................................................... 18

2.2.2 Standardni ali nestandardni model e-računa ................................................... 18

2.2.3 E-račun z uporabo spletnih obrazcev ............................................................... 18

2.2.4 E-račun preko ponudnika storitev .................................................................... 19

2.3 Razvoj in zahteve plačilnih sistemov po e-dokumentih ........................................ 20

2.3.1 Slovenska zakonodaja na področju e-dokumentov .......................................... 21

2.3.2 Evropske smernice na področju e-dokumentov ................................................ 22

2.4 Zagotavljanje varnosti pri e-plačevanju ................................................................ 23

2.4.1 Kriptografija oziroma šifriranje ........................................................................ 23

2.4.1.1 Simetrična.................................................................................................... 24

2.4.1.2 Asimetrična.................................................................................................. 24

2.4.2 Digitalni podpis .................................................................................................. 25

2.4.3 Časovni žig ......................................................................................................... 26

2.4.4 Infrastruktura javnih ključev ............................................................................ 27

2.5 E-Arhiviranje ........................................................................................................... 28

3 PODATKOVNI STANDARDI NA PODROČJU E-DOKUMENTOV ..................... 31

3.1 EDIFACT ................................................................................................................. 31

3.1.1 Zgodovinski razvoj ............................................................................................. 31

3.1.2 Predstavitev standarda ....................................................................................... 32

4

3.2 XML IN UBL STANDARD .................................................................................... 33

3.2.1 Zgodovinski razvoj UBL standarda .................................................................. 33

3.2.2 Zgodovinski razvoj XML standarda .................................................................. 34

3.2.3 Predstavitev standarda XML ............................................................................. 34

3.3 E-SLOG .................................................................................................................... 35

3.3.1 Zgodovinski razvoj ............................................................................................. 35

3.3.2 Predstavitev standarda ....................................................................................... 36

4 UVAJANJE PODATKOVNIH STANDARDOV V POSLOVNE REŠITVE ........... 38

4.1 Sistemska analiza ..................................................................................................... 39

4.2 Načrtovanje projekta ............................................................................................... 39

4.3 Metodologija in vidiki razvoja ................................................................................ 40

4.3.1 SLAM-DUNK model .......................................................................................... 40

4.3.2 Baročni model .................................................................................................... 41

4.3.3 Kaskadni model .................................................................................................. 41

4.3.4 Spiralni model razvoja ....................................................................................... 42

4.3.5 Vidiki razvoja programske opreme ................................................................... 43

4.3.5.1 Procesni vidik .............................................................................................. 44

4.3.5.2 Podatkovni (informacijski) vidik ................................................................. 45

4.3.5.3 Dogodkovni vidik......................................................................................... 45

4.4 Oblikovanje sistema ................................................................................................. 46

4.5 Implementacija sistema ........................................................................................... 48

5 ANALIZA PRIMERA IMPLMENTACIJE E-RAČUNOV V

INFORMACIJSKEM SISTEMU PRO3. FINANCE ZA MALA, SREDNJA IN

VELIKA PODJETJA ............................................................................................................. 49

5.1 Predstavitev podjetja in informacijskega sistema PRO.3 Finance ..................... 49

5.2 Implementacija e–računov v informacijski sistem PRO.3 Finance od zasnove

do programske rešitve ........................................................................................................ 50

5.2.1 Zasnova programske rešitve .............................................................................. 51

5.2.2 Oblikovanje projektne skupine .......................................................................... 53

5.2.3 Razvoj ................................................................................................................. 54

5.2.3.1 Implementacija e-računov ........................................................................... 54

5.2.3.2 Testiranje e-računov ................................................................................... 55

5.2.3.3 Instalacija e-računov pri uporabniku programske opreme ........................ 56

5.2.4 Vzdrževanje ........................................................................................................ 57

5.3 E-računi za mala, srednja in velika podjetja ........................................................ 57

5

6 POVZETEK ..................................................................................................................... 66

7 SEZNAM VIROV ........................................................................................................... 69

SEZNAM SLIK ...................................................................................................................... 74

SEZNAM TABEL .................................................................................................................. 75

PRILOGA 1 ............................................................................................................................ 76

PRILOGA 2 ............................................................................................................................ 78

6

POVZETEK

Tematika e-poslovanja in e-računov je dandanes zelo zanimiva. Poraja se vprašanje, zakaj

se podjetja takšnega načina e-poslovanja in e-izdajanja ter e-prejemanja računov ne

poslužujejo. Čeprav je stroka in državna zakonodaja zagotovila smernice razvoja in s tem

vplivala na razvoj varnostnih mehanizmov, razcveta e-poslovanja še nismo doživeli. Le

redki se poslužujejo standardiziranih struktur, kot je e-SLOG, in v večji meri poljubnih

struktur za elektronsko izmenjavo podatkov.

Vsaka implementacija programske rešitve, kot so e-računi, v že obstoječi informacijski

sistem, zahteva projektno usmerjenost in načrtovanje, da je izpeljana čim bolj uspešno in

da je zagotovljena sledljivost razvoja. Pomembno je, kateri model razvoja programiranja

izberemo in hkrati spremljamo različne vidike razvoja programske opreme. Le tako si

lahko zagotovimo uspešnost projekta na eni strani in na drugi strani zadovoljstvo

uporabnikov.

Ključne besede:

E-poslovanje, e-računi, simetrično šifriranje, asimetrično šifriranje, digitalni podpis,

časovni žig, infrastruktura javnih ključev, e-arhiviranje, EDIFACT, XML, UBL, e-SLOG,

projektno načrtovanje, metodologija in vidiki razvoja programske opreme, implementacija

in vzdrževanje.

SUMMARY

Nowadays e-business and e-invoices themes are very interesting. The question arises as to

why the companies do not use these kinds of e-business. Although the profession and state

legislation provide guidelines for the development and the impact on the development of

security mechanisms, the booming e-business has not been experienced yet. Standardized

structures, such as the e-SLOG, are only used by few while arbitrary structures for

electronic data exchange are used more.

Each software solutions implementation, such as e-invoicing, into the existing information

system, requires a project orientation and planning that is carried out most effectively and

ensures traceability of development. It is important which programme development model

is selected and simultaneously different aspects of software development should be

monitored. Only in this way the success of the project and the satisfaction of users are

ensured.

Key words:

E-bussiness, e-invoices, symmetric encryption, asymmetric encryption, digital signature,

timestamp, public key infrastructure, e-archiving EDICACT, XML, UBL, e-SLOG, project

planning, methodology and aspects of software, implementation, maintenance.

7

1 UVOD

1.1 Opredelitev področja in opis problematike

V prihajajočih letih se celotna Evropa sooča z enim izmed največjih izzivov, kako že tako

optimizirano poslovanje, narediti še bistveno bolj produktivno in okolju prijazno. Veliko

študij je dokazalo, da prav digitalizacija in avtomatizacija poslovanja (e-poslovanje),

pomenita bistveno večjo produktivnost in potencialno optimizacijo poslovanja (European

Comission 2009, 1).

Če je v preteklosti poslovanje pomenilo dejavnost nakupovanja prvin, proizvajanja in

prodajanja proizvodov, nakupovanja in prodajanja blaga ter opravljanja storitev, je danes

poslovanje mnogo bolj razširjeno. Pojem poslovanje organizacij se je skozi zgodovino

drastično spremenilo, zato nas zanima razvoj poslovanja in porast potrebe po brezpapirnem

poslovanju, saj nas trendi v svetu silijo, da se čim prej preusmerimo v brezpapirno

poslovanje.

Samo e-poslovanje potrebuje določene inpute, da lahko zaživi v pravem pomenu besede.

Predvsem mislimo na brezpapirne dokumente (v nadaljevanju e-dokumenti) in pa

informacijsko tehnologijo, tako na strani izdajatelja kot na strani prejemnika.

Če želimo doseči produktivnost in ohraniti stabilnost ter konkurenčnost, je prav migracija

na brezpapirno poslovanje, pravi odgovor (European Comission 2009, 1).

Na tem mestu je smiselno omeniti, da je že več kot 90 odstotkov vseh bank v sistemu e-

računov, vendar na strani uporabnikov tega trenda ni zaznati. Zakaj? Obstaja strah pred

internetno zlorabo ali nezaupanje v popolno brezpapirno poslovanje? Mogoče.

Kupec, ki nastopa v vlogi plačnika, mora verjeti, da bo prodajalec izpolnil dano obljubo in

prodajalec, ki nastopa v vlogi prejemnika plačila, mora verjeti, da bo kupec plačal. Oba pa

morata verjeti, da je poslovanje prek interneta varno (Bračun 2003) .

Ali pa je razlog v malih in srednje velikih podjetjih v Sloveniji, ki predstavljajo skoraj 99%

vseh podjetij v državi (SURS 2010). So torej gonilna sila gospodarske rasti, katerih

prednost je hitra prilagodljivost in sposobnost hitrega odziva na spremembe v okolju.

Večje organizacije si sicer elektronsko izmenjujejo poslovne listine, medtem ko se srednje

in majhne organizacije v tovrstno sodelovanje težje vključujejo. Kot ovire za e-poslovanje

majhna podjetja najpogosteje navajajo pomanjkanje kadrov, premajhno število

uporabnikov, naravo dela ter visoke stroške strojne in programske opreme (Bogataj et al.

2002, 5).

Obstaja pa tudi možnost, da sama državna institucija ne poskrbi, da bi sistem e-poslovanja

in pretok e-dokumentov zaživel, stekel. Do nedavnega v zakonodaji ni bilo zaznati neke

vzpodbude, ki bi dala zagon e-poslovanju in s tem tudi povečala uporabo e-računov.

Prednosti, kot so nižji stroški poslovanja, točnost podatkov, višja produktivnost pri

obdelavi in plačevanju e-računov ter podobno (GXS 2013a), ki jih omogoča e-poslovanje

so vsekakor enormne, vendar ne smemo pozabiti na varnost pri takšnem načinu poslovanja

in izdajanja računov.

8

Področje e-plačilnega prometa, ki je sestavni del e-poslovanja in z njim povezanimi e-

dokumenti, raziskujejo mnogi avtorji.

Pomanjkanje prilagojenih e-plačilnih sistemov in infrastrukture je eden izmed glavnih

razlogov, ki omejujejo povečanje e-poslovanja meni Laudon in drugi (Laudon et al. 2002).

Med drugim je splošno zaupanje v plačevanje prek interneta tisti dejavnik, ki pomembno

vpliva na pripravljenost kupca plačati in prodajalca sprejeti plačilo prek interneta

(Nyshadham et. al. 2006). Povezavo med zaupanjem in zaznanim tveganjem pri e-

poslovanju in e-plačevanju je skušal ugotoviti tudi Bračun (2003), ki je mnenja, da je

uvajanje sprejemanja e-plačevanja in e-poslovanja v podjetju povezano z velikimi vlaganji.

Poleg ustrezne zaščite podatkov so potrebne tudi določene organizacijske spremembe, v

nekaterih primerih tudi zaposlovanje ustreznih strokovnjakov (IT strokovnjakov).

Pomembno je, kdo zagotavlja tehnične rešitve in izvaja ukrepe v primeru zlorabe zaupanja.

Številna podjetja, ki se ukvarjajo z varnostnimi storitvami preko interneta, so posvetila

ogromno časa in energije, da bi ustvarila večjo varnost in kar najbolj učinkovite

mehanizme za preprečevanje zlorab. Še vedno pa se pojavlja potreba po uvedbi novih

konceptov in novi tehnologiji, ki bi omogočila optimalne pogoje za uvedbo e-dokumentov.

V ta namen smo raziskali problematiko e-računov in njihov vpliv na e-poslovanje na

izbranem vzorcu podjetij, in sicer na kakšen način, v kakšni obliki in s katerim standardom

izmenjave naj »e-posluje« neko podjetje. Raziskali smo vplive e-dokumentov na

poslovanje podjetij, opredelili prednosti in slabosti, analizirali s tem povezano

problematiko izbire standardov izmenjave e-dokumentov ter nazadnje preverili

pripravljenost podjetij na uvedbo e-dokumentov.

Tudi področje podatkovnih standardov raziskujejo mnogi raziskovalci. Vsak izdajatelj in

prejemnik morata sprejeti sporazum o pošiljanju e-dokumentov. Hkrati lahko izbereta

poljubni standard za podatkovno izmenjavo e-dokumentov.

Vedno pogosteje pa se uveljavlja povezovanje in izmenjava podatkov s pomočjo XML

standarda, kljub temu, da še ni splošno priznanih XML poslovnih listina na področju e-

poslovanja med organizacijami (Bogataj et al, 2002, 14). Čeprav je v Evropi več kot 500

podatkovnih standardov za izmenjavo podatkov, je v Sloveniji najbolj uveljavljen e-SLOG.

Namen projekta e-SLOG je po Zupančiču (2004): uveljavljanje standardnih elektronskih

listin, priprava in uveljavitev rešitev za varno e-poslovanje z uporabo e-podpisa in

uveljavitev rešitev za majhna, srednja in velika podjetja ter promocija e-poslovanja.

Obstaja pa tudi možnost, da se prejemnik in izdajatelj dogovorita in razvijeta svojo

strukturo za izmenjavo podatkov. Nekatere organizacije se povezujejo na osnovi internih

standardov (Bogataj et al. 2002, 14). Iz vidika ponudnikov informacijskih sistemov (v

nadaljevanju IS) to pomeni, neomejeno prilagajanje na izbrano podatkovno strukturo.

Želimo povedati, da se na področju e-poslovanja pogreša enovitost in standardizacija

postopkov pri e-poslovanju.

9

1.2 Namen in cilji raziskave

Namen magistrske naloge je raziskati sistem e-poslovanja in e-računov. Analizirali smo

omenjeno problematiko, ugotovili njen pomen v posamezni organizaciji, značilnosti in ne

nazadnje tudi spoznali njune omejitve. Čeprav predstavlja veliko bolj enostavno

poslovanje se ga večina udeležencev ne poslužuje. Hkrati smo raziskali uvajanje različnih

podatkovnih standardov, vse od zasnove do implementacije programske rešitve v izbran

informacijski sistem. Analizirali smo tudi priložnosti, ki jih takšen način e-poslovanja

prinaša v posamezno organizacijo in pa pasti, ki jih vsaka noviteta prinaša s seboj.

S teoretičnega vidika, smo najprej opredelili osnovne pojme e-poslovanja in e-

dokumentov, varnostne mehanizme in podatkovne standarde izmenjave podatkov pri to

vrstnem poslovanju ter nakazali potrebo po e-arhiviranju. Na koncu magistrske naloge pa

smo teoretično problematiko preslikali v praktični primer, in sicer sistem vpeljave e-

dokumentov in delno e-poslovanje v programu Pro. 3 Finance. Empirični del smo raziskali

in potrdili hipoteze z mnenji in stališči končnih uporabnikov ter IT strokovnjaki, ki

uporabljajo izbrani IS.

V magistrskem delu želimo doseči predvsem naslednje cilje:

Proučiti problematiko e-poslovanja in e-dokumentov najprej na teoretični ravni in jo

prikazati na praktičnem primeru uvajanja podatkovnih standardov.

Nakazati, da vpeljava e-poslovanja in e-dokumentov prinaša enormne prednosti ter hkrati

tudi omejitve, še posebej, če gre za mala in srednja podjetja.

V delu smo analizirali in med seboj primerjali podatkovne standarde izmenjave, ki so se

razvijali skozi zgodovino ter nakazati problematiko »ne standardizacije« postopkov pri

elektronski izmenjavi.

1.3 Načrt poteka raziskave

1.3.1 Hipoteze

V magistrskem delu smo poskusili potrditi naslednje hipoteze:

H1: V poslovnih informacijskih rešitvah na področju plačilnega prometa je najbolj

primeren podatkovni standard E-slog.

H2: Kaskadni model razvijanja/dodelave poslovnih rešitev daje najboljše rezultate

uvajanja podatkovnih standardov.

H3: Uvajanje standardiziranih podatkovnih struktur daje boljše rezultate kot uvajanje

posamičnih, med posameznimi podjetji dogovorjenih podatkovnih struktur.

H4: Najpogosteje uvajajo podatkovne standarde velika podjetja.

10

1.3.2 Potek raziskave

Magistrska naloga je razdeljena na teoretični del in empirični del.

V teoretičnem delu smo poiskali in proučili potrebno literaturo za razumevanje področja

problematike e-dokumentov, njihovo obdelavo in arhiviranje ter odnos do tovrstnega e-

poslovanja. Proučili smo tudi slovensko zakonodajo, ki s svojo nedodelanostjo in

ohlapnostjo, neugodno vpliva na porast uporabe e-računov. Pri tovrstnem poslovanju je

izrednega pomena varnost poslovanja, zato smo opredelili vidike šifriranja in možnost

arhiviranja e-dokumentov. Zadnji del teoretičnega dela obsega opredelitev standardov za

izmenjavo e-dokumentov in metodologijo programskih rešitev ter možnost njihove

vpeljave v IS.

Empirični del magistrskega dela vsebuje opredelitev raziskovalnega problema uvajanja e-

računov v izbrani IS.

Določili smo cilje, ki jih želimo doseči z uvedbo e-računov v izbrani IS ter pripravili

analizo primera uvajanja novih rešitev v izbrani IS s pomočjo znanja, ki smo ga pridobili v

teoretičnem delu ter izkušnjami na področju vpeljave programskih rešitev v IS. Uporabili

smo tudi primarne in sekundarne dokumente na temo e-računov, pridobili podatke s

pomočjo intervjuja in iz osebnih praktičnih izkušenj na področju uvajanja tovrstnih

programskih rešitev v IS.

Raziskovalni del vsebuje namenski vzorec, in sicer tri različne vzorce:

mikro ali mala;

srednja in

velika podjetja.

Hkrati obsega dve različni skupini uporabnikov, in sicer končne uporabnike in/ali IT

strokovnjake v določenem podjetju, odvisno od tega, ali ima podjetje oblikovan svoj IT

oddelek.

1.3.3 Predvidene metode

Magistrsko delo je nastajalo v več fazah. Najprej smo zbrali dostopno literaturo, tako tujo

kot slovensko, ki obravnavajo izbrano tematiko. Hkrati smo dodali misli in izkušnje iz

obiskanih seminarjev na temo e-poslovanja in e-računov ter teorijo podprli s pridobljenimi

lastnimi izkušnjami na področju implementacije e-poslovanja v program Pro.3Finance.

Teoretična in praktična spoznanja pa so osnova za določitev problematike raziskovanja,

namenov, ciljev in hipotez magistrskega dela.

V teoretičnem delu smo se lotili tematike razvoja, ureditve in implementacije e-

poslovanja in e-računov, zato je magistrsko delo poslovna raziskava. Sočasno gre za dve

raziskavi, in sicer statično - komparativno in dinamično raziskavo. Ker smo obravnavali e-

poslovanje in e-račune v določenem trenutku, gre za statično raziskavo. V tem delu smo si

pomagali z deskriptivnim pristopom raziskovanja, natančneje z metodo deskripcije, pri

čemer smo opisovali potrebo po e-poslovanju, proces razvoja podatkovnih struktur in

možnost njihovega arhiviranja.

11

Raziskava je tudi dinamična, saj smo pogledali zametke in smer razvoja e-poslovanja,

njegov tako imenovani razmah.

Poleg slednjega smo uporabili še metodo klasifikacije, da smo lahko razčlenili in pojasnili

določene pojme v zvezi z izbrano tematiko, komparativno metodo, da smo lahko med

seboj primerjali različne podatkovne strukture in pojave povezane z e-poslovanjem,

zgodovinsko metodo, da smo nakazali zametke, smer razvoja in pomembnost e-poslovanja

ter metodo kompilacije, saj smo spoznanja in stališča povzemali tudi od drugih avtorjev.

V empiričnem delu smo uporabili kvalitativno študijo primera. V našem primeru gre za

raziskavo primera, s katero smo raziskali problem uvajanja novih podatkovnih standardov

v poslovne informacijske rešitve. S pomočjo študije primera smo preverili zastavljene

hipoteze in jih skušali potrditi. Pri tem smo analizirali zbrano dokumentacijo in opravili

strukturirane intervjuje na namensko izbranem vzorcu.

Glede na tip študije primera gre za opazovalno in situacijsko študijo. Za opazovalno študijo

primera gre zato, ker smo s pomočjo uvedbe nove programske rešitve v izbrani IS,

opazovali odzive končnih uporabnikov, kot so njihovo sprejemanje in dovzetnost na nove

programske rešitve ter optimizacijo IS, v našem primeru uvedba e-računov. Vsa

opazovanja smo tudi zapisali in jih skušali razčleniti. Za situacijsko študijo primera gre

predvsem zato, ker smo opazovali uporabnike v določeni situaciji, in to je uvedba e-

računov v IS.

V tem delu smo med seboj primerjali izbrane poslovne subjekte, in sicer podjetja, ki so

mikro ali mala, srednja in velika, zato je raziskava tudi komparativna.

Metode, ki smo se jih posluževali v empiričnem delu, s pomočjo katerih smo poskusili

potrditi postavljene hipoteze so:

intervju:

opazovanje in

analiza dokumentov.

Pri metodi intervjuva gre za »pol strukturiran« intervju. Glede na vrsto, gre za dve vrsti

intervjuva, in sicer:

individualni (izvedba intervjuva neposredno s končnim uporabnikom ali preko

telefonskega klica) in

skupinski intervju (sama izvedba intervjuva se je izvedla na začetku ali koncu

izobraževanja strank, število udeležencev je bilo od 10 do 15).

Pri pol strukturiranem intervjuju smo pripravili seznam vprašanj in tem, ki smo jih želeli

raziskati. Takšen intervju nima natančnega določenega poteka, vodimo ga na podlagi teme,

ki jo raziskujemo in nabora nekaj vprašanj (Merriam 1998). Ni nujno tudi to, da vsi

vprašani dobijo ista vprašanja, kar pa je odvisno od tega, koliko vprašani vedo o tej temi in

kaj si o njej mislijo. Prednost te vrste intervjuja je, da bomo lahko določena vprašanja

izpustili ali pa dodali dodatna podvprašanja, torej možnost izbire in kombinacija vprašanj.

12

Izbira namenskega vzorca

Odločili smo se da izberemo 9, ki so privolila na intervju. Vzorčenje temelji na namensko

in majhnem izbranem vzorcu. Izbrali smo tista podjetja, od katerih lahko izvemo največ,

glede na subjektivno oceno. To so podjetja različnih velikosti in z različnimi izkušnjami o

e-računih.

Izvedba intervjujev

Za lažjo in optimalno izvedbo intervjuja, smo se zgledovali po sedmih stopnjah

načrtovanja in izvajanja intervjujev, po avtorju Kvale (1996):

Določitev tematike, ki smo jo določili v teoretičnem delu in smo jo s pomočjo

globinskih intervjujev preverili, postavljene hipoteze pa potrdili ali ovrgli;

Snovanje in načrtovanje, kjer smo s pomočjo določitev okvirnih vprašanj in tem

pol strukturiranega intervjuja in izbiro subjektivnega namenskega vzorca

udeležencev intervjuja ter določitev kraja in čas intervjuja, lažje izpeljali naslednjo

stopnjo. Intervju je sestavljen iz osmih vprašanj, ki so odprta in je trajal pol ure.

Pomagali smo si tudi s podvprašanji, tako da smo usmerjali smer intervjuja;

Izvedba intervjuja, ki se je v večini primerov izvedel na sedežu izbranega podjetja

končnega uporabnika ali IT strokovnjaka. V drugem primeru pa se je izvedel

skupinski intervju na sedežu podjetja Pro-Bit d.o.o.;

Prepis. Odgovore strank smo si zabeležili in jih takoj po končanem intervjuju

ponovno prebrali in preoblikovali;

Analiza. Posamezne pridobljene odgovore od udeležencev intervjuja smo analizirali

in jih razdelili po tematskih sklopih, kar imenujemo navzkrižna analiza;

Verifikacija. V primeru nerazumevanja posameznih odgovorov lahko ponovno

preverimo natančnost in zanesljivost pridobljenih podatkov, kar imenujemo

verifikacija in

Poročanje je zadnja stopnja pri izvedbi intervjuja in pomeni poročanje o

ugotovitvah na razumljiv in berljiv način, ki smo jih pridobili med intervjujem.

Naslednja metoda, ki smo jo uporabili v študiji primera je metoda opazovanja. Upoštevali

smo mnenja, občutenja in vrednotenja udeležencev, ki so vključena v študijo. Opazovali

smo udeležence intervjuva, spremljali pogovore sestankov in se udeleževali seminarjev na

temo uvedbe novih standardov e-računov.

Zadnja metoda, ki smo jo uporabili je metoda analiza dokumentov. Analizirali smo

primarne dokumente, to so dokumenti, ki smo jih pridobili v procesu našega raziskovanja

in sekundarne dokumente, to pa so dokumenti, ki že obstajajo, neodvisno od našega

raziskovanja.


primeren podatkovni standard e-SLOG.

S pomočjo metode analize dokumentov, tako primarnih kot sekundarnih, smo skušali

analizirati in pridobiti dovolj podatkov za potrditev, da samovoljnost bančnih sistemov in

velikih podjetij ter medsebojno dogovarjanje, bistveno vplivata na zaviranje razvoja e-

13

računov. S tem predvsem apeliramo, da obstaja veliko podatkovnih struktur izmenjave

podatkov, ki so nekonsistentni in so uporabni samo za določeno podjetje. Tudi banke pri

podatkovnih standardih še zdaleč niso poenotene. Lahko bi tudi rekli, da Združenje bank

Slovenije, ki bi naj skrbela za tovrstne standarde izmenjave podatkov, ne opravlja svojega

dela optimalno.

S pomočjo metode intervjuva smo pridobili podatke o tem ali podjetje uporablja poljubne

podatkovne strukture ali se poslužuje standardiziranih podatkovnih struktur, ki so

implementirane v poslovno informacijski sistem. Hkrati smo pridobili tudi mnenje ali se

podjetje nagiba bolj k standardizaciji postopkov ali ne.



S pomočjo metode analize dokumentov, tako primarnih kot sekundarnih, smo raziskali

uvajanje programske rešitve v izbrani IS, to je uvedba e-računov in novih podatkovnih

standardov za izmenjavo podatkov. Pokazati želimo, da skrbno načrtovana in optimalno

izbrana metoda programiranja, ugodno vpliva na uvedbo programske rešitve v izbrani

poslovni informacijski sistem.



S pomočjo metode analize dokumentov, tako primarnih kot sekundarnih, smo skušali

potrditi, da je standardizirane podatkovne strukture lažje implementirati v obstoječi

poslovni informacijski sistem. Ker so takšne podatkovne strukture standardizirane, pomeni,

da so dokumentirane in vsebujejo tehnične specifikacije ter določena pravila, ki se

konsistentno uporabljajo kot pravila, smernice ali definicije lastnosti, da bi storitve

ustrezale svojemu namenu (ISO). Prav tako smo skušali dokazati, da je takšne programske

rešitve, ki vsebujejo standardizirane podatkovne strukture lažje vzdrževati.

S pomočjo metode intervjuva smo pridobili podatke od ključnih uporabnikov v podjetjih.

V vzorcu so podjetja, ki uporabljajo standardizirane podatkovne strukture in podjetja, ki

uporabljajo poljubne podatkovne strukture za prenos podatkov. Pridobljene odgovore smo

med seboj primerjali in skušali dokazati, da se pri uporabi poljubnih podatkovnih

strukturah pojavi težava pomanjkanja specifikacij, znanj in časa ter da je vpeljava tovrstnih

podatkovnih struktur dolgotrajnejša in hkrati tudi stroškovno višja. Medtem ko se pri

uporabi standardiziranih podatkovnih struktur stroškovni vidik bistveno zmanjša,

predvsem zaradi razvoja in vzdrževanja programske rešitve.


S pomočjo metode analize dokumentov, tako primarnih kot sekundarnih, smo analizirali,

ali velikost podjetja res vpliva na težnjo po večji standardizaciji in izmenjavi e-

dokumentov. Iz tega vidika je tudi zanimanje po e-računih večje kot pri manjših podjetjih.

Potrditi želimo, da velika podjetja bistveno lažje vplivajo na uveljavitev podatkovnih

standardov pri izmenjavi kot podjetja manjših velikosti.

S pomočjo metode intervjuva, tako individualnega kot skupinskega, smo pridobili mnenja

udeležencev o e-poslovanju in uvedbi e-računov v izbrani IS. Pri tem smo se osredotočali

na končne uporabnike, deloma tudi na IT strokovnjake, odvisno od tega, kdo je v podjetju

zadolžen za spremljanje novih programskih rešitev, ki jih prejmejo od programskih hiš.

Običajno je tako, da imajo v velikih podjetjih oblikovan svoj IT oddelek, kjer sprejemajo

14

vse odločitve z uvedbami novih programskih rešitev, medtem ko pa so v manjših podjetjih

za tovrstne odločitve zadolženi končni uporabniki s priglasitvijo nadrejenega.

S pomočjo metode opazovanja, smo pridobili podatke o neverbalni komunikaciji, torej

kaj si udeleženci intervjuva sploh predstavljajo pod pojmom e-poslovanje in e-računi.

Večinoma gre za profil izobrazbe računovodja in knjigovodja, ki ima predvsem odklonilen

odnos in strah pred novitetami v izbranem IS. Če pa na drugi strani primerjamo IT

strokovnjake, je položaj popolnoma nasproten. Le-ta sili končne uporabnike k sprejemanju

in uporabljanju novitet v izbranem IS, da bi s tem imeli čim manj ročnega vnosa podatkov

in več avtomatske obdelave podatkov.

Hkrati smo se udeleževali seminarjev na to temo in imeli možnost sodelovanja na

sestankih in s tem pridobili podatke o vedenju in odnosu ljudi do e-poslovanja in e-

računov, neodvisno od izbranega IS.

1.3.4 Predpostavke in omejitve raziskave

Ko govorimo o e-poslovanju in o e-računih, predpostavljamo, da ima organizacija že

vpeljan poslovno informacijski sistem ter e-poslovanje in e-računi predstavljajo le

nadgradnjo in racionalizacijo obstoječega informacijskega sistema. Za nemoteno e-

poslovanje in izdajanje ter prejemanje e-računov obstaja omrežje oziroma infrastruktura za

izmenjavo.

V magistrskem delu smo se osredotočili predvsem na e-dokumente, ki predstavljajo na eni

strani izdani račun in na drugi strani prejeti račun. Prikazali smo postopek uvajanja

podatkovnih standardov v izbrani informacijski sistem. Hkrati tudi končni izdelek, in sicer

prejemanje e-računa iz banke, uvoz računa v informacijski sistem ter plačevanje prejetega

e-računa. Vsi ostali e-dokumenti nas v tem delu ne zanimajo.

Omejili smo se na izbrani poslovno informacijski sistem, in sicer Pro 3 in izbrano banko.

Obravnavali smo e-račune na področju Slovenije, hkrati pa se bomo dotaknili tudi izkušenj

iz tujine, predvsem iz Evropske unije.

15

2 E-POSLOVANJE

Soočamo se z enim največjih izzivov, tako v Evropi kot v Sloveniji. Zadeva pa predvsem

podjetja in njihovo poslovanje. Kako postati bistveno bolj učinkoviti in tudi okolju prijazni

pri svojem poslovanju. Veliko študij je dokazalo, da obstaja velik potencial ali tako

imenovana rezerva na področju digitalizacije in avtomatizacije administrativnih del v

večini podjetij (European Comission, 2011). Z drugo besedo bi lahko rekli, da se

zanimanje za e-poslovanje (angl. Electronic bussines) povečuje. Ne samo povečuje,

temveč napredna informacijska tehnologija nas sili k vse bolj brez papirnem poslovanju.

Samo e-poslovanje vodi v vse večjo globalizacijo, odpiranje in povezovanje tržišč.

Podjetjem, ki pa so dovolj fleksibilna in nagnjena k inovacijam, pa bo le-to omogočilo

obdobje razcveta (Gričar 1997).

Za lažje razumevanje problematike moramo najprej opredeliti, kaj sploh je e-poslovanje.

Po Turbanu (2003) je e-poslovanje proces nakupovanja in prodajanja izdelkov, storitev in

informacij, ki vključuje tudi sodelovanje s poslovnimi partnerji preko računalniških

omrežij ter izvajanje elektronskih transakcij znotraj organizacije. Pri tem pa velja

poudariti, da e-poslovanje ne predstavlja le sodelovanja s podjetji, temveč tudi poslovanje

z drugimi organizacijami.

Po Zakonu o elektronskem poslovanju in elektronskem podpisu Republike Slovenije (v

nadaljevanju (ZEPEP) pa e-poslovanje zajema poslovanje v e-obliki na daljavo z uporabo

informacijske in komunikacijske tehnologije in uporabo elektronskega podpisa v pravnem

prometu, kar vključuje tudi e-poslovanje v sodnih, upravnih in drugih podobnih postopkih,

če zakon ne določa drugače.

Samo elektronsko poslovanje je postalo pomembno predvsem za dva poslovna modela

(Abrazhevich, 2004):

B2C – poslovanje med podjetji in kupci (angl. Bussines to consumer) in

B2B – poslovanje med podjetji (angl. Bussines to Bussines).

Tako kot je za vsako poslovanje pomembna varnost, obstaja pri e-poslovanju glavna

problematika, in sicer: varna izmenjava denarja med sodelujočima partnerjema. V e-

poslovanju so plačila izvedena v denarju, ki so izražena v elektronski obliki, zato je

temeljni problem zagotavljanje varnosti pri tovrstnih poslih. V nadaljevanju bomo

pregledali priložnosti in nevarnosti, ki jih e-poslovanje prinaša s seboj, opredelili e-

dokumente, predelali zakonsko ureditev na tem področju ter zagotavljanje e-varnosti pri

tovrstnih poslih in njihovo e-arhiviranje.

2.1 Priložnosti in ovire e-poslovanja

Vsaka noviteta s seboj prinaša priložnosti in hkrati ovire. V nadaljevanju bomo opredelili

ključne prednosti e-poslovanja po izbranih avtorjih in hkrati slabosti.

16

Priložnosti e-poslovanja

Po Zupanu (2000) lahko z e-poslovanjem dosežemo predvsem zniževanje stroškov,

prilagodljivost in odzivnost, prednost pred konkurenco, poslovne priložnosti in boljše

analiziranje trga ter učinkovitejše poslovanje s poslovnimi partnerji.

Chen (2001) navaja ekonomski vpliv e-poslovanja. Z e-poslovanjem si lahko zagotovimo

boljše tržne informacije, znižamo proizvodne, distribucijske in transakcijske stroške,

imamo večjo možnost prilagajanja cen ter tvorjenja tako imenovanih virtualnih skupnosti.

Poglavitne prednosti elektronskih dokumentov bi lahko opredelili tudi takole:

povečana hitrost omogoča izmenjavo dokumentov v krajšem času. Elektronski

dokument hitreje prispe od pošiljatelja do naslovnika, kot če bi dokument poslali

fizično. Takšen e-dokument je potem hitreje dosegljiv v informacijskem sistemu in

pripravljen za nadaljnjo e-obdelavo.

zmanjšanje stroškov poštnin in poštnega materiala. Čeprav mnogi navajajo

zmanjšanje stroškov poštnin, poštnega materiala in papirja na katerega natisnemo

račun, bi lahko rekli, da ti stroški v večini podjetij, tako velikih ali majhnih, niso

poglavitni. Tudi neke enormne optimizacije samo iz tega vidika ni pričakovati, res

pa je, da pripomorejo k znižanje stroškov pisarniškega materiala.

ekološko primerno za okolje. Danes je vse preveč kadra v podjetjih, ki je nagnjen k

tiskanju dokumentov, ne samo računov, ampak tudi ostalih dokumentov. S tem

lahko beležimo večji pritisk na okolje in uporaba e-dokumentov nedvomno

pripomore k zmanjšanju obremenjevanje okolja.

Ovire e-poslovanja

Najpogostejše dejavnike, ki predstavljajo ovire pri e-poslovanju bi lahko opredelili kot

(Turban, King 2003):

pripravljenost ljudi do e-poslovanja; običajno so uporabniki tisti, ki imajo zaviralni

odnos pri spremembi in optimizaciji dela;

zakonska ureditev, ki spodbuja in nagrajuje ter regulira takšno uporabo e-

poslovanja;

slabo zasnovani in ne poenoteni tehnični standardi in protokoli, preko katerih

poteka prenos informacij ter slabi varnostni protokoli s katerimi ne zagotavljamo

zaupnost informacij;

dogovori med velikimi poslovnimi partnerji o uporabljenih protokolih za izmenjavo

podatkov, saj podjetja skušajo v svoj poslovni informacijski sistem zajeti čim več

podatkov o svojih dobaviteljih in kupcih s pomočjo elektronske izmenjave; s tem

vplivajo na nekonsistentnost protokola izmenjave podatkov;

slabe podporne storitve drugih poslovnih subjektov, ki skrbijo za strokovno pomoč

pri uvajanju e-poslovanja.

Kot ovire za e-poslovanje majhna podjetja najpogosteje navajajo pomanjkanje kadrov,

premajhno število uporabnikov, naravo dela ter visoke stroške strojne in programske

opreme. Velja upoštevati dejstvo, da majhna in srednje velika podjetja predstavljajo skoraj

99% vseh podjetij v državah članicah Evropske unije in ustvarjajo znaten delež bruto

družbenega proizvoda opreme (Bogataj et al. 2002, 6).

17

Prav zaradi navedenega je pomembno, da tudi majhne in srednje velike organizacije ne

spregledajo priložnosti za višjo produktivnost, pospeševanje inovacij, ki jih ponujata

uporaba informacijske tehnologije in e-poslovanje.

2.2 Opredelitev e-računov

Preden opredelimo e-račune, moramo opredeliti pojem e-dokumentov. E-dokument je

nekoliko širše pojmovanje dokumentov, ki se posredujejo v elektronski obliki. Njegov

namen ni, da ga natisnemo, temveč da se ga primerno posreduje, obdela in arhivira, seveda

vse v e-obliki. E-dokumenti so lahko e-naročilnice, e-dobavnice, e-računi, e-opomini in

podobno.

V našem delu se osredotočamo samo na prejemanje e-računov, zato bomo v nadaljevanju

opredelili pojem e-računa. Elektronski računi oziroma e-računi so dokumenti, ki so

izmenjani na elektronski način, največkrat preko interneta. E-račun vsebuje vsaj toliko

informacij, kot jih vsebuje račun v papirni obliki, zato se ga lahko natisne (čeprav to ni

njegov primaren namen), posreduje in arhivira.

Da lahko upoštevamo račun kot elektronski račun, mora biti izdan in prejet v kateri koli

elektronski obliki zapisa. Račun je lahko v obliki strukturiranih sporočil (kot je XML) z

ustrezno vizualizacijo ali drugih vrst elektronskih oblik (kot je e-pošta s prilogo PDF ali

sporočilo, prejeto po telefaksu v elektronski obliki in ne v papirni obliki).

Vsi računi, ki so ustvarjeni v elektronski obliki, se v skladu z opredelitvijo ne štejejo za

»elektronski račun«. Računi, ki so ustvarjeni v elektronski obliki, na primer z

računovodsko programsko opremo ali programsko opremo za obdelavo besedil in ki so

poslani in prejeti v papirni obliki, niso elektronski računi.

Kot elektronski računi pa se lahko štejejo računi, ki so ustvarjeni v papirni obliki in ki se

optično preberejo, pošljejo in prejmejo pa prek e-pošte.

Torej ni pomembna vrsta elektronske oblike računa, ampak dejstvo, da je račun v

elektronski obliki, ko je izdan in prejet. To omogoča pošiljanje in prejemanje elektronskih

računov v eni obliki zapisa, ki se lahko nato pretvori v drugo (DURS 2013).

Vredno je poudariti, da je e-račun poslovna listina, ki je med vsemi poslovnimi listinami v

e-obliki, med organizacijami, trenutno še vedno najmanj izmenjana. Še vedno prevladujejo

računi, ki so izdani v papirni obliki.

V Evropi je letno izdelanih približno 18 milijard računov (Falys 2003). Večina se jih

natisne na papir in pošlje poslovnim partnerjem po pošti. Kljub temu, da so možni

prihranki izvajanju procesov izdajanja in prejemanja računov na e-način znani, se le-to v

organizacijah, predvsem majhnih, ni razširilo.

V nadaljevanju bomo pogledali nekaj modelov e-računov.

18

2.2.1 Preslikavanje e-računa

Pri modelu preslikavanje računa, račun prejmemo v fizični, torej v papirni obliki. S

pomočjo skenerja, ga preslikamo in s tem zagotovimo nadaljnjo e-obliko poslovne listine.

S tem načinom pridobimo nadzor nad listino, ki nam omogoča, da jo v vsakem trenutku

tudi pogledamo opreme (Bogataj et al. 2002, 9). Naprednejši IS, ki imajo integriran tudi

dokumenti sistem in takšne e-račune tudi shranjujejo, omogoča vpogled v izbrano e-listino

na vsaki točki v IS, na primer v plačilnem prometu, na izpisih odprtih postavk, izpisu

opominov in podobno.

Direktiva Evropske komisije zahteva (Flechsig et al. 2003) od držav članic Evropske unije

shranjevanje originalnih računov (v papirni obliki ali e-računov), kar pri uporabi

omenjenega modela lahko povzroči dvojno shranjevanje računov, in sicer v zbirnikih v

fizični obliki in v e-arhivu v elektronski obliki.

Večina podjetij, ki uporabljajo program PRO3 programe, uporablja skenerje in integriran

dokumentni sistem. Ko račun prispe v fizični obliki, ga preslikajo, odobrijo odgovorne

osebe in poknjižijo. V trenutku, ko ga preslikajo, se shrani v dokumentni sistem (lahko je v

jpg, pdf obliki in podobno).

2.2.2 Standardni ali nestandardni model e-računa

Pri omenjenem modelu je račun posredovan v standardizirani ali nestandardizirani obliki

(HTML, Word, Excel, PDF,…). Temu modelu lahko rečemo tudi »izoliran model e-

računov«. Kupec pri tem prejme račun neposredno od dobavitelja oziroma poslovnega

partnerja. Prejemnik računa le-tega ročno vnese v lasten informacijski sistem. Potrjevanje

računa, kopiranje osnovnih podatkov računa, ki bi bili dosegljivi za nadaljnje procese v

celovitih programskih rešitvah, ni e-podprto opreme (Bogataj et al. 2002, 10). S to

trditvijo se ne moremo povsem strinjati, saj naprednejši informacijski sistemi, ki imajo

integriran tudi dokumentni sistem, omogočajo, da se ob ročnem vnosu računa v poslovni

program, pripne priponka, ki omogoča vsaj delno e-obdelavo, če že ne e-vpogled v listino.

Če so računi v standardizirani Excel obliki, se da programsko podpreti, da se takšen račun

uvozi v poslovni IS, s tem dosežemo nižje stroške ročnega vnosa in manjšo možnost napak

pri vnosu. Seveda se slednje izplača le, če imamo masovno število prejetih računov v

standardizirani obliki.

Takšen model e-računa niti ni najbolj optimalen, saj ga z e-računom povezuje samo to, da

je bil posredovan elektronsko (na primer po e-pošti).

2.2.3 E-račun z uporabo spletnih obrazcev

Uporaba omenjenega modela je primerna v primeru, ko večji kupec, ki redko izvaja

nakupe pri določenem dobavitelju, želi prejeti račun v e-obliki. Dobavitelj se v tem

primeru poslužuje spletne strani, na kateri v obrazec ročno vnese podatke o računu. Kupec

19

ima v tem primeru vpliv na obliko računa, kar omogoča tudi nadaljnje avtomatsko

obdelovanje računa.

V tem primeru lahko kupec sam vzdržuje spletno stran, kjer uporablja spletne obrazce e-

računov, ali pa to namesto njega dela pooblaščeno programsko podjetje. Vsekakor pa

upravitelj zagotavlja nadzor nad shranjevanjem in varnostjo računov opreme (Bogataj et

al. 2002, 10).

Slabosti pri uporabi omenjenega modela so (Flechsig e tal. 2003):

dobavitelj ima zelo majhen vpliv na shranjevanje računov, pogoje za zagotavljanje

celovitosti in avtentičnosti originala;

dobavitelj se lahko srečuje s podobnimi zahtevami drugih kupcev, pri čemer bi bilo

potrebno uporabljati različne spletne strani z drugačnimi pravili v zvezi s

shranjevanjem in varnostjo računov in

ker dobavitelj podatke vnaša tudi v lasten sistem (podvajanje), bi lahko prihajalo do

napak.

2.2.4 E-račun preko ponudnika storitev

Omenjeni model prikazuje situacijo, kjer so potrebne storitve tretje stranke, predvsem

ponudnika programerskih rešitev, zaradi premagovanja različnih interesov strank v zvezi z

uporabo komunikacijskih protokolov, standardov sporočil. Takšen ponudnik storitev

izmenjavanja e-računov ponuja različne komunikacijske protokole in standarde oblik

posameznih računov ter zagotavlja tudi pretvarjanje le-teh opreme (Bogataj et al. 2002,

10).

Storitve ponudnika lahko vsebujejo poljubne ali standardizirane podatkovne strukture za

izmenjavo podatkov, odvisno od zahtev in interesov strank.

Kupec in dobavitelj lahko v tem primeru zelo zmanjšata razvoj lastnih rešitev in

zagotavljata le komunikacijo oz. prenos računov med njim in ponudnikom storitev.

Omenjeni model je možno uporabiti tudi za podporo drugim poslovnim procesom, npr.

povezovanje sistema izmenjavanja računov s finančnim sistemom (plačevanje). Ker so

računi v e-obliki in v toku celotnega procesa so pripravljeni za avtomatsko obdelovanje.

Ponudnik storitev lahko ponudi tudi dodatne storitve, npr. shranjevanje poslovnih listin v

dokumentni sistem opreme (ibid.,10).

Izmenjavanje poslovnih listin je v tem primeru omogočeno na različne načine, na primer

preko e-pošte, na svetovnem spletu ali preko VAN (Value Added Network) omrežja.

Poslovanje preko ponudnika storitev e-poslovanja bi organizacijam omogočilo, da zgradijo

informacijski sistem po svojih željah, poslovne listine namenjene poslovnim partnerjem, pa

bi se v ustrezno obliko preoblikovale pri ponudniku storitev e-poslovanja. Interes za

poslovanje preko ponudnikov storitev e-poslovanja med majhnimi organizacijami v

Sloveniji se je izkazal predvsem za pošiljanje e-poslovnih listin svojim poslovnim

partnerjem (Zupan 2000).

20

Danes večinoma vsa podjetja elektronsko plačujejo in poravnavajo svoje obveznosti.

Lahko rečemo, da imajo banke in druge institucije, kot sta na primer Združenje bank

Slovenije1 in Halcom

2, izjemno vlogo.

Glede na to, da je e-plačevanje med organizacijami dobro razširjeno, vzpostavljena

infrastruktura bankam lahko predstavlja osnovo za razširjanje storitev.

2.3 Razvoj in zahteve plačilnih sistemov po e-dokumentih

Elektronska plačila so del e-poslovanja in so eden izmed večjih kritičnih dejavnikov

takšnega načina poslovanja. Lahko bi tudi rekli, da so e-plačila oblika finančne izmenjave,

ki se odvija med kupcem in prodajalcem in je omogočena z elektronskimi povezavami

(Kalakota et. al, 1997). Prav e-plačilni sistemi izvajajo plačila od kupca do prodajalca, ki

morajo biti dovolj varni. Vsekakor pa je nadaljnja rast varnih e-poslovanja v veliki meri

odvisna od dobrih elektronskih plačilnih sistemov.

Za dobro e-varnost in e-poslovanje moramo imeti dobre temelje. S tem mislimo na dobro

zasnovano in nedvoumno zakonodajo, ki na eni strani vzpodbuja rast e-poslovanja,

natančneje tudi uporabo e-dokumentov, na drugi strani pa zagotavlja e-varnost pri

tovrstnem poslovanju.

Vsekakor imajo veliko vlogo tudi institucije, kot so Gospodarska Zbornica Slovenije3 in

Združenje bank Slovenije, ki s svojimi smernicami in standardi, vplivajo na tok razvoja e-

dokumentov.

V nadaljevanju bomo opredelili najpomembnejše člene in zakone ter pojmovanje

slovenske zakonodaje na področju e-poslovanja, natančneje e-računov.

1

Združenje bank Slovenije je institucija, ki zastopa skupne interese članic Združenja pri državnih organih,

monetarnih oblasteh, finančnih organizacijah ter drugih združenjih o vprašanjih, ki zadevajo urejanje

razmerij iz makroekonomskih in denarnih politik, se povezuje z gospodarstvom, svetuje, razvija

informacijske sisteme in informacijsko tehnologijo za potrebe članic, sodeluje pri izdelovanju skupnih

standardov in rešitev s področja poslovanja bank in drugih članic, plačilnega prometa, tehnologije in tehnike

ter skrbi za poenotenje vseh vrst obrazcev in podobno (ZBS). 2 Podjetje Halcom velja za pionirja uvajanje e-računov na področju Slovenije. Podjetje Halcom je od leta

1992 do danes postalo vodilni ponudnik rešitev za plačilne sistem v srednji in jugovzhodni Evropi. Svoje

rešitve za e-bančništvo so prodali že več kot 70-im bankam, štirim centralnim bankam in klirinških hišam.

Halcom so leta 2003 nagradili z nazivom Zlata gazela, vendar podjetje raste tudi v lasu krize, predvsem z

usmeritvijo na nove

tuje trge (Čadež 2012). 3 Gospodarska zbornica Slovenije je največje samostojno, prostovoljno, interesno in nepridobitno združenje

gospodarstva, ki kot eno od združenj delodajalcev zastopa interese svojih članov v odnosih z državo in

sindikati pri oblikovanju pogojev dela in poslovanja ter pri zagotavljanju pogojev za gospodarski razvoj.

Svojim članom nudi širok nabor storitev za podporo poslovanju podjetij ter zagotavlja nove priložnosti za

razvoj, konkurenčnost in prodor na tuje trge. Na ta način vzpodbuja gospodarski, družbeni in okoljski razvoj

v Sloveniji (GZS).

21

2.3.1 Slovenska zakonodaja na področju e-dokumentov

Zakon, ki najbolj obsežno opredeljuje e-poslovanje in z njim povezane e-dokumente, je

nedvomno Zakon o elektronskem poslovanju elektronskem podpisu, ki je bil sprejet 23. 6.

2000 v Uradnem listu RS, št. 57/2000 (v nadaljevanju ZEPEP).

ZEPEP vsebuje:

posamezne izraze, ki so povezani z e-poslovanjem, to so: podatki v elektronski

obliki, elektronsko sporočilo, elektronski podpis, elektronski časovni žig in

podobno;

elektronsko poslovanje, ki opredeljuje elektronsko sporočilo, podatke v elektronski

obliki in odgovornost ponudnikov informacijske družbe (ZEPEP-A);

elektronski podpis, ki opredeljuje predvsem potrdila in overitelje, ki jih izdajo,

kvalificirana potrdila in overitelje, ki jih izdajo, tehnične zahteve za varno

elektronsko podpisovanje, odgovornost overiteljev, njihov nadzor in podobno ter

kazenske določbe.

Po ZEPEP so podatki v elektronski obliki podatki, ki so oblikovani ali shranjeni na

elektronski način. Elektronsko sporočilo pa je niz podatkov, ki so poslani ali prejeti na

elektronski način, kar vključuje predvsem elektronsko izmenjavo podatkov in elektronsko

pošto.

Posebej izpostavljamo spodnja dva člena omenjenega zakona, ki dajeta enako veljavnost

elektronskim podatkom, kot jo imajo podatki v pisni obliki.

13. člen ZEPEP (2 oddelek, Podatki v elektronski obliki) opredeljuje, da je elektronska

oblika enakovredna pisni obliki, če so podatki v elektronski obliki dosegljivi in primerni za

kasnejšo uporabo, razen če zakon drugače ne določa (Ur.l. RS, št. 57/2000).

3. člen ZEPEP-UPB1 (Prvo poglavje, Splošne določbe) opredeljuje, da se podatkom v

elektronski obliki ne sme odreči veljavnosti ali dokazne vrednosti samo zato, ker so v

elektronski obliki (Uradni list RS, št. 98/2004).

Torej ZEPEP daje isto vrednost elektronskim dokumentom kot tudi pisnim dokumentom.

Glede na to, da se v magistrskem delu lotevamo e-dokumentov, natančneje e-računov, smo

tudi v Zakonu o davku na dodano vrednost, ki je bil sprejet 26.10.2006 in objavljen v

Uradnem listu RS, št. 117/2006 našli člen, ki se nanaša na to temo.

84. člen ZDDV-1 (Uradni list RS, št. 117/2006):

2. odstavek opredeljuje, da se račun lahko izda v papirni obliki, lahko pa tudi v

elektronski obliki, če s tem soglaša kupec oziroma naročnik in če je zajamčena

pristnost izvora in celovitost vsebine;

3. odstavek pravi, da se račun lahko izda v elektronski obliki v skladu s predpisi, ki

določajo elektronsko poslovanje, če so izpolnjeni naslednji pogoji:

zagotovljena mora biti avtentičnost izvirnika računa, tako da prejemnik računa

lahko ugotovi, da je tak račun resnično poslal izdajatelj računa;

http://www.uradni-list.si/1/objava.jsp?urlid=200057&stevilka=2615

22

iz elektronskega sporočila morata biti razvidna čas in kraj odpošiljanja in

prejema računa;

zagotovljena mora biti integriteta računa, tako da uporabljena tehnologija in

postopki v zadostni meri onemogočajo spremembo podatkov na računu.

4. odstavek pravi, da ne glede na prejšnji odstavek se račun za namene DDV lahko

pošlje ali je dan na razpolago na elektronski način z elektronsko izmenjavo

podatkov (EDI4), če je zajamčena avtentičnost izvora in integriteta vsebine;

5. odstavek pravi, da lahko davčni zavezanec, ki istemu prejemniku na elektronski

način pošlje ali da na razpolago sveženj z več računi, lahko podatke, ki so skupni

posameznim računom, navede samo enkrat, če so za vsak račun dostopne vse

informacije;

Tudi ZDDV-1, daje enako veljavo elektronskemu računu, kot jo ima račun v papirni obliki.

ZDDV-1 se sklicuje na ZEPEP, kdaj je lahko račun posredovan elektronsko.

Lahko bi rekli, da je zakonodaja na področju e-poslovanja in e-računov dobro opredeljena.

Vendar do konca leta 2013 nikjer ni bilo zaznati zakonske vzpodbude, ki bi poslovne

subjekte pritegnila ali jih celo prisilila k tovrstnemu e-poslovanju.

Na primer AJPES5 uporabnike za oddajo letnih poročil pritegne k elektronski oddaji

poročil tako, da v primeru pošiljanja dokumenta v papirni obliki po pošti zaračuna višje

stroške javne objave, kot pa če je letno poročilo elektronsko oddano in e-podpisano z

digitalnim kvalificiranim potrdilom (AJPES 2014).

Dne 27. 12. 2013 je bil v Uradnem listu št. 111/2013 objavljen Zakon o spremembah in

dopolnitvah Zakona o opravljanju plačilnih storitev za proračunske uporabnike (ZOPSPU-

A), ki opredeljuje, da je s 01.01.2015 obvezno pošiljanje računov v javni sektor v

elektronski obliki.

Proračunski uporabniki bodo morali prejemati račune in spremljajoče dokumente izključno

v elektronski obliki. To pomeni, da bodo morale pravne in fizične osebe za dobavljeno

blago, izvedene storitve ali izvedene gradnje pošiljati proračunskim uporabnikom e-račune

(DURS 2013).

Obvezno pošiljanje e-računov v javni sektor bo spodbudilo približevanje maksimalnemu

obsegu uporabe e-računov v zasebnem in javnem sektorju ter prispevalo k racionalnejšemu

poslovanju tako javnega sektorja kot gospodarstva (ibid.).

2.3.2 Evropske smernice na področju e-dokumentov

S področjem e-poslovanja se je prva pričela ukvarjati organizacija Združenih narodov,

imenovana UNCITRAL (angl. United Nations Commission on International Trade Law).

Omenjena organizacija je izdala vzorčni zakon o elektronskem poslovanju, leta 1996 in

vzorčni zakon o elektronskem poslovanju, leta 2001. Z namenom širšega vključevanja

4 EDI angl. Electronic Data Interchange.

5 AJPES zbirata in posredovatuje podatke o poslovnih subjektih zainteresirani javnosti, s ciljem zagotavljanja

transparentnosti mikro in makro družbenega okolja, ob stalnem povečevanju učinkovitosti in zadovoljstva

uporabnikov (AJPES).

23

majhnih in srednje velikih podjetij v e-poslovanje je Svet Evropske komisije sprejel serijo

direktiv, katerih namen je poenostavitev in posodobitev dosedanjih pravil za e-poslovanje

(Košti 2004).

Najnovejša direktiva 2001/115/EC vključuje predvsem tematiko izdajanja in prejemanja e-

računov. Direktiva je v vseh državah članicah Evropske unije pričela veljati 1. januarja

2004. Organizacije in ponudniki tehnologije so pričakovali razcvet posla na področju

izdajanja in sprejemanja e-računov, vendar se vključevanje organizacij v izvajanje

omenjenih procesov na e-način še ni razširilo. Tematika tako predstavlja izziv za celotno

Evropsko unijo. Posebej je pomembna za e-poslovanje majhnih in srednje velikih podjetij,

zato je Evropska mreža za podporo e-poslovanja predlagala pospeševanje razvoja v vseh

državah članicah Evropske unije (Gričar 2004).

2.4 Zagotavljanje varnosti pri e-plačevanju

Zagotavljanje varnosti pri e-poslovanju, je ena izmed ključnih dejavnikov, ki omogoča

porast uporabe e-dokumentov. E-dokumente je veliko bolj enostavno spremeniti in

kopirati, še preden so zajeti v poslovni informacijski sistem. Zato je izrednega pomena

njihova istovetnost, verodostojnost in avtentičnost, kot to opredeljuje ZDDV-1.

Da bi dosegli zadovoljive varnostne mehanizme, moramo upoštevati naslednje varnostne

zahteve (Jerman Blažič, 2001):

overjanje, ki pomeni nedvoumno avtentikacijo (identifikacijo) uporabnika,

strežnika ali aplikacije, do katere uporabnik želi dostopati;

zaupnost povezave med uporabnikom in strežnikom in varnost/zaščita izmenjanih

podatkov;

celovitost ali nespremenjenost izmenjanih podatkov;

nadzor dostopa ali avtorizacija, ki prepreči nepooblaščeni dostop in določa pogoje

dostopanja;

preprečevanje zanikanja, ki onemogoča zanikanje izvora podatkov in

razpoložljivost podatkov v procesu e-poslovanja, ki morajo biti v vsakem trenutku

na razpolago.

V nadaljevanju so predstavljene osnovne tehnike, ki omogočajo zadovoljive varnostne

mehanizme za varno e-plačevanje z e-računi.

2.4.1 Kriptografija oziroma šifriranje

Kriptografija (ali šifriranje) se uporablja že dlje časa za zaščito zaupnih podatkov, ki jih je

potrebno posredovati iz ene lokacije na drugo. Šifriranje pomeni preobrazba podatkov v

takšno obliko, da jih nepooblaščeni uporabniki ne morejo razbrati. S pomočjo šifriranja

lahko dosežemo verodostojnost in tajnost posredovanih podatkov ter nezmožnost zanikanja

podatkov.

24

Šifrirni sistem je sestavljen iz kriptografskega algoritma (matematična funkcija, ki podatke

s pomočjo šifrirnega ključa spremeni v neberljivo obliko) in šifrirnih ključev (število

možnih ključev pri algoritmu pa je odvisno od dolžine ključa) (Jerman Blažič, 2001).

V nadaljevanju bomo opredelili dve kriptografiji, in sicer simetrično in asimetrično.

2.4.1.1 Simetrična

Simetrična kriptografija ali kriptografija skritih ključev, uporablja en sam skriti ključ za

šifriranje in dešifriranje. Problem, ki se lahko pojavi pri tej vrsti šifriranja je, varnost pri

razdelitvi šifrirnih ključev pooblaščenim osebam. Pošiljatelj se mora dogovoriti s

prejemnikom sporočila kako prevzeti skrivni ključ, zato obstaja nevarnost, da

nepooblaščena oseba prestreže skrivni ključ in uspe dešifrirati sporočilo. Prednost

simetrične kriptografije je njena hitrost. V primeru, da gre za izmenjavo šifriranega

besedila med dvema subjektoma, je ta način izmenjave šifriranih sporočil primeren. Kadar

pa imamo več subjektov, pri čemer potrebujemo za vsakega posameznika svoj ključ, je ta

način neprimeren.

Največkrat uporabljeni standardi za simetrično šifriranje so DES (angl. Data Enncryption

Standard), IDEA (angl. International Data Enycription Algorithm), 3DES in podobni

(Oppliger 2003).

Slika 1 prikazuje šifriranje s pomočjo simetričnega algoritma, kjer s pomočjo ključa

šifriramo ali dešifriramo besedilo.

Slika 1: Šifriranje s pomočjo simetričnega algoritma

Vir: Oppliger, 2003

2.4.1.2 Asimetrična

Asimetrična kriptografija ali kriptografija javnih ključev, temelji na paru ključev, in sicer

en ključ je namenjen šifriranju, drugi ključ pa dešifriranju besedila. Vsak uporabnik ima

tako dva ključa, zasebni in javni ključ. Javni ključ se običajno nahaja na strežniku, medtem

ko pa se zasebni ključ nahaja pri lastniku. Najbolj znana asimetrična kriptografija je RSA

(imenovan po izumiteljih Rivest-Shamir-Adelman) (ibid.).

Pri asimetrični kriptografiji pošiljatelj sporočilo šifrira z naslovnikovim javnim ključem.

Naslovnik pa s svojim zasebnim ključem dešifrira prejeto sporočilo. Prednost asimetrične

kriptografije je v enostavnem pošiljanju javnih ključev, brez strahu, da bi ga prestregla

25

nepooblaščena oseba. Kot slabost asimetrične kriptografije pa je predvsem hitrost in

overjanje javnih ključev, ki je v primerjavi s simetrično kriptografijo, počasnejša. V ta

namen se daljša sporočila šifrirajo s simetričnimi kriptografskimi algoritmi, ključe za te

algoritme pa zaščitimo z asimetričnimi (ibid.).

Sama uporaba asimetrične kriptografije v infrastrukturi javnih ključev nam zagotavlja

celovitost, zaupnost, nezatajljivost sporočila in preverjanje identitete pošiljatelja. Če

sporočilo zašifriramo z javnim ključem prejemnika, ga lahko samo ta prejemnik dešifrira s

svojim zasebnim ključem (Halcom-CA, 2013).

Slika 2 prikazuje šifriranje s pomočjo asimetričnega algoritma, kjer je Kj javni ključ in Kp

privatni ali zasebni ključ.

Slika 2: Šifriranje s pomočjo asimetričnega algoritma

Vir: Oppliger, 2003

Nadgradnja asimetrične kriptografije pa je postopek digitalnega podpisovanja, ki

zagotavlja neokrnjenost sporočila in verodostojnost pošiljatelja. Več o tem v nadaljevanju.

2.4.2 Digitalni podpis

Osnovna funkcija digitalnega podpisa je v dokazovanju identitete podpisnika

elektronskega dokumenta in zagotavljanju celovitosti podatkov oziroma zaščite pred

spreminjanjem vsebine e-dokumentov.

Digitalni podpis je vrsta elektronskega sporočila, ki temelji na asimetrični kriptografiji.

Tako kot pri slednji, imamo tukaj dva ključa, in sicer javni in zasebni (Halcom-CA, 2013).

Postopek digitalnega podpisovanja poteka v dveh korakih. Najprej sporočilo skrčimo z eno

izmed zgoščevalnih funkcij (ali matematične funkcije, ki vhodne podatke poljubne dolžine,

spremenijo v podatke fiksne dolžine) v bloke enakih dolžin. Vsaka najmanjša sprememba

v izvornem sporočilu, povzroči spremembo bloka. Posamezni blok predstavlja »prstni

odtis« sporočila, ki ga šifriramo z zasebnim ključem in tako nastane digitalni podpis. Za

preverjanje digitalnega podpisa, prejemnik uporabi javni ključ podpisnika, da dešifrira

blok. Prejemnik nato še sam izračuna vrednost enosmerne zgoščevalne funkcije

podpisanega sporočila in primerja bloka. Če sta bloka popolnoma enaka, potem je

pošiljatelj res oseba, za katero se izdaja in poslano spročilo med prenosom ni bilo

spremenjeno (Centeno, 2001).

Varen elektronski podpis po ZEPEP mora izpolnjevati naslednje zahteve:

da je povezan izključno s podpisnikom;

26

da je iz njega mogoče zanesljivo ugotoviti podpisnika;

da je ustvarjen s sredstvi za varno elektronsko podpisovanje, ki so izključno pod

podpisnikovim nadzorom in

da je povezan s podatki, na katere se nanaša, tako da je opazna vsaka kasnejša

sprememba teh podatkov ali povezave z njimi.

Slika 3: Postopek digitalnega podpisovanja

Vir: Internetni vir

2.4.3 Časovni žig

ZEPEP opredeljuje časovni žig kot elektronsko podpisano potrdilo overitelja, ki potrjuje

vsebino podatkov, na katere se nanaša, v navedenem času.

Drugače rečeno je varni časovni žig digitalni zapis, ki zagotavlja podpis dokumenta z

veljavnim digitalnim potrdilom v določenem časovnem trenutku in sicer na način, da

povezuje datum in čas podpisa ter podatke v elektronski obliki na kriptografsko varen

način (SI-TSA, 2013).

Časovno žigosanja poteka tako, da želene podatke pošljemo strežniku TSA z zgostitveno

funkcijo povzetek podatkov. Strežnik tem podatkom dopiše čas in vse skupaj podpiše s

svojim zasebnim ključem, to je časovni žig. To dokazuje, da so podatki obstajali že pred

časom, ki je naveden v časovnem žigu. Hkrati pa je možno preveriti, da so podatki ostali

nespremenjeni od časa žigosanja (SI-TSA, 2013).

27

Časovno žigosanje SI-TSA deluje kot spletna storitev (angl. Web Service). To pomeni, da

si aplikacija in strežnik za časovno overjanje izmenjujeta zahtevke v XML po protokolu

SOAP prek http oziroma https (SI-TSA, 2013).

Slika 4 predstavlja postopek časovnega žigosanja

Slika 4: Postopek časovnega žigosanja

Vir: SI-TSA

Storitev časovnega žigosanja smejo opravljati samo posebne agencije, imenovane TSA

(angl. Time-Stamp Authority), ki so vpisane v register overiteljev. Te agencije trenutno so

(Ministrstvo za visoko šolstvo, znanost in tehnologija, 2014):

SI-TSA;

POŠTA-CA;

HALCOM-CA in

SIMoD-CA-Restricted.

2.4.4 Infrastruktura javnih ključev

Infrastruktura javnih ključev je celoten sistem za uporabo varnostnih metod na podlagi

asimetrične kriptografije v elektronskem poslovanju (angl. Public Key Infrastructure

oziroma PKI). Osnovna naloga PKI je omogočanje varnega poslovanja med različnimi

uporabniki, ki se med seboj ne poznajo, kljub temu pa želijo varno komunicirati (Halcom-

CA, 2013).

PKI kot sistem je sestavljen iz (ibid.):

Agencije za overjanje, katere osnovna naloga je izdajanje, varovanje in vzdrževanje

certifikatov (overitelji javnih ključev Ministrstvo za javno upravo – SIGOV-CA,

SIGEN-CA, Halcom d.d. - HALCOM-CA, NLB d.d. – AC-NLB, Pošta Slovenije

d.o.o. – POŠTA-CA, Ministrstvo za obrambo – SIMoD-CA-Restricted) ;

Agencije za registracijo;

Politika overjanja;

Sistem distribuiranja certifikatov in

Dokumenti o ravnanju s certifikati

http://www.halcom-ca.si/?section=21

28

Infrastrukturo javnih ključev določajo postopki in oprema za (ibid.):

generiranje in hranjenje ključev;

overjanje imetnikov ključev in izdajanje digitalnih potrdil;

imeniki digitalnih potrdil;

preklicevanje digitalnih potrdil in imeniki preklicanih digitalnih potrdil in

storitve časovnega žigosanja

Vsi imetniki kvalificiranih digitalnih potrdil v infrastrukturi PKI pridobijo tri osnovne

varnostne elemente elektronskega poslovanja (ibid.):

zasebni ključ;

javni ključ in

digitalno potrdilo.

Zasebni ključ omogoča tvorbo digitalnega podpisa, ki je unikaten za vsakega imetnika,

javni pa je dostopen komurkoli.

Dokument digitalno podpišemo s svojim zasebnim ključem, medtem ko podpis

preverjamo z javnim ključem podpisnika. Ključa sta med seboj tako povezana, da podpis

dokumenta, ki smo ga naredili z zasebnim ključem, lahko preverimo samo z javnim

ključem iz para. Struktura podatkov, ki povezuje imetnika z njegovim ključem se imenuje

digitalno potrdilo ali certifikat (ibid.).

Da se izognemo morebitnim zlorabam, je potrebno omenjene varnostne elemente hraniti na

čim bolj varnih nosilcih. Trenutno najvarnejša dostopna tehnologija so pametne kartice.

2.5 E-Arhiviranje

E-arhiviranje je možno opredeliti kot zadnjo in najbolj pomembno stopnjo v življenjskem

ciklu določenega sistema za upravljanja z dokumenti. Gre še zlasti za varno, sistematično

urejeno in trajno shranjevanje dokumentov na digitalnem ali elektronskem nosilcu

informacij (Petrič 2009).

Ko govorimo o arhiviranju dokumentov pri tem pomislimo na dva možna načina

arhiviranja, in sicer:

klasičen način arhiviranja (kjer arhiviramo dokumente v fizični obliki) in

e-način arhiviranja (kjer dokumente hranimo v e-obliki). Nas zanima izključno e-

način arhiviranja, ki je opredeljen v nadaljevanju. Hkrati bomo povzeli tudi nekaj

zakonskih podlag in pa metodologijo najboljše prakse povzeto po Petriču.

Prednosti elektronskega arhiviranja pred klasičnim arhiviranjem so učinkovitejša kontrola

nad uporabo dokumentov. Beleži se lahko vsak vpogled, sprememba ali izpis dokumenta in

omogoča revizijsko sledljivost skozi ves čas hrambe, časovno in krajevno neodvisno

dostopnost do dokumentov in njihovo varno hranjenje. Takšen način arhiviranja podjetju

zagotavlja ogromne prihranke časa in denarja, saj se lahko zaposleni zaradi učinkovitejšega

dostopa do dokumentov in preprostega ter hitrega iskanja informacij, posvečajo

pomembnejšim opravilom ter tako posledično povečujejo tudi učinkovitost celotnega

poslovanja podjetja (Skrt 2006).







29

Največji izziv pri hrambi e-dokumentov je zagotoviti njihovo enakovrednost fizičnim

dokumentom, zato moramo (SETCCE 2005):

dokazati, da dokument ni bil spremenjen v času hrambe;

dokazati, da je dokument obstajal v točno določenem času in

vzdrževati časovno veljavnost digitalnih podpisov in potrdil.

Hkrati moramo zagotoviti več kriterijev pri elektronski hrambi dokumentov. Omogočen

mora biti dostop do teh shranjenih dokumentov, dokumenti morajo biti dosegljivi tudi za

kasnejšo uporabo in morajo biti shranjeni v obliki, kot so bili prejeti ali poslani. Iz

dokumentov mora biti razviden izvor, čas in kraj, pošiljatelj in prejemnik ter obstajati mora

jamstvo glede nespremenljivosti e-arhiviranih dokumentov (Uradni list RS, št. 117/2006,

86. člen ZDDV-1).

Pri e-arhiviranju imata bistveno vlogo Zakon o varstvu dokumentarnega in arhivskega

gradiva ter arhivi (ZVDAGA) in Enotne tehnološke zahteve.

ZVDAGA ureja način, organizacijo, infrastrukturo in izvedbo zajema ter hrambe

dokumentarnega gradiva v fizični in elektronski obliki, veljavnost oziroma dokazno

vrednost takega gradiva, varstvo arhivskega gradiva in pogoje za njegovo uporabo, naloge

arhivov in javne arhivske službe ter s tem povezane storitve in nadzor nad izvajanjem.

Enotne tehnološke zahteve pa predpisujejo postopke zajema in pretvorbe. Predpisujejo tudi

zahtevano obliko in način izročitve arhivskega gradiva v digitalni obliki, standarde oblike

zapisa za dolgoročno hrambo in podrobneje določajo vrste tehnoloških sredstev za

zagotavljanje avtentičnosti in celovitosti gradiva v digitalni obliki za dolgoročno hrambo ter

dodatne oz. posebne pogoje za storitve v zvezi z velikimi registri in evidencami javnopravnih

oseb (Arhiv RS).

Tako zakon kot Enotne tehnološke zahteve skupaj dajeta najpomembnejšo vlogo Arhivu RS, ki

izvaja postopke registracije.

Ponudnik storitev e-arhiviranja mora (Hajtnik 2008):

registrirati programsko in strojno opremo pri Arhivu RS (zahteve so opredeljene v

Enotnih tehnoloških zahtevah);

registrirati storitve (zajem, pretvorba, urejanje in uničevanje dokumentnega gradiva

v digitalni in/ali fizični obliki ter zagotavljanje varnih prostorov za hrambo gradiva

v e-obliki);

notranja pravila, ki jih potrdi Arhiv RS (v primeru, če ponujamo storitve javnemu

sektorju) in

pridobiti akreditacijo (Arhiv RS prizna skladnost ponujene opreme z veljavnimi

predpisi; v tem primeru smemo poslovati z javnim sektorjem).

Vzpostavitev sistema e-arhiviranja po Petriču je sestavljena iz osmih korakov:

poslovna raziskava (določimo ključne dejavnike v poslovnem okolju);

analiza poslovne dejavnosti (določimo glavne funkcije in delo organizacije);

opredelitev zahtev glede hrambe zapisov;

ocena obstoječih sistemov (določimo obseg dokumentiranih poslovnih dejavnostih

znotraj organizacije);

30

identifikacija strategij za vodenje evidenc (določimo politiko, postopke, standarde

in taktiko);

načrtovanje sistema zapisa (načrtujemo nove tehnologije in načrtovanje potrebnih

nadgradenj IS);

vgradnja sistema zapisov evidenc (vsebuje projektni načrt implementacije v IS);

pregled opravljenih korakov (ocena končnega stanja in nenehno spremljanje

delovanja).

Hkrati je vzpostavitev sistema e-arhiviranja povezana s tremi dimenzijami, in sicer:

Tehnično-tehnološka (vsebuje komunikacijsko, strojno in programsko oprema);

Organizacijsko pravna (vsebuje notranja pravila, varstvo dokumentarnega gradiva,

strateško načrtovanje in analiza organizacijskega sistema, modeliranje in simulacija

delovanja organizacijskih sistemov) in

Semantična dimenzija (ukvarja se s klasifikacijskim načrtom, avtomatično

klasifikacijo in podobnim).

31

3 PODATKOVNI STANDARDI NA PODROČJU E-DOKUMENTOV

Z naraščanjem e-poslovanja in uporabo e-dokumentov, se je pojavila tudi potreba po

standardizaciji postopkov izmenjave podatkov. Velika podjetja so postopke izmenjave

prilagodile svojim procesom, medtem ko so se, in se še, manjša podjetja poslužujejo

standardiziranih postopkov izmenjave podatkov.

Z razcvetom e-poslovanja se je tudi pojavilo večje število postopkov izmenjave podatkov.

To pomeni, da so posamezni ponudniki programske opreme ponudili svoje postopke

izmenjave podatkov, saj ni bilo primerne standardizacije. S povečevanjem števila strank

pri posameznih ponudnikih, je le-ta prevzemal večji delež na trgu in »diktiral«

standardizacijo. Na drugi strani, pa so velika podjetja, ki so imela svoj lasten IT, razvijala

svoje lastne postopke izmenjave podatkov.

Kakorkoli, potreba po standardizaciji je naraščala, tako na domačem trgu kot tudi na tujem

trgu še zlasti prej. Standardizacija je tista, ki omogoča združljivost na več področjih, ne

glede na poslovanje organizacije. Na primer: Vsak prejeti račun različnega izdajatelja, ima

datum izdaje, datum opravljene storitve, ceno, DDV, vrednost in podobno, vendar na

različnem mestu. V digitalni obliki dokumenta ravno standard omogoča enotno

»označevanje« posameznih sklopov na e-dokumentu.

V nadaljevanju so predstavljeni trije pomembni standardi, ki so pripomogli k večji in

enostavnejši izmenjavi podatkov in nato tudi »pod standard« e-SLOG, ki je slovenska

različica standarda za izmenjavo e-dokumentov.

3.1 EDIFACT

EDIFACT ali UN/EDIFACT (angl. United Nations Electronic Data Interchange For

Administration, Commerce and Transport) je najbolj razširjen mednarodni standard za

izmenjavo elektronskih dokumentov in pomeni izmenjavo podatkov za administracijo,

trgovanje in transport. Natančneje je opredeljen v nadaljevanju, kjer bomo opredelili

njegov zgodovinski razvoj in nato predstavili standard (WIKI 2013).

3.1.1 Zgodovinski razvoj

Na razvoj EDIFACT sta imeli bistveni vpliv dve celini, in sicer ZDA in Evropa.

EDI standard (angl. Electronic Data Interchange) se je razvil za izmenjavo podatkov za

potrebe prevozniške panoge. Organizacija imenovana TDCC (angl. Transportation Data

Coordinating Commitee), je v letu 1978 pridobila koncesijo ameriškega nacionalnega

urada za standardizacijo in postala odbor ANSI X12, ki je razvijala in nadgrajevala

standarde TDCC (ibid.).

Veliko podjetij iz posameznih panog, je v tistem obdobju uporabljajo lastne sisteme za

izmenjavo podatkov, kar pomeni, da je vsak, glede na potrebe panoge, razvil svoje

postopke izmenjave podatkov. To je pripeljalo do točke, da si dva podjetja, iz različnih

32

panog, nista mogla elektronsko izmenjati podatkov med seboj. V istem obdobju so v Veliki

Britaniji uporabljali standarde Tradacoms, ki so bili namenjeni mednarodni izmenjavi in so

bili kasneje nadgrajeni s strani Ekonomske komisije Združenih narodov UNECE (angl.

United Nations Economic Commission for Europe) v standarde GTDI (angl. General

purpose Trade Data Interchange) (Modic 2011, 14).

Zaradi nezdružljivosti standardov teh dveh celin, je pripeljalo do organizacije UN-JEDI

(angl. United Nations Joint European And North America). Skupaj sta razvili EDIFACT s

celostnim naborom podatkov za elektronsko izmenjavo (WIKI 2013).

3.1.2 Predstavitev standarda

Sporočilo EDIFACT je samostojen poslovni dokument, ki je sestavljen iz pravilnega,

hierarhičnega zaporedja segmentov znotraj definiranih področij. Sporočilo se začne s

segmentom glave sporočila UNH (angl. Message Header Segment) in konča z zaključnim

segmentom UNT (angl. Mesagge Trailer Segment) (ibid.,14).

Tabela 1: Struktura sporočila EDIFACT

POZICIJA OZNAKA NAZIV OBVEZNOST ŠTEVNOST

0010 UNH Glava sporočila M 1

GLAVA 0020 BGM Začetek sporočila M 1

0030 DTM Datum/Čas/Obdobje M 4

…

0040 RFF Referenca M 2 PODROBNOSTI


0060 FTX Prosto besedilo C 5

POVZETEK

…

0070 MOA Skupni znesek M 1


0090 RFF Referenca M 1

…

0100 UNT Zaključek sporočila M 1

Vir: Modic 2011

Iz zgornje tabele je razvidno, da je sporočilo sestavljeno in segmentih tabel, kjer je lahko

vsak segment znotraj tabele obvezen (angl. mandatory) ali pogojen (angl. conditional) ter

vsebuje določilo, kolikokrat se mora posamezni segment pojaviti v določenem sporočilu.

Segment predstavlja skupek logično povezanih podatkovnih elementov, ki imajo fiksno

definirano zaporedje. Podatkovni elementi pa so lahko enostavni (vsebuje en podatek) ali

sestavljeni (vsebujejo več sestavljenih podelementov) ter se razlikujejo po tipih (Modic

2011, 14 - 15):

numerični (števila);

črkovni (abecedni znaki) in

alfanumerični (števila in abecedni znaki).

33

Tabela 2: Izsek računa v standardu EDIFACT

Pozicija Segment Opis

Glava

0010 UNH+000125478' Message header

Identifikacijska številka

računa 000125478

0020 BGM+FA150258' Beginning of Message

Tip dokumenta in številka

dokumenta FA150258

0030 DTM+20150921:102' Date/Time/Period

Datum: 21.09.2015

…

Podrobnosti

0040 RFF+00-312589' Reference

Sklic dokumenta 00-312589

0050 DTM+20150921' Date/Time/Period

Datum: 21.09.2015

0060 FTX+ +' Free text

…

Povzetek

0070 MOA+100,00' Monetary Amount

Skupaj znesek 100,00

0080 DTM+20150921' Date/Time/Period

Datum: 21.09.2015

0090 RFF+00-312589' Reference

Sklic dokumenta 00-312589

…

0100 UNT

Vir: Lasten vir

3.2 XML IN UBL STANDARD

Mednarodna organizacija OASIS (angl. Organization For The Advancement Of Structed

Information Standards) je v sodelovanju z drugimi organizacijami za standardizacijo

razvila standard UBL (angl. Universal Business Language) (WIKI, 2013). Zasnovan je na

teoriji XML, zato bomo najprej predstavili zgodovinski razvoj XML standarda, nato UBL

standard in nato predstavili strukturo standarda.

Zaradi hierarhične zasnove in možnostjo dedovanja ter ponovno uporabo elementov, je

pomemben za razcvet e-poslovanja za mala in srednje velika podjetja (Modic 2011, 19).

3.2.1 Zgodovinski razvoj UBL standarda

V letu 2001 je tehnični komite, imenovan UBL (angl. Universal Business Language),

pripravil nabor poslovnih procesov, ki so temeljili na jeziku CCTS (angl. Core Component

Tehnical Specification). Njihov namen je bil narediti brezplačen in množično dostopen

standard za elektronsko izmenjavo dokumentov. Tako je po treh letih delovanja

34

omenjenega komiteja izšla različica UBL 1.0, ki je temeljila na knjižnici poslovnih

dokumentov xCBL (angl. Common Business Library) ter je vsebovala karakteristike

standarda EDIFACT. Elektronski prenos podatkov je bil standardiziran za naročilnico,

logistične dokumente in račune (ibid., 20).

3.2.2 Zgodovinski razvoj XML standarda

Razvoj sega daleč nazaj, ko so pri IBM-u razvili GML (angl. General Markup Language).

Iz slednjega se je razvil SGML (angl. Standard General Markup Language), ki je primeren

za ogromen količine dokumentov z obsežnimi besedili ter potrebuje zahteven razvoj

programske opreme. V nasprotju z SGML je XML poenostavljena različica prejšnjega in je

primeren za uporabo na internetu (ibid., 21).

Tehnologija XML (angl. Extensible Markup Lnguage) se je začela razvijati 1996. XML je

enostaven, fleksibilen, tekstovni format in označevalni jezik, ki ga je 1998 standardiziral

W3C (angl. World Wide Web Consortium).

Tehnologija XML se pričela uporabljati tudi na področju elektronske izmenjave podatkov,

kjer so definirani posebni besednjaki XML.

Razvoj gre v smeri nadgradnje EDI formata za izmenjavo podatkov. Obstaja pa kar nekaj

takšnih besednjakov, ki niso omejeni za industrijsko panogo (WIKI 2013).

Najpomembnejši besednjaki so (Budimir, Krajnc 2015):

ebXML ;

BizTalk;

RosettaNet;

cXML;

xCBL in

XEDI.

3.2.3 Predstavitev standarda XML

XML dokument je sestavljen iz treh komponent (WIKI 2013):

datoteka XML (nosi pomen informacije in vsebino);

shema dokumenta XML (pojasnjuje relacije med posameznimi elementi) in

pretvorba XSLT (omogoča pretvorbo datoteke XML iz ene v izbrano obliko s

sintakso HTML).

Tabela 3: Vsebina XML dokumenta

DOKUMENT XML

NAZIV OPIS PRIMER

Oznaka in

elementi

Vsebuje oznake (< in >) in

elemente. XML razlikuje velike in

male črke

<name>DINAMIKA D.O.O.</name>

Format in

končnica

Shranjen je kot tekst ASCII in

vsebuje končnico xml

Racun.xml

35

Komentarji sme vsebovati komentarje, ki niso

del podatkov XML dokumenta,

temveč so dodatna informacija za

uporabnika.

<sender>  <name>TELEKOM SLOVENIJE, D.D.</name>

Deklaracija vsebuje deklaracijo, ki ni obvezna,

vendar priporočljiva s strani W3C

<?xml version="1.0" encoding="UTF-8"?

Vir: Lasten vir

Primer 1: Izsek računa v xml obliki

<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="http://schemas.halcom.si/icl_envelope_einvoice.xslt"?> <envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="icl_envelope_einvoice.xsd"> <sender> <name>TELEKOM SLOVENIJE, D.D.</name> <country>SI</country> <address>CIGALETOVA ULICA 15</address> <address>1000 LJUBLJANA</address> <sender_identifier>SI98511734</sender_identifier> <sender_eddress> <sender_agent>LJBASI2XXXX</sender_agent> <sender_mailbox>SI56029220013902132</sender_mailbox> </sender_eddress> <email_id>[email protected]</email_id> </sender> …

Vir: Lasten vir

3.3 E-SLOG

Zaradi pobude nekaterih podjetij in usmerjenost k bolj konkurenčnemu poslovanju, torej e-

poslovanju, je aktivno vlogo prevzela Gospodarska Zbornica Slovenije.

E-SLOG ali elektronsko poslovanje slovenskega gospodarstva, je pričelo s projektom,

priprave in uveljavitev enostavnih vsebinskih in tehnoloških priporočil za elektronsko

izmenjavo podatkov med podjetij. V projektu je sodelovalo več kot 100 podjetij (GZS

2013).

3.3.1 Zgodovinski razvoj

Septembra 2002 so bile ustanovljene štiri delovne skupine, ki so v času 2003 in 2005,

razvile standarde in XML sheme za elektronsko izmenjavo podatkov med podjetji.

Delovne skupine so se med seboj razlikovale po vsebini projekta (ibid.):

delovna skupina za poslovne vsebinske standarde (priprava vsebin in

dokumentacije standardnih dokumentov za poslovanje med podjetji, za naročilnico,

dobavnico in račun);

delovna skupina za tehnološke rešitve (priprava tehnoloških priporočil za

elektronsko povezovanje);

36

delovna skupina za elektronski podpis (priprava praktičnih navodil za uporabo

digitalnih potrdil, arhiviranje elektronskih dokumentov in vzpostavitev enotnega

sistema uporabe digitalnih potrdil) in

delovna skupina za standarde plačilnega prometa med podjetji in bankami (priprava vsebin in dokumentacije standardnih dokumentov plačilnega prometa

med podjetji, bankami in državnimi institucijami).

Osnova za razvoj e-SLOG je bil standard UN/EDIFACT in navodila EANCOM.

3.3.2 Predstavitev standarda

E-SLOG temelji na XML shemi, ki je podrobno predstavljena v poglavju 3.2.3. Sestavljen

je iz datoteke XML, sheme dokumenta XML in vsebuje pretvorbo v XSLT. Vsebuje

oznake in elemente, shranjen je kot tekst ASCII ter ima deklaracijo.

Podlaga strukturam in šifrantom e-SLOG je mednarodni standard GS1 EANCOM, ki ga je

GS1 Slovenija (pred tem EAN Slovenija) priredila in dovolila uporabo za potrebe e-SLOG

(GZS, 2012).

V nadaljevanju je predstavljen enostaven račun.

Po e-SLOG-u je enostavni račun sestavljen iz naslednjih sklopov (ibid.):

1. glava račun (številka računa, datum izdaje, datum opravljene storitve,…);

2. subjekti računa (prejemnik in izdajatelj);

3. postavke (opisi, količine, cena, popusti, davčna osnova, davčna stopnja,…);

4. povzetki davkov (vsote po davčnih skupinah, davčne klavzule, oprostitev DDV ali

drugačnega načina obračuna,…);

5. vsote računa (znesek za plačilo, znesek računa, znesek DDV,…)

6. zaključek računa (pripravljavec računa, poljubno besedilo) in

7. noga računa (zahtevani podatki o izdajatelju in podobno)

.

V posameznem sklopu so opredeljeni kateri elementi so obvezni in kateri neobvezni ter

kateri so priporočljivi.

V spodnjem primeru je predstavljen enostaven račun v obliki e-SLOG.

Primer 2: Izsek račun v obliki E-slog

<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="http://schemas.halcom.si/icl_envelope_einvoice.xslt"?> <envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="icl_envelope_einvoice.xsd"> <sender> <name>TELEKOM SLOVENIJE, D.D.</name> <country>SI</country> <address>CIGALETOVA ULICA 15</address> <address>1000 LJUBLJANA</address> <sender_identifier>SI98511734</sender_identifier> <sender_eddress>

37

<sender_agent>LJBASI2XXXX</sender_agent> <sender_mailbox>SI56029220013902132</sender_mailbox> </sender_eddress> <email_id>[email protected]</email_id> <phone>01/234 10 00</phone> </sender> <receiver> <name>KK PROIZVODNJA TRANSPORTNIH IN POGONSKIH ELEMENTOV</name> <country>SI</country> <address>STARI TRG 13</address> <address>3210 SLOVENSKE KONJICE</address> <receiver_identifier>SI65409994</receiver_identifier> <receiver_eddress> <receiver_agent>LJBASI2XXXX</receiver_agent> <receiver_mailbox>SI56022800010452347</receiver_mailbox> </receiver_eddress> </receiver> … <count>2</count> <attachment> <filename>IzvozXMLDokument1.xml_racun_0150127920241.xml</filename> <type>xml</type> <description>Račun v eSlog obliki</description> </attachment> <attachment> <filename>IzvozXMLDokument1.xml_racun_0150127920241.pdf</filename> <type>pdf</type> <description>Račun v PDF obliki</description> </attachment> </attachments> </envelope>

38

4 UVAJANJE PODATKOVNIH STANDARDOV V POSLOVNE REŠITVE

Implementacija nove programske rešitve v že obstoječi informacijski sistem zahteva

projektno organizacijo, bodisi ali gre za veliko bodisi manjšo programsko dodelavo.

Projekt je zaključen proces, v katerem izvajamo določene aktivnosti, ki so med seboj

logično povezane z namenom doseganja ciljev projekta. Z doseganjem postopnih ciljev

dosežemo končni cilj (Hauc 2002, 43).

Gre za plansko nalogo, ki jo je potrebno izvesti v nekem planskem obdobju (Rant 1995, 8).

Iz slednjega lahko razumemo, da je vsak projekt opredeljen kot enkraten proces,

koordiniranih in nadzorovanih aktivnosti, ki ga omejujejo čas, stroški in drugi viri ter

zakonski predpisi (PMBOOK Guide 2004).

Vsak projekt zahteva sistemsko analizo, načrtovanje, zasnovo ali oblikovanje sistema s

pomočjo izbrane metodologije programiranja in na koncu tudi implementacijo ter

vzdrževanje.

Vsak projekt se izvaja v določenem okolju, na katerega vplivajo notranji in zunanji

dejavniki (Hauc 2007). Uspešnost projekta je odvisna od mnogih dejavnikov, kot so

kakovostna priprava, sposoben in izkušen projektni tim ter učinkovita projektna

organizacija, podprta z ustrezno projektno kulturo

Odločilni vpliv na projekt imajo ljudje, saj se tukaj srečajo različni profili udeležencev.

Lahko bi rekli, da se tukaj srečamo s funkcijskim managementom (najvišji, srednji in

operativni management), s strokovnjaki iz različnih področij, izvajalci, zunanjimi

strokovnjaki in podobno. Zato je izrednega pomena, da se kontrola izvajanja projekta

razume kot sredstvo za reševanje težava izvajalcev in preprečevanje odstopanj od načrta

ciljev projekta, in ne kot sredstvo za odkrivanje napak izvajalcev in sankcioniranje (ibid.).

Drugi odločilni dejavnik je projektna organizacija, ki je lahko interna (sestavljena iz

strokovnjakov, ki so zaposleni v določenem podjetju) ali eksterna (sestavljajo zunanji

strokovnjaki, ki niso zaposleni v določenem podjetju). Projektno organizacijo vedno vodi

projektni manager, ki jo izbere s pomočjo izkušenj (ibid.).

Kot zadnji vplivni dejavnik, ki vpliva na obseg in dinamiko projekta je organizacijska

struktura projektov. Organizacijska struktura projektov se lahko vrši v vertikalni ali

horizontalni smeri. Vertikalna smer predstavlja število vodstvenih ravni, za katero se

projekt izvaja, medtem ko pa horizontalna smer predstavlja razvejanost organizacijskih

enot določene organizacije. Kakor koli, več kot je vodstvenih ravni, daljšo pot mora preiti

delegiranje nalog in porabi se več časa in virov, kot če je majn vodstvenih ravni (i).

39

4.1 Sistemska analiza

Ta faza vključuje analiziranje programskega problema s specifikacijami, kar vključuje

funkcionalen opis in funkcionalne zahteve. Specifikacija zahtev programske opreme naj bi

opisovala funkcionalne zahteve, značilnosti strojenega okolja, obliko uporabniških

vmesnikov in zahtevane zmogljivosti (FRI 2013).

Ker tukaj proučimo možnosti izvedbe lahko načrtovanje projekta imenujemo tudi študija

izvedljivosti.

Z definiranjem potreb in namenov ter postavljanjem ciljev pridemo do želenih rezultatov,

zato je sistemska analiza izjemnega pomena.

Aktivnosti v tej fazi sta naslednji (ibid.):

analiza problema in

opis produkta.

Aktivnosti obeh faz opravljamo istočasno, kjer z analizo problema pridobimo popolno

razumevanje problemskega področja, medtem ko s pomočjo opisa produkta izdelamo

dokument imenovan Specifikacija zahtev programske opreme.

Bistveno vprašanje, na katero skušamo odgovoriti v tej fazi analize je KAJ naj grajeni

programski sistem zagotavlja (ibid.).

4.2 Načrtovanje projekta

V tej fazi načrtovanja projekta skušamo odgovoriti na vprašanje KAKO identificirane

zahteve iz prejšnje faze zadovoljiti.

Načrtujemo dejavnosti in določimo njihovo zaporedje ter določimo vire.

Tukaj izvedemo taktično planiranje izvedbenih projektov, kjer določimo dejavnosti,

določimo čas trajanja posamezne dejavnosti in določimo roke za izvedbo.

Izvedemo izbor sodelavcev iz podjetja, ki bodo vključeni v izvajanje projekta, če bo

projekt internega značaja. V primeru eksternega značaja projekta, pa se pripravijo razpisni

pogoji za zunanje izvajalce.

Glede na izvor, ločimo naslednje vrste virov (Semolič 2007):

delo;

predmeti dela;

delovna sredstva in

storitve drugih udeležencev na projektu.

Bistvenega pomena pri načrtovanju virov sta prav delo in storitve drugih udeležencev na

projektu. Prav ti dve vrsti virov lahko predstavljata ozko grlo pri realizaciji terminskega

plana projekta. Med te vire lahko štejemo znanje ljudi, ki sodelujejo na tem projektu.

40

Primer: Preobremenjenost določenih udeležencev na projektu, upočasnjuje izvedbo

terminskega plana.

Načrtovanje delimo na (FRI 2013):

preliminarno in

podrobno načrtovanje.

Preliminarno načrtovanje pomeni dekompozicijo programskega sistema v njegove

dejanske konsistentne komponente, kjer interaktivno razgradimo komponente v vedno

manjše podkomponente. Podkomponente razgrajujemo tako dolgo, dokler niso dovolj

majhne in razumljive vsem udeležencem v projektu. Vsak modul je dokumentiran z vhodi,

procesi in izhodi (ibid.).

V podrobnem načrtovanju pa definiramo in dokumentiramo algoritme za vsak modul

posebej v načrtovalnem drevesu. Sestavi se programska skica, ki kaže, kako graditi ciljno

okolje. Takšno načrtovanje je sestavljeno iz modularne razgradnje, definicij strukture

podatkov, definicij formata datotek in opisa pomembnejših algoritmov (ibid.).

4.3 Metodologija in vidiki razvoja

Razvijalci pri načrtovanju in implementiranju informacijskega sistema uporabljajo skupek

postopkov, tehnik, orodij in dokumentacijskih pripomočkov. Temu pravimo metodologija

razvoja. Metodologija razvoja je sestavljena iz faz in podfaz, ki vodijo razvijalce sistema

pri izbiri tehnik v vsaki fazi in podfazi projekta. Metodologija je v pomoč pri načrtovanju,

upravljanju, kontroliranji in vrednotenju projektov izgradnje informacijskih sistemov

(Avisoin, Fitzgerald 1996)

V nadaljevanju je predstavljenih nekaj modelov programiranja.

4.3.1 SLAM-DUNK model

SLAM-DUNK model, je model, ki temelji izključno na pisanju programske kode. Gre za

najbolj enostavnejši model programiranja in hkrati tudi največkrat uporabljen. Za takšen

model je značilno, da se takoj prične s programiranjem, brez predhodno pripravljenega

načrta izvedbe projekta, kot sta analiza problema in načrtovanje rešitve. Gre za psihološko

ozadje razvijalca. Razvijalec ima občutek, da lahko brez natančne razgradnje pristopi k

realizaciji (FRI 2013).

Predstavlja izrazito slab in neučinkovit primer razvoja programskega sistema. Za takšne

projekte pa je značilno, da terminsko vedno zamujajo ali pa niso nikoli realizirani.

41

Slika 5: SLAM-DUNK model programiranja

ČAS

Vir: FRI 2013

Iz zgornje slike je razvidno, da se sama implementacija programske rešitve izvaja od

začetka do konca, brez predhodne faze načrtovanja, in sicer analize problema in opisom

produkta. To je model, ki temelji le na kodiranju.

4.3.2 Baročni model

Baročni model, imenovan tudi etapni model, prinaša disciplino v slum-dunk model

programiranja. Značilnost tega modela programiranja je, da se vsaka predhodna faza v

celoti zaključi, preden se prične naslednja faza.

Baročni model uzakonjuje pretirano disciplino. Ker so zahteve vedno se spreminjajoče,

prihaja do paradoksa, da se faza analize nikoli ne zaključi.

V realni okvir lahko ta proces spravimo le tako, da se fazi analize in načrtovanja delno

prekrivata. Ta model je prispeval k razvoju realnejšega "kaskadnega" modela

programiranja (FRI 2013).

Slika 6: Baročni model programiranja

ČAS Vir: FRI, 2013

Iz zgornje slike je razvidno, da se baročni model odvija v treh fazah, in sicer faza analize,

faza načrtovanja in faza implementacije. Ker se naslednja faza ne more pričeti, preden je

zaključena predhodna faza, lahko rečemo, da ta model v praksi ne deluje, saj razvoj

programske opreme ni deterministični proces, temveč ves čas se spreminjajoči se proces.

4.3.3 Kaskadni model

Za kaskadni model je značilna sprotna izdelava dokumentacije, ki olajša vzdrževanje

sistema in povratne zanke, s katerimi se po potrebi vrnemo v predhodno fazo, da bi

odpravili napake ali vnesli dopolnitve.

Da bi lažje vključili uporabnike v proces razvoja programske opreme se, predvsem v fazi

analize in načrtovanja sistema, pogosto uporabljajo prototipi (ibid.).

ANALIZA NAČRTOVANJE IMPLEMENTACIJA

IMPLEMENTACIJA

42

Slika 7: Kaskadni model programiranja

Vir: FRI 2013

Iz zgornje slike je razvidno, da je kaskadni model sestavljen iz šestih faz, ki si sledijo

zaporedno in se vedno vrača v predhodno fazo s pomočjo povratnih zank, v primeru

spremembe okoliščin programskega okolja.

Kaskadni model je sestavljen iz faze analize, faze načrtovanja, faze implementacije, faze

testiranja, faze prenosa v ciljno kolje in nazadnje faze uporabe in vzdrževanje.

4.3.4 Spiralni model razvoja

Spiralni model razvoja je mešanica čistega strukturiranega in fleksibilnega prototipnega

modela. Poenostavljeno gledano je spiralni model v resnici kaskadni model, ki mu je

dodana analiza tveganja.

Pred vsako fazo kaskadnega modela sta dodani dve predhodni fazi (FRI 2013):

iskanje alternativ in

analiza tveganja.

Po vsaki fazi pa je dodano vrednotenje opravljenega dela in načrtovanje naslednje faze

(ibid.).

ANALIZA (KAJ)

NAČRTOVANJE

(KAKO)

IMPLEMENTACIJA

(NAREDI)

TESTIRANJE

(PREIZKUSI)

UPORABA IN

VZDRŽEVANJE

PRENOS V CILJNO

OKOLJE

43

Slika 8: Spiralni model programiranja

Vir: FRI 2013

Iz zgornje slike je razvidno, da je spiralni model sestavljen iz štirih glavnih faz in podfaz,

in sicer:

določitev ciljev in alternativ ter omejitev;

načrtovanje naslednje faze (načrt zahtev, načrt razvoja in načrt izvedbe).

ovrednotenja alternativ in identificiranje ter zmanjšanje tveganja (opravljena

analiza tveganja in prototipi) in

razvoj in verifikacija izdelka (principi, zahteve sistemsko načrtovanje, podrobno

načrtovanje, implementacija, test in instalacija).

Spiralni model omogoča boljšo oceno tveganja, podpira hitre odzive in zagotavlja višjo

kakovost končnega izdelka (ibid.).

4.3.5 Vidiki razvoja programske opreme

Razvoj programske opreme je kompleksen proces, zato je izhodišče za razvoj

informacijskega sistema preučitev določenih procesov v sistemu, podatkov v sistemu in

dogodkov v sistemu. Glede na to poznamo tri vidike razvoja programske opreme (ibid.):

PRINCIP

I

ZAHTEVE

SISTEMSKO

NAČRTOVANJE

PODROBNO

NAČRTOVANJE

IMPLEMEN

T TEST IN

INSTALACIJA

RAZVOJ IN VERIFIKACIJA

IZDELKA

OVREDNOTENJE ALTERNATIV,

IDENTIFICIRANJE IN ZMANJŠANJE

TVEGANJA

NAČRTOVANJE NASLEDNJE

FAZE

DOLOČITEV CILJEV,

ALTERNATIV IN OMEJITEV

NAČRT

ZAHTEV

NAČRT

RAZVOJA

NAČRT

IZVEDBE

ANALIZA

TVEGANJA

PROTOTIPI

44

procesni;

podatkovni in

dogodkovni vidik.

Vsak izmed zgoraj naštetih vidikov ima svoje izhodišče in daje v ospredje ali podatke ali

procese ali dogodke v razvoju programske opreme. Vsi trije vidiki so predstavljeni v

nadaljevanju.

4.3.5.1 Procesni vidik

Procesni vidik razvoja programske opreme opisuje celotni tokokrog podatkov, in sicer

vstop v sistem, pot znotraj sistema in izhod iz sistema ter transformacijo podatkov.

Procesni vidik obravnava procesno obnašanje sistema. Preučuje in predstavi kako sistem s

pomočjo transformacije, pretvori vhode v izhode (ibid.).

Poenostavljena ponazoritev bi bila: Vhod Proces Izhod.

Izhod procesnega vidika so diagrami toka podatkov (angl. Data Flow Diagram), ki so

nivojska predstavitev podatkovnih tokov v sistemu in njihovih transformacij. Diagrami

toka podatkov prikazujejo pretok podatkov skozi sistem. Sistem je lahko organizacija,

množica procedur, računalniška strojna oprema, programski sistem ali kombinacija le-teh

(ibid.).

Osnovni gradniki diagrama toka podatkov so (ibid.):

podatki, ki se pretakajo skozi sistem s pomočjo smeri vektorja, kažejo podatkovni

tok (angl. Data Flow);

proces, kjer gre za transformacijo vhodnih podatkov v izhodne podatke;

terminatorji, torej izvori in ponori podatkov, imenovani tudi zunanje entitete, ki

jih predstavimo s pomočjo pravokotnikov in

podatkovne shrambe, ki v primeru programskega sistema predstavljajo datoteke

(angl. Data Store).

Slika 9: Primer poenostavljenega diagrama toka podatkov

Vnos podatkov Prenos podatkov

Vir: Lasten vir

Zgornja slika predstavlja poenostavljen način diagram toka podatkov. Gre za primer

prejetega računa, ki ga najprej vnesemo v poštno knjigo in nato s pomočjo prenosa

zapišemo še v knjigo prejetih računov za nadaljnjo uporabo.

V našem primeru so podatki, podatki iz prejetega računa, kot so številka prejetega računa,

datumi in zneski iz računa. Smer vektorja nakazuje, da se podatki iz prejetega računa

PREJETI

RAČUN

POŠTNA

KNJIGA

KNJIGA

PREJETIH

RAČUNOV

45

zapišejo v poštno knjigo. Imamo tudi dva terminatorja, in sicer poštna knjiga in knjiga

prejetih računov ter dva procesa, ki sta vnos podatkov in prenos podatkov.

4.3.5.2 Podatkovni (informacijski) vidik

Podatkovni vidik opisuje obliko informacij, ki jih mora sistem obdelati. Nakazuje

medsebojne relacije med informacijskimi enotami. Podatkovni vidik se nanaša na strukturo

in uporabo podatkov v sistemu.

Izhod podatkovnega vidika so entitetno relacijski diagrami in podatkovni slovarji.

Namen podatkovnega slovarja je hranjenje informacij o vseh podatkih, torej podatkovnih

tokov in podatkovne shrambe, ki se nahajajo v diagramu toka podatkov. V podatkovnem

slovarju so vsi podatkovni tokovi oziroma shramba podatkov razgrajeni do podatkovnega

elementa. Podatkovni element ali tudi podatkovna prvinam je posebna vrsta podatkovnega

toka, ki ga ni možno razgraditi v še manjše ali podrejene toke (ibid.).

Primer podatkovnih shramb iz Slike 9 bi bili podatki iz prejetega računa:

številka prejetega računa;

datum izstavitve storitve prejetega računa;

datum plačila prejetega računa;

znesek prejetega računa;

znesek DDV in podobno.

4.3.5.3 Dogodkovni vidik

Dogodkovni vidik opisuje obnašanje sistema v realnem času. Nanaša se na dinamično

obnašanje sistema in je pomemben zato, ker definira, kako si dogodki sledijo v časovnem

zaporedju, kar iz zgoraj opisanih vidikov programske opreme ni bilo razvidno.

Izhod dogodkovnega vidika so diagrami prehajanja stanj (angl. State Transition

Diagram) in kontrolni diagrami (ibid.).

Delovanje kontrolne enote lahko opišemo z diagramom prehajanja stanj. Diagram ima

končno število stanj in povezave, ki določajo prehajanje iz enega stanja v drugo.

V vsakem stanju je določeno (Škraba 2015):

katero je naslednje stanje, ki ga določajo vhodni signali, ali je možno preiti v več

novih stanj in v katero stanje se preide;

kateri izhodni signali so aktivni v tem stanju in

na koncu kontrolna enota preide v novo stanje.

V vsakem diagramu prehajanja stanj mora biti definirano začetno stanje, v našem primeru

je kontrolna enota prevzem ukaza.

46

Slika 10: Primer poenostavljenega diagrama prehajanja stanj, s pomočjo kontrolnih

diagramov.

zapis v bazo podatkov PK prenos v bazo podatkov KPR

zavrnitev zapisa-manjkajoči zavrnitev prenosa-manjkajoči

obvezni podatki dodatni podatki

Vir: Lasten vir

Iz zgornje slike je razvidno, da se zapis prejetega računa zavede v bazo podatkov PK

(poštne knjige) v primeru, ko so izpolnjeni obvezni podatki o prejetem računu.

Obvezni podatki na prejetem računu so: zaporedna številka prejete pošte, datum prejema in

dobavitelj. Če obvezni podatki niso vneseni, se zapis ne zavede v bazo podatkov poštne

knjige.

Prenos v bazo podatkov KPR (knjiga prejetih računov) se zavede v primeru, če obstaja

indikator, da gre za prejeti račun in ne prejeto pošto. Dodatni podatki zahtevani za zapis v

bazo KPR so: znesek z DDV, datum opravljene storitve in datum valute. V nasprotnem

primeru prenos v bazo podatkov KPR ni mogoč.

4.4 Oblikovanje sistema

Ko smo izbrali primerno metodologijo za razvoj programske rešitve, opravili analizo

problema in opis produkta s pomočjo specifikacije zahtev programske analize, je čas za

programiranje in kodiranje.

Izvede se kodiranje, ki pomeni transformacijo algoritmov v računalniško razumljiv jezik.

Ta del opravi programer. Že tukaj se opravi del testiranja in čiščenja napak vsakega

modula, specificiranega pri samem načrtovanju (FRI 2013).

Pri oblikovanju sistema se najprej lotimo grupiranja (ibid.), ki je lahko:

grupiranje pred načrtovanjem ali

grupiranje po načrtovanju.

V obeh primerih gre za delitev procesov po posameznem računalniku, ki se lahko opravi

pred izvajanjem analize ali po njej.

Nato se lotimo vsebine, in sicer tako, da transformiramo tiste procese, ki so bili definirani v

diagramu toka podatkov v jezik, ki je bližji računalniku.

Drugi pomembnejši del pri oblikovanju sistema je testiranje, ki ga je potrebno pojmovati

kot obsežnejšo problematiko. Testiranje je analiza programa ali določene komponente

programa, ki se izvaja z namenom, da se ugotovi, ali program ustreza predpisanim

zahtevam v specifikaciji, oziroma, da se pokaže razlika med pričakovanimi in dejanskimi

izhodnimi vrednostmi (ibid.).

PREJETI

RAČUN

POŠTNA

KNJIGA

KNJIGA

PREJETIH

RAČUNOV

47

Pri izdelavi vsakega sistema je potrebno sprotno preverjanje rezultatov dela. Pri tem

obstajata dva vidika preverjanja rezultatov (ibid.):

validacija, ki preverja ustreznost programskega izdelka in

verifikacija, ki preverja pravilnost programskega izdelka.

Validacija poda odgovor na vprašanje: »Ali gradim pravi produkt?«, medtem ko

verifikacija poda odgovor na vprašanje: »Ali gradim produkt pravilno?«

Lahko bi rekli, da sta programiranje in testiranje programske rešitve dva nasprotujoča si

procesa, saj programiranje je konstruktiven proces, medtem ko je testiranje destruktiven

proces. Priporočljivo je, da naj ena oseba programira, druga pa testira.

Testiranje je uspešno le takrat, kadar uspemo dokazati obstoj napak v programski rešitvi. V

nadaljevanju so opredeljene posamezne aktivnosti v procesu testiranja, ki morajo podati

naslednje odgovore (ibid.):

proces testiranja: »Ali je v programu ena ali več napak?«;

proces odpravljanja napak: »Kje so vzroki za odpoved« in

regresijsko testiranje: »Ali smo vnesli nove napake«.

Glede na vsebino ločimo (ibid.):

funkcijsko testiranje, kjer se izvaja testiranje z vidika funkcij, ki jih izvaja

program, testne primere pa tvorimo na osnovi specifikacij funkcij in

strukturno testiranje, kjer vzorce tvorimo na podlagi struktur in uporabljenih

algoritmov in ne na podlagi specifikacij sistema ali njegovih komponent.

Iz hierarhičnega vidika pa ločimo (ibid.):

testiranje modula in

testiranje integracije.

Testiranje integracije se lahko prične šele po testiranju modula, saj module postopoma

vgrajujemo oziroma integriramo v program, zato je smiselno zaporedno testiranje.

Če želimo, da je testiranje uspešno, je pomembno, kakšno strategijo testnega vzorca smo

izbrali.

Lahko je popolno testiranje, kjer testiramo vse možne kombinacije vhodnih podatkov. V

nekaterih primerih takšno testiranje ni izvedljivo, zaradi velikega števila kombinacij. V

takšnem primeru se poslužujemo strategije tipičnih vrednosti, torej tiste, ki se bodo v

realnem okolju največkrat ponovile. Obstaja tudi metoda enakovredne razdelitve, kjer

imamo dva dela, in sicer veljavni vhodni podatki in neveljavni vhodni podatki in nato

ponovimo v več enakovrednih podmnožicah. Možnost izbire testnega vzorca je tudi

metoda mejnih vrednosti in naključni izbor (ibid.).

Pred izbiro strategije testnega vzorca, je pomembno to, da dobro poznamo programsko

rešitev, ki se razvija in poznamo okoliščine v katerih bo delovala, saj le tako lahko

zagotovimo, da bo testiranje uspešno.

Kadar gre za obsežno programsko rešitev si je smiselno pripraviti tudi testni načrt, v

katerem opredelimo (ibid.):

1. Zaporedna številka testnega načrta

48

2. Uvod

3. Opis produkta

4. Karakteristike, ki jih bomo testirali

5. Karakteristike, ki jih ne bomo testirali

6. Metode testiranja

7. Prekinitev n nadaljevanje testiranja

8. Potrebne aktivnosti za izvedbo testiranja

9. Opis testnega okolja

10. Identifikacija odgovornosti

11. Človeški viri in potrebno izobraževanje

12. Tveganje in posledice

13. Potrditev testnega načrta in

14. Dodatki

Rezultat vsakega testiranja mora biti poročilo o testiranju, kjer opredelimo potek

preverjanja in naše ugotovitve. Poročilo o testiranju mora vsebovati (ibid.):

1. Uvod

2. Povzetek

3. Izvedene verifikacije in validacije in

4. Seznam odpovedi

Pri seznamu nepravilnosti je potrebno pripraviti testni primer in pričakovane vrednosti.

Kakšni so bili dejanski rezultati, opredeliti datum in uro ter opredeliti preverjevalca in

druge opazovalce.

4.5 Implementacija sistema

V fazi implementacije sistema je programska rešitev v celoti vgrajena pri stranki in

usposabljanje osebja je zaključeno.

Ključne točke, ki morajo biti zaključene so:

primerna uporabniška dokumentacija in navodila za uporabo;

instalacija in/ali nastavitev programske rešitve, fizično pri stranki ali preko spleta;

zaključeno usposabljanje uporabnikov, individualno ali skupinsko na seminarjih;

začetek delovanja programske rešitve.

49

5 ANALIZA PRIMERA IMPLMENTACIJE E-RAČUNOV V

INFORMACIJSKEM SISTEMU PRO3. FINANCE ZA MALA, SREDNJA IN

VELIKA PODJETJA

Zadnje poglavje magistrskega dela predstavlja empirični del raziskave problema. S

predstavitvijo podjetja in računovodskim programom PRO.3 Finance bomo bralcu

približali uvajanje podatkovnih struktur za elektronsko izmenjavo podatkov v obstoječ

informacijski sistem, in sicer bo prikazan potek od zasnove do implementacije programske

rešitve.

Kot zadnji del empiričnega dela bo predstavitev raziskovalnega problema in prikaz

rezultatov intervjujev, ki smo jih izvedli na izbranem vzorcu podjetij različnih velikosti.

Pogovarjali smo se s končnimi uporabniki in IT strokovnjaki, ki imajo različen pogled na

uvajanje sprememb v obstoječ informacijski sistem.

5.1 Predstavitev podjetja in informacijskega sistema PRO.3 Finance

Podjetje Pro-Bit d.o.o. je bilo ustanovljeno leta 1989 in je svoje pričetke delovanja pričelo

z implementacijo enostavnih programskih rešitev za majhna podjetja. Podjetje je skozi leta

rastlo in sedaj je srednje veliko in ponuja svoje programske rešitve srednjim in večjim

podjetjem in zavodom.

Podjetje sodi med pet vodilnih slovenskih proizvajalcev celovitih rešitev za srednja in

večja podjetja. Osnovni produkt podjetja je program PRO.3, ki je razdeljen na tri temeljne

programske rešitve:

finance in računovodstvo;

veleprodaja, maloprodaja in proizvodnja ter

kadrovski in plačni sistem.

V magistrskem delu nas zanima programska rešitev PRO.3 Finance, ki predstavlja celovito

rešitev za računovodsko vodenje in evidentiranje ter spremljanje zakonskih in drugih

evidenc.

PRO.3 Finance sestavljajo naslednji moduli:

poštna knjiga;

DDV, ki je sestavljena iz prejetih računov in izdanih računov;

plačilni promet;

glavna knjiga;

blagajna;

evidence in poročila ter

izvršbe.

Če se osredotočimo na prejete račune, nas zanima predvsem poštna knjiga in/ali DDV s

prejetimi računi.

Osnovna programska rešitev trenutno omogoča ročni vnos prejetega računa v poštno

knjigo in njegov nadaljnji prenos v knjigo prejetih računov. Namen magistrskega dela pa

50

je, da prikažemo implementacijo programske rešitve v že obstoječi informacijski sistem.

Vpeljava napredne rešitve prenosa prejetega e-računa v poštno knjigo in nadaljnji prenos v

knjigo prejetih računov je predstavljen v naslednjih poglavjih.

Da bi lahko lažje predstavili zasnovo in razvoj programske rešitve v podjetju, moramo na

tem mestu opisati, kako je podjetje organizirano.

Podjetje sestavlja:

vodstvo podjetja;

profitni centri (PC Finance, PC Plače, PC Veleprodaja, Maloprodaja in podobno);

oddelek razvoja;

oddelek prodaje;

režija in

podpora strankam.

Čeprav obstaja poseben oddelek v podjetju, ki se ukvarja z razvojem novih tehnologij in

programov, v vsakem PC-ju obstaja interen razvoj, ki se nanaša na specifiko PC-ja.

Vsak PC pa je sestavljen iz:

vodje PC-ja, ki skrbi za vsebino in celostno podobo modula;

programerjev;

vsebinskih svetovalcev in

tehničnih svetovalcev.

5.2 Implementacija e–računov v informacijski sistem PRO.3 Finance od zasnove do

programske rešitve

Uvajanje podatkovnih struktur v obstoječi informacijski sistem zahteva dobro zasnovan

načrt in dobro upravljanje z viri, ki so na razpolago v podjetju. Ker je organizacija ali

podjetje vedno podvrženo spremembam, je hitro prilagajanje več kot nujno. Tudi

programske rešitve zahtevajo nenehno zaznavanje, spremljanje in prilagajanje tem

spremembam. V našem primeru govorimo o programskih rešitvah, ki s pomočjo

podatkovnih struktur, omogočajo uvoz podatkov na eni strani, na drugi strani pa nadaljnjo

obdelavo uvoženih podatkov.

Sama implementacija programske rešitve v obstoječ informacijski sistem zahteva dobro

zasnovo, oblikovanje projekte skupine, ki bo izpeljala zasnovan načrt in ga tudi razvila ter

poskrbela za nadaljnje vzdrževanje pri stranki.

Dober začetek dela, pomeni dobro zasnovano programsko rešitev, ki mora biti pripravljena

po točno določeni dokumentaciji, tako imenovani Specifikaciji za oddajo zahtevkov za

programske rešitve, ki v prvi meri opredeljuje problematiko (FRI 2013):

orientirano na potrebo uporabnika ali

orientirano na potrebo tržišča ali

splošno izboljšavo produkta.

51

Ogromno časa posvetimo analizi problema in zdi se, da bi jo bilo smiselno izpustiti in s

tem znižati stroške in skrajšati čas izvedbe, vendar to ne drži. Prav dobra analiza problema

in natančen opis zahtev prispevata k zmanjšanju porabljenega časa v podjetju in tudi k

znižanju stroškov razvoja ter vzdrževanja programske opreme v prihodnosti.

S pomočjo kaskadnega načina programiranja programske rešitve se v podjetju doseže

optimalen način dela, saj si faze, kot so analiza problema, načrtovanje projekta,

implementacija programske rešitve, njeno testiranje in instalacija v informacijski sistem,

smiselno sledijo in s pomočjo povratnih zank omogočajo dopolnjevanje dokumentacije in

sprotno odpravljanje napak, ki se ugotovijo v samem procesu razvoja programske rešitve.

5.2.1 Zasnova programske rešitve

Preden pričnemo z zasnovo programske rešitve, mora obstajati nek impulz zunaj ali znotraj

podjetja. Zunanji impulz predstavlja spremembo zakonodaje, ki vpliva na spremenjeno

delovanje informacijskega sistema ali povpraševanje stranke, ki v svojem poslovanju čutijo

potrebo po neki nadgradnji informacijskega sistema. O notranjem impulzu pa govorimo

takrat, kadar se v podjetju pojavi ideja o neki nadgradnji informacijskega sistema in ki bi

bil zanimiv tudi za uporabnike.

V sami zasnovi zasledujemo dva cilja, in sicer analiziramo, kje prihaja do problema in

skušamo čim bolje opisati, kaj bo programska rešitev vsebovala.

Če izhajamo iz organizacijske strukture podjetja in posameznega profitnega centra, je

vodja profitnega centra tisti, ki zazna spremembo, ne glede na to ali gre za notranji ali

zunanji impulz, in s pomočjo analize problema pripravi podroben opis produkta. V našem

primeru je to raziskovanje pri strankah in proučitev zakonodaje, ki zahteva spremembo. S

pomočjo obrazca, se pripravi natančen opis programske rešitve. Obrazec imenujemo

Specifikacija za oddajo zahtevkov za spremembe programskih rešitev.

Specifikacija za oddajo zahtevkov za spremembe programskih rešitev opredeljuje:

1. Stranko;

2. Program;

3. Datum v obliki zapisa DDMMLLLL (dan, mesec, leto);

4. Opis dodelave oz. spremembe (krajši opis);

5. Vhodne podatke;

6. Opis dodelave oz. spremembe (podrobnejši opis, po potrebi);

7. Izhodni podatki in

8. Priloge.

Spodaj je podpisan tudi tisti, ki je specifikacijo pripravil.

V specifikacijo običajno opredelimo stranko, za katero se pripravlja dodelava oziroma

programska rešitev. V našem primeru stranka ni opredeljena, saj gre za programsko

rešitev, ki zajema vse stranke, ki bodo uporabljale napredno programsko rešitev uvoza e-

računov v program.

52

Ker podjetje Pro-Bit snuje več programov hkrati, je nujno, da v specifikaciji opredelimo

tudi na kateri program se nanaša programska rešite. V našem primeru je to program

PRO3. Finance, natančneje modul poštna knjiga in/ali knjiga prejetih računov.

Pomembno je tudi, da programsko rešitev opredelimo tudi s časovnega vidika, zato

dopišemo tudi datum priprave specifikacije.

Nadalje specifikacija vsebuje krajši opis dodelave oziroma spremembe, v katerem jasno in

jedrnato opišemo vsebino spremembe. Dodelava obsega nadgradnjo poštne knjige in

knjige prejetih računov, kjer dodamo opcijo samodejnega uvoza e-računov na osnovi

standardizirane podatkovne strukture e-SLOG.

Opredelimo vhodne podatke, ki so XML dokumenti, ki jih pridobimo iz elektronskega

bančništva. XML dokument temelji na standardu izmenjave podatkov e-SLOG. V XML

dokumentu so zapisani prejeti e-računi za izbrani datum. Odvisno od tega, kako uporabnik

izvozi prejete e-račune, poznamo posamezno ali skupinsko izvažanje e-računov.

Sledi podrobnejši opis dodelave oziroma spremembe, kjer navedemo postopke in

predlagane rešitve.

V našem primeru to pomeni, da:

E-račune, zapisane v XML dokumentu, najprej izvozimo iz banke in jih shranimo

na želeno lokacijo na računalniku;

V programu PRO.3 Finance, in sicer v modulu poštna knjiga in/ali modulu knjiga

prejetih računov nastavimo lokacijo, kamor smo shranili izvožene e-račune iz

elektronskega bančništva;

V modul poštna knjiga in/ali knjiga prejetih računov, dodamo možnost uvoza e-

računo s klikom na gumb;

Po končani akciji se uvozijo e-računi v program.

V podrobnejšem opisu sledi tudi opredelitev posameznih polj, to pomeni, kateri podatek iz

XML dokumenta naj se zapiše v posamezno polje v modul poštna knjiga in/ali knjigo

prejetih računov. Sledi primer zapisa podatkov iz XML dokumenta e-računa v izbrano

polje tabele poštne knjige.

Tabela 4: Vsebina XML dokumenta in zapis podatkov v tabelo poštna knjiga

XML dokument Polje v tabeli poštna

knjiga

Opomba

<name>TELEKOM SLOVENIJE, D.D.</name>

Naziv

<address>CIGALETOVA ULICA 15</address>

Naslov

<address>1000 LJUBLJANA</address> Kraj <amount>22.97</amount> Vrednost <creditor_structured_reference>SI120150127920241</creditor_structured_reference>

Dob_sklic Referenca

računa

<requested_execution_date>2012-09-24</requested_execution_date>

Datum_v Datum valute

<timestamp>2012-09-05T20:11:44.000</timestamp>

Datum_p Datum prejema

<additional_remittance_information Zadeva

53

>Račun za 08/2012</additional_remittance_information> <external_doc_id>0150127920241</external_doc_id>

D_racun Dobaviteljeva

številka računa

Vir: Lasten vir

Iz zgornje tabele je razvidno, kako se posamezna vsebina iz XML dokumenta zapiše v

izbrano polje tabele poštne knjige. Rezultat tega zapisa so izhodni podatki, kar pomeni,

zapis podatkov v tabelo poštna knjiga.

Običajno se v specifikaciji priložijo tudi priloge. V našem primeru se poleg izpolnjene

specifikacije za oddajo zahtevkov za spremembo programske rešitve priloži tudi priročnik

za izdelavo XML dokumenta, ki ga objavlja in obnavlja Združenje bank Slovenije.

Natančnejši opis specifikacije za oddajo zahtevkov za spremembo programskih rešitev je

priloženo v Prilogi 2 magistrskega dela.

5.2.2 Oblikovanje projektne skupine

V obravnavanem podjetju se udeleženci na projektu delijo na naslednje tri nivoje (Kern

2004):

upravljanje;

vodenje in

izvajanje.

Udeleženci v upravljalnem nivoju so tisti, ki razpolagajo s sredstvi. Nivo vodenja

predstavljajo tisti udeleženci, ki so zadolženi za vodenje in usmerjanje k dosegu cilja.

Udeleženci, ki dejansko opravijo delo pa sodijo v nivo izvajanja.

Ker gre v našem primeru za programsko rešitev uvajanja podatkovnih struktur za

elektronsko izmenjavo podatkov, ki predstavlja manjši projekt v podjetju, pri oblikovanju

projektne skupine sodelujeta samo dve skupini udeležencev, in sicer skupina za vodenje in

skupina za izvajanje projekta.

Odgovornost in pristojnost vodstvene skupine je priprava koncepta projekta, njegovo

sodelovanje pri planu projekta in operativno vodenje za dosego ciljev, medtem ko

izvajalska skupina izvaja aktivnosti v planiranem času in poroča o zaključku aktivnosti.

Vodja profitnega centra, kot del vodstvenega nivoja, poskrbi za oblikovanje projektne

skupine. Najprej se preverijo proste kapacitete pri zaposlenih, in sicer programerjih,

vsebinskih svetovalcih in tehničnih svetovalcih.

S pomočjo oddelka podpora se pregleda zasedenost izbranega programerja, ki bo izvedel

programiranje programske rešitve. Določi se razpored dela in določitev termina, ko mora

biti programska rešitev na voljo za testiranje.

Sledi pregled zasedenosti vsebinskega svetovalca, ki bo prevzel vsebinsko testiranje

programske rešitve ter časovna določitev prioritet pri reševanju novih in ostalih del.

54

Hkrati sodeluje tudi tehnični svetovalec, ki pripravi programsko okolje za nemoteno

testiranje programske rešitve. Tehnični svetovalec prične pripravljati programsko okolje v

trenutku, ko je bil določen termin za dokončanje programske rešitve.

Sama izbira udeležencev, ki bodo sodelovali na izbranem projektu, je pomembna. Ker smo

si ljudje različni, karakterno in tudi delovno, je pomembna izbira ljudi v projektu, kajti

uspešnost projekta je odvisna od vseh sodelujočih in njihovega timskega dela ter ne od

posameznika.

Ko so vse zgornje faze planiranja zaključene sledi oddaja zahtevka v delo izbranemu

programerju in sledi faza razvoja, ki zajema implementacijo, testiranje, instalacijo

programske rešitve e-računov.

5.2.3 Razvoj

Podjetje Pro-Bit d.o.o. je za svoje potrebe razvilo posebno spletno aplikacijo, ki deluje na

intranetu podjetja. Spletna aplikacija, imenovana PBB.net, je namenjena zbiranju in

sortiranju zahtevkov, ki pridejo v programersko hišo od zaposlenih v podjetju in/ali od

strank. Hkrati omogoča posredovanje zahtevkov od enega zaposlenega do drugega.

Razvoj v podjetju poteka tako, da se zahtevek, ki je bil oddan v izdelavo s strani

vsebinskega svetovalca, pojavi na urniku izbranega programerja. Zahtevek za izdelavo

programske rešitve e-računov, je časovno in prednostno opredeljen. Glede na slednja

kazalnika, se zahtevek uvrsti glede na prioriteto.

V nadaljevanju je predstavljena implementacija e-računov, njihovo testiranje in instalacija

v ciljno okolje.

5.2.3.1 Implementacija e-računov

Programer zahtevek dobi na urnik, hkrati pa tudi e-sporočilo v poslovni e-predal kot

opomnik. Sledi pregled zahtevka s strani programerja s pripadajočo Specifikacijo za

oddajo zahtevkov za programske rešitve in Priročnik kot priloga zahtevku.

Sama implementacija pomeni kodiranje, ali drugače rečeno, transformacija algoritmov v

računalniško razumljiv jezik. Ko programer opravi kodiranje in pripravi testno verzijo

programske rešitve e-računov, obvesti tehničnega svetovalca, da rešitev prenese na testno

okolje.

Kot že rečeno, se tukaj izvede prvostopenjsko testiranje, ki ga opravi programer sam.

Vendar velja, da ena oseba ne more dobro razvijati in hkrati programirati, zato se opravi

podrobnejše testiranje, ki ga opravi vsebinski svetovalec.

Programer zahtevek na svojem urniku posreduje tehničnemu svetovalcu, da nadgradi

testno okolje s testno programsko rešitvijo e-računov. Tehnični svetovalec dobi na urnik

55

posredovan zahtevek od programerja, hkrati prejme tudi e-sporočilo v svoj poslovni e-

predal. Sledi nadgradnja testnega okolja.

5.2.3.2 Testiranje e-računov

Ko tehnični svetovalec nadgradi testno okolje s testno programsko rešitvijo e-računov,

zahtevek posreduje vsebinskemu svetovalcu v testiranje. Slednji prejeme zahtevek na urnik

in e-sporočilo v svoj poslovni e-predal.

Sledi testiranje programske rešitve e-računov.

Ker gre za implementacijo programske rešitve e-računov v že obstoječ program, je

potrebno testiranje modula, kjer preverimo, če modul po nadgradnji deluje pravilno, in

hkrati testiranje same integracije programske rešitve e-računov.

Pri testiranju programske rešitve je izredno pomembna izbira testnega vzorca. Popolno

testiranje v tem primeru ni možno, zato se poslužujemo strategije tipičnih vrednosti, torej

tistih, ki se bodo v realnem okolju največkrat ponovile.

Rezultat testiranja je vedno poročilo o testiranju, ki se doda kot priponka obstoječemu

zahtevku.

Poročilo testiranja je končni dokument vsakega testiranja. Dokument je sestavljen iz dveh

delov, in sicer v prvi del se vpisujejo splošne informacije, v drugi del pa se vpisujejo

napake.

Poročilo o testiranju sestavljajo:

Izvajalec;

Datum, z opredelitvijo pričetka in zaključka testiranja;

Oznaka scenarija;

Opredelitvijo statusa;

Opis napake in

Podroben opis napake s testnim primerom v testnem okolju.

56

Slika 11: Izsek poročila o testiranju uvedbe e-računov

Vir: Lasten vir

Iz zgornje slike je razvidno, da se vsako testiranje zaključi s poročilom, ki mora vsebovati,

izvajalca testiranja in kdaj ter koliko časa je testiral določeno programsko rešitev.

Oštevilčen mora biti tudi scenarij, saj v primeru večkratnega testiranja takoj pridobimo

vpogled, da se neka programska rešitev testira in rešuje večkrat. Poročila o testiranju

omogočajo tudi vpogled v zgodovino razvoja same programske rešitve. Vsaka odkrita

napaka mora biti opisana, na testnem okolju pa pripravljena simulacija napake, ki omogoča

programerju takojšen vpogled in razumevanje.

Lahko rečemo, da je v podjetju razvoj proces, ki kroži s pomočjo spletne aplikacije, od

programerja do svetovalca in proces se nadaljuje tako dolgo, dokler se zahtevek ne

zaključi. Zahtevek se zaključi, ko so odkrite in odpravljene vidne napake v programski

rešitvi. Besedo vidne smo uporabili namenoma, saj testiranje nikoli ne more biti popolno.

Podjetje testiranju programskih rešitev posveča veliko pozornost, saj le temeljito testiranje

v prihodnosti prihrani čas in denar.

5.2.3.3 Instalacija e-računov pri uporabniku programske opreme

Razvoj programske rešitve je zaključen, ko se zapre zahtevek, ki je bil pripravljen za

razvoj e-računov. Zapre ga vsebinski svetovalec, ki potrdi, da programska rešitev e-

57

računov deluje tako, kot je vsebinsko opredeljeno v Specifikaciji za oddajo zahtevkov

programskih rešitev in tehnično, kot je opredeljeno v priročniku e-SLOG.

Preden se programska rešitev posreduje uporabniku, je potrebno pripraviti navodila za

nadgradnjo aplikacije in navodila za uporabo e-računov v programu. Navodila za uporabo

in nadgradnjo aplikacije pripravi vsebinski svetovalec. Pripravljena navodila se odložijo na

izbrano spletno mesto, od koder si uporabniki, s pomočjo prejete povezave do navodil,

lahko naložijo navodila na svoj trdi ali prenosljivi disk.

Sledi priprava paketa, naložitev paketa na spletno mesto, od koder si uporabniki

programov PRO.3 sami nadgradijo program s pomočjo posredovanih navodil in

pridobljenim geslom.

Sama instalacija je dokaj ustaljen proces in uporabniki si večinoma sami nadgrajujejo

verzije programov. Obstajajo pa tudi tiste uporabniki, ki imajo posebne predpise in

protokole, glede nadgradenj aplikacij. To so večinoma velika podjetja, ali podjetja javnega

značaja, kjer je zakonsko opredeljeno, kako poskrbeti za varnost aplikacij in njihovo

nadgradnjo. V tem primeru je potrebno osebno komunicirati in posredovati informacije,

glede nadgradenj.

5.2.4 Vzdrževanje

Kot zadnji korak v procesu razvoja programske rešitve, je njeno vzdrževanje. Čeprav se

zdi, da je večina narejena, ko ima uporabnik nameščeno programsko rešitev, temu ni tako.

Pomembno je vzdrževanje, kajti ko je programska rešitev e-računov prodana in instalirana

pri uporabniku, smo jo dolžni tudi zakonsko nadgrajevati, spremljati in dopolnjevati.

Obstaja pa razlika, kadar gre za programsko rešitev e-računov, ki je narejena po

standardizirani podatkovni strukturi ali poljubni podatkovni strukturi za elektronsko

izmenjavo podatkov.

Kadar gre za programsko rešitev e-računov in izmenjavo podatkov na osnovi poljubnih

podatkovnih struktur posameznih podjetij, je v prevzemnem zapisniku opredeljeno tako, da

podjetje Pro-Bit d.o.o. ni dolžno v sklopu mesečne vzdrževalne pogodbe prodano

programsko rešitev vsebinsko spremljati in nadgrajevati v primeru sprememb. Zakaj? Iz

praktičnega vidika je to nemogoče, saj če se struktura podatkov spremeni, jo program

PRO.3 zazna šele takrat, ko se sproži uvoz e-računov. Ali takrat, kadar nas na to opozori

uporabnik sam. Obstaja pa še drugi vidik. Ker gre za poljubne podatkovne strukture, se

lahko poljubno spreminjajo in prilagajajo posameznim uporabnikom. Medtem ko je pri

uporabi standardizirane podatkovne strukture, kot je na primer e-SLOG, vsaka sprememba

objavljena na spletnem portalu Združenja bank Slovenije in opredeljena v priloženem

priročniku.

5.3 E-računi za mala, srednja in velika podjetja

V letu 2002 si je le 3% podjetij z dobavitelji elektronsko izmenjevalo račun v

standardizirani obliki. Med srednjimi podjetji elektronska izmenjava računov v

58

standardizirani obliki sploh ni bila prisotna. Zanimiv je podatek, da je bila takšna oblika

izmenjave računov najbolj razširjena med mikro podjetji (5%) (Vehovar in drugi 2003).

V tem delu smo predstavili, kakšni so rezultati intervjuja, ki smo ga izvedli na namenskem

vzorcu izbranih podjetji. Sodelovala so velika, srednja, mala in mikro podjetja. Nekatera

izmed podjetij imajo lasten IT v podjetju, druga ne. Glede na tip družbe smo izbrali

gospodarske in negospodarske družbe. V intervju so privolili tako vodstveni delavci, kot

končni uporabniki in IT strokovnjaki, z različno delovno dobo v izbranem podjetju.

Pomembna so njihova stališča in pogledi na uvedbo programske rešitve v obstoječi

informacijski sistem.

Vsem podjetjem, ki uporabljajo programe Pro 3 podjetja Pro-Bit, programska oprema in ki

bi lahko bila zainteresirana za uporabo e-računov v standardizirani obliki, to je e-SLOG, je

bila posredovana predlagana programska rešitev oktobra 2012. Teh podjetij je bilo 268. Na

ponudbo se je odzvalo 12 podjetij srednje velikosti, do končne implementacije pa je prišlo

samo pri 8 podjetjih srednje velikosti, kot je prikazano v Grafu 1.

Graf 1: Odzivnost podjetij na posredovano programsko rešitev uvedbe e-računov

Vir: Lasten vir

V ta namen smo se odločili, da izberemo 9, ki so privolila na intervju. Vzorčenje temelji na

namensko in majhnem izbranem vzorcu. Izbrali smo tista podjetja, od katerih lahko izvemo

največ, glede na subjektivno oceno. To so podjetja različnih velikosti in z različnimi

izkušnjami o e-računih.

V nadaljevanju so v Tabeli 5 prikazane posamezne značilnosti 9 podjetij, glede na njihovo

velikost, število zaposlenih, tip družbe in dejstvo ali ima podjetje svoj lasten IT oddelek.

Številoposredovanih

ponudb

Odziv naponudbo/zanimanje

Implementacijaprogramske rešitve

268

12 8

Programska rešitev e-računi

Število podjetij

59

Tabela 5: Značilnosti izbranega vzorca podjetij, različnih velikosti

Podjetje Velikost

podjetja

Število

zaposlenih

Tip

družbe

Lasten IT

v podjetju

P1 Veliko > 250 d.v.z. DA

P2 Veliko > 250 d.o.o. DA

P3 Veliko < 150 d.d. DA

P4 Srednje < 150 d.o.o. NE

P5 Srednje < 100 JVIZ NE

P6 Srednje < 100 d.o.o. NE

P7 Malo < 50 d.o.o. NE

P8 Malo < 50 s.p. NE

P9 Mikro < 10 s.p. NE

Vir: Lasten vir

Iz izbranih podjetij smo izbrali končne uporabnike in IT strokovnjake. Njihove značilnosti

so predstavljene v Tabeli 6.

Tabela 6: Značilnosti izbranega vzorca intervjuvanih oseb

Podjetje

Oseba

Spol

Starost

Trajanje

zaposlitve na

tem delovnem

mestu v letih

Naziv delovnega mesta

Vzorec 1 – Končni uporabniki iz izbranih velikih, srednjih in malih ali mikro podjetij

P1 K1 Ž >50 10-15 Vodja finančno računovodske

službe

P1 K2 Ž 40-50 5-10 Računovodja


službe


P3 K5 Ž >50 >15 Vodja finančno računovodske

službe

P4 K6 Ž 40-50 10-15 Vodja finančno računovodske

službe



službe



službe


službe

Vzorec 2 – IT strokovnjaki iz izbranih velikih podjetij

P1 S1 M 40-50 ˃ 10 Vodja IT oddelka

P2 S2 M 40-50 5-10 Vodja IT oddelka

P3 S3 M 30-40 < 5 Vodja IT oddelka

60

V prilogi 1 se nahaja opomnik in seznam vprašanj za izvedbo intervjuva. Vprašanja so

zasnovana tako, da so razumljiva osebam, ki jih intervjuvamo. Hkrati vsa vprašanja niso

prišla v poštev za vse udeležence intervjuva, saj kot prikazuje Tabela 2, so pri intervjuju

sodelovali tako vodstveni delavci kot končni uporabniki ter tudi IT strokovnjaki.

Rezultati raziskave so predstavljeni po posameznih sklopih oziroma so sortirani glede na

posamezna vprašanja.

Poznavanje e-poslovanja in e -računov

Vsi sodelujoči na intervjuju so podobno opredeliti pomen e-poslovanja in e-računov v

svojem podjetju. Pod pojmom e-poslovanje je najpogosteje omenjeno brezpapirno

poslovanje, ki predstavlja optimalen način poslovanja. Drugi opredeljujejo e-poslovanje

kot nadgradnja običajnega poslovanja oziroma gre za širši pojem poslovanja v podjetju, ki

temelji na elektronskem prenosu podatkov. E-poslovanje za nekatere predstavlja višji nivo

poslovanja, torej optimalno in brez uporabe fizičnih dokumentov. Ne popolnoma brez,

ampak večinoma izvajanje različnih transakcij preko spletnih omrežij, bodisi plačevanje

računov, sprejemanje računov, izdajanje računov, spremljanje dokumentov in podobno.

E-računi za večino vprašanih pomenijo računi, ki so v brezpapirni obliki, ki jih prejmemo

neposredno v aplikacijo in so na vpogled v arhivu, nimajo fizične osnove, ampak samo

elektronsko. Spet drugi pod pojmom e-računi razumejo, samodejni uvoz podatkov iz

prejetega e-računa, torej podatkov ni potrebno ročno vnašati v program. Drugače rečeno

izdan in prejet elektronsko, vsekakor ne poslan preko poštnih storitev v papirni obliki.

Pri nekaterih uporabnikih je uporaba e-računov celo zakonsko predpisana, vsaj iz strani

izdajanja računov.

Če povzamemo je razumevanje e-poslovanja in e-računov dobro, pri tem pa ne moremo

reči, da bi starost, spol, delovne izkušnje ali delovno mesto vplivalo na različna mnenja in

razumevanja, glede vprašane vsebine.

Seznanitev s programsko rešitvijo e-računi

Vsi sodelujoči na intervjuju so bili seznanjeni s programsko rešitvijo e-računov,

neposredno na izobraževanju za uporabnike, ali ob izidu četrtletne verzije programa, ali pa

so prejeli ponudbo, ki jo je podjetje posredovalo poleg mesečne vzdrževalne pogodbe.

Namen tega vprašanja je bilo, ali so vsi ključni uporabniki obveščeni o programski rešitvi,

saj ne glede na slednje, nas v nadaljevanju tudi zanima, zakaj se večina ni odločila za

programsko rešitev e-računov na osnovi podatkovnih standardov, ki jih ponuja stroka.

Uporaba e-računov v programu PRO3. Finance

Izmed devetih vzorčnih podjetij, 8 podjetij do neke mere uporablja e-račune v programu

PRO 3. Finance. V nadaljevanju smo povzeli do kašne mere posamezna podjetja

uporabljajo e-račune in ali uporabljajo e-račune, ki jih priporoča stroka, torej uporaba e-

SLOGa, ali pa uporabljajo poljubne strukture podatkov, ki so jih razvili s pomočjo našega

podjetja in tujega ponudnika storitev.

Dva podjetja, ki sodita v kategorijo velikih podjetij, uporabljata prejete e-račune v celoti,

torej se vsi prejeti računi samodejno uvozijo v program PRO3. Finance, brez ročnega

61

vnosa. Pri tem je potrebno poudariti, da obe podjetji uporabljata podatkovne strukture, ki

sta poljubni. Obe podjetji uporabljata dokumenti sistem, tujega ponudnika, ki omogoča

preslikavo dokumentov in samodejno branje določenih podatkov iz računov. Iz

omenjenega dokumentnega sistema nato s pomočjo poljubnih podatkovnih struktur,

uvozimo podatke v program PRO. 3 Finance, natančneje v poštno knjigo.

Tretje veliko podjetje deloma uporablja e-račune, in sicer uporabljajo e-račune med

povezanimi firmami, kar pomeni izdan račun v eni povezani firmi, je prejet e-račun v drugi

povezani firmi. Gre za delno prejemanje e-računov, medtem ko preostale prejete račune

prejemajo v fizični obliki. Tudi ta programska rešitev temelji na poljubni strukturi

podatkov.

Iz med treh srednje velikih podjetij, prvi dve podjetji uporabljata e-račune v

standardizirani strukturi podatkov, kot je e-SLOG.

V tretjem podjetju pa uporabljajo e-račune, ki se prenašajo v poštno knjigo na osnovi

poljubnih podatkovnih struktur, prav zaradi uporabe tujega dokumentnega sistema.

Naslednja kategorija podjetij sta mali podjetji. Obe podjetji uporabljata nek približek e-

računom, in sicer uvažajo prevzemnice, ki se zapišejo v knjigo prejetih računov. Podatki iz

prevzemnic pa služijo kot podatki za prejete račune in na osnovi prevzemnic se tudi

kreirajo prejeti računi. Naloga uporabnika pa je, da elektronsko kreirane prejete račune

samo preveri s podatki iz fizično prejetih računov. Obe podjetji pa uporabljata poljubne

podatkovne strukture.

Zadnja kategorija podjetja je mikro podjetje. Omenjeno podjetje ne uporablja e-računov v

nobenem pogledu.

Če povzamemo, je pri velikih podjetjih zaznati nagnjenost k uporabi poljubnih

podatkovnih struktur za elektronsko izmenjavo podatkov, medtem ko je pri srednje velikih

in malih podjetjih uporaba obojih, tako poljubnih kot standardiziranih podatkovnih struktur

za elektronsko izmenjavo podatkov.

Uvajanje programske rešitve s časovnega in stroškovnega vidika

Uvajanje programske rešitve pri velikih podjetjih s časovnega vidika je bilo različno.

Prvo veliko podjetje je bilo zadovoljno s hitro odzivnostjo in delujočo programsko

rešitvijo, medtem ko sta drugi dve veliki podjetji navedli nekaj težav pri časovnem

uvajanju programske rešitve. Drugo veliko podjetje je navedlo težavo skupnega jezika med

obema ponudnikoma programske rešitve, torej dokumentnega sistema drugega

proizvajalca in obstoječi program PRO3. Finance podjetja Pro-bit. Tretje veliko podjetje je

navedlo težavo pri časovnem vidiku zato, ker se je istočasno uvajal celotni informacijski

sistem in ne le programska rešitev e-računov.

Uvajanje programske rešitve s stroškovnega vidika pri velikih podjetjih je bila pri prvem

in tretjem podjetju primerna, medtem ko je bila pri drugem podjetju naložba nekoliko

višja, saj je bilo potrebno do programirati specifične zahteve uporabnika.

62

Nobeno od velikih podjetij ni navedlo razlog za višje stroške pomanjkanje znanja

ponudnikov programskih rešitev.

Uvedba programske rešitve pri prvih dveh srednje velikih podjetjih iz časovnega vidika,

ki uporabljata standardizirano strukturo podatkov, je bila hitra s to razliko, da prvo podjetje

navaja težave predvsem pri pridobivanju soglasij, komuniciranje z banko in veliko odprtih

stvari, za katere so morali poskrbeti sami. Tretje podjetje, ki uporablja poljubno

podatkovno strukturo, pa navaja daljše časovno obdobje uvedbe programske rešitve, težave

pa nastajajo predvsem pri usklajevanju akcij prenosa podatkov s strani tujega ponudnika

dokumentnega sistema.

Prvi dve podjetji sta navedli nizke stroške iz stroškovnega vidika uvedbe programske

rešitve, vendar dodali, da so na drugi strani nastali stroški svetovanja in podpore, ker so

potrebovali vsebinsko pomoč ali dograditev sistema, zaradi specifičnih zahtev

uporabnikov. Tretje podjetje, ki uporablja poljubno podatkovno strukturo, prav tako navaja

nizke stroške uvedbe same programske rešitve, vendar zaradi napak v sistemu delovanja

tujega dokumentnega sistema, zahteva popravljanje napak v programu PRO3. Finance

višje stroške.

Nobeno od srednje velikih podjetij ni navedlo razlog za višje stroške pomanjkanje znanja

ponudnikov programskih rešitev.

Prvo malo podjetje je navedlo daljše časovno obdobje uvajanje programske rešitve s

časovnega vidika uvajanja programske rešitve, medtem ko drugo malo podjetje ne. Obe

podjetji uporabljata isto programsko rešitev s poljubno podatkovno strukturo za

elektronsko izmenjavo podatkov. Razlika obstaja zato, ker je prvo podjetje leto prej pričelo

uporabljati programsko rešitev, dejansko se je pričelo programiranje od ideje do

programske rešitve. Drugo podjetje pa je leto dni kasneje dobilo že izdelano programsko

rešitev. Iz tega razloga je drugo podjetje navedlo krajše obdobje uvajanje programske

rešitve iz časovnega vidika.

S stroškovnega vidika uvajanje programske rešitve je prvo podjetje navedlo visoke

stroške, medtem ko drugo ne. Prvo podjetje je tudi navedlo, da je bil razlog v višjih

stroških pomanjkanje znanja na obeh straneh ponudnikov programskih rešitev ter

neusklajenost obeh.

Vsekakor lahko rečemo, da uvajanje programske rešitve s poljubno podatkovno strukturo

zahteva nekaj več časa s časovnega vidika in nekoliko višje stroške, saj gre za specifične

programske rešitve, vsaj pri srednje velikih in malih podjetjih. Kakor hitro izbrano

programsko rešitev s poljubno podatkovno strukturo za elektronsko izmenjavo podatkov

ponudimo drugi stranki z istimi potrebami, se strošek in porabljen čas uvajanja znižata,

zadovoljstvo stranke pa poveča. Pri velikih podjetjih tega trenda ne moremo potrditi niti

ovreči. Uporaba standardizirane podatkovne strukture za elektronsko izmenjavo podatkov

se je pri obeh srednje velikih vzorčnih podjetjih izkazala kot cenovno ugodna in časovno

hitro uvedena v obstoječ informacijski sistem, s to razliko, da sta obe podjetji navedli ali

dodatne stroške izobraževanja kadrov, ali programiranje specifičnih zahtev ali dolgotrajni

postopki komuniciranja in pridobivanje soglasij.

63

Obstoj lastnega IT oddelka in njegova vloga pri uvajanju programske rešitve v

informacijski sistem

Vsa velika podjetja imajo lasten IT oddelek, vloga njega pa je večinoma tehnična,

izjemoma tudi vsebinska. Samo pri prvem velikem podjetju je vloga IT oddelka velika.

Ker gre za podjetje v državni lasti zanj obstajajo posebni zakonodajni in interni predpisi

glede nadgradenj aplikacij in izboljšav, tako tehničnih kot vsebinskih. Vsa ostala podjetja

srednje velikosti, mala in mikro podjetja, pa nimajo lastnega IT oddelka, razen z izjemo

enega podjetja. V podjetju male velikosti IT oddelek nima posebne vloge pri uvajanju

programske rešitve v obstoječ informacijski sistem.

Gonilna sila za uvedbo programske rešitve e-računov v obstoječ informacijski

sistem

Pri večini vzorčnih podjetjih je bila gonilna sila za uvedbo programske rešitve v

obstoječi informacijski sistem vodja oddelka za računovodstvo. V prvem in tretjem

velikem podjetju pa je vodstvo podjetja tisto, ki je pospešilo uporabo e-računov, prav

zaradi racionalizacije poslovanja in zmanjšanja vnosa napak v informacijski sistem.

Le v enem srednje velikem podjetju je bil razlog za uvedbo programske rešitve e-računov

zakonodaja. Čeprav samo na strani izdanih e-računov so posledično uvedli tudi prejete e-

račune.

Zadovoljstvo z uporabo in vzdrževanjem programske rešitve e-računov

Vsa velika podjetja so zadovoljna z uporabo programske rešitve e-računov. Kar zadeva

vzdrževanje, vsa podjetja navajajo, da se vsaka sprememba in vzdrževanje programske

rešitve zaračuna. Razlog v zaračunavanju vsake spremembe je ravno poljubna podatkovna

struktura za elektronsko izmenjavo podatkov, za katero podjetje Pro-Bit ne more

zagotavljati, da ob vsaki spremembi vključi to storitev v vzdrževalno pogodbo. Uporabo

programske rešitve so ocenili z zelo dobro ali dobro, vzdrževanje programske rešitve in

odziv na zakonsko spremembo pa s srednje dobro ali primerno.

Vsa srednje velika podjetja so zadovoljna z uporabo programske rešitve. Prvi dve

podjetji, ki uporabljata standardizirano podatkovno strukturo za elektronsko izmenjavo

podatkov, sicer navajata, da so potrebne določene prilagoditve v programu ali minimalne

spremembe, ki bistveno niso vplivale na strošek vzdrževanja, medtem ko tretje podjetje, ki

uporablja poljubne podatkovne strukture za elektronsko izmenjavo podatkov navaja, da

oba ponudnika programske rešitve zaračunata vsako minimalno spremembo in vzdrževanje

v programu.

Uporabo programske rešitve so ocenili z dobro ali primerno, vzdrževanje programske

rešitve in odziv na zakonsko spremembo pa z dobro ali hitro.

Obe mali podjetji, ki uporabljata poljubne podatkovne strukture, sta zadovoljni z uporabo

programske rešitve in navajata isto problematiko kot ostala podjetja različnih velikosti.

Vsaka sprememba in vzdrževanje se zaračuna na obeh straneh ponudnikov. Uporabo

programske rešitve so ocenili z zelo dobro, vzdrževanje programske rešitve in odziv na

zakonsko spremembo pa s primerno.

Iz zgornjega lahko povzamemo, da poljubne podatkovne strukture za elektronsko

izmenjavo podatkov v večji meri zadovoljujejo potrebe končnih uporabnikov, čeprav je

64

njihov strošek vzdrževanja višji, kot bi bil v primeru uporabe standardiziranih podatkovnih

struktur za elektronsko izmenjavo podatkov. Na drugi strani pa prav uporabniki

standardiziranih podatkovnih struktur za elektronsko izmenjavo podatkov navajajo

nekoliko manjše zadovoljstvo ob uporabi programske rešitve, saj je potrebna minimalna

prilagoditev sistema, so pa zato stroški vzdrževanja nižji ali pa so le-ti vključeni v mesečno

vzdrževalno pogodbo.

Koristi uporabe e-računov in ali uporabniki kljub uporabi e-računov le-te natisnejo

in jih fizično odložijo v arhiv

Velika podjetja navajajo koristi uporabe e-računov prav pri prihranjenem času in

zmanjšanju človeških napak pri vnosu podatkov v program na minimum. Prvo in drugo

podjetje ne tiskata e-računov in jih fizično tudi ne odlagata v arhiv. Razlogi za to je dober

dokumentni sistem, ki omogoča vpogled v e-račun na vsakem koraku. Prav tako oba

dokumentna sistema tujega ponudnika zadostujeta pogojem e-arhiviranja, kot ga zahteva

Arhiv RS in zakonodajni predpisi. Tretje podjetje do določene mere uporablja e-račune, in

sicer samo med povezanimi podjetji, zato vse e-račune fizično tudi natisnejo in fizično

odložijo v arhiv s preostalimi računi.

Vsa srednje velika podjetja navajajo podobne koristi uporabe e-računov, torej

prihranek pri času in zmanjšanje ali ničnost napak pri vnosu podatkov v program. Prvo

podjetje, ki uporablja dokumentni sistem tujega uporabnika ne tiska e-računov in jih ne

odlaga v arhiv, medtem ko preostali dve podjetji tiskata e-račune in jih odlagata v arhiv

poleg preostalih prejetih računov. Prav ti dve podjetji uporabljata standardizirano

podatkovno strukturo za elektronsko izmenjavo podatkov, vendar navajata, da prejeti

računi še niso vsi v celoti elektronski, saj še niso uspeli skleniti vseh soglasij z dobavitelji.

Da ne bi nastala zmeda v odlaganju listin, torej nekatere imeti shranjene elektronsko druge

fizično, le-te natisnejo in fizično odložijo. Obe podjetji tudi ne uporabljata dokumentnega

sistema, ki bi sicer omogočal e-arhiviranje.

Podjetji male velikosti sta navedli koristi uporabe pri času in navzkrižni kontroli med

prevzemnicami in prejetimi računi. Obe podjetji tudi tiskata vse račune in jih fizično

odlagata v arhiv.

Vsa podjetja, različnih velikosti, vidijo koristi uporabe e-računov v prihranku na času,

zmanjšanju človeških napak pri vnosu v program in podobno. Zanimivejša so dejstva glede

tiskanja in odlaganja računov v arhiv. Podjetja, katera uporabljajo dokumentni sistem, e-

račune tudi e-arhivirajo. Podjetja, ki pa ne uporabljajo dokumentnega sistema pa e-račune

fizično natisnejo in odložijo v arhiv. Lahko rečemo, da je ključna uporaba dokumentnega

sistema oziroma e-arhiva, ki ga posamezni dokumentni sistemi zagotavljajo. Ne glede na

to, kakšne račune prejemaš, ali so to fizični računi posredovani po pošti ali računi

posredovani elektronsko, je ključen arhiv dokumentov in možnost odlaganja,

pregledovanja in ravnanja z dokumenti.

Razlogi za neuporabo standardiziranega uvoza e-računov

Razlogi za neuporabo standardiziranega uvoza e-računov pri prvih dveh velikih

podjetjih, je uporaba dokumentnega sistema tujega ponudnika programske rešitve. Obe

podjetji že dlje časa uporabljata dokumentni sistem, preden je sploh nastala pobuda za

razvoj standardizirane podatkovne strukture e-SLOG. Če bi želeli uporabo standardiziranih

65

podatkovnih struktur, bi bila potrebna dodelava na obeh straneh ponudnikov programskih

rešitev, kar z vidika uporabnikov ni bilo izvedljivo, tako s stroškovnega kot časovnega

vidika. Prav tako prehod na Pro-Bitov dokumentnega sistema ni izvedljiv pri prvem

podjetju, saj gre za podjetje v državni lasti, kjer ponudnik e-arhiviranja mora registrirati

programsko in strojno opremo ter storitve, sprejeti notranja pravila in pridobiti akreditacijo

od Arhiva RS, kar pa omenjeni dokumentni sistem še ne omogoča. Pri drugem podjetju pa

je dokumentni sistem že tako vpet v podjetje, da bi bila njegova zamenjava nesmotrna.

Tretje podjetje pa je navedlo razloge za neuporabo standardiziranih podatkovnih struktur

za elektronsko izmenjavo podatkov prav pri pridobivanju soglasij, dogovarjanje z

dobavitelji in bankami. Navajajo, da pričakujejo, da dobavitelji njim predlagajo e-račune in

ne ravno obratno. Smotrna uporaba e-računov pa se jim zdi le v primeru, ko gre za

masovno e-fakturiranje in ne le manjšina e-računov in preostali večinski del fizičnih

računov, saj v tem primeru je več dela kot koristi.

Podjetje srednje velikosti navaja razloge za neuporabo standardiziranega uvoza e-

računov prav zaradi dokumentnega sistema, ki jim trenutno omogoča preslikavanje

prejetih računov s pomočjo čitalca, ki samodejno zazna določene podatke na fizičnem

računu in jih pretvori v elektronsko obliko. Račun se nato samodejno uvozi v program

PRO3. Finance.

Mali podjetji vidita razloge za neuporabo standardiziranega uvoza e-računov prav v

pridobivanju soglasij od dobaviteljev, velikem številu dobaviteljev, ki še niti ne razmišljajo

o e-računih ter ne smotrnosti peščice e-računov in večine fizičnih računov. Drugo podjetje

navaja celo, da v celoti ne zaupa elektronskemu poslovanju, saj imajo izkušnje z

nedelovanjem mreže, kar pomeni ne dostop do e-dokumentov.

Mikro podjetje svoje razloge za neuporabo standardiziranega uvoza e-računov vidi v

majhnem številu prejetih računov.

Razlogi za neuporabo standardiziranega uvoza e-računov podjetja vidijo predvsem pri

zamenjavi obstoječega delujočega sistema elektronske izmenjave podatkov na podlagi

poljubnih podatkovnih struktur. Hkrati nimajo niti interesa karkoli spreminjati v

dokumentnem sistemu, ki jim omogoča e-arhiviranja. Druga podjetja, katera ne uporabljajo

dokumentni sistem, pa vidijo težavo pri dolgotrajnem pridobivanju soglasij od dobaviteljev

in nepripravljenost dobaviteljev do e-računov. Spet druga podjetja pravijo, da vidijo

nesmotrnost v uporabi e-računov, če še večinski del pripada fizično prejetim računom.

66

6 POVZETEK

Pomen elektronskega poslovanja in z njim povezanega elektronskega izmenjevanja

podatkov, je danes temelj vsakega poslovanja. Bistvo elektronskega poslovanje je sigurno

v bolj optimalnem načinu poslovanja, brez dodatnega balasta, ki ga danes povzročajo

fizični dokumenti. Čeprav se nam v teoriji zdi samoumevno, da je e-izmenjava podatkov

bolj smotrna, v poslovnem svetu, na novosti gledajo s kančkom ne sigurnosti. Tukaj le gre

za pomembne dokumente in izmenjavo podatkov, zato je njihova varnost na prvem mestu.

Če je zagotovljena varnost pri tovrstnem elektronskem poslovanju in če podjetja temu

načinu poslovanja zaupajo, lahko pričakujemo porast takšnega načina poslovanja. Prav s

postopki, kot so šifriranje, digitalni podpis, časovni žig in infrastruktura javnih ključev,

dosežemo varnost, ki zagotavljajo zaupnost, celovitost, nadzor in razpoložljivost

elektronskih podatkov.

Na tem mestu je bistvenega pomena tudi država s svojimi zakonodajnimi predpisi, ki ščiti

uporabnike pred možnimi zlorabami, ponudnikom tovrstnim storitvam pa nalaga smernice

razvoja. Slovenska zakonodaja z zakoni kot so ZEPEP, ZDDV in drugimi zakoni, daje e-

dokumentom enak pomen kot fizičnim dokumentom. Poudarja pa pomembnost e-

arhiviranja, torej shranjevanja in ravnanja z e-dokumenti, ki predstavlja zadnjo in hkrati

tudi najbolj pomembno stopnjo v sistemu upravljanja z e-dokumenti. ZVDAGA in Enotne

tehnološke zahteve, ki predpisujejo postopke zajema podatkov in njihove pretvorbe za

namene e-arhiviranja, najpomembnejšo vlogo pripisujeta Arhivu RS. Le-ta izvaja

postopke registracije in potrdi skladnost ponujene opreme, programske in strojne, z

veljavnimi predpisi.

Z naraščanjem uporabe e-dokumentov, so se pričeli razvijati različni standardi za

podatkovno izmenjavo. Najpomembnejši med njimi, ki so tudi vplivali na razvoj

današnjega e-SLOG-a, so EDIFACT, XML in UBL. Čeprav je bil prvi omejen sprva samo

na določeno panogo, je kljub temu pripomogel k razvoju naslednjih dveh, in sicer XML in

UBL. Le-ta je bil narejen z namenom, da se vzpostavi sistem množičnega dostopa do

omenjenega standarda in njegova brezplačna uporaba. Za razliko od prejšnjih dveh je

XML standard enostaven in fleksibilen jezik, ki se je pričela množično uporabljati tudi na

področju elektronske izmenjave podatkov. Prav e-SLOG, pa je različica elektronskega

poslovanja slovenskega gospodarstva in temu primerna XML shema.

Vsaka implementacija podatkovnih standardov v že obstoječ informacijski sistem, zahteva

projektno naravnanost v podjetju, zato je na tem mestu potrebna dobra sistemska analiza,

da ugotovimo problematiko in kakšen produkt sploh potrebujemo. Sledi načrtovanje

projekta, kjer načrtujemo dejavnosti in določimo njihovo zaporedje, oblikovanje sistema,

kjer dejansko načrtovano in specificirano tudi realiziramo in testiramo ter nazadnje tudi

sama implementacija in vzdrževanje programske rešitve.

V uvodnem delu magistrskega dela, smo si postavili hipoteze, ki jih bomo s pomočjo

predelane literature in izvedeno študijo primera skušali potrditi ali ovreči.


primeren podatkovni standard e-SLOG.

67

Če gledamo z vidika programerske hiše, ki ponuja programsko rešitev e-računov, hipoteza

nedvomno drži, saj gre za standardizirano podatkovno strukturo, ki omogoča elektronsko

izmenjevanje podatkov, na enoten in predpisan način s strani stroke. Njena implementacija

in vzdrževanje programerski hiši omogoča, da za nižje stroške, ponudi več strankam isto

programsko rešitev. Vsaka sprememba in nadgradnja pa je objavljena in predpisana s strani

stroke.

Če pa omenjeno hipotezo analiziramo skozi oči končnega uporabnika, temu ni tako. Le-ti

dajejo boljšo oceno poljubnim podatkovnim strukturam za elektronsko izmenjavo

podatkov, čeprav je njihovo vzdrževanje nekoliko dražje in ne tako hitro, kot bi bilo v

primeru uporabe standardizirane podatkovne strukture.



S pomočjo praktičnega primera uvajanja programske rešitve e-računov v obstoječ

informacijski sitem PRO3. Finance smo potrdili, da je najoptimalnejši način programiranja

prav kaskadni način. Sestavljen je iz šestih faz, ki si sledijo zaporedoma, vendar ves čas

oziraje se v predhodno fazo. Ključnega pomena sta analiza in načrtovanje projekta. Sledi

oblikovanje sistema ali implementacija. Izrednega pomena je faza testiranja, ki je ključna

za čim nižje stroške vzdrževanja v prihodnosti. Sledi še prenos v ciljno okolje in uporaba

ter vzdrževanje programske rešitve.



Slednjo hipotezo moramo zopet gledati iz dveh vidikov. Prvi vidik je vidik programerske

hiše. Nedvomno je standardizirana podatkovna struktura z vidika programerske hiše

ugodnejša in daje boljše rezultate. Gre za programsko rešitev, ki je dobro proučena v

podjetju, izpeljana projektno in premišljeno, preden je prenesena v ciljno okolje. Ista

programska rešitev se nato uporablja z vidika več podjetij, zato je veliko bolj stabilna in

varna.

Iz vidika podjetij in uporabnikov programskih rešitev, ki uporabljajo poljubno podatkovno

strukturo za elektronsko izmenjavo podatkov, favorizirajo prav slednjo strukturo, saj je

izrecno pisana njihovemu načinu poslovanja in potrebam. Enake rezultate je dala študija

primera, ki nakazuje, da poljubne podatkovne strukture za elektronsko izmenjavo podatkov

v večji meri zadovoljujejo potrebe končnih uporabnikov, čeprav je njihov strošek

vzdrževanja višji, kot bi bil v primeru uporabe standardiziranih podatkovnih struktur za

elektronsko izmenjavo podatkov. Na drugi strani pa prav uporabniki standardiziranih

podatkovnih struktur za elektronsko izmenjavo podatkov navajajo nekoliko manjše

zadovoljstvo ob uporabi programske rešitve, saj je potrebna minimalna prilagoditev

sistema, so pa zato stroški vzdrževanja nižji ali pa so le-ti vključeni v mesečno vzdrževalno

pogodbo.

68


Študija primera je pokazala, da so prav srednje velika podjetja tista, ki uvajajo podatkovne

standarde in ne velika podjetja, kot smo predpostavljali. Velika podjetja imajo precej

sofisticirane poslovne procese in temu pripadajoči informacijski sistem. Nekatera podjetja,

ki so v državni lasti imajo tudi določene predpise, katere programske rešitve morajo

uporabljati in kakšne zahteve morajo izpolnjevati, zato se v tem primeru favorizira prav

poljubna struktura za elektronsko izmenjavo podatkov.

Izvedena študija primera je pokazala, da je razumevanje o e-poslovanju in o uporabi e-

računov med uporabniki dobra. Zavedajo se prednosti, ki jih takšen način poslovanja

prinaša, kot so prihranek na času, zmanjšanje napak pri vnosu podatkov v program,

vpogled v e-račun na vsakem mestu in podobno.

Zanimivo je tudi dejstvo, da so vsi sodelujoči bili obveščeni o programski rešitvi e-

računov, vendar zaradi različnih razlogov, se niso odločili za njeno uporabo. Predvsem pri

velikih podjetjih je zaznati nagnjenost k poljubnim podatkovnim strukturam za elektronsko

izmenjavo podatkov, pri srednje velikih in malih podjetjih pa uporaba obojih, tako

poljubnih kot standardnih podatkovnih struktur za elektronsko izmenjavo podatkov, čeprav

je slednja ugodnejša s časovnega in stroškovnega vidika.

Čeprav imajo vsa vzorčna velika podjetja lasten IT oddelek, njegova vloga pri sprejemanju

odločitev v večini primerov, glede programskih rešitev ni bistvena ali pa je sploh ni.

Bistvo e-računa je prav njegov elektronski obstoj in rezultat študije primera je, da vsa

podjetja, katera nimajo urejenega e-arhiviranja, e-račun fizično natisnejo in odložijo v

arhiv. Tako se njegove prednosti, ki jih prinaša e-račun, deloma tudi izničijo. Lahko

rečemo, da e-račun ni zadostil vsem elektronskim aspektom.

Težava je tudi v tem, da ko ima podjetje delujoč informacijski sistem, ki mu v zadostni

meri zaupa, se nenaklonjenost predlaganim novostim poveča, čeprav bi bile iz

stroškovnega vidika ugodnejše.

69

7 SEZNAM VIROV

LITERATURA:

1. Abrazhevich, D. 2004. Electronic Payment Systems, A User-Centered Perspective

and Interaction Design. Eindhoven: Technische Universiteit.

2. Avision, D. & Fitzgerald, G. 1996. Information System Devolopment –

Methodologies, Techniques and Tools. London: McGraww-Hill.

3. Bogataj, K in Pucihar, A. (2002). Izdajanje in prejemanje e-računov. Fakulteta za

organizacijske vede Univerze v Mariboru. [online] Dostopno na:

http://ecenter.fov.uni-mb.si/Studenti/Predmeti/Gradiva/Gradivo-PIS.pdf [04.05.2013]

4. Bračun, F. (2003). Model dejavnikov zaupanja v plačevanje prek interneta. [online]

Dostopno na: http://ecenter.fov.uni-mb.si/Raziskovanje/Raziskave/e-placevanje.htm

[09.06.2012]

5. Budimir, G., Krajnc, A. Nekateri vidiki razvoja tehnologije XML. Institut

informacijske znanosti. [online]

Dostopno na:

http://home.izum.si/cobiss/cobiss_obvestila/2001_4/Html/clanek_03.html

[12.10.2015]

6. Centeno, C. 2001. Securin Internet Payments – The potencial of Public Key

Cryptography. B.k.: Institut for perspective tehnological Studies.

7. Chen, S. 2001. Strategic Management of e-Business. West Sussex, Johny Wiley Sons.

8. Čadež, M. 2012. Prava ideja. Pogovor z Matjažem Čadežem. TV Slovenija 1

9. Flechsig, E., Salmi H., Dechamps A., El-Khoury M. (2003). CEN/ISSS e-Invoicing

Focus Group on Standards and Developments on electronic invoicing to VAT

Directive 2001/115/EC [online] Dostopno na:

http://www.eh.svekom.se/nyheter/final%20e-invoicing%20report.pdf [22.07.2013]

10. Gričar, J. 2002. Poslovni informacijski sistem. Študijsko gradivo. Fakulteta za

organizacijske vede. Univerza v Mariboru.

11. Gričar, J. 1997. Odprta vprašanja in smernice uvajanja elektronskega poslovanja v

majhnih in srednje velikih podjetjih. Revija za management, informatiko in kadre.

Letnik 30, številka 5, str. 245 -253.

12. Hajtnik, T. 2007. Elektronska hramba dokumentarnega gradiva: sedanjost, ne

prihodnost. Seminar, Arhiv Republike Slovenije.Radenci.

http://ecenter.fov.uni-mb.si/Studenti/Predmeti/Gradiva/Gradivo-PIS.pdf

http://ecenter.fov.uni-mb.si/Raziskovanje/Raziskave/e-placevanje.htm

http://home.izum.si/cobiss/cobiss_obvestila/2001_4/Html/clanek_03.html

http://www.eh.svekom.se/nyheter/final%20e-invoicing%20report.pdf

70

13. Hajtnik, T., Škofljanec, J. 2008. Enotne Tehnološke Zahteve in MoReq – je kaj

novega? Seminar: Tehnični in vsebinski problemi klasičnega in elektronskega

arhiviranja.

14. Hauc, A. 2007. Projektni managament. Druga spremenjena izdaja. GV Ljubljana.

15. Hauc, A. 2002. Projektni management. GV Ljubljana.

16. Jerman Blažič, B. 2004. Informacijska varnost. Monitor (5).

17. Jerman Blažič, B. 2001. Elektronsko poslovanje na internetu. Ljubljana: Gospodarski

vestnik.

18. Kalakota, R., Whinston, A. 1997. Electronic commerce. B.K.: Addison Wesley.

19. Kapion. (2013). Življenjski cikel programske opreme. [online] Dostopno na:

ftp://ftp.kapion.si/pub/B2/INS/IS_v_4_6_2004.pdf [09.06.2012]

20. Kern, T., Urh, B., Roblek, M. 2004. Projektni informacijski sistemi. Prispevek na

konferenci v Portorožu.

21. Kvale, S. 1996 InterViews: An Introduction to Qualitative Research Interviewing.

Publications.

22. Laudon, K., Traver, C. 2002. E-commerce: business, technology, society. London:

Addison Wesley.

23. Merriam, S. 1998. Qualitative research and case study applications in education. San

Francisco.

24. Modic, J. 2011. E-računi. Diplomsko delo. Univerza v Ljubljani.

25. Nyshadham, A. E., Ugbaja, M. 2006. Study of Ecommerce Risk Perceptions among

B2C Consumers: A Two Country Study. Bled: Nova Southeasteren University.

26. Oppliger, R. 2003. Security Tehnologies for the World WideWeb. (2nd ed.) London:

Artech House.

27. Petrič, K. (2009). E-arhiviranje. [online] Dostopno na:

http://www.mnz.gov.si/fileadmin/mnz.gov.si/pageuploads/SK/slike/2009/E_publikaci

je_2009/E_arhiviranje.html [31.07.2013]

28. Rant, M., Jeraj, M., Ljubič, T. 1995. Vodenje projektov. Radovljica.

29. Semolič, B. (2007). Projektni management. Študijsko gradivo.

30. Skrt, R. (2006). Elektronski zajem in arhiviranje dokumentov. [online] Dostopno na:

http://www.nasvet.com/elektronsko-arhiviranje/ [22.08.2013]

ftp://ftp.kapion.si/pub/B2/INS/IS_v_4_6_2004.pdf

http://www.mnz.gov.si/fileadmin/mnz.gov.si/pageuploads/SK/slike/2009/E_publikacije_2009/E_arhiviranje.html

http://www.mnz.gov.si/fileadmin/mnz.gov.si/pageuploads/SK/slike/2009/E_publikacije_2009/E_arhiviranje.html

http://www.nasvet.com/elektronsko-arhiviranje/

71

31. Škraba, I. Osnove računalniške arhitekture I. FRI. [online] Dostopno na:

http://www.google.si/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUK

EwjMyP6nt7HJAhUM3SwKHR8JDe4QFggiMAA&url=http%3A%2F%2Fwww.fri.

uni-lj.si%2Ffile%2F102854%2Fora1-

7.pdf&usg=AFQjCNGh18a1IUxycx_p4hrpPNys4erwug [27.11.2015]

32. Turban, E., King, D. 2003. Introduction to e-commerce. Upper Saddle River. (N.J.):

Prentice Hall

33. Zupan, N. 2000. Priložnosti in težave izmenjavanja podatkov preko interneta med

večjimi in manjšimi podjetji v Sloveniji. Magistrsko delo. Fakulteta za organizacijske

vede, Univerza v Mariboru.

34. Zupančič, D. (2004). Cross-border eInvoicing in eRegion – Companies & Chambers

of Commerce Perspective. [online] Dostopno na: http://ecom.fov.uni-

mb.si/MerkurDay2004/program.htm [19.112013]

VIRI:

35. Agencija republike Slovenije za javnopravne evidence in storitve - AJPES. (2014).

Predstavitev. [online] Dostopno na :

http://www.ajpes.si/O_AJPES/Predstavitev/Vizija,_poslanstvo_in_strateski_cilji

[20.03.2014]

36. Arhiv republike Slovenije. (2014). Predpisi s področja arhivske dejavnosti v

Sloveniji. [online] Dostopno na:

http://www.arhiv.gov.si/si/zakonodaja_in_dokumenti/predpisi_s_podrocja_arhivske_

dejavnosti_v_sloveniji/ [22.07.2013]

37. Davčna uprava republike Slovenije - DURS. (2013). Elektronski računi. [online]

Dostopno na:

http://www.durs.gov.si/si/davki_predpisi_in_pojasnila/davek_na_dodano_vrednost_p

ojasnila/izdaja_racunov/elektronski_racuni/ [21.03.2014]

38. Državni portal republike Slovenije. (2013). Pridobitev digitalnega potrdila. [online]

Dostopno na:

https://e-uprava.gov.si/e-uprava/dogodkiPrebivalci.euprava?zdid=780&sid=244

[22.08.2013]

39. European Comission. (2009). Final Report of the Expert Group on e-Invoicing.

[online] Dostopno na: http://ec.europa.eu/internal_market/consultations/docs/2009/e-

invoicing/report_en.pdf [22.08.2013]

40. Fakulteta za računalništvo in informatiko - FRI. (2013). Programsko inženirstvo.

[online] Dostopno na: http://colos.fri.uni-

http://www.google.si/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjMyP6nt7HJAhUM3SwKHR8JDe4QFggiMAA&url=http%3A%2F%2Fwww.fri.uni-lj.si%2Ffile%2F102854%2Fora1-7.pdf&usg=AFQjCNGh18a1IUxycx_p4hrpPNys4erwug




http://ecom.fov.uni-mb.si/MerkurDay2004/program.htm

http://ecom.fov.uni-mb.si/MerkurDay2004/program.htm

http://www.ajpes.si/O_AJPES/Predstavitev/Vizija,_poslanstvo_in_strateski_cilji

http://www.arhiv.gov.si/si/zakonodaja_in_dokumenti/predpisi_s_podrocja_arhivske_dejavnosti_v_sloveniji/

http://www.arhiv.gov.si/si/zakonodaja_in_dokumenti/predpisi_s_podrocja_arhivske_dejavnosti_v_sloveniji/

http://www.durs.gov.si/si/davki_predpisi_in_pojasnila/davek_na_dodano_vrednost_pojasnila/izdaja_racunov/elektronski_racuni/

http://www.durs.gov.si/si/davki_predpisi_in_pojasnila/davek_na_dodano_vrednost_pojasnila/izdaja_racunov/elektronski_racuni/

https://e-uprava.gov.si/e-uprava/dogodkiPrebivalci.euprava?zdid=780&sid=244

http://ec.europa.eu/internal_market/consultations/docs/2009/e-invoicing/report_en.pdf

http://ec.europa.eu/internal_market/consultations/docs/2009/e-invoicing/report_en.pdf

http://colos.fri.uni-lj.si/eri/RACUNALNISTVO/INFORMATIKA/takojnja_implementacija.html

72

lj.si/eri/RACUNALNISTVO/INFORMATIKA/takojnja_implementacija.html

[22.08.2013]

41. Gospodarska zbornica Slovenije - GZS. (2013). e-SLOG dokumentacija. [online]

Dostopno na: http://www.gzs.si/slo/6679 [22.07.2013]

42. Gospodarska zbornica Slovenije – GZS. (2012). Projekt e-SLOG. [online] Dostopno

na:

https://e-slog.gzs.si/.../Prirocnik_ESLOG_1_6_verzija_2012_1_5.pdf [17.10.2015]

43. Gospodarska zbornica Slovenije - GZS. (2004). Pravna vprašanja elektronskega

podpisa, elektronskega poslovanja in elektronskih arhivov. [online] Dostopno na:

http://www.gzs.si/e-

poslovanje/dokumentacija/eSLOG_Pravna_vprasanja_ePoslovanja_1.4.pdf

[31.07.2013]

44. GXS. (2013a). E-InvoicingBasics. From paper to 100% electronic invoicing. [online]

Dostopno na: http://www.einvoicingbasics.co.uk/benefits-of-einvoicing/ [15.05.2014]

45. GXS. (2013b). The Ten Business Benefits of E-Invoicing. [online] Dostopno na:

http://www.gxs.co.uk/wp-content/uploads/ten_business_benefits_of_e-invoicing.pdf

[15.05.2014]

46. Halcom-CA. (2013). Digitalni podpis. [online] Dostopno na: http://www.halcom-

ca.si/?section=16 [30.06.2013]

47. Ministrstvo za visoko šolstvo, znanost in tehnologija. (2013). Register overiteljev.

Dostopno na:

http://www.arhiv.mvzt.gov.si/si/delovna_podrocja/informacijska_druzba/register_ove

riteljev/ [31.05.2014]

48. PMBOOK guide. 2004. A guide to Project Management Body of Knowledge. Third

Edition. PM Institute. Newtown Squere.

49. SECCTE. (2005). eKeeper – Trusted Electronic Archive. [online] Dostopno na:

http://www.setcce.si/images/download/eKeeper_brochure_eng.pdf [31.07.2013]

50. SI.TSA. (2013). Osnove varnih časovnih žigov. [online] Dostopno na: http://www.si-

tsa.gov.si/osnove.php [19.08.2013]

51. SURS - Statistični urad Republike Slovenije. (2010). Poslovanje podjetij po

dejavnosti in velikostnih razredih, podrobni podatki, Slovenija, 2009. [online]

Dostopno na: http://www.stat.si/novica_prikazi.aspx?id=3578 [05.06.2014]

52. Uradni list RS. (2013). Zakon o spremembah in dopolnitvah Zakona o opravljanju

plačilnih storitev za proračunske uporabnikov 111/2013. [online] Dostopno na:

http://www.uradni-list.si/1/content?id=115793 [20.03.2014]

http://colos.fri.uni-lj.si/eri/RACUNALNISTVO/INFORMATIKA/takojnja_implementacija.html

http://www.gzs.si/slo/6679

https://e-slog.gzs.si/.../Prirocnik_ESLOG_1_6_verzija_2012_1_5.pdf

http://www.gzs.si/e-poslovanje/dokumentacija/eSLOG_Pravna_vprasanja_ePoslovanja_1.4.pdf

http://www.gzs.si/e-poslovanje/dokumentacija/eSLOG_Pravna_vprasanja_ePoslovanja_1.4.pdf

http://www.einvoicingbasics.co.uk/

http://www.einvoicingbasics.co.uk/benefits-of-einvoicing/

http://www.gxs.co.uk/wp-content/uploads/ten_business_benefits_of_e-invoicing.pdf



http://www.arhiv.mvzt.gov.si/si/delovna_podrocja/informacijska_druzba/register_overiteljev/

http://www.arhiv.mvzt.gov.si/si/delovna_podrocja/informacijska_druzba/register_overiteljev/

http://www.setcce.si/images/download/eKeeper_brochure_eng.pdf

http://www.si-tsa.gov.si/osnove.php

http://www.si-tsa.gov.si/osnove.php

http://www.stat.si/novica_prikazi.aspx?id=3578

http://www.uradni-list.si/1/content?id=115793

73

53. Uradni list RS. (2012). Zakon o davku na dodano vrednost 13/11. [online] Dostopno

na: http://zakonodaja.gov.si/rpsi/r01/predpis_ZAKO4701.html [30.06.2013]

54. Uradni list RS. (2006). Zakon o elektronskem poslovanju in elektronskem podpisu

61/06. [online] Dostopno na:

http://zakonodaja.gov.si/rpsi/r03/predpis_ZAKO1973.html [30.06.2013]

55. Uradni list RS. (2006). Zakon o varstvu dokumentarnega in arhivskega gradiva

30/06. [online] Dostopno na:

http://zakonodaja.gov.si/rpsi/r04/predpis_ZAKO4284.html [30.06.2013]

56. Uradni list RS. (2004). Zakon o elektronskem poslovanju in elektronskem podpisu

98/04. [online] Dostopno na: http://www.uradni-

list.si/1/objava.jsp?urlid=200498&stevilka=4284 [30.06.2013]

57. Wikipedia - WIKI. (2013). Electronic billing. [online] Dostopno na:

http://en.wikipedia.org/wiki/Electronic_billing [20.08.2013]

58. Wikipedia - WIKI. (2013). Electronic data interchange. [online] Dostopno na:

http://en.wikipedia.org/wiki/Electronic_data_interchange [20.08.2013]

59. Wikipedia - WIKI. (2013). Universal Business Language. [online] Dostopno na:

http://en.wikipedia.org/wiki/Universal_Business_Language [20.08.2013]

60. Wikipedia - WIKI. (2013). EDIFACT. [online] Dostopno na:

http://en.wikipedia.org/wiki/EDIFACT [20.08.2013]

61. Wikipedia - WIKI. (2013). Extensible Markup Language. [online] Dostopno na:

http://sl.wikipedia.org/wiki/XML [20.08.2013]

62. Združenje bank Slovenije - ZBS. Poslanstvo ZBS. [online] Dostopno na:

http://www.zbs-giz.si/zdruzenje-bank.asp?StructureId=365 [09.06.2012]

http://zakonodaja.gov.si/rpsi/r01/predpis_ZAKO4701.html





http://en.wikipedia.org/wiki/Electronic_billing

http://en.wikipedia.org/wiki/Electronic_data_interchange

http://en.wikipedia.org/wiki/Universal_Business_Language

http://en.wikipedia.org/wiki/EDIFACT

http://sl.wikipedia.org/wiki/XML

http://www.zbs-giz.si/zdruzenje-bank.asp?StructureId=365

74

SEZNAM SLIK

Slika 1: Šifriranje s pomočjo simetričnega algoritma ......................................................... 24

Slika 2: Šifriranje s pomočjo asimetričnega algoritma ....................................................... 25 Slika 3: Postopek digitalnega podpisovanja ......................................................................... 26 Slika 4: Postopek časovnega žigosanja ................................................................................. 27 Slika 5: SLAM-DUNK model programiranja ..................................................................... 41 Slika 6: Baročni model programiranja ................................................................................. 41

Slika 7: Kaskadni model programiranja .............................................................................. 42 Slika 8: Spiralni model programiranja ................................................................................ 43 Slika 9: Primer poenostavljenega diagrama toka podatkov ............................................... 44 Slika 10: Primer poenostavljenega diagrama prehajanja stanj, s pomočjo kontrolnih

diagramov. ............................................................................................................................... 46 Slika 11: Organizacijska struktura podjetja Pro-Bit d.o.o. .... Error! Bookmark not defined.

Slika 12: Izsek poročila o testiranju uvedbe e-računov ...................................................... 56

75

SEZNAM TABEL

Tabela 1: Struktura sporočila EDIFACT ............................................................................ 32

Tabela 2: Izsek računa v standardu EDIFACT ................................................................... 33 Tabela 3: Vsebina XML dokumenta ..................................................................................... 34 Tabela 4: Vsebina XML dokumenta in zapis podatkov v tabelo poštna knjiga ............... 52 Tabela 5: Značilnosti izbranega vzorca podjetij, različnih velikosti ................................. 59 Tabela 6: Značilnosti izbranega vzorca intervjuvanih oseb ............................................... 59

76

PRILOGA 1

OPORNE TOČKE ZA GLOBINSKI INTERVJU

1. SEGMENT INTERVJUJA: značilnosti sodelujočega

Kontaktna oseba: spol, starost, delovne izkušnje, pozicija v podjetju

Datum intervjuja:

Specifika podjetja: velikost, lasten IT oddelek

2. SEGMENT INTERVJUJA: kvalitativna odprta vprašanja

1. Kaj razumete pod pojmom e-poslovanje in uporabo e-računov v vašem podjetju?

2. Poznate programsko rešitev e-računov v programu PRO.3 Finance?

Kako ste se seznanili s programsko rešitvijo e-računov?

3. Ali v programu PRO.3 Finance uporabljate e-račune?

Uporabljate poljubne podatkovne strukture, ki ste jih razvili s pomočjo sodelovanja našega

podjetja in drugim ponudnikom programskih rešitev?

Uporabljate standardizirane podatkovne strukture, kot je e-SLOG?

4. Kakšna je bila uvedba programske rešitve e-računov v vaš obstoječi informacijski

program PRO.3 Finance iz časovnega in stroškovnega vidika?

Bi lahko rekli, da je bil razlog v visokih stroških pomanjkanje znanja ponudnikov

programskih rešitev?

5. Ali imate lasten IT oddelek in kakšno vlogo je imel pri uvajanju programske

rešitve e-računov v vaš informacijski sistem?

6. Kdo je bil gonilna sila ali razlog za uvedbo programske rešitve e-računov v vaš

informacijski sistem?

Vodstvo podjetja

IT oddelek

Vodja oddelka za računovodstvo

Končni uporabnik

Zakonodajni predpisi

7. Ste zadovoljni z uporabo in vzdrževanjem programske rešitve e-računov?

Kako bi opisno ocenili uporabo in vzdrževanje programske rešitve e-računov ter odziv

ponudnika v primeru zakonske spremembe?

(odlično, dobro, srednje dobro, primerno, neprimerno)

8. Kakšne so koristi v vašem podjetju, ki jih je prinesla uporaba e-računov in ali

kljub uporabi e-računov fizično natisnete račun ter ga odložite v arhiv?

9. Kje so po vašem mnenju razlogi, da še ne uporabljate standardiziran uvoz e-

računov, kot ga priporoča stroka (to je uporaba predpisane oblike e-SLOG)?

77

Premajhno število prejetih računov

Previsok strošek uvedbe programske rešitve e -računov

Nepripravljenost bančnih sistemom in dolgotrajen proces pridobivanja soglasja

Nezaupanje v brezpapirno in izključno elektronsko poslovanje

78

PRILOGA 2 Specifikacija za oddajo zahtevkov za dodelavo programskih rešitev k ponudbi številka:

1. Stranka:

Vse potencialne stranke, ki uporabljajo računovodski program PRO.3 Finance.

2. Program:

PRO.3 FINANCE; modul poštna knjiga in knjiga prejetih računov.

3. Datum: DDMMLLLL

31.12.2014

4. Opis dodelave oz. spremembe (krajši opis):

Dodelava obsega nadgradnjo poštne knjige in knjige prejetih računov, kjer dodamo opcijo samodejnega uvoza e-računov na osnovi standardizirane podatkovne strukture e-SLOG.

5. Vhodni podatki

Vhodni podatki so XML dokumenti, ki jih pridobimo iz elektronskega bančništva. XML dokument temelji na standardu izmenjave podatkov e-SLOG. V XML dokumentu so zapisani prejeti e-računi za izbrani datum. Odvisno od tega, kako uporabnik izvozi prejete e-račune, poznamo posamezno ali skupinsko izvažanje e-računov.

6. Opis dodelave oz. spremembe (podrobnejši opis, po potrebi):

Postopek spremembe programske rešitve:

1. E-račune, zapisane v XML dokumentu, najprej izvozimo iz banke in jih shranimo na želeno lokacijo na računalniku.

2. V programu PRO.3 Finance, in sicer v modulu poštna knjiga ali modulu knjiga prejetih

računov nastavimo lokacijo, kamor smo shranili e-račune.

3. V modul poštna knjiga in/ali knjiga prejetih računov, dodamo opcijo Uvoz e-računov:

79

4. Po končani akciji se uvozijo e-računi v program.

5. Izhodni podatki

Izhodni podatki, so zapisani podatki iz XML dokumenta v tabelo poštna knjiga. Tabela 1: Vsebina XML dokumenta in opredelitev polj v poštni knjigi

XML document Polje poštna knjiga Opomba <name>TELEKOM SLOVENIJE, D.D.</name>

Naziv


Naslov

<address>1000 LJUBLJANA</address>

Kraj

<amount>22.97</amount> Vrednost <creditor_structured_reference>SI120150127920241</creditor_structured_reference>

Dob_sklic Referenca računa


Datum_v Datum valute


Datum_p Datum prejema

<additional_remittance_information>Račun za 08/2012</additional_remittance_information>

Zadeva

<external_doc_id>0150127920241</external_doc_id>

D_racun Dobaviteljeva številka računa

Tabela 2: Vsebina XML dokumenta in opredelitev polj v knjigi prejetih računov

XML document Polje knjiga prejetih računov Opomba <name>TELEKOM SLOVENIJE, D.D.</name>

Dob_naziv Dobaviteljev naziv


Naslov

80

<address>1000 LJUBLJANA</address>

Kraj

<amount>22.97</amount> Vrednost <creditor_structured_reference>SI120150127920241</creditor_structured_reference>

Dob_sklic Referenca računa


D_val Datum valute


D_prej Datum prejema

<additional_remittance_information>Račun za 08/2012</additional_remittance_information>

Namen

<external_doc_id>0150127920241</external_doc_id>

Dob_rac Dobaviteljeva številka računa

<debtor_agent>LJBASI2XXXX</debtor_agent>

SWIFT

6. Priloge:

Prirocnik ESLOG 1 6 verzija 2012 1 5

Specifikacijo pripravil/a: Maja Gal Ravnjak

https://e-slog.gzs.si/pripone/Prirocnik_ESLOG_1_6_verzija_2012_1_5.pdf

REPUBLIKA SLOVENIJA UNIVERZA V MARIBORU EKONOMSKO … · 2017. 11. 28. · na smeri Poslovna...

Documents

Transcript of REPUBLIKA SLOVENIJA UNIVERZA V MARIBORU EKONOMSKO … · 2017. 11. 28. · na smeri Poslovna...