Uvođenje informacionog sistema (ERP) za finansijsko, robno i materijalno knjigovodstvo sa naprednim izveštajno-analitičkim modulom

TEHNICKA SPECIFIKACIJA_JN 0109-26.docx TEHNIČKA SPECIFIKACIJA PREDMETA JAVNE NABAVKE 1. OPŠTI ZAHTEVI ERP SISTEMA ERP sistem Nacionalne službe za zapošljavanje (u daljem tekstu: NSZ) treba da predstavlja jedinstven, integrisan i modularno organizovan informacioni sistem koji omogućava vođenje, obradu, kontrolu i izveštavanje o podacima iz različitih poslovnih oblasti NSZ. ERP licence treba da budu obezbeđene za neograničen broj korisnika u okviru NSZ. Sistem treba da obezbedi jedinstvenu bazu podataka i integrisano funkcionisanje svih realizovanih modula, uz primenu principa: „Jedan podatak – jedno mesto unosa – korišćenje kroz ceo sistem – kontrolisana prava pristupa i izmene.“ ERP sistem treba da bude projektovan tako da: omogući realizaciju više funkcionalnih modula u okviru jedinstvenog sistema; obezbedi jedinstvenu bazu podataka; omogući zajedničko korišćenje podataka između modula; spreči nepotrebno višestruko unošenje istih podataka; obezbedi jedinstvene šifarnike i zajedničke registre; omogući automatski prenos podataka između funkcionalnih modula; omogući integraciju sa drugim informacionim sistemima; omogući proširivanje sistema novim modulima i funkcionalnostima; podrži povećanje broja korisnika, organizacionih jedinica i količine podataka bez suštinske izmene osnovne arhitekture sistema. Svi moduli treba da budu međusobno integrisani tako da se podaci uneti u jednom delu sistema mogu, u skladu sa dodeljenim pravima pristupa, koristiti u drugim poslovnim procesima. 2. KORISNICI, ULOGE I PRAVA PRISTUPA Sistem treba da obezbedi upravljanje korisnicima, korisničkim ulogama i pravima pristupa. Prava pristupa treba da se mogu definisati najmanje na sledećim nivoima: modul; funkcionalnost; vrsta operacije; organizaciona jedinica; nivo podataka; pregled, unos, izmena i brisanje/deaktivacija podataka; kreiranje, izmena i potvrda dokumenata; izvršavanje poslovnih operacija; pristup izveštajima i analitikama. Sistem treba da omogući definisanje različitih korisničkih uloga, pri čemu jedan korisnik može imati jednu ili više uloga. Potrebno je obezbediti najmanje sledeće kategorije pristupa: ograničeni pristup; prošireni pristup; potpuni pristup u okviru dodeljenih ovlašćenja. Posebno treba omogućiti razdvajanje prava za pregled podataka od prava za njihov unos i izmenu. Prava pristupa treba da budu podesiva bez izmene programskog koda sistema. 3. ORGANIZACIONA STRUKTURA I PRISTUP PODACIMA ERP sistem treba da podrži organizacionu strukturu NSZ koja najmanje obuhvata: Direkciju; filijale; druge organizacione jedinice, ukoliko se ukaže potreba. Svi relevantni poslovni podaci treba da budu povezani sa organizacionom jedinicom kojoj pripadaju ili u kojoj su nastali. Sistem treba da obezbedi: pristup korisnika podacima sopstvene organizacione jedinice; pristup korisnika Direkcije podacima svih organizacionih jedinica, u skladu sa dodeljenim pravima; mogućnost definisanja posebnih prava za pojedine organizacione jedinice; mogućnost centralizovanog izveštavanja; identifikaciju organizacione jedinice u kojoj je podatak ili poslovni događaj nastao. Za svaki relevantan dokument, transakciju, obavezu, uplatu i drugo poslovno dešavanje treba da bude moguće utvrditi njihovo poreklo, odnosno organizacionu jedinicu koja je podatak kreirala ili sa kojom je povezan. 4. JEDINSTVENA BAZA PODATAKA, ŠIFARNICI I ZAJEDNIČKI REGISTRI ERP sistem treba da koristi jedinstvenu bazu podataka za sve realizovane module. Podaci koji imaju zajedničko značenje za više poslovnih procesa treba da se vode na jednom mestu i koriste u svim modulima u kojima su potrebni. Sistem treba da obezbedi jedinstvene šifarnike, uz mogućnost njihovog centralizovanog održavanja. Zajednički šifarnici i registri treba da budu dostupni svim modulima kojima su potrebni, u skladu sa pravima pristupa korisnika. 5. INTEGRACIJA SA DRUGIM INFORMACIONIM SISTEMIMA ERP sistem treba da bude otvoren za integraciju sa drugim informacionim sistemima NSZ i spoljnim sistemima. Potrebno je obezbediti standardizovane mehanizme razmene podataka, najmanje putem WEB servisa i API interfejsa. Integracija treba da obuhvati, između ostalog: kadrovski informacioni sistem; JIS; IRIS; EPP; SEF; druge postojeće informacione sisteme NSZ; buduće informacione sisteme. Integracije treba da omoguće automatski prenos podataka bez potrebe za ponovnim ručnim unosom istih podataka. Za svaku integraciju potrebno je obezbediti kontrolu uspešnosti prenosa i evidenciju grešaka. 6. OPŠTI ZAHTEVI ZA RAD SA PODACIMA Sistem treba da omogući jednostavan i efikasan rad sa podacima u svim modulima. Potrebno je obezbediti: filtriranje po jednom ili više polja; sortiranje; pretragu; prikaz detaljnih i zbirnih podataka; analitičke preglede; izvoz podataka; štampu, gde je primenljivo. Pretraga i filtriranje treba da budu dostupni bez potrebe za poznavanjem programskog jezika ili SQL upita. 7. IZVEŠTAVANJE I BI ERP sistem treba da obezbedi integrisano izveštavanje nad podacima svih modula. Izveštaje treba da bude moguće izvoziti najmanje u: Word; Excel; PDF. Sistem treba da omogući kreiranje različitih analitičkih i sumarnih pregleda. Potrebno je obezbediti otvorenost sistema za integraciju sa BI alatima, pri čemu ovlašćenim korisnicima treba omogućiti direktan pristup podacima, odnosno kontrolisanim izvorima podataka, radi izrade sopstvenih analiza i izveštaja. Predmet ovog dela tehničke specifikacije je jedinstvena, objedinjena celina rešenja za izveštavanje koja se prvi put nabavlja i uvodi u okviru ERP sistema Nacionalne službe za zapošljavanje (NSZ). Rešenje obuhvata dva međusobno povezana i funkcionalno integrisana dela: standardno izveštavanje i unapređenje izveštavanja primenom modela veštačke inteligencije i mašinskog učenja (AI/ML) – prediktivni i analitički moduli. Oba dela treba da se realizuju kao jedinstvena softverska celina, sa zajedničkim izvorima podataka i jedinstvenom ekonomskom, funkcionalnom i organizacionom klasifikacijom, u skladu sa važećim propisima o budžetskom sistemu Republike Srbije. 7.1. ANALIZA POSTOJEĆEG STANJA I CILJ PROJEKTA NSZ upravlja dvema budžetski najosetljivijim kategorijama rashoda: novčanim naknadama za slučaj nezaposlenosti, čija je isplata zakonska obaveza i direktno zavisi od kretanja broja lica na evidenciji, i sredstvima za aktivne mere zapošljavanja (subvencije za zapošljavanje i samozapošljavanje, javni radovi, obuke, stručna praksa), koja se raspoređuju i realizuju preko mreže filijala i ispostava. Planiranje i izveštavanje u oba toka trenutno se u najvećoj meri oslanjaju na istorijsku ekstrapolaciju i ručnu analizu odstupanja, što ograničava mogućnost blagovremenog uočavanja rizika neusklađenosti realizacije sa planom i produžava vreme pripreme periodičnih izveštaja. Cilj projekta je uvođenje prediktivnih i analitičkih AI/ML modula koji se nadograđuju na postojeći ERP i izveštajni sloj NSZ radi: preciznijeg planiranja potrebnih budžetskih sredstava po ekonomskim kategorijama; ranog otkrivanja rizika od neiskorišćenosti ili prekoračenja budžetskih aproprijacija po programima i organizacionim jedinicama; bržeg otkrivanja neuobičajenih obrazaca trošenja u izvršenju budžeta; skraćenja vremena pripreme periodičnih izveštaja upravi, nadzornom odboru i nadležnom ministarstvu. 7.2. ZAHTEVI ZA STANDARDNO IZVEŠTAVANJE U nastavku su definisani zahtevi za standardno izveštavanje koji čine prvi, osnovni deo objedinjene celine rešenja. Na ovaj deo se nadovezuje drugi deo – unapređenje izveštavanja primenom AI/ML modela, opisano u narednom odeljku. Izveštavanje Softver omogućava izveštavanje u elektronskom ili štampanom obliku po bilo kom definisanom kriterijumu (definisani kriterijum – vrednosti/oznaka vezana za transakcije u sistemu koje se koriste za analizu i statističke izveštaje); konfigurabilnost izveštaja – korisnici mogu sami određivati kriterijume izveštaja; softver ima mogućnost da sve izveštaje izvozi u Word, Excel i PDF format; softver omogućava dobijanje željenog izveštaja automatski u unapred određenom trenutku; softver je otvoren za korišćenje podataka od strane BI alata za analizu i izveštavanje. Finansijsko izveštavanje softver omogućava analiziranje finansijskih računovodstvenih podataka od strane svih hijerarhijskih nivoa u ustanovi u zavisnosti od njihovih ovlašćenja; softver podržava korisničko kreiranje računovodstvenih izveštaja; softver omogućava korisničko definisanje izgleda kolona na finansijskim izveštajima; softver omogućava sumiranje različitih finansijskih računa na bazi tekućih, istorijskih ili budžetskih podataka, tj. on-line poređenje između planskih pozicija i aktuelnih stanja; softver omogućava korisnički pregled podataka u odnosu na različite vremenske periode (dan, nedelja, mesec, kvartal, godina, korisnički definisani obračunski period) i na osnovu njih sumira finansijske podatke; softver omogućava korišćenje računovodstvenih tipova pokazatelja, kao npr. imovina, obaveze, prihod; softver omogućava prodiranje od on-screen informacija iz izveštaja do detaljnog računa i detaljne transakcije i stavki koje je čine, tzv. drill-down; softver omogućava rad na izveštajima dok je on-line sistem aktivan; softver omogućava filtriranje analitičkih pregleda sa kriterijumima koje neka stavka mora da zadovolji. 7.3. UNAPREĐENJE IZVEŠTAVANJA PRIMENOM AI/ML MODELA Drugi deo objedinjene celine rešenja čini unapređenje izveštavanja primenom AI/ML modela. Ovaj deo se sastoji od tri međusobno povezana, ali samostalno primenljiva modula. Svaki modul je definisan kroz cilj, ulazne podatke iz ERP sistema, tačno navedene AI/ML algoritme i očekivane izlazne rezultate. Modul 1 – Predviđanje broja korisnika novčane naknade za nezaposlenost i potrebnih budžetskih sredstava Cilj: preciznija projekcija broja lica koja ostvaruju pravo na novčanu naknadu i visine potrebnih sredstava za naredni period (mesečno, kvartalno, godišnje), sa intervalom poverenja koji podržava scenario planiranje. Ulazni podaci: istorijski mesečni podaci o broju novoprijavljenih i odjavljenih lica sa evidencije nezaposlenih (agregatno, po filijali i sektoru delatnosti); prosečno trajanje korišćenja prava na naknadu i visina naknade po kategorijama korisnika; kalendarske i sezonske varijable (broj radnih dana, praznici); dostupni makroekonomski indikatori (stopa nezaposlenosti po regionu). AI/ML algoritmi: SARIMAX (sezonski ARIMA sa egzogenim varijablama) – statistički bazni model trenda i sezonalnosti; Facebook Prophet / NeuralProphet – modelovanje sezonalnosti, praznika i strukturnih lomova u seriji; gradient boosting regresija (XGBoost / LightGBM / CatBoost) sa inženjeringom obeležja nad egzogenim varijablama, za nelinearne zavisnosti; kvantilna regresija (LightGBM quantile loss) za generisanje optimističnog, očekivanog i pesimističnog scenarija; ansambl (ponderisano kombinovanje / stacking) navedenih modela radi robusnosti finalne prognoze; validacija metodom rolling-origin backtestinga po budžetskim ciklusima (metrike MAPE, WAPE). Izlazni rezultati: periodična prognoza broja korisnika i potrebnih sredstava po ekonomskoj klasifikaciji, sa intervalom poverenja, uključena kao dodatni prilog u postojeći izveštajni obrazac. Modul 2 – Predviđanje i praćenje dinamike realizacije budžeta po programima i filijalama Cilj: rano otkrivanje rizika neiskorišćenosti ili prekoračenja sredstava po programima aktivnih mera zapošljavanja i po organizacionim jedinicama, radi blagovremenog predloga preraspodele ili rebalansa. Ulazni podaci: istorijska mesečna realizacija rashoda po ekonomskoj i organizacionoj klasifikaciji; plan/aproprijacija po programu i filijali; broj korisnika i tip programa (subvencije, javni radovi, obuke, stručna praksa). AI/ML algoritmi: hijerarhijsko vremensko predviđanje sa MinT (Minimum Trace) rekoncilijacijom, kako bi zbir prognoza filijala i programa bio konzistentan sa nivoom centrale; panel gradient boosting model (LightGBM) sa obeležjima po filijali/programu za predviđanje očekivane stope realizacije; modelovanje S-krive (logistička/beta kriva kumulativne realizacije) kao referentni obrazac tipične dinamike trošenja tokom budžetske godine; klasifikacioni model (gradient boosting classifier / logistička regresija) koji za svaku filijalu/program procenjuje verovatnoću neiskorišćenosti ili prekoračenja aproprijacije do kraja perioda. Izlazni rezultati: rang-lista filijala i programa po riziku odstupanja realizacije od plana, sa procenjenim iznosom odstupanja, ažurirana mesečno i uključena u periodični izveštaj upravi i nadzornom odboru. Modul 3 – Detekcija anomalija u izvršenju budžeta Cilj: automatsko otkrivanje neuobičajenih obrazaca trošenja (greške u knjiženju, neplanirana koncentracija rashoda, odstupanje od uobičajenog ponašanja filijale) radi ranog upućivanja na proveru, u podršci internoj kontroli i pripremi za eksternu reviziju. Ulazni podaci: mesečni/nedeljni agregati rashoda po filijali, ekonomskoj klasifikaciji i programu; rezidualne vrednosti (odstupanja stvarnog od predviđenog) iz modela Modula 1 i 2. AI/ML algoritmi: Isolation Forest – nesupervizovana, multivarijantna detekcija anomalija na agregiranim podacima po filijali i ekonomskoj klasifikaciji; statistička kontrola procesa (CUSUM i kontrolne granice zasnovane na Z-skoru) nad rezidualima predikcionih modela, za transparentne i lako objašnjive alarme; autoencoder neuronska mreža – opciona nadogradnja u kasnijoj fazi, za detekciju anomalija na finijem, transakcionom nivou; SHAP (SHapley Additive exPlanations) vrednosti za objašnjenje doprinosa pojedinačnih varijabli oceni anomalije, radi lakšeg prihvatanja nalaza od strane interne kontrole i DRI. Izlazni rezultati: automatizovana lista označenih anomalija sa objašnjenjem verovatnog uzroka i predloženim prioritetom provere, integrisana u postojeći proces interne kontrole. 7.4. TEHNIČKA ARHITEKTURA REŠENJA Rešenje treba da se nadograđuje na postojeći ERP sistem i izveštajni sloj NSZ i ne sme da zahteva izmenu postojeće ekonomske, funkcionalne ni organizacione klasifikacije. Tok podataka treba da se odvija kroz sledeće slojeve: ERP sistem NSZ (izvor podataka) – knjigovodstveni i budžetski podaci, podaci o evidenciji nezaposlenih na agregiranom nivou; sloj za ekstrakciju, transformaciju i učitavanje podataka (ETL), sa periodičnim i automatizovanim preuzimanjem podataka iz ERP-a; analitičko skladište podataka (data warehouse / staging sloj) u okviru infrastrukture NSZ; AI/ML modul za treniranje, validaciju i izvršavanje modela (uz MLOps komponentu za praćenje kvaliteta i periodično ponovno treniranje modela); postojeći izveštajni/BI sloj NSZ, u koji se rezultati modela uključuju kao dodatni prilozi i pokazatelji; krajnji korisnici – rukovodstvo NSZ, nadležno ministarstvo, Uprava za trezor, Državna revizorska institucija. Svi izlazi modela treba da se mapiraju na postojeću ekonomsku, funkcionalnu i organizacionu klasifikaciju budžetskog sistema, tako da rezultati budu direktno uporedivi sa zvaničnim obrascima izveštavanja. Dva osnovna tipa rizika u predmetnom poslu su poslovni rizik i projektni rizik. Zadatke vezane za upravljanje poslovnim rizikom, koji je ovde posebno značajan, jer se postavlja u upotrebu složen poslovni sistem, treba da obavlja stručnjak za obezbeđivanje kvaliteta, sertifikovan za upravljanje IT sistemima visoke složenosti, sa poznavanjem rizika, arhitekture IT sistema i posebno upravljanjem obezbeđenja kvaliteta u primeni IT (Certified in the Governance of Enterprise IT (ISACA) ili ekvivalent). Ovaj sertifikat potvrđuje da lice ima veštine i iskustvo u IT sistemima visoke složenosti, u smislu upravljanja rizicima implementacije, osiguranju kvaliteta i merenju performansi, poslova koje će upravo obavljati u predmetnom projektu. Kako je predmet posla i veštačka inteligencija, kao komponenta sa posebnim aspektom regulacije i rizika s tim u vezi potrebno je da stručnjak poseduje i takve kompetencije u smislu primene veštačke inteligencije po standardu ISO/IEC 42001:2023 ili ekvivalentan. 8. RAD SA UDALJENIH LOKACIJA ERP sistem treba da omogući rad korisnika sa različitih lokacija NSZ, uključujući Direkciju i filijale. Pristup sistemu treba da bude moguć preko savremenih internet veza, uz obezbeđenje: autentifikacije; autorizacije; kontrole pristupa; bezbedne komunikacije; zaštite podataka. 9. USKLAĐENOST SA PROPISIMA ERP sistem treba da omogući rad u skladu sa važećim propisima Republike Srbije koji regulišu: računovodstvo; finansijsko poslovanje; budžetski sistem; javni sektor; poreze; zarade; elektronsko fakturisanje; zaštitu podataka; arhiviranje; druge oblasti koje su relevantne za poslovanje NSZ. Poslovna pravila i obračune treba realizovati tako da se, gde je to moguće, mogu parametarski prilagoditi izmenama propisa bez suštinske izmene osnovne arhitekture sistema. 10. JEDINSTVENI REGISTAR POSLOVNIH PARTNERA/KOMITENATA 10.1. JEDINSTVENI REGISTAR POSLOVNIH PARTNERA/KOMITENATA ERP sistem treba da sadrži jedinstveni registar poslovnih partnera/komitenata koji se koristi na nivou celog ERP sistema. Registar treba da sadrži sve relevantne podatke o poslovnom partneru/komitentu, najmanje: naziv, odnosno ime i prezime; puni i skraćeni naziv, kada je primenljivo; vrstu partnera; pravni status; matični broj; PIB; status u sistemu PDV; šifru i naziv delatnosti, kada je primenljivo; sedište; adresu; adresu za dostavu; mesto; opštinu; državu; poštanski broj; telefon; elektronsku adresu; internet adresu; podatke o kontakt osobama; podatke o bankovnim računima; podatke potrebne za elektronsku razmenu dokumenata; status poslovnog partnera; datume važenja podataka, gde je primenljivo; napomene; druge relevantne podatke. Sistem treba da omogući vođenje više: adresa; kontakt osoba; telefona; elektronskih adresa; bankovnih računa za jednog poslovnog partnera, kada je to potrebno. 10.2. KORIŠĆENJE PODATAKA O POSLOVNIM PARTNERIMA Podaci o poslovnim partnerima treba da budu zajednički za ceo ERP sistem. Korisnici koji imaju odgovarajuća prava treba da mogu da koriste podatke iz registra u svim poslovnim procesima u kojima se poslovni partner pojavljuje. Poslovni partner iz jedinstvenog registra treba da se može koristiti, između ostalog, u: glavnoj knjizi; knjizi primljenih faktura; knjizi izlaznih faktura; izvodu; prinudnoj naplati; evidenciji dobrovoljnog vraćanja duga; nalozima za plaćanje; drugim finansijskim i poslovnim procesima. Prilikom izbora poslovnog partnera u bilo kom modulu treba koristiti podatke iz jedinstvenog registra, bez potrebe za ponovnim unosom osnovnih podataka o istom partneru. 10.3. PRAVA ZA UNOS I AŽURIRANJE PODATAKA Sistem treba da omogući detaljno definisanje prava za: pregled podataka; kreiranje novog poslovnog partnera; izmenu postojećih podataka; deaktivaciju partnera; održavanje pojedinih grupa podataka. Prava za unos i izmenu treba da se dodeljuju u skladu sa podelom poslova i organizacijom rada NSZ. Potrebno je omogućiti da korisnici koji imaju pravo pregleda mogu koristiti podatke poslovnog partnera u poslovnim procesima, bez obaveze da imaju pravo da te podatke menjaju. Brisanje poslovnog partnera treba, po pravilu, biti zamenjeno deaktivacijom, kako bi se očuvala istorija poslovnih dokumenata i transakcija. 10.4. KONTROLA UNOSA Sistem treba da obezbedi kontrolu unosa i izmene podataka u registru poslovnih partnera. Potrebno je obezbediti kontrole za sprečavanje dupliranja partnera, naročito na osnovu identifikacionih podataka kao što su: matični broj; PIB; drugi jedinstveni identifikatori. Za izmene podataka treba da postoji revizioni trag koji sadrži najmanje: korisnika koji je izvršio izmenu; datum i vreme. 10.5. SINHRONIZACIJA POSLOVNIH PARTNERA SA DRUGIM INFORMACIONIM SISTEMIMA ERP sistem treba da omogući sinhronizaciju podataka o poslovnim partnerima/komitentima sa drugim informacionim sistemima NSZ i povezanim informacionim sistemima. Posebno je potrebno obezbediti mogućnost sinhronizacije komitenata sa informacionim sistemima kao što su: JIS; IRIS; drugi postojeći informacioni sistemi NSZ; budući informacioni sistemi sa kojima će biti potrebna razmena podataka. Sinhronizacija treba da omogući, u zavisnosti od konkretne integracije: preuzimanje novih komitenata; prenos novih komitenata iz ERP sistema; ažuriranje postojećih komitenata; prenos izmena podataka; identifikaciju istog komitenta u različitim sistemima; korišćenje jedinstvenih identifikatora; kontrolu duplikata. Način razmene podataka treba da bude zasnovan na standardnim mehanizmima integracije, kao što su WEB servisi, REST API, SOAP, JSON, XML ili drugi odgovarajući mehanizmi koji budu definisani za konkretan sistem. Potrebno je obezbediti mogućnost definisanja izvora podataka i pravila po kojima se određuje koji sistem predstavlja izvor podataka za pojedine atribute komitenta. Potrebno je da informacioni sistem bude projektovan i razvijen na način koji omogućava brzu i jednostavnu integraciju i komunikaciju sa sistemom SPIRI (Sistem za pripremu, izvršenje, računovodstvo i izveštavanje ). 11. MODUL GLAVNE KNJIGE Modul glavne knjige treba da obezbedi jedinstveno vođenje finansijskih podataka na nivou ERP sistema. Potrebno je obezbediti: jedinstveni kontni plan; sintetičke i analitičke račune; korišćenje jedinstvenog registra poslovnih partnera; organizacione i druge analitičke dimenzije; ručno knjiženje; automatsko knjiženje; automatski prenos podataka iz drugih modula; kontrolu knjiženja; analitičke i sumarne preglede. Potrebno je omogućiti automatski prenos u glavnu knjigu podataka iz: knjige primljenih faktura; izlaznih dokumenata; izvoda; obračuna zarada; drugih modula. Svaki knjigovodstveni događaj treba da bude povezan sa izvornim dokumentom. 11.1. Otvaranje i zatvaranje poslovne godine Sistem treba da omogući: automatsko otvaranje nove poslovne godine; prenos početnih stanja; zatvaranje klasa; zatvaranje poslovne godine; kontrolisano ponovno otvaranje godine od strane ovlašćenog korisnika. Otvaranje nove poslovne godine treba da bude moguće izvršiti bez intervencije dobavljača sistema. 11.2. Analitički pregledi Potrebno je omogućiti analizu po: računu; poslovnom partneru; organizacionoj jedinici; periodu; dokumentu; vrsti transakcije; izvornom modulu; drugim analitičkim dimenzijama. Korisniku treba omogućiti prelaz sa zbirnog prikaza na detaljne podatke i uvid u izvorni dokument na osnovu kojeg je izvršeno knjiženje. 12. MODUL KNJIGE PRIMLJENIH FAKTURA Modul treba da obezbedi: prijem i evidenciju primljenih faktura; automatski uvoz faktura iz SEF-a; dopunu podataka; kontrolu; obradu; knjiženje; korišćenje podataka iz jedinstvenog registra poslovnih partnera; povezivanje sa organizacionom jedinicom; povezivanje sa odgovarajućim računom; povezivanje sa analitičkim dimenzijama; praćenje statusa fakture. Obaveze nastale po osnovu primljenih faktura treba automatski prenositi u glavnu knjigu. 13. MODUL IZVODA Modul treba da omogući: učitavanje elektronskih izvoda; automatsku obradu stavki izvoda; identifikaciju uplata; automatsko povezivanje uplata sa odgovarajućim obavezama; automatsko knjiženje; ručno povezivanje kada automatsko povezivanje nije moguće. Uplate treba automatski povezivati, kada postoje odgovarajući podaci, sa: predmetima prinudne naplate; planovima dobrovoljnog vraćanja duga; primljenim fakturama; izlaznim fakturama; drugim obavezama i potraživanjima. 14. MODUL ZA PRINUDNU NAPLATU – DIREKCIJA Modul za prinudnu naplatu koriste ovlašćeni korisnici Direkcije. Modul treba da obezbedi: evidenciju potraživanja koja su predmet prinudne naplate; formiranje i vođenje predmeta; praćenje aktivnosti; praćenje statusa predmeta; evidenciju ukupnog duga; evidenciju plaćenog iznosa; evidenciju preostalog duga; obračun kamate, kada je primenljivo; evidenciju uplata; povezivanje uplata sa predmetima; ažuriranje stanja obaveza; izveštavanje i analitiku. Potrebno je omogućiti definisanje strukture poziva na broj, odnosno referentnog broja, tako da se na osnovu podataka o uplati može automatski identifikovati predmet prinudne naplate. Uplate učitane kroz modul izvoda treba, kada je moguće, automatski povezivati sa odgovarajućim predmetima. Svaka promena stanja predmeta treba da bude evidentirana i povezana sa odgovarajućom finansijskom transakcijom. 15. MODUL ZA EVIDENCIJU DOBROVOLJNOG VRAĆANJA DUGA – FILIJALE Modul treba da omogući filijalama samostalno evidentiranje i praćenje dobrovoljnog vraćanja duga u ratama. Za svaki plan dobrovoljnog vraćanja duga treba omogućiti evidenciju: dužnika; ukupnog iznosa duga; plana otplate; broja rata; iznosa svake rate; datuma dospeća svake rate; kamate, kada je primenljivo; izvršenih uplata; preostalog duga; statusa plana; kašnjenja; prekoračenja rokova. Sistem treba da omogući automatsko povezivanje uplata sa planom na osnovu referentnog broja, kao i ručno povezivanje kada automatska identifikacija nije moguća. Potrebno je omogućiti praćenje: ukupno zaduženog iznosa; ukupno plaćenog iznosa; preostalog duga; dospelih rata; nedospelih rata; neplaćenih rata; kašnjenja; statusa plana. Svaki plan dobrovoljnog vraćanja duga mora biti povezan sa filijalom koja ga je evidentirala. Korisnici filijale treba da imaju pristup podacima svoje filijale, dok ovlašćeni korisnici Direkcije treba da imaju mogućnost uvida u podatke svih filijala. 16. MODUL OBRAČUNA ZARADA I ISPLATA VAN RADNOG ODNOSA Modul treba da obezbedi: obračun zarada; obračun poreza; obračun doprinosa; kontrolu obračuna; obračun za isplatu; podatke za isplatu; obračun naknada; isplate van radnog odnosa; generisanje odgovarajućih finansijskih transakcija. Podaci o zaposlenima treba da se preuzimaju iz kadrovskog informacionog sistema, u skladu sa definisanom integracijom. Obračun treba da bude povezan sa finansijskim modulom tako da se odgovarajuća knjiženja mogu izvršiti automatski. 17. MODUL ZA GENERISANJE NALOGA ZA PLAĆANJE Sistem treba da omogući automatsko generisanje naloga za plaćanje na osnovu: obračuna zarada; obaveza prema dobavljačima; izlaznih dokumenata; drugih odobrenih obaveza; ručno kreiranih naloga, u skladu sa pravima korisnika. Potrebno je omogućiti kontrolu i odobravanje naloga pre slanja na realizaciju. Sistem treba da omogući pripremu i izvoz podataka za EPP. 18. PRENOS SREDSTAVA KA FILIJALAMA ERP sistem treba da omogući upravljanje procesom prenosa sredstava ka filijalama. Potrebno je obezbediti: kreiranje zahteva/naloga; evidenciju iznosa; kontrolu; odobravanje; praćenje statusa; evidenciju realizacije; automatsko generisanje odgovarajućih finansijskih transakcija. 19. AUTOMATIZOVANO POVEZIVANJE UPLATA Jedan od osnovnih zahteva ERP sistema je visok stepen automatizacije povezivanja uplata sa odgovarajućim obavezama. Potrebno je omogućiti definisanje strukture referentnog broja/poziva na broj za različite vrste obaveza, organizacione jedinice i poslovne procese. Na osnovu podataka iz uplate sistem treba, kada je moguće, da automatski identifikuje: organizacionu jedinicu; vrstu obaveze; dužnika/platioca; predmet; plan otplate; fakturu; drugu relevantnu obavezu. Nakon identifikacije sistem treba da: poveže uplatu sa odgovarajućom obavezom; ažurira stanje duga; ažurira plan otplate; kreira odgovarajuće finansijsko knjiženje; omogući praćenje celog lanca od izvoda do knjiženja. Uplate koje nije moguće automatski identifikovati treba staviti na listu za ručnu obradu. 20. SLEDLJIVOST I REVIZIONI TRAG Sistem treba da obezbedi potpun revizioni trag za značajne poslovne i finansijske operacije. Potrebno je evidentirati najmanje: korisnika; datum i vreme; organizacionu jedinicu; vrstu operacije; dokument; promenu podataka; staru i novu vrednost; povezane poslovne događaje; izvorni dokument; generisana knjiženja. Potrebno je omogućiti praćenje poslovnog događaja kroz ceo sistem, od inicijalnog dokumenta ili unosa do finansijskog knjiženja i eventualne naplate. 21. BEZBEDNOST SISTEMA ERP sistem treba da obezbedi odgovarajući nivo informacione bezbednosti. Potrebno je obezbediti: autentifikaciju korisnika; autorizaciju; kontrolu pristupa po ulogama; kontrolu pristupa po organizacionim jedinicama; kontrolu pristupa podacima; bezbednu komunikaciju; evidentiranje aktivnosti korisnika; revizioni trag; zaštitu od neovlašćenog pristupa; zaštitu od neovlašćene izmene podataka. Usklađenost sa zakonskom regulativom i zaštitom podataka rešenje treba da bude usklađeno sa Zakonom o budžetskom sistemu i Pravilnikom o standardnom klasifikacionom okviru i kontnom planu za budžetski sistem – svi izlazi modela treba da budu mapirani na postojeću klasifikaciju, bez uvođenja paralelne strukture; modeli treba da rade isključivo nad agregiranim i anonimizovanim podacima na nivou filijale, programa i sektora, u skladu sa Zakonom o zaštiti podataka o ličnosti, bez obrade podataka o pojedinačnim licima van postojećih ovlašćenja NSZ; infrastruktura za hostovanje podataka i modela treba da se realizuje u okviru infrastrukture pod kontrolom NSZ, u skladu sa bezbednosnim zahtevima za javni sektor; svi modeli treba da budu projektovani tako da budu objašnjivi (interpretabilni) – uz upotrebu SHAP vrednosti i transparentnih statističkih metoda – radi mogućnosti provere od strane interne kontrole i Državne revizorske institucije. 22. PROŠIRIVOST I OTVORENOST SISTEMA ERP sistem treba da bude realizovan kao otvoren i proširiv sistem. Potrebno je omogućiti naknadno: dodavanje novih modula; dodavanje novih funkcionalnosti; proširivanje postojećih modula; dodavanje novih organizacionih jedinica; dodavanje novih korisnika; integraciju sa novim informacionim sistemima; proširivanje šifarnika; proširivanje analitičkih dimenzija. Proširivanje sistema ne treba da zahteva izmenu osnovne arhitekture sistema. 23. CILJEVI I OČEKIVANI EFEKTI INTEGRACIJE Uvođenjem integrisanog ERP sistema treba da se obezbede sledeći efekti: jedinstveno upravljanje podacima; jednokratan unos podataka na mestu nastanka; korišćenje istih podataka kroz više poslovnih procesa; smanjenje višestrukog ručnog unosa; smanjenje mogućnosti greške; skraćenje vremena obrade; automatizacija finansijskih knjiženja; automatizacija obrade izvoda; automatsko povezivanje uplata sa obavezama; centralizovano upravljanje podacima o poslovnim partnerima; eliminisanje višestrukog vođenja istih podataka o komitentima; sinhronizacija komitenata i drugih podataka sa JIS-om, IRIS-om i drugim informacionim sistemima; poboljšanje kontrole podataka; povećanje transparentnosti; potpuna sledljivost poslovnih i finansijskih transakcija; smanjenje administrativnog opterećenja zaposlenih; poboljšanje kvaliteta izveštavanja; omogućavanje centralizovane analitike; stvaranje osnove za dalji razvoj informacionog sistema NSZ. Posebno je potrebno obezbediti da integracija različitih modula i informacionih sistema omogući da se poslovni događaj, odnosno podatak, unese jednom i da se, u skladu sa poslovnim pravilima i pravima pristupa, automatski koristi u svim procesima u kojima je potreban. Na taj način ERP sistem treba da obezbedi integrisan tok podataka od njihovog nastanka, preko poslovne obrade, do finansijskog evidentiranja, izveštavanja i analitike. 24. PLAN I DINAMIKA REALIZACIJE PROJEKTA Realizacija ERP sistema NSZ sprovodi se kroz pet faza, u ukupnom trajanju do 12 meseci od dana zaključenja ugovora (ukupan rok izvršenja ugovora naveden je u Obrascu ponude). Pojedinačni rokovi, odnosno vreme početka i završetka svake pojedinačne faze, definisani su Terminskim planom sa gantogramom aktivnosti. Pregledno, faze realizacije raspoređene su po mesecima na sledeći način: Faza 1 – Analiza; Faza 2 – Korisnički nalozi, sistemski i korisnički šifarnici; Glavna knjiga i poslovni partneri; Faza 3 – Knjiga primljenih faktura; Izvodi i prenos sredstava ka filijalama; Faza 4 – Prinudna naplata – Direkcija; Dobrovoljno vraćanje duga – filijale; Faza 5 – Zarade i isplate van radnog odnosa; Izveštavanje i BI. 24.1. FAZA 1 – ANALIZA Faza obuhvata analizu postojećeg stanja i detaljnu razradu tehničkih i funkcionalnih zahteva ERP sistema, kao osnovu za realizaciju svih narednih faza. U okviru tima ponuđača treba da bude angažovan i stručnjak za analizu poslovnih procesa koji upravlja potrebama korisnika i zahtevima korisnika-faza projektovanja sistema, i funkcionalnim i nefunkcionalnim zahtevima-faza razvoja i implementacije sistema. Izrada detaljnih specifikacija korisničkih potreba i zahteva, sa opisom poslovnih procesa (projektovanje, konsalting uključen u smislu savetovanja korisnika u projektovanju i optimizaciji poslovnih procesa, digitalizaciji i transformaciji procesa), kao i specifikacija softvera sa detaljnim specifikacijama poslovnih procesa i radnih tokova i procedura i dizajn sistema sa implementacijom sistema, odnosno specifikacija za izvođenje informacionog sistema, koji su prethodno prepoznati kao detaljne poslovne potrebe i korisnički zahtevi, u fazi projektovanja, treba da se realizuje u skladu sa metodama usavršenim kroz stečenu sertifikaciju PBA-Certified Professional in Business Analysis (prema metodologiji koju definiše organizacija PMI-Project Management Institute) ili ekvivalent. 24.2. FAZA 2 – KORISNIČKI NALOZI I ŠIFARNICI; GLAVNA KNJIGA I POSLOVNI PARTNERI Faza obuhvata paralelnu realizaciju sledećih celina: korisnički nalozi, uloge i prava pristupa, sistemski i korisnički šifarnici i zajednički registri (poglavlja 2–4); modul glavne knjige i jedinstveni registar poslovnih partnera/komitenata (poglavlja 10–11). 24.3. FAZA 3 – KNJIGA PRIMLJENIH FAKTURA; IZVODI I PRENOS SREDSTAVA KA FILIJALAMA Faza obuhvata paralelnu realizaciju sledećih celina: modul knjige primljenih faktura (poglavlje 12); modul izvoda i prenos sredstava ka filijalama (poglavlja 13 i 18). 24.4. FAZA 4 – PRINUDNA NAPLATA – DIREKCIJA; DOBROVOLJNO VRAĆANJE DUGA – FILIJALE Faza obuhvata paralelnu realizaciju sledećih celina: modul za prinudnu naplatu – Direkcija (poglavlje 14); modul za evidenciju dobrovoljnog vraćanja duga – filijale (poglavlje 15). 24.5. FAZA 5 – ZARADE I ISPLATE VAN RADNOG ODNOSA; IZVEŠTAVANJE I BI Ovo je završna faza projekta i, pored preostala dva funkcionalna modula, obuhvata i aktivnosti potrebne za puštanje sistema u produkcionu upotrebu: modul obračuna zarada i isplata van radnog odnosa (poglavlje 16); izveštavanje i BI, uključujući unapređenje izveštavanja primenom AI/ML modela (poglavlje 7); modul za generisanje naloga za plaćanje i automatizovano povezivanje uplata (poglavlja 17 i 19); sledljivost i revizioni trag, bezbednost sistema (poglavlja 20 i 21); integraciono i funkcionalno testiranje, obuku korisnika i puštanje sistema u produkcionu upotrebu. Garantni rok: Garantni rok za implementirano rešenje mora biti minimalno 12 (dvanaest) meseci od dana potpisivanja Zapisnika o uspešnom puštanju rešenja u produkciju. Mesto isporuke: Nacionalna služba za zapošljavanje, Sektor za informacioni sistem, razvoj i analitiku, Gundulićev venac 23-25, 11000 Beograd. Pod isporukom predmetnog dobra, podrazumeva se i isporuka izvornog koda (source code) predmetnog softverskog rešenja, čime Naručilac postaje vlasnik istog. Kriterijumi za dodelu ugovora.pdf KRITERIJUMI ZA DODELU UGOVORA I OSTALI ZAHTEVI NABAVKE 1 Naručilac: Nacionalna služba za zapošljavanje 103277483 Naziv postupka: Uvođenje informacionog sistema (ERP) za finansijsko, robno i materijalno knjigovodstvo sa naprednim izveštajno-analitičkim modulom Referentni broj: 0109/26 KRITERIJUMI ZA DODELU UGOVORA I OSTALI ZAHTEVI NABAVKE Deo konkursne dokumentacije koji je generisan putem Portala u slučaju kada je naručilac označio opciju automatskog rangiranja ponuda na Portalu javnih nabavki Naziv predmeta / partije: Uvođenje informacionog sistema (ERP) za finansijsko, robno i materijalno knjigovodstvo sa naprednim izveštajno-analitičkim modulom Naručilac je definisao kriterijume za dodelu ugovora na osnovu: Cene i kriterijuma kvaliteta Izabran način rangiranja prihvatljivih ponuda (formula): Automatsko rangiranje Ukupan broj bodova jednak je zbiru bodova za svaki kriterijum. Formule su navedene dole uz svaki kriterijum. Bu = Bc + ∑ k Bk - ukupan broj bodovaBu - broj bodova ceneBc - kriterijumk - broj bodova kriterijumaBk Cena Cena - ponder (numerička vrednost): 90,00 Formula za izračunavanje bodova za kriterijum cene: Maksimalni broj bodova najboljoj ponuđenoj vrednosti, ostale ponuđene vrednosti boduju se u odnosu na najbolju vrednost B = minC C × P - broj bodova ceneB - cena najniže ponudeminC - ponuđena cenaC - vrednost pondera ceneP Kod relativnog modela ocene, broj bodova koji se dobija za kriterijum za pojedinu ponudu zavisi od vrednosti koje su ponudili drugi ponuđači. Najbolja ponuđena vrednost dobija maksimalan broj bodova (numerička ponderisana vrednost). Ostale ponude dobijaju broj bodova u odnosu na najbolju ponuđenu vrednost. Kriterijumi kvaliteta KRITERIJUMI ZA DODELU UGOVORA I OSTALI ZAHTEVI NABAVKE 2 Naziv: Rok isporuke Jedinica mere: dan Ponder (numerička vrednost): 10,00 Vrednost za ovaj kriterijum može da bude samo celi broj. Opis i pojašnjenje kriterijuma i dokazi potrebni za proveru: Privredni subjekt unosi u Obrazac ponude Rok isporuke, odnosno rok u kome je dobavljač dužan da predmetno softversko rešenje i ostale prateće komponente implementira i isporuči, u svemu prema Tehničkoj specifikaciji predmeta javne nabavke, Obrascu strukture cene, Obrascu ponude i Terminskom planu, računajući od dana zaključenja ugovora. Pojedinačni rokovi, odnosno vreme početka i završetka svake pojedinačne faze, kao i projekta u celosti, definiše ponuđač u Terminskom planu sa gantogramom aktivnosti, koji se dostavlja u elektronskom obliku u sklopu ponude. Ponuđač u Obrazac ponude unosi ukupno vreme realizacije, odnosno ukupan rok svih faza (Faza 1 + Faza 2 + Faza 3 + Faza 4 + Faza 5) izražen u danima, računajući od dana zaključenja ugovora. Povoljnija je  veća ponuđena vrednost  manja ponuđena vrednost Formula za izračunavanje bodova za kriterijum: Maksimalni broj bodova najboljoj ponuđenoj vrednosti, ostale ponuđene vrednosti boduju se u odnosu na najbolju vrednost Kod relativnog modela ocene, broj bodova koji se dobija za kriterijum za pojedinu ponudu zavisi od vrednosti koje su ponudili drugi ponuđači. Najbolja ponuđena vrednost dobija maksimalan broj bodova (numerička ponderisana vrednost). Ostale ponude dobijaju broj bodova u odnosu na najbolju ponuđenu vrednost. Ograničenja: Ograničena je minimalna vrednost koju ponuđač može da ponudi Ograničena je maksimalna vrednost koju ponuđač može da ponudi Maksimalna dozvoljena vrednost: 365,00 B = minV V × P - broj bodova kriterijumaB - vrednost pondera kriterijumaP - ponuđena vrednost za kriterijumV - najveća ponuđena vrednost za kriterijumma𝑥V - najmanja ponuđena vrednost za kriterijumminV - maksimalna dozvoljena vrednost za kriterijumVma𝑥 - minimalna dozvoljena vrednost za kriterijumVmin Ostali zahtevi nabavke (koji nisu navedeni iznad kao kriterijumi) Naziv: Rok plaćanja Jedinica mere: dan Opis i pojašnjenje kriterijuma i dokazi potrebni za proveru: Rok plaćanja ponuđač upisuje na odgovarajućem mestu u Obrascu ponude, izražen u danima od dana prijema ispravno sačinjene fakture, zapisnika o primopredaji i/ili nekog drugog dokumenta kojim se dokazuje da je projekat (odnosno implementacija i isporuka predmetnog rešenja sa pratećim komponentama i pružene usluge) u celosti okončan na odgovarajući način. Naručilac će plaćanje vršiti nakon što je projekat (odnosno implementacija i isporuka predmetnog rešenja sa pratećim komponentama i pružene usluge) u celosti okončan na odgovarajući način. KRITERIJUMI ZA DODELU UGOVORA I OSTALI ZAHTEVI NABAVKE 3 Ograničenja: Ograničena je minimalna vrednost koju ponuđač može da ponudi Minimalna dozvoljena vrednost: 15,00 Ograničena je maksimalna vrednost koju ponuđač može da ponudi Maksimalna dozvoljena vrednost: 45,00 Naziv: Garantni rok za isporučeno rešenje Jedinica mere: mesec Ograničenja: Ograničena je minimalna vrednost koju ponuđač može da ponudi Minimalna dozvoljena vrednost: 12,00 Ograničena je maksimalna vrednost koju ponuđač može da ponudi Opis i pojašnjenje kriterijuma i dokazi potrebni za proveru: Ponuđač unosi u obrazac ponude trajanje garantnog roka za isporučeno rešenje, izražen u mesecima, računajući od dana potpisivanja Zapisnika o uspešnom puštanju rešenja u produkciju. Napomena: U ovom delu navedeni su ostali zahtevi nabavke koji nisu prethodno navedeni kao kriterijumi za dodelu ugovora, a ponuđač mora na njih da odgovori prilikom popunjavanja elektronskog obrasca ponude. Ti zahtevi mogu da se odnose na zahteve nabavke, koje naručilac smatra relevantnim za zaključenje ugovora i koji se mogu numerički iskazati Rezervni kriterijumi Kriterijum za dodelu ugovora je najveći ukupan broj pondera. U slučaju da dva ili više ponuđača imaju isti ukupan broj bodova (pondera) povoljnijom će se smatrati ponuda onog ponuđača koji ponudi duži rok plaćanja, koji ne može biti kraći od 15 dana, a koji u skladu sa Zakonom o rokovima izmirenja novčanih obaveza u komercijalnim transakcijama („Službeni glasnik RS“ br. 119/2012, 68/2015, 113/2017, 91/2019, 44/2021, 44/2021 - dr. zakon, 130/2021, 129/2021 - dr. zakon,138/2022 i 109/2025), ne sme biti duži od 45 dana. Primena žreba Ukoliko nakon rangiranja na osnovu kriterijuma za dodelu i rezervnih kriterijuma nije moguće doneti odluku o dodeli ugovora, naručilac će ugovor dodeliti ponuđaču koji bude izvučen putem žreba. Naručilac će obavestiti sve ponuđače koji su podneli ponude o datumu kada će se održati izvlačenje putem žreba. Žrebom će biti obuhvaćene samo one ponude koje su najpovoljnije nakon rangiranja na osnovu kriterijuma za dodelu i rezervnih kriterijuma. Izvlačenje putem žreba naručilac će izvršiti javno, u prisustvu ponuđača, i to tako što će nazive ponuđača ispisati na odvojenim papirima, koji su iste veličine i boje, te će sve te papire staviti u providnu kutiju odakle će prvo izvući samo jedan papir. Ponuđaču čiji naziv bude na izvučenom papiru će biti dodeljen ugovor. Nakon izvlačenja prvog papira naručilac izvlači preostale papire jedan po jedan te shodno redosledu kojim su izvučeni rangira preostale ponuđače. Ponuđačima koji ne prisustvuju ovom postupku, naručilac će dostaviti zapisnik izvlačenja putem žreba.