VELEUČILIŠTE U SPLITU ODJEL RAČUNARSTVA

Ksenija Klasić Karmen Klarin

INFORMACIJSKI SUSTAVI

SKRIPTA

Split, listopad 2003.

SADRŽAJ 1. Informacijski sustav u poslovanju 1.1. Definicija sustava, poslovnog sustava i njegovog informacijskog sustava 1 1.2. Kratki prikaz povijesti razvoja informacijskih sustava 8 1.3. Vrste informacijskih sustava 10 1.4. Zablude o uspješnosti informacijskih sustava i informacijska kriza 14 2. Organizacija poslovnog informacijskog sustava 2.1. Organizacija informacijskog sustava 22

2.1.1. Centralizirana organizacija informacijskog sustava 23 2.1.2. Decentralizirana organizacija informacijskog sustava 25 2.1.3. Distribuirana organizacija informacijskog sustava 26 2.1.4. Klijentsko poslužiteljska arhitektura informacijskog sustava 30

2.2. Organizacijska kultura poslovnog sustava i organizacija informacijskog sustava 32

2.3. Organizacijska zrelost i planiranje razvoja informacijskog sustava 33 2.3.1. Nolanova podjela faza informatičkog razvoja poduzeća 33 2.3.2. Faze životnog ciklusa informacijskog sustava 37 2.3.3. Informacijski inženjering 38 2.3.4. Elementi jedinstvenosti informacijskog sustava 40

3. Planiranje razvoja informacijskog sustava 3.1. Strateško planiranje informacijskog sustava 42

3.1.1. Uloga poslovodstva u procesu planiranja 42 3.1.2. Faze strateškog planiranja informacijskog sustava 42 3.1.3. Kratki prikaz metodika za strateško planiranje informacijskog

sustava 44 3.2. Analiza poslovnog sustava 49

3.2.1. Strateška analiza poslovanja organizacijskog sustava 51 3.2.2. Preoblikovanje poslovnih procesa (BPR) 51 3.2.3. Izrada “grubog” modela podataka 52 3.2.4. Određivanje temeljne arhitekture IS-a 53 3.2.5. Analiza postojećih informacijskih podsustava i utvrđivanje

potrebnih promjena 54 3.2.6. Određivanje prioriteta razvoja pojedinih informacijskih podsustava 54

3.3. Dekompozicija ciljeva, funkcija i procesa poslovnog sustava 55 3.3.1. Model procesa 55 3.3.2. Model resursa 58

3.4. Tehnika matričnih dijagrama 59 3.4.1. Matrica procesa i klasa podataka 59 3.4.2. Dijagonalizacija matrice i oblikovanje podsustava 63 3.4.3. Unutrašnja konzistentnost i vanjska povezanost podsustava 67

3.5. Određivanje osnovne arhitektura informacijskog sustava 70 3.5.1. Analiza sklonosti između procesa 71 3.5.2. Mjera kvalitete strukture informacijskog sustava 76

i

4. Izvedba informacijskog sustava 4.1. Analiza poslovnog podsustava 85

4.1.1. Dijagram tijeka dokumenata (podataka) 86 4.1.2. Radni dijagram (workflow) 90 4.1.3. Specifikacija zahtjeva 93

4.2. Administracija podataka 97 4.2.1. Rječnik podataka. 97 4.2.2. Poslovi administracije podataka 100 4.2.3. Model podataka 104 4.2.4. Osnovni pojmovi ERA modela - entitet, atribut, relacija (veza) 105

4.3. Šifarski sustavi 111 4.3.1. Izvori šifarskih sustava 111 4.3.2. Oblikovanje šifarskih sustava 111 4.3.3. Upravljanje šifarskim sustavima u poduzeću 114 4.4. Uvođenje informacijskog sustava u primjenu 114 4.4.1. Specifikacija prototipa 114 4.4.2. Testiranje, uvođenje i održavanje informacijskog sustava 116 5. Primjena CASE pomagala 5.1. Uloga i uporaba CASE pomagala 120 5.2. Vrste CASE pomagala 122 5.3. Modeli zrelosti informacijskog sustava 124 6. Kvaliteta informacijskog sustava i zaštita od zloporaba 6.1. Kvaliteta informacijskog sustava 127 6.2. Zaštita informacijskog sustava 130 7. Seminarski primjer - Poslovanje trgovine 7.1. Sustavni postupak izgradnje informacijskog sustava 132 7.2. Primjer seminarskog rada «Poslovanje trgovine» 135 7.3. Zadaci za vježbu 181 Literatura

ii

1

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.

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.

Procesu

sustavu

Ulaz 1

Ulaz 2

Ulaz n

Izlaz 1

Izlaz 2

Izlaz m

.

...

2

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 = Us

i 1=

Si

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

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.).

S

S1

S2

S3

1

3

2 4

5

6

S

S1

S2

S3

1

2

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

2 Radošević, D: Teorija sistema i teorija informacija, str. 184., FOI, Varaždin, 1975.

3

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:

⎟⎟⎠

⎞⎜⎜⎝

⎛

SS

SS = S

ssso

osoo

Soo 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.

Sos 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.

Soo (okružje) Sos (izlazi iz sustava)

O

S1

S2

S3

S4

S5

O

Vo3

Vo5

S1

0

V15

S2

V2o

0

S3

V3o

0

S4

V41

0

S5

V51

V52

0

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

Slika3. Potpuna matrica strukture sustava S

3 Primjerice, kada je 2003. godine zakonom ukinuto pravo korištenja jedinstvenog matičnog broja građana za svrhe za koje matični broj nije namijenjen, roditelji novorođene djece nisu mogli prijaviti dijete u zdravstveno osiguranje jer im nije bio poznat djetetov JMBG. Naime, aplikacija je prvo tražila prijavu novog JMBG-a a zatim je tek bilo moguće obaviti posao. Za zdravstveni sustav podatak o JMBG-u je podatak iz okruženja, jer nastaje izvan sustava.

4

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 Sos 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.

5

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.).

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

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

S t r a te š k a r a z in a( r a z in a o d lu č iv a 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.

6

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.

7

1. Kadrovska evidencija (nastavnici, ostali zaposlenici)2. Evidencija studenata3. 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 . . .

Sustav visokoškolskog obrazovanja

IS Studiranje

Evidencijanastavnika

Evidencijastudenata

Studiranjei stjecanjediplome

nastavnikpredajepredmet

student slušapredmet

student polažepredmet

studentprijavi

predmet

ISStudiranje

Nastavnik

Student

Predmet

Prijavnica

. . .

Raspored sati

Evidencija prisustva nastavi

Ocjena

Zvanje

Diploma

. . .

Sastavljanje rasporeda sati

Održavanje nastave

Polaganje ispita

Obrana diplomskog rada

. . .

Nastavnik

Student

Predmet

Prijavnica

Raspored sati

Evidencija prisustva nastavi

Ocjena

ZvanjeDiploma

PROCESI

PODACIulazni izlazni

Slika a)

Slika b)

Slika c)

Slika d)

ocjenapredmeta

Slika 5. Primjer sustava i informacijskog sustava

8

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

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

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

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

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

7 Panian, Ž.: Poslovna informatika, Potecon, Zagreb, 2001, str. 45.-48. 8 Medij može biti kamen, na kojem su stari Egipćani urezivali simbole kojima su opisivali i evidentirali zbivanja iz svakodnevnog života, papirus po kojem se pisalo trstikom, glinene pločice s klinastim pismom i konačno papir, na kojima su pisari vodili poslovne knjige odnosno zapise o ljetini, porezu i slično. 9 Poslovi pisanja na pisaćem stroju postaju cijenjenim ne samo za muškarce, nego i za žene. Na taj način ženama je omogućeno dulje i kvalitetnije školovanje, a kao završene tipkačice mogle su se samostalno uzdržavati. 10 Popisi stanovništva radili su se i u starom vijeku, no njihova obrada radila se ručno i trajala je dugo. Najpoznatiji popis stanovništva iz tog doba opisan je Bibliji, prilikom Kristova rođenja.

9

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.

10

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.

11

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

Sustavi uredskog poslovanja

Sustavi podrške odlučivanju

Ekspertni sustavi

Područje primjene

dobro strukturirana problemska područja čiji se procesi mogu strukturalno opisati

dobro strukturirani ponavljajući uredski poslovi

djelomično strukturirani procesi donošenja odluka

uska problemska područja za koja trebaju ekspertna znanja

Težište računalne podrške

- 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

- 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

- 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

- rješavanje problema konfiguriranja i planiranja - rješavanje problema dijagnosticiranja - obogaćivanje sustava novim znanjima - objašnjavanje načina rješavanja problema

14 Prema Strahonja, V. et al.: "Projektiranje informacijskih sustava", Zavod za informatičku djelatnost RH i Ina Info, Zagreb, 1992., str. 36.-37.

12

Sustavi obrade podataka

Sustavi uredskog poslovanja

Sustavi podrške odlučivanju

Ekspertni sustavi

Programska sredstva i pomagala

programi za unos, pretraživanje baze i obradu podataka

- programska pomagala za kreiranje, pretraživanje, obrađivanje i pohranjivanje dokumenata - programska pomagala za proceduralno i ad hoc upravljanje objektima (dokumentima i porukama)

- 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

programska pomagala i ljuske za unos i organiziranje znanja, zaključivanje na temelju prikupljenih znanja, prikazivanje rezultata

Skladište podataka i informacija

baze podataka organizacijskog sustava

- baze podataka pojedinih programskih pomagala - baze podataka o objektima

- baze izdvojenih podataka - baze vlastitih podataka - baze podataka sa rezultatima obrada - baze modela

baze znanja

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

- grafički, numerički i tekstualno prikazane informacije potrebne za donošenje odluka - međurezultati obrada

- rezultati ekspertize s objašnjenjima - prikaz načina rješavanja problema

Najčešći korisnici

izvršitelji i operativni rukovoditelji

svi koji obavljaju uredske poslove

srednji i viši rukovoditelji

srednji i viši rukovoditelji

Korist brzina, učinkovitost brzina, učinkovitost, izražajnost

uspješnost, izražajnost

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:

• Informacijski podsustav (IPS) planiranja i analize poslovanja,

• IPS upravljanja trajnim proizvodnim dobrima,

• IPS upravljanja ljudskim resursima,

• IPS upravljanja financijama,

• IPS nabave materijala i sirovina,

• IPS prodaje proizvoda i usluga,

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

13

• IPS računovodstva,

• IPS istraživanja i razvoja itd.

Primjena informacijske tehnologije nema jednak značaj za različite poslovne sustave, pa i onda kada imaju implementirane iste informacijske podsustave. Stoga se informacijski sustavi dijele na četiri osnovna tipa:

• Operativni informacijski sustav je sustav o kojem ovisi uspjeh tekućeg poslovanja. U ovom slučaju funkcioniranje poduzeća jako ovisi o informacijskoj tehnologiji jer informacijski sustav služi kao potpora svakodnevnom poslu (primjerice u trgovini).

• Potporni informacijski sustav je koristan, ali nije kritičan za poslovni uspjeh poduzeća. U ovom slučaju ovisnost funkcioniranja poduzeća o informacijskoj tehnologiji je mala (primjerice u građevinarstvu).

• Strateški informacijski sustav kritičan je za poslovnu strategiju u budućnosti, pa mora omogućiti pohranu i brzu obradu velike količine potrebnih podataka. U ovom slučaju funkcioniranje poduzeća jako ovisi o primjeni informacijske tehnologije, kao i poslovni rezultat poduzeća (primjerice, rezervacija karata za prijevoz).

• Izgledni informacijski sustav mogao bi utjecati na uspjeh budućeg poslovanja, stoga je ovisnost funkcioniranja poduzeća o informacijskoj tehnologiji mala, ali je utjecaj informatike na poslovni rezultat velik (primjerice, u osiguravateljnoj djelatnosti gdje osiguravatelj može funkcionirati uz ručno izdavanje police i obradu šteta, ali za isplativ izračun premije osiguranja i procjenu rizika za postojeće i nove proizvode krojene prema ciljnim skupinama mora obraditi veliku količinu prikupljenih podataka, što bez primjene informatike predugo traje i može značajno utjecati na rezultate poslovanja).

Za svaki poslovni sustav može se odrediti kojem tipu pojedini informacijski podsustav pripada, te tako, ovisno o osnovnoj djelatnosti poduzeća, lakše ocijeniti redoslijed prioriteta pri uvođenju informacijskih podsustava u poslovanje. Često se počne s izgradnjom potpornog informacijskog sustava, koji postepeno prerasta do izglednog informacijskog sustava, ključnog za dugoročno poslovanje. Neovisno o tipu i vrsti informacijskog sustava, u njima su pohranjeni podaci potrebni za dalju obradu i izvješćivanje. O kvaliteti tih podataka ovisiti će i kvaliteta informacijskog sustava. Budući da je informacijski sustav dio poslovnog sustava, o kvaliteti informacijskog sustava pak ovisi i cjelokupno poslovanje tvrtke. Dakle, bez dobro i jednoznačno definiranih podataka nema ni kvalitetnog informacijskog sustava, a bez kvalitetnog i dobro strukturiranog informacijskog sustava nema ni kvalitetne podrške klijentu kao ni rasta i razvoja poduzeća. Stoga kvalitetan informacijski sustav mora zadovoljiti sljedeća osnovna načela16:

• informacijski sustav je model poslovne tehnologije organizacijskog sustava,

• podaci su resurs poslovnog sustava,

• temelj razmatranja prilikom određivanja podsustava su poslovni procesi kao nepromjenjivi dio određene poslovne tehnologije,

16 Brumec, J.: Projektiranje i metodike razvoja IS-a,Euro Data, Zagreb, 1996.

14

• informacijski sustav izgrađuje se integracijom podsustava na osnovi zajedničkih podataka (modularnost),

• informacije za upravljanje i odlučivanje izvode se na temelju zbivanja na razini izvođenja .

Informacijski sustav izgrađen na ovim načelima preslikava poslovni tehnologiju određenog poduzeća, te može u potpunosti zadovoljiti svoju zadaću prikupljanja, obrade, pohrane i distribucije podataka svima kojima je to potrebno, s ciljem unapređenja poslovanja i ostvarenja pozitivnih poslovnih rezultata.

1.4. Zablude o uspješnosti informacijskih sustava i informacijska kriza

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

O neuspješnim informacijskim sustavima nitko ne piše, tako da se često stvara pogrešan dojam da su svi drugi sustavi uspješni, a samo onaj koji koristite ili mukotrpno razvijate neuspješan. Rijetki primjeri navedeni u literaturi postali su poznati zbog visokih šteta na ljudima i stvarima, kojima su uzrok bili neuspješni sustavi. Primjerice17:

• Ariane 5, let 501 (1996.), koja je eksplodirala prilikom lansiranja radi niza grešaka u softveru. Nesreća je mogla imati više uzroka, od kojih se navode nedovoljno testiran softver, loše održavanje te nedostaci u oblikovanju softvera.

• Therac –25, aparat za zračenje upravljan računalom, kojim je pri terapiji najmanje šest osoba ozračeno previsokim dozama radijacije, a za troje je dokazano da je umrlo od zračenja. Razlog je bio u nedovoljnoj kvaliteti sustava, odnosno neadekvatnom testiranju softvera za određivanja količine zračenja, nedovoljno jasnoj dokumentaciji i uputama za rad, te softverskim greškama u programu koji je trebao osigurati sigurnost pri primjeni stroja.

• Londonski sustav hitne pomoći (engl. The London Ambulance Service), koji je trebao upravljati prometom ambulantnih vozila na području od preko 600 kvadratnih milja, koji prevozi preko 5000 pacijenata dnevno u 750 vozila. S obzirom da se radi o preko 2000 telefonskih poziva na dan, uključujući više od 1300 hitnih intervencija, odlučeno je uvesti računalom podržan sustav. Autori softvera nisu imali dovoljno iskustva u izradi tako složenog i velikog sustava, pa su napravili čitav niz grešaka u oblikovanju i programiranju sustava, koji se tri tjedna nakon uvođenja raspao. Softver nije bio prilagođen ljudima koji su ga trebali koristiti, tako da se pretpostavlja da su neke osobe umrle jer hitna pomoć nije do njih stigla na vrijeme.

17 Prema Van Vliet, H.: Software Engineering, Wiley& Sons, NY, 2000., str. 18.-24.

15

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.

16

Uzroci neuspjeha informacijskog sustava

10

27

58

7

0

10

20

30

40

50

60

70

Program Projekt Zahtjevi Ostalo

%

Trošak otklanjanja pogrešaka pri razvoju informacijskog sustava

0

10

20

30

40

50

60

70

80

90

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

17

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

18

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

19

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

Slika 7. Upravljanje razvojem zrelosti procesa (Wats-Hemphry model) Uvođenjem mogućnosti predviđanja nastaju procesi četvrte razine ili upravljani procesi. Njihovim usklađivanjem s ostalim procesima četvrte razine i stalnim usavršavanjem nastaju optimirani ili sinkronizirani procesi. Budući da jedna od definicija kaže da je informacijski sustav dobar onoliko koliko su dobri procesi koje on obavlja21, može ga se procijeniti s dosta velikom pouzdanošću, ako se odredi razina zrelosti njegovih glavnih procesa. Ti pak podaci mogu poslužiti pri procjeni vjerojatnosti uspjeha i resursa potrebnih za provođenje preoblikovanja poslovanja. Preoblikovanje poslovanja je postupak modeliranja poslovnih procesa tako da ih se osposobi za informatičku primjenu. Jasno, ukoliko se utvrdi da su neki procesi višak potrebno ih je ukinuti. Također, procesi koje nije moguće informatički podržati jer zahtijevaju posebna znanja i donošenje odluka na temelju prosudbe, moraju se opisati što detaljnije i uključiti u informacijski sustav. U ovom prijedlogu rješenja efekta paradoksa posebno je naglašeno da su nositelji tih aktivnosti poslovodstva poslovnih sustava, a informatika je samo potpora. Drugi prijedlog rješenja efekta paradoksa predlaže konkretne postupke za uspješnost ulaganja u informacijske tehnologije22:

