Anamarija Leben RAZVOJ INFORMACIJSKIH SISTEMOV ZA PODPORO POSLOVNIM PROCESOM Študijsko gradivo Ljubljana, 2022 © Univerza v Ljubljani, Fakulteta za upravo, 2022. Vse pravice pridržane. Brez pisnega dovoljenja založnika je prepovedano reproduciranje, distribuiranje, javna priobčitev, predelava ali druga uporaba tega avtorskega dela ali njegovih delov v kakršnem koli obsegu ali postopku, vključno s fotokopiranjem, tiskanjem ali shranitvijo v elektronski obliki. Tako ravnanje je, razen v primerih iz 46. do 57. člena Zakona o avtorski in sorodnih pravicah, kršitev avtorske pravice. Kataložni zapis o publikaciji (CIP) pripravili v Narodni in univerzitetni knjižnici v Ljubljani COBISS.SI-ID 120623107 ISBN 978-961-262-130-8 (PDF) Avtor: Anamarija Leben Naslov: Razvoj informacijskih sistemov za podporo poslovnim procesom: študijsko gradivo Izdala in založila: Fakulteta za upravo, Univerza v Ljubljani Gosarjeva ulica 5, Ljubljana Za založbo: prof. dr. Maja Klun Priprava za tisk: Anamarija Leben Vrsta gradiva: e-gradivo, oblika: pdf Izdaja: Prva izdaja, Ljubljana 2022 KAZALO VSEBINE Uvod ........................................................................................................................................................ 7 1. poglavje: Osnovni pojmi, Informatizacija uprave ............................................................................. 9 2. poglavje: Upravljanje poslovnih procesov ...................................................................................... 21 3. poglavje: Načrtovanje in gradnja informacijskih sistemov ............................................................. 29 4. poglavje: Analiza in modeliranje informacijskih sistemov .............................................................. 37 5. poglavje: Modeliranje procesov ..................................................................................................... 47 6. poglavje: Modeliranje podatkov .................................................................................................... 81 7. poglavje: Model entiteta-povezava (E-R model) ............................................................................ 89 8. poglavje: Razvoj in dokumentiranje E-R modela ............................................................................ 99 9. poglavje: Izvedbeni podatkovni modeli ........................................................................................ 111 10. poglavje: Informacijska orodja za razvoj IS ................................................................................... 119 11. poglavje: Metodološki pristopi k razvoju IS .................................................................................. 125 12. poglavje: Projektno vodenje razvoja IS ........................................................................................ 131 KAZALO PONAZORITEV Kazalo slik Slika 1: Shematski prikaz poslovnega procesa ....................................................................................... 12 Slika 2: Notranja vrednostna veriga, prilagojena za upravne organizacije ............................................. 13 Slika 3: Tipične poslovne funkcije .......................................................................................................... 14 Slika 4: Od avtomatizacije do e-uprave .................................................................................................. 15 Slika 5: Cikel upravljanja poslovnih procesov ......................................................................................... 22 Slika 6: Tipična funkcijska organiziranost ............................................................................................... 23 Slika 7 Tipična funkcijska organiziranost uprave .................................................................................... 24 Slika 8: Poslovni proces in poslovne funkcije ......................................................................................... 25 Slika 9: Merjenje zrelosti procesne usmerjenosti .................................................................................. 25 Slika 10: Tri ključne karakteristike procesov .......................................................................................... 26 Slika 11: Življenjski cikel razvoja IS ......................................................................................................... 33 Slika 12: 4-stopenjski model razvoja IS .................................................................................................. 34 Slika 13: Modeliranje – preslikava stvarnosti v model ........................................................................... 38 Slika 14: Seznam konceptov modeliranja IS ........................................................................................... 41 Slika 15: Osnovni koncepti opredelitve procesov .................................................................................. 49 Slika 16: Primeri osnovnih konceptov opredelitve procesov – upravni postopek .................................. 50 Slika 17: Strukturni graf .......................................................................................................................... 50 Slika 18: Shematski prikaz funkcijskega grafa ........................................................................................ 52 Slika 19: Funkcijski graf za obračunavanje plač ...................................................................................... 52 Slika 20: Osnovni koncepti modeliranja v diagramu toka podatkov ...................................................... 53 Slika 21: Česa ne smemo povezati v DTP? ............................................................................................. 54 Slika 22: Prikaz procesne logike v diagramu poteka ............................................................................... 57 Slika 23: Prikaz procesne logike v diagramu aktivnosti .......................................................................... 59 Slika 24: Najpogostejši dogodki v BPMN ................................................................................................ 60 Slika 25: Osnovni prehodi v BPMN ......................................................................................................... 61 Slika 26: Prikaz procesne logike v BPMN ................................................................................................ 61 Slika 27: Grafični prikaz pravil osnovne verige za EPC diagram .............................................................. 63 Slika 28: Prikaz procesne logike v EPC diagramu .................................................................................... 64 Slika 29: organizacijski objekt (proga) v razširjenem diagramu poteka .................................................. 66 Slika 30: Organizacijski objekt (proga) v razširjenem diagramu aktivnosti ............................................. 67 Slika 31: Dodatni objekti v razširjenem BPMN diagramu ....................................................................... 67 Slika 32: Grafični prikaz dodatnih pravil za oblikovanje eEPC diagrama ................................................ 69 Slika 33: Primer klasifikacije ................................................................................................................... 84 Slika 34: Grafični prikaz klasifikacije ....................................................................................................... 85 Slika 35: Grafični prikaz generalizacije ................................................................................................... 85 Slika 36: Primer kartezične agregacije ................................................................................................... 86 Slika 37: Primer agregacije na ravni tipov .............................................................................................. 86 Slika 38: Povezovanje konceptov generalizacije in agregacije na ravni tipov ......................................... 87 Slika 39: Tip entitete – primerek entitete – atribut – vrednost atributa ................................................ 91 Slika 40: Primer sestavljenega atributa .................................................................................................. 91 Slika 41: Primer binarne povezave ......................................................................................................... 93 Slika 42: Primer ternarne povezave ....................................................................................................... 94 Slika 43: Tipi in primerki povezav ........................................................................................................... 94 Slika 44: Primeri kardinalnosti povezave ................................................................................................ 95 Slika 45: Primeri obveznosti povezave ................................................................................................... 95 Slika 46: Kardinalnost in obveznost povezav .......................................................................................... 96 Slika 47: Primer rekurzivne povezave .................................................................................................... 96 Slika 48: Notacija E-R diagrama.............................................................................................................. 96 Slika 49: Kardinalnost in obveznost povezav (Martinova notacija) ........................................................ 97 Slika 50: E-R diagram za prijavljanje/odjavljanje na izpitni rok ............................................................ 102 Slika 51: Primer vpeljave presečne entitete ......................................................................................... 104 Slika 52: Hierarhična drevesna struktura ............................................................................................. 112 Slika 53: Izsek iz hierarhičnega podatkovnega modela za podjetje ...................................................... 113 Slika 54: Struktura mrežnega modela .................................................................................................. 114 Slika 55: Izsek iz mrežnega podatkovnega modela za podjetje ............................................................ 114 Slika 56: Primer relacijske tabele ......................................................................................................... 115 Slika 57: Izsek iz relacijskega podatkovnega modela............................................................................ 116 Slika 58: Razmerje med razvojnimi in obratovalnimi stroški v odvisnosti od generacije programskih jezikov .................................................................................................................................................. 120 Slika 59: Terminski načrt izvedbe projekta v obliki gantograma .......................................................... 134 Slika 60: Mrežni diagram izdelkov projekta ......................................................................................... 134 Slika 61: Organizacijska shema projekta .............................................................................................. 135 Kazalo tabel Tabela 1: X2Y matrika storitev ............................................................................................................... 18 Tabela 2: (Ne)uspešnost IT projektov .................................................................................................... 30 Tabela 3: Modeli različnih pogledov na poslovni sistem ........................................................................ 40 Tabela 4: Obravnava procesnega in podatkovnega pogleda skozi 4-stopenjski model razvoja IS ......... 41 Tabela 5: Seznam informacijskih potreb za proces obravnave seminarskih nalog................................. 43 Tabela 6: Seznam podatkovnih elementov za proces obravnave seminarskih nalog ............................. 44 Tabela 7: Osnovni koncepti modeliranja v diagramu poteka ................................................................. 56 Tabela 8: Osnovni koncepti modeliranja v diagramu aktivnosti ............................................................. 58 Tabela 9: Osnovni koncepti modeliranja v BPMN diagramu .................................................................. 60 Tabela 10: Osnovni koncepti modeliranja v EPC diagramu .................................................................... 62 Tabela 11: Primer odločitvene tabele za upravni postopek ................................................................... 65 Tabela 12: Dodatni koncepti modeliranja v ePC diagramu .................................................................... 68 Tabela 13: Seznam entitet za prijavljanje/odjavljanje na izpitni rok .................................................... 100 Tabela 14: Shematski prikaz slovarja entitet ........................................................................................ 103 Tabela 15: Nepopoln slovar entitet za prijavljanje/odjavljanje na izpitni rok ...................................... 106 Tabela 16: Slovar entitet za prijavljanje/odjavljanje na izpitni rok ....................................................... 107 Tabela 17: Shematski prikaz slovarja atributov .................................................................................... 108 Tabela 18: Izsek iz slovarja atributov za prijavljanje/odjavljanje na izpitni rok .................................... 109 Uvod Pričujoče gradivo je namenjeno študentom visokošolskega strokovnega študijskega programa Uprava, 1. stopnja, na Fakulteti za upravo Univerze v Ljubljani. Zajema obvezno osnovno gradivo ločeno po poglavjih, ki sledijo načrtu predavanj za predmet Razvoj informacijskih sistemov za podporo poslovnim procesom. V gradivu so zbrana poglavja, ki so bila do sedaj v e-učilnici predmeta objavljena posamično. S tem želim študentom zagotoviti osnovno gradivo, zbrano na enem mestu. Je pa gradivo oblikovano tako, da si študenti lahko enostavno natisnejo posamezna poglavja. Za konec želim poudariti, da je to le osnovno gradivo za študij. Za uspešen študij pri predmetu je treba upoštevati še vsa ostala gradiva, ki bodo še vedno ločeno objavljena v e-učilnici. Anamarija Leben 7/136 1. poglavje: Osnovni pojmi, Informatizacija uprave V tem poglavju bomo opredelili nekaj osnovnih pojmov, s katerimi se bomo srečevali skozi ves predmet, ter podrobno predstavili proces uvajanja informacijske tehnologije (IT) v upravo. Že ime predmeta pove, da se bomo ukvarjali z informacijskimi sistemi (IS), pri čemer moramo seveda vedeti, kaj to je. Informacijski sistemi pa niso sami sebi namen, ampak jih razvijamo za podporo delovanju poslovnega sistema. Zato bomo uvodoma opredelili pojma informacijski in poslovni sistem, pa tudi osvežili znanje o tem, kaj je podatek in kaj informacija. Nato se bomo posvetili poslovnim procesom. Zavedati se moramo, da IS niso nujno računalniško podprti, saj so obstajali že pred razvojem prvih računalnikov. Spomnimo se npr. kartotečnih sistemov v knjižnicah pa tudi za spremljanje dokumentacijskega gradiva v upravi. Res pa je, da si sodobnih IS brez ustrezne podpore IT ne moremo predstavljati. Zato si bomo v nadaljevanju pogledali tudi, kako je zgodovinsko potekalo uvajanje IT v upravo. Vsebina poglavja 1.1 Osnovni pojmi ................................................................................................................................ 10 1.1.1 Informacijski sistem ........................................................................................................... 10 1.1.2 Poslovni sistem .................................................................................................................. 10 1.1.3 Poslovni proces .................................................................................................................. 11 1.1.3.1 Opredelitev (definicija) poslovnega procesa .................................................................. 11 1.1.3.2 Značilnosti poslovnega procesa ..................................................................................... 12 1.1.3.3 Porterjeva vrednostna veriga ......................................................................................... 13 1.1.4 Poslovna funkcija ............................................................................................................... 13 1.2 Informatizacija uprave ................................................................................................................... 14 1.2.1 Značilnosti uprave z vidika IT ............................................................................................. 14 1.2.2 Kronološki razvoj uvajanja IT v slovensko upravo .............................................................. 15 1.2.2.1 Karakteristična obdobja uvajanja IT ............................................................................... 15 1.2.2.2 Ključne točke procesa informatizacije organizacij ......................................................... 16 1.2.2.3 E-uprava ......................................................................................................................... 17 1.2.2.4 Elektronske storitve uprave ........................................................................................... 17 Viri in literatura ...................................................................................................................................... 18 9/136 Osnovni pojmi, Informatizacija uprave 1.1 Osnovni pojmi 1.1.1 Informacijski sistem Heeks (2002) informacijske sisteme (IS) opredeljuje kot »sisteme, sestavljene iz človeških in tehničnih komponent, ki sprejemajo, shranjujejo, obdelujejo, oddajajo in prenašajo informacije. Njihova osnova je lahko kakršnakoli kombinacija človekovega dela, papirnih postopkov in IT«. Ali povedano drugače (Ralston, 1976, v Vintar, 2006): Informacijski sistem (IS) je skupek ljudi, postopkov in naprav, zasnovan za zbiranje, obdelavo, shranjevanje in distribucijo podatkov oziroma informacij. Kot je razvidno iz gornjih opredelitev, podatki/informacije niso sestavina IS, saj le-ta z njimi nekaj dela; podatki/informacije so torej vhodi in izhodi ter predmet obdelave v IS. Na tem mestu si osvežimo znanje o tem, kakšna je razlika med podatkom in informacijo1:  podatek = znano dejstvo o določeni stvari, predmetu, pojavu,  informacija = podatki, obdelani in predstavljeni tako, da so uporabniku razumljivi in povečajo njegovo znanje. Strogo gledano je informacija pomensko torej več kot podatek, saj zahteva, da prejemnik podatek razume in da poveča njegovo znanje. V okviru tega predmeta med obema pojmoma ne bomo delali razlik in ju bomo uporabljali kot sopomenki. 1.1.2 Poslovni sistem Naslednja definicija vzpostavlja razmerje med IS in poslovnim sistemom (pri čemer v ničemer ne nasprotuje gornji opredelitvi IS): Informacijski sistem predstavlja organizacijsko tehnološko okolje za upravljanje z informacijami in informacijskimi tokovi obravnavanega poslovnega sistema. Pa si poglejmo, kaj je poslovni sistem (PS). Mavrič (2007) PS definira kot: »od okolja razmejeno in zaokroženo smiselno celoto, ki se ukvarja s poslovanjem s pridobitnim ali nepridobitnim namenom«. Še splošneje pa lahko rečemo: Poslovni sistem (PS) je organizirano okolje, v katerem se izvaja neka osnovna dejavnost. Primeri: Fakulteta za upravo – izobraževalna dejavnost, Mercator – trgovska dejavnost, SKB banka – bančništvo … Po eni strani je IS torej podsistem poslovnega sistema (PS) in podpira njegovo delovanje. Je pomemben del PS, saj si brez pravih informacij na pravem mestu in ob pravem času težko zamislimo uspešno delovanje PS. Vintar (2006) pa opozarja: »po drugi strani pa IS predstavlja le en vidik obravnave PS, kar pomeni, da je IS dejansko delni sistem PS, ki le-tega obravnava z informacijskega vidika«. In dodaja, da smo ga pri načrtovanju in gradnji IS iz praktičnih razlogov prisiljeni 'izločiti' iz PS, ker tak pristop poenostavi opredelitev in modeliranje značilnosti delovanja načrtovanega IS. 1 Islovar. Dostopno na http://www.islovar.org 10/136 Osnovni pojmi, Informatizacija uprave V nadaljevanju se bomo pogosto srečevali tudi z izrazom informacijska tehnologija, zato je prav, da opredelimo še to2: Informacijska tehnologija (IT) je tehnologija, ki omogoča zbiranje, obdelavo, shranjevanje, razpošiljanje ter uporabo podatkov, informacij. In ne nazadnje: upravo v okviru tega predmeta obravnavamo kot sklop upravnih organizacij in ne kot določeno dejavnost (upravljanje). Torej upravo razumemo kot poslovni sistem, katerega osnovna dejavnost je upravljanje, ki pomaga pri uresničevanju temeljnih nalog države. Za konec navedimo še nekaj primeri IS v upravi:  Register prebivalstva  Zemljiški kataster  Zemljiška knjiga  Davčni informacijski sistem  Zdravstveni informacijski sistem  Kadrovski informacijski sistem 1.1.3 Poslovni proces 1.1.3.1 Opredelitev (definicija) poslovnega procesa Davenport (1993) opredeljuje: Poslovni proces (PP) je strukturirana množica aktivnosti, katerih rezultat je nek proizvod ali storitev (s tržno vrednostjo). Ima jasno opredeljene vhode in izhode, ki predstavljajo neko dodano vrednost za uporabnike. Praviloma se sestoji iz več postopkov in posega na več funkcijskih področij (poslovnih funkcij). Iz te definicije lahko izluščimo:  PP je strukturirana množica aktivnosti: to pomeni, da ne gre samo za nek skupek aktivnosti, ampak da so aktivnosti organizirane v neko strukturo, da so medsebojno časovno odvisne in povezane;  rezultat PP je vedno nek proizvod ali storitev (če tega ni, ne moremo govoriti o poslovnem procesu);  proizvod ali storitev ima tržno vrednost (ga/jo lahko prodamo na trgu): to velja prvenstveno v privatnem sektorju; v upravi težko govorimo o tržni vrednosti, prav gotovo pa morajo PP v upravi zagotavljati storitve za uporabnike;  jasno opredeljeni vhodi in izhodi – ti so lahko v različni obliki (materialni, finančni, energetski, informacijski), pri čemer velja, da mora imeti vsak PP vsaj en vhod in vsaj en izhod;  izhodi morajo imeti za uporabnika neko dodano vrednost (ne nujno samo finančno);  praviloma sestoji iz več postopkov – manjših, zaključenih sklopov aktivnosti;  praviloma posega na več funkcijskih področij – to pomeni, da se ne izvaja samo v eni poslovni funkciji, ampak vključuje aktivnosti iz več funkcijskih področij. Slika 1 shematsko prikazuje gornjo definicijo. S puščicami so predstavljene aktivnosti, s krogci pa začetek in konec (temneje obarvani) ter vmesna stanja (svetleje obarvani); ta stanja nastanejo, ko se zaključi neka aktivnost. torej velja: vsaka aktivnost spremeni stanje sistema. 2 Islovar. Dostopno na http://www.islovar.org 11/136 Osnovni pojmi, Informatizacija uprave Slika 1: Shematski prikaz poslovnega procesa V literaturi (npr. Kovačič & Bosilj Vukšić, 2005, str. 29) zasledimo tudi naslednjo opredelitev: »poslovni proces je skupek logično povezanih izvajalskih in nadzornih postopkov ter aktivnosti, katerih izid je načrtovani izdelek ali storitev«. Ta definicija ni v ničemer skregana z gornjo, le ožja oz. manj natančna je. 1.1.3.2 Značilnosti poslovnega procesa Davenport (1993) pa ob gornji definiciji izpostavlja tudi značilnosti poslovnega procesa, ki jih je treba upoštevati pri analiziranju in prenavljanju procesov:  Cilji, ključni dejavniki uspeha: vsak PP mora imeti jasne cilje (kaj želimo doseči – seveda skladno s strategijo in cilji poslovnega sistema) skupaj s ključnimi dejavniki uspeha, ki povedo, kaj je tisto, brez česar ciljev ne bomo dosegli.  Skrbnik (lastnik) procesa: to ni izvajalec, temveč oseba, pooblaščena in odgovorna za izvajanje in izboljšavo procesa.  Jasen začetek in konec: to se sliši povsem samoumevno, vendar ni pri vseh procesih povsem jasno, kje se začnejo in kje končajo. Npr. pri upravnih postopkih (ki so dejansko procesi), je začetek običajno dokaj jasen (vložena vloga ali zahteva), ni pa nujno – lahko se odločimo, da v proces vključimo tudi aktivnosti pred samo vložitvijo (npr. informiranje stranke o zahtevani dokumentaciji). Podobno velja za konec procesa: je to izdana odločba, vročena odločba, polnomočna odločba? Vse navedeno vpliva na obseg procesa in njegove aktivnosti.  Vhodi in izhodi oz. rezultati: o tem smo govorili pri razlagi definicije PP; tu omenimo le, da vsak PP preoblikuje (transformira) vhode v izhode.  Aktivnosti in njihova medsebojna povezanost (časovna odvisnost): ni dovolj, da vemo, katere aktivnosti proces vsebuje, ampak kako so te aktivnosti medsebojno odvisne – govorimo o procesni logiki oz. logiki izvajanja: aktivnosti se lahko izvajajo zaporedno (druga za drugo), vzporedno (hkrati se izvaja več aktivnosti) ali pa kot alternative (različne možne poti izvajanja).  Dodana vrednost za uporabnika in organizacijo: pri opredelitvi PP smo izpostavili predvsem dodano vrednost za uporabnika, vendar pa naj bi PP imel neko dodano vrednost za organizacijo – poslovni sistem, v katerem se proces izvaja.  Kvantitativni kazalniki, ki zagotavljajo merljivost učinkovitosti procesa, kot so npr. stroški, čas in število pojavljanj. Če teh kazalnikov ni, procesov ne moremo analizirati, še manj pa prenavljati. 12/136 Osnovni pojmi, Informatizacija uprave 1.1.3.3 Porterjeva vrednostna veriga Glede na Porterjevo vrednostno verigo, ki skuša analizirati izvore konkurenčne prednosti nekega poslovnega sistema, lahko procese v poslovnem sistemu delimo na temeljne in podporne glede na to, kako ti procesi ustvarjajo vrednost in kaj določa njihove stroške:  temeljni: neposredno povezani z osnovno dejavnostjo (glavnega pomena za izdelavo izdelka oz. zagotavljanja storitve) – neposredno prispevajo k povečevanju dodane vrednosti;  podporni: podpirajo osnovno dejavnost in zagotavljajo optimalen razvoj in nadzor nad delovanjem temeljnih procesov. Slika 2: Notranja vrednostna veriga, prilagojena za upravne organizacije Skupno delovanje vseh pa pripelje do dodane/primerjalne vrednosti (kot izhoda iz verige), ki poslovnemu sistemu daje konkurenčno prednost. Slika 2 prikazuje, kako bi lahko 'notranjo' Porterjevo verigo prilagodili za upravne organizacije. Podrobneje o vrednostni verigi preberite v učbeniku Tatjane Kosi »Poslovni procesi«, poglavje 3.3.3 1.1.4 Poslovna funkcija Pri opredelitvi PP smo rekli, da PP praviloma posega na več funkcijskih področij oz. poslovnih funkcij. Zato je prav, da opredelimo tudi ta pojem. Poslovno funkcijo lahko razumemo kot poslovno enoto v organizaciji, torej organizacijsko enoto, npr. kadrovska služba, finančna služba, proizvodnja, nabava … Vendar je to razumevanje preozko. Kot pravi Ivanko (2014, str. 153), je bil Henri Fayol prvi, ki je (že v začetku 20. stoletja) razčlenil skupno poslovanje podjetja na poslovne funkcije. Po Fayolu lahko vsa opravila v podjetju razdelimo na 6 skupin: tehnična skupina opravil (proizvodnja, predelava itd.), komercialni posli (nabava, prodaja, menjava), finančni posli (zbiranje in zagotavljanje kapitala), varnostna funkcija (zaščita premoženja in osebja), računovodska funkcija (inventar, bilanca, stroški, statistika itd.), administrativna funkcija (planiranje, organiziranje, ukazovanje, koordiniranje in kontrola). Lahko torej rečemo: Poslovna funkcija je skupek strokovno sorodnih ali istovrstnih opravil. 3 Učbenik je obvezno gradivo in je dostopen v e-učilnici. 13/136 Osnovni pojmi, Informatizacija uprave Pri poslovnih funkcijah je torej osnovno načelo členitev delovnih nalog na osnovi strokovno sorodnih opravil. To po eni strani omogoča specializacijo, po drugi pa koncentracijo znanja4. Posledica tega je višja učinkovitost in hitrejši razvoj poslovanja. Velja pa omeniti, da to velja tudi z vidika razvoja IS – IS lahko učinkoviteje in hitreje razvijemo, če jih razvijamo za določeno poslovno funkcijo. Slika 3 prikazuje tipične poslovne funkcije v poslovnih sistemih. Kot je razvidno, opravila iz posamezne poslovne funkcije posegajo na različne upravljavske ravni5. Slika 3: Tipične poslovne funkcije 1.2 Informatizacija uprave 1.2.1 Značilnosti uprave z vidika IT V tem poglavju bomo najprej izpostavili značilnosti uprave z vidika IT, ker bomo tako lažje razumeli posamezna zgodovinska obdobja vpeljave IT v upravo, ki si jih bomo pogledali v nadaljevanju. Izpostavimo lahko naslednje značilnosti:  uprava kot storitveni in informacijski servis: uprava je vsekakor storitveni servis, saj zagotavlja storitve svojim uporabnikom (državljanom, poslovnim subjektom, upravnim organizacijam …); je pa tudi informacijski servis, saj so osnovni 'material', ki ga uprava obdeluje in s katerim operira, podatki in informacije;  informatizacija uprave, torej vpeljava IT v delovanje uprave (o tem bomo več spregovorili v nadaljevanju);  razvoj e-uprave, katerega posledica je usmerjenost k uporabnikom – če želimo storitve e-uprave ustrezno in učinkovito oblikovati, se moramo vprašati, kaj potrebujejo uporabniki, in izhajati iz njihovih potreb in želja;  obvladovanje procesov z namenom zniževanja stroškov, skrajševanja časov in zagotavljanja višje kakovosti storitev je povzročilo procesno usmerjenost uprave (tudi o tem več v nadaljevanju); 4 Je pa res, da se na tej podlagi oblikujejo delovna mesta, ki se združujejo v organizacijske enote – od tod razumevanje poslovnih funkcij kot poslovnih (organizacijskih) enot. 5 Tri ravni: (a) operativna raven – vsakodnevna, rutinska opravila in naloge; kratkoročno planiranje; (b) taktična raven – zahtevnejša opravila (analiziranje, napovedovanje in tudi vodenje operativne ravni), srednjeročno planiranje; in (c) strateška raven – najzahtevnejša opravila in naloge, povezane s strateškimi cilji PS, dolgoročno planiranje. 14/136 Osnovni pojmi, Informatizacija uprave  te procese je potrebno tudi ustrezno podpreti z IT – govorimo o t. i. informatizaciji procesov – to pa pomeni, da moramo vpeljati ustrezne IS; to je torej tisto, kar nas sili v razvoj IS. Zanimivo je, da tehnološki razvoj vpliva tudi na organizacijsko miselnost in organizacijo dela tako v poslovnem svetu kot tudi v upravi; v zvezi s tem lahko govorimo o treh različnih fazah: 1. faza: osredotočenost na tehnologijo (do konca 70-ih let prejšnjega stoletja): v ospredju je tehnologija, torej kako s tehnologijo olajšati delo, določena opravila; 2. faza: osredotočenost na podatke (do začetka 90-ih let prejšnjega stoletja): v ospredju so podatki, torej pridobivanje, obdelava, shranjevanje in uporaba podatkov; 3. faza: osredotočenost na procese (od začetka 90-ih let dalje): v ospredju so procesi, kar pomeni, da nas zanima predvsem, kako z ustrezno IT podpreti potek procesov. 1.2.2 Kronološki razvoj uvajanja IT v slovensko upravo 1.2.2.1 Karakteristična obdobja uvajanja IT V tem poglavju si bomo pogledali, kako je zgodovinsko potekalo uvajanje IT v upravo v Sloveniji, saj nam to posredno pove tudi, kakšen je bil razvoj IS v slovenski upravi v preteklosti. Ugotovimo lahko, da smo v slovenski upravi začeli z uvajanjem informacijske tehnologije razmeroma zgodaj. Prvi začetki segajo v zgodnja 70. leta prejšnjega stoletja – v tem pogledu slovenska uprava nič ne zaostaja za upravami drugih razvitih zahodnoevropskih držav, s katerimi se najpogosteje primerjamo. Danes govorimo o več kot petih desetletjih razvoja tega področja, ki ga lahko razdelimo v nekaj karakterističnih obdobij; narava, način in uporaba IT v 70. letih se je namreč zelo razlikovala od načina, kakovosti in uporabe IT v 90. letih, kaj šele v začetku 21. stoletja. Prišlo je do izjemno kakovostnega preskoka. Slika 4 prikazuje karakteristična obdobja uvajanja IT v slovensko upravo, hkrati pa tudi področja, na katera se je vpeljava IT v posameznem obdobju osredotočila. Tu bomo na kratko opisali posamezna obdobja, več o tem pa v Vintar (2004, 2006). Slika 4: Od avtomatizacije do e-uprave 15/136 Osnovni pojmi, Informatizacija uprave Karakteristična obdobja so6: 1. avtomatizacija: 1970–1990: pri uvajanju IT (oz. kar računalnikov) v delovanje uprave je šlo prvenstveno za avtomatizacijo preprostih rutinskih, a množičnih opravil, na operativni ravni; večinoma obdelava strogo oblikovanih številčnih podatkov; IS se razvijejo za ozka, zaprta področja dela; 2. informatizacija: 1990–2000: uporaba IT se v tem obdobju širi iz operativne ravni vse bolj na taktično raven; vpeljuje se tudi obdelava besedil ter zahtevne vsebinske analize poljubnih informacij; celotno poslovanje organizacije, se pravi njen celotni poslovni sistem, se podpre z različnimi informacijskimi rešitvami, z informacijskimi sistemi, skratka z informacijsko tehnologijo; 3. e-uprava: 2000: razširjena uporaba interneta in hiter razvoj IT povzroči vpeljavo IT na vse ravni in vsa področja (notranje in zunanje) delovanja uprave. Primerjavo karakteristik v posameznih obdobjih podaja članek »E-uprava – pogled pod lupino« (Vintar, 2004)7. 1.2.2.2 Ključne točke procesa informatizacije organizacij Ključne točke procesa informatizacije organizacij so:  Uvajanje informacijske tehnologije v vse faze zbiranja, obdelave, shranjevanja in posredovanja informacij. To je osnova, je tisto, kar je zajeto že v sami avtomatizaciji, gre torej za uvajanje računalnikov v naše delo, v naše poslovanje. Tisto, kar informatizacijo ločuje od avtomatizacije, je zajeto v naslednjih štirih točkah.  Prenova poslovnih procesov na osnovi inovativne uporabe IT. To je izrednega procesa – za uspešno informatizacijo potrebujemo prenovo poslovanja torej prenovo procesov8, in sicer prej, preden IT uvedemo v poslovanje; prenova torej predstavlja neko podlago, osnovo za uvedbo IT.  Preureditev informacijskih tokov ter njihova prilagoditev možnostim IT. Načini komuniciranja, informacijski kanali in informacijske poti so se namreč radikalno spremenili; pomislimo samo na mobilno telefonijo, elektronska pošto, internetno telefonijo (npr. Skype), uporabo spletnih obrazcev, mobilnih aplikacij ipd.  Prilagoditev ali sprememba organizacijske strukture, v katero se uvaja sodobna tehnologija. Uspešno uvajanje IT je možno samo ob ustrezni reorganizaciji, ob ustrezni prilagoditvi organizacijskih struktur znotraj organizacije dela. Uprava je v tem pogledu žal precej okostenela, zato nas tu čaka še veliko dela.  Prilagoditev metod menedžmenta uporabi sodobnih informacijskih virov. Dolgo časa je doktrina menedžmenta slonela na dveh stebrih: obvladovanje na eni strani finančnih tokov, na drugi strani pa človeških virov (denar/kapital in ljudje). Že nekaj časa pa je jasno, da so informacije enako pomemben steber. V organizacijah je postalo upravljanje z informacijami enako pomembno kot upravljanje z kapitalom in ljudmi. Morda postaja celo najpomembnejši dejavnik dobrega menedžmenta. Zavedati se moramo, da to niso posamezni koraki v procesu informatizacije, ampak da gre za različne dimenzije, ki se med seboj nujno prepletajo. 6 Letnice, ki so navedene, so okvirne, zato jih ne smemo vzeti preveč ostro. 7 Članek je obvezno gradivo za predmet in je objavljen v e-učilnici. 8 Več o prenovi procesov bomo govorili v 2. poglavju predavanj. 16/136 Osnovni pojmi, Informatizacija uprave 1.2.2.3 E-uprava Vintar (2004, str. 5) podaja naslednjo opredelitev e-uprave: E-uprava je uprava, katere celotno poslovanje temelji na uporabi elektronskih dokumentov, e-poslovanja in interneta v njenem notranjem in zunanjem poslovanju, uvajanju novih sistemskih in organizacijskih rešitev ter novih modelov upravljanja. Iz definicije lahko izluščimo naslednje značilnosti e-uprave:  sodobna IT je vključena v celotno poslovanje (ne samo v posamezne segmente),  ne gre samo za notranje poslovanje, temveč tudi za zunanje (poslovanje s strankami),  osnovna tehnološka platforma poslovanja je internet,  poslovanje je elektronsko, na osnovi elektronskih dokumentov,  zahteva nove (drugačne) sistemske in organizacijske rešitve,  zahteva nove (drugačne) modele upravljanja. Če želimo doseči zgoraj navedeno, pa se moramo v povezavi z IS v upravi zavedati dvojega:  nujna je popolna integracija različnih IS: obstoječe pa tudi nove informacijske rešitve je treba nujno povezati v enovit sistem,  delovanje je popolnoma odvisno od IS: to pomeni, da moramo zagotoviti zanesljivo, varno in neprekinjeno delovanje informacijskih rešitev. 1.2.2.4 Elektronske storitve uprave Velikokrat se e-upravo preozko razume samo kot e-storitve: to so storitve na daljavo (ne zahtevajo neposrednega stika med ponudnikom in uporabnikom), ki pa se izvedejo v elektronski obliki. Vintar (2006) opredeljuje tri kategorije e-storitev (glej tudi Sliko 4):  e-informacijske storitve: so najpreprostejše, gre za ponudbo najrazličnejših informacij preko svetovnega spleta, torej enosmerni pretok informacij (od upravnih organizacij k uporabnikom);  e-komunikacijske storitve: uporabniki lahko na različne načine (e-pošta, spletni obrazci …) vzpostavijo dialog z uslužbencem; gre torej za dvosmerni pretok informacij;  e-transakcijske storitve: celovito reševanje upravnih postopkov od oddaje vloge/zahtevka do prejema rešitve na elektronski način.9 Hai & Ibrahim (2007) opredeljujeta upravne storitve po sektorjih – komu uprava zagotavlja svoje storitve. Ti sektorji so:  B – business – podjetja  C – citizens – občani, državljani  G – government – uprava  N – non-governmental, non-profit – nevladne, neprofitne organizacije 9 Strogo gledano, e-uprava zahteva, da se vloge/zahtevki tudi obdelajo (znotraj uprave) na elektronski način; torej da je tudi notranje poslovanje elektronsko. Z vidika uporabnika pa gre za e-transakcijo, če lahko vse uredi in dobi po elektronski poti. 17/136 Osnovni pojmi, Informatizacija uprave Tabela 1: X2Y matrika storitev X2Y B C G N B B2B B2C B2G B2N C C2B C2C C2G C2N G G2B G2C G2G G2N N N2B N2C N2G N2N Na podlagi zgoraj navedenega lahko oblikujemo t. i. X2Y matriko storitev (Tabela 1), ki jo beremo po vrsticah; prva črka pove kdo zagotavlja storitev, druga pa komu. Upravne storitve (pa tudi e-storitve) tako opredeljuje predzadnja vrstica, saj je uprava (G) tista, ki zagotavlja storitve različnim sektorjem: podjetjem (B), občanom (C), upravi (G – v tem primeru lahko govorimo o notranjih storitvah uprave) in nevladnim/neprofitnim organizacijam (N). Viri in literatura Hai J. C. & Ibrahim. (2007). Fundamental of Development Administration. Selangor: Scholar Press. Heeks, R. (2002). Reinventing government in the information age. V: R. Heeks (ur.), Reinventing Government in the Information Age: International Practice in IT-enabled Public Sector Reform (1. poglavje). London: Routledge. Pridobljeno 5. 4. 2015, s http://www.google.si/books?id=MOCFAgAAQBAJ&printsec=frontcover&hl=sl&source=gbs_ge_s ummary_r&cad=0#v=onepage&q&f=false Ivanko, Š. (2014). Teorija organizacije. Ljubljana: Fakulteta za upravo. Kosi, T. (2010). Poslovni procesi [elektronski vir]. Ljubljana: Zavod IRC. Dostopno na: http://www.impletum.zavod-irc.si/docs/Skriti_dokumenti/Poslovni_procesi-Kosi.pdf Mavrič, F. (2007). Poslovni sistem [prosojnice za predavanja]. Pridobljeno s http://www.muchvs.si/files/Gradiva/OMP/2-4-poslovni-sistem.pdf Ralston, A. (1976). Encyclopedia of Computer Science. Van Nostrand Reinhold Company. Vintar, M. (2004). E-uprava – pogled pod lupino. V: M. Vintar & J. Grad (ur.), E-uprava: Izbrane razvojne perspektive (str. 3–12). Ljubljana: Fakulteta za upravo. Vintar, M. (2006). Informatika. Ljubljana: Fakulteta za upravo. 18/136 Osnovni pojmi, Informatizacija uprave Kaj moram vedeti?  Informacijski sistem  Tipični primeri IS v upravi  Poslovni sistem  Poslovni proces  Značilnosti poslovnega procesa  Porterjeva vrednostna veriga za upravo  Poslovna funkcija  Primerjava poslovni proces : poslovna funkcija  Kronološki razvoj informatizacije uprave  Karakteristična razvojna obdobja – primerjava  Razvoj e-uprave in IS  E-storitve uprave z lastnimi konkretnimi primeri  X2Y matrika storitev 19/136 2. poglavje: Upravljanje poslovnih procesov V 1. poglavju predavanj, ko smo govorili o informatizaciji uprave, smo med drugim ugotovili dvoje: (1) ena glavnih značilnosti v sodobnih poslovnih sistemih je osredotočenost na procese, torej procesna usmerjenost; in (2) ključna točka informatizacije poslovanja in še bolj razvoja e-poslovanja (torej tudi e-uprave) je prenova poslovnih procesov. Kot že rečeno, je oboje namreč izrednega pomena za uspešen razvoj takih IS, ki podpirajo poslovanje sodobnih PS. In ker je uprava kot sklop upravnih organizacij poslovni sistem, navedeno seveda velja tudi za upravo. Obe ugotovitvi se povezujeta s poslovnimi procesi, ki smo jih tudi že spoznali v 1. poglavju. Poleg tega pa se širše gledano vključujeta v upravljanje poslovnih procesov (ang. Business Process Management – BPM). Zato bomo najprej opredelili, kaj upravljanje poslovnih procesov (UPP) sploh je, nato podrobneje spoznali funkcijsko in procesno usmerjenost, poglavje pa zaključili s prenovo poslovnih procesov. Vsebina poglavja 2.1 Upravljanje poslovnih procesov ..................................................................................................... 22 2.1.1 Opredelitev upravljanja poslovnih procesov ...................................................................... 22 2.1.2 Cikel upravljanja poslovnih procesov ................................................................................. 22 2.2 Funkcijska organiziranost in usmerjenost ...................................................................................... 23 2.3 Procesna organiziranost in usmerjenost ........................................................................................ 24 2.4 Prenova poslovnih procesov .......................................................................................................... 25 Viri in literatura ...................................................................................................................................... 27 21/136 Upravljanje poslovnih procesov 2.1 Upravljanje poslovnih procesov 2.1.1 Opredelitev upravljanja poslovnih procesov V literaturi lahko zasledimo različne opredelitve, v okviru našega predmeta pa se bomo naslonili na naslednjo (ABPMP, 2019): Upravljanje poslovnih procesov (UPP) je organiziran in discipliniran pristop k identifikaciji, načrtovanju, izvajanju, dokumentiranju, spremljanju, nadzorovanju in merjenju tako avtomatiziranih kot neavtomatiziranih poslovnih procesov, da bi zagotovili stalne, ciljne rezultate v skladu s strateškimi cilji organizacije. Iz gornje opredelitve je razvidno, da to niso samo neke aktivnosti, nametane skupaj, ampak so medsebojno povezane in imajo neka pravila, ki se jih je potrebno držati. Cilj UPP je zagotoviti rezultate, ki pripomorejo k uresničitvi strateških ciljev organizacije preko izboljševanja, urejanja, izvedbe in vodenja (predvsem) temeljnih poslovnih procesov, ki so lahko ali pa niso avtomatizirani, torej ustrezno podrti s tehnologijo, tudi informacijsko. Zavedati se moramo, da z UPP v splošnem ne predpisujemo nobene konkretne tehnologije in metodologije za samo izvedbo UPP. Res pa je, da sta tako uporabljena metodologija kot IT odvisni od sistema za upravljanje s poslovnimi sistemi (SUPP); torej informacijskega sistema, ki podpira UPP v posamezni organizaciji (Stopar, 2009). 2.1.2 Cikel upravljanja poslovnih procesov UPP se izvaja skozi karakteristične faze (Weske, 2007; Slika 5). Prva je faza oblikovanja in analize PP. V tej fazi najprej identificiramo poslovne procese in jih podrobno proučimo (tudi z organizacijskega in tehnološkega vidika). Nato procese modeliramo in jih s pomočjo simulacije tudi preverimo. Vse navedeno dosežemo s pomočjo anket in intervjujev z zaposlenimi, za modeliranje pa uporabimo različne metode in tehnike modeliranja procesov (ki jih bomo podrobneje spoznali v 5. poglavju predavanj). Slika 5: Cikel upravljanja poslovnih procesov Vir: prirejeno po Weske (2007, str. 12) Tako preverjeni modeli PP so vhod v naslednjo fazo vzpostavitve PP, v kateri izboljšane PP implementiramo oz. vzpostavimo – jih prenesemo v prakso. V tej fazi torej modele PP obogatimo 22/136 Upravljanje poslovnih procesov (združimo) s tehničnimi in izvedbenimi podatki PP. To lahko storimo z različnimi politikami in predpisanimi postopki (pri čemer ne potrebujemo posebnih informacijskih rešitev za UPP), vendar pa se v zadnjem času PP vzpostavljajo s pomočjo sistemov za UPP (SUPP). Pri tem moramo izbran SUPP prilagoditi poslovnim procesom, ki jih bo nadzoroval, in njihovemu organizacijskemu okolju. Prav tako moramo SUPP povezati z obstoječimi IS, ki se uporabljajo pri izvajanju PP. Tako vzpostavljen integriran sistem moramo tudi preveriti. Naslednja je faza izvajanja, v kateri dejansko v praksi izvajamo posamezne PP. Pri tem SUPP aktivno vodi spremlja ter nadzira izvajanje posameznega PP in zbira podatke o njegovem izvajanju, kot so npr. začetek/konec posamezne aktivnosti, skupen čas izvajanja ipd. Tako zbrani podatki so osnova za naslednjo fazo – fazo vrednotenja PP. Te podatke namreč analiziramo ter tako ugotovimo, kje so pri izvedbi nastale težave (npr. ozka grla). To nam tudi omogoča, da ovrednotimo kakovost modela PP in ustreznost izvajalskega okolja. Na podlagi tega identificiramo možne izboljšave tako modela kot samega izvajanja PP. Pri zbiranju in analizi podatkov o PP pa lahko uporabimo tudi t. i. rudarjenje procesov (ang. process mining). Orodja za rudarjenje podatkov podatke o PP iščejo ne samo znotraj SUPP ampak tudi v drugih IS, ki se uporabljajo pri izvajanju PP. Identificirane možne izboljšave so vhod v novo fazo oblikovanja in analize PP. Tako se faze sklenejo v krog, zato govorimo o ciklu upravljanja PP. 2.2 Funkcijska organiziranost in usmerjenost Slika 6 prikazuje tipično funkcijsko organiziranost, kjer organizacijska struktura sledi delovnim mestom znotraj posameznih poslovnih funkcij. Kot smo že omenili v 1. poglavju, opravila iz posamezne poslovne funkcije posegajo na različne upravljavske ravni; tem pa ustrezno prilagodimo delovna mesta. Slika 6: Tipična funkcijska organiziranost V upravi kot poslovnem sistemu (najširše gledano) si lahko funkcijsko organiziranost predstavljamo tako, kot jo kaže Slika 7: na strateški ravni so aktivnosti vlade, na operativni pa aktivnosti upravnih enot, izpostave uradov in službe na lokalni ravni, ki neposredno nudijo storitve uporabnikom. Od višjih do nižjih ravni v komunikacijskem smislu potekajo podajanje nalog in nadzor, v obratni smeri pa potujejo razna poročila. Na ta način se komunikacijske poti izredno podaljšajo. 23/136 Upravljanje poslovnih procesov Slika 7: Tipična funkcijska organiziranost uprave Več o funkcijski organiziranosti (predvsem prednostih in slabostih) preberite v učbeniku Tatjane Kosi »Poslovni procesi«, poglavje 2. 2.3 Procesna organiziranost in usmerjenost »Procesna organiziranost se ne nanaša na aktivnosti v posamezni organizacijski enoti (sektorji, službe, oddelki), temveč spremlja izdelavo izdelka ali opravljanje storitev vse od začetka do konca izdelave. Predstavlja aktivnosti ne glede na to, kje se izvajajo. Pomembno je, ali so vezane na določen izdelek oziroma storitev«. (Kosi, 2010, str. 15) Hammer in Champy (1993) navajata: Procesna usmerjenost pomeni, da pozornost v poslovnih sistemih preusmerimo od poslovnih funkcij in njihovih hierarhičnih struktur k poslovnim procesom. Zakaj je to tako pomembno? Zavedati se moramo, da so poslovni procesi tisti, katerih rezultati (izdelki ali storitve) omogočajo poslovnim sistemom preživetje oziroma opravičujejo njihov obstoj. Razlogi za procesno usmeritev:  vse večja konkurenca,  večja pričakovanja strank,  pritiski na zniževanje stroškov/časov,  uvajanje sistemov kakovosti ISO 900x, CAF, EFQM, itd. Kot je razvidno na spodnji sliki (Slika 8), proces teče horizontalno, čez več poslovnih funkcij, običajno na operativni ravni (lahko pa tudi na višjih ravneh). V upravi tako na različnih ravneh zasledimo naslednje procese:  strateška raven: sprejemanje odločitev glede javnih politik (vlada);  taktična raven: priprava osnov, študij, analiz, predlogov za sprejemanje javnih politik (ministrstva, uradi); implementacija, izvedba in nadzor nad izvajanjem politik (oddelki, agencije, zavodi, inšpektorati);  operativna raven: nudenje storitev (lokalna uprava in samouprava, javna podjetja, zavodi). 24/136 Upravljanje poslovnih procesov Slika 8: Poslovni proces in poslovne funkcije Več o procesni usmeritvi in primerjavi s funkcijsko preberite v učbeniku Tatjane Kosi, poglavje 2. Leben in Jukić (2017) povzemata 4 stopnje zrelosti procesne usmerjenosti upoštevajoč tri kriterije (Slika 9). Slika 9: Merjenje zrelosti procesne usmerjenosti Več o tem v članku »Metode in tehnike za podporo procesni usmerjenosti organizacij« (Leben & Jukić, 2017)10. 2.4 Prenova poslovnih procesov BPR – iz angl. Business Process Reengineering Kovačič & Bosilj Vukšić (2005, str. 35) Prenovo poslovnih procesov lahko opredelimo kot temeljito preverjanje poslovnih procesov (procesov, postopkov in aktivnosti) in njihovo korenito spremembo, ki jo sprožimo z namenom doseganja pozitivnih rezultatov na področjih, kot so zniževanje stroškov, povečanje kakovosti izdelkov in skrajšanje dobavnih rokov. 10 Članek je obvezno gradivo in je objavljen v e-učilnici. 25/136 Upravljanje poslovnih procesov Pristop k prenovi poslovnih procesov ima za organizacije vsaj dvojen pomen: 1. omogoča, da organizacije podrobno spoznajo svoje procese ter ovrednotijo njihov pomen in vrednost v okviru njihove osnovne dejavnosti, 2. omogoča njihovo bolj ali manj radikalno prenovo in optimizacijo ob čimbolj inovativni uporabi informacijskih tehnologij. BPR se najbolj razlikuje od že prej razvitih metod in pristopov postopnega izboljševanja poslovnih procesov po svoji radikalnosti pri iskanju novih možnosti izvajanja procesov ter po pričakovanih rezultatih. Davenport (1993) trdi, da je BPR edini način za doseganje 'kvantnih' skokov v pogledu učinkovitosti poslovnih procesov in podrobno opredeljuje razliko v pristopu med BPR in že prej znanimi metodami postopnega izboljševanja procesov. Temeljna izhodišča prenove poslovnih procesov:  pristop po načelu »začeti od začetka« (nepopisan list); skušamo pozabiti, kako smo delali do sedaj; glede na opredeljene cilje procesa si zamislimo, kako bi proces tekel, da bi tem ciljem čim bolj zadostili;  procesna usmerjenost;  preseganje obstoječih organizacijskih struktur;  težnja po radikalni spremembi v pogledu učinkovitosti poslovanja; radikalno pomeni ne spremembo za 5 %, temveč za 20 ali več %;  obravnava IT kot vzvoda in sredstva za spremembe: IT ni le sredstvo za dosego cilja; zavedati se moramo, da je vpeljava IT v poslovanje tudi vzvod za spremembe, seveda, če poznamo možnosti sodobne IT in njene uporabe;  sprememba organizacije in organizacijske kulture kot nujnega spremljevalca sprememb. Temeljni cilj prenove poslovnih procesov je torej:  korenito izboljšati ključne karakteristike procesov: skrajševanje časov, zniževanje stroškov, dvig kakovosti, in  ob tem izkoristiti možnosti sodobne IT, tako da  informatiziramo procese, torej z IT podpremo izvajanje poslovnih procesov. Pri tem velja omeniti, da ne moremo hkrati skrajšati časa, znižati stroškov in dvigniti kakovosti. Lahko skrajšamo čas in znižamo stroške ob enaki kakovosti ali skrajšamo čas in dvignemo kakovost ob enakih stroških ali pa znižamo stroške in dvignemo kakovost ob enakem času. To prikazuje Slika 10. Slika 10: Tri ključne karakteristike procesov 26/136 Upravljanje poslovnih procesov Po Hammerju in Champyju (1993) obstaja cela vrsta splošnih značilnosti poslovnih procesov, na katere mora biti osredotočena prenova. Pri spreminjanju vseh značilnosti pa imata ravno sodobna IT in njena inovativna uporaba zelo pomembno, če ne najpomembnejšo vlogo. Nekatere od teh značilnosti so:  Več delovnih mest se združi v eno.  Uslužbenci se odločajo (povečana moč zaposlenih). Odločanje postane sestavni del njihovega dela.  Koraki v poslovnem procesu se izvajajo v logičnem zaporedju, več del se opravi hkrati.  Procesi imajo lahko več različic. To omogoča prilagodljivost glede na obseg.  Delo se izvaja tam, kjer je najbolj smiselno; po potrebi se prenaša preko meja organizacije.  Nadzor in druga dela, ki ne ustvarjajo nove vrednosti, so minimalizirana. Več o prenovi poslovnih procesov preberite v učbeniku Tatjane Kosi »Poslovni procesi«, poglavje 4. Viri in literatura ABPMP – Association of Business Process Management Proffesionals. (2006). ABPMP Standards for Business Process Management (BPM). Pridobljeno 3. 10. 209, s https://www.abpmp.org/page/BPM_Profession Davenport, T. H. (1993). Process Innovation: Reengineering Work through Information Technology. Boston: Harvard Business School Press. Hammer, M. & Champy, J. (1993). Reengineering the Corporation: A Manifesto for Business Revolution. London: Nicholas Brealey Publishing Ltd. Kosi, T. (2010). Poslovni procesi [elektronski vir]. Ljubljana: Zavod IRC. Dostopno na: http://www.impletum.zavod-irc.si/docs/Skriti_dokumenti/Poslovni_procesi-Kosi.pdf Kovačič, A. & Bosilj Vukšič, V. (2005). Management poslovnih procesov. Ljubljana: GV Založba. Leben, A. & Jukić, T. (2017). Metode in tehnike za podporo procesni usmerjenosti organizacij. J avna uprava kot gonilo družbe, e-zbornik člankov, DSU 2017, Ljubljana, 21.–22. september. Pridobljeno 29. 9. 2018, s http://www.fu.uni-lj.si/fileadmin/usr-files/Zalozba/DSU2017_E- zbornik_clankov.pdf Stopar, D. (2009). Upravljanje poslovnih procesov (diplomsko delo). Ljubljana: Fakulteta za računalništvo in informatiko. Weske, M. (2007). Business Process Management: Concepts, Languages, Architectures [elektronski vir]. Berlin Heidelberg: Springer-Verlag. Dostopno na https://epdf.pub/business-process- management-concepts-languages-architectures.html 27/136 Upravljanje poslovnih procesov Kaj moram vedeti?  Upravljanje poslovnih procesov  Cikel upravljanja poslovnih procesov  Faze upravljanja poslovnih procesov: kaj, s čim  Funkcijska usmerjenost/organiziranost  Procesna usmerjenost/organiziranost  Primerjava procesna : funkcijska organiziranost  Stopnje zrelosti procesne usmerjenosti  Prenova poslovnih procesov: temeljna izhodišča in glavni cilji  Prenova poslovnih procesov: glavne značilnosti in koraki 28/136 3. poglavje: Načrtovanje in gradnja informacijskih sistemov V tem poglavju bomo predstavili proces, ki nas od ideje za neko novo informacijsko rešitev pripelje do delujočega informacijskega sistema. Proces nastajanja in delovanja informacijskega sistema običajno poimenujemo življenjski cikel razvoja IS in je v splošnem podoben življenjskemu ciklu kateregakoli izdelka. Pa vendar obstaja nekaj pomembnih razlik oz. posebnosti, ki izhajajo iz same narave informacijskega sistema in vloge, ki jih imajo IS v sodobnih poslovnih sistemih (organizacijah). Tako bomo najprej opredelili, kakšna ta vloga je in nato spregovorili nekaj o vzrokih za neuspešen razvoj IS ter izpostavili ključne probleme razvoja IS. Osrednji del pa bo namenjen podrobnejši predstavitvi življenjskega cikla razvoja IS in njegovih karakterističnih faz. Sodelovanje bodočih uporabnikov pri razvoju IS je izrednega pomena, saj so oni tisti, ki ga bodo uporabljali in tudi najbolje vedo, kaj za svoje delo potrebujejo in kakšen naj bo IS, da bo njihovo delo tudi najbolje podprl. Namen tega poglavja torej je, da se spoznate s procesom razvoja IS, zato da boste vedeli, na kakšen način lahko kot bodoči uporabniki pri tem tvorno sodelujete in s tem prispevate k višji kakovosti informacijskega sistema. Vsebina poglavja 3.1 Vloga IS in ključni problemi razvoja IS ............................................................................................ 30 3.1.1 Vloga IS v sodobnih organizacijah ...................................................................................... 30 3.1.2 Ključni problemi razvoja IS ................................................................................................. 30 3.2 Metodologija razvoja IS .................................................................................................................. 32 3.3 Življenjski cikel razvoja IS ................................................................................................................ 32 3.4 4-stopenjski model razvoja IS ......................................................................................................... 34 3.4.1 Analiza stanja ..................................................................................................................... 34 3.4.2 Logična zasnova IS ............................................................................................................. 35 3.4.3 Fizična zasnova IS ............................................................................................................... 35 3.4.4 Gradnja IS ........................................................................................................................... 36 Viri in literatura ...................................................................................................................................... 36 29/136 Načrtovanje in gradnja informacijskih sistemov 3.1 Vloga IS in ključni problemi razvoja IS 3.1.1 Vloga IS v sodobnih organizacijah Prav gotovo lahko trdimo, da si v sodobnem svetu zelo težko predstavljamo poslovanje, ki ne bi bilo na tak ali drugačen način podprto z IS, kar pomeni, da smo (pa če se tega zavedamo ali ne) pri svojem delu postali odvisni od IS. Jasno je, da je hitrost razvoja in sprememb v poslovanju sodobnih organizacij neposredno povezana in odvisna od razširjene uporabe IS, temelječih na IT. To pa posledično pomeni, da imajo pri razvoju sodobnih organizacij IS strateško vlogo. Niso več nekaj obrobnega: ko razmišljamo, kako doseči zastavljene strateške cilje neke organizacije, to prav gotovo vključuje tudi razmišljanje o tem, kakšne IS za to potrebujemo. V podjetjih ugotavljajo, da imajo danes IS izjemen vpliv na konkurenčno sposobnost organizacije. Vodilni v podjetjih pogosto postavijo informacijsko tehnologijo, informatiko, informacijske sisteme, če ne na prvo mesto, pa v sam vrh najpomembnejših inštrumentov, mehanizmov, s katerimi skušajo podjetja povečati svojo konkurenčnost. Uprava je v tem pogledu nekoliko drugačna. Sam pojem konkurenčnosti je v upravi še nekoliko tuj. V upravi tako (še) ne govorimo o razvoju IS skozi vidik povečevanja konkurenčnosti oz. konkurenčne sposobnosti. V upravi izpostavljamo druge vidike in druge učinke IS in IT. Največkrat ugotavljamo, da nam sodobni IS v upravi omogočajo izboljšati učinkovitost in kakovost delovanja in da poskušajo spremeniti odnos do uporabnikov (občanov, podjetij itd.). Skratka, v upravi je ta pogled na vlogo IS nekoliko drugačen. Ni pa zato vloga IS nič manj pomembna. Nasprotno. Zaradi specifične narave osnovne dejavnosti vsake uprave in njene izrazite vezanosti na informacije je pomen in vloga IS v upravi lahko še večja kot v nekaterih, predvsem manjših, podjetjih. Zaradi vse pomembnejše vloge IS v razvoju organizacij je potrebno k njihovemu načrtovanju pristopati vedno bolj sistematično, strateško, premišljeno, saj mora biti razvoj IS čvrsto vpet v razvojne cilje in prizadevanja organizacije kot celote, ne glede na to, kakšna je njena osnovna dejavnost, in ne glede na to, ali gre za ministrstvo, javni zavod, javno podjetje ali pa privatno podjetje. Potrebujemo torej strateški načrt razvoja informatike v organizaciji. IS se v sodobnem poslovanju namreč redko razvijajo 'po navdihu', saj so z razvojem povezani visoki stroški. Tako najprej, upoštevajoč cilje in prioritete, na podlagi strateškega načrta naredimo izbor projektov, ki jih strateški načrt opredeljuje. Šele nato pa se lotimo razvoja konkretnega IS (torej izvedbe konkretnega projekta razvoja IS). 3.1.2 Ključni problemi razvoja IS Standish Group že od leta 1994 izvaja raziskavo o uspešnosti IT projektov v ZDA, pri čemer projekte (glede na uspešnost) deli v 3 skupine (Standish Group, 1994):  uspešni so tisti, ki se zaključijo v predvidenem časovnem in finančnem okviru, razvita IT rešitev (informacijski sistem) pa ima zahtevane funkcionalnosti in lastnosti;  nepopolni so projekti, ki se sicer zaključijo, a prepozno, s prekoračenimi stroški in/ali razvita rešitev ne dosega zahtevanih funkcionalnosti in lastnosti;  neuspešni pa so tisti, ki jih prekinemo in torej končne IT rešitve sploh ni. Tabela 2 prikazuje uspešnost IT projektov v ZDA v letih 1994 in 2012. Tabela 2: (Ne)uspešnost IT projektov 1994 2012 30/136 Načrtovanje in gradnja informacijskih sistemov uspešni 16 % 39 % nepopolni 53 % 43 % neuspešni 31 % 18 % Vir: Standish Group (1994, 2013) Rezultati iz leta 2012 kažejo, da je odstotek uspešnih projektov bistveno višji kot v letu 1994; še vedno pa je več kot 40 % projektov nepopolnih. Avtorji navajajo različne vzroke za neuspešnost IT projektov oz. za neuspešen razvoj IS, mi bomo izpostavili štiri (ki se najpogosteje navajajo):  napačno razumevanje sistemskih in/ali uporabniških potreb in zahtev,  prenova procesov ni bila izvedena,  slabo sodelovanje z uporabniki,  slabo vodenje projektov. Iz navedenega lahko izluščimo ključne probleme razvoja IS:  »streljamo na tarčo v gibanju«  nedorečenost metodologij in orodij  (ne)sodelovanje vodstva in uporabnikov  predolgi razvojni cikli  nepredvidljiva kakovost razvitih informacijskih rešitev  visoki razvojni in/ali vzdrževalni stroški Prvi problem je povezan s tem, da IS razvijamo za določeno poslovno okolje, ki pa je dinamično in se nenehno spreminja. Zato se tudi uporabniške potrebe in zahteve, ki naj bi jih bodoči IS zadovoljeval, nenehno spreminjajo. Ker pa IS ne moremo razviti v nekaj dneh, ampak za to potrebujemo čas, se kaj lahko zgodi, da razviti IS ne bo več ustrezal uporabniškim zahtevam takrat, ko ga začnemo uporabljati. Drugi problem se nanaša na metodologije in orodja za razvoj IS. Tu je bilo v zadnjih letih storjenega veliko, še vedno pa velja, da potrebujemo metodologije in orodja, ki bodo omogočala čim hitrejši razvoj IS, seveda ne na račun kakovosti končne rešitve. Če želimo razviti IS, ki bo ustrezal dejanskim zahtevam in potrebam uporabnikov, moramo zagotoviti njihovo tesno sodelovanje že pri razvoju IS. Prav tako je potrebna popolna podpora vodstva – če se ti ne čutijo 'povezani' s projektom, obstaja zelo velika nevarnost, da bo razvoj neuspešen. Poleg tega je informatika v sodobnih organizacijah tako prepletena z različnimi vidiki njihovega delovanja, da mora za to področje skrbeti nekdo v najvišjem vodstvu (ne sme biti prepuščeno zanesenjaštvu IT strokovnjakov ali nižjim upravljavskim ravnem). Razvojni cikli pri IS so še vedno relativno dolgi – trajajo od nekaj mesecev za majhne IT projekte (ki pokrivajo ozek del poslovanja), do nekaj let za projekte, ki ob prenovi poslovnih procesov pokrivajo aktivnosti več poslovnih funkcij. Vse do sedaj navedeno nas pripelje do naslednjega problema: nepredvidljiva kakovost razvitih rešitev. To pomeni, da rešitev, ko je razvita, ne ustreza dejanskim potrebam, torej ne zagotavlja pravih informacij na pravi način ob pravem času in na pravem mestu. Zaradi same narave procesa razvoja IS se temu v popolnosti težko izognemo, poskrbeti pa moramo, da je razkorak med potrebnim in dejanskim čim manjši. Pri IS se srečujemo z dvema vrstama stroškov: razvojni, ki so potrebi za sam razvoj IS (lahko rečemo tudi investicijski), in vzdrževalni, ki nastanejo po uvedbi rešitve, ki jo je treba stalno vzdrževati. Velikokrat se 31/136 Načrtovanje in gradnja informacijskih sistemov zgodi, da se na račun nižjih razvojnih stroškov bistveno povečajo vzdrževalni, ker smo želeli IS razviti 'na hitro' z majhnimi stroški, kar pa povzroči večje zahteve po vzdrževanju in dopolnjevanju rešitve. 3.2 Metodologija razvoja IS V prejšnjem razdelku smo ugotovili, da je nedorečenost metodologij in orodij eden od ključnih problemov razvoja IS. Pa si poglejmo, kaj metodologija razvoja IS je in katere so glavne sestavine celovite metodologije razvoja IS. Slovar slovenskega knjižnega jezika11 predeljuje:  metoda : oblika načrtnega, premišljenega dejanja, ravnanja ali mišljenja za dosego kakega cilja; način, postopek;  metodologija : skupek metod, ki se uporabljajo pri kakem raziskovanju, mišljenju. To je splošna opredelitev pojma metodologija, ki jo lahko uporabljamo na poljubnem področju. Pri razvoju IS pa velja (Kovačič & Vintar, 1994, str. 29): Metodologija razvoja informacijskih sistemov zajema tisto organizacijsko- tehnološko znanje, ki ga uporabljamo pri zasnovi in izdelavi informacijskih rešitev. Tako si vsaj v praksi največkrat predstavljamo metodologijo razvoja IS. Poleg pojma metodologija pa se pogosto srečujemo še s pojmi metoda, postopek, tehnika, ki pa so 'ožji' pojmi. Če metodologija predstavlja skupek znanj, ki jih potrebujemo pri razvoju IS od začetne ideje do uvedbe v praksi, pa pod metodami, postopki, tehnikami, razumemo sredstva, ki se jih poslužujemo za izdelavo posameznih aktivnosti znotraj procesa ali posameznih faz, ne pa celotnega razvojnega procesa. V praksi je pri načrtovanju in gradnji IS najpomembneje, da nas izbrana metodologija čimbolj povezano in natančno vodi od začetka skozi vmesne faze do cilja – uporabne IT rešitve. V ta namen lahko opredelimo glavne elemente celovite metodologije razvoja IS (Kovačič & Vintar, 1994, str. 30):  opredelitev ključnih razvojnih faz ter njihovega sosledja,  vsebinski opis vsake faze z opredelitvijo ključnih aktivnosti,  navodila za izvedbo aktivnosti,  prikaz metod in tehnik za izvedbo posameznih aktivnosti,  opredelitev zahtevanih rezultatov posamezne faze,  opredelitev kriterijev za kritično ovrednotenje rezultatov posameznih faz,  navodila glede organizacijskih, kadrovskih ter tehničnih pogojev, ki so pomembni pri uporabi metodologije,  opredelitev področja uporabnosti. 3.3 Življenjski cikel razvoja IS Kot smo omenili v uvodu, življenjski cikel razvoja IS predstavlja proces nastajanja in delovanja informacijskega sistema. Cikel ima v grobem naslednje korake: definicija problema  analiza in 11 SSKJ. Dostopno na http://bos.zrc-sazu.si/sskj.html 32/136 Načrtovanje in gradnja informacijskih sistemov opredelitev zahtev  načrtovanje  gradnja  uvedba  vzdrževanje. Skozi vse te korake poteka preverjanje rešitev. Ko pri vzdrževanju zaznamo nove probleme, se celoten cikel ponovi. Življenjski cikel zajema torej vse faze od analize do uporabe in spreminjanja IS in je odvisen od metodologije razvoja IS (Kovačič & Vintar, 1994). Slika 11: Življenjski cikel razvoja IS Slika 11 podrobneje prikazuje sam življenjski cikel razvoja IS. Ta se začne z definicijo problema: ko problem zaznamo, ga moramo tudi podrobno opredeliti, da nam je jasno, kje je težava. Sledi analiza stanja, katere rezultat je študija upravičenosti. V okviru analize skušamo preveriti, ali je projekt, ki je pred nami, uresničljiv v okviru danih robnih pogojev (rokov, finančnih sredstev, virov), ki jih imamo na voljo; in na drugi strani, ali je smiseln, se pravi ali bodo pričakovani rezultati odtehtali vlaganja. Na to je osredotočena študija upravičenosti. Če študija upravičenosti poda negativno oceno, je to pravi trenutek, da projekt razvoja brez večje škode in stroškov ustavimo. Lahko ga ustavimo v celoti ali pa ga na novo opredelimo. Če je izid študije upravičenosti pozitiven, sledi odločitev o tem, na kakšen način priti do novega IS. Danes je na trgu že polno izdelanih rešitev, še posebno za nekatera najbolj tipična poslovna področja, npr. kadrovsko, računovodsko, finančno … Zato se vprašamo, kaj je za nas bolje, racionalneje in ceneje. V osnovi sta vedno na voljo dve možnosti:  nakup in ustrezna prilagoditev kupljene rešitve našim potrebam;  lasten razvoj. Pri tem je potrebno je preučiti, ali nam kakšna od obstoječih rešitev na trgu ustreza in kako blizu je našim potrebam. Za področja, ki predstavljajo našo osnovno dejavnost, se pravi dejavnost, ki se od podjetja do podjetja navadno razlikuje, je običajno na trgu manj ali sploh ni izdelanih rešitev, ali pa so tako drugačne, da prilagajanje nima smisla. V tem primeru se odločimo za lasten razvoj, ki bo trajal dlje časa in bo dražji. Nakup se lahko na začetku pokaže za zelo ugoden, vendar ko želimo rešitev vgraditi v naše konkretno poslovno okolje, se velikokrat pokaže, da smo se zmotili. Če smo se odločili za lasten razvoj, sledijo naslednje razvojne faze: logična zasnova, fizična zasnova in gradnja IS. Ne glede na to, ali smo se odločili za nakup ali za lasten razvoj, pa moramo nov IS uvesti, ga preveriti in vzdrževati. Vedno je torej na koncu preverjanje, da ugotovimo, ali je rešitev prinesla pretežni del pričakovanih rezultatov, in vzdrževanje, kot aktivnost, ki se ji ni mogoče izogniti. Sami poslovni 33/136 Načrtovanje in gradnja informacijskih sistemov sistemi se zelo hitro razvijajo in spreminjajo, po drugi strani pa se še hitreje spreminja tehnologija. Oba razloga narekujeta, da naše informacijske rešitve nenehno dopolnjujemo, dograjujemo in spreminjamo. 3.4 4-stopenjski model razvoja IS V naši obravnavi ne bomo podrobno obravnavali vseh razvojnih faz. Osredotočili se bomo na tiste, ki so z vidika opredelitve bodočega sistema najpomembnejše, in na tiste, kjer je sodelovanje uporabnikov ključnega pomena. Tako pridemo do 4-stopenjskega modela razvoja IS (Slika 12), ki vsebuje naslednje faze: 1. analiza stanja, katere rezultat je študija upravičenosti 2. logična zasnova IS, katere rezultat je logični model, 3. fizična zasnova IS, katere rezultat je fizični model, ter 4. gradnja IS, katere rezultat je izgrajen in testiran sistem, pripravljen za uvedbo. Slika 12: 4-stopenjski model razvoja IS Pa si podrobneje poglejmo posamezne faze (Kovačič & Vintar, 1994). 3.4.1 Analiza stanja Izhodišča za analizo stanja so:  strateški cilji organizacije,  strateški načrt informatizacije,  funkcija obravnavanega sistema. Analiza obstoječega stanja zajema naslednje aktivnosti:  identifikacijo procesov in postopkov,  analizo informacijskih tokov,  grobo opredelitev uporabniških zahtev,  analizo obstoječih informacijskih rešitev in opreme. 34/136 Načrtovanje in gradnja informacijskih sistemov Študija upravičenosti, ki je rezultat te faze, vsebuje:  cilje bodočega IS,  opredeljene uporabniške zahteve,  oceno upravičenosti, ki upošteva razmerje stroški/učinki (ali pričakovani rezultati odtehtajo stroške), robne pogoje (časovni roki, finančna sredstva in ostali viri) ter omejitve/tveganja (predvsem pomembno, da se zavedamo tveganj za uspešen razvoj in kako jih je možno zmanjšati). 3.4.2 Logična zasnova IS Izhodišča za logično zasnovo so:  jasno opredeljeni strateški cilji,  opredeljene informacijske potrebe,  opredeljena poslovna pravila,  izbran metodološki pristop. Bistvene značilnosti te faze so:  v ospredju je funkcija in vsebina bodočega IS,  osnovno izhodišče so predvsem informacijske potrebe bodočih uporabnikov,  je tehnološko in izvedbeno čimbolj neodvisna. Gre za vsebinsko, funkcionalno zasnovo IS, s samo tehnično izvedbo se še ne ukvarjamo. Rezultat je logični model; kako ga predstavimo (kaj vsebuje) je odvisno od pristopa12, ki smo ga izbrali za razvoj:  tradicionalni pristop: po tem pristopu nastaneta postopkovni in pa podatkovni model;  objektni pristop: rezultat tega pristopa je objektni model, ki združuje postopkovni in podatkovni model v eno povezano celoto. 3.4.3 Fizična zasnova IS Izhodišča za to fazo so:  združitev vsebine in tehnologije,  upoštevati vse izvedbene in tehnološke predpostavke. V tej fazi moramo torej logično zasnovo IS oz. logični model prilagoditi izvedbenim in tehnološkim omejitvam, ki nam jih postavlja izbrana tehnologija. V sami fazi torej najprej izberemo tehnologijo in orodja, nato pa na podlagi logičnega modela izdelamo fizični model, ki vsebuje:  zasnovo baze podatkov,  specifikacijo programskih modulov, ki bodo sestavljali določeno rešitev,  zasnovo vhodov in izhodov, se pravi vseh vhodnih poti, preko katerih bomo podatke vnašali v IS, in vseh izhodnih poti, preko katerih bo IS posredoval podatke uporabniku (vhodne maske, izhodne maske, poročila, izpisi …). 12 Več o različnih pristopih najdete v 11. poglavju predavanj: Metodološki pristopi k razvoju IS. 35/136 Načrtovanje in gradnja informacijskih sistemov 3.4.4 Gradnja IS Aktivnosti, ki jih v tej fazi izvajamo, so:  programiranje;  testiranje (preverjanje) programov: formalno testiranje (ali so programi napisani v skladu s pravili programskega jezika; za to v sodobnem času poskrbijo ustrezna programska okolja) in logično testiranje (ali programi pravilno delujejo);  testiranje (preverjanje) celotnega informacijskega sistema. Rezultat te faze je izdelan in preverjen informacijski sistem. Viri in literatura Kovačič, A. & Vintar, M. (1994). Načrtovanje in gradnja informacijskih sistemov. Ljubljana: DZS. Standish Group. (1994). The CHAOS Report. Pridobljeno 10. 4. 2015, s http://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Standish Group. (2013). Chaos Manifesto 2013: Think Big, Act Small. Pridobljeno 19. 10. 2015, s http://www.scribd.com/doc/198550543/Chaos-Manifesto-2013#scribd Kaj moram vedeti?  Ključni problemi razvoja IS  Celovita metodologija za razvoj IS  Življenjski cikel razvoja IS  4-stopenjski model razvoja IS  Podrobno posamezne faze 4-stopenjskega modela in njihovi rezultati  Primerjava logična : fizična zasnova  Zakaj ločimo fizično in logično zasnovo 36/136 4. poglavje: Analiza in modeliranje informacijskih sistemov V prejšnjem poglavju smo se seznanili z življenjskim ciklom razvoja IS in ugotovili, da sta z vidika bodočih uporabnikov pri razvoju IS najpomembnejši fazi analize stanja in logične zasnove IS. Uporabniki lahko namreč z aktivnim sodelovanjem v teh fazah pomembno vplivajo na to, kakšen bo bodoči IS, predvsem ali bo ustrezal njihovim zahtevam in željam. V obeh fazah se srečamo z različnimi vidiki poslovnega sistema, ki jih moramo upoštevati pri razvoju IS. Obe fazi tudi zajemata modeliranje teh vidikov. V tem poglavju bomo tako najprej opredelili, kaj je model IS, se v grobem seznanili s koncepti modeliranja IS ter podrobneje spoznali poglede na poslovni sistem, ki jih moramo pri analizi in modeliranju IS upoštevati. Posebej pa se bomo osredotočili na analizo informacijskih potreb kot bistvene sestavine analize stanja. Vsebina poglavja 4.1 Modeliranje informacijskih sistemov ............................................................................................. 38 4.1.1 Model in modeliranje ......................................................................................................... 38 4.1.2 Pogledi na poslovni sistem ................................................................................................. 39 4.1.3 Procesni in podatkovni pogled ........................................................................................... 40 4.1.4 Koncepti modeliranja IS ..................................................................................................... 41 4.2 Analiza informacijskih potreb ......................................................................................................... 42 4.2.1 Seznam informacijskih potreb ........................................................................................... 43 4.2.2 Seznam podatkovnih elementov ....................................................................................... 44 37/136 Analiza in modeliranje informacijskih sistemov 4.1 Modeliranje informacijskih sistemov 4.1.1 Model in modeliranje Kaj je model? Slovar slovenskega knjižnega jezika13 opredeljuje model kot »predmet, izdelan za ponazoritev, prikaz načrtovanega ali obstoječega predmeta«, iSlovar14 pa kot »poenostavljen in formaliziran opis sistema, pojava«. Prav gotovo je našemu pojmovanju bliže druga opredelitev, saj pri modeliranju IS težko govorimo, da je model predmet – gre za opis IS, pri čemer je ta opis lahko v različnih oblikah. Najbolj splošno pa lahko opredelimo: Model je poenostavitev stvarnosti. Model sistema je torej pomenski približek (abstrakcija) stvarnega sistema. Modeliranje je izdelovanje, oblikovanje modela oz. preslikovanje stvarnosti v model. Zakaj modeliramo? Odgovor je preprost. Da lažje razumemo stvarnost. To pomeni, da pri modeliranju izločimo tiste lastnosti stvarnosti, ki nas trenutno ne zanimajo oz. nam ne koristijo, in se osredotočimo na tiste, ki so za nas v določenem trenutku pomembne. Predvsem je to pomembno pri zapletenih sistemih (kar IS kaj hitro postanejo): zapletene sisteme modeliramo, ker jih ne moremo naenkrat zaobjeti (razumeti) v njihovi celoti in z vseh vidikov. Ko smo v prvem poglavju govorili o razmerju med poslovnim in informacijskim sistemom, smo ugotovili, da IS pokriva informacijske potrebe poslovnega sistema, saj zbira, obdeluje, shranjuje in distribuira podatke in informacije, potrebne za delovanje poslovnega sistema. V IS je torej zajeto znanje (seveda ne celotno) o poslovnem sistemu. Povedano drugače: IS je neke vrste model poslovnega sistema (ali določenega področja njegovega delovanja). To tudi pomeni, da model IS predstavlja znanje o poslovnem sistemu, in je model IS torej tudi model poslovnega sistema. Modeliranje je dvofazni proces (Slika 13). Model stvarnosti ne nastane kot neposredna preslikava stvarnosti, ampak nastane kot preslikava predstave o stvarnosti. Človek si najprej v glavi ustvari neko predstavo o tem, kar vidi, sliši, občuti … Saj poznate rek: »vsake oči imajo svojega 'malarja'«. Ta predstava o stvarnosti pa je tisto, kar nato skušamo izraziti na modelu oz. z modelom. Pri ustvarjanju predstav v glavah opazovalcev torej vedno pride do nekega popačenja, temu se enostavno ne moremo izogniti; dejansko torej modeliramo 'popačeno' stvarnost. Slika 13: Modeliranje – preslikava stvarnosti v model 13 SSKJ. Dostopno na http://bos.zrc-sazu.si/sskj.html 14 Islovar, terminološki slovar informatike. Dostopno na http: //www.islovar.org 38/136 Analiza in modeliranje informacijskih sistemov Pri modeliranju IS želimo to popačenje čim bolj zmanjšati, kajti večje ko je, tem slabše bo model IS odražal pomembne značilnosti. To pa pomembno vpliva tudi na kakovost IS, ki ga bomo razvili ob upoštevanju takega modela. Na samo preslikavo predstave o stvarnosti v model vpliva dvoje:  pogled na svet, ki ga ima opazovalec,  instrumentarij (orodja, metode, tehnike), ki ga pri modeliranju uporabljamo. Različni pogledi na svet vodijo v različno reševanje istih problemov. Isti problem vidimo različni ljudje različno in zanj iščemo tudi različne rešitve. Ta subjektivnost je vedno prisotna in na to nimamo velikega vpliva. Drugače pa je pri instrumentariju, ki ga pri modeliranju uporabljamo. Na ta dejavnik pa seveda lahko vplivamo. Osrednji del predmeta Razvoj informacijskih sistemov za podporo poslovnim procesom obravnava prav metode in tehnike, ki jih uporabljamo pri modeliranju IS. Dejavniki, ki vplivajo na model IS, so:  pogled na poslovni sistem: kateri vidik sistema nas zanima, to daje modelu vsebinski pomen;  raven abstrakcije oz. poenostavitve: kako natančno želimo z modelom predstaviti stvarnost; ter  način predstavitve: kakšno metodo in tehniko bomo uporabili; pri modeliranju IS gre običajno za opisno in/ali grafično predstavitev. Iz vsega navedenega je jasno: za isti sistem lahko dobimo različne modele. 4.1.2 Pogledi na poslovni sistem PS je prav gotovo zapleten sistem, zato ga seveda težko analiziramo in modeliramo naenkrat z vseh pomembnih zornih kotov. Zato ga moramo za uspešen razvoj IS (ki bo pokrival delovanje PS ali njegov del) obravnavati z različnih vidikov, da lahko zajamemo čim več njegovih pomembnih lastnosti. Govorimo o pogledih na poslovni sistem, ki jih upoštevamo pri razvoju IS.  Organizacijski pogled pove, kakšna je formalna organiziranost PS in torej prikazuje njegovo organizacijsko strukturo: iz katerih organizacijskih enot (oddelki, sektorji, službe …) in delovnih mest je PS sestavljen in kako. Z vidika razvoja IS ta pogled ni tako pomemben, predvsem upoštevajoč procesno umerjenost, ki je osnova za razvoj IS v sodobnih PS. Ni pa povsem nepomemben, saj zajema izvajalce in odgovorne za izvajanje neke naloge, postopka, procesa, kar pa je z vidika informatizacije pomembno.  Normativni pogled daje sliko o poslovnih pravilih, ki veljajo na obravnavanem področju, in so lahko določena z zakoni, podzakonskimi akti, internimi organizacijskimi predpisi ipd. V upravi je ta normativni pogled zelo močno izražen. Pomislimo samo na Zakon o splošnem upravnem postopku, ki predpisuje način izvajanja upravnih postopkov. Normativni pogled pa je treba upoštevati tudi v gospodarstvu (kjer morajo pri svojem poslovanju upoštevati normativne predpise) in seveda tudi svoje notranje organizacijske predpise (npr. pravilnike).  Funkcijski pogled daje vpogled v delitev in strukturo procesov in postopkov. S tem v grobem opredelimo funkcionalnosti – kaj delamo.  Procesni pogled je seveda z vidika procesne usmerjenosti najpomembnejši, saj prikazuje samo izvajanje procesov, kako procesi dejansko tečejo; daje torej vpogled v potek dela – kako delamo.  Podatkovni pogled daje vpogled v podatke in podatkovne strukture. Zanima nas torej, katere podatke pri delu potrebujemo in kateri nastanejo. Poleg tega pa tudi, kakšna so razmerja, povezave med podatki (torej podatkovne strukture).  Kombinirani pogled je integracija dveh ali več zgoraj naštetih osnovnih pogledov. Gre za to, da dobimo neko generalno, širšo sliko obravnavanega procesa, ki prikazuje, kako so posamezni 39/136 Analiza in modeliranje informacijskih sistemov pogledi na obravnavani proces medsebojno povezani. Velikokrat gre za integracijo procesnega in organizacijskega pogleda, še širša pa je integracija procesnega, organizacijskega in podatkovnega pogleda. Tabela 3: Modeli različnih pogledov na poslovni sistem Pogled Organiza- Funkcijski Procesni Podatkovni Kombinirani cijski Strukturni organigram funkcijski graf grafi (org. shema) Diagrami osnovni razširjen poteka razširjen EPC EPC diagrami osnovni diagram ike hn Diagram toka te deloma deloma podatkov n Odločitvena ode i √ tabela Met E-R model √ BPMN osnovni razširjen  diagram razširjen diagram razredov UML tehnike diagram aktivnosti  diagram aktivnosti objektov Tabela 3 prikazuje metode in tehnike, ki jih uporabljamo za prikaz različnih pogledov. Za normativni pogled nimamo posebne metode/tehnike; običajno le navedemo, kateri normativni akti vplivajo na in določajo delovanje obravnavanega področja. Je pa res, da podatki in informacije, ki jih dobimo s proučitvijo teh predpisov, vplivajo na procesni in podatkovni pogled in jih moramo upoštevati pri modeliranju le-teh. Podrobneje bomo posamezne metode in tehnike spoznali v nadaljevanju predmeta. 4.1.3 Procesni in podatkovni pogled Z vidika informatizacije poslovnih procesov – torej razvoja IS, ki podpirajo izvajanje poslovnih procesov – sta posebno pomembna procesni in podatkovni pogled. Procesni obravnava potek izvajanja in je pomemben za razvoj programov. Daje vpogled v:  poslovne procese, ki se izvajajo na obravnavanem poslovnem področju;  postopke, ki se izvajajo znotraj teh poslovnih procesov;  pravila in pogoje izvajanja teh postopkov. Podatkovni obravnava podatke in podatkovne strukture in je pomemben za razvoj podatkovne baze. Zanima nas struktura in lastnosti podatkov. Daje vpogled v:  informacijske potrebe obravnavanega poslovnega področja;  entitete, atribute in povezave, s katerimi te informacijske potrebe modeliramo. 40/136 Analiza in modeliranje informacijskih sistemov Na tem mestu si poglejmo še, kako ta dva pogleda obravnavamo skozi karakteristične faze razvoja IS. Tabela 4 prikazuje, kaj v zvezi s posameznim pogledom delamo v posamezni razvojni fazi (v oklepajih so navedene metode in tehnike, ki jih pri tem lahko uporabimo). Tabela 4: Obravnava procesnega in podatkovnega pogleda skozi 4-stopenjski model razvoja IS karakteristična faza procesni pogled podatkovni pogled analiza stanja identifikacija procesov in  analiza informacijskih potreb postopkov (funkcijska  analiza informacijskih tokov dekompozicija in funkcijski graf) (diagram toka podatkov) logična zasnova postopkovni model (npr. logični podatkovni model (npr. diagram poteka, diagram E-R model) aktivnosti, EPC diagram), BPMN diagram fizična zasnova specifikacija programskih  zasnova baze podatkov modulov (algoritmi)  zasnova vhodov in izhodov gradnja programiranje baza podatkov 4.1.4 Koncepti modeliranja IS Pri modeliranju se velikokrat srečamo tudi z izrazom koncepti modeliranja. Koncept v splošnem je nekaj, »kar posreduje način delanja, dogajanja na kakem področju, zamisel«. Pri modeliranju IS pa bomo razumeli: Koncepti modeliranja so elementi modela, ki predstavljajo sestavine, pojme ali lastnosti stvarnosti, ki jo modeliramo. Slika 14: Seznam konceptov modeliranja IS Kot smo ugotovili že prej, se za predstavitev (modeliranje) različnih pogledov na poslovi sistem uporabljajo različne metode in tehnike, ki seveda uporabljajo različne koncepte modeliranja. Slika 14 prikazuje nabor konceptov, ki jih uporabljamo pri modeliranju IS. Koncepti v levem stolpcu se uporabljajo predvsem za modeliranje podatkovnega pogleda, koncepti v osrednjem stolpcu za 41/136 Analiza in modeliranje informacijskih sistemov modeliranje strogo procesnega pogleda, koncepti iz zadnjega stolpca pa ta dva ločena pogleda na nek način povezujejo. V okviru predmeta se bomo podrobneje seznanili z večino prikazanih konceptov. 4.2 Analiza informacijskih potreb Sedaj že vemo. Eden najpomembnejših pogledov na PS z vidika razvoja IS je podatkovni pogled. In kot smo videli zgoraj (Tabela 4), se v zvezi s podatkovnim pogledom vse začne z analizo informacijskih potreb. Pri tem nas zanima, kako podatke vidijo uporabniki IS. Gre torej za izrazito uporabniški pogled na podatke. Najprej si poglejmo, kaj razumemo pod pojmom informacijska potreba (IP). Z informacijskimi potrebami (IP) opredelimo, katere podatke in v kakšni obliki potrebujemo za izvajanje obravnavanega procesa ali pa nastopajo kot rezultat procesa. Običajno so to:  dokumenti  poročila  seznami in pregledi  zbirke  sporočila (ustna, telefonska, signali kot nek podatek v zbirki)  zaslonske slike (za prikaz ali vnos podatkov). Lahko so v poljubni obliki (ustno, papirni, elektronski). Analizo IP naredimo v dveh korakih:  Groba analiza IP, kjer dejansko identificiramo podatkovne vhode in izhode posameznih postopkov; vhodi so seveda tiste IP, ki jih potrebujemo za izvedbo postopka, izhodi pa tiste, ki pri izvedbi nastanejo. Temu lahko rečemo tudi analiza informacijskih tokov.  Podrobna analiza IP, kjer podrobno analiziramo posamezno IP iz prejšnjega koraka: za vsako IP določimo podatkovne elemente, ki jih vsebuje. Pri tem se vprašamo: katere podatke na določenem dokumentu, sporočilu ali v določeni zbirki potrebujemo in zakaj. Če na to zadnje vprašanje (zakaj) ne moremo odgovoriti, je velika verjetnost, da podatka ne potrebujemo. 42/136 Analiza in modeliranje informacijskih sistemov 4.2.1 Seznam informacijskih potreb Rezultat grobe analize IP je seznam informacijskih potreb v obliki tabele (Tabela 5), kjer v prvem stolpcu navedemo postopke poslovnega procesa, v drugem vhodne IP in v zadnjem izhodne IP za posamezen postopek. Za vsako IP torej določimo ime ter skušamo določiti tudi vrsto (dokument, zbirka, sporočilo). Tabela 5: Seznam informacijskih potreb za proces obravnave seminarskih nalog postopek vhodne informacijske potrebe izhodne informacijske potrebe Priprava prijave SN podatki o skupini (S) oddana prijava SN (D) podatki o koordinatorju (S) tema naloge (S) rok za prijavo (S) obrazec za prijavo SN (D) Pregled prijave SN oddana prijava SN (D) odločitev o odobritvi (S) seznam prijavljenih nalog (Z) obvestilo o potrebnih popravkih (S) identifikacijska številka skupine (S) seznam prijavljenih nalog (Z) Priprava SN prijava SN (D + Z) seminarska naloga (D) identifikacijska številka skupine (S) Pregled SN rok za oddajo SN (S) odločitev o ustreznosti SN (S) seznam prijavljenih nalog (Z) obvestilo o zavrnitvi SN (S) seminarska naloga (D) pregledana SN (D + Z) obvestilo o potrebnih popravkih SN (S) Določitev ocene SN pregledana SN (D + Z) ocena SN (Z) Obveščanje o oceni SN ocena SN (Z) obvestilo o oceni (S) Opomba: SN – seminarska naloga oznake v oklepajih pa pomenijo: S – sporočilo, D dokument, Z zbirka; ista informacijska potreba lahko nastopa v različnih oblikah Pri tem je pomembno, da so postopki med sabo povezani preko vhodov in izhodov; to pomeni, da je IP, ki je izhodna za nek postopek, hkrati tudi vhodna za nek drug postopek. V gornji tabeli je npr. 'oddana prijava SN' izhod iz 'priprava prijave SN' in hkrati vhod za 'pregled prijave SN', kar je seveda logično: študent pripravi prijavo (zato je za ta postopek seveda izhod), mentor pa jo pregleda (zato je za ta postopek to vhod). Velikokrat je ista IP za isti postopek hkrati vhod in izhod, lahko v različni fazi obdelave. Npr. 'seminarska naloga' je vhod za 'pregled SN', za isti postopek pa je izhod 'pregledana SN'. Gre za isti dokument (seminarsko nalogo). Podobno je npr. 'seznam prijavljenih nalog' hkrati vhod za postopek 'pregled prijave SN'. 43/136 Analiza in modeliranje informacijskih sistemov 4.2.2 Seznam podatkovnih elementov Rezultat podrobne analize IP pa je seznam podatkovnih elementov v obliki tabele, kjer v prvem stolpcu navedemo vse informacijske potrebe (ne zanima nas, ali so vhodi ali izhodi in v kakšni obliki), v drugem stolpcu pa pri vsaki IP napišemo podatkovne elemente, ki jih vsebuje. Pri tem pazimo na pravilno poimenovanje podatkovnega elementa: ime je vedno samostalnik v ednini (nikoli v množini). Vedno tudi napišemo, na koga se podatkovni element nanaša: torej naziv univerze, naziv fakultete, ime študenta, ime predavatelja. Tabela 6: Seznam podatkovnih elementov za proces obravnave seminarskih nalog informacijska potreba podatkovni elementi podatki o skupini (vpisna številka študenta, priimek in ime študenta, e-naslov študenta)+ podatki o koordinatorju vpisna številka koordinatorja, priimek in ime koordinatorja, e-naslov koordinatorja tema naloge naslov naloge, kratek opis procesa rok za prijavo študijski center, način študija, datum roka za prijavo, ura roka za prijavo obrazec za prijavo SN = naziv univerze, naziv fakultete, (naziv študijskega programa, kratica študijskega oddana prijava SN programa), (naziv predmeta, kratica predmeta), študijsko leto, način študija, študijski center, naslov naloge, (vpisna številka koordinatorja, priimek in ime koordinatorja, e-naslov koordinatorja), (vpisna številka študenta, priimek in ime študenta, e-naslov študenta)+, kratek opis procesa, kraj oddaje prijave, datum prijave odločitev o odobritvi prijava odobrena – da/ne obvestilo o potrebnih vpisna številka koordinatorja, opis potrebnih popravkov prijave popravkih identifikacijska številka vpisna številka koordinatorja, ID številka SN skupine seznam prijavljenih nalog datum izpisa seznama, (ID številka SN, datum prijave, naslov naloge, (vpisna številka koordinatorja, priimek in ime koordinatorja), (vpisna številka študenta, priimek in ime študenta)+)+ seminarska naloga naziv univerze, naziv fakultete, (kratica študijskega programa, naziv študijskega programa), način študija, študijski center, naslov naloge, (naziv predmeta, šifra predmeta, letnik študija), študijsko leto, (ime predavatelja, priimek predavatelja), ID številka SN, (vpisna številka koordinatorja, priimek in ime koordinatorja, e-naslov koordinatorja), (vpisna številka študenta, priimek in ime študenta, e- naslov študenta)+, kraj izdelave SN, mesec in leto izdelave SN, vsebina SN, datum oddaje SN rok za oddajo SN študijski center, način študija, datum roka za oddajo SN, ura roka za oddajo SN obvestilo o zavrnitvi SN vpisna številka koordinatorja, ID številka SN, datum zavrnitve SN, besedilo obvestila obvestilo o potrebnih vpisna številka koordinatorja, ID številka SN, opis popravkov SN popravkih SN ocena SN ID številka SN, (vpisna številka študenta, priimek in ime študenta, število točk za SN)+ obvestilo o oceni vpisna številka študenta, ID številka SN, število točk za SN 44/136 Analiza in modeliranje informacijskih sistemov V seznamu podatkovnih elementov nakažemo tudi strukturo – kako so ti podatki znotraj posamezne IP strukturirani:  v oklepajih ( ) zapišemo skupine podatkov, ki na posamezni informacijski potrebi predstavljajo neko zaključeno celoto,  s plusom + označimo podatke ali skupine podatkov, ki se pri isti informacijski potrebi ponavljajo. Če pogledamo na primeru IP 'podatki o skupini' iz zgornje tabele. Podatkovne elemente »vpisna številka študenta, priimek in ime študenta, e-naslov študenta«, smo dali v oklepaj in zadaj znak + - gre za skupino podatkov – kar nakazuje oklepaj, ki se na isti IP ponovi – kar nakazuje znak +, saj je v isti skupini več študentov, o vsakem študentu pa nas zanimajo isti podatki (vpisna številka, ime, priimek, e-naslov). pri obrazci za prijavo SN imamo enako (na istem obrazcu so podatki o več študentih), imamo pa pri tej IP npr. v oklepaju napisana podatkovna elementa »naziv predmeta, kratica predmeta«; tu pa oklepaj zato, ker oba podatka opisujeta isto stvar. oz. isti pojem – študijski predmet. Pri seznamu podatkovnih elementov velja opozoriti tudi na naslednje: isti podatki ali celo skupine podatkov se lahko pojavijo pri različnih IP, npr. skupina (vpisna številka študenta, priimek in ime študenta, e-naslov študenta) je tako na naslednjih IP: podatki o skupini, obrazec za prijavo SN, seminarska naloga. To ni nič narobe, celo zaželeno je. Pomeni, da iste podatke potrebujemo večkrat (pri različnih postopkih). Kaj moram vedeti?  Modeliranje, model  Pogledi na poslovni proces: opis, metode/tehnike  Posebno pomembna pogleda  Pogledi na poslovni proces: primerjava  Procesni in podatkovni pogled skozi 4-stopenjski model razvoja IS 45/136 5. poglavje: Modeliranje procesov V tem poglavju se bomo osredotočili na koncepte predstavitve ter metode in tehnike, ki jih uporabljamo pri modeliranju procesov. Od pogledov na poslovni sistem, ki smo jih obravnavali v 4. poglavju predavanj, v modeliranje procesov vključujemo: funkcijski, procesni in kombinirani pogled. V vseh treh pogledih so namreč osrednji predmet obravnave procesi, postopki in aktivnosti. Tako bomo najprej podrobneje predstavili osnovne koncepte predstavitve procesov, nato pa vsakega od zgoraj omenjenih pogledov vključno z metodami in tehnikami, ki jih uporabljamo za njihovo predstavitev. Vsebina poglavja 5.1 Osnovni koncepti in tehnike ........................................................................................................... 49 5.1.1 Osnovni koncepti predstavitve (modeliranja) procesov..................................................... 49 5.1.2 Strukturni graf .................................................................................................................... 50 5.2 Funkcijski pogled ............................................................................................................................ 50 5.2.1 Funkcijska dekompozicija ................................................................................................... 51 5.2.2 Funkcijski graf .................................................................................................................... 51 5.3 Diagram toka podatkov (DTP) ........................................................................................................ 52 5.3.1 Osnovno o diagramu toka podatkov .................................................................................. 52 5.3.2 Osnovni koncepti modeliranja za diagram toka podatkov ................................................. 53 5.4 Procesni pogled .............................................................................................................................. 54 5.4.1 O procesnem pogledu ........................................................................................................ 54 5.4.1.1 Osnovne značilnosti ....................................................................................................... 54 5.4.1.2 Procesna logika .............................................................................................................. 55 5.4.1.3 Metode in tehnike za prikaz procesnega pogleda ......................................................... 56 5.4.2 Diagram poteka (DP) .......................................................................................................... 56 5.4.2.1 Osnovni koncepti modeliranja za diagram poteka ......................................................... 56 5.4.2.2 Prednosti in pomanjkljivosti ........................................................................................... 57 5.4.3 Diagram aktivnosti ............................................................................................................. 58 5.4.3.1 Osnovni koncepti modeliranja za diagram aktivnosti .................................................... 58 5.4.3.2 Prednosti in pomanjkljivosti diagrama aktivnosti .......................................................... 59 5.4.4 BPMN diagram ................................................................................................................... 59 5.4.4.1 Osnovni koncepti modeliranja za BPMN diagram .......................................................... 59 47/136 Modeliranje procesov 5.4.4.2 Prednosti in pomanjkljivosti BPMN ................................................................................ 61 5.4.5 EPC diagram ....................................................................................................................... 62 5.4.5.1 Osnovni koncepti modeliranja za EPC diagram .............................................................. 62 5.4.5.2 Pravila osnovne verige ................................................................................................... 63 5.4.5.3 Prednosti in pomanjkljivosti EPC diagrama .................................................................... 64 5.4.6 Odločitvene tabele ............................................................................................................. 64 5.5 Kombinirani pogled ........................................................................................................................ 65 5.5.1 O kombiniranem pogledu .................................................................................................. 65 5.5.1.1 Osnovne značilnosti ....................................................................................................... 65 5.5.1.2 Metode in tehnike za modeliranje kombiniranega pogleda .......................................... 65 5.5.2 Razširjen diagram poteka (rDP).......................................................................................... 66 5.5.3 Razširjen diagram aktivnosti (rDA) ..................................................................................... 66 5.5.4 Razširjen BPMN diagram (rBPMN) ..................................................................................... 67 5.5.5 Razširjen EPC diagram (eEPC) ............................................................................................ 68 5.5.5.1 Koncepti modeliranja za eEPC diagram ......................................................................... 68 5.5.5.2 Pravila pri oblikovanju eEPC ........................................................................................... 68 PRILOGE: Primeri diagramov za upravni postopek ................................................................................ 70 48/136 Modeliranje procesov 5.1 Osnovni koncepti in tehnike 5.1.1 Osnovni koncepti predstavitve (modeliranja) procesov Slika 15: Osnovni koncepti opredelitve procesov Slika 15 prikazuje osnovne koncepte predstavitve oz. modeliranja procesov. Postopek Je zaključena celota operacij15 na podatkih, s katerimi se IS pripelje iz enega stanja v drugega. Opredeljen je z algoritmom, torej pravili izvajanja postopka16, ter vhodno/izhodnimi podatki. Postopek vhodne podatke pretvori (transformira) v izhodne. Dogodek je neke vrste impulz, do katerega pride bodisi zaradi sprememb ali posegov iz okolice IS ali zaradi notranjega stanja IS. Povzroči izvedbo enega ali več postopkov, s katerimi se spremeni stanje sistema. Poznamo:  notranje in zunanje dogodke: prvi nastanejo v sistemu, drugi pa v njegovi okolici; če upravni postopek sproži stranka na svojo zahtevo, gre za zunanji dogodek, če pa upravni postopek sproži po uradni dolžnosti, je to notranji dogodek;  časovne dogodke: dogodki, ki se nastanejo periodično, kar pomeni, da moramo na točno določen datum, izvršiti določeno stvar;  začetne in končne dogodke: začetni dogodek opredeljuje stanje, ki povzroči izvajanje nekega postopka, končni pa opredeljuje stanje, potem ko je postopek izvršen. Začetni pogoj zajema vse pogoje, ki morajo biti izpolnjeni, da se nek postopek lahko začne. Končni pogoj pa zajema vse pogoje, ki morajo biti izpolnjeni, da lahko štejemo, da je bil nek postopek pravilno in v celoti izvršen ter da je zagotovljena integriteta IS. Sporočilo je zaključena celota informacij, podatkov, ki je predmet obdelave v postopku. Poznamo:  vhodna, ki vstopajo v nek postopek ali proces in so potrebna za njegovo izvedbo, in  izhodna, ki izstopajo iz postopka in nastanejo kot rezultat njegove izvedbe. 15 Islovar (http://ww.islovar.org): »operacija je računski postopek, ki iz enega ali več podanih operandov na predpisan in enolično določen način izračuna rezultat«. 16 Islovar (http://ww.islovar.org) algoritem opredeljuje kot »zaporedje pravil, operacij, ukazov, ki zagotavljajo rešitev problema v končnem številu korakov«. 49/136 Modeliranje procesov Slika 16: Primeri osnovnih konceptov opredelitve procesov – upravni postopek 5.1.2 Strukturni graf  Je splošna grafična tehnika za prikazovanje hierarhične strukture  Ima obliko narobe obrnjenega drevesa  Vozlišča (običajno predstavljeni kot pravokotniki)  Koren (vozlišče na vrhu grafa) in listi (zaključki vej – vozlišča, ki niso naprej razgrajena)  Povezave med vozlišči so vedno neusmerjene, ker ne prikazujejo poteka, pretoka, ampak samo strukturo med vozlišči. Slika 17: Strukturni graf Slika 17 prikazuje splošen strukturni graf. Glede na to, kaj je vsebina vozlišč, torej strukturo česa predstavljamo, dobimo lahko različne grafe: če so vozlišča organizacijske enote ali delovna mesta, potem je to organigram (org. shema), če pa so to postopki in aktivnosti, dobimo funkcijski graf, ki prikazuje strukturo procesa. 5.2 Funkcijski pogled  Daje vpogled v delitev in strukturo poslovnih procesov in postopkov, ki se izvajajo v PS.  Je statičen pogled na procese, saj prikazuje samo strukturo, ne pa kako procesi tečejo.  Omogoča identifikacijo procesov in postopkov – v grobem opredelimo funkcionalnost – kaj delamo – makro (grob) pogled na procese.  Predstavimo ga s funkcijskim grafom, do katerega pridemo z metodo funkcijske dekompozicije. Funkcijski pogled torej prikazuje kaj delamo, ne pa tudi kako. 50/136 Modeliranje procesov 5.2.1 Funkcijska dekompozicija ZAKAJ potrebujemo funkcijsko dekompozicijo? Poslovni procesi so praviloma kompleksni, kar predstavlja problem razumljive predstavitve postopkov – kompleksnost rešujemo s pomočjo funkcijske dekompozicije. KAJ je? Funkcijska dekompozicija je postopno, sistematično razstavljanje poslovnih procesov na njihove elementarne sklope – manjše, preglednejše, obvladljivejše celote: elementarne postopke. KAKO? Vedno poteka od zgoraj navzdol (ang. top-down): od kompleksnega k enostavnemu oziroma od poslovnega procesa k elementarnim postopkom. REZULTAT? Je funkcijski graf, ki ga prikažemo s tehniko strukturnega grafa. 5.2.2 Funkcijski graf Funkcijski graf (Priloga 1) prikazuje strukturo poslovnega procesa (statičen pogled na procese), nič pa ne govori o tem, kako se postopki izvajajo.  Ima obliko strukturnega grafa (narobe obrnjeno drevo).  Vozlišča (pravokotniki) predstavljajo postopke: o koren grafa (najvišji nivo) predstavlja poslovni proces, o vmesna vozlišča predstavljajo sestavljene postopke poslovnega procesa, o listi (zaključki vej) so elementarni postopki, o v pravokotnik vpišemo ime postopka in njegovo hierarhično številko: ime postopka vedno izraža, kaj se v postopku dela; pravilno je torej sprejem vloge, ne pa vloga.  Povezave med vozlišči predstavljajo strukturo postopkov: vpeljujejo razmerje ‘sestoji-iz’ – postopek na višjem nivoju je sestavljen iz postopkov na nižjem. Ker ima funkcijski graf obliko strukturnega grafa, so te povezave seveda neusmerjene. Do funkcijskega grafa pridemo z metodo funkcijske dekompozicije. S funkcijskim grafom je povezan tudi pojem elementarnega postopka. To so zaključki vej v funkcijskem grafu – torej postopki, ki nimajo nobenega podrejenega postopka – niso razstavljeni. Elementarni postopek je najmanjša za uporabnika smiselna enota, katere izvedba predstavlja zaključeno celoto in je opredeljena z vhodno/izhodnimi podatki ter izvedbenimi pravili (algoritmom). Na spodnji sliki so elementarni postopki: 1.1, 1.2, 2, 3, 4.1, 4.2.1, 4.2.2. Elementarni postopki so lahko torej na različnih hierarhičnih nivojih. 51/136 Modeliranje procesov Slika 18: Shematski prikaz funkcijskega grafa Naslednja slika prikazuje poenostavljen funkcijski graf za obračunavanje plač. Kateri so elementarni postopki? Slika 19: Funkcijski graf za obračunavanje plač 5.3 Diagram toka podatkov (DTP) 5.3.1 Osnovno o diagramu toka podatkov Diagram toka podatkov (Priloga 2) je posebna diagramska tehnika, ki na nek način premošča prepad med strogo procesnim in strogo podatkovnim modelom. Pri tem velja poudariti, da to ni kombinirani pogled, ker ne prikazuje procesne logike (izvajanja procesa). Prav tako jo težko razvrstimo v katerega od drugih pogledov, sodi pa v modeliranje procesov. DTP torej deloma modelira:  procesni pogled o osnovne sestavine so procesi/postopki/aktivnosti o do neke mere prikazuje potek izvajanja (preko podatkovnih vhodov in izhodov) o je dinamični pogled (pretok podatkov)  podatkovni pogled o natančno opredeljuje VSE podatkovne vhode in izhode za posamezni postopek 52/136 Modeliranje procesov Osnovna opredelitev: Diagram toka podatkov omogoča opredelitev vseh informacijskih/podatkovnih tokov, ki nastopajo v okviru obravnavanega procesa ter med obravnavanim procesom in njegovo okolico. Lahko tudi rečemo: Diagram toka podatkov je grafična tehnika, pri kateri v obliki mreže predstavimo postopke obravnavanega procesa in pretok podatkov oziroma dokumentov med njimi ter med procesom in okolico. Obe definiciji sta enakovredni; druga le bolj podrobno opredeli, kaj je podatkovni tok: pretok podatkov oziroma dokumentov. Gre torej za pretok podatkov in podatkovnih struktur, pri čemer pa le-teh ne obravnavamo podrobno. S tem zgolj opredelimo vse podatkovne vhode in izhode za posamezen postopek ali aktivnost. 5.3.2 Osnovni koncepti modeliranja za diagram toka podatkov Slika 20 prikazuje osnovne koncepte modeliranja v diagramu toka podatkov. Mi bomo uporabljali Yourdon & DeMarco notacijo.  Postopek – del sistema, ki izvaja neko aktivnost, s katero transformira vhode v izhode  Zunanja entiteta – tisti zunanji elementi, s katerimi sistem komunicira: o niso pod kontrolo sistema o so mnogokrat povzročitelji dogodkov, ki sprožijo izvajanje določenega postopka o s podatkovnimi tokovi so vedno povezane s postopki (zunanji podatkovni tok)  Zbirka podatkov – modeliranje podatkovnih zbirk, ki nastajajo v okviru modeliranega IS o so lahko na poljubnem mediju o prek podatkovnih tokov so vedno povezane s postopki (notranji podatkovni tokovi)  Tok podatkov (podatkovni tok) – prenos oz. potovanje podatkov/informacij/dokumentov med različnimi deli sistema o podatki vedno v gibanju o predstavljajo vse podatkovne vhode in izhode za postopek Slika 20: Osnovni koncepti modeliranja v diagramu toka podatkov Poglejmo, kaj še moramo vedeti o podatkovnih tokovih. Zunanji (eksterni) podatkovni tok 53/136 Modeliranje procesov  vedno povezuje zunanjo entiteto in postopek  je vedno poimenovan (ime toka pove, kateri podatki, dokumenti, sporočila … s tem tokom potujejo)  je vedno enosmeren Notranji (interni) podatkovni tok  vedno povezuje zbirko podatkov in postopek  ga ne poimenujemo  je lahko tudi dvosmeren Slika 21 prikazuje, katerih konceptov v diagramu toka podatkov ne smemo nikoli povezati. Zbirka podatkov in zunanja entiteta sta namreč povezani izključno s postopkom. Slika 21: Česa ne smemo povezati v DTP? DTP je torej tehnika, ki nam pomaga analizirati informacijske tokove. 5.4 Procesni pogled 5.4.1 O procesnem pogledu 5.4.1.1 Osnovne značilnosti  Je osnova za razvoj programov  Prikazuje algoritme in potek dela o kako proces dejansko teče o logika izvajanja ali procesna logika (kako so aktivnosti povezane): zaporedje, vzporednost, različne možne poti izvajanja o mikro pogled na procese  Dinamični pogled na procese  Proučuje o poslovne procese o postopke 54/136 Modeliranje procesov o pravila in pogoje izvajanja postopkov 5.4.1.2 Procesna logika Drug izraz: logika izvajanja procesa Pod procesno logiko razumemo različne načine medsebojne povezanosti aktivnosti v smislu izvajanja procesa: - zaporedje: najprej  potem (nato) - vzporednost (paralelnost): IN hkrati - alternative (različne možne poti): ALI Zaporedje Eni aktivnosti sledi druga  naslednja aktivnost se ne more začeti izvajati, če ni zaključena predhodna aktivnost Primer:  najprej se izpiše račun,  potem se račun plača,  potem se potrdi predajo popravljenega vozila Vzporednost – razvejanje Po zaključku neke aktivnosti se hkrati pričneta izvajati dve (ali več) drugih aktivnosti Primer: po zaključku popravila vozila  administrator obvesti stranko o zaključku popravila in hkrati  blagajnik obračuna stroške popravila (delo in material) Vzporednost –združevanje Neka aktivnost se lahko prične izvajati, ko sta predhodno zaključeni dve (ali več) aktivnosti, ki sta se izvajali vzporedno. Primer: predaja vozila se lahko prične izvajati šele, ko  administrator obvesti stranko in  blagajnik obračuna stroške popravila Alternative – razvejanje Je običajno posledica neke odločitve Izvajanje postopka se nadaljuje po eni od alternativ – po zaključku neke aktivnosti izvedemo eno od več možnih aktivnosti Primer: po pregledu popravljenega vozila se lahko:  ali izvede plačilo računa (če je stranka zadovoljna s popravilom)  ali vozilo ponovno popravimo (da odpravimo napake, če stranka ni zadovoljna s popravilom) Alternative –združevanje Neka aktivnost se lahko prične izvajati, ko se predhodno zaključi ena od več možnih aktivnosti Primer: popravljanje vozila se prične izvajati  ali ko je vozilo sprejeto v popravilo (na začetku celotnega procesa)  ali pa, ko po pregledu popravljenega vozila stranka ni zadovoljna s popravilom (na koncu procesa) 55/136 Modeliranje procesov 5.4.1.3 Metode in tehnike za prikaz procesnega pogleda  Diagram poteka – DP ( Flow Chart)  Diagram aktivnosti – DA ( Activity Diagram) o V okviru UML ( Unified Modeling Language), to je metodologija za modeliranje objektnega pristopa  Notacija za modeliranje poslovnih procesov – BPMN ( Business Process Modeling Notation)  Dogodkovno-verižni diagram (tudi dogodkovno vodena veriga procesov) – EPC diagram ( Event-Driven Process Chain)  Odločitvena tabela Sedaj pa si podrobneje poglejmo zgoraj naštete metode in tehnike. 5.4.2 Diagram poteka (DP) Diagram poteka (Priloga 3) je ena najstarejših tehnik za prikaz poteka postopka. Namenjen modeliranju (prikazu) procesnega pogleda. Prikazuje potek izvajanja procesa (dinamičnost), vključno s procesno logiko: zaporedje, vzporednost, alternative (različne možne poti). Posebej so poudarjene odločitve. 5.4.2.1 Osnovni koncepti modeliranja za diagram poteka Tabela 7 prikazuje osnovne koncepte modeliranja za diagram poteka. V nadaljevanju jih bomo podrobneje opisali. Tabela 7: Osnovni koncepti modeliranja v diagramu poteka Naziv Grafični simbol začetek/konec aktivnost odločitev (razvejanje alternativ) združevanje alternativ vzporednost krmilni tok sporočilo Začetek/konec označuje začetek ali konec procesa (vsak diagram oz. vsaka veja v diagramu mora imeti začetek in konec). Aktivnost označuje eno ali več medsebojno povezanih aktivnosti ali postopkov – posamezni 'korak', ki ga izvedemo. Odločitev označuje točko odločitve oz. razvejanja alternativ (od tu gremo po različnih poteh). Prikažemo jo z rombom, v katerega vpišemo odločitev v obliki vprašanja. Vsi izhodni tokovi iz odločitve morajo biti vedno poimenovani, in sicer kot odgovori na vprašanje v odločitvi. S tem dejansko opredelimo pogoj, ki 56/136 Modeliranje procesov mora biti izpolnjen, da gremo iz odločitve po določeni poti. Odločitev ima vedno en vhodni in več izhodnih tokov. Združevanje alternativ označuje točko, ki združuje različne možne poti izvajanja. Do točke združevanja alternativ lahko torej pridemo po različnih poteh. Vedno ima več vhodnih in en izhodni tok. Vzporednost označuje točko, kjer se vzporedne poti razvejajo ali pa združijo. Lahko jo postavimo ležeče ali pokončno (kot nam glede na potek procesa najbolj ustreza). Zanjo velja:  razvejanje vzporednosti: en vhodni in več izhodnih tokov,  združevanje vzporednosti: več vhodnih in en izhodni tok,  nikoli pa hkrati več vhodnih in več izhodnih tokov. Krmilni tok nakazuje potek izvajanja procesa in povezuje ostale koncepte. Je vedno usmerjena povezava. Ni poimenovan, razen če nastopa kot izhod iz odločitve (glej pri odločitvi). Sporočilo (vhodno ali izhodno) uporabimo, kadar želimo eksplicitno prikazati, kaj je podatkovni vhod v postopek in kaj njegov podatkovni rezultat (izhod). Slika 22: Prikaz procesne logike v diagramu poteka zaporedje akt 1 akt 2 akt 3 – razvejanje (logični ALI) združevanje (logični ALI) e pogoj 1 tiv poti akt 2 akt 1 na ne akt 1 odločitev? akt 3 er alt azličr akt 3 akt 2 pogoj 2 t razvejanje (logični IN) združevanje (logični IN) akt 1 ednos akt 2 akt 1 akt 3 zporv akt 3 akt 2 5.4.2.2 Prednosti in pomanjkljivosti Kot prednosti lahko izpostavimo:  je dokaj enostaven in razumljiv (ljudje ga običajno hitro razumejo in znajo prebrati);  jasno predstavljena procesna logika, saj imamo posebne simbole za začetek in konec, odločitve in združevanje alternativ ter prikaz vzporednosti;  za razliko od ostalih tehnik, je odločitev vidno izpostavljena in vpisana v sam simbol – tako jo lažje hitro opazimo. Glavni pomanjkljivosti pa sta:  ne omogoča prikaza dogodkov;  ne omogoča opredelitve pogojev za izvedbo posamezne aktivnosti (razen pri odločitvah). 57/136 Modeliranje procesov 5.4.3 Diagram aktivnosti Diagram aktivnosti (Priloga 5) je UML diagramska tehnika za modeliranje procesnega pogleda na poslovni sistem. Prikazuje torej potek izvajanja procesa (dinamičnost) vključno s procesno logiko: zaporedje, vzporednost, alternative (različne možne poti). Je zelo podoben diagramu poteka, le simboli so drugačni. 5.4.3.1 Osnovni koncepti modeliranja za diagram aktivnosti Tabela 8 prikazuje osnovne koncepte modeliranja za diagram aktivnosti. V nadaljevanju jih bomo podrobneje opisali. Tabela 8: Osnovni koncepti modeliranja v diagramu aktivnosti Naziv Grafični simbol Začetek Konec Aktivnost Sprejemanje vloge Odločitev / združevanje alternativ Sinhronizacijska črta Krmilni tok Začetek in konec sta krmilna elementa, ki označujeta začetne in končne točke procesa. Vsak diagram aktivnosti mora imeti vsaj en začetek in vsaj en konec. Še več, vsaka veja v diagramu mora imeti vsaj en začetek in vsaj en konec. Aktivnost označuje eno ali več medsebojno povezanih aktivnosti ali postopkov – posamezni 'korak', ki ga izvedemo. Odločitev / združevanje alternativ omogoča prikazovanje različnih možnih poti (alternativ). Pri tem velja:  odločitev ima vedno en vhodni in več izhodnih tokov; na izhodne tokove v oglatem oklepaju napišemo pogoje (kriterije), ki določajo, ob katerem pogoju gremo po določenem izhodnem toku;  združevanje alternativ ima vedno več vhodnih in en izhodni tok;  nikoli pa simbol nima hkrati več vhodnih in več izhodnih tokov. Sinhronizacijska črta omogoča prikaz vzporednosti. Tudi zanjo velja:  razvejanje vzporednosti: en vhodni in več izhodnih tokov;  združevanje vzporednosti: več vhodnih in en izhodni tok;  nikoli pa hkrati več vhodnih in več izhodnih tokov. Krmilni tok (včasih poimenovan tudi kontrolni tok) povezuje ostale koncepte in nakazuje potek izvajanja. Vedno je usmerjena povezava in vedno samo v eno smer. 58/136 Modeliranje procesov Slika 23: Prikaz procesne logike v diagramu aktivnosti 5.4.3.2 Prednosti in pomanjkljivosti diagrama aktivnosti Velja podobno kot za diagram poteka (DP). Kot prednosti lahko izpostavimo:  je dokaj enostaven in razumljiv (ljudje ga običajno hitro razumejo in znajo prebrati);  jasno predstavljena procesna logika, saj imamo posebne simbole za začetek in konec ter prikaz alternativ in vzporednosti. Glavni pomanjkljivosti pa sta:  ne omogoča prikaza dogodkov;  ne omogoča opredelitve pogojev za izvedbo posamezne aktivnosti (razen pri odločitvah). V primerjavi z DP nima posebej izpostavljenih odločitev, ker sta simbola za odločitev in združevanje alternativ enaka. 5.4.4 BPMN diagram Kratica BPMN izhaja iz angleškega imena Business Process Modeling Notation (notacija za modeliranje poslovnih procesov). BPMN diagram (Priloga 7) je namenjen modeliranju procesnega pogleda. Prikazuje torej potek izvajanja procesa, vključno s procesno logiko. Prednost je, da omogoča dovolj natančno modeliranje izvajanja procesa, da ga lahko s pomočjo BPML ( Business Process Modeling Language – jezika za modeliranje poslovnih procesov) neposredno prenesemo v izvajalsko okolje. Poleg tega omogoča (z uporabo dogodkov) natančno opredeliti pogoje za izvedbo aktivnosti. 5.4.4.1 Osnovni koncepti modeliranja za BPMN diagram Tabela 9 prikazuje osnovne koncepte modeliranja v BPMN, ki jih v nadaljevanju podrobneje opišemo. 59/136 Modeliranje procesov Tabela 9: Osnovni koncepti modeliranja v BPMN diagramu Naziv Grafični simbol Dogodek Aktivnost Sprejemanje vloge Prehod (kretnica) Krmilni tok Dogodek (ang. event) označuje dogodek, dejanje ali stanje, ki sproži ali omogoči izvajanje procesa ali posamezne aktivnosti oz. opisuje stanje po zaključeni aktivnosti; glej tudi poglavje 5.1.1. Dogodek je vedno predstavljen s krogom; za različne vrste dogodkov se uporablja različne oblike; Slika 24 prikazuje le najpogostejše. Sporočilni dogodki se nanašajo na dogodke, ki nakazujejo, da je vpleteno kakršnokoli sporočilo (ne glede v kakšni obliki). Slika 24: Najpogostejši dogodki v BPMN Aktivnost (tudi opravilo; ang. task) označuje eno ali več medsebojno povezanih aktivnosti ali postopkov – posamezni 'korak', ki ga izvedemo. Prehodi (ang: gateway) usmerjajo potek izvajanja aktivnosti; omogočajo torej prikaz logike izvajanja procesa (Slika 25):  alternative prikažemo s prehodom EXCLUSIVE (XOR) – KREPKI ALI (XALI): pomeni, da se izvede natanko ena od izhodnih poti;  različne možnosti prikažemo s prehodom INCLUSIVE (OR) – ALI: pomeni, da se izvede ena ali več izhodnih poti;  vzporednost prikažemo s PREHODOM PARALLEL (AND) – IN: pomeni, da se izvedejo vse izhodne poti. Gornje velja za točke razvejanja (en vhod, več izhodov); seveda pa podobno velja tudi za točke združevanja (več vhodov in en sami izhod). 60/136 Modeliranje procesov Slika 25: Osnovni prehodi v BPMN Krmilni tok (včasih poimenovan tudi kontrolni tok; ang. sequence flow) povezuje ostale koncepte in nakazuje potek izvajanja; če je to izhod iz prehodov XOR ali OR, ga poimenujemo. Podrobneje o osnovnih konceptih modeliranja si poglejte na spletišču BPMN Modeling Reference (https://camunda.org/bpmn/reference/). Slika 26: Prikaz procesne logike v BPMN 5.4.4.2 Prednosti in pomanjkljivosti BPMN Prednosti:  posebej razvit za modeliranje poslovnih procesov  omogoča podrobno modeliranje poslovnih procesov  preko dogodkov opredeljeni pogoji  s pomočjo BPML neposredno prenosljiv v izvajalsko okolje Pomanjkljivosti:  precej zapleten in včasih težko berljiv, ker o enak simbol za vzporednost in alternative (prehodi) o ni posebnega simbola za odločitve 61/136 Modeliranje procesov 5.4.5 EPC diagram Srečamo tudi izraza: dogodkovno vodena veriga procesov ali tudi dogodkovno-verižni diagram. Običajno uporabljamo kar EPC diagram. Kratica EPC izhaja iz angleškega imena: Event-driven Process Chain. EPC diagram (Priloga 9) je namenjen modeliranju (prikazu) procesnega pogleda. Prikazuje potek izvajanja procesa (dinamičnost), vključno s procesno logiko: zaporedje, vzporednost, alternative (različne možne poti). Posebej so poudarjeni pogoji za izvedbo posamezne aktivnosti. 5.4.5.1 Osnovni koncepti modeliranja za EPC diagram Tabela 10: Osnovni koncepti modeliranja v EPC diagramu Naziv Grafični simbol Dogodek Aktivnost Logični povezovalnik Krmilni tok Dogodek označuje dogodek (ang. event), dejanje ali stanje, ki sproži ali omogoči izvajanje procesa ali posamezne aktivnosti (glej tudi poglavje 5.1.1 Osnovni koncepti predstavitve (modeliranja) procesov). Aktivnost označuje eno ali več medsebojno povezanih aktivnosti ali postopkov – posamezni 'korak', ki ga izvedemo (ang. function). Logični povezovalniki usmerjajo potek izvajanja aktivnosti (prikazujejo logiko izvajanja procesa). Krmilni tok nakazuje potek izvajanja procesa (je usmerjena povezava, črtkana črta). Velikokrat uporabimo tudi povezovalnik strani (tehnični element), ki ga uporabljamo, ker je tehnika precej prostorsko 'požrešna', da z njim povezujemo strani diagrama, ki se razteza čez več strani (sistem 'krojne pole'). Ta element lahko uporabimo tudi pri nekaterih drugih metodah/tehnikah. Še o logičnih povezovalnikih Poznamo tri vrste logičnih povezovalnikov:  IN: izvesti vse može poti (vzporednost)  XALI: izvesti natanko eno od možnih poti  ALI: izvesti vsaj eno od možnih poti (eno, lahko tudi več) Logični povezovalnik prikazuje točko:  razvejanja tokov (en vhod in več izhodov)  združevanja tokov (več vhodov in en izhod) NE sme imeti:  hkrati več vhodov in več izhodov ALI  samo enega vhoda in enega izhoda Pomni! 62/136 Modeliranje procesov  Dogodek: vedno izraža neko trenutno stanje – npr. 'prispela vloga'  Aktivnost: izraža dogajanje, ki traja dlje časa – npr. 'pregledovanje vloge'  Različne možne poti (alternative) prikažemo s pomočjo logičnega povezovalnika ALI (torej tudi odločitve)  Vzporednost prikažemo s pomočjo logičnega povezovalnika IN  Krmilni tok: črtkana črta 5.4.5.2 Pravila osnovne verige Vsak diagram se začne in konča z dogodkom (začetni in končni dogodek) Osnovno zaporedje je: dogodek  aktivnost  dogodek ... ; torej:  na poti med dvema aktivnostma je vedno vsaj en dogodek: dve aktivnosti nista nikoli neposredno medsebojno povezani  na poti med dvema dogodkoma je vedno vsaj ena aktivnost ali logični povezovalnik: dva dogodka nista nikoli neposredno medsebojno povezana Slika 27: Grafični prikaz pravil osnovne verige za EPC diagram 63/136 Modeliranje procesov Slika 28: Prikaz procesne logike v EPC diagramu 5.4.5.3 Prednosti in pomanjkljivosti EPC diagrama Prednosti:  posebej razvit za modeliranje poslovnih procesov  omogoča podrobno modeliranje poslovnih procesov  preko dogodkov opredeljeni pogoji za izvedbo posameznih aktivnosti Pomanjkljivosti:  precej prostorsko ‘požrešen’  precej zapleten in včasih težko berljiv, ker o enak simbol za vzporednost in alternative (logični povezovalnik) o ni posebnih simbolov za začetek/konec o ni posebnega simbola za odločitve 5.4.6 Odločitvene tabele Je pomožna tehnika za modeliranje procesov, ki omogoča prikaz pogojev za izvedbo posameznih aktivnosti (Tabela 11). V zgornjem delu tabele so nanizani pogoji, v spodnjem pa aktivnosti. Zgornji desni del opredeljuje kombinacijo pogojev, spodaj desno pa z X označimo, katere aktivnosti se izvedejo ob določeni kombinaciji pogojev. Tako lahko stolpec P1 preberemo: če je vloga nerešena IN je popolna, jo rešujemo. Vrstico Reševanje (1. vrstica v spodnjem delu tabele): vlogo rešujemo, če je nerešena IN popolna (stolpec P1); ALI če je nerešena IN ni popolna IN je potekel rok za dopolnitev IN je dopolnjena (stolpec P4). 64/136 Modeliranje procesov Tabela 11: Primer odločitvene tabele za upravni postopek 5.5 Kombinirani pogled 5.5.1 O kombiniranem pogledu 5.5.1.1 Osnovne značilnosti  Veže aktivnosti in vire (človeške in informacijske/podatkovne), potrebne za njihovo izvedbo  Združuje več osnovnih pogledov; najširše o procesni (potek izvajanja – dinamičnost) o organizacijski (kdo izvaja oz. je odgovoren za posamezno aktivnost oz. postopek) o podatkovni (vsi podatkovni vhodi in izhodi za posamezno aktivnost oz. postopek)  Dobimo širšo sliko (predstavo) obravnavanega procesa Pomni! Kombinirani pogled vedno vsebuje procesnega, poleg tega pa vsaj še enega od preostalih osnovnih pogledov. Največkrat se procesnemu pridruži organizacijski pogled. 5.5.1.2 Metode in tehnike za modeliranje kombiniranega pogleda Razširjen diagram aktivnosti (rDA) in razširjen diagram poteka (rDP) združujeta:  procesni in  organizacijski pogled eEPC diagram (razširjeni EPC diagram) in razširjeni BPMN diagram (rBPMN) pa združujeta:  procesni  organizacijski in  podatkovni pogled Poglejmo si podrobneje omenjene metode in tehnike. 65/136 Modeliranje procesov 5.5.2 Razširjen diagram poteka (rDP) RDP (Priloga 4) je namenjen modeliranju kombiniranega pogleda, saj:  V osnovi enako kot diagram poteka (DP) prikazuje procesni pogled in torej prikazuje potek izvajanja poslovnega procesa ali postopka (dinamičnost) vključno s procesno logiko.  Ker pa je za izvajanje procesa izredno pomembno, kdo so izvajalci oz. odgovorni za izvajanje posameznih aktivnosti ali sprejemanje odločitev, procesnemu pridružimo še organizacijski pogled, tako da ga razširimo s t. i. progami (stezami) – organizacijskimi objekti. Slika 29: organizacijski objekt (proga) v razširjenem diagramu poteka Vse, kar velja za diagram poteka, velja seveda tudi za razširjen diagram poteka. Osnovni koncepti modeliranja so torej v osnovi torej enaki kot pri osnovnem diagramu poteka (razdelek 5.4.2.1) in zanje seveda velja vse, kar smo povedali že prej. Dodan pa je še organizacijski objekt (npr. delovno mesto ali organizacijska enota), ki je predstavljen kot proga (»swimlane«). Ta je sestavljena iz dveh delov (Slika 29):  v levi del vpišemo ime organizacijskega objekta (npr. sprejemna pisarna),  v desni del pa tiste aktivnosti in odločitve, ki jih ta organizacijski objekt izvaja oz. sprejema. Proga je lahko postavljena tudi navpično – v tem primeru v zgornji del vpišemo ime organizacijskega objekta, spodnji del pa vsebuje tiste aktivnosti in odločitve, ki jih ta organizacijski objekt izvaja oz. sprejema (glej Priloga 4). 5.5.3 Razširjen diagram aktivnosti (rDA) Ta diagram (Priloga 6) v osnovi enako kot diagram aktivnosti (DA) prikazuje potek izvajanja procesa (procesni pogled), vključno s procesno logiko. Ker pa osnovni diagram aktivnosti nič ne govori o izvajalcih posameznih aktivnostih, kar je za samo izvajanje procesa izredno pomembna informacija, ga lahko razširimo s t. i. progami (stezami) in procesnemu pogledu pridružimo še organizacijski pogled. Razširjen diagram aktivnosti torej modelira kombinirani pogled, saj združuje procesni in organizacijski pogled. Vse, kar velja za diagram aktivnosti, velja seveda tudi za razširjen diagram aktivnosti. Osnovni koncepti modeliranja so v osnovi torej enaki kot pri diagramu aktivnosti (razdelek 5.4.3.1) in zanje seveda velja vse, kar smo povedali že prej. Dodan pa je še organizacijski objekt (npr. delovno mesto ali organizacijska enota), ki je – podobno kot pri rDP – predstavljen kot proga (»swimlane«) (Slika 30). Tudi tu so (podobno kot pri rDP) proge lahko postavljene navpično. 66/136 Modeliranje procesov Slika 30: Organizacijski objekt (proga) v razširjenem diagramu aktivnosti 5.5.4 Razširjen BPMN diagram (rBPMN) Ta diagram (Priloga 8) v osnovi enako kot BPMN diagram prikazuje potek izvajanja procesa (procesni pogled), vključno s procesno logiko. Ker pa osnovni BPMN diagram nič ne govori o izvajalcih posameznih aktivnostih, kar je za samo izvajanje procesa izredno pomembna informacija, ga lahko razširimo s t. i. progami (stezami) in procesnemu pogledu pridružimo še organizacijski pogled. Poleg tega pa rBPMN omogoča tudi, da v sam proces vključimo informacijske objekte in tako vidimo, kako se podatki/informacije pretakajo med aktivnostmi, hkrati s tem pa opredelimo vse podatkovne vhode in izhode za posamezno aktivnost – pridružimo torej še podatkovni pogled. Razširjen BPMN diagram torej modelira kombinirani pogled, saj združuje procesni, podatkovni in organizacijski pogled. Vse, kar velja za osnovni BPMN diagram, velja seveda tudi za razširjen BPMN diagram. Osnovni koncepti modeliranja so v osnovi torej enaki kot pri BPMN diagramu (razdelek 5.4.4.1) in zanje seveda velja vse, kar smo povedali že prej. Dodan pa je še organizacijski objekt (npr. delovno mesto ali organizacijska enota), ki je predstavljen kot proga (»lane«) (Slika 31). Pri rBPMN so proge ali steze vedno postavljene vodoravno (Priloga 8). Za razliko od rDP in rDA ime organizacijskega objekta ni s pokončno črto ločeno od ostalih sestavin diagrama v progi. Za vključitev podatkovnega pogleda pa sta dodana še informacijski objekt (npr. dokument, sporočilo, podatki/informacije) in informacijski tok (Slika 31) s katerim je informacijski objekt povezan izključno z aktivnostjo. Informacijski tok je vedno usmerjena povezava, črtkana črta (da se loči od krmilnega toka). Slika 31: Dodatni objekti v razširjenem BPMN diagramu 67/136 Modeliranje procesov 5.5.5 Razširjen EPC diagram (eEPC) Razširjen EPC diagram (Priloga 10) je namenjen modeliranju kombiniranega pogleda na poslovni sistem. Osnovnemu EPC diagramu, ki prikazuje procesni pogled, se pridružita še organizacijski in podatkovni pogled. Od vseh obravnavanih tehnik poleg rBPMN daje najširšo sliko obravnavanega procesa, saj za vsako aktivnost opredeli izvajalca oz. odgovornega za njeno izvajanje ter vhodne in izhodne podatke/informacije. Vse, kar velja za EPC diagram, seveda velja tudi za eEPC diagram. 5.5.5.1 Koncepti modeliranja za eEPC diagram Poleg konceptov modeliranja, ki veljajo za EPC diagram (dogodek, aktivnost, logični povezovalniki, krmilni tok; glej razdelek 5.4.5.1), pa eEPC vključuje še dodatne koncepte (Tabela 12). Tabela 12: Dodatni koncepti modeliranja v ePC diagramu Naziv Grafični simbol Informacijski objekt Informacijski tok Organizacijski objekt Organizacijska povezava Informacijski objekt vsebuje podatke, ki se potrebujejo za izvedbo določene aktivnosti ali so rezultat izvedbe; dejansko ti informacijski objekti združujejo entitete iz E-R diagrama in povezave med njimi. Informacijski tok nakazuje potek podatkov (iz informacijskega objekta v aktivnost ali obratno ali oboje hkrati); usmerjena povezava, polna črta. Organizacijski objekt prikazuje izvajalce ali odgovorne za izvajanje posamezne aktivnosti. Organizacijska povezava povezuje organizacijski objekt in aktivnost; neusmerjena povezava, polna črta. 5.5.5.2 Pravila pri oblikovanju eEPC Za eEPC prav tako kot za EPC veljajo pravila osnovne verige (razdelek 5.4.5.2, Slika 27), za dodatne koncepte pa poleg tega velja še (Slika 32):  organizacijski objekt je z organizacijsko povezavo povezan izključno z aktivnostjo,  informacijski objekt je z i nformacijskim tokom povezan izključno z aktivnostjo. 68/136 Modeliranje procesov Slika 32: Grafični prikaz dodatnih pravil za oblikovanje eEPC diagrama Kaj moram vedeti?  Funkcijski, procesni, kombinirani pogled – primerjava  Osnovni koncepti modeliranja procesov – lasten primer  Funkcijska dekompozicija in funkcijski graf  Diagram toka podatkov  Metode/tehnike za modeliranje procesnega pogleda – značilnosti, primerjava, osnovni koncepti posamezne  Metode/tehnike za modeliranje kombiniranega pogleda – značilnosti, primerjava, osnovni koncepti posamezne  Primerjava metod/tehnik procesnega in kombiniranega pogleda 69/136 Modeliranje procesov PRILOGE: Primeri diagramov za upravni postopek V prilogi bomo prikazali različne metode/tehnike za modeliranje procesov na konkretnem primeru. Za primer smo izbrali zelo poenostavljen splošni upravni postopek (vsak upravni postopek je poslovni proces). Priloga 1: Funkcijski graf za upravni postopek IN O A JE K A N JE IR IV JE IK A N JE V D A N A N IR IR .1 A ZB R .2 EN V .3 N 7 G O 7 D O 7 Č . G O K SIFIC LA O K V O IN SIG V K R DO JE LA TE N A K A BM TIR A 7 R EN H IDVE A JE LEP NAČ E/SK 6 O B R Č V O A DLO JE E LEP N BČ SK JA O .1 .2 5 JE 5 DA DL N A IZ O JA DA JE LEP IZ NJA E/SKB 5 DA Č IZ O DLO KE P JE O N ST A E O VA G I P 0 N 4 LO N V V V A A RB PR O U E G JE LO N V A EV EV 3 T IT H LN ZA OP LED G LED DO ER EG E R E I P G .1 G .2 LN LO 2 KI P 2 S LO A V V IN JE M B N R A SE V E FO V G 2 LO LEDO V GERP JENA EMG 1 JE LO E V RSP 70/136 Modeliranje procesov Priloga 2: Diagram toka podatkov za upravni postopek vloga; zahtevane dopolnitve sprejemanje potrdilo o STRANKA vloge prejemu 1 ZADEVE pregledovanje vloge 2 PREDPISI zahteva za dopolnitev zahtevanje dopolnitve vloge 3 evidentiranje in hramba 7 obravnavanje vloge 4 PREDPISI izdajanje odločbe/sklepa ZADEVE 5 odločba/sklep vročanje potrdilo STRANKA odločbe/sklepa o vročitvi 6 71/136 Modeliranje procesov Priloga 3: Diagram poteka za upravni postopek START VLOGA DA sprejemanje vloge pregledovanje vloge evidentiranje in hramba NE popolna vloga? DA zahtevanje dopolnitve vloge obravnavanje vloge vloga NE dopolnjena? izdajanje odločbe/sklepa vročanje odločbe/ sklepa ODLOČBA ali SKLEP KONEC 72/136 Modeliranje procesov Priloga 4: Razširjen diagram poteka za upravni postopek glavna pisarna pristojni oddelek START VLOGA evidentiranje in hramba sprejemanje vloge pregledovanje vloge popolna vloga? NE obravnavanje vloge zahtevanje dopolnitve vloge vloga DA NE dopolnjena? izdajanje odločbe/sklepa vročanje odločbe/sklepa ODLOČBA ali SKLEP KONEC 73/136 Modeliranje procesov Priloga 5: Diagram aktivnosti za upravni postopek sprejemanje vloge [vloga JE dopolnjena] pregledovanje vloge [vloga NI [vloga JE popolna] popolna] zahtevanje dopolnitve vloge obravnavanje vloge [vloga NI dopolnjena] evidentiranje in izdajanje hramba odločbe/sklepa vročanje odločbe/sklepa 74/136 Modeliranje procesov Priloga 6: Razširjen diagram aktivnosti za upravni postopek Poenostavljen upravni postopek glavna pisarna pristojni oddelek evidentiranje in hramba sprejemanje vloge pregledovanje vloge [vloga NI popolna] [vloga JE dopolnjena] zahtevanje dopolnitve vloge [vloga JE popolna] obravnavanje vloge [vloga NI dopolnjena] izdajanje odločbe/sklepa vročanje odločbe/sklepa 75/136 Modeliranje procesov Priloga 7: BPMN diagram za upravni postopek 76/136 Modeliranje procesov Priloga 8: Razširjen BPMN za upravni postopek 77/136 Modeliranje procesov Priloga 9: EPC diagram za upravni postopek 78/136 Modeliranje procesov Priloga 10: eEPC za upravni postopek 79/136 6. poglavje: Modeliranje podatkov To poglavje je uvod v obširnejšo tematiko modeliranja podatkov, kar pomeni, da se osredotočamo na podatkovni pogled. Tako bomo najprej poudarili pomen podatkov, nato spoznali, kaj so podatkovni modeli in predstavili razvoj in vrste podatkovnih modelov, poglavje pa bomo zaključili s koncepti abstrakcije, ki jih uporabljamo pri modeliranju podatkov. Poglavje je za razumevanje nadaljnjih poglavij o podatkovnem modeliranju zelo pomembno, saj predstavlja osnovo za podatkovne modele, ki jih bomo obravnavali v nadaljevanju. Vsebina poglavja 6.1 Podatkovni modeli ......................................................................................................................... 82 6.1.1 Pomen podatkov ................................................................................................................ 82 6.1.2 Opredelitev (definicija) podatkovnega modela .................................................................. 82 6.1.3 Razvoj in vrste podatkovnih modelov ................................................................................ 82 6.2 Koncepti abstrakcije pri modeliranju podatkov ............................................................................. 83 6.2.1 Klasifikacija ......................................................................................................................... 84 6.2.2 Generalizacija ..................................................................................................................... 85 6.2.3 Agregacija .......................................................................................................................... 86 Viri in literatura ...................................................................................................................................... 87 81/136 Modeliranje podatkov 6.1 Podatkovni modeli 6.1.1 Pomen podatkov Podatki so za vsak poslovni sistem in z njim povezane informacijske sisteme izrednega pomena:  podatki so predmet obdelave vsakega IS; to torej pomeni, da IS brez podatkov/informacij nima smisla;  podatki opisujejo realni svet; gre dejansko za informacijske potrebe poslovnega sistema;  zavedati se moramo kompleksnosti podatkov v sodobnih poslovnih in s tem tudi informacijskih sistemih; gre tako za veliko količino podatkov kot tudi njihovo medsebojno povezanost, v kar je potrebno vnesti nek red, če želimo učinkovit IS;  podatke moramo znati torej predstaviti na ustrezen način; zato so se razvili koncepti predstavitve (npr. entiteta, atribut) ter tudi podatkovni modeli, ki te koncepte na ustrezen način povezujejo. 6.1.2 Opredelitev (definicija) podatkovnega modela Predno nadaljujemo, si poglejmo, kaj podatkovni model sploh je. Podatkovni model je zbirka konceptov, s katerimi skušamo izraziti statične in dinamične lastnosti podatkov v okviru informacijskega sistema. Podatkovni model torej vsebuje koncepte predstavitve (ki jih bomo podrobneje opredelili v nadaljevanju), ki so med sabo povezani. Same lastnosti konceptov kot tudi povezav med njimi pa izražajo lastnosti podatkov, ki jih IS obdeluje. Te lastnosti so:  statične – gre za osnovne lastnosti podatkov, ki se ne spreminjajo, npr. študenta lahko opišemo s podatki vpisna številka, priimek, ime, datum rojstva, ki predstavljajo osnovne lastnosti študenta; in  dinamične – to so lastnosti, ki se spreminjajo, kot so npr. vrednosti podatkov in operacije na podatkih. Na tem mestu si poglejmo še razliko med matičnimi in prometnimi podatki, ki je odvisna od tega, kako pogosto se spreminja vrednost podatka:  matični podatki so podatki, katerih vrednost se redko ali sploh ne spreminja, kot so npr. osnovni podatki o študentu (vpisna številka, priimek, ime) – ti podatki se za posameznega študenta načeloma vpišejo samo enkrat, in na njih potem ni več spreminjanja.  pri prometnih podatkih pa se njihova vrednost pogosto spreminja oz. se na njih opravi veliko transakcij; to so npr. podatki o prijavah in odjavah študentov – ti podatki se spreminjajo pogosto, lahko tudi večkrat na dan (ker se lahko prijavi/odjavi več študentov v enem dnevu tudi na različne izpitne roke). 6.1.3 Razvoj in vrste podatkovnih modelov Pri razvoju podatkovnih modelov ločimo tri obdobja (Kovačič & Vintar, 1994). V obdobju 1946–1970 obstajajo preprosti modeli za vzpostavitev datotečne organizacije podatkov – podatki so bili zapisani v več datotekah, kar je povzročilo podvajanje podatkov; npr. v eni datoteki so zapisani osnovni podatki o študentih, v drugi pa podatki o prijavah študentov – obe datoteki vsebujeta podatke vpisna številka, priimek, ime 82/136 Modeliranje podatkov Po letu 1970, ko se razvije koncept baze podatkov (vsak podatek je v bazi zapisan samo enkrat), se razvijejo tudi modeli za fizično zasnovo in izvedbo podatkovnih baz, t. i. izvedbeni modeli. Predstavniki izvedbenih modelov so17:  hierarhični model,  mrežni model,  relacijski model,  objektno orientirani modeli. Po letu 1975 se razvijejo semantični modeli;18 to so modeli, ki se uporabljajo predvsem v fazi načrtovanja logične zasnove IS, ker so ugotovili, da izvedbeni modeli niso primerni za začetne faze razvoja IS. Gre torej za modele za logično predstavitev podatkov poslovnega sistema, katerih predstavniki so:  E-R model (entity-relationship) – model entiteta-povezava,  v okviru objektnega pristopa pa diagram razredov in objektov. Zgodovinsko gledano, so se torej najprej razvili izvedbeni in šele kasneje semantični podatkovni modeli; če pa gledamo faze razvoja IS, pa se najprej uporabi semantične modele in nato izvedbene. V fazi fizične zasnove moramo semantični model, razvit v fazi logične zasnove, preoblikovati v enega od izvedbenih podatkovnih modelov. 6.2 Koncepti abstrakcije pri modeliranju podatkov Podatkovni modeli slonijo na konceptih abstrakcije, ki izražajo predvsem povezave med podatki. Kaj pa abstrakcija sploh je? V splošnem lahko rečemo: Abstrakcija je način razmišljanja oz. reševanja problemov, kjer zavestno odmislimo podrobnosti in se osredotočimo na skupne, splošne lastnosti predmetov, oseb in pojmov, ki jih proučujemo. Pri modeliranju podatkov poznamo 4 koncepte abstrakcije (Kovačič & Vintar, 1994), od katerih bomo spoznali glavne tri:  klasifikacija (razvrščanje)  generalizacija (posplošitev)  agregacija (sestavljanje) Preden pa si pogledamo posameznega, pa na kratko opredelimo še dva koncepta modeliranja podatkov, ki ju potrebujemo pri opredelitvi konceptov abstrakcije in seveda v nadaljevanju pri samem oblikovanju podatkovnega modela. O konceptih modeliranja bomo podrobneje spregovorili v 8. poglavju. Entiteta je poljuben objekt, subjekt ali pojem, ki nastopa v obravnavanem poslovnem sistemu in je s podatkovnega vidika pomemben za poslovni sistem. Entiteta je nekaj, o čemer zbiramo podatke in se tvorijo podatkovne zbirke. Posamezen podatek (npr. rojstni datum) ni entiteta. Je pa v okviru poslovnega sistema Fakulteta za upravo entiteta npr. ŠTUDENT – gre za subjekt, ki je (s podatkovnega vidika) pomemben za omenjen poslovni sistem. Atribut je opisna lastnost entitete. 17 Podrobneje bomo izvedbene podatkovne modele obravnavali v 9. poglavju. 18 Semantika = veda o pomenu 83/136 Modeliranje podatkov Ko entiteti določamo atribute, se vprašamo, s katerimi podatki bi opisali njene lastnosti; npr. o študentu zbiramo naslednje podatke: vpisna številka, priimek, ime, datum rojstva, letnik študija – ti podatki opisujejo študenta, torej so to atributi entitete ŠTUDENT. Sedaj pa si podrobneje poglejmo zgoraj naštete koncepte abstrakcije pri modeliranju podatkov. 6.2.1 Klasifikacija Množico primerkov entitet (objektov), ki imajo neko skupno lastnost, klasificiramo (razvrstimo) v tip entitete (razred), ki odraža to skupno lastnost. Pri gornji opredelitvi je pomembno, da pri primerkih spoznamo neko skupno lastnost in jih glede na to lastnost razvrstimo v tip entitete. Na spodnji sliki (Slika 33) sta Irena in Miha osebi realnega sveta – sta torej entiteti. Ko modeliramo, sta vsak predstavljena z ustreznim primerkom entitete. Zanju ugotovimo skupno lastnost, namreč, da študirata (o njiju tudi zbiramo enake podatke, v našem primeru priimek in ime), zato ju v okviru modela klasificiramo razvrstimo v tip entitete ŠTUDENT, ki mu pripišemo tudi ustrezna atributa: priimek, ime. Pri tem smo torej uporabili klasifikacijo. Slika 33: Primer klasifikacije Klasifikacija je osnovni koncept abstrakcije, na katerem temelji večina podatkovnih modelov in vpeljuje razmerje 'primerek-iz' med primerkom in tipom entitete (Slika 34). Zanimivo je, da lahko iste primerke po neki drugi lastnosti razvrstimo v drug tip entitete. Npr., da za Ireno, Miho in Jana ugotovimo, da se vsi trije ukvarjajo z atletiko; v tem primeru te tri primerke razvrstimo v tip entitete ATLET (jim pripišemo drug tip entitete). Klasifikacijo lahko na grafični način predstavimo na naslednji način (Slika 34). Pri tem je tip entitete (ŠTUDENT) obarvan rdeče, primerki entitet pa sivo. Osebe iz realnega sveta so torej v modelu prikazani kot primerki entitete. 84/136 Modeliranje podatkov Slika 34: Grafični prikaz klasifikacije Še pripomba o uporabi izrazov entiteta, primerek entitete in tip entitete. V praksi se izraz entiteta nanaša na tip entitete in ga bomo tudi mi tako razumeli v nadaljevanju. 6.2.2 Generalizacija Tipom s skupnimi lastnostmi (atributi) priredimo posplošeni (generalizirani) tip na višjem nivoju, ki ima te skupne lastnosti (atribute). Generalizacija vpeljuje razmerje 'je' med osnovnim in splošnim tipom (Slika 35; rdeče obarvani so tipi entitet, modro pa njihove lastnosti – atributi). Gre torej za razmerje med tipi entitet, zato lahko rečemo, da je na višjem nivoju kot klasifikacija (kjer gre za razmerje med primerki in tipom). Slika 35: Grafični prikaz generalizacije Tu je torej pomembno, da ugotovimo, da o različnih tipih entitet zbiramo enake podatke, zato določimo posplošeni tip, ki vsebuje te skupne podatke. V gornjem primeru (Slika 35) smo ugotovili, da pri vsakem od tipov entitet ZAPOSLEN, ŠTUDENT in UPOKOJENEC (so osnovni tipi) zbiramo podatke EMŠO, priimek, ime in naslov (imajo torej te štiri skupne lastnosti). Zato tem osnovnim tipom priredimo posplošen tip OBČAN, ki ima te skupne lastnosti (atribute). Pri generalizaciji velja pravilo dedovanja, ki pravi, da osnovni tipi podedujejo lastnosti splošnega tipa. V gornjem primeru torej tipi ZAPOSLEN, ŠTUDENT in UPOKOJENEC podedujejo lastnosti (atribute) EMŠO, priimek, ime, naslov – torej tudi pri teh osnovnih tipih zbiramo omenjene podatke. Poleg tega pa ima lahko vsak osnovni tip opredeljene še svoje lastnosti (atribute). Tako ima npr. ZAPOSLEN še dva atributa organizacija in leto zaposlitve, ki ju preostala dva osnovna atributa nimata, saj nas pri njiju ne zanimata. Podobno velja za atribute pri tipih ŠTUDENT in UPOKOJENEC. 85/136 Modeliranje podatkov 6.2.3 Agregacija Pri agregaciji poznamo dve vrsti: kartezična agregacija in agregacija na ravni tipov. Pri kartezični agregaciji je tip predstavljen kot agregat svojih lastnosti: tip je torej sestavljen iz svojih lastnosti oz. tip je sestavljen iz atributov. Pri agregaciji na ravni tipov pa je tip na višji ravni predstavljen kot agregat tipov na nižji ravni (svojih sestavnih delov) oz. tip je sestavljen iz drugih tipov. Za kartezično lahko tudi rečemo, da atributi sestavljajo tip entitete, pri agregaciji na ravni tipov pa, da osnovni tipi sestavljajo sestavljen tip na višjem nivoju. Agregacija vpeljuje razmerje 'je-del' :  med atributi in tipom entitete pri kartezični agregaciji (Slika 36), oz.  med tipi entitet pri agregaciji na ravni tipov(Slika 37). Slika 36: Primer kartezične agregacije Slika 37: Primer agregacije na ravni tipov Agregacija na ravni tipov lahko poteka v več ravneh – v tem primeru prikazuje hierarhično strukturo sestavljenega tipa (Slika 37). Za kartezično agregacijo pa velja, da na njej temelji večina podatkovnih modelov, saj moramo vedeti, s katerimi podatki opisujemo lastnosti tipov entitet – poznati moramo torej njihove atribute. 86/136 Modeliranje podatkov Seveda pa lahko koncepte abstrakcije tudi medsebojno povezujemo. Slika 35 prikazuje povezovanje koncepta generalizacije (med osnovnimi in splošnim tipom) in kartezične agregacije (med tipi in njihovimi atributi), Slika 38 pa povezovanje koncepta generalizacije in agregacije na ravni tipov. Slika 38: Povezovanje konceptov generalizacije in agregacije na ravni tipov Viri in literatura Kovačič, A. & Vintar, M. (1994). Načrtovanje in gradnja informacijskih sistemov. Ljubljana: DZS. 87/136 Modeliranje podatkov Kaj moram vedeti?  Podatkovni model  Semantični podatkovni modeli  Izvedbeni podatkovni modeli  Abstrakcija  Koncepti abstrakcije  Entiteta, primerek, tip  Klasifikacija  Generalizacija  Agregacija  Primerjava klasifikacija : generalizacija 88/136 7. poglavje: Model entiteta-povezava (E-R model) V tem poglavju se bomo osredotočili na model entiteta-povezava (E-R model, tudi entitetno-relacijski model). Model je še danes široko razširjen za predstavitev podatkovnega pogleda v logični zasnovi informacijskega sistema oz. njegove podatkovne baze – gre torej za semantični podatkovni model. Kot tak je zelo pomemben za razumevanje podatkov in podatkovnih struktur ter njihovih lastnosti in je osnova za razvoj podatkovne baze, ki mora zagotavljati, da bo izgrajen IS dostopal do pravih podatkov na pravi način. V poglavju bomo najprej opisali nekaj osnovnih značilnosti E-R modela, v nadaljevanju pa podrobno spoznali osnovne koncepte E-R modela in njihove lastnosti. Vsebina poglavja 7.1 Osnovno o E-R modelu ................................................................................................................... 90 7.2 Osnovni koncepti E-R modela ........................................................................................................ 90 7.2.1 Entiteta .............................................................................................................................. 90 7.2.2 Atribut ................................................................................................................................ 90 7.2.2.1 Osnovne značilnosti atributa ......................................................................................... 90 7.2.2.2 Vrste atributov ............................................................................................................... 91 7.2.2.3 Ključni atributi ................................................................................................................ 92 7.2.3 Povezava ............................................................................................................................ 93 7.2.3.1 Osnovno o povezavah .................................................................................................... 93 7.2.3.2 Lastnosti povezav ........................................................................................................... 93 7.2.3.3 Rekurzivna povezava ...................................................................................................... 96 7.3 Notacija E-R diagrama .................................................................................................................... 96 7.4 Omejitve E-R modela ..................................................................................................................... 97 Viri in literatura ...................................................................................................................................... 97 89/136 Model entiteta-povezava (E-R model) 7.1 Osnovno o E-R modelu E-R model je namenjen modeliranju podatkovnega pogleda na poslovni sistem. Je semantični podatkovni model, ki ga uporabljamo predvsem v fazi logične zasnove IS oziroma njegove podatkovne baze. Nastal je po letu 1975, ko so razvijalci ugotovili, da izvedbeni podatkovni modeli niso primerni na zgodnejše faze razvoja IS. Sestavljen je iz 2 delov:  grafični: E-R diagram, ki je grafični formaliziran prikaz informacijskih potreb – prikazani so tipi entitet in vsebinske povezave med njimi;  opisni: podatkovni slovarji, v katerih podrobneje opišemo lastnosti entitet, atributov in povezav. Opisni del potrebujemo zato, ker iz E-R diagrama niso razvidne lastnosti entitet in atributov, kar pa je bistveno za podatkovni model, da ga lahko v fizični zasnovi preoblikujemo v ustrezno podatkovno bazo. 7.2 Osnovni koncepti E-R modela Osnovni koncepti modeliranja v E-R modelu so:  entiteta  atribut  povezava. V nadaljevanju so bomo vsakega pogledali podrobneje. 7.2.1 Entiteta Na kratko smo o njej spregovorili že v 6. poglavju. Pa ponovimo: Entiteta je poljuben objekt, subjekt ali pojem, ki nastopa v obravnavanem poslovnem sistemu in je s podatkovnega vidika pomemben za poslovni sistem. Še enkrat podarimo dvoje:  o entitetah zbiramo podatke – na podlagi tega o entitetah oblikujemo podatkovne zbirke;  ločimo tip in primerek entitete ob upoštevanju koncepta klasifikacije (glej poglavje 6.2.1); v nadaljevanju bomo uporabljali izraz entiteta kot sopomenko za tip entitete. Primeri entitet:  V poslovnem sistemu trgovine so tipične entitete: ARTIKEL, KUPEC, DOBAVNICA, RAČUN itd. O tem mora poslovni sistem trgovine zbirati podatke, da lahko trgovina posluje.  V poslovnem sistemu fakultete, pa so entitete: ŠTUDENT, ŠTUDIJSKI PROGRAM, PEDAGOG, ŠTUDIJSKA OBVEZNOST itd. O tem se zbirajo podatki. 7.2.2 Atribut 7.2.2.1 Osnovne značilnosti atributa Atribut je opisna lastnost tipa entitete. Atributi torej opisujejo lastnosti entitete. Ko se sprašujemo, katere atribute bi dodelili entiteti, se sprašujemo, s katerimi podatki bi jo opisali. 90/136 Model entiteta-povezava (E-R model) Pri atributih sta pomembni še vrednost atributa in domena oz. zaloga vrednosti. Vrednost atributa je vrednost, ki jo določen atribut tipa entitete zavzame pri določenem primerku entitete. Zaloga vrednosti ali domena je množica vseh vrednosti, ki jih atribut lahko zavzame pri določenem tipu entitete. Primeri:  atribut: spol za entiteto ŠTUDENT,  vrednost atributa: ženski za atribut spol,  zaloga vrednosti (domena): {moški, ženski} za atribut spol ( vtem primeru je zaloga množica, ki ima samo dva elementa – atribut spol lahko zavzame samo eno od teh dveh možnosti); zalogo vrednosti za atribut priimek pri entiteti ŠTUDENT pa predstavljajo priimki vseh študentov. Slika 39: Tip entitete – primerek entitete – atribut – vrednost atributa 7.2.2.2 Vrste atributov Glede na sestavljenost atributa ločimo:  elementarni – ki jih nočemo ali ne moremo razstaviti na manjše celote (npr. priimek), in  sestavljeni – uporabljamo ga lahko ali kot celoto ali pa le njegove sestavne dele (npr. naslov, Slika 40). Slika 40: Primer sestavljenega atributa Glede na to, koliko vrednosti lahko atribut zavzame pri posameznem primerku entitete, pa ločimo:  enovrednosti – zavzamejo pri posameznem primerku entitete natančno eno vrednost (npr. rojstni datum – isti občan ima samo en rojstni datum, in  večvrednostni, ki lahko zavzamejo pri posameznem primerku entitete poljubno število vrednosti (npr. poklic – isti občan ima lahko več poklicev). 91/136 Model entiteta-povezava (E-R model) 7.2.2.3 Ključni atributi Posebna vrsta atributov so ključni atributi (ključi) – to so atributi, ki imajo pri določenem tipu entitete neko posebno vlogo – bodisi enolično opredeljujejo tip entitete, pomagajo pri iskanju primerkov ali pa omogočajo povezave med tipi entitet. Poznamo 3 vrste ključnih atributov:  primarni (glavni) ključ  sekundarni (pomožni) ključ  tuji (zunanji) ključ. Poleg tega poznamo še posebno obliko ključev – to so speti ali sestavljeni ključi, ki pa so lahko katerikoli od gornjih treh. Primarni ključ (PK) Vloga PK je, da omogoči enolično identifikacijo primerkov določenega tipa entitete; to pomeni:  različna primerka istega tipa entitete NE SMETA imeti enake vrednosti primarnega ključa  če iščemo s PK, dobimo največ en zadetek  če poznamo vrednost PK, vemo točno, za kateri primerek gre (dobimo vrednosti vseh ostalih atributov tega primerka) PK je najpomembnejši atribut tipa entitete in omogoča zelo hitro iskanje določenega primerka entitete. Zaželeno je, da je kratek. Vsak tip entitete ima natanko en primarni ključ (torej samo en od atributov ima vlogo primarnega ključa in moramo imeti primarni ključ). Če imamo med atributi več kandidatov za PK, izberemo kot PK tistega, po katerem pogosteje iščemo. Če med atributi ni nobenega kandidata za PK, lahko:  oblikujemo speti ključ, ALI pa  vpeljemo nov (umeten) atribut, katerega vrednosti določamo tako, da zagotavlja enolično identifikacijo. Primeri:  EMŠO# pri tipu entitete OBČAN,  davčna številka# pri tipu entitete PODJETJE. Običajno so kandidati za primarni ključ atributi kot so šifra, matična številka, ID številka19 ipd. Sekundarni ključ Njegova vloga je iskanje primerkov entitet. Če ne poznamo vrednosti primarnega ključa, si pomagamo z iskanjem po sekundarnem ključu, pri čemer velja:  lahko dobimo več primerkov (ki imajo enako vrednost sekundarnega ključa; npr. če iščemo s priimkom študenta, lahko dobimo več študentov, ki imajo enak priimek),  zoži nabor za iskanje. Posamezen tip entitete ima lahko poljubno število sekundarnih ključev (več atributov, ki so namenjeni iskanju) – lahko nobenega, lahko pa več. 19 identifikacijska številka 92/136 Model entiteta-povezava (E-R model) Primeri  datum računa pri tipu entitet RAČUN,  priimek in ime študenta pri tipu entitete ŠTUDENT,  naziv predmeta pri tipu entitete ŠTUDIJSKI PREDMET. Običajno so kandidati za sekundarni ključ atributi kot so naziv, priimek + ime, datum ipd. Tuji ključ Njegova vloga je, da fizično (s pomočjo atributov) vzpostavi povezave med tipi entitet. Po definiciji je tuji ključ primarni ključ povezane entitete. Vpeljava tujih ključev je odvisna izključno od povezav med entitetami (več v poglavju 8). Speti ključ Je ključ, ki je sestavljen iz več atributov – med atribute, ki sestavljajo speti ključ, postavimo znak +. Lahko je:  primarni (če moramo speti več atributov, da zagotovimo enolično identifikacijo); primer številka računa + šifra artikla# za tip entitete KUPLJEN ARTIKEL  sekundarni (spnemo več atributov za hitrejše iskanje); primer priimek študenta + ime študenta za tip entitete ŠTUDENT 7.2.3 Povezava 7.2.3.1 Osnovno o povezavah Povezava opredeljuje vsebinski odnos med tipi entitet v podatkovnem modelu Tudi pri povezavah ločimo med tipom in primerkom – tip povezave je množica vseh primerkov povezav med primerki entitet. 7.2.3.2 Lastnosti povezav Ime povezave Opredeljuje vsebinski odnos med povezanimi tipi entitet – ime pove, zakaj tipe entitet s to povezavo povežemo. Stopnja povezave Pove število tipov entitet, ki sodelujejo v tipu povezave; torej koliko tipov entitet povezava povezuje. Najbolj običajna je povezava stopnje 2 (binarna povezava); na spodnjem primeru (Slika 41) povezava 'dela-za' povezuje 2 tipa entitet (ZAPOSLEN in ODDELEK). Slika 41: Primer binarne povezave Povezava stopnje 3 (ternarna povezava), ki povezuje 3 tipe entitet; na spodnjem primeru (Slika 42) povezava 'dobava' povezuje 3 tipe entitet (DOBAVITELJ, SESTAVNI DEL in PROJEKT). 93/136 Model entiteta-povezava (E-R model) Slika 42: Primer ternarne povezave Tip in primerki povezav Poglejmo si razliko med tipi in primerki povezav na primeru binarne povezave (Slika 43). Imamo tip entitete ZAPOSLEN, ki ima 6 primerkov, ter tip entitete ODDELEK, ki ima 3 primerke. Tip povezave 'del-za' povezuje omenjena tipa entitet (ZAPOSLEN in ODDELEK). Ko posamezen primerek iz ZAPOSLENEGA povežemo s posameznim primerkom iz ODDELKA, dobimo primerek povezave; npr. p1 povezuje primerek Janez (iz ZAPOSLENEGA) s primerkom Prodaja (iz ODDELKA). Ko zberem vse primerke povezav, dejansko dobimo tip povezave. Slika 43: Tipi in primerki povezav Kardinalnost (števnost) povezave Pove, koliko primerkov tipa entitete lahko sodeluje v posameznem tipu povezave oz. koliko primerkov ene entitete je lahko povezanih z istim primerkom druge entitete. Kardinalnost določamo pri vsaki od povezanih entitet (na vsaki strani povezave). Tako pridemo do naslednji razmerij kardinalnosti (Slika 44; prečna črtica prikazuje kardinalnost 1 (ena), 'kurje tace' pa kardinalnost M (mnogo)):  1 : 1 (ena : ena) isti primerek entitete ŠTUDENT je povezan samo z enim primerkom entitete E-IDENTITETA (in obratno)  1 : M (ena : mnogo) isti primerek entitete OBČAN je lahko povezan z več primerki entitete VOZILO, isti primerek iz VOZILA pa samo z enim primerkom iz OBČANA  M : N (mnogo : mnogo) isti primerek entitete DELAVEC je lahko povezan z več primerki entitete PROJEKT (in obratno) 94/136 Model entiteta-povezava (E-R model) Slika 44: Primeri kardinalnosti povezave Obveznost povezave Pove, ali v tipu povezave obvezno nastopa en primerek povezanega tipa entitete ali ne. Tudi obveznost povezave določimo pri vsaki od povezanih entitet (na vsaki strani povezave). Tako pridemo do naslednjih razmerjih med obveznostmi (Slika 45; prečna črtica prikazuje obvezno povezavo, krogec pa neobvezno):  o : o (obvezno : obvezno) primerek entitete ŠTUDENT je obvezno povezan s primerkom iz entitete E-IDENTITETA (in obratno)  n : n (neobvezno : neobvezno) primerek entitete OBČAN je lahko (NI obvezno) povezan s primerkom entitete VOZILO (in obratno)  o : n (obvezno : neobvezno) primerek entitete DELAVEC je lahko (Ni obvezno) povezan s primerkom entitete PROJEKT, primerek entitete PROJEKT je obvezno povezan s primerkom entitete DELAVEC Slika 45: Primeri obveznosti povezave Ko kardinalnost in obveznost združimo, dobimo različne kombinacije (glej Slika 46; z modro je označena kardinalnost, z rdečo pa obveznost). 95/136 Model entiteta-povezava (E-R model) Slika 46: Kardinalnost in obveznost povezav 7.2.3.3 Rekurzivna povezava Povezava je rekurzivna 20, kadar isti tip entitete nastopa v povezavi v različnih vlogah (na obeh straneh povezave je isti tip entitete). Slika 47 prikazuje rekurzivno povezavo 'nadzira'; na obeh straneh je isti tip entitete ZAPOSLEN, ki pa ima na različnih straneh različno vlogo: nadrejen in podrejen. Pri tem velja:  isti nadrejeni nadzira več podrejenih,  istega podrejenega nadzira samo en nadrejeni,  vsi pa so zaposleni (torej primerki istega tipa entitete ZAPOSLEN). Slika 47: Primer rekurzivne povezave 7.3 Notacija E-R diagrama Ko rišemo E-R diagram, se držimo določenih pravil, kako prikažemo posamezen koncept (Slika 48). Slika 48: Notacija E-R diagrama Entiteto (dejansko je tip entitete) narišemo kot pravokotnik, v katerega zapišemo ime entitete – ime je vedno samostalnik v ednini in odraža, o kom ali o čem v tej entiteti zbiramo podatke. 20 Rekurziven = nanašajoč se sam nase 96/136 Model entiteta-povezava (E-R model) Povezavo (dejansko je tip povezave) narišemo kot črto, ki povezuje dve entiteti – na sliki je to povezava (črta) med entitetama ŠTUDENT in ŠTUDIJSKI PROGRAM. Določimo ime povezave (ki odraža vsebinski odnos med povezanima entitetama – zakaj sta ti dve entiteti s podatkovnega vidika povezani); ime na sliki prikazane povezave je 'je-vpisan' (torej študent je vpisan na študijski program). Na povezavi označimo še obveznost in kardinalnost pri vsaki od povezanih entitet (na vsaki strani povezave):  oznaka za kardinalnost (prečna črtica oz. 'kurje tace') je tista, ki je bliže entiteti; na sliki je torej pri entiteti ŠTUDENT kardinalnost mnogo (ker je na istem programu lahko vpisanih več študentov), pri entiteti ŠTUDIJSKI PROGRAM pa je kardinalnost 1 (ker je isti študent lahko vpisan samo na en študijski program);  oznaka za obveznost (prečna črtica oz. krogec) je poleg oznake za kardinalnost; na sliki je torej pri entiteti ŠTUDENT povezava neobvezna (ker na programu lahko ni vpisanega nobenega študenta), pri entiteti ŠTUDIJSKI PROGRAM pa je povezava obvezna (študent mora biti vpisan na študijski program, drugače vsebinsko gledano ni študent). Ko torej označujemo kardinalnost in obveznost pri posamezni entiteti, lahko dobimo 4 možne kombinacije (Slika 49). Slika 49: Kardinalnost in obveznost povezav (Martinova notacija) 7.4 Omejitve E-R modela E-R model, ima nekaj omejitev, ki jih moramo upoštevati pri njegovem oblikovanju:  vsak atribut obravnava kot enostavnega (po naravi sestavljene atribute moramo razstaviti na njegove osnovne atribute)  neposredno ne dovoljuje večvrednostnih atributov (po naravi večvrednostne atribute moramo izločiti v svojo entiteto)  povezav višjih stopenj kot 2 ne moremo prikazati neposredno  ne omogoča neposrednega prikaza generalizacije in s tem povezanega pravila dedovanja. Viri in literatura Kovačič, A. & Vintar, M. (1994). Načrtovanje in gradnja informacijskih sistemov. Ljubljana: DZS. 97/136 Model entiteta-povezava (E-R model) Kaj moram vedeti?  Model entiteta-povezava (E-R model): kaj je, njegove omejitve  Sestava E-R modela  Koncepti E-R modela: entiteta, atribut, povezava  Vrednost in domena atributa  Vrste atributov  Ključni atributi – ključi  Povezava  Lastnosti povezav  Rekurzivna povezava  Notacija E-R diagrama 98/136 8. poglavje: Razvoj in dokumentiranje E-R modela Če smo v prejšnjem poglavju E-R model spoznali bolj s teoretičnega vidika, pa bomo v tem poglavju na konkretnem primeru podrobneje spoznali, kako razvijemo E-R model in ga dokumentiramo. Tako bomo najprej pogledali glavne korake pri razvoju E-R modela. E-R model je vedno sestavljen iz E-R diagrama in podatkovnih slovarjev, čeprav marsikdo misli, da je samo E-R diagram tudi že E-R model. Zato je osrednji del poglavja namenjen risanju E-R diagrama na konkretnem primeru in izdelavi pripadajočih podatkovnih slovarjev – torej izdelavi E-R modela v celoti. Vsebina poglavja 8.1 Koraki pri razvoju E-R modela ...................................................................................................... 100 8.2 Risanje E-R diagrama .................................................................................................................... 100 8.3 Dokumentiranje E-R modela ........................................................................................................ 103 8.3.1 Slovar entitet ................................................................................................................... 103 8.3.1.1 Vpeljava (vgradnja) tujih ključev .................................................................................. 104 8.3.1.2 Vpeljava presečne entitete .......................................................................................... 104 8.3.1.3 Izdelava slovarja entitet ............................................................................................... 105 8.3.2 Slovar atributov................................................................................................................ 107 Viri in literatura .................................................................................................................................... 109 99/136 Razvoj in dokumentiranje E-R modela 8.1 Koraki pri razvoju E-R modela Razvoj E-R modela poteka v naslednjih korakih: 1. analiza informacijskih potreb (glej poglavje 4.2) v fazi analize sistema, 2. v fazi logične zasnove najprej na podlagi analize informacijskih potreb identificiramo tipe entitet – izdelamo seznam entitet, 3. nato opredelimo razmerja (odnose) med entitetami, 4. sledi risanje E-R diagrama, kjer seveda tudi opredelimo lastnosti povezav (ime, kardinalnost in obveznost), 5. nazadnje E-R model še dokumentiramo – izdelamo podatkovne slovarje. 3. in 4. korak v praksi velikokrat delamo vzporedno, saj z risanjem povezav v E-R diagramu dejansko opredeljujemo razmerja med entitetami. 8.2 Risanje E-R diagrama E-R diagram predstavlja grafični del E-R modela, s katerim prikažemo entitete in povezave med njimi. Podrobneje bomo 1. in 2. korak obravnavali na vajah, na tem mestu pa si poglejmo razvoj E-R diagrama na primeru poenostavljenega IS za prijavljanje/odjavljanje na izpitni rok. Začnimo z že izdelanim seznamom entitet (Tabela 13). Tabela 13: Seznam entitet za prijavljanje/odjavljanje na izpitni rok entiteta opis entitete atributi ŠTUDIJSKI Osnovni podatki o šifra študijskega programa, naziv študijskega programa, PROGRAM študijskih programih kratica študijskega programa PREDMET Osnovni podatki o naziv predmeta, kratica predmeta, letnik predmeta študijskih predmetih IZPITNI ROK Podatki o izpitnih rokih datum roka, ura roka, čas trajanja, način študija za rok ŠTUDENT Osnovni podatki o vpisna številka, priimek študenta, ime študenta, način študentih študija, letnik študija, e-naslov študenta PRIJAVA Podatki o prijavah na datum prijave, ura prijave izpitni rok ODJAVA Podatki o odjavah – datum odjave, ura odjave preklicih prijav Ta seznam je izhodišče za 3. in 4. korak (opredelitev razmerij med entitetami, risanje E-R diagrama). Vzemimo entiteti ŠTUDIJSKI PROGRAM in PREDMET. Vprašamo se, ali obstaja nek vsebinski, podatkovni odnos med tema dvema entitetama. Ugotovimo, da je predmet del študijskega programa, torej bomo morali na E-R diagramu ti dve entiteti povezati in povezavo lahko tudi že poimenujemo ('je del'). 100/136 Razvoj in dokumentiranje E-R modela ŠTUDIJSKI PROGRAM je del PREDMET Sedaj pa opredelimo kardinalnost in obveznost te povezave. Torej se vprašamo: Isti predmet je lahko na koliko programih? Ugotovimo, da na enem samem, zato je kardinalnost pri ŠTUDIJSKI PREDMET 1 (prečna črtica). Kaj pa kardinalnost pri predmetu? tu se vprašamo: Na istem študijskem programu je lahko koliko predmetov? Ugotovimo seveda, da jih je lahko več, zato je kardinalnost pri PREDMET mnogo oz. več ('kurje tace'). ŠTUDIJSKI PROGRAM je del PREDMET Sedaj pa moramo določiti še obveznost povezave (seveda pri vsaki od povezanih entitet). Vprašamo se: Ali mora biti predmet obvezno na programu? Odgovor je seveda 'da' (predmet sam po sebi ne more obstajati, vedno je vezan na študijski program). Zato je povezava pri ŠTUDIJSKI PREDMET obvezna (prečna črtica). Kaj pa pri PREDMET? Vprašamo se: Ali ima program obvezno vsaj en predmet? Tudi tu je odgovor 'da' – povezava pri PREDMET je obvezna. ŠTUDIJSKI PROGRAM je del PREDMET Tako, uspešno smo narisali en del E-R diagrama. Sedaj temu diagramu dodajmo še entiteto IZPITNI ROK. S katero entiteto bi ga pa povezali, da bo povezava vsebinsko/podatkovno pomemba? Rok je razpisan za predmet (je celo odvisen od njega), zato 101/136 Razvoj in dokumentiranje E-R modela seveda povežemo IZPITNI ROK in PREDMET in povezavo poimenujemo 'razpisan za'. Sledi določanje kardinalnosti in obveznosti. Kardinalnost – Isti rok je za koliko predmetov? Seveda za enega samega, zato je kardinalnost pri PREDMET 1. In še: Isti predmet ima lahko koliko rokov? Seveda jih ima lahko več, zato je kardinalnost pri IZPITNI ROK več. Kaj pa obveznost? Ali mora biti izpitni rok vsaj na enem predmetu? Seveda (roka brez predmeta ni) – zato je povezava pri PREDMET obvezna. Ali mora predmet obvezno imeti rok – ni nujno, saj je to lahko nek nov predmet, za katerega roka še nismo razpisali. Povezava je torej pri IZPITNI ROK neobvezna. ŠTUDIJSKI PROGRAM je del razpisan za IZPITNI ROK PREDMET Tako nadaljujemo in pridemo do končnega E-R diagrama (Slika 50). Slika 50: E-R diagram za prijavljanje/odjavljanje na izpitni rok ŠTUDIJSKI PROGRAM je del vpisan na razpisan za ŠTUDENT IZPITNI ROK PREDMET je za je na PRIJAVA velja za ODJAVA 102/136 Razvoj in dokumentiranje E-R modela 8.3 Dokumentiranje E-R modela E-R model dokumentiramo s podatkovnimi slovarji, ki predstavljajo opisni del E-R modela. E-R model torej vedno vsebuje dvoje: E-R diagram in podatkovne slovarje. Poznamo 3 podatkovne slovarje:  slovar entitet, v katerem opredelimo lastnosti entitet (atribute) in določimo ključne atribute;  slovar atributov, v katerem podrobneje opredelimo lastnosti atributov;  slovar povezav, ki opredeljuje lastnosti povezav. Lastnosti povezav so razvidne že iz E-R diagrama, zato ga v zadnjem času opuščamo. Iz E-R diagrama pa niso razvidne lastnosti entitet niti lastnosti atributov, zato sta slovarja entitet in atributov izrednega pomena za zasnovo in vzpostavitev podatkovne baze, ki jo bo uporabljal bodoči IS. 8.3.1 Slovar entitet Je v obliki tabele (Tabela 14). V prvem stolpcu je oznaka entitete v obliki E-ZaporednaŠtevilka. V drugem stolpcu je ime entitete (isto ime, ki smo ga za entiteto uporabili v E-R diagramu). V tretjem stolpcu pa navedemo vse atribute, ki opisujejo entiteto, in opredelimo ključne atribute (primarne, sekundarne in tuje ključe). Pazimo, da so imena atributov enolična (torej vsak atribut ima svoje enolično ime). Tabela 14: Shematski prikaz slovarja entitet Oznaka Ime entitete Atributi entitete E-01 isto ime, ki se uporablja v E-R modelu  imena so enolična  označimo ključe E-02 E-03 V slovarju entitet je vsak atribut zapisan samo enkrat, in sicer pri entiteti, ki jo logično opisuje. Edini atribut, ki so lahko večkrat zapisani, so tuji ključi, s katerimi vzpostavimo povezave med entitetami. Ključe označujemo na naslednji način:  primarni ključ#  sekundarni ključ  tuji ključ Na kratko ponovimo, kaj smo o ključnih atributih spoznali v 7. poglavju:  Primarni ključ omogoča enolično identifikacijo primerkov entitete:  dva različna primerka istega tipa entitete ne smeta imeti enake vrednosti primarnega ključa  vsak tip entitete ima natanko en primarni ključ  Sekundarni ključi so atributi, po katerih pogosto iščemo primerke entitet  tip entitete ima lahko poljubno število sekundarnih ključev  Tuji ključi: se uporabljajo za vzpostavljanje v E-R diagramu prikazanih povezav  število pri tipu entitete je odvisno izključno od povezav  Speti ključ nastopi v primeru, ko šele več atributov skupaj enolično določi primerek entitete ali omogoči iskanje primerkov 103/136 Razvoj in dokumentiranje E-R modela Najprej določimo primarne in sekundarne ključe. Nato pa vpeljemo še tuje ključe (tega ne moremo narediti, dokler nimamo opredeljenih primarnih ključev). 8.3.1.1 Vpeljava (vgradnja) tujih ključev Pri vpeljavi tujih ključev se moramo držati naslednjih pravil:  Tuj ključ (TK)je vedno primarni ključ povezane entitete.  Za vsako povezavo imamo natanko 1 TK – za vsako povezavo moramo imeti v eni od povezanih entitet ustrezen TK.  V katero od povezanih entitet pa TK vpeljemo, je odvisno od kardinalnosti povezav:  pri M : 1 in 1 : M povezavah je tuj ključ v tisti entiteti, kjer je kardinalnost povezave M,  pri 1 : 1 povezavah je tuj ključ samo v eni od povezanih entitet (običajno upoštevamo obveznost ali posledičnost),  pri M : N povezavah pa tujega ključa ne moremo neposredno vpeljati, ampak moramo povezavo razbiti na dve povezavi (1 : N in M : 1) z vpeljavo presečne entitete. 8.3.1.2 Vpeljava presečne entitete Tudi tu se moramo držati določenih pravil:  Ime presečne entitete običajno sestavimo iz imen osnovnih dveh entitet.  Za novi povezavi velja:  pri osnovnih entitetah je kardinalnost in obveznost povezave vedno 1o (ena obvezno),  pri presečni entiteti je kardinalnost povezave vedno M, obveznost pa se ravna po osnovni povezavi (ki jo nadomeščamo s presečno entiteto),  določimo ustrezno ime vsake povezave.  Primarni ključ presečne entitete je običajno speti ključ, sestavljen iz primarnih ključev osnovnih entitet.  Primer vpeljave presečne entitete prikazuje Slika 51. Slika 51: Primer vpeljave presečne entitete Kardinalnost povezave 'dela-na' med entitetama PROJEKT in DELAVEC je M : N (na obeh straneh 'kurje tace'), saj na istem projektu lahko dela več delavcev, hkrati pa isti delavec lahko dela na več projektih. To povezavo presekamo na 2 povezavi z vpeljavo presečne entitete, ki jo poimenujemo 104/136 Razvoj in dokumentiranje E-R modela PROJEKT/DELAVEC. Presečno entiteto povežemo z vsako od osnovnih dveh entitet; v našem primeru torej po eni strani z entiteto PROJEKT in po drugi strani z entiteto DELAVEC. Označimo še kardinalnosti in obveznosti pri teh dveh povezavah. Kot pravijo pravila vpeljave presečne entitete, je na strani osnovnih entitet povezava vedno 1 obvezno (zato dve prečni črtici), na strani presečne pa je kardinalnost več. kako pa je z obveznostmi pri presečni entiteti. Ker je osnovna povezava na strani delavca obvezna, je tudi povezava PROJEKT : PROJEKT/DELAVEC pri presečni obvezna; in ker je osnovna pri projektu neobvezna, je tudi povezava DELAVEC : PROJEKT/DELAVEC pri presečni entiteti neobvezna. Kaj pa imena povezav? Tudi tu si lahko pomagamo z imeni entitet. Povezava PROJEKT : PROJEKT/DELAVEC pove, kateri delavci delajo na projektu (za isti projekt imamo več delavcev), torej jo lahko poimenujemo 'delavci-na-projektu'. Podobno velja za povezavo DELAVEC : PROJEKT/DELAVEC, ki pove, na katerih projektih dela delavec, in jo zato poimenujemo 'projekti-za-delavca'. Na koncu poglejmo še primarne ključe (PK). Pri entiteti PROJEKT je PK šif-projekta#, pri DELAVEC pa matična-številka#. Primarni ključ presečne entitete pa je spet (sestavljen) iz teh dveh primarnih ključev: šif-projekta + matična-številka#. 8.3.1.3 Izdelava slovarja entitet Izdelavo slovarja entitet si bomo pogledali na primeru poenostavljenega E-R diagrama za prijavljanje/odjavljanje na izpitni rok (Slika 50) ter pripadajočega seznama entitet (Tabela 13). Določimo najprej primarne in sekundarne ključe. entiteta opis entitete atributi ŠTUDIJSKI Osnovni podatki o šifra študijskega programa, naziv študijskega programa, PROGRAM študijskih programih kratica študijskega programa Vzemimo prvo entiteto iz seznama entitet (glej zgoraj) in se vprašajmo, ali kateri od navedenih atributov omogoča 100% enolično identifikacijo (ma lahko vlogo primarnega ključa). Ugotovimo, da je to šifra predmeta, saj je določena tako, da ima vsak študijski program svojo šifro. Nazivi niso ustrezni primarni ključi. Torej je šifra študijskega programa primarni ključ, zato jo ustrezno označimo: šifra študijskega programa#. Pa še sekundarni ključi. Vprašajmo se, kateri atributi nam lahko pomagajo iskati določen študijski program, če ne poznamo vrednosti primarnega ključa (šifre). Prav gotovo je to naziv študijskega programa, lahko pa tudi njegova kratica. Oba omenjena atributa označimo kot sekundarni ključ. Poglejmo naslednjo entiteto PREDMET. entiteta opis entitete atributi PREDMET Osnovni podatki o naziv predmeta, kratica predmeta, letnik predmeta študijskih predmetih Kateri od navedenih atributov bi bil lahko primarni ključ? Ugotovimo, da noben: imamo lahko več predmetov z enakim nazivom (npr. na različnih programih), tudi kratica je nezanesljiva (ali je res določena tako, da ima vsak predmet enolično kratico?), letnik predmeta prav gotovo ne ustreza (imamo več predmetov v istem letniku). Za primarni ključ bi atribute lahko speli, vendar tudi če spnemo vse tri atribute, še ne zagotovimo enolične identifikacije. Zato vpeljemo nov (umeten) atribut, katerega vrednosti bomo določili tako, da bo imel vsak predmet svojo vrednost tega atributa. To je lahko npr. 105/136 Razvoj in dokumentiranje E-R modela šifra predmeta (lahko tudi ID predmeta). V tem primeru se odločimo za prvo možnost in dobimo primarni ključ: šifra predmeta#. Ta sekundarni ključ izberemo naziv predmeta. Nadaljujemo še za ostale entitete s seznama entitet (Tabela 13) in dobimo naslednji slovar entitet (Tabela 15), ki pa še ni popoln, saj manjkajo tuji ključi. Tabela 15: Nepopoln slovar entitet za prijavljanje/odjavljanje na izpitni rok Oznaka Ime entitete Atributi entitete E-01 ŠTUDIJSKI šifra študijskega programa#, naziv študijskega programa, kratica študijskega PROGRAM programa E-02 PREDMET šifra predmeta#, naziv predmeta, kratica predmeta, letnik predmeta E-03 IZPITNI ROK ID roka#, datum roka, ura roka, čas trajanja, način študija za rok E-04 ŠTUDENT vpisna številka#, priimek študenta + ime študenta, način študija, letnik študija, e-naslov študenta E-05 PRIJAVA zaporedna številka prijave#, datum prijave, ura prijave E-06 ODJAVA zaporedna številka odjave#, datum odjave, ura odjave Pri tem pazimo, da je primarni ključ vedno na prvem mestu med atributi (ima tako pomembno vlogo, da si to prav gotovo zasluži). Bodite pozorni na prvi sekundarni ključ pri študentu, kjer smo speli dva atributa – pomeni, da sta priimek študenta in ime študenta v osnovi ločena atributa, ki pa smo ju speli za potrebe iskanja (vedno spenjamo tako, da je najprej priimek in potem ime). Slovar entitet do konca izdelamo tako, da vpeljemo (vgradimo) še tuje ključe. Ker so tuji ključi odvisni izključno od povezav in je tuj ključ vedno primarni ključ povezane entitete, bosta osnova za vgradnjo tujih ključev E-R diagram (zaradi povezav; Slika 50) in nepopoln slovar entitet (zaradi primarnih ključev; Tabela 15). V E-R diagramu gremo od povezave do povezave in za vsako vpeljemo natanko en tuj ključ, pri čemer se držimo pravil, ki smo jih opisali v razdelku 8.3.1.1. Prva povezava je 'vpisan na' med entitetama ŠTUDENT in ŠTUDIJSKI PROGRAM. Pogledamo, kakšna je kardinalnost povezave: mnogo (več) pri študentu in 1 (ena) pri študijskem programu. Glede na pravila vgradnje tujega ključa, le-tega dodamo k entiteti, kjer je kardinalnost mnogo, v tem primeru torej k entiteti ŠTUDENT. Kaj pa bo tuj ključ? Je vedno primarni ključ povezane entitete. Povezana entiteta je v našem primeru ŠTUDIJSKI PROGRAM, njen primarni ključ pa šifra študijskega programa. Torej gre šifra študijskega programa kot tuj ključ v entiteto ŠTUDENT (tuj ključ je dvojno podčrtan). 106/136 Razvoj in dokumentiranje E-R modela Oznaka Ime entitete Atributi entitete E-01 ŠTUDIJSKI šifra študijskega programa#, naziv študijskega programa, kratica študijskega PROGRAM programa E-04 ŠTUDENT vpisna številka#, priimek študenta + ime študenta, način študija, letnik študija, e-naslov študenta, šifra študijskega programa Kaj pa povezava 'je del' med entitetama PREDMET in ŠTUDIJSKI PROGRAM? Zopet ugotovimo, da gre za kardinalnost mnogo : 1, zato je tuj ključ na strani mnogo (PREDMET) in je to primarni ključ entitete ŠTUDIJSKI PROGRAM. Torej gre šifra študijskega programa kot tuj ključ v entiteto PREDMET. Nadaljujemo z naslednjimi povezavami (ki so večinoma mnogo : 1) in pridemo do zadnje povezave 'velja za' med entitetama ODJAVA : PRIJAVA. Tu pa je kardinalnost 1 : 1. Tudi za take povezave moramo vpeljati tuj ključ (natanko enega), torej samo v eno od povezanih entitet. Načeloma je vseeno, v katero, če pa je povezava na eni strani obvezna, na drugi pa neobvezna, gre tuj ključ v entiteto, kjer je povezava neobvezna. Torej v našem primeru v entiteto ODJAVA damo primarni ključ entitete PRIJAVA kot tuj ključ. Oznaka Ime entitete Atributi entitete E-05 PRIJAVA zaporedna številka prijave#, datum prijave, ura prijave E-06 ODJAVA zaporedna številka odjave#, datum odjave, ura odjave, zaporedna številka prijave Ko torej vpeljemo tuje ključe za vse povezave, pridemo do končnega slovarja entitet (Tabela 16). Tabela 16: Slovar entitet za prijavljanje/odjavljanje na izpitni rok Oznaka Ime entitete Atributi entitete E-01 ŠTUDIJSKI šifra študijskega programa#, naziv študijskega programa, kratica študijskega PROGRAM programa E-02 PREDMET šifra predmeta#, naziv predmeta, kratica predmeta, letnik predmeta, šifra študijskega programa E-03 IZPITNI ROK ID roka#, datum roka, ura roka, čas trajanja, način študija za rok, šifra predmeta E-04 ŠTUDENT vpisna številka#, priimek študenta + ime študenta, način študija, letnik študija, e-naslov študenta, šifra študijskega programa E-05 PRIJAVA zaporedna številka prijave#, datum prijave, ura prijave, vpisna številka, ID roka E-06 ODJAVA zaporedna številka odjave#, datum odjave, ura odjave, zaporedna številka prijave Iz slovarja je razvidno, da je entiteta lahko brez tujega ključa (npr. ŠTUDIJSKI PROGRAM), lahko pa jih ima tudi več (npr. PRIJAVA). Še enkrat opozarjamo: tuji ključi so odvisni od povezav, saj z njimi 'fizično' (z atributi) vgradimo povezave, ki smo jih opredelili in narisali v E-R diagramu. 8.3.2 Slovar atributov Je v obliki tabele (Tabela 17). V prvem stolpcu je oznaka atributa, sledi ime atributa (ki je enako kot v slovarju entitet), sledi kratko ime s standardnimi okrajšavami. V četrtem stolpcu opredelimo tip atributa, 107/136 Razvoj in dokumentiranje E-R modela v naslednjem pa njegovo dolžino. V zadnjem stolpcu navedemo kakršnekoli omejitve, ki vplivajo na določanje vrednosti atributa. Tabela 17: Shematski prikaz slovarja atributov oznaka ime atributa standardno tip dolžina standardne atributa (daljši naziv) ime vrednosti A-0101 daljše opisno ime kratko ime s A koliko znakov nabor vrednosti, ki standardnimi AN zavzame jih atribut lahko okrajšavami N 8 zavzame D 4 T A-0102 Tu podajamo še dodatno razlago za nekatere lastnosti atributov, ki jih opredeljujemo v slovarju atributov:  Oznaka atributa: A-ŠtevilkaAtributa – številka je običajno sestavljena iz številke entitete (glej slovar entitet) in zaporedne številke atributa za entiteto.  Standardno ime: gre za skrajšano ime, kjer uporabljamo standardne okrajšave (v bazi podatkov ta imena uporabljamo za imena polj v datoteki ali tabeli); standardne okrajšave so npr.:  ŠIF za šifro  NAZ za naziv  ŠT za številko  ŠTEV za število  NASL za naslov  DAT za datum  IP za ime in priimek.  Tip: določa, kaj lahko nastopa kot vrednost atributa:  A (alfa) – znakovni niz, brez cifer (male in velike črke in nekateri posebni znaki (presledek, oklepaji ipd.))  N (numerični) – številčni podatek (poljubno realno število)  AN (alfa-numerični) – niz, sestavljen iz običajnih znakov in cifer  D (date) – datum  T (time) – čas (ura).  Dolžina: določa, koliko znakov lahko zavzame atribut:  pri numeričnih podatkih lahko podamo tudi število decimalnih mest (npr. dolžina 3,1 pomeni; tri mesta, od tega 1 decimalka, torej je največje število, ki ga lahko atribut s tako dolžino zavzame: 99,9)  datum ima vedno dolžino 8, čas pa običajno 4 (če zapisujemo tudi sekunde, pa dolžina 6).  Standardne vrednosti: vse dodatne omejitve in pogoji pri določanju vrednosti atributa (nekatere omejitve so podane že s tipom in dolžino atributa); npr. pri atributu spol bi bile standardne vrednosti lahko M (moški), Ž (ženski). Tabela 18 prikazuje izsek iz slovarja atributov (za prve 3 entitete). Kot je razvidno, standardne vrednosti ni potrebno opredeliti za vsak atribut, vse ostale lastnosti pa so obvezne. 108/136 Razvoj in dokumentiranje E-R modela Tabela 18: Izsek iz slovarja atributov za prijavljanje/odjavljanje na izpitni rok oznaka ime atributa standardno ime tip dolžina standardne vrednosti atributa atributa A-0101 šifra študijskega ŠIF-ŠP N 3 programa A-0102 naziv študijskega NAZ-ŠP AN 50 programa A-0103 kratica študijskega KRAT-ŠP AN 5 programa A-0201 šifra predmeta ŠIF-PR N 4 A-0202 naziv predmeta NAZ-PR AN 100 A-0203 kratica predmeta KRAT-PR AN 10 A-0204 letnik predmeta LT-PR N 1 1 – prvi 2 – drugi 3 – tretji A-0301 ID roka ID-ROK N 7 zaporedno številčenje A-0303 datum roka DAT-ROK D 8 A-0303 ura roka URA-ROK T 6 A-0304 čas trajanja TRAJ-ROK N 3 v minutah A-0305 način študija za rok NŠ-ROK A 1 R – redni I – izredni Viri in literatura Kovačič, A. & Vintar, M. (1994). Načrtovanje in gradnja informacijskih sistemov. Ljubljana: DZS. Kaj moram vedeti?  Koraki pri razvoju E-R modela  Sestava E-R modela 109/136 Razvoj in dokumentiranje E-R modela  Podatkovni slovarji  Določanje primarnih in sekundarnih ključev  Tuji ključ: namen, definicija, vpeljava (vgradnja)  Presečna entiteta: kaj je, kdaj in kako jo vpeljemo 110/136 9. poglavje: Izvedbeni podatkovni modeli Izvedbeni podatkovni modeli se začeli razvijati v želji, da bi z njihovo uporabo olajšali razvoj, izvedbo in uporabo večjih podatkovnih baz, ki so se začele uporabljati v začetku 70-tih let prejšnjega stoletja. Izvedbeni modeli so bili osredotočeni na opredelitev fizične strukture baze podatkov ter njegovo izvedbo v praksi. V tem prvem obdobju so se razvili trije karakteristični modeli. To so hierarhični, mrežni in relacijski model. Pogosto jih zaradi tega, ker spadajo v isto obdobje, imenujemo s skupnim imenom: klasični modeli. V 90-tih letih so začele nastajati nadgradnje teh modelov. Danes jih uvrščamo v skupino objektno-orientiranih modelov, ki pa konceptualno temeljijo na klasičnih modelih. Razlika je le v tem, da pri klasičnih modelih obravnavamo podatke in podatkovne strukture, osnovna sestavina objektno-orientiranih pristopov pa so objekti, ki združujejo podatke in pripadajoče postopke na teh podatkih. Iz navedenega lahko izluščimo naslednje vrste izvedbenih podatkovnih modelov: • klasični (hierarhični, mrežni, relacijski) • objektno-orientirani Ker objektno-orientirani modeli konceptualno temeljijo na klasičnih, bomo v tem poglavju obravnavali le-te. Vsebina poglavja 9.1 Hierarhični izvedbeni podatkovni model ..................................................................................... 112 9.1.1 Osnovne značilnosti hierarhičnega modela ..................................................................... 112 9.1.2 Prednosti in slabosti hierarhičnega modela ..................................................................... 113 9.2 Mrežni podatkovni model ............................................................................................................ 113 9.2.1 Osnovne značilnosti mrežnega modela ........................................................................... 113 9.2.2 Prednosti in slabosti mrežnega modela ........................................................................... 115 9.3 Relacijski podatkovni model ......................................................................................................... 115 9.3.1 Relacijska tabela............................................................................................................... 115 9.3.2 Osnovne značilnosti relacijskega modela ......................................................................... 116 9.3.3 Prednosti in slabosti relacijskega modela ........................................................................ 117 9.3.4 Primerjava med tremi klasičnimi izvedbenimi podatkovnimi modeli ............................... 117 Viri in literatura .................................................................................................................................... 118 111/136 Izvedbeni podatkovni modeli 9.1 Hierarhični izvedbeni podatkovni model Nastal je v začetku 70-ih let prejšnjega stoletja in sicer intuitivno (ni naslonjen na matematične teorije oz. formalizme). Razvil se je skozi praktične izkušnje, ki so kazale, da je poslovni svet, ki ga skušamo modelirati s pomočjo podatkovnih modelov, običajno urejen hierarhično, in je zelo praktično, če lahko te iste hierarhije, ki nastopajo v poslovnem svetu, v poslovnih IS, čim bolj neposredno preslikamo v naše podatkovne strukture, na osnovi katerih nastane ustrezna baza podatkov. 9.1.1 Osnovne značilnosti hierarhičnega modela Zanj je uporabljena temeljna drevesna oziroma hierarhična struktura (strukturni graf), ki smo jo srečali tudi že na nekaterih drugih področjih. Gre torej za strukturo narobe obrnjenega drevesa, kjer vozlišča predstavljajo zapise (skupek podatkovnih polj oz. podatkov), povezave med vozlišči pa seveda predstavljajo povezave med zapisi in hkrati opredeljujejo pot dostopa do posameznega zapisa (Slika 52). Slika 52: Hierarhična drevesna struktura Ta struktura je grajena na osnovi dveh temeljnih pravil:  Na najvišjem nivoju je en samo zapis – koren (ang. root);  Pravilo oče-sin: vsak zapis ima lahko samo en nadrejen zapis in poljubno število podrejenih (lahko tudi samo enega); podobno kot ima sin lahko le enega očeta, oče pa poljubno sinov. Kaj taka struktura pomeni? V tako podatkovno strukturo lahko vstopamo vedno le od vrha navzdol, skozi najvišje vozlišče, ki mu pravimo koren. Če želimo priti do podatkov v določenem zapisu (vozlišču), moramo torej vstopiti na najvišjem zapisu in potem gremo po poti, ki je že vnaprej določena, da pridemo do želenega zapisa. Podatkovna struktura se torej sestoji iz vozlišč ali zapisov ter povezav med vozlišči. Izkušnje pokažejo, da je to zelo učinkovita podatkovna struktura, ki nam omogoča zelo učinkovito obdelavo podatkov vedno, kadar se podatki uporabljajo v takem zaporedju in na ta način, kot je bilo v fazi načrtovanja IS zamišljeno. To je bilo takrat, ko smo snovali IS in znotraj njega bazo podatkov in opredelil njeno podatkovno strukturo. S tem smo tudi določili, na kakšen način se bo do kakšnega podatka prišlo. Problem se pokaže takrat, kadar bi želeli obdelovati podatke na nek drug način, ki pa v času razvoja IS ni bil predviden. Takrat postane tak model neučinkovit, neprikladen in takrat se pokažejo njegove slabosti. Skratka, pri tem modelu so povezave med zapisi že vnaprej določene, so del samega 112/136 Izvedbeni podatkovni modeli modela in nam določajo, na kakšen način bomo prišli do posameznih zapisov, podatkov in kako jih bomo lahko obdelovali. Tak model je dober in najbolj učinkovit v tistih IS, kjer se že v fazi snovanja dokaj dobro ve, kako bodo potekale posamezne transakcije na podatkih. Če pa gre za nek IS, ki pokriva veliko poslovnih področij in ki ga bo uporabljalo veliko število uporabnikov, je težko predvideti, kaj vse si bodo ti uporabniki zamislili – kakšne podatke, v kakšni obliki, v kakšnem času bi radi pridobili iz IS. Takrat postane tak model omejujoč, manj prikladen in manj učinkovit. To je njegova najšibkejša stran. Slika 53: Izsek iz hierarhičnega podatkovnega modela za podjetje Slika 53 nam pokaže, da lahko do podatkov o določenem zaposlenem pridemo samo preko oddelka in nato delovnega mesta – torej moramo vedeti, v katerem oddelku in na katerem delovnem mestu je zaposlen. Druge poti do podatkov o zaposlenih ni. Ker je lahko ista oseba zaposlena na določenem delovnem mestu in hkrati dela na določenem projektu, gornji model zahteva, da so podatki o tej osebi zapisani dvakrat – enkrat v zapisu ZAPOSLEN in drugič v zapisu DELAVEC, kar seveda pomeni, da moramo biti pri spremembi podatkov o tej osebi izredno pozorni, da kje ne pozabimo česa spremeniti. 9.1.2 Prednosti in slabosti hierarhičnega modela Bistvena prednost je, da omogoča hitro in učinkovito obdelavo podatkov na način, ki je bil v fazi snovanja IS zamišljen. Ima pa model dve bistveni slabosti:  do posameznega zapisa lahko pridemo po eni sami poti,  nefleksibilnosti do zapisov lahko pridemo samo po poti, ki je vnaprej določena  ne moremo si torej pri uporabi izmišljevati drugačnih dostopov. 9.2 Mrežni podatkovni model Tudi ta model je nastal v istem času kot hierarhični model, okrog leta 70, zato ga uvrščamo v skupino klasičnih modelov. Po svoji zasnovi predstavlja razširitev hierarhičnega modela. 9.2.1 Osnovne značilnosti mrežnega modela Zasnovan je na mrežni strukturi, ki sestoji iz vozlišč in povezav med njimi. Podobno kot pri hierarhičnem modelu, tudi tu vozlišča predstavljajo zapise, povezave pa seveda povezave med zapisi (zapis je skupek podatkovnih polj oz. podatkov) in s tem poti do posameznega zapisa. Razlika je v tem, da model 113/136 Izvedbeni podatkovni modeli odpravlja dve temeljni pravili hierarhičnega modela (na vrhu en sam zapis, relacija oče-sin), kar pomeni, da velja eno samo osnovno pravilo:  vsako vozlišče ima lahko poljubno število podrejenih in poljubno število nadrejenih vozlišč (zapisov). To pomeni, da imamo lahko tudi na najvišjem nivoju več zapisov (do zapisov na nižjih nivojih imamo torej več vstopnih poti) in da ima lahko posamezen zapis več nadrejenih zapisov (do zapisov lahko pridemo po različnih poteh, tudi če bi imeli en sam zapis na najvišjem nivoju). Strukturo mrežnega modela prikazuje Slika 54. Slika 54: Struktura mrežnega modela Taka struktura nam torej do neke mere olajša dostop do podatkov, vendar še vedno velja, da do podatkov ne moremo priti po drugačni poti kot tistih, ki so bile vnaprej določene že pri snovanju IS oz. njegove podatkovne baze. Slika 55: Izsek iz mrežnega podatkovnega modela za podjetje Slika 55 nam pokaže, da lahko sedaj do podatkov o določenem zaposlenem pridemo ne samo preko oddelka in nato delovnega mesta temveč tudi preko projekta, na katerem dela. Do podatkov o določenem naslovu pa lahko pridemo celo po 3 poteh: (1) oddelek  naslov, (2) oddelek  delovno mesto  zaposlen  naslov ter (3) projekt  zaposlen  naslov. Vendar pa velja, da druge poti niso možne. Model tudi omogoča, da imamo podatke o osebi, ki je zaposlena na določenem delovnem mestu in hkrati dela na določenem projektu, zapisane samo enkrat. 114/136 Izvedbeni podatkovni modeli 9.2.2 Prednosti in slabosti mrežnega modela Prednosti:  omogoča hitro in učinkovito obdelavo podatkov na način, ki je bil v fazi snovanja IS zamišljen;  je fleksibilnejši kot hierarhični model, saj omogoča, da do določenega zapisa pridemo po različnih poteh. Vendar pa model ohranja bistveno slabost:  do zapisov lahko pridemo samo po poteh, ki so vnaprej določene  pri uporabi si torej ne moremo izmišljevati drugačnih dostopov. 9.3 Relacijski podatkovni model Uvrščamo ga v skupino klasičnih modelov, ker je nastal v istem obdobju, v začetku 70-tih let prejšnjega stoletja, vendar se po vseh ostalih značilnostih, po nadaljnji usodi in razvoju njegove uporabe, močno razlikuje od ostalih dveh modelov. Razen tega, da je nastal v istem obdobju in ga uvrščamo prav tako v klasične modele, ima ta model s prejšnjima dvema modeloma zelo malo skupnega. Za razliko od prejšnjih dveh, ki sta nastala intuitivno, pa je ta model nastal na osnovi eksaktne matematične teorije, to je teorije relacij, in od tod tudi njegovo ime, relacijski model. Ta model je na prvi pogled zelo podoben E-R modelu. Vsekakor je bolj podoben E-R modelu, kot pa prejšnjima dvema. Nekateri v praksi celo zamenjujejo ali ne ločijo dobro med njima. Pa vendar gre za dva, po svoji vlogi povsem različna modela. E-R model se uporablja izključno v fazi načrtovanja IS, relacijski model pa se uporablja za njegovo izvedbo, za izvedbo baze podatkov. To pomeni, da je izvedbeni model, kar pa E-R model ni. Je pa res, da je relacijski model tisti izvedbeni model, v katerega najlažje pretvorimo logični E-R model. 9.3.1 Relacijska tabela Osnovna sestavina relacijskega modela je relacijska tabela. To je dvodimenzionalna tabela, ki spominja na tabelo, s katero smo poskušali predstaviti entitete pri E-R modelu. Ena taka tabela se običajno oblikuje oz. nastane kot preslikava enega tipa entitete v relacijski model. V splošnem pa velja, da lahko en tip entitete preslikamo (razbijemo) v več relacijskih tabel, relacijska tabela pa lahko predstavlja tudi tip povezave iz E-R modela. V relacijski tabeli kot kolone nastopajo atributi, kot vrstice pa n-terke z vrednostmi teh atributov (Slika 56). Slika 56: Primer relacijske tabele ŠTUDENT Vpis_št. Priimek Ime Spol Naslov Kraj Letnik 4015142 Suhi Gregor M Dunajska 53 Ljubljana 2 4015165 Majcen Anja Ž Cesarska 1 Maribor 1 4015209 Maksim Jan M Kraljeva 12 Kranj 2 4015416 Starec Jerneja Ž Carjeva 105 Metlika 1 115/136 Izvedbeni podatkovni modeli 9.3.2 Osnovne značilnosti relacijskega modela Relacijski model se lahko sestoji iz poljubnega števila relacijskih tabel (Slika 57). Čim bolj obsežen je tak model, tem več bo takšnih tabel. Za razliko od mrežnega in hierarhičnega modela, kjer smo videli, da so bile definirane tudi povezave med zapisi, med relacijskimi tabelami ni določenih nobenih povezav. Slika 57: Izsek iz relacijskega podatkovnega modela ŠTUDENT ŠTUDENT-OBVEZNOST Vpis_št. Priimek Ime Letnik Vpis_št. Šif_predm. Tip_obv Datum Ocena UČITELJ PREDMET Šif_uč. Priimek_u Ime_u Šif_predm. Šif_predm. Naziv Letnik_p Pri relacijskem modelu povezave med tabelami niso vnaprej definirane, pač pa se vzpostavijo v realnem času, v času same obdelave podatkov, na osnovi uporabniških zahtev. Se pravi, da uporabnik vnese v računalnik svoje zahteve na način, da računalnik to razume, potem pa ustrezni krmilni sistem baze podatkov, ki upravlja z bazo podatkov, iz zahtev ugotovi, katere tabele bo potrebno prebrati iz baze in jih povezat med sabo, da bo lahko odgovoril na postavljeno zahtevo uporabnika. Ko se zahteve iz baze preberejo, se podatki povežejo med seboj, podajo odgovor uporabniku na ekran in takoj za tem se te povezave pozabijo. To pomeni, da se te povezave vzpostavljajo sproti, po potrebi in odvisno od uporabnikovih zahtev. Ne pa tako kot pri prejšnjih dveh modelih, ko so bile povezave vnaprej določene in nespremenljive ter so tudi vnaprej narekovale način uporabe podatkov. Iz tega se pokaže, da je ta model veliko fleksibilnejši. Poglejmo si na primeru podatkovnega modela s slike 6. Če želimo iz računalnika dobiti podatke o tem, katere študijske obveznosti in pri katerem predmetu ima opravljene nek študent (vključno s priimkom in imenom študenta ter nazivom predmeta), potem bo potrebno povezati med seboj tabele: ŠTUDENT, ŠTUDENT-OBVEZNOST in PREDMET. To računalnik ugotovi že iz našega vprašanja (poizvedbe), zato gre v bazo podatkov iskat ustrezne tabele, prebere podatke iz njih, poveže podatke med sabo, da odgovor na ekran in jih nato takoj pozabi. Naslednje vprašanje se glasi, katere predmete predava določen učitelj (seveda želimo na seznamu imeti podatke o učitelju in podatke o predmetih)? Krmilni sistem baze podatkov bo ugotovil, da je treba prebrati tabelo UČITELJ in tabelo PREDMET. Kmalu zatem bo dal na ekran ustrezen odgovor in spet pozabil povezavo. Torej, povezave se vzpostavljajo samo za tisti čas, da se odgovori na konkretno uporabnikovo vprašanje. 116/136 Izvedbeni podatkovni modeli 9.3.3 Prednosti in slabosti relacijskega modela Prednosti  Najpomembnejša prednost je njegova fleksibilnost, saj povezave med podatki niso vnaprej vgrajene v model podatke lahko torej najdemo po različnih poteh, možno je poiskati tudi različne kombinacije podatkov.  Zaradi konceptualno podobnih osnov E-R in relacijskega modela, je od izvedbenih modelov prav relacijski tisti, v katerega je najlažje pretvoriti E-R model, kar seveda pomeni lažji prehod iz fizične v logično zasnovo (se ga da z ustreznimi orodji skoraj popolnoma avtomatizirati). Slabosti  sprotno vzpostavljanje povezav med podatki zahteva veliko računanja (več časa, da pridemo do odgovora), to pa pomeni,  da potrebujemo zmogljivejšo opremo,  kar seveda pomeni tudi višje investicijske (razvojne) stroške (v primerjavi s prejšnjima modeloma). 9.3.4 Primerjava med tremi klasičnimi izvedbenimi podatkovnimi modeli Če naredimo primerjavo med temi tremi modeli, lahko rečemo, da sta se prva dva modela v praksi zelo hitro uveljavila. Najprej se je uveljavil hierarhični model. Ta je razmeroma preprost za implementacijo in se je uveljavil že v začetku 70-ih let. Ko so se začele baze podatkov v podjetjih in ustanovah razvijati, so bile vse grajene na tem hierarhičnem modelu in vsi krmilni sistemi baz podatkov so takrat temeljili na tem hierarhičnem modelu. Ti nam omogočajo izredno učinkovito obdelavo podatkov, podatki pa se uporabljajo na način, ki je bil že vnaprej predviden. Čim pa bi radi podatke obdelovali na nek drugačen način, pa postane hierarhični model zelo omejujoč. Zato se je sredi 70-ih let, začel naglo uveljavljati mrežni model, ki je nekoliko boljši in da več fleksibilnosti glede dostopa do podatkov, načina obdelave podatkov in načina uporabe podatkov, ker imamo več možnih dostopov do zapisov. Ta model je ostal do konca 80-ih let zelo popularen. Tretji model, relacijski model, pa je kljub temu, da je bil znan in da je bil predstavljen v strokovni literaturi praktično istočasno, v začetku 70-ih let, potreboval veliko več časa za uveljavitev v praksi. Zakaj? Relacijski model je povsem fleksibilen, povezave med podatki niso vnaprej določene in zato z njim lahko vzpostavimo poljubne povezave, vendar pa načeloma, ko je treba neke povezave vzpostaviti in se te seveda vzpostavljajo v realnem času, mora računalnik s pomočjo tujih ključev ugotoviti, katere tabele bo moral med seboj povezati. To predstavlja veliko režijskega dela, dodatnega računanja oz. dela, ki ga pri prejšnjih dveh modelih ni. Pri prejšnjih dveh modelih model samo prebere kazalec in že pride do naslednjega zapisa in ga prebere. Režija, ki jo zahteva relacijski model, je bila glavni razlog, da je ta model potreboval 20 let, da se je uveljavil v praksi. V začetku 70-tih let preprosto ni bilo računalnikov, kjer bi se lahko ta model v praksi implementiral in uporabil. Prve njegove praktične implementacije zasledimo v začetku 80-tih let in to samo na najzmogljivejših računalnikih. Potem je trajalo še dodatnih 10 let, da je cena računalnikom še toliko padla oz. da so postali tako zmogljivi oz. da je ta procesna moč postala dostopna širšemu krogu uporabnikov in da se je začel relacijski model bolj intenzivno uporabljati. Njegova uporaba se je iz velikih računalnikov koncem 80-ih let in v začetku 90-ih let prejšnjega stoletja začela širiti tudi na osebne računalnike in tam sredi 90-ih let je postal prevladujoči model, saj so bili računalniki (veliki in majhni) že dovolj zmogljivi. Ti krmilni sistemi baz podatkov (posebna programska oprema, ki jo potrebujemo, da implementiramo nek tak model) so danes še vedno grajeni na osnovi teh treh modelov ali nekih kombinacij med njimi, prevladujoč pa je relacijski model. 117/136 Izvedbeni podatkovni modeli Viri in literatura Kovačič, A. & Vintar, M. (1994). Načrtovanje in gradnja informacijskih sistemov. Ljubljana: DZS. Kaj moram vedeti?  Izvedbeni podatkovni modeli  Hierarhični model  Mrežni model  Relacijski model  Relacija  Primerjava hierarhični : mrežni model  Primerjava E-R model : relacijski model 118/136 10. poglavje: Informacijska orodja za razvoj IS Okolje, v katerem poteka kakršnakoli razvojna dejavnost, je izrednega pomena za uspešnost te dejavnosti. To velja tudi za razvoj IS. V splošnem lahko opredelimo štiri metodološke in tehnološke dejavnike, ki so ključni za uspešen razvoj IS: • projektno vodenje razvoja IS (ki ga bomo podrobneje spoznali v 12. poglavje), • uporabo sodobnih metodoloških pristopov k razvoju IS (o tem več v 11. poglavje), • inovativno prenovo poslovnih procesov (glej 2. poglavje). • uporaba sodobnih informacijskih orodij pri razvoju IS. V tem poglavju bomo torej spoznali nekaj orodij, ki jih uporabljamo pri razvoju IS. Gre za specializirana računalniška orodja, ki podpirajo razvoj IS in ga delajo bolj učinkovitega, kar posledično zmanjšuje razvojne čase, znižuje razvojne stroške in zvišuje kakovost razvitih rešitev. Vsebina poglavja 10.1 Programski jeziki 4. in 5. generacije ............................................................................................. 120 10.2 Sistemi za upravljanje podatkovnih baz ....................................................................................... 121 10.3 CASE orodja .................................................................................................................................. 121 10.3.1 Razvoj CASE orodij ........................................................................................................... 121 10.3.2 Vrste CASE orodij ............................................................................................................. 122 10.3.2.1 Orodja za vzdrževanje projektne dokumentacije ..................................................... 122 10.3.2.2 Orodja za prenovo informacijskih sistemov (reinženiring) ....................................... 122 10.3.2.3 Orodja za podporo celotnemu razvojnemu ciklu ..................................................... 123 Viri in literatura .................................................................................................................................... 123 119/136 Informacijska orodja za razvoj IS 10.1 Programski jeziki 4. in 5. generacije Na prvem mestu lahko izpostavimo razvoj programskih jezikov četrte in pete generacije. O tem smo podrobneje govorili že v 1. letniku pri predmetu Osnove informatike. V splošnem je razvoj programskih jezikov potekal vzporedno s razvojem računalnikov. Jeziki četrte generacije (4G) imajo za seboj kar nekaj zgodovine. Razvoj teh jezikov sega v 80-ta leta prejšnjega stoletja. Njihov namen je bil čimbolj skrajšati razvojne čase in znižati razvojne stroške – torej večja produktivnost ob krajših razvojnih časih. Glavna značilnost je, da s programom računalniku povemo, kaj želimo doseči (v nasprotju z jeziki tretje generacije (3G), ko smo morali s programom natančno povedati, kako naj računalnik pride do rezultata). Tipični predstavniki jezikov 4G so poizvedovalni jeziki (SQL). Jeziki pete generacije (5G) so novejša generacija jezikov, ki se uporablja na področju umetne inteligence; tu gre npr. za prepoznavanje vzorcev v podatkih, prepoznavanje govora ipd. V zadnjem času se tako uporabljajo večinoma jeziki 4. in 5. generacije, vendar pa se poleg teh dveh generacij jezikov še vedno intenzivno uporablja tudi tretja generacija jezikov, za katero se je že pred 20 in več leti mislilo, da bo odšla s prizorišča, pa se to ni zgodilo. Katero generacijo programskih jezikov bomo uporabili pri razvoju določenega IS, je seveda odvisno od značilnosti in karakteristik IS, ki ga razvijamo – to ni vnaprej jasno določeno, niti ni to zgolj odvisno od tega, kako moderna orodja želimo. To mora biti zelo pretehtana odločitev, utemeljena na karakteristikah rešitve, ki jo razvijamo, pri čemer sta pomembna dva parametra, ki jim imamo vedno v prvem planu: čas, ki ga imamo na voljo za razvoj, in stroški. Pri tem je potrebno upoštevati dve vrsti stroškov: razvojni in obratovalni oz. vzdrževalni stroški. Generalno velja: čim višjo generacijo jezikov uporabimo, nižji bodo razvojni in višji obratovalni stroški (Slika 58). Jeziki 4G so v pogledu časa in razvojnih stroškov bistveno boljši kot 3G (razvojni čas je krajši, razvojni stroški nižji), toda rešitve, ki na ta način nastanejo, so običajno v obratovanju dražje (saj potrebujemo zmogljivejše računalniške sisteme, da lahko v realnem času obdelajo zahteve, podane s programom). Pri izbiri ustrezne generacije programskih jezikov za razvoj določenega IS torej iščemo nek optimum v razmerju med razvojnimi in obratovalnimi stroški. Slika 58: Razmerje med razvojnimi in obratovalnimi stroški v odvisnosti od generacije programskih jezikov vokšorts an razvojni išiv obratovalni 1G 2G 3G 4G 5G generacija programskih jezikov 120/136 Informacijska orodja za razvoj IS 10.2 Sistemi za upravljanje podatkovnih baz Izvedbeni podatkovni model nam omogoča zgolj opredelitev strukture podatkovne baze in notranje strukture podatkov v bazi. Za samo konkretno izvedbo baze pa potrebujemo specializirano orodje. Tako orodje je sistem za upravljanje podatkovnih baz (SUPB)21, ki nam omogoča vse ključne aktivnosti v zvezi z razvojem, uporabo in vzdrževanjem podatkovnih baz. Omogoča nam:  opredelitev njene podatkovne strukture, na osnovi izbranega podatkovnega modela (hierarhičnega, mrežnega, relacijskega);  da tako bazo kreiramo;  uporabo baze podatkov in vse aktivnosti, ki so na to vezane, se pravi vnos podatkov, ažuriranje podatkov, spreminjanje, preglede podatkov;  vzdrževanje podatkov in  zaščito baze podatkov pred nevtraliziranim dostopom, pred uničenjem, pred poškodbo itd. Vse te funkcije so vgrajene v krmilni sistem baze podatkov. Ti krmilni sistemi baze podatkov so torej specializirani sistemi programov, ki jih danes uporabniki le izjemoma razvijajo sami. Največkrat kupijo ustrezno rešitev (ustrezen sistem oz. ustrezno orodje) na trgu, kajti ponudba teh specializiranih orodij je na trgu kar precej bogata. Nekaj teh tržnih znamk gotovo poznate, npr. Oracle je eden od najbolj razvitih in najbolj modernih sistemov orodij, obstajajo tudi Paradox, Access, Informix itd. Ko razvijamo nek IS, moramo analizirati značilnosti tega IS, obseg, količino podatkov, število uporabnikov, način uporabe podatkov. Na osnovi tega se odločimo za ustrezen krmilni sistem baz podatkov. 10.3 CASE orodja Ta kratica prihaja iz angleškega imena Computer Aided System Engineering, kar v slovenščini pomeni računalniško podprt razvoj sistemov. Gre za specializirana informacijska orodja, ki nam olajšajo in pomagajo razviti IS. Na nek način nadomeščajo papir in svinčnik pri razvoju IS. 10.3.1 Razvoj CASE orodij Razvoj teh orodij se je začel v začetku 70-tih let prejšnjega stoletja, ko so se na trgu pojavila prva tovrstna orodja. Takrat so bila to še zelo preprosta orodja; v bistvu čisto grafična orodja, ki so nam omogočala risanje raznih diagramov in grafov, ki smo jih predstavili v okviru modeliranja IS. Kakšnih analitičnih funkcij pa ta orodja takrat še niso imela. Vedelo se je, da lahko ta orodja zelo olajšajo razvoj IS, posledično skrajšajo razvojni čas, znižajo stroške, povečajo kakovost razvitih rešitev, zato je postal ta razvoj čedalje bolj intenziven. Kmalu se je pa pokazalo, da gre razvoj IS skozi zelo različne faze. Na začetku, ko začnemo s strateškim načrtovanjem sistema, so te aktivnosti povsem drugačne, kot pri neki zaključni fazi, v okviru katere je potrebno generirati ali programirati posamezne programske module, jih testirati ipd. Skratka, razvoj gre skozi zelo različne faze. Takrat je hitro postalo jasno, da bi z enim samim orodjem vse te faze zelo težko pokrili. Zato so se odprle različne razvojne smeri. Eni razvijalci so se osredotočili bolj na zgodnje razvojne faze IS in so trgu ponudili orodja, ki omogočajo razvoj v zgodnjih fazah, kot je strateško načrtovanje vse do logične zasnove IS, do razvoja E-R modela, do opisa oziroma modeliranja procesnega 21 Včasih se uporablja tudi izraz: krmilni sistem baze podatkov (KSBP). 121/136 Informacijska orodja za razvoj IS pogleda na IS, drugi pa so šli v podporo fizični zasnovi in pa sami izvedbi IS. Tretji so se osredotočili na različne podporne aktivnosti, kot je nadzor kakovosti, vzdrževanje sistema itd. 10.3.2 Vrste CASE orodij V splošnem lahko CASE orodja opredelimo kot horizontalna (ki pokrivajo posamezne faze razvoja) in vertikalna (ki podpirajo celoten razvoj, lahko z različnih vidikov). Tipične funkcionalnosti, ki jih pokrivajo različna CASE orodja, pa so:  podpora razvojnemu ciklu (z različnih vidikov),  grafična podpora,  razvoj podatkovnega slovarja (kataloga podatkov),  vzdrževanje projektne dokumentacije,  prenova informacijskih sistemov. Tako je danes trg poplavljen s številnimi orodji, ki pa jih lahko uvrstimo v nekaj karakterističnih skupin, kot so:  orodja za vzdrževanje projektne dokumentacije,  orodje za prenovo informacijskih sistemov,  orodja za podporo celotnemu razvojnemu ciklu,  orodja za podporo vodenju projektov,  orodja za spremljanje kakovosti. 10.3.2.1 Orodja za vzdrževanje projektne dokumentacije Gre za posebno skupino orodij, katerih namen je poenostaviti izdelavo projektne dokumentacije, vezane na razvoj IS. Izkušnje so pokazale, da ta orodja kot samostojna orodja niso najbolj učinkovita, saj če vzdrževanje projektne dokumentacije ni neposredno povezano z samim razvojem in aktivnostmi, potem se to vzdrževanje običajno zanemarja in pušča za konec, ko so rešitve že razvite in implementirane. Takrat pa nikoli ni dovolj časa in posledica tega je, da so rešitve slabo dokumentirane. Tako da danes teh orodij kot samostojnih orodij za vzdrževanje projektne dokumentacije ne dajemo v uporabo. Funkcionalnosti, ki jih ta orodja omogočajo, so danes vključene v splošnejša CASE orodja (npr. za prenovo IS ali za podporo razvojnemu ciklu IS). 10.3.2.2 Orodja za prenovo informacijskih sistemov (reinženiring) Namen teh orodij je olajšati prenovo obstoječih IS. V mnogih okoljih, ki imajo daljšo zgodovino na teh področjih, in kjer so začeli z uvajanjem računalnikov ter informacijske tehnologije v poslovanje že pred 30 in več leti, so se pred časom znašli v situaciji, ko so bile rešitve vsebinsko še povsem uporabne, tehnološko pa povsem zastarele. Tega je tudi v upravi ogromno. Na številnih področjih (na področju registra prebivalstva, na področju evidenc) imamo situacije, ko se področja kot je register prebivalstva nič ne spremenijo, tehnologija pa se je pa v tem času že nekajkrat zamenjala. In tega je na področju zdravstva, šolstva, pokojninskega in invalidskega zavarovanja zelo veliko. To pomeni, da veliko rešitev datira nazaj za dve ali celo več desetletij. Pojavlja se vprašanje, kako te rešitve na čim bolj enostaven način in s čim nižjimi stroški tehnološko posodobiti. Zato obstajajo na trgu posebna orodja, ki nam omogočajo, da iz obstoječe programske kode, ki še deluje, naredimo logični model rešitve in potem iz logičnega modela samodejno (avtomatično) generiramo rešitev za tehnologijo, ki jo danes uporabljamo ali pa jo mislimo vpeljati v bodoče. Zavedati se moramo, da sto odstotnega avtomatizma ni; običajno je potrebno še kar precej ročnega dela, ampak če orodje opravi 80 % dela, je to zelo veliko. 122/136 Informacijska orodja za razvoj IS 10.3.2.3 Orodja za podporo celotnemu razvojnemu ciklu Orodja za podporo celotnemu razvojnemu ciklu so osrednja ('prava') CASE orodja. Tako osrednje CASE orodje naj bi zagotavljalo podporo čim večjemu številu razvojnih faz in aktivnosti znotraj razvojnega procesa. V glavnem ta osrednja CASE orodja omogočajo:  sam razvoj IS;  izvedbo posameznih razvojnih aktivnosti, ki kot stranski rezultat izdelajo ustrezno projektno dokumentacijo. Seveda velja poudariti, da takih orodij na trgu praktično ni, ker so aktivnosti in zahteve posameznih razvojnih faz tako različne, da je težko izdelati orodje, ki bi dejansko v celoti podrlo vse faze razvoja. Obstajajo pa orodja, ki pokrivajo npr. začetne faze razvoja (analizo in logično zasnovo), ter orodja, ki v večji meri pokrivajo kasnejše faze razvoja. Razvila pa so se orodja, ki podpirajo celoten razvojni cikel z določenega vidika, tako da v to skupino uvrščamo tudi nekatera druga orodja, kot so npr. orodja za podporo vodenju projektov in orodja za spremljanje kakovosti. Viri in literatura Kovačič, A. & Vintar, M. (1994). Načrtovanje in gradnja informacijskih sistemov. Ljubljana: DZS. Kaj moram vedeti? • Kaj in katera so orodja za razvoj IS? • Programski jeziki 3., 4. in 5. generacije • Krmilni sistemi baz podatkov • CASE orodja 123/136 11. poglavje: Metodološki pristopi k razvoju IS V 3. poglavju smo spoznali življenjski cikel razvoja IS in opredelili faze razvoja. Kako pa se te faze v praksi izvedejo, kaj vse zajemajo in kakšni so rezultati po posamezni fazi, kakšne metode in tehnike uporabljamo – vse to pa je odvisno od metodološkega pristopa in od tehnologije, ki ju uporabimo. Podobno je tudi npr. v gradnji: hišo lahko gradimo po različnih pristopih, po različnih metodologijah. Poznamo klasično gradnjo in montažno gradnjo, ki prej pripelje do končnega izdelka. Tako je tudi na področju razvoja IS. V praksi so se razvili različni pristopi, ki pristopajo k izvedbi življenjskega cikla IS na različne načine. Danes lahko govorimo o treh karakterističnih pristopih, ki se uporabljajo pri načrtovanju in gradnji IS: linearni, prototipni in objektni. Kot smo videli v 10. poglavju, je izbor ustreznega metodološkega pristopa eden od ključnih dejavnikov uspeha pri razvoju IS. Vsebina poglavja 11.1 Linearni pristop ............................................................................................................................ 126 11.1.1 Osnovne značilnosti linearnega pristopa ......................................................................... 126 11.1.2 Prednosti linearnega pristopa .......................................................................................... 126 11.1.3 Slabosti linearnega pristopa ............................................................................................. 126 11.2 Prototipni pristop ......................................................................................................................... 126 11.2.1 Vloga prototipa in osnovne značilnosti prototipnega pristopa ........................................ 127 11.2.2 Prednosti prototipnega pristopa ...................................................................................... 127 11.2.3 Slabosti prototipnega pristopa......................................................................................... 127 11.2.4 Kdaj izberemo prototipni in kdaj linearni pristop? ........................................................... 128 11.3 Objektni pristop ........................................................................................................................... 128 11.3.1 Objekt in značilnosti objektnega pristopa ........................................................................ 128 11.3.2 Prednosti objektnega pristopa ......................................................................................... 129 Viri in literatura .................................................................................................................................... 129 125/136 Metodološki pristopi k razvoju IS 11.1 Linearni pristop Linearni pristop je najstarejši. Rečemo mu lahko tudi klasični ali tradicionalni pristop. Razvijati se je začel v drugi polovici 70-tih let prejšnjega stoletja v obdobju uporabe velikih računalnikov ter računalniških centrov. Značilno za to obdobje je tudi, da razvoj IS obvladujejo specializirani strokovnjaki. 11.1.1 Osnovne značilnosti linearnega pristopa Pristop temelji na t. i. kaskadnem principu (angl. waterfall principle). Kaj to pomeni? Zamislimo si vodo, ki pada v globino po več zaporednih slapovih – kaskadah. Šele ko se vrhnja kotanja napolni z vodo, se le-ta prelije kot slap v naslednjo kotanjo in tako zaporedoma do zadnjega slapa. Pri linearnem pristopu gre torej za pristop, kjer je celotni proces razvoja IS razdeljen na določeno število bolj ali manj natančno definiranih faz, ki si sledijo po vnaprej točno določenem zaporedju. Faze so dokaj natančno definirane. Določeno je, kaj je potrebno v posamezni fazi postoriti, katere aktivnosti je potrebno izvesti in tudi kakšni oz. kateri rezultati nastanejo iz teh aktivnosti. Rezultati posamezne faze so dokaj natančno opredeljeni in tudi dokumentirani. Dokumentirani rezultati predhodne faze vedno predstavljajo izhodišče za naslednjo fazo. Gre za razmeroma sistematičen pristop, katerega rezultat so dobro dokumentirane posamezne razvojne faze in na koncu tudi celoten projekt, celotna rešitev. Ta pristop je neodvisen od velikosti problema, lahko ga uporabljamo pri razvoju preprostih IS oz. informacijskih rešitev, lahko pa tudi pri razvoju najkompleksnejših rešitev. Je neodvisen od uporabljenih orodij. Ne glede na to, katera orodja bomo uporabili, je vedno mogoče uporabiti ta pristop. 11.1.2 Prednosti linearnega pristopa Iz navedenega lahko povzamemo naslednje prednosti linearnega pristopa:  dobro dokumentirane posamezne faze,  dobro dokumentirana celotna rešitev,  je neodvisen od velikosti problema,  je neodvisen od uporabljenih orodij. 11.1.3 Slabosti linearnega pristopa Vendar pa v praksi izkazuje ta pristop tudi vrsto slabosti, ki večinoma izhajajo prav iz njegovih osnovnih značilnosti (točno določene faze in rezultati, ki morajo biti natančno dokumentirani):  dolgi razvojni cikli;  visoki razvojni stroški;  slabo sodelovanje uporabnikov skozi razvojni proces;  morebitne napake in pomanjkljivosti pri načrtovanju se pokažejo šele proti koncu ali pa čisto na koncu, ko jih je težko in drago popravljati;  nepredvidljiva kakovost končne rešitve (končnega izdelka) kot posledica predvsem prejšnjih dveh in je pravzaprav največja slabost tega pristopa. 11.2 Prototipni pristop Slabosti linearnega pristopa so v največji meri prispevale k razvoju drugega, to je t. i. prototipnega pristopa. Ta je nastal kasneje, v prvi polovici 80-tih let prejšnjega stoletja, in lahko rečemo, da je nastal 126/136 Metodološki pristopi k razvoju IS kot odgovor na slabosti linearnega pristopa. Da bi lahko prototipni pristop podrobneje pojasnili, moramo najprej pojasniti, kaj prototip sploh je, kaj razumemo pod tem izrazom. 11.2.1 Vloga prototipa in osnovne značilnosti prototipnega pristopa Večina nas ve, da se prototipi veliko uporabljajo na vseh tehničnih področjih, npr. pri serijski proizvodnji tehničnih izdelkov. Ni serijskega izdelka (npr. avtomobili, letala itd.), ne da bi se prej izdelal prototip, na katerem se preizkusijo lastnosti bodočega izdelka. Na osnovi teh preizkusov, se načrti dopolnijo, popravijo in nato se prične s serijsko proizvodnjo, prototip sam pa se zavrže (navadno konča nekje na smetišču ali v muzeju). Takšna je vloga prototipa na tehničnih področjih. Na področju razvoja IS pa je pojem prototipa razumljen nekoliko drugače. Pri tem pristopu gre za neke vrste evolutivni pristop, pri katerem poskuša projektna skupina, v katero so od samega začetka aktivno vključeni bodoči uporabniki projektne rešitve, v čim krajšem času razviti prototip bodoče rešitve, bodočega IS. Ta prototip že vsebuje vse ključne funkcionalnosti, ki naj bi jih končna rešitev vsebovala in nudila uporabnikom. Ta prototip potem predstavimo vsem vpletenim v razvoj (naročnikom, uporabnikom itd.). Tako si lahko le-ti veliko bolj 'plastično' predstavljajo, ali gre razvoj v pravo smer in ali bo končna rešitev res to, kar v resnici v konkretnem poslovnem okolju potrebujejo. Vsi ti vpleteni podajo na ta prototip pripombe in predloge, kaj je še treba dopolniti, kaj mu manjka. Ta prototip se nato na podlagi podanih predlogov in pripomb dopolni in spet predstavi uporabnikom in naročnikom. Tako se prototip dopolnjuje in izpopolnjuje v več korakih vse do delujoče končne rešitve, ko se preda v uporabo uporabniku. Zgoraj opisana vloga prototipa in njegovega razvoja do končne rešitve je bistvo prototipnega pristopa. Gre za evolutivni pristop, pri katerem od samega začetka tesno sodelujejo uporabniki, ki imajo v tem razvojnem procesu ustrezno odgovornost. Če je bilo njihovo sodelovanje aktivno, če so bili ves čas zraven, kasneje ne morejo reči, da so dobili nekaj, česar niso naročili ali pa niso pričakovali ali želeli. 11.2.2 Prednosti prototipnega pristopa Ta pristop prinaša dve bistveni pozitivni stvari:  Tesno sodelovanje uporabnikov pri celotnem razvoju: uporabniki so ves čas zraven, sodelujejo, soodločajo, sooblikujejo in so soodgovorni za nastalo rešitev.  Zaradi tega je možnost, da se bodo napake in pa funkcionalnosti, ki jih ne potrebujemo, pokazale šele na koncu, neprimerno manjša.  Oboje omogoča višjo kakovost končne rešitve. Ta pristop poleg tega deloma odpravlja nekaj prej omenjenih slabosti linearnega pristopa in sicer:  skrajšuje razvojne cikle in s tem celoten razvojni čas ter  znižuje razvojne stroške. 11.2.3 Slabosti prototipnega pristopa Ima pa prototipni pristop tudi svoje slabosti:  nimamo nekih vnaprej predpisanih razvojnih faz, ki bi se jih moral projektni tim držati;  ne vemo vnaprej, kaj bo v posamezni fazi nastalo, kaj so rezultati, ki bi bili dokumentirani, itd.;  slaba dokumentiranost celotnega razvoja in končne rešitve;  težko in drago vzdrževanje. 127/136 Metodološki pristopi k razvoju IS 11.2.4 Kdaj izberemo prototipni in kdaj linearni pristop? Pri prototipnem pristopu gre v precejšnji meri za improviziran pristop, kjer so vse te odločitve, po katerih razvoj poteka, prepuščene samemu projektnemu timu. Sam se odloča, po katerih korakih bo šel, kdaj se mu bo zazdelo, da je prototip že dovolj dober, da ga lahko pokažemo javnosti, kako se bo dopolnjeval itd. Ta pristop je veliko bolj fleksibilen, vendar pa posledično rezultira v slabo dokumentiranih rešitvah, ki jih je kasneje težko in drago vzdrževati. Če povzamemo, potem lahko rečemo, da je ta pristop kot samostojen pristop primeren le, kadar gre za razvoj manj zahtevnih informacijskih rešitev, informacijskih sistemov. Kadar pa gre za kompleksnejše sisteme oz. rešitve, ki pokrivajo pomemben del nekega poslovnega sistema, poslovnih funkcij ali pa celo več poslovnih funkcij, lahko tudi celotnega poslovnega sistema, takrat pa je lahko tak pristop tvegan, zato ga odsvetujemo. To pomeni, da ko gre za kompleksne rešitve, se bo še vedno v prvi vrsti uporabljal linearni pristop. Prototipni pristop pa lahko uporabljamo tudi kot dopolnilo k linearnemu pristopu. Vidimo, da se ta dva pristopa lahko lepo dopolnjujeta. Ko gre za razvoj zahtevnega IS, katerega razvoj bo trajal daljši čas in je tveganje zelo visoko (ali bo projekt uspel ali ne, ali bomo na koncu dobili to, kar potrebujemo), je zelo koristno, če lahko v čim krajšem času pridemo do nekega prototipa, na osnovi katerega bomo lahko veliko bolj realno in objektivno preverili, ali smo na začetku določili prave cilje, ali smo razvoj usmerili v pravo smer in seveda tudi ali razvoj teče v pravi smeri. Kasneje pa s pomočjo prototipa in njegovim preučevanjem usmerjamo razvoj projekta, ki teče po tem linearnem pristopu. Ta dva pristopa je torej možno med seboj kombinirati; kadar gre za kompleksnejše rešitve, je tako kombiniranje celo priporočljivo. 11.3 Objektni pristop Je najnovejši od obravnavanih treh pristopov. Je konceptualno bistveno drugačen od prej predstavljenih pristopov in ga je težko neposredno primerjati z njima. Ideja in začetki razvoja tega pristopa segajo v začetek 90-tih let prejšnjega stoletja, pa vendar lahko rečemo, da v praksi še ni povsem nadomestil (izpodrinil) prejšnjih dveh pristopov. Njegov namen je:  skrajšati razvojne cikle,  znižati razvojne stroške,  izboljšati kakovost končne rešitve. 11.3.1 Objekt in značilnosti objektnega pristopa Tradicionalne strukturne tehnike pri razvoju IS posebej obravnavajo podatke v okviru IS in posebej postopke za njihovo obdelavo. Za vsak del se uporabljajo različni koncepti ter metode in tehnike in dobimo tudi dva različna modela: podatkovni in postopkovni model. Na podlagi prvega se razvije podatkovna baza, na podlagi drugega pa programski moduli. Objektni pristop pa v nasprotju s tem omogoča enovito obravnavo podatkov in postopkov. Temelji namreč na objektih, ki predstavljajo abstrakcijo nekih objektov, subjektov ali pojmov iz realnega sveta (podobno kot entitete). Vendar pa je bistvena razlika ta, da nas pri entitetah zanimajo zgolj njihove lastnosti (atributi in njihove vrednosti) ter povezave med entitetami (torej podatki v okviru IS), objekti pa združujejo podatke in pripadajoče postopke na teh podatkih. Objekt torej omogoča skupno obravnavo podatkov, ki opisujejo lastnosti objekta, in postopkov (aktivnosti) za obdelavo objekta. Na ta način objektni pristop združuje podatkovni in postopkovni pogled 128/136 Metodološki pristopi k razvoju IS na ravni objekta, kar je tudi osnovna značilnost objektnega pristopa. Ko je objekt enkrat oblikovan in vpeljan v IS, predstavlja nek standardiziran, tipiziran element tega IS. Objekt lahko večkrat uporabimo v različnih modulih (delih) tega IS, lahko pa tudi pri razvoju drugega IS za isto poslovno okolje. Ker objekti predstavljajo zaključene celote, lahko posamezen objekt spreminjamo, ne da bi bilo potrebno spremeniti ostale objekte, čeprav je z njimi povezan. 11.3.2 Prednosti objektnega pristopa Zgoraj opisane značilnosti objektov in njihove uporabe prinašajo naslednje prednosti projektnega pristopa:  hitrejši in cenejši razvoj IS (večkratna uporaba istih objektov znatno skrajša čas za razvoj novih rešitev in s tem zmanjša razvojne stroške);  višja kakovost rešitev ter večja zanesljivost delovanja IS (ker uporabljamo objekte, ki so že preverjeni v obstoječih rešitvah);  poenostavljeno vzdrževanje programskih rešitev (ker lahko posamezne objekte spreminjamo neodvisno od ostalih). Viri in literatura Kovačič, A. & Vintar, M. (1994). Načrtovanje in gradnja informacijskih sistemov. Ljubljana: DZS. Kaj moram vedeti? • Linearni pristop • Kaskadni princip • Prototipni pristop • Prototip • Objektni pristop • Objekt 129/136 12. poglavje: Projektno vodenje razvoja IS Izkušnje kažejo, da so projekti razvoja IS razmeroma kompleksni in da pogosto ne uspejo, da prihaja zelo pogosto do prekoračitve rokov, do ogromne prekoračitve stroškov. Gotovo je eden od ključev za rešitev teh problemov v izboru pristopov k razvoju IS, kjer se je eden od pomembnih pokazal projektni pristop, kar pomeni, da razvoj IS vodimo kot projekt. Pomembnost projektnega pristopa se je naprej dokazala na številnih drugih področjih, kjer imajo projektne metodologije že zelo dolgo tradicijo, npr. v gradbeništvu in še na drugih tehničnih področjih. Za upravo pa velja, da nekje do srede 90. let pojma projekt nismo poznali, kaj šele projektni pristop, kot nek sistematični pristop. V tem času se je razumevanje pomena projektnega pristopa začelo spreminjati in so tudi v upravi spoznali, da če želijo povečati učinkovitost, uspešnost in kakovost velikih strokovnih projektov, ki se v upravi izvajajo, da je potrebno začeti uvajati projektni pristop oz. sistematične metodologije vodenja oz. upravljanja projektov. Tudi v slovenski upravi se je v letu 2000 oblikovala enotna metodologija za razvoj informacijskih sistemov – EMRIS, po kateri tudi povzemamo to poglavje. V tem poglavju bomo tako najprej spoznali glavne korake uresničevanja projektnega pristopa, v nadaljevanju pa podrobneje predstavili predvsem pripravo projekta. Vsebina poglavja 12.1 Koraki uresničevanja projektnega pristopa .................................................................................. 132 12.2 Priprava projekta .......................................................................................................................... 132 12.2.1 Metodologije vodenja projektov ...................................................................................... 132 12.2.2 Projekta pisarna ............................................................................................................... 132 12.3 Vzpostavitveni dokument projekta (VDP) .................................................................................... 133 12.3.1 Namen VDP ...................................................................................................................... 133 12.3.2 Priprava VDP .................................................................................................................... 133 12.3.3 Sprejem VDP .................................................................................................................... 133 12.3.4 Vsebina VDP ..................................................................................................................... 133 12.4 Organizacija projekta ................................................................................................................... 134 12.5 Projektni svet ....................................................................................................................... 135 12.6 Projektna skupina ................................................................................................................ 135 12.7 Nadzor kakovosti ................................................................................................................. 135 Viri in literatura .................................................................................................................................... 136 131/136 Projektno vodenje razvoja IS 12.1 Koraki uresničevanja projektnega pristopa Vsak projekt gre skozi več faz. Najprej je potrebno sprejeti odločitev o projektu, seveda v povezavi s problemi, ki naj bi jih novi IS razrešil. Nato sledita dve glavni fazi; prva je priprava projekta in druga je izvedba projekta. V upravi sta obe fazi izredno pomembni. V upravi je običajno del priprave projekta povezan z javnim razpisom in izbiro izvajalca na javnem natečaju, v zasebnem sektorju teh problemov ni ali pa jih je bistveno manj. V upravi je priprava projekta izredno pomembna in zato moramo začeti kar s specifikacijo projektne naloge. Če želimo, da bo javni razpis uspešno in pa dobro izveden, potem je potrebno pripraviti čim boljšo specifikacijo na začetku. Od specifikacije projektne naloge je v veliki meri odvisno, kako bo potekal javni razpis in kakšni bodo njegovi rezultati. V javni upravi je v zadnjih letih veliko število javnih razpisov propadlo, ravno zaradi slabe specifikacije projektne naloge. Večina nas pozna nesrečen razpis elektronske dohodnine, ki je propadel dvakrat ali trikrat. Za specifikacijo naloge sledi v upravi razpis in seveda sklenitev pogodbe z izvajalcem. Potem se začne druga faza. To je sama izvedba projekta. 12.2 Priprava projekta Pri pripravi projekta moramo biti pozorni na naslednje:  metodologije vodenja projektov,  projektna pisarna,  vzpostavitveni dokument projekta,  organizacijska struktura projekta. O prvih dveh področjih bomo na kratko spregovorili v tem razdelku, o zadnjih dveh pa podrobneje v nadaljevanju. 12.2.1 Metodologije vodenja projektov Da bi projekt lahko čim bolj celovito in sistematično pripravili in ga potem seveda tudi uspešno izvedli, so se razvile številne metodologije vodenja projektov. Te metodologije so se že prej pogosto pojavljale na drugih področjih, npr. v gradbeništvu. V naši upravi smo v začetku tega tisočletja začeli sistematično razvijati metodologijo vodenja projektov (EMRIS – enotna metodologija razvoja IS) in ta metodologija je bila sprejeta kot neke vrste standard, ki ga skušamo v upravi uporabljati pri vodenju projektov. Je razmeroma dobro dokumentirana in o njej obstaja kar nekaj literature. 12.2.2 Projekta pisarna Večina metodologij vodenja projektov (vključujoč tudi to, ki jo uporabljamo v naši upravi) predpostavlja vodenje posebne projektne pisarne, kot enega ključnega inštrumenta vodenja projektov. V okviru projektne pisarne se vodi in spremlja vsa dokumentacija, povezana z izvajanjem nekega projekta. Z vodenjem projektne pisarne je lahko zelo veliko dela, lahko rečemo administriranja. Včasih se postavlja vprašanje, ali je to dodatno delo vredno rezultatov. V praksi se potem izkaže, da je. Vodenje projektne pisarne se lahko poenostavi, če uporabljamo za to računalniško podporo, ustrezne rešitve, ki obstajajo. Če jo hočemo vzdrževati ročno, brez specializiranih orodij, potem je ta projektna pisarna veliko breme, z uporabo specializiranih orodij pa si seveda delo lahko bistveno olajšamo. 132/136 Projektno vodenje razvoja IS 12.3 Vzpostavitveni dokument projekta (VDP) 12.3.1 Namen VDP To je temeljni dokument vsakega projekta, s katerim opredelimo vse vsebinske in izvedbene značilnosti nekega projekta ter jih predstavimo vsem sodelujočim v projektu. 12.3.2 Priprava VDP Priprava VPD je prva naloga izvajalca projekta. Pripravi ga na podlagi razpisne dokumentacije in ga predstavi vsem sodelujočim v projektu. S tem dokumentom se tudi vidi, ali je izvajalec pravilno razumel cilje in želje naročnika. 12.3.3 Sprejem VDP VDP sprejme naročnik projekta oz. projektni svet kot ključni organ projekta. Ko je VDP potrjen (sprejet), postane obvezujoč za vse sodelujoče strani v projektu (naročnik, uporabnik, izvajalec). Če VDP ni potrjen z vseh strani, izvajalec za svoje delo ni krit; s sprejemom pa dokument dobi pogodbeno veljavnost. 12.3.4 Vsebina VDP Določene elemente VDP lahko izvajalec povzame iz specifikacije naloge, ki je del razpisne dokumentacije, pri čemer mora seveda upoštevati spremembe, do katerih je prišlo v času od priprave specifikacije naloge do dejanskega začetka projekta. Standardni elementi VDP so:  Cilji in namen projekta: kaj želimo s projektom doseči in zakaj (povzeto iz razpisne dokumentacije);  Vsebina projekta: kaj se bo v projektu delalo (povzeto iz razpisne dokumentacije);  Organizacija projekta: kako bodo sodelujoči v projektu organizirani, da bo projekt nemoteno potekal in da bodo doseženi zastavljeni cilji (podrobneje v poglavju 5);  Terminski načrt izvedbe (Slika 59): faze in aktivnosti v projektu podrobno časovno opredeljene vključno s sosledjem izvajanja (kdaj se posamezna aktivnost začne in zaključi, koliko časa traja);  Izdelki projekta; imamo tri vrste izdelkov: vsebinski izdelki (kar v projektu dejansko nastane), izdelki vodenja (npr. VDP) in izdelki kakovosti (opredeljujejo npr. kakovost vsebinskih izdelkov); izdelamo tudi mrežni diagram izdelkov, ki opredeljuje, kako so posamezni izdelki medsebojno odvisni – kako bodo nastajali in v kakšni funkcijski odvisnosti so (Slika 60);  Finančni načrt projekta: opredeliti je potrebno, kako se bo projekt financiral ter kakšni bodo stroški projekta – slednje opredelimo po fazah  Opredelitev odgovornosti: kdo je odgovoren za izvedbo posamezne aktivnosti; pri tem je potrebno poudariti, da so za projekt odgovorne vse vpletene strani, ne samo izvajalec;  Ocena tveganja: opredelimo robne pogoje projekta – pogoje, ki jih ne smemo prekoračiti, pri čemer pa moramo navesti tudi tveganja, ki lahko pripeljejo do prekoračitve, in kako bomo v takih primerih ravnali (kaj lahko npr. povzroči prekoračitve stroškov ali določenih rokov);  Nadzor kakovosti: kakovost je potrebno sistematično spremljati skozi celoten potek projekta (ne le na koncu); za nadzor skrbi neodvisen organ, ki tudi pripravlja izdelke kakovosti. 133/136 Projektno vodenje razvoja IS Slika 59: Terminski načrt izvedbe projekta v obliki gantograma 2000 2001 JEN T T AJA T V C N N L T V C K AR AJ K ID IME POSTOPKA R EP O E EB PR VG EP O E T S O N D JA F M A M JU JU A S O N D Trajanje projekta 1 Vzpostavitev projekta 25 2 Poenotoenje postopkov 150 3 Razvoj Registra postopkov in dokumentov 80 4 Izdelava specifikacije RPID 20 5 Razvoj aplikacije 50 6 Vsebinsko testiranje 10 8 Formiranje baze postopkov in dokumentov 60 9 Metodologija upravnega nadzora in spremljanja 163 10 Katalog življenjskih situacij 30 11 Osnutek sprememb Uredbe in navodil o pisar.poslov. 163 12 Uvajanje registra 63 13 Izdelava metodologije 63 14 Priprava zaključnega poročila 20 15 Vodenje projekta 16 Zagotavljanje kakovosti Slika 60: Mrežni diagram izdelkov projekta 12.4 Organizacija projekta Eden od elementov VDP je tudi organizacija projekta. Poznamo različne organizacijske sheme projekta. Običajno imamo tri organe, ki so zadolženi za spremljanje, nadzor in samo izvedbo nekega projekta (Slika 61). 134/136 Projektno vodenje razvoja IS Slika 61: Organizacijska shema projekta 12.5 Projektni svet Najvišji organ projekta je projektni svet, ki je sestavljen dvopartitno, lahko pa tudi tripartitno. V njem so predstavniki naročnika, predstavniki izvajalca, lahko pa tudi ločeno predstavniki uporabnika. Včasih naročnik in uporabnik ni eno in isto. V upravi je to še pogosto primer. Npr. naroči se projekt, katerega rešitev bodo uporabljale upravne enote. Naročnik je ministrstvo, uporabniki pa so upravne enote. Dobro je, da so v takih primerih vse tri strani vključene v projektni svet. To so naročnik, uporabnik in izvajalec. Projektni svet ima seveda vodjo, ki je predstojnik projekta in je običajno postavljen s strani naročnika. Naloga projektnega sveta je strateška in usmerjevalna, kar pomeni, da usmerja, nadzira in zagotavlja pogoje za uspešno izvedbo projekta. Takoj, ko se ugotovi, da je prišlo do kakršnih koli problemov, ovir, težav, je projektni svet tisti, ki mora ugotoviti, kako te težave odstranit, da bo projekt normalno tekel naprej. Se pravi usmerjevalna, nadzorna in skrbniška. 12.6 Projektna skupina Ta je zadolžena za konkretno izvedbo. Sestavljena je dvopartitno, iz projektnega tima izvajalca, kot so informatiki, računalničarji, in projektnega tima uporabnika. Povedali smo že, da je sodelovanje uporabnikov zelo pomembno, zato morajo biti uporabniki vključeni v to projektno skupino in to že od samega začetka. Le medsebojno sodelovanje teh dveh skupin bo pripeljalo do uspešnih rezultatov. To projektno skupino vodi vodja projekta, ki pa je postavljen s strani izvajalca. 12.7 Nadzor kakovosti Danes je to postala standardna funkcija, kajti kakovost je postavljena v prvi plan in je potrebno zanj sistematično skrbeti. Za nadzor kakovosti mora biti zadolžen nekdo, ki je čim bolj neodvisen od obeh strani, od naročnika in od izvajalca. Ni dobro, da je za nadzor postavljen bodisi nekdo, ki je tako ali drugače vezan na naročnika, npr. preko delovnega razmerja, politično ali kako drugače. Niti ni dobro da je vezan na izvajalca. Skratka to mora biti čim bolj neodvisna oseba, nekdo, ki mu obe strani zaupata in glede nadzora se morata obe strani dogovoriti in zediniti. 135/136 Projektno vodenje razvoja IS Viri in literatura Center za informatiko. (2001). Metodologija vodenja projektov v državni upravi: projekti informacijske tehnologije. Ljubljana: Vlada RS, Center za informatiko. Pridobljeno 29. 9. 2020, s https://nio.gov.si/nio/asset/metodologija+vodenja+projektov+v+drzavni+upravi+projekti+infor macijske+tehnologije-713 Kaj moram vedeti?  Projektno vodenje  Metodologija vodenja projektov – EMRIS  Projektna pisarna  Vzpostavitveni dokument projekta (VDP): namen, priprava in potrditev, vsebina  Izdelki projekta: vsebinski, izdelki vodenja, izdelki kakovosti  Mrežni diagram izdelkov projekt  Organizacijska struktura projekta  Projektni svet  Projektna skupina  Nadzor kakovosti 136/136