INFORMATIČKO RJEŠENJE JEDINSTVENE BAZE ŠTETNIKA

– PROJEKTNI ZADATAK –

SARAJEVO, februara-veljače, 2010. godine

UDRUŽENJE DRUŠTAVA ZA OSIGURANJE U FEDERACIJI BOSNI I HERCEGOVINI UDRUGA DRUŠTAVA ZA OSIGURANJE U FEDERACIJI BOSNI I HERCEGOVINI ASSOCIATION OF INSURANCE COMPANIES IN FEDERATION OF BOSNIA AND HERZEGOVINA 71000 SARAJEVO, Zmaja od Bosne 4/IX-3 ODBOR ZA INFORMATIKU

1. INFORMATIČKO RJEŠENJE JEDINSTVENE BAZE ŠTETNIKA

– PROJEKTNI ZADATAK

Informatičko rješenje jedinstvene baze štetnika ima cilj da pruži pouzdan, brz i siguran pristup bazi

štetnika. Pristup treba da obezbijedi jedostavan način za unos i konzumaciju podataka kroz različite

kanale, koji podrazumijevaju distribuciju podataka putem web aplikacije, GSM/GPRS servisa, uz

postojanje interfejsa u vidu WEB servisa. Jedinstvena baza štetnika treba biti skalabilno i lako

nadogradivo rješenje za razvijanje dodatnih kanala pristupa. Rješenje mora da garantuje jednostavan

i siguran transfer podataka uz mogudnost egzaktnih mehanizama kontrole pristupne politike,

podataka (prvenstveno izdatih polica i predmeta šteta). Rješenje treba biti bazirano na zadnjim

dostupnim informacionim tehnologijama koje omogudavaju visoku pouzdanost, dostupnost i

sigurnost, te mogudnost lake nadogradnje i unapređenja.

1.1. Okvir projekta

Jedinstvena knjiga štetnika predstavlja osnovni element podrške implementaciji pravne regulative

vezane za uređivanje oblasti saradnje društava za osiguranje u FBiH.

Jedinstvena knjiga

štetnika

Treće strane

(Biro zelene

karte, Agencije

osiguranja,

Zaštitni fond i

ostali...)

Članice

UdruženjaUnutrašnji

interfejsi

UDOFBiH

Ilustracija 1 - Blok šema interoperabilnosti jedinstvene knjige štetnika

1.1.1. Osnovni principi i koncepti informacionog sistema

Osnovne principe i koncepte sistema trebaju predstavljati komponente potrebne za rad modernih IT

sistema, i to sljededih 5 komponenti:

Dijeljena infrastruktura

Informacije

Servisno orjentisana infrastruktura

Razvojno okruženje

Nadzor i upravljanje sistemima i aplikacijama

U nastavku de biti specificirani konkretni zahtijevi za svaku od 5 prikazanih komponenti.

Ra

zvo

jno

okru

že

nje

Up

ravlja

nje

sis

tem

ima

i

ap

lika

cija

ma

Servisno orijentirana

arhitektura

Informacije

Dijeljena infrastruktura

Softverska arhitektura

Ilustracija 2 - Model softverske arhitekture

1.1.1.1. Dijeljena infrastruktura

Dijeljena infrastruktura treba :

Omoguditi maksimalan povrat investicije u infrastrukturu IT sistema

Smanjiti vrijeme iskorištenja i vlasništva uređaja za pohranu podataka (Storage), servera, softvera i aplikacija

Omoguditi kvalitetan nivo servisa krajnjim korisnicima IT sistema IT sistem baziran na dijeljenoj infrastrukturi treba biti u mogudnosti odgovoriti na zahtjeve

poslovanja, da je fleksibilan, da nije kompleksan i skup za održavanje, te da je u stanju pružiti

odgovarajudi nivo servisa krajnjim korisnicima.

Dijeljena infrastruktura treba se sastojati od uređaja za pohranu podataka, odvojenih servera baze

podataka, komponenti srednjeg sloja-aplikacijskog servera kao i alata za nadzor i upravljanje

