Izrada informacionog sistema za digitalizaciju/automatizaciju poslovnih procesa sa modulom za razmjenu i integraciju podataka;

Naziv: MINISTARSTVO JAVNE UPRAVE

PIB: 11070043

E-mail: kabinet@mju.gov.me

Telefon: 020/241-412

Fax: 020/241-790

Internet adresa: https://www.gov.me/mju

Adresa: Rimski trg 45

Grad: Podgorica

Poštanski broj: 81000

-------------------------------------------------------------

OSNOVNI PODACI

Opis predmeta javne nabavke

Izrada informacionog sistema za digitalizaciju/automatizaciju poslovnih procesa sa modulom za razmjenu i integraciju podataka;

TEHNIČKA SPECIFIKACIJA PREDMETA NABAVKE

1. Izrada i održavanje informacionog sistema za digitalizaciju/automatizaciju poslovnih procesa sa modulom za razmjenu i integraciju podataka | Proizvodi i usluge koji su predmet nabavke

Glavni cilj ovog projekta je izrada informacionog sistema za digitalizaciju/automatizaciju poslovnih procesa sa modulom za razmjenu i integraciju podataka (u daljem tekstu BPM,JSERP). JSERP služi kao glavno čvorište koje omogućava razmjenu podataka između različitih registara i institucija. On ima dvojaku svrhu, kao čvorište za razmjenu podataka za institucije koje već pružaju web usluge, kao i Servisni Bus za razvoj web servisa za institucije koje ne razvijaju sopstvene usluge. Pored ovih funkcionalnosti, JSERP obezbjeđuje sledeće module/funkcionalnosti:

•Meta-registar dostupnih servisa •Katalog web servisa

•Softver i e-register kataloga •Evidencija razmjene podataka

•Semantički standardi za razmjenu podataka. Postojeće rješenje odnosno platforma ima komponente koje su pri kraju životnog ciklusa održavanja i zahtijevaju funkcionalnu i tehnološku nadogradnju. U sledećim poglavljima opisani su glavni zahtjevi, funkcionalni i tehnički, koji treba da se ispune nadograđenim platformama kako bi se ispunili savremeni zahtjevi i standardi. Takođe je od najveće važnosti da sve trenutne usluge i funkcionalnosti moraju biti očuvane i migrirane na novoj i/ili nadograđenoj platformi. Migracija bi trebalo da obezbijedi isti ili viši nivo funkcionalnosti. Migracija neće smanjiti nivo funkcionalnosti postojećih usluga I funkcionalnosti. Funkcionalni zahtjevi novog IS

Nova platforma za razmjenu I integraciju podataka mora da omogući brzo i efikasno povezivanje novih članova sa sistemom JSERP, bezbjedan prenos podataka između članova JSERP i čuvanje evidencija u standardnom i mašinski čitljivom formatu.

Nova platforma za razmjenu I integraciju podataka mora da ispuni sljedeće uslove i omogući sljedeće funkcionalnosti: 1.Obezbjediti standardan bezbjedan kanal za razmjenu podataka, putem standardizovanog protokola za razmjenu poruka, za kriptografsku bezbjednost i razmjenu poruka. Svaki član treba da bude odgovoran za registraciju i povezivanje sa JSERP.

2.Obezbjediti kontrolu detaljnijih prava na pristup podacima, definisanjem djelova ili podsistema informacionog sistema članova JSERP koji se koristi za pružanje ili korišćenje usluge podataka, kako tehnološki tako i organizaciono. Svaki član treba da bude odgovoran za registraciju svojih podsistema i davanje prava pristupa drugim članovima JSERP za njihovu upotrebu. Web korisnički interfejs bi trebalo da postoji koji bi obezbjedio ove vrste funkcionalnosti za sve administratore JSERP i za institucije članice.

3.Obezbijediti standardizovani mehanizam za konzumiranje web servisa za podatke na osnovu certifikata za potvrdu identiteta i potpisivanje. Svakoj instituciji koja želi da koristi uslugu prenosa podataka to treba dozvoliti tako što će u svom zahtjevu obezbijediti sertifikat potvrde identiteta koji je izdao kvalifikovani davalac usluga povjerenja. Provajder treba da bude odgovoran za upravljanje pravima pristupa svojim uslugama, u skladu sa bezbjednosnim principom najmanje privilegije.

4.Sve poruke koje se razmjenjuju putem JSERPa treba obraditi na takav način da se mogu koristiti kao digitalni dokazi, u skladu sa bebezbjedonosnim principima neporecivosti svojstava svake poruke koja se razmijeni. Elektronska identifikacija i usluge povjerenja za elektronske transakcije (EIDAS) - Evropski propisi propisuju vrste elektronskih pečata koji mogu poslužiti kao dokaz da je elektronski dokument izdalo pravno lice, čime se obezbjeđuje bezbjednost porijekla i integriteta dokumenta. Takođe, u vezi sa bezbjednosnim principom neodstupanja, poruke bi trebalo da budu vremenski obelježene od strane autoriteta za vremensko žigovanje, koji sprovodi upotrebu protokola sa vremenskim žigom kako bi se osigurala dugoročna dokazna vrijednost razmjenjenih poruka. Izdate vremenske oznake potvrđuju postojanje poruka u određenom vremenu. Pored toga, sistemske zapise treba periodično rotirati i čuvati u skladu sa propisima o zaštiti podataka (Zakon o zaštiti podataka o ličnosti i Zakon o zaštiti tajnosti podataka). Svi neophodni sertifikati i CA usluga biće obezbjeđeni dobavljaču i nijesu dio ovog tendera. Pretpostavlja se da će sve integracije biti obavljene sa internim CA Ministarstva javne uprave, kao i javnim sertifikovanim CA.

5.Sistemom upravlja Ministarstvo javne uprave, koji hostuje server koji sadrži meta-registar, zajedno sa objavljenim uslugama i informacijama o logičkim lokacijama njihovih servisa. Neophodno je da Ministarstvo javne uprave (MJU) članovima JSERP a kreira listu pouzdanih sertifikacionih organa i bezbjednosnih politika. Pored toga, ovaj centralni server registratora bi trebalo da podržava visoku dostupnost kroz klaster od dva ili više čvorova koji obezbeđuju dodatnu toleranciju kvara i skalabilnost sa stanovišta performansi. Sve poruke koje se razmjenjuju moraju biti šifrovane na takav način da samo dvije institucije koje razmjenjuju podatke mogu da vide prenos podataka, a da druge ne mogu da im pristupe. Minimalni podržani standard šifrovanja trebalo bi da bude AES-128 i SHA-256 kao hashing standard. Algoritmi kao što su 3DES i MD5 koji su zastarjeli, čak i ako su dio sistema, ne bi trebalo da budu konfigurisani I omogućeni.

6.Mašina za usmjeravanje poruka mora biti u mogućnosti da usmjeri zahtjev do odgovarajućeg primaoca. Poruke mogu imati više odredišta ili poticati iz više izvora, u zavisnosti od određenog procesa koji treba izvršiti. Sistem će moći da usmjerava poruke između svih podržanih izvora i odredišta. Sistem mora da podržava usmjeravanje sadržaja gdje se poruka usmjerava na osnovu procjene pravila poslovanja na određenom dijelu poruke. Odluka za usmjeravanje mora da podrži protok informacija iz spoljne komponente za upravljanje poslovnim pravilima.

