Informacijski-sustavi-skripta - OSS UNIST

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.2. Kratki prikaz povijesti razvoja informacijskih sustava
1.3. Vrste informacijskih sustava
1.4. Zablude o uspješnosti informacijskih sustava i informacijska kriza
2. Organizacija poslovnog informacijskog sustava
2.1. Organizacija informacijskog sustava
2.1.1. Centralizirana organizacija informacijskog sustava
2.1.2. Decentralizirana organizacija informacijskog sustava
2.1.3. Distribuirana organizacija informacijskog sustava
2.1.4. Klijentsko poslužiteljska arhitektura informacijskog sustava
2.2.
Organizacijska kultura poslovnog sustava i organizacija informacijskog
sustava
2.3.
Organizacijska zrelost i planiranje razvoja informacijskog sustava
2.3.1. Nolanova podjela faza informatičkog razvoja poduzeća
2.3.2. Faze životnog ciklusa informacijskog sustava
2.3.3. Informacijski inženjering
2.3.4. Elementi jedinstvenosti informacijskog sustava
3. Planiranje razvoja informacijskog sustava
3.1. Strateško planiranje informacijskog sustava
3.1.1. Uloga poslovodstva u procesu planiranja
3.1.2. Faze strateškog planiranja informacijskog sustava
3.1.3. Kratki prikaz metodika za strateško planiranje informacijskog
sustava
3.2. Analiza poslovnog sustava
3.2.1. Strateška analiza poslovanja organizacijskog sustava
3.2.2. Preoblikovanje poslovnih procesa (BPR)
3.2.3. Izrada “grubog” modela podataka
3.2.4. Određivanje temeljne arhitekture IS-a
3.2.5. Analiza postojećih informacijskih podsustava i utvrđivanje
potrebnih promjena
3.2.6. Određivanje prioriteta razvoja pojedinih informacijskih podsustava
3.3. Dekompozicija ciljeva, funkcija i procesa poslovnog sustava
3.3.1. Model procesa
3.3.2. Model resursa
3.4. Tehnika matričnih dijagrama
3.4.1. Matrica procesa i klasa podataka
3.4.2. Dijagonalizacija matrice i oblikovanje podsustava
3.4.3. Unutrašnja konzistentnost i vanjska povezanost podsustava
3.5. Određivanje osnovne arhitektura informacijskog sustava
3.5.1. Analiza sklonosti između procesa
3.5.2. Mjera kvalitete strukture informacijskog sustava
1
8
10
14
22
23
25
26
30
32
33
33
37
38
40
42
42
42
44
49
51
51
52
53
54
54
55
55
58
59
59
63
67
70
71
76
i
4. Izvedba informacijskog sustava
4.1. Analiza poslovnog podsustava
4.1.1. Dijagram tijeka dokumenata (podataka)
4.1.2. Radni dijagram (workflow)
4.1.3. Specifikacija zahtjeva
4.2. Administracija podataka
4.2.1. Rječnik podataka.
4.2.2. Poslovi administracije podataka
4.2.3. Model podataka
4.2.4. Osnovni pojmovi ERA modela - entitet, atribut, relacija (veza)
4.3. Šifarski sustavi
4.3.1. Izvori šifarskih sustava
4.3.2. Oblikovanje šifarskih sustava
4.3.3. Upravljanje šifarskim sustavima u poduzeću
4.4. Uvođenje informacijskog sustava u primjenu
4.4.1. Specifikacija prototipa
4.4.2. Testiranje, uvođenje i održavanje informacijskog sustava
85
86
90
93
97
97
100
104
105
111
111
111
114
114
114
116
5. Primjena CASE pomagala
5.1. Uloga i uporaba CASE pomagala
5.2. Vrste CASE pomagala
5.3. Modeli zrelosti informacijskog sustava
120
122
124
6. Kvaliteta informacijskog sustava i zaštita od zloporaba
6.1. Kvaliteta informacijskog sustava
6.2. Zaštita informacijskog sustava
127
130
7. Seminarski primjer - Poslovanje trgovine
7.1. Sustavni postupak izgradnje informacijskog sustava
7.2. Primjer seminarskog rada «Poslovanje trgovine»
7.3. Zadaci za vježbu
132
135
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
Ulaz 2
.
.
Proces
u
sustavu
Ulaz n
Izlaz 1
Izlaz 2
.
.
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
Si
i =1
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
S
6
4
S
S3
S3
5
S2
S2
2
3
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
S os (izlazi iz sustava)
(okružje)
O
S1
S2
S3
S4
Vo3
O
Vo5
0
S1
S2
V2o
S3
V3o
S5
V15
0
0
S4
V41
S5
V51
S so (ulazi u sustav)
0
V52
0
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,
praćenje uspješnosti, otklanjanje smetnji
povećanje učinkovitosti
ODLUČIVANJE
razina odgovorna za postavljanje
poslovnih ciljeva
osiguranje stabilnosti rasta i razvoja
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
Slika b)
student polaže
predmet
student
prijavi
Studiranje
predmet
ocjena
predmeta
Evidencija
nastavnika
Nastavnik
Evidencija prisustva nastavi
IS
Studiranje
Predmet
Prijavnica
Ocjena
Zvanje
Diploma
...
Slika d)
nastavnik
predaje
predmet
Raspored sati
Student
Slika c)
i stjecanje
diplome
...
Nastavnik
Sastavljanje rasporeda sati
Raspored sati
Student
Održavanje nastave
Evidencija prisustva nastavi
Predmet
Polaganje ispita
Ocjena
Prijavnica
Obrana diplomskog rada
Zvanje
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.
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
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
podataka
Područje
primjene
Težište
računalne
podrške
dobro strukturirana
problemska područja
čiji se procesi mogu
strukturalno opisati
- prikupljanje i
pohranjivanje
podataka u bazama
podataka o prošlim
stanjima objekata,
događajima i
transakcijama
- automatizirane
obrade podataka o
prošlim stanjima
objekata, poslovnim
događajima i
transakcijama
- automatizirane
obrade prikupljenih
podataka za kontrolu
i obračun
- izvješćivanje o
prikupljenim i
obrađenim podacima
i informacijama
Sustavi uredskog
poslovanja
dobro strukturirani
ponavljajući uredski
poslovi
- podrška komuniciranju
korisnika sa okružjem
- korištenje javnih servisa
- definiranje uredskih
procedura koje uključuje
vremenske kontrole
- obrada teksta
- pretraživanje i obrada
dokumenata koji sadrže
tekst, sliku i zvuk
- upravljanje
dokumentima
- prikazivanje podataka i
informacija
- tablični kalkulatori
- terminiranje poslova i
mrežno planiranje
- postavljanje upita na
bazu
- definiranje
jednostavnijih procedura
za rad sa bazama
14
Sustavi podrške
odlučivanju
djelomično
strukturirani
procesi donošenja
odluka
- izdvajanje
podataka potrebnih
za odlučivanje iz
baza podataka
- prikupljanje i
pohranjivanje
vlastitih podataka
- definiranje
dijaloga i ulaznih
podataka, ulaznih
podataka te izbor
modela
- rješavanja
problema
- izbor oblika
prikazivanja
izlaznih rezultata
Ekspertni
sustavi
uska problemska
područja za koja
trebaju ekspertna
znanja
- rješavanje
problema
konfiguriranja i
planiranja
- rješavanje
problema
dijagnosticiranja
- obogaćivanje
sustava novim
znanjima
- objašnjavanje
načina rješavanja
problema
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
podataka
Sustavi uredskog
poslovanja
Sustavi podrške
odlučivanju
Programska programi za unos,
pretraživanje baze i
sredstva i
obradu podataka
pomagala
- programska pomagala za
kreiranje, pretraživanje,
obrađivanje i
pohranjivanje
dokumenata
- programska pomagala za
proceduralno i ad hoc
upravljanje objektima
(dokumentima i
porukama)
baze podataka
Skladište
podataka i organizacijskog
informacija sustava
- baze podataka pojedinih
programskih pomagala
- baze podataka o
objektima
- programi za
definiranje
dijaloga, izdvajanje
podataka iz baze
postojećih i unos
vlastitih podataka
- programske
procedure obrade
podataka u koje su
uključeni modeli
odlučivanja
- baze izdvojenih
podataka
- baze vlastitih
podataka
- baze podataka sa
rezultatima obrada
- baze modela
- grafički,
numerički i
tekstualno
prikazane
informacije
potrebne za
donošenje odluka
- međurezultati
obrada
srednji i viši
rukovoditelji
uspješnost,
izražajnost
Osnovne
vrste i oblici
izlaznih
informacija
- analitička i zbirna
izvješća
- izvješća o greškama
i porukama
- informacije o
stanjima i
promjenama stanja
pojedinih objekata
- prikaz sadržaja poruka,
dokumenata i ostalih
objekata
- informacije o stanjima i
promjenama pojedinih
objekata uredskog sustava
Najčešći
korisnici
Korist
izvršitelji i operativni
rukovoditelji
brzina, učinkovitost
svi koji obavljaju uredske
poslove
brzina, učinkovitost,
izražajnost
Ekspertni
sustavi
programska
pomagala i ljuske
za unos i
organiziranje
znanja,
zaključivanje na
temelju
prikupljenih
znanja,
prikazivanje
rezultata
baze znanja
- rezultati
ekspertize s
objašnjenjima
- prikaz načina
rješavanja
problema
srednji i viši
rukovoditelji
uspješnost, brzina
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:
15
•
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,
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:
16
•
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,
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:
17
•
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.
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
27
30
20
10
7
10
0
Program
Projekt
Zahtjevi
Ostalo
Trošak otklanjanja pogrešaka pri razvoju informacijskog sustava
90
80
70
60
%
50
40
30
20
10
0
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:
•
•
21
22
strateško planiranje informacijskog sustava, istodobno s planiranjem razvoja
poduzeća;
dosljedna primjena modernih metodika projektiranja i razvoja informacijskog sustava;
Brumec, J.: Strateško planiranje IS-a, FOI Varaždin, 1997.
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
Glavni posao
Projektiranje
aplikacija
Ključni ciljevi Pridobivanje
poslovodstva
Faza 2
Faza 3
Faza 4
Definiranje
poslovnih
potreba
Usaglašavanje
prioriteta
Detaljno planiranje
informacijskog
sustava
Usklađivanje
aplikacija
Procjena
strateške
prednosti
Postizanje
poslovnih
učinaka
Inicijator
planiranja
Razvoj
informatičke
tehnologije
Više
poslovodstvo
Korisnici i
informatičari
zajedno
Poslovodstvo i
korisnici
Pristup
planiranju
Razvoj
"Bottom -up"
Analiza
"Top-down"
Opća
značajka
Planiranje
vođeno
tehnologijom
Potporni
informacijski
sustav
Planiranje
vođeno
metodama
Izgledni
informacijski
sustav
Uravnoteženo
"Top-down" i
"Bottom - up"
Administrativno
planiranje
Poduzetničko korisničke
inovacije
Planiranje
vođeno
poslovima
Operativni
informacijski
sustav
Tip
informacijskog sustava
Prijelaz iz
izglednog u
operativni
informacijski
sustav
Faza 5
Veza sa
strategijom
poslovanja
Integracija
informacijskog
sustava i
poslovnih
strategija
Usuglašeno:
korisnici,
poslovodstvo i
informatičari
Više metoda
istodobno
Planiranje vođeno
organizacijom
Strateški
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
Decentralizirana organizacija
Distribuirana organizacija
Klijentsko poslužiteljska arhitektura
informacijskog
informacijskog
informacijskog
informacijskog
sustava
sustava
sustava
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
24
Panian, Ž: Poslovna informatika za ekonomiste, Potecon, Zagreb, 2001, str.187.
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
Zastupnici
Povjerenici
Podružnica n
Posrednici
Prodajna mreža
Ostali kanali prodaje
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.
2.
3.
4.
5.
6.
poslužitelj datoteka (engl. File Server)
poslužitelj baza podataka (engl. Data Base Server)
poslužitelj transakcija (engl. Transaction Server)
poslužitelj skupina (engl. Groupware Server)
poslužitelj objektnih aplikacija (engl. Object Application Server)
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
•
organizacijske
kulture
•
•
•
•
•
•
poslovodstvo pretežno prati događanja
u poslovnom sustavu
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
Tržištem upravljana organizacijska kultura
•
•
•
•
•
•
•
Obilježja
skladišta
podataka
•
•
•
•
•
•
•
Tip skladišta
podataka
Organizacija
IS
naglasak na financijskim, statističkim i
tehničkim obradama zbog utvrđivanja
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
Vertikalni ustroj skladišta podataka
Zvjezdasta organizacija informacijskog
sustava
•
•
•
•
•
•
•
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
2. faza
3. faza
4. faza
5. faza
6. faza
28
→ uvođenje (engl. Initiation),
→ proširenje (zaraza) (engl. Contagion),
→ upravljanje (kontrola) (engl. Control),
→ povezivanje (integracija) (engl. Integration),
→ sređivanje (administracija podataka) (engl. Data Administration),
→ zrelost (engl. Maturity).
Č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
I
KONTROLA
PODATAKA
FAZE
SKUP
APLIKACIJA
ORGANIZACIJA
OBRADE
PODATAKA
Faza I
Uvođenje
Ograničene,
pojedinačne aplikacije
po poslovnim
područjima
Učenje tehnologije
obrade podataka
Slaba
Nema interesa
Faza II
Proširenje
(zaraza)
Nagli porast
broja aplikacija
Korisnički orijentirani
programeri
Vrlo slaba
Površan interes
Faza III
Upravljanje
(kontrola)
Sređivanje
dokumentacije i
restrukturiranje
postojećih aplikacija
Srednja razina
upravljanja
Formalizacija planiranja
i kontrole podataka
Neprihvaćanje
odgovornosti za
podatke
Faza IV
Prilagodba postojećih Afirmiranje korisnosti
računala
Povezivanje aplikacija uporabom
tehnologije baza
i uvođenje
(integracija)
podataka
korisnika u timove
Organizacijska
Administracija podataka
Faza V
Sređivanje integracija aplikacija
(administracija
podataka)
Faza VI
Zrelost
ULOGA
KORISNIKA
Povezano planiranje i
Odgovornost za
kontrola
podatke ovisi
sustava
o pojedincu odnosno
korisniku
Dijeljeni podaci
i zajednički sustavi
Efektivna
odgovornost korisnika
Integriranje
Upravljanje resursima Strategijsko planiranje Prihvaćanje korištenja
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
33
Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997.
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.
Prema Strahonja, V. et al.: "Projektiranje informacijskih sustava", Zavod za informatičku djelatnost RH i Ina
Info, Zagreb, 1992., str. 279.
35
38
Upravljanje poslovnim
sustavom:
Poslovni
ciljevi
Strateško planiranje
Odluka o izgradnji IS-a
(početak i kraj ciklusa)
Planovi
razvoja
Prijedlozi
Studija izvodljivosti
Prilagođavanje novog
IS-a
Održavanje novog IS-a
Izabrana
strategija
Analiza funkcija
poslovnog sustava
Uočene
potrebe i
zahtjevi
Redovni
postupci
Matrica
poslovne
tehnologije
Praćenje učinaka
Osnovna arhitektura
IS-a
Redovno
korištenje
Redoslijed
prioriteta
razvoja
Uvođenje novog IS-a
Oblikovanje IS-a
Programi
dokumentacija
resursi
Model podataka
Model procesa
.....
Izrada korisničke
dokumentacije
Izvedba programske
podrške, komunikacija,
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.
Prema Strahonja, V. et al.: "Projektiranje informacijskih sustava", Zavod za informatičku djelatnost RH i Ina
Info, Zagreb, 1992.
45
40
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.
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
42
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:
•
•
•
•
•
•
•
•
44
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.
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
Utjecaj IT
Kamo ide poslovanje i
zašto?
Postavlja i mijenja ciljeve
Donosi poslovne odluke
Podrška poslovanju
Smjernice za poslovanja
IS STRATEGIJA
Što je potrebno za ostvariti
ciljeve?
Polazi od poslovanja
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
Proizvodnja
Prodaja
Funkcija
Prodajni razgovor
....
....
Funkcija
Ugovaranje
Proces
Proces
Izrada ugovora
Procedura
Administracija
....
Pravni poslovi
....
Potpisivanje
ugovora
Proces
Evidentiranje
ugovora
Procedura
Procedura
Funkcija
Financije
Proces
Pohranjivanje
ugovora
....
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
55
Klasić, K. Modeli optimizacije strukture informacijskog sustava, doktorska disertacija, FOI Varaždin, 1998.
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
a
Skup b
e
X
a
Skup e
z
b
Skup
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:
58
•
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.
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:
•
•
•
59
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.
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
p1
R
C/D
p2
R
R
C/D
R
R
p3
C/D
p4
R
p5
R
R
p6
U
R
p7
p8
R
R
p9
C/D
p11
U
E6
E7
U
E8
E9
R
R
R
C/D
U
R
R
R
C/D
C/D
R
C/D
R
R
R
U
R
U
R
p10
p12
E5
U
R
R
R
R
U
C/D
U
R
R
R
R
R
R
R
R
U
Tablica 8.: Matrica poslovne tehnologije (primjer)
Iz navedenog proizlaze svojstva koje matrica poslovne tehnologije mora zadovoljavati:
•
•
60
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.
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
p1
C
U
p4
R
C
p5
R
R
C
p7
R
R
R
p8
U
R
U
p10
R
R
p11
E7
R
E2
R
E9
E4
E6
R
R
R
U
R
R
U
R
U
R
R
p3
C
p9
R
R
p6
R
U
U
R
R
U
R
U
R
R
R
R
p2
E8
R
C
R
p12
E1
C
R
C
R
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
p1
C
U
p4
R
C
p5
R
R
C
p7
R
R
R
p8
U
R
U
p10
R
R
p11
E7
R
E2
R
E9
E4
E6
R
R
R
U
R
R
U
R
U
R
R
p3
C
p9
R
R
p6
R
U
U
R
R
U
R
U
R
R
R
R
p2
E8
R
C
R
p12
E1
C
R
C
R
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
E2
E8
E3
pi
E8
pj
E5
E7
E7
E4
E6
Matrica procesi/entiteti koja opisuje ova zbivanja je:
E1
E2
E3
pi
+
+
+
pj
+
E4
+
E5
+
E6
+
E7
E8
+
+
+
+
Slika 25. Primjer za izračun koeficijenta sklonosti procesa
64
65
Martin, J: Information Engineering: Introduction, Prentice Hall, Englewood Cliffs, NY 1990.
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:
A( p i , p j ) =
n( p i , p j )
n( p i )
Stoga se može i za primjer izračunati koeficijente sklonosti:
A ( pi , p j ) =
A ( p j , pi ) =
n ( pi , p j )
n ( pi )
n ( p j , pi )
n( pj )
=
=
3 20
60
⋅
=
= 60%
5 20 100
3 1 50 50
= ⋅
=
= 50%
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).
0 ≤ A( pi , p j ) =
n ( pi , p j )
n ( pi )
≤1
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
Proces
p1
...
...
pi
pj
...
p1
...
pi
60
50
100
...
100
pj
...
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′ ( p i , p j ) =
A( pi , p j ) + A( p j , pi )
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 )
A′ ( p i , p j ) =
n ( pi )
+
n ( p j , pi )
n( pj )
2
,
iz čega slijedi:
67
Klasić, K: Novi pristup određivanju temeljne arhitekture informacijskog sustava, Zbornik radova CASE 10,
Opatija, 1998.
73
A′ ( p i , p j ) =
n ( pi , p j ) ⋅ ( n ( p j ) + n ( p i ) )
2 ⋅ n ( pi ) ⋅ n ( p j )
.
Tada je modificirani koeficijent sklonosti A' između procesa p i i p j:
A′ ( pi , p j ) = n ( pi , p j ).
n ( pi ) + n ( 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:
A′ ( pi , p j ) = 3/ 1
5+6
2 ⋅ 5 ⋅ 6/ 2
=
11 5 55
⋅ =
= 55% ,
20 5 100
tj. rezultat izračunavanja je simetrična matrica sklonosti procesa (slika 27.)
Proces
Proces
p1
...
...
pi
pj
...
p1
...
pi
55
55
100
...
100
pj
...
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 , Ri , j ) =
A′ ( p k , pi ) ⋅ n ( pi ) + A′ ( p k , p j ) ⋅ n ( p 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
(jer jedan podsustav
2
ne smije sadržavati samo jedan proces). Za sustav S = ∪ S i , gdje je S i i - ti podsustav
• Broj mogućih podsustava s informacijskog sustava S je 1 < s <
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:
znaci da pi treba E j kao dopunsku informaciju
⎧ 0,4
⎪⎪
znaci da pi treba E j kao vaznu informaciju
z i , j = ⎨ 0,7
⎪
⎪⎩ 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
∀ ei , j = ∅
⎧ 0
⎪
⎪⎪ 0,4
∀ ei , j = R
=
ωi , j ⎨
∀ ei , j = U
⎪ 0,7
⎪
⎪⎩ 1 ∀ ei , j = C, D
za izuzetno rijetke aktivnosti (godišnje)
⎧ 0,2
⎪
za rijetke aktivnosti (mjesecne)
⎪ 0,4
⎪⎪
za relativno ceste aktivnosti (tjedne)
ν i , j = ⎨ 0,6
⎪
za ceste aktivnosti (dnevne)
⎪ 0,8
⎪
⎪⎩ 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
gdje je
n
F S = ∑ ∑ Fi , j
informacijska funkcija sustava, a
F Si = ∑
ls+rs
∑F
i,j
i∈Si j= l
i=1 j= l
informacijska funkcija i-tog podsustava.
Informacijska funkcija i-tog podsustava je zbroj informacijskih funkcija elemenata
submatrice kojom je prikazan podsustav S i :
F Si = ∑
ls + rs
∑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
FS1 = ∑∑ Fi , j ,
i =1 j =1
5
5
n
m
FS 2 = ∑∑ Fi , j , FS 3 = ∑∑ Fi , j .
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
m
t
d
č
=
=
=
=
=
jednom (ili samo nekoliko puta) u godini odnosno godišnja aktivnost,
mjesečna aktivnost,
tjedna aktivnost,
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
p1
R,v,d
C,n,d
p2
R,v,d
R,d,č
C,n,t
R,d,d
R,d,d
p3
C,n,g
p4
R,n,č
p5
R,v,d
R,v,č
p6
U,n,č
R,n,d
R,d,č
p7
p8
R,d,č
E5
p10
C,n,d
p11
U,n,d
E7
U,n,d
E8
E9
R,d,č
R,v,d
R,d,t
C,n,t
U,n,č
R,d,d
R,v,d
R,d,č
C,n,d
C,n,d
R,v,t
C,n,m
R,d,č
R,d,t
R,v,č
U,n,č
R,v,č
U,n,č
R,d,d
p9
E6
U,n,d
R,d,t
R,v,č
R,n,č
R,n,t
U,n,t
p12
C,n,d
U,n,č
R,v,č
R,v,d
R,d,č
R,d,č
R,v,m
R,v,t
R,n,m
R,d,d
U,n,t
Slika 29. Proširena matrica poslovne tehnologije
E1
E2
E3
E4
p1
0,224
0,8
p2
0,224
0,16
0,6
0,128
0,128
p3
0,2
p4
0,4
p5
0,224
0,28
p6
0,7
0,32
0,16
p7
p8
0,16
p10
0,8
p11
0,56
E6
E7
0,56
E8
0,16
0,6
0,7
0,128
0,224
0,8
0,8
0,168
0,4
0,096
0,28
0,7
0,28
0,7
0,24
0,096
0,8
0,7
0,28
0,224
0,16
0,16
0,112
0,16
0,128
0,42
Slika 30. Informacijske funkcije elemenata proširene matrice poslovne tehnologije
80
0,168
0,56
0,28
0,42
0,224
0,16
0,16
0,4
E9
0,096
0,128
p9
p12
E5
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
p2
0,6
p6
0,224
E6
0,8
E3
E5
E7
E8
E1
0,16
0,096
0,224
0,32
0,4
0,7
0,168
0,224
0,224
0,8
0,56
0,16
0,128
0,6
0,16
p5
0,28
0,128
0,8
0,168
p7
0,16
0,096
0,28
0,56
p8
0,7
0,28
0,7
0,4
0,24
p1
p4
0,128
0,7
0,7
p10
p11
0,28
p12
0,42
0,224
0,16
0,16
0,224
0,16
0,096
0,8
0,128
0,56
0,42
p3
p9
E9
0,4
0,16
0,16
0,112
E2
0,2
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
R
R
R
C
R
U
R
R
C
U
R
R
R
R
C
p5
R
R
R
C
p7
U
R
R
R
U
R
U
R
R
p2
C
p6
R
C
p1
p4
R
U
p8
U
p10
p11
R
p12
U
R
R
U
R
R
R
U
R
R
p3
p9
R
C
R
R
R
C
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.
Odredište
Izvorište
Izvorište
Izvorište
Odredište
Odredište
tok podataka B
tok podataka A
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
1.
Proces
2.
Proces
3.
RAZINA 1
Proces
2.
Proces
3.
PROCESI RAZINE 1
Proces
2. 1.
Proces
2. 2.
RAZINA 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
Dostavljač
- ugovori
- pisma
namjere
A. Ulaz
dokumenata i
priprema
dokument
i
B. Rad u
urudžbenom
zapisniku
Pozivni centar
evidentirani
dokumenti
C. Unos podataka
u sustav
Fax
prijave za
suradnike
- prijave za
suradnike
- pisma namjere
- prijave za
suradnike
- pisma namjere
- prijave za
suradnike
- pisama namjere
podaci i
dokumentii
Baza
podataka
knjiga izlazne
pošte
Internet
D. Uparivanje
unosa sa
urudžbenim
zapisnikom
izlazne
liste
E. Izlaz
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:
Odluka
Prekid
Proces
Dokument
Baza podataka
Ručna
operacija
Zaslon
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
-pisma namjere
-ostala pošta
Kraj
No
Potvrda o
primitku?
A.1.
Razdvajanje
pošte
Ostala pošta?
No
Prijave za
suradnike?
Potvrda o
primitku
A.1.1. Ispis
potvrde o
primitku
Yes
A.2.2. Žig
na
dokument
No
Yes
A.2.1. Žig
na
kovertu
Yes
A.2.2.1.
Sortiranje
(koverte +
dokumenti)
B.1. Evidentiranje
pošte
A.2.1.1.
Sortiranje
B.2. Upis
red. br.
pošte
C.1. Unos podataka
u sustav
Prijave za
suradnike?
No
Jednostrano
potpisan ugovor
Yes
C.3. Priprema
i slanje
dokumenata
poštom
No
Yes
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
Laser printer
Urudžbeni zapisnik
- 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
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
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
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
HH:MM:SS KPKNUI03
Reg. oznaka
____________
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
F3-kraj
F7-dolje
Pregled
Stat.voz.
__
V
V
V
V
V
V
P
P
P
P
P
P
P
P
P
Datum ulaza
___________
prisutnih
Vrijeme ulaza
_________
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
vozila
Tren.akt.
__
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
U
D
A
D
D
D
D
U
D
R
D
A
S
R
D
F8-gore
PREGLED PRISUTNIH VOZILA
DD.MM.GGGG
HH:MM:SS
Reg. oznaka
____________
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
RRRRRRRRRR
Stat.voz.
__
V
V
V
V
V
V
P
P
P
P
Datum ulaza
___________
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
DD.MM.GGGG.
Vrijeme ulaza
_________
Tren.akt.
__
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
HH:MM:SS
Izradio:
_______________________
Slika 40. Primjeri izvješća
96
U
D
A
D
D
D
D
U
D
R
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
o
o
o
o
o
značenje podataka,
odnosi prema ostalim podacima,
instance ili osobe zadužene za održavanje podataka,
izvori podataka,
ovlašteni korisnici, i
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)
Baza
podataka
Sustav za
upravljanje bazom
podataka (SUBP)
Korisnik
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
Baza
podataka
Rječnik
Sustav za
podataka
upravljanje
bazom podataka
SQL
(SUBP)
(projektant, programer,
administrator)
Aplikacija
Krajnji
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
poslovnog sustava
Poslovna tehnologija
poslovnog sustava
distribucija podataka iz okruženja
distribucija entiteta, atributa
i dijelom sadržaja entiteta
konsolidacija
modela podataka
propisana tehnologija rada
kontrola ispravnosti
tehnologije rada
DISLOCIRANI RAZVOJNI CENTAR
podaci
Model podataka
aplikacije
Model procesa
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
Definiranje projekta
Izrada dijagrama
Analiza
X
Definiranje zahtjeva i
uporabe
Tijeka podataka
podataka
X
X
Eksterno oblikovanje
Izrada modela podataka
X
X
baze podataka (logičko
modeliranje)
Analiza uporabe
podataka
X
X
X
X
X
X
X
X
Eksterno oblikovanje
baze podataka (izrada
logičkog modela baze)
Interno oblikovanje
baze podataka (fizičko
modeliranje)
Oblikovanje
baze
podataka
Interno oblikovanje
baze podataka (izrada
fizičkog modela baze)
DA
DBA
Programer
Implementacija baze
podataka
X
X
Održavanje i uporaba
baze podataka
X
X
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.
81
ŠKOLA 1
ima
ŠKOLA 2
ima
RAZRED 1
RAZRED 2
RAZRED 3
RAZRED 4
RAZRED 5
RAZRED 6
.
.
.
RAZRED 1
RAZRED 2
RAZRED 3
.
.
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
pripada
RAZRED
M
1
Dijagram entiteti - veze (Martinova notacija)
ŠKOLA
RAZRED
ima
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
M
1
je ugrađen u
M
ima
Š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)
ƒ
82
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,
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
1 automobil
posjeduje
pripada
0, 1 ili više automobila
1 osobi
Grafički se taj odnos prikazuje u Chenovoj notaciji (slika 49.):
1,1
OSOBA
0,M
posjeduje
pripada
Slika 49.: Grafički prikaz kardinalnosti veze
108
AUTOMOBIL
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
STAVKA
RAČUNA
M
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
Dubrava
Dubrava
ima
ima
ima
šifru općine
04197 (Ston)
šifru naselja
15466
šifru općine
03000 (Omiš)
šifru naselja
15468
š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.
Akcija 1.
Akcija 1.
Akcija 2.
*BLOK A
*BLOK A
*BLOK B
Akcija 2.
Akcija 3.
*BLOK B
Akcija 3.
Akcija 4.
Akcija 5.
Akcija 6.
Akcija 4.
*BLOK C
Akcija 5.
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
TROŠKOVE ODRŽAVANJA
ČIMBENICI KOJI SMANJUJU TROŠKOVE
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:
K=
1
1- t +
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 → ∞ ).
Tada
1
t
.
→ 0 , pa je K =
1- t
k
Povećanje produktivnosti
korištenjem CASE pomagala
9,00
8,00
K
7,00
0
1,00
0,1
1,11
0,2
1,25
0,3
1,43
0,4
1,67
0,5
2,00
0,6
2,50
0,7
3,33
0,8
5,00
0,9 10,00
1
∞
6,00
t
Slika 55. Primjer za k → ∞
87
K
5,00
4,00
3,00
2,00
1,00
0,00
0
0,2
0,4
0,6
t
Jednadžbu je obrazložio A. Radelić na 1. hrvatskoj konferenciji SYNON korisnika, 1997. godine.
120
0,8
1
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
K=
1-
1
3
=
3
2
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
t
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
k1 k2 k3 k4
1,5
1,5
1,5
1,5
1,5
1,5
1,5
1,5
1,5
1,5
1,5
2
2
2
2
2
2
2
2
2
2
2
4
4
4
4
4
4
4
4
4
4
4
8
8
8
8
8
8
8
8
8
8
8
K1 K2 K3 K4
1,00
1,03
1,07
1,11
1,15
1,20
1,25
1,30
1,36
1,43
1,50
1,00
1,05
1,11
1,18
1,25
1,33
1,43
1,54
1,67
1,82
2,00
1,00
1,08
1,18
1,29
1,43
1,60
1,82
2,11
2,50
3,08
4,00
1,00
1,10
1,21
1,36
1,54
1,78
2,11
2,58
3,33
4,71
8,00
K
k2=2
6,00
k3=4
5,00
k4=8
4,00
3,00
2,00
1,00
0,00
0
0,2
0,4
0,6
0,8
1
t
Slika 56. Primjer za K =
1
1- t +
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
89
engl. repository
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
INFORMACIJSKOG
SUSTAVA
1. Faza rane primjene
2.
3.
4.
ORGANIZACIJSKI I METODOLOŠKI
KRITERIJI
ƒ
primjena informacijskih tehnologija u
pojedinačnim i izoliranim slučajevima
ƒ
Faza zaraze i
pridobivanja
korisnika
Faza odvajanja
funkcija
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Faza ujedinjavanja
(projektiranja,
normizacije)
ƒ
ƒ
porast broja izoliranih aplikacija
skupo održavanje aplikacija
rasap sustava
odvajanje razvoja od produkcije
uvođenje planiranja informacijskog sustava
odvajanje analize od oblikovanja i
programiranja
ujedinjavanje modela podataka
normizacija poslovne tehnologije
temeljem normizacije aplikacija
dosljedna primjena neke od metodika
razvoja informacijskog sustava
izgradnja konzistentne baze podataka
uvođenje funkcija administracije
podataka i administracije baze podataka
samostalni pristup korisnika zajedničkim
podacima
korisnici aktivno sudjeluju u razvoju IS-a
korisnik upravlja vlastitim podacima i za
njih je odgovoran
arhitektura informacijskog sustava
sukladna je arhitekturi organizacijskog
sustava
strategijsko planiranje informacijskog
sustava dio je sustava planiranja tvrtke
informacijski centar je servisna funkcija
ƒ
ƒ
ƒ
5.
TEHNOLOŠKI
KRITERIJI
Faza upravljanja
podacima
ƒ
ƒ
ƒ
6.
Faza zadovoljavanja
korisnika
ƒ
ƒ
7.
Faza pune zrelosti
ƒ
ƒ
ƒ
ƒ
ƒ
primjena računala na
kojima su odgovarajući
programi
primjena centralnog
računala ili mreže
računala
primjena pomagala za
projektiranje i
dokumentiranje
projekata
primjena sustava za
upravljanje bazama
podataka i rječnika
podataka
ƒ
korištenje jezika upita
od strane korisnika
ƒ
grafičko sučelje
aplikacija i
ujedinjene radne
okoline
otvorenost sustava
distribuiranost baze
podataka
primjena arhitekture
korisnik/poslužitelj
ƒ
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.
ZNAČAJKE
FAZA ZRELOSTI
RAZVOJA IS-a
1. Faza primitivnog
razvoja
- uporaba jezika III. generacije
- nema administracije podataka ni standardne metodike razvoja
2. Faza dobro
strukturirana
razvoja
- uporaba tehnika za strukturno programiranje ili objektno
orijentiranih tehnika
- uporaba CASE-a u fazi planiranja, oblikovanja i generiranja aplikacija
3. Faza uporabe
pomagala
temeljenih na
riznici podataka
- uporaba integratora riznice podataka zbog provjere koegzistencije i
integriteta podataka
- potpuno generiranje programskog koda računalom
- administracija riznice podataka
4. Faza uporabe
modernih
metodika i
metrika
- upravljanje projektima i metodologijama putem računala
- modeliranje poduzeća
- izrada prototipova aplikacija
- korištenje metrike za procjenu brzine, kvalitete, troškova,
produktivnosti, zadovoljstva korisnika, održavanja i fleksibilnosti
5. Faza integracije
sustava poduzeća
- upravljanje riznicom podataka 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
optimizacije
razvoja
- razvoj metodika provodi se u razvojnim timovima
- primjenjuje se upravljanje kvalitetom sustava
- koriste se za razvoj biblioteke gotovih programskih komponenti temeljenih
na riznici podataka
- oblikovanje fleksibilnih sustava
7. Faza neprekidne
optimizacije
poduzeća
- razvoj inteligentnih modela poduzeća (u kojima se zrcale poslovna
pravila i uvjeti)
- 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
SUSTAVA (Tricker)
1. Faza rane primjene
FAZA ZRELOSTI RAZVOJA
INFORMACIJSKOG SUSTAVA (Martin)
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.
2.
3.
4.
5.
6.
Objasnite uloga i uporabu CASE pomagala. Ukratko opišite razvoj CASE.
Objasnite Dedeneov izraz. Navedite primjere.
Navedite i objasnite vrste CASE pomagala. Objasnite pojam riznice.
Opišite Trickerov model zrelosti informacijskog sustava.
Opišite Martinov model faza zrelosti razvoja informacijskog sustava.
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
94
Krakar, Z.: ISO sustavi kvalitete u informatici, ZIH Zagreb, 1994.
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:
•
•
•
98
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.
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.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
Naziv teme
Poslovanje kina
Poslovanje dječjeg vrtića
Poslovanje ordinacije opće medicine
Knjigovodstveni servis
Poslovanje kluba za obuku pasa
Poslovanje videoteke
Poslovanje auto škole
Poslovanje modne agencije
Poslovanje Web design studija
Poslovanje kemijske čistionice
Poslovanje časopisa
Poslovanje Internet kluba
Poslovanje obrta - posredovanje u kupoprodaji nekretnina
Poslovanje javnobilježničkog ureda
Poslovanje pivovare
Poslovanje hotela – rezervacija i organizacija smještaja
Poslovanje prodavaonice namještaja
Poslovanje turističke agencije
Poslovanje restorana
Poslovanje ski kluba
Poslovanje caffe bara
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:
nabava i promet
sedmično:
artikli
SPLIT
Centralno skladište
- veleprodaja dnevno:
artikli
dnevno:
nabava i
promet
Trgovina VIS
Područno skladište
- maloprodaja -
Trgovina SPLIT
Područno skladište
- maloprodaja -
sedmično:
nabava i promet
2 puta
sedmično:
artikli
Trgovina TROGIR
Područno skladište
- 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
poslovanja
Poslovni
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
poduzeće
izvješća za
trgovinu
na upit:
nabava i promet
Centralno skladište
- veleprodaja -
Područno skladište
- 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:
Faza:
Poslovanje trgovine
Datum:
27.10.2002
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:
Faza:
Dokument:
Datum:
Poslovanje trgovine
13.10.2002
Analiza poslovnog sustava
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:
Faza:
Dokument:
Datum:
Poslovanje trgovine
19.10.2002
Analiza poslovnog sustava
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:
nabava i promet
sedmično:
artikli
SPLIT
Centralno skladište
- veleprodaja dnevno:
artikli
dnevno:
nabava i
promet
Trgovina VIS
Područno skladište
- maloprodaja -
Trgovina SPLIT
Područno skladište
- maloprodaja -
sedmično:
nabava i promet
2 puta
sedmično:
artikli
Trgovina TROGIR
Područno skladište
- 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
računovodstvo i
financije
Sektor prodaje
Služba
veleprodaje
Poslovna jedinica Split
Služba
maloprodaje
Poslovna jedinica Trogir
Poslovna jedinica Vis
143
Sektor marketinga
Raščlanjenje poslovodne strukture
Generalni direktor
Direktor prodaje
Šef veleprodaje
Poslovođa trgovine
Split
Direktor računovodstva
i financija
Šef maloprodaje
Poslovođa trgovine
Trogir
144
Poslovođa trgovine
Vis
Direktor
marketinga
Dokumenti prikupljeni tijekom razgovora
Prilog 1.
Prilog 2.
145
Prilog 3.
146
Prilog 4.
Prilog 5.
147
Projekt:
Faza:
Dokument:
Datum:
Poslovanje trgovine
20.10.2002
Analiza poslovnog sustava
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.
Poslovanje
veleprodaje
Naručivanje
artikala od
dobavljača
Zaprimanje
artikala u
skladište
Prodaja
artikala u
veleprodaji
Poslovanje
maloprodaje
Izdavanje
artikala u
skladište
maloprodaje
Zaprimanje
artikala iz
skladišta
veleprodaje
Vođenje
računovodstvenofinancijskih poslova
Prodaja
artikala u
maloprodaji
Vođenje
poslova
marketinga
Vraćanje
artikala u
skladište
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
artikala od
dobavljača
Zaprimanje
artikala u
skladište
Izdavanje artikala
u skladište
maloprodaje
Prodaja
artikala u
veleprodaji
1.1. Dekompozicija funkcije 'Naručivanje artikala od dobavljača'
Naručivanje
artikala od
dobavljača
Provjera i odabir
artikala čije
količine su
ispod minimalne
Izrada
dokumenta
narudžbenica
149
Prikaz izvješća
u procesu
naručivanja
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
čije količine
su ispod
minimalne
Označavanje
artikala
koje treba
naručiti
Grupiranje
označenih
artikala po
dobavljačima
1.1.2. Dekompozicija procesa 'Izrada dokumenta narudžbenica'
Izrada
dokumenta
narudžbenica
Upis novog
dobavljača
u šifrarnik
dobavljača
Upis novog
artikla koji se
naručuje
u šifrarnik
artikala
Izrada nove
narudžbenice za
pojedinog
dobavljača i
artikle koji se
naručuju od tog
dobavljača
Upis novog
artikla na
dokument
narudžbenica
1.1.3. Dekompozicija procesa 'Prikaz izvješća u procesu naručivanja'
Prikaz izvješća
u procesu
naručivanja
Prikaz
rekapitulacije
narudžbi
dobavljačima
Prikaz
minimalne i
maksimalne
količine
150
1.2. Dekompozicija funkcije 'Zaprimanje artikala u skladište'
Zaprimanje
artikala u
skladište
Zaprimanje
artikala iz
skladišta
maloprodaje
Zaprimanje
artikala od
dobavljača
1.2.1. Dekompozicija procesa 'Zaprimanje artikala od dobavljača'
Zaprimanje
artikala od
dobavljača
Izrada
dokumenta
primka
Usporedba
primke i
narudžbenice
Prikaz izvješća
u procesu
zaprimanja
1.2.1.1. Dekompozicija potprocesa 'Izrada dokumenta primka'
Izrada
dokumenta
primka
Izrada
nove primke
za odabranog
dobavljača
Upis novog
zaprimljenog
artikla u
šifrarnik artikala
151
Upis
artikala na
dokument
primka
1.2.1.2. Dekompozicija potprocesa 'Usporedba primke i narudžbenice'
Usporedba
primke i
narudžbenice
Za dobavljača sa
primke pretraživanje
i usporedba
narudžbenica koje
nisu uspoređene
Upis broja
narudžbenice
u primku
1.2.1.3. Dekompozicija potprocesa 'Prikaz izvješća u procesu zaprimanja'
Prikaz izvješća
u procesu
zaprimanja
Prikaz
rekapitulacije
primki
Prikaz
prometa po
dobavljačima
1.2.2. Dekompozicija procesa 'Zaprimanje artikala iz skladišta maloprodaje'
Zaprimanje artikala
iz skladišta
maloprodaje
Izrada dokumenta
ulazna međuskladišnica
iz odabranog skladište
maloprodaje
Upis artikala
na ulaznu
međuskladišnicu
152
Prikaz
rekapitulacije
ulaznih
međuskladišnica
1.3. Dekompozicija funkcije 'Prodaja artikala u veleprodaji'
Prodaja
artikala u
veleprodaji
Izrada cjenika
veleprodaje
Izrada
dokumenta
račun
Prikaz izvješća
u procesu
prodaje
Obavljanje
inventure
1.3.1. Dekompozicija procesa 'Izrada cjenika veleprodaje'
Izrada
cjenika
veleprodaje
Formiranje
cijene za
artikle
Ispis
cjenika
1.3.2. Dekompozicija procesa 'Izrada dokumenta račun'
Izrada
dokumenta
račun
Upis novog
kupca
u šifrarnik
kupaca
Izdavanje
novog računa
sa podacima
o kupcu
Unos
artikala
na dokument
račun
153
Dodjeljivanje
rabata za
kupca
1.3.3. Dekompozicija procesa 'Prikaz izvješća u procesu prodaje'
Prikaz izvješća
u procesu
prodaje
Prikaz
rekapitulacije
računa
Prikaz
pometa po
kupcima
Prikaz
pometa
skladišta
Prikaz
pometa po
artiklu
Prikaz
rekapitulacije
svih dokumenata
skladišta
1.3.4. Dekompozicija procesa 'Obavljanje inventure'
Obavljanje
inventure
Ispis
popisne
liste
Izrada
inventurne
liste
Generiranje
dokumenta o višku i
dokumenta o manjku
Prikaz
pregleda
inventura
1.4. Dekompozicija funkcije 'Izdavanje artikala u skladište maloprodaje'
Izdavanje artikala
u skladište
maloprodaje
Izrada dokumenta
izlazna međuskladišnica
za odabrano skladište
maloprodaje
Upis artikala
na izlaznu
međuskladišnicu
154
Prikaz
rekapitulacije
izlaznih
međuskladišnica
Opis funkcija/procesa
Rb. Naziv funkcije/procesa
Opis funkcije/procesa
1. Prikaz artikala čije
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.
2. Označavanje artikala koje
Među artiklima koji su kandidati za naručivanje odabiru se oni
koji će se naručiti. Odabrane artikle treba posebno označiti.
3. Grupiranje označenih
Označene artikle treba složiti (grupirati) po dobavljačima jer se
narudžbenica radi posebno za svakog pojedinog dobavljača.
4. Upis novog dobavljača u
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.
5. Izrada nove narudžbenice
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.
6. Upis novog artikla koji se
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.
7. Upis novog artikla na
Ako se od dobavljača prvi put naručuje neki artikal onda i njega
treba dodati na postojeću narudžbenicu.
8. Prikaz rekapitulacije
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.
9. Prikaz minimalne i
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.
količine su ispod
minimalne
treba naručiti
artikala po dobavljačima
šifarnik dobavljača
za pojedinog dobavljača i
artikle koji se naručuju od
tog dobavljača
naručuje u šifarnik
artikala
dokument narudžbenica
narudžbi dobavljačima
maksimalne količine
10. Izrada nove primke za
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.
11. Upis novog zaprimljenog
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.
12. Upis artikala na dokument
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.
13. Za dobavljača sa primke
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.
odabranog dobavljača
artikla u šifarnik artikala
primka
pretraživanje i usporedba
narudžbenica koje nisu
uspoređene
155
Rb. Naziv funkcije/procesa
Opis funkcije/procesa
14. Upis broja narudžbenice u
U primku upisati broj narudžbenice i ovu odložiti među
dokumente narudžbenica koje su rješene.
15. Prikaz rekapitulacije
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.
16. Prikaz prometa po
Ovo izvješće pokazuje pregled primki od pojedinog dobavljača
složenih po datumu zaprimanja robe, uz ispis ukupne vrijednost
robe.
17. Izrad dokumenta ulazna
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.
18. Upis artikala na ulaznu
U stavke dokumenta ulazna međuskladišnica upisuju se podaci o
artiklu i zaprimljenoj količini artikla.
19. Prikaz rekapitulacije
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.
20. Formiranje cijene za
Za artikle koji se prodaju treba formirati prodajne cijene u
kojima je ukalkulirana marža tj. zarada.
21. Ispis cjenika
Cjenik se ispisuje po potrebi, nakon što se promijeni cijena
jednog ili više arikala.
22. Upis novog kupca u
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.
23. Izdavanje novog računa sa
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.
24. Unos artikala na
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.
25. Dodjeljivanje rabata za
Za pojedine artikle koji se prodaju, mogu se unaprijed definirati
minimalni ili maksimalni rabati za kupca.
26. Prikaz rekapitulacije
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.
27. Prikaz prometa po
Ovo izvješće pokazuje pregled računa za pojedinog kupca
složenih po datumu izdavanja računa, uz ispis ukupne vrijednost
robe.
28. Prikaz prometa skladišta
Pregled ulaznih i izlaznih vrijednosti za odabrano skladište, za
sve dobavljače i kupce, za jedan ili sve artikle, u odabranom
vremenskom periodu.
29. Prikaz prometa po artiklu
Pregled prometa za jedan artikal, za jedno ili sva skladišta, za
jednog ili sve dobavljače/kupce, u odabranom vremenskom
periodu.
primku
primki
dobavljačima
međuskladišnica iz
odabranog skladište
maloprodaje
međuskladišnicu
ulaznih međuskladišnica
artikle
šifarnik kupaca
podacima o kupcu
dokument račun
kupca
računa
kupcima
156
Rb. Naziv funkcije/procesa
Opis funkcije/procesa
30. Prikaz rekapitulacije svih
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.
31. Ispis popisne liste
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.
32. Izrada inventurne liste
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’).
33. Generiranje dokumenta o
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.
34. Prikaz pregleda inventura
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.
35. Izrada dokumenta izlazna
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.
36. Upis artikala na izlaznu
U stavke dokumenta izlazna međuskladišnica upisuju se podaci
o artiklu i izdanoj količini artikla.
37. Prikaz rekapitulacije
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.
dokumenata skladišta
višku i dokumenta o
manjku
međuskladišnica za
odabrano skladište
maloprodaje
međuskladišnicu
izlaznih međuskladišnica
157
Projekt:
Faza:
Dokument:
Datum:
Poslovanje trgovine
20.10.2002
Analiza poslovnog sustava
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
MEĐUSKLADIŠNICA
Dokument kojim se artikli vraćeni iz skladišta maloprodaje
ponovno zaprimaju u skladište veleprodaje.
14. IZLAZNA
MEĐUSKLADIŠNICA
Dokument kojim se artikli izdaju u drugo skladište (skladište
maloprodaje).
159
Projekt:
Faza:
Dokument:
Datum:
Poslovanje trgovine
20.10.2002
Analiza poslovnog sustava
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
1. Prikaz artik. čije količine su ispod minimalne
R
2. Označavanje artikala koje treba naručiti
U
3. Grupiranje označenih artik. po dobavljačima
R
R
5. Izrada nove narudž. za pojedinog dobavljača ...
R
R
6. Upis novog artikla koji se naručuje u šifarnik …
C
7. Upis novog artikla na dok. narudžbenica
R
4. Upis novog dobavljača u šifarnik dobavljača
12. Upis artikala na dokument primka
R
R
R
R
R
U
R
R
R
R
15. Prikaz rekapitulacije primki
R
R
R
R
17. Izrada dokumenta ulazna međuskladišnica …
R
C
R
U
19. Prikaz rekapitulacije ulaznih međuskladišn.
R
R
R
R
21. Ispis cjenika
C
R
22. Upis novog kupca u šifarnik kupaca
C
23. Izdavanje novog računa sa podacima o kupcu
R
R
C
R
U
25. Dodjeljivanje rabata za kupca
R
26. Prikaz rekapitulacije računa
R
27. Prikaz prometa po kupcima
R
28. Prikaz prometa skladišta
R
30. Prikaz rekapitulacije svih dokum. skladišta
R
R
U
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
C
R
C
R
R
34. Prikaz pregleda inventura
R
R
35. Izrad dokumenta izlazna međuskladišnica …
R
36. Upis artikala na izlaznu međuskladišnicu
R
R
32. Izrada inventurne liste
33. Generiranje dok. o višku i dok. o manjku
ULAZNA
MEĐUSKL.
IZLAZNA
MEĐUSKL.
U
R
31. Ispis popisne liste
POPISNA LISTA
C
14. Upis broja narudžbenice u primku
29. Prikaz prometa po artiklu
ZAPISNIK O
MANJKU
R
13. Za dobav. sa primke pretraživanje narudž. …
24. Unos artikala na dokument račun
ZAPISNIK O VIŠKU
R
R
C
20. Formiranje cijene za artikle
INVENTURNA
LISTA
U
R
11. Upis novog zaprimljenog artikla u šifarnik …
18. Upis artikala na ulaznu međuskladišnicu
RAČUN
C
R
10. Izrada nove primke za odabranog dobavljača
16. Prikaz prometa po dobavljačima
CJENIK
PRIMKA
LOKACIJA
NARUDŽBENICA
R
C
8. Prikaz rekapitulacije narudžbi dobavljačima
9. Prikaz minimalne i maksimalne količine
KUPAC
Procesi
ARTIKAL
Entiteti
DOBAVLJAČ
Osnovna matrica poslovne tehnologije
R
C
C
C
U
37. Prikaz rekapitulacije izlaznih međuskladišn.
R
161
R
6. i 11. Upis novog artikla u šifarnik artikala
C
1. Prikaz artik. čije količine su ispod minimalne
R
2. Označavanje artikala koje treba naručiti
U
9. Prikaz minimalne i maksimalne količine
R
4. Upis novog dobavljača u šifarnik dobavljača
3. Grupiranje označenih artik. po dobavljačima
R
R
8. Prikaz rekapitulacije narudžbi dobavljačima
R
R
R
R
R
R
R
R
R
R
U
R
R
R
R
R
C
R
R
U
19. Prikaz rekapitulacije ulaznih međuskladišn.
R
R
R
R
C
21. Ispis cjenika
R
23. Izdavanje novog računa sa podacima o kupcu
R
C
R
R
U
25. Dodjeljivanje rabata za kupca
R
26. Prikaz rekapitulacije računa
R
R
27. Prikaz prometa po kupcima
R
R
R
U
35. Izrad dokumenta izlazna međuskladišnica …
R
37. Prikaz rekapitulacije izlaznih međuskladišn.
28. Prikaz prometa skladišta
R
30. Prikaz rekapitulacije svih dokum. skladišta
R
C
R
U
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
C
R
32. Izrada inventurne liste
33. Generiranje dok. o višku i dok. o manjku
LOKACIJA
R
U
17. Izrada dokumenta ulazna međuskladišnica …
31. Ispis popisne liste
INVENTURNA
LISTA
ZAPISNIK O
VIŠKU
ZAPISNIK O
MANJKU
C
R
15. Prikaz rekapitulacije primki
29. Prikaz prometa po artiklu
POPISNA LISTA
R
14. Upis broja narudžbenice u primku
36. Upis artikala na izlaznu međuskladišnicu
IZLAZNA
MEĐUSKL.
U
13. Za dobav. sa primke pretraživanje narudž. …
24. Unos artikala na dokument račun
RAČUN
C
R
10. Izrada nove primke za odabranog dobavljača
20. Formiranje cijene za artikle
CJENIK
R
C
7. Upis novog artikla na dok. narudžbenica
18. Upis artikala na ulaznu međuskladišnicu
ULAZNA
MEĐUSKL.
R
C
R
5. Izrada nove narudž. za pojedinog dobavljača ...
16. Prikaz prometa po dobavljačima
PRIMKA
R
22. Upis novog kupca u šifarnik kupaca
12. Upis artikala na dokument primka
KUPAC
DOBAVLJAČ
Procesi
ARTIKAL
Entiteti
NARUDŽBENICA
Dijagonalizirana matrica poslovne tehnologije
R
R
R
R
R
R
C
R
34. Prikaz pregleda inventura
R
162
R
R
C
C
R
R
Projekt:
Faza:
Dokument:
Datum:
Poslovanje trgovine
24.10.2002
Analiza poslovnog sustava
Lista korisničkih zahtjeva (ZAHTJEVI)
Ime i prezime:
Smjer:
Lista korisničkih zahtjeva
Rb.
KORISNIK
ZAHTJEV
RJEŠENJE
1.
Rukovods
tvo
Osigurati jedinstveni šifarnik artikala
dostupan svima (nabavi, veleprodaji i
maloprodaji).
2.
Rukovods
tvo
Osigurati jedinstveni šifarnik kupaca i
dobavljača (partneri) dostupan svim
lokacijama.
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
prodaje
Za sve artikle u sustavu omogućiti
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.
3.
4.
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
5.
Direktor
veleprod.
Omogućiti definiranje dokumenata za
nabavljanje, zaprimanje i prodaju artikala u
skladištu veleprodaje.
6.
Direktor
prodaje
U svakom skladištu osigurati definiranje i
ispis cjenika na dan.
Za svaki navedeni dokument izraditi masku
za unos podataka. Za sve dokumente treba
osigurati mogućnost unošenja, izmjene i
brisanja (ako je dokument nepotvrđen) stavki
artikala na tom dokumentu.
Izraditi odgovarajući program za ispis
cjenika na dan.
7.
Direktor
veleprod.
Omogućiti ispis svakog pojedinog
dokumenta (narudžbenice, primke, računa,
…) sa zaglavljem i stavkama artikala,
podacima o operateru i vremenu ispisa i
kreiranja dokumenta.
Izraditi odgovarajuće programe za svaki
pojedini dokument.
8.
Rukovods
tvo
Omogućiti vođenje dokumenata ulaznih i
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.
Izraditi odgovarajuće programe.
9.
Rukovods
tvo
Dokumente ulazne i izlazne
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.
Izraditi odgovarajuće programe.
10.
Direktor
veleprod.
Osigurati pregled tzv. Rekapitulaciju
narudžbi dobavljačima, s tim da se mogu
posebno dobiti nerealizirane narudžbenice.
Izraditi odgovarajući program za ispis
rekapitulacije.
11.
Direktor
veleprod.
Omogućiti Rekapitulacije primki i računa
po brojevima dokumenata ili za odabrane
vremenske intervale za jednog ili sve
partnere.
Izraditi odgovarajući program za ispis
rekapitulacije.
12.
Direktor
veleprod.
Pri izradi primke obavezno se mora upisati
broj narudžbenice, kako bi se znalo koja je
nabava realizirana.
Programski uvjetovati obavezan upis broja
narudžbenice.
13.
Direktor
veleprod.
Omogućiti automatsku usporedbu sadržaja
(stavki) primke i narudžbenice i
povezivanje (anuliranje) onih koje su
istovjetne u svom sadržaju.
Izraditi odgovarajući program.
14.
Rukovods
tvo
Omogućiti izvješća Promet po kupcu,
Promet skladišta i Promet po artiklima za
jedno ili za sva skladišta.
Izraditi odgovarajuće programe za ispis
izvješća.
15.
Rukovods
tvo
Osigurati efikasan popis artikala na kraju
godine ili bilo kada tokom godine
(inventura).
Izraditi odgovarajući program za ispis.
16.
Rukovods
tvo
Omogućiti da se po unosu podataka sa
inventurne liste automatski generiraju
dokumenti Višak i Manjak.
Programski pri unosu podataka kalkulirati
višak odnosno manjak. Ako se pojavi višak
automastki se generira dokument Višak, a za
manjak dokument Manjak.
164
Projekt:
Faza:
Dokument:
Datum:
Poslovanje trgovine
24.10.2002
Analiza poslovnog sustava
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
Dobavljač
izlazna
međuskladišnica
narudžbenica
dokument od
dobavljača
Skladište
maloprodaje
izlazna
međuskladišnica
Poslovanje
veleprodaje
popisna lista
cjenik
Komisija
inventurna
lista
popunjena
popisna lista
račun
Šef
veleprodaje
165
Kupac
Šef
veleprodaje
Dijagrami tijeka podataka nižih nivoa
- nivo 1: Poslovanje veleprodaje
Dobavljač
izlazna
međuskladišnica
dokument do
dobavljača
narudžbenica
1. Naručivanje
artikala od
dobavljača
naziv, mjesto,
adresa, mat. broj
količina
Komisija
inventurna
lista
šifra
lokacije
Lokacija
Artikal
šifra, naziv,
količina
popisna lista
Skladište
maloprodaje
2. Zaprimanje
artikala u
skladište
Dobavljač
količina
3. Prodaja
artikala u
veleprodaji
naziv, mjesto,
adresa, mat. broj
Artikal
račun
Šef
veleprodaje
Šef
veleprodaje
Kupac
166
šifra
lokacije
4. Izdavanje
artikala u
skladište
maloprodaje
Kupac
cjenik
izlazna
međuskladišnica
količina
- nivo 2: 1. Naručivanje artikala od dobavljača
Skladištar
Skladištar
količina na skladištu,
minimalna količina
popis
artikala
oznaka za
narudžbu
1.1. Provjera i
odabir artikala čije
količine su ispod
minimalne
količina na skladištu,
minimalna količina,
maksimalna količina
Artikal
1.3. Prikaz
izvješća
u procesu
naručivanja
oznaka za
narudžbu
šifra i
naziv artikla
Dobavljač
rekapitulacija
narudžbenica
rekapitulacija
narudžbenica
narudžbenica
Narudžbenica
šifra i naziv
dobavljača
Skladištar
1.2. Izrada
dokumenta
narudžbenica
odabir
dobavljača
i artikala
popis artikala,
min. i maksim.
količina
narudžbenica
Šef
veleprodaje
narudžbenica
Dobavljač
- nivo 3: 1.1. Provjera i odabir artikala čije količine su ispod minimalne
Skladištar
popis
artikala
1.1.1. Prikaz
artikala čije
količine su ispod
minimalne
količina na skladištu,
minimalna količina
oznaka za
narudžbu
1.1.2. Označavanje
artikala koje
treba naručiti
oznaka za
narudžbu
Artikal
šifra i
naziv artikla
Dobavljač
Skladištar
pregled dobavljača
i artikala
1.1.3. Grupiranje
označenih
artikala po
dobavljačima
167
šifra i naziv
dobavljača
- nivo 3: 1.2. Izrada dokumenta narudžbenica
Dobavljač
Skladištar
narudžbenica
šifra i naziv
dobavljača
1.2.1. Upis novog
dobavljača
u šifrarnik
dobavljača
1.2.2. Izrada nove
narudžbenice za
dobavljača i artikle
koji se naručuju
od tog dobavljača
odabir dobavljača
i artikala
šifra i naziv
dobavljača
Dobavljač
narudžbenica
šifra i naziv
dobavljača
šifra i naziv
dobavljača
Narudžbenica
šifra i
naziv artikla
Artikal
1.2.3. Upis novog
artikla
koji se naručuje
u šifrarnik obavljača
šifra i
naziv artikla
1.2.4. Upis novog
artikla na
narudžbenicu
šifra i
naziv artikla
šifra i
naziv artikla
odabir artikla
Skladištar
- nivo 3: 1.3. Prikaz izvješća u procesu naručivanja
1.3.1. Prikaz
minimalne i
maksimalne
količine
popis artikala, min.
i maksim. količina
Šef
veleprodaje
rekapitulacija
narudžbenica
količina na skladištu,
minimalna količina,
maksimalna količina
Artikal
narudžbenica
Narudžbenica
Skladištar
168
1.3.2. Prikaz
rekapitulacije
narudžbi
dobavljačima
rekapitulacija
narudžbenica
- nivo 2: 2. Zaprimanje artikala u skladište
izlazna
međuskladišnica
Dobavljač
dokument od
dobavljača
2.2. Zaprimanje
artikala iz
skladišta
maloprodaje
2.1. Zaprimanje
artikala od
dobavljača
Primka
šifra
lokacije
Lokacija
ulazna
međuskladišnica
količina
primka
Skladište
maloprodaje
Ulazna
međuskladišnica
količina
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
maloprodaje
Skladištar
šifra i naziv
artikla
izlazna
međuskladišnica
2.2.1. Izrada dok.
ulazna
međuskladišnica
iz odabranog
skladište maloprodaje
šifra
lokacije
Lokacija
šifra
lokacije
šifra i naziv
artikla
šifra
lokacije
Artikal
šifra i naziv
artikla
Ulazna
međuskladišnica
Šef
veleprodaje
169
2.2.2. Upis
artikala na
ulaznu
međuskladišnicu
količina
ulazna
međuskladišnica
rekapitulacija
ulaznih
međuskladišnica
2.2.3. Prikaz
rekapitulacije
ulaznih
međuskladišnica
rekapitulacija ulaznih
međuskladišnica
- nivo 2: 3. Prodaja artikala u veleprodaji
Skladištar
pregledi i
izvješća
Primka
primka
Šef
veleprodaje
primka
pregledi i izvješća
Ulazna
međuskladišnica
ulazna međuskl.
cjenik
ulazna
međuskl.
Artikal
3.1. Izrada
cjenika
veleprodaje
šifra i
naziv artikla
cijena
3.3. Prikaz
izvješća u
procesu prodaje
šifra i
naziv artikla
zap. o manjku
šifra i
naziv artikla
Cjenik
3.2. Izrada
dokumenta
račun
izlazna
međuskl.
Zapisnik
o manjku
zap. o višku
šifra i
naziv kupca
cijena
Izlazna
međuskladišnica
račun
Kupac
račun
izlazna međuskl.
zap. o manjku
šifra i
naziv artikla
šifra i
naziv kupca
Zapisnik
o višku
zap. o višku
Račun
račun
odabir kupca
i artikala
Šef
veleprodaje
170
3.4. Obavljanje
inventure
inventurna lista
Kupac
Skadištar
račun
popisna
lista
ispunjena
popisna lista
Komisija
- nivo 3: 3.1. Izrada cjenika veleprodaje
Šef
veleprodaje
cijena
cjenik
cjenik
3.1.1. Formiranje
cijene za artikle
3.1.2. Ispis
cjenika
šifra i naziv
artikla
cijena
šifra i naziv
artikla
Skladištar
Cjenik
cjenik
Artikal
- nivo 3: 3.2. Izrada dokumenta račun
Kupac
Kupac
šifra i naziv
kupca
račun
3.2.1. Izdavanje
novog računa
sa podacima
o kupcu
šifra i naziv
kupca
šifra i naziv
artikla
Šef
veleprodaje
račun
rabat
šifra i naziv
kupca
Račun
rabat
3.2.3. Dodjeljivanje
rabata
za kupca
Skladištar
Artikal
količina
šifra i naziv
artikla
3.2.2. Unos
artikala
na račun
šifra i naziv
artikla
171
šifra i naziv
kupca
Kupac
- nivo 3: 3.3. Prikaz izvješća u procesu prodaje
zap. o manjku
Ulazna
međuskladišnica
ulazna
međuskl.
rekapit. svih
dokumentata
skladišta
Zapisnik
o višku
zap. o višku
Šef
veleprodaje
promet po
artiklu
Primka
rekapit. svih
dokumentata
skladišta
3.3.5. Prikaz
rekapitulacije
svih dokumenata
skladišta
promet
skladišta
primka
Račun
račun
izlazna
međuskl.
3.3.4. Prikaz
pometa po
artiklu
račun
ulazna
međuskl.
Ulazna
međuskladišnica
ulazna
međuskl.
3.3.3. Prikaz
pometa
skladišta
promet po
artiklu
izlazna međuskl.
Izlazna
međuskladišnica
promet
skladišta
Skladištar
primka
izlazna
međuskl.
Šef
veleprodaje
Skladištar
Zapisnik
o manjku
šifra i naziv
artikla
Artikal
Kupac
šifra i naziv
kupca
Račun
Primka
rekapitulacija
računa
primka
račun
račun
3.3.1. Prikaz
rekapitulacije
računa
račun
rekapitulacija
računa
172
Šef
veleprodaje
3.3.2.. Prikaz
prometa po
kupcima
promet po
kupcima
promet po
kupcima
- nivo 3: 3.4. Obavljanje inventure
Popisna lista
Komisija
popisna
lista
popisna
lista
šifra i naziv
artikla
3.4.4. Prikaz
pregleda
inventura
lokacija
ispunjena
popisna lista
Lokacija
lokacija
3.4.1. Ispis
popisne
liste
pregled
inventura
šifra i naziv
artikla
Šef
veleprodaje
inventura
generiranje
lokacija
višak količine
Artikal
Šef
veleprodaje
Lokacija
Inventura
manjak količine
inventurna
lista
zap. o manjku
inventura
3.4.2. Izrada
inventurne
liste
izlazna
međuskl.
primka
Primka
3.4.3. Generiranje
dok. o višku i
dok. o manjku
račun
Račun
ulazna
međuskl.
Izlazna
međuskladišnica
zap. o viš
ku
količina
Artikal
Ulazna
međuskladišnica
- nivo 2: 4. Izdavanje artikala u skladište maloprodaje (vidi zadatak 1.e) )
173
Zapisnik
o manjku
Zapisnik
o višku
Projekt:
Faza:
Dokument:
Datum:
Poslovanje trgovine
26.10.2002
Analiza poslovnog sustava
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
količina na skladištu
dovoljna?
Da
Stavljanje artikla
na izlaznu
međuskladišnicu
Ne
Je li količina
na skladištu ispod
minimalne?
Da
Da
Ne
Obilježavanje
artikla
Ima li još
artikala na popisu
(1)?
Ne
A
174
A
Listanje ostalih
artikala u centralnom
skladištu (2)
Je li količina
na skladištu ispod
minimalne?
Da
Da
Ne
Obilježavanje
artikla
Ima li još
artikala na popisu
(2)?
Da li
naručiti novi
artikal?
Ne
Grupiranje
obilježenih artikala
po dobavljačima
Da
Da li postoji
dobavljač?
Listanje
dobavljača (3)
Ne
Da
Unos novog
dobavljača
Izrada narudžbenice
za dobavljača
Upis novog artikla
Da
Obilježavanje
novog artikla
Da
Izrada stavke
narudžbenice za
artikle zadanog
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
artikal?
Da
Upis novog artikla
Ne
Ima li još
artikala na dokumentu
od dobavljača?
Ne
Pretraživanje
neuspoređenih
narudžbenica od
dobavljača
Je li
pronađena narudžbenica
s brojem?
Da
Upis broja
narudžbenice u
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
listi artikala sa
manjakom?
Da
Izrada dokumenta
o manjku
Da
Izrada dokumenta
o višku
Ne
Ima li na
listi artikala sa
viškom?
Ne
Inventurna lista
Listanje artikala
sa inventurne
liste (1)
stvarna kol. <
nađena kol.
Da
Upis artikla i viška u
dokument o višku
Da
Upis artikla i manjka u
dokument o manjku
Ne
Da
stvarna kol. >
nađena kol.
Ne
Ima li još
artikala na listi
(1)?
Ne
Kraj
177
Projekt:
Faza:
Dokument:
Datum:
Poslovanje trgovine
Analiza poslovnog sustava
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
28.10.2002
Maska za artikle na narudžbenici:
179
Projekt:
Faza:
Dokument:
Datum:
Poslovanje trgovine
29.10.2002
Analiza poslovnog sustava
Izvjesca (IZVJESCE)
Ime i prezime:
Smjer:
Sadržaj
Izvješća
Promet skladišta (primjer)
Promet skladišta
“VE-MA” d.o.o.
Južna ulica 10, SPLIT
04.03.2001
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
dokumenta
Dokument
01.02.1997.
PR / 00054
02.02.1997.
RN / 00008
05.02.1997.
IM / 00012
05.02.1997.
RN / 00047
10.02.1997.
PR / 00055
11.02.1997.
RN / 00015
15.02.1997.
UM / 00007
21.02.1997.
UM / 00005
27.02.1997.
RN / 00002
UKUPNO:
Ulaz
Izlaz
Saldo
2.500,00
60,00
7.500,00
7.400,00
7.360,00
6.360,00
11.860,00
11.360,00
12.060,00
12.210,00
12.150,00
1.700,00
12.150,00
100,00
40,00
1.000,00
5.500,00
500,00
700,00
150,00
8.850,00
180
Po prodajnim cijenama
Izlaz
120,00
1.200,00
610,00
75,00
2.005,00
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č
Dobavljač
šifra i naziv
dobavljača
dokument do
dobavljača
Skladištar
broj
narudžbenice
neuspoređene
narudžbenice
2.1.2. Usporedba
primke i
narudžbenice
2.1.1. Izrada
dokumenta
primka
primka
broj
narudžbenice
odabir
dobavljača
i artikala
šifra i naziv
artikla
Skladištar
rekapitulacija
primki
rekapitulacija
primki
Primka
2.1.3. Prikaz
izvješća u
procesu
zaprimanja
primka
Artikal
Šef
veleprodaje
promet po
dobavljačima
b) nivo 4: 2.1.1. Izrada dokumenta primka
Dobavljač
Dobavljač
dokument do
dobavljača
2.1.1.1. Izrada
nove primke
za odabranog
dobavljača
šifra i naziv
dobavljača
šifra i naziv
dobavljača
Skladištar
šifra i naziv
artikla
šifra i naziv
dobavljača
2.1.1.2. Upis
novog zaprimljenog
artikla u šifrarnik
artikala
Primka
šifra i naziv
artikla
šifra i naziv
artikla
Artikal
šifra i naziv
artikla
količina
2.1.1.3. Upis
artikala na
dokument
primka
šifra i naziv
artikla
181
Skladištar
c) nivo 4: 2.1.2. Usporedba primke i narudžbenice
odabir
narudžbenice
šifra i naziv
dobavljača
2.1.2.1. Za dobavljača
sa primke pretraživanje i usporedba
narudžbenica koje
nisu uspoređene
Skladištar
broj
narudžbenice
neuspoređene
narudžbenice
Primka
2.1.2.2. Upis
broja
narudžbenice
u primku
narudžbenica
Narudžbenica
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
rekapitulacija
primki
2.1.5. Prikaz
rekapitulacije
primki
rekapitulacija
primki
2.1.6. Prikaz
prometa po
dobavljačima
promet po
dobavljačima
Šef
veleprodaje
e) nivo 2: 4. Izdavanje artikala u skladište maloprodaje
Skladište
maloprodaje
Skladištar
izlazna
međuskladišnica
4.1. Izrada dok.
izlazna
međuskladišnica
za odabrano
skladište
maloprodaje
šifra
lokacije
šifra
lokacije
rekapitulacija
izlaznih međuskl.
šifra i naziv
artikla
šifra i naziv
artikla
šifra
lokacije
količina
Artikal
izlazna
međuskl.
4.2. Upis
artikala na
izlaznu
međuskladišnicu
šifra i naziv
artikla
izlazna
međuskladišnica
Izlazna
međuskladišnica
Šef
veleprodaje
Lokacija
182
rekapitulacija
izlaznih međuskl.
4.3. Prikaz
rekapitulacije
izlaznih
međuskladišnica
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
Ispis izlazne
međuskladišnice
Kraj
183
Izlazna
međuskladišnica
b) Izrada cjenika veleprodaje
Početak
Zahtjev za
formiranje cjenika
Da li
već postoji
cjenik?
Ne
Da
Listanje artikala iz
popisa artikala (2)
Listanje artikala
iz cjenika (1)
Izmjena
postojeće
cijene?
Da
Odabir nabavne
cijene za artikal
Da
Ne
Da
Upis nove cijene
za artikal u cjenik
velep. cijena =
nab. cijena + marža
Upis artikla i
velep. cijene u
cjenik
Ima li još
artikala (1)?
Ima li još
artikala (2)?
Ne
Ne
Dodavanje
novog artikla u
cjenik?
Ne
Da
Odabir artikla i
nabavne cijene
Ispis cjenika
velep. cijena =
nab. cijena + marža
Kraj
Upis artikla i
velep. cijene u
cjenik
184
Cjenik
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.
Južna ulica 10, SPLIT
04.03.2003
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.
7.
Čerić et al: Poslovno računarstvo, Znak, Zagreb, 1998.
Č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.
i