cjelokupne dijeljene infrastrukture.

Na nivou Storage-a treba omoguditi automatsko upravljanje raspoloživim diskovnim prostorom –

Automatic Storage Management kako bi Storage omogudio jedinstven logički pogled na sve objekte

(različite tipove podataka) koji se u njega pohranjuju bez obzira na klasifikaciju podataka i tehnologiju

na kojoj se Storage zasniva.

Storage treba obezbijediti prostor na zahtjev i mogudnost da se njime automatski upravlja kroz

automatizirane procedure, kako bi se najbolje iskoristio prostor i optimizirao i balansirao I/O, u cilju

spriječavanja uskih grla.

Kako se podaci moraju pohranjivati i izvan sistema – offline backup, potrebno je omoguditi da su

procedure za njihovo održavanje dostupne i da su podaci istovremeno dostupni ali i zaštideni, u

slučaju gubljenja ili otuđenja medija na kojima su pohranjeni.

Na nivou servera baze podataka potrebno je predvidjeti mogudnosti dinamičkog iskorištenja

klasterske tehnologije – udružiti i dijeliti više servera te omoguditi aplikacijama da raspolažu

resursima servera baze podataka prema potrebama tj. definiranje servisa koji de omoguditi da se kroz

alocirane resurse izvrše potrebne operacije na serveru baze podataka u granicama zahtjevanog

kvaliteta servisa, uz balansiranje opteredenja servera.

Također, potrebno je predvidjeti i mogudnost kopiranja podataka na rezervnu lokaciju, s koje de, u

razumnom vremenskom roku biti mogude neometano nastaviti raditi u slučaju da primarna lokacija

nije u funkciji (bilo da je došlo do logičkih ili fizičkih oštedenja, zbog katastrofe bilo koje vrste).

Na srednjem sloju je potrebno predvidjeti da se ravnomjerno iskoriste resursi aplikacijskih serverskih

resursa, te obezbijediti raspoloživost i sposobnost aplikacijskih servera da funkcioniraju po principu

klastera servera baze podataka.

Potrebno je omoguditi monitoring iskorištenja resursa na srednjem sloju i dinamičko podešavanje

kapaciteta prema zahtjevima aplikacija, na osnovu specifičnih politika održavanja nivoa servisa –

predvidjeti neku vrstu ekspertnog sistema koji može prilagođavati raspoloživost kapaciteta servera i

predlagati najbolje politike na bazi iskustva u ponašanju rada aplikacija.

Potrebno je predvidjeti komponente/alate za nadzor i upravljanje kojima se automatski i jednostavno

može kontrolisati iskorištenost resursa dijeljene infrastrukture. Alati trebaju omoguditi automatski i

centralizitan nadzor i upravljanje zasnovano na definiranim politikama rada aplikacija. Potrebno je

omoguditi neprekidan nadzor svih prikupljenih informacija sa resursa koji se koriste: diskova, servera,

svake softverske komponente (operativni sistem, baza podataka, komponente aplikacijskih servera,

aplikacije), s jednog mjesta kako bi se imala mogudnost donošenja ispravnih odluka kod dodjele

resursa aplikacijama i obezbjeđenju nivoa servisa korisniku.

1.1.1.2. Informacije

Softver u komponenti „informacija“ sistemu treba omoguditi sljedede:

Iskorištenje informacija u punom opsegu na način da su dostupne svima kojima su potrebne

Poboljšanja kvaliteta informacija a time i vrijednosti koje one donose organizaciji

Isporučivanju trenutnih, pouzdanih informacija onima kojima su potrebne za obavljanje njihovog posla

Zbog potreba da se zadovolje zahtjevi koje postavljaju različiti autoriteti s kojima de se razmjenjivati

određene informacije i na određen način, komponenta arhitekture koja se odnosi na informacije

mora biti posebno naglašena, i to iz više razloga. Neki od razloga su povedanje količine informacija

tokom vremena i direktna interakcija između učesnika u razmjeni informacija.Tako se dolazi do