7.Uključivanje novog člana mora uključivati pokretanje novih usluga u JSERPu i njegovo prilagođavanje, bez potrebe za dodatnim razvojem ili reprogramiranjem postojećih web servisa. Novi član JSERPa mora biti u mogućnosti da lako podesi postojeće ili nove REST ili SOAP web usluge, bez potrebe za dodatnim programiranjem i razvojem sistema evidentiranja. Član će imati jednu pristupnu tačku za sve svoje web usluge. Glavni administrativni server će se koristiti za administraciju - postavljanje svojih web usluga (pružanje) i usluge drugih institucija biće konzumirane iz njega.

8.Izrada novih komponenti sistema JSERP-a meta-registar i administrativni portal JSERPa, optimizacija procedure za povezivanje institucija, administracija korisnika, administracija tehničkih parametara i dokumentacija za dostupne web usluge.

9.Izrada kataloga web usluga (koje pregledaju institucije) treba da pruži pregled svih dostupnih web usluga od strane pojedinačnih institucija (to bi trebalo da uključuje sva imena usluga, kratak opis i kategoriju usluge, npr. Podnošenje novih zahteva za ličnu identifikaciju itd), kao i integracija sa dostupnom tehničkom dokumentacijom i obrascem za pokretanje administrativnih procedura za pristup web servisu. Ovaj katalog treba da ima mogućnosti da izloži svoje usluge putem REST API-ja kako bi ga konzumirao novi portal eUprave i druge komponente u sistemu, kao i drugi sistemi. Ideja ove usluge je da možemo da omogućimo drugim web sajtovima da prikažu listu dostupnih usluga (sve ili samo dio liste) koja je vezana za njihove funkcije.

10.Trenutno postoji samo osnovni monitoring saobraćaja razmjene podataka. Unapređenje monitoring okruženja JSERPa, nadogradnja JSERPa podsistemom kontrolne table, koji će omogućiti praćenje transakcija, statističko i praćenje performansi kroz različite widget-e, tabele i statističke podatke koji se mogu pretraživati i filtrirati po uslugama, instituciji i vremenskom periodu. Ovo poboljšanje treba da obezbjedi da administratori JSERP-a mogu da kreiraju kontrolne table od unaprijed definisanih widget-a izvora podataka koji su ovdje opisani, a koji se odnose na transakciono i statističko praćenje.

11.Upravljanje transakcionom evidencijom treba da omogući šifrovano i vremensko skladištenje evidencija i da ih izloži putem veb servisa na takav način da građanin može da ima uvid u istoriju pristupa institucija njihovim podacima (Broj zahtjeva građana za uvid u sopstvene podatke. Omogućen uvid u posebne sistemske zapise - da se provjeri da li neko pregleda podatke o građanima bez ovlašćenja). Ova funkcionalnost će biti dostupna za pristup u odjeljku Moji podaci na novom portalu eUprave. Administratori sistema ne bi trebalo da mogu da vide sadržaj svake transakcione poruke u detaljima evidencije, već samo opšta svojstva transakcije, kao što su vrijeme i datum, institucije i status poruke. Sva ostala svojstva mogu da vide samo one institucije i pojedinci koji učestvuju u toj transakciji.

12.Sistem mora da podrži integraciju sa centralizovanim sistemima obavještenja treće strane za oba administrativna obavještenja (vrijeme rada sistema, vrijeme pada usluge, različite vrste problema), kao i korisnička obavještenja u vezi sa promjenama u sistemu i transakcionoj aktivnosti ako je to potrebno. Centralizovani sistem obavještavanja bio bi razvijen odvojeno, a ne u okviru razvoja JSERP. 13.Nova platforma za razmjenu podataka zamijeniće postojeću softversku platformu (Apache Service Mix), ali je neophodno obezbijediti prenos (migracije) svih postojećih ruta i interfejsa za razmjenu podataka između državnih organa i usluga iz Apache Service Mixa, bez prekida u svakodnevnom radu.

Ponuđači mogu da ponude platforme koristeći open-source riješenja ili platforme koje zahtjevaju licenciranje. Platforme koje se isporučuju, ako zahtjevaju licenciranje, licence ne mogu biti zasnovane na korisniku, zasnovane na transakcijama ili zasnovane na vremenu i moraju biti uključene u konačnu isporuku. Ponuda mora da sadrži sve licence potrebne za pun rad sistema. Ukoliko za sistem ili pojedinačne komponente ne postoje trajne licence, onda licence za podršku vendora moraju biti uključene za minimalni period od 1 godine od trenutka puštanja u produkciju. Ukoliko se isporučuje open-source rješenje, ono mora imati podršku originalnog proizvođača rješenja i enterprise licence, ukoliko iste postoje. Open-source rješenja takođe moraju imati adekvatan životni vijek i garanciju proizvođača za nadogradnje tokom tog ciklusa. Riješenje mora da poštuje arhitekturu orijentisanu na usluge i/ili arhitekturu mikro usluga da bi se dozvolila razmjena podataka pomoću usluga ili API-ja. Ovakav pristup znači da su koncepti kojima riješenje funkcioniše:

•Usluge (za REST ful pristup odvojenim krajnjim tačkama) kao atomska jedinica za pristup i autorizaciju podataka

•Informacioni sistem (jedne organizacije) kao minimalna jedinica koja se može adresirati.

Preferirati rješenja za razmjenu podataka koja standardizuju upotrebljivu tehnologiju razmjene podataka u minimalni skup standarda (na primjer: organizaciona veza sa riješenjem može da se obavi samo pomoću API-ja sa RESTfull standardom koji su opisani sa OpenAPI v3 standardom) ali istovremeno ne nameću nikakva arhitektonska ili tehnička ograničenja organizaciji o tome koju arhitekturu ili tehnologiju mogu da koriste. Kako svaka tehnologija koja je podržana riješenjem ima životni ciklus i zahtjeva održavanje, što je više tehnologija podržano interno, to su veći očekivani troškovi održavanja i složenost.

Bezbjednost / Integritet

Kako je svrha razmjene podataka da se organizacijama omogući automatizacija njihovih procesa korišćenjem podataka iz drugih organizacija, od suštinskog je značaja da se obezbijedi očuvanje njene autentičnosti i integriteta. Svako buduće rješenje za razmjenu podataka mora da objezbedi mehanizme koji obezbjeđuje integritet krajnjih podataka od polazne do krajnje tačke konzumacije podataka pomoću MJU PKI sistema za vrijeme, potpisivanje poruka i potvrdu identiteta. Funkcije zaštite integriteta moraju da obezbijede zaštitu od neovlašćene razmjenjene podatke i mogućnost provjere i dokazivanja da su podaci o razmjeni bili netaknuti.

Bezbjednost / Povjerljivost

Za implementaciju razmjene podataka sistem mora da obezbijedi zaštitu ličnih i osjetljivih podataka. Zbog toga riješenja moraju da obezbijede snažnu zaštitu povjerljivosti za poslovne podatke koji se razmjenjuju. Mehanizmi zaštite povjerljivosti moraju:

•obezbijediti mehanizme potvrde identiteta kako bi se izbjegao neautorizovan pristup podacima i uslugama. Operator rješenja mora kontrolisati mehanizme potvrde identiteta jer tokeni za potvrdu identiteta i mehanizmi igraju značajnu ulogu u upravljanju ekosistemom razmjene podataka.