• strateško planiranje informacijskog sustava, istodobno s planiranjem razvoja poduzeća;

• dosljedna primjena modernih metodika projektiranja i razvoja informacijskog sustava;

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

20

• osiguranje organizacijske zrelosti sredine za prihvaćanje nove informacijske tehnologije.

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

faza 1. → faza 2. → faza 3. → faza 4. → faza 5. ↓________________↑

Faza 1 Faza 2 Faza 3 Faza 4 Faza 5 Glavni posao Projektiranje

aplikacija Definiranje poslovnih potreba

Detaljno planiranje informacijskog sustava

Procjena strateške prednosti

Veza sa strategijom poslovanja

Ključni ciljevi Pridobivanje poslovodstva

Usaglašavanje prioriteta

Usklađivanje aplikacija

Postizanje poslovnih učinaka

Integracija informacijskog sustava i poslovnih strategija

Inicijator planiranja

Razvoj informatičke tehnologije

Više poslovodstvo

Korisnici i informatičari zajedno

Poslovodstvo i korisnici

Usuglašeno: korisnici, poslovodstvo i informatičari

Pristup planiranju

Razvoj "Bottom -up"

Analiza "Top-down"

Uravnoteženo "Top-down" i "Bottom - up"

Poduzetničko -korisničke inovacije

Više metoda istodobno

Opća značajka

Planiranje vođeno tehnologijom

Planiranje vođeno metodama

Administrativno planiranje

Planiranje vođeno poslovima

Planiranje vođeno organizacijom

Tip informacij-skog sustava

Potporni informacijski sustav

Izgledni informacijski sustav

Prijelaz iz izglednog u operativni informacijski sustav

Operativni informacijski sustav

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.

21

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!

22

2. Organizacija poslovnog informacijskog sustava

Organizacija informacijskog sustava Organizacijska kultura i organizacija informacijskog sustava

Organizacijska zrelost i planiranje informacijskog sustava.

2.1. Organizacija informacijskog sustava

Centralizirana organizacija informacijskog sustava Decentralizirana organizacija informacijskog sustava

Distribuirana organizacija informacijskog sustava Klijentsko poslužiteljska arhitektura informacijskog sustava

Poslovni sustav čine ljudi, njihovo znanje i tehnička oprema koju koriste za obavljanje svakodnevnog posla. Stoga je potrebno, posebno u velikim i složenim poslovnim sustavima, organizirati posao na način da se uz što manje troškove realiziraju postavljeni ciljevi. Iz navedenog proizlazi da: "Organizacija predstavlja svjesno udruživanje ljudi kojima je cilj da odgovarajućim sredstvima ispune određene zadatke s najmanjim mogućim naporom, na bilo kojem području rada i života23". Organizacija poslovnog sustava podložna je određenim objektivnim čimbenicima odnosno ograničenjima prostorne prirode (primjerice, poduzeće može djelovati na malom i ograničenom prostoru ili može djelovati na širem zemljopisnom području), vremenske prirode jer se uvjeti poslovanja neprekidno mijenjaju pa se i organizacija može mijenjati sukladno njima, ekonomske prirode gdje se pokušava ostvariti maksimalnu korist uz minimalne troškove, te tehnološke prirode (primjerice primjena novih tehnologija za unapređenje poslovanja i realizaciju poslovnih ciljeva). Informacijski sustav dio je svakog poslovnog sustava, što znači da je organizacija informacijskog sustava način usklađivanja ljudi i informacijske tehnologije u djelatnoj cjelini kojoj je cilj načinom, oblikom i vremenom primjereno zadovoljavanje informacijskih potreba ljudi u poslovnom sustavu, radi ostvarivanja mogućnosti učinkovitog upravljanja tim sustavom24. «Orgware» je tada skup zamisli, pravila i postupaka u skladu s kojima se informacijski sustav oblikuje, razvija i djeluje. Organizacijski ustroj poslovnog sustava može se prikazati različitim modelima, u obliku: 23 Panian, Ž: Poslovna informatika za ekonomiste, Potecon, Zagreb, 2001, str.187. 24 Prema Panian, Ž: Poslovna informatika za ekonomiste, Potecon, Zagreb, 2001, str.188.

23

• 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.

24

SREDIŠNJERAČ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.

Slika 9. Primjer primjene centralizirane organizacije informacijskog sustava u poslovanju

Prodajna mreža

Osiguravatelj

Stanice za tehnièki pregledi

Zastupnici Povjerenici Posrednici

25

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.

26

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.

27

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.

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.).

Osiguravatelj - poslovna mreža

........

Prodajna mreža

Podružnica 1

Povjerenici Posrednici Ostali kanali prodajeZastupnici

Podružnica n

Središnjica

28

SATELITSKORAČUNALO

SATELITSKORAČUNALO

GLAVNORAČUNALO

SATELITSKORAČ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.).

29

SATELITSKORAČUNALO

SATELITSKORAČUNALO

GLAVNORAČUNALO

SATELITSKORAČUNALO

GLAVNORAČUNALO

SATELITSKORAČUNALO

SATELITSKORAČ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.).

30

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.

31

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

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

Najjednostavniji je slučaj kada klijent putem mreže pristupa sa svog računala poslužitelju datoteka, pri čemu zahtjeva isporuku određenog sadržaja datoteka. Poslužitelj datoteka omogućava dijeljenje istih datoteka među različitim korisnicima odnosno klijentima. Poslužitelju baza podataka klijent uobičajeno upućuje poruke uporabom upitnih jezika (SQL ili Structured Query Language). Iako se upotrebljava u svim vrstama sustava, ovakav oblik klijentsko poslužiteljske arhitekture nužan je preduvjet za sustav potpore poslovnom odlučivanju. Poslužitelji transakcija koriste se pri obradi podataka iz baza podataka, na način da nude klijentima uporabu posebnih procedura kojima se omogućava komuniciranje podacima tipa zahtjev - odgovor. Koristi se kod složenijih transakcija nad bazom podataka. Poslužitelji skupina podržavaju razmjenu polustrukturiranih informacija s klijentima (tekstovi, slike, elektronička pošta). Oni omogućavaju direktnu komunikaciju među klijentima koji čine skupinu, bilo u lokalnoj mreži bilo na Internetu. Poslužitelj objektnih aplikacija koristi se kada se klijentsko poslužiteljska aplikacija piše u obliku skupa objekata. Za implementaciju ovog oblika klijentsko poslužiteljske arhitekture koriste se posebni softveri (od kojih je danas najpoznatiji programski paket pod nazivom CORBA). Prva globalna implementacija klijentsko poslužiteljske arhitekture je Internet sa svojim World Wide Web servisom, poznata pod nazivom poslužitelj Web aplikacija. Informacijski centar nastaje zbog razdvajanja operativnih od razvojnih aktivnosti pri razvoju i korištenju informacijskih sustava i formira se kao posebna organizacijska jedinica27 unutar distribuiranog informacijskog sustava. Uloga informacijskog centra je u pružanju savjetodavnih usluge korisnicima, usluga tehničke potpore i ekspertnih znanja potrebnih za ostvarivanje pristupa traženim sadržajima distribuirane baze podataka, te u razvijanju vlastitih aplikacija uz korištenje standardnih pomagala. Zbog velikog broja korisnika različitih informatičkih predznanja i potreba, informacijski centar nužan je u velikim i složenim poslovnim sustavima.

26 prema Panian, Ž.: Kontrola i revizija informacijskih sustava, str. 307.-308, Sinergija-nakladništvo d.o.o. Zagreb, 2001. 27 Koncept informacijskog centra uveden je kako bi se prevladalo stalna netrpeljivost i loša komunikacija između informatičara i korisnika njihovih usluga.

32

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 Tržištem upravljana 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

• 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

Obilježja skladišta podataka

• 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

• 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

Tip skladišta podataka

Vertikalni ustroj skladišta podataka Horizontalni ustroj skladišta podataka

Organizacija IS

Zvjezdasta organizacija informacijskog sustava

Hibridna ili puna mrežna organizacija informacijskog sustava

Tablica 5.:Organizacijska kultura i organizacija informacijskog sustava

33

2.3. Organizacijska zrelost i planiranje razvoja informacijskog sustava

Nolanova podjela faza informatičkog razvoja poduzeća

Faze životnog ciklusa informacijskog sustava Informacijski inženjering

Elementi jedinstvenosti informacijskog sustava 2.3.1. Nolanova podjela faza informatičkog razvoja poduzeća Svaki organizacijski sustav odnosno poslovni sustav ima svoj informacijski (pod)sustav. Organizacijski razvoj poduzeća ovisi o tehnološkoj razini informacijskog sustava, ali i utječe na nj, i obrnuto. U pojedinim fazama informatika prethodi promjenama u organizaciji (uvođenje računala u poslovanje izaziva tehnološke promjene koje utječu na organizacijsku razinu poduzeća), dok u drugima informatika zaostaje za organizacijom (sporo reagiranje informacijskog sustava na promjene nastale pod utjecajima iz okruženja poduzeća). Ne treba, međutim, zaboraviti da:

• informatizacija poduzeća nije sama sebi svrha, i da je • informatizacija poduzeća podproces komunikacijske razine poduzeća.

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

Informacijska razina poduzeća glede uporabe informacijske tehnologije definirana je Nolanovom podjelom na šest faza razvoja informacijskog sustava odnosno organizacije podataka29:

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

28 Čurčić, Grabowski, Štahan: Kako napraviti razvojni program i elaborat o procjeni vrijednosti poduzeća, TEB, Zagreb, 1992. 29 Martin, J. i McClure, C.: Software Maintenance: The Problem and Its Solution, Prentice Hall, Englewood Cliffs, NY, 1985.

34

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.

35

FAZE

SKUP APLIKACIJA

ORGANIZACIJA

OBRADE PODATAKA

PLANIRANJE I

KONTROLA PODATAKA

ULOGA

KORISNIKA

Faza I Uvođenje

Ograničene,

pojedinačne aplikacijepo 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 Povezivanje (integracija)

Prilagodba postojećih aplikacija uporabom

tehnologije baza podataka

Afirmiranje korisnosti

računala i uvođenje

korisnika u timove

Povezano planiranje i

kontrola sustava

Odgovornost za podatke ovisi

o pojedincu odnosno korisniku

Faza V Sređivanje

(administracija podataka)

Organizacijska

integracija aplikacija

Administracija podataka

Dijeljeni podaci

i zajednički sustavi

Efektivna

odgovornost korisnika

Faza VI Zrelost

Integriranje

informacijskih tokova kroz aplikacije

Upravljanje resursima

podataka

Strategijsko planiranje

resursa podataka

Prihvaćanje korištenjazajedničkih 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.

36

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,

37

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

Brzo zastarijevanje tehnološke osnovice koju je problem održavati i čije karakteristike ne zadovoljavaju sve veće potrebe korisnika (nedovoljan kapacitet računala, neodgovarajuća programska pomagala, nemogućnost povezivanja s računalima novih generacija) razlog je nabavi opreme odgovarajuće tehničke razine.

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

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

2.3.2. Faze životnog ciklusa IS

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

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

Metode se primjenjuju određenim slijedom, uglavnom u redoslijedu faza životnog ciklusa informacijskog sustava. Razni autori navode razne faze životnog ciklusa informacijskog sustava.

32 Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997. 33 prema Pavlić, M.: Razvoj informacijskih sustava, Znak, Zagreb, 1996.

38

Osnovni tijek razvoja, izgradnje i korištenja informacijskog sustava u svim modelima je istovjetan i jasno naglašava ograničen vijek informacijskog sustava (prikazan na slici 16.)34:

• strateško planiranje odnosno utvrđivanje strategije poslovanja; • analiza strukture realnog poslovnog sustava, njegovih procesa i podataka; • oblikovanje informacijskog sustava koje sadrži:

• logičko modeliranje podataka i procesa informacijskog sustava, • fizičko modeliranje baze podataka, procedura i programa;

• izvedba programske podrške, komunikacija, korisničkog sučelja; • izrada korisničke dokumentacije; • uvođenje informacijskog sustava u primjenu; • održavanje i prilagođavanje informacijskog sustava.

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

2.3.3. Informacijski inženjering Pojam "informacijski inženjering" prvi put su upotrijebili početkom sedamdesetih J. Martin i C. Finkelstein za inženjerski pristup izgradnji informacijskog sustava35: «Informacijski inženjering je skup međusobno povezanih formalnih tehnika planiranja, analize, dizajna i konstrukcije informacijskog sustava cijelog poduzeća ili njegovih dijelova". Osnovne postavke informacijskog inženjeringa su orijentacija korisnicima, isticanje važnosti planiranja informacijskog sustava, usklađivanje razvoja informacijskog sustava s ciljevima organizacijskog sustava, analiza objektnog sustava, izgradnja jedinstvenog modela podataka koji omogućava stabilnost strukture podataka i dijeljenje podataka među raznim aplikacijama (primjena principa neovisnosti podataka), povezivanje modela podataka i modela procesa i povećanje produktivnosti korištenjem suvremenih razvojnih okolina koje uključuje jezike četvrte generacije i pomagala za projektiranje i razvoj informacijskih sustava (CASE pomagala).

Informacijski inženjering definira četiri osnovne faze razvoja informacijskog sustava: • strateško planiranje informacijskog sustava, • analizu poslovnog područja, • dizajn sustava (oblikovanje), i • konstrukciju (izradu) sustava.

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

39

Slika 16. Faze životnog ciklusa informacijskog sustava

Upravljanje poslovnimsustavom:

Odluka o izgradnji IS-a(početak i kraj ciklusa)

Strateško planiranje

Studija izvodljivosti

Analiza funkcijaposlovnog sustava

Osnovna arhitekturaIS-a

Oblikovanje IS-a

Izvedba programskepodrške, komunikacija,

korisničkog sučelja

Izrada korisničkedokumentacije

Uvođenje novog IS-a

Održavanje novog IS-a

Praćenje učinaka

Prilagođavanje novogIS-a

Poslovniciljevi

Planovirazvoja

Izabranastrategija

Prijedlozi

Uočenepotrebe izahtjevi

Redovnipostupci

Matricaposlovne

tehnologije

Redoslijedprioritetarazvoja

Redovnokorištenje

Programidokumentacija

resursi

Model podatakaModel procesa

.....

Programi,ekranske slike

....

40

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.

41

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.

42

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”).

43

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

44

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

45

U praksi se koriste metodike koje kombiniraju dva ili sva tri navedena pristupa. Na slici 18. prikazano je nekoliko glavnih tehnika modeliranja te njihovo preklapanje39.

Svaki od modela stvarnog svijeta mora se uklopiti u kontekst cjelokupnog poslovnog stremljenja, koje je izraženo ciljevima, prioritetima i kritičnim čimbenicima uspjeha poslovnog sustava. Izbor metodologije rada na razvoju i dokumentiranju informacijskog sustava često je unaprijed određen bilo znanjima i iskustvom projektanta, bilo dostupnim programskim pomagalom CASE za projektiranje i razvoj informacijskog sustava. Svaka od metodika ima svoje prednosti i mane, no unatoč tome ako se dosljedno provode rezultat je uspješan i kvalitetan informacijski sustav.

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

• klasične, opće poslovne, kao što je, primjerice, BSP (Bussiness System Planning), koja je dobra ali suviše općenita za brzu primjenu;

• klasične strukturne, primjerice metodika SSADM, koja je veoma detaljna i razrađena;

• podatkovno usmjerene, primjerice Oracle-ov skup metoda pod nazivom CASE*Method, ili informacijski inženjering J. Martina;

• procesno usmjerene, primjerice BPR (Bussiness Process Reengineering). Osnovne osobine nekoliko karakterističnih metodika biti će ovdje prikazane samo informativno. BSP (Bussiness System Planning) je metodika koju je definirao IBM i počeo ju komercijalno primjenjivati još sedamdesetih godina. Poslužila je kao uzor svim kasnijim metodikama. Sadrži tri osnovne grupe dokumenata kojima je opisano:

• modeliranje podataka (određivanje klasa podataka), • modeliranje funkcija (funkcionalno raščlanjivanje odnosno dekompoziciju funkcija, te

opis procesa), • modeliranje ciljeva (strukturno raščlanjivanje ciljeva, kritičnih pretpostavki i njihovo

povezivanje s podacima i procesima). BSP se primjenjuje samo u fazi strateškog planiranja informacijskog sustava. SSADM40 (Structured Systems Analisys and Design Method) je metodika razvijena u Velikoj Britaniji koja je 1983. godine postala standard za vladine projekte. Tijekom godina postala je i standard kojeg primjenjuje veliki broj informatičkih kuća.

SSADM je cjelovita metodika, detaljno opisuje pristup razvoju i propisuje predložak razvojnog ciklusa i procesa razvoja. Za svaku fazu propisuje metodu i tehniku, ulazne parametre i izlazne rezultate. Podržana je većinom CASE pomagala.

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

46

Metodikom SSADM određeno je sedam faza razvoja informacijskog sustava:

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

Svaka faza sastoji se od dva ili više stupnjeva, a svaki stupanj od više koraka. Struktura faza i stupnjeva je hijerarhijska, a koraka (aktivnosti) mrežna, što znači da se više koraka može odvijati paralelno.