zahtjeva koji se odnose na kvalitet informacija, kontrolu pristupa do informacija, mogudnost analize i

izvještavanja na bazi informacija i sl.

Potrebno je predvidjeti visoku dostupnost, raspoloživost, skalabilnost, te povjerljivost, zaštitu i

integritet podataka uz potreban nivo interoperabilnosti.

1.1.1.3. Servisno orijentirana, događajima upravljana infrastruktura

Softver u komponenti servisno orijentirane, događajima upravljane infrastrukture (Service Oriented

Event Driven Application Infrastucture) treba obezbijediti:

Izgradnju zajedničkih intra- i inter- poslovnih procesa kojima de se optimizirati poslovni tokovi

Odgovor na sve poslovne promjene činedi fleksibilnu aplikaciju

Mogudnost konzumacije podataka od strane klijenta bez obzira na izvorni kod jedinstvene

knjige štetnika uz transparentan, standardiziran i jasno definisan interfejs

Sistem treba što efikasnije i pouzdanije omoguditi informacije potrebne za poslovanje i treba

posjedovati mogudnost kreiranja i upravljanja fleksibilnih procesa koji de se koristiti unutar cijele

organizacije i izvan nje, za potrebe razmjene informacija s okruženjem.

Komponente servisno orijentirane, događajima upravljane infrastrukture su u mogudnosti odgovoriti

na ovakve izazove jer posjeduju generičke komponente softvera sa maksimalno prilagodljivim

poslovnim procesima i informacijama kritičnim za poslovanja unutar i izvan organizacije.

Dodatno, za integraciju sa ostalim sistemima u okruženju i komunikaciju sa njima, potrebno je

osigurati zajedničku komponentu zasnovanu na standardima, i sa podrškom više protokola za

razmjenu poruka baziranih na web servisima.

Za potrebe nadzora i upravljanja poslovnih procesa potrebno je obezbijediti mehanizme kojima se

mogu definirati i kontrolirati poslovni procesi – Business Rules Engine, upravljati događajima - Event

Management i mogu vršiti analize i izvještavanja rezultata poslovanja - Business Activity Monitoring.

Zajedno sa ovim treba omoguditi Identity Management kao integriranu komponentu koja de

obezbijediti robusno i sveobuhvatno upravljanje identitetima korisnika sistema, i to: Access

Management – za kontrolu pristupa, s omogudenim samouslužnim servisom administracije korisnika,

uz podršku LDAP directory servisa, sinhronizacije sa ostalim tipovima direktorija i upravljanja web

servisima.

Za potrebe uspješnog upravljanja ovakvim okruženjem treba predvidjeti komponentu kojom se mogu

nadgledati poslovni process, partnerski linkovi (linkovi prema društvima za osiguranje, različitim

autoritetima sa kojima se vrši razmjena informacija) i eventualne greške i zastoji u izvršenju procesa.

1.1.1.4. Razvojno okruženje

Softver u komponenti razvojnog okruženja treba omoguditi visoko produktivno okruženje za brzi

razvoj, efikasno korištenje i lako održavanje komponenti aplikacija. Kad se pomene razvoj onda se

podrazumjeva, kako horizontalno širenje nadopunjavanjem novim modulima, tako i vertikalno

povezivanje sa drugim autoritetima i/ili udaljenim lokacijama.

Razvojno okruženje treba da se sastoji od skupa visoko produktivnih alata za razvoj aplikacija, baze

podataka i alata za poslovno izvještavanje – Business Intelligence kojima je mogude podržati razvoj i

tehnološku platformu na kojoj se on izvodi.

Osnovni dio aplikacije treba da je otvoren i dostupan kroz razvojno okruženje koje treba omoguditi

dio razvoja na bazi podataka sa SQL, XML treba da je dostupan kao standardni SQL kao i ostale

opštedostupne programske jezike.

Potrebno je predvidjeti što je mogude više razvojnih alata otvorenog koda dostupnih za odabranu

razvojnu platformu.

1.1.1.5. Nadzor i upravljanje sistemom i aplikacijama

