VELEUČILIŠTE U SPLITU

ODJEL RAČUNARSTVA

Ksenija Klasić
Karmen Klarin

INFORMACIJSKI SUSTAVI

SKRIPTA

Split, listopad 2003.

SADRŽAJ

1. Informacijski sustav u poslovanju

1.1. Definicija sustava, poslovnog sustava i njegovog informacijskog sustava 1
1.2. Kratki prikaz povijesti razvoja informacijskih sustava 8
1.3. Vrste informacijskih sustava 10
1.4. Zablude o uspješnosti informacijskih sustava i informacijska kriza 14

2. Organizacija poslovnog informacijskog sustava

2.1. Organizacija informacijskog sustava 22
2.1.1. Centralizirana organizacija informacijskog sustava 23
2.1.2. Decentralizirana organizacija informacijskog sustava 25
2.1.3. Distribuirana organizacija informacijskog sustava 26
2.1.4. Klijentsko poslužiteljska arhitektura informacijskog sustava 30
2.2. Organizacijska kultura poslovnog sustava i organizacija informacijskog
sustava 32
2.3. Organizacijska zrelost i planiranje razvoja informacijskog sustava 33
2.3.1. Nolanova podjela faza informatičkog razvoja poduzeća 33
2.3.2. Faze životnog ciklusa informacijskog sustava 37
2.3.3. Informacijski inženjering 38
2.3.4. Elementi jedinstvenosti informacijskog sustava 40

3. Planiranje razvoja informacijskog sustava

3.1. Strateško planiranje informacijskog sustava 42
3.1.1. Uloga poslovodstva u procesu planiranja 42
3.1.2. Faze strateškog planiranja informacijskog sustava 42
3.1.3. Kratki prikaz metodika za strateško planiranje informacijskog
sustava 44
3.2. Analiza poslovnog sustava 49
3.2.1. Strateška analiza poslovanja organizacijskog sustava 51
3.2.2. Preoblikovanje poslovnih procesa (BPR) 51
3.2.3. Izrada “grubog” modela podataka 52
3.2.4. Određivanje temeljne arhitekture IS-a 53
3.2.5. Analiza postojećih informacijskih podsustava i utvrđivanje
potrebnih promjena 54
3.2.6. Određivanje prioriteta razvoja pojedinih informacijskih podsustava 54
3.3. Dekompozicija ciljeva, funkcija i procesa poslovnog sustava 55
3.3.1. Model procesa 55
3.3.2. Model resursa 58
3.4. Tehnika matričnih dijagrama 59
3.4.1. Matrica procesa i klasa podataka 59
3.4.2. Dijagonalizacija matrice i oblikovanje podsustava 63
3.4.3. Unutrašnja konzistentnost i vanjska povezanost podsustava 67
3.5. Određivanje osnovne arhitektura informacijskog sustava 70
3.5.1. Analiza sklonosti između procesa 71
3.5.2. Mjera kvalitete strukture informacijskog sustava 76

i
4. Izvedba informacijskog sustava
4.1. Analiza poslovnog podsustava 85
4.1.1. Dijagram tijeka dokumenata (podataka) 86
4.1.2. Radni dijagram (workflow) 90
4.1.3. Specifikacija zahtjeva 93
4.2. Administracija podataka 97
4.2.1. Rječnik podataka. 97
4.2.2. Poslovi administracije podataka 100
4.2.3. Model podataka 104
4.2.4. Osnovni pojmovi ERA modela - entitet, atribut, relacija (veza) 105
4.3. Šifarski sustavi 111
4.3.1. Izvori šifarskih sustava 111
4.3.2. Oblikovanje šifarskih sustava 111
4.3.3. Upravljanje šifarskim sustavima u poduzeću 114
4.4. Uvođenje informacijskog sustava u primjenu 114
4.4.1. Specifikacija prototipa 114
4.4.2. Testiranje, uvođenje i održavanje informacijskog sustava 116

5. Primjena CASE pomagala

5.1. Uloga i uporaba CASE pomagala 120
5.2. Vrste CASE pomagala 122
5.3. Modeli zrelosti informacijskog sustava 124

6. Kvaliteta informacijskog sustava i zaštita od zloporaba

6.1. Kvaliteta informacijskog sustava 127
6.2. Zaštita informacijskog sustava 130

7. Seminarski primjer - Poslovanje trgovine

7.1. Sustavni postupak izgradnje informacijskog sustava 132
7.2. Primjer seminarskog rada «Poslovanje trgovine» 135
7.3. Zadaci za vježbu 181

Literatura

ii
1. Informacijski sustav u poslovanju

Definicija sustava, poslovnog sustava i njegova informacijskog sustava

Kratki prikaz povijesti razvoja informacijskih sustava
Vrste informacijskih sustava
Zablude o uspješnosti informacijskih sustava i informacijska kriza

1.1. Definicija sustava, poslovnog sustava i njegovog

informacijskog sustava

Riječ «sustav1» koristi se često u svakodnevnom govoru, pri čemu se smisao mijenja ovisno o
kontekstu. Primjerice, značenja političkog i zvjezdanog sustava sigurno su različita, ukoliko
se zvjezdani sustav odnosi na astronomske kategorije određenih tijela u svemiru - zvijezda (a
ne na političke «zvijezde»). Politički sustav u kojem postoji samo jedan element, samo jedan
političar, ne može se smatrati sustavom, kao niti zvjezdani sustav samo s jednom zvijezdom.
Ipak, čak i u ovom slučaju može se prepoznati nešto zajedničko – mora postojati niz dijelova
ili elemenata (dakle, zvijezda odnosno političara) koji djeluju sa svrhom postizanja
određenog, specifičnog cilja. Za politički sustav će to značiti promjene političkih programa
što se često događa nakon unosa novih ideja i ljudi u sustav, ali i izlaza određenog broja osoba
koje se ne mogu prilagoditi. U zvjezdanom sustavu će ulaz nekog novog objekta prouzročiti
različite transformacije sustava, čije posljedice mogu biti uništenje nekog nebeskog tijela.
Stoga vrijedi:
Sustav je svaki uređen skup od najmanje dva elementa koji zajedno interakcijom ostvaruju
funkciju cjeline.
Pri tome je cilj sustava transformacija različitih vrsta ulaza u izlaz. Transformacija se
obavlja djelovanjem različitih procesa u sustavu, ovisno o prirodi promatranog
sustava.

Ulaz 1 Izlaz 1
Proces
Ulaz 2
. u Izlaz 2
sustavu
.
. .
Ulaz n Izlaz m

Slika 1. Opći model sustava

1
Prema Klaić, B: Veliki rječnik stranih riječi, Zagreb, 1968, str. 122. riječ “sustav” zamjenjuje riječ “sistem”, a
znači poredak uvjetovan planskim, pravilnim raspoređajem dijelova u međusobnoj vezi.
1
Sustavi u prirodi su više ili manje složeni. Svaki složeni sustav sastoji se od niza
elementarnih sustava (podsustava), koji mogu biti više ili manje povezani2. Međusobna
djelovanja i veze među podsustavima zovu se sučelja.
Ako u sustavu postoji više od dva podsustava, njihove veze se prikazuju pomoću matrica
veza. Sve takve matrice veza povezuju se u jednu veliku matricu, tzv. matricu strukture
sustava.
Za neki složeni sustav S koji se sastoji od s podsustava vrijedi:
S = { S1, S2, … , SS }, gdje je S – sustav,
S1, …, SS – podsustavi,
s – broj podsustava
Može se pisati i:
S = S1 ∪ S2 ∪ … ∪ Ss
s
S= U
i =1
Si

Najveći broj veza između podsustava postoji u sustavu onda kada je svaki od podsustava
vezan sa svakim drugim podsustavom osim sa samim sobom. U tom slučaju je maksimalan
broj matrica veza v max = s (s - 1) , a minimalan v min = s - 1 .

PRIMJER:
Neka se sustav sastoji od 3 podsustava. Tada najveći broj matrica veza iznosi
3 x (3-1) = 3 x 2 = 6, a najmanji 3 – 1 = 2 (slika 2.).

S1 S1

1 1

2 6
4
S S S3

5 S3

S2 S2 2

Slika 2.: Maksimalni i minimalni broja veza između tri podsustava

2
Radošević, D: Teorija sistema i teorija informacija, str. 184., FOI, Varaždin, 1975.
2
Sustav s većim brojem veza ima kruću strukturu, pa je manje prilagodljiv promjenama u
vremenu, što neosporno negativno utječe na njegovu funkcionalnost. Stoga za postizanje bolje
funkcionalnosti cijelog sustava sustav treba strukturirati tako da svaki podsustav ima što
manje veza s ostalim podsustavima kao i s okruženjem. U praksi okruženje može imati
ključnu ulogu u ispravnom funkcioniranju sustava3.
Veze u sustavu prikazuju se potpunom matricom strukture sustava, koja se uvijek sastoji
od četiri submatrice. Osim veza među podsustavima uvijek se prikazuju i veze podsustava sa
okruženjem:

⎛ S oo S os ⎞
S=⎜ ⎟
⎜ ⎟
⎝ S so S ss ⎠
S oo submatrica strukture okruženja. Ta matrica gotovo uvijek ostaje nedefinirana u
cijelosti, jer u većini slučajeva nije moguće istražiti veze unutar okruženja.
S os submatrica veza između okruženja O i sustava S. Ova matrica sastoji se od samo
jednog retka i obuhvaća one veze koje izlaze iz sustava.
S so submatrica veza između sustava S i okruženja O. Ova matrica sastoji se od samo
jednog stupca i obuhvaća one veze koje iz okruženja ulaze u sustav.
S ss interna matrica strukture sustava S .
Dakle, potpuna matrica strukture sustava može se prikazati grafički kao na slici 3.

S oo (okružje) S os (izlazi iz sustava)

O S1 S2 S3 S4 S5

O Vo3 Vo5

S1 0 V15

S2 V2o 0

S3 V3o 0

S4 V41 0

S5 V51 V52 0

S so (ulazi u sustav) S ss (interna struktura)

Slika3. Potpuna matrica strukture sustava S

3
Primjerice, kada je 2003. godine zakonom ukinuto pravo korištenja jedinstvenog matičnog broja građana za
svrhe za koje matični broj nije namijenjen, roditelji novorođene djece nisu mogli prijaviti dijete u zdravstveno
osiguranje jer im nije bio poznat djetetov JMBG. Naime, aplikacija je prvo tražila prijavu novog JMBG-a a
zatim je tek bilo moguće obaviti posao. Za zdravstveni sustav podatak o JMBG-u je podatak iz okruženja, jer
nastaje izvan sustava.
3
S obzirom na njihovu povezanost s okruženjem, sustave dijelimo na zatvorene i otvorene.
Otvoreni sustavi razmjenjuju informacije, materiju i energiju s okruženjem i nastoje poprimiti
oblik i strukturu koja im omogućava da se prilagode promjenama u okruženju.
Imaju svojstvo samoorganiziranja u smislu da mijenjaju svoju organizaciju u odnosu na
promijenjene uvjete iz okoline.
Otvoreni sustavi s okruženjem imaju barem jednu nenultu matricu veze.
Zatvoreni sustavi su odvojeni od okruženja, ne razmjenjuju materiju, informacije ili energiju
sa svojim okruženjem.
U zatvorenim sustavima matrice S os i S so su nulte matrice, jer nemaju veze s
okruženjem.
Entropija je mjera neizvjesnosti u budućnost sustava odnosno mjera neorganiziranosti
sustava, koja raste s vremenom. Svaki zatvoreni sustav mora se u budućnosti raspasti ili
postati neorganiziran.
U prirodi su sustavi samo relativno zatvoreni jer nije moguće postići punu izolaciju od
utjecaja okoline. Takvi sustavi imaju kontrolirane i dobro definirane ulaze i izlaze. Stoga će se
nadalje razmatrati zatvoreni poslovni sustavi, dakle takvi sustavi koji iz okruženja ne primaju
ali niti okruženju ne predaju podatke.

Poslovni sustav je organizacijski sustav kojeg opisuje skup informacija o prošlosti i

sadašnjosti i poslovnih procesa koji ih obrađuju4.

U poslovni sustav ulaze sirovine, energija, poruke, dokumenti, a izlaze proizvodi i dokumenti.
Dakle, poslovni sustav karakteriziraju materijalni ulazi i izlazi i informacijski tokovi.
Sudionici u tom procesu transformacije ulaza u izlaze mogu biti osobe – izvršitelji posla,
razni strojevi i alati. Da bi se poslovni sustav mogao obavljati svoju funkciju potrebne su mu
informacije. Stoga svaki poslovni sustav posjeduje vlastiti informacijski sustav, kojim se
obrađuju podaci o svim segmentima poslovanja.

Informacijski sustav dio je svakog poslovnog sustava čija je funkcija neprekidna opskrba
svih razina upravljanja, odlučivanja i svakodnevnog poslovanja potrebnim informacijama.

Budući da se informacijski sustav razvija za realni poslovni sustav poslovni procesi realnog
sustava temelj su za modeliranje strukture njegova informacijskog sustava. Primjerice,
prikupljanje, obrada te korištenje podataka u poslovnim procesima poduzeća temelj je svakog
poslovanja. Pri tomu se neki od poslovnih procesa znatno razlikuju jer ovise o djelatnosti
poduzeća, dok je dio njih gotovo jednak za sve. To se posebno odnosi na knjigovodstveno
računovodstvene postupke gdje, sa stajališta općeg modela poslovnih procesa na logičkoj
razini, nema znatne razlike u postupcima i procedurama. Iz navedenog proizlazi da svako
poduzeće posjeduje vlastiti informacijski sustav koji može, ali i ne mora, biti podržan
računalom (u svojim segmentima ili u cijelosti).

Poslovni sustavi su u pravilu složeni sustavi. Jednostavan poslovni sustav u praksi znači da se
radi o poslovnom sustavu u kojem se razmatra ili samo dio poslovnih funkcija, ili je njegova
4
Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997.
4
složenost nešto manja zbog ukupnog obima posla koji obavlja (iako ne mora uvijek biti
tako5).
Informacijski sustav koji podržava složeni poslovni sustav sastoji se od niza
informacijskih podsustava, a svaki od njih može se smatrati elementarnim
informacijskim sustavom.

Dakle, zadaci informacijskog sustava su:

• prikupljanje,
• razvrstavanje,
• obrada,
• čuvanje,
• oblikovanje i
• raspoređivanje
podataka svim radnim razinama poslovnog sustava.

Važno je odrediti što se zapravo obrađuje u informacijskom sustavu. Uglavnom se radi o

podacima koji, sami za sebe, nemaju neko značenje. Primjerice, podatak pohranjen na
računalu može biti i broj «1.000». Što znači taj broj, taj podatak? To može biti cijena od 1.000
kn za neki artikl, ali to može biti i 1.000 EUR duga prema nekome ili od nekoga. Drugim
riječima, podatak je činjenica o nečemu iz realnog svijeta, dok je informacija interpretacija
podatka koja ima subjektivno značenje za primatelja. Informacijski sustav «proizvodi»
informacije tako da podatke obrađuje, organizira i prikazuje na način razumljiv korisniku, koji
onda tako pripremljene podatke interpretira i na temelju njih donosi odluke u skladu s svojim
ovlaštenjima.

Zato su ciljevi informacijskog sustava različiti za različite radne razine (tablica 1). Najčešće
se koristi podjela na tri radne razine: razinu izvođenja, razinu upravljanja i razinu odlučivanja.
Razina izvođenja je operativna razina, na kojoj se obavljaju aktivnosti osnovne djelatnosti. Te
poslove obavlja najveći broj izvršilaca. Razina upravljanja je taktička razina, na kojoj se
nalazi srednje rukovodstvo koje organizira posao, upravljaj poslovnim procesima i prati
uspješnost rada. Razinu odlučivanja ili stratešku razinu čine najviša poslovodstva poslovnih
sustava koja donose smjernice za dalji rast i razvoj sustava odnosno postavljaju poslovne
ciljeve. Često se te razine prikazuju grafički (slika 4.).
S t r a t e š k a r a z in a
( r a z i n a o d lu č iv a n ja )

T a k t ič k a r a z in a
( r a z in a u p r a v lja n ja )

O p e r a t iv n a r a z i n a
( r a z i n a i z v o đ e n ja )

Slika 4. Razine upravljanja u organizacijskom sustavu

5
Složenost sustava određena je brojem procesa koji se u njemu obavljaju ali količinom podataka odnosno
dokumenata koji se u sustavu rabe.
5
 Razina funkcija organizacijskog sustava Cilj informacijskog podsustava

IZVOĐENJE procesi osnovne djelatnosti povećanje produktivnosti rada

UPRAVLJANJE razina odgovorna za organiziranje, povećanje učinkovitosti

praćenje uspješnosti, otklanjanje smetnji

ODLUČIVANJE razina odgovorna za postavljanje osiguranje stabilnosti rasta i razvoja

poslovnih ciljeva
Izvor: Brumec, J.: Strateško planiranje IS-a, FOI Varaždin, 1997.

Tablica 1. Ciljevi informacijskih podsustava

Predmet razmatranja bit će samo zatvoreni poslovni sustav prikazan matricom S ss odnosno
matricom interne strukture sustava S. Podaci koji nastaju u okruženju, ondje se obrađuju i
povratno utječu na promatrani poslovni sustav, nisu zanemarivi u poslovnom smislu, ali ne
utječu na interno strukturiranje i funkcioniranje informacijskog sustava6.
Podaci iz okoline moraju se uključiti u poslovni sustav i to se obavlja unosom podataka u
informacijski sustav. Proces unosa podataka može se zamijeniti procesom prijenosa podataka
koji su potrebni korisniku, pri čemu se unutarnja struktura informacijskog sustava neće bitno
promijeniti (novi proces ostati će sastavnim dijelom onog podsustava kojem je pripadao stari),
a funkcionalnost će biti ostvarena.

PRIMJER:
Na slici 5. prikazan je jedan organizacijski sustav i jedan od njegovih pripadajućih
informacijskih podsustava, te primjeri ulazno/izlaznih podataka i procesa kao osnovnih
dijelova tog podsustava.
Složeni poslovni sustav visokoškolskog obrazovanja sadrži nekoliko elementarnih
podsustava (slika a). Pretpostavka je da se želi informatizirati odnosno informatički
podržati dio ovog složenog sustava koji obrađuje procese studiranja i stjecanja diplome.
Tada minimalan broj međusobno povezanih podsustava koji čine cjelinu predstavljaju
podsustavi za evidenciju nastavnika i studenata i podsustav koji obrađuje podatke
vezane uz studiranje tijekom vremena (slika b).
Zadatak sustava je transformacija različitih ulaza u izlaze (slika c), pa su ulazi u
informacijski sustav «Studiranje» podaci o nastavniku, studentu, predmetu, prijavnici i
drugo. Izlazne informacije su rezultati obrade ulaznih podataka, pa je primjerice,
evidencija prisustva nastavi rezultat obrade podataka o nastavniku, predmetu i studentu
u nekom vremenskom periodu u kojem student sluša određeni predmet.
Transformacije ulaza u izlaze događaju se djelovanjem različitih procesa u sustavu.
Primjerice, na kraju semestra može se obradom ulaznih podataka koji su nastali
bilježenjem prisustvovanja studenata nastavi izraditi izlazno izvješće «Evidencija
prisustva nastavi» (slika d).

6
Ako podaci iz okoline značajno utječu na funkcioniranje informacijskog sustava potrebno ga je izuzetno
pažljivo oblikovati kako bi bio što neovisniji.
6
 Sustav visokoškolskog obrazovanja
Slika a)
1. Kadrovska evidencija (nastavnici, ostali zaposlenici)
2. Evidencija studenata
3. Studiranje i stjecanje diplome - upis studenata
- pohađanje nastave
- polaganje ispita
- izrada diplomskog rada
- obrana diplomskog rada
4. Financijsko-knjigovodstveni poslovi - nabava materijala
- blagajničko poslovanje
- obračun plaća ...
5. Znanstveno-istraživački rad
...
IS Studiranje
student sluša
predmet
Evidencija
studenata
student polaže
predmet
ocjena student
predmeta prijavi
Slika b) Studiranje
predmet
i stjecanje
diplome
Evidencija
nastavnika
nastavnik
predaje
predmet

Nastavnik Raspored sati

Student Evidencija prisustva nastavi

Slika c) IS Ocjena
Predmet Studiranje
Zvanje
Prijavnica
Diploma
... ...

Nastavnik Sastavljanje rasporeda sati Raspored sati

Student Održavanje nastave Evidencija prisustva nastavi
Slika d)
Predmet Polaganje ispita Ocjena
Zvanje
Prijavnica Obrana diplomskog rada
Diploma
...

PROCESI
ulazni izlazni
PODACI

Slika 5. Primjer sustava i informacijskog sustava

7
1. 2. Kratki prikaz povijesti razvoja informacijskih sustava
Česta zabluda je da poslovni sustavi koji ne koriste računala u poslovanju nemaju ni
informacijski sustav. Međutim, ponekad se unatoč računalima koriste i kartoteke, u kojima se
nalaze podaci od interesa (primjerice, u knjižnicama kartice autora i naslova), pohranjeni na
papiru. Stoga se može ustvrditi da je informacijski sustav svaki sustav koji se koristi u
poslovanju sa zadatkom prikupljanja, razvrstavanja, obrade, čuvanja i raspoređivanja
podataka i on NE mora biti podržan računalom. Povijest razvoja informatike govori o tomu
kako su se dostupnim tehničkim sredstvima obrađivali podaci potrebni u svakodnevnom
životu i radu. Moguće je razlučiti četiri osnovne faze u razvoju načina obrade podataka7, pri
čemu se, unatoč povijesnoj distanci neke od njih i danas primjenjuju.

1. Faza ručne obrade podataka odlikuje se sporom obradom podataka, pri čemu se
koristi rad ruku, medij za pohranu podataka i dostupni alati za pisanje po tom mediju8.
Na taj način obrađivana je relativno mala količina podataka, pri čemu je obrada bila
nepouzdana, a njena točnost upitna. Niska produktivnost rada nadoknađivana je
upotrebom velikog broja ruku koji su evidentirali podatke (pisara), što je bilo izuzetno
cijenjeno zanimanje.

2. Faza mehaničke obrade podataka posljedica je općeg razvoja znanosti i tehnike.

Počinje od sredine 17. stoljeća, kada su konstruirani prvi pomoćni uređaji za obradu
podataka. Poznati matematičari i fizičari tog vremena ujedno su bili i njihovi
konstruktori (primjerice, Blaise Pascal konstruirao je uređaj koji se smatra pretečom
današnjih analognih računala, a Gottfried Leibniz uređaj koji se smatra pretečom
današnjih digitalnih računala). Henry Mill konstruirao je prvi mehanički pisaći stroj
čime je značajno utjecao ne samo na razvoj informacijske znanosti, nego i na
društvene odnose u cjelini9.
Ovu fazu odlikuje povećanje produktivnosti, točnosti i količine obrađenih podataka.

3. Faza elektromehaničke obrade podataka počela je u drugoj polovici 19. stoljeća,

kada je vlada SAD raspisala javni natječaj za konstruiranje uređaja kojim bi se podaci
popisa stanovništva mogli obraditi u što kraćem roku10. Hermann Hollerith je
pobijedio s prijedlogom da se kao nositelj podataka koristi bušena kartica (koju je
izumio Jacquard i primijenio je za upravljanje tkalačkim stanom što se smatra
početkom automatizacije proizvodnih procesa), a za njihovu obradu da se upotrijebi
poseban elektromehanički uređaj. Time je omogućena masovna obrada velike količine
podataka, a Holerith se obogatio i osnovao tvrtku iz koje se 1924. godine razvio IBM
(International Business Machines). Ova faza u literaturi se često naziva i fazom
kartične, mehanografske ili birotehničke obrade podataka.

7
Panian, Ž.: Poslovna informatika, Potecon, Zagreb, 2001, str. 45.-48.
8
Medij može biti kamen, na kojem su stari Egipćani urezivali simbole kojima su opisivali i evidentirali zbivanja
iz svakodnevnog života, papirus po kojem se pisalo trstikom, glinene pločice s klinastim pismom i konačno
papir, na kojima su pisari vodili poslovne knjige odnosno zapise o ljetini, porezu i slično.
9
Poslovi pisanja na pisaćem stroju postaju cijenjenim ne samo za muškarce, nego i za žene. Na taj način ženama
je omogućeno dulje i kvalitetnije školovanje, a kao završene tipkačice mogle su se samostalno uzdržavati.
10
Popisi stanovništva radili su se i u starom vijeku, no njihova obrada radila se ručno i trajala je dugo.
Najpoznatiji popis stanovništva iz tog doba opisan je Bibliji, prilikom Kristova rođenja.
8
 4. Faza elektroničke obrade podataka počinje 1944. godine s razvojem ENIAC-a koji
se smatra prvim «pravim» elektroničkim računalom. Ova faza odlikuje se iznimno
velikom brzinom obrade velike količine podataka i zanemarivim brojem grešaka.
Omogućeno je privremeno i trajno pohranjivanje podataka, te povezivanje operacija
nad podacima (obrada i prijenos podataka, integracija obrade teksta, grafika, slika i
zvuka). U ovu fazu spada i Internet kao najnoviji, uz ostale svoje funkcije, danas sve
rasprostranjeniji način obrade podataka.

U malim poduzećima i danas se često većina poslova radi ručno. Na odluku o primjeni
računala u svakodnevnom poslovanju odnosno računalom podržanog informacijskog sustava,
utječu sljedeći kriteriji:
Velika količina podataka koju je potrebno pohranjivati i obrađivati najznačajniji je kriterij
za donošenje odluke o informatizaciji poslovanja. Primjerice, nije svejedno radi li se u
poduzeću obračun plaće za dva zaposlenika ili dvije stotine zaposlenika. Za mali broj ljudi
obračun plaće je jednostavnije (i često jeftinije) napraviti ručno, dok za velik broj zaposlenika
obrada će biti točnija i značajno kraća uz primjenu odgovarajućeg računalnog programa.
Pad cijene materijalno tehničke komponente (engl. Hardware) učinio je računala
dostupnim ne samo poduzećima nego i privatnim osobama. Stoga se novoosnovana poduzeća
sve češće odlučuju na kupnju informatičke opreme odmah na početku rada, dok poduzeća
koja posluju dulje na tržištu nešto sporije obnavljaju i proširuju postojeću opremu.
Kvaliteta i mogućnosti nematerijalne komponente informacijskog sustava (engl.
Software) trebala bi biti presudna pri donošenju odluke o informatizaciji. Velik broj gotovih
programskih rješenja koje je moguće relativno jeftino nabaviti na tržištu, kao i mogućnost
razvoja softvera «po mjeri», razlog su informatizaciji poslovanja u velikom broju tvrtki.
Informacijska zrelost ljudskih resursa (engl. Lifeware) utječe na brzinu uvođenja računala
u poslovanje. Još uvijek je moguće pronaći tvrtke gdje zaposlenici odbijaju raditi na
računalima11 (smatraju se prestarim za učenje nečeg novog ili se jednostavno boje računala pa
traže razne izgovore za održavanje ručnog rada, ili čak nemaju adekvatnu školsku spremu ni
znanja za posao koji obavljaju pa se boje za svoje radno mjesto). Poznavanje rada na računalu
postalo je jedan od uvjeta pri zapošljavanju, tako da mladi potiču informatizaciju poslovanja.
Razvoj i dostupnost sredstava i veza za prijenos podataka i komunikaciju (engl.
Netware) omogućio je širenje tržišta za proizvode i usluge poduzeća, te bolju komunikaciju i
povezanost unutar poduzeća i s okolinom. Omogućio je i rad od kuće (na daljinu), veću
fleksibilnost radnog vremena, ali i rad «od jutra do sutra». Utjecaj komunikacijskih
tehnologija posebno je značajan u formiranju novih usluga i otvaranju novih radnih mjesta na
poslovima računalima podržanog poslovanja (povezivanja poduzeća s poslovnim bankama i
plaćanja putem Interneta, prodaja proizvoda putem web-a, kao što radi tvrtka Amazon i
slično).
Organizacijska zrelost poslovnog sustava (engl. Orgware) predstavlja sve mjere, metode i
propise kojima se usklađuje rad prethodne četiri komponente, pa stoga ako poduzeće nije na
adekvatnoj organizacijskoj razini nema niti kvalitetne informatizacije poslovanja. Iskustvo je
pokazalo da u tvrtkama u kojima je organizacija poslovanja loša i informacijski sustav je loš.
Pri tome uvođenje računala neće odmah riješiti probleme, jer informacijski sustav se gradi na
temelju pravila koja postoje (ili ne postoje) u poslovnom sustavu. Uvođenje informacijskog
sustava podržanog računalom utječe na organizacijsku zrelost tvrtke, te dugoročno uvodi red
u organizacijski kaos.

11
Taj problem posebno je izražen kod zaposlenika u državnoj upravi.
9
S obzirom na to da su prva računala bila jako skupa, a njihov značaj je bio od državne
važnosti, na početku su razvijani vojni sustavi. Međutim, mogućnost jeftinije, brže i točnije
obrade velike količine podataka prema jasnim i definiranim pravilima utjecala je na razvoj
programske podrške za knjigovodstvo i računovodstvo. Iako je računalna podrška potrebna i
drugim segmentima poslovanja, skupa računala i programe kupovali su članovi poslovodstava
poduzeća zaduženi za financijske poslove12. Idući korak bila je podrška kadrovskoj operativi,
najčešće u obliku programa za obračun plaća (ponovno je moguće prepoznati vezu s izvorom
financiranja nabave opreme i softvera). Tek nakon toga počela je primjena računala za
podršku proizvodnji, jer su proizvodni procesi složeniji, razlikuju se ovisno o vrsti
proizvodnje i teže ih je implementirati. Programska podrška poslovodstvu posljednja je
uvedena u primjenu u društvu, ali samo u veoma malom broju poduzeća.

1.3. Vrste informacijskih sustava

Kriteriji za podjelu informacijskih sustava su različiti. Najčešće se koriste podjele prema
konceptualnom ustrojstvu poslovodstva, prema namjeni ili prema modelu poslovnih funkcija
u poslovnom sustavu. U praksi ponekad u jednom poduzeću nema strogih granica između dva
podsustava, koji su u drugom poduzeću strogo odvojeni.

Na slici 4. prikazane su razine upravljanja u organizacijskom sustavu. S obzirom da su

nadležnosti i zadaci svake razine drugačiji, njihovi informacijski sustavi također se moraju
razlikovati (tablica 2.).

Ustroj poslovodstva Vrste IS-a

Poslovodstvo Strateški nivo Odlučivanje Sustav potpore odlučivanju

Izvršno vodstvo Taktički nivo Upravljanje Izvršni informacijski sustavi

Operativno vodstvo Operativni nivo Izvođenje Transakcijski sustavi

Tablica 2. Vrste informacijskih sustava prema konceptualnom ustroju poslovodstva

Operativnoj razini namijenjeni su transakcijski sustavi, namijenjeni za izvođenje procesa
osnovne djelatnosti. To mogu biti sustavi kojima se knjiže bankarske transakcije ili sustavi
kojima se evidentiraju pojedini koraci u proizvodnji. Taktičkoj razini namijenjeni su izvršni
informacijski sustavi čiji rezultat su izvješća nužna za upravljanje, a strateškoj razini sustavi
potpore odlučivanju.

Prema namjeni se informacijski sustavi dijele na sustave obrade podataka, sustave podrške
uredskom radu, sustave podrške u odlučivanju i ekspertne sustave13.

Sustavi obrade podataka služe za unos, obradu i pohranjivanje podataka o stanju sustava i
poslovnim događajima. Podaci su pohranjeni u bazama podataka i njima se pristupa uz pomoć

12
I danas je u velikom broju tvrtki za informatiku zadužen direktor za financijske poslove. Ponekad je takva
organizacija prepreka za dalja ulaganja u informacijske tehnologije i njihovu primjenu u ostvarenju boljeg
poslovnog rezultata.
13
Prema Čerić et al: Poslovno računarstvo, Znak, Zagreb, 1998., str. 36.
10
posebnih programa za pretraživanje baze podataka. Na temelju obrađenih podataka izrađuju
se izvješća potrebna za izvođenje procesa osnovne djelatnosti ali i za upravljanje.
Sustavi podrške uredskom radu dijele se na sustave za podršku u obavljanju
administrativnih poslova i na sustave za podršku ljudskog komuniciranja. Uz sustav za obradu
dokumenata koriste se pomoćni sustavi za potporu rada u skupini, prezentacije i slično, dok se
za podršku komuniciranju koriste elektronička pošta, telekonferiranje itd.
Kod sustava podrške u odlučivanju primjenjuju se različiti modeli odlučivanja kojima se
stvaraju informacije potrebne za odlučivanje, kao podrška pojedincu i grupi.
Ekspertni sustavi podrška su stručnjacima i ekspertima, te služe za rješavanje različitih
problema, primjerice konfiguriranja i dijagnosticiranja. U ovu kategoriju najčešće spadaju i
sustavi podrške posebnim problemskim područjima koji se odnose na podršku učenju,
podršku znanstvenom i stručnom radu ili podršku projektiranju.

U tablici 3. dan je usporedni prikaz važnijih obilježja različitih vrsta informacijskih sustava
prema namjeni14.

Sustavi obrade Sustavi uredskog Sustavi podrške Ekspertni

podataka poslovanja odlučivanju sustavi
Područje dobro strukturirana dobro strukturirani djelomično uska problemska
primjene problemska područja ponavljajući uredski strukturirani područja za koja
čiji se procesi mogu poslovi procesi donošenja trebaju ekspertna
strukturalno opisati odluka znanja
Težište - prikupljanje i - podrška komuniciranju - izdvajanje - rješavanje
računalne pohranjivanje korisnika sa okružjem podataka potrebnih problema
podrške podataka u bazama - korištenje javnih servisa za odlučivanje iz konfiguriranja i
podataka o prošlim - definiranje uredskih baza podataka planiranja
stanjima objekata, procedura koje uključuje - prikupljanje i - rješavanje
događajima i vremenske kontrole pohranjivanje problema
transakcijama - obrada teksta vlastitih podataka dijagnosticiranja
- automatizirane - pretraživanje i obrada - definiranje - obogaćivanje
obrade podataka o dokumenata koji sadrže dijaloga i ulaznih sustava novim
prošlim stanjima tekst, sliku i zvuk podataka, ulaznih znanjima
objekata, poslovnim - upravljanje podataka te izbor - objašnjavanje
događajima i dokumentima modela načina rješavanja
transakcijama - prikazivanje podataka i - rješavanja problema
- automatizirane informacija problema
obrade prikupljenih - tablični kalkulatori - izbor oblika
podataka za kontrolu - terminiranje poslova i prikazivanja
i obračun mrežno planiranje izlaznih rezultata
- izvješćivanje o - postavljanje upita na
prikupljenim i bazu
obrađenim podacima - definiranje
i informacijama jednostavnijih procedura
za rad sa bazama

14
Prema Strahonja, V. et al.: "Projektiranje informacijskih sustava", Zavod za informatičku djelatnost RH i Ina Info,
Zagreb, 1992., str. 36.-37.
11
 Sustavi obrade Sustavi uredskog Sustavi podrške Ekspertni
podataka poslovanja odlučivanju sustavi
Programska programi za unos, - programska pomagala za - programi za programska
sredstva i pretraživanje baze i kreiranje, pretraživanje, definiranje pomagala i ljuske
pomagala obradu podataka obrađivanje i dijaloga, izdvajanje za unos i
pohranjivanje podataka iz baze organiziranje
dokumenata postojećih i unos znanja,
- programska pomagala za vlastitih podataka zaključivanje na
proceduralno i ad hoc - programske temelju
upravljanje objektima procedure obrade prikupljenih
(dokumentima i podataka u koje su znanja,
porukama) uključeni modeli prikazivanje
odlučivanja rezultata
Skladište baze podataka - baze podataka pojedinih - baze izdvojenih baze znanja
podataka i organizacijskog programskih pomagala podataka
informacija sustava - baze podataka o - baze vlastitih
objektima podataka
- baze podataka sa
rezultatima obrada
- baze modela
Osnovne - analitička i zbirna - prikaz sadržaja poruka, - grafički, - rezultati
vrste i oblici izvješća dokumenata i ostalih numerički i ekspertize s
izlaznih - izvješća o greškama objekata tekstualno objašnjenjima
informacija i porukama - informacije o stanjima i prikazane - prikaz načina
- informacije o promjenama pojedinih informacije rješavanja
stanjima i objekata uredskog sustava potrebne za problema
promjenama stanja donošenje odluka
pojedinih objekata - međurezultati
obrada
Najčešći izvršitelji i operativni svi koji obavljaju uredske srednji i viši srednji i viši
korisnici rukovoditelji poslove rukovoditelji rukovoditelji
Korist brzina, učinkovitost brzina, učinkovitost, uspješnost, uspješnost, brzina
izražajnost izražajnost
Izvor: V. Strahonja et al.: "Projektiranje informacijskih sustava", 1992.

Tablica 3. Usporedni prikaz važnijih obilježja različitih vrsta informacijskih sustava

Podjela prema standardnom modelu poslovnih funkcija odnosi se na podsustave

informacijskog sustava kojima su pokrivena pojedina poslovna područja. Informacijskih
sustava može biti onoliko koliko se poslovnih funkcija obavlja u poduzeću. Njihov broj ovisi
o organizaciji poslovanja poduzeća, pa se može dogoditi da dvije tvrtke koje se bave istom
djelatnošću imaju različit broj informacijskih podsustava15. Općenito, to mogu biti:

• Informacijski podsustav (IPS) planiranja i analize poslovanja,

• IPS upravljanja trajnim proizvodnim dobrima,
• IPS upravljanja ljudskim resursima,
• IPS upravljanja financijama,
• IPS nabave materijala i sirovina,
• IPS prodaje proizvoda i usluga,

15
Primjerice, neka jedno poduzeće vodi vlastito knjigovodstvo, a drugo plaća uslužni knjigovodstveni servis.
Tada će prvom poduzeću informacijski podsustav za knjigovodstveno računovodstvene poslove biti nužan, a
drugom ne.
12
 • IPS računovodstva,
• IPS istraživanja i razvoja itd.

Primjena informacijske tehnologije nema jednak značaj za različite poslovne sustave, pa i

onda kada imaju implementirane iste informacijske podsustave. Stoga se informacijski sustavi
dijele na četiri osnovna tipa:
• Operativni informacijski sustav je sustav o kojem ovisi uspjeh tekućeg poslovanja. U
ovom slučaju funkcioniranje poduzeća jako ovisi o informacijskoj tehnologiji jer
informacijski sustav služi kao potpora svakodnevnom poslu (primjerice u trgovini).
• Potporni informacijski sustav je koristan, ali nije kritičan za poslovni uspjeh
poduzeća. U ovom slučaju ovisnost funkcioniranja poduzeća o informacijskoj
tehnologiji je mala (primjerice u građevinarstvu).
• Strateški informacijski sustav kritičan je za poslovnu strategiju u budućnosti, pa mora
omogućiti pohranu i brzu obradu velike količine potrebnih podataka. U ovom slučaju
funkcioniranje poduzeća jako ovisi o primjeni informacijske tehnologije, kao i
poslovni rezultat poduzeća (primjerice, rezervacija karata za prijevoz).
• Izgledni informacijski sustav mogao bi utjecati na uspjeh budućeg poslovanja, stoga
je ovisnost funkcioniranja poduzeća o informacijskoj tehnologiji mala, ali je utjecaj
informatike na poslovni rezultat velik (primjerice, u osiguravateljnoj djelatnosti gdje
osiguravatelj može funkcionirati uz ručno izdavanje police i obradu šteta, ali za
isplativ izračun premije osiguranja i procjenu rizika za postojeće i nove proizvode
krojene prema ciljnim skupinama mora obraditi veliku količinu prikupljenih podataka,
što bez primjene informatike predugo traje i može značajno utjecati na rezultate
poslovanja).

Za svaki poslovni sustav može se odrediti kojem tipu pojedini informacijski podsustav
pripada, te tako, ovisno o osnovnoj djelatnosti poduzeća, lakše ocijeniti redoslijed prioriteta
pri uvođenju informacijskih podsustava u poslovanje. Često se počne s izgradnjom potpornog
informacijskog sustava, koji postepeno prerasta do izglednog informacijskog sustava,
ključnog za dugoročno poslovanje.

Neovisno o tipu i vrsti informacijskog sustava, u njima su pohranjeni podaci potrebni za dalju
obradu i izvješćivanje. O kvaliteti tih podataka ovisiti će i kvaliteta informacijskog sustava.
Budući da je informacijski sustav dio poslovnog sustava, o kvaliteti informacijskog sustava
pak ovisi i cjelokupno poslovanje tvrtke. Dakle, bez dobro i jednoznačno definiranih podataka
nema ni kvalitetnog informacijskog sustava, a bez kvalitetnog i dobro strukturiranog
informacijskog sustava nema ni kvalitetne podrške klijentu kao ni rasta i razvoja poduzeća.

Stoga kvalitetan informacijski sustav mora zadovoljiti sljedeća osnovna načela16:

• informacijski sustav je model poslovne tehnologije organizacijskog sustava,
• podaci su resurs poslovnog sustava,
• temelj razmatranja prilikom određivanja podsustava su poslovni procesi kao
nepromjenjivi dio određene poslovne tehnologije,

16
Brumec, J.: Projektiranje i metodike razvoja IS-a,Euro Data, Zagreb, 1996.
13
 • informacijski sustav izgrađuje se integracijom podsustava na osnovi zajedničkih
podataka (modularnost),
• informacije za upravljanje i odlučivanje izvode se na temelju zbivanja na razini
izvođenja .

Informacijski sustav izgrađen na ovim načelima preslikava poslovni tehnologiju određenog

poduzeća, te može u potpunosti zadovoljiti svoju zadaću prikupljanja, obrade, pohrane i
distribucije podataka svima kojima je to potrebno, s ciljem unapređenja poslovanja i
ostvarenja pozitivnih poslovnih rezultata.

1.4. Zablude o uspješnosti informacijskih sustava i

informacijska kriza
Samo oko 20% svih informacijskih sustava u svijetu pokazuje
očekivanu učinkovitost, idućih 40% pokazuje marginalnu
dobit, a preostalih 40% čist je promašaj.

O neuspješnim informacijskim sustavima nitko ne piše, tako da se često stvara pogrešan

dojam da su svi drugi sustavi uspješni, a samo onaj koji koristite ili mukotrpno razvijate
neuspješan. Rijetki primjeri navedeni u literaturi postali su poznati zbog visokih šteta na
ljudima i stvarima, kojima su uzrok bili neuspješni sustavi. Primjerice17:

• Ariane 5, let 501 (1996.), koja je eksplodirala prilikom lansiranja radi niza grešaka u
softveru. Nesreća je mogla imati više uzroka, od kojih se navode nedovoljno testiran
softver, loše održavanje te nedostaci u oblikovanju softvera.
• Therac –25, aparat za zračenje upravljan računalom, kojim je pri terapiji najmanje šest
osoba ozračeno previsokim dozama radijacije, a za troje je dokazano da je umrlo od
zračenja. Razlog je bio u nedovoljnoj kvaliteti sustava, odnosno neadekvatnom
testiranju softvera za određivanja količine zračenja, nedovoljno jasnoj dokumentaciji i
uputama za rad, te softverskim greškama u programu koji je trebao osigurati sigurnost
pri primjeni stroja.
• Londonski sustav hitne pomoći (engl. The London Ambulance Service), koji je trebao
upravljati prometom ambulantnih vozila na području od preko 600 kvadratnih milja,
koji prevozi preko 5000 pacijenata dnevno u 750 vozila. S obzirom da se radi o preko
2000 telefonskih poziva na dan, uključujući više od 1300 hitnih intervencija, odlučeno
je uvesti računalom podržan sustav. Autori softvera nisu imali dovoljno iskustva u
izradi tako složenog i velikog sustava, pa su napravili čitav niz grešaka u oblikovanju i
programiranju sustava, koji se tri tjedna nakon uvođenja raspao. Softver nije bio
prilagođen ljudima koji su ga trebali koristiti, tako da se pretpostavlja da su neke
osobe umrle jer hitna pomoć nije do njih stigla na vrijeme.

17
Prema Van Vliet, H.: Software Engineering, Wiley& Sons, NY, 2000., str. 18.-24.
14
Najčešće greške događaju se na samom početku projekta razvoja informacijskog sustava.
Ako se ne uoče do završetka rada na razvoju i izvedbi, njihovo otklanjanje ima i najvišu
cijenu. Početni projekt najčešće je pogrešan zbog pogrešno utvrđenih polaznih zahtjeva
odnosno nedovoljnog razumijevanja stvarnih potreba korisnika i ponekad ga nije moguće
popraviti. Najznačajniji uzroci neuspjeha, kao i visina troškova otklanjanja pogrešaka pri
razvoju informacijskih sustava, prikazani su na slici 6.

Bez informacijskog sustava danas poduzeća ne mogu ni rasti niti razvijati se na tržištu. Isto
tako, nepažljivim ulaganjem u informacijski sustav mogu se ostvariti gubici čije posljedice
poduzeće može dugoročno osjećati, a oni ponekad mogu biti i uzrok njegova propadanja.
Nemogućnost pojedinaca i poslovnih sustava da u svakom trenutku mogu pribaviti i koristiti
potrebne informacije, te problemi uvođenja računala za podršku poslovnim i ostalim
aktivnostima odraz su informacijske krize. Osnovni uzroci informacijske krize mogu se
podijeliti na četiri glavne grupe18:

• velika količina informacija, koja prati znanstveno tehnološki razvoj i suvremeno

poslovanje,
• porast složenosti i raznolikosti problema, koji se nastoje riješiti informatizacijom,
• problemi upravljanja organizacijskim sustavima,
• kriza razvoja programskih proizvoda i informacijskih sustava.

U svakodnevnom poslovanju nastaje velika količina informacija koju poslovni sustavi žele i
moraju pratiti. To su, primjerice, podaci iz prošlosti koji mogu biti iskorišteni u promociji
proizvoda ili usluga za ostvarenje boljeg rezultata u budućnosti. Ponekad te podatke nije
moguće prepoznati kao potrebne i/ili zanimljive, sortirati ih i koristiti, jer ili nedostaje
odgovarajuća informatička podrška ili je uopće nema. Posljedica nedostatka znanstvenih
informacija znači zaostajanje države za razvijenima uz tehnološku i financijsku ovisnost o
njima, osiromašenje stanovništva te, u konačnici, gubitak samostalnosti.

Informatizacija se relativno brzo provodi za jednostavne operativne poslove koje je lako

automatizirati. Međutim, kompliciraniji poslovi zahtijevaju drugačija znanja i
multidisciplinaran pristup tima stručnjaka. Stoga se razvijaju metode i tehnike čijom
primjenom se može razviti uspješan informacijski sustav, koji treba pomoći poslovodstvima
pri upravljanju poslovnim sustavom.

18
Prema Strahonja, V. et al.: Projektiranje informacijskih sustava, Zavod za informatičku djelatnost RH i Ina
Info, Zagreb, 1992., str. 1.

15
 Uzroci neuspjeha informacijskog sustava

70

58
60

50

40
%

30 27

20

10
10 7

Program Projekt Zahtjevi Ostalo

Trošak otklanjanja pogrešaka pri razvoju informacijskog sustava

90

80

70

60

50
%

40

30

20

10

Program Projekt Zahtjevi Ostalo

Izvor: Brumec, J.: Strateško planiranje IS-a, FOI; Varaždin, 1997.

Slika 6.: Uzroci neuspjeha i visina troškova otklanjanja grešaka pri razvoju informacijskog sustava

U Hrvatskoj nedostaje nositelja promjena u organizacijskim sustavima. Posebno teška

situacija je nastala zbog privatizacije poduzeća i pojave novih vlasnika i uprava koje nisu
imale odgovarajuća znanja o upravljaju. Poduzeća su propadala, radnici su ostali bez posla, a
«preživjeli» su samo oni koji su bili spremni neprekidno učiti i usavršavati se. U sklopu
takvog permanentnog obrazovanja poslovodstva počinju razumijevati ulogu informatizacije
poslovanja, te važnost primjene informacijske tehnologije u borbi za ostvarenje poslovnih
ciljeva. Stoga se mijenja odnos prema nabavci hardvera i softvera, te uvođenju informacijskog
sustava u primjenu.

Kriza razvoja programskih proizvoda i informacijskih sustava očituje se u nedovoljnoj

količini raspoložive programske opreme te neprovjerenoj ili nezadovoljavajućoj kvaliteti
postojećih informacijskih sustava. Istodobno, produktivnost projektanata i programera je
nedovoljna, a u praksi se rijetko primjenjuju metodološke koncepcije razvoja. Količina
16
zahtjeva korisnika brzo raste i sve su kompliciraniji, posebno zato jer su korisnici sve više
informatički educirani. Loša komunikacija između korisnika i projektanata i programera
kočnica je bržem razvoju potrebnog softvera, stoga je kvalitetan informacijski sustav moguće
realizirati isključivo timskim radom.

Dakle, rješenje za informacijsku krizu je razvoj kvalitetnih informacijskih sustava, pomoću

kojih vješta i obrazovana poslovodstva upravljaju organizacijskim sustavima, uz primjenu
modernih metoda i tehnika. Postavlja se još samo pitanje da li će učinci informatizacije
opravdati njenu visoku cijenu. U praksi nije jednostavno iskazati efekte koji se postižu
informatizacijom. Dok se uspješnim informacijskim sustavom smatra onaj koji ostvaruje svoj
zadatak i cilj, djelotvornost je mjera njegove sposobnosti da zadovolji potrebe uz prihvatljivu
cijenu. Ekonomski efekti primjene informacijske tehnologije dijele se na:

• direktno mjerljive, poput smanjenja broja obrazaca, smanjenja zaliha sirovina,

povećanje proizvodnje, smanjenje troškova rada i slično,
• indirektno mjerljive, poput brže izrade potrebnih izvješća, bržeg pristupa
informacijama, mogućnosti izrade novih analiza koje prije nije bilo moguće izraditi i
slično,
• nemjerljive, poput poboljšanja kvalitete proizvoda i usluga, bolje organiziranosti
sustava, standardizacije postupaka i procedura itd.

Također je istraživanjima utvrđena činjenica da je učinak primjene informacijskih tehnologija

u praksi niži od očekivanog, što je sažeto u efektu paradoksa19:
«Što su veće investicije u informacijske tehnologije to je porast produktivnosti manji.»

Utvrđeno je da se mijenja odnos ulaganja u tehničku osnovicu i programsku podršku na način

da se smanjuju udjel ulaganja u hardver na račun povećanja ulaganja u softver. S druge strane,
raste ulaganje u troškove osoblja i održavanje postojećeg sustava. Razvoj tehničke osnovice
informacijskog sustava višestruko je brži od razvoja odgovarajućeg softvera, tako da oprema
zastarijeva prije nego li se razviju svi potrebni programi. Stoga, unatoč sve većim ulaganjima
u informacijske tehnologije, učinci informatizacije ne rastu linearno, nego znatno sporije
(porast produktivnosti manji je od očekivanog) ili čak pokazuju negativni efekt. Negativni
efekt znači da je više uloženo u informatiku nego li je njen učinak u primjeni.

Efektu paradoksa pridonosi i parcijalan pristup informatizaciji poduzeća kojim se rješava

samo određeno područje poslovanja u određenom poslovnom razdoblju, bez sagledavanja
cjelokupne poslovne tehnologije. Također su problem i nedostatna sredstva ili, što je još
češće, neodgovarajuća distribucija ulaganja, posebno u početnim koracima informatizacije
odnosno unapređenja tehnološke osnovice. U praksi se naizmjence pojavljuju dva slučaja: ili
se sredstva ulože u tehničku osnovicu pa nedostaju za razvoj aplikativne podrške, ili se ulažu
u stalni popravak aplikativne podrške, pa se ne ulaže u tehničku osnovicu koja izuzetno brzo
zastarijeva.

Iako je eliminacija efekta paradoksa predmet daljih istraživanja, već se predlažu moguća
rješenja.

19
Krakar, Z.: Efekt paradoksa, Infotrend br.51/10/1996, Zagreb
17
Jedno od njih20 navodi da je ključ problema u procesu upravljanja promjenama u poslovnim
sustavima, te njihovoj prilagodbi mogućnostima novih tehnologija. Upravljanje promjenama
uključuje:
• Upravljanje inovacijama odnosno sposobnost poslovodstva da, među ostalim,
iskoristi tehnološki razvoj za nastanak nove poslovne filozofije, uspostavu nove
poslovne organizacije, te stavi informatiku u njihovu funkciju,
• Upravljanje kvalitetom, koje osim uvođenja norme ISO 9000, uključuje upravljanje
razvojem zrelosti procesa odnosno postupka neprekidna poboljšanja načina
proizvodnje aplikacijske programske opreme kao uska grla informatizacije, te
• Upravljanje preoblikovanjem poslovanja odnosno provođenje postupka
modeliranja poslovnih procesa tako da ih se osposobi za informatičku primjenu.

Upravljanjem promjenama u poslovnim sustavima mijenjaju se i ciljevi informatizacije. Želi

se povećati efikasnost (pomoću informacijske tehnologije raditi isti posao bolje) i efektivnost
(biti kreativan i pomoću informacijske tehnologije raditi bolji posao), te ostvariti stratešku
prednost proizvodnjom novih ideja koje su moguće tek uz primjenu informacijske
tehnologije i na taj način održati prednost pred konkurencijom.

Dakle, informacijski sustav model je poslovne tehnologije promatranog poslovnog sustava.

Podaci su resurs poslovnog sustava, a poslovni procesi određuju poslovnu tehnologiju.
Tada se upravljanje poslovnim procesom može definirati kao ukupnost svih aktivnosti koje u
odnosu na poslovni proces poduzima pojedinac, organizacijska jedinica samostalno ili
zajedno s drugim organizacijskim jedinicama ili poslovni sustav u cjelini, a koje se
poduzimaju radi postizanja definiranog cilja poslovnog procesa na što kvalitetniji i
ekonomičniji način i uz racionalno korištenje resursa.

Upravljanje prepoznatim poslovnim procesima i određivanje njihove zrelosti važan je zadatak

u svakom poslovnom sustavu. Iz prakse je poznato da u velikom broju poduzeća nedostaju
pisane organizacijske upute i standardi kojih se mora pridržavati. Također, u neorganiziranom
sustavu u kojem nisu jasno definirane radne procedure i postupci, te nadležnost i odgovornost
za njih, znatno je lakše provesti, ali i sakriti zlouporabu nego u organiziranom sustavu. Za
određivanje zrelosti poslovnih procesa često se koristi Wats Hemphry-jev model koji se lako
primjenjuje na svaki organizacijski sustav.

Prema tom modelu procesi imaju pet razina zrelosti (slika 7.).

Na prvoj, najnižoj razini nalaze se početni ili tzv. divlji procesi. To su oni koji još nisu
prepoznati i događaju se gotovo slučajno. Primjer se može naći u svim poduzećima koja
počinju sa poslovanjem, pa čak i kod već uhodanih poduzeća kada uvode novi proizvod.

Uporabom elementarnih metoda za upravljanje (“discipliniranjem”) ti procesi prerastaju u

ponavljajuće procese, tj. prelaze u drugu razinu zrelosti. Najčešće već u ovoj fazi nastaje
potreba za informatizacijom procesa, no još nije dosegnuta za to zadovoljavajuća razina. Tek
uvođenjem standardizacije opisa procesa i njihovih definicija (procesi treće razine zrelosti)
stvaraju se preduvjeti za njihovu kvalitetnu implementaciju. Ako se informatički podrže
ponavljajući procesi prije standardizacije vjerojatno će rezultat biti neuspješan informacijski
sustav (ili podsustav) koji će se u kratkom vremenskom razdoblju morati zamijeniti.

20
Prema Krakar, Z.: Efekt paradoksa, Infotrend br.51/10/1996, Zagreb

18
 Izvor: Krakar,Z: ISO sustavi kvalitete u informatici, HGK, Zagreb, 1997.

Slika 7. Upravljanje razvojem zrelosti procesa (Wats-Hemphry model)

Uvođenjem mogućnosti predviđanja nastaju procesi četvrte razine ili upravljani procesi.
Njihovim usklađivanjem s ostalim procesima četvrte razine i stalnim usavršavanjem nastaju
optimirani ili sinkronizirani procesi. Budući da jedna od definicija kaže da je informacijski
sustav dobar onoliko koliko su dobri procesi koje on obavlja21, može ga se procijeniti s dosta
velikom pouzdanošću, ako se odredi razina zrelosti njegovih glavnih procesa. Ti pak podaci
mogu poslužiti pri procjeni vjerojatnosti uspjeha i resursa potrebnih za provođenje
preoblikovanja poslovanja.

Preoblikovanje poslovanja je postupak modeliranja poslovnih procesa tako da ih se osposobi

za informatičku primjenu. Jasno, ukoliko se utvrdi da su neki procesi višak potrebno ih je
ukinuti. Također, procesi koje nije moguće informatički podržati jer zahtijevaju posebna
znanja i donošenje odluka na temelju prosudbe, moraju se opisati što detaljnije i uključiti u
informacijski sustav. U ovom prijedlogu rješenja efekta paradoksa posebno je naglašeno da su
nositelji tih aktivnosti poslovodstva poslovnih sustava, a informatika je samo potpora.

Drugi prijedlog rješenja efekta paradoksa predlaže konkretne postupke za uspješnost ulaganja
u informacijske tehnologije22:

• strateško planiranje informacijskog sustava, istodobno s planiranjem razvoja

poduzeća;
• dosljedna primjena modernih metodika projektiranja i razvoja informacijskog sustava;

21
Brumec, J.: Strateško planiranje IS-a, FOI Varaždin, 1997.
22
Brumec, J.: Strateško planiranje IS-a, FOI Varaždin, 1997.
19
 • osiguranje organizacijske zrelosti sredine za prihvaćanje nove informacijske
tehnologije.

Za razmatranje organizacijske zrelosti za pristup strateškom planiranju informacijskog

sustava može se koristiti Earl-ov model. On razlikuje 5 specifičnih faza i pristupa strateškom
planiranju informacijskog sustava ovisno o povezanosti s planiranjem poslovne strategije.
Faze su opisane s jednom općom i više pojedinačnih značajki. Ove faze djelomično se
podudaraju s značajem informacijskog sustava za određeno poduzeće na način da što je
informacijski sustav zahtjevniji treba primijeniti «višu» fazu planiranja. Za najzahtjevnije
sustave mogu se, ali i ne moraju primijeniti sve faze no preporuka je koristiti određeni
redoslijed:

faza 1. → faza 2. → faza 3. → faza 4. → faza 5.

↓________________↑

Faza 1 Faza 2 Faza 3 Faza 4 Faza 5

Glavni posao Projektiranje Definiranje Detaljno planiranje Procjena Veza sa
aplikacija poslovnih informacijskog strateške strategijom
potreba sustava prednosti poslovanja
Ključni ciljevi Pridobivanje Usaglašavanje Usklađivanje Postizanje Integracija
poslovodstva prioriteta aplikacija poslovnih informacijskog
učinaka sustava i
poslovnih
strategija
Inicijator Razvoj Više Korisnici i Poslovodstvo i Usuglašeno:
planiranja informatičke poslovodstvo informatičari korisnici korisnici,
tehnologije zajedno poslovodstvo i
informatičari
Pristup Razvoj Analiza Uravnoteženo Poduzetničko - Više metoda
planiranju "Bottom -up" "Top-down" "Top-down" i korisničke istodobno
"Bottom - up" inovacije
Opća Planiranje Planiranje Administrativno Planiranje Planiranje vođeno
značajka vođeno vođeno planiranje vođeno organizacijom
tehnologijom metodama poslovima
Tip Potporni Izgledni Prijelaz iz Operativni Strateški
informacij- informacijski informacijski izglednog u informacijski informacijski
skog sustava sustav sustav operativni sustav sustav
informacijski
sustav
Izvor: Brumec, J.: "Strateško planiranje IS", FOI Varaždin, 1997.

Tablica 4. Earl-ov model faza pristupa strateškom planiranju IS

Oba su navedena prijedloga rješenja za eliminaciju efekta paradoksa kompatibilna, te se

međusobno preklapaju i dopunjavaju u primjeni jednakih pristupa i metodika.

20
Pitanja za ponavljanje:

1. Navedite i objasnite definiciju sustava, poslovnog sustava i njegova informacijskog

sustava.
2. Objasnite definiciju informacijskog sustava, njegov cilj i zadatak.
3. Ukratko opišite povijesni razvoj informacijskih sustava i navedite karakteristike svake
faze.
4. Opišite i ocijenite značenje informacijskog sustava za razne djelatnosti. Objasnite
kriterije koji utječu na donošenje odluke o informatizaciji poslovanja.
5. Navedite vrste informacijskih sustava. Koje tipove informacijskih sustav poznajete.
Objasnite ukratko svaki od njih.
6. Navedite i objasnite obilježja sustava obrade podataka.
7. Navedite i objasnite obilježja sustava uredskog poslovanja.
8. Navedite i objasnite obilježja sustava za podršku odlučivanju.
9. Navedite i objasnite obilježja ekspertnih sustava.
10. Navedite i obrazložite zablude o uspješnosti informacijskih sustava. Koji uzroci koji
utječu na uspješnost informacijskog sustava? Kada je trošak otklanjanja grešaka
najveći?
11. Objasnite pojam «efekta paradoksa».
12. Objasnite pojam informacijske krize i objasnite prijedloge za njenu eliminaciju.
13. Navedite i objasnite osnovne uzroke informacijske krize.
14. Koje ekonomske efekte primjene informacijske tehnologije poznajete i kako se oni
odražavaju na poslovanje?
15. Skicirajte i objasnite Wats-Hemphry-ev model zrelosti procesa. Navedite mogućnost
njegove primjene u praksi.
16. Kako se informatička tehnologija koristi u postizanju strateške prednosti poduzeća?
Objasnite značajke kvalitetnog informacijskog sustava.
17. Kako se može primijeniti Earl-ov model? Objasnite osobine pojedine faze!

21
2. Organizacija poslovnog informacijskog sustava

Organizacija informacijskog sustava

Organizacijska kultura i organizacija informacijskog sustava
Organizacijska zrelost i planiranje informacijskog sustava.

2.1. Organizacija informacijskog sustava

Centralizirana organizacija informacijskog sustava

Decentralizirana organizacija informacijskog sustava
Distribuirana organizacija informacijskog sustava
Klijentsko poslužiteljska arhitektura informacijskog sustava

Poslovni sustav čine ljudi, njihovo znanje i tehnička oprema koju koriste za obavljanje
svakodnevnog posla. Stoga je potrebno, posebno u velikim i složenim poslovnim sustavima,
organizirati posao na način da se uz što manje troškove realiziraju postavljeni ciljevi. Iz
navedenog proizlazi da:

"Organizacija predstavlja svjesno udruživanje ljudi kojima je cilj da odgovarajućim

sredstvima ispune određene zadatke s najmanjim mogućim naporom, na bilo kojem području
rada i života23".

Organizacija poslovnog sustava podložna je određenim objektivnim čimbenicima odnosno

ograničenjima prostorne prirode (primjerice, poduzeće može djelovati na malom i
ograničenom prostoru ili može djelovati na širem zemljopisnom području), vremenske prirode
jer se uvjeti poslovanja neprekidno mijenjaju pa se i organizacija može mijenjati sukladno
njima, ekonomske prirode gdje se pokušava ostvariti maksimalnu korist uz minimalne
troškove, te tehnološke prirode (primjerice primjena novih tehnologija za unapređenje
poslovanja i realizaciju poslovnih ciljeva).

Informacijski sustav dio je svakog poslovnog sustava, što znači da je organizacija

informacijskog sustava način usklađivanja ljudi i informacijske tehnologije u djelatnoj cjelini
kojoj je cilj načinom, oblikom i vremenom primjereno zadovoljavanje informacijskih potreba
ljudi u poslovnom sustavu, radi ostvarivanja mogućnosti učinkovitog upravljanja tim
sustavom24.

«Orgware» je tada skup zamisli, pravila i postupaka u skladu s kojima se informacijski

sustav oblikuje, razvija i djeluje.

Organizacijski ustroj poslovnog sustava može se prikazati različitim modelima, u obliku:

23
Panian, Ž: Poslovna informatika za ekonomiste, Potecon, Zagreb, 2001, str.187.
24
Prema Panian, Ž: Poslovna informatika za ekonomiste, Potecon, Zagreb, 2001, str.188.
22
 • centralizirane organizacijske shema, kod koje je upravljanje poslovnim sustavom
koncentrirano na jednom mjestu,
• decentralizirane organizacijske sheme, kod koje poslovni subjekt posluje na više
lokacija na kojima obavlja sve poslove (kao da se na svakoj lokaciji nalazi posebno
poduzeće),
• distribuirane organizacijske sheme, kod koje poslovni subjekt posluje na više
lokacija na kojima obavlja sve ili samo neke poslove.

Budući da je informacijski sustav model poslovnog sustava, organizacija poslovnog sustava

uglavnom uvijek određuje i organizaciju informacijskog sustava. Nekada je tehnološka razina
informatičke opreme bila ograničavajući čimbenik za oblikovanje organizacije informacijskog
sustava, što danas nije slučaj. Postojeći informacijski sustavi ipak se u praksi ponekad
organizacijski razlikuju od njihovog poslovnog sustava, jer je zamjena informatičke opreme
koja još nije zastarjela preskupa.

2.1.1. Centralizirana organizacija informacijskog sustava

Centralizirano organizirani model informacijskog sustava prvi je primijenjeni model

organizacije informacijskog sustava u poslovnom sustavu, sukladno tada dostupnoj
informatičkoj tehnologiji (slika 8.).

Za centraliziranu organizaciju informacijskog sustava karakteristična je koncentracija svih

procesnih informatičkih resursa na jednoj lokaciji (uvijek postoji središnje računalo),
koncentracija softvera (podataka i programa na središnjem računalu), te koncentracija
informatičkog osoblja (uglavnom u sklopu posebne organizacijske jedinice koja se često zvala
Elektronski računski centar - ERC u poduzeću).

Unatoč prednostima takve organizacije informacijskog sustava za neke djelatnosti (primjerice

za mirovinske i zdravstvene financijske fondove, osiguravajuća društva, pa i banke), njeni
nedostaci ograničavali su rast i razvoj poduzeća. Zaposlenici ERC-a postali su elita jer bez
njih nije bilo moguće obaviti niti jedan posao na računalu, što je proizvelo loš komunikacijski
odnos između njih i korisnika. Informacijski sustav koji je razvijan, prilagođavan je
potrebama poslovodstva a ne krajnjeg korisnika, što je dodatno produbilo jaz i posredno
utjecalo na širenje međusobno nekompatibilnih aplikacija za krajnjeg korisnika. S obzirom
da se radilo samo na jednom središnjem računalu, unaprijed je planirano vrijeme rada
računala i raspored poslova koje treba napraviti, tako da se javljao problem organizacije
"vršnih opterećenja" (posebno u vrijeme obračuna plaća i slično).

Centralizirano organiziran informacijski sustav pokazao se nedjelotvornim uvijek kada su se

poslovi delegirali nižim razinama upravljanja, tako da je uvođenje nove organizacije bilo
samo pitanje mogućnosti informacijske tehnologije.

23
 SREDIŠNJE
RAČUNALO

Slika 8. Centralizirana organizacija informacijskog sustava

PRIMJER:

Osiguravatelj posluje na jednoj lokaciji, a prodaju osiguranja obavlja putem prodajne

mreže bilo gdje u Hrvatskoj (slika 9.). Svi informatički resursi nalaze se kod
osiguravatelja. Na prodajnim mjestima koriste se terminali vezani za središnje
računalo ili se radi ručno, na papiru. Dokumenti se dostavljaju u centralu ili šalju
poštom, pa ih zaposlenici osiguravatelja unose u središnje računalo. Podaci potrebni
prodajnoj mreži štampaju se i šalju na papiru.

Osiguravatelj

Zastupnici Povjerenici Posrednici

Stanice za tehnièki pregledi

Prodajna mreža

Slika 9. Primjer primjene centralizirane organizacije informacijskog sustava u poslovanju

24
2.1.2. Decentralizirana organizacija informacijskog sustava

Glavni razlozi za prijelaz na novu organizaciju bili su nezadovoljstvo centraliziranom

organizacijom i njenim ograničenjima, ali i relativan pad cijena informatičke opreme, te
uvođenje u primjenu osobnih računala.

Dok je informatička oprema bila skupa korisnici su potiho «mrmljali» i ispoljavali

nezadovoljstvo jer su mogućnosti nabavke nove opreme bile ograničene. Međutim, pad cijena
opreme omogućio je poduzećima, posebno velikima, nabavu više manjih računala koja su
mogla biti smještena na raznim lokacijama. Na svakoj lokaciji se tada počinje formirati
poseban, mali računski centar, koji zadovoljava potrebe korisnika na toj lokaciji. Dakle,
decentraliziranu organizaciju informacijskog sustava karakterizira smještaj više nezavisnih
samostalnih računala na različitim lokacijama, razvoj i instalacija softvera na više mjesta i
formiranje računskih centara na više mjesta. Na taj način dolazi do stvaranja "arhipelaga
informacijskih otoka", koji nisu međusobno povezani (slika 10.).

Nedostaci decentralizirane organizacije primijećeni su vrlo brzo. Prvo je uočena nedovoljna

funkcijska i vremenska usklađenost aktivnosti (koordinacija i sinkronizacija) između
pojedinih računala na lokacijama, pa je informacijski sustav počeo djelovati kao sustav
međusobno nepovezanih cjelina. Razmjena podataka i rezultata obrade među korisnicima
postala je mora za informatičare jer se obavljala na razne načine u ovisnosti o vrsti
instaliranog softvera na računalu na lokaciji. Često uopće nije bilo moguće međusobno
povezati programsku podršku lokalnih sustava25. Onemogućeno je upravljanje sustavom na
jednoobrazan (unificiran) način, a redundantnost podataka i njihovih obrada pobudila je
sumnju u njihovu vjerodostojnost i usporedivost (često opravdanu!). Naravno da se krivnja za
nastale probleme počela prebacivati s jedne strane na drugu, pa dolazi do loših
komunikacijskih odnosa i među korisnicima različitih sustava te među zaposlenicima
različitih ERC-ova (pri čemu su često svi zaposleni u jednom poduzeću). Cijena razvoja
izuzetno raste jer se za svako računalo i svaku lokaciju naručuju posebni programi i dodatni
hardver. Posljedica takve decentralizirane organizacije informacijskog sustava je da poslovni
sustav ne može jedinstveno nastupati na tržištu.

Pojava osobnih računala dodatno je zakomplicirala situaciju. Iako su prva osobna računala
imala veoma slabu programsku podršku, brzo su se razvijali alati za rad korisnika poput tekst
procesora, tabličnih kalkulatora i grafike. Nezadovoljni korisnici informacijskog sustava koji
su stalno morali moliti (i ponekad potkupljivati) programere za izradu potrebnih listi i
izvješća odjednom su dobili mogućnost da samostalno počnu prikupljati, pratiti, obrađivati i
sortirati vlastite podatke. Iako je važnost samostalnog rada na računalu bila neosporna, ipak
su se brzo pojavili novi problemi: novi korisnici počeli su smatrati da im ne trebaju «pravi»
informacijski sustavi nego da će oni sami, uz pomoć eventualno jednog ili dva informatičara
na osobnom računalu napraviti potrebne aplikacije. Unatoč tome što se takav pristup pokazao
lošim, a potpuno nemogućim za imalo složeniji poslovni sustav, čak i danas je moguće čuti
takve stavove.

25
Za takvu nemogućnost povezivanja programske podrške koristi se izraz «inkompatibilnost». Događalo se,
pogotovo sedamdesetih i osamdesetih godina 20.-og stoljeća da su i računala međusobno inkompatibilna i da ih
nije moguće povezati zbog njihovih hardverskih karakteristika.
25
 RAČUNALO

RAČUNALO

RAČUNALO

Slika 10. Decentralizirana organizacija informacijskog sustava

Decentralizacijom organizacije informacijskog sustava i uvođenjem osobnih računala u

primjenu zbrka u podacima i poslovanju je bila potpuna. Rješenje je ponovno traženo u
primjeni nove, ovaj puta komunikacijske tehnologije.

2.1.3. Distribuirana organizacija informacijskog sustava

Osnovne pretpostavke za uvođenje nove organizacije informacijskog sustava bio je razvoj

komunikacija uz drastičan pad cijena hardvera, ubrzani razvoj programskih paketa i alata za
razvoj softvera, te nezadovoljstvo poslovodstava postojećim, najčešće nepouzdanim,
informacijskim sustavom.

Distribuirana organizacija informacijskog sustava nastala je kao kombinacija centralizirane i

decentralizirane organizacije, s namjerom da se u novoj organizaciji zadrže samo dobre
osobine tih modela. Njene osnovne karakteristike su: distribucija hardvera odnosno smještaj
više samostalnih računala na različitim lokacijama povezanih u mrežu, distribucija podataka
odnosno smještaj podataka na više računala u mreži u svakom trenutku dostupnih iz svake
točke u mreži, razvoj i instalacija softvera na više mjesta koji se koordinira s jednog mjesta i
zadovoljavanje elemenata jedinstvenosti informacijskog sustava.

26
PRIMJER:

Osiguravatelj posluje na više lokacija na kojima obavlja sve ili samo neke poslove. U
pravilu poslovnu mrežu čine podružnice osiguravatelja gdje se nalazi samostalno
računalo povezano u mrežu (slika 11.). Na svim računalima koristi se za iste poslove
isti softver.

Osiguravatelj - poslovna mreža

Središnjica

........
Podružnica 1 Podružnica n

Zastupnici Povjerenici Posrednici Ostali kanali prodaje

Prodajna mreža

Slika 11. Primjer primjene distribuirane organizacije informacijskog sustava u poslovanju

Distribuirana organizacija informacijskog sustava podržava različite arhitekture sustava koje su

nastale kao posljedica slijeda razvoja komunikacija i odgovarajućeg mrežnog softvera. Ustroj
odnosno arhitektura distribuiranih sustava može biti
• zvjezdasta,
• hibridna, i
• puna mrežna arhitektura.

Zvjezdasta arhitektura zapravo je unapređenje centralizirane organizacije informacijskog

sustava. Mreža se sastoji od glavnog računala i satelitskih računala koja NE mogu međusobno
komunicirati već samo preko glavnog računala, pa stoga postoji dvorazinska ili jednostavna
hijerarhija računala u sustavu (slika 12.).

27
 GLAVNO
RAČUNALO SATELITSKO
RAČUNALO

SATELITSKO
RAČUNALO

SATELITSKO
RAČUNALO

Slika 12. Distribuirana organizacija informacijskog sustava - zvjezdasta arhitektura

Zadatak glavnog računala kod zvjezdaste arhitekture je uspostavljanje veze između glavnih
računala kada i ako je potrebna, pri čemu glavno računalo upravlja prometom podataka u
cjelokupnom sustavu i održava središnju bazu podataka, te odgovara na upite sa satelitskih
računala postavljene prema središnjoj bazi.

Zadaci satelitskih računala odnose se na operativnu obradu podataka za krajnjeg korisnika

pomoću lokalnih programa, održavanje kopija dijelova središnje baze podataka koje se nalaze
na satelitskim računalima (odnosno lokalne baze podataka), odgovaranje na upite korisnika
upućene lokalnoj bazi podataka, prosljeđivanje korisničkih upita središnjoj bazi podataka i
prijem odgovora središnjeg računala, te uspostavu veza s ostalim satelitskim računalima uvijek
preko glavnog računala.

Hibridna arhitektura nastala je u složenijim poslovnim sustavima gdje povezuje dvije ili više
zvjezdastih skupina u jedan sustav. U takvim sustavima postoje dva ili više glavnih računala, a
satelitska računala se dodaju prema potrebi (slika 13.).

28
 SATELITSKO
RAČUNALO
SATELITSKO
RAČUNALO

GLAVNO
RAČUNALO

SATELITSKO
RAČUNALO

GLAVNO
RAČUNALO

SATELITSKO
RAČUNALO

SATELITSKO
RAČUNALO

Slika 13. Distribuirana organizacija informacijskog sustava - hibridna arhitektura

(arhitektura više zvijezda)

Punu mrežnu arhitekturu karakterizira višerazinska hijerarhija satelitskih računala koja sva
mogu međusobno komunicirati, pri čemu nema glavnog računala (slika 14.).

29
 RAČUNALO

RAČUNALO

RAČUNALO

RAČUNALO

Slika 14. Distribuirana organizacija informacijskog sustava - puna mrežna arhitektura

2.1.4. Klijentsko poslužiteljska arhitektura informacijskog

sustava

Klijentsko poslužiteljska arhitektura zapravo je jedan od oblika distribuirane organizacije

informacijskog sustava, koji odražava aspekt orijentacije na korisnika, pri čemu ignorira
unutarnje (organizacijske, tehnološke i ostale) karakteristike sustava i time omogućava
pružanje kvalitetne usluge

Korisnik je klijent sustava, a sustav je poslužitelj (koji pruža uslugu klijentu).

Klijentsko poslužiteljska arhitektura sve se više primjenjuje u praksi, za što je trebalo ostvariti
određene preduvjete: razvijeni su vrlo sofisticirani programi za pružanje usluga klijentima,
koji rade nad dobro ustrojenim i pristupačnim skladištem podataka, razvijene su mrežne
komponente informacijskog sustava, uvedeno je decentralizirano upravljanje informacijskim
sustavom i formiran je kvalitetni informacijski centar koji treba neprekidno biti na usluzi
klijentima.

30
Stoga se klijentsko poslužiteljska arhitektura uvodi u primjenu određenim redoslijedom, prema
složenosti26:

1. poslužitelj datoteka (engl. File Server)

2. poslužitelj baza podataka (engl. Data Base Server)
3. poslužitelj transakcija (engl. Transaction Server)
4. poslužitelj skupina (engl. Groupware Server)
5. poslužitelj objektnih aplikacija (engl. Object Application Server)
6. poslužitelj Web aplikacija (engl. Web Application Server)

Najjednostavniji je slučaj kada klijent putem mreže pristupa sa svog računala poslužitelju
datoteka, pri čemu zahtjeva isporuku određenog sadržaja datoteka. Poslužitelj datoteka
omogućava dijeljenje istih datoteka među različitim korisnicima odnosno klijentima.

Poslužitelju baza podataka klijent uobičajeno upućuje poruke uporabom upitnih jezika
(SQL ili Structured Query Language). Iako se upotrebljava u svim vrstama sustava, ovakav
oblik klijentsko poslužiteljske arhitekture nužan je preduvjet za sustav potpore poslovnom
odlučivanju.

Poslužitelji transakcija koriste se pri obradi podataka iz baza podataka, na način da nude
klijentima uporabu posebnih procedura kojima se omogućava komuniciranje podacima tipa
zahtjev - odgovor. Koristi se kod složenijih transakcija nad bazom podataka.

Poslužitelji skupina podržavaju razmjenu polustrukturiranih informacija s klijentima

(tekstovi, slike, elektronička pošta). Oni omogućavaju direktnu komunikaciju među klijentima
koji čine skupinu, bilo u lokalnoj mreži bilo na Internetu.

Poslužitelj objektnih aplikacija koristi se kada se klijentsko poslužiteljska aplikacija piše u

obliku skupa objekata. Za implementaciju ovog oblika klijentsko poslužiteljske arhitekture
koriste se posebni softveri (od kojih je danas najpoznatiji programski paket pod nazivom
CORBA).

Prva globalna implementacija klijentsko poslužiteljske arhitekture je Internet sa svojim World

Wide Web servisom, poznata pod nazivom poslužitelj Web aplikacija.

Informacijski centar nastaje zbog razdvajanja operativnih od razvojnih aktivnosti pri razvoju
i korištenju informacijskih sustava i formira se kao posebna organizacijska jedinica27 unutar
distribuiranog informacijskog sustava. Uloga informacijskog centra je u pružanju
savjetodavnih usluge korisnicima, usluga tehničke potpore i ekspertnih znanja potrebnih za
ostvarivanje pristupa traženim sadržajima distribuirane baze podataka, te u razvijanju vlastitih
aplikacija uz korištenje standardnih pomagala. Zbog velikog broja korisnika različitih
informatičkih predznanja i potreba, informacijski centar nužan je u velikim i složenim
poslovnim sustavima.

26
prema Panian, Ž.: Kontrola i revizija informacijskih sustava, str. 307.-308, Sinergija-nakladništvo d.o.o.
Zagreb, 2001.
27
Koncept informacijskog centra uveden je kako bi se prevladalo stalna netrpeljivost i loša komunikacija između
informatičara i korisnika njihovih usluga.
31
2.2. Organizacijska kultura poslovnog sustava i organizacija
informacijskog sustava
Obrasci ponašanja poslovodstva određuju dva temeljna tipa organizacijske kulture:
• kontrolnu organizacijsku kulturu i
• tržištem upravljanu organizacijsku kulturu.

Organizacija informacijskog sustava ne ovisi samo o organizaciji poslovnog sustava nego i o

organizacijskoj kulturi poslovnog sustava. Organizacija informacijskog sustava ovisi i o
načinu ustroja skladišta podataka, jer organizacijska kultura određuje potrebe koje poduzeće
ima za podacima pohranjenim u sustavu (tablica 5.).

Tip organizacijske kulture

Kontrolna organizacijska kultura
Obilježja • poslovodstvo pretežno prati događanja
organizacijske u poslovnom sustavu
kulture • hijerarhijska struktura poslovodstva
• funkcijska poslovna područja su strogo
razgraničena
• visok stupanj centralizacije planiranja,
odlučivanja i kontrole
• definirani i opisani procesi
ostvarivanja odluka
• razmjerno puno neovisnih dijelova u
organizacijskoj strukturi
• informacija se tretira kao oružje za
ostvarivanje ciljeva
Obilježja • naglasak na financijskim, statističkim i
skladišta tehničkim obradama zbog utvrđivanja
podataka stupnja ostvarivanja unutarnjih ciljeva
poslovnog sustava
• detaljno razrađen sustav ovlaštenja za
pristupanje podacima
• strogo funkcijski razgraničeno
skladište podataka na domene
• podaci iz skladišta distribuiranju se u
formi standardnih izvješća različitim
korisnicima
• stroga kontrola pristupa sadržaju
podataka, uz definiranje poslovne tajne
• uporaba podataka u aplikacijama je
precizno definirana, a aplikacije su
uglavnom dugovječne
• struktura skladišta je teško
prilagodljiva promjenama do kojih
dolazi u okolici sustava
Tip skladišta Vertikalni ustroj skladišta podataka
podataka
Organizacija Zvjezdasta organizacija informacijskog
IS sustava
Tržištem upravljana organizacijska kultura
• poslovodstvo pretežno prati tržišna
događanja (vanjske procese)
• poslovodstvo uključuje razmjerno velik broj
samostalnih instancija
• orijentacija poslovodstva na klijente a ne na
poslovne funkcije
• planiranje, odlučivanje i kontrola uglavnom
decentralizirani
• ključna je svrha a ne način ostvarivanja
poslovnih procesa
• slabo strukturirani procesi provođenja
poslovnih odluka mogu se ostvarivati na
razne načine
• informacija je specifičan ali ravnopravan
resurs
• orijentacija na primjenu skladišta podataka
u okviru marketinške funkcije, s naglaskom
na podatke iz vanjskih izvora
• sustav ovlaštenja za pristupanje podacima je
jednostavan i razmjerno labav
• ako postoji segmentacija onda se radi prema
ciljnim skupinama klijenata
• uglavnom nema središnje kontrole pristupu
podacima od strane poslovodstva
• korisnici dogovorno specificiraju načine
obrade istih podataka u raznim aplikacijama
• parametrizirane aplikacije koje omogućuju
varijante pristupa podacima
• korisničke aplikacije nisu detaljno
preddefinirane, strukturirane da podnose
brojne i česte promjene
Horizontalni ustroj skladišta podataka
Hibridna ili puna mrežna organizacija
informacijskog sustava

Tablica 5.:Organizacijska kultura i organizacija informacijskog sustava

32
2.3. Organizacijska zrelost i planiranje razvoja informacijskog
sustava

Nolanova podjela faza informatičkog razvoja poduzeća

Faze životnog ciklusa informacijskog sustava
Informacijski inženjering
Elementi jedinstvenosti informacijskog sustava

2.3.1. Nolanova podjela faza informatičkog razvoja poduzeća

Svaki organizacijski sustav odnosno poslovni sustav ima svoj informacijski (pod)sustav.
Organizacijski razvoj poduzeća ovisi o tehnološkoj razini informacijskog sustava, ali i utječe
na nj, i obrnuto. U pojedinim fazama informatika prethodi promjenama u organizaciji
(uvođenje računala u poslovanje izaziva tehnološke promjene koje utječu na organizacijsku
razinu poduzeća), dok u drugima informatika zaostaje za organizacijom (sporo reagiranje
informacijskog sustava na promjene nastale pod utjecajima iz okruženja poduzeća). Ne treba,
međutim, zaboraviti da:
• informatizacija poduzeća nije sama sebi svrha, i da je
• informatizacija poduzeća podproces komunikacijske razine poduzeća.

Ako je komunikacijska razina poduzeća na potrebnoj razini, kvalitetan informacijski sustav

može doći do punog izražaja, a ako nije tako, ni najnovija tehnička i programska oprema, ni
jedinstveni informacijski sustav, neće imati bitno pozitivno značenje osim kao veliko
opterećenje poduzeća28.

Informacijska razina poduzeća glede uporabe informacijske tehnologije definirana je

Nolanovom podjelom na šest faza razvoja informacijskog sustava odnosno organizacije
podataka29:

1. faza → uvođenje (engl. Initiation),

2. faza → proširenje (zaraza) (engl. Contagion),
3. faza → upravljanje (kontrola) (engl. Control),
4. faza → povezivanje (integracija) (engl. Integration),
5. faza → sređivanje (administracija podataka) (engl. Data Administration),
6. faza → zrelost (engl. Maturity).

28
Čurčić, Grabowski, Štahan: Kako napraviti razvojni program i elaborat o procjeni vrijednosti poduzeća, TEB,
Zagreb, 1992.
29
Martin, J. i McClure, C.: Software Maintenance: The Problem and Its Solution, Prentice Hall, Englewood
Cliffs, NY, 1985.
33
Model je nastao na temelju promatranja ponašanja poduzeća kod uvođenja informacijskih
tehnologija, na uzorku više od 200 poduzeća30. Iako se model mijenjao tijekom vremena,
Nolanovi opći zaključci još vrijede.

Različiti su poslovni sustavi na različitim stupnjevima razvoja informacijskog sustava,

odnosno na različitoj informacijskoj razini sa stajališta podataka. Nolan smatra da
razumijevanje faza razvoja organizacije podataka može pomoći pri upravljanju u efektivnijem
planiranju i kontroli funkcije obrade podataka. Osim toga, bolje se može odrediti plan za
prijelaz u više faze koji mora biti usklađen s poslovnim planovima u smislu definiranja
realnih troškova i koncentriran na poslovna područja koja su najkritičnija pri ostvarenju
poslovnih ciljeva poduzeća. Značajke pojedinih faza prikazane su u tablici 6.

Navedene faze razvoja poduzeća mogu upotrijebiti kao mjerilo svog napretka, ali mogu
koristiti i iskustva naprednijih poduzeća. Nolan je ujedno pretpostavio da:
• svaka faza razvoja nužno slijedi iz prethodne;
• nema preskakanja pojedinih faza, jer je tek poduzeće s iskustvom iz prethodne
faze spremno za sljedeću, a ako nema eksperimentiranja, nema ni korisnika koji bi
izazvali fazu proširenja informacijskog sustava;
• bez obzira na ograničenja slijeda faza razvoja informacijskog sustava, faze razvoja
moguće je planirati, koordinirati i njima upravljati kako bi rezultati bili što
efikasniji.

Temeljna je poruka njegova modela da je uvođenje informacijskih tehnologija evolutivan

proces. Svaka tehnologija ima svoje domete, njih treba znati procijeniti i pravodobno
pokrenuti novi razvojni ciklus.

Primjenom Nolanova modela na poslovni sustav posredno se može utvrditi i organizacijska

razina poduzeća čije je poslovanje podržano računalom: što je viša faza razvoja primijenjene
informacijske tehnologije (odnosno, prema Nolanu organizacije podataka), viša je i
organizacijska razina poduzeća. Pri tomu se pojam organizacijske razine odnosi na stupanj
organiziranosti poslovnog sustava (a time posredno i na stupanj efektivnosti). Dakle, pomoću
Nolanove podjele moguće je procijeniti trenutnu informacijsku i organizacijsku razinu
poduzeća, te planirati daljnji razvoj informacijskog sustava.

30
Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997.
34
 PLANIRANJE
FAZE SKUP ORGANIZACIJA ULOGA
I
APLIKACIJA OBRADE KORISNIKA
KONTROLA
PODATAKA
PODATAKA

Faza I Ograničene, Učenje tehnologije Slaba Nema interesa

Uvođenje pojedinačne aplikacije obrade podataka
po poslovnim
područjima

Faza II Nagli porast Korisnički orijentirani Vrlo slaba Površan interes

Proširenje broja aplikacija programeri
(zaraza)

Faza III Sređivanje Srednja razina Formalizacija planiranja Neprihvaćanje

Upravljanje dokumentacije i upravljanja i kontrole podataka odgovornosti za
(kontrola) restrukturiranje podatke
postojećih aplikacija

Faza IV Prilagodba postojećih Afirmiranje korisnosti Povezano planiranje i Odgovornost za

Povezivanje aplikacija uporabom računala kontrola podatke ovisi
(integracija) tehnologije baza i uvođenje sustava o pojedincu odnosno
podataka korisnika u timove korisniku

Faza V Organizacijska Administracija podataka Dijeljeni podaci Efektivna

Sređivanje integracija aplikacija i zajednički sustavi odgovornost korisnika
(administracija
podataka)

Faza VI Integriranje Upravljanje resursima Strategijsko planiranje Prihvaćanje korištenja

Zrelost informacijskih tokova podataka resursa zajedničkih podataka
kroz aplikacije podataka i odgovornosti
za njih
Izvor: Jandrić, K: Optimiziranje informacijskog sustava usklađivanjem različitih informacijskih sustava baza podataka,
magistarski rad, FOI, Varaždin, 1992.

Tablica 6.: Značajke pojedinih faza Nolanove podjele

Nolanova podjela na šest faza razvoja informacijskog sustava opisuje idealni slučaj u kojem
se poduzeće razvija i informacijski i organizacijski, bez vanjskih utjecaja kao što je,
primjerice, promjena tehnološke osnovice odnosno generacije računala.
Korekciju podjele dao je sam Nolan, pretpostavivši da se, nakon tehnološke promjene,
određene faze razvoja informacijskog sustava ponavljaju. Utvrđeno je pak da se promjene
razvojnih koncepcija i tehnološki skokovi događaju na prijelazu iz faze upravljanja u fazu
povezivanja. Tako se krivulja razvoja informacijskog sustava prekida, iz faze upravljanja
vraća se u fazu uvođenja. Stoga se faza povezivanja informacijskog sustava i faza sređivanja
informacijskog sustava zapravo nikad ne ostvaruju31. Na slici 15. novi razvojni ciklus označen
je krivuljom koja započinje u trećoj fazi prvog razvojnog ciklusa.

31
Martin, J: Information Engineering: Introduction, Prentice Hall, Englewood Cliffs, NY 1990.
35
Prijelaz na novu tehnologiju uvjetovan je cijelim nizom okolnosti koje je moguće grupirati
po zajedničkim karakteristikama. Presudan je utjecaj promjene poslovnih ciljeva u tržišnim
uvjetima privređivanja.

Izvor: Martin, J.: "Information Engineering : Introduction", NY 1990

Slika 15. Razlike u učincima faze razvoja informacijskog sustava (Nolan)

Vrijednost pravodobnih i točnih informacija koje trebaju služiti kao podloga za odlučivanje
raste, čime se uvjetuje sređivanje podataka i rekonstrukcija zatečenog informacijskog sustava.
Niska produktivnost odnosno spor razvoj aplikacija od oblikovanja do uvođenja u primjenu,

36
te visoki troškovi održavanja aplikacija razlog su uvođenju novih metodika i pomagala za
automatizaciju razvoja informacijskog sustava (CASE pomagala).

Brzo zastarijevanje tehnološke osnovice koju je problem održavati i čije karakteristike ne

zadovoljavaju sve veće potrebe korisnika (nedovoljan kapacitet računala, neodgovarajuća
programska pomagala, nemogućnost povezivanja s računalima novih generacija) razlog je
nabavi opreme odgovarajuće tehničke razine.

Prijelaz na nove tehnologije dugotrajan je proces. Loša organiziranost, nejasno definirani

poslovni procesi i/ili previše općenito definirani poslovni ciljevi onemogućuju kvalitativan
skok u informacijskom sustavu pri promjeni tehničke osnovice. Generacijski skok u
tehnologiji je preduvjet, ali ne i uzrok skoku u informacijskoj razini poduzeća. Rezultate
daje tek sinergijsko djelovanje navedenih elemenata koji utječu na spoznaju o potrebi
promjene uz odgovarajuću financijsku i kadrovsku podlogu te podršku strateškog
rukovodstva.

Nolanov model nema samo teorijsko značenje, već upućuje projektante na potrebu
procjenjivanja uvjeta pod kojima se novo rješenje informacijskog sustava može učinkovito
primijeniti. Organizacijski sustav sporo se prilagođava promjenama, a uopće im se neće
prilagoditi ako se promjenama ne upravlja svjesno32. Tehnički prihvatljivo rješenje razvijeno
u razvojnom laboratoriju (računski centar) ne mora biti prihvatljivo za one kojima je
namijenjeno. Kada se stvori odgovarajuća socijalna klima, nešto što je bilo odbijeno prije
godinu dana korisnici mogu prihvatiti s uvažavanjem i zadovoljstvom.

2.3.2. Faze životnog ciklusa IS

Složenost modela informacijskog sustava zahtijeva izbor metode za izgradnju modela

sustava koja omogućuje vjeran formalni prikaz realnog sustava. Odgovarajuća metoda pak
cijeli put razvoja modela razbija na korake (faze), čiji rezultati u konačnici daju model
poduzeća33. Da bi model bio što kvalitetniji, uz iskustvo i znanje, koristi se i što djelotvornija
tehnika.

Dakle, metoda definira redoslijed faza i njihove krajnje rezultate, a tehnika postupke i
tehnologiju za djelotvorno ostvarenje tih rezultata. Dok metoda omogućuje razvoj modela,
tehnika ga više ili manje djelotvorno izgrađuje.

Metode se primjenjuju određenim slijedom, uglavnom u redoslijedu faza životnog ciklusa

informacijskog sustava. Razni autori navode razne faze životnog ciklusa informacijskog
sustava.

32
Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997.
33
prema Pavlić, M.: Razvoj informacijskih sustava, Znak, Zagreb, 1996.
37
Osnovni tijek razvoja, izgradnje i korištenja informacijskog sustava u svim modelima je
istovjetan i jasno naglašava ograničen vijek informacijskog sustava (prikazan na slici 16.)34:
• strateško planiranje odnosno utvrđivanje strategije poslovanja;
• analiza strukture realnog poslovnog sustava, njegovih procesa i podataka;
• oblikovanje informacijskog sustava koje sadrži:
• logičko modeliranje podataka i procesa informacijskog sustava,
• fizičko modeliranje baze podataka, procedura i programa;
• izvedba programske podrške, komunikacija, korisničkog sučelja;
• izrada korisničke dokumentacije;
• uvođenje informacijskog sustava u primjenu;
• održavanje i prilagođavanje informacijskog sustava.

Utjecaj novih tehnologija, novih poslovnih ciljeva te stalnog natjecanja na tržištu dovode
postojeći informacijski sustav (ma kako kvalitetno i pažljivo, primjereno struci, bio izgrađen)
do granica projektantskih postavki odnosno do granica isplativosti dalje dogradnje i
rekonstrukcije.

2.3.3. Informacijski inženjering

Pojam "informacijski inženjering" prvi put su upotrijebili početkom sedamdesetih J. Martin i

C. Finkelstein za inženjerski pristup izgradnji informacijskog sustava35:

«Informacijski inženjering je skup međusobno povezanih formalnih tehnika planiranja,

analize, dizajna i konstrukcije informacijskog sustava cijelog poduzeća ili njegovih dijelova".

Osnovne postavke informacijskog inženjeringa su orijentacija korisnicima, isticanje važnosti

planiranja informacijskog sustava, usklađivanje razvoja informacijskog sustava s ciljevima
organizacijskog sustava, analiza objektnog sustava, izgradnja jedinstvenog modela podataka
koji omogućava stabilnost strukture podataka i dijeljenje podataka među raznim aplikacijama
(primjena principa neovisnosti podataka), povezivanje modela podataka i modela procesa i
povećanje produktivnosti korištenjem suvremenih razvojnih okolina koje uključuje jezike
četvrte generacije i pomagala za projektiranje i razvoj informacijskih sustava (CASE
pomagala).

Informacijski inženjering definira četiri osnovne faze razvoja informacijskog sustava:

• strateško planiranje informacijskog sustava,
• analizu poslovnog područja,
• dizajn sustava (oblikovanje), i
• konstrukciju (izradu) sustava.

34
prema Barker, R.: CASE*METHOD Tasks and Deliverables, Addison-Wesley Publishing Company, 1991.
35
Prema Strahonja, V. et al.: "Projektiranje informacijskih sustava", Zavod za informatičku djelatnost RH i Ina
Info, Zagreb, 1992., str. 279.

38
 Upravljanje poslovnim Poslovni
sustavom: ciljevi
Strateško planiranje

Odluka o izgradnji IS-a

(početak i kraj ciklusa)

Planovi
razvoja

Prijedlozi

Studija izvodljivosti

Prilagođavanje novog
Održavanje novog IS-a
IS-a
Izabrana
strategija

Analiza funkcija
poslovnog sustava
Uočene
potrebe i Redovni
zahtjevi postupci
Matrica
poslovne
tehnologije

Osnovna arhitektura
Praćenje učinaka
IS-a

Redoslijed
Redovno
prioriteta
korištenje
razvoja

Uvođenje novog IS-a Oblikovanje IS-a

Programi Model podataka

dokumentacija Model procesa
resursi .....

Izvedba programske
Izrada korisničke
podrške, komunikacija,
dokumentacije
korisničkog sučelja

Programi,
ekranske slike
....

Slika 16. Faze životnog ciklusa informacijskog sustava

39
Izraz informacijski inženjering koristi se za skup međusobno povezanih disciplina koje su
potrebne za izgradnju informacijskog sustava poduzeća na temeljima postojećih sustava
podataka. On nastoji smanjiti programiranje složene logike procesa i kreiranje zamršenih
programskih interakcija, čime se ujedno smanjuju budući troškovi održavanja sustava.

Dok se informacijski inženjering primarno bavi podacima koji su pohranjeni i održavani na

računalu, softverski inženjering se bavi logikom koja se rabi u procesu podržanom
računalom. Drugim riječima, smanjenje potrebe za softverskim inženjeringom uz povećanje
informacijskog inženjeringa u organizaciji smanjuje troškove u komercijalnoj obradi
podataka.

2.3.4. Elementi jedinstvenosti informacijskog sustava

Ako je informacijski sustav poduzeća slika realnog poslovnog sustava, očito je da se mora graditi
uporabom određenih, definiranih metoda i pravila. Time se, međutim, ne jamči integralnost
cjelokupnog sustava.
Svako poduzeće je specifičan organizacijski entitet, čija unutarnja organizacija i područje
poslovanja utječe na konačan oblik i strukturu informacijskog sustava. Moguće je ipak izdvojiti
elemente jedinstvenosti (integralnosti) koje željeni informacijski sustav treba zadovoljiti, te
odrediti faznu izgradnju jedne po jedne razine jedinstvenosti. Pri tomu je temeljna pretpostavka
jedinstvenosti informacijskog sustava da i u složenim, distribuiranim sustavima upravljanje
podacima poduzeća mora biti centralizirano.

• Koncepcijsko jedinstvo određuje da informacijski sustav svake lokacije mora biti istog
modaliteta36 kao cijeli informacijski sustav. Svaka lokacija (a to može biti i posebno
poduzeće) može odvojeno realizirati vlastiti informacijski sustav prema svojim potrebama i
mogućnostima, uz osiguranje priključnih točaka kako je predviđeno osnovnim
informatičkim normama. Razlike između podsustava koje proizlaze iz specifičnosti
poslovanja i tehničkih mogućnosti rješavaju se izgradnjom informacijskog sustava u okviru
osnovnog koncepta.

• Sadržajno jedinstvo nalaže da se sadržaj informacijskog sustava određuje utvrđivanjem

poslovnih elemenata koje treba pratiti i podacima vezanim uz različita stanja tih elemenata
tijekom poslovnog ciklusa. Budući da sadržaj informacijskog sustava mora osigurati nužne
informacije za sve razine upravljanja, mora se utvrditi minimalno obvezno jedinstvo sadržaja
klasa podataka koje korisnik može proširivati ili preoblikovati.

• Tehnološko metodološko jedinstvo može biti obvezno i racionalno. Obvezno metodološko

jedinstvo zahtjeva najmanje standardizaciju šifarskih sustava i struktura slogova podataka
koji se prenose između podsustava, dok racionalno traži standardizaciju pristupa
organizacijskim problemima, standardizaciju organizacijskih sredstava, standardizaciju svih
šifarskih sustava te zajedničkih podataka, te standardizaciju dokumentacija.

36
Prema Klaić, B: Rječnik stranih riječi, modalitet je način kako se nešto događa ili misli.
40
Zbog operativne provedbe nadzora nad primjenom elemenata jedinstvenosti sustava, kontrolu
jedinstvenosti informacijskog sustava treba planirati već u fazi modeliranja informacijskog
sustava37.

Pitanja za ponavljanje:

1. Navedite i objasnite obilježja centralizirane organizacije informacijskog sustava.

2. Navedite i objasnite obilježja decentralizirane organizacije informacijskog sustava.
3. Navedite i objasnite obilježja distribuirane organizacije informacijskog sustava i njoj
pripadajućih arhitektura.
4. Nacrtajte i objasnite razliku između pune mrežne arhitekture i hibridne arhitekture!
5. Objasnite ulogu informacijskog centra. Koje tipove organizacijske kulture poslovnog
sustava poznajete?
6. Objasnite obilježja kontrolne i tržištem upravljane organizacijske kulture. Koja su
obilježja pripadajućih skladišta podataka?
7. Opišite obilježja klijentsko poslužiteljske arhitekture informacijskog sustava.
8. Objasnite vezu između organizacijske zrelosti i planiranja informacijskog sustava.
Kako se pri tome primjenjuje Nolanova podjela faza informatičkog razvoja poduzeća?
9. Objasnite značajke pojedinih faza Nolanove podjele.
10. Objasnite smisao korigirane Nolanove podjele faza informatičkog razvoja poduzeća.
Objasnite razlike u odnosu na osnovnu podjelu.
11. Koje faze životnog ciklusa informacijskog sustava poznajete?
12. Objasnite pojam informacijskog inženjeringa i njegovu osnovnu razliku u odnosu na
softverski inženjering.
13. Navedite i objasnite elemente jedinstvenosti informacijskog sustava.

37
Jandrić, K.: Jedinstveni IS - utopija ili stvarnost, CASE 6, Opatija, 1994.

41
3. Planiranje razvoja informacijskog sustava

Strateško planiranje informacijskog sustava

Analiza poslovnog područja
Dekompozicija ciljeva, funkcija i procesa poslovnog sustava
Tehnika matričnih dijagrama
Osnovna arhitektura informacijskog sustava

3.1. Strateško planiranje informacijskog sustava

Uloga poslovodstva u procesu planiranja

Faze strateškog planiranja informacijskog sustava i metode i tehnike
Kratki prikaz metodika za strateško planiranje informacijskog sustava

Strateško planiranje informacijskog sustava nezaobilazan je proces u razvoju informacijskog

sustava i proizlazi iz strateškog planiranja poslovnog sustava. U literaturi su uglavnom
dostupne smjernice za rad, dok je znanje i iskustvo projektanata i poslovodstva odlučujuće za
njihovu provedbu.

U fazi strateškog planiranja izrađuje se opći model objektnog sustava (model poslovanja)
koji opisuje procese, podatke, ciljeve, kritične pretpostavke, ključne čimbenike uspješnosti,
zahtjeve poslovodstva prema informacijskom sustavu itd.

3.1.1. Uloga poslovodstva u procesu planiranja

Poslovodstvo u fazi strateškog planiranja informacijskog sustava ima važnu ulogu. Ono daje
smjernice za poslovanje, ali daje i podršku razvoju informacijskog sustava. Budući da
određuje model poslovnog sustava i poslovne ciljeve poduzeća aktivno sudjeluje u izradi
modela poslovanja i nadzire rad na razvoju informacijskog sustava.
Bez podrške poslovodstva nije moguće realizirati kvalitetan i uspješan informacijski
sustav.

3.1.2. Faze strateškog planiranja informacijskog sustava

Opći je pristup da se analiza poslovnog sustava odnosno planiranje informacijskog sustava

provodi “odozgo prema dolje” (“top-down”), a izvedba informacijskog sustava “odozdo
prema gore” (“bottom-up”).

42
Pristup “odozgo prema dolje” znači da se prvo izrađuje model najviše razine apstrakcije
(konceptualni model), zatim logički model, pa fizički i na kraju razvoj završava izradom i
primjenom informacijskog sustava. U suprotnom, polazi se od nižih razina apstrakcije prema
višim. Primjerice, kada se kod informacijskog sustava za koji ne postoji potpuna
dokumentacija treba provesti odgovarajuća poboljšanja započinje proces povratnog
inženjeringa. To znači da se iz postojećeg fizičkog modela rekonstruira logički model.
U fazama planiranja informacijskog sustava određuju se ciljevi poslovanja, analizira se
postojeća organizacija poslovanja, popisuju se poslovni procesi i klase podataka koje se
koriste u poslovnom sustavu. Faze planiranja informacijskog sustava određene su poslovnim
sustavom i ovise o njegovim osobinama.
U fazama izvedbe informacijskog sustava formira se baza podataka, definiraju se i izrađuju
aplikacije i procedure, uvodi se nova organizacija poslovanja koju omogućava i podržava
novi informacijski sustav, procjenjuju se učinci izrade i njegova uvođenja u primjenu. Faze
izvedbe informacijskog sustava određene su informacijskim sustavom i ovise o njegovim
osobinama.
Pri strateškom planiranju informacijskog sustava oblikovanje osnovne arhitekture
informacijskog sustava točka je prijelaza iz faza planiranja u faze izvedbe informacijskog
sustava38 (prikazano na slici 17.).

Slika 17. Sustavni postupak izgradnje informacijskog sustava

38
Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997
43
To znači da se u fazama planiranja informacijskog sustava modelira poslovni sustav, a u
fazama izvedbe se izgrađuje informacijski sustav.

3.1.3. Kratki prikaz metodika za strateško planiranje IS-a

Informacijski sustav određen je trima temeljnim elementima:

• događajima,
• procesima,
• podacima.

Svaki model informacijskog sustava mora sadržavati detaljne specifikacije sva tri temeljna
elementa. Redoslijed analize tih elemenata različit je za različite metodike.
U zavisnosti od redoslijeda najopćenitije ih dijelimo na metodike orijentirane:
• događajima, kada analiza odnosno projektiranje informacijskog sustava počinje
definiranjem događaja odnosno tokova podataka u sustavu
• procesima, kada analiza počinje od dekompozicije procesa na podprocese, dakle polazni
su dijagrami dekompozicije i dijagrami toka podataka;
• podacima, kada analiza počinje definiranjem logičkog modela podataka odnosno od
izrade globalnog modela entiteti-veze.

Slika 18. Preklapanje tehnika modeliranja

44
U praksi se koriste metodike koje kombiniraju dva ili sva tri navedena pristupa. Na slici
18. prikazano je nekoliko glavnih tehnika modeliranja te njihovo preklapanje39.
Svaki od modela stvarnog svijeta mora se uklopiti u kontekst cjelokupnog poslovnog
stremljenja, koje je izraženo ciljevima, prioritetima i kritičnim čimbenicima uspjeha
poslovnog sustava. Izbor metodologije rada na razvoju i dokumentiranju informacijskog
sustava često je unaprijed određen bilo znanjima i iskustvom projektanta, bilo dostupnim
programskim pomagalom CASE za projektiranje i razvoj informacijskog sustava. Svaka od
metodika ima svoje prednosti i mane, no unatoč tome ako se dosljedno provode rezultat je
uspješan i kvalitetan informacijski sustav.

U fazi strateškog planiranja informacijskog sustava metodike koje se koriste mogu se

podijeliti na:
• klasične, opće poslovne, kao što je, primjerice, BSP (Bussiness System Planning),
koja je dobra ali suviše općenita za brzu primjenu;
• klasične strukturne, primjerice metodika SSADM, koja je veoma detaljna i
razrađena;
• podatkovno usmjerene, primjerice Oracle-ov skup metoda pod nazivom
CASE*Method, ili informacijski inženjering J. Martina;
• procesno usmjerene, primjerice BPR (Bussiness Process Reengineering).

Osnovne osobine nekoliko karakterističnih metodika biti će ovdje prikazane samo

informativno.

BSP (Bussiness System Planning) je metodika koju je definirao IBM i počeo ju komercijalno
primjenjivati još sedamdesetih godina. Poslužila je kao uzor svim kasnijim metodikama.
Sadrži tri osnovne grupe dokumenata kojima je opisano:
• modeliranje podataka (određivanje klasa podataka),
• modeliranje funkcija (funkcionalno raščlanjivanje odnosno dekompoziciju funkcija, te
opis procesa),
• modeliranje ciljeva (strukturno raščlanjivanje ciljeva, kritičnih pretpostavki i njihovo
povezivanje s podacima i procesima).

BSP se primjenjuje samo u fazi strateškog planiranja informacijskog sustava.

SSADM40 (Structured Systems Analisys and Design Method) je metodika razvijena u

Velikoj Britaniji koja je 1983. godine postala standard za vladine projekte. Tijekom godina
postala je i standard kojeg primjenjuje veliki broj informatičkih kuća.
SSADM je cjelovita metodika, detaljno opisuje pristup razvoju i propisuje predložak
razvojnog ciklusa i procesa razvoja. Za svaku fazu propisuje metodu i tehniku, ulazne
parametre i izlazne rezultate. Podržana je većinom CASE pomagala.

39
Barker, R.: CASE*METHOD Tasks and Deliverables, Addison-Wesley Publishing Company, 1991.
40
Prema Strahonja, V. et al.: "Projektiranje informacijskih sustava", Zavod za informatičku djelatnost RH i Ina
Info, Zagreb, 1992.
45
Metodikom SSADM određeno je sedam faza razvoja informacijskog sustava:

• pokretanje projekta,
• utvrđivanje izvodljivosti projekta,
• analiza poslovnog sustava,
• oblikovanje informacijskog sustava,
• izrada informacijskog sustava,
• primjena, te
• korištenje gotovog sustava.

Svaka faza sastoji se od dva ili više stupnjeva, a svaki stupanj od više koraka. Struktura faza i
stupnjeva je hijerarhijska, a koraka (aktivnosti) mrežna, što znači da se više koraka može
odvijati paralelno.
Ova metodika se neprekidno razvija. Registrirana je kao "Certification Trade Mark" tako da
organizacije koje ovu metodiku službeno koriste moraju imati licencu Central
Communications and Telecommunications Agency (CCTA).

U fazi strateškog planiranja informacijskog sustava ova metodika se ne koristi.

U CASE*Method (skup metodika tvrtke Oracle) sistematiziran je postupak definiranja

arhitekture informacijskog sustava koji uključuje sljedeće aktivnosti41:
• Identificirati poslovne potrebe i logičke zavisnosti;
• Izabrati aplikacijska područja i granice informacijskog sustava (podsustava) u odnosu
na model funkcija;
• Ispitati postojeće informacijske sustave da se odredi njihova buduća primjenjivost,
koegzistencija i povezanost, te prikupiti informacije o obujmu i frekvenciji;
• Identificirati moguće tehnologije;
• Identificirati moguća alternativna rješenja za svako aplikacijsko područje, ispitati
izvedivost svakog od njih i prihvatiti ili odbaciti ona koja su tehnički ili ekonomski
neisplativa;
• Prikazati, raspraviti i prihvatiti određenu arhitekturu sustava;
• Izraditi preporuke za rekonstrukciju postojećeg ili izgradnju budućeg informacijskog
sustava, promjenu poslovanja, organizacije ili bilo kojeg drugog područja, što se
utvrdi raspravama.

Ovaj postupak se uz modifikacije primjenjuje u svim metodologijama koje se koriste u fazi

strateškog planiranja informacijskog sustava42.
Dakle, nacrt osnovne arhitekture informacijskog sustava proizlazi iz poslovnog modela,
dostupnih tehnologija te postojećih informacijskih sustava (slika 19.).
41
Barker, R.: CASE*METHOD Tasks and Deliverables, Addison-Wesley Publishing Company, 1991.
42
Zanimljivo je navesti da autor u procjeni potreba za ostvarenje ove faze projektiranja preporučuje uključiti
dva ili tri iskusna arhitekta sustava, jer zadatak nije lagan i njegovi su efekti širokog dosega.
46
 Izvor : Barker, R.: CASE*METHOD Tasks and
Deliverables, Addison-Wesley Publishing
Company, 1991.

Slika 19. Strateško planiranje informacijskog sustava

BPR43 (Bussiness Process Reengineering, u hrvatskom prijevodu preoblikovanje poslovnih

procesa ili poslovni reinženjering) je metodika koja je, kada su je 1993. godine predstavili
njeni autori Hammer i Champy, izazvala buru interesa, ali i suprotstavljanja.

BPR je temeljito redefiniranje i korjenito preoblikovanje postojećih poslovnih procesa radi

postizanja drastičnih poboljšanja najvažnijih sastavnica poslovanja: troškova, kvalitete i
brzine.

Ovu definiciju potrebno je pobliže objasniti.

«Temeljito» znači povratak osnovnim pitanjima zašto se nešto radi na način kako se radi, te
se utvrđuje kako bi trebalo raditi. U pravilu se ignorira postojeće stanje koje se želi
promijeniti.
«Korjenito» znači ponovno osmišljavanje nekog posla od početka (iz korijena), a ne samo
njegovo poboljšavanje, uređivanje ili modifikacija.
«Drastično» znači da se ne treba baviti sitnim poboljšanjima postojećeg, već kvalitativnim
skokovima.
«Procesi» znači da se umjesto bavljenja zadacima, poslovima i organizacijskim strukturama
pozornost treba usmjeriti na poslovne procese.

43
Srića et al: Menedžerska informatika, MEP Consulting, Zagreb, 1999., str 5-20
47
Prije informatizacije bilo kojeg procesa uz primjenu ove metodike potrebno je utvrditi da li taj
proces treba mijenjati, proširiti ili ukinuti. Posljedice na organizaciju poslovnog sustava su
značajne, pa je i prikriveni otpor provođenju poslovnog reinženjeringa velik44.

SPIS45 (Strateško planiranje informacijskih sustava) je skup metoda koje preporuča

prof.dr.sc. Brumec u fazi strateškog planiranja IS-a. Obuhvaća već poznate metode i tehnike,
sa naglaskom na to ŠTO treba uraditi, a ne KAKO to uraditi.
Značajke ove metodike su da je za izradu strateškog plana potrebna suradnja i suglasnost svih
učesnika o elementima sadržaja plana.
Plan mora biti izrađen u kratkom roku (1-3 mjeseca) i mora biti izrađen u takvom obliku da se
sve činjenice koje su u njemu utvrđene mogu koristiti u sljedećim fazama razvoja
informacijskog sustava.

MIRIS46 (Metodika za razvoj informacijskih sustava) je još jedna metodika hrvatskih autora
koju je uveo dr.sc. Pavlić. Njome se ukupan posao razvoja informacijskog sustava dijeli na
logičko i fizičko oblikovanje informacijskog sustava.
Pri tomu logičko oblikovanje sadrži strateško planiranje informacijskog sustava, izradu
glavnog projekta te izvedbeni projekt.
Fizičko oblikovanje čini izvedba programske podrške, uvođenje i primjena novog
informacijskog sustava, te njegovo održavanje.
Koristi se otprije poznatim metodama i tehnikama.

Primjenom svih navedenih metodika (kao i onih koje nisu ovdje ukratko opisane) trebao bi se
polučiti rezultat u obliku dokumenta koji sadrži:
• Sažete preporuke poslovodstvu (posebno prioritete vezane uz poslovne ciljeve te koji su
kritični faktori uspjeha),
• Temeljnu arhitekturu informacijskog sustava,
• Granice sustava,
• Promjene u organizaciji i poslovnoj tehnologiji koje se očekuju,
• Model procesa,
• Model podataka,
• Model resursa, te
• Plan realizacije po fazama.

44
Posebno u nas jer se pod krinkom poslovnog reinženjeringa posljednje desetljeće 20. stoljeća provodilo
otpuštanje zaposlenika i smanjivanje vrijednosti poduzeća. Stoga se zaposlenici uvijek kada se spominje
reinženjering boje da će biti proglašeni tehnološkim viškom i da će ostati bez posla. Takva odluka uvijek je
poslovna odluka i nju ne donose informatičari (iako mogu na nju značajno utjecati).
45
Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997.
46
Pavlić, M.: Razvoj informacijskih sustava, Znak, Zagreb, 1996.
48
3.2. Analiza poslovnog sustava

Strateška analiza poslovanja organizacijskog sustava

Preoblikovanje poslovnih procesa (BPR)
Izrada “grubog” modela podataka
Određivanje temeljne arhitekture informacijskog sustava
Analiza postojećih informacijskih podsustava i utvrđivanje potrebnih
promjena
Određivanje prioriteta razvoja pojedinih informacijskih podsustava

Prije početka posla na planiranju i izgradnji informacijskog sustava moraju se u poslovnom

sustavu provesti pripremne aktivnosti. One se prvenstveno odnose na utvrđivanje potreba za
promjenama i prikupljanje potrebnih podataka za pripremu uvodnih materijala koji trebaju
biti podastrijeti poslovodstvu kako bi ono dalo svoju podršku i suglasnost. Tek nakon toga
počinje prava priprema projekta koji treba realizirati. Pripremne aktivnosti dijele se na tri
osnovne faze.

Prvu fazu čini razumijevanje potreba poslovnog sustava i iskazivanje zanimanja za pokretanje
projekta izgradnje informacijskog sustava. U ovoj fazi potrebno je izraditi prijedlog
poslovodstvu u kojem se mora obrazložiti koje su moguće koristi od novog informacijskog
sustava, koliki je očekivani opseg projekta, koje su minimalne pretpostavke potrebne za
ostvarenje namjere, te koji članovi poslovodstva trebaju biti učesnici u projektu. Pri tome još
nije moguće racionalno procjenjivati troškove informacijskog sustava i buduće učinke, ali je
moguće planirati troškove vezano uz provedbu njegova strateškog planiranja. Obavezno je
primjenom neke metodike procijeniti organizacijsku i informacijsku zrelost poslovnog
sustava prije pokretanja projekta, kako bi se izbjegla mogućnost neuspjeha.

U drugoj fazi se osigurava suglasnost najvišeg poslovodstva, na način da se određuju

nadglednici projekta odnosno članovi poslovodstva odgovorni za nadzor projekta i
koordinaciju projektom. Određuju se i okvirna novčana sredstva za provedbu strateškog
planiranja informacijskog sustava. Uvijek treba voditi račun da bez suglasnosti i podrške
najvišeg poslovodstva nema ni uspješnog projekta ni kvalitetnog informacijskog sustava.

Treća faza je faza pripreme projekta, kada se određuju lokacije gdje će se projekt razvijati i
testirati, te organizacijske jedinice poduzeća i pojedinci koji će biti uključeni u projekt.
Osiguravaju se potrebna pomagala i sredstva, a učesnici u projektu dodatno se educiraju ako
je to potrebno. Prikuplja se i vrednuje sva postojeća dokumentacija o strategiji poslovanja
(strateški planovi i sl.). Izrađuje se plan projekta i određuju kontrolne točke i rok izvršenja
posla. Odstupanja od plana projekta zacrtanog u ovoj ranoj fazi vrlo su česta, ali je za svaku
aktivnost koja kasni moguće odrediti razloge zakašnjenja i, na temelju stečenog iskustva,
pokušati spriječiti dalja odstupanja.

Na pitanje u čijoj je nadležnosti pokretanje projekata razvoja informacijskog sustava teško je

odgovoriti. Jednom će to biti informatičari koji predlažu prijelaz na novo razvijenu
informacijsku tehnologiju jer je postojeća zastarjela i postaje je preskupo ili čak nemoguće
dalje održavati. Drugi puta su to korisnici koje postojeći sustav ne zadovoljava zbog promjena
49
u poslovnoj tehnologiji ili čak i asortimanu proizvoda. Stoga treba razlučiti kako na odluku o
razvoju informacijskog sustava utječe poslovna strategija, strategija informacijskog sustava i
strategija informatičke tehnologije (prikazano slikom 20.).

POSLOVNA
STRATEGIJA
Kamo ide poslovanje i
Utjecaj IT zašto?
Postavlja i mijenja ciljeve
Donosi poslovne odluke

Podrška poslovanju Smjernice za poslovanja

IS STRATEGIJA
Što je potrebno za ostvariti
Polazi od poslovanja ciljeve?
Bavi se aplikacijama

Tehnološka infrastruktura Potrebe i prioriteti

IT STRATEGIJA

Kako to ostvariti?
Polazi od aktivnosti
Bavi se tehnologijom

*Izvor Dr. Brumec: Strateško planiranje IS-a, FOI Varaždin, 1997.

Slika 20. Odnos poslovne strategije, IS i IT strategije

Analiza poslovnog sustava temelji se na postavci da najviše znanja o poslovnom sustavu ima
poslovodstvo i poslovni stručnjaci. Stoga je analiza poslovne tehnologije nezaobilazan dio
analize poslovnog sustava. Poslovna tehnologija trebala bi biti ključni čimbenik za izbor i
informacijske tehnologije i strategije razvoja informacijskog sustava47. Analiza poslovnog
sustava provodi se u šest osnovnih koraka koje preporučaju uglavnom sve metodike48:
1. Strateška analiza poslovanja organizacijskog sustava;
2. Preoblikovanje poslovnih procesa ili poslovni reinženjering (BPR);
3. Izrada "grubog" modela podataka;
4. Određivanje temeljne arhitekture informacijskog sustava;
5. Analiza postojećih informacijskih podsustava i utvrđivanje potrebnih promjena;
6. Određivanje prioriteta razvoja pojedinih informacijskih podsustava.

47
Primjerice, neće se nabavljati jednaka oprema i softver za poduzeće koje se bavi prodajom određenih roba u
dućanima (maloprodaja), poduzeće koje se bavi veleprodajom na jednoj lokaciji i poduzeće koje robu prodaje
putem Interneta. A sva tri poduzeća bave se trgovačkom djelatnosti.
48
Detaljnu specifikaciju svakog koraka može se naći u literaturi (primjerice Barker: CASE*Method: Tasks and
Deliverables")

50
3.2.1. Strateška analiza poslovanja organizacijskog sustava

Strateška analiza poslovanja organizacijskog sustava odvija se u timskom radu, pri čemu se
analiziraju ciljevi projekta i problemi koji postoje ili se tek očekuju pri njegovoj realizaciji,
ključni čimbenici uspjeha, te utjecaj tehnologije na projekt. Primjerice, pogrešan izbor
tehnologije koju se želi primjenjivati u budućem razdoblju može prouzročiti velike troškove u
budućnosti, a ponekad i neuspješan informacijski sustav.
Tijekom ove faze provodi se:
a. Održavanje prvog radnog sastanka,
b. Prikupljanje informacija i intervjua, što uključuje pripremu za intervju, provođenje
intervjua, prikupljanje dokumenata razmatranih tijekom intervjua i sistematizaciju
bilješki sa intervjua.
c. Provjeru navoda iz intervjua koji se odnose na poslovnu tehnologiju, koju treba
obavljati gdje god je to moguće. Ponekad osobe s kojima se vode razgovori imaju
nepotpune informacije o poslu koji se redovito obavlja, iako možda dobro razumiju
cjelinu poslovanja49.

Osobe koje su zadužene za razradu i sistematizaciju podataka prikupljenih putem intervjua

prvo moraju raščlaniti (dekomponirati) organizacijsku strukturu poslovnog sustava i njegovu
poslovodnu strukturu, te pridružiti rukovoditelje organizacijskim jedinicama kojima
upravljaju. Zatim trebaju odrediti osnovne funkcije poslovnog sustava i raščlaniti ih
(dekomponirati ih). Na temelju tih podataka trebaju izraditi matrice veza kojima povezuju
funkcije (procesa) i organizacijske jedinice te funkcije poslovnog sustava i rukovoditelje. Na
kraju se dokumentiraju, provjeravaju i vrednuju izrađeni modeli. Preporuka je da se uvijek svi
materijali daju na verifikaciju osobama s kojima su intervjui vođeni i da se od njih traži pisana
potvrda (ili makar samo potpis) da su navedene tvrdnje točne i istinite.

Rezultat ove faze je pregledni model postojećeg poslovnog sustava, uz koji su priloženi svi
relevantni dokumenti.

3.2.2. Preoblikovanje poslovnih procesa (BPR)

O preoblikovanju poslovnih procesa bilo je riječi kao o jednoj od metodika koje se

primjenjuju pri strateškom planiranju informacijskog sustava. Uvijek se razmatraju poslovni
procesi promatranog poslovnog sustava, ponekad kao skupine procesa koji se odnose na
određeno poslovno područje (funkcije), a ponekad kao postupci odnosno aktivnosti koje se
odnose na operativnu provedbu određenih segmenata posla.
Poslovne funkcije poduzeća mogu se definirati kao grupa procesa koji zajedno podržavaju
željene ciljeve i potrebe poslovnog sustava, koji se odvijaju bez prekida, nisu temeljeni na
49
Ovaj problem jako je izražen kod novih članova poslovodstava koji su na te pozicije došli po političkoj i inim
linijama. Iako oni mogu biti stručnjaci na svom poslu, uvijek je potreban period uhodavanja i upoznavanja
problematike s kojom se susreće promatrani poslovni sustav. Treba se prisjetiti da i svaka nova Vlada ima
svojih «100 dana».
51
organizacijskoj strukturi i kategoriziraju što se radi, a ne kako se radi. Funkcije se često
grupiraju u funkcijska područja koja podržavaju organizacijsku strukturu poduzeća i za
njihovo funkcioniranje poznata je nadležna odgovorna osoba.

Procesi u poduzeću su specifične aktivnosti koje se ponavljajući izvode u nekom vremenu te

pomoću određenih resursa postižu neki parcijalni cilj, koji imaju definiran i početak i kraj (pa
se stoga mogu opisati u terminima ulaza i izlaza), nisu temeljeni na organizacijskoj strukturi,
te identificiraju što se radi, a ne kako se radi.

Procesi su invarijantni dijelovi poslovne tehnologije, odnosno povezani procesi čine

poslovnu tehnologiju poduzeća.

Procedure detaljno opisuju pojedine postupke, uključuju tehnologiju rada te određuju kako se
radi. Često se za procedure koristi termin aktivnost, kojim se opisuje radnja usmjerena na
izvršenje nekog zadatka.

Tijekom poslovnog reinženjeringa provodi se kritičko preispitivanje modela poslovanja od

strane poslovodstva i korisnika i najčešće se postojeći model poslovanja poboljšava. Na
temelju predviđenih promjena i poboljšanja izrađuje se nova organizacijska shema, izrađuju
se nove matrica veza funkcija (procesa) i organizacijskih jedinica i funkcija i rukovoditelja,
kojima se zamjenjuju one izrađene u prethodnoj fazi strateške analize poslovanja. Na kraju se
obavezno pribavlja suglasnost poslovodstva za provođenje promjena.

Tijekom poslovnog reinženjeringa utvrđuje se koji su procesi u poslovnom sustavu višak,

koje je moguće pojednostavniti, a koje obavljati na potpuno drugačiji način. Vrlo često
obavljanje poslovnih procesa ovisi o postojećem informacijskom sustavu, pa se u fazi
planiranja novog sustava može, uz nove informacijske tehnologije, uvesti i nova tehnologija
rada.

3.2.3. Izrada "grubog" modela podataka

Izrada modela podataka u svakom je poslovnom sustavu izuzetno zahtjevan i često dugotrajan
posao. Za potrebe strateškog planiranja informacijskog sustava dovoljno je izraditi tzv. grubi
model podataka kojim se opisuju klase podataka u sustavu.

Klasa podataka je dokument ili zapis u bilo kojem obliku, stvoren nekim procesom unutar
(ili izvan) sustava i korišten od jednog ili više procesa unutar (ili izvan) sustava. Dakle, klasa
podataka jest logički oblikovan i povezan skup podataka koji se odnose na jednu pojavnost.
Entitet (nositelj informacije) jest bilo koja važna stvar ili pojava koju treba poznavati ili
čuvati podatke o njoj.

Dok je klasa podataka opća poslovna kategorija, entitet je opća informatička kategorija.

52
Klase podataka povezuju procese u poslovnom sustavu, stvarajući tako sa njima cjelovitu i
konzistentnu poslovnu tehnologiju. Entiteti povezuju procese u informacijskom sustavu, te
zajedno s njima opisuju tijek podataka unutar sustava.

Faza izrade "grubog" modela podataka sastoji se od prepoznavanja osnovnih klasa podataka u
poslovnom sustavu i njihovo raščlanjivanje na tipove entiteta. Obavezno se izrađuje matrica
veza klasa podataka (entiteta) i funkcija (poslovnih procesa) odnosno matrica poslovne
tehnologije. Utvrđuje se izvor klasa podataka u poslovnom sustavu što se dokumentira
izradom matrice veza organizacijskih jedinica i klasa podataka. Na kraju se provodi
dokumentiranje, provjera i vrednovanje izrađenog modela podataka.

3.2.4. Određivanje temeljne arhitekture informacijskog sustava

Određivanjem temeljne arhitekture informacijskog sustava određuje se budući izgled, ali i

plan izrade novog.

Temeljna arhitektura informacijskog sustava sadrži50:

• podsustave odnosno aplikacijska područja,
• njihovu strukturu odnosno procese koji su obuhvaćeni svakim podsustavom i
• njihove međusobne veze.

To je osnova za dalji postupni razvoj programske osnovice informacijskog sustava, u kojem

će podsustave podržavati aplikacije, pojedine procese programi (odnosno stavke u glavnom
izborniku svake aplikacije), a aktivnosti će biti stavke u izbornicima nižeg reda. Programska
podrška izvedena na taj način zaista podržava poslovnu tehnologiju na temelju koje je nastala.
Temeljna arhitektura informacijskog sustava mora omogućiti izbor prioriteta izgradnje
informacijskog sustava po podsustavima, postupnost izvođenja cjelovitog informacijskog
sustava, uz međusobnu povezanost podsustava i otpornost informacijskog sustava na
promjene.

Određivanje temeljne arhitekture informacijskog sustava provodi se izvođenjem analize

sklonosti procesa nad matricom poslovne tehnologije, pri čemu se grupiraju funkcije i klase
podataka u informacijske podsustave na temelju njihovih međusobnih sklonosti, čime se
omogućava određivanje granica informacijskih podsustava. Preporuča se predložiti više
varijanti arhitekture budućeg informacijskog sustava sukladno različitim početnim
parametrima (to mogu biti različite tehnologije rada, različite cijene koštanja opreme i
softvera, različita organizacija poslovnog sustava i slično). Na kraju se pribavlja suglasnost
poslovodstva za izbor temeljne arhitekture informacijskog sustava.

50
Brumec, J: Optimizacija strukture informacijskog sustava, Zbornik radova, FOI Varaždin, 1993.
53
3.2.5. Analiza postojećih informacijskih podsustava i utvrđivanje
potrebnih promjena

S obzirom da se ne može zanemariti utjecaj postojećih programskih rješenja na tehnologiju

rada u poslovnom sustavu, potrebno je analizirati postojeći informacijski sustav i njegove
značajke. Važno je naglasiti da se ova analiza djelomično može provoditi istodobno i
paralelno ostalim koracima, čime se štedi na vremenu ali i bolje upoznaje poslovanje
promatranog poduzeća.

Tijekom analize postojećeg informacijskog sustava obavezno se izrađuju matrice veza

informacijskih podsustava (IPS) i organizacijskih jedinica, informacijskih podsustava (IPS) i
rukovodilaca, informacijskih podsustava (IPS) i funkcija (procesa), informacijskih podsustava
(IPS) i klasa podataka (entiteta). Ako u poslovnom sustavu postoji ranije izrađena
dokumentacija potrebno ju je provjeriti i dopuniti ako je to potrebno. Tada se može utvrditi
razina podudarnosti postojećih i novih informacijskih podsustava, te prepoznati potreba za
zamjenom ili poboljšanjem postojećih podsustava. Pri tome se za određivanje potrebe za
zamjenom postojećeg informacijskog podsustava mogu koristiti razni kriteriji. Jedan od
najznačajnijih je njegov trošak održavanja i mogućnost zajedničkog funkcioniranja s
ostalim podsustavima u novom informacijskom sustavu.

3.2.6. Određivanje prioriteta razvoja pojedinih informacijskih

podsustava

Važan razlog za izradu strateškog plana razvoja informacijskog sustava je formiranje

informacijskih podsustava i njihovih granica. Time je omogućena modularnost
informacijskog sustava odnosno izrada pojedinih informacijskih podsustava neovisno jedan
od drugoga51. Svaki takav informacijski modul mora zadovoljiti osnovne elemente
jedinstvenosti informacijskog sustava te biti izrađen na temelju zajedničkih standarda.
Redoslijed prioriteta izrade pojedinih modula pri tomu ovisi o različitim kriterijima (to može
biti cijena ulaganja u novu opremu, vrijeme potrebno za razvoj softvera koje je u nekim
slučajevima dulje a u drugima kraće, postojanje programskog rješenja s kojim korisnici nisu
zadovoljni ali koje može poslužiti još neko vrijeme i slično), a konačnu odluku uvijek donosi
poslovodstvo.

Za određivanje prioriteta razvoja pojedinih informacijskih podsustava treba procijeniti

potencijalne koristi svakog od njih, usporediti zahtjeve korisnika zbog određivanja složenosti
projekta, procijeniti utjecaj na organizaciju poslovnog podsustava, procijeniti iskoristivost
postojećeg informacijskog podsustava (ako postoji), procijeniti potrebne resurse i vjerojatnost
uspjeha, te utvrditi mogućnost usporednog razvoja više informacijskih podsustava.

51
Često se za jasniji opis modularnosti koristi primjer lego kockica. Lego kockicama se mogu složiti pojedini
uređaji ili građevine koji se mogu, ali i ne moraju, povezati u jednu cjelinu. Redoslijed izrade takvih modula od
lego kockica uglavnom ovisi o skupu kockica koji dijete ima na raspolaganju, a o dubini roditeljskog džepa ovisi
rok završetka igre.
54
Redoslijed prioriteta razvoja informacijskih podsustava smije se mijenjati samo u trenutku
kada se neki od modula stavlja u funkciju. Tijekom izrade modula redoslijed prioriteta ne
smije se mijenjati52.

3.3. Dekompozicija ciljeva, funkcija i procesa poslovnog

sustava
Model procesa
Model resursa

Općenito se svaki složeni sustav sastoji od niza elementarnih sustava. Stoga se informacijski
sustav koji podržava složeni poslovni sustav sastoji od niza informacijskih podsustava, a
svaki od njih može se smatrati elementarnim informacijskim sustavom. Kako podijeliti
informacijski sustav na njegove podsustave i kako ih zorno prikazati omogućava metoda
dekompozicije (strukturnog raščlanjivanja).
Dekompozicija je postupak razlaganja složenih struktura. Stoga se njenom primjenom
složena struktura postupno raščlanjuje i time pojednostavljuje53. Dekomponirati se mogu
ciljevi poslovnog sustava (od najsloženijeg, općenito definiranog) do jednostavnog i svakom
pojedincu razumljivog cilja koji treba realizirati. Ili, dekomponirati se mogu organizacijske
jedinice pa tako zorno prikazati strukturu odgovornosti i nadležnosti za pojedine segmente
poslovanja.
Dekompozicijom se dobiva hijerarhijski prikaz promatrane složene strukture, pa je ta metoda
stoga osnova za strukturiranje informacijskog sustava. Pri tome se dekomponiraju poslovni
procesi, a rezultat se iskazuje u modelu procesa.
Model procesa prikazuje skupove procesa koji mijenjaju stanje sustava i pomoću kojih se
formiraju izlazi iz sustava (odnosno opisuju događaji s objektima). Pri planiranju izrade
informacijskog sustava potrebno je izraditi njegov model koji se odnosi na odgovarajući
segment realnog poslovnog sustava, pri čemu je model procesa samo jedan od podmodela koji
čine model informacijskog sustava. Potrebno je još izraditi model podataka koji prikazuje
stanje sustava preko skupa podataka (opisuje stanje objekata), i model resursa koji prikazuje
resurse potrebne za realizaciju modela (opremu, kadrovske resurse i slično).

3.3.1. Model procesa

Najčešća podjela poslovnog sustava na funkcijska područja navodi na misao da postoji više
razina podjele (što podržava organizacijska teorija), a koje su posljedica organizacijske
prirode sustava. Primjerice, u jednom složenom poslovnom sustavu:

52
Iskustvo je pokazalo da ako se redoslijed prioriteta mijenja tijekom izrade modula, projekt jako poskupljuje i
posao se produžava, a ponekad se projekt niti ne završi.
53
Poznata je uzrečica «Podijeli pa vladaj!».
55
 • na prvoj razini sustav se obično dijeli (dekomponira) na osnovna funkcijska područja
koja objedinjuju skup srodnih poslova,
• na drugoj se složenija funkcijska područja dijele na međusobno slična, ali tehnološki
različita područja (funkcije), dok se
• na trećoj i nižim razinama (ako je potrebno) razrađuju specifičnosti i iznimke (procesi
i procedure).

Primjere za takvu višerazinsku podjelu moguće je pronaći gotovo u svim djelatnostima,

posebice u proizvodnji robe i usluga. Iako sličnost proizvodnog asortimana navodi na
pripadnost jednom poslovnom podsustavu, različitost tehnoloških i proizvodnih postupaka
može zahtijevati podjelu podsustava proizvodnje na više podsustava na nižoj razini.
Primjer dekompozicije procesa u poslovnom sustavu prikazan je slikom 21.

Poslovni sustav

Prodaja Proizvodnja Administracija

Funkcija
.... Funkcija
.... Funkcija

Prodajni razgovor Ugovaranje Pravni poslovi Financije

Proces Proces
.... Proces Proces

Potpisivanje Evidentiranje Pohranjivanje

Izrada ugovora ugovora ugovora ugovora
.... ....
Procedura Procedura Procedura Procedura

Slika 21. Primjer dekompozicije procesa (hijerarhijski prikaz)

Cilj dekompozicije informacijskog sustava je pri tome utvrđivanje i raspoređivanje procesa

koji se smatraju invarijantnim dijelovima poslovne tehnologije. Njihovim različitim
povezivanjem mogu se ostvariti različite arhitekture informacijskog sustava, a posljedično i
različite arhitekture programske opreme koju treba razvijati za novi informacijski sustav.
Svaku od tako oblikovanih arhitektura informacijskog sustava čini neki broj podsustava (koji
može, ali i ne mora biti jednak nekoj drugoj arhitekturi), a koji sadrže neki broj procesa (koji

56
mogu biti isti, ali i ne moraju)54. Stoga se prilikom provođenja postupka dekompozicije traže
odgovori na pitanja poput «ŠTO treba napraviti da bi se obavila određena funkcija» ili
«ZAŠTO se nešto radi tako kako se radi».

Obično se postavlja pitanje do kada treba raščlanjivati određeni proces, odnosno do kada treba
provoditi dekompoziciju. Okvirni kriterij kojim se određuje hijerarhija dekompozicije
informacijskog sustava je55:
“Svaki (pod)sustav dekomponira se dotle dok ne postane dovoljno ograničen (jednostavan),
kako bi se svi temeljni elementi koji tvore taj podsustav mogli eksplicite navesti na jednom
zasebnom dijagramu.”

U primjeni je pravilo “sedam plus/minus dva”, dakle raščlanjivanje se provodi do devet razina
dekompozicije, što proizlazi iz osobine čovjeka da pogledom obuhvati ograničen broj
elemenata.
Nakon dekompozicije nastala dokumentacija sadrži najmanje:
• hijerarhijsku strukturu dekomponiranih objekata, koja se prikazuje grafički i opisno, i
• opis dekomponiranih objekata.

Grafički se dekompozicija može predočiti u više različitih oblika, od kojih su osnovni:

• Hijerarhijski ili vertikalni prikaz, prikazan slikom 21., i
• Vodoravni prikaz ili polegnuto stablo, prikazan slikom 22.

Proces 2.1.

Proces 1.

Proces 2.2.

Proces 0 Proces 2.

Proces 2.3.

Proces 3.

Proces 2.4.

Slika 22. Primjer dekompozicije procesa (vodoravni prikaz)

Slično vodoravnom prikazu, dekompozicija se može prikazati Warnier-Orrov-im

dijagramom (slika 23.):

54
Klasić, K. Modeli optimizacije strukture informacijskog sustava, doktorska disertacija, FOI Varaždin, 1998.
55
Radovan, M: Projektiranje informacijskih sistema, Informator, Zagreb, 1989.
57
 Proces 1.
Proces 2.1.
Proces 0.
Proces 2. Proces 2.2.
Proces 2.3.
Proces 3.

Slika 23. Primjer dekompozicije procesa (Warnier-Orrov dijagram)

Vennov dijagram također služi za prikazivanje dekompozicije (slika 24.)56.

Skup X
S

Skup
Skup b a e X z

a b
Skup
Skup e z

Skup S

Vennov dijagram

Slika 24. Primjer dekompozicije procesa (Vennov dijagram)

Izbor oblika grafičkog prikaza dijagrama dekompozicije ovisi o standardu koji je usvojen u
poduzeću, alatu koji se koristi za izradu modela, ili najčešće o subjektivnom izboru pojedinog
analitičara sustava.

3.3.2. Model resursa

Model resursa sadrži specifikaciju tehnološke osnovice. Njime je određen i model

organizacije informacijskog sustava. On prikazuje "procesore" glede njihovih kapaciteta i
dinamike korištenja tih kapaciteta u poduzeću odnosno:
• kadrovske resurse,
• organizacijske jedinice,
• opremu sa aspekta njihova kapaciteta i dinamike korištenja tih kapaciteta.

56
Zbog lošije preglednosti neki projektanti Vennov dijagram dekompozicije često pretvaraju u hijerarhijski
prikaz.
58
Model resursa prikazuje se matricama veza, te grafičkim prikazom modela organizacije
poslovnog i informacijskog sustava. Stoga nije moguće «kopirati» ranije izrađene modele.
Ponekad se događa da se model resursa mijenja u ovisnosti o organizaciji poslovnog sustava
(u tom slučaju se pripremljen model resursa prilagođava novoj organizaciji, a često i
raspoloživim ljudima), a ponekad se mijenja ovisno o tehnološkom napretku (uvođenjem
novih tehnologija mijenjaju se zahtjevi na novi informacijski sustav57).

3.4. Tehnika matričnih dijagrama

Matrica procesa i klasa podataka

Dijagonalizacija matrice i oblikovanje podsustava
Unutrašnja konzistentnost i vanjska povezanost podsustava

Za zorno prikazivanje poslovne tehnologije u praksi se koriste matrice veza kojima se

prikazuju veze između raznovrsnih ili istovrsnih elemenata sustava. Različite matrice veza
izrađuju se u različitim fazama projektiranja informacijskog sustava. U načelu se one koriste
za provjeru cjelovitosti, ispravnosti i logike modela informacijskog sustava s obzirom na
elemente koji ju čine, kod planiranja distribucije i prijelaza na novi informacijski sustav, te
kao mogućnost upravljanja proširivanjem postojećih informacijskih sustava.

Matrica veza je zapravo interna matrica veza unutar jednog sustava odnosno podsustava
S ss , odnosno jedna od četiri matrice potpune matrice sustava. Matrice veza sastoje se od
niza redaka i stupaca u čijim se presječnim poljima označava postojanje ili nepostojanje veze
između elemenata matrice, te priroda njihove veze. Način označavanja može biti različit (od
stavljanja oznaka «+» ili «–» kojima se prikazuje postojanje ili nepostojanje veze između
elemenata matrice, «kvačice» kojom se potvrđuje postojanje veze, do upisa slovčanih oznaka
koje mogu opisivati prirodu promatrane veze). Neka pomagala za projektiranje i razvoj
programske podrške (CASE pomagala) podržavaju automatsku izradu raznih oblika matrica
veza iz elemenata pohranjenih na računalu, jer je izrada matrice veza često dugačak i
mukotrpan posao.

3.4.1. Matrica procesa i klasa podataka

Matrica veze u čijim su redovima upisani procesi, a u stupcima klase podataka, daje
pregledan prikaz poslovne tehnologije na kojem se formalnim postupcima može provjeriti
njezina konzistentnost i cjelovitost. Stoga se ta matrica naziva i matricom poslovne
tehnologije. Za matricu poslovne tehnologije koja će poslužiti za izradu informacijskog
sustava i kojom se prikazuje njegova struktura nadalje će se koristiti terminologija matrica
procesi/entiteti.

57
Primjerice, mogućnost plaćanja parkiranja putem SMS poruka traži drugačije, dopunske resurse za realizaciju
informacijskog sustava kod davatelja usluga. Kod korisnika usluga također izaziva promjene poput nabave
mobitela i ustrojavanje evidencije takvih plaćanja.
59
Matrica poslovne tehnologije izrađuje se pri strateškom planiranju informacijskog sustava, pri
čemu se pri analizi postojećeg sustava iskazuje postojeća poslovna tehnologija, nakon
provedenog preoblikovanja poslovnih procesa željena poslovna tehnologija, a nakon
određivanja strukture informacijskog sustava operativno prihvatljiva poslovna tehnologija.

Redovi matrice poslovne tehnologije popunjavaju se poslovnim procesima u redoslijedu

njihova izvođenja. Svaki poslovni sustav može na drugačiji način organizirati vlastito
poslovanje, tako da se redoslijed procesa može razlikovati od poduzeća do poduzeća, i to za
najjednostavnije, operativne procese. Redoslijed procesa više razine (složenijih procesa)
značajno se ne razlikuje za različite poslovne sustave, a pogotovo nema razlika na razini
funkcija sustava. Primjerice, to znači da će se u većini trgovačkih poduzeća prvo obavljati
naručivanje određenih proizvoda, evidentiranje nabavne i formiranje prodajne cijene, zatim
prodaja proizvoda, pa evidentiranje prodane robe. Međutim, ulazeći u detaljniji opis procesa
pojavljuju se različitosti u tome kako se posao obavlja. Jednom se roba nabavlja od poznatog
dobavljača uz plaćanje unaprijed, po predračunu, drugi puta se roba plaća po fakturi nakon što
je roba isporučena, a treći puta se plaća tek po realiziranoj prodaji. Procesi koji popunjavaju
retke matrice poslovne tehnologije u ovom slučaju mogu čak imati i isti naziv («plaćanje»),
ali je poslovna tehnologija sustava različita.

Slična je pojava i s popunjavanjem stupaca matrice poslovne tehnologije. U stupce se upisuju

klase podataka odnosno entiteti koje određeni proces koristi. U praksi se popisuju dokumenti
koji se koriste u sustavu i njih se proglašava klasama podataka. Time se analitičar sustava,
posebno ako od ranije ne poznaje djelatnost promatranog sustava, upoznaje s poslovnom
tehnologijom i podacima koje će trebati čuvati u novom informacijskom sustavu. Već sada
treba naglasiti da se dokumenti (odnosno klase podataka) kojima se popunjavaju stupci
matrice poslovne tehnologije mogu značajno razlikovati od entiteta kojima se također matrica
popunjava u kasnijoj fazi izrade. Razlika proizlazi iz činjenice da je klasa podataka poslovna
kategorija, a entitet informatička, pa stoga jedna klasa podataka može biti prikazana s jednim
ili više entiteta58.
Stoga, dok matrica poslovne tehnologije prikazuje redoslijed odvijanja procesa u poslovnom
sustavu i uvijek je ista za isti poslovni sustav (nakon što se usuglasi poslovna tehnologija),
matrica procesi/entiteti koje prikazuju arhitekturu informacijskog sustava može biti puno.

Presječna polja matrice poslovne tehnologije popunjavaju se oznakama koje opisuju

aktivnosti procesa nad entitetima:
• C/D (stvaranje/brisanje entiteta, engl. Create/Delete),
• U (ažuriranje entiteta, engl. Update),
• R (čitanje, pretraživanje entiteta, engl. Read) i
• “prazno” odnosno ∅ (kada proces ne vrši operaciju nad entitetom). Umjesto ∅
često se koristi i oznaka 0.

58
Unatoč postupcima modeliranja podataka projektanti mogu izabrati različite strukture podataka za razne
sustave bilo zbog tehnoloških ograničenja bilo zbog nekih drugih subjektivnih razloga. Pri tome sva rješenja
mogu biti korektna i mogu dobro funkcionirati.
60
PRIMJER:

Neka je definiran sustav od 12 procesa i 9 entiteta. Operacije procesa nad entitetima

opisane su u tablici 7. Podacima iz tablice veza procesa i entiteta popunjava se
matrica procesi/entiteti odnosno matrica poslovne tehnologije (tablica 8.).

ENTITET Stvaranje/brisanje Ažuriranje Pretraživanje

E1 p10 p6, p11 p1, p2, p5, p8

E2 p3 --- p4, p7, p9

E3 p1 p8 p2, p4, p5, p6, p7, p10

E4 p2 p12 p4, p6, p11

E5 p4 p1 p5, p7, p8, p10, p12

E6 p6 p4, p10 p9, p12

E7 p5 p8 p7, p11, p12

E8 p6 p7, p12 p1, p2, p4, p5, p10

E9 p9 ---- p1, p6, p8, p11

Tablica 7.: Veze procesa i entiteta (primjer)

Matrica poslovne tehnologije popunjava se na način da se u retke upišu svi procesi bilo kojim
redom, pazeći da se neki ne izostavi. Entiteti se upišu u stupce redom kojim su navedeni u
tablici ulaznih podataka. Zatim se upisuju oznake aktivnosti u presječna polja matrice. Obično
su oznake aktivnosti definirane u ulaznim podacima. Međutim, može se dogoditi da je neka
oznaka pogrešno navedena ili da postoje nelogičnosti u obavljanju poslovnih procesa koje se
očituju tek pri popunjavanju matrice. Stoga se analitičar sustava mora pridržavati formalnih
pravila za popunjavanje matrice poslovne tehnologije, koja se mogu jednostavno opisati59:
• Jedna se klasa podataka generira (nastaje) samo u jednom procesu. Ako klasa
podataka nastaje u više različitih procesa upitna je nadležnost i odgovornost za
podatke, kao i njihova točnost. U poslovanju to znači zbrku u poslovanju jer se
krivnja za loše manipuliranje određenim dokumentom najčešće prebacuje s jedne
osobe na drugu.
• Jedna se klasa podataka može koristiti u više procesa. Dokument nastao jednim
procesom može biti korišten u više drugih, kasnijih procesa.
• Proces koji samo koristi, a ne generira nijednu klasu podataka je “parazitski” ili radi
za okruženje. Primjer takvih procesa su razni izvještaji koji se sastoje od na određeni
način sortiranih i pristupačno prikazanih podataka koji su nastali ranije u sustavu.

59
Brumec, J: Optimizacija strukture informacijskog sustava, Zbornik radova, FOI Varaždin, 1993.
61
 • Proces koji samo generira, a ne koristi nijednu klasu podataka treba posebno
analizirati. Stvaranje nove klase podataka prihvatljivo je ako se radi o temeljnim
podacima koje treba pratiti (često se u praksi zovu matičnim podacima). Ponekad to
mogu biti procesi koji preuzimaju iz nekog drugog informacijskog sustava podatke
koji se dalje koriste u poduzeću. S obzirom da se radi o različitim izvorima podataka,
različite točnosti i načina nastanka, svaki takav pojedinačni slučaj treba posebno
razmotriti i analizirati.
• Ne može postojati proces ni klasa podataka bez ijedne oznake operacije procesa nad
klasom podataka. Može se dogoditi da je došlo do greške u pripremi ulaznih podataka,
ali isto tako može biti slučaj da doista postoji greška u poslovnoj tehnologiji
promatranog poduzeća koju treba ispraviti.

E1 E2 E3 E4 E5 E6 E7 E8 E9

p1 R C/D U R R

p2 R R C/D R

p3 C/D

p4 R R R C/D U R

p5 R R R C/D R

p6 U R R C/D C/D R

p7 R R R R U

p8 R U R U R

p9 R R C/D

p10 C/D R R U R

p11 U R R R

p12 U R R R U

Tablica 8.: Matrica poslovne tehnologije (primjer)

Iz navedenog proizlaze svojstva koje matrica poslovne tehnologije mora zadovoljavati:

• Matrica mora biti m x n – tog reda, što znači da predstavlja sustav s m procesa i n
entiteta. Broj procesa u pravilu se razlikuje od broja entiteta60.
• Svaki redak matrice sadrži potpun skup entiteta koji pripada jednom procesu.

60
U praksi je broj procesa višestruko veći od broja entiteta.
62
 • Svaki stupac matrice sadrži potpun skup procesa koji vrše operacije nad jednim
entitetom.
• Element matrice definiran je kao:
e i,j = {Ø, C, D, U, R}, u ovisnosti o tome koju operaciju vrši i-ti proces
nad j-tim entitetom.
• U jednom retku smije se nalaziti više elemenata s vrijednošću ∅ , C, D, U i R, jer
jedan proces može, ali i ne mora, utjecati na sve entitete.
Redak ne smije biti prazan, jer ne postoji proces koji niti stvara niti koristi barem
jedan entitet.
Redak koji sadrži samo elemente oznake C znači da proces djeluje nezavisno od
ostalih zbivanja u sustavu, što ukazuje na moguće anomalije u poslovnoj tehnologiji
promatranog sustava.
• U jednom stupcu smije se nalaziti samo jedan element s vrijednošću C, jer se
entitet može stvoriti samo u jednom procesu.
Ako se pri analizi utvrdi postojanje više procesa koji stvaraju isti entitet, takav nalaz
ukazuje na organizacijski kaos u poslovnoj tehnologiji promatranog sustava.
Moguće je da u stupcu nema oznake C, U ili D što ukazuje da je entitet stvoren u
okolini, da se izvan sustava ažurira i briše, a da se u promatranom sustavu samo
koristi. Stupac ne smije biti prazan, jer u sustavu ne postoji entitet koji se ne koristi.
Stupac koji sadrži samo elemente oznake C ili D ukazuje da je neki entitet suvišan.

Tako definirana matrica prikaz je formalno ispravnog modela poslovne tehnologije objektnog
sustava ili modela informacijskog sustava.
Na toj matrici dopuštene su operacije zamjene redaka odnosno stupaca.
Zamjenom dva retka u matrici mijenja se redoslijed zapisa procesa u sustavu čime se
mijenja poslovna tehnologija sustava.
Stoga se za svaki drugačiji redoslijed procesa u sustavu može izraditi najmanje jedna nova
matrica poslovne tehnologije.
Zamjenom dva stupca u matrici mijenja se redoslijed entiteta u sustavu. Time se NE
mijenja poslovna tehnologija.

3.4.2. Dijagonalizacija matrice i oblikovanje podsustava

Budući da je moguće iste poslovne procese obavljati različitim redosljedom, potrebno ih je po

nekom kriteriju grupirati u podsustave, s time da jedan proces pripada jednom i samo
jednom podsustavu.
Jedan od algoritama kojim se u praksi rješava problem grupiranja empirijski je utvrđen i
poznat je pod nazivom algoritam životnog ciklusa osnovnog resursa.

Matricu poslovne tehnologije se prema tome algoritmu treba prikazati u obliku matrice u
kojoj su retci i stupci permutirani na način da su srodni procesi grupirani zajedno
prema metodi redoslijeda faza životnog ciklusa osnovnog resursa, a entiteti prema

63
redoslijedu nastajanja. Postupak formiranja takve matrice zove se dijagonalizacija
matrice, jer se njime teži dijagonalu matrice popuniti oznakama C. Važno je naglasiti da
ovaj pojam “dijagonalizacija” nije istovjetan matematičkom pojmu dijagonalizacije.
Dijagonalizacija matrice poslovne tehnologije ključan je korak u razvijanju osnovne
arhitekture informacijskog sustava.

Postupak dijagonalizacije matrice jest određivanje takvog redoslijeda stupaca i redaka matrice
poslovne tehnologije da sve međusobne veze prikazanih objekata označene s C budu
predočene što bliže dijagonali matrice. Formalni postupci opisani u literaturi mogu se svesti
na nekoliko osnovnih pravila61:
• procese treba poredati u redoslijedu faza životnog ciklusa osnovnog resursa;
• klase podataka treba permutirati tako da prvo dođe klasa podataka koju stvara prvi
proces, zatim klasa koju stvara drugi proces itd.;
• odnos klasa podataka i procesa mora ostati nepromijenjen;
• podsustavi se određuju tako da zadovolje postavljene kriterije optimalnosti.

Temeljem iskustva projektanta i poznavanja poslovne tehnologije, poštujući navedena pravila,

oblikuju se submatrice koje su reprezentanti informacijskih podsustava. S obzirom na to da
postoje različite metodike podjele informacijskog sustava koje su više ili manje heurističke,
više ili manje optimalne, u literaturi se postavlja metrika koja mjeri stupanj kvalitete rješenja,
jer je jedan informacijski sustav odnosno skup procesa moguće podijeliti na različite načine u
dva ili više podsustava.

U dijagonaliziranoj matrici informacijski podsustavi su prikazani submatricama u kojima

su oznake C na dijagonali ili što bliže njoj. Procesi koji su grupirani unutar jedne submatrice
čine informacijski podsustav (grupu, cluster, roj). Svaki element presječnog polja matrice
koji je različit od C čini vezu između procesa u čijem je retku s procesom koji u danom stupcu
ima C, odnosno koji stvara određeni entitet. Sva slova koja opisuju prirodu veze (odnosno
aktivnosti procesa nad entitetom), a nalaze se izvan submatrica, čine vanjske veze između
podsustava (i čine vanjsku povezanost između podsustava), a one koje su unutar submatrica
čine unutarnje veze podsustava (i čine koheziju ili unutarnju povezanost informacijskog
sustava). Povoljnija je ona struktura informacijskog sustava kod kojeg su vanjske veze
između podsustava što slabije, a unutar podsustava što jače. Drugim riječima, potrebno je
formirati takvu strukturu informacijskog sustava kod koje će što veći broj oznaka aktivnosti
procesa nad entitetima biti unutar submatrica, a što manji izvan njih.

PRIMJER:
Prethodni primjer potrebno je dopuniti zahtjevom da je redoslijed procesa određen
poslovnom tehnologijom u promatranom sustavu:
p1, p4, p5, p7, p8, p10, p11, p12, p3, p9, p2, p6.

61
Martin, J: Information Engineering: Introduction, Prentice Hall, Englewood Cliffs, NY 1990.
64
Početna matrica poslovne tehnologije prikazana je na tablici 8. za primjer zadan ulaznim
podacima iz tablice 7. Dijagonalizirana matrica poslovne tehnologije tada može biti prikazana
različitim tablicama (tablice 9. i 10.).

E3 E5 E7 E1 E2 E9 E4 E6 E8

p1 C U R R R

p4 R C R R U R

p5 R R C R R

p7 R R R R U

p8 U R U R R

p10 R R C U R

p11 R U R R

p12 R R U R U

p3 C

p9 R C R

p2 R R C R

p6 R U R R C C

Tablica 9.: Dijagonalizirana matrica poslovne tehnologije (varijanta 1.)

Redoslijed procesa kojima su popunjeni retci dijagonaliziranih matrica nije jednak u odnosu
na početnu matricu. Dok u početnoj matrici poslovne tehnologije poredak procesa ne ovisi o
slijedu njihova odvijanja, u dijagonaliziranim matricama je određen metodom životnog
ciklusa osnovnog resursa.

Dakle, tijekom postupka dijagonalizacije prvo se permutiraju procesi odnosno retci početne
matrice poslovne tehnologije, a zatim, ovisno o poretku procesa, klase podataka koje ti
procesi stvaraju odnosno stupci početne matrice.

Razlika između tablice 9. i tablice 10. očituje se u broju submatrica koje se formiraju
dijagonalizacijom početne matrice poslovne tehnologije. Pri tomu je oznaka za operaciju
stvaranja/brisanja entiteta C/D zamijenjena oznakom C.

65
 E3 E5 E7 E1 E2 E9 E4 E6 E8

p1 C U R R R

p4 R C R R U R

p5 R R C R R

p7 R R R R U

p8 U R U R R

p10 R R C U R

p11 R U R R

p12 R R U R U

p3 C

p9 R C R

p2 R R C R

p6 R U R R C C

Tablica 10.: Dijagonalizirana matrica poslovne tehnologije (varijanta 2.)

U tablici 9. prikazan je informacijski sustav koji se sastoji od tri podsustava:

S 1 = { p 1 , p 4 , p 5 , p7 , p 8 , p 10 , p 11 , p 12 } , S 2 = { p 2 , p6 } i S 3 = { p3 , p9 } ,
pa je
S = S1 ∪ S 2 ∪ S3 .

U tablici 10. prikazan je isti poslovni sustav (prikazan istom matricom poslovne tehnologije),
ali drugačiji informacijski sustav, jer je sastavljen od dva podsustava:
S 1 = { p1 , p 3 , p 4 , p 5 , p7 , p 8 , p 9 , p10 , p11 , p12 } i S 2 = { p 2 , p6 }
pa je
S = S1 ∪ S 2 .

U obje varijante korišten je prethodno opisan postupak dijagonalizacije.

Lako je uočiti da broj oznaka koje se nalaze izvan submatrica i kojima su opisane aktivnosti
procesa nad entitetima nije jednak u oba slučaja. S obzirom na to da treba postići što manju
povezanost između podsustava broj oznaka izvan submatrica treba biti što manji.

66
Za ovaj jednostavan primjer (mali broj procesa i entiteta) provjera koje je rješenje bliže
optimalnom odnosno koje je rješenje kvalitetnije može se izvršiti prebrojavanjem popunjenih
polja matrice.

Stoga se uvode oznake:

e0 = broj vanjskih veza svih podsustava (broj popunjenih polja izvan submatrica)
eu = broj unutarnjih veza svih podsustava (broj popunjenih polja unutar submatrica)
e = ukupan broj veza podsustava (broj popunjenih polja u matrici sustava)

U matricama poslovne tehnologije prikazanim tablicama 9. i 10. ukupan broj popunjenih polja
je e = 54.

U matrici prikazanoj na tablici 9. broj popunjenih polja izvan sve tri submatrice je e01 = 23, a
unutar njih je eu1 = 31. U matrici prikazanoj na tablici 10. broj popujenih polja izvan
submatrica je e02 = 18, a unutar submatrica eu2 = 36.

Ako je kohezija unutar i-tog podsustava (KHS)i jednaka omjeru broja popunjenih polja unutar
submatrica i ukupnog broja popunjenih polja matrice:
e
(KHS)i = u i
e
31
može se utvrditi da je kohezija unutar svih podsustava u prvoj varijanti (KHS)1 = ,au
54
36
drugoj (KHS)2 = . Iz navedenog proizlazi da je (KHS)1<(KHS)2.
54

Očigledno je da su u varijanti 2. dva podsustava spojena u jedan čime se smanjio broj

vanjskih veza između podsustava, odnosno povećala se kohezija unutar podsustava.

Ako je s F označena kvaliteta strukture informacijskog sustava mora vrijediti:

F ∝ ∑ KHS
i
i

Drugim riječima, kvaliteta dijeljenja informacijskog sustava proporcionalna je koheziji unutar

svih podsustava, a obrnuto je proporcionalna njihovoj vanjskoj povezanosti. Kvalitetnijim
rješenjem u ovom primjeru smatrati će se ono gdje je broj popunjenih polja unutar submatrica
veći, a izvan njih manji.

3.4.3. Unutrašnja konzistentnost i vanjska povezanost podsustava

Iz razmatranja postupka dijagonalizacije matrice poslovne tehnologije proizašlo je da treba
izabrati načine kako uspostaviti povezanost informacijskih podsustava koja bi jamčila
kvalitetnu strukturu informacijskog sustava. Svaki od informacijskih podsustava treba tvoriti
relativno nezavisnu i funkcijski zaokruženu cjelinu, čime se ostvaruje modularnost kao jedna
od osnovnih značajki dobre arhitekture sustava. Stoga treba utvrditi kakvu vanjsku
povezanost između podsustava i unutarnju unutra svakog od njih treba postići u svrhu
zadovoljavanja te osobine.
67
Povezanost između informacijskih podsustava (vanjska povezanost podsustava) može se
uspostaviti na temelju podataka, upravljanja i sadržaja.

Ako jedinu vezu među procesima iz različitih informacijskih podsustava čine podaci, to znači
da procesi koriste ista spremišta ili baze podataka, ili pak da se podaci stvoreni u jednom
procesu koriste u drugome. Povezanost podacima najslabija je povezanost procesa, te je
utoliko i najpoželjnija. To je ujedno nužan oblik povezanosti među procesima u raznim
podsustavima koji zaista tvore cjelinu informacijskog sustava.

Ako jedan proces (iz jednog informacijskog podsustava) šalje drugome (iz drugog
informacijskog podsustava) upravljačke ili kontrolne podatke (često zvane upravljački
indikatori), to znači da prvi proces kontrolira drugi, odnosno da drugi proces funkcijski ovisi
o prvome. Povezanost upravljanjem znači jači oblik povezanosti među procesima u
podsustavu, ali i među procesima iz različitih podsustava, te je dopuštena u slučaju
upravljanja informacijskim sustavom. Može se izbjeći, iako to nije uvijek poželjno,
rastavljanjem funkcijski ovisnih procesa odnosno podsustava na dva procesa odnosno
podsustava na nižoj razini od kojih svaki obavlja svoje aktivnosti.

Ako jedan proces (iz jednog informacijskog podsustava) podatke ili kontrolne indikatore ne
šalje drugom procesu (iz drugog informacijskog podsustava), već ih ugrađuje kao “skretnice”
u neki drugi proces (koji tog trenutka nije aktivan), utjecaj prvog procesa na drugi pojavit će
se naknadno, tek pri aktiviranju drugog procesa. Takva ovisnost drugog procesa (kao i
podsustava) o prvome može biti uzrok problemima u korištenju i održavanju, pa je oblik
vanjske povezanosti podsustava sadržajem zabranjen.

Unutarnja povezanost informacijskog podsustava (kohezija unutar informacijskog

podsustava) može biti funkcijska, slijedna, komunikacijska, proceduralna, vremenska,
logička i slučajna.

Najpoželjniji oblik kohezije je ako aktivnosti koje procesi unutar jednog informacijskog
podsustava obavljaju čine logičnu i zaokruženu funkcijsku cjelinu koja se može jednostavno
definirati. Visok stupanj kohezije procesa unutar informacijskog podsustava ujedno znači
nizak stupanj njegove povezanosti s drugim procesima u ostalim podsustavima.

Ako procesi svoje aktivnosti obavljaju slijedno, pri čemu izlaz iz jedne aktivnosti čini ulaz u
drugu, onda je sačuvano uređenje u informacijskom podsustavu odnosno poštuje se redoslijed
životnog ciklusa osnovnog resursa. Slijedna kohezija relativno je povoljan oblik kohezije
posebno na višim razinama prikaza informacijskog sustava.

Ako aktivnosti koje proces iz jednog informacijskog podsustava obavlja koriste iste ulazne
tokove ili spremišta podataka, ili ako stvaraju iste tokove podataka kao i proces iz drugog
informacijskog podsustava (komunikacijska povezanost), kohezija informacijskog
podsustava je prihvatljiva. Drugačijim strukturiranjem informacijskog podsustava koji

68
karakterizira komunikacijska kohezija može se povećati stupanj njegove kohezije i smanjiti
stupanj njegove povezanosti s drugim informacijskim podsustavima.

Ako se aktivnosti koje obavlja proces u informacijskom podsustavu izvode slijedno, ali
obavljaju sasvim različite vrste operacija tako da ne čine logičnu i zaokruženu cjelinu, radi se
o proceduralnoj povezanosti i kohezija procesa unutar informacijskog podsustava je slaba. U
tom slučaju potrebno je preoblikovati proces unutar podsustava kako bi se povećala kohezija
procesa u informacijskom podsustavu ili treba promijeniti strukturu informacijskog sustava.

Ako su aktivnosti koje proces obavlja povezane isključivo izvršavanjem u određenom

vremenskom trenutku, treba preoblikovati proces i pridružiti ga onim procesima u
informacijskom podsustavu kojima funkcijski pripada.

Ako se u informacijskom podsustavu obavlja niz aktivnosti istog tipa, među kojima ne postoji
ni jedan od navedenih oblika kohezije, kohezija je izuzetno slaba (logička povezanost). Takav
bi, primjerice, bio informacijski podsustav koji stvara sve ispise iz sustava.

Ako nema uočljiva razloga zbog kojeg su aktivnosti koje se obavljaju u informacijskom
podsustavu oblikovane u jednu cjelinu, radi se o slučajnoj povezanosti i kohezija unutar
podsustava praktički ne postoji.

Dakle, informacijski sustav treba dekomponirati odnosno podijeliti tako da međusobna

povezanost podsustava bude što slabija, a kohezija (tj. unutarnja povezanost) svakog od
podsustava što jača. Iz prethodnog proizlazi da mora vrijediti:

Povezanost između informacijskih sustava može biti:

• podacima,
• upravljanjem.

Unutarnja povezanost informacijskog sustava može biti:

• funkcijska,
• slijedna,
• komunikacijska.

Ostale vrste povezanosti su neprihvatljive.

Nizak stupanj povezanosti informacijskih podsustava i visok stupanj njihove kohezije pruža
niz pogodnosti i u procesu razvoja i uspostave novog informacijskog sustava. Naime,
nezavisni i kohezivni informacijski podsustavi mogu se razvijati (koristiti) samostalno62, što
omogućuje postupno razvijanje, uvođenje i korištenje novog informacijskog sustava.
Visok stupanj nezavisnosti i kohezivnosti podsustava olakšava i kasnije održavanje (i
mijenjanje) informacijskog sustava. Ako struktura informacijskog sustava udovoljava tim

62
Svaki podsustav jedan je modul složenog sustava.
69
zahtjevima, izmjena svakog pojedinog podsustava relativno je nezavisna od ostalih
podsustava. Time se pojednostavnjuje definiranje, provođenje i dokumentiranje izmjene.

3.5. Određivanje osnovne arhitekture informacijskog sustava

Analiza sklonosti između procesa

Mjera kvalitete strukture informacijskog sustava

Optimalno strukturiran informacijski sustav treba biti strukturiran u niz zaokruženih i

međusobno relativno nezavisnih podsustava, za koje je povezanost između podsustava
uspostavljena temeljem podataka, a kohezija unutar podsustava funkcijska, slijedna ili
barem komunikacijska. Tada procesi koji su sadržani u svakom podsustavu tvore zaokružen
i cjelovit segment informacijskog sustava. Takva optimalna struktura informacijskog sustava
mora omogućiti bolju funkcionalnost i efikasnost poslovnog sustava, bolju kontrolu i
upravljanje, ali i podržati informatizaciju korak po korak, modul po modul.

Određivanje optimalne strukture informacijskog sustava moguće je provesti na dva načina:

• najprije odrediti ukupan broj podsustava koji vodi ka optimalnoj strukturi, a zatim koji
procesi pripadaju svakom od njih;
• početi grupiranje procesa po nekom kriteriju (proizvoljnom) čime se definiraju grupe
procesa odnosno podsustavi.

Izbor metode obično ovisi o iskustvu projektanta. Ako se radi o iskusnom analitičaru sustava
s iskustvom u projektiranju informacijskih sustava uglavnom će se koristiti prvi način. Ako
se, pak radi o manje iskusnom projektantu, posebno ako su mu dostupna programska
pomagala za projektiranje sustava vjerojatno će biti primijenjen drugi način. Ponekad se u
praksi javljaju problemi zbog nedovoljnog poznavanja poslovnih procesa u sustavu koje
CASE pomagala raspoređuju prema svom nahođenju (naravno, u skladu s programiranim
algoritmima63). Temeljna pretpostavka formiranja arhitekture informacijskog sustava je da se
svi procesi rasporede u pripadne informacijske podsustave. Ovdje se navode dvije metode
koje se koriste za određivanje optimalne strukture složenog informacijskog sustava tj.
raspoređivanja procesa u podsustave, a to su analiza sklonosti (analiza sklonosti entiteta i/ili
analiza sklonosti procesa) i određivanje mjere kvalitete strukture informacijskog sustava
putem informacijske funkcije.

63
Martinovom metodom (analiza sklonosti entiteta) procesi koji nisu međusobno dovoljno slični raspoređuju se
u zajedničku, mješovitu grupu koja čini zaseban podsustav. U poslovanju takav pristup nije prihvatljiv, jer nije
opravdano formirati informacijski podsustav od "hrpe" raznorodnih procesa, koji su pri tomu neuređeni, odnosno
nisu poredani funkcijski ili slijedno. Kod formiranja baze podataka takva podjela ne predstavlja ni logički niti
operativan problem.

70
3.5.1. Analiza sklonosti između procesa

Analiza sklonosti između entiteta, poznatija pod nazivom analiza afiniteta64, jedna je od
metoda informacijskog inženjeringa koju je uveo J. Martin.
S obzirom na to da je metoda primarno prilagođena potrebi izrade modela podataka, nije u
cijelosti prihvatljiva u modelu analize sklonosti procesa, iako je u nedostatku neke druge
metode, primjenjivana i u tu svrhu65.

Analiza sklonosti među entitetima promatra entitete, te računa sklonost odnosno sličnost
između njih koja ovisi o broju procesa koji ih koriste. Rezultat provedene analize sklonosti
među entitetima je model podataka informacijskog sustava, a često i gotova struktura baze
podataka.

Analiza sklonosti među procesima promatra procese, te računa sklonost odnosno sličnost
između njih koja ovisi o broju entiteta koje procesi koriste. Rezultat je model procesa
informacijskog sustava i struktura informacijskog sustava.

Dakle, analizom sklonosti među entitetima formiraju se rojevi (nakupine, množine, cluster-i)
koji se u procesu fizičke implementacije interpretiraju kao predmetne baze podataka, a
analizom sklonosti među procesima formiraju se poslovni, a posljedično tome i informacijski
podsustavi. Stoga se dalje razmatra samo analiza sklonosti procesa.

Analiza sklonosti procesa temelji se na činjenici da su neki procesi međusobno više povezani
od drugih, dok se pripadnost entiteta istom procesu ne mijenja.

PRIMJER:

Promatrani procesi p i i p j koriste određeni broj entiteta,

E1
E1 E1
E8
E4
E2 pi E3 pj
E7 E5
E8 E7
E6
Matrica procesi/entiteti koja opisuje ova zbivanja je:

E1 E2 E3 E4 E5 E6 E7 E8
pi + + + + +
pj + + + + + +

Slika 25. Primjer za izračun koeficijenta sklonosti procesa

64
Martin, J: Information Engineering: Introduction, Prentice Hall, Englewood Cliffs, NY 1990.
65
Posebno zato što je podržana CASE pomagalima.
71
 Tada je n ( p i ) = 5 broj entiteta koji koristi proces p i i n ( p j ) = 6 broj entiteta koji
koristi proces p j.

Broj entiteta koje koriste oba procesa je n ( p i , p j ) = n ( p j , p i ) = 3.

Koeficijent sklonosti procesa A ( pi, pj ) poznat iz literature (često prevođen kao faktor
afiniteta) određen je tim podacima:

Neka je n ( p i ) broj ulaznih i izlaznih entiteta procesa p i , i neka je n ( p i , p j ) broj

zajedničkih entiteta koje imaju procesi p i i p j . Tada je koeficijent sklonosti između procesa
pi i pj:
n( p i , p j )
A( p i , p j ) =
n( p i )
Stoga se može i za primjer izračunati koeficijente sklonosti:

n ( pi , p j ) 3 20 60
A ( pi , p j ) = = ⋅ = = 60%
n ( pi ) 5 20 100

n ( p j , pi ) 3 1 50 50
A ( p j , pi ) = = = ⋅ = = 50%
n( pj ) 6 2 50 100

Za koeficijent sklonosti između procesa p i i p j vrijedi da je uvijek veći od 0 i manji od 1

(odnosno 100%). To znači da ako dva procesa ne koriste iste entitete njihova sličnost je 0
(nisu slični), a ako su svi entiteti koje koriste isti onda je sličnost 1 (uvijek se radi o sličnosti
procesa sa samim sobom).

n ( pi , p j )
0 ≤ A( pi , p j ) = ≤1
n ( pi )

Ovaj izraz je mjera sličnosti66 samo ako je broj ulaznih i izlaznih entiteta procesa p i
jednak broju ulaznih i izlaznih entiteta procesa p j . S obzirom na to da su u pravilu takvi
slučajevi izuzeci, koeficijent sklonosti općenito nije mjera sličnosti osim u navedenom
specijalnom slučaju.
Matrica sklonosti procesa kod računanja koeficijenata sličnosti je asimetrična (slika 26.). To
znači da iznos koeficijenta sklonosti ovisi o redoslijedu kojim je ispitivana sličnost između
dva procesa. Rezultat takve analize nije prihvatljiv u poslovnom smislu: ne smije sličnost
jednog procesa prema drugom biti veća ili manja od sličnosti drugog procesa prema prvom.

66
Prema Topolovec, V.:Klaster analiza: algoritmi i aplikacije na procese rasta, doktorska disertacija, Zagreb,
1980: Funkcija s : X x X → R je mjera sličnosti u X ako vrijedi:
• 0 ≤ s( xi , x j ) ≤ 1 ,
• s( xi , xi ) = 1 ,
• s ( x i , x j ) = s ( x j , x i ) , ∀x i , x j ∈ X
72
 Proces
p1 ... pi ... pj ...
Proces

p1

... 100 60
pi
...

pj 50 100
...

Slika 26. Primjer asimetrične matrice sklonosti procesa

Stoga je koeficijent sklonosti poslužio kao polazište za definiciju modificiranog koeficijenta

sklonosti procesa67.

Kako je modificirani koeficijent sklonosti mjera sličnosti, njime se inducira parcijalno

uređenje u promatranom skupu procesa odnosno procesi su u informacijskim podsustavima
poredani slijedno.

Neka je n ( p i ) broj ulaznih i izlaznih entiteta procesa p i , i neka je n ( p i , p j ) broj

zajedničkih entiteta koje imaju procesi pi i p j .

Modificirani koeficijent sklonosti definira se kao:

A( pi , p j ) + A( p j , pi )
A′ ( p i , p j ) = ,
2

pa ako uvrstimo gore navedeno definiciju koeficijenata sklonosti između procesa p i i p j,

odnosno procesa p j i p i dobivamo:

n ( pi , p j ) n ( p j , pi )
+
n ( pi ) n( pj )
A′ ( p i , p j ) = ,
2

iz čega slijedi:

67
Klasić, K: Novi pristup određivanju temeljne arhitekture informacijskog sustava, Zbornik radova CASE 10,
Opatija, 1998.

73
 n ( pi , p j ) ⋅ ( n ( p j ) + n ( p i ) )
A′ ( p i , p j ) = .
2 ⋅ n ( pi ) ⋅ n ( p j )

Tada je modificirani koeficijent sklonosti A' između procesa p i i p j:

n ( pi ) + n ( p j )
A′ ( pi , p j ) = n ( pi , p j ).
2 ⋅ n ( pi ) ⋅ n ( p j )

Ako se sada za prethodni primjer izračunaju modificirane koeficijente sklonosti između

procesa p i i p j rezultat je:

5+6 11 5 55
A′ ( pi , p j ) = 3/ 1 = ⋅ = = 55% ,
2 ⋅ 5 ⋅ 6/ 2 20 5 100

tj. rezultat izračunavanja je simetrična matrica sklonosti procesa (slika 27.)

Proces
p1 ... pi ... pj ...
Proces

p1
...

pi 100 55
...

pj 55 100
...

Slika 27. Primjer simetrične matrice sklonosti procesa

Može se izračunati i modificirani koeficijent sklonosti procesa p k prema roju odnosno

informacijskom podsustavu Rij kao:

A′ ( p k , pi ) ⋅ n ( pi ) + A′ ( p k , p j ) ⋅ n ( p j )
A′ ( p k , Ri , j ) =
n ( pi ) + n ( p j )

74
Iz navedenog se može zaključiti da:
• ako dva procesa imaju visoku sklonost trebali bi se nalaziti u istom podsustavu, i
• ako je sklonost između dva procesa 0, oni sigurno ne trebaju biti smješteni zajedno.

Pravila i ograničenja kojih se pri postupku strukturiranja sustava odnosno raspoređivanju

procesa u podsustave treba pridržavati su sljedeća:
• Procesi se međusobno razlikuju. To znači da ne mogu postojati dva potpuno jednaka
procesa u poslovnom sustavu. Može se dogoditi da se jedan proces treba odvijati na više
mjesta i da ga trebaju provoditi različite osobe, no takve slučajeve treba pojedinačno
razmotriti.
• Grupiranje procesa mora biti neovisno o redoslijedu pretraživanja procesa, što
znači da procesi u početnoj matrici poslovne tehnologije ne moraju biti poredani po
životnom ciklusu osnovnog resursa odnosno redosljedu odvijanja posla.
• Trivijalni slučajevi isključuju se iz analize:
• s=1
Ako broj podsustava iznosi jedan znači da je informacijski sustav ujedno i
podsustav samom sebi. Iako je kohezija u tom slučaju maksimalna jer su sve veze
između sustava i podsustava isključivo unutarnje, takva podjela nije prihvatljiva iz
organizacijskih razloga (posebno kada se radi o malo većim poslovnim sustavima).
• s=2
Ako broj podsustava iznosi dva, znači da postoje samo dva podsustava, što nema
praktičnog smisla (nije ni organizacijski opravdano). Ovaj je slučaj najjednostavniji
slučaj strukturiranja, ali nije primjenjiv u praksi ni zanimljiv za proučavanje.
• Podsustav ne smije sadržavati samo jedan proces, jer to znači da je podsustav
trivijalan i da ga nema smisla razmatrati (organizacijski nije opravdan).
Načelno je moguće definirati onoliko podsustava koliko ima procesa, no takav je pristup
organizacijski i informatički neprihvatljiv. Svaki podsustav mora sadržavati barem dva
procesa kako bi postupci strukturiranja bili svrhoviti.
• p j ∈ S i _ p j ∉ S k , za i , k = 1...s , j = 1....m i i ≠ k odnosno S i ∩ S k = ∅
Isti proces ne smije biti istodobno raspoređen u dva podsustava. Svi procesi iz sustava
moraju se rasporediti u podsustave s kojima imaju najveću sličnost
m
• Broj mogućih podsustava s informacijskog sustava S je 1 < s < (jer jedan podsustav
2
ne smije sadržavati samo jedan proces). Za sustav S = ∪ S i , gdje je S i i - ti podsustav
i
sustava S, prihvaćeno je organizacijsko pravilo " 7 ± 4 ", pa vrijedi ograničenje
i ∈ [3,11] .

Primjenom analize sklonosti procesa procesi se grupiraju prema svojoj sličnosti pa se time i
određuje njihov redoslijed u poslovnom sustavu. Analitičar sustava ili projektant može
dovoljno dobro poznavati poslovni sustav tako da može na temelju iskustva odrediti poslovnu
tehnologiju. Za njega je analiza sklonosti procesa sredstvo kojim potvrđuje svoja razmišljanja.
Međutim, za manje iskusnog projektanta analiza sklonosti procesa je korisna jer daje dobru
osnovicu za dalje razmatranje poslovne tehnologije, pa se naknadno, nakon dodatnih
razgovora s korisnicima, mogu provesti eventualne potrebne promjene.

75
3.5.2. Mjera kvalitete strukture informacijskog sustava

Određivanje mjere kvalitete strukture informacijskog sustava putem informacijske funkcije

jedna je od metoda koja se koristi pri određivanju optimalne strukture informacijskog sustava,
a u praksi se kombinira s analizom sklonosti procesa. Pri tome se u analizi sklonosti procesa
kvantificiraju veze između procesa i entiteta u početnoj matrici poslovne tehnologije. To znači
da se svakoj aktivnosti koju vrši proces nad entitetom dodjeljuje neka vrijednost.

Ako je s e i j označen element matrice, tada informacijska funkcija elementa matrice

poslovne tehnologije opisuje veze između procesa i entiteta i iznosi68:

⎧ 0 ∀ ei, j = ∅
⎪
F i, j = ⎨
⎪⎩ f i, j ∀ ei, j ≠ ∅

gdje je fi,j iznos informacijske funkcije elementa matrice koji ovisi o značaju informacijske
veze, jakosti informacijske veze i frekvenciji pojavljivanja aktivnosti procesa nad entitetom:

f i , j = z i , j ⋅ ω i , j ⋅ν i , j

Značaj informacijske veze z i , j ovisi o vrsti odnosa između procesa i entiteta (neophodna,
važna, dopunska informacija).

Jakost informacijske veze ω i , j opisuje aktivnosti koju obavlja proces nad entitetom (C, R,
U, D).

Frekvencija odnosno učestalost ν i , j opisuje učestalost pojavljivanja aktivnosti procesa nad

entitetom (mnogo puta dnevno, dnevno, tjedno, mjesečno, godišnje).

Parametri koji određuju iznos informacijske funkcije elementa matrice poprimaju diskretne
vrijednosti iz intervala [0,1]. To znači da će se u presječnim poljima matrice poslovne
tehnologije nalaziti neki iznos, umnožak vrijednosti parametara z i , j , ω i , j i ν i , j , a ako ne
postoji veza između procesa i entiteta iznos je 0.
Za određivanje vrijednosti parametra mogu se koristiti odgovarajuće matematičke metode.
Na temelju iskustva izabrane su vrijednosti parametara:

⎧ 0,4 znaci da pi treba E j kao dopunsku informaciju

⎪⎪
z i , j = ⎨ 0,7 znaci da pi treba E j kao vaznu informaciju
⎪
⎪⎩ 1 znaci da pi treba E j kao neophodnu informaciju

68
Osnovne pojmovi metode uvedeni su u Brumec, J: Optimizacija strukture informacijskog sustava, Zbornik
radova, FOI Varaždin, 1993.
76
 ⎧ 0 ∀ ei , j = ∅
⎪
⎪⎪ 0,4 ∀ ei , j = R
ωi , j ⎨
=
⎪ 0,7 ∀ ei , j = U
⎪
⎪⎩ 1 ∀ ei , j = C, D

⎧ 0,2 za izuzetno rijetke aktivnosti (godišnje)

⎪
⎪ 0,4 za rijetke aktivnosti (mjesecne)
⎪⎪
ν i , j = ⎨ 0,6 za relativno ceste aktivnosti (tjedne)
⎪
⎪ 0,8 za ceste aktivnosti (dnevne)
⎪
⎪⎩ 1 za izuzetno ceste aktivnosti (mnogo puta dnevno)

S obzirom na to da je uvedena kvantifikacija veza između procesa i entiteta potrebno je

redefinirati pojam dijagonalizacije poznat iz metode životnog ciklusa osnovnog resursa.
Budući da se u presječnim poljima matrice poslovne tehnologije nalaze konkretne vrijednosti,
nije moguće postupkom dijagonalizacije smještati C-ove što bliže dijagonali, nego se sada na
dijagonali približavaju najveće, maksimalne vrijednosti izračunate množenjem parametara.
Postupak dijagonalizacije matrice postaje određivanje takvog redoslijeda stupaca i redaka
matrice poslovne tehnologije kojim sve maksimalne vrijednosti iznosa informacijske funkcije
elemenata matrice teže da budu predočene što bliže dijagonali matrice.

Dijagonalizacijom se kreiraju različite matrice poslovne tehnologije, s različitim brojem

podsustava, koje određuju različite strukture informacijskog sustava. Pri tome vrijedi da se
struktura informacijskog sustava može oblikovati na različite načine, ali se kvaliteta pojedinih
rješenja međusobno razlikuje. Stoga se uvodi pojam mjere kvalitete informacijskog sustava.

Mjera kvalitete strukture informacijskog sustava F je razlika između informacijske

funkcije sustava i zbroja informacijskih funkcija svih njegovih podsustava
s
F = F S - ∑ F Si
i=1

m n ls+rs
gdje je F S = ∑ ∑ Fi , j informacijska funkcija sustava, a F Si = ∑ ∑F i,j
i=1 j= l i∈Si j= l

informacijska funkcija i-tog podsustava.

Informacijska funkcija i-tog podsustava je zbroj informacijskih funkcija elemenata

submatrice kojom je prikazan podsustav S i :
ls + rs
F Si = ∑ ∑F i,j
i∈Si j = l

77
gdje je Si podskup svih procesa koji prema trenutnoj strukturi pripadaju podsustavu Si.
Varijabla ls označava redni broj stupca lijeve granice i -te submatrice, odnosno pokazuje na
prvi entitet koji pripada podsustavu, dok varijabla rs označava broj entiteta koji pripadaju i -
toj submatrici. Granice submatrice određene su prethodno postupkom dijagonalizacije.

Dakle, obje varijable odnose se na stupce matrice odnosno na entitete (slika 28.).

E1 E2 E3 E4 E5 E6 ..... En

p1

p2 S1

p3

p4 S2

p5

P6 Sn
...

pm

ls
I.. …...............I
rs

Slika 28. Granice informacijskog podsustava

Iz slike 28. može se zaključiti da je informacijska funkcija i-tog podsustava zapravo zbroj
vrijednosti informacijskih funkcija elemenata matrice (odnosno iznosa informacijskih
funkcija u presječnim poljima matrice poslovne tehnologije). Stoga za navedeni primjer
vrijedi:

3 3 5 5 n m
FS1 = ∑∑ Fi , j , FS 2 = ∑∑ Fi , j , FS 3 = ∑∑ Fi , j .
i =1 j =1 i =4 j =4 i =6 j =6

n m 3
Tada je mjera kvalitete strukture informacijskog sustava F = ∑∑ Fi , j − ∑ FS i .
i =1 j =1 i =1

Iz definicije proizlazi da je informacijska funkcija velika kada je unutar submatrice popunjen

velik broj presječnih polja i obrnuto, kada je popunjenost presječnih polja mala, informacijska
funkcija podsustava je mala.

78
Tada vrijedi TEOREM:
s

Neka je F = F S - ∑ F S i . Tada ako informacijska funkcija unutar svakog od

i=1
podsustava teži maksimumu ( F S i → max ) onda mjera kvalitete strukture
informacijskog sustava F mora težiti minimumu ( F → min ).

Dokaz neće biti ovdje proveden.

Mjera kvalitete strukture informacijskog sustava ima smisla računati i uspoređivati samo za
isti broj podsustava i u povoljnijem slučaju je ta vrijednost manja. Optimalna struktura uvijek
se može postići za minimalan dopušten broj podsustava zato što se spajanjem dva podsustava
povećava kohezija sustava, jer se smanjuje broj vanjskih, a povećava broj unutarnjih veza.

Načelni postupak određivanje optimalne strukture informacijskog sustava primijenjen u ovoj

metodi je sljedeći:
• popuniti početnu matricu poslovne tehnologije podacima o procesima, entitetima i
njihovim vezama;
• izračunati informacijsku funkciju F i, j za svaki element matrice;
• za prvi redak matrice preseliti nalijevo onaj stupac za koji informacijska funkcija elementa
matrice ima najveću vrijednost, za drugi redak matrice ponoviti postupak i preseliti stupac
nalijevo, na prvo sljedeće mjesto itd.;
• izračunati informacijsku funkciju sustava FS;
• izračunati informacijsku funkciju svakog tako formiranog podsustava FS i ;
• izračunati mjeru kvalitete strukture sustava F.

PRIMJER:

Može se pretpostaviti da, osim različite jakosti informacijske veze, postoje i podaci o
iznosu značaja informacijske veze te učestalosti aktivnosti procesa nad entitetom. U
tom slučaju koristi se početna matrica poslovne tehnologije proširena s dodatnim
podacima, koja je prikazana na slici 29. Pri tome se koriste oznake za značaj
informacijske veze:
n = nužna (neophodna) informacija,
v = važna informacija,
d = dopunska informacija,
i učestalost:
g = jednom (ili samo nekoliko puta) u godini odnosno godišnja aktivnost,
m = mjesečna aktivnost,
t = tjedna aktivnost,
d = dnevna aktivnost,
č = česta, odnosno aktivnost koja se ponavlja više puta dnevno.

U skladu s načelnim postupkom za određivanje optimalne strukture informacijskog sustava

potrebno je izračunati iznose informacijskih funkcija elemenata matrice (slika 30.).
79
 E1 E2 E3 E4 E5 E6 E7 E8 E9

p1 R,v,d C,n,d U,n,d R,d,č R,v,d

p2 R,v,d R,d,č C,n,t R,d,t

p3 C,n,g

p4 R,n,č R,d,d R,d,d C,n,t U,n,č R,d,č

p5 R,v,d R,v,č R,d,d C,n,d R,v,t

p6 U,n,č R,n,d R,v,d C,n,d C,n,m R,v,t

p7 R,d,č R,d,č R,d,t R,v,č U,n,d

p8 R,d,č U,n,č R,v,č U,n,č R,d,t

p9 R,d,d R,v,č C,n,d

p10 C,n,d R,n,č R,n,t U,n,č R,v,d

p11 U,n,d R,v,č R,d,č R,d,d

p12 U,n,t R,d,č R,v,m R,n,m U,n,t

Slika 29. Proširena matrica poslovne tehnologije

E1 E2 E3 E4 E5 E6 E7 E8 E9

p1 0,224 0,8 0,56 0,16 0,224

p2 0,224 0,16 0,6 0,096

p3 0,2

p4 0,4 0,128 0,128 0,6 0,7 0,16

p5 0,224 0,28 0,128 0,8 0,168

p6 0,7 0,32 0,224 0,8 0,4 0,168

p7 0,16 0,16 0,096 0,28 0,56

p8 0,16 0,7 0,28 0,7 0,096

p9 0,128 0,28 0,8

p10 0,8 0,4 0,24 0,7 0,224

p11 0,56 0,28 0,16 0,128

p12 0,42 0,16 0,112 0,16 0,42

Slika 30. Informacijske funkcije elemenata proširene matrice poslovne tehnologije

80
Primjenom algoritma za izračun optimalne strukture sustava koji podržava izloženu metodu,
na slici 31. prikazano je rješenje strukture informacijskog sustava koje se smatra optimalnim
(za određeni redoslijed poslovnih procesa).

E4 E6 E3 E5 E7 E8 E1 E2 E9

p2 0,6 0,16 0,096 0,224

p6 0,224 0,8 0,32 0,4 0,7 0,168

p1 0,8 0,56 0,16 0,224 0,224

p4 0,128 0,7 0,128 0,6 0,16 0,4

p5 0,28 0,128 0,8 0,168 0,224

p7 0,16 0,096 0,28 0,56 0,16

p8 0,7 0,28 0,7 0,16 0,096

p10 0,7 0,4 0,24 0,224 0,8

p11 0,28 0,16 0,56 0,128

p12 0,42 0,112 0,16 0,16 0,42

p3 0,2

p9 0,28 0,128 0,8

Slika 31. Optimalna struktura informacijskog sustava (varijanta 1.)

Informacijska funkcija sustava iznosi FS = 18,74, a informacijske funkcije pojedinih

podsustava: FS1 = 1,624, FS2 = 10,292, FS3 = 1,128.
Za navedeni izbor vrijednosti parametara mjera kvalitete strukture sustava iznosi F = 5,696.
Maksimalni iznosi nalaze se na dijagonali matrice i oko nje (u ovom primjeru ni jedan ne
iznosi 1).
Optimalna struktura sustava je tada:
S = { p 2 , p 6 } ∪ { p 1 , p 4 , p 5 , p 7 , p 8 , p 10 , p 11 , p 12 } ∪ { p 3 , p 9 } .

Ako se s E označi skup entiteta koji pripada skupu procesa S, onda je struktura skupa entiteta
koja pripada optimalnoj strukturi informacijskog sustava:

E = { E 4 , E 6 } ∪ { E 3, E 5 , E 7 , E 8 , E 1 } ∪ { E 2 , E 9 } .

U varijanti 2., na slici 32. prikazani su podsustavi koje čine isti procesi, ali je raspored
pripadajućih entiteta drugačiji. Tu je provedena klasična dijagonalizacija matrice poslovne
tehnologije, pri čemu nisu računati iznosi informacijskih funkcija elemenata matrice
(zanemareni su podaci o značaju i frekvenciji informacijske veze). Ne samo da je mjera

81
kvalitete strukture sustava u tom slučaju veća, nego je i broj popunjenih polja izvan
submatrice veći.

E4 E6 E8 E3 E5 E7 E1 E2 E9

p2 C R R R

p6 R C C R U R

p1 R C U R R

p4 R U R R C R

p5 R R R C R

p7 U R R R R

p8 U R U R R

p10 U R R R C

p11 R R U R

p12 U R U R R

p3 C

p9 R R C

Slika 32. Struktura informacijskog sustava (varijanta 2.)

Ukoliko se u presječna polja matrice poslovne tehnologije sa slike 32. unesu iznosi
informacijskih funkcija sa slike 30., lako se može izračunati mjera kvalitete strukture
informacijskog sustava.
U ovom slučaju je struktura i skupa entiteta drugačija od one koja pripada optimalnoj strukturi
informacijskog sustava:

E = { E 4 , E 6 , E 8 } ∪ { E 3, E 5 , E 7 , E 1 } ∪ { E 2 , E 9 } .

Primijeni li se na varijante struktura informacijskog sa slika 30. i 31. izračun kohezije može se
pokazati da je kohezija za optimalnu strukturu informacijskog sustava veća od kohezije za
druge strukture.
Ukupan broj popunjenih polja je e = 54.

U matrici prikazanoj na tablici 31. broj popunjenih polja izvan sve tri submatrice je e01 = 19,
a unutar njih je eu1 = 35. U matrici prikazanoj na tablici 32. broj popunjenih polja izvan
submatrica je e02 = 23, a unutar submatrica eu2 = 31.

82
Ako je kohezija unutar i-tog podsustava KHSi jednaka omjeru broja popunjenih polja unutar
submatrica i ukupnog broja popunjenih polja matrice:
e
(KHS)i = u i
e
35
može se utvrditi da je kohezija unutar svih podsustava u prvoj varijanti (KHS)1 = ,au
54
31
drugoj (KHS)2 = . Iz navedenog proizlazi da je (KHS)1>KHS)2, što znači da je slikom 31.
54
prikazano optimalno rješenje.

Pitanja za ponavljanje:

1. Objasnite pojam strateškog planiranja informacijskog sustava, te zašto se pri tome

primjenjuje «top - down" pristup. Kakvu ulogu ima poslovodstvo u procesu
planiranja?
2. Navedite i objasnite faze strateškog planiranja informacijskog sustava.
3. Navedite podjelu metodika koje se koriste pri razvoju informacijskog sustava. Objasnite
ukratko najmanje tri od njih.
4. Objasnite sustavni postupak izgradnje informacijskog sustava.
5. Napišite kratki prikaz metodika za strateško planiranje informacijskog sustava
(najmanje četiri!).
6. Objasnite povezanost poslovnog modela i modela informacijskog sustava. Kakav je
odnos između poslovne strategije, IS i IT strategije.
7. Od kojih faza se sastoji analiza poslovnog sustava? Kakva je uloga analize poslovne
tehnologije? Ukratko opišite postupak.
8. Objasnite fazu strateške analize poslovanja organizacijskog sustava.
9. Opišite postupak poslovnog reinženjeringa (BPR).
10. Objasnite fazu izrade "grubog" modela podataka.
11. Objasnite ulogu određivanja temeljne arhitekture informacijskog sustava. Što čini
temeljnu arhitekturu informacijskog sustava?
12. Objasnite značenje analize postojećih informacijskih podsustava i utvrđivanje potrebnih
promjena.
13. Objasnite postupak određivanja prioriteta razvoja pojedinih informacijskih
podsustava.
14. Objasnite pojam dekompozicije. Kako se i zašto dekompozicija primjenjuje na model
procesa? Nacrtajte i objasnite jedan jednostavan primjer.
15. Kako se grafički može prikazati dekompozicija? Nacrtajte najmanje tri različita
grafička prikaza za isti primjer.
16. Što je model resursa i što on prikazuje? Kako se grafički prikazuje?
17. Klase podataka. Tehnika matričnih dijagrama. Matrica procesa i klasa podataka.
18. Objasnite pojam matrice veza. Što se sve njima može prikazati? Koja je njihova uloga u
procesu razvoja informacijskog sustava?
19. Objasnite pojam matrice poslovne tehnologije.
20. Navedite formalna pravila za popunjavanje matrice poslovne tehnologije.
21. Navedite i objasnite svojstva matrice poslovne tehnologije.
22. Kako se provodi dijagonalizacija matrice i oblikovanje podsustava? Što određuje
algoritam životnog ciklusa osnovnog resursa?
83
23. Objasniti pojam kohezije, te odnos između kohezije i kvalitete strukture informacijskog
sustava.
24. Kako se računa kohezija i kako se putem nje određuje koji je sustav kvalitetniji?
25. Kakva može biti unutrašnja konzistentnost informacijskog sustava? Koje vrste
povezanosti su dopuštene i zašto?
26. Kakva može biti vanjska povezanost informacijskih podsustava? Koje vrte povezanosti
su dopuštene i zašto?
27. Kakva mora biti struktura informacijskog sustava da bi ju smatrali optimalnom?
28. Objasnite razliku između analize sklonosti među entitetima i među procesima!
29. Napišite formulu i objasnite na jednostavnom primjeru koeficijent sklonosti procesa.
Kako izgleda matrica sličnosti? Objasnite njeno značenje u kontekstu poslovne
tehnologije sustava.
30. Navedite formulu i objasnite pojam modificiranog koeficijenta sklonosti procesa. Kako
izgleda matrica sličnosti? Objasnite njeno značenje u kontekstu poslovne tehnologije
sustava.
31. Da li je koeficijent sklonosti mjera sličnosti? Objasnite zašto.
32. Navedite i objasnite ograničenja kojih se treba pridržavati pri strukturiranju sustava.
33. Navedite formulu i objasnite pojam informacijske funkcije elementa matrice poslovne
tehnologije.
34. Navedite formulu i objasnite pojmove značaja informacijske veze, jakosti informacijske
veze i frekvencije.
35. Navedite formulu i objasnite pojam mjere kvalitete strukture informacijskog sustava.
36. Kako se provodi postupak dijagonalizacije ako su poznati parametri informacijske
funkcije elementa matrice? Objasnite na jednostavnom primjeru.
37. Navedite načelni postupak za određivanje optimalne strukture informacijskog sustava.

84
4. Izvedba informacijskog sustava

Analiza poslovnog podsustava

Administracija podataka
Šifarski sustavi
Uvođenje informacijskog sustava u primjenu

4.1. Analiza poslovnog podsustava

Dijagram tijeka dokumenata (podataka)

Radni dijagram (workflow)
Specifikacija zahtjeva

Postupak dekompozicije uveden u prethodnom poglavlju primjenjuje se ne samo na poslovne

procese, već i na sam sustav. Složen i velik poslovni sustav teško je sagledati odjednom, kao
cjelinu. Stoga se za projektiranje i izradu informacijskog sustava promatranog poslovnog
sustava uvijek provodi raščlanjivanje sustava na njegove dijelove, u ovom slučaju poslovne
podsustave69. Stoga se svaki poslovni podsustav analizira, utvrđuju se zahtjevi i poslovne
potrebe, te izrađuje potrebna projektna dokumentacija. Inženjerski pristup koji se pri tome
primjenjuje blizak je i drugim strukama, pa se često izgradnja informacijskog sustava
uspoređuje s izgradnjom kuće.

Korisnik (odnosno budući vlasnik i investitor) naručuje projekt (nacrt, izračun potrebnog
materijala, te vremena potrebnog za izgradnju) željene kuće od arhitekta. Arhitekt izrađeni
prijedlog modificira u skladu s željama i zahtjevima korisnika te, nakon što je korisnik
prihvatio projekt, predaje ga građevinaru na izradu. Izbor građevinara ovisi o visini troškova
koje je korisnik spreman platiti (uvijek se mogu izabrati skuplji ili jeftiniji materijali).
Izgradnja kuće traje neko vrijeme (uglavnom uvijek nešto duže nego li je planirano) i košta
gotovo uvijek nešto više nego li je predviđeno troškovnikom. Nakon primopredaje kuću
korisnik počinje koristiti i tada, u garantnom roku, prijavljuje kvarove koje izvođač treba
popraviti (ponekad se takvi popravci razvuku godinama, a ponekad je izvođač korektan i sve
obavi na vrijeme). Tijekom korištenja kuće vlasnik uočava nove nedostatke, koji mogu biti ili
posljedica loše izvedenih radova ili posljedica uvođenja nove funkcionalnosti koju korisnik
prije nije uočavao (primjerice, nije svejedno da li se kuća gradi u vrijeme dok vlasnik nema
djece ili su djeca mala, ili su djeca stariji tinejdžeri s svojim zahtjevima poput dovoljnog broja
utičnica u sobi za računalo i svu drugu moguću opremu). Poslovi koje treba obaviti na
uklanjanju nedostataka sada spadaju u održavanje kuće. Ponekad se rade rekonstrukcije i
modernizacije čitave kuće. I tako sve dok kuća ne bude dovoljno stara i neupotrebljiva u
svojoj funkciji, ili dok je vlasnik ne odluči zamijeniti novom, većom urbanom vilom.

Zamijeni li se riječ «kuća» s riječju «informacijski sustav» može se prepoznati životni ciklus
informacijskog sustava kako je opisan u poglavlju 2.3.2.

69
Može se primijeniti i poznata uzrečica «Podijeli pa vladaj», jer je lakše prepoznati potrebe, pa i realizirati ih u
manjem podsustavu.
85
Postupak analize poslovnog podsustava provodi se u nekoliko koraka, pri čemu se uvijek prvo
utvrđuju poslovne potrebe podsustava i izrađuje dijagram dekompozicije poslovnih procesa.
Zatim se izrađuje dijagram tijeka dokumenata koji kolaju u poslovnom sustavu, te radni
dijagram (engl. workflow) koji opisuje tehnologiju rada u sustavu. Radi se matrica veza
proces – zaposlenik kako bi se utvrdile nadležnosti za pojedine poslove, a ponekad i
nelogičnosti u opterećenju pojedinih radnih mjesta ili osoba. Na kraju se izrađuje detaljni
model podataka i model procesa poslovnog područja.

4.1.1. Dijagram tijeka dokumenata (podataka)

Dijagram tijeka dokumenata (podataka) je slika sastavljena od standardnih, unaprijed

propisanih grafičkih simbola koji predstavljaju pojmove iz organizacijskog sustava. Metodu
je 1978. godine uveo De Marco.

Metoda je pogodna za prikazivanje tijeka dokumenata u sustavu. U pravilu, kada se započinje

s analizom poslovnog sustava (ili podsustava) prikupljaju se dokumenti koji se koriste u tom
sustavu. Iskusni projektanti znaju da se svaki poslovni sustav može na različit način
organizirati kolanje svoje dokumentacije, kao i da terminologija koja se koristi u sustavu za
nazive pojedinih dokumenata može biti različita. Drugim riječima, izrada dijagrama tijeka
dokumenata prilika je za upoznavanje projektanta s sadržajem pojedinih dokumenata i
njihovom uporabom, ali i s rječnikom koji se koristi u poduzeću70. Stoga je dijagram tijeka
podataka dio procesne analize sustava čiji je cilj utvrditi logički tijek podataka kroz sustav.
Dijagram tijeka podataka opisuje paralelne (istovremene) procese iz stvarnog sustava i
temeljni je dio strukturnih metoda analize.

Dijagram tijeka podataka (u praksi se koristi skraćenica DTP) sastoji se od:

1. ulaznih i izlaznih tijekova podataka (zaslona, dokumenata) koje sustav dobiva ili
daje u okruženje,
2. vanjskih objekata (organizacija, ljudi, drugih sustava) koji šalju prema ili primaju
tijekove podataka od sustava,
3. procesa sustava (programa, aktivnosti, postupaka, podsustava) koji transformiraju
ulazne tijekove podataka u izlazne,
4. spremišta podataka (baze podataka, kartoteke) u kojima se čuvaju podaci potrebni za
izvršenje procesa ili dobiveni kao rezultat rada procesa.

Navedeni koncepti prikazuju se grafičkim simbolima koji mogu biti različiti kod različitih
autora71 (dijagram tijeka podataka općeg procesa prikazan je na slici 33.):

70
Primjer iz prakse bio bi razgovor između dva činovnika osiguravajućeg društva, u kojem se jedan analizira
premijski sustavi, a drugi tarife. To znači da činovnici razgovaraju o cjenicima premija osiguranja za različite
vrste osiguranja. Zajednički naziv za premijski sustav i tarifu tada bi bio «CJENIK».
71
U literaturi se navodi prema raznim metodama, primjerice prema DeMarco i Yourdon ili po Gane i Sarson
metodi itd.
86
 1. Tijek podataka predstavlja se vektorom ili usmjerenim lukom.
2. Vanjski sustav (izvorište ili odredište, granični entitet) predstavlja se pravokutnikom
ili pravokutnicima u nizu poput karata. Neki autori radije koriste elipse.
3. Proces (funkcija) predstavlja se zaobljenim pravokutnikom, elipsom i sl. Neki autori
radije koriste pravokutnik.
4. Spremište (skladište) podataka predstavlja se s dvije paralelne crte.

Izvorište Odredište
Izvorište Odredište
Izvorište Odredište

tok podataka A tok podataka B

Proces

Spremište podataka

Slika 33. Dijagram tijeka podataka općeg procesa

Da bi dijagram tijeka podataka prikazivao ispravan logički slijed procesa u sustavu potrebno
ga je povezati s dijagramom dekompozicije poslovnih procesa koji se također izrađuje pri
analizi sustava.

Na razini 0 nalazi se samo jedan proces i dijagram tijeka podataka koji sadrži samo taj proces
zove se kontekst dijagram. Kontekst dijagram prikazuje odnos sustava s okolinom i važan je
za utvrđivanje potrebe za povezivanjem s drugim sustavima.

Dekompozicijom se taj proces raščlanjuje na više potprocesa razine 1, koji se svi nalaze na
sljedećem dijagramu tijeka podataka. Daljim raščlanjivanjem svakog od potprocesa formiraju
se procesi razine 2. Međutim, njih se ne prikazuje na jednom dijagramu, nego se za svaki
proces razine 1 radi poseban dijagram tijeka podataka (slika 34.). Dakle, samo za razinu 0 i
razinu 1 izrađuje se po jedan dijagram tijeka podataka, a za niže razine se izrađuje onoliko
dijagrama koliko ima procesa na višoj razini (primjerice, ako na razini 3 postoji 5 procesa
onda će trebati nacrtati 5 dijagrama tijeka podataka).

87
 Proces RAZINA 0. Proces
razina 0 razina 0

KONTEKST DIJAGRAM

Proces
1.

Proces Proces Proces

1. 2. 3. RAZINA 1

Proces Proces
2. 3.

PROCESI RAZINE 1

Proces Proces RAZINA 2

2. 1. 2. 2.

Proces
2. 1.

Proces
2. 2.

PROCESI RAZINE 2. PROCESI RAZINE 2. PROCESI RAZINE 2.

Slika 34. Model povezivanja dijagrama dekompozicije i dijagrama tijeka podataka

Važno je zapamtiti da dijagram tijeka podataka NIJE dijagram tijeka programa i ne sadrži
opise programske logike.

Umjesto dijagrama tijeka podataka (posebno u ranim fazama analize podsustava) crta se
dijagram tijeka dokumenata. Primjer dijagrama tijeka dokumenata za urudžbeni zapisnik u
jednom mirovinskom fondu u fazi prikupljanja članstva prikazan je na slici 35.

88
 Pošta

- prijave za
suradnike
- ugovori
- pisma namjere
- ostala pošta

- ugovori
- pisma
Dostavljač
namjere A. Ulaz
dokumenata i
priprema

dokument
i

B. Rad u
urudžbenom Fax
zapisniku

evidentirani prijave za
dokumenti suradnike
Pozivni centar - prijave za Baza
suradnike podataka
- pisma namjere
C. Unos podataka
u sustav - prijave za
- prijave za suradnike
suradnike - pisma namjere
- pisama namjere

podaci i
dokumentii
knjiga izlazne
Internet
pošte

D. Uparivanje
unosa sa
urudžbenim
zapisnikom

izlazne E. Izlaz
liste
dokumenata

F. Izlaz informacija

Slika35. Primjer dijagrama tijeka dokumenata

89
4.1.2. Radni dijagram (workflow)

Radnim dijagramom prikazuje se slijed odvijanja procesa u promatranom poslovnom sustavu.

Procesi koji se odvijanju u nekom redoslijedu i obavljaju određene aktivnosti nad klasama
podataka prikazuju poslovnu tehnologiju poslovnog sustava. Poslovna tehnologija sustava
određena je pravilima i procedurama koje su usvojene u tom sustavu i kojih se svi zaposlenici
moraju pridržavati. Dakle, tehnologija rada je automatizacija procesa ili tijeka rada gdje
dokumenti, informacije ili zadaci prelaze od jednog sudionika ka drugom na način da su
upravljani pravilima ili procedurama. Stoga radni dijagram ili dijagram tijeka rada prikazuje
tehnologiju rada.

Radni dijagram se obično izrađuje najmanje dva puta za svaki proces: prvi puta se nacrta
postojeće stanje, znači kako se određeni posao obavlja u trenutku analize. Drugi crtež obično
se radi nakon što se provede standardizacija procedura, dokumentacije i podataka. Ponekad se
uspije provesti i preoblikovanje poslovnih procesa, tako da se taj drugi radni dijagram može
značajno razlikovati od prvog.

Koriste se slični ili isti grafički simboli kao kod dijagrama tijeka dokumenta. Mogu se
koristiti i dodatni simboli kojima se označava proces koji nije informatiziran za razliku od
onog koji jest, kao što su primjerice:

Dokument Ručna
Odluka
operacija

Prekid Baza podataka

Zaslon

Proces Spoj

Slika 36. Primjeri grafičkih simbola koji se koriste pri izradi radnog dijagrama

Radni dijagram grafički prikazuje procedure rada koje ne moraju nužno biti automatizirane.
Često se zaboravlja da postoje poslovi u sustavu koji iz raznih razloga neće biti
informatizirani, a o kojima treba voditi računa kada se analizira sustav i projektira
informacijski sustav. Radni dijagram prikazuje te procese i upozorava gdje je moguće kasnije
«usko grlo» u poslovnoj tehnologiji. Dapače, na temelju razmatranja radnog dijagrama
ponekad se mogu promijeniti redoslijedi prioriteta izgradnje informacijskih podsustava, jer se
može lakše uočiti njihov utjecaj na cjelokupno poslovanje.

Na slici 37. prikazan je radni dijagram za dio tehnologije rada u urudžbenom zapisniku
mirovinskog fonda (za primjer sa slike 35.):

90
-prijave za suradnike
-ugovori
Kraj
-pisma namjere
-ostala pošta No

Potvrda o A.1.1. Ispis Potvrda o

A.1. Yes
primitku? potvrde o primitku
Razdvajanje primitku
pošte

Prijave za A.2.2. Žig

Ostala pošta? No No na
suradnike?
dokument

Yes
Yes
A.2.1. Žig
na
kovertu
A.2.2.1.
B.1. Evidentiranje Sortiranje
pošte (koverte +
dokumenti)
A.2.1.1.
Sortiranje

B.2. Upis
red. br.
pošte

C.1. Unos podataka

u sustav

Prijave za Jednostrano
No
suradnike? potpisan ugovor

Yes No
Yes
C.3. Priprema
i slanje
dokumenata
poštom C.2. Pohrana
dokumenata

Kraj

Slika 37. Primjer radnog dijagrama (varijanta 1.)

91
Radni dijagrami često se izrađuju uz primjenu simbola koji nisu grafički. Posebno često se
takvi prikazi rade kada se želi poslovodstvu poduzeća prezentirati opću tehnologiju rada, bez
zadiranja u detalje. Na taj način se koncipira osnovna tehnologija, određuju potrebe za
resursima, uočavaju nelogičnosti u poslovanju kao i potrebe za uključivanjem poslovodstva u
realizaciju poslova. Danas dostupni programski alati za crtanje omogućavaju brzo skiciranje
radne tehnologije na način blizak poslovodstvu72. Primjer takvog prikaza dat je na slici 38.

-ugovori
-pisma namjere

- prijave za suradnike
- ugovor
- pisma namjere
knjiga izlazne pošte

PC

prijave za
suradnike Urudžbeni zapisnik Laser printer

- prijave za suradnike
- pisma namjere

Fax
- prijave za suradnike
- pisma namjere

INTERNET Pozivni centar

Slika 38. Primjer radnog dijagrama (varijanta 2.)

72
Ne treba zaboraviti da još uvijek velik broj direktora i/ili vlasnika poduzeća koji donose odluke o poslovanju i
ulaganjima nemaju formalno informatičko obrazovanje, pa je svakako u početku puno jednostavnije
komunicirati slikovnim simbolima.
92
4.1.3. Specifikacija zahtjeva

Specifikaciju zahtjeva odnosno listu korisničkih zahtjeva u pravilu bi trebao pripremati

korisnik. Međutim, korisnik uglavnom ne može samostalno izraditi kvalitetan i dovoljno
detaljno razrađen zahtjev. Stoga se specifikacija zahtjeva najčešće izrađuje timski, uz
korisnika sudjeluje i projektant sustava, a ponekad i ostali informatičari uključeni u projekt
(stručnjaci za bazu podataka, sistemski i aplikativni programeri).

Specifikacija zahtjeva posebno je važna zbog utjecaja na troškove i uspješnost informacijskog

sustava. S obzirom da se izrađuje u ranoj fazi razvoja informacijskog sustava, popravke i
preinake specifikacije zahtjeva u kasnijim fazama najčešće izazivaju i najveće troškove73.
Specifikacija zahtjeva je ujedno i dokument koji kasnije služi za provjeru da li je izveden
sustav u skladu s zahtjevom korisnika sustava. Njime naručitelj dokazuje da je tražio nešto što
izvođač možda nije izradio, a izvođač pak dokazuje da je izradio točno ono što je naručitelj
tražio. Zato specifikaciju zahtjeva nikada jedna strana ne smije sama mijenjati, ni korisnik niti
projektant odnosno informatičari koji izrađuju sustav. Dapače, preporuka je da se svaka
promjena koja odstupa od specifikacije zahtjeva pismeno dokumentira i potpiše od obje
strane. Tako kasnije nema rasprave o tome da li je nešto rađeno što nije naručeno ili je
naručeno nešto što nije izrađeno.

Sadržaj specifikacije zahtjeva stoga čini niz dokumenata od kojih je prvi zahtjev korisnika. To
je dokument kojim je korisnik pokrenuo postupak izrade informacijskog sustava (ili
podsustava). Zatim sadrži još analizu poslovnog podsustava (koja uključuje dekompozicijski
dijagram procesa, dijagram tijeka dokumenata, radni dijagram i tekstualni opis procesa),
šifarski sustav koji se koristi (sa naznakom koji je obvezujući, a koji proizvoljan), željeni
izgled maski (odnosno ekranskih slika), te izvješća i to barem osnovna, a po mogućnosti i
ona za koja se očekuje da će trebati napraviti.

Željene ekranske slike i izvješća potrebno je nacrtati. Često ih korisnik skicira rukom, a
projektant prenosi na računalo u neki od alata za izradu grafičkih prikaza, te nakon toga
verificira sadržaj sa korisnikom. Pri tome projektant mora voditi računa o čestim greškama
koji se javljaju u praksi (tablica 11.):

Česti problemi i greške Rješenja

nepostojanje standarda u poduzeću pa su ekranske
slike raznih aplikacija različite
previše podataka za jednu ekransku sliku pa je
nepregledna
nedostaju neki od podataka koji su definirani
modelom podataka
pojavljuju se novi podaci koji nisu ranije
definirani modelom podataka
podaci se pojavljuju na ekranskim slikama
neusklađeno sa procedurom rada
Tablica 11. Česte greške i preporuke kako ih izbjeći kod oblikovanja ekranskih slika
uvesti standarde (ili ih preuzeti od aplikacije koja se
najviše koristi u poduzeću ) i strogo ih se pridržavati
razdvojiti obavezne podatke od dodatnih, a dodatne
grupirati i izdvojiti ih u posebnu ekransku sliku -
preporuka je da se osnovni podaci uvijek vide na ekranu
neprekidno provjeravati model podataka i uspoređivati ga
sa ekranskim slikama
neprekidno provjeravati model podataka i uspoređivati ga
sa ekranskim slikama
provjeriti radne dijagrame i utvrditi razloge

73
U praksi se ovaj primjer može poistovjetiti s slučajem kad investitor pri gradnji kuće mijenja raspored
prostorija, zatvara postojeće ili probija nove prozore, pomiče zidove, vrata i slično. Tada se ugovorena cijena
gradnje kuće mijenja i to raste to više što je kasnije investitor zahtijevao promjenu.
93
Ekranske slike treba početi crtati "top-down" tj. prvo treba nacrtati glavni izbornik, pa zatim
redom prema dijagramu dekompozicije procesa. Na taj način sama aplikacija "vodi" korisnika
prilikom njenog korištenja.

Primjeri ekranskih slika za izbornike te za unos podataka prikazani su na slici 39.

94
 Slika 39. Primjeri ekranskih slika

Naravno da ekranske slike mogu biti prikazane i jednostavnim grafičkim alatima.

Izvješća se također prikazuju grafički i to:

o izvješća koja će se prikazivati na ekranu,
o izvješća koja će se prikazivati na papiru, i
o izvješća koja će se prikazivati i na papiru i na ekranu.

Izvješća koja će se prikazivati samo na ekranu moraju biti oblikovane u skladu s standardima
za ekranske slike koji su primijenjeni na cijelu aplikaciju, te moraju imati definirane tipke za
pomicanje stranica. Ta izvješća moraju biti oblikovana sukladno preporukama navedenim u
tablici 11. kao rješenje problema oblikovanja ekranskih slika.

Izvješća koja će se prikazivati na papiru moraju biti pregledna i čitka, s razumnim brojem
podataka na jednoj stranici papira. Čest slučaj je da korisnik stalno dodaje nove kolone i retke
na izvješće, tako da se font slova smanjuje do nečitljivosti. Na pisanim izvješćima mora
postojati oznaka tko je i kada napravio taj ispis. Ponekad se, posebno ako se izvješća šalju
izvan poduzeća, osim podataka o operateru, ostavlja i mjesto za potpis odgovorne osobe.

Izvješća koja će se prikazivati i na ekranu i na papiru često ne mogu biti identična. Dok na
ekranu postoji mogućnost pregledavanja velike količine podataka pomicanjem lijevo-desno i
gore-dolje, to nije moguće na ograničenog površini papira. Stoga se za takva izvješća izabiru
samo ona koja doista stanu na jednu širinu stranice papira. To je posebno važno kada se neki
ispis mora pohraniti u registrator i čuvati za kasniju uporabu određeni niz godina.

Pri kreiranju izvješća treba paziti da njihovi nazivi jasno govore na što se ona odnose i nikada
se ne smiju istim nazivom zvati izvješća za koja se mijenjanju parametri ispisa.

95
DD.MM.GGGG Pregled prisutnih vozila
HH:MM:SS KPKNUI03

Reg. oznaka Stat.voz. Datum ulaza Vrijeme ulaza Tren.akt.

____________ __ ___________ _________ __

RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS U

RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS A
RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS U
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS R
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS A
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS S
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS R
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D
F3-kraj F7-dolje F8-gore

PREGLED PRISUTNIH VOZILA

DD.MM.GGGG
HH:MM:SS

Reg. oznaka Stat.voz. Datum ulaza Vrijeme ulaza Tren.akt.

____________ __ ___________ _________ __

RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS U

RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS A
RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS U
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D
RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS R

Izradio:
_______________________

Slika 40. Primjeri izvješća

96
4.2. Administracija podataka

Rječnik podataka
Poslovi administracije podataka
Model podataka
Osnovni pojmovi ERA modela - entitet, relacija (veza), atribut

4.2.1. Rječnik podataka

Rječnik podataka je skup znanja o bazama podataka, odnosno baza podataka o bazama
podataka. Uloga rječnika podataka u informacijskom sustavu je nezamjenjiva. Većinu
podataka koristi više aplikacija, različite grupe korisnika, a u distribuiranim sustavima i više
računala. Isti podaci često su različito definirani i prikazani u istom informacijskom sustavu,
pa bez rječnika podataka nema ni koordinacije rada s podacima. Dodavanjem sufiksa i
prefiksa stvara se privid postojanja velikog broja različitih podataka, iako se radi o jednom
jedinom podatku. Često u loše organiziranim i nedovoljno kontroliranim informacijskim
sustavima takvi podaci postaju izvor buduće nekontrolirane redundance (zalihosti).
Uvođenje rječnika podataka, međutim, ne rješava probleme koji bi trebali biti riješeni još u
pripremnoj fazi definiranja novih ili konsolidacije postojećih podataka. Primjerice, ne smije
se dopustiti njihovo višeznačno ili neprecizno imenovanje, iako je to ponekad nemoguće
provesti za postojeće sustave. U tom slučaju rječnik podataka mora dopustiti vođenje
sinonima (različito imenovanje istog polja podataka) i homonima (jednako imenovanje
različitih polja). Time se ne podržava višeznačno imenovanje podataka, već se samo
omogućuje slika stvarnosti kao osnova za pročišćavanje definicija podataka.

Rječnik podataka treba pomoći pri uklanjanju nedostataka postojeće organizacije podataka.
Njegova primjena ne može se ograničiti samo na novorazvijene informacijske sustave, jer su
u danas postojeće sustave uložena velika financijska sredstva. Za mnoga poduzeća
projektiranje novog informacijskog sustava je neprihvatljivo i cilj je saniranje postojećeg
stanja. Slika stvarnog trenutnog stanja informacijskog sustava u rječniku podataka značajan je
dio povratnog inženjeringa.

Dok informacijski sustav služi za upravljanje realnim sustavom pomoću informacija koje
nastaju interpretacijom podataka iz baza podataka, rječnik podataka služi za upravljanje
podacima u bazama podataka74. Budući da je i rječnik podataka baza podataka, on sadrži
podatke o podacima (metapodatke), nastaje već pri modeliranju podataka i procesa (bilo na
papiru bilo na računalu) i služi kao osnova u svim fazama razvoja informacijskog sustava.
Rječnik podataka može biti upotrebljavan kao nezavisan sustav za definiranje i katalogiziranje
svih resursa podataka, bilo ručno ili automatizirano, za datoteke ili baze podataka, te za
katalogiziranje programa, projekata, sistemskih resursa.

74
Jandrić, K.: Primjena rječnika podataka u razvoju informacijskog sistema Končar, Zbornik Savjetovanja
CASE 3 o metodama i alatima za projektiranje informacijskih sustava, Opatija, 1991.
97
U užem smislu rječnik podataka služi za upravljanje metapodacima, tj. značajkama podataka,
ali ne i sadržajem opisanih podataka, dok su u širem smislu u rječniku podataka opisane sve
vrste objekata u entitetima rječnika, zajedno s njihovim svojstvima (atributima) i vezama. Uz
entitete podataka tada sadrže i procesne entitete (programske module, programe itd.). Tada je
to centralizirano spremište informacija o opisima podataka, kao što su:
o značenje podataka,
o odnosi prema ostalim podacima,
o instance ili osobe zadužene za održavanje podataka,
o izvori podataka,
o ovlašteni korisnici, i
o formati podataka.

Stoga rječnik podataka poslovodstvu ukazuje koji su podaci raspoloživi za podršku procesu
odlučivanja, projektante obavještava postoje li potrebni podaci za novu aplikaciju u nekoj od
postojećih baza podataka, programerima daje informacije o tome kakvi su formati postojećih
slogova, struktura podataka i sl., a korisnicima koji su podaci raspoloživi i koji su njihovi
nazivi.
Rječnik podataka je alat i proizvod administracije podataka, što znači da ju opskrbljuje
informacijama o tome gdje se pojavljuje redundanca, gdje je prisutna nekonzistentnost
podataka, kakve su strukture baza podataka na raznim platformama računala i u raznim
aplikacijama, koja je verzija podataka pravovaljana, tko sve koristi bazu podataka i na kojoj
razini zaštite podataka, te kako promjene u poslovnom procesu utječu na model podataka i
implementirane baze podataka. Ujedno osigurava mogućnost usklađivanja i usporedbe
podataka (osigurava kompatibilnost podataka) i pomaže pri održavanju integralnosti
(jedinstvenosti) modela podataka poslovnog sustava.

Prvi rječnici podataka bili su pasivni, mogli su čuvati korisne informacije o podacima, no
nisu imali mogućnost aktivnog udjela pri izvođenju transakcija.
Zatim su uvedeni rječnici podataka povezani s odgovarajućim sustavom za upravljanje
bazama podataka čime su projektanti i programeri “natjerani” na poštivanje stroge
standardizacije. Iako su informacije o podacima i njihovoj uporabi u takvim rječnicima
podataka bile korisne informatičarima, za krajnje korisnike nisu bile razumljive i lako
dostupne (slika 41).

Sustav baza podataka (SBP)

Sustav za
Baza
upravljanje bazom Korisnik
podataka
podataka (SUBP)

Slika 41. Model rječnika podataka povezanog s sustavom za upravljanje bazom podataka

98
Jezici četvrte generacije za rad s relacijskim bazama podataka omogućili su kreiranje
aktivnih rječnika podataka, čiji se sadržaj koristi u svim fazama razvoja informacijskog
sustava. Isti podaci definirani su i opisani sukladno potrebama projektanata (opis entiteta,
njihovih atributa te međusobnih veza), programera (detaljne strukture podataka, alternativna
imena za uporabu u jezicima treće generacije i sl.), te korisnika (opisi razumljivi korisnicima
različitih razina stručnosti, znanja i potreba).
Aktivni rječnik podataka je potpuno integriran u sustav upravljanja bazom podataka i jezik
baze podataka (slika 42). Za relacijske baze podataka standardni jezik je SQL (Structured
Query Language).

Sustav baza podataka (SBP)

Korisnik
(projektant, programer,
Sustav za Rječnik administrator)
Baza upravljanje podataka
podataka bazom podataka
(SUBP) SQL

Krajnji
Aplikacija
korisnik

Slika 42. Model aktivnog rječnika podataka

Aktivni rječnik podataka čine baza metapodataka (metabaza), alati za zahvat i analizu
sadržaja metabaze, funkcionalna sučelja i alati za upravljanje podacima75.

Metabaza sadrži podatke koji opisuju:

ƒ interne podatke, odnosno polja, slogove, datoteke, baze podataka;
ƒ ulaze i izlaze, odnosno korisničke transakcije, ekranske sadržaje i izvješća;
ƒ opremu koju čine središnje, periferne i komunikacijske jedinice računalnog sustava;
ƒ procese odnosno programe, module, programske sustave, ručne procedure, i
ƒ korisnike.

Baza metapodataka može sadržavati nekoliko stotina atributa koji opisuju navedene entitete.

Alati za zahvat i analizu sadržaja metabaze dijele se na:

ƒ alate za obradu upita koji su slični upitnim jezicima, a koriste se za pojedinačne i
povremene upite na zahtjev (ad hoc upite), i
ƒ generatore izvješća koji formiraju unaprijed utvrđena i planirana izvješća poput
pregleda veza među podacima, popis podataka prema ključnim riječima, sumarna
izvješća i sl.

Funkcionalna sučelja služe za povezivanje rječnika podataka sa vanjskim izvorima podataka

(primjerice s statističkim zavodom, državnim institucijama i sl.). Njima se provodi konverzija
metapodataka različitih sustava iz jednog u neki drugi oblik, što može biti razmjerno
komplicirano i može dovesti do logičke nedosljednosti odnosno nekonzistencije.

75
Panian, Ž.: Poslovna informatika, Potecon, Zagreb, 2001, str. 162.-164.

99
Alati za upravljanje podacima primaju, tumače i obrađuju korisničke zahtjeve za
dodavanjem, promjenom i/ili brisanjem nekih sadržaja metabaze. Oni moraju surađivati sa
sustavom za upravljanje bazom podataka pa stoga moraju biti kompatibilni. Njihova glavna
funkcija je zaštita sadržaja podataka u metabazi od neovlaštene uporabe, provjera
vjerodostojnosti tih sadržaja, obnavljanje podataka nakon mogućih prekida rada i uslijed
grešaka hardvera i softvera, osiguranje integriteta metapodataka u bazi (poduzimanje mjera
zaštite od oštećenja ili uništenja) te stvaranje uvjeta za istovremeni rad više korisnika sa istim
ili različitim dijelovima metabaze.

Integrirani rječnik podataka idealno je rješenje za poslovni sustav koji na jednom ili više
računala ima isti sustav za upravljanje bazom podataka. Metapodaci rječnika podataka tada
mogu biti usklađeni i standardizirani na razini cijele organizacije.

Rječnik podataka povezan s alatima za modeliranje i oblikovanje informacijskih sustava ili

skraćeno CASE pomagalima (engl. Computer Aided Software Engineering), te
generatorima aplikacija, ima ključnu ulogu pri kreiranju i održavanju složenih
informacijskih sustava. Jednom definirani standardi provode se u svim fazama razvoja, uz
kvalitetnu i opširnu dokumentaciju koja je preduvjet jeftinom i kvalitetnom održavanju
informacijskih sustava. Takav rječnik podataka ugrađen u CASE alate u hrvatskom prijevodu
naziva se "riznicom podataka" (engl. repository). Time se daje dodatni značaj vrijednosti
pohranjenih podataka.

4.2.2. Poslovi administracije podataka

Pri razvoju projekta bilo kojeg informacijskog podsustava neophodna je suradnja

administracije podataka već u ranim fazama razvoja projekta. Uspostava neophodnih baza
podataka je složen zadatak, jer o tome ovisi i budući razvoj informacijskog sustava.

Svaki poslovni sustav ima goleme količine podataka pohranjene u svom informacijskom
sustavu. Jedan podatak može biti korišten u više organizacijskih jedinica odnosno poslovnih
područja poduzeća, kao i u raznim aplikacijama. Zato je podacima nužno standardizirati
imena, prikaze (reprezentacije) i definicije. Posebna pažnja mora biti posvećena zaštiti
podataka, a sve ove funkcije zahtijevaju centraliziranu kontrolu76. Kao što je grupa
specijalista odgovorna za pojedina poslovna područja u poduzeću, tako i za organizaciju
podataka mora postojati grupa odgovornih specijalista. U velikim i teritorijalno raspršenim
poduzećima administracija podataka ne mora biti u potpunosti centralizirana, već može biti
više administratora podataka na raznim lokacijama. Pri tomu je važno strogo definirati
informacijske standarde kojih se moraju svi pridržavati77.

76
Jandrić, K.: Jedinstveni IS - utopija ili stvarnost , Zbornik Savjetovanja CASE 6 o metodama i alatima za
projektiranje informacijskih sustava, Opatija, 1994.
77
Trend decentralizacije informatičke inteligencije djelomično je uzrokovao nekontrolirano bujanje
redundantnih i nekompatibilnih podataka. Razvoj “otočnih” aplikacija bio je brži od razvoja informacijskih
podsustava integralnog informacijskog sustava. Pitanje koje poslove centralizirati, a koje decentralizirati time
utječe na organizaciju rada i daljnji razvoj informacijskog sustava kao cjeline.

100
Centralizirano upravljanje podacima (slika 43.) provodi se pri razvoju informacijskih sustava
u više dislociranih razvojnih centara. Centralno se propisuju informacijske norme i
tehnologija rada, razvija i konsolidira model podataka, te usklađuje model procesa.
Dislocirano se razvija model procesa i izrađuju prototipi i aplikacije. Konsolidacija modela
podataka provodi se u onoliko iteracija koliko kompleksnost problema zahtijeva.

SREDIŠNJI RAZVOJNI CENTAR

elementi poslovne tehnologije

Model podataka Poslovna tehnologija

poslovnog sustava poslovnog sustava

distribucija podataka iz okruženja

distribucija entiteta, atributa

i dijelom sadržaja entiteta konsolidacija propisana tehnologija rada kontrola ispravnosti
modela podataka tehnologije rada

DISLOCIRANI RAZVOJNI CENTAR

podaci

Model podataka Model procesa

aplikacije poslovnog podsustava

dokumenti

Slika 43. Centralizirano upravljanje razvojem u dislociranim razvojnim centrima

Rezultat ovakvog načina rada je model podataka poslovnog sustava na jednom mjestu, u
središnjem razvojnom centru, i njegovi različiti podskupovi u dislociranim razvojnim
centrima u obliku modela podataka aplikacije. Na taj način se čuva integralnost podataka u
informacijskom sustavu, a poslovne tehnologije u poslovnom sustavu78.

Potreba za upravljanjem podatkovnim resursima odnosno za administracijom podataka javila

se početkom sedamdesetih godina uvođenjem koncepcije baza podataka. U početku je bila

78
Jandrić, K.: Kada i kako rekonstruirati informacijski sustav, Infotrend br. 24/7, Zagreb, 1994.
101
organizirana kao servisna funkcija na svakoj lokaciji za svako računalo posebno, a tijekom
vremena se razgranala u niz poslova za koja su potrebna različita znanja i sposobnosti.
Prihvaćanjem stajališta da su informacije jedan od ključnih resursa poduzeća, posao
postavljanja infrastrukture podataka i kontrole razvoja i upravljanja sustavom baza podataka
postaje vrlo važan.

Poslovna funkcija administracije podataka može se općenito podijeliti na dvije osnovne

funkcije:
• funkciju administracije podataka kao kreatora informacijskih resursa organizacije i
• funkciju administracije baza podataka koja je tehnički i uslužno orijentirana.

Dok se administracija podataka bavi konceptualnim oblikovanjem modela podataka

(metapodacima odnosno podacima u rječniku podataka ili riznici), administracija baza
podataka bavi se fizičkom implementacijom modela podataka odnosno podacima u bazi
podataka79. Dakle, dok se administracija podataka bavi metapodacima (pa je prihvatljiviji
naziv administracija metapodataka), administracija baza podataka se bavi realnim podacima
koji nastaju i koriste se u informacijskom sustavu poduzeća. U postupku logičkog oblikovanje
baza podataka ove dvije funkcije se međusobno djelomično prekrivaju.
Administracija dostupnosti dijelova baza podataka (autorizacija korištenja i sl.), iako je
dijelom područje djelatnosti administracije podataka ipak se uglavnom odvija u nadležnosti
administratora sustava na kojem se baze podataka nalaze. Prema tome, moguće je
funkcijski razlikovati poslove planiranja podataka na strategijskoj razini kompanije,
administratora podataka na razini modela podataka, administratora baza podataka, operatera
nad bazom podataka, te osobe zadužene za kontrolu upotrebe baze podataka. Često te, iako
različite, poslove obavlja jedna osoba. Time se otvara mogućnost zlouporabe informacijskog
sustava, jer se ovlasti nad sustavom nalaze u rukama osobe koja možda nije pouzdana ili je
nepoštena, a nad njenim postupanjem nema praktički nikakve kontrole i nadzora. Stoga
poslove administracije podataka u poduzeću uvijek moraju obavljati barem dvije osobe.

Poslove administracije podataka se, sukladno tomu, može podijeliti na:

1. Administraciju metapodataka, koja se bavi uvođenjem koncepta modeliranja podataka
odnosno planiranja informacijskog sustava u organizaciji, izradom standarda za izradu
modela, izborom i uvođenjem CASE alata za konceptualno modeliranje, kreiranjem
konvencije imenovanja elemenata modela podataka (entiteti, veze, atributi i sl.),
oblikovanjem modela podataka i njegovim održavanjem, nadzorom nad uporabom dijelova
modela (i izradom uputa za korištenje) u pojedinim aplikacijama u poslovnom sustavu,
izborom i uvođenjem modela baze podataka i sustava za upravljanje bazom podataka,
planiranjem i održavanjem distribuirane baze podataka i povezanosti distribuiranih dijelova
baze podataka na razini modela podataka, promicanjem organizacijske i tehnološke razine
poslovnog sustava na temelju razvoja informatičke tehnologije i informatičkih znanja.

2. Administraciju baza podataka, koja se bavi oblikovanjem i formiranjem baze podataka,

kreiranjem konvencije korištenja i imenovanja elemenata u bazi podataka (datoteka, tablica,
pogleda itd.), osiguranjem dostupnosti podataka u bazi podataka, održavanjem integriteta

79
Jandrić, K.: Administracija podataka u poduzeću, Časopis za teoriju i praksu osiguranja "Osiguranje i
privreda" god. XXXIII br. 4., str. 20, Croatia osiguranje d.d., 1993.
102
baze podataka (postupcima osiguranja i rekonstrukcije baze podataka, reorganizacijom baza
podataka, itd.), praćenjem rada nad bazom podataka i njenim podešavanjem (punjenjem baze
podataka, izdvajanjem podataka iz baze podataka), izradom uputa za optimalno korištenje
baze podataka (pogotovo pri kreiranju ad hoc upita uporabom jezika četvrte generacije ili
SQL-a, ili o načinu i učestalosti uzimanja sigurnosnih kopija baza podataka i sl.).

Umjesto strogo tehničkih znanja nekadašnje administracije podataka danas je potrebno široko
poznavanje postojećih i novih tehnologija, poznavanje ekonomike obrade informacija,
sposobnost uočavanja dugoročne perspektive organizacija, te organizacijske i komunikativne
sposobnosti. Time administracija podataka postaje poslovna, a ne isključivo tehnička
funkcija.

Poslovi administracije podataka uključeni su u gotovo sve faze razvoja projekta, što je
prikazano na tablici 12. Administracija podataka u fazi održavanja i uporabe baze podataka
postaje temeljem povratnog inženjeringa, pri rekonstrukciji postojećeg i izgradnji novog
informacijskog sustava. Svi zahtjevi za nadopunama i promjenama postojećih aplikacija
trebali bi se dostavljati administratoru baze podataka za određeni sustav za upravljanje bazom
podataka, kako bi se uskladile nove strukture podataka s postojećim te kontrolirali
informacijski standardi prihvaćeni u informacijskom sustavu poduzeća.

podaci i z v r š i t e lj i

Faze razvoja projekta Poslovi Područja Projektant DA DBA Programer

Definiranje projekta Izrada dijagrama Analiza X

Definiranje zahtjeva i Tijeka podataka podataka X X
uporabe
Eksterno oblikovanje Izrada modela podataka X X
baze podataka (logičko Analiza uporabe X X X
modeliranje) podataka
Eksterno oblikovanje Oblikovanje X X X
baze podataka (izrada baze
logičkog modela baze) podataka

Interno oblikovanje Interno oblikovanje X X

baze podataka (fizičko baze podataka (izrada
modeliranje) fizičkog modela baze)
Implementacija baze X X
podataka
Održavanje i uporaba X X
baze podataka
Oznake:
DA - administrator podataka
DBA - administrator baza podataka

Tablica 12.: Uloga administracije podataka u razvoju baze podataka u sklopu projekta razvoja
informacijskog sustava

103
4.2.3. Model podataka

Modeliranje podataka je proces koji počinje utvrđivanjem i analiziranjem potreba korisnika za

informacijama, a završava izgradnjom stabilne ali prilagodljive baze podataka. Stoga model
podataka pojednostavljeno prikazuje karakteristike sustava preko skupa entiteta (objekata),
njihovih atributa i veza.

Pojedinim fazama izrade modela podataka odgovaraju različite razine apstrakcije i tumačenja
podataka, pa se može razlikovati80:
ƒ konceptualni model podataka,
ƒ logički model podataka, i
ƒ fizički model podataka.

Konceptualno modeliranje provodi se u fazama strateškog planiranja informacijskog sustava.

Dobro oblikovan konceptualni model zadovoljava sljedeća načela:
ƒ jedan podatak pohranjen je na jednom mjestu,
ƒ podaci moraju biti što je više moguće međusobno neovisni.

Izvor podataka za izradu konceptualnog modela je dijagram tijeka podataka (dokumenata)

izrađen na temelju analize postojećih i potrebnih podataka. Za njegovu izradu u pravilu je
nadležan administrator podataka.

Logičko modeliranje je definiranje logičkog modela podataka budućeg informacijskog

sustava. Proizlazi iz konceptualnog modela i sastoji se od:
ƒ oblikovanja logičkog modela podataka informacijskog sustava ili nekog njegovog
dijela uporabom modela entiteti-veze,
ƒ provjere logičkog modela u odnosu na konceptualni model i zahtjeve korisnika,
ƒ vrednovanja logičkog modela od strane korisnika, i
ƒ prevođenja modela entiteti-veze u logičku shemu baze podataka (uglavnom na
relacijski jezik) primjenom pravila prevođenja.

Posao logičkog modeliranja obavlja se u suradnji administratora podataka i administratora

baza podataka.

Fizičko modeliranje podataka polazi od logičkog modela i definira fizičku organizaciju baze
podataka koja je izabrana za određeni informacijski sustav.
Za taj posao nadležan je administrator baze podataka.

80
Prema Strahonja, V. et al.: Projektiranje informacijskih sustava, Zavod za informatičku djelatnost RH i Ina
Info, Zagreb, 1992., str. 108.
104
4.2.4. Osnovni pojmovi ERA modela - entitet, relacija (veza), atribut

Model entiteti-veze (ERA model – engl. Entity, Relationship, Attributes koji je postavio
Chen 1976.) izrađuje se pri logičkom modeliranju podataka i ne ovisi ni o računalnoj opremi
(hardveru) niti o softveru za upravljanje bazom podataka.

ERA model je grafički prikaz znanja o objektima, vezama i svojstvima podataka.

Sva tri osnovna koncepta modela entiteti – veze treba pobliže objasniti.

Entitet je stvarni ili apstraktni predmet ili događaj o kojemu se u informacijskom sustavu
pamte podaci. Entitet se odnosi na točno jednu određenu pojavnost (primjerice određenu kuću
u gradu). Tip entiteta odnosi se na istu klasu srodnih entiteta, dakle sve kuće u nekom gradu,
ili sve jednokatnice u nekom gradu i slično. U praksi se često pojmom entitet označava tip
entiteta. Oznaka za entitet je pravokutnik u koji je velikim štampanim slovima upisana
imenica (naziv entiteta) u jednini (dakle KUĆA, OSOBA, ŠKOLA, KUPAC). Budući da
naziv mora biti jasan i nedvosmislen treba koristiti pojmove koji se koriste u poslovanju.

Entitet odnosno objekt81 prema «srodstvu» može biti jaki, koji postoji neovisno od drugih
entiteta i slabi koji egzistencijalno i/ili identifikacijski ovisi o jakom entitetu.

PRIMJER:
Jaki entitet je može biti entitet ŠKOLA, jer može postojati sam za sebe (za sada se u
razmatranjima zanemaruje okolina, pa se tako u modelu zanemaruje Ministarstvo
prosvjete koje je nadležno za sve škole u Hrvatskoj). Slabi entitet je primjerice
RAZRED jer ovisi o entitetu ŠKOLA i ako se iz baze podataka obrišu podaci o školi
brišu se podaci i o razredu te škole.

ŠKOLA 1 ima RAZRED 1

RAZRED 2
RAZRED 3
RAZRED 4
RAZRED 5
RAZRED 6
.
.
.
ŠKOLA 2 ima RAZRED 1
RAZRED 2
RAZRED 3
.
.

81
Nekada se kao sinonim u za entitet koristio pojam objekt. Međutim, uvođenjem objektnih modela taj pojam se
prestao koristiti za entitet.
105
Entiteti su opisani svojstvima (atributima). Atribut može biti:
ƒ identifikacijski, koji jednoznačno i nedvosmisleno identificira jednu pojavu entiteta
među svim ostalima, trajno je pridružen entitetu i često se zove ključni atributi ili
šifra (jedinstveni matični broj građana (JMBG), matični broj pravnog subjekta (MBS),
matični broj indeksa studenta na nekom fakultetu i slično),
ƒ opisni, koji opisuje kvalitativna ili kvantitativna svojstva entiteta, pa se stoga mijenja
s vremenom jer se mijenjaju i stanja i svojstva entiteta (boja kose, broj osobne
iskaznice, adresa stanovanja i slično),
ƒ izvedeni, koji se izvode logičkim ili aritmetičkim operacijama iz definiranih
vrijednosti nekih drugih atributa, pri čemu su uključene formule, algoritmi i logički
izrazi (iznos poreza i prireza po zaposleniku i slično).

Vezom se povezuju entiteti. Veza se imenuje, a naziv veze opisuje ulogu entiteta u vezi.

ima
ŠKOLA RAZRED
pripada
1 M

Dijagram entiteti - veze (Martinova notacija)

ŠKOLA ima RAZRED

1 M

Dijagram entiteti - veze (Chenova notacija)

Slika 44. Primjer dijagrama entiteti – veze

Naziv veze je glagol ili glagolska imenica, ispisana malim slovima.

Veze se u ERA modelu razlikuju prema redu veze, prema načinu učešća entiteta u vezi i
prema tipu povezanosti entiteta.

Prema redu veze (ili stupnju veze pri čemu je stupanj veze jednak broju entiteta koji sudjeluju
u vezi) razlikuju se:

ƒ unarna, gdje se radi o vezi između dvije pojave istog tipa entiteta (često se koristi
naziv rekurzivna veza),
ƒ binarna, gdje se radi o vezi između dva entiteta, i
ƒ ternarna, gdje se radi o tri međusobno povezana entiteta.

106
Prema načinu učešća entiteta u vezi (često se naziva i članstvom entiteta) veze se dijele na
obavezne gdje svi članovi skupa pojava entiteta obavezno sudjeluju u vezi, i neobavezne ili
opcionalne gdje u vezi ne moraju sudjelovati svi članovi skupa pojava entiteta82.

sastoji se od
DIO
1

M je ugrađen u

ima M
ŠKOLA RAZRED
pripada
1

Slika 45. Primjer unarne i binarne veze

Prema tipu povezanosti (pridruživanja) određuje se kardinalnost veza koja može biti:
• jednostavno ili potpuno pridruživanje ( 1 : 1 ), gdje je svaki član iz skupa pojava
jednog entiteta povezan je s jednim i samo jednim članom iz skupa pojava drugog
entiteta,

OSOBA
JMBG
ima

123456789012
213456789123

ima

ima

1009955335121

Slika 46. Jednostavno pridruživanje (1:1)

ƒ uvjetno pridruživanje ( 1 : M ), gdje je svaki član iz skupa pojava jednog entiteta

povezan s jednim ili niti jednim ili s više članova iz skupa pojava drugog entiteta, pri
čemu je svaki član iz skupa pojava drugog entiteta povezan samo s jednim članom iz
skupa pojava prvog entiteta,

82
Pavlić, M.: Razvoj informacijskih sustava, Znak, Zagreb, 1996.
107
 OSOBA
INDEKS
ima

12345

ima 12457

ima

67890

Slika 47. Uvjetno pridruživanje (1:M)

ƒ složeno ili višeznačno pridruživanje ( M : N ), gdje je svaki član iz skupa pojava

jednog entiteta povezan s jednim, niti jednim ili s više članova iz skupa pojava drugog
entiteta (ne postoje ograničenja u povezanosti članova skupa pojava oba entiteta).

OSOBA
KLUB
je član

Košarkaški klub

je član
je član je član Nogometni klub

je član

Bridge klub

Slika 48. Složeno pridruživanje (M:N)

Važno je uočiti da se kardinalnost veze može mijenjati ovisno o tomu koji se entitet promatra.

Tako je moguće da:

1 osoba posjeduje 0, 1 ili više automobila

1 automobil pripada 1 osobi

Grafički se taj odnos prikazuje u Chenovoj notaciji (slika 49.):

1,1 0,M
posjeduje
OSOBA AUTOMOBIL
pripada

Slika 49.: Grafički prikaz kardinalnosti veze

108
U praksi korisnik opisuje povezanost između dokumenata, a projektant prepoznaje odnose
između entiteta. Na taj način postepeno se izrađuje ERA model. Stoga je prikladno navesti
neke primjere semantike veza:

o Trgovac jednom dobavljaču može poslati više narudžbi, ali se jedna narudžba
odnosi samo na jednog dobavljača. Tip pridruživanja je 1:M.

o Unarna veza ne može biti tipa pridruživanja 1:1, jer osoba ne može biti u braku
sama sa sobom. Unarna veza ne može biti tipa pridruživanja M:N, jer proizvod se
ne sastoji od samog sebe. Dakle, kardinalnost unarne veze mora biti 1:M.

o Način učešća entiteta u vezi (obvezno ili neobvezno članstvo) može se pojaviti kod
svakog reda veze i kod svakog tipa pridruživanja.

o Samo se veze tipa pridruživanja 1:1 i 1:M mogu implementirati u relacijskoj bazi
podataka. Stoga se svaka veza tipa M:N treba pretvoriti u dvije veze tipa 1:M i N:1
(primjer na slici 50.)

N M
RAČUN sadrži PROIZVOD

RAČUN PROIZVOD

1 1

sadrži
sadrži

N M
STAVKA
RAČUNA

Slika 50. Primjer semantike veze (Chen –ova notacija)

Isti primjer prikazan je Martinovom notacijom na slici 51.

109
 N M
RAČUN PROIZVOD

RAČUN PROIZVOD

1 1

N M
STAVKA
RAČUNA

Slika 51. Primjer semantike veze (Martinova notacija)

Osnovni postupak izrade ERA modela sastoji se od nekoliko osnovnih koraka. Prvi je
prepoznavanje entiteta83, pri čemu se utvrđuje ima li neki entitet svojstva koja ga detaljnije
opisuju, te ako ih ima proglašava se jakim entitetom. Nakon toga se utvrđuju njegovi atributi,
posebno identifikacijski, pri čemu izvorno svojstvo pripada izvornom entitetu (primjerice,
IZNOS stavke ne mora biti ničiji atribut, on može biti izveden od CIJENE (koja pripada
objektu PROIZVOD) i KOLIČINE (koja pripada objektu STAVKA). Zatim slijedi
utvrđivanje tipova veza i pridruživanje značenja svakoj vezi u oba smjera. Na kraju se provodi
objedinjavanje ERA modela koji se odnose na pojedina uža područja, pri čemu integracija
modela zahtjeva vođenje rječnika podataka. Objedinjeni model mora biti cjelovit odnosno
mora sadržavate sve informacije koje sadrže pojedini podmodeli, nereduntantan odnosno iste
informacije smije sadržavati samo jednom i usklađen odnosno ne smije sadržavati međusobno
proturječne informacije84.

Izrada ERA modela važan je dio posla koji se obavlja u fazi projektiranja informacijskih
sustava, jer o kvaliteti modela često može ovisiti uspješnost informacijskog sustava.

83
Ponekad je teško odrediti da li neki dokument proglasiti entitetom ili podatke s njega prepoznati u više
različitih entiteta.
84
Prema Strahonja, V. et al.: Projektiranje informacijskih sustava, Zavod za informatičku djelatnost RH i Ina
Info, Zagreb, 1992., str. 131.

110
4.3. Šifarski sustavi

Izvori šifarskih sustava

Oblikovanje šifarskih sustava
Upravljanje šifarskim sustavima u poduzeću

4.3.1. Izvori šifarskih sustava

Šifrom je jednoznačno određen neki pojam, osoba ili dokument. Obično se šifra dodjeljuje u
nekom organizacijskom sustavu, a drugi sustavi ju samo trebaju koristiti. Primjer je matični
broj poslovnog subjekta koji dodjeljuje Državni zavod za statistiku svakom poduzeću koje
počinje s radom, a zatim se taj broj koristi i u bankama i za porezne svrhe itd. Međutim, isto
poduzeće u različitim poslovnim sustavima može dobiti drugačiju šifru kupca ili dobavljača.
Stoga se preporuča u poslovanju koristiti provjerene izvore šifarskih sustava kada god je to
moguće. Tako su, primjerice, izvori šifarskih sustava često iz okruženja odnosno iz različitih
tvrtki, državnih institucija i slično. Tako je na razini države propisan šifarnik teritorijalni
ustroj, kao i međunarodni sustav označavanja valuta. Državni zavod za statistiku određuje
matične brojeve pravnih osoba, a Hrvatske pošte poštanske brojeve. Poslovni partneri kao što
su banke određuju šifre klijenata, tečajne liste i slično, a udruženja određenih djelatnosti kao
što je primjerice Hrvatski ured za osiguranje zone rizika u auto odgovornosti i kodove
osiguravajućih društava. Dio šifarskih sustava nastaje u poslovnom sustavu poput sustava
označavanja dokumenata, sustava označavanja poslovnih partnera i slično i koristi se najčešće
samo u njemu. Često se u informacijskom sustavu uz šifru koja je dodijeljena u nekoj od
institucija koristi i vlastita šifra, koja se generira u informacijskom sustavu poslovnog subjekta.
Iako je takav pristup dodjeljivanja više šifri istom entitetu informatički nepoželjan, koristan je
u poslovne svrhe. Poznat primjer je zabrana korištenja jedinstvenog broja građana (JMBG-a)
koji se dodjeljuje svakom državljaninu Republike Hrvatske, tako da su poslovni sustavi koji su
u svom informacijskom sustavu koristili samo te šifre za identifikaciju osobe, u 2003. godini
imali neplanirane visoke financijske izdatke za izmjene i dopune postojećih aplikacija.

4.3.2. Oblikovanje šifarskih sustava

Šifarski sustav dio je temeljnih podataka poduzeća koji se može pojavljivati u različitim
informacijskim sustavima u cijelosti ili u pojedinim segmentima. To je skup datoteka (tablica)
čiji se slog u pravilu sastoji od
• šifre (identifikacijskog atributa ili ključa),
• naziva, i
• još jednog ili više atributa koji podrobnije opisuju pojavu opisanu šifrom.

Šifra je obično identifikacijski ili ključni atribut entiteta. Kako se koriste u dnevnoj praksi
korisnici često preferiraju govoreće šifre, koje su njima bliske i razumljive, a mogu biti
slovčane ili se sastoje od kombinacije slova i brojeva. Negovoreće šifre često dodjeljuje
računalo, to može biti redni broj ili neki broj izračunat primjenom određenog algoritma i
slično. Negovoreće šifre korisnici nerado koriste i stoga treba već pri planiranju sustava o tomu

111
s njima postići dogovor. U većim poduzećima oblikovanje šifarskih sustava i upravljanje njima
provode za taj posao nadležne službe.

Šifarnici se u pravilu moraju koristiti povezano, što je ponekad teško provedivo jer su veze
između njih reda M:N. Zato se uvodi vezni ili asocijativni entitet koji povezuje takva dva
entiteta. Na slici 52. prikazan je primjer takve veze na primjeru teritorijalnog ustroja RH i
pošti (poštanskih brojeva). U Hrvatskoj svako naselje ima svoju šifru. Međutim, poštanske
brojeve dodjeljuju Hrvatske pošte prema svojim dostavnim poštama (poznat je izraz «zadnja
pošta ta i ta» što znači da svako mjesto nema svoju poštu ni poštanski broj).

PRIMJER:

Naselje Dobropoljana na otoku Pašmanu ima šifru naselja 011258. Međutim, to

naselje nema svoju poštu nego se koristi poštanski broj naselja Neviđane koji ima
šifru naselja 043036, a poštanski broj 23264.

Prijenosom modela šifarnika u fizičku organizaciju podataka (danas uglavnom u relacijsku)

ključevi odnosno identifikatori pojedinih zavisnih entiteta se spajaju u tzv. sastavljeni ključ.
To znači da se logički prikaz šifarskog sustava razlikuje od fizičke implementacije.

PRIMJER:
Gradu Zagrebu je dodijeljen čitav niz različitih šifri odnosno identifikatora:

Zagreb ima šifru županije 21

šifru grada 01333
šifru naselja 072150

Dakle, za odrediti šifru Zagreba treba paziti o kojoj se šifri radi.

Međutim, ako je poznato samo ime naselja, primjerice Dubrava, mora se znati gdje se
to mjesto nalazi. Zašto?
U Hrvatskoj postoji naselje Dubrava s tri šifre naselja: 15466, 15468 i 15440.
Svako od tih naselja nalazi se u drugoj općini, pa je za određivanje mjesta Dubrava
potrebno koristiti šifru naselja u kombinaciji s šifrom pripadajuće općine:

Dubrava ima šifru općine 04197 (Ston)

šifru naselja 15466
Dubrava ima šifru općine 03000 (Omiš)
šifru naselja 15468
Dubrava ima šifru općine 00973 (Dubrava)
šifru naselja 15440

112
 Očito je da se sva tri naselja koja se zovu Dubrava nalaze i u drugim županijama.
Dakle, prva je u Dubrovačko neretvanskoj (šifra županije 19), druga je u Splitsko
dalmatinskoj (šifra županije 17), a treća u Zagrebačkoj (šifra županije 01).

Šifra države- 2 mjesta

brojčana

Šifra države- 2 mjesta

slovčana

Šifra države - 3
mjesta - slovčana

Službeni naziv države DRŽAVA

Skraćeni naziv države

Naziv države u poš

tansikom prometu

Šifra županije
ŽUPANIJA
Naziv županije

Matični broj
grada/općine
GRAD (OPĆINA)
Naziv grada / općine

Matični broj naselja Broj pošte

NASELJE POŠTA
Naziv naselja Naziv pošte

NASELJE /
NASELJE/POŠTA
POŠTA

Matični broj naselja Broj pošte

Slika 52. Primjer veze teritorijalnog ustroja RH i pošti

113
4.3.3. Upravljanje šifarskim sustavima u poduzeću

Upravljanje šifarskim sustavima u poduzeća osjetljiv je posao, pa se stoga preporuča da ga

obavlja administrator podataka.

Ako šifarnik nastaje izvan poduzeća za koje se izgrađuje informacijski sustav (primjerice
teritorijalni ustroj Hrvatske), mora se pridržavati pravila postupanja koja nalaže autor
šifarnika (Državni zavod za statistiku nalaže evidentiranje i nove i stare šifre).

Ako šifarnik nastaje u poduzeću za kojeg se izrađuje informacijski sustav preporuka je

maksimalno automatizirati način dodjeljivanja novih šifara (najbolje je rješenje programsko
dodjeljivanje šifri pri unosu), zabraniti mijenjanje šifri, te strogo ograničiti mogućnost
inaktiviranja i brisanja šifri na jednu imenovanu osobu. Osoba koja unosi nove šifre u
pravilu je korisnik koji dobro poznaje svoj posao i koji zna kada treba dodijeliti novu šifru ili
ukinuti staru.

Vrijednosti identifikacijskih atributa (ključeva, šifri) ne mogu se mijenjati, a da se ne naruši

integritet entiteta. To znači da samo ovlaštena osoba izuzetno pažljivo smije definirati nove
šifre i brisati ih. Mijenjanje šifri nije dopušteno, nego se slog sa starom šifrom inaktivira, a
novi se unosi s novom šifrom. Stare šifre mogu izuzetno dugo postojati u sustavu iako se više
ne koriste. Ponekad je razlog tomu zakonska regulativa koja zahtijeva dugotrajno čuvanje
određenih podataka, a ponekad nedostatak adekvatnih (vrlo najčešće vrlo kompliciranih)
programa kojima se podaci vezani uz staru šifru «sele» na novu.

4.4. Uvođenje informacijskog sustava u primjenu

Specifikacija prototipa
Testiranje, uvođenje i održavanje informacijskog sustava

4.4.1. Specifikacija prototipa

Potpunu funkcionalnost aplikacije može se provjeriti izradom prototipa. Prototipom se

uglavnom ne mogu izvesti sve željene funkcije, ali on može poslužiti pri izradi potpune
specifikacije sustava i razjašnjavanju svih nedoumica. Ponekad se prototip može privremeno
koristiti dok se ne izradi potpuna aplikacija.

Za izradu prototipa potrebno je pripremiti akcijski dijagram, čiju tehniku su razvili i opisali J.
Martin i C. McClure 1985. god.

Akcijski dijagram je specifikacija unutarnje logike procesa odnosno opisivanje logike

programskog modula. Pri tome je «akcija» naziv za operacije i druge funkcionalne
komponente niže razine od kojih se sastoji proces.

114
Jedna akcija se dalje ne razlaže i njoj odgovara jedna ili više naredbi programskog koda
odabranog programskog jezika, odnosno jedna ili više pseudonaredbi pseudokoda.
Pseudokod je programski jezik blizak formalnom programskom jeziku, ali značajno
slobodniji u formiranju sintakse te stoga razumljiv i korisniku.

Akcijskim dijagramom prikazuju se i slijedni i usporedni procesi koji su grupirani u blokove,

pri čemu je blok akcija skup akcija koje se izvode sekvencijalno, alternativno ili repetitivno
(ponavljajuće)85. Na lijevoj strani slike 53. prikazan je sekvencijalni blok akcijskog
dijagrama, a na desnoj strani usporedno odvijanje blokova akcija B i C. Svaki blok ima naziv
kao i dijagram akcija, a oznaka "*" označava početak bloka. Ulazni podaci u pojedini blok
mogu se pisati odnosno navoditi s desne strane bloka na način da se prvo popišu svi ulazi, a
zatim svi izlazi.
*BLOK A
Akcija 1.

*BLOK A *BLOK B
Akcija 1. Akcija 2.
Akcija 2. Akcija 3.
*BLOK B
Akcija 3. Akcija 4.
Akcija 4.
*BLOK C
Akcija 5. Akcija 5.
Akcija 6. Akcija 6.

Akcija 7.

Slika 53. Primjeri akcijskih dijagrama

Akcijske dijagrame ponekad izrađuju projektanti sustava (posebno ako se koriste CASE
pomagalima), iako ih najčešće izrađuju sami programeri kako bi sebi detaljno pojasnili
zadatak. Takav primjer akcijskog dijagrama prikazan je na slici 54.

Akcijski dijagrami izrađuju se kada se metodama povratnog inženjerstva86 rekonstruira fizički

i logički model informacijskog sustava na temelju programskog koda. Taj posao se obavlja
uglavnom onda kada je potrebno obaviti dorade i promjene u postojećem sustavu, a
programska dokumentacija nedostatna ili je izgubljena. Tada je redoslijed postupaka
povratnog inženjerstva sljedeći:
ƒ Prvo se programski kod pretvara u pseudokod dijagrama akcija, a moduli opisani
pseudokodom prikazuju se strukturnim dijagramima.
ƒ Logički model podataka i dijagram tijeka podataka izrađuju se iz fizičkog modela.
ƒ Konceptualni model izrađuje se iz logičkog modela.

Za razliku od strateškog planiranja razvoja informacijskog sustava pristup povratnog

inženjerstva je "bottom-up". To znači da se iz poznavanja programskog koda i procesa na
najnižoj razini izvodljivosti rekonstruira logički model informacijskog sustava. Ovaj postupak
može pomoći projektantima pri upoznavanju poslovne tehnologije određenog sustava, ali ne
smije unaprijed odrediti kako će budući sustav funkcionirati. Ponekad se događa da korisnik
85
Prema Strahonja, V. et al.: Projektiranje informacijskih sustava, Zavod za informatičku djelatnost RH i Ina
Info, Zagreb, 1992., str. 201.
86
Njime se omogućuje rekonstrukcija postojećih sustava čiji programski proizvodi često nisu dokumentirani.
115
zahtjeva da nova aplikacija izrađena novom informatičkom tehnologijom bude preslika stare,
no tu treba biti oprezan i ne preslikavati zastarjelu tehnologiju rada.

Dakle, akcijski dijagrami omogućavaju analizu "odozgo prema dolje" i povratni inženjering
"odozdo prema gore".

Slika 54. Akcijski dijagram «Kreiranje računa»

4.4.2. Testiranje, uvođenje i održavanje informacijskog sustava

Testiranje sustava (provjera svih funkcionalnosti) ozbiljan je posao koji zahtjeva pomnu
pripremu. Iako se tijekom razvoja sustava neprekidno provjerava ispravnost funkcioniranja
sustava, obično se to radi u tzv. laboratorijskim uvjetima. Stoga je obavezno, prije početka
primjene provesti testiranje sustava u realnim uvjetima rada. Veoma često se (za svaki slučaj)
neko vrijeme (od mjesec dana do tri) radi paralelno na novi i stari način i provjerava svaki
korak i svaki izlazni podatak. Vrijeme paralelnog rada mora biti dostatno za utvrđivanje
mogućih nedostataka koji su promakli pri ranijem testiranju i za njihov popravak, kao i za
"uhodavanje" djelatnika za rad sa novim sustavom.

Uvođenje i primjena novog informacijskog sustava sastoji se od nekoliko koraka koje treba
detaljno pripremiti. Prvi korak je obuka korisnika i priprema početnih stanja baza podataka.
Taj posao se može obaviti kroz unos podataka (koji rade korisnici pri čemu vježbaju rad s
novim sustavom) ili kroz preuzimanje podataka iz starog sustava uz pomoć programa, a
korisnici provjeravaju ispravnost prenesenih podataka. Zatim se provodi testiranje funkcija
prema zahtjevu korisnika (u realnim uvjetima) i definira sustav pomoći korisnicima. U većim
tvrtkama često se organizira posebna organizacijska jedinica za pomoć korisnicima, dok u
manjim obično korisnicima pomažu programeri. Sljedeći korak je paralelan rad starog i novog
sustava, što iskusni projektanti zahtijevaju i zbog uhodavanja korisnika i zbog optimiranja
116
rada same aplikacije. Nakon dogovorenog roka (od jednog do tri mjeseca) provodi se završno
testiranje, pri čemu se rade kalkulacije i listaju sva potrebna izvješća, potpisuje se zapisnik o
preuzimanju informacijskog sustava i počinje njegova primjena.

Svaki sustav treba održavati (primjerice, čovjek mora jesti da bi mogao raditi), pa tako i
informacijski sustav. Održavanje sustava je izvođenje svih prethodnih aktivnosti radi
razvoja novih poslovnih procesa, izmjene postojećih procesa i otklanjanja pogrešaka. Ne
postoji informacijski sustav koji ne treba održavati. Međutim, ako je informacijski sustav
dobro i kvalitetno dokumentiran, vrijeme i trud koji se troše za održavanje sustava znatno se
smanjuje. To znači da uvijek prilikom izgradnje sustava treba izraditi:
ƒ projektnu dokumentaciju,
ƒ programsku dokumentaciju i
ƒ korisničku dokumentaciju.

Treba naglasiti da je bez obzira na to koliko je softver kvalitetno razvijen, zbog stalnog
mijenjanja potreba organizacije sukladno njenim poslovnim ciljevima, njenog rasta i
promjena u okruženju, životni ciklus aplikacijskog softvera kratak, čak kraći nego za hardver.
Znači da aplikacija danas razvijena, makar najkvalitetnija, već sutra može biti mijenjana.

Weinbergovo pravilo 80/20 vrijedi u većini organizacija čije je poslovanje podržano

računalom: «Općenito, 80% napora troši se održavanje manje od 20% programskog koda».
Stoga su u tablici 13. prikazani neki od čimbenika koji utječu na troškove održavanja.

ČIMBENICI KOJI POVEĆAVAJU ČIMBENICI KOJI SMANJUJU TROŠKOVE

TROŠKOVE ODRŽAVANJA ODRŽAVANJA

Starost sustava Uporaba novih informacijskih i komunikacijskih tehnologija

Veličina sustava Uporaba strukturnih tehnika

Nepostojanost podsustava, a time i aplikacija Uporaba alata za automatizaciju oblikovanja i modeliranja

Količina korisničkih izvješća Uporaba kvalitetnih baza podataka

Složenost programa Uporaba jezika četvrte generacije, generatora aplikacija itd.

Nezadovoljavajuća dokumentacija Kvalitetna administracija podataka

Tablica 13 .: Čimbenici koji povećavaju troškove održavanja

Nakon završetka projekta potrebno je izraditi post implementacijsku studiju. Njome se

potvrđuje ono što je napravljeno u prethodnim fazama životnog ciklusa sustava i uspoređuje
se s onim što se željelo postići. Rezultati post implementacijske studije daju podlogu za
donošenje odluka i plana daljeg razvoja sustava.

117
Struktura sadržaja post implementacijske studije odnosi se na izvršavanje plana, izradu novog
plana akcija i zaključivanje projekta.

Izvršavanje plana sadrži podatke o završenom projektu i to ocjenu ispunjenja zadanih

ciljeva, visinu troškova, te utrošeno vrijeme, podatke o izvršavanju sustava odnosno o
ispunjenju ciljeva, izvorima i efektima sustava, o automatiziranim dijelovima, dokumentaciji,
programima, sigurnosti sustava, zadovoljstvu korisnika itd., te na kraju o provođenju radnih
metoda odnosno izvještaj o primijenjenoj metodi rada.

Plan akcija sadrži evidenciju simptoma (grešaka u radu, nedostataka aplikacije, manjkavosti
neodgovarajućeg hardvera i slično) koji su otkriveni tijekom izrade post implementacijske
studije, njihovu analizu i prijedlog alternativnih akcija, uz opis prednosti i nedostataka
pojedine alternative, te prijedlog plana akcija koji može poslužiti kao osnovica za novu
izvedbenu studiju, razvojnu studiju kao i za održavanje sustava (u ovisnosti o tome kakav
zahvat se predlaže).

Zaključivanje projekta sadrži zaključak projekta i provjereni plan akcija.

Post implementacijska studija ne izrađuje se odmah nakon završetka projekta razvoja

informacijskog sustava, već se preporuča da sustav prethodno funkcionira najmanje godinu
dana. Na taj način dospijeva se provjeriti puna funkcionalnost sustava, a ponekad se u tom
razdoblju mogu obaviti i značajne dopune i preinake početnog projekta.

Pitanja za ponavljanje:

1. Objasnite postupak analize poslovnog podsustava. Koji dokumenti se pri tome

izrađuju?
2. Objasnite postupak izrade dijagrama tijeka dokumenata.
3. Nacrtajte i na jednostavnom primjeru objasnite koncepte dijagrama tijeka podataka.
4. Objasnite model povezivanja dijagrama dekompozicije s dijagramom tijeka podataka.
5. Objasnite pojam radnog dijagrama (workflow).
6. Objasnite pojam specifikacije zahtjeva. Što sadrži specifikacija zahtjeva?
7. Navedite česte greške pri izradi ekranskih slika i izvješća. Objasnite kako ih
eliminirati.
8. Objasnite pojam rječnika podataka. Nacrtajte i objasnite model aktivnog rječnika
podataka.
9. Navedite i ukratko opišite strukturu aktivnog rječnika podataka.
10. Objasnite uloua administracije podataka. Kako se provodi centralizirano upravljanje
razvojem u dislociranim razvojnim centrima?
11. Objasnite razliku između administratora podataka i administratora baza podataka. U
kojim fazama razvoja projekta oni sudjeluju zajedno, a u kojim svaki posebno?
12. Opišite ulogu modela podataka u razvoju informacijskog sustava, te objasnite koje
modele razlikujemo?
13. Navedite i objasnite pojam entiteta. Opišite jednostavnim primjerima kakve entitete
razlikujemo.

118
14. Navedite i objasnite pojam atributa. Opišite jednostavnim primjerima kakve atribute
razlikujemo.
15. Navedite i objasnite pojam veze. Koje vrte veza poznajete? Objasnite na jednostavnim
primjerima kardinalnost veza.
16. Navedite i ukratko objasnite upute za izradu ERA modela.
17. Objasnite ulogu standardizacije postupaka i podataka.
18. Objasnite što su šifarski sustavi. Navedite i ukratko opišite izvore šifarskih sustava.
19. Objasnite vrste šifri. Što čini šifarski sustav? Navedite i objasnite pravila kojih se
treba pridržavati pri upravljanju šifarskim sustavima.
20. Objasnite pojam specifikacije prototipa. Što je akcijski dijagram? Na jednostavnom
primjeru pokažite kako se crta akcijski dijagram.
21. Ukratko objasnite zadatak i redoslijed postupaka povratnog inženjerstva.
22. Kako se provodi testiranje informacijskog sustava? Navedite i opišite postupak.
23. Kako se provodi uvođenje informacijskog sustava? Navedite i opišite postupak.
24. Kako se provodi održavanje informacijskog sustava? Navedite i opišite postupak.
25. Koji čimbenici smanjuju, a koji povećavaju troškove održavanja informacijskog
sustava. Objasnite zašto!
26. Objasnite ulogu i sadržaj post implementacijske studije.

119
5. Primjena CASE pomagala

Uloga i uporaba CASE pomagala

Vrste CASE pomagala
Modeli zrelosti informacijskih sustava

5.1. Uloga i uporaba CASE pomagala

Potrebu za korištenjem programskih pomagala u procesu razvoja informacijskog sustava

moguće je prikazati izrazom koji je postavio prof. dr. Guido Dedene (Katholieke Universiteit
Leuven)87:
1
K=
t
1- t +
k
gdje je:
1 = jedinično trajanje projekta
t = trajanje faze u kojoj se koristi pomagalo ( 0 < t < 1 )
k = koeficijent povećanja produktivnosti zbog primjene pomagala ( k > 1)
K = koeficijent povećanja ukupne produktivnosti.

Zamišljeno je da postoji hipotetski savršeno pomagalo za koje koeficijent povećanja

produktivnosti postaje beskonačan ( k → ∞ ).

t 1
Tada → 0 , pa je K = . Povećanje produktivnosti
k 1- t korištenjem CASE pomagala

9,00

8,00

t K 7,00

0 1,00 6,00
0,1 1,11
5,00
0,2 1,25 K
0,3 1,43 4,00

0,4 1,67 3,00

0,5 2,00 2,00
0,6 2,50
1,00
0,7 3,33
Slika 55. Primjer za k → ∞ 0,8 5,00 0,00
0,9 10,00 0 0,2 0,4 0,6 0,8 1
1 ∞ t

87
Jednadžbu je obrazložio A. Radelić na 1. hrvatskoj konferenciji SYNON korisnika, 1997. godine.
120
Ako se navedeno savršeno pomagalo koristi samo u nekim fazama razvoja sustava, primjerice
na trećini trajanja ukupnog razvoja, koeficijent povećanja ukupne produktivnosti K je 1,5
odnosno povećanje je svega 50%.
1 3
K= =
1 2
1-
3

Budući da ne postoji takvo savršeno programsko pomagalo, povećavanjem koeficijenta

produktivnosti k zbog uporabe pomagala 1, 2,.., n puta, iz izraza se uočava da koeficijent
ukupne produktivnosti K polako raste, za isti t < 1.

Povećanje produktivnosti
korištenjem CASE pomagala
9,00

8,00
k1=1,5
7,00
k2=2
6,00 k3=4
t k1 k2 k3 k4 K1 K2 K3 K4 k4=8
5,00
0 1,5 2 4 8 1,00 1,00 1,00 1,00 K
0,1 1,5 2 4 8 1,03 1,05 1,08 1,10 4,00
0,2 1,5 2 4 8 1,07 1,11 1,18 1,21
0,3 1,5 2 4 8 1,11 1,18 1,29 1,36 3,00
0,4 1,5 2 4 8 1,15 1,25 1,43 1,54 2,00
0,5 1,5 2 4 8 1,20 1,33 1,60 1,78
0,6 1,5 2 4 8 1,25 1,43 1,82 2,11 1,00
0,7 1,5 2 4 8 1,30 1,54 2,11 2,58
0,00
0,8 1,5 2 4 8 1,36 1,67 2,50 3,33
0,9 1,5 2 4 8 1,43 1,82 3,08 4,71 0 0,2 0,4 0,6 0,8 1
1 1,5 2 4 8 1,50 2,00 4,00 8,00 t

1
Slika 56. Primjer za K =
t
1- t +
k

Izrazom je pokazana nedovoljna efikasnost primjene pomagala ako se koristi samo u

nekim fazama razvoja sustava, što proizlazi iz nepovoljnog međusobnog odnosa između
koeficijenta povećanja ukupne produktivnosti K i trajanja faze t u kojoj se koristi
pomagalo. Zaključak je, stoga, da treba povećati trajanje faze u kojoj se koristi pomagalo
odnosno proširiti uporabu CASE pomagala na sve faze razvoja informacijskog sustava.

Dakle, CASE pomagala su potrebna u svim fazama razvoja, pa i u fazi strategijskog

planiranja odnosno izrade arhitekture informacijskog sustava.
Prva CASE pomagala razvijena su u početku osamdesetih godina, a u posljednjih se
petnaestak godina njihov broj izuzetno povećao. Pri tomu neka od njih podržavaju samo neku

121
od aktivnosti pri projektiranju informacijskih sustava, druga objedinjuju više aktivnosti, neka
generiraju izvršni kod pa ih se naziva i generatorima aplikacija, a neka teže objediniti sve faze
razvoja informacijskog sustava. Njihova je glavna zadaća povećati produktivnost i kvalitetu
programskih rješenja, što čine više ili manje uspješno.

5.2. Vrste CASE pomagala

Osnovna podjela CASE pomagala je na:

o pomagala za konceptualno i logičko projektiranje (gornji ili “upper” CASE) i
o pomagala za fizičko modeliranje i izradu (donji ili “lower” CASE).

Na slici 57. prikazane su vrste CASE pomagala i faze projektiranja informacijskog sustava
koje je moguće pomoću njih izvoditi. Uočljivo je da se faze prekrivaju (CASE potpunog
životnog ciklusa informacijskog sustava objedinjuje ih sve), dok bi integrirani CASE
(ICASE), koji još nije realiziran, trebao uključivati i povratno programsko preoblikovanje
procesa (povratni inženjering) kao i kontrolu kvalitete.

Neovisno o njihovoj unutrašnjoj strukturi, kao i o fazama projektiranja koje pojedine vrste
CASE pomagala pokrivaju, sva moraju imati rječnik podataka (riznicu88), moraju u
modeliranju strukture podataka polaziti od relacijskog ili objektnog modela, te moraju
proizvoditi svu potrebnu dokumentaciju. Riznica sadrži sve opise koji određuju stvarni
sustav i njegov informatički model, sve što je vrijedno o sustavu znati, pohraniti, sačuvati i
koristiti, pa je stoga širi pojam od rječnika podataka.

Kao posljedica primjene Dedene-ovog izraza može se zaključiti da je integracija CASE

pomagala nužna. Međutim, u praksi to često nije ostvarivo. Izbor CASE pomagala ovisi o
fazama razvoja informacijskog sustava koje se želi izvoditi računalom, ali i o metodikama
projektiranja koje pomagalo podržava. «Svaki CASE je dobar ako ga se zna primijeniti»89.

Primjerice, u složenim poslovnim sustavima koji se bave raznorodnom djelatnošću može se

dogoditi da, zbog povijesnih razloga praćenja razvoja informacijske tehnologije, paralelno i
istodobno postoji različita programska oprema, koja je međusobno neusporediva. Neovisno o
potrebi za rekonstrukcijom i ponovnom izgradnjom informacijskog sustava temeljenog na
istoj razini informacijske tehnologije, takav opsežan i dugotrajan proces nije moguće obaviti
preko noći. Primjena CASE pomagala u takvim uvjetima pomaže pri konsolidaciji postojećih
“rasutih” podataka, dok se njihovom uporabom na razini strategijskog planiranja i analize
poslovnog sustava kontroliraju elementi jedinstvenosti informacijskog sustava. Za izvedbu
pojedinih podsustava koriste se ili donji CASE ili generatori aplikacija koji podržavaju rad s
određenom bazom podataka.

88
engl. repository
89
Brumec, J.: Epistemiologija CASE alata, CASE6, Opatija, 1994.
122
 Slika 57.: Faze projektiranja informacijskog sustava i CASE

CASE pomagala nisu nužna da bi se projektirao informacijski sustav, pa je prihvatljiv stav da

“Ako to ne znamo učiniti bez njih, ni ona nam neće pomoći90”. Međutim, CASE pomagala
su projektantu nužna zato da bi se brzo i ekonomično projektirao takav informacijski sustav
koji ima velike izglede da bude prihvaćen kod korisnika, jer omogućuje izradu rješenja koje
odražava poslovnu tehnologiju sasvim određenog organizacijskog sustava.

90
Brumec, J.: Epistemiologija CASE alata, CASE6, Opatija, 1994.
123
5.3. Modeli zrelosti informacijskog sustava

Kao što je Nolan odredio skalu za organizacijsku i informacijsku zrelost poduzeća, temeljenu
na organizaciji podataka, Tricker je 1982. proširio model na sedam stupnjeva zrelosti
informacijskog sustava. Model nije teško primijeniti u praksi, jer se kriteriji za određivanje
pojedinih stupnjeva zrelosti koje je Tricker sistematizirao lako uočavaju i vrednuju.
Neovisnost o tehnologiji koliko je prednost Nolanova i Trickerova modela, toliko je i
nedostatak. Stoga su u literaturi definirani tehnološki uvjeti koje mora postići informacijski
sustav da bi dosegao određenu razinu zrelosti91. Odgovarajuća tehnološka osnovica
preduvjet je za primjenu informacijskih tehnologija u poduzeću, pa je stoga i njome određena
pripadnost pojedinom stupnju zrelosti informacijskog sustava.

Organizacijski, metodološki i tehnološki kriteriji za određivanje zrelosti informacijskog

sustava Trickerove podjele prikazani su u tablici 14.

FAZE ZRELOSTI ORGANIZACIJSKI I METODOLOŠKI TEHNOLOŠKI

INFORMACIJSKOG KRITERIJI KRITERIJI
SUSTAVA
1. Faza rane primjene ƒ primjena informacijskih tehnologija u ƒ primjena računala na
pojedinačnim i izoliranim slučajevima kojima su odgovarajući
programi
2. Faza zaraze i ƒ porast broja izoliranih aplikacija ƒ primjena centralnog
pridobivanja ƒ skupo održavanje aplikacija računala ili mreže
korisnika ƒ rasap sustava računala
3. Faza odvajanja ƒ odvajanje razvoja od produkcije ƒ primjena pomagala za
funkcija ƒ uvođenje planiranja informacijskog sustava projektiranje i
ƒ odvajanje analize od oblikovanja i dokumentiranje
programiranja projekata
4. Faza ujedinjavanja ƒ ujedinjavanje modela podataka ƒ primjena sustava za
(projektiranja, ƒ normizacija poslovne tehnologije upravljanje bazama
normizacije) temeljem normizacije aplikacija podataka i rječnika
ƒ dosljedna primjena neke od metodika podataka
razvoja informacijskog sustava
5. Faza upravljanja ƒ izgradnja konzistentne baze podataka ƒ korištenje jezika upita
podacima ƒ uvođenje funkcija administracije od strane korisnika
podataka i administracije baze podataka
ƒ samostalni pristup korisnika zajedničkim
podacima
6. Faza zadovoljavanja ƒ korisnici aktivno sudjeluju u razvoju IS-a ƒ grafičko sučelje
korisnika ƒ korisnik upravlja vlastitim podacima i za aplikacija i
njih je odgovoran ujedinjene radne
okoline
7. Faza pune zrelosti ƒ arhitektura informacijskog sustava ƒ otvorenost sustava
sukladna je arhitekturi organizacijskog ƒ distribuiranost baze
sustava podataka
ƒ strategijsko planiranje informacijskog ƒ primjena arhitekture
sustava dio je sustava planiranja tvrtke korisnik/poslužitelj
ƒ informacijski centar je servisna funkcija

Tablica 14: Organizacijski, metodološki i tehnološki kriteriji za određivanje

zrelosti informacijskog sustava (Trickerov model)

91
Strahonja, V.: Zrelost informacijskog sustava, Infotrend br. 43/2/1996, Zagreb
124
Ovisnost o tehnologiji jasno je izražena u modelu zrelosti razvoja informacijskog sustava
temeljenog na načinu njegove izgradnje koji je izradio J. Martin92. Sedam faza zrelosti razvoja
informacijskog sustava određeno je ovisno o uporabi metoda i tehnika, te pomagala za
projektiranje i programiranje, ali i o razvoju informacijske tehnologije. S obzirom na to da
kvaliteta i tehnološka razina informacijskog sustava određuju razinu njegove zrelosti, taj
model opisuje tehnološku zrelost razvoja informacijskog sustava. Značajke Martinove podjele
prikazane su u tablici 15.

FAZA ZRELOSTI ZNAČAJKE

RAZVOJA IS-a

1. Faza primitivnog - uporaba jezika III. generacije

razvoja - nema administracije podataka ni standardne metodike razvoja

2. Faza dobro - uporaba tehnika za strukturno programiranje ili objektno

strukturirana orijentiranih tehnika
razvoja - uporaba CASE-a u fazi planiranja, oblikovanja i generiranja aplikacija

3. Faza uporabe - uporaba integratora riznice podataka zbog provjere koegzistencije i

pomagala integriteta podataka
temeljenih na - potpuno generiranje programskog koda računalom
riznici podataka - administracija riznice podataka

4. Faza uporabe - upravljanje projektima i metodologijama putem računala

modernih - modeliranje poduzeća
metodika i - izrada prototipova aplikacija
metrika - korištenje metrike za procjenu brzine, kvalitete, troškova,
produktivnosti, zadovoljstva korisnika, održavanja i fleksibilnosti

5. Faza integracije - upravljanje riznicom podataka sustava poduzeća

sustava poduzeća - razvoj podsustava koji se uklapaju u arhitekturu sustava
- preoblikovanje funkcija u tijekove vrijednosti poduzeća
- mrežni ili Internet pristup
- uporaba metrike vezana uz poslovni dobitak

6. Faza neprekidne - razvoj metodika provodi se u razvojnim timovima

optimizacije - primjenjuje se upravljanje kvalitetom sustava
razvoja - koriste se za razvoj biblioteke gotovih programskih komponenti temeljenih
na riznici podataka
- oblikovanje fleksibilnih sustava

7. Faza neprekidne - razvoj inteligentnih modela poduzeća (u kojima se zrcale poslovna

optimizacije pravila i uvjeti)
poduzeća - poslovni modeli i preoblikovanje procesa prevode se direktno u
generatore koda temeljene na riznici podataka
- razvoj poduzeća u potpunosti je sukladan razvoju informacijske tehnologije
- inženjering poduzeća je neprekinut proces

Tablica 15.: Značajke faza zrelosti razvoja informacijskog sustava (Martinov model)

Očigledno je da se faze zrelosti informacijskog sustava ne podudaraju s fazama zrelosti

razvoja informacijskog sustava. Faze zrelosti razvoja informacijskog sustava uglavnom ovise
o stupnju razvoja informacijske tehnologije, a posebice pomagala koja se rabe pri
projektiranju, generiranju koda, upravljanju riznicom podataka, uporabi metrika. Prelazak u
92
Martin, J.: J. Martin World Seminar, Savant, 1995.
125
višu fazu zrelosti razvoja informacijskog sustava uvjetovan je razinom svijesti i znanja
korisnika i projektanata, te organizacijskom i tehnološkom razinom zrelosti informacijskog
sustava poduzeća. Pri tomu Martinova podjela može pomoći u planiranju daljeg razvoja.
Ujedno treba napomenuti da je postizanje faze pune zrelosti odnosno faza neprekidne
optimizacije razvoja i poduzeća više cilj nego li stvarnost. Čak i uz pretpostavku pouzdane
informacijske tehnologije i kvalitetne infrastrukture, dakle tehničkih preduvjeta, ključnu
ulogu u postizanju najviših faza Martinova modela ima korisnik, dakle ljudski čimbenik.
Stoga je u tablici 16. predočena usporedba između faza zrelosti informacijskog sustava
(Trickerov model) i faza zrelosti razvoja informacijskog sustava (Martinov model) kako bi se
naznačio put kojim treba ići, ali od kojeg su moguća i odstupanja.

FAZA ZRELOSTI INFORMACIJSKOG FAZA ZRELOSTI RAZVOJA

SUSTAVA (Tricker) INFORMACIJSKOG SUSTAVA (Martin)

1. Faza rane primjene 1. Faza primitivnog razvoja

2. Faza zaraze i pridobivanja korisnika

3. Faza odvajanja funkcija 2. Faza dobro strukturiranog razvoja

4. Faza ujedinjavanja

5. Faza upravljanja podacima 3. Faza uporabe pomagala temeljenih na riznici

podataka

6. Faza zadovoljavanja korisnika 4. Faza uporabe modernih metodika i metrika

5. Faza integracije sustava poduzeća

7. Faza pune zrelosti 6. Faza neprekidne optimizacije razvoja

7. Faza neprekidne optimizacije poduzeća

Tablica 16.:Usporedba faza zrelosti informacijskog sustava i faza zrelosti razvoja informacijskog
sustava

Pitanja za ponavljanje:

1. Objasnite uloga i uporabu CASE pomagala. Ukratko opišite razvoj CASE.

2. Objasnite Dedeneov izraz. Navedite primjere.
3. Navedite i objasnite vrste CASE pomagala. Objasnite pojam riznice.
4. Opišite Trickerov model zrelosti informacijskog sustava.
5. Opišite Martinov model faza zrelosti razvoja informacijskog sustava.
6. Objasnite usporedbu između faza Trickerovog i Martinovog modela.

126
6. Kvaliteta informacijskog sustava i zaštita od zloporaba

Kvaliteta informacijskog sustava

Zaštita informacijskog sustava

6.1. Kvaliteta informacijskog sustava

Međunarodne norme koje se primjenjuju u informatičkoj djelatnosti odnose se na različite
skupove podataka (poput šifri država i šifri valuta) ali i na kvalitetu softvera. Te norme donosi
posebna organizacija ISO - The International Organization for Standardization – odnosno
svjetsko udruženje nacionalnih institucija za normizaciju koje su ISO članice. Svaka nova
norma prihvaća se kada ju prihvati najmanje 75% svih ISO članica, ali ju članice nisu
obavezne koristiti93. S obzirom da se radi o preporuci za korištenje očekuje se da će ISO
članice primijeniti novodonesenu normu kada ostvare potrebne preduvjete. U Hrvatskoj su
norme ISO 3166 (šifre zemalja) i ISO 4217 (šifre valuta) uvedene u primjenu tek kada su ih
počele koristiti banke u svojim informacijskim sustavima, a u NN br. 111/2001 propisane su
za korištenje u platnom prometu s inozemstvom.

ISO norme uvijek propisuju i terminologiju koju treba koristiti. Tako se norma ISO 8402
odnosi na upravljanje kakvoćom i osiguravanje kakvoće, a zapravo je rječnik pojmova.
Norma ISO 9000-3 je norma za upravljanje kakvoćom i osiguranje kakvoće, a za
informatičare je zanimljiv Dio 3 koji donosi Smjernice za primjenu ISO 9001 u razvoju,
dobavljanju i održavanju softvera. Ovi međunarodni standardi odnose se primarno na
organizacije koje se bave razvojem, dobavljanjem i održavanjem softvera, iako se dijelom
mogu primijeniti i na korisnike.

Prvo je potrebno definirati pojmove koje norme koriste94. Tako je kvaliteta odnosno kakvoća
ukupnost značajki i svojstava proizvoda ili usluga zasnovana na sposobnosti zadovoljenja
utvrđenih ili očekivanih potreba. Sustav kvalitete onda čine organizacijska struktura,
postupci, procesi i resursi za uspostavljanje i provedbu upravljanja kvalitetom. Predmet
razmatranja je programska podrška (softver) odnosno intelektualni proizvod koji uključuje
programe, postupke, pravila i pridruženu dokumentaciju za rad sustava za obuhvat, pohranu,
obradu i razmjenu podataka. Softver je neovisan od medija na kojem je pohranjen.
Programski proizvod je cjeloviti skup računalnih programa, postupaka, pridruženih
dokumenata i podataka namijenjen za isporuku korisniku, a dio programskog proizvoda je
onaj segment programskog proizvoda koji je moguće identificirati tijekom razvojnih faza ili u
krajnjoj fazi razvoja.

Razvoj čine sve aktivnosti koje je potrebno učiniti da bi nastao programski proizvod, a taj rad
se odvija u fazama odnosno definiranim dijelovima posla. Na kraju svake faze razvoja
provodi se verifikacija odnosno proces evaluacije proizvoda u nekoj fazi razvoja u cilju
osiguranja ispravnosti i konzistencije u odnosu na proizvode i norme koji se pojavljuju kao
ulaz u tu fazu. Validacija se provodi na kraju procesa razvoja i to je proces evaluacije
softvera kojim se osigurava ispunjenje specificiranih zahtjeva.

93
Krakar, Z.: ISO sustavi kvalitete u informatici, ZIH Zagreb, 1994.
94
Međunarodna norma ISO 8402, Upravljanje kvalitetom i osiguranje kakvoće, Rječnik, HrQA INFO, 1994.
127
Navedeni pojmovi su korišteni u ovom radu, a ponekad su zamijenjeni drugim, prikladnijim
izrazom (primjerice, verifikacija je provjera ispravnosti izrađenog dijela softvera na kraju
neke faze razvoja).

Norma ISO 9000-3 (sustav kvalitete ili kakvoće) sastoji se od tri osnovna dijela95:
• Okvira,
• Aktivnosti životnog ciklusa i
• Aktivnosti podrške.

Okvir daje osnovne smjernice kojih se treba pridržavati i prvenstveno se odnosi na

organizacijsku komponentu provedbe sustava kvalitete. Određuje odgovornost poslovodstva,
upućuje da sustav kakvoće mora biti integrirani proces kroz cijeli životni ciklus kako bi se
omogućile preventivne akcije96, pri čemu je izuzetno važna uredna dokumentacija, nalaže
interne provjere sustava kakvoće te korektivne akcije gdje dobavljač uspostavlja,
dokumentira i održava procedure za otkrivanje i uklanjanje potencijalnih uzroka
neusklađenosti proizvoda sa zahtjevima kupca.

Aktivnosti koje se odnose na kakvoću treba planirati i implementirati u odnosu na prirodu

korištenja modela životnog ciklusa. U svakom poslu prvo se sklapa ugovor, pa je provjera
ugovora primjenjiva ne samo za informatičke tvrtke. Provjerava se da li su opseg ugovora i
zahtjevi definirani i dokumentirani, da li su utvrđeni mogući rizici i slučajni događaji koji
mogu utjecati na uspjeh projekta, da li su privatne informacije zaštićene na odgovarajući
način, da li su razriješeni svi zahtjevi, različiti od onih u ponudi, da li je dobavljač sposoban
zadovoljiti zahtjeve iz ugovora, da li su definirane odgovornosti dobavljača u odnosu na
podugovorne radove, da li je ugovorena terminologija među strankama, da li je kupac
sposoban zadovoljiti obveze iz ugovora. Većina sporova oko kvalitete informatičke podrške
softvera proizlazi iz loše dogovorenih i nejasno definiranih ugovora. Stoga posao ugovaranja
nije samo pravni posao nego timski rad u koji je uključen i informatičar.

U ugovoru bi trebale biti navedene stavke koje se odnose na kvalitetu softvera, poput
određenih kriterija prihvatljivosti gotovog rješenja, postupaka u svezi s promjenama zahtjeva
kupca tijekom razvoja, postupaka u svezi s problemima otkrivenim nakon preuzimanja
programa uključivši reklamacije koje se odnose na kvalitetu i opravdanih prigovora kupca.
Moraju biti određene aktivnosti koje provodi kupac, posebno uloga kupca u specifikacijama
zahtjeva, instaliranju i preuzimanju gotovog rješenja, te osiguranje sredstava, pomagala i
dijelova softvera od strane kupca. Kvalitetan softver informatičari ne mogu izraditi bez
korisnika – kupca, stoga se ugovornim stavkama specificira odgovornost kupca za kvalitetu
rješenja. Određuju se norme i procedure koje će se koristiti, kao i broj kopija gotovog
softvera.

Specifikaciju zahtjeva izrađuju najčešće zajedno naručitelj softvera (korisnik, kupac) i

dobavljač (informatička kuća, informatičar u tvrtki). Pri planiranju razvoja za svaku fazu
razvoja treba odrediti potrebne ulaze i izlaze, te plan verifikacije izlaza iz svih razvojnih faza
na kraju svake faze. Samo verificirani izlazi mogu se predati na dalji razvoj odnosno za dalju
uporabu. Planiranje kvalitete uključeno je u planiranje razvoja. Proizvod treba oblikovati u
opsegu koji će omogućiti olakšano testiranje, održavanje i uporabu, uz primjenu standardnih
pravila programiranja, konvencija, dosljednost nazivlja, kodiranja i primjenu pravila
95
Međunarodna norma ISO 9000-3, Norma za upravljanje kakvoćom i osiguranje kakvoće, Dio 3: Smjernice za
primjenu ISO 9001 u razvoju, dobavljanju i održavanju softvera, HrQA INFO, 1993.
96
Sustav kvalitete ne smije se razmatrati samo na kraju procesa razvoja.
128
komentiranja, te metodologije implementacije. Gotov programski proizvod mora proći
testiranje i validaciju odnosno potvrdu operativnosti (funkcionalnosti) dovršenog proizvoda.
Preuzimanje je tada formalizirana primopredaja programskog rješenja kupcu na daljnje
korištenje. Pri preuzimanju se potpisuje primopredajni zapisnik, kojim dobavljač potvrđuje
predaju proizvoda koji je izradio, a kupac da je primio proizvod u traženom obliku. Ujedno se
određuje broj kopija svakog softverskog dijela koji se isporučuje, vrsta medija za svaki
pojedini softverski dio, uključivši format i verziju, predaje se potrebna dokumentacija
(korisnički priručnici i upute), licence i autorska prava, upute i pravila za nadzor nad
originalom i kopijama uključivši plan rekonstrukcije softvera nakon uništenja, te period
obveze dobavljača za dobavom kopija.

U praksi se nakon primopredaje potpisuje poseban ugovor o održavanju. Sve promjene

softvera koje se izvršavaju tijekom održavanja treba što je više moguće provoditi sukladno
istim procedurama koje se provođene u razvoju tog softverskog proizvoda. Prema normi ISO
9000-3 razlikuju se tipovi aktivnosti održavanja, od kojih svaka ima svoju cijenu.
Rješavanje problema uključuje otkrivanje, analizu i ispravljanje nepodudarnosti proizvoda
koji uzrokuju operativne probleme. Ponekad se može ispravak provesti privremeno da bi se
skratilo vrijeme, a konačna modifikacija se može provesti kasnije. Modifikacija sučelja
odnosi se na zahtjeve u slučaju promjena u računalnoj konfiguraciji ili komponentama, pod
kontrolom servera. Najskuplje je funkcionalno proširenje ili poboljšanje performansi jer
naručitelj može u fazi održavanja zahtijevati funkcionalna proširenja ili poboljšanja
performansi postojećih funkcija, što može iziskivati izradu nove grupe programa ili značajne
promjene postojećih.
Aktivnosti održavanja treba registrirati i sve aktivnosti statistički pratiti. Treba izraditi popis
zahtjeva za pomoć ili popis primljenih izvješća o problemima, te zapis statusa svakog od njih,
odrediti organizaciju ili organizacijski dio odgovoran za realizaciju zahtjeva za pomoć ili
implementaciju primjerenih korektivnih akcija, pratiti prioritete dodijeljene korektivnim
akcijama i rezultate korektivnih akcija.
Dobavljač je obavezan izraditi i predati kupcu procedure za rad s verzijama odnosno
temeljna pravila koja određuju gdje se verzije mogu ugraditi kao i pravila za postupanje s
novim verzijama ažuriranih kopija softverskog proizvoda97. Takav dokument mora sadržavati
opis tipova (ili klasa) izdanja verzije softvera ovisno o njihovoj učestalosti i/ili utjecaju na
radnje naručitelja i mogućnost uvođenja promjena u bilo kojem trenutku, metode koje će se
preporučiti naručitelju za provođenje tekućih ili budućih promjena, metode koje treba koristiti
za provjeru da uvedene promjene neće uzrokovati nove probleme, te zahtjeve za
evidentiranjem promjena, koji upućuju na mjesta gdje su promjene uvedene.

U aktivnosti podrške spada upravljanje konfiguracijom kojim se osigurava mehanizam

utvrđivanja, kontrole i usklađivanja verzija svakog pojedinačnog dijela softvera.
Jednoobrazno se utvrđuje svaki pojedini dio softvera, identificiraju se verzije svih pojedinih
dijelova softvera koji zajednički tvore posebnu verziju kompletnog proizvoda, utvrđuje se
stanje izvedbe softverskog proizvoda u razvoju ili proizvedenog i instaliranog softvera,
kontrolira se istovremeno ažuriranje pojedinačnog dijela softvera od strane jedne ili više
osoba, osigurava se koordinacija ažuriranja višestrukih proizvoda na jednoj ili više lokacija,
prema potrebi, te se utvrđuju i usmjeravaju sve akcije i promjene koje su posljedice zahtjeva
97
Iako danas postoji velik broj informatičkih tvrtki koje se ne pridržavaju smjernica koje propisuje ova norma,
kad Hrvatska uđe u Europsku uniju morati će ih prihvatiti ili će propasti jer neće moći poslovati na uređenom
tržištu.
129
za promjenama. Poseban slučaj je kada se od dobavljača traži da uključi ili koristi softverski
proizvod dobavljen od drugog dobavljača ili od treće strane. Tada on mora uspostaviti i
održavati procedure validacije, pohrane, održavanja i zaštite takvog proizvoda, što mora biti
posebno ugovorno specificirano.

Aktivnosti podrške čini i kontrola dokumenata, podaci o kvaliteti i provedenim mjerenjima,

pravila, praksa i konvencije, kao i trening (edukacija) korisnika.

6.2. Zaštita informacijskog sustava

Rizik informatičko/internetske tehnologije je opasnost da njezina primjena dovede do

neželjenih posljedica (šteta) u organizacijskom sustavu i/ili njegovoj okolini. Do zloporabe
uglavnom dolazi iz dva razloga, i to radi ostvarivanja neopravdanih ili protupravnih koristi od
strane pojedinaca ili organiziranih skupina ili radi nanošenja materijalne ili nematerijalne štete
pojedincu, skupini ili zajednici. Najugroženiji su informacijski sustavi iz kojih se može
pristupiti Internetu, jer je i sam Internet izuzetno ugrožen.

Rizik zloporabe nije moguće u potpunosti spriječiti, ali ga je moguće minimalizirati

poduzimanjem općih preventivnih mjera, poput štićenja tajnosti podataka pohranjenih na
računalnim memorijskim medijima, pri čemu je najpouzdanija enkripcija odnosno postupak
izmjene digitalne poruke (iz tzv. otvorenog teksta u šifrat) tako da ga mogu čitati samo
ovlašteni korisnici, kontroliranja tipova ostvarivanih veza s ostalim subjektima na Internetu,
štićenja privatnosti pojedinca, štićenja od prijevara u poslu, štićenja od obasipanja neželjenim
porukama, za što se koriste preusmjerivači pošte, alternativne mail adrese, programi za
filtriranje poruka i sl., štićenja tajnosti enkripcijskih i identifikacijskih ključeva, posebno kod
korištenja kartica za plaćanja. Potrebno je redovito provjeravati ne postoji li u programima
koji se obrađuju neka vrst "zloćudnog" koda (računalni virus ili crv) koji se u pravilu lijepi na
računalni program kako bi preuzeo kontrolu pri njegovom sljedećem izvođenju, te razviti u
tvrtkama odgovarajuću sigurnosnu politiku i primorati sve djelatnike da se pridržavaju
njezinih odrednica.

Osim preventivnih mjera provodi se i fizička zaštita informacijskog sustava, koju čine98:

• kontrola nenamjernog i namjernog ugrožavanja fizičke imovine informacijskog

sustava (od prirodnih nepogoda, požara i zlonamjernih aktivnosti), u što su uključena
računala i ostala oprema,
• kontrola zlonamjernog ugrožavanja logičke imovine informacijskog sustava odnosno
diskova, medija, podataka na računalu, te
• provođenje mjera zaštite pristupa informacijskom sustavu kroz:
• aktivnosti identifikacije korisnika koja se provodi putem lozinke (engl. Password)
korisnika, i
• aktivnosti provjere ovlaštenosti (autoriziranosti) korisnika koja se obavlja
programski, na temelju unaprijed definiranih parametara za svakog korisnika.

98
Klasić, K.: Zaštita informacijskih sustava, str. 31-31., Iproz, Zagreb, 2002.
130
Stoga se mogu definirati tri osnovne razine organizacije sigurnosti i zaštite informacijskog
sustava:

I razina, na kojoj se uklanjaju rizici fizičke naravi uvođenjem sljedećih postupaka:

• kontrola fizičkog pristupa opremi i prostorijama s računalima,
• protupožarna, protupotresna, protupoplavna zaštita opreme i podataka,
• osiguranje neprekinutog napajanja računala električnom energijom,
• zaštita od prljavštine, prašine, elektrostatičkog naboja,
• redovita izrada zaštitnih verzija podataka (engl. Backup).

II razina, na kojoj se uklanjaju rizici moguće zloporabe informacijskog sustava ili neovlaštenog
pristupa podacima, a temelji se na fizičkoj i logičkoj identifikaciji korisnika (ključevi, kartice,
lozinke) te dodatnim provjerama ovlaštenja u pojedinim koracima obrade podataka.

III razina, koja je usmjerena na osobito važne i vrijedne podatke i informacije u sustavu, na
očuvanje njihove tajnosti i sigurnosti, a temelji se na kriptografskim metodama.

Svi korisnici sustava moraju biti upoznati sa pravilima i postupcima zaštite informacijskog
sustava, te sve aktivnosti redovito provoditi. Sigurnost i zaštita informacijskih sustava i računala
važno je područje kojim se bave informatičari i koje treba posebno detaljno razmatrati.

Pitanja za ponavljanje:

1. Što su ISO standardi i tko ih donosi? Kako se oni primjenjuju?

2. Objasnite pojam kvalitete informacijskog sustava. Koji ISO standard pokriva područje
kvalitete?
3. Objasnite kako se u ISO 9000-3 navodi sustav kakvoće - okvir.
4. Objasnite kako se u ISO 9000-3 navodi sustav kakvoće - aktivnosti životnog ciklusa.
5. Objasnite kako se u ISO 9000-3 navodi sustav kakvoće - aktivnosti podrške.
6. Zašto se provodi zaštita informacijskog sustava? Objasniti razloge zloporabe.
7. Navedite kako preventivno zaštititi informacijski sustav.
8. Navedite i objasnite na što se odnose razine organizacije sigurnosti i zaštite
informacijskog sustava.

131
7. Seminarski primjer - Poslovanje trgovine

Sustavni postupak izgradnje informacijskog sustava

Primjer seminarskog rada “Poslovanje trgovine”
Zadaci za vježbu

Planiranje informacijskog sustava odvija se tijekom analize poslovnog sustava, pa su stoga na

primjeru poslovanja trgovine «VE-MA» d.o.o. date upute i detaljno razrađeni postupci kako
taj posao obaviti u praksi. Metodika koja je korištena skup je poznatih tehnika koje studenti
moraju usvojiti, a forma seminarskog rada standardna je za projektnu dokumentaciju
Veleučilišta u Splitu. Na kraju rada nalaze se zadaci s rješenjima, kako bi studenti mogli
provjeriti stečeno znanje.

S obzirom na to da je razvoj informacijskog sustava složen, dugotrajan i skup posao i da su za

njegovu provedbu potrebna različita znanja, izrada takvog projekta se u praksi obavlja timski.
Stoga je i izrada seminarskog rada timski rad koji rade po tri studenta u timu i svaki ima
unaprijed određene zadatke. Niti jedan član tima ne može obaviti svoj dio posla bez suradnje s
drugim članovima tima. Svaki tim bira svoj vlastiti projektni zadatak – poslovanje određene
tvrtke ili nekog njenog segmenta, pri čemu nije dozvoljeno obrađivati poslovanje trgovine u
dijelu koji je obrađen u seminarskom primjeru.

Primjeri tema:

Red. br. Naziv teme

1. Poslovanje kina
2. Poslovanje dječjeg vrtića
3. Poslovanje ordinacije opće medicine
4. Knjigovodstveni servis
5. Poslovanje kluba za obuku pasa
6. Poslovanje videoteke
7. Poslovanje auto škole
8. Poslovanje modne agencije
9. Poslovanje Web design studija
10. Poslovanje kemijske čistionice
11. Poslovanje časopisa
12. Poslovanje Internet kluba
13. Poslovanje obrta - posredovanje u kupoprodaji nekretnina
14. Poslovanje javnobilježničkog ureda
15. Poslovanje pivovare
16. Poslovanje hotela – rezervacija i organizacija smještaja
17. Poslovanje prodavaonice namještaja
18. Poslovanje turističke agencije
19. Poslovanje restorana
20. Poslovanje ski kluba
21. Poslovanje caffe bara
22. Poslovi Župnog ureda

132
7.1. Sustavni postupak izgradnje informacijskog sustava
Sustavni postupak izgradnje informacijskog sustava prikazan je na slici 17. Za primjer
'Poslovanje trgovine «VE-MA» d.o.o.' prikazan je u kratkim crtama sustavni postupak
izgradnje informacijskog sustava odnosno kako izgleda planiranje informacijskog sustava
analizom poslovnog sustava trgovine, te razvoj novog informacijskog sustava. Predmet
seminarskog rada je analiza poslovnog sustava, a ne izgradnja informacijskog sustava
(koja se obrađuje u drugim kolegijima).

POSLOVNI SUSTAV:

1. Ciljevi poslovanja:
• Ostvarenje prihoda od prodaje: praćenje dnevnog, mjesečnog i godišnjeg prometa, za cijelo
poduzeće i za svako prodajno mjesto.
• Pravodobna nabava artikala: praćenje količina na zalihama i popunjavanja zaliha u područnim
skladištima.
• Praćenje cijena artikala, pravovremena mjesečna prijava PDV-a.
• Praćenje dugovanja prema dobavljačima. Praćenje naplate od kupaca, obračun zateznih
kamata.
• Periodične statistike: artikli koji se prodaju dobro, oni koji se ne prodaju, koji se prodaju ispod
cijene i sl.

2. Organizacija poslovanja:

sedmično: SPLIT sedmično:

nabava i promet Centralno skladište nabava i promet

sedmično:
- veleprodaja - 2 puta
artikli sedmično:
dnevno: dnevno: artikli
nabava i artikli
promet

Trgovina VIS Trgovina SPLIT Trgovina TROGIR

Područno skladište Područno skladište Područno skladište
- maloprodaja - - maloprodaja - - maloprodaja -

3. Poslovni procesi:
• Zaprimanje artikala u centralno skladište (narudžbenica, primka)
• Veleprodaja (veleprodajni račun)
• Distribucija artikala u područna skladišta, povrat artikla iz područnog u centralno skladište
(međuskladišnice)
• Formiranje maloprodajnih cijena (cjenik artikala)
• Maloprodaja (maloprodajni račun)
• Dnevno zaključenje kase
• Inventura

4. Klase podataka:
SKLADIŠTE (naziv skladišta, adresa, tip prodaje, poslovođa)
DOKUMENT (vrsta dokumenta, datum izdavanja, datum zaprimanja, dobavljač/kupac, rabat)
ARTIKAL (naziv artikla, nabavna cijena, količina)
CJENIK (naziv artikla, prodajna cijena, vrijedi do datuma)
133
Model strukture informacijskog
sustava:
Organizacija Poslovni
poslovanja procesi

Klase
podataka

INFORMACIJSKI SUSTAV:

1. Model baze podataka:

SKLADIŠTE CJENIK

DOKUMENT ARTIKAL

2. Aplikacije i procedure:
Nabava, Zaprimanje artikala, Distribucija, Formiranje cjenika, Prodaja, Promet trgovine,
Praćenje partnera (dugovanja i potraživanja), Inventura, …

3. Nova organizacija poslovanja:

izvješća za izvješća za
poduzeće na upit: trgovinu
nabava i promet
Centralno skladište Područno skladište
- veleprodaja - - maloprodaja -
na upit:
artikli

4. Procjena učinaka:
Na kraju poslovne godine, obzirom da se podaci vode ažurno, a procesi nad podacima su
automatizirani, informacije koje se dobivaju iz infromacijskog sustavau slika su stvarnog
stanja poslovanja poduzeća.

134
7.2. Primjer seminarskog rada “Poslovanje trgovine”

Projekt: Poslovanje trgovine Datum: 27.10.2002

Faza:
Analiza poslovnog sustava (APS)
Ime i prezime (1): Smjer: Vl. potpis:

Ime i prezime (2): Smjer: Vl. potpis:

Ime i prezime (3): Smjer: Vl. potpis:

Sadržaj Član tima Str.

Plan razgovora s korisnikom (PLANRK) (1) 136

Razgovor sa korisnikom (RAZKOR) (1) 138
Određivanje i opis funkcija (OPISFUN) (2) 148
Određivanje i opis klasa podataka (OPISPOD) (2) 158
Matrica poslovne tehnologije (MPT) (3) 160
Lista korisničkih zahtjeva (ZAHTJEVI) (1) 163
Dijagram tijeka podataka (DTP) (1) 165
Radni dijagram (RADD) (2) 174
Maske za unos (MASKA) - primjer (3) 178
Izvješća (IZVJESCE) - primjer (3) 180

135
 Projekt: Poslovanje trgovine Datum: 13.10.2002
Faza: Analiza poslovnog sustava
Dokument: Plan razgovora s korisnikom (PLANRK)
Ime i prezime: Smjer:

Sadržaj

Cilj razgovora sa korisnikom

Upoznati se sa poslovnim i organizacijskim sustavom/podsustavom.
Sagledati procese.
Sagledati podatke.
Odrediti granice sustava/podsustava.
Navesti ograničenja sustava.
Pitanja za analizu

Cilj razgovora sa korisnikom

Upoznati se sa poslovnim i organizacijskim sustavom/podsustavom.

Cilj razgovora s odgovornim korisnikom je prikupiti informacije o postojećem
podsustavu, sustavima na koje utječe i sustavima koji utječu na njega.

Sagledati procese.
Potrebno je sagledati sve aspekte procesa koji se obavlja i posebno naglasiti način na
koji bi se morao obavljati.
Utvrditi sve dokumente koji su neophodni u veleprodaji i maloprodaji, kao i podatke
koji su potrebni za svaki dokument.

Sagledati podatke.
Prikupiti informacije o podacima, definirati ih i klasificirati.
Utvrditi da li je potrebno omogućiti različite pristupe podacima, te ako jest definirati
tko pristupa kojim podacima (po dokumentima), kao i način i redoslijed pristupa.

Odrediti granice sustava/podsustava.

Sustav ograničiti procesno i podatkovno, navesti i prepoznate pojmove u svezi sa
projektom a koji ostaju van granica sustava.

Navesti ograničenja sustava.

Prepoznati ograničenja, opisati ih i definirati utjecaj na projekt.

136
Pitanja za analizu

1. Kakva je sadašnja organizacijska struktura poduzeća i koji su njeni nedostaci?

Detaljno ispitati organizaciju poslovnog sustava zbog prijedloga organizacije
informacijskog sustava i potrebnih hardverskih komponenti.
2. Kakva je sadašnja poslovodna struktura poduzeća?
3. Koji djelovi poslovanja su problematični i ima li prijedloga kako probleme rješiti?
4. Postoje li procesi u poslovanju koji su višak i kako ih zaobići u budućnosti? Postoje li
procesi koji nedostaju? Popisati ih i povezati sa postojećim procesima poslovanja.
5. Do kojih podataka u procesu rada se teško dolazi i zašto? Ima li prijedlog za rješenje
tog problema?
6. Do kojih podataka u procesu odlučivanja se teško dolazi i nepouzdani su? Ima li
prijedloga za poboljšanje protoka podataka?
7. Kako trenutno izgleda i kako bi trebao izgledati model komunikacije sa partnerima
(kupcima i dobavljačima)?
8. Kojom dinamikom poduzeće namjerava širiti svoje poslovanje i djelokrug poslovanja
(godišnji plan, višegodišnje planiranje)?
9. Da li poduzeće svoje poslovanje namjerava širiti na inozemno tržište?

137
 Projekt: Poslovanje trgovine Datum: 19.10.2002
Faza: Analiza poslovnog sustava
Dokument: Razgovor s korisnikom (RAZKOR)
Ime i prezime: Smjer:

Sadržaj

Razgovor sa korisnikom
Sistematizacija bilješki sa razgovora
Raščlanjenje organizacijske strukture
Raščlanjenje poslovodne strukture
Dokumenti prikupljeni tijekom razgovora

Razgovor sa korisnikom

Razgovor je održan 18.10.2002.g., a vodili su ga:

za izvođača: ime i prezime projektanta/analitičara
za naručitelja: ime i prezime odgovorne osobe
Tijekom razgovora prikupljene su informacije o postojećem poslovnom sustavu i organizaciji
poslovanja. Sagledani su ciljevi poslovanja i poslovni procesi na način na koji se sada
odvijaju.

Ciljevi poslovanja:

• Ostvarenje prihoda od prodaje: praćenje dnevnog, mjesečnog i godišnjeg prometa, za

cijelo poduzeće i za svako prodajno mjesto.
• Pravodobna nabava artikala: praćenje količina na zalihama i popunjavanja zaliha u
područnim skladištima.
• Praćenje cijena artikala, pravovremena mjesečna prijava PDV-a.
• Praćenje dugovanja prema dobavljačima. Praćenje naplate od kupaca, obračun zateznih
kamata.
• Periodične statistike: artikli koji se prodaju dobro, oni koji se ne prodaju, koji se prodaju
ispod cijene i sl.

138
Postojeća organizacija poslovanja:

sedmično: SPLIT sedmično:

nabava i promet Centralno skladište nabava i promet

sedmično:
- veleprodaja - 2 puta
artikli sedmično:
dnevno: dnevno: artikli
nabava i artikli
promet

Trgovina VIS Trgovina SPLIT Trgovina TROGIR

Područno skladište Područno skladište Područno skladište
- maloprodaja - - maloprodaja - - maloprodaja -

Poslovni procesi:

• Nabava i zaprimanje artikala u centralno skladište (narudžbenica, primka)

• Veleprodaja (veleprodajni račun)
• Distribucija artkala u područna skladišta, povrat artikla iz područnog u centralno
skladište (međuskladišnice)
• Formiranje maloprodajnih cijena (cjenik artikala)
• Maloprodaja (maloprodajni račun)
• Dnevno zaključenje kase
• Inventura

Pregledani su, popisani i detaljno opisani svi dokumenti koji su neophodni u veleprodaji i
maloprodaji, kao i podatci koji su potrebni za svaki dokument.

Sistematizacija bilješki sa razgovora

Nabava robe (artikala)

Nabava artikala od dobavljača radi se ispisivanjem dokumenta narudžbenica na kome se

nalazi popis artikala koji se naručuju (stavke narudžbenice).
Dokument narudžbenica sastoji se od zaglavlja dokumenta na kome pišu podaci o dobavljaču
(naziv, adresa, telefon, matični broj, žiro račun). Također na zaglavlju treba upisati datum
kada je narudžbenica sastavljena i način plaćanja (jednoobročno ili u više obroka, ovisno o
dogovoru).
Stavki narudžbenice može biti jedna ili više, složene su u formi tablice u kojoj je popis
artikala sa podacima (kolonama):
- redni broj stavke
- šifra i naziv artikla
- jedinica mjere i naručena količina
- cijena po kojoj se naručuje
- iznos stavke (količina * cijena)
139
Za svakog dobavljača postoji nabavni cjenik. Na cjeniku su podaci o nabavnoj cijeni artikla i
roku isporuke.
Prilikom sastavljanja popisa artikala za narudžbenicu potrebno je imati podatke:
- o minimalnoj i maksimalnoj količina artikla (za skladište ili za cijelo poduzeće).
Ako je količina artikla u skladištu pala ispod minimalne količine, obavezno ga treba
naručiti. Artikle nikako ne bi trebalo naručivati ako je količina iznad maksimalno
određene zalihe.
- iz prodaje o naručenim i rezerviranim artiklima od strane pojedinih kupaca
- prethodnoj narudžbi određenog artikla (kako ne bi došlo do ponovne narudžbe).

Pregledi (izvješća) u nabavi artikala:

Rekapitulacija narudžbi dobavljačima – izvješće koje se može formirati za
odabrano ili za sva skladišta i za odabranog dobavljača. Treba omogućiti
rekapitulaciju narudžbenica koje nisu realizirane kroz neki zadani vremenski peroid, te
brisanje (poništavanje) više nevažećih narudžbenica.
Minimalne i maksimalne količine – izvješće koje za odabrano skladište i odabranu
grupu artikala daje pregled minimalnih i maksimalnih količina (zaliha) za svaki
artikal, te podatak o posljednjem dobavljaču.

Zaprimanje artikala u centralno skladište

Artikal se u centralno (veleprodajno) skladište može zaprimiti na sljedeće načine:

- od dobavljača
- iz maloprodaje (povrat iz područnih skladišta)

U slučaju da se zaprime artikli od dobavljača izrađuje se dokument primka (Dokumenti

prikupljeni tijekom razgovora - Prilog 1.). Pri izradi primke obavezno se mora upisati broj
narudžbenice, kako bi se znalo koja je nabava realizirana. Stavke s narudžbenice, koje su
pristigle s primkom, moraju se anulirati. Moguće je zaprimati i robu bez narudžbenice.
Osnovni podaci na primci su:
- datum zaprimanja i skladište
- podaci o dobavljaču
- način na koji je roba dopremljena.
Primka sadrži artikle koji su zaprimljeni u skladište. Osnovni podaci o artiklima na primci su:
- naziv i šifra (skladišni broj)
- jedinica mjere
- masa ili količina
- nabavna cijena
- iznos (nabavna cijena * količina)
Veleprodajno skladište se zadužuje za količinu i nabavnu vrijednost zaprimljenih artikala.
U primci bi trebalo pored nabavne cijene upisati i veleprodajnu cijenu iz cjenika dobavljača,
na osnovu kojeg se proračuna marža.

Kada se roba zaprima iz područnog skladišta radi se izlazna međuskladišnica u područnom

skladištu i ulazna međuskladišnica u centralnom skladištu. Dokumenti međuskladišnica
imaju u zaglavlju uz opis da li se radi o ulaznoj ili izlaznoj međuskladišnici još i podatke:
- skladište iz kojeg su izdani aktikli
- skladište u koje su zaprimljeni artikli
- datum i broj dokumenta.
140
U stavkama međuskladišnica su artikli koji se izdaju (zaprimaju) iz jednog u drugo skladište.

Izdavanje atrikala iz veleprodaje (zaprimanje u maloprodaju)

U maloprodaji se artikal može zaprimiti iz centralnog skladišta dokumentom ulazna

međuskladišnica.
Izdavanje artikala iz centralnog (veleprodajnog) skladišta u područna (maloprodajna)
skladišta i zaprimanje artikala u ta područna skladišta su dva procesa koja su ovisna jedan o
dugom i slijede jedan za drugim.

Pregledi (izvješća) prilikom zaprimanja/izdavanja artikala:

Rekapitulacija primki – pregled dokumenata primki za pojedinog dobavljača
popisanih po datumu kada je roba zaprimana u skladište. Uz redni broj, datum i broj
primke tablica popisa primki treba sadržavati i ukupnu nabavnu vrijednost artikala.
Promet po dobavljaču – izvješće u kojem se prikazuje popis dobavljača u nekom
vremenskom periodu (mjesečno, kvartalno, polugodišnje, godišnje) i vrijednost
nabavljene robe za svakog od njih. Izvješće se može formirati po grupama artikala, a
ako se zatraži, i po zadanom artiklu.
Rekapitulacija međuskladišnica – pregled dokumenata međuskladišnica (ulaznih i
izlaznih) za pojedino skladište, složenih po datumu izdavanja uz podatak o vrijednosti
izdane/zaprimljene robe.

Prodaja artikala u veleprodaji

Kod prodaje artikala iz veleprodajnog skladišta izdaje se za odabranog kupca dokument

račun (Dokumenti prikupljeni tijekom razgovora - Prilog 2.) koji može imati sljedeće
elemente:
- podatke o prodavatelju
- podatke o kupcu
- broj narudžbenice od kupca
- uvjete prodaje
- uplaćeni avans (ako ga ima)
- poziv na broj koji se sastoji od modela, broja računa i šifre kupca sa kontrolnim
brojem.
Uz artikle moguće je fakturirati usluge i amabalažu. Osnovni podaci o artiklima na računu su:
- naziv artikla ili usluge
- količina
- jedinična cijena
- iznos (jedinična cijena * količina) bez PDV-a1
- vrijednost PDV-a
- ukupan iznos (iznos + vrijednost PDV-a).
Na računu je potpis osobe koja je sastavila račun i potpis odgovorne osobe uz pečat
prodavatelja.

Za svaki artikal koji se prodaje u veleprodaji treba formirati veleprodajnu cijenu. Najvažniji
parametar koji određuje veleprodajnu cijenu je nabavna vrijednost artikla. Na nabavnu

1
PDV – Porez na dodanu vrijednost
141
vrijednost prodavatelj dodaje svoju zaradu (maržu). Prodavatelj i kupac mogu sklopiti ugovor
koji kupcu jamči određeni popust (rabat) na količinu kupljene robe u nekom periodu.
Popis svih artikala i njihovih cijena je cjenik. Cjenik bi morao imati datum od kada vrijede
izvješene cijene.

Pregledi (izvješća) u veleprodaji:

Rekapitulacija računa - pregled računa za pojedinog kupca popisanih po datumu
kada je račun izdan. Uz redni broj, datum i broj računa treba prikazati ukupnu
vrijednost računa bez PDV-a, ukupnu vrijednost PDV-a te ukupan iznos (vrijednost +
PDV).
Cjenik - ispis cijena za odabrano skladište, sve artikle ili odabranu grupu, uz
mogućnost ispisa i količina artikala na skladištu. Posebno se može ispisati cjenik
cijelog poduzeća. U cjenik ne ulaze artikli koji imaju oznaku neaktivni (trenutno se ne
prodaju).
Promet po kupcu – pregled isti kao Promet po dobavljaču, s tim da se osim artikala
može tražiti i pregled usluga.

Prodaja artikala u maloprodaji

Prodaja u područnim skladištima je prodaja tzv. krajnjem kupcu kome se na blagajni (kasi)
izdaje maloprodajni račun. Na maloprodajnom računu nema podataka o kupcu i
maloprodajni račun ne mora imati izraženu vrijednost PDV-a za svaki artikal. Dovoljno je
ispisati ukupni iznos PDV-a za cjelokupnu vrijednost računa.
Podaci u stavkama maloprodajnog računa su: artikal, količina, maloprodajna cijena i
vrijednost (količina * maloprodajna cijena).

Pregledi (izvješća) u maloprodaji:

Rekapitulacija utrška maloprodaje – pregled ukupne vrijednosti prodanih artikala
za zadani period (dnevni, mjesečni) sa ili bez prethodnog prometa (zatečenog stanja u
blagajni).
Rekapitulacija prometa maloprodaje - rekapitulacija dnevnog prometa po artiklima
i elementima cijene (cijena, PDV, ukupna vrijednost).

Pregledi (izvješća) u veleprodaji i maloprodaji:

Promet skladišta – izvješće koje za odabrano skladište prikazuje ulazne i izlazne
vrijednosti pojedinačno po svim dokumentima, za neko određeno vremensko
razdoblje.
Promet po artiklu (Dokumenti prikupljeni tijekom razgovora - Prilog 5.) – izvješće
koje u formi kartice prikazuje što se događalo tijekom vremena sa pojedinim artiklom.
Rekapitulacija svih dokumenata skladišta – izvješće koje se koristi kao zamjena
trgovačke knjige i knjige prometa. U ispisu su navedeni svi dokumenti u odabranom
razdoblju, te podaci o ulazu, izlazu i stanju po nabavnim i prodajnim cijenama, te
iznos PDV-a.

142
Inventura

Tijekom godine moguće je raditi neograničeni broj inventura. U tu svrhu se prvo za odabrano
skladište generira popisna lista i to za sve artikle sortirana po šifri ili nazivu (Dokumenti
prikupljeni tijekom razgovora - Prilog 3.).
Nakon što se popisna lista popuni sa stvarnim stanjem generira se inventurna lista u koju se
zapisuje stvarno stanje (Dokumenti prikupljeni tijekom razgovora - Prilog 4.). Ukoliko se
stvarno stanje razlikuje od stanja na popisnoj listi, tada se razlika zapisuje u kolone manjak,
odnosno višak, na osnovu kojih se generiraju dokumenti: zapisnik o manjku i zapisnik o
višku.
Pregled inventura – izvješće koje daje popis inventura s datumom inventure.

Raščlanjenje organizacijske strukture

"VE-MA" d.o.o.

Sektor za
Sektor prodaje računovodstvo i Sektor marketinga
financije

Služba Služba
veleprodaje maloprodaje

Poslovna jedinica - Poslovna jedinica - Poslovna jedinica -

Split Trogir Vis

143
Raščlanjenje poslovodne strukture

Generalni direktor

Direktor računovodstva Direktor

Direktor prodaje
i financija marketinga

Šef veleprodaje Šef maloprodaje

Poslovođa trgovine Poslovođa trgovine Poslovođa trgovine

Split Trogir Vis

144
Dokumenti prikupljeni tijekom razgovora

Prilog 1.

Prilog 2.

145
Prilog 3.

146
Prilog 4.

Prilog 5.

147
 Projekt: Poslovanje trgovine Datum: 20.10.2002
Faza: Analiza poslovnog sustava
Dokument: Određivanje i opis funkcija (OPISFUN)
Ime i prezime: Smjer:

Sadržaj

Određivanje osnovnih funkcija/procesa poslovnog sustava

Raščlanjenje funkcija
Opis funkcija/procesa

Određivanje osnovnih funkcija/procesa poslovnog sustava

Raščlanjenje osnovnih funkcija poslovnog sustava poduzeća 'VE-MA' d.o.o. do 2. nivoa dano
je ovom slikom:

Poslovanje trgovine
"VE-MA" d.o.o.

Vođenje Vođenje
Poslovanje Poslovanje
računovodstveno- poslova
veleprodaje maloprodaje
financijskih poslova marketinga

Izdavanje Zaprimanje Vraćanje

Naručivanje Zaprimanje Prodaja Prodaja
artikala u artikala iz artikala u
artikala od artikala u artikala u artikala u
skladište skladišta skladište
dobavljača skladište veleprodaji maloprodaji
maloprodaje veleprodaje veleprodaje

Na slici nisu raščlanjeni računovodstveno-financijski poslovi ni poslovi marketinga (oni nisu

bili ni predmetom razgovora s korisnikom) već je težište analize stavljeno na poslove prodaje.
Kako su i poslovi prodaje načelno podijeljeni na veleprodaju i maloprodaju, a svaka od tih
funkcija je relativno složena i raščlanjenjem bi dobili složenu hijerarhijsku strukturu koju bi

148
trebalo u ovoj analizi detaljno obraditi, to smo se odlučili za daljnju analizu poslovnog
podsustava koji se odnosi na veleprodaju.
Tako je u sljedećim slikama napravljena dekompozicija (raščlanjenje) podsustava 'Poslovanje
veleprodaje'.

Raščlanjenje funkcija

1. Dekompozicija podsustava 'Poslovanje veleprodaje'

Poslovanje
veleprodaje

Naručivanje Zaprimanje Prodaja Izdavanje artikala

artikala od artikala u artikala u u skladište
dobavljača skladište veleprodaji maloprodaje

1.1. Dekompozicija funkcije 'Naručivanje artikala od dobavljača'

Naručivanje
artikala od
dobavljača

Provjera i odabir
Izrada Prikaz izvješća
artikala čije
dokumenta u procesu
količine su
narudžbenica naručivanja
ispod minimalne

149
1.1.1. Dekompozicija procesa 'Provjera i odabir artikala čije količine su ispod min.'

Provjera i odabir
artikala čije
količine su
ispod minimalne

Prikaz artikala Označavanje Grupiranje

čije količine artikala označenih
su ispod koje treba artikala po
minimalne naručiti dobavljačima

1.1.2. Dekompozicija procesa 'Izrada dokumenta narudžbenica'

Izrada
dokumenta
narudžbenica

Upis novog Izrada nove Upis novog Upis novog

dobavljača narudžbenice za artikla koji se artikla na
u šifrarnik pojedinog naručuje dokument
dobavljača dobavljača i u šifrarnik narudžbenica
artikle koji se artikala
naručuju od tog
dobavljača

1.1.3. Dekompozicija procesa 'Prikaz izvješća u procesu naručivanja'

Prikaz izvješća
u procesu
naručivanja

Prikaz Prikaz
rekapitulacije minimalne i
narudžbi maksimalne
dobavljačima količine

150
1.2. Dekompozicija funkcije 'Zaprimanje artikala u skladište'

Zaprimanje
artikala u
skladište

Zaprimanje
Zaprimanje
artikala iz
artikala od
skladišta
dobavljača
maloprodaje

1.2.1. Dekompozicija procesa 'Zaprimanje artikala od dobavljača'

Zaprimanje
artikala od
dobavljača

Izrada Usporedba Prikaz izvješća

dokumenta primke i u procesu
primka narudžbenice zaprimanja

1.2.1.1. Dekompozicija potprocesa 'Izrada dokumenta primka'

Izrada
dokumenta
primka

Izrada Upis novog Upis

nove primke zaprimljenog artikala na
za odabranog artikla u dokument
dobavljača šifrarnik artikala primka

151
1.2.1.2. Dekompozicija potprocesa 'Usporedba primke i narudžbenice'

Usporedba
primke i
narudžbenice

Za dobavljača sa
Upis broja
primke pretraživanje
narudžbenice
i usporedba
u primku
narudžbenica koje
nisu uspoređene

1.2.1.3. Dekompozicija potprocesa 'Prikaz izvješća u procesu zaprimanja'

Prikaz izvješća
u procesu
zaprimanja

Prikaz Prikaz
rekapitulacije prometa po
primki dobavljačima

1.2.2. Dekompozicija procesa 'Zaprimanje artikala iz skladišta maloprodaje'

Zaprimanje artikala
iz skladišta
maloprodaje

Izrada dokumenta Prikaz

Upis artikala
ulazna međuskladišnica rekapitulacije
na ulaznu
iz odabranog skladište ulaznih
međuskladišnicu
maloprodaje međuskladišnica

152
1.3. Dekompozicija funkcije 'Prodaja artikala u veleprodaji'

Prodaja
artikala u
veleprodaji

Izrada Prikaz izvješća

Izrada cjenika Obavljanje
dokumenta u procesu
veleprodaje inventure
račun prodaje

1.3.1. Dekompozicija procesa 'Izrada cjenika veleprodaje'

Izrada
cjenika
veleprodaje

Formiranje
Ispis
cijene za
cjenika
artikle

1.3.2. Dekompozicija procesa 'Izrada dokumenta račun'

Izrada
dokumenta
račun

Upis novog Izdavanje Unos

Dodjeljivanje
kupca novog računa artikala
rabata za
u šifrarnik sa podacima na dokument
kupca
kupaca o kupcu račun

153
1.3.3. Dekompozicija procesa 'Prikaz izvješća u procesu prodaje'

Prikaz izvješća
u procesu
prodaje

Prikaz
Prikaz Prikaz Prikaz Prikaz
rekapitulacije
rekapitulacije pometa po pometa pometa po
svih dokumenata
računa kupcima skladišta artiklu
skladišta

1.3.4. Dekompozicija procesa 'Obavljanje inventure'

Obavljanje
inventure

Ispis Izrada Generiranje Prikaz

popisne inventurne dokumenta o višku i pregleda
liste liste dokumenta o manjku inventura

1.4. Dekompozicija funkcije 'Izdavanje artikala u skladište maloprodaje'

Izdavanje artikala
u skladište
maloprodaje

Izrada dokumenta Prikaz

Upis artikala
izlazna međuskladišnica rekapitulacije
na izlaznu
za odabrano skladište izlaznih
međuskladišnicu
maloprodaje međuskladišnica

154
Opis funkcija/procesa
Rb. Naziv funkcije/procesa
1. Prikaz artikala čije
količine su ispod
minimalne
2. Označavanje artikala koje
treba naručiti
3. Grupiranje označenih
artikala po dobavljačima
4. Upis novog dobavljača u
šifarnik dobavljača
5. Izrada nove narudžbenice
za pojedinog dobavljača i
artikle koji se naručuju od
tog dobavljača
6. Upis novog artikla koji se
naručuje u šifarnik
artikala
7. Upis novog artikla na
dokument narudžbenica
8. Prikaz rekapitulacije
narudžbi dobavljačima
9. Prikaz minimalne i
maksimalne količine
10. Izrada nove primke za
odabranog dobavljača
11. Upis novog zaprimljenog
artikla u šifarnik artikala
12. Upis artikala na dokument
primka
13. Za dobavljača sa primke
pretraživanje i usporedba
narudžbenica koje nisu
uspoređene
Opis funkcije/procesa
Ova funkcija daje popis svih artikala za pojedino skladište čije
količine su na zadani datum manje ili jednake unaprijed zadanoj
vrijednosti koja predstavlja minimum dozvoljene količine.
Među artiklima koji su kandidati za naručivanje odabiru se oni
koji će se naručiti. Odabrane artikle treba posebno označiti.
Označene artikle treba složiti (grupirati) po dobavljačima jer se
narudžbenica radi posebno za svakog pojedinog dobavljača.
Ako se prvi put naručuje roba od nekog dobavljača treba
podatke o tom novom dobavljaču upisati u registar (šifarnik)
dobavljača i dodijeliti mu šifru dobavljača.
Za svakog dobavljača i sve artikle koji se nabavljaju od tog
dobavljača izrađuje se dokument narudžbenice sa podacima o
dobavljaču (naziv, mjesto, adresa, matični broj), datumu
naručivanja, broju dokumenta i odgovornoj osobi koja je izadila
dokument.
Ako se prvi put naručuje neki artikal od dobavljača treba
podatke o tom novom artiklu upisati u registar (šifarnik) artikala
i dodijeliti mu šifru artikla.
Ako se od dobavljača prvi put naručuje neki artikal onda i njega
treba dodati na postojeću narudžbenicu.
Izvješće koje sadrži popis narudžbenica za pojedinog dobavljača
ispisane redosljedom nastanka. Narudžbenice koje nisu
realizirane kroz neki zadani vremenski peroid posebno su
označene i vrijednost tih narudžbenica ne ulazi u kumulativnu
vrijednost naručenih artikala na ovom izvješću.
Popis artikala sa šifrom i nazivom, te minimalnom i
maksimalnom količinom, na nivou svakog pojedinog skladišta u
poduzeću i na nivou cijelog poduzeća.
Izrađuje se dokument primka kojim se bilježi 'ulazak' artikala
poslanih od dobavljača (na osnovu narudžbenice) u skladište. U
zaglavlje primke se upisuju podaci o dobavljaču, datum
zaprimanja, broj dokumenta i osoba koja je izradila dokument.
Ako je neki artikal prvi put registriran kod zaprimanja treba
podatke o tom novom artiklu upisati u registar (šifarnik) artikala
i dodijeliti mu šifru artikla.
Svi artikli koje je dobavljač poslao zapisuju se u tablicu tzv.
stavki primke i to: šifra i naziv artikla, jedinica mjere,
zaprimljena količina i nabavna cijena.
U nizu narudžbenica koje su poslane dobavljaču a još po njima
nije pristigla roba treba pronaći onu po kojoj je napravljena
primka.
155
Rb. Naziv funkcije/procesa
14. Upis broja narudžbenice u
primku
15. Prikaz rekapitulacije
primki
16. Prikaz prometa po
dobavljačima
17. Izrad dokumenta ulazna
međuskladišnica iz
odabranog skladište
maloprodaje
18. Upis artikala na ulaznu
međuskladišnicu
19. Prikaz rekapitulacije
ulaznih međuskladišnica
20. Formiranje cijene za
artikle
21. Ispis cjenika
22. Upis novog kupca u
šifarnik kupaca
23. Izdavanje novog računa sa
podacima o kupcu
24. Unos artikala na
dokument račun
25. Dodjeljivanje rabata za
kupca
26. Prikaz rekapitulacije
računa
27. Prikaz prometa po
kupcima
28. Prikaz prometa skladišta
29. Prikaz prometa po artiklu
Opis funkcije/procesa
U primku upisati broj narudžbenice i ovu odložiti među
dokumente narudžbenica koje su rješene.
Izvješće koje sadrži popis primki ispisanih redosljedom nastanka
uz prikaz iznosa: ukupna vrijednost primke bez PDV-a, iznos
PDV-a na primci i ukupna vrijednost + iznos PDV-a.
Ovo izvješće pokazuje pregled primki od pojedinog dobavljača
složenih po datumu zaprimanja robe, uz ispis ukupne vrijednost
robe.
Za artikle koji se iz skladišta maloprodaje (područna skladišta)
vraćaju u glavno skladište radi se dokument ulazna
međuskladišnica. Na dokumentu su podaci o izlaznom i podaci o
ulaznom skladištu, datum dokumenta, broju dokumenta i
odgovorna osoba koja je izadila dokument.
U stavke dokumenta ulazna međuskladišnica upisuju se podaci o
artiklu i zaprimljenoj količini artikla.
Ovo izvješće pokazuje pregled svih ulaznih međuskladišnica,
složenih po datumu nastanka dokumenta i podatku iz kojeg
skladišta je došla roba.
Za artikle koji se prodaju treba formirati prodajne cijene u
kojima je ukalkulirana marža tj. zarada.
Cjenik se ispisuje po potrebi, nakon što se promijeni cijena
jednog ili više arikala.
Ako se roba prvi put prodaje nekom kupcu onda podatke o tom
novom kupcu treba upisati u registar (šifarnik) kupaca i dodijeliti
mu šifru kupca.
Izrađuje se novi račun na kojem pišu podaci o kupcu, datum
dokumenta, datum dospjeća valute, broj dokumenta, osoba koja
ga izradi, rabat za kupca i sl.
U stavke računa upisuju se podaci o artiklu, njegovoj količini,
cijeni po kojoj se prodaje ( iznos bez poreza, iznos poreza i
ukupni iznos), ukupnoj cijeni.
Za pojedine artikle koji se prodaju, mogu se unaprijed definirati
minimalni ili maksimalni rabati za kupca.
Ovo izvješće pokazuje pregled svih računa, složenih po datumu
izdavanja računa uz ispis ukupne vrijednost robe bez PDV-a,
vrijednosti PDV-a te vrijednosti robe sa PDV-om.
Ovo izvješće pokazuje pregled računa za pojedinog kupca
složenih po datumu izdavanja računa, uz ispis ukupne vrijednost
robe.
Pregled ulaznih i izlaznih vrijednosti za odabrano skladište, za
sve dobavljače i kupce, za jedan ili sve artikle, u odabranom
vremenskom periodu.
Pregled prometa za jedan artikal, za jedno ili sva skladišta, za
jednog ili sve dobavljače/kupce, u odabranom vremenskom
periodu.
156
Rb. Naziv funkcije/procesa
30. Prikaz rekapitulacije svih
dokumenata skladišta
31. Ispis popisne liste
32. Izrada inventurne liste
33. Generiranje dokumenta o
višku i dokumenta o
manjku
34. Prikaz pregleda inventura
35. Izrada dokumenta izlazna
međuskladišnica za
odabrano skladište
maloprodaje
36. Upis artikala na izlaznu
međuskladišnicu
37. Prikaz rekapitulacije
izlaznih međuskladišnica
Opis funkcije/procesa
Pregled svih dokumenata generiranih za pojedino skladište, za
jednog ili sve dobavljače/kupce, za odabrani vremenski period.
Pregled je poredan po vremenu nastajanja dokumenata.
Izvješće koje se formira za odabrano skladište i sadrži popis svih
artikala u tom skladištu i kolonu za upis stvarne količine koja se
nađe na skladištu prilikom obavljanja inventure.
Inventura je dokument kojim se izjednačavaju količine artikala u
skladištu koje dobivamo kao rezultat poslovanja skladišta (ovdje
se zovu ’knjižene količine’) i količine artikala nađene u skladištu
(’stvarne količine’).
Izjednačavanje 'knjiženih količina' sa inventurne liste i 'stvarnih
količina' nađenih prilikom inventure u skladištu radi se
formiranjem dokumenta o manjku ili višku za svaki artikal kome
nije jednaka knjižena i stvarna količina.
Izvješće koje daje popis inventura složenih po brojevima
inventure sa datumom obavljanja inventure i podacima o
knjiženoj i stvarnoj vrijednosti za cijelu inventuru.
Za artikle koji se iz skladišta veleprodaje (glavno skladište)
izdaju u područna skladišta radi se dokument izlazna
međuskladišnica. Na dokumentu su podaci o izlaznom i podaci o
ulaznom skladištu, datum dokumenta, broju dokumenta i
odgovorna osoba koja je izadila dokument.
U stavke dokumenta izlazna međuskladišnica upisuju se podaci
o artiklu i izdanoj količini artikla.
Ovo izvješće pokazuje pregled svih izlaznih međuskladišnica,
složenih po datumu nastanka dokumenta i podatku u koje
skladište se izdaje roba.
157
 Projekt: Poslovanje trgovine Datum: 20.10.2002
Faza: Analiza poslovnog sustava
Dokument: Određivanje i opis klasa podataka (OPISPOD)
Ime i prezime: Smjer:

Sadržaj

Određivanje osnovnih klasa podataka poslovnog sustava

Opis klasa podataka

Određivanje osnovnih klasa podataka poslovnog sustava

Za procese podsustava veleprodaje može se prepoznati nekoliko osnovnih klasa podataka koje
se koriste u više procesa iste logičke funkcionalnosti. To su:
• artikli
• pravne osobe od kojih se kupuju artikli (dobavljači) i pravne osobe kojima se
prodaju artikli (kupci).
• lokacije na kojima se izdaju dokumenti (skladišta)

Dokumenti koji se ovdje razmatraju ukazuju na sljedeće klase podataka:

• narudžbenica
• primka
• cjenik
• račun
• popisna lista
• inventurna lista
• zapisnik o višku
• zapisnik o manjku
• ulazna međuskladišnica
• izlazna međuskladišnica.

Već se sada može pretpostaviti, a i kasnija detaljna analiza podataka će pokazati da se skup
osnovnih klasa podataka koji se ponavljaju u više procesa (artikli, dobavljači, kupci, te
lokacije) definiraju kao osnovni šifarnici.

158
Opis klasa podataka

Rb. Naziv klase podataka Opis klase podataka

1. ARTIKAL Podaci o artiklu koji se zaprima u skladište i prodaje.
2. DOBAVLJAČ Podaci o dobavljačima od kojih se naručuju i kupuju artikli.
3. KUPAC Podaci o kupcima kojima se prodaju artkli.
4. NARUDŽBENICA Dokument kojim se naručuju artikli od dobavljača.
5. LOKACIJA Mjesto nastanka dokumenta. Važno za međuskladišnice i
inventuru, te za račune.
6. PRIMKA Dokument kojim se artikli pristigli od dobavljača zaprimaju u
skladište.
7. CJENIK Popis artikala i cijena po kojima se prodaju na zadani datum.
8. RAČUN Dokument na kojem je popis artikala koji se prodaju kupcu.
9. POPISNA LISTA Dokument na kojem je popis artikala sa količinama artikala
koje se vode kroz dokumente, a koja se lista prije utvrđivanja
stvarnog stanja skladištu.
10. INVENTURNA LISTA Dokument na kojem je popis artikala sa količinama artikala
koje se vode kroz dokumente i stvarnim količinama
pronađenim u skladištu.
11. ZAPISNIK O VIŠKU Dokument koji nastaje kao pisani trag o pronađenim viškovima
artikala nakon inventure.
12. ZAPISNIK O MANJKU Dokument koji nastaje kao pisani trag o pronađenim
manjkovima artikala nakon inventure.
13. ULAZNA Dokument kojim se artikli vraćeni iz skladišta maloprodaje
MEĐUSKLADIŠNICA ponovno zaprimaju u skladište veleprodaje.
14. IZLAZNA Dokument kojim se artikli izdaju u drugo skladište (skladište
MEĐUSKLADIŠNICA maloprodaje).

159
 Projekt: Poslovanje trgovine Datum: 20.10.2002
Faza: Analiza poslovnog sustava
Dokument: Matrica poslovne tehnologije (MPT)
Ime i prezime: Smjer:

Sadržaj

Osnovna matrica poslovne tehnologije

Dijagonalizirana matrica poslovne tehnologije

Matrica poslovne tehnologije prikazuje redosljed odvijanja procesa u poslovnom sustavu i

aktivnosti tih procesa nad entitetima.
Matrica poslovne tehnologije podsustava “Poslovanje veleprodaje” ima dva procesa (br. 6. i
br. 11.) koji upisuju novi artikal u šifarnik artikala. U poslovanju veleprodaje dodavanje
novog artikla u šifarnik artikala može se dogoditi u procesu naručivanja robe od dobavljača i
u procesu zaprimanja robe u skladište.
U dijagonaliziranoj matrici koja predstavlja arhitekturu budućeg informacijskog podsustava
ova dva procesa su objedinjena u jedan i stavljena na početak matrice. Dijagonalizirana
matrica je podijeljenja u 3 submatrice: osnovni šifarnici vezani uz veleprodaju, veleprodaja i
inventura. Može se napraviti podjela i u 2 submatrice: osnovni šifarnici i veleprodaja, tako da
je u ovu drugu uključena i inventura te je broj entiteta izvan podsustava koje koriste procesi
podsustava manji.
Entitet LOKACIJA nastaje izvan podsustava “Poslovanje veleprodaje” (kreira se na nivou
poduzeća). U podsustavu “Poslovanje veleprodaje” ovaj entitet se samo čita. Takvih entiteta
ima još, poput POŠTE, NASELJA, VALUTE, DJELATNOSTI itd. Oni nisu navedeni uz ovaj
podsustav, iako se se u praksi koriste u informacijskom sustavu. Entiteti koji se koriste u
cijelom sustavu, a nastaju izvan sustava (ponekad se u potpunosti preuzimaju od drugih
institucija) ili u samom sustavu, u nekom njegovom dijelu, često se nazivaju matičnim
šifarnicima ili matičnim podacima.

160
Osnovna matrica poslovne tehnologije

ZAPISNIK O VIŠKU
NARUDŽBENICA

POPISNA LISTA
Entiteti

INVENTURNA
DOBAVLJAČ

ZAPISNIK O

MEĐUSKL.

MEĐUSKL.
LOKACIJA
ARTIKAL

IZLAZNA
MANJKU

ULAZNA
PRIMKA

CJENIK

RAČUN
KUPAC

LISTA
Procesi
1. Prikaz artik. čije količine su ispod minimalne R R
2. Označavanje artikala koje treba naručiti U
3. Grupiranje označenih artik. po dobavljačima R R
4. Upis novog dobavljača u šifarnik dobavljača C
5. Izrada nove narudž. za pojedinog dobavljača ... R R C
6. Upis novog artikla koji se naručuje u šifarnik … C
7. Upis novog artikla na dok. narudžbenica R U
8. Prikaz rekapitulacije narudžbi dobavljačima R R
9. Prikaz minimalne i maksimalne količine R R
10. Izrada nove primke za odabranog dobavljača R R C
11. Upis novog zaprimljenog artikla u šifarnik … C
12. Upis artikala na dokument primka R U
13. Za dobav. sa primke pretraživanje narudž. … R R
14. Upis broja narudžbenice u primku R R U
15. Prikaz rekapitulacije primki R R R
16. Prikaz prometa po dobavljačima R R R R R
17. Izrada dokumenta ulazna međuskladišnica … R C
18. Upis artikala na ulaznu međuskladišnicu R U
19. Prikaz rekapitulacije ulaznih međuskladišn. R R
20. Formiranje cijene za artikle R R C
21. Ispis cjenika R
22. Upis novog kupca u šifarnik kupaca C
23. Izdavanje novog računa sa podacima o kupcu R R C
24. Unos artikala na dokument račun R U
25. Dodjeljivanje rabata za kupca R R U
26. Prikaz rekapitulacije računa R R
27. Prikaz prometa po kupcima R R R
28. Prikaz prometa skladišta R R R R R
29. Prikaz prometa po artiklu R R R R R R
30. Prikaz rekapitulacije svih dokum. skladišta R R R R R R R
31. Ispis popisne liste R R C
32. Izrada inventurne liste R R R C R R
33. Generiranje dok. o višku i dok. o manjku R R R C C
34. Prikaz pregleda inventura R R
35. Izrad dokumenta izlazna međuskladišnica … R C
36. Upis artikala na izlaznu međuskladišnicu R U
37. Prikaz rekapitulacije izlaznih međuskladišn. R R

161
Dijagonalizirana matrica poslovne tehnologije

NARUDŽBENICA
Entiteti

POPISNA LISTA
INVENTURNA
DOBAVLJAČ

ZAPISNIK O

ZAPISNIK O
MEĐUSKL.

MEĐUSKL.

LOKACIJA
ARTIKAL

IZLAZNA

MANJKU
ULAZNA
PRIMKA

CJENIK

RAČUN
KUPAC

VIŠKU
LISTA
Procesi
6. i 11. Upis novog artikla u šifarnik artikala C
1. Prikaz artik. čije količine su ispod minimalne R R
2. Označavanje artikala koje treba naručiti U
9. Prikaz minimalne i maksimalne količine R R
4. Upis novog dobavljača u šifarnik dobavljača C
3. Grupiranje označenih artik. po dobavljačima R R
22. Upis novog kupca u šifarnik kupaca C
5. Izrada nove narudž. za pojedinog dobavljača ... R R C
7. Upis novog artikla na dok. narudžbenica R U
8. Prikaz rekapitulacije narudžbi dobavljačima R R
10. Izrada nove primke za odabranog dobavljača R C R
12. Upis artikala na dokument primka R U R
13. Za dobav. sa primke pretraživanje narudž. … R R
14. Upis broja narudžbenice u primku R U R
15. Prikaz rekapitulacije primki R R R
16. Prikaz prometa po dobavljačima R R R R R
17. Izrada dokumenta ulazna međuskladišnica … C R
18. Upis artikala na ulaznu međuskladišnicu R U
19. Prikaz rekapitulacije ulaznih međuskladišn. R R
20. Formiranje cijene za artikle R R C
21. Ispis cjenika R
23. Izdavanje novog računa sa podacima o kupcu R C R
24. Unos artikala na dokument račun R U
25. Dodjeljivanje rabata za kupca R R U
26. Prikaz rekapitulacije računa R R
27. Prikaz prometa po kupcima R R R
35. Izrad dokumenta izlazna međuskladišnica … C R
36. Upis artikala na izlaznu međuskladišnicu R U R
37. Prikaz rekapitulacije izlaznih međuskladišn. R R
28. Prikaz prometa skladišta R R R R R
29. Prikaz prometa po artiklu R R R R R R
30. Prikaz rekapitulacije svih dokum. skladišta R R R R R R R
31. Ispis popisne liste R C R
32. Izrada inventurne liste R R R R C R
33. Generiranje dok. o višku i dok. o manjku R R C C R
34. Prikaz pregleda inventura R R

162
 Projekt: Poslovanje trgovine Datum: 24.10.2002
Faza: Analiza poslovnog sustava
Dokument: Lista korisničkih zahtjeva (ZAHTJEVI)
Ime i prezime: Smjer:

Lista korisničkih zahtjeva

Rb. KORISNIK ZAHTJEV RJEŠENJE

1.
Rukovods Osigurati jedinstveni šifarnik artikala
tvo
dostupan svima (nabavi, veleprodaji i
maloprodaji).
2.
Rukovods Osigurati jedinstveni šifarnik kupaca i
tvo
dobavljača (partneri) dostupan svim
lokacijama.
3.
Direktor Omogućiti definiranje svakog pojedinog
korisnika informacijskog sustava unutar tog
sustava. Svakom korisniku dodijeliti prava
na nivou: čitanje, izmjena, dodavanje i
brisanje podataka.
Direktor Za sve artikle u sustavu omogućiti
4. prodaje
definiranje podataka o minimalnim
količinama na svakom pojedinom skladištu
i na nivou cijelog poduzeća. Kod nabave
novih artikala omogućiti listu svih artikala
čije količine su pale ispod minimalnih na
nivou poduzeća, a kod prodaje iz skladišta i
trgovina signalizirati one artikle koji su u
skladištu ili trgovini količinom pali ispod
minimuma u tom skladištu.
Treba definirati unosnu masku koja će
omogućiti unos, ažuriranje, brisanje i pregled
artikala. Ovaj šifrarnik mogu koristiti svi
korisnici informacijskog sustava kojima je to
pravo dodijeljeno. Podaci o artiklima se
nalaze na jednom mjestu u bazi podataka te
je svaka izmjena nad podacima vidljiva i
dostupna svima.
Definirati unosnu masku za unos, ažuriranje,
brisanje i pregled podataka o partneru. Ovaj
šifarnik mogu koristiti svi korisnici
informacijskog sustava kojima je to pravo
dodijeljeno. Podaci o partnerima se nalaze na
jednom mjestu u bazi podataka te je svaka
izmjena nad podacima vidljiva i dostupna
svima.
Treba definirati šifarnik korisnika i pridijeliti
mu sljedeće podatke: ime, prezime,
organizacijsku jedinicu u kojoj radi, šifru
pristupa informacijskom sustavu. Osim ovih
podataka još treba definirati i podatke tipa:
može čitati određenu tablicu u bazi, može
unositi/mijenjati/brisati podatke iz određene
tablice u bazi i ime jedne ili više tablica na
koju se odnose prava.
U šifarniku artikala iz zahtjeva 1. dodati
podatak minimalna količina na nivou
trgovine. Osim ovih osnovnih podataka o
artiklima na nivou poduzeća, treba u bazi
podataka definirati posebnu tablicu u kojoj
će biti podaci o artiklima u pojedinom
skladištu. Napraviti izvješće 'Količine ispod
minimuma' koje će na određeni datum davati
popis artikala u jednom ili svim skladištima
čije količine su pale ispod minimuma.
U prodaji (generiranje računa za kupca) kod
odabira artikla na stavci računa treba
dodatno označiti one artikle čije količine su
pale ispod minimuma, ili prodajom postaju
manje od minimuma.

163
Rb. KORISNIK ZAHTJEV RJEŠENJE
Direktor Omogućiti definiranje dokumenata za Za svaki navedeni dokument izraditi masku
5. veleprod.
nabavljanje, zaprimanje i prodaju artikala u za unos podataka. Za sve dokumente treba
skladištu veleprodaje. osigurati mogućnost unošenja, izmjene i
brisanja (ako je dokument nepotvrđen) stavki
artikala na tom dokumentu.
6.
Direktor U svakom skladištu osigurati definiranje i Izraditi odgovarajući program za ispis
prodaje cjenika na dan.
ispis cjenika na dan.
7.
Direktor Omogućiti ispis svakog pojedinog Izraditi odgovarajuće programe za svaki
veleprod. pojedini dokument.
dokumenta (narudžbenice, primke, računa,
…) sa zaglavljem i stavkama artikala,
podacima o operateru i vremenu ispisa i
kreiranja dokumenta.
8.
Rukovods Omogućiti vođenje dokumenata ulaznih i Izraditi odgovarajuće programe.
tvo
izlaznih međuskladišnica na način da se
prilikom kreiranja izlazne međuskladišnice
u jednom (izlaznom) skladištu automatski
generira ulazna međuskladišnica u drugom
(ulaznom) skladištu.
9.
Rukovods Dokumente ulazne i izlazne Izraditi odgovarajuće programe.
tvo
međuskladišnice treba moći ispisati a
moraju sadržavati zaglavlje i stavke sa
artiklima, podatke o operateru i vremenu
ispisa i kreiranja dokumenta.
10.
Direktor Osigurati pregled tzv. Rekapitulaciju Izraditi odgovarajući program za ispis
veleprod. rekapitulacije.
narudžbi dobavljačima, s tim da se mogu
posebno dobiti nerealizirane narudžbenice.
11.
Direktor Omogućiti Rekapitulacije primki i računa Izraditi odgovarajući program za ispis
veleprod. rekapitulacije.
po brojevima dokumenata ili za odabrane
vremenske intervale za jednog ili sve
partnere.
12.
Direktor Pri izradi primke obavezno se mora upisati Programski uvjetovati obavezan upis broja
veleprod. narudžbenice.
broj narudžbenice, kako bi se znalo koja je
nabava realizirana.
13.
Direktor Omogućiti automatsku usporedbu sadržaja Izraditi odgovarajući program.
veleprod.
(stavki) primke i narudžbenice i
povezivanje (anuliranje) onih koje su
istovjetne u svom sadržaju.
14.
Rukovods Omogućiti izvješća Promet po kupcu, Izraditi odgovarajuće programe za ispis
tvo izvješća.
Promet skladišta i Promet po artiklima za
jedno ili za sva skladišta.
15.
Rukovods Osigurati efikasan popis artikala na kraju Izraditi odgovarajući program za ispis.
tvo
godine ili bilo kada tokom godine
(inventura).
16.
Rukovods Omogućiti da se po unosu podataka sa Programski pri unosu podataka kalkulirati
tvo višak odnosno manjak. Ako se pojavi višak
inventurne liste automatski generiraju
dokumenti Višak i Manjak. automastki se generira dokument Višak, a za
manjak dokument Manjak.

164
 Projekt: Poslovanje trgovine Datum: 24.10.2002
Faza: Analiza poslovnog sustava
Dokument: Dijagram tijeka podataka (DTP)
Ime i prezime: Smjer:

Sadržaj

Kontekst dijagram - Dijagram tijeka podataka nivoa 0 (DTP-0)

Dijagrami tijeka podataka nižih nivoa (DTP)

Kontekst dijagram

- nivo 0: Poslovanje veleprodaje

izlazna
Dobavljač
narudžbenica međuskladišnica Skladište
maloprodaje

dokument od izlazna
dobavljača međuskladišnica

Poslovanje
veleprodaje Šef
popisna lista
cjenik veleprodaje

Komisija inventurna
lista
popunjena
popisna lista račun
Kupac
Šef
veleprodaje

165
Dijagrami tijeka podataka nižih nivoa

- nivo 1: Poslovanje veleprodaje

Dobavljač
dokument do izlazna
dobavljača međuskladišnica

narudžbenica
2. Zaprimanje Skladište
Dobavljač
artikala u maloprodaje
1. Naručivanje naziv, mjesto,
skladište šifra
artikala od adresa, mat. broj lokacije
dobavljača
izlazna
međuskladišnica
Lokacija šifra
količina
lokacije
Artikal
šifra, naziv,
količina

4. Izdavanje
Komisija količina artikala u
Kupac
skladište
maloprodaje
naziv, mjesto,
popisna lista adresa, mat. broj
3. Prodaja količina
Artikal
artikala u
veleprodaji
inventurna cjenik
lista

račun
Šef
Šef
veleprodaje
veleprodaje
Kupac

166
- nivo 2: 1. Naručivanje artikala od dobavljača

Skladištar
Skladištar

popis količina na skladištu, količina na skladištu,

artikala minimalna količina minimalna količina, rekapitulacija
maksimalna količina narudžbenica
1.1. Provjera i
oznaka za
narudžbu odabir artikala čije
Artikal
količine su ispod
1.3. Prikaz
minimalne
oznaka za izvješća
narudžbu u procesu
naručivanja

šifra i narudžbenica rekapitulacija

Dobavljač naziv artikla narudžbenica

Narudžbenica
šifra i naziv popis artikala,
1.2. Izrada
dobavljača min. i maksim.
dokumenta narudžbenica količina
narudžbenica
Šef
veleprodaje
odabir
dobavljača
i artikala narudžbenica
Skladištar Dobavljač

- nivo 3: 1.1. Provjera i odabir artikala čije količine su ispod minimalne

Skladištar
popis oznaka za
artikala narudžbu

1.1.1. Prikaz
1.1.2. Označavanje
artikala čije
artikala koje
količine su ispod oznaka za treba naručiti
minimalne narudžbu

količina na skladištu,
minimalna količina
Artikal
šifra i
naziv artikla
Dobavljač
pregled dobavljača 1.1.3. Grupiranje
i artikala označenih šifra i naziv
Skladištar dobavljača
artikala po
dobavljačima

167
- nivo 3: 1.2. Izrada dokumenta narudžbenica

Skladištar Dobavljač
narudžbenica
šifra i naziv
dobavljača
1.2.2. Izrada nove
1.2.1. Upis novog odabir dobavljača
narudžbenice za
dobavljača i artikala
dobavljača i artikle
u šifrarnik narudžbenica
koji se naručuju
dobavljača
od tog dobavljača
šifra i naziv
dobavljača
šifra i naziv šifra i naziv Narudžbenica
dobavljača dobavljača
Dobavljač
šifra i
naziv artikla

Artikal

1.2.3. Upis novog šifra i

1.2.4. Upis novog
šifra i
artikla naziv artikla naziv artikla artikla na
koji se naručuje narudžbenicu
u šifrarnik obavljača
šifra i
naziv artikla odabir artikla
Skladištar

- nivo 3: 1.3. Prikaz izvješća u procesu naručivanja

1.3.1. Prikaz popis artikala, min.

minimalne i i maksim. količina Šef
maksimalne veleprodaje
količine

rekapitulacija
količina na skladištu, narudžbenica
minimalna količina,
maksimalna količina

Artikal 1.3.2. Prikaz

narudžbenica rekapitulacije
Narudžbenica
narudžbi
dobavljačima

rekapitulacija
narudžbenica
Skladištar

168
- nivo 2: 2. Zaprimanje artikala u skladište

izlazna
međuskladišnica Skladište
Dobavljač
maloprodaje
dokument od
dobavljača
2.2. Zaprimanje
artikala iz šifra
2.1. Zaprimanje skladišta lokacije
Lokacija
artikala od maloprodaje
dobavljača
ulazna
količina međuskladišnica
primka
Ulazna
količina međuskladišnica
Primka Artikal

- nivo 3: 2.1. Zaprimanje artikala od dobavljača (vidi zadatak 1.a) )

- nivo 4: 2.1.1. Izrada dokumenta primka (vidi zadatak 1.b) )
- nivo 4: 2.1.2. Usporedba primke i narudžbenice (vidi zadatak 1.c) )
- nivo 4: 2.1.3. Prikaz izvješća u procesu zaprimanja (vidi zadatak 1.d) )

- nivo 3: 2.2. Zaprimanje artikala iz skladišta maloprodaje

Skladište
Skladištar
maloprodaje šifra i naziv
artikla
izlazna
međuskladišnica
2.2.2. Upis
artikala na
2.2.1. Izrada dok. šifra i naziv ulaznu
šifra
ulazna lokacije artikla međuskladišnicu
međuskladišnica
iz odabranog
količina rekapitulacija
skladište maloprodaje Artikal ulaznih
međuskladišnica

šifra šifra i naziv

lokacije artikla
šifra ulazna 2.2.3. Prikaz
lokacije Ulazna međuskladišnica rekapitulacije
Lokacija međuskladišnica ulaznih
međuskladišnica

Šef
veleprodaje rekapitulacija ulaznih
međuskladišnica

169
- nivo 2: 3. Prodaja artikala u veleprodaji

Skladištar

pregledi i
izvješća Primka
primka
Šef primka
veleprodaje pregledi i izvješća
Ulazna
međuskladišnica
ulazna međuskl.
cjenik
Artikal ulazna
međuskl.
3.3. Prikaz izlazna međuskl.
šifra i
naziv artikla
izvješća u
3.1. Izrada
procesu prodaje
cjenika
zap. o manjku
veleprodaje Izlazna
međuskladišnica
šifra i
naziv artikla račun
šifra i
cijena
naziv artikla Zapisnik izlazna
Kupac zap. o višku međuskl.
o manjku
Cjenik šifra i
naziv kupca zap. o manjku
šifra i
Zapisnik
cijena naziv artikla
o višku
3.2. Izrada
dokumenta šifra i zap. o višku
račun naziv kupca 3.4. Obavljanje
račun Račun
račun
inventure

račun
inventurna lista popisna
Kupac
lista
odabir kupca
i artikala ispunjena
popisna lista
Šef
Komisija
Skadištar veleprodaje

170
- nivo 3: 3.1. Izrada cjenika veleprodaje

Šef
cijena veleprodaje
Skladištar
cjenik
cjenik

3.1.1. Formiranje
cijene za artikle šifra i naziv 3.1.2. Ispis
artikla cjenika

šifra i naziv cijena Cjenik

artikla
cjenik
Artikal

- nivo 3: 3.2. Izrada dokumenta račun

Kupac Kupac

šifra i naziv Šef

kupca
račun veleprodaje

3.2.1. Izdavanje
novog računa račun rabat
sa podacima
o kupcu šifra i naziv
kupca
šifra i naziv 3.2.3. Dodjeljivanje
kupca rabat
Račun rabata
šifra i naziv
artikla za kupca
Skladištar
šifra i naziv
Artikal
količina kupca
šifra i naziv
artikla
Kupac
šifra i naziv
3.2.2. Unos
artikla
artikala
na račun

171
- nivo 3: 3.3. Prikaz izvješća u procesu prodaje

Zapisnik
Šef
o manjku
Ulazna zap. o manjku veleprodaje
međuskladišnica
Zapisnik
ulazna o višku promet po
zap. o višku
međuskl. artiklu

rekapit. svih
dokumentata Primka
skladišta
3.3.5. Prikaz primka Skladištar
rekapitulacije primka
rekapit. svih svih dokumenata
dokumentata skladišta
skladišta Račun

promet po
račun račun 3.3.4. Prikaz
izlazna artiklu
Šef međuskl.
pometa po
veleprodaje artiklu

Izlazna izlazna međuskl.

međuskladišnica šifra i naziv
promet artikla
skladišta izlazna ulazna
međuskl. Ulazna međuskl.
Artikal
međuskladišnica

promet ulazna
skladišta 3.3.3. Prikaz Kupac
međuskl.
Skladištar pometa šifra i naziv
promet po
skladišta kupca
kupcima
Račun

račun 3.3.2.. Prikaz

primka račun prometa po
Primka
kupcima

rekapitulacija promet po
3.3.1. Prikaz račun Šef
računa kupcima
rekapitulacije veleprodaje
računa
rekapitulacija
računa

172
- nivo 3: 3.4. Obavljanje inventure

Popisna lista
Komisija lokacija
Lokacija
popisna popisna
lista lista šifra i naziv
artikla
lokacija 3.4.4. Prikaz
pregleda pregled
3.4.1. Ispis inventura inventura
ispunjena
popisna lista
popisne
šifra i naziv
liste artikla
inventura Šef
lokacija generiranje veleprodaje
Šef Artikal višak količine
veleprodaje
Lokacija Inventura 3.4.3. Generiranje
zap. o manjku
dok. o višku i
manjak količine dok. o manjku
Zapisnik
inventurna inventura o manjku
lista
3.4.2. Izrada zap. o viš
inventurne ku Zapisnik
izlazna
liste međuskl. o višku
primka
ulazna Izlazna količina
međuskl. međuskladišnica
račun
Primka Artikal
Ulazna
Račun
međuskladišnica

- nivo 2: 4. Izdavanje artikala u skladište maloprodaje (vidi zadatak 1.e) )

173
 Projekt: Poslovanje trgovine Datum: 26.10.2002
Faza: Analiza poslovnog sustava
Dokument: Radni dijagram (RADD)
Ime i prezime: Smjer:

Sadržaj
Naručivanje artikala
Zaprimanje artikala
Generiranje dokumenta o višku i manjku

Naručivanje artikala
U područnom skladištu periodično se formira dokument zahtjevnica za nabavku artikala koji se
šalje u centralno skladište. Oni artikli kojih ima u dovoljnim količinama šalju se iz centralnog u
područno skladište a za one kojih nema radi se narudžbenica. Na narudžbenicu se stavljaju i ostali
artikli čija količina je u centralnom skladištu manja od minimalne. Ako ima potrebe za
naručivanjem artikla po prvi put onda se i on stavlja na narudžbenicu poznatog dobavljača ili se
narudžbenica radi prvi put za novog dobavljača.

Početak
Zahtjev za
nabavku atrikala

Listanje artikala koje

treba naručiti (1)

Je li Stavljanje artikla
količina na skladištu Da na izlaznu
dovoljna? međuskladišnicu

Ne

Da Je li količina
na skladištu ispod
minimalne?

Da

Obilježavanje
Ne artikla

Ima li još
artikala na popisu
(1)?

Ne

174
 A

Listanje ostalih
artikala u centralnom
skladištu (2)

Je li količina
na skladištu ispod
minimalne?

Da
Da

Obilježavanje
Ne artikla

Ima li još
artikala na popisu
(2)?

Da li
naručiti novi Ne
artikal?

Da
Grupiranje
obilježenih artikala
po dobavljačima
Da li postoji
dobavljač?
Listanje
Ne dobavljača (3)

Unos novog
Da dobavljača

Izrada narudžbenice
za dobavljača

Upis novog artikla

Izrada stavke
Da Da
narudžbenice za
Obilježavanje artikle zadanog
novog artikla dobavljača

Ima li
još artikala za
dobavljača?

Ne

Ima li još
dobavljača na listi
(3)?

Kraj

175
Zaprimanje artikala
Dobavljač šalje robu i dokument na kome je popis artikala koje dostavlja. Na dokumentu od
dobavljača su podaci o dobavljaču, podaci o naručitelju, popis, količina i cijena artikala i broj
narudžbenice od naručitelja na osnovu koje se dostavlja roba. Za pristigle artikle se radi dokument
primka sa popisom svih zaprimljenih artikala. Na primku se upiše i broj narudžbenice sa
dokumenta od dobavljača.

Početak
Dokument od
dobavljača

Izrada primke za
dobavljača

Izrada stavke
primke za artikle
zadanog dobavljača

Da

Da li je
na dokumentu od
dobavljača novi
Da Upis novog artikla
artikal?

Ne

Ima li još
artikala na dokumentu
od dobavljača?

Ne

Pretraživanje
neuspoređenih
narudžbenica od
dobavljača

Je li Upis broja
pronađena narudžbenica Da narudžbenice u
s brojem? primku

Ne

Kraj
Usporedba svih
neuspoređenih
narudžbenica sa
primkom

176
Generiranje dokumenta o višku i manjku
Popunjena inventurna lista za sve artikle u skladištu zu stvarnu količinu ima i količinu artikla
nađenu prilikom obavljanja inventure. Ako postoji artikal za koji vrijedi stvarna količina - nađena
količina < 0, onda se formira dokument o višku. Ako je stvarna količina - nađena količina > 0, onda
se formira dokument o manjku.

Početak

Pregled sadržaja
inventurne liste

Ima li na
Izrada dokumenta
listi artikala sa Da
manjakom? o manjku

Ne

Ima li na
Izrada dokumenta
listi artikala sa Da
viškom? o višku

Ne
Inventurna lista

Listanje artikala
sa inventurne
liste (1)

stvarna kol. <

Da
Upis artikla i viška u
nađena kol. dokument o višku

Ne
Da

stvarna kol. > Upis artikla i manjka u

Da
nađena kol. dokument o manjku

Ne

Ima li još
artikala na listi
(1)?

Ne

Kraj

177
 Projekt: Poslovanje trgovine Datum: 28.10.2002
Faza: Analiza poslovnog sustava
Dokument: Maske za unos (MASKA)
Ime i prezime: Smjer:

Sadržaj

Maske za unos
Narudžbenica (primjer)

Narudžbenica

Maska za unos zaglavlja dokumenta narudžbenica:

178
Maska za artikle na narudžbenici:

179
 Projekt: Poslovanje trgovine Datum: 29.10.2002
Faza: Analiza poslovnog sustava
Dokument: Izvjesca (IZVJESCE)
Ime i prezime: Smjer:

Sadržaj

Izvješća
Promet skladišta (primjer)

Promet skladišta

“VE-MA” d.o.o. 04.03.2001

Južna ulica 10, SPLIT

Promet skladišta
po ulaznim i izlaznim dokumentima
od datuma 01.02.2001. do datuma 28.02.2001.

Skladište: 003 Glavno skladište

Početno stanje po nabavnim cijenama: 5.000,00
Datum Po nabavnim cijenama Po prodajnim cijenama
dokumenta Dokument Ulaz Izlaz Saldo Izlaz
01.02.1997. PR / 00054 2.500,00 7.500,00
02.02.1997. RN / 00008 100,00 7.400,00 120,00
05.02.1997. IM / 00012 40,00 7.360,00
05.02.1997. RN / 00047 1.000,00 6.360,00 1.200,00
10.02.1997. PR / 00055 5.500,00 11.860,00
11.02.1997. RN / 00015 500,00 11.360,00 610,00
15.02.1997. UM / 00007 700,00 12.060,00
21.02.1997. UM / 00005 150,00 12.210,00
27.02.1997. RN / 00002 60,00 12.150,00 75,00

UKUPNO: 8.850,00 1.700,00 12.150,00 2.005,00

180
7.3. Zadaci za vježbu
ZADATAK 1:
Izraditi dijagram toka podataka (DTP) za prethodni primjer seminarskog rada za:
a) nivo 3: 2.1. Zaprimanje artikala od dobavljača
b) nivo 4: 2.1.1. Izrada dokumenta primka
c) nivo 4: 2.1.2. Usporedba primke i narudžbenice
d) nivo 4: 2.1.3. Prikaz izvješća u procesu zaprimanja
e) nivo 2: 4. Izdavanje artikala u skladište maloprodaje

Rješenje:

a) nivo 3: 2.1. Zaprimanje artikala od dobavljača

Narudžbenica
Dobavljač Skladištar
Dobavljač
neuspoređene broj
šifra i naziv narudžbenice
dobavljača narudžbenice
dokument do
dobavljača
2.1.2. Usporedba
rekapitulacija
primke i primki
2.1.1. Izrada narudžbenice
dokumenta
primka primka

broj
narudžbenice
odabir rekapitulacija
dobavljača šifra i naziv Primka primki
i artikala artikla
Šef
2.1.3. Prikaz
primka
veleprodaje
izvješća u
Skladištar Artikal
procesu
zaprimanja
promet po
dobavljačima

b) nivo 4: 2.1.1. Izrada dokumenta primka

Dobavljač
Dobavljač šifra i naziv Skladištar
šifra i naziv artikla
dobavljača
dokument do
dobavljača
2.1.1.2. Upis
2.1.1.1. Izrada novog zaprimljenog
nove primke artikla u šifrarnik
za odabranog šifra i naziv artikala
dobavljača dobavljača

šifra i naziv
dobavljača Primka šifra i naziv
artikla
šifra i naziv
Skladištar artikla
Artikal
šifra i naziv količina
artikla
2.1.1.3. Upis šifra i naziv
artikala na artikla
dokument
primka

181
c) nivo 4: 2.1.2. Usporedba primke i narudžbenice

odabir
narudžbenice
2.1.2.1. Za dobavljača
sa primke pretraži-
vanje i usporedba Skladištar
šifra i naziv narudžbenica koje
dobavljača nisu uspoređene broj
narudžbenice
neuspoređene
narudžbenice
Primka 2.1.2.2. Upis
narudžbenica broja
Narudžbenica
narudžbenice
u primku
broj narudžbenice

d) nivo 4: 2.1.3. Prikaz izvješća u procesu zaprimanja

Dobavljač
šifra i naziv
dobavljača
Skladištar
Primka
primka
primka 2.1.6. Prikaz
rekapitulacija prometa po
primki dobavljačima

2.1.5. Prikaz
rekapitulacija promet po
rekapitulacije primki dobavljačima
primki Šef
veleprodaje

e) nivo 2: 4. Izdavanje artikala u skladište maloprodaje

Skladište rekapitulacija
Skladištar
maloprodaje šifra i naziv izlaznih međuskl.
izlazna artikla
međuskladišnica
4.2. Upis
šifra i naziv
4.1. Izrada dok. šifra artikla
artikala na
izlazna lokacije izlaznu
međuskladišnica količina međuskladišnicu
za odabrano
skladište šifra i naziv
Artikal
artikla
maloprodaje
izlazna
međuskl. 4.3. Prikaz
šifra šifra izlazna rekapitulacije
lokacije međuskladišnica
lokacije Izlazna izlaznih
međuskladišnica Šef međuskladišnica
veleprodaje rekapitulacija
Lokacija izlaznih međuskl.

182
ZADATAK 2:
Izraditi radni dijagram (RADD) za prethodni primjer seminarskog rada za:
b) Izdavanje u područno skladište
a) Izrada cjenika veleprodaje

Rješenje:

a) Izdavanje u područno skladište

Početak
Zahtjev za izdavanje
artikala u područno
skladište

Odabir lokacije
(područno skladište)

Izrada izlazne
međuskladišnice

Da Izrada stavke
artikala za izlaznu
međuskladišnicu

Još
artikala za izlaznu
međuskl.?

Ne

Izlazna
Ispis izlazne
međuskladišnica
međuskladišnice

Kraj

183
b) Izrada cjenika veleprodaje

Početak
Zahtjev za
formiranje cjenika

Da li
već postoji Ne
cjenik?

Da

Listanje artikala Listanje artikala iz

iz cjenika (1) popisa artikala (2)

Izmjena
postojeće Odabir nabavne
cijene?
cijene za artikal
Da
Da
Da
Upis nove cijene velep. cijena =
Ne za artikal u cjenik nab. cijena + marža

Upis artikla i
velep. cijene u
Ima li još cjenik
artikala (1)?

Ne Ima li još
artikala (2)?

Ne
Dodavanje
novog artikla u Ne
cjenik?

Da

Odabir artikla i
nabavne cijene Ispis cjenika Cjenik

velep. cijena =
nab. cijena + marža
Kraj

Upis artikla i
velep. cijene u
cjenik

184
ZADATAK 3:
Za prethodni primjer seminarskog rada skicirati unosnu masku za Cjenik.

Rješenje:

ZADATAK 4:
Za prethodni primjer seminarskog rada skicirati izgled izvješća Šifarnik artikala.

Rješenje:

“VE-MA” d.o.o. 04.03.2003

Južna ulica 10, SPLIT

Popis artikala

Rb. Šifra Naziv JM Minim. kol. Maksim. kol.

za poduzeće za poduzeće
1. C-001 PLASTIČNE CIJEVI ZA VODOVOD - FI 20 m 3000 20000
2. C-002 PLASTIČNE CIJEVI ZA VODOVOD - FI 25 m 3000 20000
3. C-005 PLASTIČNE CIJEVI ZA VODOVOD - FI 35 m 4000 20000
4. C-035 PLASTIČNE CIJEVI ZA KANALIZACIJU m 2500 20000
5. O-067 PODNE OBLOGE U ROLI - PVC m2 5000 18000
6. O-109 PODNE OBLOGE U ROLI - TEPISON m2 5000 18000
7. O-178 PODNE OBLOGE U ROLI - PLATNO m2 5000 22000
8. L-0011 LAMINAT - II klasa - orah m2 1000 5000
9. L-0023 LAMINAT - II klasa - javor m2 1000 5000
10. L-0023 LAMINAT - I klasa - hrast m2 2000 7000

185
Literatura

1. Barker, R.: CASE*METHOD Tasks and Deliverables, Addison-Wesley Publishing Company,

1991.
2. Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997.
3. Brumec, J.: Epistemiologija CASE alata, CASE 6, Opatija, 1994.
4. Brumec, J.: Projektiranje i metodike razvoja IS-a,Euro Data, Zagreb, 1996.
5. Brumec, J: Optimizacija strukture informacijskog sustava, Zbornik radova, FOI Varaždin,
1993.
6. Čerić et al: Poslovno računarstvo, Znak, Zagreb, 1998.
7. Čurčić, Grabowski, Štahan: Kako napraviti razvojni program i elaborat o procjeni vrijednosti
poduzeća, TEB, Zagreb, 1992.
8. Jandrić, K.: Administracija podataka u poduzeću, Časopis za teoriju i praksu osiguranja
"Osiguranje i privreda" god. XXXIII br. 4., Croatia osiguranje d.d., 1993.
9. Jandrić, K.: Jedinstveni IS - utopija ili stvarnost , CASE 6, Opatija, 1994.
10. Jandrić, K.: Kada i kako rekonstruirati informacijski sustav, Infotrend br. 24/7, Zagreb, 1994.
11. Jandrić, K.: Primjena rječnika podataka u razvoju informacijskog sistema Končar, CASE 3,
Opatija, 1991.
12. Klaić, B: Veliki rječnik stranih riječi, Zagreb, 1968.
13. Klasić, K. Modeli optimizacije strukture informacijskog sustava, doktorska disertacija, FOI
Varaždin, 1998.
14. Klasić, K.: Zaštita informacijskih sustava, Iproz, Zagreb, 2002.
15. Klasić, K: Novi pristup određivanju temeljne arhitekture informacijskog sustava, CASE 10,
Opatija, 1998.
16. Krakar, Z.: Efekt paradoksa, Infotrend br.51/10/1996, Zagreb
17. Krakar,Z: ISO sustavi kvalitete u informatici, HGK, Zagreb, 1997.
18. Martin, J. i McClure, C.: Software Maintenance: The Problem and Its Solution, Prentice Hall,
Englewood Cliffs, NY, 1985.
19. Martin, J.: J. Martin World Seminar, Savant, 1995.
20. Martin, J: Information Engineering: Introduction, Prentice Hall, Englewood Cliffs, NY 1990.
21. Međunarodna norma ISO 8402, Upravljanje kvalitetom i osiguranje kakvoće, Rječnik, HrQA
INFO, 1994.
22. Međunarodna norma ISO 9000-3, Norma za upravljanje kakvoćom i osiguranje kakvoće, Dio
3: Smjernice za primjenu ISO 9001 u razvoju, dobavljanju i održavanju softvera, HrQA INFO,
1993.
23. Panian, Ž.: Poslovna informatika, Potecon, Zagreb, 2001.
24. Pavlić, M.: Razvoj informacijskih sustava, Znak, Zagreb, 1996.
25. Radošević, D: Teorija sistema i teorija informacija, FOI, Varaždin, 1975.
26. Radovan, M: Projektiranje informacijskih sistema, Informator, Zagreb, 1989.
27. Srića et al: Menedžerska informatika, MEP Consulting, Zagreb, 1999
28. Strahonja, V. et al.: Projektiranje informacijskih sustava, Zavod za informatičku djelatnost
RH i Ina Info, Zagreb, 1992
29. Strahonja, V.: Zrelost informacijskog sustava, Infotrend br. 43/2/1996, Zagreb
30. Topolovec, V.:Klaster analiza: algoritmi i aplikacije na procese rasta, doktorska disertacija,
Zagreb, 1980.
31. Van Vliet, H.: Software Engineering, Wiley& Sons, NY, 2000.