Ova metodika se neprekidno razvija. Registrirana je kao "Certification Trade Mark" tako da organizacije koje ovu metodiku službeno koriste moraju imati licencu Central Communications and Telecommunications Agency (CCTA).

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

U CASE*Method (skup metodika tvrtke Oracle) sistematiziran je postupak definiranja arhitekture informacijskog sustava koji uključuje sljedeće aktivnosti41:

• Identificirati poslovne potrebe i logičke zavisnosti;

• Izabrati aplikacijska područja i granice informacijskog sustava (podsustava) u odnosu na model funkcija;

• Ispitati postojeće informacijske sustave da se odredi njihova buduća primjenjivost, koegzistencija i povezanost, te prikupiti informacije o obujmu i frekvenciji;

• Identificirati moguće tehnologije;

• Identificirati moguća alternativna rješenja za svako aplikacijsko područje, ispitati izvedivost svakog od njih i prihvatiti ili odbaciti ona koja su tehnički ili ekonomski neisplativa;

• Prikazati, raspraviti i prihvatiti određenu arhitekturu sustava;

• Izraditi preporuke za rekonstrukciju postojećeg ili izgradnju budućeg informacijskog sustava, promjenu poslovanja, organizacije ili bilo kojeg drugog područja, što se utvrdi raspravama.

Ovaj postupak se uz modifikacije primjenjuje u svim metodologijama koje se koriste u fazi strateškog planiranja informacijskog sustava42.

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

47

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

48

Prije informatizacije bilo kojeg procesa uz primjenu ove metodike potrebno je utvrditi da li taj proces treba mijenjati, proširiti ili ukinuti. Posljedice na organizaciju poslovnog sustava su značajne, pa je i prikriveni otpor provođenju poslovnog reinženjeringa velik44.

SPIS45 (Strateško planiranje informacijskih sustava) je skup metoda koje preporuča prof.dr.sc. Brumec u fazi strateškog planiranja IS-a. Obuhvaća već poznate metode i tehnike, sa naglaskom na to ŠTO treba uraditi, a ne KAKO to uraditi.

Značajke ove metodike su da je za izradu strateškog plana potrebna suradnja i suglasnost svih učesnika o elementima sadržaja plana.

Plan mora biti izrađen u kratkom roku (1-3 mjeseca) i mora biti izrađen u takvom obliku da se sve činjenice koje su u njemu utvrđene mogu koristiti u sljedećim fazama razvoja informacijskog sustava.

MIRIS46 (Metodika za razvoj informacijskih sustava) je još jedna metodika hrvatskih autora koju je uveo dr.sc. Pavlić. Njome se ukupan posao razvoja informacijskog sustava dijeli na logičko i fizičko oblikovanje informacijskog sustava.

Pri tomu logičko oblikovanje sadrži strateško planiranje informacijskog sustava, izradu glavnog projekta te izvedbeni projekt.

Fizičko oblikovanje čini izvedba programske podrške, uvođenje i primjena novog informacijskog sustava, te njegovo održavanje.

Koristi se otprije poznatim metodama i tehnikama.

Primjenom svih navedenih metodika (kao i onih koje nisu ovdje ukratko opisane) trebao bi se polučiti rezultat u obliku dokumenta koji sadrži:

• Sažete preporuke poslovodstvu (posebno prioritete vezane uz poslovne ciljeve te koji su kritični faktori uspjeha),

• Temeljnu arhitekturu informacijskog sustava, • Granice sustava, • Promjene u organizaciji i poslovnoj tehnologiji koje se očekuju, • Model procesa, • Model podataka, • Model resursa, te • Plan realizacije po fazama.

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

49

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

50

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.).

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")

POSLOVNASTRATEGIJA

Postavlja i mijenja ciljeveDonosi poslovne odluke

IS STRATEGIJA

Polazi od poslovanjaBavi se aplikacijama

IT STRATEGIJA

Polazi od aktivnostiBavi se tehnologijom

Smjernice za poslovanja

Potrebe i prioriteti

Podrška poslovanju

Tehnološka infrastruktura

Kamo ide poslovanje izašto?

Što je potrebno za ostvariticiljeve?

Kako to ostvariti?

Utjecaj IT

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

51

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».

52

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.

53

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.

54

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.

55

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!».

56

• 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.

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

Poslovni sustav

Prodajni razgovor

Proces

Pravni poslovi

Proces

Ugovaranje

Proces

Financije

Proces

Prodaja

Funkcija

Administracija

Funkcija

Proizvodnja

Funkcija

Potpisivanjeugovora

Procedura

Izrada ugovora

Procedura

Pohranjivanjeugovora

Procedura

Evidentiranjeugovora

Procedura

. . . . . . . .

. . . .

. . . . . . . .

57

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.

Slika 22. Primjer dekompozicije procesa (vodoravni prikaz)

Slično vodoravnom prikazu, dekompozicija se može prikazati Warnier-Orrov-im dijagramom (slika 23.):

54 Klasić, K. Modeli optimizacije strukture informacijskog sustava, doktorska disertacija, FOI Varaždin, 1998. 55 Radovan, M: Projektiranje informacijskih sistema, Informator, Zagreb, 1989.

Proces 0

Proces 1.

Proces 2.

Proces 3.

Proces 2.1.

Proces 2.2.

Proces 2.3.

Proces 2.4.

58

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

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

Skup S

Skup X

SkupaSkup b

Skup eSkup

z

S

e X z

a b

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.

Proces 1.

Proces 2.

Proces 3.

Proces 0.Proces 2.1.

Proces 2.2.

Proces 2.3.

59

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.

60

Matrica poslovne tehnologije izrađuje se pri strateškom planiranju informacijskog sustava, pri čemu se pri analizi postojećeg sustava iskazuje postojeća poslovna tehnologija, nakon provedenog preoblikovanja poslovnih procesa željena poslovna tehnologija, a nakon određivanja strukture informacijskog sustava operativno prihvatljiva poslovna tehnologija.

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

Slična je pojava i s popunjavanjem stupaca matrice poslovne tehnologije. U stupce se upisuju klase podataka odnosno entiteti koje određeni proces koristi. U praksi se popisuju dokumenti koji se koriste u sustavu i njih se proglašava klasama podataka. Time se analitičar sustava, posebno ako od ranije ne poznaje djelatnost promatranog sustava, upoznaje s poslovnom tehnologijom i podacima koje će trebati čuvati u novom informacijskom sustavu. Već sada treba naglasiti da se dokumenti (odnosno klase podataka) kojima se popunjavaju stupci matrice poslovne tehnologije mogu značajno razlikovati od entiteta kojima se također matrica popunjava u kasnijoj fazi izrade. Razlika proizlazi iz činjenice da je klasa podataka poslovna kategorija, a entitet informatička, pa stoga jedna klasa podataka može biti prikazana s jednim ili više entiteta58.

Stoga, dok matrica poslovne tehnologije prikazuje redoslijed odvijanja procesa u poslovnom sustavu i uvijek je ista za isti poslovni sustav (nakon što se usuglasi poslovna tehnologija), matrica procesi/entiteti koje prikazuju arhitekturu informacijskog sustava može biti puno.

Presječna polja matrice poslovne tehnologije popunjavaju se oznakama koje opisuju aktivnosti procesa nad entitetima:

• C/D (stvaranje/brisanje entiteta, engl. Create/Delete),

• U (ažuriranje entiteta, engl. Update),

• R (čitanje, pretraživanje entiteta, engl. Read) i

• “prazno” odnosno ∅ (kada proces ne vrši operaciju nad entitetom). Umjesto ∅ često se koristi i oznaka 0.

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

61

PRIMJER: Neka je definiran sustav od 12 procesa i 9 entiteta. Operacije procesa nad entitetima opisane su u tablici 7. Podacima iz tablice veza procesa i entiteta popunjava se matrica procesi/entiteti odnosno matrica poslovne tehnologije (tablica 8.).

ENTITET Stvaranje/brisanje Ažuriranje Pretraživanje

E1

p10

p6, p11

p1, p2, p5, p8

E2

p3

---

p4, p7, p9

E3

p1

p8

p2, p4, p5, p6, p7, p10

E4

p2

p12

p4, p6, p11

E5

p4

p1

p5, p7, p8, p10, p12

E6

p6

p4, p10

p9, p12

E7

p5

p8

p7, p11, p12

E8

p6

p7, p12

p1, p2, p4, p5, p10

E9

p9

----

p1, p6, p8, p11

Tablica 7.: Veze procesa i entiteta (primjer)

Matrica poslovne tehnologije popunjava se na način da se u retke upišu svi procesi bilo kojim redom, pazeći da se neki ne izostavi. Entiteti se upišu u stupce redom kojim su navedeni u tablici ulaznih podataka. Zatim se upisuju oznake aktivnosti u presječna polja matrice. Obično su oznake aktivnosti definirane u ulaznim podacima. Međutim, može se dogoditi da je neka oznaka pogrešno navedena ili da postoje nelogičnosti u obavljanju poslovnih procesa koje se očituju tek pri popunjavanju matrice. Stoga se analitičar sustava mora pridržavati formalnih pravila za popunjavanje matrice poslovne tehnologije, koja se mogu jednostavno opisati59:

• Jedna se klasa podataka generira (nastaje) samo u jednom procesu. Ako klasa podataka nastaje u više različitih procesa upitna je nadležnost i odgovornost za podatke, kao i njihova točnost. U poslovanju to znači zbrku u poslovanju jer se krivnja za loše manipuliranje određenim dokumentom najčešće prebacuje s jedne osobe na drugu.

• Jedna se klasa podataka može koristiti u više procesa. Dokument nastao jednim procesom može biti korišten u više drugih, kasnijih procesa.

• Proces koji samo koristi, a ne generira nijednu klasu podataka je “parazitski” ili radi za okruženje. Primjer takvih procesa su razni izvještaji koji se sastoje od na određeni način sortiranih i pristupačno prikazanih podataka koji su nastali ranije u sustavu.

59 Brumec, J: Optimizacija strukture informacijskog sustava, Zbornik radova, FOI Varaždin, 1993.

62

• Proces koji samo generira, a ne koristi nijednu klasu podataka treba posebno analizirati. Stvaranje nove klase podataka prihvatljivo je ako se radi o temeljnim podacima koje treba pratiti (često se u praksi zovu matičnim podacima). Ponekad to mogu biti procesi koji preuzimaju iz nekog drugog informacijskog sustava podatke koji se dalje koriste u poduzeću. S obzirom da se radi o različitim izvorima podataka, različite točnosti i načina nastanka, svaki takav pojedinačni slučaj treba posebno razmotriti i analizirati.

• Ne može postojati proces ni klasa podataka bez ijedne oznake operacije procesa nad klasom podataka. Može se dogoditi da je došlo do greške u pripremi ulaznih podataka, ali isto tako može biti slučaj da doista postoji greška u poslovnoj tehnologiji promatranog poduzeća koju treba ispraviti.

E1

E2

E3

E4

E5

E6

E7

E8

E9

p1

R

C/D

U

R

R

p2

R

R

C/D

R

p3

C/D

p4

R

R

R

C/D

U

R

p5

R

R

R

C/D

R

p6

U

R

R

C/D

C/D

R

p7

R

R

R

R

U

p8

R

U

R

U

R

p9

R

R

C/D

p10

C/D

R

R

U

R

p11

U

R

R

R

p12

U

R

R

R

U

Tablica 8.: Matrica poslovne tehnologije (primjer)

Iz navedenog proizlaze svojstva koje matrica poslovne tehnologije mora zadovoljavati:

• Matrica mora biti m x n – tog reda, što znači da predstavlja sustav s m procesa i n entiteta. Broj procesa u pravilu se razlikuje od broja entiteta60.

• Svaki redak matrice sadrži potpun skup entiteta koji pripada jednom procesu.

60 U praksi je broj procesa višestruko veći od broja entiteta.

63

• 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

64

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.

65

Početna matrica poslovne tehnologije prikazana je na tablici 8. za primjer zadan ulaznim podacima iz tablice 7. Dijagonalizirana matrica poslovne tehnologije tada može biti prikazana različitim tablicama (tablice 9. i 10.).

E3

E5

E7

E1

E2

E9

E4

E6

E8

p1

C

U

R

R

R

p4

R

C

R

R

U

R

p5

R

R

C

R

R

p7

R

R

R

R

U

p8

U

R

U

R

R

p10

R

R

C

U

R

p11

R

U

R

R

p12

R

R

U

R

U

p3

C

p9

R

C

R

p2

R

R

C

R

p6

R

U

R

R

C

C

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

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

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

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

66

E3

E5

E7

E1

E2

E9

E4

E6

E8

p1

C

U

R

R

R

p4

R

C

R

R

U

R

p5

R

R

C

R

R

p7

R

R

R

R

U

p8

U

R

U

R

R

p10

R

R

C

U

R

p11

R

U

R

R

p12

R

R

U

R

U

p3

C

p9

R

C

R

p2

R

R

C

R

p6

R

U

R

R

C

C

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

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

} p ,p ,p ,p ,p ,p ,p ,p { = S 121110875411 , } p ,p { = S 622 i } p ,p { = S 933 , pa je

S S S = S 321 ∪∪ .

U tablici 10. prikazan je isti poslovni sustav (prikazan istom matricom poslovne tehnologije), ali drugačiji informacijski sustav, jer je sastavljen od dva podsustava:

} p ,p ,p ,p ,p ,p ,p ,p ,p ,p { = S 12111098754311 i } p ,p { = S 622 pa je S S = S 21∪ .

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.

67

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:

(KHS)i = ee iu

može se utvrditi da je kohezija unutar svih podsustava u prvoj varijanti (KHS)1 = 5431 , a u

drugoj (KHS)2 = 5436 . Iz navedenog proizlazi da je (KHS)1<(KHS)2.

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 ∝ ∑i

iKHS

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.

68

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

69

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.

70

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.

71

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,

Matrica procesi/entiteti koja opisuje ova zbivanja je:

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

Slika 25. Primjer za izračun koeficijenta sklonosti procesa

64 Martin, J: Information Engineering: Introduction, Prentice Hall, Englewood Cliffs, NY 1990. 65 Posebno zato što je podržana CASE pomagalima.

pi pj

E1 E2 E8

E1 E3 E7

E8 E7

E1 E4 E5 E6

72

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 p i i p j :

)(),(

),(i

jiji pn

ppnppA =

Stoga se može i za primjer izračunati koeficijente sklonosti:

%6010060

2020

53

==⋅=) p( n

) p ,p( n = ) p ,p( A

i

jiji

%5010050

5050

21

63

==⋅==) p( n

) p ,p(n = ) p ,p( A

j

ijij

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).

