Post on 06-Oct-2020
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.
H1: V poslovnih informacijskih rešitvah na področju plačilnega prometa je najbolj
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.
H2: Kaskadni model razvijanja/dodelave poslovnih rešitev daje najboljše rezultate
uvajanja podatkovnih standardov.
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.
H3: Uvajanje standardiziranih podatkovnih struktur daje boljše rezultate kot uvajanje
posamičnih, med posameznimi podjetji dogovorjenih podatkovnih struktur.
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.
H4: Najpogosteje uvajajo podatkovne standarde velika podjetja.
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;
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
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
0050 DTM Datum/Čas/Obdobje M 1
0060 FTX Prosto besedilo C 5
POVZETEK
…
0070 MOA Skupni znesek M 1
0080 DTM Datum/Čas/Obdobje 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> <!--Naziv pošiljatelja--> <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>l.k@telekom.si</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>L.K@telekom.si</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
P2 K3 Ž >50 5-10 Vodja finančno računovodske
službe
P3 K4 Ž 40-50 10-15 Računovodja
P3 K5 Ž >50 >15 Vodja finančno računovodske
službe
P4 K6 Ž 40-50 10-15 Vodja finančno računovodske
službe
P5 K7 Ž 30-40 5-10 Računovodja
P6 K8 Ž >50 10-15 Vodja finančno računovodske
službe
P7 K9 Ž 30-40 5-10 Računovodja
P8 K10 Ž 40-50 10-15 Vodja finančno računovodske
službe
P9 K11 Ž 30-40 5-10 Vodja finančno računovodske
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.
H1: V poslovnih informacijskih rešitvah na področju plačilnega prometa je najbolj
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.
H2: Kaskadni model razvijanja/dodelave poslovnih rešitev daje najboljše rezultate
uvajanja podatkovnih standardov.
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.
H3: Uvajanje standardiziranih podatkovnih struktur daje boljše rezultate kot uvajanje
posamičnih, med posameznimi podjetji dogovorjenih podatkovnih struktur.
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
H4: Najpogosteje uvajajo podatkovne standarde velika podjetja.
Š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.
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]
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-
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]
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]
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
<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>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
<address>CIGALETOVA ULICA 15</address>
Naslov
80
<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>
D_val Datum valute
<timestamp>2012-09-05T20:11:44.000</timestamp>
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