Specifikacije

TEHNIČNI DEL RAZPISNE DOKUMENTACIJE IN SPECIFIKACIJE

ZA JAVNO NAROČILO NABAVA, PILOTNA

IMPLEMENTACIJA, DOPOLNITEV, IMPLEMENTACIJA, VZDRŽEVANJE IN

NADGRADNJA INFORMACIJSKEGA SISTEMA ZA PODPORO

UPRAVLJANJU DOKUMENTARNEGA GRADIVA CENTROV ZA SOCIALNO

DELO

KAZALO

1. UPORABNOST IN NAMEN INFORMACIJSKEGA SISTEMA ZA UPRAVLJANJE DOKUMENTARNEGA GRADIVA CENTROV ZA SOCIALNO DELO.......................................42. OPIS FUNKCIONALNOSTI IN VSEBIN INFORMACIJSKEGA SISTEMA ZA UPRAVLJANJE DOKUMENTARNEGA GRADIVA CSD..............................................................5

2.1 Sprejem.............................................................................................................................52.1.1 Elektronske pošiljke...................................................................................................52.1.2 Fizične pošiljke..........................................................................................................5

2.2 Evidentiranje.....................................................................................................................62.1.1 Zadeve........................................................................................................................62.2.2 Dokumenti..................................................................................................................7

2.3 Odprema..........................................................................................................................102.4 Rokovnik.........................................................................................................................112.5 Upravna statistika............................................................................................................122.6 Hramba............................................................................................................................12

2.6.1 Splošno.....................................................................................................................122.6.2 Tekoča zbirka...........................................................................................................122.6.3 Stalna zbirka.............................................................................................................13

2.7 Šifranti.............................................................................................................................142.7.1 Splošno.....................................................................................................................142.7.2 Klasifikacijski načrt.................................................................................................152.7.3 Signirni načrt............................................................................................................152.7.4 Šifrant subjektov......................................................................................................152.7.5 Šifrant pisarniških odredb........................................................................................162.7.6 Šifrant ključnih besed..............................................................................................162.7.7 Ostali šifranti............................................................................................................16

2.8 Pregledi...........................................................................................................................172.8.1 Splošno o prikazu zapisov.......................................................................................172.8.2 Pregledi v poštnem nabiralniku...............................................................................172.8.3 Pregledi v zbirki, ki predstavlja glavno pisarno.......................................................172.8.4 Pregledi v zbirki evidenčnega dokumentarnega gradiva.........................................182.8.5 Pregledi v tekoči zbirki dokumentarnega gradiva...................................................192.8.6 Pregledi v stalni zbirki dokumentarnega gradiva.....................................................202.8.7 Pregledi šifrantov.....................................................................................................202.8.8 Pregledi v rokovniku................................................................................................202.8.9 Ostalo.......................................................................................................................20

2.9 Izpisi................................................................................................................................203. ZAKONODAJA...........................................................................................................................224. SKUPINE UPORABNIKOV......................................................................................................23

4.1 Uporabniki v glavni pisarni............................................................................................234.2 Referenti centrov za socialno delo.................................................................................234.3 Skrbniki šifrantov...........................................................................................................234.4 Administratorji sistema..................................................................................................23

5. ZBIRKE INFORMACIJSKEGA SISTEMA ZA UPRAVLJANJE DOKUMENTARNEGA GRADIVA CSD....................................................................................................................................24

5.1 Zbirke..............................................................................................................................246. ARHITEKTURA SISTEMA IN TEHNOLOŠKO OKOLJE CENTRALNE STREŽNIŠKE INFRASTRUKTURE MINISTRSTVA ZA JAVNO UPRAVO TER PRAVILA UVELJAVLJANJA SPREMEMB......................................................................................................25

2

6.1 Arhitektura sistema.........................................................................................................256.2 Tehnološko okolje...........................................................................................................256.3 Splošna postavitvena pravila..........................................................................................26

6.3. 2 Model baznega servisa.......................................................................................266.3.3 Smernice za razvoj aplikacij, ki se nameščajo na strežniško infrastrukturo MJU...27Metodologija razvoja ter upravljanje s spremembami programske opreme.....................27Optimalnost aplikacije in baznih objektov.......................................................................28Namestitvena pravila........................................................................................................28Obremenitveni test............................................................................................................29Generalni preizkus............................................................................................................29Statistični podatki in osnovna poročila.............................................................................29Tehnološka neodvisnost....................................................................................................30Pravila postopkov nameščanja..........................................................................................30Informacijska varnost in skladnost z zakonodajo.............................................................30

7. UVEDBA INFORMACIJSKEGA SISTEMA ZA UPRAVLJANJE DOKUMENTARNEGA GRADIVA CENTROV ZA SOCIALNO DELO...............................................................................31

7.1 Namestitev informacijskega sistema...............................................................................317.2 Povezava s CRP..............................................................................................................317.3 Povezava zalednim(a) sistemom(a)................................................................................317.4 Integracija SIGOV-CA certifikata..................................................................................317.5 Pilotni projekt..................................................................................................................317.6 Testiranje sistemov.........................................................................................................317.7 Dokumentiranje in spremljanje različic..........................................................................327.8 Usposabljanje uporabnikov.............................................................................................32

8. VZDRŽEVANJE SISTEMA IN TEHNIČNA POMOČ..........................................................348.1 Redno vzdrževanje..........................................................................................................348.2 Dopolnilno vzdrževanje..................................................................................................358.3 Tehnična pomoč..............................................................................................................35

9. NADGRADNJE INFORMACIJSKEGA SISTEMA................................................................369.1 Povezava z informacijskim sistemom eCSD..................................................................36

10. TERMINSKI PLAN......................................................................................................................37

3

1. UPORABNOST IN NAMEN INFORMACIJSKEGA SISTEMA ZA UPRAVLJANJE DOKUMENTARNEGA GRADIVA CENTROV ZA SOCIALNO DELO

Informacijski sistem za upravljanje dokumentarnega gradiva centrov za socialno delo mora omogočati:

zajem; klasificiranje; signiranje, dosigniranje in presigniranje; odpremo; elektronsko podpisovanje; elektronsko vročanje; hrambo; e-arhiv (ne v prvi fazi); odbiranje in izločanje dokumentarnega gradiva; vodenje rokovnika; izdelavo upravne statistike.

S spletnimi servisi mora biti povezan s CRP-jem in z zalednima postopkovnima informacijskima sistemoma centrov za socialno delo (IS CSD in eCSD) na način:

1. da ob evidentiranju nove zadeve sistemoma posreduje: številko zadeve; subjekt zadeve; EMŠO-je; signirni znak nosilca zadeve; XML shemo za elektronsko prejete vloge.

2. da se na podlagi številke zadeve dokumenti, skreirani v enem od zalednih sistemov, evidentirajo kot izhodni ali lastni dokument v ustrezni zadevi.

Cilj razvoja informacijskega sistema za upravljanje dokumentarnega gradiva centrov za socialno delo je centrom zagotoviti enotno rešitev, ki bo v največji možni meri povezana z zalednima sistemoma, obenem pa bo podpirala tudi tehnološke novosti na področju upravljanja z dokumentarnim gradivom (sprejemanje elektronskih vlog, elektronsko podpisovanje in elektronsko vročanje v varne elektronske nabiralnike).

Uvoz že zajetih podatkov iz trenutno uporabljanih informacijskih sistemov za upravljanje dokumentarnega gradiva, ki so pripravljeni (urejeni) v predpisanem formatu.

Informacijski sistem mora omogočati tudi pretvarjanje dokumentarnega gradiva v elektronsko obliko (skeniranje), čeprav to ni predmet javnega naročila.

4

2. OPIS FUNKCIONALNOSTI IN VSEBIN INFORMACIJSKEGA SISTEMA ZA UPRAVLJANJE DOKUMENTARNEGA GRADIVA CSD

2.1 Sprejem

2.1.1 Elektronske pošiljke

V elektronski obliki prihajajo pošiljke na uradni elektronski naslov posameznega centra za socialno delo, in sicer preko enotnega državnega portala e-uprava, kjer se preveri tako elektronski podpis kot tudi veljavnost digitalnega potrdila, ti podatki pa prispejo skupaj z vsebino dokumenta (vloge) v uradni elektronski poštni nabiralnik centra za socialno delo.

Poštni nabiralnik je ločen od evidenčnega dela informacijskega sistema zaradi možnosti zavračanja neželene pošte. Omogočena mora biti možnost nastavitve zavračanja sporočil z določenih naslovov.

Informacijski sistem samodejno potrdi prejem vseh pošiljk z naslednjimi podatki:navedba prejetega sporočila ali njegova celotna vsebina, datum, čas in varen elektronski podpis csd-ja, overjen s kvalificiranim potrdilom.

Iz poštnega nabiralnika mora biti možno usmeriti prispelo sporočilo v zbirko za glavno pisarno in ga tam evidentirati kot dokument v obstoječo zadevo ali po potrebi predhodno odpreti novo zadevo. Ob tem mora biti omogočeno iskanje po različnih atributih obstoječih zadev in dokumentov (številka zadeve, subjekt, kratek opis, ključne besede, datum, signirni znak,…).

Ob evidentiranju se iz prejetega sporočila v ustrezna polja prenesejo tile podatki:- datum prispetja (pri času tudi minute),- pošiljatelj, - naslov sporočila, - vsebina sporočila- XML shema (če obstaja).

Po prenosu mora biti onemogočeno spreminjanje teh podatkov in vsebine.

Prav tako mora biti možno preusmeriti pošiljko v zbirko neevidenčnega gradiva ali pa jo označiti za nezaželeno pošto.

2.1.2 Fizične pošiljke

Dokumenti v fizični obliki se poskenirajo, vsebine pa se s pomočjo optičnega čitalca (ocr) prenesejo tako v dokumentni kot tudi v zaledni sistem. Elektronske slike dokumenta se shranjujejo na posebnem strežniku, informacijski sistem pa mora omogočati povezavo do elektronske slike dokumenta z linkom iz evidenčnega dela. Obstajati mora možnost avtomatske shranitve elektronsko podpisanega dokumenta in priponk na posebnem strežniku.

5

2.2 Evidentiranje

V sistemu mora biti možno evidentirati zadeve in dokumente. Dokument je vedno del neke zadeve. Evidentiranje zadev in dokumentov v glavni pisarni mora biti izvedeno v zaporedju izvajanja: najprej podatki o dokumentu, ki niso vezani na zadevo, potem preverjanje obstoja ustrezne zadeve in avtomatsko dopolnjevanje podatkov dokumenta s podatki obstoječe zadeve, oziroma evidentiranje nove zadeve.