•obezbijediti ovlašćenje za pristup podacima i uslugama. Ovlašćenje moraju da kontrolišu odgovarajući vlasnici podataka/usluga da bi se obezbijedilo da kontrola, odgovornost i motivacija vlasnika podataka budu usklađeni sa radom platforme.

•obezbijediti najviši nivo povjerljivosti (po mogućnosti PKI mehanizme šifrovanja) između pošiljaoca i primaoca tokom životnog ciklusa poruke, takođe razmatrajući operatera platforme kao trećeg proizvođača.

Bezbjednost / Dostupnost

Imajući u vidu dugu perspektivu u kojoj je većina državnih organa povezana sa ekosistemom razmjene podataka, od suštinskog je značaja da implementacija rješenja bude za upotrebu velikih razmjera, posebno ako se uzme u obzir da bi u kasnijim fazama značajan dio privatnog sektora učestvovao i koristio riješenje. To zahtijeva da riješenje mora da ima dokazan arhitektonski pristup za minimiziranje gubitka dostupnosti. Riješenje ne smije definisati nijednu tačku neuspjeha u svojoj operativnoj logici. Kada ekosistem sazri i dostigne veći broj učesnika i transakcija, ne smije zahtijevati više infrastrukturnih investicija za rad platforme. Bilo bi neophodno da rješenje ima operativne primjere iz slične veličine zemlje sa dokazanom dostupnošću praćenja zapisa.

Integrator modul

Pored glavnih funkcionalnosti JSERPa opisanih u prethodnim djelovima ove dokumentacije, sistem mora da pruži mogućnost Ministarstvu javne uprave da razvija sopstvene usluge kada je to potrebno. Ovo bi trebalo da bude modul integratora jer dio sistema mora da ispuni slijedeće tehničke zahtjeve:

•Softver za integraciju jezgra (pokretanje integratornih funkcija kao što su preuzimanje informacija, transformacija protokola, mapiranje podataka, orkestracija usluge itd.)

•Potpuna usaglašenost sa JSERP sistemom opisanim iznad u tačkama 1-13

•Razmjena poruka

•Platforma za obradu toka događaja •Brz prenos fajlova, koji bi trebalo da omogući prenos fajlova bez uskog grla sa platforme aplikacije i bez zagušenja koja se kreiraju kroz standardne FTP TCP prenose.

•Sve komponente moraju biti sastavni dio proizvoda, a ne pokrenute kao samostalne i neintegrisane

•Proces toka poruke: Obrada toka poruke obezbijeđena riješenjem mora biti u skladu sa arhitektonskim stilom Cijevi i filteri. Unos u tok može biti bilo koji od podržanih protokola i metode integracije. Izlaz može biti bilo koji od podržanih protokola i metoda integracije. Sve ostale funkcije moraju da omoguće efikasnu transformaciju i obradu poruka, uključujući prilagođeno programiranje •Provjera valjanosti poruke: Mašina za integraciju će moći da provjeri valjanost poruke u odnosu na određenu šemu poruka. •Usmjeravanje poruka

•Transformacija poruke: Modul integracije aplikacija treba da ima funkcionalnost za transformaciju poruka u smislu transportnog protokola i/ili formata podataka Modul za integraciju aplikacija mora da podržava transformaciju bilo šta – prema bilo kome. Očekujemo da će se transformacija protokola koristiti za integrisanje sa različitim interfejsima na sistemima za integraciju i transformaciju podataka koji će se koristiti za mapiranje različitih modela podataka u kanonski model podataka koji će biti definisan na Platformi za integraciju. Takođe, trebalo bi da budu moguće i druge prilagođene transformacije podataka i mapiranje. Važno je imati fleksibilan integracioni sloj kako bi se prevazišlo svako pitanje u integracijama u smislu podržanih interfejsa i protokola

•Kompatibilnost između softvera razvijenog i zasnovanog na različitim tehnologijama, posebno. .Net i Java kompatibilnost mora biti moguća

•Prilagođena obrada poruka, koja programerima može omogućiti da pišu prilagođene djelove koda u svrhu transformacije podataka u okviru poruke, podržavajući Java i .NET programiranje

•Sistem mora da ima funkciju snimi i ponovi za poruke

•Riješenje mora da ima punu sposobnost da izvrši integraciju sa postojećim back-end sistemima, kroz različite protokole i metode pristupa. Ovdje se primarna integracija odnosi na integraciju sa internim CA, drugim sertifikacionim tijelima kao i NSeID rješenjem za autorizaciju i autentifikaciju.

•Sve što se bude identifikovalo u toku Analize trenutnog stanja Izvođač je u obavezi da isto implementira.

•Sistem bi trebalo da podrži izgradnju API-ja pomoću funkcije Open API

•Sistem bi trebalo da ima preuranjene adaptere za više tipova sistema i baza podataka da bi podržao nisku integraciju koda. Sistemski adapteri bi trebalo da omoguće nisku integraciju koda za najmanje slijedeće usluge: izvore datoteka zasnovane na strukturiranim podacima kao što su CSV, Excel datoteke, konektori za mysql, postgreSQL, Oracle DB, MS SQL, Rest services, SOAP web usluge, SAP komponente

•Sistem bi trebalo da podrži praćenje poruka između krajnjih tačaka i zahtjeva sa mogućnošću praćenja svega sa jedinstvene administrativne konzole. Sistem bi trebalo da ima GUI interfejs kroz koji se može kreirati novi tok usluge na slijedeći način (grafikon dat u dijelu Dokumenti - Tenderska dokumentacija):

•Nakon prijavljivanja na backend panel, korisnik mora imati mogućnost da kreira novi tok usluge

•Koristeći alatku za dizajn dijagrama, korisnik mora biti u stanju da definiše sve tokove podataka, izvore podataka, proizvodne postupke i transformacije, korišćenjem jednostavnih definicija prevlačenja i niskog koda

•Za svaki unos podataka korisnik mora biti u mogućnosti da izabere mapiranja podataka koje korisnik želi

•Za svako mapiranje, nakon što je definisano, korisnik mora biti u mogućnosti da izabere transformaciju podataka ako je to potrebno

•Korisnik mora biti u mogućnosti da doda zadatke koji mogu da prizivaju spoljne komande ili usluge napisane na različitim jezicima ili da ima veze sa drugim REST uslugama da bi omogućio dodatne pozive za podatke ili obradu

•Korisnik mora da definiše opcionalne tokove za izlaz podataka ili više putanja za protok podataka

•Korisnik mora biti u mogućnosti da omogući praćenje i praćenje za svaki dio toka usluge

•Na kraju, korisnik mora biti u mogućnosti da definiše tip izlaza podataka i kanala za usmjeravanje, nakon čega bi korisnik mogao da odabere da testira uslugu i da generiše link koji će se koristiti za objavu usluge i endpointa u okviru kataloga usluga JISERP.

U slučaju primjene nove usluge koja je već kreirana u određenoj instituciji, nakon sticanja svih potrebnih tehničkih detalja, glavni administrator JSERPa mora biti u mogućnosti da izvrši slijedeće radnje:

•Kreiranje nove institucije u administrativnom panelu

•Kreiranje proxy servisa za tu instituciju i/ili uslugu

•Definisanje svih detalja krajnje tačke servisa i konfigurisanje parametara potvrde identiteta, autorizacije i praćenja

•Kreiraj izlazne putanje za servis

•Testiranje servisa radi funkcionalnosti