10 ≤≤ ) p(n

) p ,p(n = ) p ,pA(

i

jiji

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:

• 1),(0 ≤≤ ji xxs ,

• 1),( =ii xxs , • ),(),( ijji xxsxxs = , Xxx ji ∈∀ ,

73

Proces

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

p1

...

pi 100 60

...

pj 50 100

...

Slika 26. Primjer asimetrične matrice sklonosti procesa

Stoga je koeficijent sklonosti poslužio kao polazište za definiciju modificiranog koeficijenta sklonosti procesa67. Kako je modificirani koeficijent sklonosti mjera sličnosti, njime se inducira parcijalno uređenje u promatranom skupu procesa odnosno procesi su u informacijskim podsustavima poredani slijedno. Neka je n ( p i ) broj ulaznih i izlaznih entiteta procesa p i , i neka je n ( p i , p j ) broj zajedničkih entiteta koje imaju procesi pi i p j . Modificirani koeficijent sklonosti definira se kao:

2

) p ,pA( ) p ,pA( = ) p ,p( A ijji

ji

+′ ,

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

2

) p(n

) p ,p(n

) p(n

) p ,p(n

= ) p ,p( A j

ij

i

ji

ji

+

′ ,

iz čega slijedi:

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

74

) p(n) p(n

) ) p(n) p(n() p ,p(n = ) p ,p( A

ji

ijjiji ⋅⋅

+⋅′

2 .

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

) p( n) p( n2

) p( n + ) p( n ). p ,p( n = ) p ,p( A

ji

jijiji ⋅⋅

′

Ako se sada za prethodni primjer izračunaju modificirane koeficijente sklonosti između procesa p i i p j rezultat je:

%5510055

55

2011

652653 2

1 ==⋅=/⋅⋅

+/′ = ) p ,p( A ji ,

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

Proces

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

p1

...

pi 100 55

...

pj 55 100

...

Slika 27. Primjer simetrične matrice sklonosti procesa

Može se izračunati i modificirani koeficijent sklonosti procesa p

k prema roju odnosno informacijskom podsustavu Rij kao:

) p ( n + ) p ( n

) p ( n) p ,p ( A + ) p ( n) p ,p ( A = )R ,p ( A

ji

jjkiikj ,ik

⋅′⋅′′

75

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.

• S p S p kjij ∉∈ _ , za i , k = 1...s , j = 1....m i k i ≠ odnosno ∅∩ = S S ki

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

• Broj mogućih podsustava s informacijskog sustava S je 2m < s< 1 (jer jedan podsustav

ne smije sadržavati samo jedan proces). Za sustav S = S ii∪ , gdje je S i i - ti podsustav

sustava S, prihvaćeno je organizacijsko pravilo " 47 ± ", pa vrijedi ograničenje [3,11] i∈ .

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.

76

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:

⎪⎩

⎪⎨⎧

∅≠∀

∅∀

e f

= e 0 = F

ji,ji,

ji,ji,

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:

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

Značaj informacijske veze z i , j ovisi o vrsti odnosa između procesa i entiteta (neophodna, važna, dopunska informacija). Jakost informacijske veze ω j ,i opisuje aktivnosti koju obavlja proces nad entitetom (C, R, U, D). Frekvencija odnosno učestalost ν j ,i 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 , ω j ,i i ν j ,i , 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:

⎪⎪⎩

⎪⎪⎨

⎧

uinformacij neophodnu kao E treba p da znaci1

uinformacijvaznu kao E treba p da znaci0,7

uinformacijdopunsku kao E treba p da znaci0,4

= z

ji

ji

ji

j ,i

68 Osnovne pojmovi metode uvedeni su u Brumec, J: Optimizacija strukture informacijskog sustava, Zbornik radova, FOI Varaždin, 1993.

77

⎪⎪⎪

⎩

⎪⎪⎪

⎨

⎧

∀

∀

∀

∅∀

D C, = e 1

U = e 0,7

R = e 0,4

= e 0

=

j ,i

j ,i

j ,i

j ,i

j ,iω

⎪⎪⎪⎪

⎩

⎪⎪⎪⎪

⎨

⎧

dnevno) puta (mnogo aktivnosti ceste izuzetno za1

(dnevne) aktivnosti ceste za0,8

(tjedne) aktivnosti ceste relativno za0,6

(mjesecne) aktivnosti rijetke za0,4

(godišnje) aktivnosti rijetke izuzetno za0,2

= j ,iν

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 - SF = F i

s

1 = i∑

gdje je F = SF j ,i

n

l =j

m

1 = i∑∑ informacijska funkcija sustava, a F = S F j ,i

r + l

l =j S ii

ss

i

∑∑∈

informacijska funkcija i-tog podsustava. Informacijska funkcija i-tog podsustava je zbroj informacijskih funkcija elemenata submatrice kojom je prikazan podsustav Si :

F = S F j ,i

r + l

l =j S ii

ss

i

∑∑∈

78

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

l s 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

1,

3

11

iji

jFFS , ∑∑

= =

=5

4,

5

42

iji

jFFS , ∑∑

= =

=n

iji

m

jFFS

6,

63 .

Tada je mjera kvalitete strukture informacijskog sustava ∑∑∑== =

−=3

11,

1 ii

n

iji

m

jFSFF .

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.

79

Tada vrijedi TEOREM:

Neka je S F - SF = F i

s

1 = i∑ . Tada ako informacijska funkcija unutar svakog od

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

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

Načelni postupak određivanje optimalne strukture informacijskog sustava primijenjen u ovoj metodi je sljedeći: • popuniti početnu matricu poslovne tehnologije podacima o procesima, entitetima i

njihovim vezama; • izračunati informacijsku funkciju F i, j za svaki element matrice; • za prvi redak matrice preseliti nalijevo onaj stupac za koji informacijska funkcija elementa

matrice ima najveću vrijednost, za drugi redak matrice ponoviti postupak i preseliti stupac nalijevo, na prvo sljedeće mjesto itd.;

• izračunati informacijsku funkciju sustava FS; • izračunati informacijsku funkciju svakog tako formiranog podsustava FS i ; • izračunati mjeru kvalitete strukture sustava F.

PRIMJER:

Može se pretpostaviti da, osim različite jakosti informacijske veze, postoje i podaci o iznosu značaja informacijske veze te učestalosti aktivnosti procesa nad entitetom. U tom slučaju koristi se početna matrica poslovne tehnologije proširena s dodatnim podacima, koja je prikazana na slici 29. Pri tome se koriste oznake za značaj informacijske veze:

n = nužna (neophodna) informacija, v = važna informacija, d = dopunska informacija,

i učestalost:

g = jednom (ili samo nekoliko puta) u godini odnosno godišnja aktivnost, m = mjesečna aktivnost, t = tjedna aktivnost, d = dnevna aktivnost, č = česta, odnosno aktivnost koja se ponavlja više puta dnevno.

U skladu s načelnim postupkom za određivanje optimalne strukture informacijskog sustava potrebno je izračunati iznose informacijskih funkcija elemenata matrice (slika 30.).

80

E1

E2

E3

E4

E5

E6

E7

E8

E9

p1 R,v,d

C,n,d

U,n,d

R,d,č

R,v,d

p2

R,v,d

R,d,č

C,n,t

R,d,t

p3

C,n,g

p4

R,n,č

R,d,d

R,d,d

C,n,t

U,n,č

R,d,č

p5

R,v,d

R,v,č

R,d,d

C,n,d

R,v,t

p6

U,n,č

R,n,d

R,v,d

C,n,d

C,n,m

R,v,t

p7

R,d,č

R,d,č

R,d,t

R,v,č

U,n,d

p8

R,d,č

U,n,č

R,v,č

U,n,č

R,d,t

p9

R,d,d

R,v,č

C,n,d

p10

C,n,d

R,n,č

R,n,t

U,n,č

R,v,d

p11

U,n,d

R,v,č

R,d,č

R,d,d

p12

U,n,t

R,d,č

R,v,m

R,n,m

U,n,t

Slika 29. Proširena matrica poslovne tehnologije

E1

E2

E3

E4

E5

E6

E7

E8

E9

p1

0,224

0,8

0,56

0,16

0,224

p2

0,224

0,16

0,6

0,096

p3

0,2

p4

0,4

0,128

0,128

0,6

0,7

0,16

p5

0,224

0,28

0,128

0,8

0,168

p6

0,7

0,32

0,224

0,8

0,4

0,168

p7

0,16

0,16

0,096

0,28

0,56

p8

0,16

0,7

0,28

0,7

0,096

p9

0,128

0,28

0,8

p10

0,8

0,4

0,24

0,7

0,224

p11

0,56

0,28

0,16

0,128

p12

0,42

0,16

0,112

0,16

0,42

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

81

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

E4

E6

E3

E5

E7

E8

E1

E2

E9

p2

0,6

0,16

0,096

0,224

p6

0,224

0,8

0,32

0,4

0,7

0,168

p1

0,8

0,56

0,16

0,224

0,224

p4

0,128

0,7

0,128

0,6

0,16

0,4

p5

0,28

0,128

0,8

0,168

0,224

p7

0,16

0,096

0,28

0,56

0,16

p8

0,7

0,28

0,7

0,16

0,096

p10

0,7

0,4

0,24

0,224

0,8

p11

0,28

0,16

0,56

0,128

p12

0,42

0,112

0,16

0,16

0,42

p3

0,2

p9

0,28

0,128

0,8

Slika 31. Optimalna struktura informacijskog sustava (varijanta 1.) Informacijska funkcija sustava iznosi FS = 18,74, a informacijske funkcije pojedinih podsustava: FS1 = 1,624, FS2 = 10,292, FS3 = 1,128.

Za navedeni izbor vrijednosti parametara mjera kvalitete strukture sustava iznosi F = 5,696. Maksimalni iznosi nalaze se na dijagonali matrice i oko nje (u ovom primjeru ni jedan ne iznosi 1).

Optimalna struktura sustava je tada:

S = { p 2 , p 6 } ∪ { p 1 , p 4 , p 5 , p 7 , p 8 , p 10 , p 11 , p 12 } ∪ { p 3 , p 9 } . Ako se s E označi skup entiteta koji pripada skupu procesa S, onda je struktura skupa entiteta koja pripada optimalnoj strukturi informacijskog sustava:

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

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

82

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

E4

E6

E8

E3

E5

E7

E1

E2

E9

p2

C

R

R

R

p6

R

C

C

R

U

R

p1

R

C

U

R

R

p4

R

U

R

R

C

R

p5

R

R

R

C

R

p7

U

R

R

R

R

p8

U

R

U

R

R

p10

U

R

R

R

C

p11

R

R

U

R

p12

U

R

U

R

R

p3

C

p9

R

R

C

Slika 32. Struktura informacijskog sustava (varijanta 2.)

Ukoliko se u presječna polja matrice poslovne tehnologije sa slike 32. unesu iznosi informacijskih funkcija sa slike 30., lako se može izračunati mjera kvalitete strukture informacijskog sustava.

U ovom slučaju je struktura i skupa entiteta drugačija od one koja pripada optimalnoj strukturi informacijskog sustava:

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

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

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

83

Ako je kohezija unutar i-tog podsustava KHSi jednaka omjeru broja popunjenih polja unutar submatrica i ukupnog broja popunjenih polja matrice:

(KHS)i = ee iu

može se utvrditi da je kohezija unutar svih podsustava u prvoj varijanti (KHS)1 = 5435 , a u

drugoj (KHS)2 = 5431 . Iz navedenog proizlazi da je (KHS)1>KHS)2, što znači da je slikom 31.

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?

84

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.

85

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.

86

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.

87

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.

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).

Izvorište Odredište

Procestok podataka A tok podataka B

Spremište podataka

IzvorišteIzvorište

OdredišteOdredište

88

Procesrazina 0

Proces 1.

Proces 2.

Proces 3.

Proces 2. 1.

Proces 2. 2.

KONTEKST DIJAGRAM

Procesrazina 0

PROCESI RAZINE 1

Proces 1.

Proces 2.

Proces 3.

Proces 2. 2.

Proces 2. 1.

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

RAZINA 0.

RAZINA 1

RAZINA 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.

89

Slika35. Primjer dijagrama tijeka dokumenata

A. Ulazdokumenata i

priprema

B. Rad uurudžbenom

zapisniku

D. Uparivanjeunosa sa

urudžbenimzapisnikom

E. Izlazdokumenata

F. Izlaz informacija

C. Unos podatakau sustav

Pozivni centar

Pošta

Dostavljač

Internet

Fax

- prijave zasuradnike- ugovori- pisma namjere- ostala pošta

- ugovori- pismanamjere

dokumenti

evidentiranidokumenti

- prijave zasuradnike- pisama namjere

- prijave zasuradnike- pisma namjere

prijave zasuradnike

podaci idokumentii

izlazneliste

knjiga izlaznepošte

Bazapodataka

- prijave zasuradnike

- pisma namjere

90

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:

OdlukaDokument Ručna

operacija

Prekid Baza podatakaZaslon

Proces Spoj

Slika 36. Primjeri grafičkih simbola koji se koriste pri izradi radnog dijagrama Radni dijagram grafički prikazuje procedure rada koje ne moraju nužno biti automatizirane. Često se zaboravlja da postoje poslovi u sustavu koji iz raznih razloga neće biti informatizirani, a o kojima treba voditi računa kada se analizira sustav i projektira informacijski sustav. Radni dijagram prikazuje te procese i upozorava gdje je moguće kasnije «usko grlo» u poslovnoj tehnologiji. Dapače, na temelju razmatranja radnog dijagrama ponekad se mogu promijeniti redoslijedi prioriteta izgradnje informacijskih podsustava, jer se može lakše uočiti njihov utjecaj na cjelokupno poslovanje. Na slici 37. prikazan je radni dijagram za dio tehnologije rada u urudžbenom zapisniku mirovinskog fonda (za primjer sa slike 35.):

91

Slika 37. Primjer radnog dijagrama (varijanta 1.)

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

Ostala pošta?

A.1.Razdvajanje

pošte

A.2.1. Žigna

kovertu

No

Yes

A.2.2. Žigna

dokument

A.2.1.1.Sortiranje

A.2.2.1.Sortiranje(koverte +dokumenti)

Prijave zasuradnike? No

Yes

B.1. Evidentiranjepošte

B.2. Upisred. br.pošte

Potvrda oprimitku?

Yes

No

Kraj

Potvrda oprimitku

A.1.1. Ispispotvrde oprimitku

C.1. Unos podatakau sustav

C.2. Pohranadokumenata

C.3. Pripremai slanje

dokumenatapoštom

Jednostranopotpisan ugovor

Prijave zasuradnike?

Yes

No

Yes

No

Kraj

92

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.

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.

Urudžbeni zapisnik

-ugovori-pisma namjere

PC

Fax

INTERNET

Laser printer

- prijave za suradnike- ugovor- pisma namjere

prijave zasuradnike

- prijave za suradnike- pisma namjere

Pozivni centar

- prijave za suradnike- pisma namjere

knjiga izlazne pošte

93

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

uvesti standarde (ili ih preuzeti od aplikacije koja se najviše koristi u poduzeću ) i strogo ih se pridržavati

previše podataka za jednu ekransku sliku pa je nepregledna

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

nedostaju neki od podataka koji su definirani modelom podataka

neprekidno provjeravati model podataka i uspoređivati ga sa ekranskim slikama

pojavljuju se novi podaci koji nisu ranije definirani modelom podataka

neprekidno provjeravati model podataka i uspoređivati ga sa ekranskim slikama

podaci se pojavljuju na ekranskim slikama neusklađeno sa procedurom rada

provjeriti radne dijagrame i utvrditi razloge

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.

94

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.

95

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.

96

DD.MM.GGGG Pregled prisutnih vozila HH:MM:SS KPKNUI03 Reg. oznaka Stat.voz. Datum ulaza Vrijeme ulaza Tren.akt. ____________ __ ___________ _________ __ RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS U RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS A RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS U RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS R RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS A RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS S RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS R RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D F3-kraj F7-dolje F8-gore

PREGLED PRISUTNIH VOZILA

DD.MM.GGGG

HH:MM:SS Reg. oznaka Stat.voz. Datum ulaza Vrijeme ulaza Tren.akt. ____________ __ ___________ _________ __ RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS U RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS A RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR V DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS U RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS D RRRRRRRRRR P DD.MM.GGGG. HH:MM:SS R Izradio: _______________________

Slika 40. Primjeri izvješća

97

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.

98

U užem smislu rječnik podataka služi za upravljanje metapodacima, tj. značajkama podataka, ali ne i sadržajem opisanih podataka, dok su u širem smislu u rječniku podataka opisane sve vrste objekata u entitetima rječnika, zajedno s njihovim svojstvima (atributima) i vezama. Uz entitete podataka tada sadrže i procesne entitete (programske module, programe itd.). Tada je to centralizirano spremište informacija o opisima podataka, kao što su:

o značenje podataka, o odnosi prema ostalim podacima, o instance ili osobe zadužene za održavanje podataka, o izvori podataka, o ovlašteni korisnici, i o formati podataka.

Stoga rječnik podataka poslovodstvu ukazuje koji su podaci raspoloživi za podršku procesu odlučivanja, projektante obavještava postoje li potrebni podaci za novu aplikaciju u nekoj od postojećih baza podataka, programerima daje informacije o tome kakvi su formati postojećih slogova, struktura podataka i sl., a korisnicima koji su podaci raspoloživi i koji su njihovi nazivi.

Rječnik podataka je alat i proizvod administracije podataka, što znači da ju opskrbljuje informacijama o tome gdje se pojavljuje redundanca, gdje je prisutna nekonzistentnost podataka, kakve su strukture baza podataka na raznim platformama računala i u raznim aplikacijama, koja je verzija podataka pravovaljana, tko sve koristi bazu podataka i na kojoj razini zaštite podataka, te kako promjene u poslovnom procesu utječu na model podataka i implementirane baze podataka. Ujedno osigurava mogućnost usklađivanja i usporedbe podataka (osigurava kompatibilnost podataka) i pomaže pri održavanju integralnosti (jedinstvenosti) modela podataka poslovnog sustava.

Prvi rječnici podataka bili su pasivni, mogli su čuvati korisne informacije o podacima, no nisu imali mogućnost aktivnog udjela pri izvođenju transakcija.

Zatim su uvedeni rječnici podataka povezani s odgovarajućim sustavom za upravljanje bazama podataka čime su projektanti i programeri “natjerani” na poštivanje stroge standardizacije. Iako su informacije o podacima i njihovoj uporabi u takvim rječnicima podataka bile korisne informatičarima, za krajnje korisnike nisu bile razumljive i lako dostupne (slika 41).

Sustav baza podataka (SBP)

Bazapodataka

Sustav zaupravljanje bazompodataka (SUBP)

Korisnik

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

99

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)

Bazapodataka

Sustav zaupravljanje

bazom podataka(SUBP)

Krajnjikorisnik

Rječnikpodataka

SQL

Aplikacija

Korisnik(projektant, programer,

administrator)

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.

100

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.

101

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

Model podatakaposlovnog sustava

Poslovna tehnologijaposlovnog sustava

DISLOCIRANI RAZVOJNI CENTAR

Model podatakaaplikacije

Model procesaposlovnog podsustava

elementi poslovne tehnologije

podaci

dokumenti

distribucija entiteta, atributa i dijelom sadržaja entiteta konsolidacija

modela podatakapropisana tehnologija rada kontrola ispravnosti

tehnologije rada

distribucija podataka iz okruženja

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.

102

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.

103

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.

p o d a c i i z v r š i t e lj i

Faze razvoja projekta Poslovi Područja Projektant DA DBA Programer

Definiranje projekta Izrada dijagrama Analiza X

Definiranje zahtjeva i uporabe

Tijeka podataka podataka X X

Eksterno oblikovanje Izrada modela podataka X X baze podataka (logičko modeliranje)

Analiza uporabe podataka

X X X

Eksterno oblikovanje baze podataka (izrada logičkog modela baze)

Oblikovanje baze podataka

X X X

Interno oblikovanje baze podataka (fizičko modeliranje)

Interno oblikovanje baze podataka (izrada fizičkog modela baze)

X X

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

104

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.

105