2.1.1 Zadeve

Zadeva je evidentirana z naslednjimi podatki:- številka zadeve; * - klasifikacijski znak in opis (samo prikazano); - datum odprtja zadeve (privzet, možno spreminjanje nazaj); * - signirni znak; * - opis zadeve; * - subjekt ali tema zadeve (pri subjektu tudi naslov); * - EMŠO-ji (vsak v svojem polju);- povezave (zveza);- stanje zadeve; * - rok hrambe (prenesen iz klasifikacijskega načrta); * - rok za rešitev;- rok za naslednjo akcijo;- mesto hranjenja;- v vednost;- ključne besede;- zahteva za elektronsko obveščanje o spremembi statusa zadeve;- oznaka vrste postopka in stopnje zahtevnosti ; (samo pri ZUP zadevah) - tip zadeve (elektronska, fizična, kombinirana);- opombe;- kdo, kdaj in kaj je spreminjal.

* obvezen podatek

Podatke je možno vpisovati neposredno v polja ali jih izbirati iz šifranta, bodisi iz aplikacije ali tudi drugih sistemov. Sistem mora pri prostem vpisu preverjati obstoj vnesene vrednosti.

Številko zadeve generira informacijski sistem samodejno, na podlagi izbranega klasifikacijskega znaka in zadnje zaporedne številke znotraj te vsebine v tekočem letu. Zadeve se številčijo ločeno za vsak center za socialno delo posebej. Sistem mora onemogočati izbiro ali vpis eno in dvomestnih klasifikacijskih znakov.

Ob evidentiranju zadeve mora sistem omogočiti tiskanje ovoja zadeve v skladu s Pravilnikom o izvrševanju uredbe o upravnem poslovanju. Pri zadevah po ZUP in ZUJPS se na ovoj zadeve izpiše tudi šifra postopka iz Razvida postopkov centrov za socialno delo.

V polje rok hrambe se ob evidentiranju prepiše(jo) rok(i) iz klasifikacijskega načrta. Rok hrambe ob rešitvi zadeve samodejno izračuna sistem, razen če je za posamezen klasifikacijski znak predvidenih več rokov hrambe. V takem primeru mora zahtevati, da se uporabnik odloči za enega od možnih rokov. Rok hrambe, ki ga izračuna sistem, mora biti uporabniku dovoljeno podaljšati, ni pa ga dovoljeno krajšati.

6

Omogočena mora biti nastavitev kdo lahko odpira zadeve in onemogočeno evidentiranje dokumentov v rešenih zadevah.

Naknadno je možno spreminjati vse podatke o zadevi, z izjemo številke zadeve.

Očitne pomote je možno odpraviti s storniranjem zadeve (posebna pisarniška odredba). Omogočiti je treba vnos poljubnega števila subjektov z natančnimi podatki o naslovu.

Kadar so naslovniki fizične osebe, mora informacijski sistem naziv zapisati v zaporedju najprej ime in šele nato priimek osebe.

Zadeve in dokumenti se v glavni pisarni samo evidentirajo in razvrščajo v ustrezne zbirke.

Informacijski sistem mora uporabniku nuditi možnost izdelave popisa zadeve z naslednjimi podatki:datum, subjekt, datum rešitve, prikaz povratnic kot delov dokumenta.

Sistem mora podpirati tako funkcionalnost presigniranja kot tudi dosigniranja. Pri presigniranju se v nobenem primeru ne sme spreminjati vsebina že obstoječih zapisov. Obstoječi dokumenti v zadevi, ki jo presigniramo, se presignirajo, dejanje pa se zabeleži v zgodovino sprememb. Informacijski sistem mora omogočati masovno presigniranje oz. usklajevanje za signirni zank (del zadev enega uporabnika).

Omogočati mora avtomatizirano pridobivanje podatkov, ko poizvedba nosi s sabo identifikacijske podatke, ki jih informacijski sistem ob povratku razpozna in odgovor na njihovi osnovi samodejno uvrsti v pravo zadevo/dokument. Pri tem obvesti po elektronski pošti referenta, da je odgovor prispel.

Informacijski sistem mora omogočati možnost objave dokumentov na oglasni deski e-uprave.

Za dokumente iz zbirke neevidenčnega gradiva mora biti omogočeno, da se evidentirajo kot del zadeve v zbirki evidenčnega gradiva.

2.2.2 Dokumenti

V zadeve mora biti omogočeno dodajanje dokumentov različnih tipov (vhodni, izhodni, lastni) z možnostjo podrobnejše delitve posameznih tipov na različne vsebinske vrste. Dokumenti morajo imeti ustrezne grafične oznake (ikone), ločeno za:

- vhodne dokumente;- vhodne dokumente – prenesene iz elektronskega poštnega nabiralnika zaposlenega;- dokumente, čakajoče na odpremo;- dokumente, čakajoče na podpis;- izhodne dokumente;- izhodne dokumente, čakajoče na povratnico;- izhodne dokumente – odpremljene neposredno, brez posredovanja glavne pisarne;- lastne dokumente.

Podprte morajo biti najmanj naslednje oblike dokumentov:- elektronski dokumenti, ki imajo poleg tekstualnega še formatirani del (ovojnico);- sporočila, prejeta preko elektronske faksimilne naprave;- tekst;- tabele;

7

- sporočila elektronske pošte, vključno s prilogami;- skenirani papirni dokumenti;- strukturirani podatki (npr. transakcije z računalniško izmenjavo podatkov);- izmenjava podatkov z bazami podatkov;- spletne vloge.

O dokumentu se evidentirajo naslednji podatki:- oznaka nujnosti- številka zadeve (privzeta od zadeve in samo prikazana); - klasifikacijski znak z opisom (samo prikazan); - zaporedna številka dokumenta v okviru zadeve (skupaj s številko zadeve tvori številko

dokumenta);- signirni znak in opis signirnega znaka; - datum in čas evidentiranja (privzet, možen vpis preteklega datuma); - kratek opis dokumenta; - subjekt (ime in priimek fizične osebe oziroma ime pravne osebe ter naslov); - XML shema; - vrsta dokumenta (vhodni, izhodni, lastni, ki lahko se spremeni v izhodnega, zaznamek) ; - status dokumenta; - način prispetja/pošiljanja;- priloge;- v vednost;- vročiti;- referenčna številka (zveza, sklic na številko vhodnega dokumenta);- rok za naslednjo akcijo;- datum dokumenta;- podpisnik;- pripravljalec dokumenta;- ključne besede;- opombe;- oznake za upravno statistiko;- kdo, kdaj in kaj je spreminjal.

Za subjekt dokumenta mora sistem ponuditi subjekt zadeve z možnostjo spreminjanja.

Kot vhodni lahko nastopa tudi elektronska pošta, ki jo uslužbenec prejme v svoj elektronski nabiralnik. Za evidentiranje teh sporočil veljajo enaka pravila kot za prenos sporočil iz uradnega elektronskega naslova centra za socialno delo. V polje vsebine pri tem prenosu naj informacijski sistem prenese tudi ovojnico(glavo) sporočila.

Dokumente mora biti možno evidentirati tudi iz zalednega (ih) sistema(ov), od koder se kot priponka prenese odločba ali drug dokument. Povezovalni parameter je številka zadeve.

Informacijski sistem mora uporabniku omogočiti, da dokumentu določi enega od statusov:- v pripravi – skrito : samo pripravljalec vidi, da se dokument pripravlja;- v pripravi – javno : vsi, ki imajo dostop do dokumenta, vidijo, da se dokument pripravlja in

kdo ga pripravlja, ne vidijo pa njegove vsebine;- osnutek : dokument vidijo vsi, uporabnik, na katerega je signiran, pa ga lahko še spreminja;- v mnenje oziroma potrjevanje (uporabnik določi, kdo vse dobi ta dokument v pregled, sistem

pa uporabniku v vsakem trenutku omogoča pregled, kdo je mnenje že dal oziroma na koga se še čaka);

- objavljen: vsebine dokumenta ne more nihče več spreminjati;- v podpis in za odpremo; - za odpremo: dokument čaka, da ga glavna pisarna odpremi;- pridobivanje podatkov;

8

- storniran;- zavrnjen.

Nekatere statuse mora informacijski sistem dokumentom dodeliti samodejno, in sicer:- odpremljen : takoj, ko je odprema dejansko izvedena;- v podpisovanju : dokler ga niso še vsi podpisali;- podpisan : takoj, ko ga podpiše zadnji podpisnik.

Informacijski sistem mora omogočati izdelavo dokumentov neposredno v aplikaciji in pa pripenjanje vsebin dokumentov, ki so izdelani z drugimi programskimi orodji.

Pri dokumentih tipa lastni in izhodni mora obstajati možnost, da se vsebina vpisuje tudi preko vnaprej pripravljenih obrazcev. Pri tem mora biti omogočena uporaba programskih orodij za oblikovanje teksta na integriran način brez zapuščanja osnovnega okolja. Podprta mora biti uporaba standardnih obrazcev, ki so vsebovani v Priročniku celostne podobe državne uprave, pri ostalih pa mora obstajati možnost, da jih kreira in spreminja uporabnik sam. Pri obrazcih mora biti poskrbljeno, da se avtomatično narišejo prelomi strani. Obstajati mora možnost vezave določenega nabora obrazcev na določen tip dokumentov.

Podprto mora biti številčenje strani.

Informacijski sistem mora omogočati tudi avtomatsko generiranje množice istovrstnih dokumentov za vnaprej definirane naslovnike.

Napačno uvrščene dokumente morajo imeti uporabniki možnost zavrniti – s tem se vrnejo v glavno pisarno ali pa jih premestiti v poljubno drugo svojo zadevo. Pri premeščanju mora na prvotnem mestu dokumenta ostati zaznamek o tem dokumentu in dejstvu, da je bil premeščen in kam.

Obstajati mora možnost dodajanja drugih oseb kot avtorje ali bralce na zadeve in dokumente.

Pri dokumentih, ki jih uporabnik nekomu delegira, mora imeti tudi možnost nastavitve roka, do katerega mora ta odgovoriti.

Pri izhodnih dokumentih mora biti omogočeno tudi elektronsko podpisovanje (večkratno) in žigosanje.

Sistem mora imeti tudi funkcionalnost elektronskega parafiranja in podpisovanja dokumentov enega ali več podpisnikov.

Podpisovanje dokumenta se zabeleži v zgodovino dokumenta.

Pripravljalec dokumenta določi seznam podpisnikov. Ko prvi podpisnik podpiše dokument, seznama podpisnikov ni več mogoče spreminjati, prav tako tudi ne same vsebine dokumenta. Vsak člen podpisovalne verige ima možnost podpisovanje prekiniti. V tem primeru mora obvezno zabeležiti, kaj je razlog temu, dokument pa se vrne k pripravljalcu v status osnutka.

