vpeljava on line avtorizacije bankomatskih in pos

UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE

Diplomsko delo visokošolskega strokovnega študija Smer: Informatika v organizaciji in managementu

VPELJAVA ON LINE AVTORIZACIJE BANKOMATSKIH IN POS TRANSAKCIJ V

HYPO ALPE-ADRIA-BANK D.D.

Mentor: doc. dr. Igor Bernik Kandidat: Anže Šubelj

Kranj, december 2009

ZAHVALA

Zahvaljujem se svojemu mentorju doc. dr. Igorju Berniku za vse njegove nasvete in pomoč pri sestavljanju te diplomske naloge. Še posebej bi se rad zahvalil vsem mojim sodelavcem, ki so mi pomagali s svojimi bogatimi izkušnjami pridobivati potrebno znanje in material. Ne nazadnje pa bi se zahvalil tudi moji ženi Simoni ter hčerkama Neji in Nini, ki so mi v času študija vedno stali ob strani in me spodbujali.

POVZETEK V diplomskem delu je predstavljena selitev sistema za avtoriziranje zahtevkov vnesenih preko bankomatov, oziroma POS terminalov. Pred selitvijo se je avtorizacija izvajala izključno v podjetju Bankart d.o.o. ki se je do sedaj tako pojavljal v dvojni vlogi. Do vpeljave tega projekta se je Bankart d.o.o. pojavljal v vlogi procesnega centra, kar ostaja še danes, ter v vlogi avtorizacijske hiše. Za slednjo smo morali plačevati dodatno provizijo. Poleg tega nismo mogli voditi trenutnega stanja na računih naših komitentov, saj smo informacije o prometu na bankomatih in POS terminalih dobivali šele naslednji dan, z datoteko za knjiženje. Z vpeljavo tega projekta naj bi se avtorizacije zahtevkov izdanih preko bankomatov in POS terminalov vršile v Hypo Alpe-Adria-bank d.d. Zaradi sodelovanja več strokovnjakov iz različnih področji znotraj HBS, ter zunanjih partnerjev, kot tudi zadostitvi vseh pogojev, ki so znotraj celotne grupe Hypo group Alpe Adria potrebni za vpeljavo projekta, se je celotna naloga vodila kot projekt. Ustanovila se je projektna skupina, katera je celoten projekt pripeljala do vključitve v produkcijsko okolje. Znotraj projekta so bili določeni časovni roki, finančna, kadrovska in tehnična sredstva. KLJUČNE BESEDE

• Bankomat • POS terminal • On line avtorizacija • Maestro plačilna kartica • MPLS • Projekt

ABSTRACT The diploma work is presented in changing the way authorization requests entered via the ATM or POS terminals. Before changing the authorization performed exclusively in the company Bankart d.o.o, which has so far appeared in the dual role. Until end of this project Bankart d.o.o., appeared as a process centre, which remains today, as well as Authorisation house. For these two services we have had to pay a commission. We are receiving the traffic information at ATMs and POS terminals not until next working day. Because of that, we were unable to keep the current balances of our customers. With the introduction of this project the authorisation request is handling by Hypo Alpe-Adria-bank d.d. Due to the cooperation of experts from several different areas within the Hypo Alpe-Adria-Bankd.d., as well as external partners, and fulfilling all necessary conditions needed for starting a project within the entire group Hypo Group Alpe Adria, we ware started these task as a project. Within these project we limits the personnel, technical, financial and time resources.

KEYWORDS • ATM machine • POS computers • On Line authorization • Maestro debit card • MPLS • Project

KAZALO

1. UVOD ................................................................................................................. 1

1.1. PREDSTAVITEV PROBLEMA .................................................. 1 1.2. PREDSTAVITEV OKOLJA ....................................................... 1

2. OSNOVE DELOVANJA BANKOMATSKEGA PLAČILNEGA PROMETA ....... 4

2.1. POVEZAVA PREKO MPLS OMREŽJA ............................................. 4 2.2. ON-LINE AVTORIZACIJA BANKOMATSKIH IN POS TRANSAKCIJ ........... 5 2.3. IZVAJANJE PROJEKTOV V HBS ................................................... 6

3. OBSTOJEČE STANJE ....................................................................................... 8

3.1. POSNETEK STANJA ................................................................... 8 3.2. ANALIZA RAZLOGOV ZA SPREMEMBO NAČINA AVTORIZACIJE ........... 12 S.W.O.T. ANALIZA PROJEKTA VPELJAVA ONLINE .................................. 14

4. ZASNOVA PROJEKTA PRENOVE ................................................................. 15

4.1. PROJEKTNI ZAHTEVEK ............................................................. 15 4.2. BUSINESS CASE ..................................................................... 16 4.3. PROJEKTNA KNJIGA ................................................................. 20 4.3.1. IZGRADNJA VMESNIKA MINIBIC ISO ........................................ 21 4.3.2. POSTAVITEV MREŽNE POVEZAVE HBS-BANKART ....................... 21 4.3.3. IZDELAVA PBF DATOTEKE ..................................................... 22 4.3.4. PRVO TESTIRANJE ............................................................... 22 4.3.5. KNJIŽENJE EVIDENČNEGA PROMETA ........................................ 23 4.3.6. KNJIŽENJE ATM DATA .......................................................... 23 4.3.7. BRISANJE EVIDENČNIH KNJIŽB PO 8 DNEH ................................ 23 4.3.8. PRIKAZ PROMETA TRR NA HYPO-NETU ................................... 24 U

4.3.9. IZDELAVA NAVODIL ............................................................... 24 4.3.10. GLOBALNO TESTIRANJE ..................................................... 24 4.3.11. PREHOD V PRODUKCIJO ..................................................... 24

5. ZAKLJUČKI...................................................................................................... 33

5.1. OCENA UČINKOV ..................................................................... 33 5.2. POGOJI ZA UVEDBO ................................................................. 33 5.3. MOŽNOSTI NADALJNJEGA RAZVOJA ............................................ 35 LITERATURA IN VIRI ..................................................................... 36 KAZALO SLIK ............................................................................... 38 KAZALO TABEL ............................................................................ 38 POJMOVNIK ................................................................................. 39 KRATICE IN AKRONIMI ................................................................. 40

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Anže Šubelj: Vpeljava On Line avtorizacije bankomatskih in POS transakcij v Hypo Alpe-Adria-bank d.d. stran 1

1. UVOD

1.1. PREDSTAVITEV PROBLEMA

Z hitro rastjo Hypo Alpe-Adria-bank d.d. (v nadaljevanju HBS) in s tem povečevanjem števila komitentov, kakor tudi z razvojem tehnologije in razvojem storitev drugih konkurenčnih bank, so se pojavile zahteve po dodatnih storitvah. Ena od dodatnih storitev je tudi prikazovanje vseh transakcij na transakcijskih računih naših komitentov. Spremembe naj bi bile vidne v realnem času in ne šele naslednji dan kot je bila praksa do sedaj.. Med te transakcije spadajo tudi dvigi na bankomatih in plačila preko POS terminalov v sistemu BA Maestro, katerega člani smo tudi mi. Do sedaj se je dvige na bankomatih in plačila preko POS terminalov avtoriziralo na podjetju Bankart d.o.o. (v nadaljevanju Bankart). Zaradi tega smo informacijo o dvigih na bankomatu, oziroma plačilih preko POS terminalov dobili šele naslednji delovni dan. Informacije smo prejeli z datoteko namenjeno knjiženju. S tem je nastajala razlika med prikazanem stanjem na bankomatih, ki je prikazovalo evidenčno stanje na Bankartu z že odštetim zneskom dviga in knjiženem stanjem na računu, katerega vodimo v banki. Stanje računa se prikazuje tudi preko storitve Hyponet.. Časovni zamik je predstavljal grožnjo in sicer kot potencialno možnosti goljufije. Zaradi vsega naštetega in zaradi novih storitev, ki jih ponuja podjetje Bankart smo se v HBS odločili, da bomo avtorizacijo dvigov na bankomatu in plačil preko POS terminalov izvajali sami. S tem bomo povečali varnost poslovanja, dvignili zadovoljstvo strank, ter pocenili poslovanje, k čemur pa v HBS vedno strmimo. Pri tem prehodu moramo zagotoviti odzivnost in visoko razpoložljivost našega informacijskega sistema. Le na tak način bomo lahko povečali zadovoljstvo naših strank.

1.2. PREDSTAVITEV OKOLJA

HBS je del mednarodne skupine Hypo-Alpe-Adria group, katera je prisotna predvsem na celotnem področju Alpe Adria. Ne glede na razvejanost grupe po celotni regiji, so posamezne članice tudi del bančnega sistema države v kateri se nahajajo. Tudi naša banka ni nobena izjema. Na spodnji sliki (Slika 1) si lahko ogledamo organizacijsko strukturo naše banke v obliki organigrama. Vse banke naše skupine imajo podobno organizacijsko shemo.