4.2.4. Osnovni pojmovi ERA modela - entitet, relacija (veza), atribut Model entiteti-veze (ERA model – engl. Entity, Relationship, Attributes koji je postavio Chen 1976.) izrađuje se pri logičkom modeliranju podataka i ne ovisi ni o računalnoj opremi (hardveru) niti o softveru za upravljanje bazom podataka. ERA model je grafički prikaz znanja o objektima, vezama i svojstvima podataka. Sva tri osnovna koncepta modela entiteti – veze treba pobliže objasniti. Entitet je stvarni ili apstraktni predmet ili događaj o kojemu se u informacijskom sustavu pamte podaci. Entitet se odnosi na točno jednu određenu pojavnost (primjerice određenu kuću u gradu). Tip entiteta odnosi se na istu klasu srodnih entiteta, dakle sve kuće u nekom gradu, ili sve jednokatnice u nekom gradu i slično. U praksi se često pojmom entitet označava tip entiteta. Oznaka za entitet je pravokutnik u koji je velikim štampanim slovima upisana imenica (naziv entiteta) u jednini (dakle KUĆA, OSOBA, ŠKOLA, KUPAC). Budući da naziv mora biti jasan i nedvosmislen treba koristiti pojmove koji se koriste u poslovanju. Entitet odnosno objekt81 prema «srodstvu» može biti jaki, koji postoji neovisno od drugih entiteta i slabi koji egzistencijalno i/ili identifikacijski ovisi o jakom entitetu. PRIMJER:

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

ŠKOLA 1 ima RAZRED 1

RAZRED 2 RAZRED 3 RAZRED 4 RAZRED 5 RAZRED 6 . . .

ŠKOLA 2 ima RAZRED 1 RAZRED 2 RAZRED 3

. .

81 Nekada se kao sinonim u za entitet koristio pojam objekt. Međutim, uvođenjem objektnih modela taj pojam se prestao koristiti za entitet.

106

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.

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.

ŠKOLA RAZREDima

pripada

Dijagram entiteti - veze (Martinova notacija)

ŠKOLA RAZRED

Dijagram entiteti - veze (Chenova notacija)

ima

1 M

1 M

107

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.

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,

OSOBAJMBG

123456789012213456789123

1009955335121

ima

ima

ima

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

uvjetno pridruživanje ( 1 : M ), gdje je svaki član iz skupa pojava jednog entiteta povezan s jednim ili niti jednim ili s više članova iz skupa pojava drugog entiteta, pri čemu je svaki član iz skupa pojava drugog entiteta povezan samo s jednim članom iz skupa pojava prvog entiteta,

82 Pavlić, M.: Razvoj informacijskih sustava, Znak, Zagreb, 1996.

DIO

ima

pripadaŠKOLA RAZRED

sastoji se od

je ugrađen u

1

M

1

M

108

OSOBAINDEKS

12345

67890

ima

ima

12457ima

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).

OSOBAKLUB

Košarkaški klub

Bridge klub

je član

je član

Nogometni klubje članje članje član

Slika 48. Složeno pridruživanje (M:N) Važno je uočiti da se kardinalnost veze može mijenjati ovisno o tomu koji se entitet promatra. Tako je moguće da:

1 osoba posjeduje 0, 1 ili više automobila 1 automobil pripada 1 osobi

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

Slika 49.: Grafički prikaz kardinalnosti veze

OSOBA AUTOMOBILposjedujepripada

0,M1,1

109

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.)

RAČUN PROIZVODsadrži

MN

RAČUN PROIZVOD

sadrži

M

STAVKARAČUNA

N

sadrži

1 1

Slika 50. Primjer semantike veze (Chen –ova notacija) Isti primjer prikazan je Martinovom notacijom na slici 51.

110

RAČUN PROIZVOD

MN

RAČUN PROIZVOD

MNSTAVKARAČUNA

11

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.

111

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

112

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

Naselje Dobropoljana na otoku Pašmanu ima šifru naselja 011258. Međutim, to naselje nema svoju poštu nego se koristi poštanski broj naselja Neviđane koji ima šifru naselja 043036, a poštanski broj 23264.

Prijenosom modela šifarnika u fizičku organizaciju podataka (danas uglavnom u relacijsku) ključevi odnosno identifikatori pojedinih zavisnih entiteta se spajaju u tzv. sastavljeni ključ. To znači da se logički prikaz šifarskog sustava razlikuje od fizičke implementacije.

PRIMJER:

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

Zagreb ima šifru županije 21

šifru grada 01333

šifru naselja 072150

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

Međutim, ako je poznato samo ime naselja, primjerice Dubrava, mora se znati gdje se to mjesto nalazi. Zašto?

U Hrvatskoj postoji naselje Dubrava s tri šifre naselja: 15466, 15468 i 15440.

Svako od tih naselja nalazi se u drugoj općini, pa je za određivanje mjesta Dubrava potrebno koristiti šifru naselja u kombinaciji s šifrom pripadajuće općine:

Dubrava ima šifru općine 04197 (Ston)

šifru naselja 15466

Dubrava ima šifru općine 03000 (Omiš)

šifru naselja 15468

Dubrava ima šifru općine 00973 (Dubrava)

šifru naselja 15440

113

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).

DRŽAVA

ŽUPANIJA

GRAD (OPĆINA)

NASELJE POŠTA

NASELJE/POŠTANASELJE /POŠTA

Matični brojgrada/općine

Naziv grada / općine

Matični broj naselja

Naziv naselja

Broj pošte

Naziv pošte

Matični broj naselja Broj pošte

Šifra županije

Naziv županije

Šifra države- 2 mjestaslovčana

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

Službeni naziv države

Skraćeni naziv države

Naziv države u poštansikom prometu

Šifra države- 2 mjestabrojčana

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

114

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.

115

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.

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.

Akcija 1. Akcija 2.

Akcija 5. Akcija 6.

Akcija 3.Akcija 4.

*BLOK A

*BLOK B

Akcija 1.

Akcija 4.

Akcija 7.

Akcija 2.Akcija 3.

*BLOK A

*BLOK B

Akcija 5.Akcija 6.

*BLOK C

116

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

117

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.

118

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.

119

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.

120

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:

kt + t - 1

1 = 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 0 kt→ , pa je

t - 11 = K .

Slika 55. Primjer za ∞→ k

87 Jednadžbu je obrazložio A. Radelić na 1. hrvatskoj konferenciji SYNON korisnika, 1997. godine.

Povećanje produktivnosti korištenjem CASE pomagala

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

9,00

0 0,2 0,4 0,6 0,8 1

t

K

t K0 1,00

0,1 1,110,2 1,250,3 1,430,4 1,670,5 2,000,6 2,500,7 3,330,8 5,000,9 10,001 ∞

121

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%.

23 =

31 - 1

1 = K

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.

Slika 56. Primjer za

kt + t - 1

1 = 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

t k1 k2 k3 k4 K1 K2 K3 K40 1,5 2 4 8 1,00 1,00 1,00 1,00

0,1 1,5 2 4 8 1,03 1,05 1,08 1,100,2 1,5 2 4 8 1,07 1,11 1,18 1,210,3 1,5 2 4 8 1,11 1,18 1,29 1,360,4 1,5 2 4 8 1,15 1,25 1,43 1,540,5 1,5 2 4 8 1,20 1,33 1,60 1,780,6 1,5 2 4 8 1,25 1,43 1,82 2,110,7 1,5 2 4 8 1,30 1,54 2,11 2,580,8 1,5 2 4 8 1,36 1,67 2,50 3,330,9 1,5 2 4 8 1,43 1,82 3,08 4,711 1,5 2 4 8 1,50 2,00 4,00 8,00

Povećanje produktivnosti korištenjem CASE pomagala

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

9,00

0 0,2 0,4 0,6 0,8 1t

K

k1=1,5k2=2k3=4k4=8

122

od aktivnosti pri projektiranju informacijskih sustava, druga objedinjuju više aktivnosti, neka generiraju izvršni kod pa ih se naziva i generatorima aplikacija, a neka teže objediniti sve faze razvoja informacijskog sustava. Njihova je glavna zadaća povećati produktivnost i kvalitetu programskih rješenja, što čine više ili manje uspješno.

5.2. Vrste CASE pomagala

Osnovna podjela CASE pomagala je na: o pomagala za konceptualno i logičko projektiranje (gornji ili “upper” CASE) i o pomagala za fizičko modeliranje i izradu (donji ili “lower” CASE).

Na slici 57. prikazane su vrste CASE pomagala i faze projektiranja informacijskog sustava koje je moguće pomoću njih izvoditi. Uočljivo je da se faze prekrivaju (CASE potpunog životnog ciklusa informacijskog sustava objedinjuje ih sve), dok bi integrirani CASE (ICASE), koji još nije realiziran, trebao uključivati i povratno programsko preoblikovanje procesa (povratni inženjering) kao i kontrolu kvalitete.

Neovisno o njihovoj unutrašnjoj strukturi, kao i o fazama projektiranja koje pojedine vrste CASE pomagala pokrivaju, sva moraju imati rječnik podataka (riznicu88), moraju u modeliranju strukture podataka polaziti od relacijskog ili objektnog modela, te moraju proizvoditi svu potrebnu dokumentaciju. Riznica sadrži sve opise koji određuju stvarni sustav i njegov informatički model, sve što je vrijedno o sustavu znati, pohraniti, sačuvati i koristiti, pa je stoga širi pojam od rječnika podataka.

Kao posljedica primjene Dedene-ovog izraza može se zaključiti da je integracija CASE pomagala nužna. Međutim, u praksi to često nije ostvarivo. Izbor CASE pomagala ovisi o fazama razvoja informacijskog sustava koje se želi izvoditi računalom, ali i o metodikama projektiranja koje pomagalo podržava. «Svaki CASE je dobar ako ga se zna primijeniti»89. Primjerice, u složenim poslovnim sustavima koji se bave raznorodnom djelatnošću može se dogoditi da, zbog povijesnih razloga praćenja razvoja informacijske tehnologije, paralelno i istodobno postoji različita programska oprema, koja je međusobno neusporediva. Neovisno o potrebi za rekonstrukcijom i ponovnom izgradnjom informacijskog sustava temeljenog na istoj razini informacijske tehnologije, takav opsežan i dugotrajan proces nije moguće obaviti preko noći. Primjena CASE pomagala u takvim uvjetima pomaže pri konsolidaciji postojećih “rasutih” podataka, dok se njihovom uporabom na razini strategijskog planiranja i analize poslovnog sustava kontroliraju elementi jedinstvenosti informacijskog sustava. Za izvedbu pojedinih podsustava koriste se ili donji CASE ili generatori aplikacija koji podržavaju rad s određenom bazom podataka.

88 engl. repository 89 Brumec, J.: Epistemiologija CASE alata, CASE6, Opatija, 1994.

123

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.

124

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

ORGANIZACIJSKI I METODOLOŠKI KRITERIJI

TEHNOLOŠKI KRITERIJI

1. Faza rane primjene primjena informacijskih tehnologija u pojedinačnim i izoliranim slučajevima

primjena računala na kojima su odgovarajući programi

2. Faza zaraze i pridobivanja korisnika

porast broja izoliranih aplikacija skupo održavanje aplikacija rasap sustava

primjena centralnog računala ili mreže računala

3. Faza odvajanja funkcija

odvajanje razvoja od produkcije uvođenje planiranja informacijskog sustava odvajanje analize od oblikovanja i

programiranja

primjena pomagala za projektiranje i dokumentiranje projekata

4. Faza ujedinjavanja (projektiranja, normizacije)

ujedinjavanje modela podataka normizacija poslovne tehnologije

temeljem normizacije aplikacija dosljedna primjena neke od metodika

razvoja informacijskog sustava

primjena sustava za upravljanje bazama podataka i rječnika podataka

5. Faza upravljanja podacima

izgradnja konzistentne baze podataka uvođenje funkcija administracije

podataka i administracije baze podataka samostalni pristup korisnika zajedničkim

podacima

korištenje jezika upita od strane korisnika

6. Faza zadovoljavanja korisnika

korisnici aktivno sudjeluju u razvoju IS-a korisnik upravlja vlastitim podacima i za

njih je odgovoran

grafičko sučelje aplikacija i ujedinjene radne okoline

7. Faza pune zrelosti arhitektura informacijskog sustava sukladna je arhitekturi organizacijskog sustava

strategijsko planiranje informacijskog sustava dio je sustava planiranja tvrtke

informacijski centar je servisna funkcija

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

125

Ovisnost o tehnologiji jasno je izražena u modelu zrelosti razvoja informacijskog sustava temeljenog na načinu njegove izgradnje koji je izradio J. Martin92. Sedam faza zrelosti razvoja informacijskog sustava određeno je ovisno o uporabi metoda i tehnika, te pomagala za projektiranje i programiranje, ali i o razvoju informacijske tehnologije. S obzirom na to da kvaliteta i tehnološka razina informacijskog sustava određuju razinu njegove zrelosti, taj model opisuje tehnološku zrelost razvoja informacijskog sustava. Značajke Martinove podjele prikazane su u tablici 15.

FAZA ZRELOSTI RAZVOJA IS-a

ZNAČAJKE

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.

126

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) FAZA ZRELOSTI RAZVOJA

INFORMACIJSKOG SUSTAVA (Martin) 1. Faza rane primjene 2. Faza zaraze i pridobivanja korisnika

1. Faza primitivnog razvoja

3. Faza odvajanja funkcija 4. Faza ujedinjavanja

2. Faza dobro strukturiranog razvoja

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 6. Faza neprekidne optimizacije razvoja

7. Faza pune zrelosti

7. Faza neprekidne optimizacije poduzeća

Tablica 16.:Usporedba faza zrelosti informacijskog sustava i faza zrelosti razvoja informacijskog

sustava

Pitanja za ponavljanje:

1. Objasnite uloga i uporabu CASE pomagala. Ukratko opišite razvoj CASE. 2. Objasnite Dedeneov izraz. Navedite primjere. 3. Navedite i objasnite vrste CASE pomagala. Objasnite pojam riznice. 4. Opišite Trickerov model zrelosti informacijskog sustava. 5. Opišite Martinov model faza zrelosti razvoja informacijskog sustava. 6. Objasnite usporedbu između faza Trickerovog i Martinovog modela.

127

6. Kvaliteta informacijskog sustava i zaštita od zloporaba

Kvaliteta informacijskog sustava

Zaštita informacijskog sustava

6.1. Kvaliteta informacijskog sustava

Međunarodne norme koje se primjenjuju u informatičkoj djelatnosti odnose se na različite skupove podataka (poput šifri država i šifri valuta) ali i na kvalitetu softvera. Te norme donosi posebna organizacija ISO - The International Organization for Standardization – odnosno svjetsko udruženje nacionalnih institucija za normizaciju koje su ISO članice. Svaka nova norma prihvaća se kada ju prihvati najmanje 75% svih ISO članica, ali ju članice nisu obavezne koristiti93. S obzirom da se radi o preporuci za korištenje očekuje se da će ISO članice primijeniti novodonesenu normu kada ostvare potrebne preduvjete. U Hrvatskoj su norme ISO 3166 (šifre zemalja) i ISO 4217 (šifre valuta) uvedene u primjenu tek kada su ih počele koristiti banke u svojim informacijskim sustavima, a u NN br. 111/2001 propisane su za korištenje u platnom prometu s inozemstvom. ISO norme uvijek propisuju i terminologiju koju treba koristiti. Tako se norma ISO 8402 odnosi na upravljanje kakvoćom i osiguravanje kakvoće, a zapravo je rječnik pojmova. Norma ISO 9000-3 je norma za upravljanje kakvoćom i osiguranje kakvoće, a za informatičare je zanimljiv Dio 3 koji donosi Smjernice za primjenu ISO 9001 u razvoju, dobavljanju i održavanju softvera. Ovi međunarodni standardi odnose se primarno na organizacije koje se bave razvojem, dobavljanjem i održavanjem softvera, iako se dijelom mogu primijeniti i na korisnike. Prvo je potrebno definirati pojmove koje norme koriste94. Tako je kvaliteta odnosno kakvoća ukupnost značajki i svojstava proizvoda ili usluga zasnovana na sposobnosti zadovoljenja utvrđenih ili očekivanih potreba. Sustav kvalitete onda čine organizacijska struktura, postupci, procesi i resursi za uspostavljanje i provedbu upravljanja kvalitetom. Predmet razmatranja je programska podrška (softver) odnosno intelektualni proizvod koji uključuje programe, postupke, pravila i pridruženu dokumentaciju za rad sustava za obuhvat, pohranu, obradu i razmjenu podataka. Softver je neovisan od medija na kojem je pohranjen. Programski proizvod je cjeloviti skup računalnih programa, postupaka, pridruženih dokumenata i podataka namijenjen za isporuku korisniku, a dio programskog proizvoda je onaj segment programskog proizvoda koji je moguće identificirati tijekom razvojnih faza ili u krajnjoj fazi razvoja. Razvoj čine sve aktivnosti koje je potrebno učiniti da bi nastao programski proizvod, a taj rad se odvija u fazama odnosno definiranim dijelovima posla. Na kraju svake faze razvoja provodi se verifikacija odnosno proces evaluacije proizvoda u nekoj fazi razvoja u cilju osiguranja ispravnosti i konzistencije u odnosu na proizvode i norme koji se pojavljuju kao ulaz u tu fazu. Validacija se provodi na kraju procesa razvoja i to je proces evaluacije softvera kojim se osigurava ispunjenje specificiranih zahtjeva. 93 Krakar, Z.: ISO sustavi kvalitete u informatici, ZIH Zagreb, 1994. 94 Međunarodna norma ISO 8402, Upravljanje kvalitetom i osiguranje kakvoće, Rječnik, HrQA INFO, 1994.

128

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.

129

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.

130