Dokumenti v podpisovanju oziroma podpisani dokumenti morajo imeti vidno dodatno oznako o tem dogajanju.

Elektronsko podpisan dokument mora imeti na mestu podpisa napisano, da je elektronsko podpisan, kdo ga je podpisal, s katerim certifikatom in veljavnost.

Podpisovanje mora biti izvedeno s potrdili SIGOV.CA.

Podpisovati mora biti možno tudi priponke v dokumentih.

9

Poskrbljeno mora biti, da bodo elektronsko podpisani dokumenti čitljivi tudi še po poteku certifikata.

Pri dokumentih, ki so prispeli elektronsko podpisani, naj se 'odpakiranemu' delu pri izpisu na papir doda zapis, da je dokument elektronsko podpisan ter podatki o podpisniku in certifikatu.

2.3 Odprema

Informacijski sistem mora nosilcem zadev omogočiti, da elektronsko zahtevajo odpremo dokumenta. Ob tem morajo določiti tudi način pošiljanja:

- navadna pošta;- obvezno osebno vročanje po ZUP (87. člen ZUP);- z javnim naznanilom (94. člen ZUP);- priporočeno;- priporočeno s povratnico;- po faksu;- po elektronski pošti;- po kurirju ali dostavni službi;- po kurirju ali dostavni službi osebno;

Pri vsakem načinu je mogoče navesti več naslovnikov, njihova izbira mora biti omogočena iz šifranta oziroma prenesena iz zadeve ali izhodnega (vhodnega) dokumenta oziroma pri elektronskem načinu odpreme iz imenikov elektronske pošte (SVN, CSD,…).

Pri skupinskem naslavljanju morajo biti zabeležena imena distribucijskih list, prav tako pa morajo biti dostopna tudi imena članov teh list (časovno neodvisna).

Obstajati mora tudi funkcionalnost izbire načina odpreme glede na vrsto izhodnega dokumenta. Program naj sam ponudi ustrezno možnost:

- pri dopisu naj ponudi - navadna pošta;- pri pozivu, sklepu, odločbi naj ponudi - vročanje s povratnico;- pri odstopu zadeve naj ponudi – priporočeno.

Pri odpremi lastnih ali izhodnih dokumentov po elektronski poti naj obstaja tudi možnost pošiljanja v vednost. Pri tem načinu mora informacijski sistem samodejno pripraviti XML ovojnico z evidenčnimi podatki dokumenta:

- organ javne uprave, - številka zadeve, - zveza, - kratek opis, - način pošiljanja, - datum dokumenta- naslov dokumenta- naslovnik;- pripravil.

Glavna pisarna vidi vse zahtevke za odpremo v posebnem pregledu in s klikom potrdi dejansko odpremo. Datum odpreme se zabeleži pri dokumentu. Odpremiti je možno samo uradni del dokumenta.

V primeru, da je bil dokument poslan s povratnico, se pošiljka vodi v posebnem pregledu čakajočih na povratnico. Vrnitev povratnice s klikom miške evidentira povratnico kot del dokumenta, na podlagi katerega je nastala, pošiljka pa se odstrani s seznama čakajočih na povratnico. Omogočeno mora biti tudi, da se evidentira, da povratnica ni prispela – pošiljka se prav tako odstrani s seznama čakajočih na povratnico.

10

Ko je za nek dokument zahtevana odprema, mora sistem poskrbeti, da ga ni mogoče več spreminjati. Mora pa obstajati možnost, da ga glavna pisarna vrne nazaj v pripravo.

Informacijski sistem mora podpreti elektronsko vročanje dokumentov enakovredno kot navadno (prispeti mora vročilnica oziroma povratnica).

Podprt mora biti sistem vpisovanja R številk na kuverte s povratnico z evidenco poštnine.

Skladno z zahtevami pošte je potrebno realizirati sistem za zapisovanje (izpisovanje) R številk na kuverte za obvezno osebno vročanje po ZUP in na priporočene pošiljke v obliki črtne kode. Sistem mora omogočiti tudi evidenco dnevne/mesečne poštnine, izpis oddajne knjige za vse poslane priporočene pošiljke z vpisanimi vsemi potrebnimi elementi (R številka, naslovnik, teža, poštnina,…). Navadne pošiljke se v oddajno knjigo vpišejo v celotnem številu glede na težo pošiljk (npr 20 kom. pošiljk do 20g) in tako dalje glede na težo v skladu s poštno tabelo območij tež.

Pri tem je treba upoštevati naslednje predpostavke (velja za vsak posamezen center za socialno delo):

- kuverte se izpisujejo na več delovnih mestih;- R številka se dodeljuje centralno za posamezen center za socialno delo. Pošta dodeli nabor

številk (npr. od 2001 do 3000), ki kolobarijo (ko porabijo zadnjo, se številčenje začne od začetka);

- odprema se izvaja centralno (na enem ali več mestih);- oddajna knjiga se izpiše na enem mestu za vse pošiljke;- za tehtanje pošiljk se uporabi tehtnica, priključena na računalnik;- sistem mora znati iz teže in vrste pošiljke izračunati poštnino (tudi za navadne pošiljke).

Za nevročene pošiljke mora obstajati možnost, da glavna pisarna označi, da vročitev ni možna. Taka pošiljka se odstrani s seznama čakajočih povratnic ali pa se izvede postopek skladno z ZUP.

Informacijski sistem mora omogočati ponovno pošiljanje že poslanih dokumentov, preprečiti pa mora spreminjanje vsebine že odpremljenega dokumenta. Zabeleženi morajo biti vsi datumi odpreme.

2.4 Rokovnik

Rok mora biti možno določiti tako na zadevah kot dokumentih. O poteku roka informacijski sistem samodejno obvesti uporabnika in glavno pisarno.

Rokovnik mora omogočati:- spremljanje poteka roka zadevam v rokovniku;- spremljanje roka za naslednjo akcijo na zadevah;- spremljanje roka za naslednjo akcijo na dokumentih;- spremljanje roka za rešitev zadeve.

Obvezni podatki o rokovniku:- vrsta odredbe/akcije- datum poteka- seznam zadev/dokumentov (ločen prikaz)- komentar.

Sistem mora opozarjati na bližanje izteka roka (obvestilo v okviru) nekaj dni prej (nastavljivo).

Uporabnik mora imeti možnost, da v primeru odsotnosti določi, da namesto njega obvestilo o poteku roka dobi kdo drug.

11

Obstajati mora možnost nastavitve samodejne spremembe stanja zadeve (samo za primer vodenja evidence izključno v elektronski obliki z vsebinami vseh dokumentov v elektronski obliki) in možnost spremembe roka.

2.5 Upravna statistika

Uporablja se Razvid centrov za socialno delo.

Informacijski sistem mora za zadeve po ZUP, z izjemo zadev po ZUPJS (predvidoma klasifikacijski znak 123), na zahtevo izdelati predpisane obrazce za poročanje o upravnih stvareh na prvi stopnji v določenem časovnem intervalu v skladu s Pravilnikom o vodenju evidence o upravnem postopku.

2.6 Hramba

2.6.1 Splošno

Obvezni podatki o rešenih zadevah, ki morajo biti prikazani v kazalu:

- številka zadeve;- subjekt;- kratek opis zadeve;- signirni znak;- rok hrambe;- leto rešitve;- mesto hrambe;- status (izposojena, izločena, predana arhivu,…).

Omogočeno mora biti vodenje izposoje zadev z naslednjimi podatki pri evidenci dokumentarnega gradiva:

- odobritev izposoje – vodja upravnega dela ali vodja organizacijske enote ali predstojnik;- datum izposoje;- kdo izposoja,- namen izposoje,- kopiranje – kaj se kopira,- datum reverza ali pogodbe – če gradivo nese izven organa,- do kdaj se dovoli izposoja,- datum vrnitve;- kdo je vrnil zadevo na mesto hrambe, - opombe.

2.6.2 Tekoča zbirka

V tekoči zbirki dokumentarnega gradiva se hranijo rešene zadeve tekočega leta in dveh predhodnih let. Prenos iz aktivne (postopkovne) zbirke poteka na zahtevo in sicer se lahko prenesejo v to zbirko samo rešene zadeve, ki imajo določen rok hrambe.

Tekoča zbirka je lahko skupna ali pa obstajajo ločeno za posamezne aktivne zbirke.

12

Zadeve se lahko po potrebi reaktivirajo, takrat se morajo vrniti v izvirno zbirko nerešenih zadev. Pri reaktivaciji je treba obvezno napisati razlog tega dejanja in že določeni rok hrambe zamenjati z rokom, zapisanim v klasifikacijskem načrtu.

Informacijski seznam konec januarja tega leta avtomatično izpiše vse rešene zadeve preteklega leta in jih med letom dopolnjuje v posebnem pregledu.

Prenos iz tekoče v stalno zbirko dokumentarnega gradiva se izvaja na zahtevo. Informacijski sistem mora določiti sam tiste zadeve, ki se prenašajo (ki so bile v tekoči zbirki dokumentarnega gradiva več kot dve celi leti). Samodejno mora izločiti tiste zadeve, ki jim je ob prenosu že potekel rok hrambe. Izločanje zadev pomeni, da dobijo navedene zadeve ustrezen status in se premestijo v poseben pregled ter se po predpisanem postopku tudi izbrišejo (vsebina).

Informacijski sistem mora izdelati zapisnik o prenosu zadev v stalno zbirko dokumentarnega gradiva, ki ima poleg podatkov o zadevi in vsebine zadev, tudi datum prenosa in podatke o odgovornem delavcu, ki je izvedel prenos.

Informacijski sistem mora izdelati zapisnik o izločanju gradiva iz tekoče zbirke (zadeve, ki imajo rok hrambe do 2 leti) z (najmanj) naslednjimi podatki:

naziv in naslov organa, predsednik in drugi člani komisije, datum,seznam zadev za uničenje.

Dejansko izločanje (brisanje vsebine zadev) izvede na podlagi zapisnika komisije odgovorni delavec s posebnim šifriranim ukazom, ki je dostopen samo njemu. Dopustiti je potrebno tudi možnost, da ne izloči zadev, ki jim je potekel rok hrambe.

2.6.3 Stalna zbirka

Informacijski sistem mora biti sposoben samodejno izdelati načrt stalne zbirke z naslednjimi podatki:

- oznaka prostorov,- oznaka polic v prostoru in druge opreme za hranjenje gradiva,- razporeditev zadev v tehničnih enotah po prostorih in policah oziroma drugi opremi za