•Objavljivanje servisa u katalogu kao i u samom JSERP sistemu

•Kreiranje stranica koje određuju tehničke standarde za pristup servisu, kao i testiranje unosa podataka

•Kreiranje krajnje probne tačke za servis.

Dodatno, potrebno je kreirati unutar JISERP-a ili kao nezavisni modul aplikaciju koja će se koristiti u slučaju nove institucije koja želi da pristupi registrima/servisima, institucija klijenta (Obrađivač) mora biti u mogućnosti da obavlja slijedeće aktivnosti:

•Registrovanje novog zahtjeva za pristup

•Popunjavanje svih potrebnih detalja za pristupanje

•Izabrati registar/servis kojima treba pristupiti

•Unijeti pravni osnov koji dozvoljava pristup registru/servisu

•Unijeti kriterijume procesa za koje se zahtjeva pristup registru/servisu

•Podnijeti zahtjev za pristup registru/servisu

U okviru iste aplikacije i/ili modula nakon podnošenja zahtjeva, institucija klijenta (Kontrolor) mora biti u mogućnosti da obavlja slijedeće zadatke:

•Provjeravanje podnijetog zahtjeva

•Odobravanje ili odbijanje zahtjev

Nakon što zahtjev bude odobren, Glavni administrator JSERPa verifikuje isto i može da kreira novu instituciju ako je potrebno. Nakon kreiranja institucije, korisnik će kreirati namjenske naloge za tu instituciju i odobriti im pristup usluzi. Pored ovih funkcija, JISERP platforma mora omogućiti da se BPM, portal eUprave i svi ostali dijeljeni sistemi integrišu na adekvatan način sa istim. Aktivnosti na razvoju JSERPa

Ponuđač treba da bude odgovoran za izradu okruženja za razvoj softvera za testiranje i produkciju na strani klijenta (Ministarstvo javne uprave) i mora da obavlja slijedeću vrstu aktivnosti:

•Isporuka nove tehnološke platforme za razmjenu podataka, sa izvornim kodom i tehničkom dokumentacijom

•Prilagođavanje tehnološke platforme zakonodavstvu Crne Gore i potrebama sistema JSERP

•Instalacija i implementacija platforme na centralnoj lokaciji

•Migracija svih postojećih ruta i web usluga iz Apache servisa miksa na novu platformu, uz mogućnost paralelnog rada nove platforme i postojećeg sistema.

•Instalacija i implementacija platforme za 23 članova sistema JSERP (Ministarstvo javne uprave, Ministarstvo rada i socijalnog staranja, Ministarstvo prosvjete, nauke I inovacija, Ministarstvo unutrašnjih poslova, Poreska uprava, Uprava carina, Fond za zdravstveno osiguranje Crne Gore, Ministarstvo finansija, Glavni grad Podgorica, Ministarstvo pravde, Ministarstvo ekonomskog razvoja, Ministarstvo poljoprivrede, šumarstva I vodoprivrede, Ministarstvo odbrane, Agencija za zaštitu životne sredine, MONSTAT - Uprava za statistiku, Fond za penzijsko i invalidsko osiguranje, Uprava za ljudske resurse, Uprava za nekretnine, Uprava za inspekcijske poslove, Investiciono-razvojni fond, Uprava za zaštitu kulturnih dobara, Uprava za vode, Agencija za sprečavanje korupcije)

•Implementacija digitalnih sertifikata za potvrdu identiteta, potpisivanje i formatiranje vremena unutar platforme uz oslanjanje na CA sistem Ministarstva javne uprave

•Poboljšanje administratorskog modula korisnika/uloge, kao i administrativnih tokova posla

•Sistem mora imati komponente za praćenje transakcija i sistemskih zapisa. U zavisnosti od toga neophodno je adekvatno podešavanje ovih komponenti sistema

•Obuka administratora sistema

•Isporuka korisničkih uputstava za:

oCentralnu komponentu sistema (Administrativno tijelo)

oČlanove Sistema (institucije), sa koracima o načinu povezivanja, podesavanja svojih usluga

oKonzumiranje postojećih usluga.

Platforma za upravljanje poslovnim procesima - BPM koja će se koristiti kao platforma za isporuku usluga mora biti razvijena na takav način da je moguće integrisati sa portalom eUprave za dijeljenje informacija i podataka uz analizu integracionih tačaka u toku implementacije, kao i sa JSERP-om, ali može da funkcioniše potpuno nezavisno od obje usluge i može da se integriše u bilo koje drugo potrebno riješenje ili komponentu. BPM riješenje treba da ima predloške poslovnih procesa i sve preduslove za upravni postupak u skladu sa Zakonom o opštem upravnom postupku.

Osnovna funkcionalnost kreiranja procesa u GUI-u treba da funkcioniše na slijedeći način:

•Korisnik treba da bude u mogućnosti da kreira novi proces i definiše svoje osnovne parametre

•Nakon osnovnog kreiranja, korisnik treba da bude u mogućnosti da definiše polazne tačke, procesne događaje, procesne aktivnosti, korisnike koji djeluju u njemu, kao i mrežne prolaze sadržaja koji mogu biti izvedeni iz portala, GSB-a ili bilo kog drugog izvora trećeg proizvođača

•Korisnik treba da bude u mogućnosti da dizajnira osnovne obrasce vezane za svaku aktivnost/zadatak u toku procesa

•Korisnik treba da koristi korisnički interfejs ili nisko kodno riješenje za primjenu osnovnih aktivnosti u svakom dijelu procesnog toka

•Korisnik treba da bude u mogućnosti da kreira snimak procesa i da kreira probno okruženje za njega

•Korisnik treba da bude u mogućnosti da primjeni proces u produkciji bez velike nedostupnosti usluge (maksimalno 2 minuta)

•Korisnik treba da bude u mogućnosti da vidi sve pokrenute instance procesa, faze u kojima se nalazi i generiše izvještaje za svaki kreirani proces

•Korisnik treba da bude u mogućnosti da ponovo pokrene i administrira sve instance procesa tokom izvršavanja.

Za potrebe jednostavnih usluga, preko svog administrativnog panela ili BPM integracije treba da omogući kreiranje jednostavnih obrazaca za zahtjev i odgovor:

•U slučaju da usluga zahtijeva popunjavanje obrasca, izrada obrazaca treba da omogući kreiranje obrasca sa više tipova polja, omogući povezivanje na postojeće šifrarnike, i ukoliko je kreirana integracija, omogući povezivanje polja sa JISERP-om kao izvorom podataka.

•Korisnik treba da može da definiše obrazac u više koraka ili aktivnosti ili da kreira vezane obrasce.

•Korisnik treba da može da bira mogućnost provjere za svako polje: lični identifikacioni broj, broj telefona, poštanski broj, samo numerički, e-mail itd.

•U slučaju da usluga zahtjeva plaćanje administrativnih taksi/naknada, korisnik treba da bude u mogućnosti da kreira obrazac za plaćanje i omogući generisanje zahtjeva za elektronsko plaćanje, tj. direktnu integraciju sa NS-NAT sistemom kako bi se omogućilo plaćanje platnim karticama. U slučaju plaćanja drugim sredstvima, zahtjev za plaćanje treba generisati sa jedinstvenim brojem i to plaćanje treba pratiti i povezati koristeći CSAT komponentu NS-NAT. Da budemo precizniji, čim uplata bude izvršena u banci ili pošti i informacije postanu dostupne u CSAT-u, usluga treba da promjeni svoj status u Plaćen, na osnovu dokaza prikupljenih preko CSAT-a. Ako postoji potreba za plaćanjem više administrativnih taksi/naknada, sistem će omogućiti korisniku da pregleda i obavlja platne operacije na opisan način za svaku posebnu administrativnu taksu/naknadu.