Slika 1: Organigram HBS (vir: http://www.hypo-alpe-adria.si/si_cms/bank/home.nsf/r/Organigram/$file/HBS_SLO_01_09_2009_brez_imen.pdf)

Tako smo kot del finančnega sistema v Sloveniji med drugim povezani tudi v sistem BA Maestro. Ta pa je del bolj poznanih sistemov Maestro in Cirrus. Ta dva sistema debetnih kartic sta zelo razširjena na celotnem evropskem prostoru. Kartice se lahko uporablja na vseh bankomatih in POS terminalih, ki so del omenjenih sistemov. Naš procesni center je podjetje Bankart . Za namen avtoriziranja in procesiranja avtorizacijskih zahtevkov, izdanih na bankomatih in POS terminalih, so v podjetju Bankart razvili posebno aplikacijo BSE. Ta aplikacija upravlja z celotnim dogajanjem v sistemu BA Maestro. Med drugim aplikacija BSE bankam članicam sistema pripravlja datoteke za knjiženje prometa na bankomatih in POS terminalih. Do sedaj



je Bankart za nas poleg procesnega centra izvrševal tudi avtorizacijo vseh zahtev, vnesenih preko bankomatov in POS terminalov. V tej diplomski nalogi bo predstavljen projekt selitve procesa avtoriziranja iz Bankarta na HBS. Za ta namen so nam naši zunanji partnerji po Bankartovih navodilih in naših funkcijskih specifikacijah razvili sistem avtoriziranja, katerega smo skupaj umestili v naš informacijski sistem. S tem sistemom bomo lahko sami upravljali z avtorizacijo vseh bankomatskih in POS zahtevkov naših komitentov. V HBS, kot osnovno bančno aplikacijo uporabljamo program HIBIS, katerega je za banke razvilo podjetje HRC d.o.o. iz Žalca. To je zelo kompleksen sistem, sestavljen iz več modulov. Moduli pokrivajo različne segmente bančnih poslov. Kot del tega sistema bo razvit tudi nov modul za OnLine avtorizacijo. Program HIBIS je zgrajen na relacijski bazi Oracle. Na HIBIS-ove baze se povezujejo tudi drugi bančni programi, med katerimi je tudi naša spletna banka HypoNET. Oraclova baza je nameščena na strežnike, ki delujejo v načinu visoke razpoložljivosti (cluster). Sami podatki se hranijo v diskovnem polju SAN. Celoten sistem je za primer kakršne koli odpovedi na primarni lokaciji, podvojen v našem centru rezervnih zmogljivosti. Celotna podatkovna baza se poleg podvojenosti sistema, še redno arhivira na trakove v dnevnih, tedenskih in mesečnih ciklih. Trakovi se med seboj rotirajo in prepisujejo. Izjema so samo mesečni trakovi, katere se nosi na oddaljeno lokacijo, v z zakonom določeno 10 letno hrambo.



2. OSNOVE DELOVANJA BANKOMATSKEGA PLAČILNEGA PROMETA

V zadnjem času smo priča velikemu razmahu informacijske tehnologije. Ta razvoj je prinesel veliko pozitivnih in na žalost tudi nekaj negativnih stvari. Med pozitivne umeščamo zmožnost obdelave velike količine podatkov v realnem času, pridobivanje želenih podatkov, praktično kjerkoli in kadarkoli in njihov prikaz na poljuben način. Med negativne stvari pa nedvomno uvrščamo izgubo velike mere zasebnosti, nevarnost škodljivega manipuliranja s podatki, ter ne nazadnje možnost različnih goljufij, kar iz nepridipravovega računalnika povezanega v omrežje. V diplomski nalogi opisujemo delovanje avtorizacij plačilnih zahtevkov poslanih preko bankomatov oz. POS terminalov. Te podatki so še posebej občutljivi, saj predstavljajo finančne podatke slehernega komitenta naše banke. Zaradi tega se za prenos teh podatkov uporablja zasebno omrežje, ki je skrbno varovano in nedostopno iz omrežji, kot je Internet. Poleg tega je v sam prenos vključenih še kar nekaj varnostnih mehanizmov. Te mehanizmi so med drugim podpisovanje in kodiranje z certifikati izdanimi od zaupanja vrednih institucij. Zaradi hitrosti delovanja in cenejšega vzdrževanja privatnih omrežji, se vedno bolj uporablja enake protokole, kot jih poznamo v modernem Internetu. Vendar so ta omrežja, zaradi varnosti, fizično ločena od javnih omrežji. V nalogi bomo predstavili in obravnavali povezavo med HBS in Bankartom. Obravnavali bomo tudi način avtoriziranja poslanih zahtevkov in prikaz prometa v spletni banki.

2.1. Povezava preko MPLS omrežja

Najprej opišimo MPLS omrežje, katerega bomo uporabili za povezavo HBS z Bankartom. Kot je opisano v enciklopediji Wikipedia je Multi Protocol Label Switching, kar kratica MPLS pomeni, vrsta povezave, ki je bila prvotno razvita za zamenjavo sicer zelo varnega vendar okornega omrežnega protokola Frame relay. Ta protokol je ustvarjal veliko prometa. MPLS zaradi svoje uporabnosti izpodriva tudi protokol ATM. Stari protokoli so imeli veliko balasta v obliki raznih kontrolnih mehanizmov. Zaradi tega so ustvarjali veliko prometa na že tako malih prepustnostih omrežja. Ta potratnost in slaba omrežna prepustnost sta povzročali neodzivnost sistemov. Poleg tega je bila taka infrastruktura zelo draga, saj je bilo potrebno fizično povezati obe končni točki. Izgradnja frame relay ali ATM omrežja je zaradi vsega naštetega zelo dolgotrajna, saj traja izvedba povezave tudi po več mesecev. Po drugi strani pa so zaradi direktnih povezav taka omrežja izjemno varna, saj morajo biti mrežne naprave med seboj fizično povezana. MPLS omrežje uspešno ohranja varnost frame ralaya oz ATM omrežji, poleg tega pa izkorišča sodobne internetne standarde povezav. Te povezave zagotavljajo dosti večji pretok podatkov, kar zelo poveča odzivnost celotnega sistema. Zaradi razširjenosti naprav, katere podpirajo potrebno tehnologijo, so tudi cene takih sistemov občutno nižje. Ravno tako je zaradi razširjenosti uporabe poznavanje protokolov boljše. Tako je število strokovnjakov večje, zaradi česar je samo vzdrževanje takega sistema lažje in cenejše. V MPLS omrežju podatkovnim paketom dodajamo tako imenovane etikete. Usmerjanje teh paketov se vrši izključno preko teh etiket. Zaradi tega je lahko vsebina paketa kodirana in se pri usmerjanju ne spreminja. Ta lastnost omogoča kreiranje povezav točka- točka preko kateregakoli protokola oziroma vrste nosilca



podatkov (optika, bakrena parica, wireless…). Največja pridobitev je torej izničenje odvisnosti od določene tehnologije na drugem nivoju OSI modela (Data link layer) kot so ATM, Frame relay, SONET ali Ethernet. Ob enem odstrani potrebo po večkratni uporabi Data Link nivoja, za zagotovitev različnih tipov prometa. V OSI modelu se MPLS umešča nekje med 2 in 3 nivo, tako da se ga pogosto opisuje kot nivo 2,5. Vsi paketi so, kot že rečeno, lahko kodirani in podpisani. S tem je zagotovljena relativno visoka varnost poslanih paketov, saj jih lahko odklene in prebere samo lastnik certifikata. MPLS zaradi svojega načina delovanja deluje na IPv4 kot tudi IPv6 omrežjih. Zaradi naštetih lastnosti se tem omrežjem obeta svetla prihodnost.

6.Predstavitveni nivo

7.Aplikacijski nivo

5.Nivo seje

4. Transportni nivo

3.Mrežni nivo

2.Nivo Podatkovne povezave

1.Fizični nivo

OSI MODEL

Slika 2: OSI model (vir: Bernik, I. (2005), Računalniški sistemi 10. Komunikacije)

Tudi na Bankart-u, kot novi Slovenski klirinški hiši so se odločili za uporabo MPLS omrežja, katerega jim je postavil zunanji partner. V bližnji prihodnosti bodo postavili še eno tako omrežje za katerega bo skrbel drug zunanji partner. S tem se bo zagotovila podvojenost omrežja. Bankart uporablja MPLS predvsem zaradi svoje vloge kot klirinška hiša. Vendar bo to omrežje postopno uporabil tudi za druge povezave, kot so izmenjava raznovrstnih finančnih podatkov. Bankomatsko ter POS omrežje pa je v času nastajanja te diplomske naloge ravno v fazi selitve na novo omrežje.

2.2. On-line avtorizacija bankomatskih in POS transakcij

On line avtorizacija bankomatskih in POS transakcij pomeni, da vse transakcije, ki so poslane iz bankomata oziroma POS terminala, avtorizira avtorizacijska hiša. V našem primeru je to banka izdajateljica plačilne kartice in skrbnica transakcijskega računa komitenta. S tem se procesnemu centru odvzame vlogo avtorizacije, katero prevzame le v primeru izpada katerega koli dela avtorizacijskega sistema na strani banke. S tem dobi banka večjo kontrolo nad prometom na posameznem transakcijskem računu. Poveča se tudi varnost samega poslovanja.



2.3. Izvajanje projektov v HBS

V HBS se vsi projekti pripravijo in vodijo po enotnem okviru, ki je predpisan za vse banke znotraj Hypo grupe. Pravila in napotki so tako zbrani v dokumentu The Hypo Project Management Framework (v nadaljevanju HPMF).. Dokument se stalno dopolnjuje in sledi vsem svetovno uveljavljenim standardom projektnega vodenja. Trenutna verzija dokumenta je 3.0. Za dokument skrbijo kolegi v matični banki iz Celovca. Kot določa ta dokument, imamo v vsaki banki znotraj skupine formirano lokalno projektno pisarno. Naloga lokalne projektne pisarne je spremljati vse projekte v posamezni banki in obveščati matično banko o realizaciji le teh. Vsak projekt mora biti potrjen s strani matične banke. Da neka naloga postane projekt, mora zadostovati naslednjim pogojem:

• Trajanje izvajanja naloge je več kot 2 meseca • Planirana aktivnost na projektu je ocenjena na najmanj 75 človek dni1 • Planiran proračun projekta je večji kot 30.000,00 EUR ne upoštevajoč stroškov

dela zaposlenih, oziroma planirano delo več kot 150 človek dni • V projekt morata biti vključena vsaj dva različna področja oz službi • V enem področju ne sme biti več kot 80% dela na nalogi

Neka naloga mora, če hoče postati projekt zadostovati zgornjim kriterijem in mora biti potrjena s strani avtorizacijskega telesa, ki je ali t.i. Portfolio Steering Committee ali pa s strani uprave banke. Vsak projekt mora imeti določen:

• začetek in konec • vodjo projekta in projektnega sponzorja • področje reševanja oz namen • člane • proračun

Znotraj projekta morajo nastati sledeči dokumenti:

• Projektni zahtevek/naloga • Business case • Projektna knjiga • Projektna poročila

Projektni zahtevek/naloga: Ta dokument vsebuje kratek opis naloge, katero nameravamo izvesti. V primeru, da je naloga obsežnejša je lahko razdeljena tudi na vrsto manjših nalog Business case: Izvedena je analiza naloge s finančnega vidika. S tem dokumentom se upravi oz. steering committee –ju predstavi vsako nalogo tudi v finančnem smislu, iz česar je razvidno v kolikšnem času se bo predvidoma vložek v projekt povrnil. Ta podatek zelo olajša odločitev o sprejetju projekta. To pomeni da mora biti dokument pripravljen z vso vestnostjo.

1 Človek dan = 8 delavnih ur



Projektna knjiga: Ta dokument vsebuje vse podatke o projektu. V njej mora biti projekt razčlenjen na posamezne faze. Faze so razčlenjene na manjše delavne naloge. Delavne naloge je tako lažje spremljati in ovrednotiti. V projektni knjigi so zapisani tudi vsi člani projekta in njihove naloge z vsemi terminskimi plani. Zaradi nepoznavanja vseh dejavnikov, je v projektu potrebno določiti več mejnikov(angleško mile stone). Te mejniki služijo pregledu in oceni poteka projekta. Mejniki so določeni že v pripravljalni fazi projekta in opisani v projektni knjigi. Mejnike se navadno postavi ob zaključku posameznih faz. Na vsakem mejniku se pogleda in oceni potek projekta, katerega se lahko na podlagi izsledkov korigira. Zaradi teh sprotnih korektur se projektna knjiga skozi cel projekt stalno vzdržuje in dopolnjuje. Dostop do projektne knjige morajo imeti vsi vpleteni v projekt. V projektni knjigi so opisani tudi protokoli komuniciranja, celotna projektna organizacija z vsemi člani, sredstvi in nalogami. Določeni so tudi vsi datumi, katere lahko glede na potek projekta tudi spreminjamo. Nujno mora projektna knjiga vsebovati datum začetka in konca projekta, kot tudi datume vseh mejnikov in sestankov. Ta dokument je zelo pomemben za učinkovito izvedbo projekta. Projektna poročila: V projektu sta nujni vsaj dve vrsti poročil. To sta

• Poročilo o trenutnem stanju. S tem poročilom se predstavi sponzorju projekta trenutno stanje projekta. V poročilu naj bi bile navedene končane naloge, težave na katere se je naletelo med izvajanjem teh nalog, ter razlogi za morebitna odstopanja od posameznih ciljev nalog. S temi poročili lahko tako vodja projekta kot tudi sponzor projekta pravočasno ukrepata v primeru težav.

• Poročilo o zaključku projekta: To poročilo ob koncu projekta izdela vodja projekta ter ga predstavi na zaključnem sestanku. S tem poročilom se projekt uradno zaključi, projektni izdelek pa preda v uporabo. Poročilo mora vsebovati dosežene cilje, spremembe oz odstopanja od načrtovanih ciljev. Navedeni morajo biti tudi razlogi za to. Vsebovati mora tudi informacijo o porabi sredstev. V primeru prekoračitev sredstev morajo biti navedeni razlogi za to. Pod poročilo se podpišejo vodja projekta, sponzor kot tudi vsi člani Portfolio Steering Committee. S pridobitvijo teh podpisov se projekt formalno tudi konča.



3. OBSTOJEČE STANJE

3.1. Posnetek stanja

Do prehoda na On-line avtorizacijo, je kot že rečeno v točki 1.2 za nas avtorizacijo izvajalo podjetje Bankart. Podjetje Bankart je eden izmed štirih procesnih centrov kartičnega poslovanja na področju Slovenije in kot tak vključen v Evropski plačilni sistem. Ima svoji blagovni znamki BA in Karanta, kateri sta del sistema Maestro Cirrus debetnih kartic. Poleg tega pa je Bankart vključen tudi v mednarodni sistem kreditnih kartic MasterCard in VISA. Bankart kot upravljavec sistema poravnave kartic in klirinški agent, skrbi za nemoteno delovanje sistemov plačilnih kartic na področju Slovenije. Kot upravljavec celotnega sistema ima razvito programsko opremo za spremljanje plačilnih zahtevkov in po potrebi tudi za avtoriziranje le teh. Z to programsko oprem je do sedaj za nas izvajal avtorizacijo poslanih plačilnih zahtevkov preko bankomatov oziroma POS terminalov. Za zagotavljanje neprekinjenega delovanja sistema, v Bankartu vodijo svojo bazo stanj na računih. Njihova baza stanj upošteva vse dvige na bankomatih in POS terminalih. Poleg tega vodi tudi evidenco o dnevnih dvigih. Na podlagi te evidence odobrava oz. zavrača zahtevke za avtorizacijo. Komitent lahko med drugim plačuje tudi preko spletne banke oziroma preko bančnega okenca. Taka plačila niso del Bankartovega sistema, zato moramo te informacije pošiljati na Bankart. Le tako taka plačila lahko upoštevajo pri samem stanju računa. Te informacije pošiljamo enkrat na uro vsak dan med 6:00 in 23:00. Bankart pa pošlje informacijo o bankomatskem prometu enkrat dnevno za en dan nazaj. S pomočjo te datoteke v bankah prjmemo informacijo za knjiženje vseh avtoriziranih zahtevkov. Poleg te datoteke Bankart pripravi še vrsto drugih datotek, ki potem postanejo podlaga za knjiženje in vodenje raznoraznih statistik. Do zaključka projekta je celoten dvig denarja na bankomatu oziroma plačilo preko POS terminala potekal na spodaj opisan način:

1. V bankomat oziroma POS terminal vstavimo plačilno kartico 2. Bankomat od nas zahteva da vpišemo svojo PIN kodo, ki je poznana samo

nam in jo preko bankomata lahko po želji tudi zamenjamo. POS terminal od prodajalca zahteva da vpiše znesek plačila

3. V primeru da smo vpisali pravilno pin kodo bo bankomat od nas zahteval da izberemo način izbire želene vsote za dvig. POS terminal bo v tej točki od nas zahteval vnos PIN kode

4. Izbrana naprava združi informacijo o znesku, številki računa in PIN kodo ter veljavnost kartice v datoteko katerega kriptera in podpiše.

5. Tako obdelan paket pošlje preko SNA protokola po Frame relay najeti liniji do procesnega centra ki skrbi za izbrani bankomat oziroma POS terminal. V Sloveniji imamo štiri procesne centre. To so poleg Bankarta še Banka Koper, Plasis in Visa

6. Procesni center s svojo programsko opremo prepozna vrsto zahtevka (BA, VISA, MasterCard…). V primeru da zahtevek ni poslan temu procesnemu centru celoten zahtevek pošlje na procesni center ki je zadolžen za tak tip avtorizacije, drugače da zahtevek v obdelavo.

7. Če gre torej v našem primeru za zahtevek namenjen BA Maestro sistemu, potem na Bankartu preverijo "osnovne" parametre kartice kot so kontrola



številke kartice,njene veljavnosti, pravilnost PINa ter ali so dnevni limiti oziroma limiti posameznih transakcij v dogovorjenih okvirih.

8. Če so vse te kontrole v redu potem gre celoten paket v avtorizacijo, kjer se preveri stanje samega računa lastnika kartice. Preveri se status računa ki je lahko zaprt, blokiran ali pa veljaven. Poleg tega se preverja stanje na računu če je v dovoljenih okvirih po izplačilu zahtevanega zneska. Dovoljen okvir pomeni dejansko stanje plus dovoljen limit.

9. Izdajatelj kartice v določenih časovnih intervalih pošilja spremembe na transakcijskih računih zaradi čim bolj ažurnega stanja na posameznem transakcijskem računu.

10. Po preverjanju v točki h se zahtevek avtorizira oz. zavrne. V primeru da se zahtevek avtorizira in da je bil poslan iz POS terminala zmanjša razpoložljivo stanje na transakcijskem računu. Obenem se zmanjša tudi prikazano stanje na bankomatu. Poleg tega se za avtoriziran znesek zmanjša dnevni limit. Ob vsem tem se pripravi nov paket z informacijo da je zahtevek avtoriziran.V primeru da se avtorizira zahtevek poslan iz bankomata pa se v tem koraku pripravi samo paket z informacijo da je zahtevek avtoriziran.

11. Paket iz točke j se kodira in podpiše, ter pošlje nazaj na napravo, kjer je vstavljena plačilna kartica.

12. Na POS terminalu je transakcija s tem zaključena vendar pa še ni knjižena. Na bankomatu se v tej točki izroči denar. Po prevzemu denarja se šteje da je transakcija opravljena in se lahko zmanjša razpoložljivo stanje na računu. Nato se zmanjša prikazano stanje na bankomatu in dnevni limit.

13. Vsak delovni dan se zvečer sproži obdelava na Bankartu v kateri se pripravi datoteke z informacijami o prometu na bankomatih v lasti banke, o prometu bančnih komitentov, o prodaji gsm kartic in podobnimi informacijami katere dobimo iz tega sistema. Datoteke se odložijo na vnaprej ogovorjeno mesto z vnaprej dogovorjenim imenom od koder jih posamezne banke pobiramo za potrebe knjiženja, kontrole in usklajevanja stanja.

14. Po prejemu potrebnih datotek iz Bankarta in uvozu v program Hibis se izvedene transakcije dejansko zaključijo.

Celoten potek dviga preko bankomata oz. POS terminala si lahko ogledamo na procesu kateri je podan na sliki Slika 3



Slika 3: Potek dviga preko bankomata oz. POS terminala (Vir: lasten)



Na sliki (Slika 4) lahko pogledamo celoten sistem plačilnega prometa v HBS, kot smo ga uporabljali do prehoda na on line avtorizacijo v HBS.

Poslovanje preko bančnega okenca

Strežniki za sistem HIBIS in izmenjavo podatkov

Hyponet preko interneta

Internet

Zahteva za

izplačilo in

avtorizacija

Zahteva za izplačilo in avtorizacija

Zahteva za izplačilo in

avtorizacija

Info

rmac

ije o

pro

met

u ko

mite

ntov

na

bank

omat

ih in

PO

S

term

inal

ih

Stan

je n

a raču

nu b

rez

upoš

teva

ne p

orab

e na

ATM

ali

POS

Slika 4: Sistem plačilnega prometa v HBS do danes (Vir: lasten)

Na zgornji sliki vidimo, da je podjetje Bankart,do prehoda na On line avtorizacijo v HBS, za nas avtoriziral plačilne zahtevke podane preko bankomatov oz POS terminalov. Za ta namen je uporabljal aplikacijo BSE. Zaradi tega smo v HBS tako šele naslednji delovni dan prejeli datoteke z podatki o knjiženih transakcijah in s tem posodobili pravo stanje na računu komitentov. Zaradi tega smo vedno z enodnevno



zamudo uskladili stanje na računu komitenta s stanjem, prikazanem na bankomatu. Posledica tega je bila, da je komitent v HypoNetu, ki je naša spletna banka, le redko videl stanje, kot ga je videl na bankomatu. Na račun tega je bilo veliko vprašanj in pripomb s strani komitentov. Za povezavo med HBS in Bankartom smo uporabljali kompleksno mrežno infrastrukturo. Kompleksna je bila predvsem zaradi sočasne uporabe dveh protokolov in sicer TCP/IP in SNA. Ta povezava je bila postavljena tako, da smo imeli v prostorih Bankarta svoj usmerjevalnik, s katerim smo bili povezani preko najete linije z x25 povezavo in uporabo TCP/IP protokola. Naš usmerjevalnik je bil povezan naprej z Bankartovim usmerjevalnikom preko posebnih vrat. Usmerjevalnik je tako TCP/IP promet prevajal v SNA protokol. Poleg tega sta bila naša usmerjevalnika povezana tudi preko rezervne ISDN povezave, katera bi se vklopila v primeru težav z najeto x25 linijo. Celotno povezavo smo imeli podvojeno v našem centru rezervnih zmogljivosti. Slednja bi se vklopila v primeru odpovedi katerega koli dela na primarni strani naše banke. Povezava je prikazana na sliki (Slika 5).

Slika 5: Izvedba mrežne povezave med HBS in Bankartom (Vir: lasten)

3.2. Analiza razlogov za spremembo načina avtorizacije

Zaradi zmanjšanja izpostavljenosti tveganja pri vodenju osebnih računov naših komitentov, smo pristopili k selitvi procesa avtorizacije na našo banko. Poleg tega smo z posodobitvijo našega informacijskega sistema zagotovili tehnične možnosti za takšen prehod. Pred to posodobitvijo bi se nam zaradi preobremenjenosti sistema lahko zgodilo, da bi kakšen zahtevek za avtorizacijo obdelali izven predvidenega časovnega limita. Časovni limit za avtoriziranje zahtevka je določen na maksimalno 15 s. S prekoračitvijo časovnega limita bi povzročili slabo voljo pri uporabnikih, katerim bi se ta zakasnitev odražala z zavrnitvijo avtorizacije plačila. Z uvedbo avtorizacije na HBS bomo lahko poenotili tudi prikaz stanja na računu na bankomatu s stanjem v spletni banki. Poleg tega bomo zmanjšali tudi stroške kateri nastajajo s samo avtorizacijo v podjetju Bankart. Zaradi pomembnosti te selitve in



sodelovanjem več področji naše banke ter zunanjimi izvajalci smo se v HBS odločili, da se bo celotna migracija vodila kot projekt. Selitev sistema avtorizacije izpolnjuje vse pogoje za to (glej izvajanje projektov v HBS poglavje 2.3 v tem dokumentu). V projektu se bo razvil sistem za On line avtorizacijo zahtevkov poslanih iz bankomatov in POS terminalov. Kot del tega sistema se bo razvil program, ki bo tekel kot servis in bo skrbel za prenos avtorizacijskih zahtevkov. Program bo skrbel za prenos med našo programsko opremo HIBIS in bankomatom oziroma POS terminalom. Poleg tega bo potrebno predelati tudi strani za prikaz stanja v naši spletni banki. V projektu se bo izdelalo navodilo za ravnanje v primeru izpada avtorizacijskega sistema. Do izpada avtorizacijskega sistema bo lahko prišlo zaradi tehničnih težav na katerem koli od vpletenih sistemov. Do prekinitev bo prihajalo tudi ob nadgradnji oziroma vzdrževanju sistemov. Splošna praksa na Bankartu je, da se takšna vzdrževanja v naprej napove. V času ne operativnosti avtorizacijskega sistema na HBS, le tega prevzame Bankart. Po končani prekinitvi se avtorizacijski sistem zopet preseli na HBS. Po končani prekinitvi se iz Bankarta pošlje datoteko za posodobitev stanja na računih v programu HIBIS. V okviru projekta bomo spremenili tudi način povezave med HBS in Bankartom. S to spremembo bomo pocenili in pohitrili fizično povezavo, saj se bomo znebili prevajanja med TCP/IP in SNA protokolom. Z uspešnim prenosom projekta v produkcijo, bomo pripravili tudi vse potrebno za razvoj podobnih produktov na ostalih bančnih področjih. Razvili bomo lahko nove produkte, kot je na primer obveščanje o stanju na računu preko SMS ali e-pošte. To nam bo pomagalo ohraniti oziroma izboljšati zadovoljstvo strank, ki postajajo iz leta v leto zahtevnejše. Seveda se bodo z vpeljavo tega projekta pojavile tudi nove zahteve. Tem zahtevam se bomo v samem projektu poizkušali prilagoditi, oziroma se nanje kar najbolje pripraviti. Med te zahteve štejemo potrebo po neprekinjenem delovanju in predhodnem obveščanju Bankarta o predvidenih izpadih. Tako bomo morali ob vsaki nadgradnji ali vzdrževanju podatkovne baze, oziroma kakršne koli druge načrtovane prekinitve usklajevati z Bankartom. Ena izmed pomanjkljivosti tega projekta je kar visok finančni vložek v programsko opremo. S tem prehodom se nam bodo pojavile tudi dodatne grožnje, kot so razne okvare na katerem koli sistemu vpletenem v samo avtorizacijo, za katere nam do sedaj ni bilo potrebno skrbeti. V nadaljevanju je prikazana S.W.O.T. analiza celotnega projekta.



S.W.O.T. analiza projekta Vpeljava OnLine

Slika 6: S.W.O.T. analiza (Vir: lasten)



4. ZASNOVA PROJEKTA PRENOVE

Analiza je pokazala nujnost spremembe načina avtoriziranja plačilnih zahtevkov poslanih iz bankomatov ter POS terminalov. Pri pripravah na izvedbo spremembe, se je pokazalo, da se bo celoten postopek najkvalitetnejše izvedel, če pristopimo k projektnemu reševanju problema. Naloga izpolnjuje vse dane kriterije za izvedbo projekta. Tako se je v prvi polovici leta 2008 izdelal projektni predlog, ki je bil potrjen s strani projektne pisarne v naši matični banki v Avstriji.

4.1. Projektni zahtevek

V projektu On line avtorizacije bankomatskih in POS transakcij v HBS se bo reševala problematika selitve sistema avtorizacije iz Bankarta na HBS. Sam projekt se bo zaradi kompleksnosti delil na več faz. Z uspešno izvedbo projekta bomo dosegli naslednje cilje:

• Zmanjšanje tveganja pri poslovanju s fizičnimi osebami • Vzpostavitev pravega evidenčnega stanja na partiji komitenta tudi znotraj

HBS in ne samo na Bankartu • Pocenitev procesa avtorizacije za provizijo, katero smo do sedaj plačevali

podjetju Bankart. • Prikaz celotnega prometa na naši e-banki " HypoNet" v realnem času. • Priprava sistema za razvoj novih produktov (uvedba debetnih kartic za

podjetja, obveščanje komitentov preko SMS,… ) • Ostati konkurenčni in s tem slediti naši viziji, priti med prvih pet najboljših

bank v Sloveniji.

Za zagotovitev zgoraj naštetih ciljev je potrebno problematiko razčleniti na več faz. Faze v tem projektu so:

• Izdelava vmesnika, ki služi povezavi med Bankartovo aplikacijo BSE in našo aplikacijo HIBIS

• Izvedba mrežne povezave med Bankartom in HBS preko MPLS omrežja • Priprava programa HIBIS za prevzem datotek "Positive Balance File" (v

nadaljevanju PBF), • Knjiženje tako imenovanih ATM datotek, ki služijo za knjiženje potrjenih

avtoriziranih zahtevkov • Priprava postopka za brisanje evidenčnih knjižb starejših od 8 dni • Dodelava spletne aplikacije HypoNet za prikaz evidenčnega in

knjigovodskega stanja • Priprava navodil za zaposlene • Izvedba globalnega testiranja • Prehod v produkcijo



4.2. Business case

V tej točki bo opisana priprava poslovnega načrta (angleško Business case) za projekt "Vpeljava On line avtorizacij bankomatskih in POS transakcij v HBS". V HBS se poslovni načrt za posamezne projekte obvezno pripravlja s pomočjo posebnega Excelovega obrazca. Predloga obrazca je pripravljena v projektni pisarni naše matične banke in dopolnjena z nacionalnimi specifikami vsake banke članice. Uporablja se ga v celotni skupini Hypo group Alpe Adria. Obrazec izpolni predlagatelj projekta, s pomočjo lokalne projektne pisarne. Izpolnjen obrazec je obvezen za odobritev projekta. V nadaljevanju si poglejmo pripravljen poslovni načrt obravnavanega projekta. Del obrazca je v angleškem jeziku, zaradi enotne uporabe terminologije v celotni grupi. V obrazcu so vsi finančni podatki samo nakazani zaradi poslovne skrivnosti. Prva stran poslovnega načrta je Skupni pregled projekta (Tabela 1). To je kratek povzetek celotnega poslovnega načrta. Namenjena je hitremu pregledu najpomembnejših podatkov pri potrjevanju projekta. Prikazani podatki se pripravijo v tabelah, ki so tudi del poslovnega načrta. Te tabele se nahajajo na za njih pripravljenih listih, tako da so podatki sistematično ločeni med seboj. V tej diplomski nalogi so podatki iz tabel samo opisani. Glede na to, da so finančni podatki namerno izpuščeni, je od predpisanega excelovega dokumenta prikazana samo prva stran zaradi lažje predstave (Tabela 1). Poleg prikazanega prvega lista je v tem dokumentu še dvanajst listov. Listi v dokumentu se imenujejo:

• Skupni pregled • Projektni stroški • Operativni str., inv.- trenutno • Operativni str., inv.- novo • Projektne koristi • Denarni tok • Notes • Parametri • Project Assasment Overview • Risk • Qualitative benefit • Project Importance • Required finalisation

Prikazana stran (Tabela 1) je sestavljena iz pripravljenih podatkov na listih Skupni pregled, Projektni stroški, Projektne koristi, Denarni tok, Parametri, Project, Assasment Overview, Risk, Qualitative benefit, Project Importance. Ostali listi služijo za različne izračune , potrebne za pripravo podatkov. Podatki v teh tabelah so vneseni v projektni pisarni in so enotni v celotni grupi.



Tabela 1: Poslovni načrt - Skupni pregled (Vir: Predloga Hypo business case03.xls)



Na drugem listu, imenovanem "Projektni stroški" se nahaja tabela, v kateri se vpišejo vsi planirani stroški projekta. Stroški se delijo na tri skupine in sicer na:

• Stroške internih virov • Administrativne stroške,IT stroške in ostale stroške • Investicije V prvo skupino smo vpisali predvideno delo projektnih članov, zaposlenih v HBS. Stroške smo predvideli tako za leto 2008, kot tudi za leto 2009. V tabeli se je določil tudi strošek zaposlenega, izraženega v vrednosti človek dan. V drugi skupini smo upoštevali stroške kot so na primer reklamni material, obvestila strankam in podobno. Tudi te stroške smo razdelili na predvidene stroške v letu 2008 in 2009. V tretjo skupino smo zajeli stroške investicij. Ravno tako kot v prejšnji dve skupini, smo jih razdelili na leto 2008 in 2009. Med investicije smo uvrstili vse nakupe potrebne strojne opreme, programske opreme, stroške programiranja pri zunanjih izvajalcih, ter nakup potrebnih licenc. Sama tabela je narejena tako, da s pomočjo makra preračuna vnesene stroške in jih razporedi po tipih in času. Tako obdelani podatki se nato prikažejo v skupnem pregledu na prvi strani dokumenta. Prikažejo se v delu "Projektni stroški in investicije v €". Te podatki se uporabijo tudi za izračune v tabeli "Denarni tok" na istoimenskem listu.

V tabeli na listu "Operativni stroški in investicije-trenutno" smo prikazali, koliko nas stane avtorizacija zahtevkov bankomatskih in POS transakcij pred uvedbo projektnega cilja. Tudi ta tabela je razvrščena na tri skupine, podobno kot prejšnja. Te skupine so:

• Stroški internih virov • Administrativni stroški,IT stroški in ostali stroški • Investicije

V prvo skupino nismo vpisali ničesar , saj so do zaključka tega projekta avtorizacijo izvajali v podjetju Bankart. V drugi skupini so se upoštevali stroški najema x25 povezave, ter provizije, katere plačujemo podjetju Bankart, za izvajanje avtorizacije. Trenutno dosedanji sistem ni imel nobenih investicij, saj je bil že več let postavljen. Zaradi tega smo tudi ta del pustili prazen. Te podatki se ne pokažejo na prvem listu. Vsaj ne direktno, saj služijo za pripravo podatkov v tabeli "Projektne koristi". Na listu "Operativni str., inv.- novo se nahaja tabela z planiranimi operativnimi stroški, nastalimi po zaključku projekta. Tudi te stroški so ločeni po enakih skupinah, kot na prejšnjih dveh listih. Zaradi tega projekta se bodo pojavili stroški najema MPLS linije, kar smo zavedli med IT stroške v skupini "Administrativni stroški, IT stroški in ostali stroški". Ostalih stroškov nastalih zaradi uvedbe projekta nismo predvideli. Podatki iz te tabele se ravno tako, kot iz prejšnje ne prikazujejo na prvi strani dokumenta, ampak služijo za pripravo podatkov v tabeli "Projektne koristi".



Na petem listu, imenovanem "Projektne koristi", se nahaja tabela, katera zajema podatke iz prejšnjih dveh tabel. Poleg teh podatkov, se v to tabelo lahko vpiše tudi informacijo o provizijah, rezultatih trgovanja, svetovanju ipd. Podatki iz te tabele se prikazujejo na prvi strani dokumenta, saj so pomembni pri potrjevanju projekta.. Na naslednjih štirih listih, so podatki vneseni v projektni pisarni, oziroma se izračunajo iz ostalih tabel. Na te liste sami ne vnašamo ničesar. Podatki služijo kot konstante, za razne izračune in prikaze v ostalih tabelah. Te listi se imenujejo "Denarni tok", "Parametri" in "Project Assasment Overview". V tabeli "denarni tok" se pripravi podatke dobljene v tabeli "Projektne koristi". Tako pripravljene podatke se prikaže v tabeli na prvem listu dokumenta. Poleg tega te podatki služijo za izris grafa prikazanega na prvem listu. Na listu "parametri" so razne konstante, spiski oddelkov, ter drugi opisi, kateri služijo za izdelavo spustnih oken v tem delavnem zvezku. Na listu "Project Assasment Overview" se zbirajo podatki, kateri služijo za kvalitativni prikaz na prvi strani, v razdelkih "Risk", Qualitative benefit" in "Project Importance". Na listu "Risk" se v tabelo vpisujejo pred nastavljene vrednosti za oceno tveganosti projekta. Z vnosom pred nastavljenih vrednosti v polja, se na koncu dobi kvalitativno oceno tveganja. Pri oceni tveganja se ocenjuje

• Trajanje projekta • Življenjski cikel uporabe rezultatov projekta • Število uporabnikov na katere bo imel projekt kakršen koli vpliv • Število oddelkov vpletenih v izvedbo projekta • Ocena koristi in stroškov • Razpoložljivost projektnih članov • Poznavanje tehnologije in izkušenost projektnih članov • Izkušenost projektnega vodje • Število zunanjih svetovalcev pri vodenju projekta • Število primerljivih projektov • Zunanji vplivi na projekt, kot so razni zakoni, konkurenca ipd. • Notranji vplivi, kot so drugi projekti znotraj banke • Vpliv projekta na banko v primeru neuspeha

V našem primeru je bil projekt ocenjen kot rizičen. Ta ocena je bila podana predvsem zaradi velikega števila uporabnikov, na katere bo imel projekt vpliv, ter zaradi dolge življenjske dobe projektnega izdelka. Na listu "Qualitative benefit" se poda pred nastavljene ocene o koristnosti projekta. V tabeli so podatki razdeljeni v tri grupe. Te grupe so

• Business strategies • Other benefits • IT-architecture

Omenjene grupe so sestavljene iz podgrup z različnimi vplivi. V tabeli se izbira med tremi različnimi vrstami vpliva, direktni, indirektni in brez vpliva. Na koncu se dobi s



pomočjo uteži kvalitativno oceno koristnosti projekta. V našem primeru je bil projekt ocenjen z oceno "zelo visoka korist".

Na listu "Project importance", v pripravljeno tabelo podamo številsko oceno petim kategorijam, prikazanim na prvi strani delovnega zvezka. V odvisnosti od ocene, se doda tudi kvalitativni opis vpliva projekta na posamezno kategorijo. Ocenjevane kategorije so:

• Vpliv na stranke • Skladnost s poslovanjem • Usklajenost s strategijo • Usklajenost z IT arhitekturo • Strateški potencial

Na zadnjem listu "Required finalisation" se poda številsko oceno obdobja v katerem naj bi bil projekt končan. Ta ocena služi projektni pisarni za lažjo časovno uskladitev projektov.

4.3. Projektna knjiga

Projektna knjiga se vodi v programu Daptiv, ki je potrjen s strani projektne pisarne. Program Daptiv je spletna aplikacija, tako da ga lahko uporabljamo v celotni grupi. Projektno knjigo vodi vodja projekta , ki tudi skrbi, da so podatki v njej sproti posodabljanji in dostopni vsem članom projekta, sponzorju, upravi in projektni pisarni. Sam projekt se zaradi lažjega obvladovanja projekta v projektni knjigi razdeli na več delavnih nalog. V knjigi so tudi določeni mejniki. Z uporabo mejnikov tako lažje že kar med izvajanjem projekta zaznamo možne težave. Na te težave se tako lažje še pravočasno odzovemo in se s tem izognemo morebitnim zamudam in z zamudami povezanim dodatnim stroškom. Vsaki nalogi so dodeljeni tudi člani projekta, z točno določenimi časovnimi okviri končanja posamične naloge. Vsaka projektna knjiga mora vsebovati tudi vse planirane stroške, materialna sredstva in trajanje projekta. Tudi naša projektna knjiga tako ni nobena izjema. Projekt Vpeljava OnLine avtorizacij bankomatskih in POS transakcij v Hypo Alpe-Adria bank d.d. je tako razdeljen na sledeče delavne naloge:

• Izgradnja vmesnika MiniBIC ISO • Postavitev mrežne povezave HBS-Bankart • Izdelava PBF(Possitive Balance File) • Prvo testiranje • Knjiženje evidenčnega prometa • Knjiženje ATM data • Brisanje evidenčnih knjižb po 8 dneh • Prikaz prometa na Hyponet-u • Izdelava navodil • Globalno testiranje • Prehod v produkcijo



4.3.1. Izgradnja vmesnika MiniBIC ISO

Zaradi uporabe različnih programov v naši in partnerski organizaciji, kateri tečejo tudi na različnih operacijskih sistemih, je potrebno izdelati odgovarjajoč vmesnik. Vmesnik bo skrbel za izmenjava podatkov med Bankartiovo aplikacijo BSE in Hibisom. Osnovo vmesnika imenovanim MiniBIC ISO so razvili strokovnjaki v podjetju Bankart. Zaradi uporabe vmesnika na različnih platformah, je le ta napisan v programskem jeziku C++. Jezik C++ je eden bolj uporabljanih jezikov med programerji v slovenskem prostoru. Tak skelet vmesnika vsaka banka dodela po svoje, tako da se podatki izmenjujejo direktno iz za to določenih tabel. S tem se dobi potrebno odzivnost pri sami avtorizaciji, saj ni potrebno čakati na tako imenovane prožilce (trigerje). Za nas bodo ta vmesnik dodelali v podjetju HRC, kjer so program HIBIS tudi razvili. Funkcijske specifikacije za izdelavo tega vmesnika ni bilo potrebno napisati, saj je v sami kodi opisan celoten postopek. Na naslednji sliki (Slika 7) si lahko pogledamo umestitev vmesnika MiniBIC ISO v nov avtorizacijski model.

Slika 7:Umestitev vmesnika MiniBIC ISO (Vir: lasten)

4.3.2. Postavitev mrežne povezave HBS-Bankart

Za samo vpeljavo OnLine avtorizacije bi sicer lahko izkoriščali dosedanjo povezavo med HBS in Bankartom. Verjetno jo na samem začetku tudi bomo, saj je MPLS oblak za enkrat postavljen samo za SEPA plačilni promet. Vendar bomo povezavo preselili takoj, ko bo to mogoče. Povezava bo na celotni poti potekala po tcp/ip protokolu v privatnem omrežju , katerega je Bankart s svojim partnerjem postavil v ta namen. S tem bo zagotovljen varen prenos datotek, na nivoju, kot ga nudi povezava točka točka.(podroben opis te povezave je vpisan v točki 2.1). Za vzpostavitev delovanja je potrebno povezati strežnik na katerem bo tekel vmesnik miniBiC ISO v HBS s Bankartovin strežnikom na katerem teče avtorizacijski program BSE. Za samo povezavo moramo tako pri nas, kot tudi na Bankartu izvesti preslikavo mrežnih naslovov (NAT). Preslikavo bomo izvedli na požarnih pregradah. Preslikava mrežnih naslovov (IP naslovi) je potrebna, saj imata notranja LAN omrežja obeh podjetji različne naslovne prostore. Poleg tega bo potrebno na požarni pregradi odpreti za ta promet določena vrata (porte), katera se lahko po potrebi in



predhodnem dogovoru tudi spremeni. Nastavitve povezave bo potrebno nastavljati v obeh podjetjih istočasno zaradi lažjega usklajevanja in odpravljanja morebitnih težav. Pri nastavljanju mora sodelovati tudi skrbnik MPLS omrežja.

Slika 8: Shema povezave (Vir: lasten)

4.3.3. Izdelava PBF datoteke

PBF (Positive Balance File) je datoteka, katero pripravlja vsaka avtorizacijska hiša, v našem primeru mi. Mi torej PBF datoteko, v vnaprej dogovorjenih intervalih pošiljamo v procesni center, se pravi Bankart. Ta datoteka služi za primer izpada katerega koli dela avtorizacijskega sistema v avtorizacijski hiši. Celoten sistem je zgrajen tako, da se v primeru neodzivnosti avtorizacijskega sistema sam preklopi na procesni center. Avtorizacijski sistem jse smatra kot neodziven, če za avtorizacijo potrebuje več kot 15 sekund. V Bankartu program BSE uporabi za preverjanje stanja na računu pošiljatelja zahtevka zadnjo prejeto PBF datoteko. Po ponovni vzpostavitvi avtorizacije v avtorizacijski hiši, Bankart pošlje datoteko z informacijami o vseh avtorizacijah, ki so nastale v času neaktivnosti. S to datoteko se v avtorizacijski hiši uskladi stanje z Bankartovim. V HBS PBF datoteko pripravljamo večkrat dnevno in sicer vsako uro, z začetkom ob 7:00. Zadnjo datoteko pošljemo ob 23:00. Datoteka mora biti pripravljena v predpisanem formatu. Pošlje se jo s programom ConnectDirect. V tem programu je pripravljen tako imenovan proces, ki odloži PBF datoteko na odgovarjajočo mapo. Tam jo program BSE prevzame in obdela. Program Connect Direct se v našem primeru uporablja zaradi uporabe različnih operacijskih sistemov. Za kontrolo nam avtorizacijski program čez 15 minut pripravi potrditveno datoteko. To datoteko prevzamemo z drugim procesom v ConnectDirectu, katero odloži v mapo, od koder jo program HIBIS uvozi. V samem HIBISu se avtomatsko izvrši analiza prejete datoteke. V primeru razhajanja katerega koli podatka, program HIBIS poskrbi za obveščanje skrbnikov sistema. V primeru pojava napake, skrbniki po odpravi vzroka datoteko ponovno pripravijo in pošljejo na Bankart.

4.3.4. Prvo testiranje

Po zaključku prvih treh faz bomo izvedli prvo testiranje. Prvi test je namenjen infrastrukturi, se pravi sami fizični povezavi, vmesniku MiniBIC ISO in ostali infrastrukturi na strani banke. Test je pripravljen in izveden na način, da Bankart pošlje v avtorizacijo veliko število zahtevkov v kratkih časovnih intervalih. V Bankartu nato z zato pripravljeno aplikacijo merijo čas posamezne avtorizacije in iz dobljenih rezultatov izračunajo povprečni čas avtorizacije. Na strani banke se med



tem meri obremenjenost celotnega sistema. Med testom je tako poslano nekajkrat več zahtevkov, kot jih je realno lahko pričakovati. Sistem se potrdi kot primeren, ko zadosti pogoju, da povprečni čas avtorizacije ne presega 15 sekund. V testu se preizkuša celotna "trasa" od avtorizacijskega programa na Bankartu, kjer so testni zahtevki tudi generirani, preko celotne omrežne opreme, vmesnika MiniBIC ISO do avtorizacijskega modula v HIBIS-u. V test ni zajeta izmenjava podatkov za knjiženje, izmenjava PBF datotek niti prikaz podatkov v e-banki. Vse ostale funkcionalnosti sistema se bodo testirale v končnem integralnem testiranju.

4.3.5. Knjiženje evidenčnega prometa

Na strani HBS je potrebno dopolniti modul Transakcijskih računov. Dopolnjen modul mora biti sposoben voditi in prikazovati tudi evidenčni promet in ne samo knjiženo stanje. Do sedaj se je namreč dogajalo, da je prikazano stanje na bankomatu odstopalo od stanja na bančnem okencu, oziroma stanju prikazanem v e-banki. Razvoj tega modula je tudi eden od vzrokov, da je banka sploh pristopila k projektu. Banka je kot že rečeno na račun te razlike prejela kar nekaj pripomb. Rešitev tega problema je možna na način, da se za vsak račun fizične osebe vodi knjiženo stanje, kot se ga je vodilo do sedaj, poleg pa se doda še evidenčno stanje. V evidenčnem stanju so upoštevani tudi vsi dvigi na bankomatu in plačila na POS terminalih, še preden se jih poknjiži na podlagi ATM datoteke. ATM datoteko se prejme šele naslednji delovni dan. Z prikazom evidenčnega stanja, se le ta izenači stanju prikazanem na Bankomatih. Te funkcionalnosti ne moremo zagotoviti drugače kot s selitvijo avtorizacijskega sistema v našo banko.

4.3.6. Knjiženje ATM data

Praviloma, naslednji delovni dan dobimo iz avtorizacijskega programa na Bankartu tako imenovano ATM Data datoteko. To datoteko prevzamemo v obliki tekstovne datoteke. Datoteka se v podjetju Bankart izdela vsak dan, razen Nedelje in praznikov. Prevzame se jo s pomočjo programa ConnectDirect. Prevzeto datoteko se odloži v mapo za prevzem. Program HIBIS jo nato uvozi. Na podlagi uvoženih informacij se evidenčno stanje spremeni v knjiženo. V tem procesu se na podlagi podatkov iz ATM datoteke, sredstva tudi nakaže na račun lastnika bankomata oziroma POS terminala. Ta način se je uporabljal tudi v preteklosti. Zaradi tega je treba v HIBIS-u dodelati samo še funkcijo za spremembo statusa prometa iz evidenčnega v knjiženega.

4.3.7. Brisanje evidenčnih knjižb po 8 dneh

Po opravljeni avtorizaciji na bankomatu oz. POS terminalu je lastnik bankomata oz POS terminala dolžan v 8 dneh poslati zahtevek za plačilo procesnemu centru. Bankart, kot naš procesni center, pripravi v prejšnji točki omenjeno ATM data datoteko. S pomočjo te datoteke se izvede plačilo lastniku bankomata oz POS terminala. Včasih se zgodi, da iz kakršnega koli razloga, lastnik bankomata oz POS terminala ne pošlje zahtevka za plačilo v dogovorjenem roku. V takem primeru avtomatsko zapade pravica za poplačilo terjatve. V programu HIBIS moramo tako zagotoviti, da se vse transakcije starejše od 8 dni brišejo iz evidenčnega stanja. S tem se zagotovi prikaz pravega stanja.



4.3.8. Prikaz prometa TRR na Hypo-Netu

Eden od ciljev projekta je tudi prikaz stanja na transakcijskem računu v naši spletni banki HypoNet. V HypoNetu je potrebno dodelati prikaz prometa na način, da se ne knjiženim zneskom doda predpono AVT. V skupnem seštevku prometa v breme pa se zneski evidenčnega stanja že upoštevajo, kljub temu, da še niso knjiženi. V prikazu "Promet na mojih računih" se torej v stolpcu "Datum kniženja" prikaže datum avtorizacije postavke. Stolpec "Datum valutacije" se pusti prazen. V stolpec "V breme / v dobro" se izpiše avtorizirani znesek. V stolpec "Opis" se začne opis z predpono AVT: in doda opis avtorizacije. V tem opisu je napisano ali je bila avtorizacija na bankomatu oz. POS terminalu poleg tega pa je napisan kraj oziroma ime trgovca, od koder se je zahtevek za avtorizacijo poslal.

4.3.9. Izdelava navodil

Izdelati je potrebno tri vrste navodil in sicer navodila za sodelavce iz področja poslovanja z občani. Te sodelavci se bodo srečevali z vprašanji glede stanja s strani komitentov, prav tako pa se jim bo malo spremenil tudi pogled v programu HIBIS. V programu se jim bo namreč pojavil nov status ne knjiženega prometa. Druga vrsta navodil je za sodelavce v oddelku Plačilnega prometa, ki deluje v okviru transakcijskega bančništva. Ta oddelek med drugim izvaja tudi "HelpDesk" za elektronsko bančništvo. Zaradi tega jim morajo biti znane vse spremembe, katere se bodo zgodile z selitvijo avtorizacij v našo banko in s spremembami prikaza prometa v naši spletni banki "HypoNet". Tretja vrsta navodil, so navodila za sodelavce iz področja Informacijske tehnologije. Ta navodila morajo vsebovati postopke o ravnanju ob planiranih in ne planiranih prekinitvah. V njih morajo biti opisana pravila in protokoli o ravnanju ob teh prekinitvah.

4.3.10. Globalno testiranje

Globalno testiranje je namenjeno testu delovanja celotnega sistema. Pripravi se scenarij testiranja. V testu mora biti zajet celoten postopek. To pomeni da test zajame vse od zahtevka za avtorizacijo, poslanega v avtorizacijsko hišo. Zahtevek se nato avtorizira in pošlje nazaj. V Bankartu se pripravi ATM datoteko, katero se preko prevzemnih kanalov prevzame v HIBIS. Medtem se pripravi in pošlje še PBF datoteko v procesni center. Test mora obsegati tudi izvajanje postopkov ob prekinitvah delovanja avtorizacijskega sistema. Preveriti je potrebno tudi delovanje postopka brisanja evidenčnih knjižb starejših od 8 dni. Test mora zajemati tudi prikaz stanja v HypoNet-u.

4.3.11. Prehod v produkcijo

V primeru uspešno opravljenega testa, se po v naprej pripravljenem scenariju, začne s postopki za vključitev avtorizacijskega sistema v produkcijsko okolje. V scenarij je potrebno vključiti poleg tehničnega preklopa, tudi aktivnosti za obveščanje komitentov. Te aktivnosti morajo obsegati tako obveščanje preko e-banke, kot tudi preko pošiljanja obvestil komitentom in pripravi zgibank. Slednje se bo delilo na bančnih okencih in pri bankomatih. Po uspešnem prehodu v produkcijo se bo projekt zaključil.



Potem ko smo projekt razdelili na več nalog, katere so opisane v točkah od 4.3.1 do 4.3.11, smo po nalogah določili tudi mejnike. Vsaki nalogi smo dodali tudi časovno komponento, finančni okvir ter določili člane projekta. Člani projekta dodeljeni posamezni nalogi so odgovorni za izvedbo posamezne naloge. V sami projektni knjigi smo določili tudi protokol obveščanja. Protokol obveščanja zapoveduje izključno uporabo aplikacije Daptiv. Tako se v Daptiv-u v vsakem trenutku da preveriti stanje projekta. V projekt smo vključili interne človeške vire, kot tudi zunanje izvajalce. Na začetnem (kick off) sestanku vseh sodelujočih v projektu, smo se domenili, da se bomo sestajali pred začetkom vsake naloge oziroma faze. V primeru, da bi se pokazala potreba po vmesnih sestankih, bo le te sklical vodja projekta v zoženi sestavi. Dogovore sprejete na sestankih pa bo napisal v poročilo in ga objavil med ostalo projektno dokumentacijo. Dogovorjeno je bilo tudi, da se po zaključku vsake faze obvesti vse člane projekta, še posebno sponzorja. S takim načinom dela, se bo projekt dalo varno pripeljati do konca.

Glede na raznovrstnost posameznih nalog se potrebuje različne profile strokovnjakov. Strokovnjake smo poiskali znotraj lastnih virov in jih okrepili s strokovnjaki iz partnerskih organizacij. V spodnji tabeli (tabela 2) so opisani profili članov projekta. Zaradi lažje komunikacije z zunanjimi partnerji, smo od vseh razen Bankarta povsod pridobili koordinatorja. Koordinatorjeve naloge so bile predvsem prenos zahtev med njihovem teamom in nami. Celotna korespondenca bo torej potekala preko teh koordinatorjev. Na ta način bodo vsi sodelujoči obveščeni o celotnem dogajanju v projektu predvsem na njihovem področju. V podjetju Bankart smo zaradi intenzivnosti izvajanja posameznih nalog, kot tudi potrebe po relativno velikem številu različnih strokovnjakov, povezani direktno s samimi izvajalci teh nalog. Zaradi tega se je pred samim uradnim začetkom projekta organiziralo sestanek na podjetju Bankart. Na tem sestanku smo se dogovorili o predvidenem poteku projekta. Tu smo se vsi sodelujoči tudi spoznali in izmenjali svoje poglede na problematiko. Dogovorili smo se tudi o načinu komuniciranja. V tabeli (Tabela 2) so opisani profili članov projekta. Iz opisa profila lahko razberemo znanja potrebna za uspešno končanje projekta. V projektu so namesto profilov napisana imena posameznih članov, vendar so za to diplomsko nalogo popolnoma iralevantna.



Kratko ime

profila Dolgo ime profila Opis profila

HBS PI Poslovni informatik Poslovni informatik nastopa v tem projektu kot vodja projekta.

HBS IT Nadzornik omrežja in administrator sistemov

Njegova glavna naloga je postaviti infrastrukturo omrežja, ter zagotoviti platformo za delovanje potrebne programske opreme (MiniBIC ISO in podobna podporna prog. opr.)

Bankart IT Nadzornik omrežja na strani Bankarta

Odgovoren pripraviti vse potrebno za fizično povezavo Bankart-HBS.

Bankart PI Poslovni informatik Odgovoren za pomoč pri razvoju programske opreme, predvsem oskrbovanje z potrebnimi informacijami vseh sodelujočih. Njegova naloga je tudi aktivno sodelovanje pri izvajanju vseh testov.

HBS tehnolog 1

Tehnolog za področje e-banke in poslovanja z občani

Odgovoren za izdelavo funkcijskih specifikacij, ter preverjanje delovanja rešitve

HBS Tehnolog 2

Tehnolog za področje kartičnega poslovanja

Odgovoren za izdelavo funkcijskih specifikacij, ter spremembo delovnega procesa

HRC Koordinator na strani podjetja HRC

Odgovoren za koordinacijo HRCjevih programerjev za dodelavo programa HIBIS, ter integriranje vmesnika MiniBIC ISO v naš sistem.

Hermes Koordinator na strani podjetja Hermes Soft Lab

Odgovoren za koordinacijo pri izdelavi internetnih strani, za prikaz evidenčnega stanja, ter posodobitev navodil za uporabo

Marketing Odgovorna oseba v Marketingu

Odgovoren za pripravo celotne marketinške akcije obveščanja naših komitentov.

PZO Odgovorna oseba na področju Poslovanja z občani

Oseba odgovorna za pomoč pri izdelavi grafične podobe internetnih strani. Skrbi tudi za obveščanje sodelavcev o eventualnih spremembah pri samem poslovanju.

TBKP Odgovorna oseba v oddelku Kartičnega poslovanja na področju Transakcijskega bančništva

Oseba odgovorna za koordinacijo med Bankartom in HBS. Pobudnik za inicializacijo projekta.

Tabela 2: Imena profilov projektnih članov (Vir: lasten)



V nadaljevanju si poglejmo še časovno razporeditev nalog. V ta namen je uporabljen Gantt-ov diagram celotnega projekta. Nekatere naloge so tekle vzporedno, saj so bili izvajalci nalog različni. Spet druge so bile odvisne od drugih nalog v projektu. Te so se lahko začele šele po uspešnem zaključku potrebnih nalog.

Slika 9: Gantt diagram celotnega projekta (Vir: lasten)

Vsaka od zgoraj opisanih nalog je sestavljena iz več manjših nalog, katere so smiselno povezane. Najprej si poglejmo nalogo 1 Izgradnja vmesnika MiniBIC ISO. V tej nalogi sodelujejo člani projekta HBS PI, HBS IT in HRC. Koordinatorju podjetja HRC se je izročilo prototip rešitve z vso dokumentacijo. Prototip smo predhodno dobili v podjetju Bankart. Izdelali so ga z namenom podajanja smernic pri izdelavi vmesnika. Po pripravi načrta za izdelavo vmesnika, so na HRCu predvideli rešitev, katera se bo poganjala preko "batch" datoteke klicane z parametri. Glede na to, da smo zaradi lažje kontrole delovanja želeli, da ta vmesnik teče v obliki servisa, smo bili primorani v nakup programske opreme FireDeamon. Ta program prilagodi kateri koli zagonski program da deluje kot servis. Program dela na način, da sam teče v obliki servisa, znotraj katerega zažene želeno zagonsko datoteko, kateri se lahko dodeli potrebne parametre. Ta "virtualni" servis lahko nadziramo z enim od nadzornih programov. V naši banki uporabljamo nadzorni program Zabbix. Ta program med drugim lahko nadzira delovanje servisov. Ob vnaprej nastavljenih pogojih, nas v primeru prekoračitve teh pogojev, obvesti z alarmom preko elektronske pošte. Za izdelavo te naloge sta predvidena 2 meseca. V nalogi 2 je postavitev povezave med Bankartom in HBS. Ta povezava je kot že rečeno, izvedena tako preko MPLS oblaka z uporabo TCP/IP protokola, kot tudi preko stare povezave. Obe podjetji se ščitita s požarno pregrado na kateri izvajata tudi NAT. (glej Slika 8). Postavitev MPLS oblaka in povezave preko njega je bila postavljena malo pred začetkom projekta. Postavljen je bil z namenom povezati nov klirinški sistem, ki je ravno tako pred kratkim ugledal luč sveta. Na ta način smo izkoristili že postavljeno infrastrukturo, katero smo morali samo malo dopolniti. Preko te povezave tako lahko tečeta oba sistema. Poudariti je potrebno, da bomo v samem začetku koristili še staro povezavo, ker v podjetju Bankart za enkrat še niso izvedli selitve celotnega avtorizacijskega sistema na novo povezavo. To nameravajo storiti v kratkem. V projektu bomo sicer testirali tudi MPLS povezavo, tako da jo bomo lahko koristili takoj, ko bo to mogoče. Zaradi relativno preprostih nastavitev smo si za to nalogo rezervirali samo 11 dni v katerih je vračunana tudi rezerva v



primeru, da bi šlo kaj narobe. Pri tej nalogi sodelujejo trije člani projekta in sicer HBS IT, HBS PI in Bankart IT. Nastavitve omrežnih povezav je potrebno nastavljati sočasno. Le na tak način lahko takoj preverimo delovanje povezave. Naloga 3 obravnava izdelavo PBF datoteke. Ta datoteka se izdeluje v dveh različicah in sicer, kot delna ter kot celotna PBF datoteka. V delni datoteki so navedene samo spremembe, katere so se zgodile od predhodno poslane datoteke. Celotna datoteka pa vsebuje vse podatke o komitentih ne glede na spremembe. Tej nalogi je dodeljeno več projektnih članov, saj je potrebno napisati funkcijsko specifikacijo po navodilih, poslanih s strani Bankarta. V programu HIBIS je potrebno razviti funkcijo, katera pripravi datoteko in jo odloži na dogovorjeno mesto. Poleg tega je potrebno izdelati proces v programu ConnectDirect, za pošiljanje PBF datoteke na Bankart. Prav tako je potrebno izdelati tudi proces za prevzem datoteke z odgovorom. Ta odgovor nam služi kot potrditev, da je datoteka uspešno uvožena v avtorizacijski program BSE. Ta datoteka služi za sinhronizacijo stanja med programoma HIBIS in BSE. V tej nalogi sodelujejo člani projekta HRC, Bankart PI, HBS IT, HBS PI, HBS tehnolog2, TBKP. Za nalogo je predvidel slab mesec dni.

Po končani izvedbi povezave in izdelanem vmesnikom MiniBIC ISO lahko pristopimo k nalogi 4, prvem testiranju infrastrukture. Kot že opisano v točki 4.3.4, se v sodelovanju z Bankartom meri prepustnost sistema. Prepustnost sistema se meri na način, da iz Bankarta prejmemo veliko količino različnih zahtevkov za avtorizacijo. S posebno aplikacijo se nato na Bankartu meri hitrost in ustreznost odgovorov. V testu sodelujejo člani projekta HBS IT, HBS PI, HRC, Bankart IT, TBKP Po uspešno zaključenem testu se pristopili k nalogi 5. Peta naloga je knjiženje evidenčnega prometa. Za potrebe knjiženja evidenčnega prometa je potrebno poleg razvoja programske kode razširiti tudi tabele, v katerih se shranjujejo podatki o transakcijskih računih. Dodati je namreč potrebno en stolpec za vodenje statusa prometa. Tako se lahko loči knjižen promet od evidenčnega. Razviti je potrebno tudi postopek za uvoz podatkov iz datoteke, katero nam Bankart pošlje po odpravi našega avtorizacijskega sistema. Te podatke potrebujemo za sinhronizacijo stanja med aplikacijama BSE in HIBIS. Pri tej nalogi sodelujejo HBS PI, Bankart PI, HRC, HBS Tehnolog2, TBKP. Nalogi 6 je namenjena popravljanju postopka knjiženja avtoriziranih zahtevkov na podlagi datoteke ATM data. To datoteko, nam kot že rečeno, pripravi podjetje Bankart, vsak dan razen nedelje in praznikov. V tej datoteki so zajete terjatve lastnikov bankomatov oziroma POS terminalov poslane do 22:00 ure preteklega dne. S pomočjo te informacije, program HIBIS spremeni stanje transakcije iz evidenčnega prometa v knjižen promet. Poleg tega nakaže sredstva na račun lastnika bankomata oziroma POS terminala. Do sedaj, se je sicer ravno tako knjižilo preko datoteke ATM data, vendar pri tem ni bilo potrebno spreminjati statusa evidenčnega prometa. V tej nalogi je torej potrebno program HIBIS nadgraditi tako, da bo znal poleg knjiženja spremeniti še status evidenčnemu prometu. Glede na to, da se mora ta naloga izvršiti ravno v decembru je v planiranju časovnega okna upoštevan tudi čas praznikov in dopustov. Pri tej nalogi sodelujejo HBS PI, HRC,Bankart PI,HBS Tehnolog1, HBS Tehnolog2, TBKP.



Včasih se zgodi, da iz kakršnih koli razlogov lastnik bankomata oz POS terminala ne pošlje terjatve procesnemu centru, zato jo le ta ne vključi v datoteko ATM data. Po preteku 8 dni taka terjatev postane nična. To se sicer zgodi zelo redko, vendar je treba v sistemu predvideti tudi tak primer. Zato smo se temu problemu posvetili v 7 nalogi. Tu je potrebno v HIBISu napisati akcijo tako, da bo pobrisala vse terjatve starejše od 8 dni in se nahajajo v stolpcu evidenčnega stanja. V tej nalogi sodelujejo isti člani projekta kot v prejšnji. To so HBS PI, HRC,Bankart PI,HBS Tehnolog1, HBS Tehnolog2, PZO, TBKP. Glede na to, da se ta akcija nanaša na iste tabele in poglede se jo razvija istočasno z prejšnjo nalogo Knjiženje ATM. Po razvoju samega delovanja avtorizacijskega sistema v HBS je čas, da se posvetimo tudi prikazovanju prometa na naši spletni banki HypoNet. V spletno banko za fizične osebe HYPOnet se torej v nalogi 8 poleg obstoječih prometnih postavk, doda še prikaz evidenčnega prometa. Tako bo uporabnikom HYPOneta omogočen pregled knjiženih in evidenčnih prometnih postavk, ter stanje z že upoštevanim evidenčnim prometom. Pregled 'Promet na mojih računih' se zato dopolni tako, da vsebuje tako knjižene postavke, kot evidenčni promet. Prikaz knjiženih postavk se ne spremeni. Posamezna postavka pri evidenčnem prometu pa vsebuje naslednje vrednosti: • Datum knjiženja: datum avtorizacije za dano postavko prikazano iz zato

pripravljenega pogleda (view-a) • Datum valutacije: postane prazno polje do prejema datoteke ATMdata • V breme / v dobro: V to polje se vpiše avtorizirani znesek • Opis: V to polje se doda predpona AVT:, kateri sledi opis avtorizacije iz

odgovarjajočega pogleda. Če je torej postavka v pogledu, ki izhaja iz HIBISa označena kot evidenčni promet, se ji v prikazu doda predpono AVT: .

V prikazu "Pomoč" se v poglavje "Promet na mojih računih" doda besedilo s pojasnilom, kaj pomeni predpona AVT:. Ob dvigu gotovine na bankomatu ali plačilu s kartico prek POS terminala se izvedena transakcija najprej zabeleži kot evidenčni promet. Taka postavka dobi v prikazu "Promet na mojih računih" v opisu postavke predpono AVT. Z zneskom, ki ima oznako AVT ne morete več upravljati, vsota avtorizacij (AVT) pa je že upoštevana v izračunih razpoložljivih sredstev. Po prejemu ATM Data datoteke Banka spremeni status iz AVT v knjiženega.

V tej nalogi, katera je ena večjih v tem projektu sodelujejo projektni člani HBS PI, HRC, Bankart PI,HBS Tehnolog1, HBS Tehnolog2, PZO, TBKP, Hermes. Glede na veliko število članov, potrebnih za dokončanje te naloge, ter z upoštevanjem praznikov se je nalogi namenilo dober mesec dni.



Slika 10: Ono "Promet na mojih računih" (Vir: Interna navodila)

Med razvojem spletne strani se začne pripravljati navodila. V nalogi 8 se naj bi pripravilo navodila namenjena trem različnim tipom uporabnikov. To so zaposleni v področju informacijske tehnologije, zaposleni v področju Transakcijskega bančništva, znotraj katerega v oddelku Plačilnega prometa deluje "HelpDesk" za vse naše stranke , ter za zaposleni v področju Poslovanje z občani (Slika 1). V navodilih namenjenim zaposlenim v Informacijski tehnologiji je opisan celoten protokol, kako nadzorovano ustaviti proces avtorizacije v HBS in jo preseliti na Bankartov sistem. Ta postopek se bo uporabljal v primerih, ko se bodo na HIBISovih bazah izvajala vzdrževalna dela, oziroma se bo izvajala nadgradnja. Te akcije so venomer znane v naprej in se jih lahko planira. Poleg tega morajo navodila vsebovati postopek ravnanja, v primeru nepričakovane prekinitve avtorizacijskega sistema. Za take primere morajo biti razdelani scenariji, da se lahko motnjo čim hitreje odpravi. Ta navodila pripravijo naslednji člani: Bankart PI, Bankart IT, HBS PI in HBS IT. Na pomoč so priskočili tudi na partnerski organizaciji, ki skrbi za vzdrževanje MPLS oblaka. Navodila se lahko pripravi po vzpostavitvi povezave in namestitvi vmesnika MiniBIC ISO. Navodila za pomoč v "HelpDesku" pripravijo člani projekta HBS tehnolog1, HBS tehnolog 2 in TBKP. Navodila se lahko izdela šele po končanju naloge 7, ko bo HypoNet že popravljen. Starim navodilom se doda še opise novih funkcionalnosti.



Pripraviti je potrebno tudi navodila za zaposlene v področju Poslovanje z občani. Njim se spremenijo zaslonski obrazci pri delu z Transakcijskimi računi v modulu namenjenem delu na bančnem okencu. Tu je potrebno dopolniti navodila za delo s programom HIBIS. Ta navodila pripravi HBS Tehnolog 1, vendar šele po zaključku naloge 7 "Brisanje evidenčnih knjižb starejših od 8 dni". Predzadnja 9 naloga pred prehodom v produkcijo je Globalno testiranje celotnega sistema. Priprave na test morajo biti obsežne, saj je potrebno predelati vse scenarije in jih združiti v 9 dnevni test. V veliko pomoč pri pripravi scenarija nam bodo prišli nasveti izkušenih Bankartovih kolegov. Po njihovih nasvetih se pripravi 9 dnevni test, ki zajema delovanje avtorizacijskega sistema pod veliko obremenitvijo, delovanje ob prekinitvi linije, ter ponovno vzpostavitev sistema. Pri tem se izvaja vse postopke predvidene za delo produkciji. V testu se nakazila prikazuje v testnem Hypo Net-u, ter v modulu za delo na bančnih okencih. Celoten testni sistem, ki sicer ni tako zmogljiv kot produkcijski, mora opraviti celoten test brez težav. Ob pripravi testnega scenarija se pripravlja tudi scenarij za izvedbo prehoda na produkcijsko okolje. Že zaradi tega dejstva, je potrebno v pripravo globalnega testa vložiti malo več časa in energije. Le tako se lahko predvidi čim več možnih stvari , ki bi v produkciji lahko šle narobe. Zaradi obsega testiranja v testu sodelujejo vsi člani projekta. Zaključni oziroma globalni test se izvede šele po uspešnem končanju vseh ostalih nalog. Po uspešnem zaključku testiranja se pristopi k zaključni nalogi 10, prehod v produkcijo. Pri prehodu je potrebno namestiti vso potrebno programsko opremo na produkcijske strežnike, kar se lahko izvede že pred samim prehodom. Na dan prehoda je potrebno uskladiti vsa dejanja z Bankartom, da ne bo prišlo do kakšne podvojene avtorizacijske zahteve. V nadaljevanju si poglejmo še akcijski načrt prehoda. Prehod je potrebno izvesti naenkrat, da ne bi prišlo do podvojitev knjiženj ali podobnih težav. Z podjetjem Bankart smo se odločili da dokončni prehod izvedemo v ponedeljek 16.02.2009. Akcijski načrt si lahko ogledamo v naslednji tabeli (Tabela 3)

Datum Ura začetka

Naloga Izvajalec

11.02.2009 Obvestiti Bankart o dokončnem datumu preklopa na nov način avtorizacije

Projektni vodja

11.02.2009 18:30 Objava baznih objektov v produkcijskem HIBISu, objava novih mask na modulu za delo na bančnih okencih ter objava novega "snap shota" za objavo na hypo netu.

HRC, HBS PI

11.02.2009 20:00 Ureditev pravic za dostop do objavljenih mask

HRC

11.02.2009 18:30 Objava sprememb na Hypo Netu za prikaz evidenčnega stanja

HBS Tehnolog 1, Hermes

15.02.2009 23:10 Ustavimo avtomatsko pošiljanje osveževalne datoteke za evidenco stanja na računih

HBS IT

16.02.2009 06:30 Vzpostavitev produkcijskega okolja. HBS PI, HBS IT 16.02.2009 06:50 Poklicati Bankart za nastavitev

produkcijskih parametrov v MiniBIC HBS PI



ISO vmesniku. 16.02.2009 07:00 Pošiljanje celotne PBF datoteke

preko ConnectDirecta HBS IT, HBS PI, TBKP

16.02.2009 07:05 Zagon MiniBIC ISO vmesnika. HBS IT 16.02.2009 07:15 Prevzem datoteke ATM Data in

knjiženje HBS IT, TBKP

16.02.2009 07:20 Preveriti da so vsi agenti za pripravljanje osveževalnih datotek ustavljeni

HBS PI

16.02.2009 07:35 Sprožiti agenta za pripravo delne in celotne PBF datoteke

HBS PI

16.02.2009 07:55 Sprožiti nov ConnectDirect proces za pošiljanje PBF datotek in poslati prvo celotno PBF datoteko

HBS IT

16.02.2009 08:00 Kontrola delovanja ter izmenjanih datotek

HBS PI, HBS IT, HBS Tehnolog 1, HBS tehnolog 2. Bankart, TBKP

16.02.2009 08:15 Obvestiti vse prizadete v banki o vpeljavi OnLine avtorizacije

Vodja projekta

19.02.2009 08:15 Uparjanje knjižb, katere se niso uparile z avtorizacijo

HBS PI, TBKP

Tabela 3: Akcijski načrt prehoda na ON line avtorizacijo (Vir: Hypo 2009, Akcijski_na_rt_projekta_OnLine_ver3.xls)

Po uspešnem prehodu se organizira še zadnji zaključni sestanek (naloga 11) na katerem se projekt Vpeljava On line avtorizacij bankomatskih in POS transakcij v Hypo Alpe-Adria bank d.d. tudi uradno zaključi.



5. ZAKLJUČKI

5.1. Ocena učinkov

Po nekaj mesečnem delovanju OnLine avtorizacije so prve spremembe že opazne. Najbolj vidna sprememba je ukinitev plačevanja provizije za izvajanje avtorizacije v našem imenu. V HypoNetu se je dvignilo zadovoljstvo strank, predvsem zaradi poenotenja prikaza stanja. S tem prehodom se je nedvomno dvignila tudi sama varnost poslovanja, vendar je le to kvantitativno zelo težko prikazati, kvalitativno pa je to velik korak v pravo smer. Saj z uvedbo On Line avtorizacije lahko vsak trenutek preverimo pravo stanje, brez čakanja na datoteko ATM data, katera kot vemo praviloma pride šele naslednji delovni dan. S tem onemogočimo dvig gotovine preko dovoljenih limitov in vse pravne zaplete, kateri nastanejo zaradi tega. V samem projektu smo se poleg same postavitve nove storitve, dodobra spoznali z delom v samem programu Daptiv. Te izkušnje nam bodo prišle zelo prav v naslednjih projektih , katerih bo v prihodnosti vedno več. Saj je projektni pristop reševanja nalog v skupini Hypo Group Alpe Adria postal obvezna praksa.

5.2. Pogoji za uvedbo

Pogoji za uvedbo OnLine avtorizacij bankomatskih in POS transakcij se delijo na različne zvrsti sredstev. V tem poglavju si bomo ogledali potrebna sredstva za izvedbo tega projekta. Sredstva delimo na finančna, kadrovska, tehnična in časovna. Z nobeno od naštetih kategorij ne moremo razpolagati v neomejenih količinah. Ta sredstva so se bolj ali manj natančno predvidela že v sami pripravi projekta. Ta projekt ni bil med zahtevnejšimi, tako da so bila potrebna sredstva okvirno poznana že pred samim začetkom projekta. Finančna sredstva so za naročnika projekta največkrat najbolj zanimiva. Na žalost jih zaradi poslovne skrivnosti v tej diplomski nalogi ne bomo obravnavali. Za potrditev tega projekta so imela ta sredstva sicer velik ne pa tudi odločilen del. Ta storitev se je "morala" uvesti, seveda na za banko najbolj ugoden način. Namenjena finančna sredstva so bila ves čas trajanja projekta tudi pod največjim nadzorom. Kadrovska sredstva pri planiranju projekta nemalokrat vodji projekta povzročijo največ težav. Saj mora vodja projekta od linijskih vodji pridobiti želene ljudi. Te ljudje razpolagajo z potrebnimi znanji. Vendar imajo že svoje zadolžitve tako v vsakdanjem delu, kot tudi v drugih projektih, katerih člani so. Zaradi tega se nemalokrat zgodi, da se zaradi omejenega časa kakšnega projektnega člana zavleče cel projekt. Naloga dobrega projektnega vodje je, da se predhodno dogovori z linijskim vodjem in vodji ostalih projektov, katerih član je želena oseba. Le tako se lahko uspešno planira razpoložljiv čas vseh članov projekta. S tem se izognemo zaostankom, oziroma so le ti planirani. Pri tem ima veliko vlogo tudi projektna pisarna , katere ena ključnih nalog je razporejanje projektov, tako, da se ne prekrivajo. Pri daljših projektih je to nemogoče zagotoviti. V primeru sporov, mora le te razrešiti uprava. Saj ima uprava najboljšo sliko o prioritetah v podjetju. V našem primeru smo s kadrovskimi sredstvi imeli srečo, saj se je projekt odvijal v času, ko ni bilo drugih pomembnejših projektov. Poleg tega je cel projekt trajal le pet mesecev. Na kratek čas izvajanja projekta je vplivalo tudi dejstvo. da je bil ves razvoj, kar se tiče programiranja predan partnerskim organizacijam. Zaposleni v HBS smo poleg



postavljanja mrežne infrastrukture in pisanja navodil, sodelovali predvsem pri testiranju in nadzoru poteka projekta. V spodnji tabeli si lahko pogledamo profile zaposlenih z predvidenim številom dni potrebnim za končanje projekta.

HBS PI HBS IT HBS Tehnolog 1 HBS Tehnolog 2 Marketing PZO TBKPIzgradnja vmesnika MiniBIC ISO 10 5Postavitev mrežne povezave HBS-Bankart 2 8

Izdelava PBF(Possitive Balance File) 16 5 15 15Prvo testiranje 5 5 5Knjiženje evidenčnega prometa 11 11 11Knjiženje ATM data in Brisanje evidenčnihknjižb po 8 dneh

6 6 6

Prikaz prometa na Hyponet-u 8 8 8 8 8Izdelava navodil 15 5 5 5 5 5Globalno testiranje 10 4 10 10 10 10Prehod v produkcijo 3 3 3 3 3 3 3SKUPAJ 86 35 32 58 3 32 63

6 6

Tabela 4: Poraba Kadrovskih sredstev v [ČD] (Vir: lasten)

Tehnična sredstva se v tem projektu delijo na strojno in programsko opremo. Za zagotovitev in delovanje OnLine avtorizacije bankomatskih in POS transakcij v Hypo Alpe-Adria-bank d.d. potrebujemo oboje. V sklopu strojne opreme je bilo potrebno zagotoviti strežnik na katerem se je lahko namestil vmesnik za MiniBIC ISO, ter mrežno opremo, kot sta usmerjevalnik in požarna pregrada. Obe napravi služita za povezavo preko MPLS oblaka. V okviru programske opreme je bilo potrebno zagotoviti neprimerno več sredstev. Med programsko opremo spada: • celotno programiranje HIBISa • vmesnik MiniBIC iso, • program za zagon zagonskih datotek v obliki servisa, • izdelava procesov za pošiljanje datotek preko ConnectDirecta • izdelava spletnih strani • konfiguracija požarne pregrade in usmerjevalnika V projektu je podobno, kot pri vseh ostalih projektih, ta del predstavljal največje stroške. Zaradi tega je tehničnim sredstvom pred izvedbo projekta potrebno posvetiti veliko pozornosti. Saj se s skrbno in gospodarno izbiro lahko na tem segmentu prihrani največ. S površnim planiranjem, oziroma s preveliko željo po varčevanju lahko hitro naredimo veliko škodo. Saj se nam lahko zgodi, da uporabimo neko cenejšo napravo, ki je sicer po tehničnih specifikacijah enako zmogljiva, kot neka druga, dražja vendar že preverjena naprava, katera se nam v praksi v produkcijskem okolju pokaže kot neprimerna. Tako napravo je potem potrebno zamenjati, kar nam ne planirano podraži projekt. Ravno zato je tej točki potrebno posvetiti veliko pozornosti in pritegniti čim več različnih strokovnjakov, kateri nam lahko pomagajo pri izbiri. V projektu je potrebno upoštevati še eno sredstvo in to je čas. Vsi poznamo rek čas je denar. V današnjem času ta rek še kako velja. Zaradi lažjega razporejanja vseh ostalih virov, moramo upoštevati časovne okvire. Saj kot že rečeno, so kadrovska sredstva vedno bolj omejena, saj morajo biti le ta čim bolje izkoriščena. Tudi pri tem viru se da s skrbnim načrtovanjem prihraniti. Saj pri zunanjih izvajalcih najdražje plačamo ravno čakanje na potrebne informacije. Zahtevane informacije jim moramo priskrbeti v čim krajšem času, tako da ne zamujajo pri končanju zaupanih nalog.



5.3. Možnosti nadaljnjega razvoja

Z vpeljavo tega projekta v produkcijo, smo postavili temelj za razvoj dodatnih storitev. Takoj po zaključku projekta, smo pristopili k razvoju vmesnika za obveščanje stanja na transakcijskem računu, preko SMS sporočilnega sistema. Ta storitev je v času nastajanja te diplomske naloge ravno v fazi testiranja. Stranka bo z naročilom te storitve enkrat dnevno obveščena o stanju na računu. Poleg tega bo obveščena tudi o vsaki spremembi, katera se bo zgodila na naročnikovem transakcijskem računu. To velja tudi za vsak avtoriziran dvig na bankomatu ali POS terminalu. S tem si bo stranka zagotovila dodatno varnost. Saj bo lahko ob nepooblaščeni uporabi plačilne kartice obveščena in bo lahko takoj ustrezno ukrepala. S tem se bo možnost zlorabe kartice ob izgubi ali kraji zmanjšala. V HBS razmišljamo tudi o uvedbi debetne plačilne kartice za podjetja. Za uvedbo take plačilne kartice vlada med podjetji kar velik interes. Predpogoj za to pa je seveda uvedba On Line avtorizacije. Sama uvedba debetne kartice je nekoliko zahtevnejša iz pravnega stališča. Tehnično pa uvedba take kartice ne predstavlja večjih dodelav, saj je praktično vsa infrastruktura že postavljena.



LITERATURA IN VIRI

Primarna literatura:

Anžič, J. (2002). Širokopasovna in inteligentna omrežja, interno gradivo, Šolski center za pošto in elektronske komunikacije, Ljubljana

Bankart (1999), Nivo zagotavljanja storitev na področju poslovanja z bančnimi avtomati, interno navodilo, Bankart d.o.o., Ljubljana

Bankart (2006), Multilateralna medbančna poravnava bankomatskega prometa, interno navodilo, Bankart d.o.o., Ljubljana

Bankart (2006), Poravnava bankomatov, operativno navodilo, Bankart d.o.o., Ljubljana

Bankart (2007), Protokol obveščanja bank v primerih nepredvidenih prekinitev delovanja celotnega avtorizacijskega sistema, interno navodilo, Bankart d.o.o., Ljubljana

Bernik, I. (2005) Računalniški sistemi 10. Komunikacije, študijsko gradivo, Univerza v Mariboru, Fakulteta za organizacijske vede, Kranj

Delovne skupine za SEPA produkte pri ZBS, SEPA nacionalni program Slovenija (2007), dosegljivo na: http://www.sepa.si/slo/Sepa/NacionalniProgram_slo.pdf, obiskano 20.01.2009 European Central Bank (2007), Information and Control Module (ICM) User handbook 1 ver. 2.3, priročnik, European Central Bank, Frankfurt am Main

Hypo Alpe-Adria-bank (2003), Splošna navodila za poslovanje z bančnimi avtomati, interno gradivo, Hypo Alpe Adria Bank d.d., Ljubljana

Hypo Alpe-Adria-bank (2007), Poravnava kartic, operativno navodilo, Hypo Alpe Adria Bank d.d., Ljubljana

Hypo Alpe-Adria-bank, Annual Report 2008 (2009), dosegljivo na: http://www.hypo-alpe-adria-bank-annualreports.com/2008_annual_report/hypo-alpe-adria-bank-d.d.slovenia.1682.htm, obiskano 22.07.2009 Hypo Alpe-Adria-bank (2009), Akcijski_na_rt_projekta_OnLine_ver3.xls, operativno navodilo, Hypo Alpe Adria Bank d.d., Ljubljana Hypo Group Alpe Adria (2008), User Handbook Daptiv PPM v.1.03, interno gradivo, Hypo Group Alpe Adria, Celovec

HypoGroup organization/IT (2008), HPMF- Hypo Project Manager Framework, interno gradivo, Hypo Group Alpe Adria, Celovec



Kern, T. (2005-2006), Metode in tehnike projektnega dela, študijsko gradivo, Univerza v Mariboru, Fakulteta za organizacijske vede, Kranj

Kunc, U. (2007), Model preprečevanja neželene elektronske pošte, diplomsko delo, Univerza v Mariboru, Fakulteta za organizacijske vede, Kranj Vavpotič Srakar, J., Vpliv Slovenske in tuje regulative na bančno prakso na pdročju trgovanja (2003), dosegljivo na: http://www.cek.ef.uni-lj.si/magister/vavpotic222.pdf, obiskano 16.01.2009 Wikipedia, Multiprotocol Label Switching, dosegljivo na: http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching, obiskano 20.03.2009



KAZALO SLIK

Slika 1: Organigram HBS ........................................................................................... 2 Slika 2: OSI model ..................................................................................................... 5 Slika 3: Potek dviga preko bankomata oz. POS terminala ....................................... 10 Slika 4: Sistem plačilnega prometa v HBS do danes ............................................... 11 Slika 5: Izvedba mrežne povezave med HBS in Bankartom .................................... 12 Slika 6: S.W.O.T. analiza ......................................................................................... 14 Slika 7:Umestitev vmesnika MiniBIC ISO ................................................................ 21 Slika 8: Shema povezave ......................................................................................... 22 Slika 9: Gantt diagram celotnega projekta ............................................................... 27 Slika 10: Ono "Promet na mojih računih" ................................................................ 30

KAZALO TABEL

Tabela 1: Poslovni načrt - Skupni pregled ............................................................... 17 Tabela 2: Imena profilov projektnih članov ............................................................... 26 Tabela 3: Akcijski načrt prehoda na ON line avtorizacijo ......................................... 32 Tabela 4: Poraba Kadrovskih sredstev v [ČD] ........................................................ 34



POJMOVNIK

Frame relay: vrsta računalniške omrežne povezave, Značilno zanjo je da sta dve omrežni naprave direktno povezani med seboj na način točka točka. To pomeni da med njima ni nobene druge naprave. Zaradi tega je ta tip povezave zelo varen.

TCP/IP: To je skupek mrežnih protokolov uporabljen v Internetu in podobnih omrežjih.

OSI model: Open System Interconnection Reference Model, to je model po katerem deluje danes poznan promet , ki teče po med računalniških povezavah.

Cluster: Skupina računalnikov povezanih med seboj, kateri se v omrežju predstavljajo kot eden. Zelo uporaben in velikokrat uporabljen način za zagotavljanje neprekinjenega poslovanja. Saj se v taki povezavi lahko kadarkoli izključi enega izmed računalnikov.

Človek dan (ČD oz PD vangleškem jeziku): Enota za prikaz potrebnega dela. 1ČD=8 ur dela enega človeka. To enoto se uporablja v projektih za planiranje kadrovskih potreb. Uporablja se jo tudi v raznih ponudbah, kjer je potrebno prikazati oziroma ponuditi delo, katerega je potrebno opraviti.

Business case: Poslovni načrt, katerega se uporablja v projektih in za prikaz načina kako spraviti neko idejo v delovni proces, pri čemer so upoštevani vsi znani dejavniki.

Debetna kartica: Plačilna kartica kjer nakažemo denar takoj ob nakupu, za razliko od kreditne plačilne kartice kjer pride do zamika plačila.




KRATICE IN AKRONIMI

ATM V omrežju pomeni Asynchronous Transfer Mode, kar je eden od načinov omrežnega prometa.

Automated teller machine angleška kratica za bankomat

POS Point of sale (Prodajna točka)

MPLS Multiprotocol Label Switching (Več protokolno usmerjanje paketov)

OSI Open System Interconnection Reference Model (glej pojmovnik)

HBS Hypo Banka Slovenija

PIN Personal Identification Noumber (osebna identifikacijska številka)

S.W.O.T. Strenghts Weaknesses Opportunities Threats. (Prednosti, Pomanjkljivosti, Priložnosti, Grožnje)

HPMF Hypo Project Manager Framework (Hypo interni priročnik namenjen projektnemu delu)

PBF Positive Balance File, datoteka katero pripravijo v procesnem centru. V tej datoteki so podatki o knjiženih dvigih na bankomatih in POS terminalih

NAT Network address translation, mehanizem za spreminjanje mrežnega naslova kateri koli mrežni napravi.

TCP Transmission Control Protocol

IP Internet Protocol

vpeljava on line avtorizacije bankomatskih in pos

Documents