hranjenje,- oznaka tehnične enote – naziv organa, klasifikacijski znak, zaporedne številke zadev oziroma

začetne črke imen ali nazivov subjektov, če so zadeve v okviru klasifikacijskega znaka urejene po abecedi, leto nastanka, rok hrambe (A ali T) oziroma leto, ko poteče rok hrambe.

V informacijskem sistemu morajo obstajati pregledi nad zadevami z različnimi roki hrambe:ATdoločen rok hrambe v letih.

Odbiranje in izločanje dokumentarnega gradiva mora potekati na zahtevo. Uporabnik mora imeti možnost podrobneje določiti pogoje za odbiranje gradiva (obdobje odbiranja, upoštevanje dodatnih zahtev pristojnega arhiva pred začetkom in med odbiranjem itd).

Informacijski sistem mora avtomatično izdelati naslednje dokumente:

1. popis arhivskega gradiva z (najmanj) naslednjimi podatki:naziv in naslov organa, ime in priimek članov komisije,

13

obdobje za katero se gradivo odbira – začetna in končana letnica, seznam zadev s potrebnimi podatki: številka, subjekt, kratka vsebina zadeve, letnica nastanka.

2. zapisnik o predaji arhivskega gradiva pristojnemu arhivu z (najmanj) naslednjimi podatki:naziv in naslov organa naziv in naslov pristojnega arhiva, ime in priimek pristojnih delavcev,datum in kraj izročitve, obdobje, za katero se izroča arhivsko gradivo, obseg oziroma število enot, ki se predajajo, navedbo arhivskega gradiva, ki iz tega obdobja še izjemno ostaja pri izročitelju in rok, dostopnost arhivskega gradiva.

3. popis gradiva za uničenje z (najmanj) naslednjimi podatki:naziv organa, ime in priimek članov komisije, datum popis zadev za uničenje.

Zadeve, ki so predvidene za izločanje se brišejo. Dejansko izločanje (brisanje vsebine zadev) izvede na podlagi zapisnika komisije odgovorni delavec s posebnim šifriranim ukazom, ki je dostopen samo njemu.

Informacijski sistem mora omogočiti avtomatski prenos odbranega gradiva v elektronski obliki v informacijski sistem pristojnega arhiva. Po prenosu dobi gradivo status 'predano arhivu'.

Dopustiti je potrebno tudi možnost, da posamezni organ javnopravne osebe lahko zadrži elektronske zadeve, ki jim je potekel rok hrambe.

Zadeve mora biti možno reaktivirati. Pri tem se morajo vrniti v izvorno zbirko nerešenih zadev, v polje rok hrambe pa se ponovno prepiše rok hrambe iz klasifikacijskega načrta.

2.7 Šifranti

2.7.1 Splošno

Šifranti morajo biti dostopni neposredno iz aplikacije, tudi iz postopka evidentiranja. Uporabniku mora biti omogočeno, da podatek izbere iz šifranta ali da ga neposredno vpiše. Pri neposrednem vpisu mora sistem preveriti obstoj podatka.

Šifranti morajo biti medsebojno povezljivi, prav tako pa tudi s sorodnimi šifranti drugih splošno uporabljanih aplikacij.

Pri vseh šifrantih je potrebno voditi celotno zgodovino.

Število vpisov v šifrante ne sme biti omejeno.

14

2.7.2 Klasifikacijski načrt

Uporablja se enotni klasifikacijski načrt za centre za socialno delo. Informacijski sistem mora dopustiti dodajanje klasifikacijskih znakov na četrtem in petem mestu in imeti vgrajeno kontrolo, da so klasifikacijski znaki izključno številčni in ne več kot pet mestni.

Obvezni podatki v klasifikacijskem načrtu:- klasifikacijski znak (obvezno);- opis klasifikacijskega znake (obvezno);- rok hrambe (obvezno);- prejšnji klasifikacijski znaki (vodenje zgodovine);- datum začetka veljavnosti (obvezno).

Preprečena mora biti možnost brisanja klasifikacijskih znakov.

Ob spremembi klasifikacijskega načrta mora informacijski sistem omogočiti generiranje avtomatske arhivske kopije dotedanjega z datumom tega dogodka. Povezava prejšnjega klasifikacijskega načrta z aplikacijo se mora ohraniti.

Kadar se informacijski sistem oblikuje tako, da uporablja grafični uporabniški vmesnik, mora podpirati pregledovanje in grafično navigacijo skozi zadeve in strukturo klasifikacijskega načrta kot tudi izbor, iskanje in prikazovanje elektronskih zadev in njihove vsebine s tem mehanizmom.

2.7.3 Signirni načrt

Signirnih načrtov je toliko, kot je centrov za socialno delo (62). Struktura signirnega načrta je standardizirana:

Obvezni podatki v signirnem načrtu:- signirni znak;- opis signirnega znaka;- delovno področje (npr. država, regija, mednarodna organizacija);- ime in priimek zaposlenega;- dodani bralci;- dodani avtorji;- nadrejeni;- datum vnosa- naziv funkcija (za avtomatsko podpisovanje).

Informacijski sistem mora podpirati številčne, črkovne in kombinirane signirne znake.

Preko signirnega načrta mora biti izvedeno krmiljenje omejevanja dostopa do zadev in dokumentov in kontrola dostopov.

Ob spremembi signirnega načrta mora biti možno samodejno generiranje arhivske kopije dotedanjega z datumom tega dogodka.

2.7.4 Šifrant subjektov

Šifrant je specifičen za posamezen center za socialno delo.

15

Obvezni podatki:- kratica;- naziv;- EMŠO;- Davčna številka;- ulica in hišna številka oz. p.p.;- telefon;- fax;- elektronski naslov;- poštna številka;- kraj;- mednarodna oznaka države;- ime države;- opombe.

Šifranta poštnih številk in držav morata biti povezana z ustreznim poljem v šifrantu subjektov.

2.7.5 Šifrant pisarniških odredb

Obvezni podatki:

- opis odredbe;- možna predhodna stanja;- možna naslednja stanja- opombe.

2.7.6 Šifrant ključnih besed

Obvezni podatki:

- zaporedna številka;- opis ključne besede;- opombe.

Treba je omogočiti vezavo ključnih besed na klasifikacijski ali signirni znak in zagotoviti povezavo z Eurovoc-om.

2.7.7 Ostali šifranti

Informacijska rešitev mora predvideti vsaj še naslednje vrste šifrantov:

- šifrant držav;- šifrant poštnih številk;- šifrant oblik / vrst dokumentov (računi, ….);- šifrant načinov prispetja;- šifrant načinov odpreme;- šifrant nujnosti (izredno nujno, zelo nujno, nujno);- šifrant prilog.

16

2.8 Pregledi

2.8.1 Splošno o prikazu zapisov

Vsa imena polj morajo biti povsem usklajena s terminologijo, ki jo uporabljajo ustrezni predpisi.

Zagotovljeno mora biti, da uporabnik po vrnitvi v zbirko vidi enak pogled, kot ga je imel na ekranu pri zapuščanju zbirke. Informacijski sistem mora prikazati zapise, ki jih je našel z iskanjem, ne glede na število zadetkov.

Na nivoju celotnega sistema mora biti možno pridobiti pregled za določeno časovno obdobje:- vhodni dokumenti;- izhodni dokumenti;- rešene zadeve;- uporabnik;- število;

pa tudi podrobnejši, kjer bi se videla številka zadeve in opis.

Na zahtevo mora informacijski sistem izdelati datumski pregled posegov na zapisih, iz katerih mora biti natančno razvidno kdo je izvajal spremembe in kaj konkretno je spremenil.

2.8.2 Pregledi v poštnem nabiralniku

V poštnem nabiralniku morajo biti organizirani pregledi:

- prejetih sporočil;- zavrnjenih oziroma izbrisanih sporočil;- prejetih povratnic;- poslanih povratnih sporočil;- pregledi v poštnem nabiralniku - arhiv.

2.8.3 Pregledi v zbirki, ki predstavlja glavno pisarno

Informacijski sistem mora nuditi natančen, ločen pregled prispele in odposlane pošte za poljuben datum ali časovni interval. V zbirki, ki predstavlja glavno pisarno morajo biti na voljo pregledi, pri katerih mora biti vsaka pošiljka prikazana z naslednjimi podatki:

- datum prispetja/odpošiljanja;- oznaka stopnje tajnosti oz. stopnje nujnosti;- oznaka načina prispetja/odpošiljanja (elektronsko, po faxu, v papirni obliki…);- pošiljatelj/naslovnik;- opisom dokumenta; - številka zadeve v katero je uvrščen (v primeru obstoja več zbirk, še informacija o zbirki)- signirni znakom;- povezava na evidenčne podatke in vsebino dokumenta.

Preglede mora biti možno omejiti tudi na posamezne načine prispetja/pošiljanja dokumentov. Omogočeno mora biti iskanje po naslovnikih/pošiljateljih, opisih dokumenta…

17

Narejen mora biti poseben pregled dokumentov, ki čakajo na vrnitev povratnic.

Pri pregledovanju odpremljenih dokumentov morajo biti vidni vsi naslovniki, ki jim je bil dokument poslan.

2.8.4 Pregledi v zbirki evidenčnega dokumentarnega gradiva

V zbirki evidenčnega dokumentarnega gradiva mora obstajati glavni pregled, kjer je uporabnikom na voljo nabor vseh zadev s pripadajočimi dokumenti, dostop do njih pa jim je omogočen oziroma omejen v skladu z zaščitno shemo.

Seznam zadev je na vrhnjem nivoju prikazan z naslednjimi podatki:

- oznaka tajnosti zadeve;- številka zadeve;- kratek opis zadeve;- subjekt;- signirni znak;- stanje zadeve.

Na tem nivoju mora biti uporabniku ponujeno, da dobi celoten seznam dokumentov, ki jih vsebuje posamezna zadeva.

Dokumenti morajo biti prikazani z naslednjimi podatki:- zaporedna številka;- kratek opis dokumenta;- podatek o pošiljatelju ali pripravljalcu oziroma statusu dokumenta.

En nivo nižje mora uporabnik priti do celote vseh evidenčnih podatkov zadeve ali dokumenta in vsebine dokumenta, ki jih lahko v skladu s pravicami popravlja ali samo gleda.

Poleg glavnega mora obstajati tudi osebni pregled zadev, ki je v bistvu ekstrakt glavnega pregleda, vsebuje samo zadeve konkretnega uporabnika, od glavnega pregleda pa se razlikuje še po tem, da nima prikazanega signirnega znaka.