•Omogućiti elektronsko zakazivanje uz uslugu ili posebno

•Institucija nadležna za uslugu treba da ima mogućnost definisanja vrste obavještenja za uslugu

•Definisanje zvaničnih rokova za ispunjenje usluge

•Nakon unošenja svih osnovnih informacija, korisnik treba da bude u mogućnosti da testira uslugu •Nakon testiranja usluge, administrator portala mora da ima način da publikuje poslovni process i dobije link za započinjanje eusluge

•Nakon dobijanja linka, isti treba da bude generisan na način da se može iskoristiti za objavljivanje usluge na portal eUprave.

Nakon objavljivanja usluge, korisnici koji obrađuju zahtjeve za uslugu treba da budu u mogućnosti da izvršavaju slijedeće zadatke:

•Korisnik može da svaki obrazac ili proces zahtjeva da zaustavi i nastavi u bilo kom trenutku

•Ispitati listu trenutnih i stalnih zaduženja povezanih sa svim uslugama za koje se obradjuju

•Korisnik – obrađivač bi trebalo da može da preuzme sve potrebne podatke, izvrši obradu van sistema ukoliko je neophodno može da vrati rezultat obrade ili informaciju o rezultatu nazad u sistem.

•Dobijati obavještenja prije isteka roka za obradu podnešenog zahtjeva

•Komunikacija sa klijentom putem web interfejsa, uvjeriti se da se cijela komunikacija vezana za određeni zahtjev uvijek skladišti na jednom mjestu, uključujući opciju razmjene dokumenata preko priloga u generičkim ili određenim poljima, što može biti zavisna usluga

•Za svaki podneseni zahtjev, sva potrebna dokumentacija je potrebno da se proslijedi eDMS sistemu određene institucije za dalju obradu

•Sistem mora da ima mogućnost kreiranja API poziva ka određenoj instanci procesa ili postupku na način da uz programski kod i dodatne šifre postupka je moguće povući neophodne podatke iz postupka ili upload-ovati podatke u postupak iz eDMS i drugih sistema.

•Promjena statusa zahtjeva za uslugu

•Filtriranje, arhiviranje i provjera sve obrađene dokumentacije

•Objedinjavanje zahtjeva sa drugim zahtjevima

•Potražnja dodatne informacije/dokumentacije u skladu sa Zakonom o upravnom postupku

•Prenijeti zahtjev za uslugu drugom korisniku radi dalje obrade usluga.

Tehnički/funkcionalni zahtjevi BPM platforme su slijedeći:

Riješenje mora da sadrži najmanje slijedeće funkcionalne module za automatizaciju: •Automatizacija upravljanja velikom količinom digitalnog sadržaja (Upravljanje Sadržajem)

•Automatizacija objedinjenog upravljanja poslovnim procesima (Upravljanje tokovima posla) i predmetima klijenata (Upravljanje predmetima)

•Automatizacija upravljanja poslovnim odlukama (Upravljanje odlukama)

•Automatizacija digitalizacije papirne dokumentacije (Document capture)

•Sve funkcionalnosti moraju biti dio istog riješenja jednog dobavljača, licenciranog putem jedne vrste licence koja omogućava proširenje kapaciteta bilo kog modula ili preusmjeravanje korišćenja kupljenog kapaciteta iz jednog modula u drugi tokom korišćenja; dio riješenja van kutije , tj. van ekosistema proizvođača koji se može razviti za potrebe upravljanja sistemom mora biti takav da koristi fabričke komponente za interaciju.

•Riješenje mora da sadrži alate za dizajniranje riješenja za automatizaciju bez kodiranja (bez koda) ili sa niskim nivoom kodiranja koji je potreban (low code), koristeći grafički drag & drop interfejs

•Riješenje mora da sadrži OOTB modul za sveobuhvatnu analitiku automatizacije, zasnovanu na tehnologiji mašinskog učenja, koji mora da prihvati informacije/događaje iz drugih modula za automatizaciju i da ih agregira u poslovne metrike i portale (kontrolne table) namijenjene lakom preispitivanju situacije sa poslovnim procesima unutar preduzeća od strane menadžmenta. Mašinsko učenje mora biti u mogućnosti da preporuči potencijalne oblasti optimizacije poslovnih procesa menadžmentu na osnovu prikupljenih podataka. •Riješenje mora da koristi tehnologije otvorenog mašinskog učenja za laku integraciju sa drugim aplikacijama ministarstva, ali mora da uključi podršku za ovu platformu od strane prodavaca softvera, na isti način kao i za sve ostale module. Funkcije mašinskog učenja moraju da omoguće upotrebu mehanizma kreiranja modela Jupyter Notebooks, jer je ovo univerzalni open-source standard za razvoj ove vrste funkcionalnosti

•Modul dizajna riješenja za automatizaciju procesa mora da sadrži OOTB sa najmanje slijedećim funkcionalnostima, dostupnim kao grafički korisnički interfejs koji se lako koristi (drag & drop):

oKreiranje procesnih aplikacija i usluga pomoću biblioteke elemenata koji se mogu ponovo koristiti

oGrafičko i semantičko modeliranje toka poslovnih odluka za instalaciono stručno iskustvo u automatizovanom sistemu

oKreiranje modela digitalnog sadržaja koji omogućava lako izdvajanje relevantnih informacija iz digitalnih dokumenata

oSaradnički alati za saradnju između programera aplikacija i poslovnih stručnjaka u automatizaciji procesa

oOrganizacija aktivnosti i proizvoda rada u Projektima, sa mogućnošću snimanja snimaka tokom razvoja i unapređenja aplikacije.

•Riješenje mora da sadrži OOTB modul za upravljanje identitetom korisnika, koji mora da omogući minimum SSO (Jedinstveno prijavljivanje) funkcionalnosti između različitih modula aplikacije ili opciju Teams za upravljanje razvojnim timovima i njihov nivo pristupa različitim modulima za automatizaciju

•Riješenje mora da sadrži OOTB portal za navigaciju korisnika, koji obezbjeđuje jednu Web stranicu sa koje korisnik može da pristupi svim aplikacijama procesa, kontrolnim tablama, digitalnom sadržaju, dodatnim komponentama i spoljnim aplikacijama kojima je odobrio pristup. Portal mora da dozvoli paralelni početak različitih procesa aplikacija, brz prelazak sa jedne na drugu promjenom kartica i otvaranjem dodatnih aplikacija sa liste

•Što se tiče digitalnog sadržaja, portal mora minimalno da podržava OOTB: pregleda digitalnog sadržaja u skladištu, sadržaj pretrage teksta, čuvanje dokumenata, folder i sadržaje u lične omiljene lokacije, uređivanje (sa adekvatnim privilegijama), dodavanje i organizovanje dokumenata kreiranjem foldera i preraspodjelom dokumenata na njih, korišćenjem pravila kontrole verzije dokumenta u folderima, kreiranjem timskog prostora za saradnju timskog rada na digitalnom sadržaju