Softver u komponenti upravljanja treba omoguditi aktivno upravljanje širokim sistemom i pružiti

automatski odziv kako bi se održao kvalitetan nivo servisa IT sistema.

1.2. Tehničke specifikacije jedinstvene knjige štetnika

Sistem treba činiti centralna aplikacija integrisana sa sistemima u centralama osiguravajudih kuda. Sva

komunikacija sa centralnom aplikacijom mora biti kriptovana i pružati zaštitu od Man in the Middle

napada. Autorizacioni sistem treba sadržavati mehanizam zaštite od brute force napada na korisničke

račune.

Server baze podataka

Aplikacija

Interfejsi

Elektronska razmjena podataka

Centrale društava za osiguranje

Agenti

Treće strane/autoriteti

Aplikacija

WEB aplikacija (WEB, SMS, GPRS/EDGE/UMTS

Modul administracije

Modul za upravljanje podacima

Modul za napredno izvještavanje

Ilustracija 3 - koncept tehničke specifikacije jedinstvene knjige štetnika

1.2.1. Centralna baza podataka

Centralna baza podataka treba da bude projektovana tako da može sakupljati podatke o štetnicima,

policama osiguranja i štetama. Struktura treba da bude pogodna za pretraživanje podataka potrebnih

za određivanje bonusa i malusa prilikom pravljenja nove police osiguranja.

U bazi je potrebno držati i podatke o korisnicima koji imaju pristup zajedno sa jednosmjernom

enkripcijom zaštidenom šifrom korisnika.

Pristup bazi podataka mora biti omoguden samo aplikacijama koje služe kao interfejs prema

korisnicima. Direktni pristup izvana mora biti zabranjen.

Struktura baze mora podržavati funkcionalnost bilježenja historije svih promjena nad slogovima

zajedno sa vremenom i korisnikom koji je izmjene napravio, i strukturu zapisivanja svih važnih akcija

na ostalim nivoima aplikacije zajedno sa korisničkim imenom i vremenom poduzimanja akcije.

1.2.2. Web aplikacija za upravljanje podacima

Web aplikacija za upravljanje podataka mora omogudavati korisnicima iz osiguravajudih kuda

pretragu, pregled i modifikovanje svih podataka, napredne prilagodljive izvještaje i administraciju

korisnicima, te bilježiti pristup sistemu kroz upis u log koji sadrži pored opisa akcije, ime korisnika, tip

akcije (radi lakšeg pretraživanja).

Web aplikacija mora podržati sljedede uloge korisnika:

Globalni administrator

o Može podešavati sistem i dodavati sve vrste korisnika, pregledati log.

Lokalni administrator

o Može podešavati sistem za osiguravajudu kudu kojoj pripada, pregledati podskup loga

za osiguravajudu kudu, dodavati manje privilegovane korisnike za svoju osiguravajudu

kudu.

Agent

o Pripada osiguravajudoj kudi

o Može pristupiti podskupu informacija dovoljnom da se odrede uslovi izdavanja nove

police.

o Može slati upite SMS-om

Operater

o Pripada osiguravajudoj kudi

o Može sve što i Agent, a dodatno modifikovati, pregledati i pretraživati podatke za

svoju osiguravajudu kudu

o Može vršiti grupni upload podataka o policama, štetnicima i štetama za određeni

period kroz web interfejs.

Statistika

o Može pristupati modulu naprednih izvještaja.

Elektronski pristup za osiguravajude kude

o Može pristupati web servisima za osiguravajude kude

Elektronski pristup za trede strane

o Može pristupati web servisima namijenjenim tredim stranama

1.2.2.1. Modul za administraciju

Modul za administraciju treba da podrži dodavanje, onemogudavanje pristupa i izmjenu korisničkih

podataka za globalnog administratora kao i lokalne administratore na nivou osiguravajudih kuda. U

njemu se treba nalaziti i interfejs za podešavanja sistema kao i izmjenu šifrarnika koji postoje u

sistemu, dodavanje i modifikaciju podataka o osiguravajudim kudama itd..

U ovom modulu administratorima treba omoguditi i pregled i pretraživanje log-a akcija koje su

vezane za nivo administriranja (globalni administrator treba imati pristup cijelom logu, lokalni

administrator samo akcijama vezanim za podatke osiguravajude kude kojoj pripada)

1.2.2.2. Modul za upravljanje podacima

Omogudava korisnicima iz osiguravajudih kuda pretragu, pregled i modifikovanje svih podataka,

Potrebno je pratiti historiju promjena za svaki slog i spriječiti mogudnost trajnog gubljenja podataka.

Osim modifikacije postojedih podataka, korisniku treba omoguditi da izvrši grupni upload podataka o

štetnicima, policama i štetama.

Podrška za slanje podataka mora raditi validaciju poslanih podataka te odbiti upis ukoliko podaci nisu

prošli validaciju. Korisnik mora biti detaljno obaviješten o greški kako bi grešku mogao ispraviti.

1.2.2.3. Modul za napredno izvještavanje

Prema zahtjevima osiguravajudih kuda i tredih strana potrebno je pripremiti izvještaje i omoguditi

pristup njima.

1.2.3. Interfejsi za elektronsku razmjenu podataka

Interfejsi za elektronsku razmjenu podataka trebaju predstavljati skalabilnu platformu koja de prije

svega omoguditi tri posebna, transparenta i standardizirana interfejsa:

- Interfejs za komunikaciju prema agentima

- Interfejs za komunikaciju sa centralama osiguravajudih kuda

- Interfejs za komunikaciju sa tredim stranama/autoritetima

Potrebno je predvidjeti širenje ovih interfejsa, posebno pazedi na zakonsku regulativu, a najviše na

Zakon o zaštiti ličnih podataka. Ukoliko se ukaže opravdan zahtjev za proširenje broja interfejsa ili

karakteristika njegovog tipa

1.2.3.1. Interfejs za komunikaciju prema agentima

Softver treba omoguditi slanje informacija dovoljnih da se odrede uslovi izdavanja nove police kao

odgovor na upit slanjem SMS poruke sa broja upisanom u korisničkim podacima.

Svaki zahtjev se sa vremenom i korisnikom mora zapisati u log.

1.2.3.2. Interfejs za komunikaciju sa centralama osiguravajudih kuda

Softver korištenjem SOAP Web servisa mora omogudavati slanje jednog ili više podataka o

štetnicima, policama i štetama kao i dohvatanje podataka za osiguravajudu kudu. Web servis mora

vršiti validaciju te informisati klijentsku aplikaciju o greškama koje su se desile. Aplikacija se mora

autenticirati prije korištenja servisa računom sa ulogom “Elektronski pristup za osiguravajude kude”.

1.2.3.3. Interfejs za komunikaciju sa tredim stranama/autoritetima

Softver korištenjem SOAP Web servisa mora omogudavati preuzimanje dogovorenih podataka nakon

autenticiranja računom sa ulogom “Elektronski pristup za trede strane/autoritete”.

1.3. Logika rada i tok podataka

Prikupljanje podataka se treba vršiti putem unosa (importa) podataka sa police i unosa (importa)

štetnika. Ova dva importa trebaju logički biti odvojena i mogu se odvijati neovisno. Distribuciju

podataka treba vršiti putem više kanala i s ciljem da budu uvijek i svugdje dostupni.

1.3.1. Import podataka polica

Prva faza toka podataka jeste import u bazu ili akvizicija podataka. Pravilo je da svaki Korisnik koji se

logira na sistem može importovati podatke samo svog Društva. Ovo se odnosi i na import podataka

sa polica i na import štetnika. Import polica se ne može vršiti ukoliko podaci nisu homogeni u smislu

porijekla od strane društa za osiguranje koje importuje podatke. Dakle, društvo je dužno dostaviti

validne podatke, u protivnom podaci moraju biti odbijeni . Import podataka se treba vršiti na više

načina. Jedan način je dostavljanje podataka u XML file-u koji bi se importovao u bazu kroz aplikaciju.

Struktura XML datoteke bi bila jasno definisana i sve XML datoteke se moraju uklapiti u XML šemu

koja bi bila predložena/dostavljena od strane sistema svim društvima. XML datoteka treba biti

organizovana tako da je čitljiva bazi i import podataka iz njega bi se odvijao brzo, jednostavno i

korisnički transparentno.

Također, mogude je predložiti klijentsku desktop aplikaciju, ili WEB modul unutar aplikacije

jedinstvene knjige štetnika koja bi mogla da provjeri XML datoteku koju treba poslati. Sama WEB

aplikacija mora sadržati kontrolni mehanizam upozorenja korisnika.

Drugi način bi bio slanje strukturirane datoteke (npr. CSV), gdje bi se poštovala identična procedura

kao i kod XML datoteke. Ukoliko bi došlo do greške prilikom importa, neophodno je implementirati

log sistem za detekciju greške i upozoravanje korisnika, gdje bi se detektovale i upisale sve ispravne i

neispravne akcije nad sistemom.

Tredi način importa podataka bi bio import iz Excel datoteke. Excel datoteka treba biti jasno

definisana (tačan naziv sheet-a, kolona, struktura redova itd.) i import bi se odvijao po logici

specificiranoj u prva dva slučaja.

U sistemu je neophodno implementirati dodatne mehanizme kontrole (provjera broja polica,

popunjenost obaveznih polja, odgovarajuda polja pripadaju odgovarajudem osiguravajudem

društvu...) koji de korisnika izvještavati o mogudem problemu, uspjehu importa i slično.

1.3.2. Import podataka štetnika

Po sličnoj logici importa kao i kod importa podataka polica postupilo bi se i pri importu podataka

štetnika. Implementacija kontrolnih mehanizama za provjeru ispravnosti importa, bilježenje i

izvještavanje za svaku akciju nad sistemom je obavezna. Potrebno je omoguditi kvalitetan

mehanizam podešavanja kriterija provjere importa od strane Udruženja društava za osiguranje FBiH.

1.3.3. Distribucija podataka

Mehanizme distribucije podataka potrebno je obezbijediti preko više kanala. Svaki kanal

podrazumijeva kvalitetno definisanu i implementiranu autorizacionu politiku.

WEB aplikacija - dostupna korištenjem WEB tehnologija

WEB servisi – interfejs namijenjen za automatsko uvezivanje sistema društava za osiguranje,

Udruženja i drugih autoriziranih...

SMS interackija – jednostavnim, predefinisanim SMS upitima je potrebno poslati odgovor

korisniku sa tačnom informacijom iz baze (u smislu JMB:xxxxx dati odgovor iz baze o štetniku

sa JMB-om xxxx i sl.). Omoguditi jednostavne i jasno predefinisane SMS inserte koji

autoriziranom licu omogudavaju da sudjeluje u dopunjavanju baze. Sve to implicira da de

sistem morati posjedovati vlastiti, sigurnan i transparentan SMS protokol za rad nad

sistemom sa implementiranim mehanizmima detekcije greške.

Sarajevo, februara-veljače 2010. godine Odbor za informatiku

2. Sadržaj

1. INFORMATIČKO RJEŠENJE JEDINSTVENE BAZE ŠTETNIKA – PROJEKTNI ZADATAK ......................... 1

1.1. Okvir projekta .......................................................................................................................... 2

1.1.1. Osnovni principi i koncepti informacionog sistema ........................................................ 2

1.2. Tehničke specifikacije jedinstvene knjige štetnika .................................................................. 6

1.2.1. Centralna baza podataka ................................................................................................. 7

1.2.2. Web aplikacija za upravljanje podacima ......................................................................... 7

1.2.3. Interfejsi za elektronsku razmjenu podataka .................................................................. 8

1.3. Logika rada i tok podataka ...................................................................................................... 9

1.3.1. Import podataka polica ................................................................................................... 9

1.3.2. Import podataka štetnika .............................................................................................. 10

1.3.3. Distribucija podataka ..................................................................................................... 10

2. Sadržaj ........................................................................................................................................... 11