V tem pregledu mora obstajati ločen prikaz zadev, katerih lastnik je uporabnik (so signirane nanj) in tistih, ki jih je dobil samo v vednost.

Obstajati mora tudi osebni pregled dokumentov in sicer organiziran po posameznih statusih dokumenta.

Poleg tega morajo obstajati še pomožni pregledi nad celotno vsebino zbirke nerešenih zadev:- po tipih dokumentov (vhodni, izhodni, lastni);- še neprebrani dokumenti;- po številkah zadev;- po subjektih;- po tipih zadev (zadeve, dosjeji, zadeve s seznamom vlog, mape predpisov);- po statusih (stanju) zadev;- po referentih;- po upravnih postopkih;- po ključnih besedah;- po roku za rešitev;- po datumih;- povezane zadeve;

18

- pravnomočne;- statistika;- seznam vseh elektronskih podpisnikov s podatki, ki omogočajo dostop do dokumentov.

Obstajati morajo najmanj naslednji seznami:- seznam vseh zadev organa javne uprave, posamezne organizacijske enote ali delovnega mesta,

evidentiranih v koledarskem letu, s pregledom dokumentov k vsaki zadevi;- seznam vseh nerešenih zadev;- seznam nerešenih zadev na posameznem delovnem mestu ali v posamezni organizacijski

enoti;- seznam vseh rešenih zadev upravnega organa, organizacijske enote, delovnega mesta v

določenem časovnem obdobju;- seznam zadev, ki jim določenega dne poteče rok;- seznam nerešenih zadev, kjer v zadnjih x (npr. 10) dnevih ni bilo evidentiranega nobenega

dokumenta;- seznam zadev, ki se nanašajo na določeno vsebino, to je na določen klasifikacijski znak, vseh

ali samo nerešenih oziroma rešenih;- seznam vseh subjektov z možnostjo, da se prikažejo vse zadeve, ki se nanašajo na posamezen

subjekt ali temo;- seznam vseh podpisnikov (elektronskih) s podatki, ki omogočajo dostop do dokumentov.- slovar vseh ključnih besed z možnostjo, da se prikažejo vse zadeve, povezane s posamezno

ključno besedo;- statistično poročilo o številu rešenih in nerešenih zadev po klasifikacijskih znakih v izbranem

letu;- seznam nerešenih zadev, ki so na tekoči dan popolne poljubno število dni;- seznam nerešenih zadev, ki so na tekoči dan vložene poljubno število dni in nepopolne.

Omogočeno mora biti razvrščanje zapisov po vseh stolpcih z možnostjo preklopa padajoče – naraščajoče.

Omogočena naj bo možnost vpogleda v že pripravljene agregirane podatke z možnostjo spreminjanja iskalnih parametrov.

Pridobiti mora biti možno tudi naslednje sezname:

- število vseh signiranih zadev na posameznega referenta v določenem obdobju (po S in O).- število signiranih zadev na referenta v določenem obdobju po zahtevnosti upravnega postopka

(obremenitev).- celoletni pripad zadev razdeljen po obdobjih (kvartalno, mesečno itd.).- pripad zadev na delavca za zadeve, ki niso upravni postopek, za obdobje 1 meseca, treh

mesecev in pol leta.- število zaostankov.

2.8.5 Pregledi v tekoči zbirki dokumentarnega gradiva

Pregled zadev, ki so v tekoči zbirki (celoten in ločeno po posameznih letih);Pregled vseh zadev, rešenih v določenem koledarskem letu;Pregled zadev, prenesenih v določenem letu iz tekoče v stalno zbirko dokumentarnega gradiva oziroma zapisnikov o prenosu;Pregled vseh zadev, ki imajo določen rok hrambe (se pravi, da niso trajne ali arhivske);Pregled arhivskega gradiva;Pregled trajnega gradiva;Pregled izločenega gradiva;Pregled izposojenih zadev.

19

2.8.6 Pregledi v stalni zbirki dokumentarnega gradiva

Pregled zadev, ki so v stalni zbirki;Pregled vseh zadev, ki imajo določen rok hrambe (se pravi, da niso trajne ali arhivske, sortirano (grupirano) po letih, ko rok hrambe poteče);Pregled arhivskega gradiva;Pregled trajnega gradiva;Pregled izločenega gradiva;Pregled gradiva, predanega arhivom;Pregled gradiva, predanega arhivom in izločenega iz lastne zbirke (kako je prav?);Pregled zapisnikov o odbiranju in izločanju;Pregled izposojenih zadev.

2.8.7 Pregledi šifrantov

V vseh šifrantih morajo biti posamezne kolone naslovljene, da bo vidno, katero vsebino predstavljajo. Omogočeno mora biti hitro sortiranje po posamezni koloni.

2.8.8 Pregledi v rokovniku

Informacijski sistem mora vsak dan samodejno generirati seznam zadev, ki jim ta dan poteče rok. Omogočati mora zaposlenim v glavni pisarni in vodstvu pregled nad roki zadev in dokumentov vseh zaposlenih, vsakemu zaposlenemu nad svojimi in navzgor po hierarhiji.

Aplikacija mora nuditi različne preglede nad zadevami/dokumenti v rokovniku:- pregled o poteku roka na določen dan;- pregled o poteku roka v določenem časovnem obdobju.

2.8.9 Ostalo

Uporabniku mora biti omogočeno, da sam določi, katere zbirke želi preiskovati oziroma na enostaven način, da želi preiskovati vse. Pri tem mora informacijski sistem sam nadzorovati, do katerih zbirk ima uporabnik dostop in do katerih ne. Informacijski sistem mu mora v tem primeru pri zadetkih tudi označiti, v kateri zbirki jih je našel.

Vse preglede mora biti omogočeno sortirati po poljubnih kriterijih.

2.9 Izpisi

Izpis mora ohraniti izgled, kakršnega proizvede programsko orodje, s katerim je zapis ustvarjen in vključiti vse sestavne dele elektronskega zapisa (ki jih je možno izpisati).

Tiskanje mora biti omogočeno tako iz kazal kot tudi iz zadev oziroma dokumentov. Pri tiskanju dokumentov naj obstaja tako možnost izpisa evidenčnega dela in vsebine.

Uporabnik mora imeti vedno tudi možnost, da si natisne neko poizvedbo kot poročilo. V takem primeru mora informacijski sistem izpis opremiti z glavo, ki obsega naziv organa, naslov, datum izpisa in iskalne kriterije.

20

Ovoj zadeve mora biti možno natisniti tako v glavni pisarni kot tudi pri posamezni zadevi. Na ovoj se morajo prepisati evidenčni podatki zadeve, kot so predvideni z uredbo, na mesta, ki so zanje določena V primeru, da gre za zadevo, ki sodi med upravne postopke, mora informacijski sistem na ovoj pod številko zadeve natisniti še najavko 'U. p.: ' , če je že določeno, pa tudi številko postopka ter stopnjo zahtevnosti iz razvida.

Če gre za zadevo, ki ima oznako tajnosti, se kratica stopnje tajnosti izpiše tudi na ovoj pred številko zadeve.

Informacijski sistem mora imeti opcijo tiskanja naslovov na nalepke, kuverte, povratnice in vročilnice. Predvideno mora biti tiskanje obrazcev in kuvert (povratnic) v zadevah z večjim številom dokumentov.

Informacijski sistem mora uporabnikom omogočiti, da si za izpise izberejo privzeti tip pisave.

21

3. ZAKONODAJA

Informacijski sistem mora izpolnjevati zahteve naštete zakonodaje:

Uredba o upravnem poslovanju (Uradni list RS, št. 106/2005, 30/2006, 86/2006, 32/2007, 63/2007, 115/2007 (122/2007 popr.), 31/2008, 35/2009, 58/2010);

Pravilnik o izvrševanju uredbe o upravnem poslovanju (Uradni list RS, št. 75/05, 86/06 in 47/08);

Pravilnik o celostni podobi organov državne uprave (Uradni list RS,št. 46/08, 97/08, 106/08 – popr., 122/08, 48/09 in 50/10);

Zakon o varstvu dokumentarnega in arhivskega gradiva ter arhivih (Uradni list RS, št. 30/06);

Uredba o varstvu dokumentarnega in arhivskega gradiva (Uradni list RS, št. 86/06);

Enotne tehnološke zahteve verzija 1.0;

Pravilnik o določanju rokov hranjenja dok. gradiva v javni upravi (Uradni list RS, 52/09);

Zakon o splošnem upr. postopku (Uradni list RS,, št. 80/99, 70/00, 52/02, 73/04, 119/05, 105/06 – ZUS-1, 126/07, 65/08, 8/10);

Pravilnik o vodenju evidence o upravnem postopku (Uradni list RS, št. 18/03 in 7/06);

Pravilnik o potrjevanju dokončnosti in pravnomočnosti upravnih aktov (Ur.l. št. 43/05 in 94/07);

Zakon o dostopu do informacij javnega značaja (Uradni list RS, št. 51/06-upb2);

Zakon o tajnih podatkih (Uradni list RS, 50/06-UPB2 in 9/10).

22

4. SKUPINE UPORABNIKOV

uporabniki v glavni pisarni, referenti centrov za socialno delo, administratorji sistema.

Uporabniki se v sistem prijavljajo z uporabo certifikata SIGOV-CA.

4.1 Uporabniki v glavni pisarni

Uporabniki v glavni pisarni imajo dostop do vseh zbirk informacijskega sistema in polne pravice na teh zbirkah (kreiranje, spreminjanje). Izjema so lahko določeni šifranti.

4.2 Referenti centrov za socialno delo

Referenti centrov za socialno delo imajo dostop do zbirke evidenčnega dokumentarnega gradiva, neevidenčnega dokumentarnega gradiva, tekoče in stalne zbirke dokumentarnega gradiva.

V zbirki evidenčnega dokumentarnega gradiva lahko kreirajo dokumente in izvajajo akcije nad njimi (elektronsko podpisovanje, odprema, uvrščanje elektronskih sporočil). V zbirki neevidenčnega dokumentarnega gradiva lahko dokumente premeščajo v zadeve v zbirki evidenčnega dokumentarnega gradiva.

Nad zadevami in dokumenti v tekoči in stalni zbirki dokumentarnega gradiva imajo samo pregled.

4.3 Skrbniki šifrantov

Poleg zbirk za redno delo (bodisi v funkciji glavne pisarne ali referenta) imajo dostop do določenih šifrantov, na katerih imajo polne pravice.

4.4 Administratorji sistema

Imajo dostop do vseh zbirk informacijskega sistema in ustrezne pravice.

23

5. ZBIRKE INFORMACIJSKEGA SISTEMA ZA UPRAVLJANJE DOKUMENTARNEGA GRADIVA CSD