•Riješenje mora da sadrži modul za poslovnu analizu podataka i događaja iz modula automatizacije poslovnih procesa, koji OOTB mora da ima bar slijedeće funkcionalnosti:

oSkladištenje svih relevantnih podataka i događaja, kako iz modula platforme za automatizaciju, tako i iz spoljnih aplikacija, u zajednički ugrađenom Data Lake-u, koji mora biti dio platforme, podržan na isti način kao i drugi moduli riješenja. Data Lake mora biti zasnovan na Hadoop File System (HDFS) velikoj platformi podataka ili sličnoj, kao relevantnom open-source industrijskom standardu, lakom za održavanje i nadogradnju od strane korisnika

oRiješenje mora da sadrži modul za obradu događaja putem mehanizma čekanja u redu čekanja, zasnovanog na open-source Kafka tehnologiji ili slično, kao relevantni open-source standard u industriji, lak za održavanje i nadogradnju od strane korisnika

oRiješenje mora da sadrži modul za obradu evidencije teksta i fleksibilnu kontrolnu tablu, zasnovanu na open-source tehnologijama Kibana i Elastic Search ili slično, kao relevantni open-source standardi u industriji, jednostavni za održavanje i nadogradnju od strane korisnika

oRiješenje mora da omogući upotrebu Jupyter Notebooks-a ili slično, kao relevantan open-source standard u industriji, jednostavan za održavanje i nadogradnju od strane korisnika, kako bi se kreirao model Mašinskog učenja na osnovu podataka iz Data Lakea; oRiješenje mora biti isporučeno sa primjerima Jupyter Notebooks ili simipalr minimum: integracija sa modulom za automatizaciju poslovnih odluka i modulom za automatizaciju poslovnih procesa.

•Sve tehnologije i moduli koji se koriste moraju biti pokriveni podrškom proizvođača softvera, sa jednom tačkom kontakta za evidentiranje i rješavanje problema. Za sve platforme koje se implementiraju i/ili koriste, autorizacije proizvođača softvera moraju biti obezbijeđene.

•Modul za automatizovano izvršavanje poslovnih odluka mora biti sastavni dio riješenja i OOTB mora da obezbijedi slijedeće funkcionalnosti:

oMogućnost kreiranja poslovnih pravila/stabala odluka na jednostavan, ne-programski način, korišćenjem grafičkih interfejs alata, tabela odluka i/ili pseudo-jezičkih definicija u okviru grafičkog dizajnera aplikacija za automatizaciju

oUključena je CI/CD automatizacija za build & deploy executive okruženje za automatizaciju poslovnih pravila, sa ugrađenom integracijom sa drugim modulima (prvenstveno procesne aplikacije), kao i mogućnost upita poslovnih pravila iz spoljnih Web i mobilnih aplikacija putem REST API-ja

oMogućnost povezivanja (bez dodatnog programiranja i prilagođavanja) sa modulom mašinskog učenja radi poboljšanja fiksnih poslovnih pravila po iskustvu zaposlenih i preporukama prediktivnog modela mašinskog učenja na osnovu prethodnih odluka u sličnim situacijama

oFormiranje i obogaćivanje poslovnog riječnika pravila poslovanja na pseudo-jeziku novim/domaćim terminima kako bi se olakšalo uvođenje i održavanje poslovnih pravila od strane zaposlenih.

•Riješenje mora da sadrži OOTB modul za interno numerisanje, kontrolu i reviziju (Elektronski zapisi), koji mora imati najmanje slijedeće funkcionalnosti:

oZaštićena hijerarhijska baza podataka bezbjednih metapodataka svoje elektronske i fizičke dokumentacije relevantne za obradu poslovnih procesa i/ili stavki klijenata i druge operacije vezane za prikupljanje, upravljanje, skladištenje i skladištenje digitalnih ili fizičkih dokumenata u preduzeću

oKreiranje pravila za skladištenje i uništavanje dokumentacije

oPokretanje procesa arhiviranja ili uništavanja dokumentacije zasnovane na internoj politici

oKontrola prava pristupa dokumentima

Pretraga dokumentacije po datim kriterijumima

oUklanjanje dokumentacije u skladu sa politikom preduzeća.

•Riješenje mora da sadrži OOTB modul za automatizaciju svakodnevnih jednostavnih procesnih zadataka bez programiranja (bez šifre), koji mora imati bar slijedeće funkcionalnosti:

oOsmisljen alat za kreiranje i izvršavanje automatizacije čestih procesnih aktivnosti (npr. slanje odluke o odobrenju/potpisu, dodeljivanje timu ljudi zadatak za rad na predmetu, prikupljanje relevantnih podataka predmeta putem obrasca ili kontrolne liste itd.) lako, bez potrebe za programiranjem, isključivo korišćenjem grafičkih interfejsa. o OOTB alatka mora da pokrije najmanje slijedeće tipove procesa: obrasce, kontrolne liste, odobrenja

oProcesima mora biti moguće dodati dokumente/obrasce

oPortal za korisnike mora biti uključen u aktivnosti koje su im dodjeljene ili status tekućeg procesa, kao i detalji stavki korisnika (za autora procesa i/ili zaposlene za dozvolu za prikazivanje) prikazuju na jednostavan način.

•Riješenje mora da sadrži OOTB modul za kreiranje aplikacija za automatizaciju složenih poslovnih procesa sa minimalnom potrebom za programiranjem (low code), koji mora imati bar slijedeće funkcionalnosti:

oAlatka za dizajniranje i izvršavanje procesnih aplikacija, u kojoj je moguće kreirati i izmijeniti najmanje slijedeće tipove artefakata: aplikacije procesa, predloške za procesne aplikacije i biblioteku elemenata aplikacije (toolkits)

oAlatka za reprodukciju koja omogućava pregled / simulaciju procesne aplikacije tokom razvoja, bez njene primjene u proizvodnju

oVrijeme izvršavanja aplikacije za izvršavanje i upravljanje aplikacijama za automatizaciju poslovnih procesa, nakon njihovog raspoređivanja u proizvodnom okruženju.

•Riješenje mora da sadrži OOTB modul za automatsku analizu i klasifikaciju sadržaja digitalne dokumentacije, koji mora da podržava najmanje slijedeće funkcionalnosti:

oAutomatska klasifikacija dokumentacije formiranjem ontološkog meta opisa dokumenta zasnovanog na sadržaju, naslovima, ključnim terminima i zaglavljima

oMogućnost lakog obogaćivanja klasifikacije (bez programiranja ili prilagođavanja) sa eksternim uslugama za te aktivnosti oIzvoz analitičkih podataka kako u JSON formatu, tako i u PDF ili UTF-8 tekstualnom fajlu, pogodnom za pretragu

oMogućnost korišćenja modula putem REST API interfejsa

oMogućnost pravljenja rezervne kopije, kopiranja ili vraćanja ontoloških podataka u prethodno stanje

oRiješenje mora da sadrži OOTB modul za automatsko prikupljanje i arhiviranje digitalnog sadržaja, sa najmanje slijedećim funkcionalnostima:

oMogućnost prikupljanja, arhiviranja i automatizacije reakcija (npr. pokretanje poslovnog procesa) na e-poruke ili dokumente iz barem slijedećih izvora: MS Exchange server, javni folderi i PST datoteke; SMTP poštanski serveri, Lotus Domino serveri pošte, MS SharePoint, dokumenti u NTFS, DFS ili Novell sistemima datoteka, SAP sistemski dokumenti.