za promjenama. Poseban slučaj je kada se od dobavljača traži da uključi ili koristi softverski proizvod dobavljen od drugog dobavljača ili od treće strane. Tada on mora uspostaviti i održavati procedure validacije, pohrane, održavanja i zaštite takvog proizvoda, što mora biti posebno ugovorno specificirano. Aktivnosti podrške čini i kontrola dokumenata, podaci o kvaliteti i provedenim mjerenjima, pravila, praksa i konvencije, kao i trening (edukacija) korisnika.

6.2. Zaštita informacijskog sustava Rizik informatičko/internetske tehnologije je opasnost da njezina primjena dovede do neželjenih posljedica (šteta) u organizacijskom sustavu i/ili njegovoj okolini. Do zloporabe uglavnom dolazi iz dva razloga, i to radi ostvarivanja neopravdanih ili protupravnih koristi od strane pojedinaca ili organiziranih skupina ili radi nanošenja materijalne ili nematerijalne štete pojedincu, skupini ili zajednici. Najugroženiji su informacijski sustavi iz kojih se može pristupiti Internetu, jer je i sam Internet izuzetno ugrožen. Rizik zloporabe nije moguće u potpunosti spriječiti, ali ga je moguće minimalizirati poduzimanjem općih preventivnih mjera, poput štićenja tajnosti podataka pohranjenih na računalnim memorijskim medijima, pri čemu je najpouzdanija enkripcija odnosno postupak izmjene digitalne poruke (iz tzv. otvorenog teksta u šifrat) tako da ga mogu čitati samo ovlašteni korisnici, kontroliranja tipova ostvarivanih veza s ostalim subjektima na Internetu, štićenja privatnosti pojedinca, štićenja od prijevara u poslu, štićenja od obasipanja neželjenim porukama, za što se koriste preusmjerivači pošte, alternativne mail adrese, programi za filtriranje poruka i sl., štićenja tajnosti enkripcijskih i identifikacijskih ključeva, posebno kod korištenja kartica za plaćanja. Potrebno je redovito provjeravati ne postoji li u programima koji se obrađuju neka vrst "zloćudnog" koda (računalni virus ili crv) koji se u pravilu lijepi na računalni program kako bi preuzeo kontrolu pri njegovom sljedećem izvođenju, te razviti u tvrtkama odgovarajuću sigurnosnu politiku i primorati sve djelatnike da se pridržavaju njezinih odrednica. Osim preventivnih mjera provodi se i fizička zaštita informacijskog sustava, koju čine98:

• kontrola nenamjernog i namjernog ugrožavanja fizičke imovine informacijskog sustava (od prirodnih nepogoda, požara i zlonamjernih aktivnosti), u što su uključena računala i ostala oprema,

• kontrola zlonamjernog ugrožavanja logičke imovine informacijskog sustava odnosno diskova, medija, podataka na računalu, te

• provođenje mjera zaštite pristupa informacijskom sustavu kroz: • aktivnosti identifikacije korisnika koja se provodi putem lozinke (engl. Password)

korisnika, i • aktivnosti provjere ovlaštenosti (autoriziranosti) korisnika koja se obavlja

programski, na temelju unaprijed definiranih parametara za svakog korisnika. 98 Klasić, K.: Zaštita informacijskih sustava, str. 31-31., Iproz, Zagreb, 2002.

131

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.

132

7. Seminarski primjer - Poslovanje trgovine

Sustavni postupak izgradnje informacijskog sustava Primjer seminarskog rada “Poslovanje trgovine”

Zadaci za vježbu

Planiranje informacijskog sustava odvija se tijekom analize poslovnog sustava, pa su stoga na primjeru poslovanja trgovine «VE-MA» d.o.o. date upute i detaljno razrađeni postupci kako taj posao obaviti u praksi. Metodika koja je korištena skup je poznatih tehnika koje studenti moraju usvojiti, a forma seminarskog rada standardna je za projektnu dokumentaciju Veleučilišta u Splitu. Na kraju rada nalaze se zadaci s rješenjima, kako bi studenti mogli provjeriti stečeno znanje. S obzirom na to da je razvoj informacijskog sustava složen, dugotrajan i skup posao i da su za njegovu provedbu potrebna različita znanja, izrada takvog projekta se u praksi obavlja timski. Stoga je i izrada seminarskog rada timski rad koji rade po tri studenta u timu i svaki ima unaprijed određene zadatke. Niti jedan član tima ne može obaviti svoj dio posla bez suradnje s drugim članovima tima. Svaki tim bira svoj vlastiti projektni zadatak – poslovanje određene tvrtke ili nekog njenog segmenta, pri čemu nije dozvoljeno obrađivati poslovanje trgovine u dijelu koji je obrađen u seminarskom primjeru. Primjeri tema:

Red. br. Naziv teme

1. Poslovanje kina 2. Poslovanje dječjeg vrtića 3. Poslovanje ordinacije opće medicine 4. Knjigovodstveni servis 5. Poslovanje kluba za obuku pasa 6. Poslovanje videoteke 7. Poslovanje auto škole 8. Poslovanje modne agencije 9. Poslovanje Web design studija 10. Poslovanje kemijske čistionice 11. Poslovanje časopisa 12. Poslovanje Internet kluba 13. Poslovanje obrta - posredovanje u kupoprodaji nekretnina 14. Poslovanje javnobilježničkog ureda 15. Poslovanje pivovare 16. Poslovanje hotela – rezervacija i organizacija smještaja 17. Poslovanje prodavaonice namještaja 18. Poslovanje turističke agencije 19. Poslovanje restorana 20. Poslovanje ski kluba 21. Poslovanje caffe bara 22. Poslovi Župnog ureda

133

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:

Trgovina VISPodručno skladište

- maloprodaja -

Trgovina TROGIRPodručno skladište

- maloprodaja -

SPLITCentralno skladište

- veleprodaja -

Trgovina SPLITPodručno skladište

- maloprodaja -

sedmično:nabava i promet

sedmično:artikli

sedmično:nabava i promet

2 putasedmično:

artiklidnevno:nabava ipromet

dnevno:artikli

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)

134

Model strukture informacijskog sustava:

Organizacijaposlovanja

Poslovni procesi

Klase podataka

INFORMACIJSKI SUSTAV: 1. Model baze podataka:

SKLADIŠTE

ARTIKAL

CJENIK

DOKUMENT

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:

Područno skladište- maloprodaja -

Centralno skladište- veleprodaja -

na upit:nabava i promet

na upit:artikli

izvješća zapoduzeće

izvješća zatrgovinu

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.

135

7.2. Primjer seminarskog rada “Poslovanje trgovine”

Projekt: Poslovanje trgovine Datum: 27.10.2002

Faza: Analiza poslovnog sustava (APS)

Ime i prezime (1): Smjer: Vl. potpis: Ime i prezime (2): Smjer: Vl. potpis: Ime i prezime (3): Smjer: Vl. potpis:

Sadržaj Član tima Str.

Plan razgovora s korisnikom (PLANRK) (1) 136

Razgovor sa korisnikom (RAZKOR) (1) 138

Određivanje i opis funkcija (OPISFUN) (2) 148

Određivanje i opis klasa podataka (OPISPOD) (2) 158

Matrica poslovne tehnologije (MPT) (3) 160

Lista korisničkih zahtjeva (ZAHTJEVI) (1) 163

Dijagram tijeka podataka (DTP) (1) 165

Radni dijagram (RADD) (2) 174

Maske za unos (MASKA) - primjer (3) 178

Izvješća (IZVJESCE) - primjer (3) 180

136

Projekt: Poslovanje trgovine Datum: 13.10.2002

Faza: Analiza poslovnog sustava

Dokument: Plan razgovora s korisnikom (PLANRK)

Ime i prezime: Smjer:

Sadržaj

Cilj razgovora sa korisnikom Upoznati se sa poslovnim i organizacijskim sustavom/podsustavom. Sagledati procese. Sagledati podatke. Odrediti granice sustava/podsustava. Navesti ograničenja sustava.

Pitanja za analizu Cilj razgovora sa korisnikom

Upoznati se sa poslovnim i organizacijskim sustavom/podsustavom. Cilj razgovora s odgovornim korisnikom je prikupiti informacije o postojećem podsustavu, sustavima na koje utječe i sustavima koji utječu na njega.

Sagledati procese.

Potrebno je sagledati sve aspekte procesa koji se obavlja i posebno naglasiti način na koji bi se morao obavljati. Utvrditi sve dokumente koji su neophodni u veleprodaji i maloprodaji, kao i podatke koji su potrebni za svaki dokument.

Sagledati podatke.

Prikupiti informacije o podacima, definirati ih i klasificirati. Utvrditi da li je potrebno omogućiti različite pristupe podacima, te ako jest definirati tko pristupa kojim podacima (po dokumentima), kao i način i redoslijed pristupa.

Odrediti granice sustava/podsustava.

Sustav ograničiti procesno i podatkovno, navesti i prepoznate pojmove u svezi sa projektom a koji ostaju van granica sustava.

Navesti ograničenja sustava.

Prepoznati ograničenja, opisati ih i definirati utjecaj na projekt.

137

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?

138

Projekt: Poslovanje trgovine Datum: 19.10.2002

Faza: Analiza poslovnog sustava

Dokument: Razgovor s korisnikom (RAZKOR)

Ime i prezime: Smjer:

Sadržaj

Razgovor sa korisnikom Sistematizacija bilješki sa razgovora

Raščlanjenje organizacijske strukture Raščlanjenje poslovodne strukture

Dokumenti prikupljeni tijekom razgovora Razgovor sa korisnikom Razgovor je održan 18.10.2002.g., a vodili su ga:

za izvođača: ime i prezime projektanta/analitičara za naručitelja: ime i prezime odgovorne osobe

Tijekom razgovora prikupljene su informacije o postojećem poslovnom sustavu i organizaciji poslovanja. Sagledani su ciljevi poslovanja i poslovni procesi na način na koji se sada odvijaju. Ciljevi poslovanja: • Ostvarenje prihoda od prodaje: praćenje dnevnog, mjesečnog i godišnjeg prometa, za

cijelo poduzeće i za svako prodajno mjesto. • Pravodobna nabava artikala: praćenje količina na zalihama i popunjavanja zaliha u

područnim skladištima. • Praćenje cijena artikala, pravovremena mjesečna prijava PDV-a. • Praćenje dugovanja prema dobavljačima. Praćenje naplate od kupaca, obračun zateznih

kamata. • Periodične statistike: artikli koji se prodaju dobro, oni koji se ne prodaju, koji se prodaju

ispod cijene i sl.

139

Postojeća organizacija poslovanja:

Trgovina VISPodručno skladište

- maloprodaja -

Trgovina TROGIRPodručno skladište

- maloprodaja -

SPLITCentralno skladište

- veleprodaja -

Trgovina SPLITPodručno skladište

- maloprodaja -

sedmično:nabava i promet

sedmično:artikli

sedmično:nabava i promet

2 putasedmično:

artiklidnevno:nabava ipromet

dnevno:artikli

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)

140

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.

141

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

142

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.

143

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 prodajeSektor za

računovodstvo ifinancije

Sektor marketinga

Službaveleprodaje

Službamaloprodaje

Poslovna jedinica -Split

Poslovna jedinica -Vis

Poslovna jedinica -Trogir

144

Raščlanjenje poslovodne strukture

Generalni direktor

Direktor prodaje Direktor računovodstvai financija

Direktormarketinga

Šef maloprodajeŠef veleprodaje

Poslovođa trgovineVis

Poslovođa trgovineTrogir

Poslovođa trgovineSplit

145

Dokumenti prikupljeni tijekom razgovora Prilog 1.

Prilog 2.

146

Prilog 3.

147

Prilog 4.

Prilog 5.

148

Projekt: Poslovanje trgovine Datum: 20.10.2002

Faza: Analiza poslovnog sustava

Dokument: Određivanje i opis funkcija (OPISFUN)

Ime i prezime: Smjer:

Sadržaj

Određivanje osnovnih funkcija/procesa poslovnog sustava Raščlanjenje funkcija

Opis funkcija/procesa Određivanje osnovnih funkcija/procesa poslovnog sustava Raščlanjenje osnovnih funkcija poslovnog sustava poduzeća 'VE-MA' d.o.o. do 2. nivoa dano je ovom slikom:

Poslovanje trgovine"VE-MA" d.o.o.

Poslovanjeveleprodaje

Poslovanjemaloprodaje

Vođenjeposlova

marketinga

Vođenjeračunovodstveno-

financijskih poslova

Prodajaartikala u

veleprodaji

Zaprimanjeartikala uskladište

Naručivanjeartikala oddobavljača

Zaprimanjeartikala izskladišta

veleprodaje

Vraćanjeartikala uskladište

veleprodaje

Prodajaartikala u

maloprodaji

Izdavanjeartikala uskladište

maloprodaje 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

149

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'

Poslovanjeveleprodaje

Prodajaartikala u

veleprodaji

Zaprimanjeartikala uskladište

Naručivanjeartikala oddobavljača

Izdavanje artikalau skladište

maloprodaje 1.1. Dekompozicija funkcije 'Naručivanje artikala od dobavljača'

Naručivanjeartikala oddobavljača

Provjera i odabirartikala čijekoličine su

ispod minimalne

Izradadokumenta

narudžbenica

Prikaz izvješćau procesu

naručivanja

150

1.1.1. Dekompozicija procesa 'Provjera i odabir artikala čije količine su ispod min.'

Provjera i odabirartikala čijekoličine su

ispod minimalne

Prikaz artikalačije količine

su ispodminimalne

Grupiranjeoznačenihartikala po

dobavljačima

Označavanjeartikala

koje trebanaručiti

1.1.2. Dekompozicija procesa 'Izrada dokumenta narudžbenica'

Izradadokumenta

narudžbenica

Upis novogartikla nadokument

narudžbenica

Izrada novenarudžbenice za

pojedinogdobavljača i

artikle koji senaručuju od tog

dobavljača

Upis novogartikla koji se

naručujeu šifrarnik

artikala

Upis novogdobavljačau šifrarnikdobavljača

1.1.3. Dekompozicija procesa 'Prikaz izvješća u procesu naručivanja'

Prikaz izvješćau procesu

naručivanja

Prikazrekapitulacije

narudžbidobavljačima

Prikazminimalne imaksimalne

količine

151

1.2. Dekompozicija funkcije 'Zaprimanje artikala u skladište'

Zaprimanjeartikala uskladište

Zaprimanjeartikala oddobavljača

Zaprimanjeartikala izskladišta

maloprodaje 1.2.1. Dekompozicija procesa 'Zaprimanje artikala od dobavljača'

Zaprimanjeartikala oddobavljača

Izradadokumenta

primka

Usporedbaprimke i

narudžbenice

Prikaz izvješćau procesu

zaprimanja

1.2.1.1. Dekompozicija potprocesa 'Izrada dokumenta primka'

Upisartikala nadokument

primka

Izradanove primkeza odabranog

dobavljača

Upis novogzaprimljenog

artikla ušifrarnik artikala

Izradadokumenta

primka

152

1.2.1.2. Dekompozicija potprocesa 'Usporedba primke i narudžbenice'

Usporedbaprimke i

narudžbenice

Za dobavljača saprimke pretraživanje

i usporedbanarudžbenica kojenisu uspoređene

Upis brojanarudžbenice

u primku

1.2.1.3. Dekompozicija potprocesa 'Prikaz izvješća u procesu zaprimanja'

Prikaz izvješćau procesu

zaprimanja

Prikazrekapitulacije

primki

Prikazprometa po

dobavljačima

1.2.2. Dekompozicija procesa 'Zaprimanje artikala iz skladišta maloprodaje'

Zaprimanje artikalaiz skladištamaloprodaje

Upis artikalana ulaznu

međuskladišnicu

Izrada dokumentaulazna međuskladišnicaiz odabranog skladište

maloprodaje

Prikazrekapitulacije

ulaznihmeđuskladišnica

153

1.3. Dekompozicija funkcije 'Prodaja artikala u veleprodaji'

Prodajaartikala u

veleprodaji

Izradadokumenta

račun

Izrada cjenikaveleprodaje

Prikaz izvješćau procesuprodaje

Obavljanjeinventure

1.3.1. Dekompozicija procesa 'Izrada cjenika veleprodaje'

Izradacjenika

veleprodaje

Formiranjecijene zaartikle

Ispiscjenika

1.3.2. Dekompozicija procesa 'Izrada dokumenta račun'

Izradadokumenta

račun

Izdavanjenovog računasa podacima

o kupcu

Dodjeljivanjerabata za

kupca

Unosartikala

na dokumentračun

Upis novogkupca

u šifrarnikkupaca

154

1.3.3. Dekompozicija procesa 'Prikaz izvješća u procesu prodaje'

Prikaz izvješćau procesuprodaje

Prikazrekapitulacije

računa

Prikazpometa pokupcima

Prikazpometa

skladišta

Prikazpometa po

artiklu

Prikazrekapitulacije

svih dokumenataskladišta

1.3.4. Dekompozicija procesa 'Obavljanje inventure'

Obavljanjeinventure

Ispispopisne

liste

Izradainventurne

liste

Generiranjedokumenta o višku i

dokumenta o manjku

Prikazpregledainventura

1.4. Dekompozicija funkcije 'Izdavanje artikala u skladište maloprodaje'

Izdavanje artikalau skladište

maloprodaje

Upis artikalana izlaznu

međuskladišnicu

Izrada dokumentaizlazna međuskladišnica

za odabrano skladištemaloprodaje

Prikazrekapitulacije

izlaznihmeđuskladišnica

155

Opis funkcija/procesa

Rb. Naziv funkcije/procesa Opis funkcije/procesa

1. Prikaz artikala čije količine su ispod minimalne

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 treba naručiti

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 artikala po dobavljačima

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 šifarnik dobavljača