Vsebina in funkcionalne značilnosti posameznih zbirk so obrazložene v 2. poglavju. V nadaljevanju pa so naštete posamezne dokumentne zbirke informacijskega sistema za upravljanje dokumentarnega gradiva centrov za socialno delo:

5.1 Zbirke

poštni nabiralnik; zbirka za glavno pisarno; zbirka neevidenčnega dokumentarnega gradiva; zbirka evidenčnega dokumentarnega gradiva; tekoča zbirka dokumentarnega gradiva; stalna zbirka dokumentarnega gradiva.

24

6. ARHITEKTURA SISTEMA IN TEHNOLOŠKO OKOLJE CENTRALNE STREŽNIŠKE INFRASTRUKTURE MINISTRSTVA ZA JAVNO UPRAVO TER PRAVILA UVELJAVLJANJA SPREMEMB

6.1 Arhitektura sistema

Informacijski sistem mora biti zasnovan centralno s skupnimi šifranti (izjema sta signirni načrt in šifrant subjektov), omogočati pa mora ločeno vodenje evidenc dokumentarnega in neevidenčnega gradiva za vsak center za socialno delo.

Dostop do informacijskega sistema bo mogoč samo z digitalnim spletnim potrdilom SIGOV-CA.

6.2 Tehnološko okolje

To poglavje se nanaša na sisteme, ki se postavljajo na novo. Sistemi, ki že tečejo, ostajajo na obstoječi infrastrukturi, razen če razpis izrecno definira drugače.

Za aplikacijski nivo sistema je predvideno javansko strežniško izvajalno J2EE okolje IBM Websphere, za bazni del pa Oracle podatkovna zbirka.

Naročnik zagotavlja strežniško infrastrukturo, ki je zastavljena v luči zagotavljanja visoke razpoložljivosti, skalabilnosti ter prenosljivosti na novo strojno opremo,

o celotna postavitev temelji na okoljih z operacijskim sistemom Z/OS, Linux (SUSE, RedHat),

o predvideni sta ločeni lokaciji na razdalji več kot 100 km, povezani z eno ali več 1 Gbit povezavam,

o zagotovljena je stikalna oprema za porazdelitev bremen, ločena za DMZ ter intranet,o za internetno in intranetno dostopne module so predvideni ločeni sklopi po več instanc

spletnih/aplikacijskih J2EE strežnikov, o podatkovna zbirka (podatkovne zbirke) so postavljene kot Oracle DATAGUARD

logična replikacija oddaljeno lokacijo, o nad fizično podatkovno zbirko je lahko (če se naročnik tako odloči zaradi povečanja

razpoložljivosti sistema) na razpolago zbirka , ki deluje v celoti v spominu, dostopna preko JDBC mehanizma in se sinhronizira z podležno zbirko

Pri izvedbi projekta mora izbrani ponudnik upoštevati navodilo RTP v PRILOGI 1 – »DEUP – RTP, Politika v zvezi z namestitvami aplikacijskih sistemov na skupno strežniško infrastrukturo«.

Uporabljeni naj bodo sodobni, odprti in neodvisni tehnološki standardi in specifikacije pri razvoju spletnih rešitev. Izvajalec naj v soglasju z naročnikom predlaga in utemelji izbiro posameznih tehnologij pred začetkom razvoja (PZI). Uporaba tehnologij, ki bi povzročila naročniku in/ali zunanjim uporabnikom sistema dodatne stroške (licence) oz. spremembo njegovega tehnološkega okolja, je nedopustna.

25

6.3 Splošna postavitvena pravila

Moduli, do katerih dostopajo uporabniki, ki nimajo dostopa do komunikacijskega omrežja državnih organov (v nadaljevanju HKOM), se nameščajo v DMZ območje (segment požarne pregrade in segmentih stikala za porazdelitev bremen – »Content Switch«). Moduli, do katerih dostopajo izključno HKOM uporabniki, se nameščajo znotraj intraneta komunikacijskega omrežja državnih organov. Točna postavitev modulov pa se določa, ko so znani gabariti posameznega modula (značilnost aplikacije, nabor uporabnikov, nivo zahtevane varnosti, pričakovane obremenitve ipd.) skupaj s strokovnjaki Ministrstva za javno upravo.

6.3.1 Splošne arhitekturne smernice

Arhitektura sistema je spletna, več-nivojska (podatkovna zbirka, aplikacijski strežniki, spletni strežniki, spletni brskalnik), nekateri deli aplikacij so zaprti za "zunanje" uporabnike (dostop le iz privatnega državnega omrežja HKOM).

Sistem mora biti zgrajen modularno. Predstavitveni nivo mora biti logično ločen od poslovne logike.

6.3. 2 Model baznega servisa

(Spletna) aplikacija naj do baze ne dostopa neposredno preko SQL poizvedb nad tabelami, ampak naj do podatkov dostopa preko klicev baznih procedur. Prav tako naj se v nobenem primeru ne bi na bazo prijavljala s povezavo (bazno sejo), vzpostavljeno neposredno na shemo, ki je lastnik baznih objektov (tabel, baznih procedur etc).

Aplikacija do baze dostopa s prijavo na posebnega, za dano aplikacijo namensko postavljenega baznega uporabnika (create user …). Le-ta ima dodeljene le pravice (grant execute) do izvajanja tistih namensko spisanih baznih procedur/funkcij, ki jih za svoje delovanje nujno potrebuje. Glede na specifično situacijo, lahko ta bazna procedura opravlja tudi kake druge potrebne funkcije, npr ustvarjanje revizijskih sledi, preverjanje pravic izvajanja v varnostni shemi etc.

Slika 1. Okvirna princip modela baznega modula.

26

Model tipičnega baznega modulaVhodni podatki:

Ključ - poizvedbenipodatki,Kdo,Od kod,Zakaj.

Izhodni podatki:Atributni podatki

Vmesnik

Servis

Dnevnik ZBIRKAVpis

Tabele zbirke

Varnostna shema

zahteva

odgovor

Izjema za to pravilo je lahko (vendar ne nujno) bralni način dostopa do šifrantov in klasifikacij ter list vrednosti, ki se kateri se lahko izvede preko »podatkovnih pogledov« (database views). Prav tako se dopušča izjema za že izdelane komercialne in odprtokodne produkte za urejanje vsebin (CMS). V tem primeru, se morajo podatki sistema (osebni, poslovni, upravni, finančni, varnostni (uporabniki, pravice) etc) strogo ločiti od podatkov, s katerimi se upravlja preko sistema za CMS; načeloma se podatki poslovnega dela informacijskega sistema gostijo na samostojni podatkovni instanci, ločeni od instance, ki služi sistemu CMS.

Navedene izjeme naročnik potrdi na nivoju dokumenta PZI (projekt za izvedbo) ali pa na nivoju dokumenta VDP.

6.3.3 Smernice za razvoj aplikacij, ki se nameščajo na strežniško infrastrukturo MJU

Metodologija razvoja ter upravljanje s spremembami programske opreme

Naročnik izrecno ne predpisuje konkretne metodologije razvoja programske opreme, vendar mora izvajalec navesti, katero metodologijo uporablja in kateri izdelki, poleg tistih, ki so eksplicitno že navedeni v okviru danega razpisa, bodo rezultat razvoja.

Pred začetkom izgradnje sistema izvajalec pripravi projektno dokumentacijo (projekt za izvedbo – PZI), ki je rezultat natančne analize skupaj z načrtom sistema oziroma drugo dokumentacijo, potrebno za izvedbo sistema.

Dokumentacijo v okviru PZI mora pred nadaljevanjem dela potrditi naročnik; poleg PZI pa tudi po potrditvi PZI ostaja zavezujoča tako razpisna kot tudi druga potrjena dokumentacija.

Od izvajalca se pričakuje, da ima izdelane in uveljavljene postopke obvladovanja sprememb (repozitorij, številčenje različic). Izvajalec je dolžan voditi evidenco, vse spremembe ustrezno označevati ter dokumentirati. Verzija naj bo jasno razvidna iz uporabniškega vmesnika modula (npr: 'vizitka', 'noga', itd).

Pravilo velja tako za spremembe aplikacije, za spremembe baznih objektov ter za spremembe spremljajoče dokumentacije. Za vse spremembe, ki jih izvajalec načrtuje, mora izvesti postopke obveščanja tako naročnika kot upravljavca infrastrukture.

Izdelki razvoja se posredujejo/odlagajo naročniku v namenski »SVN repozitorij« - strežnik za hranjenje verzij oziroma sistem za upravljanje sprememb.

Zaželeno je, da izvajalec pripravi vzorčne namestitvene pakete aplikacije še preden je razvoj aplikacije končan, saj se lahko integracijsko okolje za potrebe prevzema novega sistema (novih funkcionalnosti) na ciljno infrastrukturo vzpostavlja vzporedno z razvojem. Vzorčni namestitveni paketi so torej namenjeni vzpostavitvi tehničnega okolja za nameščanje, ne toliko za vsebinsko oz. funkcionalno testiranje.

Ko je projekt pripravljen za namestitev (to naj se v fazi implementacije zgodi čim prej), izvajalec pripravi izdajo aplikacije in shrani izvorno kodo projekta na strežnik za hranjenje verzij. Izdajo mora opremiti s po vnaprej določenem načinu številčenja, ki ga izvajalec definira v okviru PZI.

27

Slika 2. prikazuje okvirni princip sistema za obvladovanje sprememb, ki vsebuje repozitorij izvorne kode SVN (Subversion) ter orodje za izvajanje upravljanja ter izdelavo poročil (Hudson) v povezavi s simbolično prikazano več nivojsko strežniško testno in produkcijsko infrastrukturo.

Optimalnost aplikacije in baznih objektov

Izvajalec je dolžan optimizirati programsko kodo in bazne objekte s ciljem zagotavljanja optimalnega delovanja. Vse neoptimalnosti, ki se izkažejo skozi obremenitveni test in skozi generalni preizkus mora izvajalec odpraviti do trenutka produkcije. Enako pravilo velja tudi za obdobje garancije oziroma obdobje operativnega vzdrževanja. Prav tako mora izvajalec vsako spremembo ali nadgradnjo aplikacije predhodno preveriti tudi s performančnega stališča. Lastnik infrastrukture izvaja periodične preglede optimalnega delovanja. Priporočila, ki nastanejo na podlagi takih pregledov je izvajalec dolžan v najkrajšem še razumnem roku upoštevati.

Namestitvena pravila

Za vsak modul/aplikacijo se vzpostavi najmanj tri okolja (testno, produkcijsko in šolsko/uvajalno) kot sledi:

testno okolje služi potrditvenemu testiranju (torej preverjanju, ali je bil nek popravek izveden v skladu z željami naročnika; testiranje pravilnosti kode se izvaja na strani izvajalca),produkcijsko služi polni produkciji. Sem se nameščajo samo popravki, katerih prehod iz testa na produkcijo je bil po predpisanem protokolu odobren Prenos namestitve aplikacije ali njenih popravkov iz razvojnega preko testnega do produkcijskega definira t.i. RTP navodilo (Razvoj-Test-Produkcija). Podrobnejši način izvajanja navodila se določi prilagojeno značilnostim vsakega projekta posebej.,uvajalno okolje je namenjeno izobraževanju uporabnikov in naj bi bilo po verzijah aplikacij izenačeno s produkcijskim.

28

Ukazi testnih namestitev

Ukazi produkcijskih namestitev

Nadzorno produkcijsko okolje

Nadzorno testno okolje

SVNREPOZITO-RIJIZVORNEKODEIN DOKUMEN-TACIJE

DokumentacijaIzvorna kodaAplikacijski paketiTestiPoročila o testiranjuPoročila o namestitvah

Objekti podatkovne zbirkeNavodila za nameščanjeNavodila za povratekPoročila o namestitvi

TESTJ2EE

TESTBAZA

PRODJ2EE

PRODBAZA

PRODJ2EE

PRODBAZA

SISTEM ZA UPRAVLJANJE SPREMEMB

Za vsako namestitev novega modula ali popravka obstoječega modula mora izvajalec pripraviti ustrezna navodila za namestitev.

Nove verzije/popravki tako spletnih aplikacij kot baznih objektov se najprej namestijo na testno področje;- Odgovorni predstavnik izvajalca opravi najmanj naslednja preverjanja:

- da je bila namestitev opravljena v skladu s izvajalčevimi navodili,- da je aplikacija deluje v skladu s funkcionalnimi pričakovanji,- da je aplikacija tudi preformančno ustrezna in deluje v skladu s pričakovanji;

Šele na podlagi pozitivnega izida tega potrditvenega testa, izjave odgovornega, da je bil test pozitivno opravljen, se lahko namesti deploy ali popravki na produkcijo.

Po namestitvi na produkcijo, izvajalec preveri delovanje po enakem vzoru, kot je bila narejena verifikacija na testu:

- da odgovorni predstavnik izvajalca izvede potrditveni test na produkciji, ki sestoji najmanj iz naslednjega preverjanja:- da je bila namestitev opravljena v skladu z izvajalčevimi navodili,- da je aplikacija deluje v skladu s funkcionalnimi pričakovanji,- da je aplikacija tudi preformančno ustrezna in deluje v skladu s pričakovanji;

Potrditveni test mora obsegati poleg delovanja same aplikacije tudi delovanje podatkovne zbirke in ustreznost baznih objektov.

Nameščanje aplikacij in njih popravkov se izvaja v skladu s t.i. RTP navodilom Ministrstva za javno upravo (navodilo obravnava postopke obvladovanja sprememb Razvojnega, Testnega in Produkcijskega okolja) ter obrazcem OVSP.

Razvojno okolje (in testna okolja za razvojno testiranje) so na strani izvajalca.

Obremenitveni test

Za kritične aplikacije ali celotni sistem, lahko naročnik zahteva izvedbo obremenitvenega preizkusa. Obremenitveni preizkus se običajno izvaja skupaj s strokovnjaki MJU s pomočjo orodja JMeter. Izvajalec je dolžan pripraviti scenarije in podatke za to orodje. Naročnik si pridržuje pravico spremembe orodja za izvajanje obremenitvenih preizkusov.

Generalni preizkus

Za kritične aplikacije z lahko določi naročnik izvedbo generalnega preizkusa. Generalni preizkus pomeni hkratno vajo vseh uporabnikov. Lahko se izvaja tudi kot vzporedni test. Za generalni preizkus je izvajalec dolžan pripraviti vsebinske in postopkovne scenarije.

Statistični podatki in osnovna poročila

Informacijska rešitev, ki je predmet javnega naročila mora omogočati izdelavo osnovnih statističnih poročil za podatke, ki so pomembni za upravljanje informacijske rešitve (kot na primer: statistika obiska, statistika postopkov (napak, po statusih), statistika po uporabi storitev , statistika urednikovanja ipd).

29

Tehnološka neodvisnost

Informacijska rešitev, ki je predmet javnega naročila mora omogočati uporabnikom nemoteno delo uporabo vseh relevantnih tehnologij (MS IE, Mozilla Firefox) odjemalca in operacijskih sistemov (MS WIN XP, MS Vista, MS WIN 7, Linux, Mac OS).

Pravila postopkov nameščanja

Tako izvajalec kot naročnik se držijo pravil postopkov nameščanja, kot so opisana v »Politiki v zvezi z namestitvami aplikacijskih sistemov na skupno strežniško infrastrukturo« (t.i. RTP pravilo) ter podrobneje definirana z obrazcem OVSP (Naročilo za namestitev aplikacij/popravka).

Informacijska varnost in skladnost z zakonodajo

Informacijska rešitev, ki je predmet javnega naročila mora biti izdelana z upoštevanjem vseh dobrih praks in ustreznih rešitev, ki zagotavljajo visoko stopnjo informacijske varnosti.

Informacijski sistem mora biti skladen s področno zakonodajo, ki obravnava podatke, ki se obdelujejo v informacijskem sistemu skladno z namenom, načinom obdelave in stopnjo tveganja:

Izvajalec je dolžan upoštevati dobre prakse in priročnike objavljene na spletni strani pooblaščenke glede na področja uporabe (Upravne storitve, Informatika v ...).

Rešitev mora biti skladna s standardom ISO 27001 in 27002 v poglavjih, ki se nanašajo/navezujejo na informacijsko varnost in revizijske sledi.

30

7. UVEDBA INFORMACIJSKEGA SISTEMA ZA UPRAVLJANJE DOKUMENTARNEGA GRADIVA CENTROV ZA SOCIALNO DELO

Za uvedbo informacijskega sistema izvajalec izvede naslednje naloge:

7.1 Namestitev informacijskega sistema

Namestitev informacijskega sistema se opravi v skladu z navodili: DEUP – RTP, Politika v zvezi z namestitvami aplikacijskih sistemov na skupno strežniško infrastrukturo, Tehnično okolje MJU ter pravila uveljavljanja sprememb, Naročilo za namestitev aplikacije/popravka OVSP, človeški viri za sistemsko administracijo na strani MJU-a.

Aplikativno administracijo informacijskega sistema bo v skladu z navodili: DEUP – RTP, Politika v zvezi z namestitvami aplikacijskih sistemov na skupno strežniško infrastrukturo, Tehnično okolje MJU ter pravila uveljavljanja sprememb, Naročilo za namestitev aplikacije/popravka OVSP, opravljal izvajalec.

V ta namen si mora izvajalec pridobiti SecureID kartico.

7.2 Povezava s CRP

Informacijski sistem preko spletnega servisa pridobiva podatke o subjektih iz Centralnega registra prebivalstva.

7.3 Povezava zalednim(a) sistemom(a)

Informacijski sistem se preko spletnih servisov poveže z informacijskim sistemom IS CSD, v nadaljevanju pa še z informacijskim sistemom eCSD.

7.4 Integracija SIGOV-CA certifikata

Integracija uporabe certifikatov SIGOV-CA za vse uporabnike.

7.5 Pilotni projekt

Usposobi se uporabnike dveh centrov za socialno delo, kjer se sistem testira 2 meseca. V tem času se ugotovi, če so potrebne še kakšne spremembe/dopolnitve.

7.6 Testiranje sistemov

Pri postavitvi sistema je potrebno testirati delovanje vsakega posameznega dela posebej in sistema kot celote.

delovanja informacijskega sistema(obremenilni testi) testiranje integracije certifikatov

testiranje delovanja povezav

31

testiranje administracije uporabnikov

testiranje podpore uporabnikom

7.7 Dokumentiranje in spremljanje različic

Pri razvoju sistema mora izvajalec vsako različico programske opreme ustrezno dokumentirati. Vsaka izdelek (različica programske opreme in dokumentacije sistema) mora biti označena po vnaprej določeni shemi, ki jo predlaga izvajalec.

Različica posameznega modula mora biti razvidna iz uporabniškega vmesnika tega modula (npr. vizitka, footer, ...)

7.8 Usposabljanje uporabnikov

Usposabljanje mora biti predvideno za cca 1200 in se izvaja za tri različne vrste uporabnikov:

uporabniki v glavni pisarni;referenti;administratorji.

Trajanje usposabljanja je do osem šolskih ur (4x 45 minut) in se izvede večkratno v skupinah po 12 oseb.

Vsi udeleženci usposabljanj morajo imeti na voljo računalnike, na katerih bodo izvedena usposabljanja.

Način izvedbe usposabljanja

Izvedba usposabljanja se prične, ko informacijski sistem deluje v produkcijskem okolju v skladu z razpisanimi funkcionalnostmi. Usposabljanje se praviloma izvaja ob torkih in četrtkih, ko na centih za socialno delo ni uradnih ur.

Izvajalec mora zagotoviti zbiranje prijav na usposabljanje, v ta namen naročnik izvajalcu izroči seznam udeležencev. Izvajalec nato s subjekti s seznama uskladi udeležbo na usposabljanju. O uspešni prijavi mora biti udeleženec obveščen na e-mail, ki ga navede ob prijavi. Udeležencem usposabljanja mora biti na razpolago e-mail naslov in telefonska številka za sporočanje morebitnih sprememb ali postavljanje vprašanj o sami organizaciji usposabljanja. Na telefonsko številko mora biti izvajalec dosegljiv ob 8.00 do 15.00. Prijave se morajo začeti zbirati v razumnem roku pred prvim terminom usposabljanja. Na prijavnici morajo biti tudi vsi podatki o časovnem poteku in lokaciji usposabljanja, vključno z zemljevidom lokacije usposabljanja in opisom poti do kraja usposabljanja. Usposabljanje se izvede na lokacijah, ki jih predhodno uskladita naročnik in izvajalec.V primeru nezadostnega števila prijav lahko naročnik prestavi ali potrdi izvedbo posameznega usposabljanja.

Točno uro pričetka usposabljanja določi naročnik.

Na spletni strani s podatki o prijavi se mora nahajati objavljeno gradivo s strani predavateljev. Predavatelje za usposabljanje potrdi naročnik. Stroške predavateljev krije izvajalec.

Na usposabljanju mora biti ves čas usposabljanja prisotna oseba, ki pozna delovanje informacijskega sistema in vseh njegovih funkcionalnosti.

