Увођење информационог система (ЕРП) за финансијско, робно и материјално књиговодство са напредним извештајно-аналитичким модулом

TEHNICKA SPECIFIKACIJA_JN 0109-26.docx ТЕХНИЧКА СПЕЦИФИКАЦИЈА ПРЕДМЕТА ЈАВНЕ НАБАВКЕ 1. ОПШТИ ЗАХТЕВИ ERP СИСТЕМА ERP систем Националне службе за запошљавање (у даљем тексту: НСЗ) треба да представља јединствен, интегрисан и модуларно организован информациони систем који омогућава вођење, обраду, контролу и извештавање о подацима из различитих пословних области НСЗ. ERP лиценце треба да буду обезбеђене за неограничен број корисника у оквиру НСЗ. Систем треба да обезбеди јединствену базу података и интегрисано функционисање свих реализованих модула, уз примену принципа: „Један податак – једно место уноса – коришћење кроз цео систем – контролисана права приступа и измене.“ ERP систем треба да буде пројектован тако да: омогући реализацију више функционалних модула у оквиру јединственог система; обезбеди јединствену базу података; омогући заједничко коришћење података између модула; спречи непотребно вишеструко уношење истих података; обезбеди јединствене шифарнике и заједничке регистре; омогући аутоматски пренос података између функционалних модула; омогући интеграцију са другим информационим системима; омогући проширивање система новим модулима и функционалностима; подржи повећање броја корисника, организационих јединица и количине података без суштинске измене основне архитектуре система. Сви модули треба да буду међусобно интегрисани тако да се подаци унети у једном делу система могу, у складу са додељеним правима приступа, користити у другим пословним процесима. 2. КОРИСНИЦИ, УЛОГЕ И ПРАВА ПРИСТУПА Систем треба да обезбеди управљање корисницима, корисничким улогама и правима приступа. Права приступа треба да се могу дефинисати најмање на следећим нивоима: модул; функционалност; врста операције; организациона јединица; ниво података; преглед, унос, измена и брисање/деактивација података; креирање, измена и потврда докумената; извршавање пословних операција; приступ извештајима и аналитикама. Систем треба да омогући дефинисање различитих корисничких улога, при чему један корисник може имати једну или више улога. Потребно је обезбедити најмање следеће категорије приступа: ограничени приступ; проширени приступ; потпуни приступ у оквиру додељених овлашћења. Посебно треба омогућити раздвајање права за преглед података од права за њихов унос и измену. Права приступа треба да буду подесива без измене програмског кода система. 3. ОРГАНИЗАЦИОНА СТРУКТУРА И ПРИСТУП ПОДАЦИМА ERP систем треба да подржи организациону структуру НСЗ која најмање обухвата: Дирекцију; филијале; друге организационе јединице, уколико се укаже потреба. Сви релевантни пословни подаци треба да буду повезани са организационом јединицом којој припадају или у којој су настали. Систем треба да обезбеди: приступ корисника подацима сопствене организационе јединице; приступ корисника Дирекције подацима свих организационих јединица, у складу са додељеним правима; могућност дефинисања посебних права за поједине организационе јединице; могућност централизованог извештавања; идентификацију организационе јединице у којој је податак или пословни догађај настао. За сваки релевантан документ, трансакцију, обавезу, уплату и друго пословно дешавање треба да буде могуће утврдити њихово порекло, односно организациону јединицу која је податак креирала или са којом је повезан. 4. ЈЕДИНСТВЕНА БАЗА ПОДАТАКА, ШИФАРНИЦИ И ЗАЈЕДНИЧКИ РЕГИСТРИ ERP систем треба да користи јединствену базу података за све реализоване модуле. Подаци који имају заједничко значење за више пословних процеса треба да се воде на једном месту и користе у свим модулима у којима су потребни. Систем треба да обезбеди јединствене шифарнике, уз могућност њиховог централизованог одржавања. Заједнички шифарници и регистри треба да буду доступни свим модулима којима су потребни, у складу са правима приступа корисника. 5. ИНТЕГРАЦИЈА СА ДРУГИМ ИНФОРМАЦИОНИМ СИСТЕМИМА ERP систем треба да буде отворен за интеграцију са другим информационим системима НСЗ и спољним системима. Потребно је обезбедити стандардизоване механизме размене података, најмање путем WEB сервиса и API интерфејса. Интеграција треба да обухвати, између осталог: кадровски информациони систем; JIS; IRIS; EPP; SEF; друге постојеће информационе системе НСЗ; будуће информационе системе. Интеграције треба да омогуће аутоматски пренос података без потребе за поновним ручним уносом истих података. За сваку интеграцију потребно је обезбедити контролу успешности преноса и евиденцију грешака. 6. ОПШТИ ЗАХТЕВИ ЗА РАД СА ПОДАЦИМА Систем треба да омогући једноставан и ефикасан рад са подацима у свим модулима. Потребно је обезбедити: филтрирање по једном или више поља; сортирање; претрагу; приказ детаљних и збирних података; аналитичке прегледе; извоз података; штампу, где је применљиво. Претрага и филтрирање треба да буду доступни без потребе за познавањем програмског језика или SQL упита. 7. ИЗВЕШТАВАЊЕ И BI ERP систем треба да обезбеди интегрисано извештавање над подацима свих модула. Извештаје треба да буде могуће извозити најмање у: Word; Excel; PDF. Систем треба да омогући креирање различитих аналитичких и сумарних прегледа. Потребно је обезбедити отвореност система за интеграцију са BI алатима, при чему овлашћеним корисницима треба омогућити директан приступ подацима, односно контролисаним изворима података, ради израде сопствених анализа и извештаја. Предмет овог дела техничке спецификације је јединствена, обједињена целина решења за извештавање која се први пут набавља и уводи у оквиру ERP система Националне службе за запошљавање (НСЗ). Решење обухвата два међусобно повезана и функционално интегрисана дела: стандардно извештавање и унапређење извештавања применом модела вештачке интелигенције и машинског учења (AI/ML) – предиктивни и аналитички модули. Оба дела треба да се реализују као јединствена софтверска целина, са заједничким изворима података и јединственом економском, функционалном и организационом класификацијом, у складу са важећим прописима о буџетском систему Републике Србије. 7.1. АНАЛИЗА ПОСТОЈЕЋЕГ СТАЊА И ЦИЉ ПРОЈЕКТА НСЗ управља двема буџетски најосетљивијим категоријама расхода: новчаним накнадама за случај незапослености, чија је исплата законска обавеза и директно зависи од кретања броја лица на евиденцији, и средствима за активне мере запошљавања (субвенције за запошљавање и самозапошљавање, јавни радови, обуке, стручна пракса), која се распоређују и реализују преко мреже филијала и испостава. Планирање и извештавање у оба тока тренутно се у највећој мери ослањају на историјску екстраполацију и ручну анализу одступања, што ограничава могућност благовременог уочавања ризика неусклађености реализације са планом и продужава време припреме периодичних извештаја. Циљ пројекта је увођење предиктивних и аналитичких AI/ML модула који се надограђују на постојећи ERP и извештајни слој НСЗ ради: прецизнијег планирања потребних буџетских средстава по економским категоријама; раног откривања ризика од неискоришћености или прекорачења буџетских апропријација по програмима и организационим јединицама; бржег откривања неуобичајених образаца трошења у извршењу буџета; скраћења времена припреме периодичних извештаја управи, надзорном одбору и надлежном министарству. 7.2. ЗАХТЕВИ ЗА СТАНДАРДНО ИЗВЕШТАВАЊЕ У наставку су дефинисани захтеви за стандардно извештавање који чине први, основни део обједињене целине решења. На овај део се надовезује други део – унапређење извештавања применом AI/ML модела, описано у наредном одељку. Извештавање Софтвер омогућава извештавање у електронском или штампаном облику по било ком дефинисаном критеријуму (дефинисани критеријум – вредности/ознака везана за трансакције у систему које се користе за анализу и статистичке извештаје); конфигурабилност извештаја – корисници могу сами одређивати критеријуме извештаја; софтвер има могућност да све извештаје извози у Word, Excel и PDF формат; софтвер омогућава добијање жељеног извештаја аутоматски у унапред одређеном тренутку; софтвер је отворен за коришћење података од стране BI алата за анализу и извештавање. Финансијско извештавање софтвер омогућава анализирање финансијских рачуноводствених података од стране свих хијерархијских нивоа у установи у зависности од њихових овлашћења; софтвер подржава корисничко креирање рачуноводствених извештаја; софтвер омогућава корисничко дефинисање изгледа колона на финансијским извештајима; софтвер омогућава сумирање различитих финансијских рачуна на бази текућих, историјских или буџетских података, тј. on-line поређење између планских позиција и актуелних стања; софтвер омогућава кориснички преглед података у односу на различите временске периоде (дан, недеља, месец, квартал, година, кориснички дефинисани обрачунски период) и на основу њих сумира финансијске податке; софтвер омогућава коришћење рачуноводствених типова показатеља, као нпр. имовина, обавезе, приход; софтвер омогућава продирање од on-screen информација из извештаја до детаљног рачуна и детаљне трансакције и ставки које је чине, тзв. drill-down; софтвер омогућава рад на извештајима док је on-line систем активан; софтвер омогућава филтрирање аналитичких прегледа са критеријумима које нека ставка мора да задовољи. 7.3. УНАПРЕЂЕЊЕ ИЗВЕШТАВАЊА ПРИМЕНОМ AI/ML МОДЕЛА Други део обједињене целине решења чини унапређење извештавања применом AI/ML модела. Овај део се састоји од три међусобно повезана, али самостално применљива модула. Сваки модул је дефинисан кроз циљ, улазне податке из ERP система, тачно наведене AI/ML алгоритме и очекиване излазне резултате. Модул 1 – Предвиђање броја корисника новчане накнаде за незапосленост и потребних буџетских средстава Циљ: прецизнија пројекција броја лица која остварују право на новчану накнаду и висине потребних средстава за наредни период (месечно, квартално, годишње), са интервалом поверења који подржава сценарио планирање. Улазни подаци: историјски месечни подаци о броју новопријављених и одјављених лица са евиденције незапослених (агрегатно, по филијали и сектору делатности); просечно трајање коришћења права на накнаду и висина накнаде по категоријама корисника; календарске и сезонске варијабле (број радних дана, празници); доступни макроекономски индикатори (стопа незапослености по региону). AI/ML алгоритми: SARIMAX (сезонски ARIMA са егзогеним варијаблама) – статистички базни модел тренда и сезоналности; Facebook Prophet / NeuralProphet – моделовање сезоналности, празника и структурних ломова у серији; gradient boosting регресија (XGBoost / LightGBM / CatBoost) са инжењерингом обележја над егзогеним варијаблама, за нелинеарне зависности; квантилна регресија (LightGBM quantile loss) за генерисање оптимистичног, очекиваног и песимистичног сценарија; ансамбл (пондерисано комбиновање / stacking) наведених модела ради робусности финалне прогнозе; валидација методом rolling-origin backtestinga по буџетским циклусима (метрике MAPE, WAPE). Излазни резултати: периодична прогноза броја корисника и потребних средстава по економској класификацији, са интервалом поверења, укључена као додатни прилог у постојећи извештајни образац. Модул 2 – Предвиђање и праћење динамике реализације буџета по програмима и филијалама Циљ: рано откривање ризика неискоришћености или прекорачења средстава по програмима активних мера запошљавања и по организационим јединицама, ради благовременог предлога прерасподеле или ребаланса. Улазни подаци: историјска месечна реализација расхода по економској и организационој класификацији; план/апропријација по програму и филијали; број корисника и тип програма (субвенције, јавни радови, обуке, стручна пракса). AI/ML алгоритми: хијерархијско временско предвиђање са MinT (Minimum Trace) реконцилијацијом, како би збир прогноза филијала и програма био конзистентан са нивоом централе; панел gradient boosting модел (LightGBM) са обележјима по филијали/програму за предвиђање очекиване стопе реализације; моделовање S-krive (логистичка/бета крива кумулативне реализације) као референтни образац типичне динамике трошења током буџетске године; класификациони модел (gradient boosting classifier / логистичка регресија) који за сваку филијалу/програм процењује вероватноћу неискоришћености или прекорачења апропријације до краја периода. Излазни резултати: ранг-листа филијала и програма по ризику одступања реализације од плана, са процењеним износом одступања, ажурирана месечно и укључена у периодични извештај управи и надзорном одбору. Модул 3 – Детекција аномалија у извршењу буџета Циљ: аутоматско откривање неуобичајених образаца трошења (грешке у књижењу, непланирана концентрација расхода, одступање од уобичајеног понашања филијале) ради раног упућивања на проверу, у подршци интерној контроли и припреми за екстерну ревизију. Улазни подаци: месечни/недељни агрегати расхода по филијали, економској класификацији и програму; резидуалне вредности (одступања стварног од предвиђеног) из модела Модула 1 и 2. AI/ML алгоритми: Isolation Forest – несупервизована, мултиваријантна детекција аномалија на агрегираним подацима по филијали и економској класификацији; статистичка контрола процеса (CUSUM и контролне границе засноване на Z-skoru) над резидуалима предикционих модела, за транспарентне и лако објашњиве аларме; autoencoder неуронска мрежа – опциона надоградња у каснијој фази, за детекцију аномалија на финијем, трансакционом нивоу; SHAP (SHapley Additive exPlanations) вредности за објашњење доприноса појединачних варијабли оцени аномалије, ради лакшег прихватања налаза од стране интерне контроле и DRI. Излазни резултати: аутоматизована листа означених аномалија са објашњењем вероватног узрока и предложеним приоритетом провере, интегрисана у постојећи процес интерне контроле. 7.4. ТЕХНИЧКА АРХИТЕКТУРА РЕШЕЊА Решење треба да се надограђује на постојећи ERP систем и извештајни слој НСЗ и не сме да захтева измену постојеће економске, функционалне ни организационе класификације. Ток података треба да се одвија кроз следеће слојеве: ERP систем НСЗ (извор података) – књиговодствени и буџетски подаци, подаци о евиденцији незапослених на агрегираном нивоу; слој за екстракцију, трансформацију и учитавање података (ETL), са периодичним и аутоматизованим преузимањем података из ERP-a; аналитичко складиште података (data warehouse / staging слој) у оквиру инфраструктуре НСЗ; AI/ML модул за тренирање, валидацију и извршавање модела (уз MLOps компоненту за праћење квалитета и периодично поновно тренирање модела); постојећи извештајни/BI слој НСЗ, у који се резултати модела укључују као додатни прилози и показатељи; крајњи корисници – руководство НСЗ, надлежно министарство, Управа за трезор, Државна ревизорска институција. Сви излази модела треба да се мапирају на постојећу економску, функционалну и организациону класификацију буџетског система, тако да резултати буду директно упоредиви са званичним обрасцима извештавања. Два основна типа ризика у предметном послу су пословни ризик и пројектни ризик. Задатке везане за управљање пословним ризиком, који је овде посебно значајан, јер се поставља у употребу сложен пословни систем, треба да обавља стручњак за обезбеђивање квалитета, сертификован за управљање ИТ системима високе сложености, са познавањем ризика, архитектуре ИТ система и посебно управљањем обезбеђења квалитета у примени ИТ (Certified in the Governance of Enterprise IT (ISACA) или еквивалент). Овај сертификат потврђује да лице има вештине и искуство у ИТ системима високе сложености, у смислу управљања ризицима имплементације, осигурању квалитета и мерењу перформанси, послова које ће управо обављати у предметном пројекту. Како је предмет посла и вештачка интелигенција, као компонента са посебним аспектом регулације и ризика с тим у вези потребно је да стручњак поседује и такве компетенције у смислу примене вештачке интелигенције по стандарду ISO/IEC 42001:2023 или еквивалентан. 8. РАД СА УДАЉЕНИХ ЛОКАЦИЈА ERP систем треба да омогући рад корисника са различитих локација НСЗ, укључујући Дирекцију и филијале. Приступ систему треба да буде могућ преко савремених интернет веза, уз обезбеђење: аутентификације; ауторизације; контроле приступа; безбедне комуникације; заштите података. 9. УСКЛАЂЕНОСТ СА ПРОПИСИМА ERP систем треба да омогући рад у складу са важећим прописима Републике Србије који регулишу: рачуноводство; финансијско пословање; буџетски систем; јавни сектор; порезе; зараде; електронско фактурисање; заштиту података; архивирање; друге области које су релевантне за пословање НСЗ. Пословна правила и обрачуне треба реализовати тако да се, где је то могуће, могу параметарски прилагодити изменама прописа без суштинске измене основне архитектуре система. 10. ЈЕДИНСТВЕНИ РЕГИСТАР ПОСЛОВНИХ ПАРТНЕРА/КОМИТЕНАТА 10.1. ЈЕДИНСТВЕНИ РЕГИСТАР ПОСЛОВНИХ ПАРТНЕРА/КОМИТЕНАТА ERP систем треба да садржи јединствени регистар пословних партнера/комитената који се користи на нивоу целог ERP система. Регистар треба да садржи све релевантне податке о пословном партнеру/комитенту, најмање: назив, односно име и презиме; пуни и скраћени назив, када је применљиво; врсту партнера; правни статус; матични број; ПИБ; статус у систему ПДВ; шифру и назив делатности, када је применљиво; седиште; адресу; адресу за доставу; место; општину; државу; поштански број; телефон; електронску адресу; интернет адресу; податке о контакт особама; податке о банковним рачунима; податке потребне за електронску размену докумената; статус пословног партнера; датуме важења података, где је применљиво; напомене; друге релевантне податке. Систем треба да омогући вођење више: адреса; контакт особа; телефона; електронских адреса; банковних рачуна за једног пословног партнера, када је то потребно. 10.2. КОРИШЋЕЊЕ ПОДАТАКА О ПОСЛОВНИМ ПАРТНЕРИМА Подаци о пословним партнерима треба да буду заједнички за цео ERP систем. Корисници који имају одговарајућа права треба да могу да користе податке из регистра у свим пословним процесима у којима се пословни партнер појављује. Пословни партнер из јединственог регистра треба да се може користити, између осталог, у: главној књизи; књизи примљених фактура; књизи излазних фактура; изводу; принудној наплати; евиденцији добровољног враћања дуга; налозима за плаћање; другим финансијским и пословним процесима. Приликом избора пословног партнера у било ком модулу треба користити податке из јединственог регистра, без потребе за поновним уносом основних података о истом партнеру. 10.3. ПРАВА ЗА УНОС И АЖУРИРАЊЕ ПОДАТАКА Систем треба да омогући детаљно дефинисање права за: преглед података; креирање новог пословног партнера; измену постојећих података; деактивацију партнера; одржавање појединих група података. Права за унос и измену треба да се додељују у складу са поделом послова и организацијом рада НСЗ. Потребно је омогућити да корисници који имају право прегледа могу користити податке пословног партнера у пословним процесима, без обавезе да имају право да те податке мењају. Брисање пословног партнера треба, по правилу, бити замењено деактивацијом, како би се очувала историја пословних докумената и трансакција. 10.4. КОНТРОЛА УНОСА Систем треба да обезбеди контролу уноса и измене података у регистру пословних партнера. Потребно је обезбедити контроле за спречавање дуплирања партнера, нарочито на основу идентификационих података као што су: матични број; ПИБ; други јединствени идентификатори. За измене података треба да постоји ревизиони траг који садржи најмање: корисника који је извршио измену; датум и време. 10.5. СИНХРОНИЗАЦИЈА ПОСЛОВНИХ ПАРТНЕРА СА ДРУГИМ ИНФОРМАЦИОНИМ СИСТЕМИМА ERP систем треба да омогући синхронизацију података о пословним партнерима/комитентима са другим информационим системима НСЗ и повезаним информационим системима. Посебно је потребно обезбедити могућност синхронизације комитената са информационим системима као што су: JIS; IRIS; други постојећи информациони системи НСЗ; будући информациони системи са којима ће бити потребна размена података. Синхронизација треба да омогући, у зависности од конкретне интеграције: преузимање нових комитената; пренос нових комитената из ERP система; ажурирање постојећих комитената; пренос измена података; идентификацију истог комитента у различитим системима; коришћење јединствених идентификатора; контролу дупликата. Начин размене података треба да буде заснован на стандардним механизмима интеграције, као што су WEB сервиси, REST API, SOAP, JSON, XML или други одговарајући механизми који буду дефинисани за конкретан систем. Потребно је обезбедити могућност дефинисања извора података и правила по којима се одређује који систем представља извор података за поједине атрибуте комитента. Потребно је да информациони систем буде пројектован и развијен на начин који омогућава брзу и једноставну интеграцију и комуникацију са системом СПИРИ (Систем за припрему, извршење, рачуноводство и извештавање ). 11. МОДУЛ ГЛАВНЕ КЊИГЕ Модул главне књиге треба да обезбеди јединствено вођење финансијских података на нивоу ERP система. Потребно је обезбедити: јединствени контни план; синтетичке и аналитичке рачуне; коришћење јединственог регистра пословних партнера; организационе и друге аналитичке димензије; ручно књижење; аутоматско књижење; аутоматски пренос података из других модула; контролу књижења; аналитичке и сумарне прегледе. Потребно је омогућити аутоматски пренос у главну књигу података из: књиге примљених фактура; излазних докумената; извода; обрачуна зарада; других модула. Сваки књиговодствени догађај треба да буде повезан са изворним документом. 11.1. Отварање и затварање пословне године Систем треба да омогући: аутоматско отварање нове пословне године; пренос почетних стања; затварање класа; затварање пословне године; контролисано поновно отварање године од стране овлашћеног корисника. Отварање нове пословне године треба да буде могуће извршити без интервенције добављача система. 11.2. Аналитички прегледи Потребно је омогућити анализу по: рачуну; пословном партнеру; организационој јединици; периоду; документу; врсти трансакције; изворном модулу; другим аналитичким димензијама. Кориснику треба омогућити прелаз са збирног приказа на детаљне податке и увид у изворни документ на основу којег је извршено књижење. 12. МОДУЛ КЊИГЕ ПРИМЉЕНИХ ФАКТУРА Модул треба да обезбеди: пријем и евиденцију примљених фактура; аутоматски увоз фактура из SEF-а; допуну података; контролу; обраду; књижење; коришћење података из јединственог регистра пословних партнера; повезивање са организационом јединицом; повезивање са одговарајућим рачуном; повезивање са аналитичким димензијама; праћење статуса фактуре. Обавезе настале по основу примљених фактура треба аутоматски преносити у главну књигу. 13. МОДУЛ ИЗВОДА Модул треба да омогући: учитавање електронских извода; аутоматску обраду ставки извода; идентификацију уплата; аутоматско повезивање уплата са одговарајућим обавезама; аутоматско књижење; ручно повезивање када аутоматско повезивање није могуће. Уплате треба аутоматски повезивати, када постоје одговарајући подаци, са: предметима принудне наплате; плановима добровољног враћања дуга; примљеним фактурама; излазним фактурама; другим обавезама и потраживањима. 14. МОДУЛ ЗА ПРИНУДНУ НАПЛАТУ – ДИРЕКЦИЈА Модул за принудну наплату користе овлашћени корисници Дирекције. Модул треба да обезбеди: евиденцију потраживања која су предмет принудне наплате; формирање и вођење предмета; праћење активности; праћење статуса предмета; евиденцију укупног дуга; евиденцију плаћеног износа; евиденцију преосталог дуга; обрачун камате, када је применљиво; евиденцију уплата; повезивање уплата са предметима; ажурирање стања обавеза; извештавање и аналитику. Потребно је омогућити дефинисање структуре позива на број, односно референтног броја, тако да се на основу података о уплати може аутоматски идентификовати предмет принудне наплате. Уплате учитане кроз модул извода треба, када је могуће, аутоматски повезивати са одговарајућим предметима. Свака промена стања предмета треба да буде евидентирана и повезана са одговарајућом финансијском трансакцијом. 15. МОДУЛ ЗА ЕВИДЕНЦИЈУ ДОБРОВОЉНОГ ВРАЋАЊА ДУГА – ФИЛИЈАЛЕ Модул треба да омогући филијалама самостално евидентирање и праћење добровољног враћања дуга у ратама. За сваки план добровољног враћања дуга треба омогућити евиденцију: дужника; укупног износа дуга; плана отплате; броја рата; износа сваке рате; датума доспећа сваке рате; камате, када је применљиво; извршених уплата; преосталог дуга; статуса плана; кашњења; прекорачења рокова. Систем треба да омогући аутоматско повезивање уплата са планом на основу референтног броја, као и ручно повезивање када аутоматска идентификација није могућа. Потребно је омогућити праћење: укупно задуженог износа; укупно плаћеног износа; преосталог дуга; доспелих рата; недоспелих рата; неплаћених рата; кашњења; статуса плана. Сваки план добровољног враћања дуга мора бити повезан са филијалом која га је евидентирала. Корисници филијале треба да имају приступ подацима своје филијале, док овлашћени корисници Дирекције треба да имају могућност увида у податке свих филијала. 16. МОДУЛ ОБРАЧУНА ЗАРАДА И ИСПЛАТА ВАН РАДНОГ ОДНОСА Модул треба да обезбеди: обрачун зарада; обрачун пореза; обрачун доприноса; контролу обрачуна; обрачун за исплату; податке за исплату; обрачун накнада; исплате ван радног односа; генерисање одговарајућих финансијских трансакција. Подаци о запосленима треба да се преузимају из кадровског информационог система, у складу са дефинисаном интеграцијом. Обрачун треба да буде повезан са финансијским модулом тако да се одговарајућа књижења могу извршити аутоматски. 17. МОДУЛ ЗА ГЕНЕРИСАЊЕ НАЛОГА ЗА ПЛАЋАЊЕ Систем треба да омогући аутоматско генерисање налога за плаћање на основу: обрачуна зарада; обавеза према добављачима; излазних докумената; других одобрених обавеза; ручно креираних налога, у складу са правима корисника. Потребно је омогућити контролу и одобравање налога пре слања на реализацију. Систем треба да омогући припрему и извоз података за EPP. 18. ПРЕНОС СРЕДСТАВА КА ФИЛИЈАЛАМА ERP систем треба да омогући управљање процесом преноса средстава ка филијалама. Потребно је обезбедити: креирање захтева/налога; евиденцију износа; контролу; одобравање; праћење статуса; евиденцију реализације; аутоматско генерисање одговарајућих финансијских трансакција. 19. АУТОМАТИЗОВАНО ПОВЕЗИВАЊЕ УПЛАТА Један од основних захтева ERP система је висок степен аутоматизације повезивања уплата са одговарајућим обавезама. Потребно је омогућити дефинисање структуре референтног броја/позива на број за различите врсте обавеза, организационе јединице и пословне процесе. На основу података из уплате систем треба, када је могуће, да аутоматски идентификује: организациону јединицу; врсту обавезе; дужника/платиоца; предмет; план отплате; фактуру; другу релевантну обавезу. Након идентификације систем треба да: повеже уплату са одговарајућом обавезом; ажурира стање дуга; ажурира план отплате; креира одговарајуће финансијско књижење; омогући праћење целог ланца од извода до књижења. Уплате које није могуће аутоматски идентификовати треба ставити на листу за ручну обраду. 20. СЛЕДЉИВОСТ И РЕВИЗИОНИ ТРАГ Систем треба да обезбеди потпун ревизиони траг за значајне пословне и финансијске операције. Потребно је евидентирати најмање: корисника; датум и време; организациону јединицу; врсту операције; документ; промену података; стару и нову вредност; повезане пословне догађаје; изворни документ; генерисана књижења. Потребно је омогућити праћење пословног догађаја кроз цео систем, од иницијалног документа или уноса до финансијског књижења и евентуалне наплате. 21. БЕЗБЕДНОСТ СИСТЕМА ERP систем треба да обезбеди одговарајући ниво информационе безбедности. Потребно је обезбедити: аутентификацију корисника; ауторизацију; контролу приступа по улогама; контролу приступа по организационим јединицама; контролу приступа подацима; безбедну комуникацију; евидентирање активности корисника; ревизиони траг; заштиту од неовлашћеног приступа; заштиту од неовлашћене измене података. Усклађеност са законском регулативом и заштитом података решење треба да буде усклађено са Законом о буџетском систему и Правилником о стандардном класификационом оквиру и контном плану за буџетски систем – сви излази модела треба да буду мапирани на постојећу класификацију, без увођења паралелне структуре; модели треба да раде искључиво над агрегираним и анонимизованим подацима на нивоу филијале, програма и сектора, у складу са Законом о заштити података о личности, без обраде података о појединачним лицима ван постојећих овлашћења НСЗ; инфраструктура за хостовање података и модела треба да се реализује у оквиру инфраструктуре под контролом НСЗ, у складу са безбедносним захтевима за јавни сектор; сви модели треба да буду пројектовани тако да буду објашњиви (интерпретабилни) – уз употребу SHAP вредности и транспарентних статистичких метода – ради могућности провере од стране интерне контроле и Државне ревизорске институције. 22. ПРОШИРИВОСТ И ОТВОРЕНОСТ СИСТЕМА ERP систем треба да буде реализован као отворен и проширив систем. Потребно је омогућити накнадно: додавање нових модула; додавање нових функционалности; проширивање постојећих модула; додавање нових организационих јединица; додавање нових корисника; интеграцију са новим информационим системима; проширивање шифарника; проширивање аналитичких димензија. Проширивање система не треба да захтева измену основне архитектуре система. 23. ЦИЉЕВИ И ОЧЕКИВАНИ ЕФЕКТИ ИНТЕГРАЦИЈЕ Увођењем интегрисаног ERP система треба да се обезбеде следећи ефекти: јединствено управљање подацима; једнократан унос података на месту настанка; коришћење истих података кроз више пословних процеса; смањење вишеструког ручног уноса; смањење могућности грешке; скраћење времена обраде; аутоматизација финансијских књижења; аутоматизација обраде извода; аутоматско повезивање уплата са обавезама; централизовано управљање подацима о пословним партнерима; елиминисање вишеструког вођења истих података о комитентима; синхронизација комитената и других података са JIS-ом, IRIS-ом и другим информационим системима; побољшање контроле података; повећање транспарентности; потпуна следљивост пословних и финансијских трансакција; смањење административног оптерећења запослених; побољшање квалитета извештавања; омогућавање централизоване аналитике; стварање основе за даљи развој информационог система НСЗ. Посебно је потребно обезбедити да интеграција различитих модула и информационих система омогући да се пословни догађај, односно податак, унесе једном и да се, у складу са пословним правилима и правима приступа, аутоматски користи у свим процесима у којима је потребан. На тај начин ERP систем треба да обезбеди интегрисан ток података од њиховог настанка, преко пословне обраде, до финансијског евидентирања, извештавања и аналитике. 24. ПЛАН И ДИНАМИКА РЕАЛИЗАЦИЈЕ ПРОЈЕКТА Реализација ERP система НСЗ спроводи се кроз пет фаза, у укупном трајању до 12 месеци од дана закључења уговора (укупан рок извршења уговора наведен је у Обрасцу понуде). Појединачни рокови, односно време почетка и завршетка сваке појединачне фазе, дефинисани су Терминским планом са гантограмом активности. Прегледно, фазе реализације распоређене су по месецима на следећи начин: Фаза 1 – Анализа; Фаза 2 – Кориснички налози, системски и кориснички шифарници; Главна књига и пословни партнери; Фаза 3 – Књига примљених фактура; Изводи и пренос средстава ка филијалама; Фаза 4 – Принудна наплата – Дирекција; Добровољно враћање дуга – филијале; Фаза 5 – Зараде и исплате ван радног односа; Извештавање и BI. 24.1. ФАЗА 1 – АНАЛИЗА Фаза обухвата анализу постојећег стања и детаљну разраду техничких и функционалних захтева ERP система, као основу за реализацију свих наредних фаза. У оквиру тима понуђача треба да буде ангажован и стручњак за анализу пословних процеса који управља потребама корисника и захтевима корисника-фаза пројектовања система, и функционалним и нефункционалним захтевима-фаза развоја и имплементације система. Израда детаљних спецификација корисничких потреба и захтева, са описом пословних процеса (пројектовање, консалтинг укључен у смислу саветовања корисника у пројектовању и оптимизацији пословних процеса, дигитализацији и трансформацији процеса), као и спецификација софтвера са детаљним спецификацијама пословних процеса и радних токова и процедура и дизајн система са имплементацијом система, односно спецификација за извођење информационог система, који су претходно препознати као детаљне пословне потребе и кориснички захтеви, у фази пројектовања, треба да се реализује у складу са методама усавршеним кроз стечену сертификацију PBA-Certified Professional in Business Analysis (према методологији коју дефинише организација PMI-Project Management Institute) или еквивалент. 24.2. ФАЗА 2 – КОРИСНИЧКИ НАЛОЗИ И ШИФАРНИЦИ; ГЛАВНА КЊИГА И ПОСЛОВНИ ПАРТНЕРИ Фаза обухвата паралелну реализацију следећих целина: кориснички налози, улоге и права приступа, системски и кориснички шифарници и заједнички регистри (поглавља 2–4); модул главне књиге и јединствени регистар пословних партнера/комитената (поглавља 10–11). 24.3. ФАЗА 3 – КЊИГА ПРИМЉЕНИХ ФАКТУРА; ИЗВОДИ И ПРЕНОС СРЕДСТАВА КА ФИЛИЈАЛАМА Фаза обухвата паралелну реализацију следећих целина: модул књиге примљених фактура (поглавље 12); модул извода и пренос средстава ка филијалама (поглавља 13 и 18). 24.4. ФАЗА 4 – ПРИНУДНА НАПЛАТА – ДИРЕКЦИЈА; ДОБРОВОЉНО ВРАЋАЊЕ ДУГА – ФИЛИЈАЛЕ Фаза обухвата паралелну реализацију следећих целина: модул за принудну наплату – Дирекција (поглавље 14); модул за евиденцију добровољног враћања дуга – филијале (поглавље 15). 24.5. ФАЗА 5 – ЗАРАДЕ И ИСПЛАТЕ ВАН РАДНОГ ОДНОСА; ИЗВЕШТАВАЊЕ И BI Ово је завршна фаза пројекта и, поред преостала два функционална модула, обухвата и активности потребне за пуштање система у продукциону употребу: модул обрачуна зарада и исплата ван радног односа (поглавље 16); извештавање и BI, укључујући унапређење извештавања применом AI/ML модела (поглавље 7); модул за генерисање налога за плаћање и аутоматизовано повезивање уплата (поглавља 17 и 19); следљивост и ревизиони траг, безбедност система (поглавља 20 и 21); интеграционо и функционално тестирање, обуку корисника и пуштање система у продукциону употребу. Гарантни рок: Гарантни рок за имплементирано решење мора бити минимално 12 (дванаест) месеци од дана потписивања Записника о успешном пуштању решења у продукцију. Место испоруке: Национална служба за запошљавање, Сектор за информациони систем, развој и аналитику, Гундулићев венац 23-25, 11000 Београд. Под испоруком предметног добра, подразумева се и испорука изворног кода (source code) предметног софтверског решења, чиме Наручилац постаје власник истог. Kriterijumi za dodelu ugovora.pdf КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ 1 Наручилац: Национална служба за запошљавање 103277483 Назив поступка: Увођење информационог система (ЕРП) за финансијско, робно и материјално књиговодство са напредним извештајно-аналитичким модулом Референтни број: 0109/26 КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ Део конкурсне документације који је генерисан путем Портала у случају када је наручилац означио опцију аутоматског рангирања понуда на Порталу јавних набавки Назив предмета / партије: Увођење информационог система (ЕРП) за финансијско, робно и материјално књиговодство са напредним извештајно-аналитичким модулом Наручилац је дефинисао критеријуме за доделу уговора на основу: Цене и критеријума квалитета Изабран начин рангирања прихватљивих понуда (формула): Аутоматско рангирање Укупан број бодова једнак је збиру бодова за сваки критеријум. Формуле су наведене доле уз сваки критеријум. Бу = Бц + ∑ к Бк - укупан број бодоваБу - број бодова ценеБц - критеријумк - број бодова критеријумаБк Цена Цена - пондер (нумеричка вредност): 90,00 Формула за израчунавање бодова за критеријум цене: Максимални број бодова најбољој понуђеној вредности, остале понуђене вредности бодују се у односу на најбољу вредност Б = минЦ Ц × П - број бодова ценеБ - цена најниже понудеминЦ - понуђена ценаЦ - вредност пондера ценеП Код релативног модела оцене, број бодова који се добија за критеријум за поједину понуду зависи од вредности које су понудили други понуђачи. Најбоља понуђена вредност добија максималан број бодова (нумеричка пондерисана вредност). Остале понуде добијају број бодова у односу на најбољу понуђену вредност. Критеријуми квалитета КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ 2 Назив: Рок испоруке Јединица мере: дан Пондер (нумеричка вредност): 10,00 Вредност за овај критеријум може да буде само цели број. Опис и појашњење критеријума и докази потребни за проверу: Привредни субјект уноси у Образац понуде Рок испоруке, односно рок у коме је добављач дужан да предметно софтверско решење и остале пратеће компоненте имплементира и испоручи, у свему према Техничкој спецификацији предмета јавне набавке, Обрасцу структуре цене, Обрасцу понуде и Терминском плану, рачунајући од дана закључења уговора. Појединачни рокови, односно време почетка и завршетка сваке појединачне фазе, као и пројекта у целости, дефинише понуђач у Терминском плану са гантограмом активности, који се доставља у електронском облику у склопу понуде. Понуђач у Образац понуде уноси укупно време реализације, односно укупан рок свих фаза (Фаза 1 + Фаза 2 + Фаза 3 + Фаза 4 + Фаза 5) изражен у данима, рачунајући од дана закључења уговора. Повољнија је  већа понуђена вредност  мања понуђена вредност Формула за израчунавање бодова за критеријум: Максимални број бодова најбољој понуђеној вредности, остале понуђене вредности бодују се у односу на најбољу вредност Код релативног модела оцене, број бодова који се добија за критеријум за поједину понуду зависи од вредности које су понудили други понуђачи. Најбоља понуђена вредност добија максималан број бодова (нумеричка пондерисана вредност). Остале понуде добијају број бодова у односу на најбољу понуђену вредност. Ограничења: Ограничена је минимална вредност коју понуђач може да понуди Ограничена је максимална вредност коју понуђач може да понуди Максимална дозвољена вредност: 365,00 Б = минВ В × П - број бодова критеријумаБ - вредност пондера критеријумаП - понуђена вредност за критеријумВ - највећа понуђена вредност за критеријумма𝑥В - најмања понуђена вредност за критеријумминВ - максимална дозвољена вредност за критеријумВма𝑥 - минимална дозвољена вредност за критеријумВмин Остали захтеви набавке (који нису наведени изнад као критеријуми) Назив: Рок плаћања Јединица мере: дан Опис и појашњење критеријума и докази потребни за проверу: Рок плаћања понуђач уписује на одговарајућем месту у Обрасцу понуде, изражен у данима од дана пријема исправно сачињене фактуре, записника о примопредаји и/или неког другог документа којим се доказује да је пројекат (односно имплементација и испорука предметног решења са пратећим компонентама и пружене услуге) у целости окончан на одговарајући начин. Наручилац ће плаћање вршити након што је пројекат (односно имплементација и испорука предметног решења са пратећим компонентама и пружене услуге) у целости окончан на одговарајући начин. КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ 3 Ограничења: Ограничена је минимална вредност коју понуђач може да понуди Минимална дозвољена вредност: 15,00 Ограничена је максимална вредност коју понуђач може да понуди Максимална дозвољена вредност: 45,00 Назив: Гарантни рок за испоручено решење Јединица мере: месец Ограничења: Ограничена је минимална вредност коју понуђач може да понуди Минимална дозвољена вредност: 12,00 Ограничена је максимална вредност коју понуђач може да понуди Опис и појашњење критеријума и докази потребни за проверу: Понуђач уноси у образац понуде трајање гарантног рока за испоручено решење, изражен у месецима, рачунајући од дана потписивања Записника о успешном пуштању решења у продукцију. Напомена: У овом делу наведени су остали захтеви набавке који нису претходно наведени као критеријуми за доделу уговора, а понуђач мора на њих да одговори приликом попуњавања електронског обрасца понуде. Ти захтеви могу да се односе на захтеве набавке, које наручилац сматра релевантним за закључење уговора и који се могу нумерички исказати Резервни критеријуми Критеријум за доделу уговора је највећи укупан број пондера. У случају да два или више понуђача имају исти укупан број бодова (пондера) повољнијом ће се сматрати понуда оног понуђача који понуди дужи рок плаћања, који не може бити краћи од 15 дана, а који у складу са Законом о роковима измирења новчаних обавеза у комерцијалним трансакцијама („Службени гласник РС“ бр. 119/2012, 68/2015, 113/2017, 91/2019, 44/2021, 44/2021 - др. закон, 130/2021, 129/2021 - др. закон,138/2022 и 109/2025), не сме бити дужи од 45 дана. Примена жреба Уколико након рангирања на основу критеријума за доделу и резервних критеријума није могуће донети одлуку о додели уговора, наручилац ће уговор доделити понуђачу који буде извучен путем жреба. Наручилац ће обавестити све понуђаче који су поднели понуде о датуму када ће се одржати извлачење путем жреба. Жребом ће бити обухваћене само оне понуде које су најповољније након рангирања на основу критеријума за доделу и резервних критеријума. Извлачење путем жреба наручилац ће извршити јавно, у присуству понуђача, и то тако што ће називе понуђача исписати на одвојеним папирима, који су исте величине и боје, те ће све те папире ставити у провидну кутију одакле ће прво извући само један папир. Понуђачу чији назив буде на извученом папиру ће бити додељен уговор. Након извлачења првог папира наручилац извлачи преостале папире један по један те сходно редоследу којим су извучени рангира преостале понуђаче. Понуђачима који не присуствују овом поступку, наручилац ће доставити записник извлачења путем жреба.