Ako se prvi put naručuje roba od nekog dobavljača treba podatke o tom novom dobavljaču upisati u registar (šifarnik) dobavljača i dodijeliti mu šifru dobavljača.

5. Izrada nove narudžbenice za pojedinog dobavljača i artikle koji se naručuju od tog dobavljača

Za svakog dobavljača i sve artikle koji se nabavljaju od tog dobavljača izrađuje se dokument narudžbenice sa podacima o dobavljaču (naziv, mjesto, adresa, matični broj), datumu naručivanja, broju dokumenta i odgovornoj osobi koja je izadila dokument.

6. Upis novog artikla koji se naručuje u šifarnik artikala

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 dokument narudžbenica

Ako se od dobavljača prvi put naručuje neki artikal onda i njega treba dodati na postojeću narudžbenicu.

8. Prikaz rekapitulacije narudžbi dobavljačima

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 maksimalne količine

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.

10. Izrada nove primke za odabranog dobavljača

Izrađuje se dokument primka kojim se bilježi 'ulazak' artikala poslanih od dobavljača (na osnovu narudžbenice) u skladište. U zaglavlje primke se upisuju podaci o dobavljaču, datum zaprimanja, broj dokumenta i osoba koja je izradila dokument.

11. Upis novog zaprimljenog artikla u šifarnik artikala

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 primka

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 pretraživanje i usporedba narudžbenica koje nisu uspoređene

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.

156

Rb. Naziv funkcije/procesa Opis funkcije/procesa

14. Upis broja narudžbenice u primku

U primku upisati broj narudžbenice i ovu odložiti među dokumente narudžbenica koje su rješene.

15. Prikaz rekapitulacije primki

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 dobavljačima

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 međuskladišnica iz odabranog skladište maloprodaje

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 međuskladišnicu

U stavke dokumenta ulazna međuskladišnica upisuju se podaci o artiklu i zaprimljenoj količini artikla.

19. Prikaz rekapitulacije ulaznih međuskladišnica

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 artikle

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 šifarnik kupaca

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 podacima o kupcu

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 dokument račun

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 kupca

Za pojedine artikle koji se prodaju, mogu se unaprijed definirati minimalni ili maksimalni rabati za kupca.

26. Prikaz rekapitulacije računa

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 kupcima

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.

157

Rb. Naziv funkcije/procesa Opis funkcije/procesa

30. Prikaz rekapitulacije svih dokumenata skladišta

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 višku i dokumenta o manjku

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 međuskladišnica za odabrano skladište maloprodaje

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 međuskladišnicu

U stavke dokumenta izlazna međuskladišnica upisuju se podaci o artiklu i izdanoj količini artikla.

37. Prikaz rekapitulacije izlaznih međuskladišnica

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.

158

Projekt: Poslovanje trgovine Datum: 20.10.2002

Faza: Analiza poslovnog sustava

Dokument: Određivanje i opis klasa podataka (OPISPOD)

Ime i prezime: Smjer:

Sadržaj

Određivanje osnovnih klasa podataka poslovnog sustava Opis klasa podataka

Određivanje osnovnih klasa podataka poslovnog sustava Za procese podsustava veleprodaje može se prepoznati nekoliko osnovnih klasa podataka koje se koriste u više procesa iste logičke funkcionalnosti. To su:

• artikli • pravne osobe od kojih se kupuju artikli (dobavljači) i pravne osobe kojima se

prodaju artikli (kupci). • lokacije na kojima se izdaju dokumenti (skladišta)

Dokumenti koji se ovdje razmatraju ukazuju na sljedeće klase podataka:

• narudžbenica • primka • cjenik • račun • popisna lista • inventurna lista • zapisnik o višku • zapisnik o manjku • ulazna međuskladišnica • izlazna međuskladišnica.

Već se sada može pretpostaviti, a i kasnija detaljna analiza podataka će pokazati da se skup osnovnih klasa podataka koji se ponavljaju u više procesa (artikli, dobavljači, kupci, te lokacije) definiraju kao osnovni šifarnici.

159

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).

160

Projekt: Poslovanje trgovine Datum: 20.10.2002

Faza: Analiza poslovnog sustava

Dokument: Matrica poslovne tehnologije (MPT)

Ime i prezime: Smjer:

Sadržaj

Osnovna matrica poslovne tehnologije Dijagonalizirana matrica poslovne tehnologije

Matrica poslovne tehnologije prikazuje redosljed odvijanja procesa u poslovnom sustavu i aktivnosti tih procesa nad entitetima.

Matrica poslovne tehnologije podsustava “Poslovanje veleprodaje” ima dva procesa (br. 6. i br. 11.) koji upisuju novi artikal u šifarnik artikala. U poslovanju veleprodaje dodavanje novog artikla u šifarnik artikala može se dogoditi u procesu naručivanja robe od dobavljača i u procesu zaprimanja robe u skladište.

U dijagonaliziranoj matrici koja predstavlja arhitekturu budućeg informacijskog podsustava ova dva procesa su objedinjena u jedan i stavljena na početak matrice. Dijagonalizirana matrica je podijeljenja u 3 submatrice: osnovni šifarnici vezani uz veleprodaju, veleprodaja i inventura. Može se napraviti podjela i u 2 submatrice: osnovni šifarnici i veleprodaja, tako da je u ovu drugu uključena i inventura te je broj entiteta izvan podsustava koje koriste procesi podsustava manji.

Entitet LOKACIJA nastaje izvan podsustava “Poslovanje veleprodaje” (kreira se na nivou poduzeća). U podsustavu “Poslovanje veleprodaje” ovaj entitet se samo čita. Takvih entiteta ima još, poput POŠTE, NASELJA, VALUTE, DJELATNOSTI itd. Oni nisu navedeni uz ovaj podsustav, iako se se u praksi koriste u informacijskom sustavu. Entiteti koji se koriste u cijelom sustavu, a nastaju izvan sustava (ponekad se u potpunosti preuzimaju od drugih institucija) ili u samom sustavu, u nekom njegovom dijelu, često se nazivaju matičnim šifarnicima ili matičnim podacima.

161

Osnovna matrica poslovne tehnologije Entiteti Procesi A

RT

IKA

L

DO

BA

VL

JAČ

KU

PAC

NA

RU

DŽ

BE

NIC

A

LO

KA

CIJ

A

PRIM

KA

CJE

NIK

RAČ

UN

INV

EN

TU

RN

A

LIS

TA

ZA

PISN

IK O

VIŠ

KU

ZA

PISN

IK O

M

AN

JKU

POPI

SNA

LIS

TA

UL

AZ

NA

M

EĐ

USK

L.

IZL

AZ

NA

M

EĐ

USK

L.

1. Prikaz artik. čije količine su ispod minimalne R R 2. Označavanje artikala koje treba naručiti U 3. Grupiranje označenih artik. po dobavljačima R R 4. Upis novog dobavljača u šifarnik dobavljača C 5. Izrada nove narudž. za pojedinog dobavljača ... R R C 6. Upis novog artikla koji se naručuje u šifarnik … C 7. Upis novog artikla na dok. narudžbenica R U 8. Prikaz rekapitulacije narudžbi dobavljačima R R 9. Prikaz minimalne i maksimalne količine R R 10. Izrada nove primke za odabranog dobavljača R R C 11. Upis novog zaprimljenog artikla u šifarnik … C 12. Upis artikala na dokument primka R U 13. Za dobav. sa primke pretraživanje narudž. … R R 14. Upis broja narudžbenice u primku R R U 15. Prikaz rekapitulacije primki R R R 16. Prikaz prometa po dobavljačima R R R R R 17. Izrada dokumenta ulazna međuskladišnica … R C 18. Upis artikala na ulaznu međuskladišnicu R U 19. Prikaz rekapitulacije ulaznih međuskladišn. R R 20. Formiranje cijene za artikle R R C 21. Ispis cjenika R 22. Upis novog kupca u šifarnik kupaca C 23. Izdavanje novog računa sa podacima o kupcu R R C 24. Unos artikala na dokument račun R U 25. Dodjeljivanje rabata za kupca R R U 26. Prikaz rekapitulacije računa R R 27. Prikaz prometa po kupcima R R R 28. Prikaz prometa skladišta R R R R R 29. Prikaz prometa po artiklu R R R R R R 30. Prikaz rekapitulacije svih dokum. skladišta R R R R R R R 31. Ispis popisne liste R R C 32. Izrada inventurne liste R R R C R R 33. Generiranje dok. o višku i dok. o manjku R R R C C 34. Prikaz pregleda inventura R R 35. Izrad dokumenta izlazna međuskladišnica … R C 36. Upis artikala na izlaznu međuskladišnicu R U 37. Prikaz rekapitulacije izlaznih međuskladišn. R R

162

Dijagonalizirana matrica poslovne tehnologije Entiteti Procesi A

RT

IKA

L

DO

BA

VL

JAČ

KU

PAC

NA

RU

DŽ

BE

NIC

A

PRIM

KA

UL

AZ

NA

M

EĐ

USK

L.

CJE

NIK

RAČ

UN

IZL

AZ

NA

M

EĐ

USK

L.

POPI

SNA

LIS

TA

INV

EN

TU

RN

A

LIS

TA

Z

API

SNIK

O

VIŠ

KU

Z

API

SNIK

O

MA

NJK

U

LO

KA

CIJ

A

6. i 11. Upis novog artikla u šifarnik artikala C 1. Prikaz artik. čije količine su ispod minimalne R R 2. Označavanje artikala koje treba naručiti U 9. Prikaz minimalne i maksimalne količine R R 4. Upis novog dobavljača u šifarnik dobavljača C 3. Grupiranje označenih artik. po dobavljačima R R 22. Upis novog kupca u šifarnik kupaca C 5. Izrada nove narudž. za pojedinog dobavljača ... R R C 7. Upis novog artikla na dok. narudžbenica R U 8. Prikaz rekapitulacije narudžbi dobavljačima R R 10. Izrada nove primke za odabranog dobavljača R C R 12. Upis artikala na dokument primka R U R 13. Za dobav. sa primke pretraživanje narudž. … R R 14. Upis broja narudžbenice u primku R U R 15. Prikaz rekapitulacije primki R R R 16. Prikaz prometa po dobavljačima R R R R R 17. Izrada dokumenta ulazna međuskladišnica … C R 18. Upis artikala na ulaznu međuskladišnicu R U 19. Prikaz rekapitulacije ulaznih međuskladišn. R R 20. Formiranje cijene za artikle R R C 21. Ispis cjenika R 23. Izdavanje novog računa sa podacima o kupcu R C R 24. Unos artikala na dokument račun R U 25. Dodjeljivanje rabata za kupca R R U 26. Prikaz rekapitulacije računa R R 27. Prikaz prometa po kupcima R R R 35. Izrad dokumenta izlazna međuskladišnica … C R 36. Upis artikala na izlaznu međuskladišnicu R U R 37. Prikaz rekapitulacije izlaznih međuskladišn. R R 28. Prikaz prometa skladišta R R R R R 29. Prikaz prometa po artiklu R R R R R R 30. Prikaz rekapitulacije svih dokum. skladišta R R R R R R R 31. Ispis popisne liste R C R 32. Izrada inventurne liste R R R R C R 33. Generiranje dok. o višku i dok. o manjku R R C C R 34. Prikaz pregleda inventura R R

163

Projekt: Poslovanje trgovine Datum: 24.10.2002

Faza: Analiza poslovnog sustava

Dokument: Lista korisničkih zahtjeva (ZAHTJEVI)

Ime i prezime: Smjer:

Lista korisničkih zahtjeva

Rb. KORISNIK Z A H T J E V R J E Š E N J E

1. Rukovodstvo

Osigurati jedinstveni šifarnik artikala dostupan svima (nabavi, veleprodaji i maloprodaji).

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.

2. Rukovodstvo

Osigurati jedinstveni šifarnik kupaca i dobavljača (partneri) dostupan svim lokacijama.

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.

3. Direktor Omogućiti definiranje svakog pojedinog korisnika informacijskog sustava unutar tog sustava. Svakom korisniku dodijeliti prava na nivou: čitanje, izmjena, dodavanje i brisanje podataka.

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.

4. 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.

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.

164

Rb. KORISNIK Z A H T J E V R J E Š E N J E

5. Direktor veleprod.

Omogućiti definiranje dokumenata za nabavljanje, zaprimanje i prodaju artikala u skladištu veleprodaje.

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.

6. Direktor prodaje

U svakom skladištu osigurati definiranje i ispis cjenika na dan.

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. Rukovodstvo

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. Rukovodstvo

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. Rukovodstvo

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. Rukovodstvo

Osigurati efikasan popis artikala na kraju godine ili bilo kada tokom godine (inventura).

Izraditi odgovarajući program za ispis.

16. Rukovodstvo

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.

165

Projekt: Poslovanje trgovine Datum: 24.10.2002

Faza: Analiza poslovnog sustava

Dokument: Dijagram tijeka podataka (DTP)

Ime i prezime: Smjer:

Sadržaj

Kontekst dijagram - Dijagram tijeka podataka nivoa 0 (DTP-0) Dijagrami tijeka podataka nižih nivoa (DTP)

Kontekst dijagram - nivo 0: Poslovanje veleprodaje

Poslovanjeveleprodaje Šef

veleprodaje

Dobavljač

Kupac

Skladištemaloprodaje

Komisija

narudžbenica

dokument oddobavljača

cjenik

račun

izlaznameđuskladišnica

izlaznameđuskladišnica

Šefveleprodaje

popisna lista

popunjenapopisna lista

inventurnalista

166

Dijagrami tijeka podataka nižih nivoa

- nivo 1: Poslovanje veleprodaje

Šefveleprodaje

Dobavljač

Kupac

Skladištemaloprodaje

Komisija

narudžbenica

dokument dodobavljača

cjenik

račun

izlaznameđuskladišnica

izlaznameđuskladišnica

Šefveleprodaje

popisna lista

inventurnalista

3. Prodajaartikala u

veleprodaji

2. Zaprimanjeartikala uskladište1. Naručivanje

artikala oddobavljača

4. Izdavanjeartikala uskladište

maloprodaje

Dobavljač

Artikal

naziv, mjesto,adresa, mat. broj

šifra, naziv,količina

količinaLokacija šifra

lokacije

šifralokacije

količinaKupac

naziv, mjesto,adresa, mat. broj

Artikalkoličina

167

- nivo 2: 1. Naručivanje artikala od dobavljača

1.3. Prikazizvješća

u procesunaručivanja

1.1. Provjera iodabir artikala čijekoličine su ispod

minimalne

1.2. Izradadokumenta

narudžbenica

Dobavljač

Dobavljač

Artikal

Skladištar

Narudžbenica

popisartikala

Šefveleprodaje

količina na skladištu,minimalna količina

Skladištar

šifra i nazivdobavljača

šifra inaziv artikla

Skladištar

odabirdobavljača

i artikala

narudžbenica

narudžbenica

rekapitulacijanarudžbenica

rekapitulacijanarudžbenica

popis artikala,min. i maksim.količina

količina na skladištu,minimalna količina,

maksimalna količinaoznaka zanarudžbu

oznaka zanarudžbu

narudžbenica

- nivo 3: 1.1. Provjera i odabir artikala čije količine su ispod minimalne

1.1.1. Prikazartikala čije

količine su ispodminimalne

1.1.3. Grupiranjeoznačenihartikala po

dobavljačima

1.1.2. Označavanjeartikala kojetreba naručiti

Dobavljač

Artikal

Skladištarpopisartikala

oznaka zanarudžbu

količina na skladištu,minimalna količina

oznaka zanarudžbu

šifra inaziv artikla

šifra i nazivdobavljačaSkladištar

pregled dobavljačai artikala

168

- nivo 3: 1.2. Izrada dokumenta narudžbenica

Dobavljač

Dobavljač

Narudžbenica

Artikal

Skladištar

šifra i nazivdobavljača

odabir dobavljačai artikala

šifra inaziv artikla

narudžbenica

narudžbenica

šifra i nazivdobavljača

šifra inaziv artikla

1.2.3. Upis novogartikla

koji se naručujeu šifrarnik obavljača

šifra i nazivdobavljača

šifra i nazivdobavljača

1.2.1. Upis novogdobavljačau šifrarnikdobavljača

1.2.2. Izrada novenarudžbenice za

dobavljača i artiklekoji se naručuju

od tog dobavljača

1.2.4. Upis novogartikla na

narudžbenicu

Skladištarodabir artikla

šifra inaziv artikla

šifra inaziv artikla

- nivo 3: 1.3. Prikaz izvješća u procesu naručivanja

1.3.2. Prikazrekapitulacije

narudžbidobavljačima

1.3.1. Prikazminimalne imaksimalne

količine

Artikal

Narudžbenica

Šefveleprodaje

Skladištar

narudžbenica

rekapitulacijanarudžbenica

rekapitulacijanarudžbenica

popis artikala, min.i maksim. količina

količina na skladištu,minimalna količina,maksimalna količina

169

- nivo 2: 2. Zaprimanje artikala u skladište

Dobavljač Skladištemaloprodaje

dokument oddobavljača

izlaznameđuskladišnica

2.2. Zaprimanjeartikala izskladišta

maloprodaje

Artikalkoličina

Lokacija

šifralokacije2.1. Zaprimanje

artikala oddobavljača

količina

Primka

primkaUlazna

međuskladišnica

ulaznameđuskladišnica

- 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

2.2.2. Upisartikala na

ulaznumeđuskladišnicu

2.2.1. Izrada dok.ulazna

međuskladišnicaiz odabranog

skladište maloprodaje

2.2.3. Prikazrekapitulacije

ulaznihmeđuskladišnica

Skladištemaloprodaje