32

Lokacijo in predavalnico potrdi naročnik na predlog izvajalca. Predavalnica mora bi svetel prostor z dobro vidljivostjo projekcije. Vsa predavanja se morajo dobro slišati.

Uporaba aplikacije s strani predavatelja se mora projicirati na platno, tako da projekcijo jasno vidijo vsi udeleženci.

Celotno gradivo, pripravljeno s strani predavateljev, mora izvajalec natisniti in zvezati na A4 format. Izvajalec vsa gradiva celotno oblikuje. Končni izgled navodil in enotnost navodil potrdi naročnik. Izvajalec mora vsakemu udeležencu ob prihodu zagotoviti poleg gradiva tudi pisalo in blok za pisanje.

Na usposabljanju se morajo zbirati liste prisotnosti v skladu z zahtevami naročnika.

Izvajalec naročniku predloži predlog urnika po predhodno opravljenem razgovoru glede zahtevanega vrstnega reda predavanj in razpoložljivosti predavateljev. Urnik potrdi naročnik.

33

8. VZDRŽEVANJE SISTEMA IN TEHNIČNA POMOČVzdrževanje informacijskega sistema za upravljanje dokumentarnega gradiva centrov za socialno delo obsega naloge, ki se izvajajo v okviru rednega vzdrževanja za podporo rednemu delovanju in dopolnilnega vzdrževanja.

8.1 Redno vzdrževanje

Redno vzdrževanje sistema se izvaja v okviru mesečnega pavšala in obsega:zagotavljanje nemotenega delovanja informacijskega sistema z vsemi njegovimi funkcionalnostmi, zagotavljanje razpoložljivosti in zahtevane odzivnosti ter kakovosti izvajanja storitev vzdrževanja,vodenje in koordinacijo dela med izvajalcem in naročnikom oziroma uporabniki oziroma končnimi uporabniki; spremljanje tehnoloških novosti, povezanih z informacijsko rešitvijo ter priprava predlogov ukrepov za nemoteno delovanje ter za izboljšanje delovanja, ki jih bo realiziral izvajalec v okviru dopolnilnega vzdrževanja; spremljanje ugotovljenih problemov ter predlaganje ukrepov za nemoteno delovanje aplikativne programske opreme,odpravljanje skritih napak in pomanjkljivosti v kodi po preteku jamstva (Bug Fix Releases and Remedial Software Patches) v skladu z navodili proizvajalca; ažuriranje (usklajevanje s predpisi); namestitev novih verzij oziroma sprememb in dopolnitev programske opreme, ki so posledica rednega vzdrževanja,skrb za sistem varovanja (sistem zaščite, sistem varnostnega kopiranja); zaradi sprememb predpisov po navodilih naročnika oziroma uporabnikov v okviru mesečnega zneska vzdrževalnine; osnovno daljinsko uporabniško pomoč in svetovanje glede uporabe informacijskega sistema v skupnem obsegu največ 300 motenj oziroma 700 uporabniških vprašanj oziroma ekvivalentu posegov;vodenje evidence pomoči in vodenje baze znanja, do katere imajo naročnik in uporabniki dostop preko spleta; dokumentiranje storitev rednega vzdrževanja, dogovorov in sprememb v zvezi z osnovnim vzdrževanjem; druge vzdrževalne aktivnosti po naročilu naročnika oziroma uporabnikov, ki ne presegajo predvidenega mesečnega zneska vzdrževalnine za osnovno vzdrževanje in predvideno število uporabniških vprašanj oziroma motenj oziroma posegov.

Odzivni časi:

Prioriteta zahtevka Odzivni čas*

Čas v katerem mora izvajalec odpraviti

napako**Primer

kritična Takoj, ko je mogoče - začne reševati takoj 4 ure Sistem ne deluje v celoti.

visoka 4 ure 8 ur Sistem deluje deloma, ogrožene so nekatere pomembne funkcionalnosti

pomembna 8 ur 18 ur Sistem deluje deloma, ogrožene so le nekatere manj bistvene funkcionalnosti

nizka 1 delovni dan 2 delovna dneva Lepotne napake

*Odzivni čas - je maksimalni čas, ki preteče od trenutka, ko uporabnik izvajalcu pošlje zahtevek za odpravo napake do trenutka, ko izvajalec na zahtevek odgovori in prične z reševanjem napake.**Čas, v katerem mora izvajalec odpraviti napako - je maksimalni čas od trenutka, ko uporabnik izvajalcu pošlje zahtevek za odpravo napake do trenutka, ko izvajalec odpravi napako.

Redno vzdrževanje poteka do izteka okvirnega sporazuma (predvidoma 3 leta).

Problem opredeljujemo kot težavo oziroma določeno nezaželeno stanje, ki ni skladno s pričakovanji in ga je potrebno odpraviti oziroma rešiti, na ta način, da se stanje normalizira.

Uporabniško vprašanje predstavlja problem, ki je logična celota, katerega se rešuje praviloma daljinsko (npr. telefonski klic, e-mail oziroma z namensko spletno aplikacijo za podporo uporabnikom) in se za njegovo rešitev porabi do 15 minut.

Motnja predstavlja problem, ki je logična celota, katerega se rešuje praviloma daljinsko (npr. telefonski klic, e-mail oziroma z namensko spletno aplikacijo za podporo uporabnikom) in se za njegovo rešitev porabi do 30 minut.

8.2 Dopolnilno vzdrževanje

Dopolnilno vzdrževanje sistema obsega:

vzdrževalne aktivnosti, ki presegajo predvideni mesečni znesek vzdrževalnine za osnovno vzdrževanje in predvideno število uporabniških vprašanj oziroma motenj oziroma posegov;

odprava manjših težav oz. napak pri delovanju informacijskega sistema, ki so nastale kot posledica ravnanj na strani naročnika;

kontrolni nadzor nad delovanjem v dogovoru z naročnikom oziroma uporabniki; izboljševanje in dodajanje funkcionalnosti ter popravljanje nebistvenih napak na zahtevo naročnika oziroma uporabnikov;

sodelovanje pri analizi in pri pripravi specifikacij uporabniških zahtev za dodajanje novih in izboljšanje obstoječih funkcionalnosti programske opreme;

izboljševanje lastnosti delovanja, uporabnosti in dograjevanje novih funkcionalnosti ter odprava nebistvenih podatkov na podlagi predlogov naročnika, uporabnikov ali izvajalca in s strani naročnika potrjenih specifikacij;

prilagajanje programske opreme glede na spremembe sistemskega okolja in operacijskega sistema v okviru možnosti in zagotovil proizvajalcev oz. principalov;

uporabniško pomoč in svetovanje na lokaciji v dogovoru z naročnikom oziroma uporabniki; dokumentiranje storitev dopolnilnega vzdrževanja.

Dopolnilno vzdrževanje se izvede po pisnem naročilu naročnika, ki je lahko tudi elektronska pošta, če izvajalec izvede tudi funkcionalnost brez naročila naročnika, nosi stroške izvedbe sam.

Dopolnilno vzdrževanje poteka do izteka pogodbe (predvidoma 4 leta).

8.3 Tehnična pomoč

V informacijskem sistemu so vsem uporabnikom na voljo uporabniška navodila, ki uporabniku opišejo vse funkcionalnosti sistema in so prilagojena vsem vrstam uporabnikov.

35

9. NADGRADNJE INFORMACIJSKEGA SISTEMA

V teku implementacije ali v času produkcijskega delovanja informacijskega sistema za upravljanje dokumentarnega gradiva centrov za socialno delo lahko pride do večjih sprememb oz. dodatnih funkcionalnih zahtev.

Ponudbena cena za nabavo, pilotno implementacijo, dograditev in implementacijo informacijskega sistema ne vključuje nadgradenj iz te točke. Cene posameznih nadgradenj bodo predmet povpraševanj na podlagi sklenjenega okvirnega sporazuma.

Predvidena nadgradnja:

9.1 Povezava z informacijskim sistemom eCSD

Ker ni zanesljivo, da bo informacijski sistem eCSD že vzpostavljen ob času implementacije informacijskega sistema, bo treba povezavo z njim izvesti kasneje. Finančno pa mora biti že vključena v ponudbi.

10. TERMINSKI PLAN

Izvajalec mora v fazi razvoja glede na terminski plan pri posameznih aktivnostih sodelovati z naročnikom in na kontrolnih točkah (KT) predložiti naslednjo dokumentacijo:

Oznaka Aktivnost Dokument Število dniKT0 Začetek 10

Vzpostavitveni dokument KT0-VDPKT1 Analiza 60

Vzpostavitveni dokument - potrjen KT1-VDPFunkcionalne specifikacije-podrobne KT1-FS

KT2 Pilotni projekt 60Namestitev sistema v testno okolje naročnika

KT2-NS

Navodila za uporabnike v glavni pisarni KT2-NGPNavodila za referente KT2-NRNavodila za administratorje KT2-NAPoročilo o usposobitvi pilotnih uporabnikov

KT2-UPU

Načrt testiranja KT2-NTPoročilo o testiranju KT2-PTNačrt migracije KT2-NMFunkcionalne specifikacije-dopolnjene na podlagi rezultatov testiranja

KT2-FS

KT3 Testiranje sistema 30 (start 1. 9. 2011)Namestitev popravkov KT3-NPNačrt testiranja popravkov KT3-NTPoročilo o testiranju popravkov KT3-TPFunkcionalne specifikacije - dokončne KT3-FS

KT4 Delni prevzem sistema 1. 10. 2011Izvorna koda (spletni servisi) KT4-SCDokončna navodila za namestitev programske opreme

KT4-NN

Dokončna navodila za uporabo za administratorja

KT4-NA

Dokončna navodila za uporabo za uporabnike v glavni pisarni

KT4-NGP

Dokončna navodila za uporabo za referente

KT4-NR

Povezava z IS CSD in CRP KT4-CSDDelni prevzemni zapisnik KT4-DPZ

KT5 Usposobitev uporabnikov 120 dni (start 1. 9. 2011)

Načrt usposabljanja – potrjen s strani naročnika

KT5-NU

Poročilo o usposabljanju uslužbencev glavnih pisarn

KT5-PUGP

Poročilo o usposabljanju referentov KT5-PURPoročilo o usposabljanju administratorjev

KT5-PUA

KT6 Prevzem sistema 1. 2. 2012Prevzemni zapisniki o uvozu (62) KT6-PPZU

37

Prevzemni zapisnik KT6-PZ

Rok T za izvedbo posameznih aktivnosti prične teči z dnem obojestranskega podpisa pogodbe, dnevi so v preglednici mišljeni kot koledarski dnevi.

38