oAutomatsko ili interaktivno (na zahtjev korisnika) arhiviranje sadržaja na unaprijed definisanu lokaciju spoljne arhive

oImplementacija smjernica za životni ciklus dokumenta

oModul mora da podržava pristup funkcijama putem REST API interfejsa za integraciju sa spoljnim aplikacijama i drugim modulima riješenja.

•Riješenje mora da sadrži OOTB modul za upravljanje digitalnim sadržajem (Upravljanje sadržajem), koji mora imati najmanje slijedeće funkcionalnosti:

oUpravljanje poslovnim objektima koji predstavljaju model podataka koji uključuje digitalni sadržaj / dokument, sve relevantne metapodatke, kao i podatke relevantne za kontekst poslovnog procesa u kojem se dokument koristi

oUpravljanje događajima / događajima vezanim za životni ciklus dokumenta, i integracija ovih događaja sa drugim modulima platforme procesa

oUpravljanje cijelim životnim ciklusom dokumenta

oKreiranje verzija i upravljanje promjenama u dokumentima

oKategorizacija dokumenata i njihova obrada u grupama (masovna obrada)

oUlazni obrasci i predlošci dokumenata

oAutomatsko popunjavanje obrazaca i izrada završnih dokumenata (npr. riješenja itd.)

oUvoz i izvoz podataka iz relevantnih izvora

oKeširanje dokumenata i metapodataka radi bržeg pristupa.

Sve aktuelne poslovne procese koji su dio aktuelnog portala eUPRAVE (euprava.me) treba migrirati na novu platformu. Migracija postojećih zapisa i evidencija u transakcionom formatu nije obavezna ako se ne može izvršiti. Ukoliko to nije moguće, neophodno je prenijeti sumarne statuse transakcija koje su izvršene na starom portalu u okviru svake usluge. Pored ovoga neophodno je kreirati do 10 usluga na centralnom ili lokalnom nivou, sa jednim ili više nivoa odlučivanja koji se mogu koristiti kao šablon za kreiranje novih usluga I formi u skladu sa upravnim postupkom. Ove usluge pored toga što mogu biti dostupne kao pojedinačne, neophodno je da mogu da služe kao šablon na osnovu kojeg se kreiraju nove usluge. Kao npr. možemo imati šablon za uslugu prvostepenog upravnog postupka u okviru jedne institucije koja zahtijeva jedan nivo odlučivanja. Neophodno je adekvatno implementirati ovakvu uslugu, omogućiti njenu šablonizaciju i kreiranje novih usluga na osnovu tog šablona. Pri kreiranju usluge iz šablona neophodno je omogućiti da se jasno definiše nova ulazna forma, devijacije, tj. odstupanja u toku podataka, konekcije na izvore podataka, kao i uloge koje vrše odlučivanje u ključnim koracima te usluge, a koje su definisane unaprijed na osnovu šablona.

Platforma za BPM treba da ima mogućnost integracije sa JSERP platformom, omogućavajući preuzimanja podataka, kao i sa svim drugim dijeljenim sistemima u nadležnosti Ministarstva javne uprave. Garancija i garantni rok Garantni rok mora biti godinu dana od dana puštanja sistema u produkciju, odnosno od potpisivanja primopredajnog zapisnika o isporučenim funkcionalnostima. Garancija mora uključivati otklanjanje svih grešaka koje se uoče prilikom korišćenja sistema. U garantnom periodu neophodno je voditi računa o redovnom ažuriranju softvera, unapređenju u okviru postojećih funkcionalnosti u skladu sa iskustvom korisnika, tehnološkim prilagođavanjima. Izabrani ponuđač ima obavezu da, u toku trajanja ugovora, obezbjedi normalno i potpuno funkcionisanje IS u skladu sa svim funkcionalnim osobinama, otkrivanje i rješavanje eventualnih grešaka i problema u regularnom radu sistema, gdje se detaljno analizira uzrok i preduzimaju aktivnosti na otklanjanju istog, bilo da to podrazumijeva promjene u kodu, novu instalaciju sistema i sve druge neophodne aktivnosti kako bi sistem funkcionisao u punom kapacitetu. Navedeno podrazumijeva: -Obezbjeđivanje rješavanja mogućih problema, koji proizilaze iz regularnog funkcionisanja sistema, na tehničkom i funkcionalnom nivou (24/7); -Hitne intervencije po potrebi naručioca, koje su posljedica neispravnosti u radu softverskog rješenja ili njegovih pojedinih funkcionalnih cjelina (24/7); -Tehnička podrška službenicima naručioca koji su angažovani na poslovima administriranja softverskog rješenja u slučaju problema, a na zahtjev glavnih administratora sistema iz Ministarstva javne uprave. Zahtjev se upućuje dogovorenim kanalima komunikacije; -Odgovaranje na dostavljena pitanja i zahtjeve za konsultacije na dnevnom nivou (Pitanja dostavljaju glavni administratori sistema iz Ministarstva javne uprave dogovorenim kanalima komunikacije); -Održavanje baze podataka (24/7); -Prilagođavanja u skladu sa promjenama relevantne zakonske regulative i promjenama u o

rganizacionoj strukturi, na zahtjev Naručioca, i u najkraćem mogućem roku; -Planiranje i sprovođenje redovnog backup-a svih elemenata Sistema; -Plan za vraćanje sistema u funkciju (system recovery) u slučaju eventualnih grešaka ili ispada Sistema; -Testiranje vraćanja Sistema u funkciju sa vraćanjem bekapovanih podataka, periodično, u skladu sa dogovorom sa naručiocem; -Obavezu ažuriranja svih komponenti sistema na poslednju stabilnu verziju softvera u toku trajanja ugovora o održavanju Sistema; -U slučaju implementacije informacionog sistema sistema na lokaciji za oporavak od havarije, ponuđač je dužan da pruži podršku u projektu replikacije sistema u cilju postizanja kontinuiteta poslovanja, na hardverskoj infrastrukturi koju obezbjeđuje Ministarstvo javne uprave;

-Implementaciju testnog okruženja koje će se koristiti za obuke korisnika I testiranje sprovedenih unapređenja Sistema; -Uklanjanje ranjivosti softverskih platformi (sistemskih i aplikativnih) u cilju postizanja većeg stepena sajber bezbjednosti sistema po potrebi Naručioca. -Nadzor Sistema (monitoring) u cilju pružanja garancije za performanse sistema i preventivno djelovanja (24/7); -Uklanjanje svih potencijalnih rizika u funkcionisanju IS (24/7); -Preporuke za unaprijeđenje rada sistema i dovođenje sistema u regularno stanje u slučaju pronalaženja neregularnosti koje bi mogle prouzrokovati probleme u radu sistema; U slučaju potrebe, kada ne postoji opcija udaljenog pristupa, intervencije na sistemu je potrebno pružiti on site (na lokaciji korisnika). Za ovakve intervencije potrebno je obezbijediti stručna lica izabranog ponuđača. Vrijeme odziva i kategorizacija problema U okviru održavanja incidenti/problemi/greške podliježu sledećoj kategorizaciji i u skladu sa tim odgovarajućim procedurama i rokovima: E-1 Problem” označava problem koji dovodi sistem u alarmantno i kritično stanje, uključujući, ali i ne ograničavajući se na to da Naručilac nije u mogućnosti da koristi sistem i problem dovodi do toga da kritični djelovi jednog ili više glavnih sistema za rad nisu upotrebljivi ili operativni; E-2 Problem” označava otežano stanje u kojem su kritični sistem Naručioca operativni, ali je rad na njima znatno otežan; E-3 Problem” označava ozbiljan problem koji odstupa od specifikacija koje su definisane ugovorom, ali ne utiče na aktivan rad Naručioca i može se privremeno zaobići problem koji stvara; E-4 Problem” predstavlja ne kritičan problem koji se može jednostavno zaobići od strane Naručioca i ne utiče na poslovanje Naručioca ni na kakav način. Procedure i rokovi za odgovor na probleme u okviru usluga održavanja su: E-1 Problem – izabrani ponuđač se obavezuje da će započeti rješavanje problema u roku od jednog (1) sata od trenutka prijave problema i