izlaznameđuskladišnica

Artikal

Lokacija

šifralokacije

količina

Ulaznameđuskladišnica

Skladištar

šifralokacije

šifralokacije

šifra i nazivartikla

šifra i nazivartikla

šifra i nazivartikla

rekapitulacijaulaznih

međuskladišnica

ulaznameđuskladišnica

Šefveleprodaje rekapitulacija ulaznih

međuskladišnica

170

- nivo 2: 3. Prodaja artikala u veleprodaji

Zapisniko manjku

3.2. Izradadokumenta

račun

3.1. Izradacjenika

veleprodaje

3.3. Prikazizvješća u

procesu prodaje

3.4. Obavljanjeinventure

Šefveleprodaje

cjenik

Cjenik

Kupac

Artikal

šifra inaziv artikla

šifra inaziv artikla

cijena

cijena

račun

Kupac

Skadištar

Račun

šifra inaziv artikla

odabir kupcai artikala

račun

šifra inaziv kupca

šifra inaziv kupca

šifra inaziv artikla

Primka

Ulaznameđuskladišnica

Skladištar

Izlaznameđuskladišnica

Zapisniko višku

pregledi i izvješća

pregledi iizvješća

primka

ulazna međuskl.

izlazna međuskl.

račun

zap. o višku

zap. o manjku

Šefveleprodaje Komisija

primka

ulaznameđuskl.

izlaznameđuskl.

račun

popisnalista

ispunjenapopisna lista

inventurna lista

zap. o višku

zap. o manjku

171

- nivo 3: 3.1. Izrada cjenika veleprodaje

Artikal

cijena Cjenik

cijena

3.1.1. Formiranjecijene za artikle 3.1.2. Ispis

cjenika

Šefveleprodaje

šifra i nazivartikla

šifra i nazivartikla

Skladištar

cjenik

cjenikcjenik

- nivo 3: 3.2. Izrada dokumenta račun

račun

3.2.2. Unosartikalana račun

Kupac

Artikal

Račun

šifra i nazivkupca

Skladištar

šifra i nazivkupca

šifra i nazivartikla

šifra i nazivartikla

šifra i nazivartikla

Kupac

šifra i nazivkupca

količina

3.2.1. Izdavanjenovog računasa podacima

o kupcu

3.2.3. Dodjeljivanjerabata

za kupca

račun

Šefveleprodaje

rabat

rabat

Kupac

šifra i nazivkupca

172

- nivo 3: 3.3. Prikaz izvješća u procesu prodaje

3.3.1. Prikazrekapitulacije

računa

3.3.2.. Prikazprometa po

kupcima

Skladištar

Račun

Kupac

računrekapitulacijaračuna Šef

veleprodaje

račun

rekapitulacijaračuna

promet pokupcima

šifra i nazivkupca

3.3.3. Prikazpometa

skladišta

3.3.4. Prikazpometa po

artiklu

3.3.5. Prikazrekapitulacije

svih dokumenataskladišta

Zapisniko manjku

Primka

Zapisniko višku

Ulaznameđuskladišnica

Izlaznameđuskladišnica

Artikal

Šefveleprodaje

primkaračun

ulaznameđuskl.

izlaznameđuskl.

prometskladišta

prometskladišta

Skladištar

Račun

Primka

šifra i nazivartiklaulazna

međuskl.

izlazna međuskl.

rekapit. svihdokumentataskladišta

rekapit. svihdokumentataskladišta

zap. o manjku

zap. o višku

Ulaznameđuskladišnica

ulaznameđuskl.

računračun

primkaprimka

izlaznameđuskl.

Šefveleprodaje

promet poartiklu

promet poartiklu

promet pokupcima

173

- nivo 3: 3.4. Obavljanje inventure

Zapisniko manjku

Zapisniko višku

zap. o višku

zap. o manjku

3.4.1. Ispispopisne

liste

3.4.2. Izradainventurne

liste

3.4.3. Generiranjedok. o višku i

dok. o manjku

3.4.4. Prikazpregledainventura

Izlaznameđuskladišnica

Komisija

Šefveleprodaje

ispunjenapopisna lista

popisnalista

Ulaznameđuskladišnica

Primka

Račun

Lokacija Inventura

Artikal

šifra i nazivartikla

lokacija

inventurnalista

Šefveleprodaje

primka

račun

ulaznameđuskl.

izlaznameđuskl.

inventura

manjak količine

višak količine

inventura

Lokacijalokacija

pregledinventura

generiranje

Artikal

količina

Popisna listapopisnalista šifra i naziv

artikla

lokacija

- nivo 2: 4. Izdavanje artikala u skladište maloprodaje (vidi zadatak 1.e) )

174

Projekt: Poslovanje trgovine Datum: 26.10.2002

Faza: Analiza poslovnog sustava

Dokument: Radni dijagram (RADD)

Ime i prezime: Smjer:

Sadržaj

Naručivanje artikala Zaprimanje artikala Generiranje dokumenta o višku i manjku

Naručivanje artikala

U područnom skladištu periodično se formira dokument zahtjevnica za nabavku artikala koji se šalje u centralno skladište. Oni artikli kojih ima u dovoljnim količinama šalju se iz centralnog u područno skladište a za one kojih nema radi se narudžbenica. Na narudžbenicu se stavljaju i ostali artikli čija količina je u centralnom skladištu manja od minimalne. Ako ima potrebe za naručivanjem artikla po prvi put onda se i on stavlja na narudžbenicu poznatog dobavljača ili se narudžbenica radi prvi put za novog dobavljača.

Početak

Zahtjev zanabavku atrikala

Listanje artikala kojetreba naručiti (1)

Je likoličina na skladištu

dovoljna?Da

Stavljanje artiklana izlaznu

međuskladišnicu

Je li količinana skladištu ispod

minimalne?

Ne

Obilježavanjeartikla

Da

Ima li jošartikala na popisu

(1)?

Da

Ne

A

Ne

175

A

Listanje ostalihartikala u centralnom

skladištu (2)

Je li količinana skladištu ispod

minimalne?

Obilježavanjeartikla

Ima li jošartikala na popisu

(2)?

Da

Ne

Da

Da linaručiti novi

artikal?

Da li postojidobavljač?

Unos novogdobavljača

Upis novog artikla

Obilježavanjenovog artikla

Da

Ne

Ne

Da

Grupiranjeobilježenih artikala

po dobavljačima

Listanjedobavljača (3)

Ima li jošdobavljača na listi

(3)?

Izrada narudžbeniceza dobavljača

Izrada stavkenarudžbenice zaartikle zadanog

dobavljača

Ima lijoš artikala zadobavljača?

Ne

DaDa

Kraj

176

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četakDokument od

dobavljača

Izrada primke zadobavljača

Izrada stavkeprimke za artikle

zadanog dobavljača

Ima li jošartikala na dokumentu

od dobavljača?

Ne

Da

Upis novog artiklaDa li je

na dokumentu oddobavljača novi

artikal?

Ne

Da

Upis brojanarudžbenice u

primku

Je lipronađena narudžbenica

s brojem?

KrajUsporedba svihneuspoređenih

narudžbenica saprimkom

Ne

Da

Pretraživanjeneuspoređenih

narudžbenica oddobavljača

177

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.

Ima li jošartikala na listi

(1)?

Ne

Kraj

Ne

Početak

Pregled sadržajainventurne liste

Ima li nalisti artikala sa

manjakom?

Izrada dokumentao manjku

Ima li nalisti artikala sa

viškom?

Izrada dokumentao višku

Ne

Da

Da

NeInventurna lista

Listanje artikalasa inventurne

liste (1)

stvarna kol. <nađena kol.

stvarna kol. >nađena kol.

Upis artikla i viška udokument o višku

Upis artikla i manjka udokument o manjku

NeDa

Da

Da

178

Projekt: Poslovanje trgovine Datum: 28.10.2002

Faza: Analiza poslovnog sustava

Dokument: Maske za unos (MASKA)

Ime i prezime: Smjer:

Sadržaj

Maske za unos Narudžbenica (primjer) Narudžbenica Maska za unos zaglavlja dokumenta narudžbenica:

179

Maska za artikle na narudžbenici:

180

Projekt: Poslovanje trgovine Datum: 29.10.2002

Faza: Analiza poslovnog sustava

Dokument: Izvjesca (IZVJESCE)

Ime i prezime: Smjer:

Sadržaj

Izvješća Promet skladišta (primjer)

Promet skladišta “VE-MA” d.o.o. 04.03.2001

Južna ulica 10, SPLIT

Promet skladišta po ulaznim i izlaznim dokumentima

od datuma 01.02.2001. do datuma 28.02.2001.

Skladište: 003 Glavno skladište

Početno stanje po nabavnim cijenama: 5.000,00

Datum Po nabavnim cijenama Po prodajnim cijenama

dokumenta Dokument Ulaz Izlaz Saldo Izlaz

01.02.1997. PR / 00054 2.500,00 7.500,0002.02.1997. RN / 00008 100,00 7.400,00 120,0005.02.1997. IM / 00012 40,00 7.360,0005.02.1997. RN / 00047 1.000,00 6.360,00 1.200,0010.02.1997. PR / 00055 5.500,00 11.860,0011.02.1997. RN / 00015 500,00 11.360,00 610,0015.02.1997. UM / 00007 700,00 12.060,0021.02.1997. UM / 00005 150,00 12.210,0027.02.1997. RN / 00002 60,00 12.150,00 75,00

UKUPNO: 8.850,00 1.700,00 12.150,00 2.005,00

181

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

2.1.2. Usporedbaprimke i

narudžbenice2.1.1. Izradadokumenta

primka

2.1.3. Prikazizvješća uprocesu

zaprimanja

Dobavljač

dokument dodobavljača

Artikal

Primka

primka

Skladištar

odabirdobavljačai artikala

šifra i nazivartikla

NarudžbenicaDobavljač

šifra i nazivdobavljača

Šefveleprodajeprimka

rekapitulacijaprimki

promet podobavljačima

Skladištar

rekapitulacijaprimki

brojnarudžbenice

brojnarudžbenice

neuspoređenenarudžbenice

b) nivo 4: 2.1.1. Izrada dokumenta primka

2.1.1.3. Upisartikala nadokument

primka

2.1.1.1. Izradanove primkeza odabranog

dobavljača

Dobavljač

dokument dodobavljača

Artikal

Primka

šifra i nazivdobavljača

Skladištar

šifra i nazivdobavljača

šifra i nazivartikla

šifra i nazivartikla

šifra i nazivartikla

Dobavljač

šifra i nazivdobavljača

količina

2.1.1.2. Upisnovog zaprimljenog

artikla u šifrarnikartikala

Skladištaršifra i nazivartikla

šifra i nazivartikla

182

c) nivo 4: 2.1.2. Usporedba primke i narudžbenice

2.1.2.1. Za dobavljačasa primke pretraži-vanje i usporedbanarudžbenica kojenisu uspoređene

2.1.2.2. Upisbroja

narudžbeniceu primku

Primka

Skladištar

Narudžbenica

odabirnarudžbenice

brojnarudžbenice

šifra i nazivdobavljača

neuspoređenenarudžbenice

narudžbenica

broj narudžbenice

d) nivo 4: 2.1.3. Prikaz izvješća u procesu zaprimanja

2.1.5. Prikazrekapitulacije

primki

2.1.6. Prikazprometa po

dobavljačima

SkladištarPrimka

Dobavljač

primka

rekapitulacijaprimki

Šefveleprodaje

primka

rekapitulacijaprimki

promet podobavljačima

šifra i nazivdobavljača

e) nivo 2: 4. Izdavanje artikala u skladište maloprodaje

4.2. Upisartikala na

izlaznumeđuskladišnicu

4.3. Prikazrekapitulacije

izlaznihmeđuskladišnica

Skladištemaloprodaje

izlaznameđuskladišnica

Artikal

Lokacija

šifralokacije

količina

Izlaznameđuskladišnica

Skladištar

šifralokacije

šifralokacije

šifra i nazivartikla

šifra i nazivartikla

šifra i nazivartikla

rekapitulacijaizlaznih međuskl.

izlaznameđuskladišnica

Šefveleprodaje rekapitulacija

izlaznih međuskl.

4.1. Izrada dok.izlazna

međuskladišnicaza odabrano

skladištemaloprodaje

izlaznameđuskl.

183

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četakZahtjev za izdavanjeartikala u područno

skladište

Izrada izlaznemeđuskladišnice

Jošartikala za izlaznu

međuskl.?

Da

Kraj

Izrada stavkeartikala za izlaznumeđuskladišnicu

Ispis izlaznemeđuskladišnice

Ne

Izlaznameđuskladišnica

Odabir lokacije(područno skladište)

184

b) Izrada cjenika veleprodaje

Početak

Zahtjev zaformiranje cjenika

Listanje artikalaiz cjenika (1)

Ima li jošartikala (1)?

Ne

Da

Ne

Da

Listanje artikala izpopisa artikala (2)

Izmjenapostojećecijene?

Da

Odabir artikla inabavne cijene

Dodavanjenovog artikla u

cjenik?

Kraj

Ne

Da

Da liveć postoji

cjenik?

Upis nove cijeneza artikal u cjenikNe

velep. cijena =nab. cijena + marža

Upis artikla ivelep. cijene u

cjenik

Odabir nabavnecijene za artikal

velep. cijena =nab. cijena + marža

Upis artikla ivelep. cijene u

cjenik

Ima li jošartikala (2)?

Da

Ne

Ispis cjenika Cjenik

185

ZADATAK 3: Za prethodni primjer seminarskog rada skicirati unosnu masku za Cjenik. Rješenje:

ZADATAK 4: Za prethodni primjer seminarskog rada skicirati izgled izvješća Šifarnik artikala. Rješenje:

“VE-MA” d.o.o. 04.03.2003 Južna ulica 10, SPLIT

Popis artikala

Rb. Šifra Naziv JM Minim. kol. za poduzeće

Maksim. kol. 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

i

Literatura

1. Barker, R.: CASE*METHOD Tasks and Deliverables, Addison-Wesley Publishing Company, 1991.

2. Brumec, J. Strateško planiranje IS-a, FOI Varaždin, 1997. 3. Brumec, J.: Epistemiologija CASE alata, CASE 6, Opatija, 1994. 4. Brumec, J.: Projektiranje i metodike razvoja IS-a,Euro Data, Zagreb, 1996. 5. Brumec, J: Optimizacija strukture informacijskog sustava, Zbornik radova, FOI Varaždin,

1993. 6. Čerić et al: Poslovno računarstvo, Znak, Zagreb, 1998. 7. Čurčić, Grabowski, Štahan: Kako napraviti razvojni program i elaborat o procjeni vrijednosti

poduzeća, TEB, Zagreb, 1992. 8. Jandrić, K.: Administracija podataka u poduzeću, Časopis za teoriju i praksu osiguranja

"Osiguranje i privreda" god. XXXIII br. 4., Croatia osiguranje d.d., 1993. 9. Jandrić, K.: Jedinstveni IS - utopija ili stvarnost , CASE 6, Opatija, 1994. 10. Jandrić, K.: Kada i kako rekonstruirati informacijski sustav, Infotrend br. 24/7, Zagreb, 1994. 11. Jandrić, K.: Primjena rječnika podataka u razvoju informacijskog sistema Končar, CASE 3,

Opatija, 1991. 12. Klaić, B: Veliki rječnik stranih riječi, Zagreb, 1968. 13. Klasić, K. Modeli optimizacije strukture informacijskog sustava, doktorska disertacija, FOI

Varaždin, 1998. 14. Klasić, K.: Zaštita informacijskih sustava, Iproz, Zagreb, 2002. 15. Klasić, K: Novi pristup određivanju temeljne arhitekture informacijskog sustava, CASE 10,

Opatija, 1998. 16. Krakar, Z.: Efekt paradoksa, Infotrend br.51/10/1996, Zagreb 17. Krakar,Z: ISO sustavi kvalitete u informatici, HGK, Zagreb, 1997. 18. Martin, J. i McClure, C.: Software Maintenance: The Problem and Its Solution, Prentice Hall,

Englewood Cliffs, NY, 1985. 19. Martin, J.: J. Martin World Seminar, Savant, 1995. 20. Martin, J: Information Engineering: Introduction, Prentice Hall, Englewood Cliffs, NY 1990. 21. Međunarodna norma ISO 8402, Upravljanje kvalitetom i osiguranje kakvoće, Rječnik, HrQA

INFO, 1994. 22. Međunarodna norma ISO 9000-3, Norma za upravljanje kakvoćom i osiguranje kakvoće, Dio

3: Smjernice za primjenu ISO 9001 u razvoju, dobavljanju i održavanju softvera, HrQA INFO, 1993.

23. Panian, Ž.: Poslovna informatika, Potecon, Zagreb, 2001. 24. Pavlić, M.: Razvoj informacijskih sustava, Znak, Zagreb, 1996. 25. Radošević, D: Teorija sistema i teorija informacija, FOI, Varaždin, 1975. 26. Radovan, M: Projektiranje informacijskih sistema, Informator, Zagreb, 1989. 27. Srića et al: Menedžerska informatika, MEP Consulting, Zagreb, 1999 28. Strahonja, V. et al.: Projektiranje informacijskih sustava, Zavod za informatičku djelatnost

RH i Ina Info, Zagreb, 1992 29. Strahonja, V.: Zrelost informacijskog sustava, Infotrend br. 43/2/1996, Zagreb 30. Topolovec, V.:Klaster analiza: algoritmi i aplikacije na procese rasta, doktorska disertacija,

Zagreb, 1980. 31. Van Vliet, H.: Software Engineering, Wiley& Sons, NY, 2000.