Standardni Projekt Elektroni010dkog Uredskog Poslovanja (SPEUP) - Verzija 1.0

REPUBLIKA HRVATSKA
Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0.
Gajeva 4, 10000 Zagreb, Hrvatska telefon: +385 1 6303 355, fax: +385 1 6303 783; e-mail: e-hrvatska@e-hrvatska.hr www.e-hrvatska.hr

Naziv dokumenta: Standardni projekt elektronikog uredskog poslovanja SPEUP Ver. 1.0 31.05.2010. Slubena verzija
SPEUP Ver. 1.0
Oznaka verzije dokumenta: Datum dokumenta: Status dokumenta: Svrha dokumenta: Veza: Cilj: Donositelj:
Definiranje specifikacija funkcionalnih i nefunkcionalnih zahtjeva na sustav za elektroniki podrano uredsko poslovanje s kojima se trebaju uskladiti razliita aplikativna rjeenja za podrku uredskom poslovanju u javnopravnim tijelima. 1. Uredba o uredskom poslovanju (NN 7/2009) 2. Strategija razvoja elektronike uprave u Republici Hrvatskoj za razdoblje od 2009. do 2012. godine Uspostaviti jednoznaan sustav upravljanja elektronikim ispravama Sredinji dravni ured za e-Hrvatsku uz suglasnost Ministarstva uprave
31. svibnja 2010.
2/95

SADRAJ
SPEUP Ver. 1.0
1 2
SAETAK ....................................................................................................................................................................... 6 2.1 SVRHA I CILJ STANDARDNOG PROJEKTA ELEKTRONIKOG UREDSKOG POSLOVANJA ...................................................... 7 2.2 UPOTREBA STANDARDNOG PROJEKTA ELEKTRONIKOG UREDSKOG POSLOVANJA......................................................... 7 2.3 ZNAAJ I OGRANIENJA STANDARDNOG PROJEKTA.............................................................................................................. 8 2.6 ORGANIZACIJA DOKUMENTA ................................................................................................................................................. 11 2.4 STANDARDNI PROJEKT ELEKTRONIKOG UREDSKOG POSLOVANJA I DRUGI SUSTAVI ..................................................... 8 2.5 SUSTAV ZA INTEROPERABILNOST ........................................................................................................................................... 9 2.7 VLASNITVO SPECIFIKACIJE .................................................................................................................................................. 12 3.1 PRAVNI OKVIR U REPUBLICI HRVATSKOJ ........................................................................................................................... 13 PRAVNI OKVIR ......................................................................................................................................................... 13 METODOLOGIJA PRIMJENE STANDARDNOG PROJEKTA U JAVNOPRAVNIM TIJELIMA ................. 15 4.2 PROJEKT UVOENJA ELEKTRONIKOG UREDSKOG POSLOVANJA ..................................................................................... 15 PROCESI UREDSKOG POSLOVANJA ................................................................................................................... 17 3.2 PRAVNI OKVIR U EU............................................................................................................................................................... 14 4.1 SCENARIJI UVOENJA ELEKTRONIKOG UREDSKOG POSLOVANJA ................................................................................... 15 5.1 PLANIRANJE KLASIFIKACIJSKIH I BROJANIH OZNAKA STVARATELJA I PRIMATELJA PISMENA ................................... 18 5.5 ADMINISTRATIVNO TEHNIKA OBRADA AKTA................................................................................................................ 25 5.7 RAZVOENJE I ROKOVNIK PREDMETA ................................................................................................................................. 27 5.8 STAVLJANJE PREDMETA U PISMOHRANU I UVANJE .......................................................................................................... 28 5.9 STATISTIKA I MJERENJE EFIKASNOSTI ................................................................................................................................. 30 PODATKOVNA ARHITEKTURA, ELEKTRONIKE ISPRAVE I XML SHEME ........................................... 31 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 Identifikatori ...................................................................................................................................................... 31 Kodovi/ifre (metapodaci) ........................................................................................................................... 31 Klasa ...................................................................................................................................................................... 32 Urudbeni broj ................................................................................................................................................... 32 Adresa ................................................................................................................................................................... 33 Osoba ..................................................................................................................................................................... 34 Stranka ................................................................................................................................................................. 34 5.2 PRIMITAK, OTVARANJE I PREGLED POILJKI ....................................................................................................................... 18 UVOD .............................................................................................................................................................................. 7
5.3 UPISIVANJE PISMENA ............................................................................................................................................................. 21 5.4 DOSTAVA PISMENA U RAD ..................................................................................................................................................... 23 5.6 OTPREMANJE AKATA.............................................................................................................................................................. 26
6.1 OSNOVNI GRADIVNI BLOKOVI ............................................................................................................................................... 31
31. svibnja 2010.
3/95

6.1.8
6.1.8.1 6.1.8.2 6.1.8.3 6.1.9.1 6.1.9.2 6.1.9.3
e-Dokument......................................................................................................................................................... 36
Administrativni metapodaci ...................................................................................................................... 38 Opisni metapodaci .......................................................................................................................................... 38 Sadraj dokumenta ......................................................................................................................................... 40 Identifikacija e-Pismena ............................................................................................................................... 43 Procesni metapodaci...................................................................................................................................... 44 Elektroniki potpis i vremenska oznaka .............................................................................................. 45
SPEUP Ver. 1.0
6.1.9
e-Pismeno............................................................................................................................................................. 41
6.1.10 6.1.11 6.1.12
e-Prilog ................................................................................................................................................................. 46 e-Predmet ............................................................................................................................................................ 47 e-Poiljka (e-Otpremnica) ............................................................................................................................. 50

6.1.12.1 6.1.12.2 6.1.12.3 6.1.12.4
Omotnica.............................................................................................................................................................. 51 Identifikacija poslovnog procesa ............................................................................................................. 52 Sadraj poiljke................................................................................................................................................. 53
Sigurna dostava poiljki ............................................................................................................................... 51
6.1.13 6.1.14 7
Potvrda primitka poiljke (e-Dostavnica) .............................................................................................. 54 Repozitorij podatkovnih modela ................................................................................................................ 56
7.1 PLANIRANJE DOSJEA I BROJANIH OZNAKA STVARATELJA I PRIMATELJA AKATA ......................................................... 57 FUNKCIONALNI ZAHTJEVI ................................................................................................................................... 57 7.2 PRIMITAK, OTVARANJE I PREGLED POILJKI ....................................................................................................................... 57 7.5 ADMINISTRATIVNO TEHNIKA OBRADA AKTA................................................................................................................ 59 7.7 RAZVOENJE I ROKOVNIK PREDMETA ................................................................................................................................. 61 7.8 STAVLJANJE PREDMETA U PISMOHRANU I UVANJE .......................................................................................................... 62 7.9 STATISTIKA I MJERENJE EFIKASNOSTI ................................................................................................................................. 62 7.4 DOSTAVA PISMENA U RAD ..................................................................................................................................................... 59 7.6 OTPREMANJE AKATA.............................................................................................................................................................. 60 7.10 SUSTAV POVEZIVANJA I SUELJA ZA DRUGE SUSTAVE ....................................................................................................... 64
7.3 ZAPRIMANJE PISMENA ........................................................................................................................................................... 58
7.11 DODATNE FUNKCIONALNOSTI OVLATENJA.................................................................................................................... 65 8.1 ATRIBUTI KVALITETE U RADU SUSTAVA ZA ELEKTRONIKO UREDSKO POSLOVANJE................................................... 67 NEFUNKCIONALNI ZAHTJEVI .............................................................................................................................. 66 8.1.1 8.1.2 8.1.3 8.1.4 8.1.5 8.1.6 Jednostavnost koritenja ............................................................................................................................... 67 Mogunost podravanja rada sustava ..................................................................................................... 69 Pouzdanost .......................................................................................................................................................... 70 Dostupnost .......................................................................................................................................................... 71 Performanse ....................................................................................................................................................... 71 Upravljivost i osmotrivost ............................................................................................................................. 72
31. svibnja 2010.
4/95

8.1.7 8.1.8 8.1.9 8.1.10 8.1.11
Sigurnost .............................................................................................................................................................. 73
SPEUP Ver. 1.0
Otpornost na greke ........................................................................................................................................ 73 Neovisnost o promjenama tehnologije i starenju ................................................................................ 73 Sigurnosna pohrana (backup) .................................................................................................................... 74 Skalabilnost ........................................................................................................................................................ 75
8.2 ATRIBUTI KVALITETE U RAZVOJU SUSTAVA ........................................................................................................................ 75 8.2.1 8.2.2 8.2.3 8.2.4 8.2.5 8.2.6 8.2.7 8.2.8 8.2.9 8.2.10 8.2.11 8.2.12 Mogunost testiranja ...................................................................................................................................... 75 Proirivost ........................................................................................................................................................... 76 Prilagodljivost .................................................................................................................................................... 76 Mogunost lokalizacije ................................................................................................................................... 77 Mogunost viestrukog koritenja modula............................................................................................. 77 Brzina i resursi potrebni za implementaciju ......................................................................................... 77 Metodologija razvoja i implementacije ................................................................................................... 78 Metodologija voenja projekta ................................................................................................................... 78 Metodologija upravljanja promjenama .................................................................................................. 78 Metodologija upravljanja kvalitetom ....................................................................................................... 79 Upravljanje konfiguracijom ......................................................................................................................... 79 Ogranienja......................................................................................................................................................... 80
8.2.12.1 8.2.12.2 8.2.12.3 8.2.12.4 8.2.12.5 8.2.12.6 8.2.12.7 Arhitektura sustava ........................................................................................................................................ 80 Tehnoloka infrastruktura .......................................................................................................................... 80 Tehniki standardi .......................................................................................................................................... 80 Usklaenost s pravnom regulativom ..................................................................................................... 80 Podrka za druge platforme ....................................................................................................................... 81 Interoperabilnost ............................................................................................................................................ 80 Otvorenost .......................................................................................................................................................... 81
ZAKLJUNE PREPORUKE...................................................................................................................................... 82
10 DODACI ....................................................................................................................................................................... 83
10.1 DIJAGRAMI AKTIVNOSTI ........................................................................................................................................................ 83 10.2 POPIS SLIKA ............................................................................................................................................................................. 84 10.3 POPIS TABLICA ........................................................................................................................................................................ 85
11 PRIVITCI OSNOVNOG DOKUMENTA ................................................................................................................. 86
12 REFERENCE ............................................................................................................................................................... 87
31. svibnja 2010.
5/95
SAETAK
SPEUP Ver. 1.0
Sredinji dravni ured za e-Hrvatsku uz suglasnost Ministarstva uprave objavljuje Standardni projekt elektronikog uredskog poslovanja, temeljem kojeg javnopravna tijela pripremaju vlastite projekte implementacije elektronikog uredskog poslovanja. Standardni projekt elektronikog uredskog poslovanja jedan je od kljunih projekata programa e-Ured kojim se uspostavlja elektroniko uredsko poslovanje javnopravnih tijela u Republici Hrvatskoj. Elektronika uprava predstavlja poslovnu pretvorbu djelovanja javnopravnih tijela primjenom informacijsko-komunikacijske tehnologije kojom se cjelokupno poslovanje javne uprave usmjerava prema korisnicima. Elektronika uprava takoer ukljuuje stalnu prilagodbu pravnog i tehnolokog okvira djelovanja javnopravnih tijela u cilju postizanja to vee uinkovitosti rada, racionalnijeg koritenja proraunskih sredstava i kvalitetnijeg pruanja usluga. Stoga e biti potrebno uskladiti aplikacijska rjeenja za uredsko poslovanje sa Standardnim projektom elektronikog uredskog poslovanja. SPEUP predstavlja funkcionalni model modularnog rjeenja zasnovanog na modernim konceptima informacijsko komunikacijske tehnologije za upravljanje, kreiranje i razmjenu elektronikih dokumenata s posebnim naglaskom na upravljanje elektronikim zapisima (ERMS - Electronic Records Management System) u skladu sa zahtjevima koje je preporuila Europska komisija u specifikaciji MoReq2 [EC 2008c]. Referenti zahtjevi sustava po specifikaciji MoReq2 opisani su u Privitku 1 ovog dokumenta.
Uredbom o uredskom poslovanju i Standardnim projektom elektronikog uredskog poslovanja (SPEUP) ureuje se postupanje s pismenima u elektronikom obliku u tijelima dravne uprave, tijelima jedinica lokalne i podrune (regionalne) samouprave te u poslovanju pravnih osoba s javnim ovlastima (u daljnjem tekstu: javnopravna tijela).
31. svibnja 2010.
6/95
UVOD
SPEUP Ver. 1.0
Prema Uredbi o uredskom poslovanju Sredinji dravni ured za e-Hrvatsku uz suglasnost Ministarstva uprave donosi Standardni projekt elektronikog uredskog poslovanja. Za sva struna informatika pitanja miljenje daje Sredinji dravni ured za e-Hrvatsku, dok za pravna pitanja miljenje daje Ministarstvo uprave. Ukoliko u tekstu Standardnog projekta elektronikog uredskog poslovanja doe do eventualnog odstupanja u koritenju pojedinih termina ili u opisima pojedinih procesa u odnosu na Uredbu o uredskom poslovanju, prednost ima Uredba. 2.1 Svrha i cilj Standardnog projekta elektronikog uredskog poslovanja
Upravljanje elektronikim dokumentima i ispravama je kompleksno, zahtijeva veliki broj funkcionalnosti, pa je ova specifikacija vodi za transformaciju postojeih sustava takve namjene, odnosno specifikacija za budue nabave. Cilj je Standardnog projekta elektronikog uredskog poslovanja, postii s jedne strane maksimalnu neovisnost o proizvoaima i dobavljaima programskih rjeenja, a s druge strane osigurati svim javnopravnim tijelima da unato tome to koriste razliita programska rjeenja mogu meusobno razmjenjivati isprave, dokumente i poruke elektronikim putem. 2.2 Upotreba Standardnog projekta elektronikog uredskog poslovanja
Svrha Standardnog projekta elektronikog uredskog poslovanja je definiranje specifikacije obveznih i opcionalnih funkcionalnih i nefunkcionalnih zahtjeva prvenstveno vezanih za rad s elektronikim dokumentima, a s kojima se razliita aplikativna rjeenja podrke uredskom poslovanju u javnopravnim tijelima trebaju uskladiti.
Zahtjevi koji proizlaze iz Standardnog projekta elektronikog uredskog poslovanja definirani su modularno, a njihova implementacija ovisi o razliitim okolinama u kojima e se koristiti. Specifikacija je pisana pod pretpostavkom da sustav uredskog poslovanja ne ukljuuje samo djelatnike u pisarnici, ve i ostale slube u javnopravnim tijelima koje u svom redovnom radu zaprimaju, kreiraju i alju elektronike dokumente i isprave. Budui da je Standardni projekt elektronikog uredskog poslovanja modularan, javnopravna tijela mogu dodavati nove funkcionalnosti specifine za njihove poslovne zahtjeve. Specifikacije iz Standardnog projekta elektronikog uredskog poslovanja mogu se koristiti za: obuku korisnika, pripremu tendera, dobavljae aplikativnih rjeenja kao vodi u pripremi ponuda i rjeenja, provjeru postojeih aplikativnih sustava podrke uredskom poslovanju,
31. svibnja 2010.
7/95
Standardnim projektom elektronikog uredskog poslovanja ne opisuje se funkcioniranje javnopravnih tijela u cjelini, niti pojedini specifini zahtjevi koji se ne mogu u potpunosti obuhvatiti procesima uredskog poslovanja kako su definirani Uredbom. Takoer, ne opisuje se na koji se nain moduli uredskog poslovanja povezuju s drugim aplikativnim podsustavima informacijskog sustava pojedinog javnopravnog tijela, budui da to ovisi o softverskoj arhitekturi tog sustava. 2.4 Standardni projekt elektronikog uredskog poslovanja i drugi sustavi
Standardni projekt elektronikog uredskog poslovanja je praktini alat koji pomae javnopravnim tijelima i dobavljaima aplikativnih rjeenja da bre i efikasnije uspostave funkcionalnosti elektroniki podranog uredskog poslovanja, posebno zaprimanje i otpremu elektronikih isprava graanima i gospodarstvu kao krajnjim korisnicima, te razmjenu elektronikih dokumenata izmeu javnopravnih tijela. Pri tome se opisuju standardizirani procesi uredskog poslovanja u manje sloenim i vrlo sloenim sustavima javnopravnih tijela. 2.3 Znaaj i ogranienja Standardnog projekta
planiranje daljnjeg razvoja informacijskog sustava.
korisnike sustava u javnopravnim tijelima,
SPEUP Ver. 1.0
SUSTAV ZA INTEROPERABILNOST
Zaprimanje e-isprava Dostava e-isprava
GENERIKI MODEL e-UREDA
Primitak
......
dostava UPRAVNI POSTUPCI
POSTUPCI UREDSKOG POSLOVANJA

NEUPRAVNI POSTUPCI
elektronika arhiva
Podsustavi Informacijskog sustava TDU
31. svibnja 2010.
Slika 2.1 Standardni projekt elektronikog uredskog poslovanja u odnosu na druge sustave
8/95
Standardnim projektom elektronikog uredskog poslovanja opisani su procesi uredskog poslovanja prema Uredbi o uredskom poslovanju. Definirani su ulazni i izlazni podaci u okviru kojih je i elektronika isprava koju zaprima, odnosno otprema sustav. Nain povezivanja osnovnih procesa uredskog poslovanja prema drugim podsustavima informacijskog sustava svako javnopravno tijelo definira samostalno. Posebnim projektom elektronike arhive definirat e se zahtjevi vezani za uspostavu elektronike arhive u javnopravnim tijelima i izgradnju zajednikih servisa arhiviranja elektronikih isprava i dokumenata.
SPEUP Ver. 1.0
Uspostava interoperabilnosti predmet je posebnog projekta prema odredbama Hrvatskog okvira za interoperabilnost i projekta uspostave jedinstvenog sustava autentikacije i autorizacije za korisnike objavljenih servisa. Preko sustava za interoperabilnost, javnopravna tijela razmjenjivat e informacije, elektronike dokumente i isprave, te isporuivati korisnicima cjelovite usluge horizontalno povezanih procesa. Elektroniko uredsko poslovanje koristit e sustav za interoperabilnost za razmjenu elektronikih isprava i dokumenata s drugim sudionicima. 2.5 Sustav za interoperabilnost
Javnopravna tijela razvijat e elektronike servise za svoje korisnike, graane, gospodarstvo i druga javnopravna tijela koji e se isporuivati preko sredinjeg internetskog portala javne uprave Mojauprava (http://www.mojauprava.hr).
Slika 2.2 Sustav za interoperabilnost javne uprave
31. svibnja 2010.
9/95
Sustav za interoperabilnost standardizira komunikacijsku infrastrukturu javnopravnih tijela te omoguava razmjenu pismena i ostalih dokumenata s drugim javnopravnim tijelima i ostalim subjektima.
SPEUP Ver. 1.0
Povezivanje aplikacija svaka sa svakom stvaralo bi probleme u odravanju sustava, budui da je kod promjene posluitelja ili komunikacijskog suelja bilo koje aplikacije potrebno promjene unijeti u svim aplikacijama koje s njom komuniciraju. Uvoenje sustava za interoperabilnost omoguit e da sve aplikacije komuniciraju samo s tim sustavom, koji e obavljati funkcije: implementacije poslovnih pravila i povezivanja s drugim tijelima. sigurne dostave poruka, orkestracije poslovnih procesa,
Funkcija sigurne dostave poruka omoguit e komunikaciju izmeu pojedinih aplikacija. Svaka aplikacija komunicirat e iskljuivo sa sustavom za interoperabilnost, dok e se taj sustav brinuti za usmjeravanje poruka, eventualnu promjenu komunikacijskih protokola te dostavu potvrde o prijemu izvornoj aplikaciji. Funkcija orkestracije poslovnih procesa omoguit e povezivanje poruka koje razne aplikacije razmjenjuju u jedinstveni poslovni proces, na nain da e se definirati redoslijed poruka koje se razmjenjuju te akcije/transformacije koje je nad njima potrebno obaviti. Funkcija implementacije poslovnih pravila omoguit e definiranje pravila tko s kim moe komunicirati i pod kojim uvjetima.
Funkcija povezivanja s drugim tijelima omoguit e elektroniku razmjenu pismena s drugim javnopravnim tijelima, pri emu e sustav za interoperabilnost definirati web servise, XML sheme, poslovne procese i scenarije koji e omoguiti sigurnu razmjenu dokumenata, pismena s prilozima i kompletnih predmeta s elektronikim potpisom, adresiranjem primatelja i poiljatelja, potvrdama primitka te specifikacijom poslovnog procesa. Sustav za interoperabilnost e obavljati prijem dokumenta, kreiranje i serversko potpisivanje poruka, odreivanje primatelja i dostavu poruka. Nakon slanja, sustav e prihvaati potvrde primitka od drugih sustava i obavljati osvjeavanje statusa slanja poruka u izvornoj aplikaciji. Scenarij razmjene poruka izmeu dva javnopravna interoperabilnost prikazan je slikom u nastavku. tijela preko sustava za Na prijemnoj strani, sustav za interoperabilnost e prihvaati dolazne poruke, vriti validaciju njihovog sadraja, provjeru poslovnih pravila i dostavljati ih ciljanoj aplikaciji te vraati potvrdu statusa (potvrdu uspjenog prijema ili eventualne poruke o grekama) poiljatelju.
31. svibnja 2010. 10/95

Aplikacija Ministarstvo 1 Min.1 Sustav za interop. Sustav za interoperabinost Sustav za interop. Min 2
SPEUP Ver. 1.0

Aplikacija Ministarstvo 2
Kreiranje dokumenta
Prijem dokumenta
Kreiranje i potpisivanje poruke
Validacija poslovnih pravila
Slanje poruke
Zaprimanje poruke
Validacija/konverzija formata poruke
Osvjeavanje statusa
Prijem potvrde statusa
Slanje potvrde primitka
Usmjeravanje poruke
Zaprimanje poruke
Validacija potvrde i potpisa Validacija poslovnih pravila
Prijem potvrde statusa Usmjeravanje potvrde statusa
Stanje statusa primitka
Osvjeavanje statusa
Prijem potvrde statusa
Dostava poruke aplikaciji
Prijem dokumenta
Slika 2.3 Scenarij razmjene poruka izmeu dva javnopravna tijela preko sustava za interoperabilnost
U uvodnom poglavlju objanjava se znaaj, namjena i upotreba Standardnog projekta, te njegov odnos prema drugim projektima koje Sredinji dravni ured za e-Hrvatsku pokree radi ostvarenja ciljeva Strategije razvoja elektronike uprave u razdoblju od 2009. do 2012. godine. 2.6 Organizacija dokumenta
U poglavlju Pravni okvir dat je osvrt na osnovne zakone koji ureuju elektroniko uredsko poslovanje i odnos Standardnog projekta prema europskim zahtjevima za upravljanje elektronikim zapisima.
31. svibnja 2010.
Standardni projekt elektronikog uredskog poslovanja uvaava preporuke iz nacrta Hrvatskog okvira za interoperabilnost, koji se izrauje na temelju postavki europskog okvira za interoperabilnost (EIF 2.0)
U ostalim poglavljima dokumenta prikazan je model poslovnih procesa prema Uredbi o uredskom poslovanju, opisani su obvezni i opcionalni funkcionalni i nefunkcionalni zahtjevi s kojima se postojea aplikativna rjeenja trebaju uskladiti, odnosno prema kojima se novi sustavi trebaju razvijati, te je objanjena podatkovna struktura koja standardizira strukturu elektronikih isprava za njihovu razmjenu.
11/95
Dozvoljeno je kopiranje i raspaavanje dokumenta u tiskanom i digitalnom obliku uz uvjet da je naveden izvor dokumenta i da su jasno oznaena sva odstupanja od izvornika kao i autori dodanih i/ili promijenjenih dijelova teksta.
Dokument Standardni projekt elektronikog uredskog poslovanja je u vlasnitvu Republike Hrvatske. 2.7 Vlasnitvo specifikacije
U privitcima osnovnom dokumentu nalaze se osvrti na specifikaciju MoReq2, primjeri poslovnih procesa u nekom ministarstvu, primjeri koritenja modela poslovnih procesa (eng. use-case) kao i podatkovni model za razmjenu elektronikih isprava (XML shema). Pored toga, kao pomo javnopravnim tijelima, priloene su i dvije tablice koje slue kao kontrolne liste za provjeru funkcionalnih, odnosno nefunkcionalnih zahtjeva koji se postavljaju na aplikativna rjeenja za elektroniko uredsko poslovanje (eng. check-list), te na kraju rjenik koritenih pojmova.
SPEUP Ver. 1.0
31. svibnja 2010.
12/95
PRAVNI OKVIR
SPEUP Ver. 1.0
Uredba o uredskom poslovanju (NN 7/2009.) ureuje uredsko poslovanje u tijelima dravne uprave, a primjenjuje se i na uredsko poslovanje strunih slubi Hrvatskoga sabora, Vlade Republike Hrvatske, Ureda predsjednika Republike Hrvatske i drugih dravnih tijela, tijela i slubi jedinica lokalne i podrune (regionalne) samouprave te pravnih osoba koje imaju javne ovlasti, ako za uredsko poslovanje nisu doneseni posebni propisi. 3.1 Pravni okvir u Republici Hrvatskoj
Uredbom su definirani osnovni pojmovi elektronike isprave, elektronikog dokumenta te je odreeno postupanje s pismenima u elektronikom obliku sukladno Zakonu o elektronikoj ispravi kojim se ureuje postupanje s elektronikim ispravama. U sluaju kada podnesak ne sadri potvrdu o plaanju pristojbe postupanje je ureeno Zakonom o upravnim pristojbama. Pravilnik o jedinstvenim klasifikacijskim oznakama i brojanim oznakama stvaratelja i primatelja akata ureuje jedinstvene klasifikacijske oznake i identifikatore u uredskom poslovanju.
Zakonom o opem upravnom postupku (NN 47/2009.) ureuju se pravila na temelju kojih tijela dravne uprave i druga dravna tijela, tijela jedinica lokalne i podrune (regionalne) samouprave, pravne osobe koje imaju javne ovlasti, u okviru djelokruga utvrenog na temelju zakona, postupaju i rjeavaju u upravnim stvarima. Ovim je zakonom predvieno da stranke mogu: podnijeti zahtjev za pokretanje postupka ili od njega odustati elektronikim putem izvoditi dokazivanje javnim ili privatnim ispravama i u elektronikom obliku dostaviti podneske u obliku elektronike isprave komunicirati u elektronikom obliku. voditi spis u elektronikom obliku
Tijela dravne uprave mogu:
obavljati dostavu elektronikim putem, na zahtjev ili uz izriit pristanak stranke, odnosno kad je propisano zakonom, izdavati potvrde o injenicama o kojima se vodi slubena evidencija u elektronikom obliku.
13/95
osigurati dostupnost spisa voenih u elektronikom obliku elektronikim putem komunicirati s javnopravnim tijelima i strankama u elektronikom obliku obavjetavati stranku i druge sudionike u postupku elektronikim putem
31. svibnja 2010.
Zakonom o elektronikoj ispravi (NN 150/2005.) definirana je elektronika isprava i ureeno postupanje s elektronikim ispravama. Elektronika isprava je jednoznano povezan cjelovit skup podataka koji su elektroniki oblikovani (izraeni pomou raunala i drugih elektronikih ureaja), poslani, primljeni ili sauvani na elektronikom, magnetnom, optikom ili drugom mediju, i koji sadri svojstva kojima se utvruje izvor (stvaratelj), utvruje vjerodostojnost sadraja te dokazuje postojanost sadraja u vremenu. Uredbom o djelokrugu, sadraju i nositelju poslova certificiranja elektronikih potpisa za tijela dravne uprave (NN 146/2004.) Vlada Republike Hrvatske povjerila je Financijskoj agenciji poslove certificiranja elektronikih potpisa za tijela dravne uprave. Zakon o arhivskom gradivu i arhivima (NN 105/1997., NN 64/2000., NN 65/2009.) ureuje zatitu i uvjete koritenja, uvanje, uporabu i obradu arhivskoga gradiva.
SPEUP Ver. 1.0
Takva svojstva osiguravaju se primjenom naprednog elektronikog potpisa ureenog Zakonom o elektronikom potpisu (NN 10/2002., NN 80/2008.).
Zakon o tajnosti podataka (NN 79/2007), Zakon o zatiti osobnih podataka (NN 103/2003., NN 118/2006., NN 41/2008.), Zakon o informacijskoj sigurnosti (NN 79/2007.) i podzakonski akti stvaraju pravni okvir za klasifikaciju podataka i postupanje s klasificiranim i neklasificiranim podacima, te zahtjevima na njihovu informacijsku sigurnost. Europska pravna steevina relevantna za elektroniko uredsko poslovanje ukljuuje propise o elektronikom potpisu i dostupnosti javnih informacija: 3.2 Pravni okvir u EU
Hrvatsko zakonodavstvo o elektronikom potpisu u potpunosti je usklaeno s europskim propisima. Direktiva o ponovnoj upotrebi informacija javnog sektora (2003/98/EZ) ne obvezuje zemlje lanice da stavljaju na raspolaganje informacije javnog sektora, ali u sluaju stavljanja na raspolaganje ona ureuje jednaka prava na dostupnost takvih informacija pod trinim uvjetima.
Direktiva 1999/93/EZ Europskog parlamenta i Vijea od 13. prosinca 1999. o okviru Zajednice za elektroniki potpis, Direktiva 2003/98/EZ Europskog parlamenta i Vijea od 17. studenog 2003. o ponovnoj upotrebi informacija javnog sektora.
31. svibnja 2010.
14/95
METODOLOGIJA PRIMJENE STANDARDNOG PROJEKTA U JAVNOPRAVNIM TIJELIMA
SPEUP Ver. 1.0
Svako javnopravno tijelo treba formulirati vlastitu strategiju, viziju i ciljeve razvoja elektronikog poslovanja, ovisno o specifinostima svoga poslovanja. Potom je potrebno provesti samoprocjenu spremnosti za elektroniko uredsko poslovanje i odabrati jedan od scenarija uvoenja elektronikog uredskog poslovanja. Konano treba izraditi i implementirati vlastiti projekt elektronikog uredskog poslovanja.
Svako javnopravno tijelo ovaj dokument treba koristiti kao podlogu za izradu vlastitog projekta primjene Standardnog projekta na uredsko poslovanje, uvaavajui pritom specifinosti svoga poslovanja. Za pripremu vlastitog projekta potrebno je provesti samoprocjenu spremnosti za elektroniko uredsko poslovanje i odabrati jedan od scenarija uvoenja elektronikog uredskog poslovanja prema naputcima koji su opisani u nastavku. Scenariji primjene standardnog javnopravnim tijelima: 4.1 Scenariji uvoenja elektronikog uredskog poslovanja projekta elektronikog uredskog poslovanja u
1. Javnopravna tijela koja imaju aplikacijske sustave za uredsko poslovanje trebaju prema priloenoj tablici funkcionalnih zahtjeva provjeriti usklaenost svojih sustava sa specifikacijom, te ovisno o utvrenom stanju i poslovnoj procjeni poduzeti sljedee: 2. Javnopravna tijela koja nemaju aplikacijske sustave za uredsko poslovanje razraditi e primjenu standardnog projekta, te provesti javnu nabavu rjeenja za uredsko poslovanje usklaenog sa standardnim projektom (neovisno da li kao aplikacijski sustav ili kao iznajmljenu uslugu Application Service Provider ASP). b. nabaviti novo ve usklaeno rjeenje. a. nadograditi svoje sustave za podrku uredskom poslovanju,
Pri izradi vlastitog projekta uvoenja elektronikog uredskog poslovanja javnopravno tijelo koristit e generike komponente, odnosno konstruktivne elemente Standardnog projekta elektronikog uredskog poslovanja. Pritom treba analizirati primjerenost komponenti Standardnog projekta svojem okruenju (organizacijskom, procesnom, tehnolokom itd.). U pravilu e biti potrebno prilagoditi generike komponente (arhitekture i modele procesa, arhitekture i modele podataka, modele funkcionalnih i nefunkcionalnih zahtjeva) vlastitom okruenju, vodei pri tom brigu o zahtjevima na procesnu, semantiku i tehnoloku interoperabilnost iz Hrvatskog okvira za interoperabilnost. 4.2 Projekt uvoenja elektronikog uredskog poslovanja
31. svibnja 2010. 15/95
Prilagodba e ukljuivati npr.:
detaljizaciju procesa,
SPEUP Ver. 1.0
identifikaciju i pridruivanje stvarnih organizacijskih, slubenikih, prostornih, IT i ostalih resursa na mjesto generikih resursa u modelima, imenovanje nadlenosti, preciziranje prava pristupa,
Pri izradi vlastitog projekta uvoenja vano je analizirati moe li se u procesu implementacije elektronikog uredskog poslovanja provesti optimizacija vlastitog poslovanja, kako bi se postigli ciljevi postavljeni strategijama Vlade Republike Hrvatske i stratekim dokumentima iz podruja nadlenosti pojedinih tijela.
postavljanje prioriteta, itd.
31. svibnja 2010.
16/95
PROCESI UREDSKOG POSLOVANJA
SPEUP Ver. 1.0
Procesna struktura elektronikog uredskog poslovanja prikazana je na najvioj razini dijagramom:
Slika 5.1 Procesna struktura elektronikog uredskog poslovanja (I dio)
Slika 5.2 Procesna struktura elektronikog uredskog poslovanja (II dio)
31. svibnja 2010.
17/95
5.1 Planiranje klasifikacijskih i brojanih oznaka stvaratelja i primatelja pismena Proces planiranja se sastoji od:
Javnopravna tijela propisuju vlastiti plan klasifikacijskih i brojanih oznaka stvaratelja i primatelja pismena. Donoenja plana klasifikacijskih oznaka, Donoenja plana brojanih oznaka stvaratelja i primatelja pismena. Ustrojavanja pisarnice i pismohrane,
SPEUP Ver. 1.0
Ustrojavanje pisarnice i pismohrane
Ovisno o broju lokacija, veliini ustrojstvenih jedinica i sloenosti poslova, donosi se odluka o broju pisarnica i pismohrana. Mogue je formirati pisarnice i pismohrane samo za odreene vrste poslova. Donoenje plana klasifikacijskih oznaka Plan klasifikacijskih oznaka donosi elnik tijela. Plan klasifikacijskih oznaka sadri sve vrste poslova koje e organizacija izvravati. Klasifikacijske oznake su u planu odreene do razine dosjea. Svakom se predmetu odreuje klasifikacijska oznaka, odnosno pripadnost dosjeu. Preporuke:
Plan se priprema krajem godine za sljedeu godinu. Tijekom godine plan se dopunjava novim oznakama. Oznake koje se prestaju koristiti ne planiraju se za sljedeu godinu. Klasifikacijska oznaka koja je u jednoj godini bila dodijeljena za jednu vrstu posla, ne smije se u nekoj drugoj godini dodijeliti drugoj vrsti posla Ako je mogue, potrebno je za klasifikacijsku oznaku najnie razine (dosje), jednoznano odrediti nadlenu ustrojstvenu jedinicu, kako bi se operativni posao klasifikacije predmeta i imenovanje nadlene ustrojstvene jedinice mogao to vie pojednostaviti i automatizirati.
Donoenje plana brojanih oznaka stvaratelja i primatelja pismena Preporuka:
Brojane oznake stvaratelja akata su jedinstvene oznake svake ustrojstvene jedinice unutar organizacije. Mogu se hijerarhijski razraditi upravna tijela, ustrojstvene jedinice, pojedinani izvritelji. Predmet se rasporeuje na unutarnju ustrojstvenu jedinicu koja je propisana planom. Oznaka stvaratelja akata mora biti jedinstvena.
Proces obuhvaa:
5.2 Primitak, otvaranje i pregled poiljki Primitak pismena i drugih poiljki Potvrda primitka poiljke Otvaranje i pregled poiljki
31. svibnja 2010.
18/95
Primitak pismena i drugih poiljki
Provjera uplaene upravne pristojbe
Primitak pismena i drugih poiljki obavlja ovlateni slubenik u pisarnici ili iznimno ovlateni slubenik u unutarnjoj ustrojstvenoj jedinici ako je za istu ustrojena vlastita pisarnica. Poiljke mogu stii na razliite naine: o stranka predaje osobno podnesak u pisarnicu, odmah na mjesto za upisivanje podneska, o poiljka pristie potanskom slubom, o poiljka pristie elektronikim putem.
Razvrstavanje i rasporeivanje pismena
SPEUP Ver. 1.0
Potvrda primitka poiljke
Potvrda primitka poiljke je potpis ovlatenog slubenika koji je poiljke preuzeo. Potpisuje se primitak poiljki prema propisima potanske slube i drugih poiljki za koje se trai potpis. Poiljke koje glase na ime se ne otvaraju, ve se dostavljaju osobi na koju glase. Ostale poiljke koje se ne otvaraju (povjerljive poiljke, natjeaji i sl.) dostavljaju se elniku tijela, odnosno komisiji naznaenoj na omotnici poiljke. Za poiljke pristigle elektronikim putem na e-mail adresu stranke se odmah nakon zaprimanja poiljke na posluitelju, alje potvrda primitka. Otvaranje i pregled poiljki
Poiljke iji se prijem potvruje upisuju se u knjigu primljene pote. Poiljke pristigle elektronikim putem
Ako se utvrdi da je poiljka pogreno dostavljena, dostavit e se onom kome je upuena. Upisuje se odmah u knjigu otpremljene pote. Nedostaci koji se utvrde se navode u slubenoj biljeci uz otisak prijamnog tambilja.
U poiljci se moe nalaziti jedno ili vie pismena. Potrebno je provjeriti jesu li pristigla pismena u skladu s propisima o elektronikoj ispravi.
Ako se u poiljci osim elektronike isprave nalazi i metastruktura podataka iz koje je mogue automatski odrediti vrstu predmeta, jednoznano identificirati poiljatelja i sve druge potrebne podatke za odreenu vrstu posla, mogue je potpuno automatski otvoriti predmet, registrirati pismeno, odrediti nadlenost i dostaviti predmet s ulaznim pismenom u nadlenu ustrojstvenu jedinicu. Provjera uplaene upravne pristojbe
31. svibnja 2010.
Uz podnesak stranka predaje i dokaz o plaenoj upravnoj pristojbi. Slubenik pisarnice nee zaprimiti podnesak ako nije plaena pristojba. Ako je podnesak stigao potom ili
19/95
elektronikim putem, slubenik pisarnice e ga zaprimiti i staviti slubenu zabiljeku o neplaenoj pristojbi. Razvrstavanje i rasporeivanje pismena
SPEUP Ver. 1.0
Nakon otvaranja i pregleda poiljki, pismena se radi upisivanja u evidencije razvrstavaju na upravne i neupravne te se rasporeuju po unutarnjim ustrojstvenim jedinicama.
Slika 5.3 Dijagram aktivnosti: Primitak, otvaranje i pregled poiljki 1
Opis simbola koritenih u dijagramu aktivnosti nalazi se u poglavlju 10. ovog dokumenta, dok su primjeri procesa uredskog poslovanja opisani u privitku 2, a primjeri modela poslovnih procesa u privitku 3.
1
31. svibnja 2010.
20/95
Pristigli podnesci i vlastiti akti se upisuju u odgovarajue evidencije: urudbeni zapisnik ako se radi o neupravnom postupku ili u upisnik predmeta ako se radi o upravnom postupku. 5.3 Upisivanje pismena Proces obuhvaa: Zaprimanje pismena Otvaranje predmeta Traenje predmeta Upisivanje pismena
SPEUP Ver. 1.0
Zdruivanje e-dokumenta Skeniranje dokumenata
Stavljanje prijemnog tambilja
Novi predmet se pokree na zahtjev stranke koja je predala podnesak ili ako se pismenom pokree novi predmet, odreuje se klasifikacijska oznaka predmeta i otvara novi predmet. Odreuje se i ustrojstvena jedinica koja je nadlena za rjeavanje predmeta i kojoj e se predmet uputiti. Klasifikacijske oznake i nadlene ustrojstvene jedinice se odreuju prema Planu klasifikacijskih i brojanih oznaka stvaratelja i primatelja akata koji je vaei u tekuoj godini. Ispisuje se omot spisa u koji e se spremati pismena. Traenje predmeta Ako se pristigli podnesak ili akt zdruuje s postojeim predmetom potrebno je utvrditi gdje se predmet nalazi. Predmet moe biti u: o u rokovniku predmeta pa se trai vaenje predmeta iz rokovnika, o u radu, u tom sluaju se akt alje internom dostavom do mjesta na kojem je predmet. o pismohrani pa se trai izdavanje predmeta iz pismohrane,
Otvaranje predmeta
Povezivanje i prijenos upisa
Izdavanje potvrde o zaprimanju podneska
Upisivanje pismena
Pismeno se upisuje pod klasifikacijskom oznakom predmeta kojemu pripada. Pismenu se odreuje urudbeni broj.
31. svibnja 2010.
21/95
Zdruivanje e-dokumenta
Pismeno moe biti napravljeno u elektronikom obliku. Sastoji se od jednog ili vie elektronikih dokumenata (e-dokumenti), to su pismeno i njegovi prilozi. Stavljanje prijemnog tambilja
SPEUP Ver. 1.0
Na primljeno pismeno se stavlja otisak prijemnog tambilja. Ako je pismeno u elektronikom obliku zaprima se u sustav na nain odreen lankom 17. i lankom 18. Zakona o elektronikoj ispravi (NN 150/2005.). Prijem elektronike isprave obiljeava se metapodacima, koji osim elemenata klasinog prijemnog tambilja, sadre i elemente iz lanaka 17. i 18. Zakona o elektronikoj ispravi (NN 150/2005). E-dokumenti koji nemaju svojstva elektronike isprave zaprimaju se u sustav na isti nain kao i elektronika isprava. Izdavanje potvrde o zaprimanju podneska Na zahtjev stranke koja neposredno predaje podnesak u pisarnici, izdaje se potvrda o zaprimanju podneska. Potvrda se izdaje u papirnatom obliku, a sadri datum primitka pismena, brojanu oznaku i potpis slubenika pisarnice koji je podnesak primio. Skeniranje dokumenata
Svi e-dokumenti zaprimaju se u sustav i zdruuju s upisanim pismenom. E-dokumenti mogu imati svojstva elektronike isprave, ali i ne moraju.
Za podneske pristigle elektronikim putem potvrda o zaprimanju se alje korisniku odmah nakon zaprimanja poiljke na posluitelju za primanje takvih poruka.
Dokumenti koji ine pismeno i priloge, a izraeni su na papiru, mogu se skenirati i spremiti u sustav. Ne smatraju se e-dokumentom. To su skenirani prilozi koji smanjuju upotrebu papira. Povezivanje i prijenos upisa U evidencijama se upisuje i povezivanje klasifikacijskih oznaka predmeta. Ako se isti predmet vodi pod vie klasifikacijskih oznaka, radi se povezivanje svih predmeta na onaj koji je prvi otvoren.
Ako neupravni predmet postaje upravni i obrnuto, biljei se prijenos upisa na postojeem predmetu i otvara novi predmet.
31. svibnja 2010.
22/95
SPEUP Ver. 1.0
Slika 5.4 Dijagram aktivnosti: Upisivanje pismena
Dostavljanje pismena u rad
5.4 Dostava pismena u rad Nakon to ovlateni slubenik pisarnice zavri upis pismena u urudbeni zapisnik odnosno u upisnik predmeta upravnog postupka, pismena i predmeti dostavljaju se u rad u nadlenu ustrojstvenu jedinicu. Voenje interne dostavne knjige
Osim upisa u urudbeni zapisnik, odnosno u upisnik predmeta upravnog postupka, pismena se, takoer, evidentiraju i u Internoj dostavnoj knjizi.
31. svibnja 2010.
Interna dostavna knjiga omoguava praenje tijeka predmeta i pismena izmeu pisarnice i unutarnjih ustrojstvenih jedinica.
23/95
Referent kojemu je predmet dodijeljen, upisom datum i potpisa u Internu dostavnu knjigu, potvruje primanje pismena u rad. Ovlateni slubenik pisarnice potvruje primitak vraenih predmeta.
Voditelj ustrojstvene jedinice, putem Interne dostavne knjige, potvruje primitak pismena u odjel. Takoer, voditelj ustrojstvene jedinice, odreivanjem brojane oznake referenta, rasporeuje predmet referentu koji e biti nadlean za njegovo rjeavanje.
SPEUP Ver. 1.0
Referent, nakon to je njegov rad na predmetu zavren, rijeene predmete, zajedno s uputom pisarnici, putem Interne dostavne knjige vraa pisarnici. Interna dostavna knjiga se moe voditi na konvencionalan nain, tako da se ispisuje na papir i runo se potvruju primici pismena i predmeta u ustrojstvenim jedinicama i pisarnici, ili u elektronikom obliku. Ukoliko je mogue, potrebno je koristiti dostavu elektronikih pismena kako bi se poslovni proces ubrzao, pojednostavio i smanjili trokovi, posebno ako organizacija ima vie lokacija.
Prednosti voenja interne dostavne knjige u elektronikom obliku su dostupnost knjige u svakom trenutku svim zainteresiranim slubenicima u pisarnici i ustrojstvenoj jedinici, ukidanje nunosti ispisa na papir, poveanje efikasnosti i brzine rada te smanjivanje trokova.
31. svibnja 2010.
24/95
SPEUP Ver. 1.0
Slika 5.5 Dijagram aktivnosti: Dostava pismena u rad
Uredbom o uredskom poslovanju propisani su forma i sadraj neupravnog akta. Potpisivanje akata
Izrada akata
5.5 Administrativno tehnika obrada akta U okviru rada na predmetu, referent zaduen za rjeavanje predmeta vri slubenu prepisku s drugim tijelima ili osobama. U tu svrhu, referent izrauje neupravne akte.
Referent, po potrebi, alje izlazni akt na pregled elniku tijela. elnik tijela pregledava akt te ga, ako je potrebno, vraa referentu na doradu. Nakon to je akt doraen, ovlatene osobe potpisuju akt.
Potpisani akt dostavlja se u pisarnicu na otpremu, zajedno s uputom pisarnici o nainu otpreme. Ako je akt elektronika isprava, potrebno je da bude pripremljen i potpisan u skladu sa Zakonom o elektronikoj ispravi te Zakonom o elektronikom potpisu.
25/95
Uredbom o uredskom poslovanju propisani su nain i forma potpisivanja primjerka akta koji ostaje u spisu.
31. svibnja 2010.
SPEUP Ver. 1.0
Slika 5.6 Dijagram aktivnosti: Izrada i potpisivanje akta
Otpremanje dostavljaem 5.6 Otpremanje akata
Izlazni akt se moe otpremiti konvencionalnim putem, potom ili dostavljaem. Akti koji se otpremaju dostavljaem, upisuju se u dostavnu knjigu za mjesto. Otpremanje putem pote
Otprema akata obavlja se putem pisarnice te se vri u skladu s uputom za otpremu koju je ovlatena osoba upisala prilikom dostave akta za otpremu.
Izlazni akti koji se otpremaju potom, pripremaju se za otpremu i otpremaju na nain utvren propisima potanske slube. Otpremanje elektronikim komunikacijskim kanalima
31. svibnja 2010.
Prema Uredbi o uredskom poslovanju, svi akti koji se dostavljaju potom upisuju se u dostavnu knjigu za potu. Ako je izlazni akt elektronika isprava, potrebno je da akt bude pripremljen u skladu sa Zakonom o elektronikoj ispravi.
26/95
Osim potom ili dostavljaem, elektronika isprava se primatelju moe poslati e-potom ili e se dostaviti na neki na drugi nain prihvaen od zainteresiranih strana, poiljatelja i primatelja. Slanje elektronike isprave e-potom evidentira se u odgovarajuoj dostavnoj knjizi za otpremu elektronike pote.
SPEUP Ver. 1.0
Slika 5.7 Dijagram aktivnosti: Otpremanje pismena
5.7 Razvoenje i rokovnik predmeta Razvoenje predmeta Voenje rokovnika predmeta
Razvoenje predmeta
Proces obuhvaa:
Nakon razvoenja predmet se odlae u pismohranu.

31. svibnja 2010.
Predmet se smatra rijeenim kada je rad referenta na predmetu zavren. Prema uputi referenta slubenik pisarnice razvodi pismena u upisniku predmeta upravnog postupka odnosno urudbenom zapisniku. Upisuje se datum razvoenja i rok uvanja predmeta te stavlja oznaka ''a/a''. Razvedeni predmeti se predaju pismohrani na uvanje.
27/95
Voenje rokovnika predmeta
Prema uputi referenta predmet se sprema u rokovnik predmeta u kojemu se dri do odreenog roka. Rokovnik predmeta se nalazi u pisarnici. Predmet se vadi iz rokovnika i dostavlja u rad referentu: ako je istekao rok. ako pristigne pismeno koje se pridruuje predmetu u rokovniku
SPEUP Ver. 1.0
Slika 5.8 Dijagram aktivnosti: Razvoenje i rokovnik predmeta
Rijeeni predmeti stavljaju se u pismohranu i u njoj uvaju. Na uvanje predmeta u pismohrani primjenjuju se propisi o uvanju arhivske grae. 5.8 Stavljanje predmeta u pismohranu i uvanje Pisarnica pregledava rijeene predmete i predaje ih pismohrani na uvanje. Proces obuhvaa: Odlaganje predmeta u pismohranu Izluivanje predmeta Rukovanje predmetima pohranjenim u pismohrani Izdavanje predmeta iz pismohrane u rad
Odlaganje predmeta u pismohranu

31. svibnja 2010.
Izdavanje predmeta iz pismohrane slubenicima na uvid

28/95
Predmeti koje je pisarnica razvela u evidencijama preuzimaju se i spremaju u pismohranu. Izdavanje predmeta iz pismohrane u rad
SPEUP Ver. 1.0
Pisarnica predaje zahtjev pismohrani za izdavanje predmeta koji se ponovo uzimaju u rad. Pismohrana izdaje traene predmete uz potvrdu o preuzimanju. Izdavanje predmeta iz pismohrane slubenicima na uvid pismohranu.
Iznimno, ako pisarnica zaprimi pismeno kojeg treba pridruiti predmetu koji je u pismohrani, predmet je potrebno ponovno dostaviti u rad nadlenoj ustrojstvenoj jedinici bez izdavanja potvrde. Pismohrana izdaje arhivirane predmete slubeniku na uvid. Slubenik potpisuje potvrdu o preuzimanju predmeta i obvezan je vratiti predmet u odreenom roku. Sve potvrde se evidentiraju u knjigama koje se vode po godinama. Izluivanje predmeta Pismohrana prema evidenciji pronalazi predmete i brine o vraanju predmeta natrag u
Predmeti se u pismohrani uvaju dok ne istekne rok odreen za uvanje svakog predmeta. Nakon isteka roka predmeti se izluuju i unitavaju. Predmeti koji se trebaju uvati trajno, izluuju se i predaju na trajno uvanje nadlenom arhivu.
31. svibnja 2010.
Slika 5.9 Dijagram aktivnosti: Stavljanje predmeta u pismohranu i uvanje
29/95
Sustav izvjetavanja u uredskom poslovanju treba evidentirati aktivnosti vezane uz rad na pismenu odnosno predmetu, a odnose se na unos pismena, otvaranje predmeta, odreivanje nadlene ustrojstvene jedinice za postupanje po predmetu, odreivanje nadlenog referenta za postupanje po predmetu, otpremu pismena, razvoenja predmeta, promjenu statusa predmeta, arhiviranje predmeta. 5.9 Statistika i mjerenje efikasnosti
SPEUP Ver. 1.0
Na temelju zbirnog praenja aktivnosti vezanih uz pismena i predmete, izvjetavanje u uredskom poslovanju treba omoguiti mjerenje efikasnosti rada i uspjenosti poslovanja na razliitim upravljakim razinama, operativno izvjetavanje te, takoer, izradu izvjetaja propisanih zakonom i drugim propisima.
Slika 5.10 Izvjetavanje pretvaranje podataka u korisne informacije
31. svibnja 2010.
30/95
PODATKOVNA ARHITEKTURA, ELEKTRONIKE ISPRAVE I XML SHEME
SPEUP Ver. 1.0
XML shema definira osnovne strukture podataka koji ine gradivne blokove te elektronike dokumente (e-Dokumente), e-Pismeno, e-Prilog, e-Predmet, elektroniku poiljku (e-Poiljku) i elektroniku potvrdu primitka (e-Dostavnicu). 6.1 Osnovni gradivni blokovi 6.1.1 Identifikatori Identifikatori (pismena, predmeta, osoba, stranaka) imaju sljedeu strukturu:
Identifikator je naveden u sadraju elementa, dok se atributima poblie moe definirati domena (organizacija nadlena za administraciju i izdavanje identifikatora) i uloga.
Slika 6.1 XML shema: Identifikator
Podaci koji sadre kodove ili ifre koji dolaze iz kontroliranih rjenika imaju sljedeu strukturu: 6.1.2 Kodovi/ifre (metapodaci)
Vrijednost podatka navedena je u obveznom atributu sifra. Domena iz koje dolaze kodovi (kontrolirani rjenik) definirana je atributom domena koji sadri URI koji identificira domenu.
Slika 6.2 XML shema: Kod/ifra (metapodaci)
U sadraju elementa mogue je navesti tekst koji slui za prikaz vrijednosti korisnicima.
31. svibnja 2010.
31/95
6.1.3 Klasa
Klasa obvezno u tijelu elementa sadri punu oznaku klase, dok opcionalni pojedini atributi identificiraju pojedine sastavne dijelove oznake sukladno Uredbi o uredskom poslovanju.
SPEUP Ver. 1.0
Slika 6.3 XML shema: Klasa
Na isti je nain definirana struktura Urudbenog broja 6.1.4 Urudbeni broj
Tijelo elementa obvezno sadri puni urudbeni broj, dok atributi mogu identificirati njegove pojedine dijelove.
Slika 6.4 XML shema: Urudbeni broj
31. svibnja 2010.
32/95
Adresa ima sljedeu strukturu: 6.1.5 Adresa
SPEUP Ver. 1.0
Slika 6.5 XML shema: Adresa
Adresa je definirana ili nestrukturiranim elementom LinijaAdrese ili strukturiranim Ulica koji sadri atribut KucniBroj, dok se naziv ulice nalazi u sadraju elementa.
Obvezni element adrese je Grad. Naziv grada je u sadraju elementa, a atribut postanskiBroj definira potanski broj.
Opcionalno, adresa moe sadravati i dravu, pri emu se oznaka drave navodi u atributu sifra, a puno ime u dijelu elementa.
31. svibnja 2010.
33/95
Osoba predstavlja fiziku osobu i obvezno je navesti njezino Prezime i Ime, ili Id. Id se po potrebi moe ponavljati ime se omoguava navoenje identifikacijskih oznaka iz vie sustava (npr. OIB, JMBG, userId). 6.1.6 Osoba Opcionalno, mogu se navesti i Titula i Adresa osobe te njezina Funkcija.
SPEUP Ver. 1.0
Slika 6.6 XML shema: Osoba
Stranka je svaka pravna osoba koja se identificira ili Nazivom i opcionalnom Adresom ili identifikatorom Id. Identifikator se moe ponavljati ime se omoguava koritenje razliitih sustava identifikacije (OIB, MB), s time da identifikatori moraju imati razliite atribute domena i uloga. 6.1.7 Stranka Osim identifikatora, stranka moe sadravati jednu ili vie osoba ili organizacijskih jedinica koji slue za interno usmjeravanje poruke unutar informatikog sustava stranke.
31. svibnja 2010.
34/95
SPEUP Ver. 1.0
Slika 6.7 XML shema: Stranka
31. svibnja 2010.
35/95
Prema Uredbi o uredskom poslovanju, dokument je svaki podatak, odnosno svaki napisani, umnoeni, nacrtani, slikovni, tiskani, snimljeni, magnetni, optiki, elektroniki ili bilo koji drugi zapis podatka, fiziki predmet, priopenje ili informacija koji sadrajem i strukturom ine raspoznatljivu i jednoznano odreenu cjelinu povezanih podataka. 6.1.8 e-Dokument
SPEUP Ver. 1.0
Elektroniki dokument (e-Dokument) je bilo koja vrsta elektronikog zapisa koja nema svojstva elektronike isprave. Zaglavlje omoguava identifikaciju dokumenta, bilo pomou Klase i Urudbenog Broja, bilo pomou drugih identifikatora.
e-Dokument moe sadravati opcionalno zaglavlje koje omoguava njegovu identifikaciju, prava, administrativne i opisne metapodatke, ekstenziju i sadraj, te elektroniki potpis i vremenski ig (engl. timestamp). Identifikator Id sadri atribute domena i uloga kako bi se omoguilo koritenje vie identifikatora dodijeljenih tijekom ivotnog ciklusa sustava ili od strane razliitih sustava.
Dokument moe sadravati administrativne i opisne metapodatke koji opisuju njegovo porijeklo i sadraj te proirenje metapodacima iz drugog prostora imena (engl. namespace). Sadraj dokumenta moe biti potpisan elektronikim potpisom i oznaen vremenskim igom (engl. timestamp). Sadraj dokumenta mogu biti kodirani binarni podaci (binarni dokument), XML podaci ili referenca na eksterni dokument.
Povjerljivost sadraja oznaena je elementom Povjerljivo. Kd koji oznaava stupanj povjerljivosti nalazi se u atributu sifra, dok se u sadraj elementa moe staviti tekstualna oznaka. Kodovi za oznaavanje stupnja povjerljivosti nisu predmet ove specifikacije.
31. svibnja 2010.
36/95
SPEUP Ver. 1.0
Slika 6.8 XML shema: e-Dokument
31. svibnja 2010.
37/95
Administrativni metapodaci oznaavaju metapodatke vezane uz autore i nastanak dokumenta. 6.1.8.1 Administrativni metapodaci
SPEUP Ver. 1.0
Stvaratelj oznaava osobu ili organizaciju koja je sudjelovala u nastanku dokumenta. Mogue je navesti vie stvaratelja, a njihove uloge u nastanku sadraja oznaiti u atributu uloga.
Slika 6.9 XML shema: Administrativni metapodaci
Vrijeme nastanka dokumenta nalazi se u elementu VrijemeNastanka. Element sadri ili puno datum i vrijeme ili samo datum u standardnom formatu XML sheme.
Vrsta definira vrstu sadraja dokumenta, npr: zahtjev, rjeenje, zapisnik itd. Ako se radi o dokumentu u standardnom formatu (npr. obrascu), njegov format se moe navesti u elementu Model. DokumentacijskoMjesto oznaava mjesto pohrane izvornog (papirnatog) dokumenta koji je sadraj pismena. Sadraj dokumenta mogue je opisati pomou DublinCore metapodataka: naslov, kljune rijei, kategorija, saetak, jezik i napomene. 6.1.8.2 Opisni metapodaci Naslov sadri naziv dokumenta kako je on identificiran u sustavu. Naslova moe biti vie, pri emu se mogu razlikovati po jeziku ili po ulozi (npr, za web i za mobilnu komunikaciju).
38/95
Element KljucnaRijec sadri kljune rijei koje se koriste za opis sadraja dokumenta.
31. svibnja 2010.
Sadraj dokumenta moe se opisati i elementom Kategorija ako postoji razraena kategorizacijska shema za opis sadraja pismena, kao to je to npr. EUROVOC. Kd
Element Sazetak sadri kratki saetak sadraja dokumenta, element Jezik specificira jezik koriten u sadraju (moe ih biti vie), a Napomena dodatno pojanjenje vezano uz sadraj dokumenta.
Element Subjekt omoguava navoenje imenovanih entiteta (osoba, organizacija itd) koji su vezani uz sadraj dokumenta.
kategorije navodi se u atributu sifra, a kategorizacijska shema moe se dodatno identificirati navoenjem njenog URI-a u atributu domena, dok je naziv kategorije namijenjen prikazu korisnicima i moe se nalaziti u tijelu elementa.
SPEUP Ver. 1.0
Slika 6.10 XML shema: Opisni metapodaci
31. svibnja 2010.
39/95
Sadraj dokumenta (binarni dokument, XML podaci ili referenca na eksterni dokument) nalazi se u elementu Sadrzaj. 6.1.8.3 Sadraj dokumenta
SPEUP Ver. 1.0
Slika 6.11 XML shema: Sadraj dokumenta
31. svibnja 2010.
40/95
Binarni dokumenti nalaze se u elementu BinarniSadrzaj. Budui da binarni dokument nije mogue ukljuiti u XML direktno, potrebno ga je prethodno kodirati algoritmom Base64. Ako je sadraj XML dokument u drugom prostoru imena (engl. namespace), mogue ga je ukljuiti u elementu XmlSadrzaj. Alternativno, dokument se moe referencirati samo elementom DokumentRef, koji sadri URL eksternog dokumenta i opcionalno TipPoruke. Sadraj se moe dodatno opisati i atributima. Atribut id je lokalni identifikator sadraja unutar XML dokumenta.
SPEUP Ver. 1.0
Format oznaava format sadraja pismena. Alternativno, format sadraja se moe oznaiti i navoenjem atributa contentType ili navoenjem aplikacije koja je koritena za izradu sadraja u atributu aplikacija. Ime i ekstenzija binarne datoteke moe se navesti u atributima imeDatoteke i ekstenzija, a moe se oznaiti i njezina veliina u bajtovima prije kodiranja u atributu contentLength. Prema Uredbi o uredskom poslovanju pismeno je podnesak ili akt. 6.1.9 e-Pismeno
Akt je pismeno kojim tijelo odluuje o predmetu postupka, odgovara na podnesak stranke, odreuje, prekida ili zavrava neku slubenu radnju te obavlja slubeno dopisivanje s drugim tijelima odnosno pravnim osobama koje imaju javne ovlasti.
Podnesak je pismeno kojim stranka pokree postupak, dopunjuje, mijenja svoj zahtjev odnosno drugo traenje ili od tog odustaje.
e-Pismeno je pismeno izraeno u elektronikom obliku i pohranjeno u raunalnom sustavu. e-Pismeno sadri identifikacijske oznake, moe biti opisano administrativnim, procesnim i opisnim metapodacima i moe imati definirana prava koritenja, te dodatne metapodatke u nekom drugom prostoru imena (engl. namespace). Vrsta pismena (podnesak ili akt) odreena je procesnim metapodatkom Vrsta. Sadraj pismena moe biti binarni dokument, XML podaci ili referenca na eksterni dokument, a nalazi se u elementu Sadrzaj. Pismeno moe biti elektroniki potpisano i moe imati vremenski ig (engl. timestamp). Pismeno moe imati i priloge, od kojih svaki moe imati administrativne metapodatke, naziv, dokument, te vlastiti elektroniki potpis i vremenski ig. Uloga pojedinog priloga definirana je atributom uloga.
31. svibnja 2010.
41/95
SPEUP Ver. 1.0
Slika 6.12 XML shema: e-Pismeno
31. svibnja 2010.
42/95
Pismeno se primarno identificira ili elementima KLASA i URBROJ ili nekim drugim identifikatorom (npr. poslovnim brojem) Id. Dodatno, pismeno moe biti oznaeno dodatnim identifikatorima (kao to je jedinstvena oznaka pismena ili barkod). Uloga i domena oznake definirane su zasebnim atributima. Ne smiju postojati dva identifikatora koji imaju iste vrijednosti atributa uloga i domena. 6.1.9.1 Identifikacija e-Pismena Opcionalno, moe se identificirati Verzija zapisa o pismenu.
SPEUP Ver. 1.0
Dodatno, pismeno moe identificirati pripadnost jednom ili vie predmeta navoenjem njihove Klase ili oznake u elementu PREDMET, te vezu s drugim pismenima (npr. kada je Akt odgovor na Podnesak) u elementu Veza. Vezano pismeno identificira se na isti nain kao i samo pismeno Klasom i Ur. brojem ili drugim identifikatorom.
Slika 6.13 XML shema: Identifikacija e-Pismena
31. svibnja 2010.
43/95
Procesni metapodaci definiraju poslovni proces. 6.1.9.2 Procesni metapodaci
SPEUP Ver. 1.0
Tip definira je li pismeno podnesak ili akt, a Status definira trenutni status obrade pismena.
Element Vrijednost moe definirati vrijednosti priloene pismenu (npr. biljege) sukladno Uredbi o uredskom poslovanju.
ZadnjiIzmijenio i Odobrio oznaavaju osobe koje su zadnje radile na sadraju odnosno odobrile sadraj pismena, dok Rjesavatelj oznaava osobu koja je zaduena za sljedeu akciju s pismenom.
VrijemeZadnjeIzmjene i VrijemeOdobrenja sadre datum i opcionalno vrijeme zadnje radnje na sadraju ili zapisu pismena odnosno njegovog odobravanja.
Radnje s pismenom (kao to su prijem, otprema ili arhiviranje pismena) mogue je zabiljeiti navoenjem elementa Radnja za svaku pojedinu radnju. Vrsta radnje definirana
Slika 6.14 XML shema: Procesni metapodaci
31. svibnja 2010.
44/95
je elementom Vrsta, a vrijeme radnje elementom Vrijeme koji sadri datum i opcionalno vrijeme. Opcionalni podaci su Kanal koji oznaava komunikacijski kanal preko kojeg je obavljen prijem ili otprema dokumenta, Stranka koja oznaava stranku koja je poslala pismeno ili kojoj je pismeno otpremljeno, Izvrsitelj koji oznaava osobu koja je inicirala ili izvrila radnju, Status koji oznaava status predmeta nakon izvrenja radnje, Verzija koja oznaava verziju zapisa o pismenu te IDPoruke koji identificira poruku kojom je izvrena otprema ili prijem pismena. Redoslijed radnji s pismenom mogue je identificirati atributom redniBroj.
SPEUP Ver. 1.0
Slika 6.15 XML shema: Vrsta radnje
Pismeno se moe potpisati elektroniki koritenjem XMLDSIG formata potpisa, a vrijeme nastanka moe se dodatno oznaiti vremenskim igom (engl. timestamp). 6.1.9.3 Elektroniki potpis i vremenska oznaka
31. svibnja 2010. 45/95
SPEUP Ver. 1.0
Slika 6.16 XML shema: Elektroniki potpis i vremenski ig
Prilog je svaki pisani sastavak ili slikovni prikaz (tablica, slika, crte ili slino) kao i fiziki predmet koji se prilae uz podnesak ili akt radi nadopune, pojanjenja ili dokazivanja njegovog sadraja. 6.1.10 e-Prilog S obzirom da e-Pismeno moe sadravati jedan ili vie priloga, uloga svakog priloga moe se oznaiti atributom uloga na elementu Prilog.
e-Prilog moe sadravati iste administrativne i opisne metapodatke kao i e-Dokument i ePismeno, te proirenje metapodacima u drugom prostoru imena (engl. namespace).
Dokument (sadraj priloga), elektroniki potpis i vremenski ig (engl. timestamp) takoer su isti kao i kod e-Dokumenta i e-Pismena.
31. svibnja 2010.
46/95
SPEUP Ver. 1.0
Slika 6.17 XML shema: Prilog
Predmet (spis) je skup pismena, priloga i drugih dokumenata koji se odnose na isto pitanje ili zadau ili koji na drugi nain ine posebnu cjelinu. 6.1.11 e-Predmet e-Predmet sadri vlastite metapodatke te reference na e-Pismena, e-Priloge i e-Dokumente.
31. svibnja 2010.
47/95
SPEUP Ver. 1.0
Predmet se identificira elementom KLASA i/ili nekim drugim identifikatorom. Identifikatora moe biti vie.
Slika 6.18 XML shema: Predmet
Metapodaci predmeta sastoje se od Naziva predmeta te opcionalnih elemenata Vrsta koji oznaava vrstu predmeta (dodatnu klasifikaciju), DokumentacijskoMjesto koje definira fiziku lokaciju predmeta, NadleznaJedinica koja definira stranku nadlenu za predmet i Subjekt koji navodi stranke, odnosno subjekte povezane s predmetom. Procesni metapodaci predmeta su isti kao i kod e-Pismena. Predmet moe sadravati i reference na dokumente i pismena koji su sadraj predmeta.
31. svibnja 2010.
48/95
SPEUP Ver. 1.0
Dokument se referencira preko imena datoteke, a pismeno preko identifikacije pismena.

Slika 6.19 XML shema: Reference na dokumente i pismena
Referenca moe sadravati i metapodatke koji opisuju njen sadraj.

31. svibnja 2010.
49/95
Krovni element XML poruke za razmjenu sadraja je Posiljka. Poiljka omoguava elektroniko otpremanje dokumenata, pismena i predmeta te vraanje potvrde njihova prijema. 6.1.12 e-Poiljka (e-Otpremnica) Poiljka ima sljedeu strukturu:
SPEUP Ver. 1.0
Slika 6.20 XML shema: e-Poiljka
31. svibnja 2010.
50/95
U elementu Omotnica nalaze se podaci za identifikaciju, usmjeravanje i sigurnu dostavu poruke. 6.1.12.1 Omotnica
SPEUP Ver. 1.0
Kod identifikacije poruke obvezni element je ID, jedinstveni identifikator poruke u transportnom sustavu. Identifikator se koristi za potvrdu prijema poruke kod sigurne dostave i za ponavljanje poruke, pa mora biti jedinstven unutar duljeg razdoblja. Poruka moe imati jednog ili vie primatelja. Primatelj poruke je podatak tipa StrankaTip. 6.1.12.2 Sigurna dostava poiljki
Opcionalni podaci su vremenski ig (engl. timestamp) koji oznaava vrijeme slanja poruke, Redoslijed koji oznaava redni broj poruke u nizu, te Ponavljanje koji se koristi za indikaciju da se radi o ponovljenom slanju prethodno poslane poruke. Ako je sustav ve primio poruku s istim ID, ponovljena poruka se moe ignorirati. Opcionalno, moe se navesti i poiljatelj poruke. Struktura poiljatelja ista je kao i za primatelja.
Sigurna dostava poiljki podrazumijeva traenje i slanje potvrde uspjenog primitka poiljke ili eventualnih poruka o greci.
Traenje potvrde dostave poiljke specificira se postavljanjem atributa traziPotvrdu u elementu SigurnaDostava na vrijednost true. Sustav koji primi poiljku sa traziPotvrdu=true mora vratiti poiljku koja sadrava element PotvrdaPrijema u kojem e vratiti status primljene poruke u elementu Status, te identificirati poiljku koja se potvruje navoenjem njezinog ID-a u elementu IzvornaPoruka ili oznaku dokumenta u elementu IzvorniDokument. Opcionalno se mogu navesti i Timestamp i Slijed parametri izvorne poiljke radi lake identifikacije, te hash klju izvorne poruke u elementu dsig:Reference. Mogue je odjednom potvrditi prijem vie od jedne poiljke ponavljanjem elemenata IzvornaPoruka ili IzvorniDokument, ali samo ako sve imaju isti status. Ako je prilikom prijema ili parsiranja poiljke dolo do greke, greke se mogu vratiti prijemnom sustavu u elementu PorukaGreske. Mogue je vratiti kd pogreke, vrijeme kada se ona dogodila, te tekst poruke o greci. Ako je greaka bilo vie, svaku greku treba vratiti u zasebnom elementu PorukaGreske. Opcionalno, mogue je specificirati i atribut ttl koji oznaava krajnje vrijeme dostave poiljke, atribut ponavljanje koji definira maksimalan broj pokuaja dostave, te atribut interval koji definira minimalni interval izmeu dva pokuaja dostave.
31. svibnja 2010.
51/95
SPEUP Ver. 1.0
Slika 6.21 XML shema: Sigurna dostava poiljki
Paralelno, akcija se moe specificirati i navoenjem parametra Korak, pri emu je vrijednost redni broj koraka u procesu koji treba obaviti sa sadrajem, pri emu je prvi korak oznaen s 0.
31. svibnja 2010.
Mogue je specificirati i jednu ili vie traenih akcija koje treba obaviti sa sadrajem navoenjem njihove oznake u elementu Akcija. Ako akcija ima vie, njihov poredak moe se odrediti atributom redniBroj.
Poslovni proces unutar kojeg se odvija razmjena poiljki mogue je specificirati u elementu PoslovniProces. 6.1.12.3 Identifikacija poslovnog procesa Proces se definira navoenjem njegove ifre u elementu Proces.
52/95
Mogue je specificirati i slanje obavijesti izvornom sustavu nakon zavretka obrade sadraja poruke navoenjem elementa ZavrnaObavijest koji sadri URL na koji treba vratiti povratnu obavijest i opcionalnu oznaku formata poruke u elementu TipPoruke.
SPEUP Ver. 1.0
Slika 6.22 XML shema: Identifikacija poslovnog procesa
6.1.12.4
31. svibnja 2010.
U elementu Sadrzaj mogue je u poruku ukljuiti jedno ili vie Dokumenata, Pismena, Predmeta ili nekih drugih dokumenata u elementu Ekstenzija u nekom vanjskom formatu, pri emu taj vanjski format mora biti oznaen vlastitim prostorom imena (engl. namespace). Sadraj poiljke
53/95
SPEUP Ver. 1.0
Potvrda prijema poiljke mogua je slanjem e-Dostavnice. 6.1.13 Potvrda primitka poiljke (e-Dostavnica)
Struktura reference ista je kao i referenca na dokumente ili pismena koji su sadraj predmeta (DokumentRefTip).
Poiljka moe sadravati i opcionalni DostavniList, koji sadri reference na sve Dokumente, Pismena, Predmete ili druge sadraje poiljke, te ukupni broj stavki brStavki.
Slika 6.23 XML shema: Sadraj poiljke
Dostavnica ima strukturu slinu kao i Otpremnica u Poiljci, te sadri identifikaciju same dostavnice, primatelje, opcionalnog poiljatelja i potvrdu prijema. PotvrdaPrijema sadri jedan ili vie elemenata koji definiraju dokumente, pismena, predmete ili poiljke iji se prijem potvruje.
e-Dostavnica moe takoer biti potpisana elektronikim potpisom i oznaena vremenskim igom (engl. timestamp).
31. svibnja 2010.
54/95
SPEUP Ver. 1.0
Slika 6.24 XML shema: e-Dostavnica
31. svibnja 2010.
55/95
Objava podatkovnih modela ostvaruje se putem web portala sustava za interoperabilnost, te aplikacijskog suelja za pristup shemama i ontologijama (preko web servisa i tehnologija semantikog weba kao to su RDF i OWL).
Nakon uspostave raunalne platforme sustava za interoperabilnost, podatkovni modeli koji su objavljeni u okviru Standardnog projekta elektronikog uredskog poslovanja uvijek se referenciraju na modele unutar sustava za interoperabilnost.
Repozitorij podatkovnih modela sastoji se od repozitorija XML shema i jezgrenih komponenti, te repozitorija metapodataka usluga, dokumenata, sustava i organizacija. Metapodaci usluga, dokumenata sustava i organizacija povezani su u jedinstvenu ontologiju javne uprave. 6.1.14 Repozitorij podatkovnih modela Svi podaci su pohranjeni u raunalnoj platformi sustava za interoperabilnost, koja sadri i alate za modeliranje XML shema i upravljanje ontologijama.
SPEUP Ver. 1.0
Podatkovni model za razmjenu elektronikih isprava putem XML sheme prikazan je u Privitku 4. ovog dokumenta.
31. svibnja 2010.
56/95
FUNKCIONALNI ZAHTJEVI
SPEUP Ver. 1.0
Kod definiranja zahtjeva za bilo koji tehniki i organizacijski sustav razlikujemo funkcionalne i nefunkcionalne zahtjeve. Najjednostavnije reeno, funkcionalni zahtjevi opisuju to sustav treba raditi. Funkcionalni zahtjevi opisani su za svaki od procesa koji je prikazan u poglavlju 5. Procesi uredskog poslovanja. Za realizaciju ovog procesa, potrebno je podrati sljedee funkcionalnosti: Dodavanje nove pisarnice Priprema klasifikacijskih oznaka za sljedeu godinu Otvaranje novih dosjea tokom godine Deaktiviranje / ukidanje klasifikacijske oznake 7.1 Planiranje dosjea i brojanih oznaka stvaratelja i primatelja akata Mogunost koritenja samo propisanih glavnih grupa, grupa, podgrupa i djelatnosti; potreban jedinstveni ifrarnik Pretraivanje klasifikacijskih oznaka; mogunost pretraivanja po svim godinama Priprema unutarnjih ustrojstvenih jedinica za sljedeu godinu Deaktiviranje / ukidanje ustrojstvenih jedinica Pretraivanje ustrojstvenih jedinica Dodavanje novih unutarnjih ustrojstvenih jedinica tokom godine Dodavanje brojanih oznaka pojedinanih izvritelja Ukidanje brojane oznake pojedinanog izvritelja Pretraivanje pojedinanih izvritelja Preuzimanje poiljke
Mogunost koritenja samo propisanih stvaratelja akata na razini drave; potreban jedinstveni ifrarnik Promjena brojane oznake i naziva unutarnjih ustrojstvenih jedinica
Za poiljke pristigle elektronikim putem potrebno je podrati sljedee funkcionalnosti: 7.2 Primitak, otvaranje i pregled poiljki Slanje potvrde prijema poiljke poiljatelju; (automatski sa posluitelja) Provjera tehnike ispravnosti poiljke i formata sadraja poiljke
31. svibnja 2010.
57/95
Slanje obavijesti u sluaju da se poiljka ne moe proitati iz tehnikih razloga ili poiljka nije u jednom od standardnih formata koji je izabran za razmjenu elektronikih isprava Zapisivanje tonog vremena zaprimanja poiljke na posluitelju (time stamp) Prikazivanje poiljke na popisu novozaprimljenih poiljki Zapisivanje komunikacijskog kanala kojim je poiljka dostavljena Mogunost automatskog upisivanja jednog ili vie pismena iz poiljke; samo za strukturirane i aplikativno podrane vrste posla
SPEUP Ver. 1.0
Ostale funkcionalnosti, neovisne o putu kojim je poiljka pristigla su: Upisivanje primljene pote Pretraivanje poiljki po razliitim kriterijima
Evidentiranje slubene biljeke o neplaenoj upravnoj pristojbi
Za realizaciju ovog procesa, potrebno je podrati sljedee funkcionalnosti: 7.3 Zaprimanje pismena Ispisivanje omota spisa (kouljica predmeta)
Izbor unutarnje ustrojstvene jedinice kojoj se predmet upuuje na rjeavanje Vaenje predmeta iz rokovnika; evidentira se promjena na predmetu Zahtjev za izdavanje predmeta iz pismohrane, ako je predmet u pismohrani
Otvaranje predmeta; upisivanje novog predmeta u neki od postojeih dosjea
Traenje i prikaz pojedinanog predmeta; utvrivanje gdje se predmet nalazi Upisivanje pismena, urudbenog broja i ostalih podataka koje trai evidencija u koju se upisuje; povezano s predmetom kojem se pridruuje pismeno
Pridruivanje pristiglih e-dokumenata uz pismeno; upisivanje osnovnih podataka o e-dokumentu, dohvaanje e-dokumenta (folder ili pristigla pota) i njegovo spremanje u sustav Skeniranje pismena i pridruivanje skeniranog priloga pismenu Pretraivanje predmeta po razliitim kriterijima Povezivanje predmeta
Priprema potvrde o zaprimanju podneska; ispis na papir ili formiranje edokumenta koji e se poslati na e-mail adresu stranke Formiranje popisa pismena koja se upuuju u pojedine ustrojstvene jedinice; interna dostavna knjiga
58/95
31. svibnja 2010.
7.4 Dostava pismena u rad Dostavljanje pismena u rad
SPEUP Ver. 1.0
Otvorene predmete je potrebno to prije dostaviti u rad. Koliko je mogue, potrebno je koristiti elektroniku dostavu, tj. dostavu elektronikih pismena, kako bi se poslovni proces ubrzao, pojednostavio i smanjili trokovi, posebno ako organizacija ima vie lokacija. Potrebne funkcionalnosti: Voenje Interne dostavne knjige Evidentiranje dostave predmeta / pismena iz pisarnice u ustrojstvenu jedinicu Upis potvrde primitka predmeta / pismena kod referenta Upis potvrde primitka predmeta / pismena iz pisarnice u ustrojstvenu jedinicu
Upis potvrde primitka rijeenih predmeta / pismena u pisarnici Pregled i ispis dostavne knjige
Upis dostave rijeenih predmeta / pismena iz ustrojstvene jedinice u pisarnicu
Pretraivanje dostavne knjige po razliitim kriterijima (datum upisa pismena, klasifikacijska oznaka i urudbeni broj, nadlena ustrojstvena jedinica, i sl.) Oznaavanje predmeta i pismena bar kod oznakama radi lake manipulacije
Mogunost elektronike dostave u rad pismena koja su zaprimljena elektronikim putem
Ako je izlazni akt elektronika isprava, potrebno je da bude pripremljen u skladu sa Zakonom o elektronikoj ispravi. Akti se izrauju u potrebnom broju primjeraka, osim ako se izrauju elektronikim putem.
31. svibnja 2010.
Forma i sadraj osnovnih dijelova neupravnog akta (zaglavlje, adresa primatelja, oznaka predmeta, tekst akta, potpis ovlatene osobe, otisak slubenog peata), te dodatnih dijelova (nain otpreme akta, dostava upravnih akata, i ostalo) propisana je Uredbom o uredskom poslovanju. Izrada akata
Izrada akata vri se u skladu s Uredbom o uredskom poslovanju. Akti se u elektronikom formatu kreiraju u jednom od formata koje je organizacija izabrala kao svoj standard. Nuno je da izabrani standardni formati zadovoljavaju sve zahtjeve u skladu sa Zakonom o elektronikoj ispravi i Zakonom o elektronikom potpisu. 7.5 Administrativno tehnika obrada akta
59/95
Potrebne funkcionalnosti:
Automatska popuna akta podacima iz pismena i/ili spisa Elektroniko potpisivanje akta Upravljanje statusima akta Rjeavanje vie predmeta jednim aktom
Mogunost upisa upute za otpremu
Mogunost izrade forme i sadraja akta prema digitalnom predloku
SPEUP Ver. 1.0
Potpisivanje akata
Elektroniko potpisivanje akta mora biti provedeno u skladu sa Zakonom o elektronikoj ispravi. Potrebne funkcionalnosti: Evidentiranje kada je akt poslan na potpisivanje Evidentiranje kada je potpisivanje izvreno Dostava akta na otpremu Dostava od osobe koja je izradila akt do ovlatenog potpisnika
Ispis elektroniki potpisanog akta (u skladu sa Zakonom o elektronikoj ispravi) Ovjera ispisanog primjerka od strane ovlatene osobe
7.6 Otpremanje akata
Otprema akata vri se u skladu s uputom za otpremu koju je ovlatena osoba, koja rjeava predmet, upisala prilikom dostave akta za otpremu. Akti se mogu otpremiti dostavljaem, potom, ili elektronikim komunikacijskim kanalima.
Akti koje dostavlja dostavlja upisuju se u dostavnu knjigu za mjesto. Akti koji se otpremaju potom evidentiraju se u dostavnoj knjizi za potu. Akti koji se otpremaju elektroniki upisuju se u dostavnu knjigu za otpremu elektronikim komunikacijskim kanalima. Dostavna knjiga za mjesto i dostavna knjiga za potu propisane su Uredbom o uredskom poslovanju. Potrebne funkcionalnosti:
31. svibnja 2010.
Otpremanje dostavljaem
Potvrda primitka
Pregled i ispis dostavne knjige za mjesto
60/95
Pregled i ispis popisa pismena za dostavu Ispis kuverti s adresama
Pretraivanje popisa pismena prema razliitim kriterijima Potvrda primitka (broj preporuke, podaci o uruenju) Pregled i ispis dostavne knjige za potu Pregled i ispis popisa pismena za otpremu
SPEUP Ver. 1.0
Otpremanje putem pote
Otpremanje elektronikim komunikacijskim kanalima
Pretraivanje popisa pismena koja se otpremaju potom prema razliitim kriterijima
Evidentirati datum i vrijeme otpreme s posluitelja poiljatelja Pregled i ispis popisa pismena koja se alju Pretraivanje popisa pismena prema razliitim kriterijima
Evidentirati datum i vrijeme primitka poiljke od strane primatelja (informacijski sustav ili poiljatelj osobno)
7.7 Razvoenje i rokovnik predmeta Razvoenje predmeta; evidentira se promjena na predmetu i upisuju propisani podaci Formiranje popisa predmeta za dostavu u pismohranu
Potrebne su sljedee funkcionalnosti:
Stavljanje predmeta u rokovnik; evidentira se promjena na predmetu i upisuju propisani podaci Formiranje popisa predmeta kojima istjee rok Vaenje predmeta iz rokovnika; evidentiranje promjene na predmetu Pridruivanje predmeta koji se vadi iz roka na internu dostavnu knjigu
31. svibnja 2010.
61/95
Potrebne su sljedee funkcionalnosti:
7.8 Stavljanje predmeta u pismohranu i uvanje
SPEUP Ver. 1.0
Prilikom izdavanja predmeta iz pismohrane u rad evidentira se promjena na predmetu, predmet se vraa u rad Izrada popisa predmeta koji se iz pismohrane izdaju u rad Potvrda preuzimanja predmeta u rad Evidentiranje izdavanja predmeta iz pismohrane slubeniku na uvid
Formiranje potvrde o izdavanju predmeta na uvid
Formiranje popisa izdanih predmeta (knjiga reversa koja se sastoji od potvrda o izdanim predmetima) Vraanje izdanog predmeta
Ispis potvrde o izdavanju predmeta; potvrda se stavlja na mjesto predmeta u pismohrani Izluivanje predmeta; evidentira se promjena na predmetu Zabrana promjene podataka o izluenim predmetima Uvid u provedena izluivanja Predavanje podataka nadlenom arhivu
Izrada popisa dosjea i predmeta koji se izluuju; predmeti kojima je istekao rok uvanja
7.9 Statistika i mjerenje efikasnosti Upravljake izvjetaje Operativne izvjetaje
Za potrebe upravljanja sustavom uredskog poslovanja potrebno je osigurati: Izvjetaje propisane zakonima ili drugim propisima
31. svibnja 2010.
62/95
SPEUP Ver. 1.0
Slika 7.1 Organizacija izvjetavanja
Sustav za elektroniko uredsko poslovanje mora omoguiti mjerenje efikasnosti javnopravnih tijela prema predmetima koji predstavljaju njihove kljune poslovne procese.
U tim procesima treba evidentirati aktivnosti vezane uz rad na pismenu odnosno predmetu, a odnose se na unos pismena, otvaranje predmeta, odreivanje nadlene ustrojstvene jedinice za postupanje po predmetu, odreivanje nadlenog referenta za postupanje po predmetu, otpremu pismena, razvoenja predmeta, promjenu statusa predmeta, arhiviranje predmeta. Nad predmetima je potrebno mjeriti parametre kao to su primjerice trajanje postupanja po predmetu, vrijeme izmeu razliitih aktivnosti, trajanje rada na predmetu po djelatnicima, itd. kako bi se mogla ustanoviti eventualna prekoraenja graninih vrijednosti. Na osnovu zbirnog praenja aktivnosti na pismenima i predmetima, sustav treba omoguavati kvalitetno izvjetavanje i analizu uspjenosti svakog zaposlenika, ustrojstvene jedinice i tijela u cjelini. Zbirno se prati i izvjetajno prikazuje broj predmeta i broj pismena.
31. svibnja 2010.
63/95
Dimenzije su podaci koji opisuju jedan aspekt praenja poslovanja. Izvjetaji u uredskom poslovanju trebali bi sadravati sljedee dimenzije: vrsta evidencije ( neupravni postupak, UP/I, UP/II) klasa odnosno dosje upravno podruje vrijeme (dnevni, mjeseni, kvartalni, godinji)
SPEUP Ver. 1.0
razina poslovnog odluivanja (uprava, upravna tijela, organizacijske jedinice, referenti) status rijeenosti (rijeeni predmeti po statusima, nerijeeni predmeti po statusima)
Primjeri standardnih izvjetaja:
Funkcionalnosti prilikom razmjene podataka izmeu sustava: Grupni uvoz (import) podataka iz drugog sustava Zaprimanje elektronikih dokumenata Univerzalni web servisi za:
Sustav treba omoguiti i koristiti mehanizme povezivanja i razmjene podataka s drugim sustavima, bez obzira na tehnologiju i izvor te lokaciju podataka, uz mogunost kontrole podataka. 7.10 Sustav povezivanja i suelja za druge sustave
Izvjetaj 4: Broj predmeta neupravnog postupka/upravnog postupka za izabrano upravno podruje, po razinama poslovnog odluivanja, u odreenom razdoblju
Izvjetaj 3: Broj predmeta neupravnog postupka/upravnog postupka za izabrane klase, po razinama poslovnog odluivanja, u odreenom razdoblju
Izvjetaj 2: Broj nerijeenih predmeta neupravnog postupka/upravnog postupka, po razinama poslovnog odluivanja, prema statusu rijeenosti u odreenom razdoblju
Izvjetaj 1: Broj rijeenih predmeta neupravnog postupka/upravnog postupka, po razinama poslovnog odluivanja, prema statusu rijeenosti u odreenom razdoblju
Povezivanje se treba omoguiti radi razmjene podataka bez potrebe ljudskog angamana, odnosno ponovnog unosa (prepisivanja) podataka iz jednog aplikacijskog sustava u drugi. Ugraivanje podataka prijemnog tambilja na elektroniki dokument
31. svibnja 2010.
o promjenu statusa predmeta iz drugog sustava
o otvaranje predmeta iz drugih sustava
o registriranje pismena iz drugih sustava
64/95
o provjeravanje i pretraivanje predmeta o provjeravanje i pretraivanje pismena o pridruivanje poslovnog subjekta spisu Definiranje vie dokumentacije. komunikacijskih
o promjenu statusa pismena iz drugog sustava
o otvaranje i uvid u predmet iz drugog sustava ovisno o ovlastima o otvaranje i uvid u pismeno iz drugog sustava ovisno o ovlastima
SPEUP Ver. 1.0
o pridruivanje poslovnog subjekta pismenu
Definirani XML formati dokumenata za razmjenu podataka s drugim sustavima Evidencija zaprimljenih elektronikih dokumenata kanala za dostavu
elektronike
7.11 Dodatne funkcionalnosti ovlatenja
Ovlatenja za obavljanje pojedinih poslova u sustavu su dodatna funkcionalnost. Odnose se na sve poslovne procese. Svakom korisniku sustava dodjeljuju se odgovarajua ovlatenja za rad, a sustav dozvoljava rad prema ovlatenjima. Zahtjevi su: ovlatenje za obavljanje pojedinih funkcija ovlatenje za rad na odreenom skupu predmeta ovlatenje za uvid u odreeni skup predmeta
ovlatenje za rad na sadraju odreenih dokumenata ovlatenje za uvid u sadraj odreenih dokumenata.
Svi ovdje opisani funkcionalni zahtjevi pobrojani su i prikazani u tablinoj formi u Privitku 5. kao kontrolna lista.. Uz pomo te liste mogue je nainiti provjeru da li i u kojem opsegu postojei informacijski sustav za podrku uredskom poslovanju udovoljava postavljenim funkcionalnim zahtjevima.
31. svibnja 2010.
65/95
NEFUNKCIONALNI ZAHTJEVI
SPEUP Ver. 1.0
Nefunkcionalni zahtjevi definiraju razinu kvalitete s kojom sustav treba izvravati svoje funkcije, a uobiajeno se dijele u dvije grupe:
Osim toga, u nefunkcionalne zahtjeve se mogu svrstati i ogranienja na karakteristike sustava koja proizlaze iz uvjeta u kojima sustav radi ili svojstava okoline. Slika 8.1. prikazuje taksonomiju nefunkcionalnih zahtjeva na sustav s primjerima zahtjeva iz svake kategorije.
zahtjeve ili atribute kvalitete u radu sustava (engl. run-time requirements, execution qualities) i zahtjeve ili atribute kvalitete u razvoju sustava (engl. development requirements, evolution qualities).
Meu atribute kvalitete u radu sustava moemo ubrojiti jednostavnost koritenja, mogunost podravanja rada sustava, pouzdanost, dostupnost, performanse, pristupanost osobama s posebnim potrebama, upravljivost i osmotrivost, sigurnost, otpornost na greke, sigurnosnu pohranu (backup), neovisnost o promjenama tehnologije i starenju, skalabilnost i druge zahtjeve koji opisuju kvalitetu sustava na nain na koji ju percipiraju korisnici i administratori tijekom rada sa sustavom. U atribute kvalitete u razvoju sustava moemo ubrojiti. (i) interna svojstva sustava koja omoguavaju laki razvoj i implementaciju i (ii) svojstva procesa voenja razvoja i implementacije. Pod interna svojstva sustava moemo svrstati mogunost testiranja, proirivost, prilagodljivost, mogunost lokalizacije, mogunost viestrukog koritenja modula i sl. U svojstva procesa razvoja i implementacije moemo ubrojiti brzinu i potrebne resurse za razvoj i implementaciju, metodologije razvoja i implementacije, metodologiju voenja projekta, metodologiju upravljanja promjenama, metodologiju upravljanja kvalitetom, upravljanje konfiguracijom i druge atribute procesa.
31. svibnja 2010.
66/95

Nefunkcionalni zahtjevi
SPEUP Ver. 1.0
Atributi kvalitete u radu sustava
Atributi kvalitete u razvoju sustava
Ogranienja
Jednostavnost koritenja Mogunost podravanja rada sustava Pouzdanost Dostupnost Performanse Upravljivost i osmotrivost Sigurnost Otpornost na greke Neovisnost o promjenama tehnologije i starenju Backup Skalabilnost i drugi
Mogunost testiranja Proirivost Prilagodljivost Mogunost lokalizacije Mogunost viestrukog koritenja modula Brzina i resursi za implementaciju Metodologija razvoja i implementacije Metodologija voenja projekta Metodlogija upravljanja promjenama Metodlogija upravljanja kvalitetom Upravljanje konfiguracijom i drugi
Arhitektura sustava Tehnoloka infrastruktura Tehniki standardi Usklaenost s pravnom regulativom Interoperabilnost Otvorenost Podrka za druge platforme i druga
Ogranienja na sustav mogu biti zahtjevi da sustav bude izraen prema odreenom arhitekturalnom konceptu, da se temelji na odreenoj tehnolokoj infrastrukturi, da je usklaen s tehnikim standardima i pravnom regulativom, da je interoperabilan s drugim sustavima i otvoren za povezivanje, da se moe prebaciti i na druge platforme i slino. 8.1 Atributi kvalitete u radu sustava za elektroniko uredsko poslovanje 8.1.1 Jednostavnost koritenja Jednostavnost koritenja (eng. usability) je svojstvo sustava da primarnim ciljanim grupama korisnika omoguava jednostavno ostvarenje ciljeva s kojima koriste sustav. Jednostavnost koritenja obuhvaa, meu ostalim, sljedee atribute sustava: jednostavno uenje kako se radi sa sustavom, efikasnost i brzinu kojom uvjebani korisnici ostvaruju svoje ciljeve koristei sustav,
Slika 8.1 Taksonomija nefunkcionalnih zahtjeva
31. svibnja 2010.
67/95
laku pamtljivost kako se sustav koristi i nakon duljeg vremena nekoritenja sustava, broj i ozbiljnost greaka koje korisnici rade dok upotrebljavaju sustav te sposobnost sustava da se oporavi od tih greaka, zadovoljstvo korisnika dok rade sa sustavom. dizajn korisnikog suelja. usklaenost s poslovnim procesima i
SPEUP Ver. 1.0
Na jednostavnost koritenja sustava presudno utjeu dva aspekta sustava:
Usklaenost s poslovnim procesima je kljuna za jednostavnost koritenja sustava jer omoguava korisniku da se integrira sa sustavom na nain koji mu je prirodan za posao koji obavlja. Sustav prirodno slijedi procesne korake i prati korisnika u uobiajenom slijedu aktivnosti koje obavlja. Sustav koji nije na taj nain usklaen s procesima korisnici e doivjeti kao teak, neintuitivan, nespretan i sl. Suelje mora biti dizajnirano u skladu s pravilima i dobrom praksom za jednostavnost koritenja web-aplikacija. Ta pravila se odnose na prisutnost, izgled i ponaanje standardnih elemenata suelja, konzistentnost, grafiki dizajn, nain obrade greaka, funkcije pomoi korisnicima i drugo. Kod definiranja nefunkcionalnih zahtjeva, naruitelj treba odrediti primarne grupe korisnika i uestalost izvoenja pojedinih procesa ili usluga na sustavu, kako bi se suelje sustava moglo dizajnirati da bude jednostavno za koritenje. Neki od moguih zahtjeva na jednostavnost koritenja su: Sustav treba grafiki prikazati procesne korake i oznaiti korak u kojem se proces trenutno nalazi. Transakcije koje se najee provode moraju biti dizajnirane tako da se mogu izvesti s najmanjim brojem interakcija (pritisaka na tipke mia ili tipkovnice).
Sustav treba sadravati pomo (on-line help) za sve funkcionalnosti. Pomo mora biti organizirana na dva naina: (i) preko kljunih rijei i elemenata suelja i (ii) preko opisa procesa (Kako?). Sve poruke o grekama moraju biti jasne, kako bi korisnik razumio u kojem je statusu transakcija i kako moe ispraviti greku ili odustati od procesa. Pravila i ponaanje korisnikog suelja moraju biti konzistentni kroz cijeli sustav, ukljuujui prozore, izbornike i komande.
Sustav mora ponuditi smislene podrazumijevane vrijednosti (engl. default value) u sva polja za unos podataka gdje to ima smisla. Podrazumijevane vrijednosti mogu biti unaprijed fiksirane, definirane od strane korisnika, prenesene iz prethodnog unosa ili odreene prema kontekstu.
31. svibnja 2010.
68/95
Mogunost podravanja rada sustava (engl. supportability) obuhvaa razliite elemente podrke i odravanja koju treba pruati za vrijeme eksploatacije sustava. Neki od elemenata podrke koje bi trebalo osigurati su: 8.1.2 Mogunost podravanja rada sustava elementi produkcijske podrke o o o help-desk usluge o o o o o edukacija korisnika instalacija, konfiguracija i nadzor rada sustava podrka korisnicima u radu sa sustavom putem telefona, e-pote, web stranica i sl. sistemsko odravanje, odravanje baza podataka, odravanje aplikacija preventivne zamjene hardvera i sistemskog softvera ispravljanje greaka i uklanjanje kvarova
SPEUP Ver. 1.0
elementi preventivnog odravanja
praenje dogaaja u radu sustava
identifikacija i izvjeivanje o izvanrednim dogaajima u radu sustava
elementi korektivnog odravanja o o
elementi tehnolokog odravanja o
dokumentacija o
zamjena aplikacijske programske opreme novim verzijama kada one budu raspoloive
prilagodbe i dogradnje sustava prema zahtjevima korisnika, promjeni regulative i poslovnih procesa o o tranzicija sa starih sustava o podrka u definiranju i analizi zahtjeva provedba dogradnji i prilagodbi prijenos podataka i probni rad
tehnika i korisnika dokumentacija
prilagodbe aplikacijske programske opreme i podataka novim verzijama programskih alata
31. svibnja 2010.
Posebno je vano utvrditi zahtjeve za brzinu odziva i rokove uklanjanja kvarova. Preporuljivo je kategorizirati kvarove u nekoliko kategorija prema utjecaju na rad sustava
povezivanje s drugim sustavima u istom ili drugim javnopravnim tijelima.
69/95
te odrediti vrijeme odziva i garantirano vrijeme popravka kvara za svaku kategoriju. Primjer takve kategorizacije kvarova nalazi se u sljedeoj tablici:
Tablica 8.1 Kategorizacija kvarova sustava
SPEUP Ver. 1.0
Prioritet nivoa A (Potpuni pad sustava) Prioritet nivoa B (Djelomini pad sustava) Prioritet nivoa C (Znaajan utjecaj) Prioritet nivoa D (Ogranien utjecaj)
Poslovni proces je u potpunosti stao.
Poslovni proces je u funkciji ali znatno otean. Poslovni proces je ugroen, ali u funkciji. Potreban nadzor ponaanja sustava.
Help-desk usluge moraju biti dostupne u radno vrijeme javnopravnih tijela svim zaposlenicima, a graanima i izvan tog vremena. Potrebno je utvrditi zahtjeve na brzinu odziva help-deska na pristigle upite. Funkcije help-deska su: Registriranje svih poruka (incidenata), te primarna pomo za njihovo rjeavanje, Registriranje novih korisnikih zahtjeva (CRF), Praenje rada i izvjeivanje o stanju, Struna miljenja i prijedlozi poboljanja, Prijedlozi informatikog obrazovanja djelatnika.
Help-desk moe biti organiziran vierazinski, gdje prvu razinu usluga pruaju HD specijalisti, a drugu i treu razinu specijalisti za pojedine aspekte ili tehnologije sustava. 8.1.3 Pouzdanost
Pouzdanost (engl. reliability) je svojstvo sustava (najee nekog ureaja ili tehnikog sustava) da obavlja svoju funkciju neprekidno kroz odreeno vrijeme u okvirima zadanih uvjeta. Najei parametar za opisivanje pouzdanosti je srednje vrijeme izmeu kvarova (engl. mean time between failures MTBF). MTBF oznaava koliko prosjeno vremena proe izmeu dva dogaaja u kojima je sustav prestao raditi. Drugi parametar koji se koristi zajedno s MTBF-om je srednje vrijeme za popravak sustava (engl. mean time to repair MTTR).
31. svibnja 2010. 70/95
Kod poslovnih informacijskih sustava zahtjevi za pouzdanost se esto definiraju na nain da se trai redundancija u komponentama sustava i koritenje mehanizama za prebacivanje poslova s primarne na priuvne komponente, prvenstveno koritenjem serverskih klastera (engl. clustering), te postupcima uravnoteavanja optereenja (engl. load balancing), prebacivanjem poslova s primarne na priuvne komponente u sluaju nepredvienih situacija (engl. fail over) ili slinim tehnikama. 8.1.4 Dostupnost
Taj parametar opisuje koliko vremena je potrebno da se sustav ponovno osposobi za rad nakon to je dolo do kvara.
SPEUP Ver. 1.0
Dostupnost (engl. availability) govori o tome koliko vremena je odreena usluga dostupna u nekom periodu (npr. 100/168 sati 100 sati tjedno), odnosno u koliko posto sluajeva je dostupna kad ju pozovemo (npr. veza se mora ostvariti u 99,8% sluajeva). Ovo svojstvo se najee koristi u definiranju kvalitete elektroniko-komunikacijskih usluga i usluga help-deska vezanih za rad poslovnih sustava u takozvanim Ugovorima o razini usluga (engl. Service Level Agreement - SLA). Na primjer, za usluge help-deska SLA moe sadravati: postotak poziva koji su prekinuti prije nego je operater odgovorio na poziv prosjeno vrijeme potrebno da operater odgovori na poziv prosjeno vrijeme rjeavanja upita. postotak poziva na koje treba odgovoriti u odreenom roku postotak poziva koje treba rijeiti odmah, bez prespajanja ili dodatne komunikacije s korisnikom
SLA za dostupnost funkcija sustava moe propisivati dozvoljeni postotak vremena u kojem sustav ne radi zbog kvara mree, nestanka struje, hardverskih kvarova, preventivnog odravanja i sl. Ukupna dostupnost usluga sustava moe se definirati zahtjevom oblika: Sustav mora biti dostupan korisnicima 24 sata dnevno, 7 dana u tjednu kroz cijelu godinu, osim u vremenu predvienom za odravanje. Planirano vrijeme za odravanje sustava je najvie x sati tokom svakog kvartala. Termini planskog odravanja se moraju uskladiti s naruiteljem kako bi iskljuenje sustava minimalno utjecalo na izvrenje poslovnih procesa.
31. svibnja 2010.
Uinkovitost ili performanse sustava (engl. performance) opisuju koliko jedinica posla sustav moe obaviti u odreenom vremenu i s odreenim resursima. Drugaije reeno, to je 8.1.5 Performanse
Vrijeme u kojem sustav ne radi zbog kvara ne smije prijei x minuta svaki kvartal.
71/95
Osim njih, performanse se mogu mjeriti i nizom drugih mjera, poput: vremena odziva (u normalnom pretpostavljene mrene resurse), vremena potrebnog da se izvri odreena usluga, i vrnom
sposobnost sustava da izvri svoje funkcionalnosti dovoljno brzo da bi bio prihvatljiv za korisnike. Neke od mjera performansi, poput pouzdanosti i dostupnosti, ve smo opisali. optereenju sustava uz
SPEUP Ver. 1.0
kapacitetu za izvrenje odreene koliine usluga u zadanom vremenu (engl. throughput), pojasnoj irini za prijenos podataka (engl. bandwidth) trajanju prijenosa podataka. brzini i omjerima kompresije / dekompresije podataka
Kod poslovnih sustava posebno je vana brzina odziva, kapacitet, trajanje prijenosa podataka. Kao primjer, zahtjevi za performanse sustava mogu se izraziti u obliku:
Sustav mora osigurati odgovarajue vrijeme odziva (x sekundi) nakon unosa podataka od strane korisnika u uvjetima normalnog optereenja, a y sekundi u uvjetima vrnog optereenja (definirati normalno i vrno optereenje u odnosu na broj korisnika, broj otvorenih dokumenata i sl.).
Upravljivost (engl. controlability) i osmotrivost (engl. observability) su svojstva sustava koja se izvode iz teorije upravljanja. Upravljivost govori o tome moe li se sustav prebaciti u eljeno stanje, a osmotrivost govori o tome mogu li se pratiti informacije o stanju sustava. Kod informacijskih sustava ovi aspekti se primarno odnose na funkcije administriranja i nadzora rada sustava. 8.1.6 Upravljivost i osmotrivost Zahtjevi na upravljivost i osmotrivost:
Sustav mora vratiti rezultate jednostavnog pretraivanja u x sekundi (npr. 3 sekunde), a sloenog pretraivanja u roku od y sekundi (npr. 10 sekundi) od unosa zahtjeva.
Sustav treba trenutno automatski kreirati izvjea o izvanrednim dogaajima i slati ih putem sms-a (e-pote, ) definiranoj grupi korisnika. Sustav treba podravati mogunosti rekonfiguracije hardvera, softvera (detaljne specifikacije) bez prekida rada.
Sustav treba redovito (dnevno, tjedno, mjeseno) automatski kreirati izvjea o radu u proteklom periodu s podacima o
Sustav treba omoguiti da administrator prati informacije o (intenzitetu koritenja, broju korisnika, iskoritenosti resursa, incidentima...)
31. svibnja 2010.
72/95
Sustav treba omoguavati administratoru da po potrebi ukljuuje dodatne vorove na nain Sustav treba omoguavati da administrator ugrauje nove mehanizme zatite
SPEUP Ver. 1.0
8.1.7 Sigurnost
Kod poslovnih sustava sigurnost je vrlo vana, a u tehnikom smislu se osigurava primjenom odgovarajuih sustava autentikacije i autorizacije korisnika, vierazinskih prava i uloga u sustavu, enkripcijom podataka, postavljanjem vatrozida (eng. firewall), koritenjem virtualnih privatnih mrea, ugradnjom sigurnosnih elemenata u aplikacije, praenjem i zapisivanjem svih aktivnosti na sustavu, voenjem povijesnosti o promjenama podataka i dr. Meutim, tehnike mjere za sigurnost nisu dovoljne, nego je za postizanje sigurnosti potrebno izgraditi cjelovit sustav informacijske sigurnosti koji obuhvaa sve aspekte sustava, ukljuujui procese, ljude i tehnologiju. Podaci u sustavu moraju biti osigurani u skladu s odredbama vaee pravne regulative, posebno Zakona o zatiti osobnih podataka i Zakona o tajnosti podataka. Otpornost na greke (engl. fault tolerance) je svojstvo sustava da nastavi raditi i nakon to je dolo do greke ili kvara u radu jednog dijela sustava. Pri tome je dozvoljeno da sustav radi sa smanjenim performansama za vrijeme oporavka. 8.1.8 Otpornost na greke
Sigurnost (engl. security) je sposobnost sustava da sprijei pristup, pregled i promjene podataka ili aplikacija neautoriziranim stranama.
Elektroniki dokumenti s kojima radi sustav za elektroniko uredsko poslovanje podloni su trima vrstama rizika vezanim uz protok vremena: 8.1.9 Neovisnost o promjenama tehnologije i starenju degradaciju medija na koje su pohranjeni, zastarijevanje hardvera, zastarijevanje formata.
Kod izrade korisnikog suelja treba takoer voditi brigu o tome da se sprijei unos pogrenih ili besmislenih podataka koritenjem unaprijed definiranih vrijednosti i validacijom unosa prije slanja podataka na server. Nikako se ne bi smjelo desiti da sustav prestane pruati smislenu uslugu korisniku zbog nepravilnog unosa podataka.
Osnovni mehanizam za postizanje otpornosti na greke je uvoenje redundancije u sustav, posebno za kritine elemente sustava. Redundancija se moe uvesti i za hardverske i za softverske komponente sustava.
Neovisnost o promjenama tehnologije i starenju je svojstvo sustava koje osigurava da e se pohranjeni dokumenti i nakon vie godina moi koristiti u radu sustava.
31. svibnja 2010.
73/95
Neovisnost o promjenama tehnologije i starenju moe se postii kombinacijom raznih metoda, poput: rutinskih preventivnih zamjena medija uvanja vie kopija istih dokumenata emulacija starih formata ili hardvera
SPEUP Ver. 1.0
odabira medija koji imaju odgovarajui vijek trajanja i pravilnog uskladitenja medija preventivne zamjene hardverskih komponenti migracija podataka na nove vrste medija konvertiranje podataka u nove formate
Zahtjevi u vezi s neovisnou o promjenama tehnologije i starenju mogu biti primjerice sljedei: Sustav mora omoguavati nadzor i zamjenu medija kao osiguranje protiv degradacije medija. Sustav mora podravati migraciju podataka na nove medije. Sustav mora omoguavati usporedbe kopija podataka i automatske zamjene kopija koje nisu konzistentne.
odravanje zastarjele tehnologije u operativnom stanju kroz dulji period.
Svi podaci i promjene u sustavu se moraju pohranjivati u vie kopija na razliite lokacije kako bi se sprijeio gubitak podataka. U sustavima elektronikog uredskog poslovanja potrebno je definirati plan ouvanja podataka (engl. Data Recovery Plan DRP) i osigurati potrebnu tehniku infrastrukturu. Osnovna tri cilja koja treba postii backup procedurama su: 8.1.10 Sigurnosna pohrana (backup) minimiziranje gubitka podataka ako je gubitak neizbjean, mogunost povrata izgubljenih podataka,
Potrebno je osigurati program obnavljanja opreme kako bi se osigurala stalna dostupnost podataka.
Tri osnovne vrste backup-a su:
minimiziranje vremena potrebnog za restauraciju podataka, tj. smanjenje vremena nedostupnosti podataka.
31. svibnja 2010.
potpuni backup kopiraju se sve podatkovne stranice koje se koriste i dio REDO log-a koji ukljuuje sve otvorene transakcije i transakcije koje su izvrene tijekom trajanja backup-a,
74/95
inkrementalni backup kopiraju se samo one podatkovne stranice koje su se promijenile od posljednjeg potpunog backup-a,
SPEUP Ver. 1.0
Skalabilnost (engl. scalability) je svojstvo sustava da opslui naglo povean broj korisnika ili obavi povean broj transakcija. Skalabilnost se moe definirati u smislu: 8.1.11 Skalabilnost optereenja (eng. load scalability) mogunost obavljanja poveanog broja operacija, pruanja veeg broja usluga ili poveanja broja korisnika administrativnog ili organizacijskog proirenja mogunost pruanja usluga dodatnim organizacijskim jedinicama ili organizacijama funkcionalnog proirenja mogunost pruanja dodatnih usluga
backup arhivskih log-ova - kopiraju se samo log-ovi o transakcijama koje su provedene nakon zadnjeg potpunog ili inkrementalnog backup-a, a ne kopiraju se podatkovne stranice.
geografskog proirenja mogunost pruanja usluga na novom geografskom podruju tehnolokog proirenja mogunosti proirenja na druge ureaje ili platforme (npr. pruanjem mobilne m-usluge).
Zahtjevi za skalabilnost se najee postavljaju kod baza podataka i aplikacijskih servera, gdje se trai mogunost poveanja diskovnog i memorijskog prostora, poveanja broja procesora ili vorova u sustavu. U prijenosu podataka skalabilnost se definira mogunou poveanja pojasne irine ili broja linija. Zahtjevi mogu biti definirani i na sljedei nain: sustav se mora moi proiriti za rad s poveanim brojem korisnika (xx novih korisnika u godini dana) bez prekida pruanja usluga sustav mora biti skalabilan i pogodan za primjenu u tijelima koja imaju izmeu 20 i 2000 zaposlenih s razliitim brojem ustrojbenih jedinica sustav se mora moi instalirati u sve podrunice unutar Republike Hrvatske.
8.2 Atributi kvalitete u razvoju sustava Mogunosti testiranja sustava (eng. testability) je karakteristika sustava koja osigurava da se ispitaju svi funkcionalni i nefunkcionalni zahtjevi na rad sustava. 8.2.1 Mogunost testiranja
31. svibnja 2010.
Testovi se tipino sastoje od testova komponenti, testova integracije podsustava, testova integracije sustava te testova prihvatljivosti.
75/95
Testovi komponenti provjeravaju da li pojedine komponente sustava pravilno izvravaju predviene funkcije. Testovi integracije podsustava provjeravaju interoperabilnost komponenti unutar sustava. Te testove uobiajeno provodi dobavlja (s moguim nadzorom naruitelja), a o rezultatima testova sastavlja zapisnik. Testovi integracije se odnose i na funkcionalne i na nefunkcionalne zahtjeve postavljene na sustav. Pri tome se mogu provesti razni testovi, ukljuujui: testove kompatibilnosti kako bi se ispitalo je li sustav kompatibilan s drugim postojeim sustavima kao to je traeno u zahtjevima
SPEUP Ver. 1.0
Testovi integracije uobiajeno se provode u suradnji naruitelja i isporuitelja sustava.
testove pod normalnim optereenjem koji mjere vremena odziva u normalnim uvjetima rada sustava testove pod visokim optereenjem koji ispituju performanse sustava u situacijama kad je optereenje vee od normalnog.
testove performansi koji ispituju karakteristike ponaanja sustava i otkrivaju uska grla
funkcionalne testove prema knjizi testnih scenarija koji ispituju ispravnu funkcionalnost sustava u cjelini
Testovi prihvatljivosti sustava ispituju tijek procesa i funkcionalnosti sustava sa stanovita korisnika, i tipino ih provode krajnji korisnici prije samog prihvaanja sustava i poetka rada. 8.2.2 Proirivost
Proirivost sustava (eng. extensibility) je mogunost ugradnji novih svojstava u sustav na ekonomski prihvatljiv nain i bez negativnih efekata na postojee funkcionalnosti. Moe se zahtijevati da sustav treba u budunosti osigurati mogunost povezivanja s nekim drugim sustavom, ili mogunost ugradnje novih funkcionalnosti koje se oekuju kroz budue izmjene regulative (npr. zbog meunarodnih integracijskih procesa i sl.). 8.2.3 Prilagodljivost
U zahtjevima se uobiajeno navode vrste testova te procedure testiranja i prihvaanja sustava.
Prilagodljivost ili mogunost prilagodbe sustava (eng. modifability, flexibility) opisuje sposobnost sustava da se prilagodi za promjene npr. regulative ili poslovnih procesa na ekonomski prihvatljiv nain. Prilagodljivost se moe promatrati na vie razina:
31. svibnja 2010.
na razini pojedinanog korisnika koji moe prilagoavati suelje (profili)
76/95
Zahtjevi na prilagodljivost koje postavlja naruitelj odnose se tipino na prilagodljivost na razini korisnika i organizacije naruitelja.
na razini organizacije naruitelja koja moe u sustavu prilagoavati nain izvoenja poslovnih procesa, poslovna pravila, obrasce i sl. koristei jednostavne alate za implementaciju promjena na razini proizvoaa sustava koji moe rekonfigurirati module, programirati dodatne module i sl.
SPEUP Ver. 1.0
Fleksibilnost se takoer moe odnositi na sposobnost prilagodbi promjenama nefunkcionalnih zahtjeva, poput zahtjeva za promjene arhitekture distribuiranog sustava, poveanje dostupnosti, pouzdanosti, skalabilnosti i sl. 8.2.4 Mogunost lokalizacije
Mogunost lokalizacije (eng. localizability) je svojstvo sustava da se na jednostavan nain moe mijenjati jezik ili terminologija suelja. Lokalizacija se moe odnositi na promjenu u drugi jezik (npr. jezik nacionalne manjine) ili promjenom strune terminologije (npr. iz strunog jezika vezanog uz EU fondove u struni jezik vezan uz dravni proraun RH). Zahtjevi za lokalizaciju moraju se navesti u projektnom zadatku ako se oekuje takva potreba. 8.2.5 Mogunost viestrukog koritenja modula Mogunost viestrukog koritenja modula (eng. reusability) opisuje svojstvo da se neki moduli sustava mogu koristiti i u drugim sustavima. To se prvenstveno odnosi na softverske module. Za mogunost viestrukog koritenja modula najvie su zainteresirani proizvoai sustava jer time smanjuju trokove i trajanje razvoja. Kod sustava e-Ured mogunost viestrukog koritenja je vrlo vana u smislu implementacije istog sustava u vie organizacija, kako bi se smanjili trokovi razvoja te ekonomizirali trokovi odravanja. 8.2.6 Brzina i resursi potrebni za implementaciju
Naruitelji sustava mogu postaviti zahtjev da se u sustav ukljue neki moduli ili aplikacije kojima oni raspolau od ranije. Uobiajeno se takav zahtjev formulira na nain da se sustav mora povezati s postojeim aplikacijama koritenjem odreene tehnologije.
U nekim situacijama naruitelj moe definirati resurse s kojima je spreman podrati projekt, npr. na nain da definira raspoloivost svog strunog tima, raspoloivost infrastrukture i sl.
31. svibnja 2010.
Jedan od kljunih nefunkcionalnih zahtjeva u razvoju i implementaciji sustava za elektroniko uredsko poslovanje je rok isporuke i postizanja pune operativne upotrebe sustava. Taj se zahtjev uobiajeno izrie u obliku: Rok za instalaciju i prihvaanje sustava je x mjeseci od potpisa ugovora.
77/95
Proces razvoja i implementacije sustava trebao bi se voditi prema unaprijed definiranom metodolokom obrascu da se osigura kvaliteta i upravljivost procesa. Metodologija definira faze ivotnog ciklusa tog procesa, standardne discipline, procesne korake, kriterije za prelazak izmeu faza ili koraka, ulazne i izlazne artefakte, standardne obrasce i sl. 8.2.7 Metodologija razvoja i implementacije Danas je najrairenija metodologija razvoja softvera RUP Rational Unified Process, a poznate su svjetske metodologije implementacije npr. AIM Application Implementation Method (Oracle) ili ASAP A SAP (SAP). Pojedini proizvoai ili isporuitelji sustava mogu imati i vlastite metodologije razvoja i implementacije. Zahtjevi za koritenje metodologija mogu se formulirati npr. u obliku: Prilikom implementacije je potrebno koristiti definiranu implementacijsku metodologiju.
SPEUP Ver. 1.0
Metodologija voenja projekta osigurava da se projektni zahtjevi realiziraju na kontroliran nain u okvirima zadanog prorauna, rokova i specificirane razine kvalitete. Metodologija voenja projekta moe biti usklaena s meunarodnim strukovnim standardima i dobrom praksom (npr. sadranoj u Project Management Body of Knowledge PM BOK instituta PMI, Prince 2 metodologiji, IPMA metodologiji i sl), ili moe biti vlastita metodologija isporuitelja sustava. 8.2.8 Metodologija voenja projekta Zahtjevi za koritenje metodologija upravljanja projektima mogu biti:
Projekt se mora voditi u skladu s definiranom metodologijom voenja projekta koja je usklaena s meunarodnim standardima (PMI ili ekvivalentni). Voditelj projekta na strani isporuitelja mora imati PMP ili ekvivalentan certifikat. da se vode zapisi o svim zahtjevima za promjene da se zahtjevi za promjene dostavljaju u slubenom obliku na slubene adrese stranaka da zahtjevi za promjene sadre sve potrebne informacije za odluivanje
8.2.9 Metodologija upravljanja promjenama
Metodologija upravljanja promjenama osigurava:
da se analiziraju posljedice svakog zahtjeva na opseg, rokove, trokove, kvalitetu i druge aspekte sustava da se sastavi i potpie odgovarajui aneks ugovora o izvedbi promjene
da se donese odluka o prihvaanju zahtjeva na odgovarajuoj razini upravljanja projektom

78/95
31. svibnja 2010.
Metodologija upravljanja kvalitetom na projektu osigurava jasnu dodjelu odgovornosti za kvalitetu, identifikaciju zahtjeva za kvalitetu, definiranje postupaka i metoda za osiguranje kvalitete, definiranje postupaka i metoda za dokazivanje kvalitete, te stalno unaprjeenje procesa. Dio metodologije upravljanja kvalitetom je i upravljanje zapisima i dokumentima kvalitete, te kontrola kvalitete u svim fazama projekta. 8.2.10 Metodologija upravljanja kvalitetom Zahtjevi na metodologiju upravljanja kvalitetom mogu se definirati na primjer na sljedee naine: U projektnom timu isporuitelja osoba odgovorna za kvalitetu (menader kvalitete) mora imati certifikat za internog auditora po normi ISO 9001:2000 ili ekvivalentan.
U zahtjevima se mogu navesti koraci i faze u upravljanju promjenama koje propisuje naruitelj, ili se od isporuitelja moe traiti da u projektu definira metodologiju upravljanja promjenama.
da se o promjeni informiraju sve zainteresirane strane da se prati realizacija promjene.
SPEUP Ver. 1.0
Isporuitelj treba imati sustav upravljanja kvalitetom certificiran po normi ISO 9001:2000 ili ekvivalentan.
Upravljanje konfiguracijom osigurava konzistentnost promjena na modulima i dokumentaciji sustava putem sistematske kontrole promjena pojedinih komponenti. Upravljanje konfiguracijom sastoji se od: 8.2.11 Upravljanje konfiguracijom
Kod sustava koji su instalirani na vie lokacija, upravljanje konfiguracijom obuhvaa tonu evidenciju o stanju konfiguracije sustava na svakoj lokaciji. Zahtjevi za upravljanje konfiguracijom mogu biti:
31. svibnja 2010.
auditiranja konfiguracije - nadzora da li je nova konfiguracija ispunila traene funkcionalne i druge zahtjeve.
evidentiranja stanja konfiguracije voenje izvjetavanje o promjenama konfiguracije sustava
identifikacije konfiguracije procesa identifikacije atributa komponenti sustava kontrole konfiguracije procesa nadzora i odobravanja vrijednosti atributa komponenti sustava zapisa (povijesnosti) i
Isporuitelj e voditi zapisnik o svim promjenama konfiguracije sustava.
79/95
8.2.12 Ogranienja 8.2.12.1
SPEUP Ver. 1.0
Ogranienja na arhitekturu sustava mogu definirati karakter aplikacije (npr. web-aplikacija s vieslojnom arhitekturom), osnovne module, strukturu baza podataka i sl. Standardna arhitektura za projekt e-Ured definirana je u posebnom dokumentu. Arhitektura sustava 8.2.12.2 Tehnoloka infrastruktura
U okviru projekta moe se traiti da sustav bude usklaen s odreenom tehnolokom infrastrukturom, npr. hardverskim komponentama (serverske platforme, radne stanice), operativnim sustavima, sustavima za upravljanje bazama podataka, mrenim protokolima, standardima interoperabilnosti, razvojnim alatima i sl. Takvi zahtjevi tipino proizlaze iz postojee arhitekture informacijskog sustava naruitelja. Naruitelj moe traiti da sustav bude usklaen s relevantnim tehnikim standardima koji se odnose na kvalitetu, interoperabilnost, performanse ili druga svojstva sustava u cjelini ili njegovih dijelova. 8.2.12.3 Tehniki standardi Na primjer, zahtjev moe biti: Sustav mora pohranjivati sve datume u skladu sa standardom ISO 8601, Data elements and interchange formats Information interchange Representation of dates and times. Sustav mora podravati rad sa skupom znakova Unicode (ISO 10646). Sustav mora podravati koritenje web servisa razmjenom poruka u formatu XML. Usklaenost s pravnom regulativom Sustav mora podravati eksport dokumenata u formatima MS Office (.doc, .docx, .xls, .xlsx) i .pdf.
8.2.12.4
Sustav mora biti usklaen s pravnom regulativom, koja je obraena u poglavlju 3. ovog dokumenta. 8.2.12.5 Interoperabilnost
Interoperabilnost se odnosi na sposobnost sustava da implementira transakcije u suradnji s drugim sustavima. Moe se traiti da sustav bude interoperabilan s postojeim sustavima u javnopravnom tijelu, te sa sustavima drugih tijela. Interoperabilnost obuhvaa: procesnu interoperabilnost usklaenost poslovnih procesa koje sustavi podravaju semantiku interoperabilnost usklaenost terminologije
31. svibnja 2010.
80/95
Podrka za druge operativne sustave i hardverske platforme (eng. portability) moe ukljuivati zahtjeve da se izgradi suelje za pristup preko mobitela ili da se osigura mogunost prebacivanja sustava na drugi operativni sustav bez promjene programskog koda. 8.2.12.7 Podrka za druge platforme Svi ovdje opisani nefunkcionalni zahtjevi pobrojani su i prikazani u tablinoj formi u Privitku 6. kao svojevrsna kontrolna lista.. Uz pomo te liste mogue je nainiti provjeru da li i u kojem opsegu postojei informacijski sustav za podrku uredskom poslovanju udovoljava postavljenim nefunkcionalnim zahtjevima.
Usko vezana uz interoperabilnost, otvorenost je svojstvo sustava da omoguava drugim sustavima da se poveu s njime i izmjenjuju podatke ili koriste njegove usluge. Da bi bio otvoren, sustav treba imati jasno definirana i dokumentirana suelja. 8.2.12.6 Otvorenost
Zahtjevi za interoperabilnost ovise o konkretnim potrebama javnopravnih tijela koje uvodi sustav.
tehniku interoperabilnost usklaenost komunikacijskih kanala i formata podataka koji se razmjenjuju.
SPEUP Ver. 1.0
31. svibnja 2010.
81/95
ZAKLJUNE PREPORUKE
SPEUP Ver. 1.0
Pri projektiranju, uvoenju i koritenju sustava za elektroniko uredsko poslovanje potrebno je: Koristiti standardne metodologije voenja projekata i upravljanja promjenama;
Koristiti svjetski priznate metodologije i norme za modeliranje procesne i podatkovne arhitekture elektronikog uredskog poslovanja; Primijeniti norme i dobru praksu pri dizajnu funkcionalnosti i suelja sustava elektronikog uredskog poslovanja da postignu uporabljivost (eng. usability), pristupanost (eng. accessibility) te osiguraju prihvaanje od strane korisnika;
Usklaivati sustav elektronikog uredskog poslovanja sa specifikacijom MoReq2, odnosno njenom posljednjom, aktualnom verzijom; U modelima procesa identificirati prikljune toke u kojima se provode mjerenja kljunih pokazatelja uspjenosti iz Strategije vladinih programa; Uspostaviti sustav za interoperabilnost sa potrebnim funkcijama vezanim uz omoguavanje uspostavljanja razmjene elektronikih dokumenata, prema Hrvatskom okviru za interoperabilnost; Javnopravna tijela trebaju meusobno komunicirati elektronikim putem (razmjenom e-Dokumenata i koritenjem e-Servisa); Koristiti primjere dobre prakse (postojee u RH).
Voditi rauna o ivotnom vijeku sustava (odravanju i unaprjeenjima sustava, dokumentiranosti);
Uspostaviti sustav elektronikog uredskog poslovanja koji implementira obvezne funkcionalne i nefunkcionalne zahtjeve;
31. svibnja 2010.
82/95
10 DODACI
SPEUP Ver. 1.0
Svi procesi prepisani su u navedenu notaciju BPMN (Business Process Modeling Notation). Notacija je koritena za modeliranje poslovnih procesa. 10.1 Dijagrami aktivnosti Simbol
Tablica 10.1 Legenda grafikih simbola dijagrama aktivnosti
Opis
Swimlane predstavlja vizualnu prezentaciju pojedine organizacije ili organizacijske jedinice koja obavlja neki podskup u okviru procesa Osnovni slijed procesa
Organizacija
Proces
Jednostavan proces Poetak Kraj
DA ili NE
Odluka
Sinkronizacija
31. svibnja 2010.
83/95
10.2 Popis slika
Slika 2.2 Sustav za interoperabilnost javne uprave ................................................................................ 9 Slika 5.1 Procesna struktura elektronikog uredskog poslovanja (I dio) .................................... 17 Slika 5.2 Procesna struktura elektronikog uredskog poslovanja (II dio) ................................... 17 Slika 5.3 Dijagram aktivnosti: Primitak, otvaranje i pregled poiljki ............................................. 20 Slika 5.4 Dijagram aktivnosti: Upisivanje pismena ............................................................................... 23 Slika 5.5 Dijagram aktivnosti: Dostava pismena u rad ........................................................................ 25 Slika 5.6 Dijagram aktivnosti: Izrada i potpisivanje akta.................................................................... 26 Slika 5.7 Dijagram aktivnosti: Otpremanje pismena ............................................................................ 27 Slika 5.8 Dijagram aktivnosti: Razvoenje i rokovnik predmeta..................................................... 28 Slika 5.9 Dijagram aktivnosti: Stavljanje predmeta u pismohranu i uvanje.............................. 29 Slika 5.10 Izvjetavanje pretvaranje podataka u korisne informacije ....................................... 30 Slika 6.1 XML shema: Identifikator.............................................................................................................. 31 Slika 6.2 XML shema: Kod/ifra (metapodaci) ....................................................................................... 31 Slika 6.3 XML shema: Klasa ............................................................................................................................ 32 Slika 6.4 XML shema: Urudbeni broj......................................................................................................... 32 Slika 6.5 XML shema: Adresa ......................................................................................................................... 33 Slika 6.6 XML shema: Osoba ........................................................................................................................... 34 Slika 6.7 XML shema: Stranka ........................................................................................................................ 35 Slika 6.8 XML shema: e-Dokument .............................................................................................................. 37 Slika 6.9 XML shema: Administrativni metapodaci .............................................................................. 38 Slika 6.10 XML shema: Opisni metapodaci ............................................................................................... 39 Slika 6.11 XML shema: Sadraj dokumenta.............................................................................................. 40 Slika 6.12 XML shema: e-Pismeno ............................................................................................................... 42 Slika 6.13 XML shema: Identifikacija e-Pismena .................................................................................... 43 Slika 6.14 XML shema: Procesni metapodaci .......................................................................................... 44 Slika 6.15 XML shema: Vrsta radnje ............................................................................................................ 45 Slika 6.16 XML shema: Elektroniki potpis i vremenski ig .............................................................. 46 Slika 6.17 XML shema: Prilog......................................................................................................................... 47
31. svibnja 2010.
Slika 2.3 Scenarij razmjene poruka izmeu dva javnopravna tijela preko sustava za interoperabilnost................................................................................................................................................ 11
Slika 2.1 Standardni projekt u odnosu na druge sustave...................................................................... 8
SPEUP Ver. 1.0
84/95
Slika 6.18 XML shema: Predmet ................................................................................................................... 48 Slika 6.19 XML shema: Reference na dokumente i pismena ............................................................. 49 Slika 6.20 XML shema: e-Poiljka ................................................................................................................. 50 Slika 6.21 XML shema: Sigurna dostava poiljki .................................................................................... 52 Slika 6.22 XML shema: Identifikacija poslovnog procesa ................................................................... 53 Slika 6.23 XML shema: Sadraj poiljke ..................................................................................................... 54 Slika 6.24 XML shema: e-Dostavnica .......................................................................................................... 55 Slika 7.1 Organizacija izvjetavanja ............................................................................................................ 63 Slika 8.1 Taksonomija nefunkcionalnih zahtjeva ................................................................................... 67 Tablica 8.1 Kategorizacija kvarova sustava ............................................................................................. 70 10.3 Popis tablica Tablica 10.1 Legenda grafikih simbola dijagrama aktivnosti ......................................................... 83
SPEUP Ver. 1.0
31. svibnja 2010.
85/95
11 PRIVITCI OSNOVNOG DOKUMENTA SPEUP
SPEUP Ver. 1.0
Standardni projekt elektronikog uredskog poslovanja (SPEUP) sadri pored ovog osnovnog dokumenta jo i sedam privitaka: Privitak 3 - Primjeri modela poslovnih procesa uredskog poslovanja (Ver. 1.0.) Privitak 5 Funkcionalni zahtjevi kontrolna lista (Ver. 1.0.) Privitak 7 Rjenik koritenih pojmova (Ver. 1.0.) Privitak 6 Nefunkcionalni zahtjevi kontrolna lista (Ver. 1.0.) Privitak 2 Primjer procesa uredskog poslovanja u ministarstvu (Ver. 1.0) Privitak 1 MoReq2 Referentni zahtjevi (Ver. 1.0.) Privitak 4 Podatkovni model za razmjenu elektronikih isprava - XML sheme (Ver. 1.0.)
31. svibnja 2010.
86/95
12 REFERENCE
SPEUP Ver. 1.0
[Adobe 1992] TIFF 6.0 Specification. Mountain View: Adobe Systems Incorporated. (http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf) [AT 2002] Wissensmanagement Forum (Hg.): An Illustrated Guide to Knowledge Management, Graz 2002. [AT 2004] The Austrian E-Government Act (AFLG 10/04, 7/08 i 59/08) [AT 2005] XML-Schema zu EDIAKTII V1.1.0.
[AT 2008] Administration on the Net: The ABC guide of eGovernment in Austria. Wien: Austrian Federal Chancellery,, ICT Strategy Unit.
[AU 2005a] Australian Government Technical Interoperability Framework. Canberra: Department of Finance and Administration, Australian Government Information Management Office (http://www.finance.gov.au/publications/australiangovernment-technical-interoperability-framework/docs/AGTIF_V2_-_FINAL.pdf)
[AU 2005b] The National Collaboration Framework (NCF) An Introduction. Canberra: Department of Finance and Administration, National Collaboration Framework Program Office (http://www.finance.gov.au/e-government/service-improvementand-delivery/national-collaboration-framework/docs/NCP-Overview_Document__5_tiers.pdf)
[AU 2006a] Australian Government Information Interoperability Framework. Canberra: Department of Finance and Administration, Australian Government Information Management Office (http://www.finance.gov.au/publications/agimo/docs/Information_Interoperability_ Framework.pdf) [AU 2006b] Delivering Australian Government Services: Managing Multiple Channels. A guide for the strategic assessment and development of service delivery channels. Canberra: Department of Finance and Administration, Australian Government Information Management Office (http://www.finance.gov.au/publications/delivering-australian-governmentservices-managing-multiple-channels/docs/mmc.pdf)
[AU 2007] The Australian Government Business Process Interoperability Framework. Canberra: Department of Finance and Administration, Australian Government Information Management Office (http://www.finance.gov.au/publications/businessprocess-interoperabilityframework/docs/Business_Process_Interoeprabiltiy_Framework.pdf) [AU 2009] A National Standards Framework for Government. Canberra: Department of Finance and Administration, Australian Government Information Management Office (http://www.finance.gov.au/publications/national-standardsframework/docs/nsf.pdf)
31. svibnja 2010.
87/95
[Calabrese 2006] Calabrese FA, Orlando CY: Deriving a 12-step process to create and implement a comprehensive knowledge management system, The journal of information and knowledge management systems Vol. 36 No. 3, 2006: 238-254.
[CA 2002] Knowlede matters: Skills and learning for Canadians, Ottawa: Human resource developement Canada (http://www.eric.ed.gov/ERICDocs/data/ericdocs2sql/content_storage_01/0000019 b/80/1a/cf/39.pdf) [CapGemini, 2004a] Technical description of target eGov infrastructure for delivering PEGS: Architecture for delivering pan-European e-Government services, Version 1.0. Brussels: EC DG Enterprise. (http://ec.europa.eu/idabc/servlets/Doc?id=18944) [CapGemini, 2004b] Technical description of target eGov infrastructure for delivering PEGS: PEGS Infrastructure Requirements Synthesis Document, Version 3.1. Brussels: EC DG Enterprise. (http://ec.europa.eu/idabc/servlets/Doc?id=18946)
SPEUP Ver. 1.0
[Capgemini 2004d] Online Availability of Public Services: How is Europe Progressing?, Brussels: EC Directorate General for Information and Media:, 2005-03-04
[CapGemini, 2004c] Technical description of target eGov infrastructure for delivering PEGS: Technology and Market Trends, Version 1.2. Brussels: EC DG Enterprise. (http://ec.europa.eu/idabc/servlets/Doc?id=18945)
[CapGemini 2004e] Invation management and the Knowledge-driven Economy, Brussels: EC ftp://ftp.cordis.europa.eu/pub/innovation-policy/studies/studies_innovation_manag ement_final_report.pdf [Charalabidis et al., 2009] Adding Systems Support to National Government Interoperability Frameworks: A Good Practice Example from Greece A Possible Strategy for European Member States. 7th Eastern European e-Government Days, 2324 April 2009, Prague, Czech Republic. [Charalabidis et al., 2008] The Greek Electronic Government Interoperability Framework: Standards and Infrastructures for One-Stop Service Provision. Proceedings of the 2008 Panhellenic Conference on Informatics, 25-28 August 2008, Samos, Greece.
[Craig i Jutla, 2000] Craig J, Jutla D: e-Business Readiness: A Customer-Focused Framework. New York: Addison-Wesley, 2000.
[DE 2004] Musterprozess: Frderung. Berlin: Bundesverwaltungsamt, Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation (CC VBPO)
31. svibnja 2010.
[DE 2003] Musterprozess: Zahlungsverkehr/ ePayment Organisatorische und prozessuale Aspekte, Version 1.0. Berlin: Bundesverwaltungsamt, Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation (CC VBPO) (http://www.cio.bund.de/cae/servlet/contentblob/79892/publicationFile/3987/mu sterprozess_zahlungsverkehr.pdf)
88/95
[DE 2007] Leitfaden fr Entwickler von Prozess- und Datenmodellen, Version 1.0. Berlin: Bundesministerium des Innern, Koordinierungs- und Beratungsstelle der Bundesregierung fr Informationstechnik in der Bundesverwaltung (http://www.cio.bund.de/cae/servlet/contentblob/79184/publicationFile/4104/leit faden_fuer_entwickler_stand_2007_download.pdf) [DE 2008] SAGA Version 4.0, Standards und Architekturen fr E-GovernmentAnwendungen. Berlin: Bundesministerium des Innern (http://gsb.download.bva.bund.de/KBSt/SAGA/SAGA_v4.0.pdf) [DE 2009] Rahmenarchitektur IT-Steuerung: Bund Grundlagen, Version 1.0. Berlin: Rat der IT-Beauftragten des Bundes (http://www.cio.bund.de/cae/servlet/contentblob/467604/publicationFile/23674/ rahmenarchitektur_itsteuerung_bund_grundlagen_download.pdf) [Deloitte 2009] Supporting the European Interoperability Strategy Elaboration Final Report Phase 1. Brussels: Deloitte for the European Commission, Directorate-General for Informatics (http://ec.europa.eu/idabc/en/document/7772) [EC 2004b] European Interoperability Framework for Pan-European e-Government Services Version 1.0. Luxembourg: Office for Official Publications of the European Communities (http://ec.europa.eu/idabc/servlets/Doc?id=19529) [EC 2005c] Conference on Knowledge Economy: Challenges for Measurement, Background Paper, Luxembourg: Eurostat
31. svibnja 2010.
[DE 2005b] Musterprozess: Allgemeine Antragsverfahren, Version 1.0. Berlin: Bundesverwaltungsamt, Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation (CC VBPO) (http://www.cio.bund.de/cae/servlet/contentblob/79880/publicationFile/3984/mu sterprozess_allgemeine_antragsverfahren.pdf)
[DE 2005a] Musterprozess: Beschaffung, Version 1.0. Berlin: Bundesverwaltungsamt, Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation (CC VBPO) (http://www.cio.bund.de/cae/servlet/contentblob/79878/publicationFile/3985/mu sterprozess_beschaffung.pdf)
(http://www.cio.bund.de/cae/servlet/contentblob/275124/publicationFile/3986/m usterprozess_foerderung_download.pdf)
SPEUP Ver. 1.0
[EC 2004a] Architecture Guidelines for Trans-European Telematics Networks for Administrations, Version 7.1. Brussels: Enterprise DG (http://ec.europa.eu/idabc/en/document/3485/5585)
[EC 2006] eGovernment Economics Project (eGEP): Expenditure Study, Final Version. Brussels: eGovernment Unit, DG Information Society, European Commission
[EC 2005b]Challenges for the European Information Society beyond. Brussels: EC, 2005.
[EC 2005a]i2010 - A European Information Society for growth and employment, Brussels: EC
89/95
[EC 2007] Study on Interoperability at Local and Regional Level. Brussels: eGovernment Unit, DG Information Society, European Commission (http://www.epractice.eu/files/media/media1309.pdf) [EC 2008a] Draft document as basis for EIF 2.0. Brussels: European Commission (http://ec.europa.eu/idabc/servlets/Doc?id=31597)
(http://82.187.13.175/eGEP/Static/Contents/final/D.1.3Expenditure_Study_final_ve rsion.pdf)
SPEUP Ver. 1.0
[Gartner 2006] Malhotra Y.: Knowledge Assets in the Global Economy: Assessment of National Intellectual Capital, Journal of Global Information Management, Jul-Aug 2000 [Gottschalk 2004] Gottschalk, P.: Strategic Knowledge Management Technology, Idea Group Publishing [Gartner 2009] National Interoperability Framework Observatory project - Final report. Brussels: Gartner for the European Commission, Directorate-General for Informatics (http://ec.europa.eu/idabc/en/document/7796)
[EUekonomist 2006] Allee, V.:Kako upravljati znanjem, Zagreb, sijeanj 2006, str. 64.
[EC 2009] IDABC Work Programme 2005-2009, Sixth revision. European Commission, DG Informatics, Bruxelles, 2009.
[EC 2008c] MoReq2 Model Requirements for the Management of Electronic Records, Update and Extension, 2008. Bruxelles- Luxembourg: CECA-CEE-CEEA.
[EC 2008b] Semantic Interoperability Centre Europe Interconnecting Europe. Brussels: European Commission, Directorate-General for Informatics (ed.) (http://www.semic.eu/semic/view/documents/Interconnecting-Europe-SEMIC-EUBook.pdf)
[Hanford 2009a] Hanford M.: Gartner's Everything to Know About Program Management. [Hanford 2009b] Hanford M.: The Gartner Universe of PPM Roles. [Harris 2001] Harris J: Puting the P in PMO [HR 2004a] Strategija Programa One Stop Shop
[Hanford 2007] Hanford M., The Program Office: An Essential Program Element
[Gottschalk2007] Gottschalk, P.: Knowledge Management Systems: Value Shop Creation. Hershey: Idea Group Publishing
[Harris 2006] Harris K.: A Knowledge Management Maturity Model Explains Where You're Going and How to Get There [HR 2004b] Plan provedbe Programa One Stop Shop
31. svibnja 2010.
[HR 2007a] Program Vlade Republike Hrvatske za mandat 2008. 2011.
[HR 2006] Odrednice razvitka i uporabe raunalnih programa s otvorenim kodom u tijelima dravne uprave (politika otvorenog programskog koda)
90/95
[HR 2007b] Strategija razvitka elektronikog poslovanja u Republici Hrvatskoj za razdoblje 2007. 2010. [HR 2009b] Strategija razvoja elektronike uprave u Republici Hrvatskoj za razdoblje od 2009. do 2012. godine. [HR 2008] Strategija reforme dravne uprave za razdoblje 2008. - 2011. [HR 2009a] Strategija Vladinih programa za razdoblje 2010. - 2012.
SPEUP Ver. 1.0
[IEEE 2002] Malhotra Y., Galletta D.: Role of Commitment and Motivation in Knowledge Management Systems Implementation: Theory, Conceptualisation and Measurement of Antecedents of Success, Proceedings of the 36th Hawai International Conference on System Sciences [ISO 9241-171] ISO 9241-171:2008 - Ergonomics of human-system interaction Part 171: Guidance on software accessibility [IR 2005] Irish mind, Anual report 2005. Dublin: Industrial Development Agency, 2005 http://www.idaireland.com/uploads/reports/IDA%20Annual%20Report_2005.pdf
[HRN ISO 19005-1] HRN ISO 19005-1:2008 Upravljanje dokumentima Format datoteka elektronikih dokumenata za dugoronu zatitu 1. dio: Uporaba PDF-a 1.4 (PDF/A1) (ISO 19005-1:2005+Cor 1:2007)
[ISO 15444-1] ISO/IEC 15444-1:2004 - Information technology JPEG 2000 image coding system: Core coding system [ISO 15444-1/Amd 1] ISO/IEC 15444-1:2004/Amd 1:2006 - Profiles for digital cinema applications [ISO 15444-1: Cor 1] ISO/IEC 15444-1:2004/Cor 1:2007 [ISO/IEC 15444-1/Amd 2] ISO/IEC 15444-1:2004/Amd 2:2009 - Extended profiles for cinema and video production and archival applications
[ISO 15444-1/Cor 2] ISO/IEC 15444-1:2004/Cor 2:2008 - Clarification on determination of maximum file size [ISO 15444-2] ISO/IEC 15444-2:2004 - Information technology JPEG 2000 image coding system: Extensions
[ISO 15444-2: Cor 4] ISO/IEC 15444-2:2004/Cor 4:2007
[ISO 15444-3] ISO/IEC 15444-3:2007 - Information technology JPEG 2000 image coding system: Motion JPEG 2000 [ISO 15444-4] ISO/IEC 15444-4:2004 - Information technology JPEG 2000 image coding system: Conformance testing
31. svibnja 2010.
[ISO 15444-2/Cor 3] ISO/IEC 15444-2:2004/Cor 3:2005Information technology JPEG 2000 image coding system: Extensions
[ISO 15444-2/Amd 2] ISO/IEC 15444-2:2004/Amd 2:2006 - Information technology JPEG 2000 image coding system: Extensions, Extended capabilities marker segment
91/95
[ISO15444-4/Cor 1] ISO/IEC 15444-4:2004/Cor 1:2009
[ISO 15444-5] ISO/IEC 15444-5:2003 - Information technology JPEG 2000 image coding system: Reference software [ISO 15444-8] ISO/IEC 15444-8:2007 - Information technology JPEG 2000 image coding system: Secure JPEG 2000 [ISO 15444-8/Amd 1] ISO/IEC 15444-8:2007/Amd 1:2008 - File format security [ISO 15444-6] ISO/IEC 15444-6:2003Information technology JPEG 2000 image coding system Part 6: Compound image file format [ISO 15444-6/Amd 1] ISO/IEC 15444-6:2003/Amd 1:2007 - Hidden text metadata
SPEUP Ver. 1.0
[ISO 15444-9] ISO/IEC 15444-9:2005 - Information technology JPEG 2000 image coding system: Interactivity tools, APIs and protocols [ISO 15444-9/Amd 1] ISO/IEC 15444-9:2005/Amd 1:2006 - APIs, metadata, and editing [ISO 15444-9/Cor 2] ISO/IEC 15444-9:2005/Cor 2:2008 [ISO 15444-9/Cor 1] ISO/IEC 15444-9:2005/Cor 1:2007 [ISO 15444-9/Amd 2] ISO/IEC 15444-9:2005/Amd 2:2008 - JPIP extensions [ISO 15444-9/Amd 3] ISO/IEC 15444-9:2005/Amd 3:2008 - JPIP extensions to 3D data
[ISO 15444-11] ISO/IEC 15444-11:2007 - Information technology JPEG 2000 image coding system: Wireless [ISO 15444-12] ISO/IEC 15444-12:2008 - Information technology JPEG 2000 image coding system Part 12: ISO base media file format [ISO 15444-12/Cor 1] ISO/IEC 15444-12:2008/Cor 1:2008 [ISO 15444-12/Cor 2] ISO/IEC 15444-12:2008/Cor 2:2009 [ISO 15444-12/Cor 3] ISO/IEC 15444-12:2008/Cor 3:2009 [ISO 15444-12/Amd 1] ISO/IEC 15444-12:2008/Amd 1:2009 - General improvements including hint tracks, metadata support and sample groups [ISO 15444-13] ISO/IEC 15444-13:2008 - Information technology JPEG 2000 image coding system: An entry level JPEG 2000 encoder
[ISO 15444-10] ISO/IEC 15444-10:2008 - Information technology JPEG 2000 image coding system: Extensions for three-dimensional data
[ISO 18019] ISO/IEC 18019:2004 - Software and system engineering Guidelines for the design and preparation of user documentation for application software [ISO 19005-1] ISO 19005-1:2005 - Document management Electronic document file format for long-term preservation Part 1: Use of PDF 1.4 (PDF/A-1) [ISO 19005-1/Cor 1] ISO 19005-1:2005/Cor 1:2007
31. svibnja 2010.
92/95
[ISO 19766] ISO/IEC TR 19766:2007 - Information technology Guidelines for the design of icons and symbols accessible to all users, including the elderly and persons with disabilities [ISO 24756] ISO/IEC 24756:2009 - Information technology Framework for specifying a common access profile (CAP) of needs and capabilities of users, systems, and their environments [ISO 24786] ISO/IEC 24786:2009 - Information technology User interfaces Accessible user interface for accessibility settings [ISO 29138-1] ISO/IEC TR 29138-1:2009 - Information technology Accessibility considerations for people with disabilities Part 1: User needs summary
SPEUP Ver. 1.0
[ISO 26514] ISO/IEC 26514:2008 - Systems and software engineering Requirements for designers and developers of user documentation [ISO 29138-2] ISO/IEC TR 29138-2:2009 - Information technology Accessibility considerations for people with disabilities Part 2: Standards inventory
[ISO 29138-3] ISO/IEC TR 29138-3:2009 - Information technology Accessibility considerations for people with disabilities Part 3: Guidance on user needs mapping [Kaplan i Norton 2008] Kaplan, RS, Norton DP: Mastering the Management System. Harvard Business Review January, 2008: 62-77. [Kendall2003] Kendall GI, Rollins SC: PMP Project Portfolio Management and the PMO, Boca Raton: J ROSS Publishing. [Light 2002] Light M, Hotle M: The Project Office: A Spectrum of Organizational Styles. [Kerzner 2006] Kerzner H:Project Management Best Practices. John Wiley & Sons, Inc.
[Maier 2005] Maier R: Knowledge management systems. Berlin: Springer Verlag, 2. izdanje. [Mullaly 2007] Mullaly M: PMO prognosis
[OECD 2003] Vickery G: Policy Frameworks for Knowledge Based Economy: ICT's, Innovation and Human Resources, Wiena: Austrian Council International Workshop [PM Network 2006] Creating a customer-focused Program Management Office can help drive process improvement. PM Network [PM Network 2007] A PMO is born. PM Network
[McElroy 2003] McElroy MW: The New Knowledge Management - Complexity, Learning, and Sustainable Innovation, KMCI press, 2003.
[Light 2002] Light M, Fabular JI: Project Management Office (ATC Summer Session, July, 25, 2002) www.ganthead.com (the online community for IT project managers)
[OECD 1999] European Principles for Public Administration. SIGMA PAPERS: No. 27. Paris: OECD.
31. svibnja 2010.
93/95
[Rommety 2006] Rommety G: Expanding the Innovation Horizon: The global CEO study 2006, IBM business service. [The Open Group 2009] TOGAF Version 9: The Open Group Architecture Framework. [Tucker 2006] Tucker C, Agopian H: Taking your PMO to the next stage.
[PMI 2008] A Guide to the Project Management Body of Knowledge PMBOK IV edition,. Pennsylvania: Project Management Institute, Inc. [Rischard 2005] Rischard JF: Tono u podne: 20 globalnih problema za 20 godina rjeavanja, Golden Marketing Tehnika knjiga, (prijevod), Zagreb, 2005.
SPEUP Ver. 1.0
[Stankosky 2005] Stankosky M: Creating the Discipline of Knowledge Management - The Latest in University Research. Elsevier Inc.
[Tiwana 2002] Tiwana A: The Knowledge Management Toolkit. Englewood Cliffs: Prentice Hall PTR, 2002. [Turban 2005] Turban E, Aronson J, Liang T: Decision Support Systems and Intelligent Systems, 7. izdanje. Prentice Hall, 2005.
[UK 2003] Government Data Standards Catalogue (GDSC) Volume 1. London: Cabinet Office, e-Government Unit (http://www.govtalk.gov.uk/schemasstandards/datastandards_document.asp?docnu m=692) [UK 2005a] e-Government Interoperability Framework, Version 6.1. London: Cabinet Office, e-Government Unit (http://www.cabinetoffice.gov.uk/media/253452/eGIF%20v6_1(1).pdf)
[UK 2004] Government Data Standards Catalogue (GDSC) Volume 2. London: Cabinet Office, e-Government Unit (http://www.govtalk.gov.uk/schemasstandards/datastandards_document.asp?docnu m=693) [UK 2005b] Technical Standards Catalogue (TSC) Version 6.2. London: Cabinet Office, e-Government Unit (http://www.govtalk.gov.uk/schemasstandards/egif_document.asp?docnum=957)
[UN 2002] UN Economic Commission for Europe: Towards a Knowledge-Based Economy of Slovakia, Country Readiness Assessment Report, New York and Geneve, http://www.unece.org/ie/enterp/documents/coverpagregion.pdf [UN 2005] World Summit on the Information Society: Tunis Agenda for the Information Society, Tunis
31. svibnja 2010. 94/95
[UK 2006] e-Government Metadata Standard Version 3.1. London: Cabinet Office, e-Government Unit (http://www.govtalk.gov.uk/schemasstandards/metadata_document.asp?docnum=1 017)
[US 1999] Federal Enterprise Architecture Framework (FEAF), Version 1.1. Washington, DC: US Federal Chief Information Officer (CIO) Council (www.cio.gov/documents/fedarch1.pdf) [W3C 2008] W3C: Web Content Accessibility Guidelines (WCAG) 2.0 (http://www.w3.org/TR/WCAG20/) [Wikipedia 2009] Wikipedia http://en.wikipedia.org/wiki/Project_Management_Office [World Bank 2002] World Bank, a preliminary strategy to develop a knowledge economy in European Union accession countries, http://www.rec.org/eaarhus/files/worldbank.pdf [Zachman 1987] A framework for information systems architecture. IBM Systems Journal 26/3: 276-292. [Zachman 2008] The Zachman Enterprise Framework2 TM (http://www.ZachmanInternational.com/2/standards.asp)
[UN/CEFACT 2003] Core Components Technical Specification Part 8 of the ebXML Framework. (http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf)
SPEUP Ver. 1.0
31. svibnja 2010.
95/95
REPUBLIKA HRVATSKA

Privitak 1
MoReq2 Referentni zahtjevi

Ver. 1.0
SPEUP Privitak 1: MoReq2 Referentni zahtjevi

SADRAJ
Ver. 1.0
1.1 KLJUNI ZAHTJEVI NA FUNKCIONALNOSTI SUSTAVA PO SPECIFIKACIJI MOREQ2 ........................................................... 4 1.1.1 Klasifikacijske sheme i organizacija datoteka ......................................................................................... 4 Kontrola i sigurnost ............................................................................................................................................ 8 Zahvaanje i proglaavanje zapisa .............................................................................................................. 9 Administrativne funkcije ............................................................................................................................... 10 Upravljanje dokumentima i kolaboracija ............................................................................................... 12 Tijek rada............................................................................................................................................................. 13 Rad sa sluajevima ........................................................................................................................................... 14 Integracija sa sustavom za upravljanje sadrajem ............................................................................ 15 Elektroniko potpisivanje .............................................................................................................................. 15 Integracija telefaksa ....................................................................................................................................... 16 Zahtjevi na metapodatke ............................................................................................................................... 16 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 1.1.8 1.1.9 1.1.10 1.1.11
MOREQ2 REFERENTNI ZAHTJEVI ........................................................................................................................ 3
POPIS SLIKA .............................................................................................................................................................. 18
31. svibnja 2010.
2/18
MoReq2 se sastoji od formalne specifikacije funkcionalnih zahtjeva na generiki sustav za upravljanje elektronikim zapisima, testne dokumentacije i ostalih relevantnih informacija. Uz specifikaciju funkcionalnih zahtjeva za generiki sustav upravljanja zapisima, MoReq2 dodatno sadri: nefunkcionalne zahtjeve 13 opcionalnih modula koji definiraju skupove funkcionalnosti koje obino zahtijevaju integraciju sa sustavom za upravljanje zapisima, kao to su upravljanje dokumentima, faks, kolaboracijska okolina te upravljanje sadrajem
MoReq2 [EC 2008c] je skraeni naziv od eng. Model Requirements for Management of Electronic Records, second version. U okviru EU programa IDABC koji je namijenjen financiranju projekata i infrastrukturnih servisa za uspostavljanje paneuropskih servisa javne uprave, Europska komisija je prepoznala vanost uspostavljanje interoperabilnosti nacionalnih informacijskih sustava za podrku uredskog poslovanja, upravljanja dokumentima i arhiviranja. Europska komisija naruila je izradu dokumenta MoReq2 od tvrtke Serco Consulting, a u proces izrade dokumenta bio je ukljuen i DLM Forum kao i nacionalni eksperti zemalja lanica EU. Zahvaljujui procesu konzultacija sa irokom bazom korisnika, konzultanata, tehnolokih dobavljaa, akademske zajednice i strunih tijela iz svih dijelova svijeta, specifikacija MoReq2 predstavlja referentni model za uspostavu sustava elektronikog upravljanja zapisima. 1 MoReq2 REFERENTNI ZAHTJEVI
SPEUP Privitak 1: MoReq2 - Referentni zahtjevi
Ver. 1.0
model metapodataka s definiranih 345 elemenata potrebnih za realizaciju definiranih funkcionalnih zahtjeva dokumentaciju za testiranje (testne podatke, testne sluajeve, oekivane rezultate, upute za testiranje) XML sheme modela metapodataka objanjenja, dodatke i reference.
Za potrebe ovog projekta provedena je analiza zahtjeva iz specifikacije MoReq2 s obzirom na hrvatske propise i praksu uredskog poslovanja, te je napravljena selekcija relevantnih funkcionalnih zahtjeva za dizajn i razvoj novih, odnosno doradu i prilagodbu postojeih informatikih rjeenja za elektroniko uredsko poslovanje usklaeno s novom Uredbom za uredsko poslovanje. Pri tom je provedeno mapiranje generikih objekata iz MoReq2 na objekte hrvatskog uredskog poslovanja. U daljnjem tekstu dan je pregled kljunih zahtjeva na funkcionalnosti sustava po poglavljima MoReq2 za izgradnju aplikativnog rjeenja za podrku elektronikom uredskom poslovanju.
31. svibnja 2010.
3/18
1.1 Kljuni zahtjevi na funkcionalnosti sustava po specifikaciji MoReq2 1.1.1 Klasifikacijske sheme i organizacija datoteka
Ver. 1.0
U kontekstu specifikacije MoReq2 definiraju se sljedei pojmovi vezani uz uz klasifikacijske sheme i organizaciju datoteka:
Za potrebe upravljanja zapisima mora postojati barem jedna klasifikacijska shema koja sadrava vie klasa. Klasifikacijska shema je hijerarhijski organizirana. Svaka klasa moe sadravati i podreene klase, grupe ili zapise. Meutim meusobne kombinacije navedenih objekata nisu dozvoljene. Grupe se pojavljuju unutra klasa na bilo kojoj razini hijerarhije, ali se mogu pojavljivati samo u klasama koje ne sadre druge klase. Grupe se mogu dijeliti na podgrupe ili sveske, te sadravati zapise. Kao i u sluaju klasa kombinacije objekata nisu doputene. Nadalje, podgrupe mogu, a ne moraju postojati za pojedinu grupu. Mogu sadravati: sveske i zapise, a meusobne kombinacije nisu doputene. Podjela podgrupe na sveske iskljuivo se radi zbog olakanog odravanja. Svezak unutar podgrupe moe, a i ne mora postojati. Rasporedi uvanja i raspolaganja sadravaju pravila za uvanje i izluivanje zapisa. Vie rasporeda/politika uvanja moe se primjeniti na svaku klasu, grupu, pogrupu, svezak, zapis, dok se samo jedan raspored moe primjeniti na svaki tip zapisa. Zapisi su sastavljeni od jednog ili vie dokumenata, a svaki dokument se moe pojaviti i u vie zapisa. Svaki zapis moe biti pohranjen samo u jedan svezak ili jednu podgrupu ili jednu grupu ili jednu klasu dokumenata. Svaki zapis ima svoj tip koji je povezan s rasporedima/politikama uvanja. Svaki zapis ili dokument sastoji se od jedne ili vie komponenata.
31. svibnja 2010. 4/18
Slikom 1.1. prikazan je pojednostavljen E-R model iz specifikacije MoReq2 koji prikazuje osnovne entitete i njihove meusobne odnose.
Svezak (eng. volume) manji blokovi podjedinica. Podjedinice se dijele u manje organizacijske blokove radi poboljanja upravljivosti. Podjela se radi na temelju broja zapisa, raspona oznaka, vremenskog perioda i sl. Zapis (eng. record) informacija stvorena, zaprimljena i odravana kao dokaz/informacija o poslovnom dogaaju.
Podgrupa (eng. sub-file) predstavlja logiku podjelu organizirane jedinice zapisa u kojoj su pohranjeni specifini zapisi (npr. rauni, korespondencija, elektronika pota i sl.)
Grupa (eng. file) organizirana skupina zapisa koji su povezani putem iste teme, aktivnosti ili transakcije;
Klasifikacijska shema (eng. classification sheme) hijerarhijska organizacija klasa(eng. class), grupa (eng. file), podgrupa (eng. sub-file), svezak (eng. volume), i zapisa (eng. record);

1 sadri 1-* KLASA
KLASIFIKACIJSKA SHEMA
Ver. 1.0
0-*
sastoji se od 1 1 1 moe sadravati 0-* GRUPA (eng. file) 1 11 moe se dijeliti na 0-* PODGRUPA (eng. sub-file) 1 moe se dijeliti na 0-* 0-* SVEZAK (eng. volume) 1-* moe se dijeliti na 1-*
1-* primjenjuje se na 1-*
Raspored uvanja i raspolaganja (korisnike role) 0-1
primjenjuje se na
Tip dokumenta 1 ima 1-* DOKUMENT 1 1-* 1-* 0-* ZAPIS 1 sastoji se od sastoji se od 1-* 1-* Komponenta 1-* 1-* 1-* ima 1 Tip zapisa je pohranjeno u
sastoji se od
Klasifikacijska shema omoguava da se elektroniki zapisi organiziraju u elektronike predmete, te definiranje odnosa izmeu pojedinih elektronikih predmeta.
Slika 1.1. MoReq2 - E-R Model
Klasifikacijska shema mora omoguiti hijerarhijsku klasifikaciju. Prednosti hijerarhijske klasifikacije su: sukladnost s dobrom praksom Europske unije. efikasno, stabilno i transparentno klasificiranje zapisa
31. svibnja 2010.
5/18

Classification Scheme
Ver. 1.0
Class
Class
Class
Class
Class
Class
Class
Class
Class
Class
File
File
File
Class
Class
Class
File
File
Recs.
Recs.
Recs.
File
File
File
Recs.
Recs.
Recs. Key: Recs. Records
Recs.
Recs.
Recs.
Nain usklaivanja klasifikacijske sheme sa specifikacijom MoReq2 prikazan je slikom 1.3. Urudbene knjige, klase i dosjei su organizirani u klasifikacijskoj shemi kao klase, dok se spisi/predmeti vode kao grupe (eng. file). Upotreba podgrupa i svezaka je mogua, ali nije neophodna. Preporuka je da se koriste eventualno zbog tehnoloke implementacije sustava.
Neophodno je kvalitetno usklaivanje klasifikacijske sheme s potrebama definiranim Uredbom o uredskom poslovanju, Pravilnikom o jedinstvenim klasifikacijskim oznakama i brojanim oznakama i stvaratelja i primatelja akata, te Planom klasifikacijskih oznaka i brojanih oznaka stvaratelja i primatelja pismena koje donosi elnik tijela koje je obveznik Uredbe o uredskom poslovanju.
Slika 1.2. MoReq2 - organizacija klasifikacijske sheme
31. svibnja 2010.
6/18
KLASIFIKACIJSKA SHEMA 1 sadri 1-* KLASA 1-* primjenjuje se na
Ver. 1.0
Urudbene knjige Klase Dosjei
0-*
sastoji se od 1 1 1 moe sadravati 0-* 1-* FILE 1 11 moe se moe se dijeliti na dijeliti na 0-* 1-* sub-file 1 moe se dijeliti na 0-* 0-* 1-* volume
tip zapisa 0-1
Predmeti
primjenjuje se na
Tip dokumenta 1 Pismena ima 1-* Dokument 1 1-* 1-* 0-* zapis 1 sastoji se od sastoji se od 1-* 1-* Komponenta 1-* 1-* ima 1-* tip zapisa je pohranjeno u
sastoji se od
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju klasifikacijskih shema i organizacije datoteka su:
Slika 1.3. Organizacija klasifikacijske sheme sukladno specifikaciji MoReq2
Sustav mora podravati i biti kompatibilan s klasifikacijskom shemom organizacije. o aktivnosti odravanja o aktivnosti korisnika
Sustav mora odravati interni integritet podataka (relacijski integritet ili neki drugi) u svakom trenutku bez obzira na: o otkazivanje rada sistemskih komponenti.
Drugim rijeima, ne smije se dogoditi situacija nekonzistentnosti podataka u sustavu zbog aktivnosti korisnika ili otkazivanja bilo kojeg dijela sustava.
Sustav mora omoguiti organizaciju grupa i zapisa unutar hijerarhijske klasifikacijske sheme.
7/18
31. svibnja 2010.
Sustav mora omoguiti implementaciju klasifikacijske sheme za vrijeme konfiguriranja sustava zbog osiguravanja spremnosti za zahvaanje i/ili importiranje elektronikih zapisa. Sustav mora omoguiti definiranje sustava imenovanja za vrijeme konfiguracije cijelog sustava od strane administratora. U dijelovima sustava koji podravaju eksport podataka, podaci bi trebali biti eksportirani u XML ili ekvivalentnom standardiziranom otvorenom formatu.
Ver. 1.0
Sustav mora omoguiti administratorima konfiguraciju klasa na naina da se u klasu mogu/ne mogu direktno pohranjivati zapisi.
Sustav ne smije nametnuti nikakvo praktino ogranienje na broj klasa ili grupa unutar sustava.
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju kontrole i sigurnosti su: 1.1.2 Kontrola i sigurnost Pristup Sustav ne smije dozvoliti osobi koja nije uspjeno identificirana i autenticirana, te autorizirana za koritenje sustava, izvravanje niti jedne akcije u sustavu. Sustav ne smije ograniiti broj uloga ili korisnikih grupa koje se mogu konfigurirati. Sustav mora omoguiti administratorima definiranje dozvola za: o ograniavanje pristupa pojedinim grupama ili zapisima o o ograniavanje pristupa pojedinoj klasi klasifikacijske sheme o ograniavanje pristupa sukladno korisnikovim sigurnosnim ovlastima
Sustav bi trebao omoguiti eksport podataka o svim grupama kao i eksport podataka o svim grupama unutar jedne klase (i njezinih podklasa) u XML formatu ili formatu itljivom ovjeku.
Sustav mora omoguiti administratorima proglaavanje pojedinih korisnika neaktivnim, bez brisanja korisnika iz sustava.
31. svibnja 2010.
Sustav mora omoguiti da korisnik bude lan jedne, vie ili niti jedne korisnike grupe.
Sustav bi trebao imati mogunost konfiguracije pristupa na naine prijave korisnika putem uspostavljene integrirane IT infrastrukture (eng. integrated network log-on).
o ograniavanje pristupa nakon odreenog datuma
o dozvoljavanja pristupa nakon odreenog datuma.
ograniavanje pristupa pojedinim funkcionalnostima i funkcijama (npr. itanja, auriranja, brisanja specifinih metapodataka)
8/18
Sustav treba omoguiti administratorima postavljanje i upravljanje pravilima koja definiraju pristup korisnika pojedinim funkcijama sustava, na nain da razliite korisnike uloge imaju pristup razliitoj kombinaciji funkcija sustava.
Ver. 1.0
Revizijski dnevnici
Ako korisnik pokrene pretragu koja ukljuuje pretraivanje sadraja (tipino pretraivanje po cijelom sadraju teksta). Sustav ne smije ukljuiti u rezultate pretrage niti jedan zapis kojem korisnik nema ovlasti pristupiti. Sustav mora imati mogunost automatskog zahvaanja i pohranjivanja u revizijski dnevnik (eng. audit log) koji se ne smije moi mijenjati, informacije o: o korisniku koji je poduzeo radnju o vremenu i datumu kada je radnja poduzeta. o svim radnjama izvrenim s pojedinim zapisom, grupom objekata ili klasifikacijskom shemom
Sustav mora omoguiti dostupnost revizijskog dnevnika za provoenje inspekcijskog nadzora na zahtjev, kako bi se mogli identificirati pojedini dogaaji i sve relevantne informacije.
Revizijski dnevnik se mora moi konfigurirati od strane administratora na nain da se moe definirati za koje radnje sustav mora automatski biljeiti revizijski trag.
Kada se postave parametri revizijskog dnevnika sustav mora pratiti sve radnje i automatski biljeiti informacije o njima u revizijski dnevnik.
1.1.3 Zahvaanje i proglaavanje zapisa
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju zahvaanja i proglaavanja zapisa su: Zahvaanje zapisa Sustav, u procesu zahvaanja zapisa mora osigurati funkcionalnosti koje omoguavaju: o zahvaanje elektronikih zapisa bez obzira na format datoteka, metoda kodiranja ili drugih tehnolokih karakteristika, bez izmjene sadraja zapisa o osiguravanje povezanosti zapisa i klasifikacijske sheme o osiguravanje povezanosti zapisa s jednom ili vie grupa ili klasa.
Sustav mora omoguiti korisnicima da u revizijskom dnevniku trae specifini dogaaj, objekt (klase, zapisi itd.), korisnika, korisniku grupu, ulogu, vrijeme ili vremenski period.
31. svibnja 2010.
Sustav ne smije postavljati ogranienja na broj zapisa koji se mogu zahvatiti u pojedinoj klasi, grupi, podgrupi ili svesku, niti na maksimalni broj zapisa koji se mogu pohraniti u sustavu.
9/18
Upravljanje elektronikom potom
U sluaju da se zahvaa poruka e-pote, sustav mora osigurati zahvaanje poruke u takvom formatu da budu sauvane informacije iz zaglavlja poruke (eng. header information). Sustav mora omoguiti korisniku izbor naina zahvaanja poruke e-pote s prilozima i to kao: o zahvaanje samo priloga, jednog ili svih kao zasebnih zapisa. o zahvaanje poruke e-pote s prilozima kao jedinstvenog zapisa o zahvaanje samo poruke e-pote bez priloga
U sluaju kada se zahvaa zapis koji se sastoji od vie komponenti, sustav mora omoguiti zahvaanje svih komponenti kao jedinstvenog zapisa, zadravajui veze izmeu komponenti i zadravajui strukturni integritet zapisa.
Ver. 1.0
Sustav mora omoguiti zahvaanje poruke e-pote direktno iz aplikacije e-pote bez potrebe ulaska u Sustav.
Skeniranje i snimanje
Sustav mora imati mogunost povezivanja s barem jednim rjeenjem za skeniranje. o TIFF format (TIFF 6.0) [Adobe 1992] o JPEG forma (ISO 15444) [ISO 15444-1] do [ISO 154444-13] o PDF/A forma (ISO 19005) [HRN ISO 19005-1].
Funkcionalnost skeniranja mora omoguiti pohranu slika u standardnim formatima ukljuujui, ali ne ograniavajui na: Funkcionalnost skeniranja bi trebala imati optiko prepoznavanje znakova (eng. Optical Character Recognition - OCR). Sustav bi trebao omoguiti funkcionalnosti za pregled skeniranih slika.
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju administrativnih funkcija su: 1.1.4 Administrativne funkcije Opi zahtjevi
31. svibnja 2010.
Funkcionalnost skeniranja bi trebala omoguiti automatsko prepoznavanje relevantnih metapodataka u sluaju kada su definirani obrasci skeniranja.
Funkcionalnost skeniranja bi trebala imati mogunost prepoznavanja i zahvaanja individualnih dokumenata prilikom skeniranja vie dokumenata istovremeno (eng. bulk scanning process).
Sustav mora omoguiti administratorima dohvat, prikaz i rekonfiguraciju sistemskih parametara i postavki konfiguriranih u trenutku postavljanja sustava.
10/18
Sustav mora omoguiti administratorima da:
o dodaju korisnika u jednu ili vie grupa ili uloga
Izvjeivanje
Sustav mora omoguiti administratorima kreiranje periodinih izvjea (dnevna, tjedna, mjesena, tromjesena) i definiranje ad-hoc izvjea. Sustav mora omoguiti eksport izvjea za upotrebu u drugim aplikacijama. Sustav mora osigurati izvjea o ukupnom broju i lokacijama za: o grupe, podgrupe i sveske o zapise, sortiranje po formatu i verzijama
o jednostavno prebacuju korisnika izmeu pojedinih korisnikih grupa i uloga.
o alociraju funkcije sustava korisnicima, grupama korisnika ili ulogama
Ver. 1.0
Sustav mora imati funkcionalnosti koje omoguavaju sortiranje i odabir informacija koje su ukljuene u izvjea.
o grupe, podgrupe i sveske, sortirane po kontroli pristupa i sigurnosnim oznakama o grupe, podgrupe i sveske sortirane po veliini o kljune zapise. o grupe, podgrupe i sveske sortirane po mjestu pohrane
Sustav mora omoguiti kreiranje izvjea o veliini trenutno zauzetog i slobodnog sistemskog prostora za pohranu. Sustav mora omoguiti administratorima izradu izvjea o revizijskim zapisima. Izvjea moraju ukljuivati minimalno informacije o: o svesku o zapisu o klasi o podgrupi o grupi
Auriranje, brisanje i ureivanje zapisa

31. svibnja 2010.
Pristup pojedinim izvjeima bi se trebao moi ograniiti od strane administratora sustava.

11/18
o korisniku
o vremenskom periodu.
Sustav mora imati opciju koja sprjeava brisanje ili premjetanje bilo kojeg zapisa od strane korisnika i administratora sustava. Sustav mora omoguiti administratorima brisanje klasa, grupa, podgrupa, svezaka i zapisa koji nisu u procesu izluivanja. Sustav mora omoguiti korisnicima oznaavanje klasa, grupa, podgrupa, svezaka i zapisa koji su kandidati za brisanje. o obrisati cjelokupni sadraj klase, grupe, podgrupe ili sveska o kreirati izvjee za administratore o zapisati revizijski trag u dnevnik
Ver. 1.0
U sluaju brisanja sustav mora:
o osigurati da nije izbrisan niti jedan dokument ije bi brisanje izazvalo promjene u drugom zapisu (npr. ako je dokument dio dvaju zapisa istovremeno) o naglasiti administratorima sve veze iz drugih grupa ili zapisa prema grupama, podgrupama ili svescima koji e biti obrisani, zahtijevajui potvrdu prije brisanja o odravati integritet metapodataka u svakom trenutku.
Administratori moraju moi promijeniti bilo koju vrijednost metapodatka unesenu od strane korisnika. Informacije o svim promjenama metapodataka moraju biti pohranjene u revizijski dnevnik.
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju upravljanja dokumentima i kolaboracije su: 1.1.5 Upravljanje dokumentima i kolaboracija Intencija ovog zahtjeva je da se korisniku dozvoli pohrana dokumenata u radnoj verziji, ali da se on naknadno moe proglasiti zapisom.
Kada sustav upravlja i dokumentima i zapisima unutar iste klasifikacijske sheme, mora nedvosmisleno indicirati koje stavke su dokumenti, a koje zapisi. o brisanje dokumenata
Sustav bi trebao omoguiti upravljanje i elektronikim dokumentima i zapisima u kontekstu iste klasifikacijske sheme koristei isti mehanizam pristupa.
U sluaju kada austav upravlja i zapisima i dokumentima unutar iste klasifikacijske sheme, mora poslati administratorima obavijest u sluaju da se postojei dokumenti, unutar klase ili grupe, izluuju iz sustava, te omoguiti: o proglaavanje dokumenata zapisima
12/18
31. svibnja 2010.
Korisnici moraju moi stvoriti zapis zahvaanjem dokumenta unutar sustava za upravljanje dokumentima. Sustav mora omoguiti korisniku unos vrijednosti metapodataka u trenutku zahvaanja. o vidjeti samo zadnju verziju dokumenta o sve verzije dokumenta o odreenu, odabranu verziju dokumenta
o izluivanje dokumenata zajedno sa zapisima.
Ver. 1.0
Sustav bi trebao omoguiti restrikciju pogleda na dokumente na nain da korisnik moe: o verzije dokumenta koje su zahvaene ili proglaene zapisima.
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju tijeka rada su: 1.1.6 Tijek rada Sustav mora prepoznati kao sudionike procesa i grupe korisnika i pojedine korisnike. Sustav mora omoguiti administratorima definiranje predprogramiranih tijekova rada. Sustav mora omoguiti korisnicima koritenje i pokretanje tijekova rada definiranih od strane administratora. Sustav mora korisnicima dozvoliti uvid u napredak tijeka rada koji su pokrenuli ili u kojem sudjeluju. Sustav ne bi trebao ograniiti broj koraka u pojedinom tijeku rada. Sustav mora omoguiti tijek rada koji se sastoji od vie koraka koji svaki zapoinje prosljeivanjem dokumenta, zapisa ili grupe od jednog prema drugom sudioniku procesa radi izvrenje akcije ili donoenja odluke.
Restrikcija bi se trebala moi napraviti u trenutku konfiguracije ili kasnije od strane administratora.
Sustav bi trebao dozvoliti automatsku deklaraciju dokumenta kao koraka u tijeku rada. Administratori bi trebali imati mogunost dodjeljivanja prava pojedinim korisnicima pomou kojeg oni mogu proslijediti zadatak/akciju nekom drugom korisniku ili grupi korisnika.
31. svibnja 2010.
13/18
Ver. 1.0
Administrative roles should be able to allocate permissions to individual users so that they are able to reassign tasks/actions in a workflow to a different user or group. A user may wish to send a file or record to another user because of the record content, because the assigned user is on leave, or for other reasons.
Sustav mora omoguiti korisniku mehanizam obavjetavanja drugih korisnika o njihovoj potrebnoj panji prema pojedinom zapisu.
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju rada sa sluajevima su: 1.1.7 Rad sa sluajevima U sluajevima kada Sustav koristi druge poslovne aplikacije trebalo bi omoguiti jednostavan pristup povezanim podacima u drugoj aplikaciji i obratno. Sustav mora omoguiti korisnicima pristup i otvaranje predmeta (eng. case file) unosom specifinog identifikatora predmeta
Revizijski trag tijeka procesa mora biti nepromjenjiv.
Revizijski trag tijeka rada trebao bi se integrirati s revizijskim tragom cijelog sustava.
Dozvoljava se koritenje postojeeg sustava elektronike pote ili samostalne aplikacije za slanje obavijesti.
Sustav bi trebao podravati eksport standardnog tijeka rada ili konzistentnih dijelova tijeka rada sukladno bilo kojim standardnim XML shemama.
Sustav mora omoguiti da se predmetu dodijele specifini metapodaci.
U sluajevima kada Sustav omoguava kreiranje novog predmeta iz druge poslovne aplikacije mora moi primiti relevantne metapodatke iz druge aplikacije
Sustav mora omoguiti korisnicima da preko identifikatora predmeta umjesto preko klasifikacijskog koda izvre sve akcije nad predmetom poput dohvata predmeta, pretvaranja u zapis. U sluajevima kada Sustav zaprima zapis sa strukturiranim sadrajem drugog aplikacijskog sustava mora biti u mogunosti automatski izvui metapodatke iz zapisa. U sluajevima kada Sustava zaprima zapis sa strukturiranim sadrajem iz drugog aplikacijskog sustava mora biti u mogunosti automatski izvui metapodatke potrebne za kreiranje zapisa.
31. svibnja 2010.
Sustav mora osigurati unos revizorskog traga u dnevnik za sve radnje izvrene na bilo kojoj klasi, grupi, podgrupi ili zapisu bez obzira na to radi li se o autoriziranom korisniku ili drugom aplikacijskom sustavu.
14/18
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju integracije sa Sustavom za upravljanje sadrajem (u daljnjem tekstu CMS) su: 1.1.8 Integracija sa sustavom za upravljanje sadrajem Sustav mora omoguiti prihvaanje zapisa iz CMS-a ukljuujui i metapodatke, te: o omoguiti korisniku odabir grupe u koju e se pohraniti zapis. o revizorske dnevnike upravljanja sadrajem o predloke stilova (eng. style sheets). o temeljem metapodataka automatski zahvaati zapis u odgovarajuu grupu zapisa ili
Sustav mora omoguiti izradu revizijskih izvjea o svim izvrenim radnjama nad pojedinom grupom bez obzira na to radi li se o autoriziranom korisniku ili drugom aplikacijskom sustavu.
Ver. 1.0
Sustav mora omoguiti zahvaanje komponenti i datoteka CMS-a kao zapisa ukljuujui: Sustav mora omoguiti pohranu metapodataka obaveznih u CMS-u uz metapodatke za upravljanje zapisima definirane MoReq2 specifikacijom. Prijenos zapisa iz CMS-a u Sustav mora se automatski zabiljeiti u revizorski dnevnik i u metapodatke zapisa.
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju elektronikog potpisivanja su: 1.1.9 Elektroniko potpisivanje Sustav mora omoguiti zahvaanje, verifikaciju i pohranu, verifikaciju elektronikih potpisa, pripadajueg elektronikog certifikata i detalja o izdavatelju elektronikog certifikata u trenutku zahvaanja zapisa. Sustav bi trebao imati standardno suelje koji omoguava uvoenje novih tehnologija elektronikog potpisa. Sustav bi trebao omoguiti provjeru valjanosti elektronikog potpisa ukljuujui provjeru elektronikog certifikata, u trenutku zahvaanja zapisa, sa informacijama s liste za opoziv elektronikih certifikata, te pohranu rezultata provjere u metapodatke zapisa. U sluaju negativnog rezultata provjere sustav bi trebao obavijestiti odreenog korisnika ili administratore. Sustav bi trebao ukljuivati funkcionalnost provjere integriteta zapisa koji je elektroniki potpisan. Sustav bi treba omoguiti da se uz zapis pohrani i: o elektroniki potpis povezan sa zapisom
31. svibnja 2010.
15/18
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju integracije telefaksa su: 1.1.10 Integracija telefaksa Sustav mora omoguiti pohranu telefaksa u standardnim formatima, npr. TIFF v6 slikovni format s Group IV kompresijom. Sustav bi trebao omoguiti aplikacijski programsko suelje (eng. application programming interface API) za integraciju telefaks posluitelja. Sustav treba omoguiti zahvaanje telefaksa na integrirani nain, tako da korisnik moe zahvatiti telefaks, kao zapis, direktno iz suelja za zaprimanje telefaksa (ako suelje postoji) bez potrebe ulaska u Sustav. o automatsko zahvaanje telefaksa kao zapisa o automatsko obavjetavanje korisnika s opcijom da se telefaks proglasi zapisom
Transportna poruka je poruka koja se alje izmeu aplikacijskih sustava kao dio transportnog protokola izmeu aplikacijskih sustava.
Sustav bi trebao omoguiti administratorima elektroniko potpisivanje zapisa, grupe, transportne poruke prilikom procesa eksporta ili prijenos podataka u svrhu naknadne provjere integriteta i izvora zapisa, grupe ili transportne poruke.
o elektroniki certifikat za provjeru elektronikog potpisa.
Ver. 1.0
Administratori moraju moi konfigurirati Sustava na jedan od sljedeih naina kada korisnik alje telefaks: o nikakva akcija (oslanjanje na korisnika da e po potrebi proglasiti telefaks zapisom) o naslova/tema o poiljatelja o primatelja.
Sustav bi trebao omoguiti automatsku ekstrakciju metapodataka iz telefaksa poput: o vremena i datuma zaprimanja
31. svibnja 2010.
Kljuni zahtjevi iz specifikacije MoReq2 koje bi sustav trebao zadovoljavati na podruju metapodataka su: 1.1.11 Zahtjevi na metapodatke
16/18
Sustav mora omoguiti korisnicima koji zahvaaju telefaks kao zapis auriranje metapodatka naslova u cilju kratkog opisivanja sadraja telefaksa.
Sustav ne smije nametati ogranienja na broj metapodataka za pojedini entitet (npr. klasu, grupu, podgrupu, svezak, zapis). Sustav mora omoguiti definiciju razliitih skupova metapodataka za razliite tipove zapisa u trenutku konfiguriranja sustava.
Ver. 1.0
U situacijama kada se metapodatak vee na funkcionalno ponaanje sustava, tada sustav mora koristiti kontekst metapodatka za definiranje funkcionalnosti. Npr. kada sustav pohranjuje podatak o otvaranju datoteke mora automatski popuniti metapodatak svaki put kada se datoteka otvara. Sustav mora omoguiti administratorima definiranje, u trenutku konfiguracije, je li metapodatak obvezan ili opcionalan. Sustav mora omoguiti administratorima specifikaciju za koje metapodatke se vrijednosti unose i odravaju runim unosom, a za koje iz kontroliranih rjenika.
Sustav mora omoguiti konfiguraciju metapodataka na nain da se jedanput unesena vrijednost ne moe vie mijenjati od strane korisnika.
Sustav bi trebao omoguiti unos vrijednosti metapodataka iz ifrarnika ili pozivom prema drugim aplikacijskim sustavima. Sustav bi trebao omoguiti konfiguraciju da se vrijednost metapodatka moe koristiti kao polje za pretragu po cijelom tekstu.
31. svibnja 2010.
17/18
Slika 1.1. MoReq2 - E-R Model......................................................................................................................... 5 2 POPIS SLIKA Slika 1.2. MoReq2 - organizacija klasifikacijske sheme ......................................................................... 6 Slika 1.3. Organizacija klasifikacijske sheme sukladno specifikaciji MoReq2 .............................. 7
Ver. 1.0
31. svibnja 2010.
18/18

REPUBLIKAHRVATSKA
Standardniprojekt elektronikoguredskogposlovanja
Privitak2
Primjerprocesauredskogposlovanjauministarstvu
Ver.1.0
Gajeva4,10000Zagreb,Hrvatska telefon:+38516303355,fax:+38516303783;email:ehrvatska@ehrvatska.hr www.ehrvatska.hr
SPEUPPrivitak2:Primjerprocesauredskogposlovanjauministarstvu
SADRAJ
Ver.1.0
1.1 PRIMITAK,OTVARANJEIPREGLEDPOILJKI..........................................................................................................................5 PRIMJERPROCESAUREDSKOGPOSLOVANJAUMINISTARSTVU............................................................3 1.2 UPISIVANJEPISMENAIODREIVANJENADLENOSTI(SIGNACIJA).................................................................................10 1.3 DOSTAVAPISMENAURAD.....................................................................................................................................................13 1.4 ADMINISTRATIVNOTEHNIKAOBRADAAKATA................................................................................................................17 1.5 STAVLJANJEUPISMOHRANUIUVANJE...............................................................................................................................23 1.6 UPRAVNIPOSTUPAK...............................................................................................................................................................26 1.6.1 1.6.2 1.6.3 1.6.4 Pokretanjeupravnogpostupka......................................................................................................................27 Postupakrjeavanjaupravnestvari.............................................................................................................35 Rjeavanjeupravnestvari.................................................................................................................................37 Pravnilijekovi(albenipostupak)................................................................................................................38
2 3 4
2.1 EPCDIJAGRAM........................................................................................................................................................................40 LEGENDAGRAFIKIHSIMBOLA......................................................................................................................40 POPISSLIKA...........................................................................................................................................................42 POPISTABLICA.....................................................................................................................................................44
31.svibnja2010.
2/44
U nastavku su, kao primjer, prikazani procesi uredskog poslovanja u ministarstvu. Procesi uredskog poslovanja u tijelima npr. lokalnesamoupraverazlikovateseodnavedenogprimjerasaspektarolaisl. PRIMJERPROCESAUREDSKOGPOSLOVANJAUMINISTARSTVU Procesnastrukturastandardnogprojektaelektronikoguredskogposlovanjaprikazanajenanajviojrazinidijagramom:
Planiranje dosjea, broj anih oznak a i ov lasti Primitak, otv aranje i pregled poiljk i Upisivanje pismena i odre iv anje nadlenosti (SIGNACIJA)
Ver.1.0
Ustrojavanje pisarnic e i pismohrane
Primitak pismena i drugih poiljk i
Upisiv anje pismena
Donoenje plana k lasifik ac ijsk ih oznak a
Plaanje uprav ne pristojbe
Povezivanje i prijenos upisa
Donoenje prav ilnik a o broj anim oznakam stvaratelja ak ata
Otvaranje i pregled poiljk i
Otvaranje spisa
Postupanje s ak tima ozna enim stupnjem tajnosti
Razvrstavanje i raspore iv anje p ismena
Slika 1.1 Procesna struktura elektronikog uredskog poslovanja (I dio)
31.svibnja2010.
3/44
Dostava pismena u rad Administrativno-tehni ka obrada akata Otprema akata Rokovnik i razvoenja ak ata Stavljanje u pismohranu i uv anje
Ver.1.0
Statistika i mjerenje efik asnosti
Dostavljanje predmeta odnosno pismena u rad
Kreiranje ak ata
Otprema putem pisarnic e
Voenje rokov nik a predmeta
Odlaganje predmeta u pisarnicu
Voenje interne dostav ne k njige
Potpisivanje akata
Otprema putem pote
Razvoenje spisa predmeta
Rukovanje predmetima pohranjenim u pisarnicu
Otpremanje elektroni kim komunik ac ijsk im kanalima
Slika 1.2 Procesna struktura elektronikog uredskog poslovanja (II dio)
31.svibnja2010.
4/44
1.1 Primitak,otvaranjeipregledpoiljki Primitakpismenaidrugihpoiljki
Ver.1.0
Poiljke mogu biti zaprimljene razliitim komunikacijskim kanalima koji ukljuuju neposredniprijemodstranke,potanskuslubu,aliielektronikimkanalima(internetski servisi, elektronika pota, podatkovne sabirnice (EAI/GSB engl. Enterprise Application Integration/GovernmentServiceBus).
Poiljkaje pristiglapreko altera Poiljkaje pristiglaputem pote Poiljkaje pristigla referentu Poiljkaje pristiglaputem weba Poiljkaje pristigla putem epote Poiljkajepristigla putempodatkovne sabirnice
Zaprimanjepoiljki
Poiljkajezaprimljena neposredno Stranka
Poiljkajezaprimljena posredno
Slubenik Izdavanjeslubene biljekeoprimitku pismena Slubenik eUredsko Slanjepotvrdeo primitkupismena

SYS
Poiljatelj
Potvrdaprimitka
Biljekaje izdana
Potvrdaje poslana
Poiljkaje zaprimljena
Poiljka naslovljenana javnopravnotijelo
Poiljkajenaslovljena elnikatijelailina slubenika
Poiljkaje oznaenasa odreenim stupnjemtajnosti
Slika 1.3 Zaprimanje poiljki
5/44
31.svibnja2010.
U poiljci se moe nalaziti jedno ili vie pismena. Potrebno je provjeriti jesu li pristigla pismenauskladuspropisimaoelektronikojispravi.Nadlenaosobapregledavapristigla pismena i daljnji postupak je isti kao kod pismena zaprimljenih konvencionalnim komunikacijskim kanalima. Poiljke se zaprimaju i upisuju u knjigu poiljki (knjigu primljene pote). Poiljke zaprimljene razliitim komunikacijskim kanalima moraju nositi oznaku kanala kojim su zaprimljene, kako bi se mogao mjeriti i pratiti promet razliitim komunikacijskim kanalima u vremenu. Primljena, razvrstana i rasporeena pismena te vlastitiaktiupisujuseuupisnikpredmetaupravnogpostupkailiuurudbenizapisnik. Otvaranjeipregledpoiljki
Strankajepredala podnesakupisarnicu Ponesakjestigaoputem potanskeslube Podnesakjestigao direktnouUpravu Podnesakjestigao elektronikimputem
Ver.1.0
Sortiranje ulaznepote Zaprimanje podneskau Upravi
Omotnicajenaslovljenana javnopravnotijelo
Omotnicaje naslovljenana elnikatijela
Omotnicaje naslovljenana slubenika...
Zaprimanjepote naslovljenena djelatnika
Zaprimanje podneska
Pregledpote zaelnika dravnogtijela
Dostavapodneska zaupis
Podnesaksuputomza urudbiranjejeupisarnici
Urudbiranje podneska
Dostavaunadlenu ustrojstvenujedinicu
Slika 1.4 Primitak i otvaranje poiljki
6/44
31.svibnja2010.
Ver.1.0
Sortiranjepote poprimatelju
Odlaganjeomotnices podneskomdodostave osobinakojuje naslovljena
SLUBENIK PISARNICE
Dostavaneotvorenih omotnicas podneskomunadlenu ustrojstvenujedinicu
PRIMATELJ POILJKE
Omotnicaje dostavljenaslubeniku
Otvaranjeomotnicei pregledpodneska
REFERENT
Dostavapodneskaza urudbiranje
Podnesakjedostavljeni urudbiran
Slika 1.5 Zaprimanje pote naslovljene na slubenika
31.svibnja2010.
7/44
05Zaprimanjepoiljkinaelnikatijela Zaprimanje potezaelnika tijela
Ver.1.0
Dostavaomotniceu kabinet
SLUBENIK
Omotnicaje dostavljenana ministra
Otvaranjeipregled podneska
ELNIKTIJELA
Upisuputeza urudbiranjepodneska
ELNIKTIJELA
Kopiranjepodneskai dostavakopije nadlenomdravnom tajniku
ELNIKTIJELA
Dostavapodneska u pisarnicu na urudbiranje
SLUBENIK
Podnesak dostavljen
Slika 1.6 Zaprimanje poiljki za elnika tijela
31.svibnja2010.
8/44
Postupanjesaktimaoznaenimstupnjemtajnosti
Ver.1.0
Poiljkajezaprimljena prekopisarnice
Poiljkajezaprimljena elektronikimputem
Postupasepremapropisimaozatiti tajnostipodatakai informacisjkojsigurnosti Dostavapoiljke ovlatenojosobi SLUBENIK
Otvaranjeipregled podneska
Evidentiranjeu urudbenomzapisniku povjerljivepote
Dostavanauvid ovlatenojosobi
Pohranapodneskau arhivikabineta
Podnesakjeklasificiran kaotajniipohranjen
Slika 1.7 Zaprimanje podneska oznaenog odreenim stupnjem tajnosti
31.svibnja2010.
9/44
Razvrstavanjeirasporeivanjepismena
Ver.1.0
Zaprimanje poiljkiu pisarnici
Pregledulaznihpoiljki
SLUBENIK PISARNICE
Omotnicanema oznakutajnosti
Omotnicaimaoznaku tajnosti
Sortiranjepotepo primatelju
SLUBENIK PISARNICE
Dostava omotnice primatelju
Zaprimanje tajnepote
Slika 1.8 Razvrstavanje i rasporeivanje pismena
Pismenaserazvrstavajunapismenaupravnogilineupravnogpostupka. 1.2 Upisivanjepismenaiodreivanjenadlenosti(signacija)
Za spise i pismena dodjeljuju se brojane oznake, odnosno klasifikacijske oznake i urudbeni brojevi, u skladu s odredbama Uredbe o uredskom poslovanju i planu klasifikacijskihoznakakojejeorganizacijausvojilazatekuugodinu. Ujedno,odreujeseinadlenostustrojstvenejedinicezarjeavanjepredmeta,tesesviti podaciupisujuuprijemnitambilj. Samim razvrstavanjem i rasporeivanjem pismena, te odreivanjem svih podataka iz prijemnogtambilja,izvrenjeiupispismenauodgovarajuiupisnik,odnosnourudbeni zapisnik. Nakon osnivanja spisa predmeta naknadno pristigli podnesci odnosno akti zdruujusetakodasesvakisljedeipodnesakiliaktdostaviuradunutarnjojustrojstvenoj jedinicikodkojesepredmetnalazi.
10/44
31.svibnja2010.
Klasifikacijska oznaka odreuje se prilikom upisa prvog podneska. Prilikom upisivanja prvog podneska, odnosno akta kojim se osniva predmet, otvara se omot spisa za taj predmet(prikazanosljedeomslikom). Upisivanjepismena
Dostavapodneskaza upis
Ver.1.0
Pregledpodneska
SLUBENIK PISARNICE
Upispodneskau urudbenizapisnik
Upispodneskau upisnikpredmeta upravnogpostupka
Nijepoznatanadlena ustrojstvenajedinica Poznatanadlena ustrojstvenajedinica Traenjeupute zasignaciju predmeta
Odabirpredmetaukoji eseevidentirati podnesak
SLUBENIK PISARNICE
Postojiotvorenpredmet
Predmetpostojialise nalaziupismohrani SLUBENIK PISARNICE SLUBENIK PISMOHRANE
Nemaotvorenog predmeta
Pronalazakpredmetau kojieseevidentirati podnesak
eUredsko
Dearhiviranje predmeta
Otvaranjenovog predmeta
SLUBENIK PISARNICE Podacioposlovnomsubjektu,klasifikacijskaoznaka, urudbenibroj,nadlenaustrojstvenajedinica Postojipredmetukojise evidentirapodensak
31.svibnja2010.
Slika 1.9 Upisivanje pismena (dio I)
11/44
Ver.1.0
eUredsko
Evidentiranjepodneska ipodatakaopodnesku
SLUBENIK PISARNICE
Otisakprijemnog tambilja
SLUBENIK PISARNICE
Podnesakjeevidentirani upisanisupotrebnipodaci
Odlaganjepodneskado dostaveunadlenu ustrojstvenujedinicu
SLUBENIK PISARNICE
31.svibnja2010.
12/44
Ver.1.0
Postojipredmetukojise evidentirapodnesak SLUBENIK PISARNICE SLUBENIK PISARNICE SLUBENIK PISARNICE
eUredsko
Evidentiranjepodneska ipodatakaopodnesku
Otisakprijemnog tambilja
eUredsko Ispiskouljice predmeta
Printer
Podnesakjeevidentirani upisanisupotrebnipodaci SLUBENIK PISARNICE
Odlaganje predmeta/podneskado dostaveunadlenu ustrojstvenujedinicu
Slika 1.10 Upisivanje pismena (dio II)
Poslije upisivanja pismena u upisnik predmeta upravnog postupka odnosno urudbeni zapisnik,pismenasedostavljajuurad. 1.3 Dostavapismenaurad
Primljena pismena razvrstavaju se na pismena predmeta upravnog postupka i pismena predmeta neupravnog postupka. Razvrstana pismena rasporeuju se na unutarnje ustrojstvenejedinice.Razvrstavanjeirasporeivanjeprimljenihpismenaobavljaslubenik pisarnicekojiotvaraipregledavaprimljenepoiljke.
31.svibnja2010. 13/44
Dostavljanjepredmetaodnosnopismenaurad
Dostavljanjepredmeta unadlenuUpravu
Ver.1.0
Predmetjedostavljen unadlenuUpravu
Preuzimanjedostave predmeta/podneska
OVLATENI SLUBENIKUJ
Pregledavanje predmeta/podneska
OVLATENI SLUBENIKUJ
Novipredmet
Novipodnesaku postojeempredmetu
Signacijanovog predmeta
Dostava podneska rjeavatelju...
OVLATENI SLUBENIKUJ
OVLATENI SLUBENIKUJ Dostavapredmeta ravnatelju NAELNIKODJELA
Predmetje dostavljen
31.svibnja2010. 14/44
02ODREIVANJENADLENOSTIIDOSTAVAPREDMETAURAD
Ver.1.0
Dostavljanjepredmeta unadlenuupravu
Predmetjedostavljen unadlenuupravu
Preuzimanjedostave predmeta/podneska
OVLATENI SLUBENIKUJ
OVLATENI SLUBENIKUJ
Novipredmet Signacijanovog predmeta OVLATENI SLUBENIKUJ Dostavapredmeta ravnatelju NAELNIKODJELA Predmetje dostavljen
Novipodnesaku postojeempredmetu OVLATENI SLUBENIKUJ
Dostavaakta rjeavatelju predmeta
Slika 1.11 Dostavljanje predmeta, odnosno pismena u rad
31.svibnja2010.
15/44
08Signacijapredmeta Dostavljanjepredmeta unadlenuupravu
Ver.1.0
Odlukaosignaciji predmeta
RAVNATELJ UPRAVE
Poznatirjeavatelj (tipskipredmet)
Nepoznati rjeavatelj
Signacijananaelnika sektora
RAVNATELJ UPRAVE
NAELNIK SEKTORA
Signacijananaelnika odjela
NAELNIK SEKTORA
NAELNIKODJELA
Signacijana rjeavatelja
Postojievidencija predmetaunutarUprave
Upispredmetau internudostavu
OVLATENI SLUBENIKUJ
Dostava predmeta rjeavatelju
Slika 1.12 Signacija predmeta
16/44
31.svibnja2010.
1.4 Administrativnotehnikaobradaakata Izradaakata

Dostava predmeta/podneska rjeavatelju
Ver.1.0
Izmjenanepotpisanog izlaznogpismena
Predmetsasvimpismenimase nalazikodrjeavatelja
Izlazniaktjevraen nadoradu
Rjeavanje predmetai izradaizlazno...
Parafiranje
Potpisivanje
OTPREMANJE AKATA
Slika 1.13 Rjeavanje i potpisivanje
31.svibnja2010.
17/44
Dostava predmeta/podneska rjeavatelju
Ver.1.0
Rjeavanjepredmeta
REFERENT
SWzaobradu teksta
Izradaakta
REFERENT
Ispisakta
REFERENT
Printer
Parafiranje
Slika 1.14 Rjeavanje predmeta i izrada izlaznog akta
Na jedan primjerak akta, pripremljen za potpis ovlatene slubene osobe, koji ostaje u spisu,potpisstavljaslubenikkojijeaktizradiozapotpis, apopotrebiidrugislubenici kojisusudjelovaliuizradiakta.Potpisisestavljajuupravilusdesnestrane,ispodmjestaza potpisslubeneosobeovlatenezapotpisivanje. Potpisivanjeakata
31.svibnja2010.
18/44
Rjeavanje predmetaiizrada izlaznogakta
Ver.1.0
Dostavaaktanaparaf naelnikuodjela
REFERENT
Dostavacijelog predmeta
REFERENT
Dostavasamoizlaznog akta
REFERENT
Pregledavanjeizlaznog akta
NAELNIKODJELA
Aktjespremanza potpis
Aktnijespreman zapotpis
Parafiranjeizlaznog akta
NAELNIKODJELA
Izmjena nepotpisanog izlaznog...
NAELNIKODJELA
Dostavaaktanaparaf naelnikusektora
NAELNIKODJELA
NAELNIK SEKTORA
Aktjespremanza potpis
Aktnijespreman zapotpis
NAELNIK SEKTORA
Izmjena nepotpisanog izlaznogpismena
NAELNIK SEKTORA
Dostavaizlaznogakta napregled
NAELNIK SEKTORA
RAVNATELJ UPRAVE
Potpisivanje
Slika 1.15 Parafiranje akta
31.svibnja2010.
19/44
Parafiranje
Ver.1.0
Ravnateljima pravopotpisa
Ravnateljnemapravo potpisa
Potpisivanjeizlaznog akta
RAVNATELJ UPRAVE
RAVNATELJ UPRAVE
Izlazniaktje potpisan
Dostavaizlaznogakta napregled
OVLATENI SLUBENIKUJ
Dostavapotpisanog aktarjeavatelju
OVLATENI SLUBENIKUJ
DRAVNITAJNIK
Dravnitajnik imapravo...
Dravnitajniknema pravopotpisa
DRAVNITAJNIK
Dostavljanjenapotpis elnikutijela
TAJNICAELNIKA TIJELA
ELNIKTIJELA
ELNIKTIJELA
Potpisaniizlazniaktje dostavljenrjeavatelju
Otpremanje akta
Slika 1.16 Potpisivanje akta
20/44
31.svibnja2010.
Otpremaakataobavljaseuskladusuputomzaotpremukojujeovlatenaosobaupisala prilikomdostaveaktazaotpremu. Otpremaakata Otpremaputempisarnice

RJEAVANJEI POTPISIVANJE
Ver.1.0
Potpisaniizlazniaktje dostavljenrjeavatelju
Priprema izlaznogaktaza otpremu
Otpremanje izlaznogaktau pisarnici
Gotovorjeavanje predmeta
ODLAGANJEPREMETA UPISMOHRANUI UVANJE
Slika 1.17 Otprema putem pisarnice - Otpremanje akata
31.svibnja2010.
21/44
Priprema izlaznogaktaza otpremu
Ver.1.0
Upisdatumaotpreme naarhivskiprimjerak
SLUBENIK PISARNICE
eUredsko
Oznaavanje Otpremanjeizlaznog aktausustav
SLUBENIK PISARNICE
Otpremanje poiljki
Predmetjepotrebno vratitiurad
Predmetjepotrebno stavitiurok
Predmetjepotrebno razvesti...
Dostavljanjepredmeta uradreferentu
SLUBENIK
Predmetseuvau rokovniku
SLUBENIK
Predmetjedostavljen rjeavatelju Stigaojenoviulazni aktzatajpredmet Istekaojerokuvanja urokovniku
Uzimanjepredmetaiz roka
SLUBENIK Predmetsedostavljau pismohranu SLUBENIK PISMOHRANE
Dostavljanjepredmeta uradreferentu
SLUBENIK ODLAGANJEPREMETA UPISMOHRANUI UVANJE
Slika 1.18 Otprema putem pisarnice - Otpremanje izlaznog akta
31.svibnja2010.
22/44
Potrebnoje otpremitiakt
Ver.1.0
Upisdatumaotpreme
Oznaavanjenaina otpreme
Otpremanjaaktapreko altera
Otpremanjeaktapreko referenta
Otpremanjaaktapute pote
Otpremanjeakta putemweba
Otpremanjeakta putemepote
Otpremanjeakta putempodatkovne sabirnice
Slubenik Internet Email
Podatkovna sabirnica
Aktje otpremljen
Slika 1.19 Otprema elektronikim komunikacijskim kanalima
Rijeeni predmeti stavljaju se u pismohranu i u njoj uvaju, sukladno propisima o zatiti arhivskegrae.Akosepismenaobraujuelektronikimputem,rijeenipredmetisnimaju senaelektronikimedijiuvajunadrugommjestu.Uizvornomoblikunapapiruuvajuse samo oni dokumenti za koje je to utvreno propisom o izluivanju arhivske grae. Na uvanjespisaupismohraniprimjenjujusepropisiouvanjuarhivskegrae. 1.5 Stavljanjeupismohranuiuvanje
31.svibnja2010.
23/44
Odlaganjepredmetaupisarnicu
Ver.1.0
Dostava predmetau pismohranu
Predmetjedostavljen upismohranu
Razvoenjepredmeta upismohrani
Upisdatuma razvoenjairok uvanja
Stavljanjeoznake predmeta"R"
Stavljanjeoznake predmeta"a/a"
uvanjepredmetau pismohrani
Referentjezatraio predmetnauvid
Predmetujeproao rokuvanja
Predmetjetrajno pohranjen
Pretragapredmeta
SLUBENIK PISARNICE
Izluivanjepredmetaiz pismophrane
uvanjepredmeta propisanbr.godina
SLUBENIK PISARNICE
eUredsko
Izdavanjepredmetauz potvrdu
Predmetje izluen
Predavanjearhivske graenadlenom arhivu SLUBENIK PISARNICE
SLUBENIK PISARNICE
Dostavapremeta rjeavatelju
SLUBENIK PISARNICE REFERENT
Predmetje dostavljen
Predmetjepredan nadlenomarhivu
Slika 1.20 Odlaganje predmeta u pisarnicu
31.svibnja2010.
24/44
Ver.1.0
Dostava predmetau pismohranu
Kontrola pismenau spisu
SLUBENIK PISMOHRANE
eUredsko
Upisivanje podatakaonainu rjeavanja
SLUBENIK PISMOHRANE
Pohrana predmetau pismohranu
SLUBENIK PISMOHRANE
uvanje predmetau pismohrani
Slika 1.21 Rukovanje predmetima pohranjenim u pismohrani

31.svibnja2010. 25/44
Temeljni propis koji propisuje postupanje u upravnom postupku jest Zakon o opem upravnompostupku(NN47/09).OvajZakonpropisujekorakeiaktivnostipriprovoenju upravnih postupaka pred nadlenim javnopravnim tijelima. Opisi i grafiki prikazi poslovnih procesa dani ovim modelom temeljeni su i usklaeni upravo s aktivnostima i koracima propisanima Zakonom o opem upravnom postupku. Pokretanje i voenje upravnogpostupka 1.6 Upravnipostupak Pokretanjeivoenjeupravnogpostupkaobuhvaasljedeefunkcije: pokretanjeupravnogpostupka rjeavanjeupravnestvari pravnilijekovi. postupakrjeavanjaupravnestvari
Ver.1.0
Pri tome se u postupku rjeavanja upravne stvari provode specifine radnje u postupku, dokazivanjeiupravljarokovima.Dokazivanjemtijekomrjeavanjaupravnestvariutvruje se injenino stanje. Dokazivanje ukljuuje dokazivanje ispravama koje mogu biti i u elektronikom obliku, sasluavanje svjedoka, provoenje vjetaenja i oevida. Radnje u postupku dokazuju se dokumentima koji se vode tijekom postupka poput podnesaka, zapisnika, zakljuaka. Stranka u postupku ima pravo koritenja pravnih lijekova u albenompostupku.
POKRETANJE I VOENJE UPRAVNOG POSTUPKA
Pokretanje postupka
POSTUPAK RJEAVANJA UPRAVNE STVARI
RJEAVANJE UPRAVNE STVARI
PRAVNI LIJEKOVI
DOKAZIVANJE
-Dokazi -Osiguranje dokaza -Isprav e -Pribav ljanje isprav a -Sv jedoci -Obv eza sv jedoenja -Sasluanje sv jedoka -Vjetaenje -Oev id -Izjav a stranke -Podnesci -Elektronika komunikacija -Zapisnik -Zakljuak -Obnav ljanje (rekonstrukcija) spisa -
RAD NJE U POSTUPKU
ROKOVI
OBAVJEIVANJE
-Oblici obav jeiv anja -Obav jeiv anje o tijeku postupka i razgledav anje spisa -Osobna dostav a -Posredna dostav a -Dostav a zajednikom predstav niku -Dostav a prav noj osobi, osobi koja obav lja registriranu djelatnost i jav noprav nom tijelu -Dostav a u posebnim sluajev ima -
Tijekom cijelog postupka slubena osoba moe obavjeivati stranke u postupku o tijeku postupka pri emu se obavjeivanje moe odvijati konvencionalnim (dostava, pota) ili
Slika 1.22 Pokretanje i voenje upravnog postupka
31.svibnja2010.
26/44
elektronikimputem,aobavljenadostavasepotvrujedostavnicom,odnosnobiljeenjem pismenanaposluiteljuzaprimanjetakvihporuka. 1.6.1 Pokretanjeupravnogpostupka zahtjevstrankezapokretanjemupravnogpostupka,
Ver.1.0
Sukladno Zakonu o opem upravnom postupku, dogaaji koji mogu inicirati pokretanje upravnogpostupkajesu: U posebnim sluajevima, javnopravno tijelo moe pokrenuti upravni postupak javnom objavom. spajanjeilirazdvajanjeupravnihstvari, izmjenazahtjeva, pokretanjeupravnogpostupkaposlubenojdunosti.
Osim pokretanja upravih postupaka, tijekom postupanja u upravnim stvarima mogua je pojavapotrebezapokretanjemsljedeihprocesakojiizravnoutjeunatijekpostupanjau upravnojstvari: odustanakodzahtjevaiobustavapostupka.
Slika 1.23 Pokretanje upravnog postupka
Kadajavnopravnotijelozaprimizahtjevzapokretanjeupravnogpostupka,slubenaosoba javnopravnog tijela, u pravilu slubenik pisarnice, sukladno propisima koji ureuju uredskoposlovanje,upisujezahtjevzapokretanjepostupkauupisnikpredmetaupravnog postupka. Javnopravno tijelo koje ima uredsko poslovanje podrano aplikacijskim sustavom u tu svrhu koristi taj sustav. Radi preglednosti grafikih prikaza, na grafikom prikazu procesa aplikacijski sustav koji podrava uredsko poslovanje oznaen je pojmom eUredsko. Sljedea slika detaljno opisuje aktivnosti koje se odvijaju od trenutka slanja zahtjeva za pokretanje upravnog postupka preko provjerene nadlenosti javnopravnog tijela i potpunosti i razumljivosti podneska do poetka procesa Postupka za rjeavanje upravnestvari,odnosnodoslanjarjeenjaoodbacivanjupodneska. Pokretanjepostupkanazahtjevstranke
31.svibnja2010.
27/44
Podnesak Potrebno pok renuti postupak na zahtjev strank e Zahtjev se moe neposredno podnijeti u pisanom oblik u ili usmenom na zapisnik Slanje Zahtjeva za pok retanje postupk a javnoprav nom tijelu
Ver.1.0
Zahtjeva za pok retanje postupk a
Strank a
Pota
E-mail
e-Uredsk o Zaprimanje i urudbiranje Zahtjev a za pokretanje postupk a Slubena osoba
Podnesak
- klasifikacijsku oznak u predmeta - urudbeni broj pismena - datum primitka zahtjev a
Provjera nadlenosti javnoprav nog tijela
Slubena osoba
Nije nadleno javnoprav no tijelo
Ne moe se utv rditi koje je tijelo nadleno za rad podnesk a
Podnesak Slanje Podnesk au odreeno jav noprav no tijelo Slubena osoba Donoenje Rjeenja k ojim e se odbac iti Podnesak zbog nenadlenosti Slubena osoba
Obavijetavanje o strank e o slanju Podnesk a u drugo javnoprav no tijelo
Slubena osoba Dostava Rjeenja stranc i
Slubena osoba
Rjeenje
Stranka obav jetena o promjeni javnoprav nog tijela
Rjeenje dostav ljeno strancu
31.svibnja2010.
28/44
Nadleno javnoprav no tijelo
Ver.1.0
e-Uredsko
Evidentiranje datuma zaprimanja Podnesk a
Slubena osoba
e-Uredsk o
Izrada i slanje Potv rde podnositelju o preuzetom Podnesk u
Slubena osoba
e-Uredsk o
Evidentiranje datuma slanja Potv rde preporuenom potom
Slubena osoba
Podnesak Provjera potpunosti i razumljiv osti podnesk a Javnoprav no tijelo
Podnesak potpun i razumljiv
Podnesak nepotpun ili/ i nerazumljiv
e-Uredsk o
Upuivanje Upozorenja stranci o nedostatk u i definiranje rok a za otk lanjanje
Slubena osoba
e-Uredsko
Utvrivanje zakonskih pretpostav ki za pokretanje postupk a
Javnoprav no tijelo Stranka obavjetena o nedostatk u Istekao rok za otklanjanje nedostatak a
e-Uredsk o Postoje zakonsk e pretpostav k e zapokretanje postupk a Ne postoje zakonsk e pretpostav k e zapok retanje postupka
Izrada rjeenja o odbacivanju podnesk a
Slubena osoba
e-Uredsk o POSTUPAK RJEAVANJA UPRAVNE STVARI Rjeenje za odbacivanje zahtjev a
Rjeenje o odbacivanju podnesk a izra eno Izrada i slanje Rjeenja za odbacivanje zahtjev a Javnoprav no tijelo
Rjeenje za odbacivanje zahtjev a izra eno
Slika 1.24 Pokretanje postupka na zahtjev stranke
29/44
31.svibnja2010.
Pokretanjepostupkaposlubenojdunosti
Pokretanje postupk a temeljem podnesk a Zaprimanje Predstav k e k oje upuuju na potrebu zatite javnoga interesa na temelju k oje se pokree postupak
Ver.1.0
e-Uredsk o - klasifikacijsku oznak u predmeta - urudbeni broj pismena - datum primitka zahtjev a
Podnesak
Urudbiranje Odluk e uprav nog tijela za pok retanje postupk a
Slubena osoba
Predstav k a
e-Uredsk o
Ocjena o postojanju razloga za pokretanje postupk a po slubenoj dunosti
Slubena osoba
Slubena osoba utv rdila da postoje uvjeti za pok retanje postupka po slubenoj dunosti
Slubena osoba utv rdila da ne postoje uvjeti za pok retanje postupka po slubenoj dunosti Najkasnije u roku od 30 dana od dana podnoenja predstavke treba obav ijestiti podnositelja
POSTUPAK RJEAVAN JA UPRAVNE STVARI
Obavjetav anje podnositeljada ne postoje uvjeti za pokretanje postupk a po slubenoj dunosti
Slubena osoba
Podnositelj ima prav o izjav iti prigov or jav noprav nom tijelu od kojeg je primio obav ijest k ojom se ne prihv a a prijedlog za pokretanje postupka, u roku od osam dana od dana primanja obav ijesti, kao i u sluaju da u propisanom rok u nije dobio odgov or.
Podnositelj nema prigov or na obav ijest
Podnositelj ima prigov or
Osim pokretanja upravnog postupka na zahtjev stranke, upravni postupak moe se pokrenuti i po slubenoj dunosti. Ako je pokretanje postupka po slubenoj dunosti posljedicamonitoringastanjauodreenomupravnompodruju(npr.inspekcijskinadzor), prikljuivanje specifinih procesa u tom upravnom podruju s procesima uredskog poslovanja i njihovo povezivanje elektronikim poslovanjem omoguuje automatsko pokretanje upravnog postupka po slubenoj dunosti temeljem upozorenja pristiglih iz drugihinformacijskihsustava.
Slika 1.25 Pokretanje postupka po slubenoj dunosti
31.svibnja2010.
30/44
Pokretanjepostupkajavnomobjavom
Doneena Odluk a samog upravnog tijela da pok rene postupak jav nom objav om
Ver.1.0
e-Uredsk o
- klasifikacijsku oznak u predmeta - urudbeni broj pismena - datum primitka zahtjev a
Urudbiranje Odluk e uprav nog tijela za pok retanje postupk a Odluk a
Pokretanje postupak kad su strank e nepoznate ili je takav na in pok retanja postupka propisan zak onom
Javnoprav no tijelo
Javna objav a
Javna objav a mora sadrav ati: -naznaku upravne stv ari, -odreenje osoba na k oje se odnosi, -nain sudjelovanja tih osoba u postupk u, -popis isprava koje trebaju poslati ili ih osobno dostav iti jav noprav nom tijelu te -upozorenje na posljedice neodazivanja na jav nu objav u u odre enom rok u.
Definiranje rok a za odaziv anje na javnu objav u
Javnoprav no tijelo
Oglaavanje objav e u odgov araju en slubenom glasilu ili sredstv ima javnog priop enja
Javnoprav no tijelo
Objav a oglaena
Uposebnimsluajevimakadsustrankenepoznateilikadatopropisujezakon,javnopravno tijelomoepokrenutiupravnipostupakjavnomobjavom.
Slika 1.26 Pokretanje postupka javnom objavom
31.svibnja2010.
31/44
Dvijeupravnestvariilivienjihmogusespojitiujedanpostupak,akosepravailiobveze stranakatemeljenaistojpravnojosnoviinaistomilislinominjeninomstanju.Akose promijene okolnosti zbog kojih su stvari spojene u jedan postupak, postupci e se razdvojiti.Spajanje,odnosnorazdvajanjeupravnihstvariobavljasezakljukom.Naproces spajanja odnosno rastavljanja upravne stvari nastavlja se proces Postupka rjeavanja upravnestvari. Spajanjeirastavljanjeupravnestvari
Dvije upravne stv ari ili v ie njih
Ver.1.0
Provjera da li se obv eze stranak a temelje na istoj prav noj obv ezi i na istom ili sli nom injeni nom stanju
Javnoprav no tijelo
Provjera da li je jav noprav no tijelo koje vodi postupak stv arno i mjesto nadleno za voenje svih tih postupak a
Nadleno javnoprav no tijelo Promjena ok olnosti zbog kojih su stvari spojene u jedan postupak Podnesak
Nije nadleno javnoprav no tijelo
Ne moe se utv rditi koje je tijelo nadleno za rad podnesk a
Slanje Podnesk au odreeno jav noprav no tijelo
Slubena osoba
Donoenje Rjeenja k ojim e se odbac iti Podnesak zbog nenadlenosti
Slubena osoba
Razdvajanje postupk a zaklju k om
Obavijetavanje o strank e o slanju Podnesk a u drugo javnoprav no tijelo
Slubena osoba Dostava Rjeenja stranc i
Slubena osoba
Rjeenje
Razdv ajanje upravnih stv ari izv reno
Stranka obav jetena o promjeni javnoprav nog tijela
Rjeenje dostav ljeno strancu
Slika 1.27 Spajanje i rastavljanje upravne stvari
31.svibnja2010.
32/44
Izmjenazahtjeva
Ver.1.0
Pokretanje zahtjev a za Izmjenom zahtjev a
Stranka ima pravo na izmjenu zahtjev a do donoenja prv ostupanjsk e odluke o upravnoj stvari Utvrivanje uvjeta za izmjenom podnesenog ili za podnoenje drugog zahtjev a
Slubena osoba
Zahtjev se u bitnim pretpostav k ama temelji na istom injeni nim stanju
Zahtjev se u bitnim pretpostav k ama ne temelji na istom injeni nim stanju
Izmjena Zahtjev a
Izrada Rjeenja za odbac iv anje zahtjeva strank e Rjeenje za odbac iv anje zahtjeva strank e
Zahtjev izmjenjen
Rjeenja za odbac iv anje zahtjeva strank e izra eno
Ako pokrenuti upravni postupak nije rijeen, stranka moe izmijeniti svoj zahtjev ili podnijeti drugi, ako se ti zahtjevi u bitnim pretpostavkama temelje na istom injeninom stanju.Slubenaosobautvrujepostojanjeuvjetazaizmjenupodnesenogilizapodnoenje drugog zahtjeva, te e donijeti rjeenje kojim e odbaciti zahtjev stranke ili ui u proces Postupkarjeavanjaupravnestvaritemeljemizmijenjenog(novog)zahtjevastranke.
Slika 1.28 Izmjena zahtjeva
31.svibnja2010.
33/44
Odustanakodzahtjevaiobustavapostupka
Ver.1.0
Odustanak od zahtjev a u pisanom oblik u
Odustanak od zahtjev a usmeno na zapisnik
Odustanak od zahtjev a elektroni k im putem
e-Uredsk o
Urudbiranje Zahtjev a za odustav om
Slubena osoba
Slubena osoba e-Uredsk o Izrada Rjeenje o obustav i postupk a Rjeenje o obustav i postupk a
Rjeenje o obustavi postupk a izra eno
Slika 1.29 Odustanak od zahtjeva i obustava postupka
Postupak se moe obustaviti temeljem odustanka stranke od zahtjeva ili po slubenoj dunosti (iz postupanja stranke ili drugih okolnosti postupka moe se zakljuiti da je stranka odustala od zahtjeva). Stranka moe odustati od zahtjeva u pisanom obliku, usmeno na zapisnik ili elektronikim putem. Postupak se obustavlja donoenjem rjeenja o obustavljanju postupka.
31.svibnja2010.
34/44
1.6.2 Postupakrjeavanjaupravnestvari
Ver.1.0
Utvrivanje injeni nog stanja
Podnoenje i ev identiranje dok aza
Neposredno rjeav anje u postupk u pokrenutom na zahtjev strank e
Ispitni postupak
Prethodno pitanje
Nagodba
Neposredno rjeav anje
Neposredno rjeav anje u postupk u pokrenutom po slubenoj dunosti
Usmena rasprav a
Rjeavanje pretnodnog pitanja
Slika 1.30 Postupak rjeavanja upravne stvari
31.svibnja2010.
35/44
Postupakrjeavanjaupravnestvari
Pokretanje postupk a na zahtjev strank e
Ver.1.0
Pokretanje postupk a po slubenoj dunosti
Postoje zak onsk e pretpostavke zapok retanje postupk a
Slubena osoba utv rdila da postoje uvjeti za pok retanje postupka po slubenoj dunosti
Uvjerenje o injenic ama Utvr ivanje injeni nog stanja Javnoprav no tijelo
e-Uredsk o
Podnoenje i ev identiranje dok aza Dokaz
Slubena osoba
Stranka je za sv oje navode ponudila dok aze
Stranka nije za sv oje navode ponudila dok aze
Zakljuak Pozivanje strank e da ponudi dok aze u primjerenom rok u Slubena osoba
Stranka dostav ila dok aze
Stranka nije dostav ila dokaze-postupak je pok renut po slubenoj dunosti
Stranka nije dostav ila dokaze-postupak je pok renut na zahtjev protivne strank e
Stranke nije dostav ila dokaze-bez dok aza se ne moe udov oljiti zahtjevu strank e
Slubena osoba Zahtjev se odbija Rjeenjem Rjeenje
Izrada R jeenja
Neposredno rjeav anje
31.svibnja2010.
36/44
Ver.1.0
Prethodno pitanje
Usmena rasprav a
Rjeav anje pretnodnog pitanja
e-U redsk o
Izrada Z apisnik a
Slubena osoba
Zapisnik
RJEAVANJE UPRAVN E ST VAR I Zapisnik itanje Zapisnik a nazo nim osobama koje su sudjelov ale u uprav noj radnji Slubena osoba
Slubena osoba
Zapisnik Potpisiv anje Z apisnik a Zapisni ar
Osobe k oje su dale izjav u Zapisnik potpisan
Slika 1.31 Poslovni proces: Rjeavanje upravne stvari
1.6.3 Rjeavanjeupravnestvari
Djelomi no rjeav anje upravne stv ari
Dopunsko rjeav anje upravne stv ari
Priv remeno rjeav anje upravne stv ari
Rjeenje u stv arima manjeg znaenja
Slika 1.32 Rjeavanje upravne stvari
37/44
31.svibnja2010.
l. 50. st. 1. t. 2. ZOUP l. 50. st. 1. t. 2. ZOUP l. 50. st. 1. t. 2. ZOUP Pravo stanje stvari moe utv rditi na temelju slubenih podatak a javnoprav nog tijela Poduzimanje hitnih mjera radi zatite ivota i zdrav lja ljudi ili imov ine Stranka u zahtjevu navela koje se ne mogu odga ati, sve injenice ili podnijela potrebne ako je to u javnom interesu, a injenic e na dokaze na temelju k ojih se moe kojima se rjeenje temelji su utv r ene utvrditi pravo stanje stv ari ili barem u injene v jerojatni
l. 50. st. 1. t. 2. ZOUP
Ver.1.0
Propisano da se stv ar moe rijeiti na temelju injenic a ili ok olnosti koje nisu potpuno dokazane
Slubena osoba Donoenje rjeenja i evidentiranje
e-Uredsk o
Rjeenje
Rjeenje Izvrenje rjeenja Nagodba
Djelomi no rjeav anje upravne stvari
Dopunsko rjeav anje upravne stv ari
Priv remeno rjeav anje upravne stv ari
Rjeenje u stv arima manjeg zna enja
PRAVNI LIJEKOVI
Slika 1.33 Rjeavanje upravne stvari
Osnovna postavka upravnog postupka je da stranke imaju pravo na cijeli niz pravnih lijekova. Od suvremenog eservisa oekuje se da stranku vodi kroz taj postupak te ga upozoravanarokove.Nadlenerjeavateljesustavupozoravanaistekrokaipravomonost rjeenja,odnosnodrugedogaaje. 1.6.4 Pravnilijekovi(albenipostupak)
31.svibnja2010. 38/44
Strank a predaje albu Strank a predaje albu
Ver.1.0
e-Uredsk o Kad stranka izjav ljuje albu zbog nedonoenja rjeenja u propisanom roku, alba se moe predati izrav no i drugostupanjskom tijelu
alba
Predaja albe prvostupanjsk om tijelu
Strank a
Strank a
e-Uredsk o
Evidentiranje zaprimljene albe alba
Slubena osoba
alba Prvostupanjsko tijelo ispitat e je li alba doputena, prav odobna i izjavljena od ov latene osobe Slubena osoba
alba Ispitivanje zak onitosti rjeenja k oje se pobija Slubena osoba
alba
Ocjenjivanje svrhov itosti rjeenja Rjeenje
Slubena osoba
Postupanje drugostupanjsk og tijela po primitk u albe
alba osnov ana u c ijelosti ili djelomi no
Prvostupanjesk o tijelo ne odbaci albu ili ne zamijeni pobijano rjeenje novim
alba Zamijena pobijanog rjeenja novim ako se ne dira u prav a tre ih osoba. Slanje albe sa spisom predmeta drugostupanjskom tijelu Slubena osoba Slubena osoba
alba Ocjena da li je alba doputena, pravodobna i izjavljena od ov latene osobe Slubena osoba
Rijeenje zamjenjeno novim
alba odbijena
Rjeenje poniteno u cjelini ili djelomino
Rjeenje izmjenjeno
Slika 1.34 Pravni lijekovi (albeni postupak)
39/44
31.svibnja2010.
Legendagrafikihsimbolakoritenihupoglavlju1.Primjerprocesauredskogposlovanjau ministarstvu. 2 LEGENDAGRAFIKIHSIMBOLA Grafiki prikazi dani su EPC (eng. Event Driven Process Chain) dijagramima koji na intuitivannainprikazujuproceseijepokretanjeiniciraodreenidogaaj.Sljedeatablica prikazujeznaenjepojedinihsimbolauEPCdijagramima: 2.1 EPCdijagram Simbol
Funkcija
Ver.1.0
Tablica 2.1 Legenda grafikih simbola EPC dijagrama
Opis
Kljunefunkcijemodela
Glavni proc es
Aktivnost
Kljuniproces
Aktivnostuprocesu Dogaajuprocesu
Oznakadazafunkciju/proces/aktivnostpostojidetaljnija razradaprikazanadrugimdijagramom(metoda propadanjadrilldown)
Doga aj
referent / slubenik
Dokument
Pismeno(ilidrugidokument)upostupku
Slubenik/referentjavnopravnogtijelakojiobavlja odreenuaktivnost
31.svibnja2010.
40/44
Simbol
e-Uredsk o
Pota
E-mail
Strank a
Aplikacijazapodrkuuredskomposlovanju
Opis
Ver.1.0
Zaprimanje/slanjepismenakonvencionalnompotom/ dostavom Zaprimanje/slanjepismenaelektronikimputem
Javnoprav no tijelo
Napomena
Strankaupostupkukojaobavljaodreenuaktivnost Javnopravnotijelonadlenozaobavljanjeodreene aktivnosti Slijedaktivnostiidogaajaupostupku
Napomenailipojanjenjeodreeneaktivnosti
Logikagrananjauprocesu(I,ekskluzivnoILI,ILI)
31.svibnja2010.
41/44
Slika1.1Procesnastrukturaelektronikoguredskogposlovanja(Idio)........................................ 3 3 POPISSLIKA Slika1.2Procesnastrukturaelektronikoguredskogposlovanja(IIdio)...................................... . 4 Slika1.3Zaprimanjepoiljki................................................................................................................................ 5 Slika1.4Primitakiotvaranjepoiljki.............................................................................................................. 6 Slika1.5Zaprimanjepotenaslovljenenaslubenika............................................................................. 7 Slika1.6Zaprimanjepoiljkizaelnikatijela............................................................................................... 8 Slika1.7Zaprimanjepodneskaoznaenogodreenimstupnjemtajnosti...................................... 9 Slika1.8Razvrstavanjeirasporeivanjepismena..................................................................................10 Slika1.9Upisivanjepismena(dioI)..............................................................................................................11 Slika1.10Upisivanjepismena(dioII)..........................................................................................................13 Slika1.11Dostavljanjepredmeta,odnosnopismenaurad................................................................15 Slika1.12Signacijapredmeta..........................................................................................................................16 . Slika1.13Rjeavanjeipotpisivanje...............................................................................................................17 Slika1.14Rjeavanjepredmetaiizradaizlaznogakta..........................................................................18 Slika1.15Parafiranjeakta.................................................................................................................................19 Slika1.16Potpisivanjeakta..............................................................................................................................20 . Slika1.17OtpremaputempisarniceOtpremanjeakata....................................................................21 Slika1.18OtpremaputempisarniceOtpremanjeizlaznogakta....................................................22 Slika1.19Otpremaelektronikimkomunikacijskimkanalima.........................................................23 Slika1.20Odlaganjepredmetaupisarnicu................................................................................................24 Slika1.21Rukovanjepredmetimapohranjenimupismohrani.........................................................25 Slika1.22Pokretanjeivoenjeupravnogpostupka..............................................................................26 Slika1.23Pokretanjeupravnogpostupka..................................................................................................27 Slika1.24Pokretanjepostupkanazahtjevstranke................................................................................29 Slika1.25Pokretanjepostupkaposlubenojdunosti.........................................................................30 Slika1.26Pokretanjepostupkajavnomobjavom...................................................................................31 Slika1.27Spajanjeirastavljanjeupravnestvari.....................................................................................32 Slika1.28Izmjenazahtjeva...............................................................................................................................33 Slika1.29Odustanakodzahtjevaiobustavapostupka........................................................................34 Slika1.30Postupakrjeavanjaupravnestvari.........................................................................................35
31.svibnja2010.
Ver.1.0
42/44
Slika1.31Poslovniproces:Rjeavanjeupravnestvari.........................................................................37 Slika1.32Rjeavanjeupravnestvari............................................................................................................37 Slika1.33Rjeavanjeupravnestvari............................................................................................................38 Slika1.34Pravnilijekovi(albenipostupak)............................................................................................39
Ver.1.0
31.svibnja2010.
43/44
Tablica2.1LegendagrafikihsimbolaEPCdijagrama..........................................................................40 4 POPISTABLICA
Ver.1.0
31.svibnja2010.
44/44
REPUBLIKA HRVATSKA

Privitak 3
Primjeri modela poslovnih procesa uredskog poslovanja

Ver. 1.0
SPEUP Privitak 3: Primjeri modela poslovnih procesa uredskog poslovanja

SADRAJ
Ver. 1.0
1.1 SLUAJEVI KORITENJA INTERNIH PROCESA UREDSKOG POSLOVANJA .............................................................................. 3 1.1.1 1.1.2 1.1.3 1.1.4 Predmet ................................................................................................................................................................... 3 Pismeno ................................................................................................................................................................... 8 Dostava ................................................................................................................................................................. 12 Otprema ............................................................................................................................................................... 15
PRIMJERI MODELA POSLOVNIH PROCESA UREDSKOG POSLOVANJA .................................................... 3
1.2 PRIMJERI DIJAGRAMA AKTIVNOSTI INTERNIH PROCESA UREDSKOG POSLOVANJA ....................................................... 17 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 Zaprimanje podneska i otvaranje predmeta ......................................................................................... 17 Dostava predmeta/pismena u rad ............................................................................................................. 18 Rjeavanje i potpisivanje ............................................................................................................................... 19 Otpremanje izlaznih akata ........................................................................................................................... 20 Arhiviranje predmeta ..................................................................................................................................... 21
1.3 PRIMJERI UML MODELA ELEKTRONIKOG OTPREMANJA I ZAPRIMANJA PISMENA...................................................... 22 1.4.1 1.4.2 2 3 Web Service PREDMET ............................................................................................................................... 25 Web Service PISMENO ................................................................................................................................ 28
1.4 SPECIFIKACIJA WEB SERVISA ZA E-URED.......................................................................................................................... 25 POPIS SLIKA .............................................................................................................................................................. 31 POPIS TABLICA ........................................................................................................................................................ 32
31. svibnja 2010.
2/32
U nastavku su dani primjeri sluajeva koritenja za razvoj informacijskog sustava, prema zahtjevu odreenog tijela dravne uprave. 1 PRIMJERI MODELA POSLOVNIH PROCESA UREDSKOG POSLOVANJA 1.1 Sluajevi koritenja internih procesa uredskog poslovanja 1.1.1 Predmet
Otvori predmet
Ver. 1.0
uses Promjeni podatke predmeta uses uses Odredi rjeavatelja
uses uses Top Package::Naelnik
uses
Zatvori predmet
uses Top Package::Svi korisnici
Pogledaj predmet
Pridrui pismeno predmetu Pogledaj dostave predmeta uses uses uses Povei predmete uses uses uses Top Package::Administrator SP uses Dostavi predmet Top Package::Referent uses uses uses Stavi predmet u rok
Ispii naljepnicu
Dodaj subjekta u predmet
Slika 1.1 Sluaj koritenja: Predmet
Use-Case "Otvori predmet" omoguava korisniku da otvori novi predmet. Prilikom otvaranja predmeta korisnik upisuje sve potrebne podatke, a minimalni skup podataka koji mora unijeti ini: Otvori predmet Naziv predmeta Vrsta predmeta Dosje
31. svibnja 2010.
3/32
Ostali podaci:
Nadlenost (Ustrojstvena jedinica). Godina otvaranja predmeta Datum. Kljune rijei Napomene.
Ver. 1.0
Dokumentacijsko mjesto korisnika koji otvara predmet automatski se ispisuje na ekranu. Korisnik uz skup obveznih podataka moe unijeti i skup neobveznih podataka kao to su: Rok za rjeavanje UP/I podaci ako se radi o otvaranju upravnog premeta drugog stupnja 1. Signacija (Odreivanje poslovnog podruja) Poetni status spisa je "Otvoren".
Nakon to je korisnik spremio podatke predmeta, moe nastaviti daljnji rad na tom predmetu. Use-Case "Otvori spis" u sebi sadri: Poslovna pravila: 2. Signacija (Odreivanje nadlene ustrojstvene jedinice).
Use-Case "Pridrui predmetu pismeno" omoguava korisniku da postojeem predmetu pridrui neko pismeno. Sustav korisniku prezentira listu pismena (vidi Use-Case: pismeno::Pregledaj pismena) od kojih moe odabrati pismeno koje se onda pridruuje tom predmetu. Pismeno se u tom sluaju ponaa u skladu s Use-Case-om: pismeno::Pridrui pismeno predmetu. Pridrui predmetu pismeno Use-Case "Promijeni podatke predmeta" omoguava korisniku da promijeni osnovne podatke predmeta. Nakon to je korisnik odabrao spis (vidi Use-Case: Pregledaj predmete), prezentiraju mu se podaci predmeta koji se mogu mijenjati. Potvrdom unosa ti se podaci spremaju. Promijeni podatke predmeta Poslovna pravila: Mijenjati se mogu samo spisi kojima je status "U rjeavanju". Spis nakon spremanja podataka ostaje u tom statusu. Samo rjeavatelji i surjeavatelji tog predmeta mogu mijenjati podatke. Poslovno pravilo: Vrijede ista poslovna pravila kao u Pridrui pismeno predmetu.
31. svibnja 2010.
4/32
Use-Case "Dodaj subjekt u predmet" omoguava korisniku da odredi jedan ili vie subjekata u tom predmetu. Prilikom odabira partnera sustav korisniku prezentira listu subjekata iz koje on odabere odreeni subjekt. Ako je subjekt odreen u pismenu koje je pridijeljeno tom predmetu mogue ga je preuzeti iz tog pismena. Kombinacija oba pristupa mogua je u svakom trenutku. Dodaj subjekt u predmet Poslovna pravila: Use-Case "Odredi rjeavatelje" omoguava korisniku da odreenom predmetu odredi rjeavatelja (3. Signacija) i eventualno surjeavatelje. Pokretanje ovog Use-Casea uvjetuje postojanje predmeta za koji se odreuju rjeavatelji i eventualni surjeavatelji, tako da se ovaj Use Case moe izvriti odmah nakon otvaranja predmeta (vidi Use-Case: Otvori predmet) ili u nekom kasnijem trenutku prilikom mijenjanja podataka predmeta (vidi Use Case: Promijeni podatke predmeta). Korisnik iz liste ponuenih korisnika odreuje rjeavatelja predmeta, automatski prilikom odabira korisnika se na podacima spisa vidi taj korisnik s nazivom pripadajue ustrojstvene jedinice i postavlja se datum zaduenja (na trenutni datum). Ako korisnik za taj predmet eli odrediti i surjeavatelje, nakon dodavanja rjeavatelja odabire i potreban broj surjeavatelja. Korisnik svoj zahtjev za surjeavanjem moe obrazloiti kratkim komentarom u previeno polje Prilikom spremanja predmeta svim rjeavateljima i surjeavateljima se alje e-mail (e-obavijest) u kojoj ih se obavjetava da su odreeni kao rjeavatelji (surjeavatelji) na tom predmetu. Pritiskom na link u emailu oni direktno pristupaju tom predmetu gdje moraju dati svoju suglasnost glede dobivenog zaduenja. Prilikom davanja suglasnosti u odgovarajue polje predmeta upisuje se datum davanja suglasnosti odreenog rjeavatelja (surjeavatelja). Odredi rjeavatelje Poslovna pravila: Samo spisu koji ima status "U rjeavanju" moe se dodijeliti partner(e).
Ver. 1.0
Samo korisnik iz nadlene ustrojstvene jedinice moe odrediti rjeavatelje i/ili surjeavatelje Samo spisu koji ima status "Otvoreno" mogue je dodijeliti rjeavatelja i eventualne surjeavatelje Kao rjeavatelji mogu se odrediti samo korisnici iz ustrojstvene jedinice koja je nadlena za taj spis, odnosno za njegovo rjeavanje Kao surjeavatelji mogu se odrediti svi korisnici koji zadovoljavaju prethodni uvjet i svi korisnici drugih ustrojstvenih jedinica koji imaju odgovarajuu ulogu
Prihvaanjem signiranog posla od strane korisnika spisu se mijenja status u "U rjeavanju".
5/32
31. svibnja 2010.
Use Case "Povei spis" omoguava korisniku da jedan spis moe referencirati s drugim. Prilikom rada na nekom spisu, korisnik primijeti da ima drugi spis (predmet) koji se bavi istom tematikom, i taj spis povee s ovim spisom. Povei spis Poslovna pravila: Dostavi spis Oba spisa koji sudjeluju u ovom Use-Caseu moraju najmanje imati status Otvoren ili U rjeavanju.
Ver. 1.0
Use-Case "Dostavi spis" omoguava korisniku da dostavi odabrani spis (vidi Use-Case: spis:Pregledaj spise). Nakon to je korisnik inicirao dostavljanje spisa, ovaj Use-Case se nadopunjava Use-Case-ovima: dostavnica::Kreiraj dostavnicu, dostavnica::Promijeni podatke dostavnice i dostavnica::Poalji dostavnicu. Poslovna pravila:
Use-Case "Ispii naljepnicu" omoguava korisniku da ispie naljepnicu spisa, koju onda zalijepi na kouljicu spisa. Naljepnica sadri sljedee podatke: Ispii naljepnicu Datum otvaranja spisa Godina otvaranja predmeta Redni broj spisa Naziv nadlene ustrojstvene jedinice
Vrijede ista poslovna pravila kao u: Kreiraj dostavnicu, Promijeni podatke dostavnice, Poalji dostavnicu.
Use-Case "Zatvori predmet" omoguava korisniku da predmet na kojem je posao gotov zatvori. Zatvori predmet Poslovna pravila: Samo naelnik nadlene ustrojstvene jedinice predmeta moe zatvoriti predmet Sva izlazna pismena moraju biti otpremljena.
Naziv predmeta
Klasifikacijsku oznaku predmeta.
Use-Case "Pregledaj dostave predmeta" omoguava korisniku da u svakom trenutku moe vidjeti kada je i kome neki spis dostavljen. Pregledaj dostave predmeta
31. svibnja 2010. 6/32
Use-Case "Stavi predmet u rok" omoguava korisniku da odreeni predmet stavi i vrati iz roka. Stavi predmet u rok Poslovna pravila: Predmet mora imati status "U rjeavanju" Samo rjeavatelj moe predmet staviti u rok Predmet nakon stavljanja u rok ima status "U roku"
Ver. 1.0
Predmet nakon vraanja iz roka ima status "U rjeavanju"
Use-Case "Pregledaj predmete" omoguava korisniku da dobije popis predmeta po odabranom kriteriju, koji ovisi o njegovim pravima na sustavu, te trenutnoj poslovnoj funkciju koja se izvrava. Sustav omoguava korisniku da navigira kroz popis na razne naine, te da sortira kolone po vlastitoj volji. Pregledaj predmete
Ako se predmetu pridrui pismeno dok je u roku, on se automatski sam vraa iz roka.
31. svibnja 2010.
7/32
1.1.2 Pismeno
Ver. 1.0
Pogledaj otpreme pismena uses Potpii izlazno pismeno
uses Promijeni podatke pismena Top Package::Naelnik
uses
uses
Pogledaj pismena uses
Kreiraj izlazno pismeno
uses uses uses Top Package::Svi korisnici Top Package::Referent uses Pogledaj dostave pismena Trai potpis pismena
Dostavi pismeno
uses Otpremi pismeno
Pridrui pismeno predmetu
uses
uses
Dodaj subjekt u pismeno
Top Package::Administrator SP
Registriraj ulazno pismeno
Slika 1.2 Sluaj koritenja: Pismeno
Use Case "Registriraj ulazno pismeno" omoguava korisniku da registrira novo ulazno pismeno. Prilikom kreiranja ulaznog pismena korisnik upisuje sve potrebne podatke, a minimalni skup podataka koji mora unijeti ini: Registriraj ulazno pismeno Podaci tko je registrirao pismeno, iz koje ustrojstvene jedinice i kojem dokumentacijskom mjestu pripada ta ustrojstvena jedinica ispisuju se automatski. Korisnik uz skup obaveznih podataka moe unijeti i skup neobaveznih podataka kao to su: Va znak Datum nastanka Datum uruenja Ostali podaci: vrsta pismena. naziv pismena
31. svibnja 2010.
8/32
Va datum Prilozi:
Vrijednosti uz pismeno (npr. pristojbe) Broj priloga Popis priloga.
Ver. 1.0
Nakon to je korisnik spremio podatke pismena, on moe nastaviti daljnji rad na tom pismenu. Tijekom upisa podataka korisnik moe pismeno direktno pridruiti nekom spisu na nain da iz liste spisa, koju mu prezentira sustav (vidi Use-Case: spis::Pregledaj predmete) odabere predmet za to pismeno. Poslovna pravila: U/I status mora biti "ULAZNO" Poetni status pismena je "Zaprimljeno".
Use-Case "Kreiraj izlazno pismeno" omoguava korisniku da kreira novo izlazno pismeno. Prilikom kreiranje izlaznog pismena korisnik upisuje sve potrebne podatke, a minimalni skup podataka koji mora unijeti ini: Kreiraj izlazno pismeno Podaci tko je registrirao pismeno, iz koje ustrojstvene jedinice i kojem dokumentacijskom mjestu pripada ta ustrojstvena jedinica ispisuju se automatski. Korisnik uz skup obaveznih podataka moe unijeti i skup neobaveznih podataka kao to su: Primatelji pismena Nain otpreme Ostali podaci: Va znak Datum nastanka Datum uruenja Naziv pismena Vrsta pismena.
Va datum Prilozi:
Nakon to je korisnik spremio podatke pismena moe nastaviti daljnji rad nad tim pismenom.
31. svibnja 2010.
Broj priloga
Popis priloga.
9/32
Tokom upisa podataka korisnik moe pismeno direktno pridruiti nekom predmetu na nain da iz liste predmeta, koju mu prezentira sustav (vidi Use-Case: Pregledaj predmete), odabere odgovarajui predmet. Poslovna pravila: U/I status mora biti "IZLAZNO" Nakon spremanja status je u "U izradi".
Ver. 1.0
Use-Case "Trai potpis pismena" omoguava korisniku da neko pismeno alje na autorizirajui potpis. Korisnik koji treba autorizirati to pismeno svojim potpisom biva preko e-mail-a obavijeten o tom pismenu. Preko upravljake konzole primatelj pristupa pismenu. Trai potpis pismena Poslovna pravila: Samo pismena iji je U/I Status : "Izlazno" mogu se slati na potpis Nakon slanja status pismena prelazi u "Na potpisu". Samo pismena koji imaju statusu "U izradi" mogu se slati na potpis Samo korisnik koji je registrirao pismeno moe ga slati na potpis
Use-Case "Potpii pismeno" omoguava korisniku da autorizira odgovarajue pismeno. Prilikom primitka obavijesti korisnik moe odobriti ili odbiti potpis. Potpii pismeno Poslovna pravila:
Pismena koja se potpiu prelaze u status "Potpisano", nikakve promjene, od bilo koga, nad tim pismenom vie nisu mogue
Poslovna pravila:
Use Case "Pridrui pismeno spisu" omoguava korisniku da postojee pismeno pridrui nekom spisu. Sustav korisniku prezentira listu spisa (vidi Use-Case: Pregledaj predmete) od kojih on moe odabrati predmet kojem se onda pridruuje to pismeno. Pismeno se u tom sluaju ponaa u skladu s Use-Caseom: Pridrui predmetu pismeno. Pridrui pismeno spisu Pismeno je mogue pridruiti samo jednom spisu Ulazno pismeno: prelazi u status "Pridrueno". Izlazno pismeno: samo ako je korisnik rjeavatelj ili surjeavatelj na tom spisu
10/32
Pismena kojima se odbija potpis prelaze u status "Odbijeno", korisnik koji je to pismeno slao na potpis mora ga doraditi i ponovno poslati na potpis.
31. svibnja 2010.
Use Case "Promijeni podatke pismena" omoguava korisniku da promijeni osnovne podatke pismena. Nakon to je korisnik odabrao pismeno (vidi Use Case: Pregledaj pismena), prezentiraju mu se podaci pismena koji se mogu mijenjati. Potvrdom unosa ti podaci se spremaju. Promijeni podatke pismena Poslovna pravila: Mijenjati se mogu samo pismena kojima je status "U izradi" ili "Odbijeno" Pismeno nakon spremanja podataka ima status "U izradi" Vrijede ista poslovna pravila kao u: Kreiraj izlazno pismeno, :Registriraj ulazno pismeno.
Ver. 1.0
Use-Case "Dostavi pismeno" omoguava korisniku da dostavi odabrano pismeno (vidi UseCase: Pregledaj pismena) na rjeavanje, te dostavu svih drugih pismena zaprimljenih i registriranih u sustavu. Nakon to je korisnik inicirao dostavljanje pismena, ovaj Use-Case se nadopunjava Use-Caseovima : Kreiraj dostavnicu, Promijeni podatke dostavnice i Poalji dostavnicu. Dostavi pismeno Poslovna pravila: Vrijede ista poslovna pravila kao u:Kreiraj dostavnicu, Promijeni podatke dostavnice, Poalji dostavnicu
Use Case "Pregledaj dostave pismena" omoguava korisniku da dobije kompletan pregled dostava tog pismena. Pregledaj dostave pismena Poslovna pravila: Pregledaj otpreme pismena Poslovna pravila: Korisnik vidi samo podatke dostave pismena koje je on kreirao/registrirao.
Use Case "Pregledaj otpreme pismena" omoguava korisniku da dobije kompletan pregled otprema tog pismena. Use-Case "Pregledaj pismena" omoguava korisniku da dobije popis pismena po odabranom kriteriju, koji ovisi o njegovim pravima na sustavu, te trenutnoj poslovnoj funkciju koja se izvrava. Sustav omoguava korisniku da navigira kroz popis na razne naine, te da sortira kolone po vlastitoj volji. Pregledaj pismena
11/32
Korisnik vidi samo podatke otpreme pismena koje je on kreirao/registrirao.
31. svibnja 2010.
Use Case "Dodaj subjekt u pismeno" omoguava korisniku da odredi jedan ili vie subjekata pismena, kojima se nakon potpisivanje pismena, to pismeno otprema. Prilikom odabira subjekta sustav korisniku prezentira listu subjekata iz koje on odabere odreeni broj subjekata. Ako se to pismeno otprema svim subjektima treba odabrati nain otpreme za to pismeno, u suprotnom sluaju treba svaki subjekt kojemu se to pismeno alje posebno oznaiti kao primatelja. Dodaj subjekt u pismeno Poslovna pravila: 1.1.3 Dostava Samo pismenima koji imaju status "U izradi" mogu se dodjeljivati subjekti.
Ver. 1.0
Dodaj stavke dostavnice
uses Pogledaj dostave uses
uses Poalji dostavnicu uses
Top Package::Svi korisnici
uses Prihvati dostavnicu
uses
Prihvati dostavu
Promijeni podatke dostavnice
Slika 1.3 Sluaj koritenja: Dostava
Use-Case "Kreiraj dostavnicu" omoguava korisniku da kreira dostavnicu. Ovo je poetni Use-Case prilikom procesa dostave. Nakon to je korisnik kreirao dostavnicu moe dodavati stavke dostavnice (vidi Use-Case: Dodaj stavke dostavnici) i na kraju poslati Kreiraj dostavnicu
31. svibnja 2010.
12/32
dostavnicu (vidi Use-Case: dostavnica::Poalji dostavnicu). Sve te radnje mogu se obaviti odjednom ili asinkrono u diskretnim vremenskim trenucima. Nakon to je korisnik kreirao dostavnicu sustav mu prua mogunost da odmah dodaje stavke dostavnice (vidi Use-Case: Dodaj stavke dostavnici) ili da te aktivnosti odgodi za drugi trenutak. Poslovna pravila: Dodaj stavke dostavnici Poetni status dostavnica je "U radu".
Ver. 1.0
Use-Case "Dodaj stavke dostavnici" omoguava korisniku da dodaje razne stavke postojeoj dostavnici. Stavke mogu biti ili spisi ili pismena ili oboje. Prilikom odabira korisnik moe izabrati jednu ili vie stavaka istog tipa za dodavanje, nije mogue da korisnik odabere u jednom trenutku dvije stavke razliitog tipa, odnosno, na jednoj stavci ne mogu istovremeno biti i spis i pismeno. Poslovna pravila: Stavke se mogu dodavati samo na dostavnice kojima je status "U radu" Dostavnica ostaje u tom status nakon dodavanja stavaka Stavka dostavnice moe biti ili spis ili pismeno Spisi koji imaju status "Otvoreno" ili "U rjeavanju" Spise iji je rjeavatelj korisnik koji kreira dostavnicu Na dostavnicu se mogu dati stavke koje zadovoljavaju:
Pismena koji imaju status "Zaprimljeno", "Pridrueno" i "Potpisano" Pismena koje je kreirao korisnik koji kreira dostavnicu
Spisi i pismena koja nisu ve na nekoj dostavnici koja ima status "U izradi" ili "U dostavi"
Use-Case "Poalji dostavnicu" omoguava korisniku da gotovu dostavnicu poalje odgovarajuem dokumentacijskom mjestu ili osobi. Paralelno sa slanjem dostavnice, sustav primatelja dostave obavjetava o dostavi e-mailom u kojem primatelj klikom na link moe direktno pristupiti dostavnici. Da ako si korisnik sam definira alarme za dostavnice koje su u dostavi prilikom aktivacije alarma korisnik sam moe definirati u kojem periodu eli primati mailove za neprihvaene dostavnice. Poalji dostavnicu
31. svibnja 2010.
Samo ona pismena i spis koja se nalaze (fiziki) u dokumentacijskom mjestu iz koje je korisnik koji kreira tu dostavnicu.
Poslovna pravila:
Mogue je dostaviti samo dostavnice kojima je status "U radu"
13/32
Dostavnica mora imati bar jednu stavku
Use-Case "Prihvati dostavu" slui za potvrdu primitka dostave. Korisnik na osnovu e-maila, u kojem je obavijeten da je dobio dostavu, ili pregledom dostavnica odabere novu dostavu, koju moe prihvatiti ili odbiti. Prihvati dostavu Poslovna pravila: Dostavnica mora imati status "U dostavi" Dostavu moe prihvatiti samo korisnik kojem je ta dostavnica bila namijenjena ili korisnik u istom dokumentacijskom mjestu Dostavu moe odbiti samo korisnik kojemu je ta dostavnica bila namijenjena ili korisnik u istom dokumentacijskom mjestu Nakon to se neka dostavnica prihvati, a materijalna je, sva pismena i svi spisi koji se nalaze na toj dostavnici mijenjaju lokaciju, odnosno dokumentacijsko mjesto u ono koje ih je prihvatilo. Ako korisnik prihvati dostavu status dostavnice prelazi u stanje "Dostavljeno" Ako korisnik iz bilo kojeg razloga odbije primitak dostave dostavnica prelazi u stanje "Odbijeno"
Samo korisnik koji je kreirao dostavnicu moe poslati dostavnicu
Ver. 1.0
Nakon to korisnik dostavnicu poalje, ta dostavnica prelazi u stanje "U dostavi".
Use-Case "Promijeni podatke dostavnice" omoguava korisniku da promijeni osnovne podatke dostavnice. Nakon to je korisnik odabrao neku dostavnicu (vidi Use-Case: Pregledaj dostavnice), prezentiraju mu se podaci dostavnice koji se mogu mijenjati. Promijeni podatke dostavnice Poslovna pravila: Mijenjati se mogu samo dostavnice kojima je status "U radu" ili "Odbijeno" Dostavnica nakon spremanja promjena ima status "U radu.
Use-Case "Pregledaj dostave" omoguava korisniku da dobije popis dostavnica po odabranom kriteriju, koji ovisi o njegovim pravima na sustavu, te trenutnoj poslovnoj funkciji koja se izvrava. Sustav omoguava korisniku da navigira kroz popis na razne naine, te da sortira kolone po vlastitoj volji. Pregledaj dostave
31. svibnja 2010.
14/32
1.1.4 Otprema
Ver. 1.0
Dodaja pismena otpremnici
uses
uses
Kreiraj otpremnicu
uses
uses Top Package::Administrator SP uses
Pogledaj otpreme
Poalji otpremnicu
Promijeni podatke otpremnice
Slika 1.4 Sluaj koritenja: Otprema
Use-Case "Kreiraj otpremnicu" omoguava korisniku da kreira novu otpremnicu. Ovo je poetni Use-Case prilikom procesa otpreme. Nakon to je korisnik kreirao otpremnicu moe dodavati stavke otpremnice (vidi Use-Case: Dodaj stavke otpremnici) i na kraju poslati otpremnicu (vidi Use-Case: Poalji otpremnicu). Sve te radnje mogu se obaviti odjednom ili asinkrono u diskretnim vremenskim trenucima. Kreiraj otpremnicu Nakon to je korisnik kreirao otpremnicu sustav mu prua mogunost da odmah dodaje stavke otpremnice (vidi Use-Case: Dodaj stavke otpremnici) ili da tu aktivnosti odgodi za drugi trenutak. Poslovna pravila: Use-Case "Dodaj pismena otpremnici" omoguava korisniku da dodaje pismena postojeoj otpremnici. Prilikom odabira korisnik moe izabrati jedno ili vie pismena. Dodaj pismena otpremnici Poslovna pravila:
31. svibnja 2010.
Poetni status otpremnice je "U radu"
Otpremnica ostaje u tom statusu nakon dodavanja stavaka
Stavke se mogu dodavati samo na otpremnice kojima je status "U radu"
15/32
Stavka otpremnice moe biti samo pismeno
Na otpremnicu se mogu dati stavke koje zadovoljavaju:
Ver. 1.0
Izlazna pismena koji imaju status "U izradi" i Potpisano
Pismena koja ve nisu na nekoj otpremnici koja ima status "U izradi" ili "Otpremljeno"
Use-Case "Poalji otpremnicu" omoguava korisniku da gotovu otpremnicu poalje odgovarajuem dokumentacijskom mjestu. Poalji otpremnicu Poslovna pravila: Mogue je otpremiti samo otpremnice kojima je status "U radu" Otpremnica mora imati bar jednu stavku Samo korisnik koji je kreirao otpremnicu moe poslati otpremnicu
Samo ona pismena koja se nalaze (fiziki) u dokumentacijskom mjestu iz koje je korisnik koji kreira tu otpremnicu.
Use-Case "Promijeni podatke otpremnice" omoguava korisniku da promijeni osnovne podatke otpremnice. Nakon to je korisnik odabrao neku otpremnicu (vidi Use-Case: Pregledaj otpremnice), prezentiraju mu se podaci otpremnice koji se mogu mijenjati. Promijeni podatke otpremnice Poslovna pravila: Mijenjati se mogu samo otpremnice kojima je status "U radu" Otpremnica nakon spremanja podataka ostaje u statusu "U radu".
Nakon to korisnik otpremnicu poalje, ta otpremnica prelazi u stanje "Otpremljeno"
Use-Case "Pregledaj otpreme" omoguava korisniku da dobije popis otprema po odabranom kriteriju, koji ovisi o njegovim pravima na sustavu, te trenutnoj poslovnoj funkciju koja se izvrava. Sustav omoguava korisniku da navigira kroz popis na razne naine, te da sortira kolone po vlastitoj volji. Pregledaj otpreme
31. svibnja 2010.
16/32
1.2 Primjeri dijagrama aktivnosti internih procesa uredskog poslovanja 1.2.1 Zaprimanje podneska i otvaranje predmeta
STRANKA PISARNICA UPRAVA
Ver. 1.0
Zaprimanje podneska
Predaja podneska
Zaprimanje podneska
Dostava podneska u Pisarnicu
Provjera formalnih nedostataka
Uoeni formalni nedostaci
DA
NE
Sastavljanje slubene zabiljeke o nedostatku u prilogu podneska
Pretraivanje registra predmeta na osnovu podataka iz sadraja pristiglog podneska
Vraanje podneska sa zabiljekom na dopunu
Stavljanje otiska prijemnog
12. Prima potvrdu o prijemu
Izdavanje potvrde o prijemu podneska sa ev. br. i datumom
DA
Da li je podnesak neposredno zaprimljen
NE
DA
Predmet ve otvoren
NE
Auriranje kartice predmeta i omota spisa
Otvaranje novog predmeta i odreivanje signacije nad predmetom
Dostava predmeta u rad (interna dostavnica)
Potpisivanje interne dostavnice (zaprimanje predmeta u rada)
Odreivanje vrste postupanja
31. svibnja 2010.
Slika 1.5 Dijagram aktivnosti: Zaprimanje podneska i otvaranje predmeta
17/32
1.2.2 Dostava predmeta/pismena u rad
Ver. 1.0
PISARNICA
UPRAVA
Kreiranje interne dostavnice
Slanje predmet, pismena u Upravu
Zaprimanje predmeta,pismena (interna dostavnica)
Signacija predmeta
Odluka o signaciji predmeta
Nepoznat rjeavatelj
Poznat rjeavatelj (tipski predmet) Signacije predmeta na naelnika sektora
Pregled predmeta, pismena
Signacija na naelnika odjela
Pregled predmeta, pismena
Signacija na rjeavatelje
Postoji evidencija predmeta unutar Uprave
Upis predmeta u internu evidenciju
Dostava predmeta u rad
Slika 1.6 Dijagram aktivnosti: Dostava predmeta/pismena u rad
31. svibnja 2010.
18/32
1.2.3 Rjeavanje i potpisivanje
Ver. 1.0
MINISTAR/ DRAVNI TAJNIK
RAVNATELJ/ NAELNIK SEKTOR/ NAELNIK ODJELA
RJEAVATELJ ( REFERENT)
Preuzimanje predmeta
Rjeavanje predmeta
Izrada izlaznog akta
Parafiranje akta
Dostava na parfiranje, potpisivanje
Pregledavanje izlaznog akta
Da li je akt spreman za potpisivanje
Ne Slanje na doradu
Da
Da li postoji ovlast za potpisivanje akta?
Da
Potpisivanje akta Ne
Dorada izlaznog akta
Dostava akta na potpisivanje
Dostava potpisanog akta
Prihvaanje i pregled akta
Da li je akt spreman za potpisivanje
Ne
Da
Slanje na doradu
Potpisivanje akta
Preuzimanje i priprema za otpremu
Dostavljanje na otpremu
Slika 1.7 Dijagram aktivnosti: Rjeavanje i potpisivanje
31. svibnja 2010.
19/32
1.2.4 Otpremanje izlaznih akata

RJEAVATELJ (REFERENT)
Ver. 1.0
PISARNICA
Priprema akta za otpremu
Dostava akta u pisarnicu (interna dostavnica)
Preuzimanje akta (interna dostavnica)
Upis datuma otprema na arhivski primjerak
Otpremanje akta
Ne
Da li je predmet potrebno staviti u rok?
Da
Vratiti u rad Vratiti u rad ili arhivirati?
Stavljanje predmeta u rokovnik
Arhivirati
Dostava predmeta u pismohranu
Istekao rok
Da li je istekao rok ili stiglo novo pismeno?
Novo pismeno
Prihvaanje predmeta
Vaenje predmeta iz rokovnika predmeta
Slika 1.8 Dijagram aktivnosti: Otpremanje izlaznih akata
31. svibnja 2010.
20/32
1.2.5 Arhiviranje predmeta

RJEAVATELJ (REFERENT)
Ver. 1.0
PISMOHRANA
Dostava predmeta na arhiviranje
Zaprimanje predmeta za arhiviranje
Kontrola pismena u spisu
Upis podataka u arhivske evidencije
Odlaganje predmeta u arhivu
Izluivanje predmeta iz arhive
Ne
Da li potrebno dostavit na uvanje u nadleni arhiv?
Da
Unitavanje arhivske grae
Dostava predmeta u nadleni arhiv
Slika 1.9 Dijagram aktivnosti: Arhiviranje predmeta
31. svibnja 2010.
21/32
1.3 Primjeri UML modela elektronikog otpremanja i zaprimanja pismena Sluajevi koritenja
IS poiljatelja
Ver. 1.0
Kreiraj pismeno/dokument
uses uses
pripremi omotnicu
uses Zaprimi potvrdu omotnice extends
Poiljatelj uses
uses
otpremi omotnicu sa dokumentom Zaprimi potvrdu primitka dokumenta uses uses
uses uses
e-Potpis posluitelj
uses
Posluitelj za zaprimanje elektronikih dokumenata

uses Zaprimi omotnicu uses Potvrdi zaprimanje omotnice uses
uses Potpii uses uses Ovjeri potpis Potvrdi primitak dokumenta
uses
Government Gateway uses Proslijedi omotnicu

- potpisati se moe dokument, omotnica, potvrda
uses
Aplikacija uredskog poslovanja primatelja uses

Potvrdi primitak
uses uses Zaprimi omotnicu
uses
uses Primatelj
uses uses Slubenik pisarnice
uses
Raspakiraj omotnicu Proslijedi u pisarnicu Registriraj pismeno
Slika 1.10 Sluaj koritenja: Elektroniko otpremanje i zaprimanje pismena
31. svibnja 2010.
22/32
Dijagrami aktivnosti
Poiljatelj
Kreiraj dokument
Ver. 1.0
Primatelj
Government Gateway
e-Potpis server
Pisarnica
Potpii dokument Ovjeri potpis Kreiraj omotnicu
Potpii omotnicu Ovjeri potpis
Otpremi Zaprimi omotnicu Zaprimi omotnicu Potvrdi zaprimanje omotnice
Proslijedi omotnicu Ovjeri potpis
Potpii primitak omotnice Raspakiraj omotnicu
Zaprimi potvrdu primitka omotnice
Proslijedi potvrdu primitka omotnice
Poalji potvrdu primitka
Zaprimi pismeno
Potpii primitak dokumenta Zaprimi potvrdu primitka dokumenta Proslijedi potvrdu primitka dokumenta Ovjeri potpis Dostavi pismeno primatelju
Poalji potvrdu primitka dokumenta
Slika 1.11 Dijagram aktivnosti: Elektroniko otpremanje i zaprimanje pismena
31. svibnja 2010.
23/32
Dijagram stanja
Ver. 1.0
- kreiran elektroniki dokument - elektroniki dokument potpisan ePotpisom - definiran(i) primatelj(i)
eOmotnica kreirana
Omotnica elektroniki potpisana
Omotnica otpremljena
Omotnica zaprimljena na posluitelj za zaprimanje e-dokumenata
Omotnica neispravna
Potvren primitak otpremnice na posluitelju za zaprimanje e-dokumenata
- nemogue idenficiriati primatelja - neispravan format dokumenta - neispravan ePotpis
eOmotnica proslijeena primatelju
Omotnica odbijena Omotnica zaprimljena kod primatelja
- nepodran format dokumenta - neispravan ePotpis Omotnica prihvaena
Potvrda primitka poslana
Slika 1.12 Dijagram stanja: Elektroniko otpremanje i zaprimanje pismena
31. svibnja 2010.
24/32
U ovom poglavlju dani su primjeri web servisa za neke funkcionalnosti u uredskom poslovanju. 1.4 Specifikacija WEB servisa za e-Ured 1.4.1 Web Service PREDMET
Metoda KreirajPredmet
Tablica 1.1 Metoda KreirajPredmet
Ver. 1.0
Parametar upisnaKnjiga
Tip String String Int String Int String Date
Opis
vrstaPredmeta nadleznaOrgJedinica rjesavatelj subjekt nazivPredmeta
Oznaka upisnika u kojem se otvara predmet ifra vrste predmeta klasifikacijskih oznaka ifra ustrojstvene jedinice nadlene za rjeavanje predmeta. Ako se ne preda rjeavatelj, onda je ovaj parametar obvezan Identifikator slubenika koji zaduen za rjeavanje predmeta Identifikator stranke je iz plana
Obveznost DA DA NE NE NE NE
datumOtvaranja Username
Ako naziv predmeta nije predan, generira se konkatenacijom naziva subjekta i naziva vrste predmeta Ako se ne preda datum, koristi se trenutno vrijeme na serveru Identifikator slubenika koji otvara predmet
DA
String
DA
31. svibnja 2010.
25/32
SPEUP Privitak 3: Primjeri modela poslovnih procesa uredskog poslovanja Metoda OdrediRjesavatelja
Tablica 1.2 Metoda OdrediRjesavatelja
Ver. 1.0
Parametar klasifikacijskaOznaka Rjesavatelj Username
Tip
Identifikator String kojem se rjeavatelj String String
Opis
Identifikator slubenika koji je zaduen za rjeavanje predmeta Identifikator slubenika koji odreuje rjeavatelja
predmeta odreuje
Obveznost DA DA DA
Metoda ZatvoriPredmet
Tablica 1.3 Metoda ZatvoriPredmet
Parametar
Tip
Opis
klasifikacijskaOznaka String Username String
Identifikator koji se zatvara
Metoda StornirajPredmet
Identifikator slubenika koji zatvara predmet
predmeta
Obveznost DA DA
Tablica 1.4 Metoda StornirajPredmet
Parametar
Tip
Opis
Identifikator predmeta koji se stornira Identifikator slubenika koji stornira predmet
Obveznost DA DA
31. svibnja 2010.
26/32
SPEUP Privitak 3: Primjeri modela poslovnih procesa uredskog poslovanja Metoda PostaviSubjektaNaPredmetu
Tablica 1.5 Metoda PostaviSubjektaNaPredmetu
Ver. 1.0
Parametar
Tip
Opis
klasifikacijskaOznaka String
Username subjekt uloga String Int Int
Identifikator predmeta kojem se postavlja subjekt (stranka)

Identifikator slubenika koji postavlja subjekta na predmetu Identifikator stranke Identifikator predmetu uloge subjekta
Obveznost
DA
DA DA DA DA
isGlavni
Boolean
Metoda ObrisiSubjektaNaPredmetu
True = glavni subjekt na predmetu, False = ostali subjekti
Tablica 1.6 Metoda ObrisiSubjektaNaPredmetu
Parametar
Tip
Opis
klasifikacijskaOznaka String Username subjekt String Int
Obveznost DA DA DA
Identifikator slubenika koji brie subjekta na predmetu Identifikator stranke
31. svibnja 2010.
27/32
SPEUP Privitak 3: Primjeri modela poslovnih procesa uredskog poslovanja Metoda DohvatiPodatkePredmeta
Tablica 1.7 Metoda DohvatiPodatkePredmeta
Ver. 1.0
Parametar
Tip
Opis

Identifikator slubenika koji dohvaa podatke
Obveznost DA DA
1.4.2 Web Service PISMENO

Metoda KreirajPismeno
Tablica 1.8 Metoda KreirajPismeno
Parametar klasifikacijskaOznaka Username subjekt
Tip String String Int String String Date
Opis
Identifikator predmeta unutar kojeg se kreira pismeno Identifikator slubenika koji kreira pismeno Identifikator stranke ifra vrste pismena
Obveznost DA DA DA DA DA DA NE
vrstaPismena
nazivPismena
datumNastanka
Naziv pismena (stvaratelj/stranka, vrsta, kratak sadraj) Datum nastanka pismena Datum registriranja pismena u sustav. Ako se ne preda, uzima se trenutno vrijeme na serveru
datumRegistriranja
Date
31. svibnja 2010.
28/32
SPEUP Privitak 3: Primjeri modela poslovnih procesa uredskog poslovanja Metoda PostaviSubjektaNaPismenu
Tablica 1.9 Metoda PostaviSubjektaNaPismenu
Ver. 1.0
Parametar Jop
Tip Int Int Int
Opis
Username Subjekt uloga
String
Identifikator pismena Identifikator stranke
Obveznost DA DA DA DA NE
Identifikator slubenika subjekta na pismenu
koji
kreira
isGlavni
Boolean
Identifikator uloge subjekta u predmetu
Metoda DohvatiPodatkePismena
True = glavni subjekt na pismenu, False = ostali subjekti
Tablica 1.10 Metoda DohvatiPodatkePismena
Parametar Jop
Tip Int
Opis
Username
String
Identifikator pismena
Obveznost DA DA
Metoda KreirajDokumentZaPismeno
Identifikator slubenika koji dohvaa podatke
Tablica 1.11 Metoda KreirajDokumentZaPismeno
Parametar Jop
Tip Int
Opis
Username Extension Attachement 31. svibnja 2010.
String String Base64 Binary
Identifikator pismena Identifikator dokument Ekstenzija datoteke
Obveznost koji kreira DA DA DA DA 29/32
slubenika
Base 64 enkodiran binary byte stream (datoteka)
SPEUP Privitak 3: Primjeri modela poslovnih procesa uredskog poslovanja Metoda ObrisiDokumentZaPismeno
Tablica 1.12 Metoda ObrisiDokumentZaPismeno
Ver. 1.0
Parametar Jop
Tip Int
Opis
Username
String
Identifikator pismena Identifikator dokument
Obveznost DA DA
slubenika
koji
brie
31. svibnja 2010.
30/32
Slika 1.1 Sluaj koritenja: Predmet .............................................................................................................. 3 2 POPIS SLIKA Slika 1.2 Sluaj koritenja: Pismeno .............................................................................................................. 8 Slika 1.3 Sluaj koritenja: Dostava ............................................................................................................. 12 Slika 1.4 Sluaj koritenja: Otprema ........................................................................................................... 15 Slika 1.5 Dijagram aktivnosti: Zaprimanje podneska i otvaranje predmeta ............................... 17 Slika 1.6 Dijagram aktivnosti: Dostava predmeta/pismena u rad .................................................. 18 Slika 1.7 Dijagram aktivnosti: Rjeavanje i potpisivanje .................................................................... 19 Slika 1.8 Dijagram aktivnosti: Otpremanje izlaznih akata.................................................................. 20 Slika 1.9 Dijagram aktivnosti: Arhiviranje predmeta ........................................................................... 21 Slika 1.10 Sluaj koritenja: Elektroniko otpremanje i zaprimanje pismena ........................... 22 Slika 1.11 Dijagram aktivnosti: Elektroniko otpremanje i zaprimanje pismena ..................... 23 Slika 1.12 Dijagram stanja: Elektroniko otpremanje i zaprimanje pismena ............................. 24
Ver. 1.0
31. svibnja 2010.
31/32
Tablica 1.1 Metoda KreirajPredmet ............................................................................................................. 25 3 POPIS TABLICA Tablica 1.2 Metoda OdrediRjesavatelja ...................................................................................................... 26 Tablica 1.3 Metoda ZatvoriPredmet............................................................................................................. 26 Tablica 1.4 Metoda StornirajPredmet ......................................................................................................... 26 Tablica 1.5 Metoda PostaviSubjektaNaPredmetu ................................................................................... 27 Tablica 1.6 Metoda ObrisiSubjektaNaPredmetu...................................................................................... 27 Tablica 1.7 Metoda DohvatiPodatkePredmeta......................................................................................... 28 Tablica 1.8 Metoda KreirajPismeno ............................................................................................................. 28 Tablica 1.9 Metoda PostaviSubjektaNaPismenu...................................................................................... 29 Tablica 1.10 Metoda DohvatiPodatkePismena......................................................................................... 29 Tablica 1.11 Metoda KreirajDokumentZaPismeno ................................................................................. 29 Tablica 1.12 Metoda ObrisiDokumentZaPismeno ................................................................................... 30
Ver. 1.0
31. svibnja 2010.
32/32
REPUBLIKA HRVATSKA

Privitak 4
Podatkovni model za razmjenu elektronikih isprava (XML shema)

Ver. 1.0
Prikazana XML shema takoer je pripremljena i kao datoteka u *.XSD formatu pod nazivom xmlspeup-schema.xsd. Ta datoteka se nalazi u privitku (engl. Attachment) unutar PDF datoteke osnovnog dokumenta, kao i na internetskim stranicama www.e-hrvatska.hr Sredinjeg dravnog ureda za e-Hrvatsku, za potrebe on-line referenciranja na njezin sadraj. 1 Podatkovni model za razmjenu elektronikih isprava (XML shema)
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.e-hrvatska.hr/xmlns/speup" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" targetNamespace="http://www.e-hrvatska.hr/xmlns/speup" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0" xml:lang="hr">  <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/> <xs:element name="Posiljka"> <xs:annotation> <xs:documentation>Krovni element poruke za razmjenu sadraja</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Omotnica"> <xs:annotation> <xs:documentation>Zaglavlje poiljke</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Identifikacija"> <xs:annotation> <xs:documentation>Identifikacija poiljke</xs:documentation> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="IDPorukeTip"> <xs:sequence> <xs:element name="Ponavljanje" type="xs:positiveInteger" minOccurs="0"> <xs:annotation> <xs:documentation>Oznaka da se ponavlja neuspjeno poslana poiljka. Vrijednost sadri broj prethodnih neuspjenih pokuaja. </xs:documentation> </xs:annotation> </xs:element>
SPEUP Privitak 4: Podatkovni model za razmjenu elektronikih isprava - XML shema
Ver. 1.0
31. svibnja 2010.
2/31
31. svibnja 2010.
</xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="Primatelj" type="StrankaTip" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Primatelj(i) poiljke</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Posiljatelj" type="StrankaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Poiljatelj poiljke</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Tip" type="SifraTip" minOccurs="0"> <xs:annotation> <xs:documentation>Tip poiljke (dostavnica, otpremnica)</xs:documentation> </xs:annotation> </xs:element> <xs:element name="SigurnaDostava" minOccurs="0"> <xs:annotation> <xs:documentation>Parametri za sigurnu dostavu poiljke i vraanje potvrde/poruke o greci</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="PovratnaObavijest" type="EAdresaTip" minOccurs="0"/> </xs:sequence> <xs:attribute name="traziPotvrdu" type="xs:boolean"> <xs:annotation> <xs:documentation>Ako je vrijednost "true", poiljatelj e ponavljati slanje poruke dok ne dobije potvrdu ili se ne prekorae vrijednosti definirane u @ttl i @ponavljanje </xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="ttl" type="xs:dateTime"> <xs:annotation> <xs:documentation>Krajnji rok dostave poruke</xs:documentation> </xs:annotation> </xs:attribute>
Ver. 1.0
3/31
31. svibnja 2010.
<xs:attribute name="ponavljanje" type="xs:integer"> <xs:annotation> <xs:documentation>Broj ponavljanja slanja poruke u sluaju neuspjeha</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="interval" type="xs:duration"> <xs:annotation> <xs:documentation>Najmanji razmak izmeu dva uzastopna ponavljanja</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="PotvrdaPrijema" type="SigurnaDostavaTip" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Potvrda dostave poiljke i vraanje potvrde/poruke o greci</xs:documentation> </xs:annotation> </xs:element> <xs:element name="PoslovniProces" type="PoslovniProcesTip" minOccurs="0"> <xs:annotation> <xs:documentation>Parametri vezani uz poslovni proces unutar kojega se obavlja razmjena sadraja</xs:documentation> </xs:annotation> </xs:element> <xs:group ref="EpotpisGrupa"> <xs:annotation> <xs:documentation>Digitalni potpis i timestamp poiljke</xs:documentation> </xs:annotation> </xs:group> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="DostavniList" minOccurs="0"> <xs:annotation> <xs:documentation>Lista stavki sadraja poiljke (Otpremna/dosavna knjiga)</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="SadrzajRef"> <xs:annotation> <xs:documentation>Referenca sadraja poiljke</xs:documentation> </xs:annotation>
Ver. 1.0
4/31
31. svibnja 2010.
<xs:complexType> <xs:complexContent> <xs:extension base="DokumentRefTip"> <xs:attribute name="tipSadrzaja"> <xs:annotation> <xs:documentation>Tip referenciranog sadraja (Dokument, Pismeno, Predmet, Ekstenzija) </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="brStavki"> <xs:annotation> <xs:documentation>Broj stavki sadraja poiljke</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="Sadrzaj" minOccurs="0"> <xs:annotation> <xs:documentation>Ovojnica za sadraj poiljke</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:choice maxOccurs="unbounded"> <xs:element ref="Dokument"/> <xs:element ref="Pismeno"/> <xs:element ref="Predmet"/> <xs:element name="Ekstenzija"> <xs:complexType> <xs:sequence> <xs:any namespace="##any" processContents="lax" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Bilo koji dokument</xs:documentation> </xs:annotation> </xs:any> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/>
Ver. 1.0
5/31
31. svibnja 2010.
</xs:complexType> </xs:element> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Dostavnica"> <xs:annotation> <xs:documentation>Krovni element poruke za razmjenu sadraja</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Identifikacija"> <xs:annotation> <xs:documentation>Identifikacija poruke</xs:documentation> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="IDPorukeTip"> <xs:sequence> <xs:element name="Ponavljanje" type="xs:positiveInteger" minOccurs="0"> <xs:annotation> <xs:documentation>Oznaka da se ponavlja neuspjeno poslana poruka. Vrijednost sadri broj prethodnih neuspjenih pokuaja. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="Primatelj" type="StrankaTip" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Primatelj(i) povratnice</xs:documentation> </xs:annotation> </xs:element>
Ver. 1.0
6/31
31. svibnja 2010.
<xs:element name="Posiljatelj" type="StrankaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Poiljatelj povratnice</xs:documentation> </xs:annotation> </xs:element> <xs:element name="PotvrdaPrijema" type="SigurnaDostavaTip" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Parametri za vraanje potvrde/poruke o greci</xs:documentation> </xs:annotation> </xs:element> <xs:group ref="EpotpisGrupa"> <xs:annotation> <xs:documentation>Digitalni potpis i vremenska oznaka poruke</xs:documentation> </xs:annotation> </xs:group> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Predmet"> <xs:complexType> <xs:sequence> <xs:group ref="IDPredmetaGrupa"/> <xs:group ref="MetapodaciPredmetaGrupa"/> <xs:group ref="ProcesniMetapodaciGrupa"/> <xs:element name="DokumentRef" type="DokumentRefTip" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Referenca na eksterne dokumente iz predmeta</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Pismeno"> <xs:complexType> <xs:complexContent> <xs:extension base="PismenoTip"> <xs:sequence> <xs:element name="Prilog" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Prilog pismenu</xs:documentation>
Ver. 1.0
7/31
31. svibnja 2010.
</xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="PrilogTip"> <xs:attribute name="uloga"> <xs:annotation> <xs:documentation>Uloga priloga</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="Dokument"> <xs:complexType> <xs:sequence> <xs:group ref="ZaglavljeGrupa" minOccurs="0"/> <xs:group ref="PravaGrupa"/> <xs:group ref="AdministrativniMetapodaciGrupa"/> <xs:group ref="OpisSadrzajaGrupa"/> <xs:any namespace="##other"/> <xs:element name="Sadrzaj" type="SadrzajTip"/> <xs:group ref="EpotpisGrupa"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="AdresaTip"> <xs:sequence> <xs:choice> <xs:element name="LinijaAdrese" maxOccurs="unbounded"/> <xs:sequence> <xs:element name="Ulica"> <xs:annotation> <xs:documentation>Naziv ulice u tijelu elementa</xs:documentation> </xs:annotation>
Ver. 1.0
8/31
31. svibnja 2010.
<xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="rpjMaticniBroj"> <xs:annotation> <xs:documentation>Matini broj ulice u Registru prostornih jedinica</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="KucniBroj"> <xs:annotation> <xs:documentation>Kuni broj - puni sadraj u tijelu elementa</xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="kucniBroj" type="xs:integer"> <xs:annotation> <xs:documentation>Kuni broj</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="dodatakAlfa" type="xs:string"> <xs:annotation> <xs:documentation>Slovani dodatak kunom broju</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="dodatakNumericki" type="xs:int"> <xs:annotation> <xs:documentation>Brojani dodatak kunom broju</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> </xs:choice>
Ver. 1.0
9/31
31. svibnja 2010.
<xs:element name="Naselje" minOccurs="0"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="rpjMaticniBroj"> <xs:annotation> <xs:documentation>Maticni broj u registru prostornih jedinica</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="Grad"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="postanskiBroj"/> <xs:attribute name="rpjMaticniBroj"> <xs:annotation> <xs:documentation>Maticni broj u Registru prostornih jedinica</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="Drzava" type="SifraTip" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="DokumentRefTip"> <xs:sequence> <xs:group ref="ZaglavljeGrupa" minOccurs="0"/> </xs:sequence> <xs:attribute name="redniBroj"> <xs:annotation> <xs:documentation>Redni broj reference</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="idRef">
Ver. 1.0
10/31
31. svibnja 2010.
<xs:annotation> <xs:documentation>Referenca na id sadraja</xs:documentation> </xs:annotation> </xs:attribute> <xs:attributeGroup ref="AtributiSadrzajaGrupa"/> </xs:complexType> <xs:complexType name="EAdresaTip"> <xs:sequence> <xs:element name="URL"> <xs:annotation> <xs:documentation>Adresa</xs:documentation> </xs:annotation> </xs:element> <xs:element name="TipPoruke" type="SifraTip" minOccurs="0"> <xs:annotation> <xs:documentation>Format poruke</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="IdentifikatorTip"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="domena" type="xs:anyURI"> <xs:annotation> <xs:documentation>Opcionalni URI koji oznaava domenu (authority) koji upravlja vrijednostima identifikatora</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="uloga"> <xs:annotation> <xs:documentation>Oznaka uloge identifikatora u poslovnom procesu. Poeljno je za vrijednost atributa koristiti URI </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="IDPorukeTip"> <xs:sequence> <xs:element name="ID" type="xs:string">
Ver. 1.0
11/31
31. svibnja 2010.
<xs:annotation> <xs:documentation>Jedinstveni identifikator poiljke</xs:documentation> </xs:annotation> </xs:element> <xs:element name="VrijemeSlanja" type="xs:dateTime" minOccurs="0"> <xs:annotation> <xs:documentation>Vrijeme slanja poiljke ili potvrde prijema poiljke</xs:documentation> </xs:annotation> </xs:element> <xs:element name="RedniBroj" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>Oznaka rednog broja poiljke u nizu ukoliko je redosljed poiljki bitan</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="IzvornaPorukaTip"> <xs:complexContent> <xs:extension base="IDPorukeTip"> <xs:sequence> <xs:element ref="dsig:Reference" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="KlasaTip"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="upisnaKnjiga"> <xs:annotation> <xs:documentation>Upisnik predmeta - prema uredbi o uredskom poslovanju (UP/I, UP/II, neupravni)</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="grupe"> <xs:annotation> <xs:documentation>Glavna grupa, grupa i podgrupa - klasifikacija prema sadrzaju prema uredbi o uredskom poslovanju </xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="djelatnost">
Ver. 1.0
12/31
31. svibnja 2010.
<xs:annotation> <xs:documentation>Djelatnost prema uredbi o uredskom poslovanju</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="godina"> <xs:annotation> <xs:documentation>Godina stvaranja predmeta porema uredbi o uredskom poslovanju</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="dosje"> <xs:annotation> <xs:documentation>Klasifikacija prema obliku prema uredbi o uredskom poslovanju</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="predmet"> <xs:annotation> <xs:documentation>Redni broj predmeta porema uredbi o uredskom poslovanju</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="OsobaTip"> <xs:sequence maxOccurs="unbounded"> <xs:choice> <xs:sequence> <xs:element name="Titula" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>Titula osobe</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Prezime" type="xs:string"> <xs:annotation> <xs:documentation>Prezime osobe</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Ime" type="xs:string"> <xs:annotation> <xs:documentation>Ime osobe</xs:documentation> </xs:annotation>
Ver. 1.0
13/31
</xs:element> <xs:element name="Adresa" type="AdresaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Adresa osobe</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> <xs:element name="Id" type="IdentifikatorTip"> <xs:annotation> <xs:documentation>Oznaka osobe u raunalnom sustavu (npr. OIB). Tijelo elementa sadri identifikator, a po potrebi se domena i uloga mogu preciznije opisati predvienim atributima. Ne smiju postojati dvije oznake sa istim vrijednostima domene i uloge </xs:documentation> </xs:annotation> </xs:element> </xs:choice> <xs:element name="Id" type="IdentifikatorTip" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Dodatna oznaka osobe u raunalnom sustavu.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Funkcija" type="xs:string"> <xs:annotation> <xs:documentation>Funkcija koju osoba obavlja ili njen poloaj u administrativnoj hijerarhiji</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="PismenoTip"> <xs:sequence> <xs:group ref="IdentifikacijaGrupa"> <xs:annotation> <xs:documentation>Identifikacija pismena</xs:documentation> </xs:annotation> </xs:group> <xs:group ref="PravaGrupa"> <xs:annotation> <xs:documentation>Prava vezana uz pismeno ili dokument.</xs:documentation> </xs:annotation> </xs:group> <xs:group ref="ProcesniMetapodaciGrupa"/>
Ver. 1.0
31. svibnja 2010.
14/31
<xs:group ref="AdministrativniMetapodaciGrupa"/> <xs:group ref="OpisSadrzajaGrupa"> <xs:annotation> <xs:documentation>Metapodaci za opis sadraja pismena.</xs:documentation> </xs:annotation> </xs:group> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Proirenje elementima iz drugoh nemespace-a</xs:documentation> </xs:annotation> </xs:any> <xs:element name="Sadrzaj" type="SadrzajTip"> <xs:annotation> <xs:documentation>Sadraj pismena</xs:documentation> </xs:annotation> </xs:element> <xs:group ref="EpotpisGrupa" minOccurs="0"> <xs:annotation> <xs:documentation>Digitalni potpis i vremenska oznaka</xs:documentation> </xs:annotation> </xs:group> </xs:sequence> </xs:complexType> <xs:complexType name="PoslovniProcesTip"> <xs:sequence> <xs:element name="Proces" type="SifraTip"> <xs:annotation> <xs:documentation>Oznaka poslovnog procesa unutar kojeg se obavlja razmjena sadraja. Vrijednost elementa sadri atribut @sifra, a u tijelo elementa moe sadravati tekst za prikaz korisnicima. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Akcija" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Oznaka akcije unutar poslovnog procesa koju poruka inicira.</xs:documentation> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="SifraTip"> <xs:attribute name="redniBroj" type="xs:positiveInteger">
Ver. 1.0
31. svibnja 2010.
15/31
31. svibnja 2010.
<xs:annotation> <xs:documentation>Redni broj akcije ako ih ima vie</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="Korak" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation>Oznaka koraka unutar poslovnog procesa na koji se poruka odnosi.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ZavrsnaObavijest" type="EAdresaTip" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Adresa na koju treba poslati poruku nakon okonanja procesiranja sadraja poruke.</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="PrilogTip"> <xs:sequence> <xs:group ref="AdministrativniMetapodaciGrupa"/> <xs:group ref="OpisSadrzajaGrupa"/> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Sadrzaj" type="SadrzajTip"> <xs:annotation> <xs:documentation>Binarni sadraj priloga</xs:documentation> </xs:annotation> </xs:element> <xs:group ref="EpotpisGrupa"> <xs:annotation> <xs:documentation>Elektroniki potpis i vremenska oznaka</xs:documentation> </xs:annotation> </xs:group> </xs:sequence> </xs:complexType> <xs:complexType name="RadnjaTip"> <xs:sequence> <xs:element name="Vrsta" type="SifraTip">
Ver. 1.0
16/31
31. svibnja 2010.
<xs:annotation> <xs:documentation>Vrsta radnje s pismenom (prijem, otprema, arhiviranje)</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Vrijeme" type="VrijemeTip"> <xs:annotation> <xs:documentation>Vrijeme radnje s pismenom (npr. prijema ili otpreme pismena)</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Kanal" type="SifraTip" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Komunikacijski kanal preko kojeg je obavljena razmjena</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Stranka" type="StrankaTip" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Stranka s kojom se razmjenjuje pismeno (poiljatelj ili primatelj)</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Izvrsitelj" type="OsobaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Osoba koja je izvrsila radnju</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Status" type="SifraTip" minOccurs="0"> <xs:annotation> <xs:documentation>Status poruke prije iizvrenja radnje</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Verzija" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation>Verzija zapisa o pismenu </xs:documentation> </xs:annotation> </xs:element> <xs:element name="IDPoruke" type="IdentifikatorTip" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="SadrzajTip"> <xs:choice> <xs:element name="BinarniSadrzaj">
Ver. 1.0
17/31
31. svibnja 2010.
<xs:annotation> <xs:documentation>Enkodirani binarni podaci</xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:base64Binary"> <xs:attribute name="kodiranje" type="xs:string"> <xs:annotation> <xs:documentation>Nain enkodiranja sadraja. Za binarne dokumente standardno kodiranje je Base64 </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="XmlSadrzaj"> <xs:annotation> <xs:documentation>Podaci u XML obliku</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:any namespace="##other"> <xs:annotation> <xs:documentation>XML sadraj u drugom namespace-u</xs:documentation> </xs:annotation> </xs:any> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="DokumentRef" type="EAdresaTip"> <xs:annotation> <xs:documentation>Referenca na eksterni dokument</xs:documentation> </xs:annotation> </xs:element> </xs:choice> <xs:attributeGroup ref="AtributiSadrzajaGrupa"/> <xs:attribute name="id" type="xs:ID"> <xs:annotation> <xs:documentation>Lokalni identifikator sadraja</xs:documentation>
Ver. 1.0
18/31
</xs:annotation> </xs:attribute> </xs:complexType> <xs:complexType name="SifraTip"> <xs:annotation> <xs:documentation>Metapodatak oznaen kodom u atributu "sifra". Element moe sadravati opcionalni tekst koji se moe koristiti za prikaz korisnicima vrijednosti oznaene ifrom </xs:documentation> </xs:annotation> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="domena" type="xs:anyURI"> <xs:annotation> <xs:documentation>Opcionalni URI koji oznaava domenu (authority) koji upravlja kodovima</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="sifra" use="required"> <xs:annotation> <xs:documentation>Sadri kod koji oznaava vrijednost elementa.</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="SigurnaDostavaTip"> <xs:sequence minOccurs="0"> <xs:element name="Status" type="SifraTip"> <xs:annotation> <xs:documentation>Status prijema i parsiranja poiljke. Koristi se kod vraanja potvrde prijema poiljke za indikaciju uspjenog ili neuspjenog prijema i parsiranja poiljke </xs:documentation> </xs:annotation> </xs:element> <xs:element name="VrijemePrijema" type="VrijemeTip" minOccurs="0"> <xs:annotation> <xs:documentation>Datum i opcionalno vrijeme prijema ili obrade poiljke iji se prijem potvruje</xs:documentation> </xs:annotation> </xs:element> <xs:element name="PorukaGreske" minOccurs="0" maxOccurs="unbounded"> <xs:annotation>
Ver. 1.0
31. svibnja 2010.
19/31
<xs:documentation>Poruka o greci nastala prilikom prijema ili parsiranja poiljke. Tekstualni sadraj poruke o greci nalazi se u tijelu elementa. </xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="kodGreske" type="xs:integer"> <xs:annotation> <xs:documentation>Kod poruke o greci</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="timestamp" type="xs:dateTime"> <xs:annotation> <xs:documentation>Vremenska oznaka greke</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:choice maxOccurs="unbounded"> <xs:element name="IzvornaPoruka" type="IzvornaPorukaTip"> <xs:annotation> <xs:documentation>ID poiljke za koju se potvruje status. Mogue je istovremeno potvrditi status za vie od jedne poiljke ako se radi o uspjenom prijemu. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="IzvorniDokument" type="DokumentRefTip"> <xs:annotation> <xs:documentation>Referenca na dokument za koji se potvruje prijem</xs:documentation> </xs:annotation> </xs:element> </xs:choice> </xs:sequence> </xs:complexType> <xs:complexType name="StrankaTip"> <xs:sequence> <xs:choice>
Ver. 1.0
31. svibnja 2010.
20/31
<xs:sequence> <xs:element name="Naziv" type="TekstUlogaTip" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Slubeni naziv stranke</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Adresa" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="AdresaTip"> <xs:attribute name="uloga"> <xs:annotation> <xs:documentation>Uloga adrese ako ih ima vise</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> <xs:element name="Id" type="IdentifikatorTip"> <xs:annotation> <xs:documentation>Identifikator stranke (npr OIB). Vrijednost identifikatora sadrana je u tijelu elementa. U sluaju vie identifikatora oni moraju imati razliite ulogu ili domenu. </xs:documentation> </xs:annotation> </xs:element> </xs:choice> <xs:element name="Id" type="IdentifikatorTip" minOccurs="0" maxOccurs="unbounded"/> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="Osoba"> <xs:annotation> <xs:documentation>Oznaka osobe unutar Stranke</xs:documentation> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="OsobaTip"> <xs:attribute name="uloga"> <xs:annotation> <xs:documentation>Uloga osobe unutar Stranke</xs:documentation>
Ver. 1.0
31. svibnja 2010.
21/31
31. svibnja 2010.
</xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="OrganizacijskaJedinica" type="SifraTip"> <xs:annotation> <xs:documentation>Organizacijska jedinica unutar Stranke </xs:documentation> </xs:annotation> </xs:element> </xs:choice> </xs:sequence> </xs:complexType> <xs:complexType name="TekstUlogaTip"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="jezik"> <xs:annotation> <xs:documentation>Jezik metapodatka</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="uloga"> <xs:annotation> <xs:documentation>Uloga metapodatka - npr web ili mobile</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="UrBrTip"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="stvaratelj"> <xs:annotation> <xs:documentation>Oznaka stvaratelja pismena prema uredbi o uredskom poslovanju</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="godina"> <xs:annotation>
Ver. 1.0
22/31
31. svibnja 2010.
<xs:documentation>Godina nastanka pismena prema uredbi o uredskom poslovanju</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="redniBroj"> <xs:annotation> <xs:documentation>redni broj pismena unutar predmeta</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:simpleType name="VrijemeTip"> <xs:annotation> <xs:documentation>The type of a date (required) and a time (optional).</xs:documentation> </xs:annotation> <xs:union memberTypes="xs:date xs:dateTime"/> </xs:simpleType> <xs:group name="AdministrativniMetapodaciGrupa"> <xs:sequence> <xs:element name="Stvaratelj" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="StrankaTip"> <xs:attribute name="uloga"> <xs:annotation> <xs:documentation>Uloga stvaratelja u nastanku pismena</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="VrijemeNastanka" type="VrijemeTip" minOccurs="0"> <xs:annotation> <xs:documentation>Vrijeme nastanka dokumenta ili pismena. Najraniji trenutak postojanja sadraja u raunalnom sustavu. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Vrsta" type="SifraTip" minOccurs="0"> <xs:annotation>
Ver. 1.0
23/31
31. svibnja 2010.
<xs:documentation>Vrsta sadraja dokumenta ili pismena (rjeenje, molba, zahtjev...).</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Model" type="SifraTip" minOccurs="0"> <xs:annotation> <xs:documentation>Predloak / model po kojem je napravljen sadraj u sluaju tipskih dokumenata ili pismena</xs:documentation> </xs:annotation> </xs:element> <xs:element name="DokumentacijskoMjesto" type="StrankaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Mjesto fizike pohrane dokumenta</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:group> <xs:attributeGroup name="AtributiSadrzajaGrupa"> <xs:annotation> <xs:documentation>Atributi za opis sadrzaja</xs:documentation> </xs:annotation> <xs:attribute name="format" type="xs:string"> <xs:annotation> <xs:documentation>Oznaka formata sadraja</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="imeDatoteke" type="xs:string"> <xs:annotation> <xs:documentation>Izvorno ime datoteke</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="ekstenzija" type="xs:string"> <xs:annotation> <xs:documentation>Izvorna ekstenzija datoteke</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="aplikacija" type="xs:string"> <xs:annotation> <xs:documentation>Oznaka aplikacije u kojoj je kreiran sadraj</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="contentType" type="xs:string">
Ver. 1.0
24/31
31. svibnja 2010.
<xs:annotation> <xs:documentation>ContentType sadraja</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="contentLength" type="xs:integer"> <xs:annotation> <xs:documentation>Duina sadraja u bajtovima prije enkodiranja</xs:documentation> </xs:annotation> </xs:attribute> </xs:attributeGroup> <xs:group name="EpotpisGrupa"> <xs:sequence> <xs:element ref="dsig:Signature" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="timestamp" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:any namespace="##any" processContents="lax" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:sequence> </xs:group> <xs:group name="ExtensionGrupa"> <xs:sequence> <xs:any namespace="##other"/> </xs:sequence> </xs:group> <xs:group name="IdentifikacijaGrupa"> <xs:sequence> <xs:group ref="ZaglavljeGrupa"/> <xs:element name="Verzija" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation>Verzija pismena </xs:documentation> </xs:annotation> </xs:element> <xs:element name="PREDMET" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Oznaka predmeta kojima pismeno pripada</xs:documentation> </xs:annotation>
Ver. 1.0
25/31
31. svibnja 2010.
<xs:complexType> <xs:group ref="IDPredmetaGrupa"/> <xs:attribute name="redniBroj"> <xs:annotation> <xs:documentation>Redni broj dokumenta u predmetu</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="godina"> <xs:annotation> <xs:documentation>Godina predmeta</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="Veza" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Veza na drugo pismeno</xs:documentation> </xs:annotation> <xs:complexType> <xs:group ref="ZaglavljeGrupa"/> <xs:attribute name="uloga"> <xs:annotation> <xs:documentation>Uloga vezanog pismena</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> </xs:sequence> </xs:group> <xs:group name="IDPredmetaGrupa"> <xs:sequence> <xs:choice> <xs:element name="KLASA" type="KlasaTip"> <xs:annotation> <xs:documentation>Klasa predmeta</xs:documentation> </xs:annotation> </xs:element> <xs:element name="IdPredmeta" type="IdentifikatorTip"> <xs:annotation> <xs:documentation>Jedinstvena oznaka predmeta </xs:documentation>
Ver. 1.0
26/31
31. svibnja 2010.
</xs:annotation> </xs:element> </xs:choice> <xs:element name="IdPredmeta" type="IdentifikatorTip" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Dodatna oznaka predmeta (npr. redni broj predmeta unutar godine) </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:group> <xs:group name="MetapodaciPredmetaGrupa"> <xs:sequence> <xs:element name="Naziv" type="TekstUlogaTip"> <xs:annotation> <xs:documentation>Naziv predmeta</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Vrsta" type="SifraTip" minOccurs="0"> <xs:annotation> <xs:documentation>Vrsta predmeta </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DokumentacijskoMjesto" type="StrankaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Mjesto fizike pohrane predmeta </xs:documentation> </xs:annotation> </xs:element> <xs:element name="NadleznaJedinica" type="StrankaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Jedinica nadlena za rjeavanje predmeta</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Subjekt" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Subjekt povezan s predmetom</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:group> <xs:group name="OpisSadrzajaGrupa">
Ver. 1.0
27/31
<xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="Naziv" type="TekstUlogaTip"> <xs:annotation> <xs:documentation>Naslov pismena</xs:documentation> </xs:annotation> </xs:element> <xs:element name="KljucnaRijec"> <xs:annotation> <xs:documentation>Kljuna rije koja oznaava sadraj pismena</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Kategorija" type="SifraTip"> <xs:annotation> <xs:documentation>Kategorija koja oznaava sadraj pismena. Vrijednost kategorije dana je u atrivutu @sifra, a sadraj elementa moe se koristiti za prikaz kategorije korisnicima </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Subjekt" type="SifraTip"> <xs:annotation> <xs:documentation>Osoba, organizacija ili lokacija relevantna za sadraj</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Sazetak" type="TekstUlogaTip"> <xs:annotation> <xs:documentation>Kratki saetak pismena</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Jezik" type="SifraTip"> <xs:annotation> <xs:documentation>Jezik koriten u sadraju pismena.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Napomena" type="TekstUlogaTip"> <xs:annotation> <xs:documentation>Napimena o sadraju pismena.</xs:documentation> </xs:annotation> </xs:element> </xs:choice>
Ver. 1.0
31. svibnja 2010.
28/31
31. svibnja 2010.
</xs:sequence> </xs:group> <xs:group name="PravaGrupa"> <xs:sequence> <xs:element name="Povjerljivo" type="SifraTip" minOccurs="0"> <xs:annotation> <xs:documentation>Stupanj tajnosti pismna</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:group> <xs:group name="ProcesniMetapodaciGrupa"> <xs:sequence> <xs:element name="Tip" type="SifraTip" minOccurs="0"> <xs:annotation> <xs:documentation>Podnesak (ulazno pismeno) ili Akt (izlazno pismeno) </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Status" type="SifraTip" minOccurs="0"> <xs:annotation> <xs:documentation>Trenutni status pismena ili predmeta</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Vrijednost" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>Vrijednosti priloene pismenu prema uredbi o uredskom poslovanju</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Rjesavatelj" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Osoba zaduena za sljedeu radnju s pismenom ili predmetom</xs:documentation> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="OsobaTip"> <xs:attribute name="uloga"> <xs:annotation> <xs:documentation>Uloga rjeavatelja u poslovnom procesu</xs:documentation> </xs:annotation> </xs:attribute>
Ver. 1.0
29/31
31. svibnja 2010.
</xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="ZadnjiIzmjenio" type="OsobaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Osoba koja je zadnja izmijenila pismeno ili zapis</xs:documentation> </xs:annotation> </xs:element> <xs:element name="VrijemeZadnjeIzmjene" type="VrijemeTip" minOccurs="0"> <xs:annotation> <xs:documentation>Vrijeme zadnje promjene sadraja pismena ili zapisa </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Odobrio" type="OsobaTip" minOccurs="0"> <xs:annotation> <xs:documentation>Osoba koja je odobrila sadraj pismena</xs:documentation> </xs:annotation> </xs:element> <xs:element name="VrijemeOdobrenja" type="VrijemeTip" minOccurs="0"> <xs:annotation> <xs:documentation>Vrijeme odobrenja sadraja pismena od nadlene osobe</xs:documentation> </xs:annotation> </xs:element> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="Radnja"> <xs:complexType> <xs:complexContent> <xs:extension base="RadnjaTip"> <xs:attribute name="redniBroj" type="xs:integer"> <xs:annotation> <xs:documentation>Redni broj radnje</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:choice> </xs:sequence>
Ver. 1.0
30/31
</xs:group> <xs:group name="ZaglavljeGrupa"> <xs:sequence> <xs:choice> <xs:sequence> <xs:element name="KLASA" type="KlasaTip"> <xs:annotation> <xs:documentation>Klasifikacijska oznaka pismena</xs:documentation> </xs:annotation> </xs:element> <xs:element name="URBROJ" type="UrBrTip"> <xs:annotation> <xs:documentation>Urudbeni broj pismena</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> <xs:element name="Id" type="IdentifikatorTip"> <xs:annotation> <xs:documentation>Oznaka pismena u raunalnom sustavu (poslovni broj). Tijelo elementa sadri identifikator, a po potrebi se domena i uloga mogu preciznije opisati predvienim atributima. Ne smiju postojati dvije oznake sa istim vrijednostima domene i uloge </xs:documentation> </xs:annotation> </xs:element> </xs:choice> <xs:element name="Id" type="IdentifikatorTip" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Dodatna oznaka dokumenta u raunalnom sustavu </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:group> </xs:schema>
Ver. 1.0
31. svibnja 2010.
31/31
REPUBLIKA HRVATSKA

Privitak 5
Funkcionalni zahtjevi kontrolna lista

Ver. 1.0
Funkcionalni zahtjevi opisuju to sustav elektronikog uredskog poslovanja treba raditi i definirani su za svaki od procesa koji je opisan i prikazan u poglavlju 5. Procesi uredskog poslovanja, odnosno u poglavlju 7. Funkcionalni zahtjevi u osnovnom dokumentu Standardni projekt elektronikog uredskog poslovanja (SPEUP). Funkcionalni zahtjevi kontrolna lista
SPEUP Privitak 5: Funkcionalni zahtjevi kontrolna lista
Ver. 1.0
U ovom su privitku ti funkcionalni zahtjevi numerirani i grupirani prema navedenim procesima, te su prikazani u tablinom obliku kao kontrolna lista koju je mogue koristiti kao podlogu za provjeru i ocjenu usklaenosti postojeeg rjeenja za elektroniko uredsko poslovanje ili za pripremu tehnike dokumentacije za nabavu novog rjeenja. Svakom od funkcionalnih zahtjeva u tablici, pridruena je oznaka obvezatnosti u sustavu koja je prikazana u koloni 'OBVEZAN (DA/NE)'. Ukoliko je funkcionalni zahtjev oznaen sa oznakom 'DA', to znai da sustav elektronikog uredskog poslovanja MORA osigurati navedenu funkcionalnost. U sluaju kada je oznaka 'NE' sustav MOE, ali NE MORA podravati navedenu funkcionalnost. Meutim pojedino javnopravnotijelo, kao naruitelj, moe ju zahtijevati od isporuitelja sustava ukoliko procjeni da je ta funkcionalnost nuna za rjeavanje njegovih poslovnih potreba u okviru sustava elektronikog uredskog poslovanja. Posljednja kolona u tablici 'ZADOVOLJAVA (DA/NE)' predviena je za ocjenjivanje i vrednovanje karakteristika nekog konkretnog sustava. REDNI BROJ 1. 1.1 1.2 1.3 1.4 1.5 1.6 NAZIV FUNKCIONALNOG ZAHTJEVA Planiranje dosjea i brojanih oznaka stvaratelja i primatelja akata Dodavanje nove pisarnice Mogunost koritenja samo propisanih glavnih grupa, grupa, podgrupa i djelatnosti; potreban jedinstveni ifrarnik Priprema klasifikacijskih oznaka za sljedeu godinu Otvaranje novih dosjea tijekom godine Pretraivanje klasifikacijskih oznaka; mogunost pretraivanja po svim godinama OBVEZAN (DA/NE) NE ZADOVOLJAVA (DA/NE)
DA DA DA DA DA
2/10
Deaktiviranje/ukidanje klasifikacijske oznake
31. svibnja 2010.
REDNI BROJ 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 2. 2.1 2.2 2.3 2.4 2.5
Mogunost koritenja samo propisanih stvaratelja akata na razini drave; potreban jedinstveni ifrarnik Dodavanje novih unutarnjih ustrojstvenih jedinica tijekom godine
NAZIV FUNKCIONALNOG ZAHTJEVA
OBVEZAN (DA/NE) DA DA DA DA DA DA DA DA DA DA DA DA DA DA
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Priprema unutarnjih ustrojstvenih jedinica za sljedeu godinu Deaktiviranje/ukidanje ustrojstvenih jedinica Pretraivanje ustrojstvenih jedinica
Promjena brojane oznake i naziva unutarnjih ustrojstvenih jedinica Dodavanje brojanih oznaka pojedinanih izvritelja Ukidanje brojane oznake pojedinanog izvritelja Pretraivanje pojedinanih izvritelja Preuzimanje poiljke Primitak, otvaranje i pregled poiljki Slanje potvrde prijema poiljke poiljatelju; automatski s posluitelja
Provjera tehnike ispravnosti poiljke i formata sadraja poiljke Slanje obavijesti u sluaju da se poiljka ne moe proitati iz tehnikih razloga ili poiljka nije u jednom od standardnih formata koji je izabran za razmjenu elektronikih isprava Zapisivanje tonog vremena zaprimanja poiljke na posluitelju (timestamp)
31. svibnja 2010.
3/10
REDNI BROJ 2.6 2.7 2.8 2.9 2.10 2.11 3. 3.1 3.2 3.3 3.4 3.5 3.6 3.7
Prikazivanje poiljke na popisu novozaprimljenih poiljki
OBVEZAN (DA/NE) DA DA NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Zapisivanje komunikacijskog kanala kojim je poiljka dostavljena Upisivanje primljene pote
Mogunost automatskog upisivanja jednog ili vie pismena iz poiljke; samo za strukturirane i aplikativno podrane vrste posla Evidentiranje slubene biljeke o neplaenoj upravnoj pristojbi Otvaranje predmeta; upisivanje novog predmeta u neki od postojeih dosjea Zaprimanje pismena
DA DA DA DA DA DA DA DA DA DA
Pretraivanje poiljki po razliitim kriterijima
Izbor unutarnje ustrojstvene jedinice kojoj se predmet upuuje na rjeavanje Ispisivanje omota spisa (kouljica predmeta) Traenje i prikaz pojedinanog predmeta; utvrivanje gdje se predmet nalazi
Vaenje predmeta iz rokovnika; evidentira se promjena na predmetu
Zahtjev za izdavanje predmeta iz pismohrane, ako je predmet u pismohrani
Upisivanje pismena, urudbenog broja i ostalih podataka koje trai evidencija u koju se upisuje; povezano s predmetom kojem se pridruuje pismeno
31. svibnja 2010.
4/10
REDNI BROJ 3.8 3.9
Pridruivanje pristiglih e-dokumenata uz pismeno; upisivanje osnovnih podataka o edokumentu, dohvaanje e-dokumenta (folder ili pristigla pota) i njegovo spremanje u sustav Priprema potvrde o zaprimanju podneska Skeniranje pismena i pridruivanje skeniranog priloga pismenu Formiranje popisa pismena koji se upuuju u pojedine ustrojstvene jedinice; interna dostavna knjiga Pretraivanje predmeta po razliitim kriterijima Povezivanje predmeta Dostava pismena u rad
OBVEZAN (DA/NE) DA NE NE NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
3.10 3.11 3.12 3.13 4. 4.1 4.2 4.3 4.4 4.5 4.6 4.7
DA DA DA NE NE
Evidentiranje dostave predmeta/pismena iz pisarnice u ustrojstvenu jedinicu
Mogunost upisa potvrde primitka predmeta/pismena iz pisarnice u ustrojstvenu jedinicu Mogunost upisa potvrde primitka predmeta /pismena kod referenta Mogunost upisa potvrde primitka rjeenih predmeta/pismena u pisarnici Pregled i ispis dostavne knjige Pretraivanje dostavne knjige po razliitim kriterijima (datum upisa pismena, Mogunost upisa dostave rjeenih predmeta/pismena iz ustrojstvene jedinice u pisarnicu
DA NE
DA DA
5/10
31. svibnja 2010.
REDNI BROJ 4.8 4.9 5. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12
klasifikacijska oznaka i urudbeni broj, nadlena ustrojstvena jedinica, i sl.)
OBVEZAN (DA/NE) DA NE NE NE NE NE NE NE NE NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Mogunost elektronike dostave u rad pismena koja su zaprimljena elektronikim putem Oznaavanje predmeta i pismena bar kod oznakama radi lake manipulacije
Mogunost izrade forme i sadraja akta prema digitalnom predloku Mogunost upisa upute za otpremu Mogunost automatske popune akta podacima iz pismena i/ili spisa Mogunost elektronikog potpisivanja akta Upravljanje statusima akta Mogunost rjeavanja vie predmeta jednim aktom Evidentiranje kada je akt poslan na potpisivanje Mogunost elektronike dostave od osobe koja je kreirala akt do ovlatenog potpisnika Evidentiranje kada je potpisivanje izvreno Mogunost dostave akta na otpremu Ispis elektroniki potpisanog akta od strane ovlatene osobe (u skladu sa Zakonom o elektronikoj ispravi)
Administrativno-tehnika obrada akata
DA DA
DA
Ovjera primjerka elektroniki potpisanog akta od strane ovlatene osobe
DA
31. svibnja 2010.
6/10
REDNI BROJ 6. 6.1 6.2 6.3 6.4 6.5 6.6 6.7 7. 7.1 7.2 7.3 7.4 7.5
OBVEZAN (DA/NE) NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Mogunost upisa potvrde primitka (kod otpremanja potom upisuje se broj preporuke, podaci o uruenju) Evidentirati datum i vrijeme otpreme s posluitelja poiljatelja kod otpremanja elektronikim komunikacijskim kanalima Evidentirati datum i vrijeme primitka poiljke od strane primatelja (informacijski sustav ili poiljatelj osobno), kod otpremanja elektronikim komunikacijskim kanalima Pregled i ispis popisa pismena za otpremu Ispis koverti s adresama
Otpremanje akata
DA DA DA DA DA NE
Pregled i ispis dostavne knjige (za mjesto, za potu, dostavu elektronikim komunikacijskim kanalima) Pretraivanje popisa pismena prema razliitim kriterijima Rokovnik i razvoenje akata
Mogunost razvoenja predmeta; evidentira se promjena na predmetu i upisuju propisani podaci Formiranje popisa predmeta za dostavu u pismohranu Stavljanje predmeta u rokovnik; evidentira se promjena na predmetu i upisuju propisani podaci Formiranje popisa predmeta kojima istie rok Mogunost vaenja predmeta iz rokovnika;
DA NE
DA DA DA
7/10
31. svibnja 2010.
REDNI BROJ 7.6 8. 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13
evidentiranje promjene na predmetu
OBVEZAN (DA/NE) NE DA DA NE NE NE NE NE DA DA DA DA NE NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Mogunost pridruivanja predmeta koji se vadi iz roka na internu dostavnu knjigu Prilikom izdavanja predmeta iz pismohrane u rad evidentira se promjena na predmetu, predmet se vraa u rad Izrada popisa predmeta koji se iz pismohrane izdaju u rad Potvrda preuzimanja predmeta u rad Evidentiranje izdavanja predmeta iz pismohrane slubeniku na uvid
Stavljanje predmeta u pismohranu i uvanje
Formiranje potvrde o izdavanju predmeta na uvid Formiranje popisa izdanih predmeta (knjiga reversa koja se sastoji od potvrda o izdanim predmetima) Vraanje izdanog predmeta Ispis potvrde o izdavanju predmeta; potvrda se stavlja na mjesto predmeta u pismohrani Izrada popisa dosjea i predmeta koji se izluuju; predmeti kojima je istekao rok uvanja
Izluivanje predmeta; evidentira se promjena na predmetu Zabrana promjene podataka o izluenim predmetima Uvid u provedena izluivanja Predavanje podataka nadlenom arhivu
31. svibnja 2010.
8/10
REDNI BROJ 9. 9.1 9.2 9.3 9.4 9.5 9.6
OBVEZAN (DA/NE) DA DA DA DA DA DA
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Mogunost evidentiranja svake aktivnosti nad predmetima i pismenima. Mogunost generiranja izvjetaja propisanih zakonima ili drugim propisima
Statistika i mjerenje efikasnosti
Mogunost statistikog praenja i prikazivanja broja predmeta i broja pismena na svim razinama poslovnog odluivanja. Mogunost generiranja upravljakih izvjetaja na svim razinama poslovnog odluivanja (analiza uspjenosti po ustrojstvenim jedinicama i tijela u cjelini) Mogunost generiranja operativnih izvjetaja (analiza uspjenosti svakog zaposlenika) Mogunost generiranja izvjetaja sa sljedeim dimenzijama: - broj predmeta sukladno razinama poslovnog odluivanja (po upravama, upravnim tijelima, ustrojstvenim jedinicama, referentima) - vremenskoj dimenziji (dnevni, mjeseni, kvartalni, godinji) - vrsti evidencije (neupravni postupak, UP/I, UP/II) - statusu rijeenosti (rijeeni predmeti po statusima, nerijeeni predmeti po statusima) - klasa odnosno dosje, upravno podruje. Dodatne funkcionalnosti - ovlatenja Ovlatenje za rad na odreenom skupu predmeta Ovlatenje za obavljanje pojedinih funkcija
10.
10.1 10.2 10.3
DA DA DA
9/10
31. svibnja 2010.
Ovlatenje za uvid u odreeni skup predmeta
REDNI BROJ 10.4 10.5
Ovlatenje za rad na sadraju odreenih dokumenata Ovlatenje za uvid u sadraj odreenih dokumenata.
OBVEZAN (DA/NE) DA DA
ZADOVOLJAVA (DA/NE)
Ver. 1.0
31. svibnja 2010.
10/10
REPUBLIKA HRVATSKA

Privitak 6
Nefunkcionalni zahtjevi kontrolna lista

Ver. 1.0
Nefunkcionalni zahtjevi definiraju razinu kvalitete s kojom sustav elektronikog uredskog poslovanja treba izvravati svoje funkcije. Uobiajeno se dijele na zahtjeve ili atribute kvalitete na rad sustava te u zahtjeve u razvoju samog sustava. Uz njih se mogu svrstati jo i ogranienja na karakteristike sustava koja proizlaze iz uvjeta u kojima sustav radi, kako je to opisano u poglavlju 8. Nefunkcionalni zahtjevi u osnovnom dokumentu Standardni projekt elektronikog uredskog poslovanja (SPEUP). Nefunkcionalni zahtjevi kontrolna lista
SPEUP Privitak 6: Nefunkcionalni zahtjevi kontrolna lista
Ver. 1.0
U ovom su privitku svi nefunkcionalni zahtjevi numerirani i grupirani prema navedenim atributima kvalitete, te su prikazani u tablinom obliku kao kontrolna lista koju je mogue koristiti kao podlogu za provjeru i ocjenu usklaenosti postojeeg rjeenja za elektroniko uredsko poslovanje ili za pripremu tehnike dokumentacije za nabavu novog rjeenja.
Svakom od nefunkcionalnih zahtjeva u tablici, pridruena je oznaka obvezatnosti u sustavu koja je prikazana u koloni 'OBVEZAN (DA/NE)'. Ukoliko je zahtjev oznaen sa oznakom 'DA', to znai da sustav elektronikog uredskog poslovanja MORA osigurati navedeni zahtjev. U sluaju kada je oznaka 'NE' sustav MOE, ali NE MORA podravati navedeni zahtjev, meutim pojedino javnopravno tijelo, kao naruitelj, moe ga zahtijevati od isporuitelja sustava ukoliko procjeni da je taj zahtjev nuan za rjeavanje njegovih poslovnih potreba u okviru sustava elektronikog uredskog poslovanja. Posljednja kolona u tablici 'ZADOVOLJAVA (DA/NE)' predviena je za ocjenjivanje i vrednovanje nekog konkretnog sustava. REDNI BROJ 1. 1.1 1.2 1.3 NAZIV NEFUNKCIONALNOG ZAHTJEVA Jednostavnost koritenja Transakcije koje se najee provode moraju biti dizajnirane tako da se mogu izvesti s najmanjim brojem interakcija (pritisaka na tipke mia ili tipkovnice). Sustav treba grafiki prikazati procesne korake i oznaiti korak u kojem se proces trenutno nalazi. Sustav treba sadravati pomo (on-line help) za sve funkcionalnosti. Pomo mora biti organizirana na dva naina: (i) preko kljunih rijei i elemenata suelja i (ii) preko opisa procesa (Kako?). OBVEZAN (DA/NE) NE NE ZADOVOLJAVA (DA/NE)
DA
31. svibnja 2010.
2/11
REDNI BROJ 1.4 1.5 1.6
Sve poruke o grekama moraju biti jasne, kako bi korisnik razumio u kojem je statusu transakcija i kako moe ispraviti greku ili odustati od procesa. Pravila i ponaanje korisnikog suelja moraju biti konzistentni kroz cijeli sustav, ukljuujui prozore, izbornike i komande. Sustav mora ponuditi smislene podrazumijevane vrijednosti (engl. default value) u sva polja za unos podataka gdje to ima smisla. Podrazumijevane vrijednosti mogu biti unaprijed fiksirane, definirane od strane korisnika, prenesene iz prethodnog unosa ili odreene prema kontekstu. Podrka u radu sustava Osigurati usluge produkcijske podrke za sustav Osigurati edukaciju korisnika
NAZIV NEFUNKCIONALNOG ZAHTJEVA
OBVEZAN (DA/NE) DA DA DA
ZADOVOLJAVA (DA/NE)
Ver. 1.0
2.
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8
Osigurati instalaciju, konfiguraciju i nadzor rada sustava na svim lokacijama
DA DA DA DA DA NE NE NE
Osigurati e-Learning materijale za edukaciju stalno dostupne korisnicima Osigurati redovno preventivno odravanje sustava Osigurati identifikaciju i izvjeivanje o izvanrednim dogaajima
Osigurati help-desk usluge za korisnike putem telefona ili interneta prema raspoloivosti definiranoj u SLA ugovoru Osigurati praenje i mjeseno/tromjeseno izvjeivanje o aktivnostima u radu sustava
31. svibnja 2010.
3/11
REDNI BROJ 2.9
2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 3. 3.1 3.2
Osigurati sistemsko odravanje, odravanje baza podataka, odravanje aplikacijskog i sistemskog softvera, odravanje hardvera i mrea Osigurati korektivno odravanje sustava
OBVEZAN (DA/NE) DA DA DA DA NE NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Osigurati ispravljanje greaka i otklanjanje kvarova prema kategorijama ozbiljnosti kvara u rokovima prema SLA modelu Osigurati tehnoloko usavravanje sustava Osigurati zamjene softvera novim verzijama Osigurati prilagodbe aplikacijske programske opreme i podataka novim verzijama programskih alata i hardvera Osigurati prilagodbe sustava promjenama pravnog okvira i poslovnih procesa
Osigurati tehniku i korisniku dokumentaciju Osigurati konzultantsku podrku u definiranju i analizi zahtjeva za prilagodbe Osigurati izradu procedura za ienje, konsolidaciju i migracija podataka sa starih sustava Pouzdanost
DA DA DA NE NE
4/11
NE
Garantirano srednje vrijeme izmeu kvarova (engl. mean time between failures MTBF) za hardverski i komunikacijski dio sustava je [XX] dana
31. svibnja 2010.
Garantirano srednje vrijeme za popravak sustava (engl. mean time to repair MTTR) za hardverski i komunikacijski dio sustava je [XX] sati
REDNI BROJ 3.3 3.4
Osigurane procedure za upravljenje kontinuitetom poslovanja( business continuity)
OBVEZAN (DA/NE) NE NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
4.
4.1 4.2 4.3 4.4 4.5 4.6
Sustav mora imati arhitekturu i mehanizme koji poveavaju pouzdanost rada sustava: prebacivanje poslova s primarne na priuvne komponente, prvenstveno koritenjem serverskih klastera (clustering), praenje izvrenih operacija (logging), automatsko stavranje siguronosne kopije i njen povratak (automatski backup and recovery), uravnoteavanje optereenja(load-balancing), prebacivanje poslova s primarne na priuvne komponente u sluaju nepredvienih situacija(DB failover) Dostupnost Sustav mora biti dostupan najmanje svaki radni dan u radno vrijeme ustanove, a sustav razmjene podataka 24 sata dnevno. Vrijeme u kojem sustav ne radi zbog odravanja je manje od [XX] sati godinje
Vrijeme u kojem sustav ne radi zbog kvarova i izvanrednih dogaaja je manje od [XX] sati godinje Help-desk mora potvrditi primitak poruke u roku od [XX] sati, a prosjeno vrijeme za rjeavanje poruke je [XX] dana
DA NE NE NE
Kvarovi i neispravnosti koji uzrokuju potpuni zastoj poslovnog procesa (potpuni pad sustava) moraju biti rijeeni u roku od [XX] sati Kvarovi i neispravnosti koji uzrokuju znatno oteano odvijanje poslovnog procesa (djelomian pad sustava) moraju biti rijeeni
DA DA
5/11
31. svibnja 2010.
REDNI BROJ 4.7 4.8
u roku od [XX] sati
OBVEZAN (DA/NE) DA NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Kvarovi i neispravnosti koji ugroavaju odvijanje poslovnog procesa (znaajan utjecaj na sustav) moraju biti rijeeni u roku od [XX] sati
5.
5.1 5.2 5.3
Kvarovi i neispravnosti koji zahtijevaju nadzor ponaanja sustava radi prevencije (djelomian utjecaj na sustav) moraju biti rijeeni u roku od [XX] sati Performanse Sustav podrava ukupno barem [XX] registriranih korisnika
Sustav podrava rad barem [XX] korisnika istovremeno
DA DA NE
5.4
Vrijeme odziva sustava prilikom izvoenja standardnih operacija (navesti kojih: npr. unos pismena, pregled dokumenta, jednostavno pretraivanje itd.) u normalnom optereenju sustava (navesti broj aktivnih korisnika, broj otvorenih dokumenata ili drugu prikladnu mjeru) je najvie [XX] sekundi Vrijeme odziva sustava prilikom izvoenja standardnih operacija (navesti kojih: npr. unos pismena, pregled dokumenta, jednostavno pretraivanje itd.) u predvienom vrnom optereenju sustava (navesti broj aktivnih korisnika, broj otvorenih dokumenata ili drugu prikladnu mjeru) je najvie [XX] sekundi
NE
5.5
31. svibnja 2010.
Sustav moe izvriti [XX] standardnih operacija (npr. operacija u bazi podataka) u sekundi
NE
6/11
REDNI BROJ 6. 6.1
OBVEZAN (DA/NE) NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Upravljivost i osmotrivost
6.2 6.3 6.4 6.5 6.6 7. 7.1 7.2 7.3 7.4
Sustav treba osigurati administrativne alate za standardne administrativne operacije (npr. monitoring aktivnosti i performansi u radu sustava, upravljanje korisnikim raunima i ulogama, upravljanje sigurnou sustava, alerti itd.) Sustav treba periodino: dnevno / tjedno / mjeseno / kvartalno / godinje, kreirati automatska izvjea o radu (definirati koje podatke izvjea trebaju sadravati)
NE NE NE NE NE DA NE NE DA
Sustav treba trenutno automatski slati izvjea o izvanrednim dogaajima i slati ih putem e-maila, sms-a ili na drugi nain definiranoj grupi korisnika Sustav treba podravati mogunost rekonfiguracije hardvera i softvera bez prekida rada Sustav treba omoguavati administratoru da po potrebi ukljuuje dodatne vorove Sustav treba omoguavati da administrator ugrauje nove mehanizme zatite Sigurnost Autentikacija i autorizacija korisnika
Upravljanje korisnikim raunima, ulogama i pravima Sustav ispunjava zahtjeve za razinu tajnosti [XX] prema Uredbi o mjerama informacijske sigurnosti i Pravilniku o standardima sigurnosti informacijskih sustava Monitoring aktivnosti na sustavu
31. svibnja 2010.
7/11
REDNI BROJ 7.5 7.6 7.7
Povijesnost promjena podataka
OBVEZAN (DA/NE) DA DA DA
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Usklaenost sa Zakonom o zatiti osobnih podataka, Uredbom o nainu pohranjivanja i posebnim mjerama tehnike zatite posebnih kategorija osobnih podataka
8.
8.1 9. 9.1 9.2 9.3 9.4 10.
Usklaenost sa Zakonom o tajnosti podataka, Zakonom o pravu na pristup informacijama, Zakonom o informacijskoj sigurnosti, Uredbi o mjerama informacijske sigurnosti, Pravilnikom o standardima sigurnosti informacijskih sustava, Pravilnikom o prevenciji i odgovoru na raunalnosigurnosne incidente i drugom regulativom RH Otpornost na greke Redundantna arhitektura, automatsko oporavljanje (recovery), failover mehanizmi Neovisnost o promjenama tehnologije i starenju Sustav omoguava i postoje procedure za nadzor nad kvalitetom medija za pohranu podataka i preventivnu zamjenu medija
NE NE NE NE NE
Sustav pohranjuje podatke na vie medija, omoguava usporedbe kopija podataka i automatske zamjene nekonzistentnih kopija Definiran je program obnavljanja opreme kako bi se osigurala stalna dostupnost podataka Backup
Sustav podrava migraciju podataka na nove medije
31. svibnja 2010.
8/11
REDNI BROJ 10.1 10.2 10.3 11.1 11. 11.2 12.1 12.
Mogunost povrata izgubljenih podataka
OBVEZAN (DA/NE) DA DA NE NE NE NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Mogunost izrade sigurnosne kopije podataka Mogunost inkrementalne pohrane podataka Skalabilnost Sustav se moe proiriti za rad poveanog broja korisnika (poveanje za [XX] korisnika) bez prekida pruanja usluga
Sustav se moe proiriti na druge ustrojstvene jedinice ili druge lokacije u roku od [XX] mjeseci bez prekida pruanja usluga Testiranje Definirana procedura testiranja i prihvaanja sustava koja ukljuuje testove komponenti, testove integracije (funkcionalne testove, testove kompatibilnosti, testove performansi, testove pod normalnim i vrnim optereenjem), testove prihvatljivosti
12.2
12.3 13.1 13. 13.2
U proceduri testiranja i prihvaanja sustava je definirano da knjigu testiranja ovjerava naruitelj, da naruitelj nadzire i ovjerava rezultate testova, sudjeluje u integracijskim testovima i provodi testove prihvatljivosti sustava
NE
U proceduri testiranja i prihvaanja sustava su definirani nain i rokovi za otklanjanje nedostataka utvrenih testovima Proirivost Sustav se moe povezati s odreenim drugim sustavima u roku [XX] mjeseci bez prekida pruanja usluga Sustav se moe proiriti odreenim novim funkcionalnostima u roku [XX] mjeseci bez
NE NE NE
31. svibnja 2010.
9/11
REDNI BROJ 14.1 14. 14.2 14.3
prekida pruanja usluga Prilagodljivost
OBVEZAN (DA/NE) NE NE DA
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Sustav sadri alate za prilagodbu sustava promjenama poslovnih procesa, poslovnih pravila, regulative, obrazaca, izvjea i dr. (navesti to) koji omoguavaju prilagodbe sustava bez promjena programskog koda
Sustav omoguava da korisnici prilagode sadraj grafikog suelja svojim potrebama (navesti koje elemente suelja, npr. polja u tablicama i formama, komande u izbornicima, boje i izgled suelja (skin) i sl.)
15.1 15. 16.1 16. 16.2 17.1 17.
Sustav se moe proiriti (navesti kako: broj korisnika, organizacijske jedinice, lokacije, nove funkcionalnosti, povezivanje s drugim sustavima) u roku od [XX] mjeseci bez prekida pruanja usluga. Mogunost lokalizacije Sustav omoguava promjenu jezika suelja. Sustav e koristiti odreenu postojeu infrastrukturu ili aplikacijske module. Mogunost viestrukog koritenja modula
NE NE NE
Sustav e se povezati s odreenim postojeim aplikacijama ili sustavima. Usklaenost s pravnom regulativom
31. svibnja 2010.
18.1 18.
Sustav mora biti usklaen s pravnom regulativom Republike Hrvatske navedenom u poglavlju Pravni okvir u Republici Hrvatskoj Standardnog projekta elektronikog uredskog poslovanja. Interoperabilnost i otvorenost Sustav treba biti usklaen s okvirom za interoperabilnost.
DA
DA
10/11
REDNI BROJ 19.1 19. 19.2 19.3
OBVEZAN (DA/NE) NE NE NE
ZADOVOLJAVA (DA/NE)
Ver. 1.0
Podrka za druge platforme
Aplikacijski sustav se moe koristiti na razliitim hardverskim platformama (npr. mobilni ureaji)
Aplikacijski sustav se moe koristiti na razliitim operativnim sustavima (npr. verzije Windowsa, UNIX, Linux - na serverima i na klijentskim raunalima). Aplikacijski sustav se moe koristiti na razliitim klijentskim softverima (npr. web preglednicima IE, Mozilla Firefox).
31. svibnja 2010.
11/11
REPUBLIKA HRVATSKA

Privitak 7
Rjenik koritenih pojmova

Ver. 1.0
SPEUP Privitak 7: Rjenik koritenih pojmova
Rjenik koritenih pojmova NAZIV POJMA AD-HOC IZVJEA AKT
Ver. 1.0
SKRAENICA
izvjea za tu svrhu OBJANJENJE
IZVOR Uredba o uredskom poslovanju (NN 7/2009)
APPLICATION IMPLEMENTATION METHOD (ORACLE) ASAP A SAP AUTENTIKACIJA
AIM
SAP
pismeno kojim tijelo odluuje o predmetu postupka, odgovara na podnesak stranke, odreuje, prekida ili zavrava neku slubenu radnju te obavlja slubeno dopisivanje s drugim tijelima odnosno pravnim osobama koje imaju javne ovlasti metodologija implementacije metodologija implementacije proces provjere identiteta nekog subjekta, najee se odnosi na fiziku osobu. U praksi subjekt daje odreene podatke po kojima druga strana moe utvrditi da je subjekt upravo taj kojim se predstavlja proces kojim se odreuje do kojih dijelova sustava korisnik sustava ima pravo pristupa sigurnosna pohrana irina pojasa za prijenos podataka identifikacija predmeta odnosno pismena koja se sastoji od klasifikacijske oznake i urudbenog broja skeniranje vie dokumenata istovremeno notacija koritena za modeliranje poslovnih procesa
AUTORIZACIJA
BACKUP BANDWIDTH BROJANA OZNAKA
31. svibnja 2010.
BULK SCANNING PROCESS BUSINESS PROCESS MODELING NOTATION
BPMN
Uredba o uredskom poslovanju (NN 7/2009)
2/12
NAZIV POJMA
CHARGING RULE FUNCTION CONTENT MANAGEMENT SYSTEM DATA RECOVERY PLAN DEVELOPMENT REQUIREMENTS DOCUMENT LIFECYCLE MANAGENMENT DOKUMENT
CRF
SKRAENICA CMS DRP
funkcija pravila registriranja korisnikih zahtjeva sustav za upravljanje sadrajem OBJANJENJE plan ouvanja podataka upravljanje ivotnim ciklusom dokumenata
IZVOR
Ver. 1.0
DLM
zahtjevi u razvoju sustava svaki podatak, odnosno svaki napisani, umnoeni, nacrtani, slikovni, tiskani, snimljeni, magnetni, optiki, elektroniki ili bilo koji drugi zapis podatka, fiziki predmet, priopenje ili informacija, koji sadrajem i strukturom ini raspoznatljivu i jednoznano odreenu cjelinu povezanih podataka skup predmeta koji se odnose na istu cjelinu, istu osobu, tijelo ili zadau koliko vremena je odreena usluga dostupna u nekom periodu sustav upravljanja elektronikim zapisima Uredba o uredskom poslovanju (NN 7/2009)
DOSJE
DOSTUPNOST (ENG. AVAILABILITY) ELECTRONIC RECORD MANAGEMENT SYSTEM
ERMS
31. svibnja 2010.
3/12
NAZIV POJMA
SKRAENICA
ELEKTRONIKA ISPRAVA
ELEKTRONIKI CERTIFIKAT
ELEKTRONIKI DOKUMENT ELEKTRONIKI POTPIS
ENTERPRISE APPLICATION INTEGRATION/ GOVERNMENT SERVICE BUS

31. svibnja 2010.
EAI/GSB
jednoznano povezan cjelovit skup podataka koji su elektroniki oblikovani (izraeni pomou raunala i drugih elektronikih ureaja), poslani, primljeni ili sauvani na elektronikom, magnetnom, optikom ili drugom mediju, i koji sadri svojstva kojima se utvruje izvor (stvaratelj), utvruje vjerodostojnost sadraja te dokazuje postojanost sadraja u vremenu. Sadraj elektronike isprave ukljuuje sve oblike pisanog teksta, podatke, slike i crtee, karte, zvuk, glazbu, govor potvrda u elektronikom obliku koja povezuje podatke za verificiranje elektronikog potpisa s nekom osobom i potvruje identitet te osobe bilo koja vrsta elektronikog zapisa koji nema svojstva elektronike isprave skup podataka u elektronikom obliku koji su pridrueni ili su logiki povezani s drugim podacima u elektronikom obliku i koji slue za identifikaciju potpisnika i vjerodostojnosti potpisanoga elektronikog dokumenta centralna podatkovna sabirnica za razmjenu podataka izmeu tijela javne uprave OBJANJENJE
Zakon o elektronikoj ispravi (NN 150/2005) IZVOR
Ver. 1.0
Zakon o elektronikom potpisu (NN 10/2002, 80/2008) Uredba o uredskom poslovanju (NN 7/2009) Zakon o elektronikom potpisu (NN 10/2002, 80/2008)
4/12
NAZIV POJMA
EUROPEAN INTEROPERABILITY FRAMEWORK, VERSION 2.0 EUROVOC
EIF 2.0
SKRAENICA
Europski okvir za interoperabilnost, verzija 2.0 OBJANJENJE
IZVOR
Ver. 1.0
EVENT DRIVEN PROCESS CHAIN DIJAGRAM EVOLUTION QUALITIES EXECUTION QUALITIES EXTENSIBLE MARKUP LANGUAGE
EPC dijagram
multidisciplinarni, viejezini pojmovnik Europske unije namijenjen indeksiranju dokumenata iz djelatnosti Europskih zajednica dopunjen dodatkom hrvatskih specifinih naziva. dijagram za modeliranje procesa i dogaaja atributi kvalitete u razvoju sustava atributi kvalitete u radu sustava
XML
EXTENSIBLE MARKUP LANGUAGE Schema
XML Schema
FAILOVER MEHANIZAM FOLDER
31. svibnja 2010.
jezik za oznaavanje podataka koji je jednostavno itljiv i ljudima i raunalnim programima noviji nain odreivanja pravila strukturiranja XML dokumenta format se kreira prema pravilima XML jezika koritenjem XML Scheme mogue je na vrlo detaljnom nivou odrediti opis sadraja odgovarajueg elementa koritenje mehanizama za prebacivanje poslova s primarne na priuvne komponente mapa, fascikl - virtualna mapa u digitalnom sustavu, a slui za organizaciju datoteka i dokumenata
5/12
NAZIV POJMA GRUPA (ENG. FILE)
SKRAENICA
INTEROPERABLE IDABC DELIVERY OF EUROPEAN EGOVERNMENT SERVICES TO PUBLIC ADMINISTRATIONS, BUSINESSES AND CITIZENS IPMA IPMA METODOLOGIJA (INTERNATIONAL PROJECT MANAGEMENT ASSOCIATION) JAVNOPRAVNA TIJELA
organizirana skupina zapisa koji su povezani putem iste teme, aktivnosti ili transakcije EU program za financiranje projekata i infrastrukturnih servisa za uspostavljanje paneuropskih servisa javne uprave OBJANJENJE metodologija voenja projekta
IZVOR
Ver. 1.0
JOINT PHOTOGRAPHIC EXPERTS GROUP KLASIFIKACIJSKA OZNAKA
JPEG
KLASA
Svi obveznici primjene Uredbe o uredskom poslovanju (NN 7/09): Tijela dravne uprave Strune slube Hrvatskog sabora i Vlade Republike Hrvatske, Ureda predsjednika Republike Hrvatske i drugih dravnih tijela, tijela i slubi jedinica lokalne i podrune (regionalne) samouprave te pravnih osoba koje imaju javne ovlasti komprimirani slikovni format najee koriten u normalnom radu sa slikama oznaava predmet prema sadraju, godini nastanka, obliku i rednom broju predmeta

6/12
31. svibnja 2010.
NAZIV POJMA
SKRAENICA
KLASIFIKACIJSKA SHEMA (ENG. CLASSIFICATION SHEME) LOAD BALANCING MEHANIZAM
MEAN TIME BETWEEN FAILURES
MEAN TIME TO MTTR REPAIR MODEL MoReq2 REQUIREMENTS FOR MANAGEMENT OF ELECTRONIC RECORDS MOGUNOST LOKALIZACIJE (ENG. LOCALIZABILITY) MOGUNOST VIESTRUKOG KORITENJA MODULA (ENG. REUSABILITY) MOGUNOSTI TESTIRANJA SUSTAVA (ENG. TESTABILITY) MONITORING
MTBF
hijerarhijska organizacija klasa(eng. class), grupa (eng. file), podgrupa (eng. sub-file), svezak (eng. volume), i zapisa (eng. record) tip servisa koji izvrava raunar koji dodjeljuje radno optereenje grupi (umreenih) serverskih stanica tako da se kompjuterski resursi koriste optimalno oznaava koliko prosjeno vremena proe izmeu dva dogaaja u kojima je sustav prestao raditi srednje vrijeme za popravak sustava OBJANJENJE referentni model za uspostavu sustava elektronikog upravljanja zapisima
IZVOR
Ver. 1.0
svojstvo sustava da se na jednostavan nain moe mijenjati jezik ili terminologija suelja svojstvo da se neki moduli sustava mogu koristiti i u drugim sustavima
karakteristika sustava koja osigurava da se ispitaju svi funkcionalni i nefunkcionalni zahtjevi na rad sustava praenje, nadgledanje
7/12
31. svibnja 2010.
NAZIV POJMA
SKRAENICA
OPTEREENJA (ENG. LOAD SCALABILITY) OCR
OPTIKO PREPOZNAVANJE ZNAKOVA (ENG. OPTICAL CHARACTER RECOGNITION) OSMOTRIVOST (ENG. OBSERVABILITY) OTPORNOST NA GREKE (ENG. FAULT TOLERANCE) PISARNICA
mogunost obavljanja poveanog broja operacija, pruanja veeg broja usluga ili poveanja broja korisnika raunalni softver koji je dizajniran tako da prevodi sliku u editabilni tekst, ili prevodi sliku sa znakovima u standardnu kodnu shemu predstavljajui ih u ASCII ili Unicode kodu mogunosti praenja informacija o stanju sustava ( teorija upravljanja) OBJANJENJE
IZVOR
Ver. 1.0
svojstvo sustava da nastavi raditi i nakon to je dolo do greke ili kvara u radu jednog dijela sustava
PISMENO
posebna unutarnja ustrojstvena jedinica koja obavlja poslove primanja i pregleda pismena i drugih dokumenata, njihovog razvrstavanja i rasporeivanja, upisivanja u odgovarajue evidencije (oevidnike), dostave u rad, otpremanja, razvoenja te njihova uvanja u pismohrani podnesak ili akt dio pisarnice koja obavlja poslove uvanja i izluivanja pismena te drugih dokumenata
PISMOHRANA
Uredba o uredskom poslovanju (NN 7/2009) Uredba o uredskom poslovanju (NN 7/2009)
31. svibnja 2010.
8/12
NAZIV POJMA PODGRUPA
SKRAENICA
(ENG. SUB-FILE)
PODNESAK
PODRKA ZA DRUGE OPERATIVNE SUSTAVE I HARDVERSKE PLATFORME (ENG. PORTABILITY) PORTABLE DOCUMENT FORMAT FOR LONGTERM ARCHIVING POILJATELJ
PDF/A
POTPISNIK
POUZDANOST (ENG. RELIABILITY)
logika podjela organizirane jedinice zapisa u kojoj su pohranjeni specifini zapisi (npr. rauni, korespondencija, elektronika pota i sl.) pismeno kojim stranka pokree postupak, dopunjuje, mijenja svoj zahtjev odnosno drugo traenje ili od tog odustaje ukljuuje zahtjeve izgradnje suelja za pristup preko mobitela ili osiguranja mogunosti prebacivanja sustava na drugi operativni sustav bez promjene programskog koda meunarodni ISO standard i hrvatska norma za dugorono pohranjivanje elektronikih dokumenata fizika ili pravna osoba koja alje ili u ime koje se primatelju alje elektronika isprava i ne ukljuuje informacijskog posrednika osoba koja posjeduje sredstvo za izradu elektronikog potpisa kojim se potpisuje, a koja djeluje u svoje ime ili u ime fizike ili pravne osobe koju predstavlja svojstvo sustava (najee nekog ureaja ili tehnikog sustava) da obavlja svoju funkciju neprekidno kroz odreeno vrijeme u okvirima zadanih uvjeta OBJANJENJE
MoReq2 IZVOR
Ver. 1.0
Zakon o elektronikoj ispravi (NN 150/2005) Zakon o elektronikom potpisu (NN 10/2002, 80/2008)
31. svibnja 2010.
9/12
NAZIV POJMA
SKRAENICA
PRILAGODLJIVOST (ENG. MODIFABILITY, FLEXIBILITY)
PRILOG
PRIMATELJ
PRINCE 2 METODOLOGIJA PROIRIVOST SUSTAVA (ENG. EXTENSIBILITY) RUP
RATIONAL UNIFIED PROCESS REDO LOG FILE
RESOURCE DESCRIPTION FRAMEWORK
RDF
31. svibnja 2010.
(ili mogunost prilagodbe sustava) opisuje sposobnost sustava da se prilagodi za promjene npr. regulative ili poslovnih procesa na ekonomski prihvatljiv nain svaki pisani sastavak ili slikovni prikaz (tablica, slika, crte ili slino) kao i fiziki predmet koji se prilae uz podnesak ili akt radi nadopune, pojanjenja ili dokazivanja njegovog sadraja fizika ili pravna osoba koja prima njoj upuenu elektroniku ispravu i ne ukljuuje informacijskog posrednika, metodologija voenja projekta mogunost ugradnji novih svojstava u sustav na ekonomski prihvatljiv nain i bez negativnih efekata na postojee funkcionalnosti. metodologija razvoja softvera datoteka za obnavljanje ( kod potpunog backupa kopiraju se sve podatkovne stranice koje se koriste i dio REDO loga koji ukljuuje sve otvorene transakcije i transakcije koje su izvrene tijekom trajanja backupa) W3C specifikacija za metadata podatkovni model; koristi se kao metodologija za konceptualni opis i modeliranje informacija (web servisi i tehnologije semantikog weba) OBJANJENJE
IZVOR
Ver. 1.0
Uredba o uredskom poslovanju (NN 7/2009) Zakon o elektronikoj ispravi (NN 150/2005)
10/12
NAZIV POJMA
SKRAENICA SLA
RUN-TIME REQUIREMENTS SERVICE LEVEL AGREEMENT
zahtjevi u radu sustava OBJANJENJE
IZVOR
Ver. 1.0
SIGURNOST (ENG. SECURITY)
SKALABILNOST (ENG. SCALABILITY)
SLUAJ KORITENJA (ENG. USE-CASE) SPIS (PREDMET)
STVARATELJ
SVEZAK (ENG. VOLUME)
TAGGED IMAGE FILE FORMAT

31. svibnja 2010.
TIFF
ugovori o razini pruanja usluga slue za definiranje kvalitete elektroniko komunikacijskih usluga i Help-desk usluga vezanih za rad poslovnih sustava sposobnost sustava da sprijei pristup, pregled i promjene podataka ili aplikacija neautoriziranim stranama svojstvo sustava da opslui naglo povean broj korisnika ili obavi povean broj transakcija prikazuje odnos izmeu izvoaa (sudionika) i korisnike funkcije skup pismena, priloga i drugih dokumenata koji se odnose na isto pitanje ili zadau ili koji na drugi nain ine posebnu cjelinu fizika ili pravna osoba koja primjenom elektronikih sredstava (ureaji i programi) izrauje, oblikuje i potpisuje elektroniku ispravu svojim naprednim elektronikim potpisom manji blokovi podjedinica koji se dijele u manje organizacijske blokove radi poboljanja upravljivosti podjela se radi na temelju broja zapisa, raspona oznaka, vremenskog perioda i sl. jedan od slikovnih formata
Zakon o elektronikoj ispravi (NN 150/2005)
11/12
NAZIV POJMA
THE PROJECT MANAGEMENT INSTITUTE THROUGHPUT TIJELA DRAVNE UPRAVE TIMESTAMP
PMI
SKRAENICA
metodologija voenja projekta OBJANJENJE
IZVOR
Ver. 1.0
TDU
UINKOVITOST (ENG. PERFORMANCE)
UPRAVLJIVOST (ENG. CONTROLABILITY) URUDBENI BROJ
kapacitet za izvrenje odreene koliine usluga u zadanom vremenu tijela dravne uprave su ministarstva, dravne upravne organizacije i uredi dravne uprave Vremenski ig je elektroniki potpisana potvrda izdavatelja koja potvruje sadraj podataka na koje se odnosi u navedenom vremenu uinkovitost ili performanse sustava opisuju koliko jedinica posla sustav moe obaviti u odreenom vremenu i s odreenim resursima mogunost prebacivanja sustava u eljeno stanje (teorija upravljanja) oznaava stvaratelja pismena, godinu nastanka i redni broj pismena unutar predmeta svojstvo sustava da primarnim ciljanim grupama korisnika omoguava jednostavno ostvarenje ciljeva s kojima koriste sustav web servisi i tehnologije semantikog weba digitalni potpis
Zakon o sustavu dravne uprave (NN 190/2003) Zakon o elektronikom potpisu (NN 10/2002, 80/2008)
JEDNOSTAVNOST KORITENJA (ENG. USABILITY) OWL
WEB ONTOLOGY LANGUAGE XMLDSIG (ENG. DIGITAL SIGNATURE) ZAPIS (ENG. RECORD)
31. svibnja 2010.
informacija stvorena, MoReq2 zaprimljena i odravana kao dokaz/informacija o poslovnom dogaaju
12/12

Standardni Projekt Elektroni010dkog Uredskog Poslovanja (SPEUP) - Verzija 1.0

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Standardni Projekt Elektroni010dkog Uredskog Poslovanja (SPEUP) - Verzija 1.0

Enviado por

Direitos autorais:

Formatos disponíveis

REPUBLIKA HRVATSKA

Standardni projekt elektronikog uredskog poslovanja

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

6.1 OSNOVNI GRADIVNI BLOKOVI ............................................................................................................................................... 31

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

6.1.10 6.1.11 6.1.12

Sigurna dostava poiljki ............................................................................................................................... 51

Potvrda primitka poiljke (e-Dostavnica) .............................................................................................. 54 Repozitorij podatkovnih modela ................................................................................................................ 56

7.3 ZAPRIMANJE PISMENA ........................................................................................................................................................... 58

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

11 PRIVITCI OSNOVNOG DOKUMENTA ................................................................................................................. 86

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

planiranje daljnjeg razvoja informacijskog sustava.

korisnike sustava u javnopravnim tijelima,

SPEUP Ver. 1.0

GENERIKI MODEL e-UREDA

dostava UPRAVNI POSTUPCI

POSTUPCI UREDSKOG POSLOVANJA

Standardni projekt elektronikog uredskog poslovanja

Podsustavi Informacijskog sustava TDU

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

Slika 2.2 Sustav za interoperabilnost javne uprave

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

Kreiranje i potpisivanje poruke

Validacija poslovnih pravila

Validacija/konverzija formata poruke

Prijem potvrde statusa

Slanje potvrde primitka

Validacija potvrde i potpisa Validacija poslovnih pravila

Prijem potvrde statusa Usmjeravanje potvrde statusa

Stanje statusa primitka

Prijem potvrde statusa

Dostava poruke aplikaciji

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja

SPEUP Ver. 1.0

Tijela dravne uprave mogu:

31. svibnja 2010.

Standardni projekt elektronikog uredskog poslovanja