ukoliko se taj problem ne može riješiti sa udaljene lokacije ili putem telefonske podrške, izabrani ponuđač se obavezuje da pošalje zaposlenog na lice mjesta kako bi pristupili rješavanju problema. Ukoliko se detektuje da problem nije moguće riješiti u toku jednog radnog dana izabrani ponuđač će nastaviti sa rješavanjem problema i izvještavaće Naručioca o progresu rješavanja problema na svaka dva (2) sata. Vrijeme rješavanja je maksimalno 2 dana. Za vrijeme trajanja problema, izabrani ponuđač je dužan da ukoliko je moguće obezbijedi zaobilazno i/ili privremeno rješenje; E-2 Problem - izabrani ponuđač je dužan da se javi Naručiocu na rješavanje problema u roku od jednog (1) sata od trenutka prijave problema i da riješi problem u roku od jednog (1) do pet (5) radnih dana. Ukoliko izabrani ponuđač nije u mogućnosti da riješe problem u roku od (5) pet dana mora dati predlog za riješavanje i ustanoviti novi rok za rješavanje zajedno sa naručiocem. Za vrijeme trajanja problema izabrani ponuđač je dužan da obavijesti Naručioca o progresu rješavanja problema najmanje dva puta dnevno; E-3 Problem – izabrani ponuđač je dužan da se javi Naručiocu za potrebe rješavanja problema u roku od jednog (1) do dva (2) dana i da ustanove tačan problem i definišu termine rješavanja problema. U toku ovog procesa izabrani ponuđač je dužan da obavijesti Naručioca o progresu makar jednom dnevno ukoliko nije drugačije dogovoreno; E-4 Problem – izabrani ponuđač je dužan da se javi Naručiocu na rješavanje problema u roku od jednog (1) do dva (2) dana i da ustanove tačan problem i definišu termine rješavanja problema, a koji ne mogu biti duži od deset (10) dana. Očekivani rezultati i isporuka

Implementacija projekta biće redovno praćena, a izveštaji o implementaciji će se redovno dijeliti sa Naručiocem. Pored radnih platformi, tokom svake faze isporučeni materijali treba da obuhvataju:

•Matrica logičkih okvira projekta - Ponuđač treba dati detaljan opis metodologije koja će biti korišćena i plan rada za izvođenje projekta sa planom aktivnosti (poslova) sa opisima pripadajućih faza i pojedinačnih aktivnosti, koji uključuje sve učesnike, vremenski raspored, itd.

•Izvorni kod za aplikacije - Nakon roka izvršenja Ugovora naručilac stiče sva prava iskorišćavanja softverskog rješenja u skladu sa ovom specifikacijom. Svi planovi, specifikacije, projekti, izvještaji, ostali dokumenti i softver postaju vlasništvo Naručioca.

•Tehnička dokumentacija

•Analitički izvještaji

•Arhitektonske specifikacije

•Testiranje softverskog rješenja - Ponuđač mora da definiše plan testiranja softvera i da predloži testne slučajeve koji su sastavni dio metodologije i plana rada. Plan treba da predloži metodologiju koja će se primijeniti, metode testiranja koje će se sprovesti, učesnike, rezultate istog i postupak verifikacije testiranja. Potrebno je obezbijediti testiranje svih funkcionalnosti aplikativnog rješenja, kako administrativni modul tako i softversku komponentu. Za potrebe testiranja treba obezbijediti korisničke obrasce za testiranje gdje je na kraju testiranja po jednom obrascu cilj imati potpisan obrazac od obje strane, što će na samom kraju predstavljati sastavni dio Zapisnika o testiranju.

•Rezervni i planovi za oporavak od katastrofe

•Obuku Naručioca za korišćenje i administraciju sistema •Sve sistemske komponente moraju biti kompatibilne i instalirane na postojećoj VMware ESXi platformi i konfigurisane na način da podrže visoku dostupnost

•Sva komunikacija I isporučena dokumentacija mora biti na crnogorskom jeziku. Projektni zahtjevi Ponuđač u ponudi treba da predloži detaljan opis metodologije koja će biti korišćena i plan rada za izvođenje projekta sa planom aktivnosti (poslova) sa opisima pripadajućih faza i pojedinačnih aktivnosti, koji uključuje sve učesnike, vremenski raspored, itd.

Izabrani ponuđač će nakon analize zahtjeva i postojećeg okruženja predložiti Plan projekta, koji će usaglasiti sa projektnim timom naručioca.

Izabrani ponuđač mora imenovati vođu projekta koji će sa njegove strane biti zadužen za koordinaciju i upravljanje projektom - planiranje vremena potrebnog za pojedine faze projekta, upravljanje kvalitetom projekta, upravljanje rizicima i promjenama. Sve aktivnosti rukovodilac projekta sa strane izabranog ponuđača mora usaglasiti sa projektnim timom sa strane naručioca, vodeći računa o budžetu i vremenu predviđenom za realizaciju projekta. O svim aktivnostima vođa projekta sačinjava i dostavlja naručiocu izvještaje u pisanoj formi.

Dinamika realizacije projekta, odnosno izrade i implementacije IS, je podijeljena u faze: -I faza Licence: nabavka I isporuka svih trajnih licenci koje su neophodne za funcionisanje informacionog sistema za digitalizaciju/automatizaciju poslovnih procesa sa modulom za razmjenu i integraciju podataka.

-II faza BPM: instalacija, konfiguracija i postavka sistema za rad BPM platforme I migracija postojećih servisa, kao i implementacija novih eservisa na BPM platformi.

-II faza JSERP: instalacija, konfiguracija i postavka sistema za rad I migracija postojećih ruta.

Naručilac zadržava pravo da, u slučaju da izrada softverskog rješenja ne zadovoljava kriterijume postavljene tehničkom specifikacijom u bilo kojoj fazi izrade, raskine Ugovor sa Izabranim ponuđačem bez obaveze finansijske nadoknade. | 1 kom

Vrsta predmeta: Usluge

CPV: 72000000 - IT usluge: konsalting, izrada softvera, Internet i podrška

Vrsta postupka: Otvoreni postupak

Službenik za javne nabavke: Dijana Džaković

Kontakt: 068634330

Datum objave: 2024-05-15 16:25:00

Napomena

-------------------------------------------------------------

Procijenjena vrijednost nabavke: 495867.77 EUR

-------------------------------------------------------------

ROKOVI

Početak podnošenja: 15.05.2024 16:25

Kraj podnošenja: 17.06.2024 10:00

Datum otvaranja: 17.06.2024 10:00

Rok za donošenje odluke: 16.08.2024 15:00