Grįžti į sąrašą

ERP sistemos KAS sistemai įsigijimas ir diegimas

Išanalizuota

Lietuvos Respublikos krašto apsaugos ministerija

Rinkos konsultacijaCPV: 72263000 - Programinės įrangos diegimo paslaugos
ID: 79363042026-05-19 10:25
Atidaryti CVP IS

Aprašymas

Krašto apsaugos ministerija (KAM) planuoja įsigyti ir įdiegti vieningą ERP sistemą, skirtą Lietuvos kariuomenės ir kitų KAS sistemos organizacijų veiklos procesams valdyti ir apskaityti. Ši sistema užtikrins duomenų integravimą, analizę, dirbtinio intelekto ir automatizavimo galimybes bei informacijos dalijimąsi su sąjungininkais. Pirkimo tikslas – diegti jau veikiantį, funkcionaliai patikrintą sprendimą, pritaikytą gynybos pramonei ir viešojo sektoriaus įstaigoms.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas privalo turėti Įmonės patikimumo pažymėjimą (IPP) RIBOTO NAUDOJIMO / NATO RESTRICTED lygiui – išduotą Lietuvos Respublikos VSD arba pripažintą NATO abipusio pripažinimo tvarka.
  • 2Susitikimuose dalyvaujantys tiekėjo atstovai privalo turėti Asmens patikimumo pažymėjimą (APP) RIBOTO NAUDOJIMO / NATO RESTRICTED lygiui.
  • 3Tiekėjas turi pateikti informaciją apie veikiančius diegimus klasifikuotose gynybos aplinkose (pvz.: „NATO valstybės narės gynybos ministerija, operatyvinis diegimas klasifikuotoje aplinkoje nuo [metai], >X vartotojų“) ir kiekvieno nurodyto diegimo atveju pateikti verifikacijos kontaktą.
  • 4Pardavėjas turi atitikti ir pateikti atitikimą pagrindžiančius įrodymus ISO/IEC 27001 informacijos saugos vadybos arba lygiavertį standartą.
  • 5Pardavėjas turi atitikti ir pateikti atitikimą pagrindžiančius įrodymus kibernetinio saugumo subjektui keliamiems reikalavimams, nustatytiems Kibernetinio saugumo reikalavimų apraše (KSRA).
  • 6ERP sistema turi būti NATO ir ES šalių kariuomenėse naudojama komercinė programinė įranga.
  • 7Jei kartu su Pardavėjo sukurta programine įranga bus naudojama kitų gamintojų programinė įranga (išskyrus atviro kodo nelicencijuojamą programinę įrangą), Pardavėjas turi pateikti oficialius tokios programinės įrangos gamintojo dokumentus, leidžiančius jam naudoti to gamintojo programinę įrangą.

Techniniai reikalavimai

Diegimo Reikalavimai

  • 1ERP sistema turi būti siūloma kaip programinė įranga kaip paslauga, kurios infrastruktūrą valdo Pirkėjas, o privačios debesijos aplinkoje – Tiekėjas.
  • 2ERP sistemą turi būti galima diegti lokalioje aplinkoje naudojant standartinę aparatinę įrangą.
  • 3ERP sistemoje turi būti naudojamas automatinio Tęstinės integracijos/Tęstinio diegimo principas ERP sistemos palaikymui ir atnaujinimui, nepriklausomai nuo to, kur ERP sistema yra patalpinta.
  • 4Pardavėjas turi pateikti visą reikalingą techninę įrangą, atsižvelgdamas į Pirkėjo pateiktus reikalavimus.
  • 5Siekiant įsitikinti, kad Pirkėjo infrastruktūra atitiks našumo ir saugumo reikalavimus, Pardavėjas turi bendradarbiauti su Pirkėju infrastruktūros projektavimo etape.
  • 6Remdamasis Pirkėjo pateiktais reikalavimais, Pardavėjas turi pateikti rekomenduojamas serverių aparatinės įrangos specifikacijas, kuriose turi būti nurodytas serverių skaičius ir specifikacijos (CPU, RAM, diskų dydis ir tipas, tinklo adapterio tipas ir t. t.).
  • 7Remdamasis Pirkėjo pateiktais reikalavimais, Pardavėjas turi pateikti rekomenduojamus tinklo komutatoriaus parametrus (prievadų greitį, prievadų skaičių, maksimalų komutatoriaus pralaidumą pps (paketais per sekundę) ir Gbps (gigabitais per sekundę) ir kitos ERP sistemai korektiškai veikti reikalingos tinklo įrangos parametrus.
  • 8Pateikti visus kitus išankstinius reikalavimus Pirkėjo infrastruktūrai (serveriuose įdiegtos operacinės sistemos tipą, papildomus įrankius / programinę įrangą, reikalingą ERP sistemai administruoti).
  • 9Padėti sukurti ir patvirtinti galutinį Pirkėjo pateiktą sprendimo dizainą.

Plečiamumo Reikalavimai

  • 1ERP sistema turi būti pritaikyta didelių kiekių duomenų valdymui, analizei ir užtikrinti didelį našumą.
  • 2ERP sistemos infrastruktūra turi apimti docker paremtą konteinerizavimo sprendimą su enterprise lygio palaikymu, leidžiančiu dinamiškai skirstyti sistemos resursus pagal kliento naudojimo poreikius.
  • 3ERP sistema turi užtikrinti greitus ir tikslius atsakymus į užklausas bei efektyvų skaičiavimo pajėgumų naudojimą naudojant paskirstytą failų sistemą ir jos duomenų saugyklas.
  • 4ERP sistema turi leisti savo pagrindines taikomąsias programas replikuoti ir dubliuoti, kad būtų užtikrintas atsparumas gedimams ir plečiamumas.
  • 5ERP sistema turi turėti galimybę būti techniškai plečiama papildant ją skaičiavimo galios didinimu, atminties didinimu, papildomos aplinkos įsigijimu pasirašant naują kontraktą arba papildant esamą.

Projektų Valdymo Modulis

  • 1Turi būti galimybė formuoti ir valdyti projektų portfelius bei programas, grupuojant projektus pagal KAS sistemos subjektus, veiklos sritis, finansavimo šaltinius, strateginius tikslus ar kitus klasifikatorius.
  • 2Turi būti galimybė nustatyti projektų tarpusavio priklausomybes, susieti lydimuosius projektus, paketus bei bendrus iniciatyvų rinkinius bei skirtingus KAS subjektus ir skirtingų KAS sistemos subjektų vykdomus projektus.
  • 3Turi būti galimybė stebėti pažangą portfelio, programos ir atskiro projekto lygmeniu, sugeneruoti ataskaitas norimu detalumu.
  • 4Turi būti galimybė valdyti projektų gyvavimo ciklą, įskaitant projektų inicijavimą, planavimą, vykdymą, stabdymą, užbaigimą ir archyvavimą.
  • 5Turi būti galimybė registruoti projekto rizikas, problemas, pokyčius ir sprendimus bei sekti jų būsenų istoriją.
  • 6Turi būti užtikrintas pilnas projekto duomenų atsekamumas, registruojant atliktus pakeitimus, jų autorius, datas ir pakeitimų istoriją.
  • 7Turi būti galimybė projektus susieti su strateginiais tikslais, veiklos planais, biudžeto programomis, priemonėmis, finansavimo šaltiniais ir kitais planavimo dokumentais.
  • 8Turi būti galimybė administruoti projektų klasifikatorius, įskaitant projektų tipus, būsenas, prioritetus, finansavimo šaltinius, atsakingus KAS sistemos subjektus, projekto kategorijas ir kitus projektų valdymui reikalingus požymius.
  • 9Turi būti galimybė registruoti projekto inicijavimo, vertinimo, derinimo ir patvirtinimo procesą, įskaitant atsakingus asmenis, sprendimus, pastabas ir patvirtinimo datas.
  • 10Turi būti galimybė formuoti projekto biudžeto poreikį, jį pagrįsti, derinti ir susieti su patvirtintais asignavimais, finansavimo šaltiniais ir biudžeto eilutėmis.
  • 11Turi būti galimybė planuoti ir valdyti projekto žmogiškuosius, finansinius, materialinius ir infrastruktūrinius resursus, formuoti konkrečius darbus (WBS), planuoti užduotis, jų terminus, priklausomybes ir atsakingus vykdytojus.
  • 12Turi būti galimybė planuoti ir stebėti projekto darbų etapus (milestone), identifikuoti terminų nukrypimus bei generuoti automatinius perspėjimus.
  • 13Turi būti galimybė registruoti projekto vykdymo faktinius duomenis, lyginti juos su planiniais rodikliais ir analizuoti nukrypimus.
  • 14Turi būti galimybė lyginti faktinius projekto vykdymo duomenis su patvirtintu projekto planu pagal suplanuotas veiklas, resursus, terminus ir biudžetą, identifikuojant nukrypimus nuo patvirtinto projekto plano.
  • 15Turi būti galimybė planuoti, stebėti ir vertinti projekto rezultatus, naudą ir rodiklius, įskaitant planines bei faktines reikšmes.
  • 16Turi būti galimybė valdyti projekto apimties, terminų, biudžeto ir resursų pakeitimus, išsaugant pakeitimų pagrindimą, sprendimą ir patvirtinimo istoriją.
  • 17Turi būti galimybė priskirti projekto roles ir atsakomybes, įskaitant projekto savininką, projekto vadovą, vykdytojus, derintojus ir tvirtintojus.
  • 18Turi būti galimybė susieti projekto veiklas, užduotis, etapus ir rezultatus su atsakingais KAS sistemos subjektais, padaliniais ir vykdytojais.
  • 19Turi būti galimybė formuoti standartines ir naudotojo konfigūruojamas projektų vykdymo ataskaitas norimu detalumu.
  • 20Turi būti galimybė duomenis analizuoti skirtingais pjūviais: pagal KAS sistemos subjektą, projektą, programą, objektą, finansavimo šaltinį, laikotarpį ir kitus klasifikatorius.
  • 21Turi būti galimybė eksportuoti ataskaitas į XLSX, PDF ir kitus standartinius formatus.
  • 22Turi būti galimybė formuoti vizualias valdysenos suvestines projekto, programos, projektų portfelio ir KAS sistemos subjekto lygmenimis, kuriose būtų atvaizduojami pagrindiniai rodikliai, projekto pažanga, būsenos, terminų vėlavimai, biudžeto vykdymas ir nukrypimai, rizikos bei projektų priklausomybės.
  • 23Turi būti galimybė naudotojams pagal suteiktas teises savarankiškai konfigūruoti ataskaitų filtrus, rodiklių rinkinius ir suvestinių vaizdus.
  • 24Projektų valdymo funkcionalumas turi būti integruotas su ERP finansų, biudžeto, viešųjų pirkimų, sutarčių, turto, dokumentų valdymo, personalo ir ataskaitų moduliais.
  • 25Turi būti užtikrinta, kad tie patys projektų, KAS sistemos subjektų, finansavimo šaltinių, turto, sutarčių, tiekėjų ir darbuotojų duomenys būtų naudojami vieningai visoje ERP sistemoje, nedubliuojant duomenų skirtinguose moduliuose.
  • 26Turi būti galimybė nustatyti naudotojų prieigos teises pagal KAS sistemos subjektą, padalinį, projektą, rolę, duomenų jautrumo lygį ir atliekamas funkcijas.
  • 27Turi būti galimybė susieti projektus su ERP dokumentų valdymo modulyje saugomais dokumentais, sprendimais, derinimo įrašais, sutartimis, protokolais ir kitais projekto vykdymą pagrindžiančiais dokumentais.
  • 28Turi būti užtikrinta, kad projektų duomenys būtų prieinami centralizuotai analitikai, duomenų eksportui ir integracijai su išorinėmis analitikos priemonėmis pagal nustatytas prieigos teises.
  • 29Objekto gyvavimo ciklo duomenys turi būti pasitelkiami vykdant projekto iniciavimą ir planavimą.
  • 30Turi būti galimybė susieti projekto pirkimus, sutartis, sąskaitas, mokėjimus ir turto vienetus su konkrečiu projektu, programa, infrastruktūros objektu ar biudžeto eilute.
  • 31Turi būti galimybė planuoti ir valdyti investicinius (gali apimti daugiau nei vieną infrastruktūros objektą) ir infrastruktūros projektus, taikant bendruosius projekto valdymo principus.
  • 32Infrastruktūros projektą turi būti galima susieti su daugiau nei viena turto kortele, konvertuoti į turto korteles, jas perduodant kitoms grupės organizacijoms.
  • 33Reikalingas funkcionalumas infrastruktūros objektų priežiūrai/remontui/ esminiam pagerinimui planuoti ir valdyti (tiek savo, tiek kitos organizacijos objektus), kuris apima: remonto poreikio fiksavimą, jo prioritetizavimą, infrastruktūros plėtros plano paruošimą ir iš jo formuojamą biudžeto poreikį, remonto/pagerinimo projekto valdymą.
  • 34Turi būti galimybė infrastruktūros projektus susieti su konkrečiais infrastruktūros objektais, žemės sklypais, pastatais, statiniais, patalpomis, inžineriniais tinklais, turto vienetais ir jų techniniais duomenimis.

Suderinamumo Reikalavimai

  • 1ERP sistema turėtų būti sukurta remiantis paskirstyta mikroservisų architektūra su atviromis, gerai dokumentuotomis REST API sąsajomis.
  • 2ERP sistema turi gebėti integruoti bet kokius duomenų šaltinius, nereikalauti specifinių integravimo technologijų.
  • 3ERP sistema turi užtikrinti saugius prisijungimo taškus per standartines populiarias API sąsajas ir jungtis (pvz., REST API, ODBC ir JDBC tvarkykles).
  • 4Prisijungimo technologijos turi atitikti industrijos standartus.
  • 5ERP sistema API sąsajos turi būti saugios, autentifikuotos ir audituojamos.
  • 6ERP sistemoje turi būti įdiegti atskaitomybės mechanizmai, leidžiantys stebėti, kokiais duomenimis, kas ir kada naudojasi, fiksuojamas duomenų keitimo laikas, autorius, kas buvo keista (pokyčių istorija).
  • 7ERP sistema turi saugoti ir gebėti eksportuoti sistemos duomenis atvirais formatais, kad būtų užtikrinta prieiga prie duomenų ir išvengta duomenų naudojimo apribojimų.
  • 8ERP sistema turi turėti galimybę susijungti su kitomis KAS organizacijoje naudojamomis informacinėmis sistemomis.
  • 9ERP sistema turi būti suderinama su egzistuojančiais analitiniais sprendimais (pvz. Tableau, PowerBI ir kt.).
  • 10ERP sistemoje sukurtus duomenis ir artefaktus turi būti galima eksportuoti atvirais formatais, įtraukiant PDF ir DOCX tekstams, CSV ir XLSX struktūrizuotiems duomenims, ir multimedijos formatus (WAV, AVI, MP4).

Licencijavimo Reikalavimai

  • 1Pardavėjas privalo pateikti visą ERP sistemai reikalingą programinę įrangą, operacines sistemas, duomenų bazių programinę įrangą, taikomąsias programas ir kitas ERP sistemos programinės įrangos sudėtines dalis.
  • 2Pardavėjas pateiks visą reikalingą techninę įrangą ir reikalingą virtualizacijos programinę įrangą ERP sistemos instaliacijai duomenų centruose.
  • 3Tiekėjas suteiks nustatytus skaičiavimo resursus privačios debesijos duomenų centruose, suderinęs tinkamumą su Pirkėju.
  • 4Pardavėjas turi užtikrinti savo sukurtos programinės įrangos, kuri įdiegta ERP sistemoje, palaikymą ir atnaujinimą visą sutarties galiojimo periodą.
  • 5Sutartis sudaroma 3 (trims) metams su galimybe pratęsti papildomiems 1 (vieniems) metams.
  • 6Jei kartu su Pardavėjo sukurta programine įranga bus naudojama kitų gamintojų programinė įranga (išskyrus atviro kodo nelicencijuojamą programinę įrangą), Pardavėjas turi pateikti oficialius tokios programinės įrangos gamintojo dokumentus, leidžiančius jam naudoti to gamintojo programinę įrangą.
  • 7Pardavėjas turi užtikrinti tokios programinės įrangos palaikymą ir reguliarų atnaujinimą.
  • 8Pardavėjas, įdiegdamas ERP sistemoje bet kuriuo būdu licencijuojamą (pagal serverių skaičių, pagal procesorių kiekį, ir pagal procesoriaus branduolių kiekį, ir pagal kitus galimus licencijavimo kriterijus) programinę įrangą, privalo pateikti visas įdiegtos programinės įrangos licencijas.
  • 9Prioritetinis yra vieno gamintojo komercinės programinės įrangos naudojimas ERP sistemoje (netaikoma atvirojo kodo programinei įrangai).
  • 10Pardavėjas turi užtikrinti, kad ERP sistemoje naudojama programinė įranga bus palaikoma ir atnaujinama sutarties galiojimo metu griežtai laikantis ERP sistemos gamintojo rekomendacijų.
  • 11Jei ERP sistemoje bus naudojama kito gamintojo komercinė programinė įranga ar jos komponentai ir, jei per Sutarties galiojimo laikotarpį kito gamintojo komercinė programinė įranga bus nebegaminama, nebetiekiama ir nebepalaikoma, Pardavėjas įsipareigoja nemokamai pakeisti tokią programinę įrangą ar jos komponentus naujais.
  • 12Licencijomis neturi būti ribojami šie ERP sistemos funkcionalumo parametrai: įkeliamų duomenų kiekis; saugomų objektų kiekis; prijungiamų duomenų šaltinių kiekis; vienu metu vykdomų užklausų kiekis; bendras ir vienu metu prisijungusių prie ERP sistemos naudotojų kiekis; naudotojų grupių ir naudotojų skaičius.
  • 13Pardavėjas kartu su pasiūlymu turi pateikti informaciją apie bet kokio tipo licencinius programinės įrangos ir funkcionalumo apribojimus.
  • 14Pirkėjas pasilieka visas teises, nuosavybės ir turtinę teisę į visus duomenis, importuotus, kaupiamus ir tvarkomus ERP sistemoje.
  • 15Visos licencijavimo sąlygos galioja Pirkėjui neribotam naudotojų skaičiui.

Kitos Apskaitos Procedūros

  • 1ERP sistemoje turi būti realizuotas Komandiruočių planavimo ir apskaitos sprendimas (komandiruočių tipai: mokymų, tarnybinė, misijos), galimybė komandiruočių duomenis (planas/faktas) pildyti ne tiesiogiai sistemoje, bet per išorinius įrankius.
  • 2ERP turi turėti kontrolę ir funkcionalumą išskaidyti ateinančių laikotarpių sumų paskirstymą.
  • 3ERP sistemoje turi būti realizuotas kaštų analizės sprendimas.
  • 4Turi būti galimybė vesti detalią mažaverčio turto išduodamo asmenims kiekinę apskaitą užbalansinėse sąskaitose.
  • 5Turi būti lengvai realizuotas kuro pirkimo automatizuotas importas į ERP sistemą.

Korupcijos Prevencijos Modulis

  • 1ERP sistemoje turi būti įdiegtas modulis, skirtas korupcijos rizikų, galimų kartelinių susitarimų ir kitų įtartinų veiklos modelių stebėsenai, vertinimui, prioretizavimui ir ataskaitų rengimui.
  • 2Modulis turi remtis: sektorių pagrindų veikiančia rizikų analize; Specialiųjų tyrimų tarnybos korupcijos pasireiškimo tikimybės nustatymo metodika; teisės aktų projektų antikorupcinio vertinimo principais OECD kartelių patikros praktika; kitais tarptautiniais rizikos vertinimo metodais.
  • 3Modulis turi padėti: anksti nustatyti galimas korupcijos rizikas; aptikti galimus kartelinių susitarimų požymius; įvertinti veiklos sričių rizikingumą; atlikti teisės aktų projektų antikorupcinį vertinimą; vertinti rizikas konkrečiuose sektoriuose ir procesuose; pateikti pagrįstus įspėjimus vadovui, auditoriui, tyrimą, analizę atliekančiam asmeniui; kaupti rizikos vertinimo istoriją ir leisti lyginti laikotarpius; stebėti, ar įgyvendinamos rizikos mažinimo priemonės.
  • 4Modulis turi analizuoti ne bendrą korupcijos riziką abstrakčiai, o konkrečias veiklos sritis: pirkimus, finansus, turtą, sutartis, dokumentų derinimą ir projektų vykdymą.
  • 5Modulis turi veikti pagal nuoseklią rizikos valdymo ciklo logiką: nustatoma konkreti veiklos sritis arba procesas; identifikuojami rizikos veiksniai; rizikos suskirstomos pagal pobūdį ir svarbą; nustatomas rizikos lygis pagal tikimybę ir poveikį; pateikiamos rizikos mažinimo priemonės; stebima priemonių įgyvendinimo būklė; kaupiama vertinimo istorija ir palyginamieji duomenys.
  • 6Modulis turi tikrinti duomenų išsamumą ir patikimumą prieš generuodamas įspėjimus.
  • 7Modulis turi analizuoti vidinius ERP duomenis: Viešųjų pirkimų duomenys; Finansų ir mokėjimų duomenys; Sutarčių ir jų pakeitimų duomenys; Personalo ir teisių duomenys; Turto apskaitos duomenys; Dokumentų derinimo ir keitimo istorija; Vidaus teisės aktai ir jų projektai.
  • 8Modulis turi analizuoti išorinius duomenis: Juridinių asmenų registro duomenys; CVP IS pirkimų duomenys; VIISP susiję registrai; Sankcijų sąrašai; Įmonių ryšiai ir savininkai; Privačių interesų deklaracijos; Kiti susiję išoriniai šaltiniai.
  • 9Modulis turi vertinti rizikas bent šiose srityse: Karteliniai susitarimai pirkimuose; Interesų konfliktai; Netipiniai mokėjimai ir sąskaitos; Sutarties skaidymas ir dažni pakeitimai; Neįprasti tiekėjų laimėjimo modeliai; Ilgalaikio ir trumpalaikio turto valdymui būdingi nukrypimai; Rankiniai nustatymai nuo standartinės patvirtinimo procedūros; Darbuotojų veiksmų ir įgaliojimų neatitikimai; Teisės aktų nuostatos, galinčios sudaryti korupcijos prielaidas.
  • 10Rizikos valdymo funkcijos apima tris tarpusavyje susijusias funkcijas, visoms jų taikoma ta pati vykdymo logika: nustatomas objektas, identifikuojami rizikos veiksniai, nustatomas rizikos lygis, priskiriamos mažinimo priemonės ir stebimas jų įgyvendinimas.
  • 11Kiekvienam sektoriui turi būti galima priskirti atskirus rizikos veiksnius, rodiklius ir mažinimo priemones.
  • 12Modulis turi leisti vertinti rizikas pagal konkrečias veiklos sritis atskirai: Viešieji pirkimai; Finansų valdymas; Personalo valdymas; Turto valdymas; Projektų valdymas; Dokumentų tvirtinimas; Sutarčių vykdymas.
  • 13Modulis turi turėti funkciją korupcijos pasireiškimo tikimybei nustatyti pagal galiojančią tvarką ir nustatytus kriterijus.
  • 14Modulis turi leisti pasirinkti vertinamą veiklos sritį; registruoti rizikos veiksnius pagal Specialiųjų tyrimų tarnybos metodologiją; nurodyti rizikos priežastis ir galimas pasekmes; pateikti vertinimo išvadą; priskirti siūlomas priemones rizikai mažinti; sekti priemonių įgyvendinimą; saugoti visų vertinimų istoriją; leisti palyginti skirtingų laikotarpių rezultatus.
  • 15Modulis turi turėti funkciją teisės aktų projektų ir vidaus dokumentų antikorupciniam vertinimui.
  • 16Modulis turi saugoti vertinamo dokumento versiją, vertinimo išvadą, nustatytas rizikas, siūlomus pakeitimus, atsakingo asmens veiksmus ir patvirtinimo istoriją.
  • 17Vertinama, ar: Dokumentas nesukuria perteklinės diskrecijos; Nėra neaiškių ar dviprasmiškų formuluočių; Tinkamai paskirstytos funkcijos ir atsakomybės; Yra pakankamos kontrolės priemonės; Yra pareigų atskyrimas; Nėra spragų, sudarančių galimybę piktnaudžiauti.
  • 18Modulis turi naudoti nustatomus rizikos rodiklius, pagrįstus Specialiųjų tyrimų tarnybos praktika, OECD kartelių patikros metodika ir kitomis tarptautinėmis rizikos analizės praktikomis.
  • 19Rodikliai veikia kaip raudonos vėliavėlės – požymiai, kad situaciją reikia peržiūrėti žmogui.
  • 20Modulis turi leisti keisti rodiklių slenksčius pagal institucijos praktiką ir rizikos toleranciją. Atsakomybė už konfigūravimą turi būti suteikiama kompetentingam vartotojui.
  • 21Stebimi pirkimų ir kartelių rodikliai: Tas pats tiekėjas laimi neįprastai dažnai; Pasiūlymų skaičius neįprastai mažas; Kainos labai panašios tarp skirtingų tiekėjų; Tiekėjai laimi rotacijos principu; Dažni sutarčių pakeitimai po sudarymo; Pasiūlymų dokumentuose kartojasi tie patys šablonai ar metaduomenys; Kiti signalai, rodantys galimą susitarimą.
  • 22Stebimi korupcijos rizikų rodikliai: Tas pats asmuo inicijuoja, derina ir tvirtina veiksmus; Darbuotojas turi per plačias teises; Mokėjimai neatitinka sutarties ir biudžeto logikos; Turtas nurašomas ar perkeliamas netipiškai; Dokumentai dažnai koreguojami po patvirtinimo; Procesai dažnai apeinami rankiniu būdu; Vidaus tvarka sudaro sąlygas neaiškių sprendimų priėmimui.
  • 23Sistema turi naudoti kelis vertinimo lygius: Taisyklėmis grįstas vertinimas – konkrečių slenksčių pažeidimai; Statistinė analizė – nukrypimai nuo vidurkio ar normos; Tendencijų analizė – kitimo per laikotarpį stebėjimas; Ryšių analizė – asmenų, įmonių, dokumentų sąsajos; Rizikos balas – kiekvienam atvejui, subjektui ar sričiai.
  • 24Modulis turi gebėti ne tik aptikti riziką, bet ir ją prioretizuoti: Išskirti aukščiausios rizikos atvejus; Rodyti, kur rizika didžiausia ir kodėl; Padėti pasirinkti, nuo ko pradėti analizę ar kontrolę; Siūlyti, kokios priemonės būtų efektyviausios pirmiausia.
  • 25Modulis turi automatiškai generuoti įspėjimus; priskirti jiems rizikos lygį; pateikti paaiškinimą, kodėl įspėjimas sugeneruotas; rodyti susijusius dokumentus, veiksmus ir asmenis; leisti filtruoti pagal laikotarpį, padalinį, projektą, tiekėją, darbuotoją ar dokumentą.
  • 26Modulis turi turėti mechanizmą, leidžiantį vadovui, auditoriui, tyrimą, analizę atliekančiam asmeniui: pažymėti įspėjimą kaip išnagrinėtą; nurodyti atmetimo priežastį; užregistruoti sprendimą su laiku ir atsakingu asmeniu; sukurti audito pėdsaką kiekvienam įspėjimui.
  • 27Ataskaitos turi būti suprantamos ne tik IT specialistui, bet ir vadovui, auditoriui, tyrimą, analizę atliekančiam asmeniui.
  • 28Modulis turi įdiegti rolėmis grįstą prieigos modelį: Administratorius – pilna prieiga, konfigūravimas, rodiklių slenksčių valdymas; Auditorius – ataskaitos, įspėjimai, vertinimo istorija, klaidingų įspėjimų žymėjimas; Vadovas – suvestinės ataskaitos, prioretizuoti įspėjimai, būklės peržiūra; Tyrimą, analizę atliekantis asmuo – išsamios ataskaitos, ryšių analizė, dokumentų peržiūra; Vidaus kontrolės specialistas – priemonių įgyvendinimo stebėsena, vertinimo įrašai.
  • 29Modulis turi leisti atsekti, kaip rizika atsirado, kaip ji buvo įvertinta ir kokie veiksmai buvo atlikti.
  • 30Modulis turi saugoti: Visus rizikos vertinimus; Visus pakeitimus; Visus įspėjimus ir sprendimus dėl jų; Priemonių įgyvendinimo būklę; Kas, kada ir ką pakeitė.
  • 31Moduliui turi galioti bendrieji reikalavimai: Turi veikti su standartiniais duomenų formatais; Turi naudoti atviras integracijas; Turi turėti aprašytus duomenų laukus; Turi būti integruojamas į skirtingas ERP platformas arba naudojamas kaip integruotas modulis visoje platformoje.
  • 32Modulis turi turėti aiškiai aprašytas integracijas su išorinėmis sistemomis. Būtinos integracijos: Juridinių asmenų registras – įmonių duomenys, savininkai, ryšiai; CVP IS – Centrinė viešųjų pirkimų informacinė sistema; VIISP – valstybės informacinių išteklių sąveikumo platforma; Sankcijų sąrašai – ES, JT, OFAC ir kiti tarptautiniai sąrašai; PINREG – privačių interesų registras.

Iždo Funkcionalumo Reikalavimai

  • 1ERP sistema turi turėti funkcionalumą, reikalingą vykdyti centralizuotus mokėjimus (viena grupės įmonė yra mokančioji organizacija).
  • 2Turi būti realizuota integracija su visais pagrindiniais Lietuvos bankais ir Finansų ministerijos valdoma VIKSVA per API funkcionalumą: automatinis valiutų kursų importas, mokėjimų vykdymas, mokėjimų paraiškų būsenos atnaujinimas.
  • 3Turi būti realizuotas automatinis duomenų apsikeitimas su valstybės iždu (integracija su VBAMS).
  • 4Turi būti realizuotas automatinis mokėjimo paraiškų formavimas ERP sistemoje pagal administruojamas pačių vartotojų taisykles.
  • 5ERP turi turėti galimybę atlikti asignavimų panaudojimo ir atitaisymo (VBAMS) registravimo funkciją mokėjimams per Lietuvos bankus ir VIKSVA.

Palaikymo ir Aptarnavimo Sąlygos

  • 1ERP sistemos ir jos programinei įrangai turi būti teikiamas palaikymas sutarties galiojimo metu.
  • 2Palaikymo metu Tiekėjas privalo užtikrinti ERP sistemos funkcionalumo palaikymą ir reguliarų, programinės įrangos atnaujinimą griežtai laikantis ERP sistemos gamintojo rekomendacijų.
  • 3Palaikymo metu Tiekėjas privalo užtikrinti ERP sistemos funkcionalumo sutrikimo, gedimų/ trūkumų šalinimą.
  • 4Kritinis sutrikimo lygis: Reakcijos laikas 4 darbo valandos; šalinimas ERP sistemos diegimo vietoje per 24 valandas nuo pranešimo apie gedimą gavimo, kol gedimas bus pašalintas.
  • 5Svarbus sutrikimo lygis: Reakcijos laikas 12 darbo valandų; šalinimas ERP sistemos diegimo vietoje per 36 darbo valandas, kol gedimas bus pašalintas.
  • 6Vidutinis sutrikimo lygis: Reakcijos laikas 24 darbo valandos; klaida ištaisoma programinės įrangos atnaujinime.
  • 7Žemas sutrikimo lygis: Reakcijos laikas 60 darbo valandų; klaidos ištaisomos Tiekėjo nustatytais terminais.
  • 8Informacija Pardavėjui apie ERP sistemos funkcionalumo sutrikimus, gedimus/ trūkumus pateikiama Pardavėjo nurodytu elektroniniu paštu ar telefonu.

Duomenų Iškėlimo Funkcionalumas

  • 1ERP sistema turi galėti saugoti ir eksportuoti duomenis atvirais formatais, tokiais kaip CSV ar XLSX.
  • 2Turi būti galimybė ERP sistemos įrankiais sukonfigūruoti duomenų eksportą.
  • 3Turi būti galimybė duomenų rinkinius pagal nustatytą datą ir laiką iškelti po vieną ar daugiau į kitas duomenų bazes, aplikacijas ar failines sistemas.
  • 4ERP sistemoje duomenų atidavimui turi būti iš anksto paruošti prisijungimai prie JDBC, lokalios failų sistemos, HDFS, SFTP, S3, ABFS.
  • 5Turi būti galimybė sistemos administratoriams sukurti norimas spausdinių formas (eksportuojant ir saugant dokumentus Excel, Word ar PDF formatu).

Viešųjų Pirkimų Valdymo Modulis

  • 1ERP sistemoje turi būti modulis, kuris užtikrintų krašto apsaugos sistemos viešųjų pirkimų proceso valdymą, planavimą, kontrolę, analizę ir atsekamumą.
  • 2Sistema turi sudaryti galimybes centralizuotai valdyti visus viešųjų pirkimų proceso etapus – nuo pirkimo poreikio inicijavimo ir planavimo iki sutarčių vykdymo kontrolės bei ataskaitų rengimo.
  • 3Sistema turi sudaryti galimybes realiu laiku stebėti vykdomų pirkimų būsenas, terminus, atsakingus asmenis, pirkimų vertes, sutarčių vykdymą bei biudžeto panaudojimą.
  • 4Taip pat sistema turi sudaryti galimybes atlikti pirkimų duomenų analizę, vertinti pirkimų efektyvumą, identifikuoti rizikas, stebėti tiekėjų aktyvumą bei planuojamų pirkimų poreikius.
  • 5Turi būti įdiegtos duomenų filtravimo, segmentavimo, vizualizavimo ir ataskaitų rengimo galimybės, sudarančios sąlygas efektyviai naudoti duomenis sprendimams pagrįsti.
  • 6ERP sistema turi automatizuoti pagrindinius viešųjų pirkimų procesus, užtikrinti veiksmų atsekamumą, procesų kontrolę, dokumentų valdymą ir efektyvų pirkimų administravimą.
  • 7ERP sistema turi turėti funkcionalumą, skirtą registruoti organizacijos pirkimų poreikius bei inicijuoti pirkimų planavimo procesą.
  • 8Turi būti sudarytos galimybės pateikti pirkimo poreikio pagrindimo informaciją, nurodant pirkimo tikslą, poreikio atsiradimo priežastis, planuojamą naudą organizacijai bei kitą su poreikiu susijusią informaciją.
  • 9Sistema turi užtikrinti preliminarios pirkimo vertės, planuojamų terminų bei kitos su planuojamu pirkimu susijusios informacijos registravimą.
  • 10Turi būti galimybės klasifikuoti ir grupuoti pirkimų poreikius pagal organizacijoje naudojamas kategorijas, tipus ar kitus klasifikatorius.
  • 11Pirkimo iniciatoriui turi būti galimybė atrinkti duomenis iš ERP sistemos funkcinių reikalavimų „Poreikių ir pajėgumų planavimas, Pajėgų vystymas, padalinių parengtis, pajėgų dislokavimo, pajėgų planavimas“ ir kt.
  • 12Turi būti galimybė prie pirkimo poreikio pridėti pagrindžiančius dokumentus, skaičiavimus, technines specifikacijas bei kitą susijusią informaciją.
  • 13Pirkimo iniciatoriui turi būti galimybė surinkti ir inicijuoti duomenų pirkimų planui pateikimą ir registraciją.
  • 14Sistema turi užtikrinti atsakingų asmenų, iniciatorių bei kitų procese dalyvaujančių naudotojų priskyrimą.
  • 15Pirkimo iniciatoriui turi būti galimybė perduoti pirkimo poreikį ir visą susijusią medžiagą atsakingiems asmenims derinimui.
  • 16Pirkimo iniciatoriui turi būti galimybė suderinus pirkimų poreikį perduoti visą susijusią informaciją asmeniui, atsakingam už pirkimų planavimą.
  • 17ERP sistema turi užtikrinti pirkimų poreikių istorijos, atliktų pakeitimų bei naudotojų veiksmų stebėjimą ir atsekamumą.
  • 18Sistema turi turėti funkcionalumą, skirtą formuoti ir valdyti metinį pirkimų planą pagal suderintus pirkimų poreikius, pirkimų organizatorių (PO), pirkimų iniciatorių, sudarant galimybę atsakingam už pirkimų planavimą asmeniui įkelti, suvesti arba importuoti (rankiniu būdu) pirkimų plano eilutes iš duomenų pirkimų planui formų.
  • 19Turi būti galimybė konsoliduoti susijusius pirkimų poreikius bei formuoti planuojamų pirkimų suvestines, užtikrinant galimybę atsakingam už pirkimų planavimą asmeniui koreguoti, apjungti ir /ar panaikinti eilučių apjungimą.
  • 20Sistema turi sudaryti galimybes valdyti planuojamų pirkimų terminus, prioritetus, atsakingus asmenis bei kitą su planavimu susijusią informaciją.
  • 21ERP sistema turi užtikrinti pirkimų plano koregavimo, versijavimo bei pakeitimų istorijos saugojimo funkcionalumą.
  • 22Atsakingas už pirkimų planavimą asmuo: galimybė suformuoti dokumentą Viešųjų pirkimų planą pagal KAS patvirtintas tvarkas.
  • 23ERP sistema turi užtikrinti planinių ir neplaninių pirkimų registravimą bei stebėseną.
  • 24Turi būti galimybė atsakingam už pirkimų planavimą asmeniui inicijuoti automatizuotą plano perkėlimą į CVP IS.
  • 25Turi būti galimybė vykdyti pirkimų plano stebėseną, analizę bei rengti susijusias ataskaitas.
  • 26Sistema turi turėti funkcionalumą, skirtą inicijuoti pirkimo paraišką pagal patvirtintą metinį pirkimų planą ar pirkimo poreikį (išskirtiniais atvejais).
  • 27ERP Sistema turi užtikrinti automatizuotą duomenų perkėlimą iš pirkimų plano ar pirkimo poreikio į pirkimo paraišką.
  • 28ERP sistema turi sudaryti galimybes pildyti ir valdyti pirkimo paraiškos informaciją, įskaitant technines specifikacijas, planuojamą vertę, terminus bei kitą su pirkimu susijusią informaciją.
  • 29ERP sistema turi sudaryti galimybes prie pirkimo paraiškos pridėti susijusius dokumentus bei kitus priedus.
  • 30Sistema turi užtikrinti pirkimo paraiškų derinimo, tvirtinimo ir grąžinimo tikslinimui procesų valdymą.
  • 31Sistema turi sudaryti galimybes stebėti pirkimo paraiškos būseną, terminus bei atsakingus asmenis realiu laiku.
  • 32ERP sistema turi užtikrinti automatinius pranešimus apie laukiančius veiksmus, derinimus ar terminus.
  • 33ERP sistema turi užtikrinti visų veiksmų, pakeitimų ir sprendimų istorijos registravimą bei atsekamumą.
  • 34ERP sistema turi turėti funkcionalumą, skirtą vykdyti ir administruoti pirkimo procedūras pagal patvirtintas pirkimo paraiškas bei organizacijoje nustatytus procesus.
  • 35Sistema turi sudaryti galimybes valdyti skirtingus pirkimo būdus, pirkimo eigą, terminus bei su pirkimu susijusią informaciją.
  • 36Pirkimo vykdytojas: formuoti elektroninę pirkimo bylą, kurioje yra vykdomi ir saugomi elektroniniai dokumentai (susiję su viešojo pirkimo procedūrų vykdymu). Bylą suskirstyti į aplankus: pirkimų planas; pirkimo dokumentai; protokolai; skelbimai; pasiūlymai; susirašinėjimas; pretenzijos sutartys; sutartys.
  • 37ERP sistema turi užtikrinti pirkimo dokumentų rengimą, derinimą, saugojimą ir valdymą viso pirkimo proceso metu.
  • 38Pirkimo vykdytojas: automatizuoti pirkimo dokumentų šablonai.
  • 39Turi būti galimybės administruoti technines specifikacijas, kvalifikacinius reikalavimus, vertinimo kriterijus bei kitus su pirkimu susijusius dokumentus.
  • 40Turi būti galimybė Pirkimo vykdytojui inicijuoti automatizuotą skelbimo perkėlimą į CVP IS.
  • 41Turi būti funkcionalumas Pirkimo vykdytojui inicijuoti automatizuotą pirkimų procedūrų dokumentų formavimą, dokumentų perkėlimą (importavimą) iš CVP IS.
  • 42Sistema turi sudaryti galimybes registruoti, valdyti ir saugoti komunikaciją su tiekėjais, klausimus, paaiškinimus bei kitą su pirkimu susijusią informaciją.
  • 43Sistema turi užtikrinti pirkimo proceso būsenų, terminų, atsakingų asmenų bei atliktų veiksmų stebėseną ir atsekamumą.
  • 44Turi būti pirkimo komisijų sudarymo, komisijos narių paskyrimo bei komisijos veiklos administravimo funkcionalumas.
  • 45ERP sistema turi sudaryti galimybes generuoti su pirkimo vykdymu susijusias suvestines, dokumentus ir ataskaitas.
  • 46Sistema turi turėti funkcionalumą, skirtą registruoti, administruoti ir vertinti tiekėjų pateiktus pasiūlymus.
  • 47ERP sistema turi sudaryti galimybes nustatyti ir valdyti pasiūlymų vertinimo kriterijus.
  • 48ERP sistema turi užtikrinti individualaus ir komisijos vertinimo proceso administravimą.
  • 49ERP sistema turi sudaryti galimybes vykdyti pasiūlymų palyginimą pagal nustatytus kriterijus bei registruoti vertinimo rezultatus.
  • 50ERP sistema turi užtikrinti vertinimo protokolų, sprendimų bei kitos su vertinimu susijusios informacijos formavimą ir saugojimą.
  • 51ERP sistema turi užtikrinti pasiūlymų vertinimo proceso, atliktų veiksmų ir sprendimų stebėseną bei atsekamumą.
  • 52Sistema turi turėti funkcionalumą, skirtą administruoti sutarčių sudarymo ir vykdymo procesus.
  • 53Sistema turi sudaryti galimybes rengti, derinti, tvirtinti ir registruoti sutartis bei jų priedus.
  • 54Sistema turi užtikrinti sutarčių numeracijos, galiojimo terminų bei susijusios informacijos valdymą.
  • 55Sistema turi sudaryti galimybes registruoti ir valdyti sutarties pakeitimus bei saugoti pakeitimų istoriją.
  • 56Sistema turi užtikrinti sutarčių vykdymo, terminų, įsipareigojimų bei susijusių veiksmų stebėseną.
  • 57ERP sistema turi sudaryti galimybes registruoti informaciją apie mokėjimus, pristatymus bei kitus su sutarties vykdymu susijusius duomenis.
  • 58Už sutarties vykdymą atsakingas asmuo: sekti sutarties vykdymą (kiekine ir sumine išraiška), formuoti sutarties vykdymo ataskaitas.
  • 59Sistema turi užtikrinti automatinių pranešimų ir priminimų generavimą apie sutarties terminus, pakeitimus ar kitus svarbius įvykius.
  • 60ERP sistema turi užtikrinti sutarčių vykdymo proceso, atliktų veiksmų ir sprendimų atsekamumą.
  • 61Sistema turi turėti funkcionalumą, skirtą vykdyti viešųjų pirkimų procesų stebėseną, analizę ir kontrolę.
  • 62ERP sistema turi sudaryti galimybes realiu laiku stebėti pirkimų, sutarčių, terminų bei kitų procesų būsenas.
  • 63Turi būti užtikrinti pirkimų, sutarčių, tiekėjų bei biudžeto duomenų analizės funkcionalumai.
  • 64ERP sistema turi sudaryti galimybes vykdyti planinių ir faktinių duomenų palyginimą bei stebėti procesų vykdymo rodiklius.
  • 65ERP sistema turi užtikrinti veiksmų istorijos, auditavimo informacijos bei procesų atsekamumo peržiūrą.
  • 66Sistema turi sudaryti galimybes vykdyti duomenų paiešką, filtravimą, segmentavimą bei grupavimą pagal skirtingus kriterijus.
  • 67ERP sistema turi užtikrinti duomenų vizualizavimo, suvestinių bei standartinių ir naudotojo formuojamų ataskaitų rengimo funkcionalumus.
  • 68Ataskaitų rengimas: automatizuoti reikalingų registrų pildymai.
  • 69Ataskaitų rengimas: automatizuotas patvirtintų efektyvumo kriterijų (KPI) atvaizdavimas (grafinis ir lentelių forma).
  • 70ERP sistema turi sudaryti galimybes eksportuoti duomenis ir ataskaitas į skirtingus formatus.
  • 71ERP sistema turi užtikrinti KPI, veiklos rodiklių bei kitų analitinių duomenų stebėseną.
  • 72ERP sistema turi turėti funkcionalumą, skirtą administruoti viešųjų pirkimų procese dalyvaujančius naudotojus, jų roles, teises ir atsakomybes.
  • 73Sistema turi sudaryti galimybes valdyti pirkimų organizatorių, iniciatorių, komisijų narių, derinančių bei kitų procese dalyvaujančių asmenų priskyrimą.
  • 74ERP sistema turi užtikrinti naudotojų teisių ir prieigų administravimą pagal organizacijoje nustatytas roles ir atsakomybes.
  • 75ERP sistema turi sudaryti galimybes administruoti pirkimų procesų eigą, būsenas, terminus bei automatinius pranešimus.
  • 76ERP sistema turi užtikrinti elektroninio pasirašymo funkcionalumą pirkimo procese dalyvaujantiems asmenims.
  • 77ERP sistema turi sudaryti galimybes administruoti dokumentų šablonus, numeraciją, klasifikatorius bei kitus su viešųjų pirkimų procesu susijusius nustatymus.
  • 78ERP sistema turi užtikrinti delegavimo funkcionalumą naudotojų nebuvimo laikotarpiu.
  • 79ERP sistema turi sudaryti galimybes administruoti organizacinę struktūrą, padalinius bei su pirkimų procesu susijusius naudotojų duomenis.
  • 80ERP sistema turi užtikrinti visų administravimo veiksmų istorijos, pakeitimų ir naudotojų veiksmų atsekamumą.
  • 81Sistema turi turėti funkcionalumą, skirtą administruoti ir valdyti viešųjų pirkimų procese naudojamas duomenų ir reikšmių bazes: BVPŽ kodai, pirkimo būdai, kvalifikaciniai reikalavimai, nušalinimo pagrindai, tiekėjų sąrašai, KAS darbuotojų sąrašai ir kt.
  • 82ERP sistema turi užtikrinti integracijų su išorinėmis informacinėmis sistemomis funkcionalumą, sudarant galimybes automatizuotai gauti, tikrinti ir sutikrinti viešųjų pirkimų procese naudojamus duomenis, įskaitant pirkimų procese dalyvaujančių asmenų, tiekėjų ir kitų susijusių subjektų duomenis, su išorinių sistemų duomenimis, įskaitant, bet neapsiribojant, PINREG, CVP IS bei kitomis susijusiomis informacinėmis sistemomis.

Bendrieji Architektūros Reikalavimai

  • 1ERP sistema turi palaikyti galimybes panaudoti Pirkėjo pasirinktus komercinius ar atvirų šaltinių Dirbtinio Intelekto modelius naudojant standartines sąsajas.
  • 2ERP sistema turi turėti galimybes naudoti modelius veikiančius debesijoje ir modelius veikiančius Pirkėjo duomenų centruose be ryšio su internetu.
  • 3ERP sistemą turi būti galima atnaujinti be veiklos sustabdymo.
  • 4Tiekėjas turi naudoti nuolatinės integracijos / nuolatinio diegimo metodą, kad atnaujinimai ir kiti konfigūracijos pakeitimai ERP sistemai būtų taikomi be veiklos sustabdymo arba su nedideliu poveikiu visai ERP sistemai.
  • 5ERP sistema įgalina atitinkamas teises turinčius naudotojus ERP sistemos įrankiais kurti automatinius duomenų įkėlimo ir iškėlimo mechanizmus taip, kad KAS sistemos, valstybės ir savivaldybių institucijų bei įstaigų, taip pat kitų atvirų šaltinių duomenys, esantys jų informacinėse sistemose, svetainėse ar kitur, galėtų būti naudojami kaip ERP sistemoje, taip ir už jos ribų.
  • 6Palaikyti paskirstytas, saugias ir plačiai pasiekiamas duomenų saugojimo infrastruktūras.
  • 7ERP sistema turi būti sukurta ir įdiegta tokiu būdu, kad galėtų veikti neįslaptintuose ir įslaptintuose tinkluose bei atitikti jų reikalavimus.
  • 8ERP sistema turi būti parengta ir tinkamai konfigūruota sudarant prielaidas suinteresuotų išorės šalių prijungimui duomenų mainams atitinkamos klasifikacijos tinkluose, bei bendram darbui su autorizuotais partneriais.

Gautinų ir Mokėtinų Sumų Valdymas

  • 1ERP sistemoje turi būti realizuota integracija su sąskaitų administravimo bendrąja informacine sistema (SABIS) bei integruotų sąskaitų automatinis apdorojimas.
  • 2ERP sistemoje turi būti gautų sąskaitų faktūrų ir kitų dokumentų (pvz., pirkimo užsakymų) tvirtinimo sekos valdymas (galimybė tam tikriems sistemos vartotojams administruoti nustatymus be programavimo paslaugų).
  • 3Tvirtinimo funkcionalumas turi turėti savyje ir pavadavimo vedimo ir taikymo galimybes.
  • 4Turi būti realizuotas vienos pirkimo SF registravimas pagal daugiau nei vieną finansinių dimensijų rinkinį.
  • 5ERP sistemoje turi būti realizuotas automatizuotas skolų su tiekėjais derinimo procesas.

Finansų Planavimo ir Apskaitos Modulis

  • 1ERP sistemoje turi būti moduliai, kurie užtikrintų Krašto apsaugos sistemos teisingą ir tikslią ūkinių operacijų registravimą, planavimą ir analizę, vadovaujantis Lietuvos Respublikos teisės aktais, reglamentuojančiais finansinę apskaitą, taip pat Viešojo sektoriaus apskaitos ir finansinės atskaitomybės standartų (VSAFAS) nuostatomis.
  • 2Sistema turi sudaryti galimybes realiu laiku matyti duomenis apie KAS institucijų finansinę būklę, formuoti tiek kiekvienos KAS institucijos finansines ataskaitas vadovaujantis VSAFAS reikalavimais, tiek ruošti konsoliduotųjų finansinių ataskaitų rinkinį.
  • 3KAS institucija laikoma atskiru apskaitos vienetu ir į finansinių ataskaitų rinkinį turi būti įtrauktas tik KAS institucijos nuosavas ir patikėjimo teise valdomas, naudojamas ir disponuojamas valstybės ar savivaldybės turtas, finansavimo sumos ir įsipareigojimai, grynasis turtas, pajamos ir sąnaudos bei pinigų srautai.
  • 4ERP sistema turi automatizuoti pagrindinius finansų ir apskaitos valdymo procesus.

Ilgalaikio Turto Apskaitos Reikalavimai

  • 1Ilgalaikio turto apskaita turi būti apskaitoma vadovaujantis atitinkamais VSAFAS skyriais.
  • 2Turtą turi būti galima grupuoti detaliau nei apibrėžta finansinių ataskaitų teikime, taip pat papildomai grupuoti pagal valdymo pobūdį (nuosavas; valdomas, naudojamas ir disponuojamas patikėjimo teise; nuomojamas; išnuomotas; naudojamas pagal panaudą; atiduotas panaudai; įsigytas pagal sutartis, atitinkančias finansinės nuomos (lizingo) sutartis; gautas pasaugai; atiduotas pasaugai, naudojamas pagal nuomos sutartį), naudojimo būklę (naudojamas veikloje; nenaudojamas veikloje).
  • 3Turtą, gautą pagal panaudos ar nuomos sutartį, turi būti galima apskaityti užbalansinėse sąskaitose.
  • 4ERP sistemoje turi būti realizuoti keli turto apskaitos metodai: įsigijimo savikainos ir tikrosios vertės (Žemė, kilnojamosios, nekilnojamosios kultūros vertybės ir kitos vertybės).
  • 5ERP sistemoje turi būti galima suformuoti įvedimo į eksploataciją, turto pripažinimo nereikalingu ar netinkamu naudoti, turto likvidavimo ar nurašymo aktą, turto inventorizacijos aprašą, dokumentuose atspindint visus reikalingus apskaitos duomenis.
  • 6ERP sistemoje turi būti galimybė registruoti tokias ilgalaikio turto operacijas: įsigijimas, pasigaminimas, turto mainai, gavimas neatlygintinai, nuvertėjimas, vertės didinimas/mažinimas, perkainojimas, nurašymas, pardavimas/perleidimas kitai institucijai.
  • 7Taip pat turi būti galima fiksuoti su turtu susijusias remonto išlaidas, kurios nedidina turto vertės.
  • 8Visos turto operacijos turi būti tinkamai atspindimos apskaitoje pagal VSAFAS nuostatas.
  • 9Ilgalaikio turto vertes turi būti galima apskaityti pagal daugiau nei vieną finansavimo šaltinį.
  • 10ERP sistema turi formuoti ataskaitas skirtingais pjūviais (pagal pavadinimą, kodą, atsakingą, vietą, likutį, įsigijimo savikainą, didžiosios knygos sąskaitą, dimensijas, disponavimą, būklę ir t.t.).

Naudotojų Teisių Valdymo Funkcionalumas

  • 1ERP sistema turi užtikrinti išsamią ir plečiamą prieigos kontrolės infrastruktūrą, kad Užsakovas galėtų įdiegti atitinkamus saugumo teisių lygius ir saugumo žymas.
  • 2ERP sistema turi suteikti administratoriams galimybę apibrėžti ir įgyvendinti labai detalias teisių schemas iki pat langelio ar eilutės lygio.
  • 3Administratoriai turi turėti galimybę naudotojams ir grupėms priskirti konkrečias prieigos teises, kurios reglamentuoja, kaip jie sąveikauja su bet kokiu ištekliu ar duomenimis.
  • 4ERP sistema turi turėti prieinamą ir intuityvią vartotojo sąsają duomenų prieigos teisėms konfigūruoti ir valdyti.
  • 5Naudodamiesi šia sąsaja administratoriai turi galėti kurti, testuoti, įgyvendinti ir valdyti saugumo politiką.
  • 6ERP sistema turi leisti administratoriams peržiūrėti prieigos teisių politiką prieš ją įgyvendinant.
  • 7ERP sistema turi užtikrinti prieigos kontrolės priemonių paskirstymą ir paveldėjimą visiems duomenims ir analizėms, tiesiogiai ar netiesiogiai išvestiems iš pradinių duomenų.
  • 8Šis prieigos kontrolės priemonių paskirstymas turi būti vykdomas iki pat galutinio naudotojo aplikacijos, kad būtų užtikrintas prieigos kontrolės vientisumas visoje ERP sistemoje.
  • 9ERP sistema turi užtikrinti tikslais pagrįstą prieigos kontrolę, kurios pagalba būtų galima nustatyti, kad naudotojai, prieš pradėdami dirbti su konkrečiais duomenų rinkiniais, turėtų paprašyti prieigos, pateikti pagrindimą ir gauti patvirtinimą.
  • 10ERP sistema turi užtikrinti saugumo žymomis pagrįstą prieigos kontrolę, kad administratoriai galėtų apibrėžti naudotojų prieigą prie saugumo žymomis apsaugotų išteklių.
  • 11ERP sistema turi užtikrinti rolėmis pagrįstą prieigos kontrolę, kad administratoriai galėtų nustatyti, kokius duomenis naudotojai gali matyti ir kokius veiksmus jie gali atlikti, remdamiesi savo individualiomis rolėmis ir naryste grupėse (pvz., skaityti, rašyti, valdyti, atrasti).
  • 12ERP sistema turi užtikrinti atributais pagrįstą prieigos kontrolę, kad administratoriai galėtų apibrėžti naudotojų prieigą prie duomenų pagal atributus (pvz., naudotojų atributus, su duomenimis susijusius atributus).
  • 13Visos prieigos kontrolės priemonės atskiriems naudotojams ar naudotojų grupėms turi būti priskiriamos administratorių ir (arba) paveldimos iš šaltinio sistemų bei gali būti atnaujinamos bet kuriuo metu.
  • 14ERP sistema turi leisti nustatyti pasirinktinius rolių apibrėžimus konkrečioms darbo užduotims, o ne reikalauti naudoti pagal nutylėjimą nustatytas naudotojų roles (pvz., administratorius ir paprastas naudotojas).
  • 15ERP sistema turi leisti atskiriems naudotojams priskirti konkrečius prieigos prie duomenų lygius, įskaitant nuosavybės, rašymo, skaitymo teises ir prieigos neturėjimą.
  • 16ERP sistema turi palaikyti išteklių saugojimą katalogų hierarchijoje.
  • 17ERP sistema turi palaikyti pagrindinių katalogų kūrimą, į kuriuos naudotojai turi turėti galimybę dėti išteklius pagal jų šaltinį, organizacijos struktūrą, projektinę veiklą ar kitą loginę tvarką.
  • 18Kataloguose naudotojai turi turėti galimybę dėti išteklius ar kitus (vaikinius) katalogus.
  • 19Turi būti galimybė kiekvieną katalogą hierarchijoje apsaugoti prieigos teisėmis. Vaikiniai katalogai ir ištekliai turi perimti savo prieigos teises iš visų savo tėvinių katalogų.
  • 20Naudotojų paieškos rezultatuose rodomi ištekliai turi atitikti kiekvieno iš rodomų išteklių prieigos teises: turi būti rodomi tik tie ištekliai, kuriuos ieškantis naudotojas turi teises matyti.
  • 21ERP sistema turi palaikyti išteklių apsaugojimą saugumo žymomis.
  • 22Papildomai prie aukščiau aprašytų prieigos teisių, turi būti galimybė ištekliams suteikti vieną ar kelias saugumo žymas.
  • 23Turi būti galimybė naudotojams ir grupėms suteikti prieigą prie vienos ar kelių saugumo žymų. Saugumo žymų naudotojams priskyrimą turi galėti atlikti tik naudotojai, turintys atitinkamas teises.
  • 24Ištekliai kataloguose turi paveldėti katalogams priskirtas saugumo žymas.
  • 25Ištekliai, kurie naudoja duomenis iš kitų saugumo žymomis apribotų išteklių, turi paveldėti jų saugumo žymas.
  • 26Saugumo žymos atsiradimas ant išteklių turi apriboti naudotojų turėtas prieigos prie išteklių teises.
  • 27Naudotojas privalo turėti kiekvieną išteklių saugumo žymą tam, kad galėtų pasiekti išteklius.
  • 28Naudotojai turi negalėti priskirti ištekliams tokios saugumo žymos, po kurios priskyrimo jie patys nebegalėtų pasiekti išteklių.
  • 29ERP sistema RESTful API turi palaikyti ilgalaikį prisijungimą iš išorinių sistemų: ERP sistema turi galėti išduoti ilgalaikį prisijungimo atpažinimo ženklą ar slaptažodžius, kuriuos išorinės sistemos galėtų panaudoti automatizuotai pasiekiant sistemos išteklius naudojantis RESTful API.
  • 30Turi būti įmanoma lengvai atšaukti tokius atpažinimo ženklus ar slaptažodžius, jei jie būtų prarasti ar paviešinti už ERP sistema ribų.
  • 31ERP sistema turi užtikrinti įslaptintos informacijos žymėjimą slaptumo žymomis.
  • 32ERP sistema turi sudaryti galimybę nustatyti naudotojų teises ir leistinus veiksmus dirbant su tvarkoma įslaptinta informacija.
  • 33ERP sistemoje turi būti galimybė kontroliuoti naudojimąsi įslaptinta informacija griežtai laikantis principo „būtina žinoti“.

Poreikių ir Pajėgumų Planavimo Modulis

  • 1Planavimo scenarijai: taikos ir karo metas, misijos ir operacijos. Papildomai įtraukiant į planavimą tiek infrastruktūros, įrangos, ginklų sistemų, atsargų, personalo poreikį pagal turimas kompetencijas.
  • 2Sistema turi leisti pajėgumų planavimą susieti su gynybos planavimo scenarijais, grėsmėmis, karinėmis užduotimis bei NATO įsipareigojimais.
  • 3Planavimą turi būti galima atlikti nedetalizuojant konkrečiais atsargų kodais, bet bendrais turto/atsargos kodais pagal produkto parametrus.
  • 4Turi būti galimybė vėlesniuose planavimo etapuose bendrus poreikius detalizuoti iki konkrečių elementų, gaminių, atsargų, įrangos ar infrastruktūros objektų lygmens.
  • 5Planavime turi būti galimybė nurodyti reikalingas lokacijas, atsargų tiekimo šaltinį (sandėlį/tiekėją), numatomą pajėgų išvystymo terminą, padalinį/kaštų centrą.
  • 6Papildomai turi būti galima nurodyti atsakingus padalinius, priemonių įgyvendinimo laikotarpius, finansavimo šaltinius, projektus, priemonių grupes ir jų tarpusavio priklausomybes laike.
  • 7Pajėgumų sąrašo prioritetizavimas, aprašant pajėgumų svarbos kriterijus, ryšį su NATO įsipareigojimais ir pan. bei galimybę suformuoti prioritetinių pajėgumų sąrašą, sąsaja su parengtu pajėgumų vystymo planu.
  • 8Prioritetizavimas turi būti vykdomas pagal konfigūruojamus kriterijus ir jų svarbos koeficientus, sudarant galimybę įvesti ekspertinius vertinimus ir automatiškai apskaičiuoti bendrą prioritetinį balą.
  • 9Pajėgumų vystymo planų ruošimas, įvertinant finansinių išteklių ir kt. apribojimus. Turi būti galima suformuoti 10 ir 3 metų numatomus vystymo planus.
  • 10Pajėgumų vystymo planai turi būti rengiami pagal DORSAPLIS dalis: doktrininę, organizacinę, rengimo, sistemų, aprūpinimo, personalo, lyderystės, infrastruktūros ir sąveikumo.
  • 11Sistema turi leisti valdyti pajėgumų vystymo plano kortelę, plano būsenas, versijas, atsakingus asmenis ir susijusius dokumentus.
  • 12Pajėgumų vystymo planų ir organizacinės sistemos ir įrangos lentelė (OSĮL) / personalo aprūpinimo lentelė (PAL) ĮL sąsajos. Įkelti į pajėgumų vystymo planus trūkstamą įrangą/infrastruktūrą pagal susietų OSĮL/PAL ĮL siektinus kiekius ir turimus kiekius.
  • 13Naujų OSĮL/PAL ĮL kūrimas pajėgumų vystymo planų pagrindu.
  • 14Tėvinių (be padalinių) ir vaikinių (su padaliniais) OSĮL/PAL ĮL ryšys.
  • 15Peržiūrėti informaciją ar pagal pasirinktą OSĮL/PAL ĮL yra suplanuotų poreikių, suplanuotų ar vykdomų pirkimų, vykdomų sutarčių.
  • 16Sistema turi užtikrinti OSĮL/PAL ĮL versijavimą, siektinos ir faktinės būsenos palyginimą, tvirtinimo būsenų valdymą bei ryšį su pajėgumų vystymo planais, poreikių planais, pirkimais, sutartimis, projektais, atsargomis, infrastruktūra ir personalo duomenimis.
  • 17Pajėgumų planavimo funkcionalumas turi būti susietas su kitais sistemos moduliais, pavyzdžiui atsargų, personalo, biudžeto ar pirkimų valdymu.
  • 18Taip pat turi būti užtikrintas ryšys su finansų planavimo, projektų valdymo, sutarčių valdymo, turto valdymo, logistikos, infrastruktūros, kovos platformų ir ataskaitų formavimo funkcionalumais.
  • 19ERP sistemoje turi būti realizuotas pajėgumų katalogo funkcionalumas, leidžiantis registruoti, klasifikuoti, grupuoti ir naudoti pajėgumus visuose susijusiuose planavimo, poreikių nustatymo, prioritetizavimo ir vystymo procesuose.
  • 20Pagal aprašytus pajėgumų ir pajėgų planus galimybė automatiškai inicijuoti norimo lygio ir apimties įsigijimą/tiekimą/judėjimą tarp lokacijų.
  • 21Turi būti galima sekti pajėgumų vystymo būseną (trūkstamų, perteklinių ir reikiamų išlaikyti pajėgumų sąrašas).
  • 22Pajėgumų būsenos turi būti sekamos pagal patvirtintus planus, įgyvendinamas priemones, finansavimo būklę, pirkimų eigą, sutarčių vykdymą, pristatymo terminus, personalo komplektavimą ir faktinį pajėgumo pasiekimo lygį.
  • 23Sistema turi sudaryti galimybę pajėgumų vystymo plano priemones apjungti į projektus ir priemonių grupes, valdyti jų perkėlimą tarp metų, priklausomybes, prioritetus, atsakingus vykdytojus ir būsenas.
  • 24Pagal pajėgumų ir pajėgų planus galima vykdyti priežiūra, atlikti pakeitimus, planuoti naujas misijas/operacijas, vykdyti personalo samdos procedūras.
  • 25Sistema turi leisti periodiškai peržiūrėti ir atnaujinti pajėgumų vystymo planus, registruoti pakeitimus, saugoti versijų istoriją, atlikti palyginimą tarp ankstesnių ir naujų planų versijų bei užtikrinti pakeitimų atsekamumą.
  • 26Sistema turi leisti vertinti pajėgumo palaikymo poreikius per visą jo gyvavimo ciklą, įskaitant personalo, atsargų, infrastruktūros, įrangos, ginklų sistemų, priežiūros, remonto ir finansavimo poreikius.
  • 27ERP sistemoje turi būti realizuotas centralizuotas poreikių, resursų ir planavimo pagrindimo funkcionalumas, leidžiantis vykdyti funkcinį ir nefunkcinį planavimą bet kuriame planavimo etape, įskaitant KAM Gynybos planavimo departamento, Gynybos štabo J55, Gynybos resursų agentūros prie KAM ir kitų KAS planavimo procese dalyvaujančių institucijų poreikius.
  • 28Sistema turi leisti formuoti detalų planą iš atskirų pajėgumų, programų, priemonių, projektų, veiklų, infrastruktūros, įrangos, personalo, finansavimo, atsargų ir kitų resursų poreikių, išlaikant ryšį tarp pirminio poreikio, pagrindžiančių dokumentų, skaičiavimų, finansavimo šaltinių, atsakingų padalinių ir įgyvendinimo būsenų.
  • 29Sistema turi leisti vykdyti planavimą pagal skirtingus planavimo lygmenis ir etapus: strateginį, operacinį ir taktinį planavimą; ilgalaikį, vidutinės trukmės ir trumpalaikį planavimą; 10 metų, 3 metų ir einamųjų metų planavimo ciklus.
  • 30Sistema turi leisti registruoti ir planuoti tiek funkcinius poreikius, tiesiogiai susijusius su pajėgumo sukūrimu ar palaikymu, tiek nefunkcinius poreikius, reikalingus pajėgumo įgyvendinimui, pavyzdžiui: finansavimą, personalą, infrastruktūrą, informacines sistemas, ryšius, logistiką, atsargas, techninę priežiūrą (įskaitant FSR paslaugas ir sutartis), mokymą, dokumentus, leidimus, priklausomybes nuo kitų projektų ar sprendimų.
  • 31Sistema turi leisti prie kiekvieno pajėgumo, plano, priemonės ar poreikio priskirti pagrindžiančius dokumentus, sprendimus, skaičiavimus, metodikas, finansinius duomenis, personalo duomenis, OSĮL/PAL duomenis, infrastruktūros duomenis, pirkimų duomenis, sutarčių duomenis ir kitą planavimo pagrindimui reikalingą informaciją.
  • 32Sistema turi automatiškai tikrinti planavimo duomenų susikirtimus, dubliavimąsi, neatitikimus ir galimus trūkumus tarp skirtingų planų, pajėgumų, priemonių, projektų, finansavimo šaltinių, personalo poreikių, atsargų, infrastruktūros, pirkimų ir sutarčių.
  • 33Sistema turi identifikuoti situacijas, kai poreikis gali būti suplanuotas nepakankamai, perteklinai arba ne iki galo pagrįstai, pavyzdžiui: trūksta finansavimo, nenumatytas personalas, nesuplanuota infrastruktūra, nėra pirkimo priemonės, nėra sutarties, dubliuojasi poreikiai, nesutampa terminai, suplanuotas pajėgumas neturi visų būtinų resursų arba tas pats resursas priskirtas keliems nesuderinamiems planams.
  • 34Sistema turi gebėti pagal kitų ERP sistemos modulių duomenis, įskaitant finansų, personalo, pirkimų, sutarčių, atsargų, turto, infrastruktūros, logistikos ir projektų valdymo modulius, automatiškai pateikti planavimo rizikas, neatitikimus, trūkstamus duomenis ir siūlomus koregavimo veiksmus.
  • 35Sistema turi palaikyti didelių kalbos modelių (LLM) funkcionalumą, kuris, naudodamasis ERP sistemoje esančiais duomenimis ir naudotojo teisėmis, galėtų pateikti planavimo pasiūlymus, įspėti apie galimus planavimo susikirtimus, pasiūlyti trūkstamus resursus, paaiškinti neatitikimus ir padėti naudotojui pagrįsti planavimo sprendimus.
  • 36LLM funkcionalumas turi veikti kaip pagalbinis sprendimų palaikymo įrankis, o ne kaip savarankiškai sprendimus priimantis mechanizmas.
  • 37Visi LLM pateikti pasiūlymai, įspėjimai ar rekomendacijos turi būti patvirtinami atsakingo naudotojo ir turi būti atsekami audito žurnaluose.
  • 38Sistema turi leisti formuoti skirtingas plano versijas, palyginti versijas tarpusavyje, matyti pasikeitimus tarp planavimo ciklų, saugoti istorinius duomenis ir užtikrinti planavimo sprendimų atsekamumą nuo pirminio poreikio iki galutinio finansavimo, pirkimo, įsigijimo, pristatymo ar įgyvendinimo.
  • 39Sistema turi leisti naudotojams pagal suteiktas teises kurti, koreguoti, tvirtinti, derinti ir peržiūrėti planavimo duomenis, užtikrinant skirtingų institucijų ir padalinių atsakomybių atskyrimą, duomenų matomumo valdymą, tvirtinimo eigą ir bendrą planavimo proceso kontrolę.
  • 40Sistema turi sudaryti galimybę rengti ataskaitas ir suvestines pagal pajėgumus, planus, priemones, DORSAPLIS dalis, finansavimo šaltinius, metus, institucijas, padalinius, projektus, pirkimus, sutartis, personalo poreikius, infrastruktūros poreikius ir kitus naudotojo pasirinktus pjūvius.
  • 41Sistema turi leisti iš detaliojo plano duomenų formuoti finansinių išteklių planavimo, biudžeto planavimo, pirkimų planavimo, sutarčių vykdymo, projektų valdymo ir resursų paskirstymo duomenis, užtikrinant, kad planavimo informacija nebūtų vedama kelis kartus skirtinguose moduliuose.

Saugumo ir Veiklos Tęstinumo Reikalavimai

  • 1Pardavėjas turi vadovautis Pirkėjo nustatytais kibernetinio saugumo politikos dokumentų reikalavimais, apimančiais incidentų, pokyčių, pataisų, spragų valdymo tvarkomis, žurnalinių įrašų administravimo ir saugojimo, įsibrovimų aptikimo ir prevencijos reikalavimais.
  • 2Siekiant užtikrinti perduodamos informacijos saugą, turi būti naudojama ne žemesnė nei TLS 1.2 arba naujesnė kriptografijos protokolo versija šiuose komunikacijos scenarijuose: sistema–naudotojas ir pagal poreikį sistema–sistema.
  • 3Duomenys platformoje turi būti šifruojami tiek tranzito perdavimo metu, tiek ramybės saugojimo metu, laikantis KSRA 4 lentelėje esminiam kibernetiniam subjektui numatytų reikalavimų.
  • 4ERP sistemoje turi būti užtikrintas automatizuotas visos ERP sistemoje vykdomos veiklos stebėjimas, įskaitant naudotojo, administratoriaus ir sistemos veiklą visuose jos komponentuose, laikantis KSRA 1 lentelėje esminiam kibernetiniam subjektui numatytų reikalavimų.
  • 5Audito žurnalai turi būti išsamūs ir patikimi, saugomi tokiu formatu, kad juos būtų paprasta interpretuoti ir bet kuriuo metu būtų galima eksportuoti analizei įprastais formatais į Pirkėjo turimas auditavimo priemones.
  • 6ERP sistema turi būti prieinama ne mažiau kaip 99 proc. laiko palaikyti aukštą prieinamumą ir tęsti veiklą įvykus pavieniams aparatinės įrangos komponentų gedimams.
  • 7Pirkėjas turi turėti galimybę sukurti visų ERP sistemoje esančių duomenų atsargines kopijas saugojimui pasirinktoje vietoje, laikantis KSRA 2 lentelėje esminiam kibernetiniam subjektui numatytų reikalavimų.
  • 8ERP sistema turi palaikyti savaiminį atsistatymą pavienių aparatinės įrangos gedimų atveju ir palaikyti pilną atkūrimą iš atsarginės kopijos katastrofinio gedimo atveju.
  • 9ERP turi užtikrinti VTPĮ ir VTPĮ įgyvendinančių teisės aktų (įskaitant LRV 820 ir LRV 40-1 nutarimus) nustatytų saugumo reikalavimų ĮIRIS įgyvendinimą, taip pat tų KSRA techninių reikalavimų, kurie neprieštarauja VTPĮ ir jo įgyvendinančių teisės aktų nustatytiems saugumo reikalavimams.

Biudžeto Planavimo ir Valdymo Reikalavimai

  • 1Biudžeto planavimas turi būti ERP sistemoje pagal finansines dimensijas, numatytas Strateginio valdymo įstatyme (Ekonominė išlaidų klasifikacija, Programa, Priemonės, Finansavimo šaltiniai, Valstybės funkcijos, Įstaiga), struktūrinius įstaigos padalinius, kitas dimensijas pagal KAS poreikius (Projektas, išlaidų klasifikatorius, personalo struktūrinė grupė, išlaidų požymis, planavimo ciklas ir kt.).
  • 2Biudžeto planavimas turi būti integruotas su kitais moduliais: pajėgumų, personalo, Ilgalaikio turto, atsargų ir kt.
  • 3ERP sistemoje turi būti galima vykdyti biudžeto planavimo procesą, taip pat biudžeto eilutes įkelti iš CSV, EXCEL formato failų.
  • 4Turi būti galima konsoliduoti KAS sistemos įstaigų biudžetus į asignavimų valdytojo biudžetą (bendras KAM biudžetas).
  • 5Biudžetą turi būti galima planuoti trejiems metams.
  • 6Pilnai paruoštas biudžetas turi būti tvirtinamas sistemoje, patvirtinto biudžeto neleistų koreguoti.
  • 7Turi būti galima atlikti patvirtinto biudžeto tikslinimus, kuriuos papildomai tvirtintų atsakingi asmenys.
  • 8Turi būti galimybė stebėti biudžeto vykdymą (lėšų faktinį panaudojimą) ir vykdyti lėšų panaudojimo kontrolę.
  • 9Turi būti realizuota biudžeto duomenų integracija su FINVIS (finansinių išteklių valdymo informacinė sistema): integruojant tiek pirminį biudžetą, tiek jo patvirtintus tikslinimus, jei būtų priimtas toks sprendimas diegimo projekto apimtyje; VBAMS (valstybės biudžeto apskaitos ir mokėjimų sistema), SVIS (strateginio valdymo informacinė sistema), kuri vykdoma automatiškai nustatytu periodiškumu naudojant Webservice.
  • 10Turi būti galimybė perkelti ankstesnių sąmatų duomenis į naujai rengiamą biudžetą, atlikti metų biudžeto sumos paskirstymą ketvirčiais.
  • 11ERP sistemoje turi būti funkcionalumas formuoti biudžeto vykdymo ataskaitų rinkinį, eksportuoti biudžeto ir jo vykdymo ataskaitos duomenis CSV, EXCEL, PDF ir kitais formatais.

Personalo Valdymo ir Darbo Apskaitos Modulis

  • 1ERP sistemoje turi būti modulis, kuris užtikrintų Krašto apsaugos sistemos personalo valdymą, planavimą, analizę, ir prognozavimą.
  • 2Sistema turi sudaryti galimybes realiu laiku matyti duomenis apie personalą, atlikti personalo duomenų palyginamąją analizę, prognozuoti personalo augimo ir mažėjimo dinamiką, vertinti rizikas bei modeliuoti įvairius žmogiškųjų išteklių scenarijus.
  • 3Taip pat turi būti įdiegtos duomenų filtravimo, segmentavimo, vizualizavimo ir ataskaitų rengimo galimybės, sudarančios sąlygas efektyviai naudoti duomenis sprendimams pagrįsti.
  • 4ERP sistema turi automatizuoti pagrindinius personalo valdymo procesus, personalo gyvavimo ciklą.
  • 5Skirtingų personalo tipų administravimas: kariai, valstybės tarnautojai, darbuotojai, dirbantys pagal darbo sutartis, ir kt. ERP sistemoje turi būti sudaryta galimybė pagal personalo tipą administruoti skirtingus parametrus.
  • 6ERP sistemoje turi būti galimybė aprašyti organizacinę struktūrą (taikos/krizės/karo meto, misijų ir operacijų organizacinė struktūra), pagal pareigas valdyti prieigą prie tam tikrų ERP sistemos duomenų, vykdyti dokumentų ar kitų užduočių tvirtinimą, bei ERP sistemoje įvestos informacijos pagrindu formuoti dokumentų – sprendimų projektus.
  • 7Personalo judėjimo administravimas: sistemoje turi būti sudaryta galimybė fiksuoti personalo judėjimą, įskaitant įdarbinimą, misijos, atleidimą / išėjimą į atsargą, perkėlimą tarp padalinių bei organizacijų sistemos viduje.
  • 8ERP sistemoje turi būti sudaryta galimybė administruoti darbo ir tarnybos sutartis, leidimų bei pažymėjimų išdavimą, taip pat valdyti asmeninę ir tarnybinę informaciją.
  • 9Personalo statistika, duomenų analizė realiu laiku bei prognozavimas. Vieninga statistinė informacija einamuoju laiku apie personalą – strateginiame, operaciniame ir taktiniame lygmenyje.
  • 10Automatizuota karių ir valstybės tarnautojų karjeros planavimo sistema, kuri sutrumpintų karių atrankos ir paskyrimo procesus, užtikrintų, kad kariai būtų atrinkti į reikiamus kursus bei paskirti į jiems tinkamiausias pareigas pagal jų gebėjimus ir strateginius poreikius.
  • 11Veiklos bei tarnybos vertinimo proceso automatizavimas.
  • 12Galimų personalo trūkumų numatymas, kvalifikacijos tobulinimo planavimas ir sąlygų imtis personalo komplektavimo veiksmų iš anksto sudarymas.
  • 13Ginkluotojų pajėgų karių ir LK rezervo karių automatizuotas paskyrimas į Karo meto struktūros pareigas.
  • 14Greitas, efektyvus ir pagrįstas realiais duomenimis rezervo karių pasirengimo įvertinimas, tinkamų rezervistų atranka ir paskyrimas į karo meto pareigas.
  • 15Sistemoje turi būti galima administruoti toliau išvardintą informaciją krizės/karo metu: mobilizacija, sužeistųjų, žuvusiųjų asmenų, dezertyrų, karo belaisvių, karo pabėgėlių informacijos administravimas.
  • 16Galimybė darbo ir tarnybos laiko apskaitos žiniaraščius tabelius, atostogų, kito laisvo laiko, komandiravimo pranešimus ir kitus prašymus pildyti ne tiesiai sistemoje, bet naudojant patogesnes išorines priemones (savitarnos sistema/ mobili aplikacija, kurioje būtų galima ne tik pateikti įvairius prašymus, bet ir peržiūrėti savo informaciją; vadovai turėtų galėti matyti ne tik savo, bet ir pavaldinių informaciją), o ERP sistemoje juos apdoroti.
  • 17ERP sistemos galimybės turi leisti lengvai administruoti integraciją su darbo užmokesčio sistema (personalo duomenų į DU, iš DU į ERP darbo užmokesčio duomenys).
  • 18KAS pareigybių administravimas ir valdymas, statistika.
  • 19Karo prievolininkų valdymo optimizavimas.
  • 20Karo prievolininkų duomenų analizė, atrankos automatizavimas, automatizuotų karo prievolininkų paskyrimo į karinius dalinius ir pareigas automatizavimas.
  • 21Algoritmo sukūrimas, kuris atrinktų kandidatus į karinius dalinius pagal aiškius ir koreguojamus kriterijus.
  • 22Sistema turi sudaryti galimybė administruoti su karo prievolininkais patiriamas išlaidas.
  • 23Savitarnos funkcionalumas ir jo mobilioji versija turi būti prieinami kiekvienam KAS darbuotojui.
  • 24Savitarnos programėlė turi sudaryti galimybę realiuoju laiku vykdyti pagrindinius personalo administravimo ir savitarnos procesus: peržiūrėti tarnybinius ir asmeninius duomenis, valdyti atostogų ir nebuvimų tarnyboje (darbe) informaciją, teikti bei sekti prašymus, inicijuoti personalo veiksmus, vykdyti dokumentų derinimą ir tvirtinimą, gauti pranešimus, peržiūrėti užduotis bei personalo procesų būsenas.
  • 25Sistema turi sudaryti galimybę kaupti ir analizuoti klausimynų duomenis, rengti ataskaitas bei naudoti surinktą informaciją sprendimų priėmimo ir procesų optimizavimo tikslais.
  • 26ERP sistemoje turi būti integruoti personalo klausimynai (pvz., į atsargą išleidžiamų karių klausimynai ir kt.), skirti duomenų rinkimui, statistinei analizei, išvadų formavimui bei personalo procesų tobulinimui.

Didžiųjų Kalbos Modelių (LLM) Funkcionalumas

  • 1ERP sistema turi palaikyti pasirinktinų LLM integraciją, įskaitant atviro kodo LLM.
  • 2ERP sistema turi palaikyti semantinės paieškos galimybes.
  • 3ERP sistema turi teikti LLM pagrįstą natūralios kalbos pokalbių robotą.
  • 4ERP sistema turi turėti LLM pagrįstą paslaugą, kuri padeda vartotojams naršyti sistemoje ir ją veiksmingai naudoti, palaikydama kelias kalbas ir gebėdama atsakyti į vartotojų klausimus apie ERP sistemą.
  • 5ERP sistema turi turėti sąsają, skirtą LLM pagrįstos logikos apibrėžimui ir taikymui.
  • 6ERP sistema turi turėti galimybę grafinėje sąsajoje, be programavimo, kurti LLM pagrįstą sąsają, leidžiančią vartotojams kurti verslo logiką.
  • 7Sąsajos LLM turi gebėti ištaisyti bet kokią logiką, kuri neveikia, ir paaiškinti vartotojui, kaip buvo ištaisyta.
  • 8ERP sistema turi leisti vartotojams naudoti LLM duomenims analizuoti.

Sistemos Administravimas, Palaikymas ir Valdymas

  • 1ERP sistemoje turi būti sąsaja, leidžianti administratoriams valdyti ERP sistemos nustatymus organizacijai.
  • 2Sąsaja turi leisti administratoriams konfigūruoti tokius nustatymus kaip prieigos teisės, laikantis KSRA 7 lentelėje esminiam kibernetiniam subjektui numatytų reikalavimų.
  • 3ERP sistemoje turi būti sąsaja, leidžianti administratoriams peržiūrėti ir valdyti bendrą ERP sistema išteklių sunaudojimą.
  • 4ERP sistemoje turi būti sąsaja, suteikianti administratoriams galimybę matyti būsimus sistemos atnaujinimus, kuriems reikalingi rankiniai veiksmai.
  • 5Sąsaja taip pat turi siųsti administratoriams pranešimus, kai artėja atnaujinimas reikalaujantis rankinio veiksmo.
  • 6ERP sistema turi turėti internetinį palaikymo portalą, kuriame autorizuotiems naudotojams suteikiama prieiga prie sistemos informacijos ir pagalbinių dokumentų, įskaitant naudotojų vadovus, mokymo vadovus ir dažniausiai užduodamus klausimus.

Veiklos Procesų ir Informacijos Saugumo Valdymas

  • 1Sistema turi užtikrinti funkcionalumus tvarkomų dokumentų žymėjimą slaptumo ir platinimo žymomis (tag).
  • 2ERP sistema turi užtikrinti tarnybinio naudojimo informacijos žymėjimą platinimo žyma vadovaujantis Lietuvos Respublikos krašto apsaugos sistemos organizavimo ir karo tarnybos įstatymo nuostatomis.
  • 3ERP sistema turi užtikrinti asmens duomenų žymėjimą platinimo žyma vadovaujantis Europos Sąjungos bendrojo duomenų apsaugos reglamento Lietuvos Respublikos asmens duomenų teisinės apsaugos įstatymo nuostatomis.
  • 4ERP sistema turi užtikrinti komercinę paslaptį sudarančios informacijos žymėjimą platinimo žymomis vadovaujantis Lietuvos Respublikos komercinių paslapčių teisinės apsaugos įstatymo nuostatomis.
  • 5ERP sistema turi sudaryti galimybę nustatyti naudotojų teises ir leistinus veiksmus dirbant su tvarkoma įslaptinimo ir platinimo žymomis pažymėta informacija.
  • 6ERP sistemoje turi būti galimybė kontroliuoti naudojimąsi įslaptinimo ir platinimo žymomis pažymėta informacija griežtai laikantis principo „būtina žinoti“.
  • 7Veiklos rodiklių skaičiavimas: reikalinga veiklos stebėsenos rodiklių planinių ir įvykdymo reikšmių apskaičiavimo funkcija iš skirtingo saugumo lygio duomenų.
  • 8Stebėsenos rodiklių duomenys gali būti paimti iš skirtingų šaltinių: xls failų, iš kitų sistemų ar suvedami rankiniu būdu, tam, kad būtų galimybė „įdarbinti” gautus duomenis – juos analizuoti, atvaizduoti skirtingais pjūviais, prognozuoti.
  • 9Reikalinga sąsaja su BI.
  • 10Veiklos planavimas – sudaryti karinių vienetų veiklos planus, kuriuose pagal KAS hierarchiją būtų nustatomos užduotys nuo KAM iki žemiausio LK karinio vieneto, rengiančio veiklos planą.
  • 11Užduotys turi būti susietos su strateginiais planavimo dokumentais, kuriuose nustatomos užduotys LK vadui, pajėgoms, vienetams: su planavimo vadovu, Strateginiu veiklos planu (programų struktūra), LK veiklos direktyva.
  • 12Užduotys turi būti susietos su programų struktūra – t. y. metiniame veiklos plane detalizuojami (nustatant užduotis/veiksmus) planuojamų programų pažangos ir tęstinės veiklos uždaviniai ir priemonės.
  • 13Turi būti funkcija, sudaryti bendrą vieneto veiklos planą su galimybėmis teikti štabo skyriams ar pavaldiems vienetams siūlymus, dėl užduočių/veiksmų tikslinimo ir papildymo.
  • 14Turi būti galimybė generuoti padalinio veiklos ataskaitą su suderinimo ir tvirtinimo funkcijomis (ataskaitose teikiama informacija apie užduočių įvykdymą).
  • 15Reikalinga funkcija, gautus duomenis analizuoti ir panaudoti prognozavimui.
  • 16Integracija su Vyriausybės strateginio planavimo Sistema (SVIS) programos ir projektų lygiu veiklos rodiklių perdavimui.
  • 17ERP sistema turi užtikrinti įslaptintos informacijos žymėjimą slaptumo žymomis vadovaujantis Lietuvos Respublikos valstybės ir tarnybos paslapčių įstatymo nuostatomis.

Duomenų Apdorojimo ir Integracijos Funkcionalumas

  • 1ERP sistema turi įgalinti sistemos naudotojus įvesti ar įkelti įvairių rūšių duomenų rinkinius ar įkelti elektronines rinkmenas.
  • 2ERP sistema turi leisti lengvai kurti teikiamų duomenų įvedimo formą ir suteikti kitiems įgaliotiems ERP sistema naudotojams teisę ją pildyti.
  • 3ERP sistema turi leisti lengvai kurti formas, kurios vartotoją įgalins įkelti duomenis iš CSV, XLS formatų rinkmenų ir pan. arba įkelti kitų formatų elektronines rinkmenas, tokias kaip nuotrauka ar nestruktūrizuotas tekstas.
  • 4ERP sistema turi turėti galimybę prisijungti prie trečiųjų šalių sistemų ir sąveikauti su jomis, neatsižvelgiant į duomenų, kuriais keičiamasi, technologiją, kiekius ar struktūrą.
  • 5ERP sistemos naudotojui, turinčiam atitinkamas teises, turi būti galimybė naudojant vartotojo sąsają aprašyti ir sukonfigūruoti duomenų paėmimo mechanizmą, leidžiantį paimti duomenų rinkinius ar elektronines rinkmenas tiesiai iš kitų informacinių sistemų.
  • 6ERP sistemoje taip pat turi būti įgyvendintas būdas keliais mygtuko paspaudimais masiškai eksportuoti duomenis į išorines programas, duomenų bazes ir failų sistemas.
  • 7ERP sistema turi turėti iš karto įdiegtas jungtis, skirtas standartiniams šaltinių tipams, pavyzdžiui, SQL duomenų bazėms, išorinėms failų sistemoms ir debesyje talpinamoms duomenų bazėms.
  • 8ERP sistema turi turėti paruoštus prisijungimus prie dažniausiai pasitaikančių duomenų šaltinių, tokių kaip Oracle, Microsoft SQL Server, FTP server, SAS, SAP, Hive, Teradata, Sybase, DB2 ir pan.
  • 9Sprendimas turi palaikyti standartines sąsajas (pvz., JDBC, REST ir kt.).
  • 10ERP sistema turi palaikyti lanksčią duomenų integravimo sistemą, kuri gali integruoti įvairius duomenų formatus, įskaitant struktūrizuotus (pvz., CSV), pusiau struktūrizuotus (pvz., XML, JSON) ir nestruktūrizuotus (pvz., PDF) duomenų tipus.
  • 11ERP sistema turi palaikyti dvikryptį duomenų judėjimą, gebėdama skaityti duomenis iš šaltinio sistemų ir siųsti duomenis atgal į tas sistemas, naudojant atgalinį įrašymą, pvz., atnaujinti informaciją, susijusią su veiklos sprendimais.
  • 12ERP sistema leidžia automatizuoti duomenų ir elektroninių rinkmenų įkėlimo, panaudojimo ir iškėlimo procesus.
  • 13ERP sistemos naudotojui, turinčiam atitinkamas teises, kurti automatinius procesus, kurie pagal jo numatytą datą ir laiką gali atlikti duomenų ar elektroninių rinkmenų paėmimą, išarchyvavimą ir įkėlimą į duomenų bazę.
  • 14ERP sistemos naudotojui, turinčiam atitinkamas teises, kurti automatinius procesus, kurie iš vidinių ar išorinių vartotojų ar kitų informacinių sistemų įkeltus duomenų rinkinius ar elektronines rinkmenas galėtų priimti, išarchyvuoti ir įkelti į ERP sistemos aplinką.
  • 15ERP sistemoje turi būti laikomasi šaltinio sistemos duomenų saugumo konfigūracijų, kai prieinama prie duomenų.
  • 16ERP sistema turi turėti gebėjimą veikti pilnai izoliuotoje, be prisijungimo prie interneto, aplinkoje, valdomoje Pirkėjo.
  • 17ERP sistemoje turi būti saugomi išsamūs įspėjimų, klaidų žurnalai ir versijų istorija, kad naudotojai galėtų greitai nustatyti problemų priežastis.
  • 18ERP sistema turi turėti versijų funkcionalumą, taikomą programiniam kodui. Prireikus turi būti galimybė atstatyti pakeistą programinį kodą į pasirinktą versiją.

Atsargų Valdymo, Logistikos ir Sandėlių Valdymo Modulis

  • 1ERP sistemoje turi būti logistikos aplikacija, skirta karinių operacijų logistikos planavimui bei monitoringui, situacijos analizei, aprūpinimui ir sprendimų priėmimui.
  • 2Sistema turi užtikrinti bendrą operacinį logistinės situacijos vaizdą, gebėti planuoti ir valdyti resursus, vykdyti jų apskaitą ir kontrolę, sistemų gyvavimo ciklą, integruoti ir konsoliduoti pasirinktus duomenis iš skirtingų karinių ir civilinių logistikos sistemų ir duomenų registrų pagal vartotojo poreikius.
  • 3Sistema turi palaikyti taktinių, operacinių ir strateginių lygių duomenų atvaizdavimą, leisti realiu laiku stebėti materialinių išteklių judėjimą operacijos rajone ir tiekimo grandinėse, palaikyti geografinių (GIS) duomenų integraciją su operacijos aplinka.
  • 4Karinės įrangos ir atsargų valdymas / apskaita pagal NATO klasifikaciją (NSN, NATO tiekimo klases).
  • 5Bendras tam tikrų klasifikatorių valdymas organizacijų grupei – atsargų/gaminių/paslaugų kortelės.
  • 6Atsargos, priklausomai nuo jos grupės, turi būti apskaitomos finansinėje apskaitoje pagal atitinkamą įkainojimo metodą: FIFO; konkrečių kainų.
  • 7Užtikrinti karinės įrangos ir atsargų sekimą (vienetas, vieta, kiekis) bei jų turi būti automatiškai atspindimas finansų apskaitoje.
  • 8Atsargos finansinėje apskaitoje taip pat turi būti apskaitomos pagal atsakingą asmenį bei turėti funkcionalumą registruoti tokias atsargų operacijas: įsigijimas, pasigaminimas, gavimas neatlygintinai, nuvertėjimas, nurašymas, pardavimas/perleidimas.
  • 9ERP sistemoje turi būti galima suformuoti atsargų judėjimo aktus (vidinis perdavimas, nurašymas ir k.t.).
  • 10Atsargos, kaip ir IT, turi būti galima grupuoti pagal disponavimą.
  • 11ERP sistema turi formuoti ataskaitas skirtingais pjūviais (likutis pagal pavadinimą, kodą, atsakingą, vietą, didžiosios knygos sąskaitą, dimensijas).
  • 12Planuoti ir valdyti atsargų išdavimą pagal pateiktas paraiškas, taip pat ERP sistemoje turi būti galimybė aprašyti tam tikrų atsargų išdavimo normatyvus, vadovautis jais išduodant bei grąžinant atsargas.
  • 13ERP sistemoje turi būti galimybė fiksuoti gamybos funkcijas pagal medžiagų sunaudojimo normas (BOM).
  • 14ERP sistema turi turėti integracinius taškus su POS terminalais bei gautų duomenų apdorojimas. Pagal gautus POS duomenis, turėtų būti nurašomi ERP sistemoje parduoti gaminiai.
  • 15ERP sistemoje turi būti realizuota prieiga prie atsargų likučių per API funkcionalumą.
  • 16Centralizuoti/decentralizuoti pirkimai administruojami pagal organizacijas/prekių grupes, kai centralizuoto pirkimo funkcijas vykdo viena iš grupės organizacijų.
  • 17Pirkimų plano sudarymo remiantis patvirtintu biudžetu funkcionalumas.
  • 18Pirkimo sutarčių valdymas, sekimas ir įvykdymo kontrolė (kiekis/kaina/terminas).
  • 19Pirkimo sąskaitų skaitmeninimo sprendimas ir jų automatizuotas apdorojimas, kai pirkimo sąskaitos nėra teikiamos per SABIS.
  • 20Užtikrinti multimodalinio (sausuma, jūra, oras) bei karinių krovinių transportavimo planavimą, vykdymą bei stebėseną.
  • 21Palaikyti judėjimo apribojimus pagal saugumo ir grėsmių vertinimą, operacijos pobūdį bei infrastruktūros būklę.
  • 22Gebėti vertinti transportavimo rizikas ir vėlavimus.
  • 23Gebėti analizuoti transportavimo pajėgumo panaudojimą.
  • 24ERP sistemoje turi būti galimybė aprašyti įvairių tipų transporto priemonių kuro suvartojimo normas, apskaityti transporto priemonių sunaudotą kurą pagal kelionės lapus, fiksuoti kuro užpylimą iš civilių ir vietinių KAS degalinių (būtina šių duomenų integracija iš minėtų sistemų).
  • 25ERP sistemoje turi būti realizuotas funkcionalumas transporto priemonių remonto ir priežiūros darbams užsakyti, fiksuoti faktines patirtas išlaidas (remontas, aptarnavimas, draudimas ir kt.).
  • 26Užtikrinti operacijos logistinės paramos modeliavimą (pvz. tiekimo sutrikimai, infrastruktūros praradimai ir pan.).
  • 27Gebėti vertinti logistinių sprendimų poveikį operacijos eigai ir esant poreikiui greitai perplanuoti operaciją pasikeitus situacijai.
  • 28Teikti rekomendacijas dėl alternatyvių tiekimo ar transportavimo sprendimų.
  • 29Turi palaikyti valstybės mobilizacijos ir priimančios šalies paramos planus bei leisti greitai pereiti nuo taikos meto prie krizės ar karo meto logistikos režimo.
  • 30Turi palaikyti rezervo ir civilinių resursų integravimą į karines operacijas.
  • 31Gebėti vertinti ir dekonfliktuoti mobilizacinius ir priimančiosios šalies poreikius ir logistikos rizikas.
  • 32Vertinti ir dekonfliktuoti evakuacijos ir mobilumo koridorius.
  • 33Užtikrinti visos tiekimo grandinės matomumą realiu laiku bei stebėti materialinių vertybių judėjimo būseną visose tiekimo grandinės stadijose.
  • 34Identifikuoti tiekimo grandinės sutrikimų rizikas bei užtikrinti ankstyvo perspėjimo procedūras.
  • 35Sandėliavimo funkcionalumas turi leisti pagal atsargas administruoti sandėlio vietas (stelažas, lentyna, aukštas), vykdyti standartines sandėlio valdymo funkcijas.
  • 36ERP sistema turi turėti sprendimą naudoti duomenų kaupiklius sandėlio operacijoms fiksuoti ir į sistemą sukelti fiksuotus duomenis.
  • 37Analizuoti sandėlio pajėgumų panaudojimą.
  • 38Atsargų poreikių planavimas turi būti susietas su pajėgumų vystymo ir palaikymo planais, OSĮL/PAL ĮL duomenimis, normatyvais, faktiniais likučiais, pirkimų planais, sutartimis ir sandėlių pajėgumais.
  • 39Palaikyti materialinių vertybių priėmimo, saugojimo, komplektavimo ir išsiuntimo duomenų analizę bei šių operacijų našumą.
  • 40Sistema turi leisti nustatyti, ar planuojami atsargų kiekiai nėra per maži arba pertekliniai, įvertinant sunaudojimo normas, kaupiamų atsargų poreikį, turimus likučius, numatomus gavimus, nurašymus, perdavimus ir finansinius apribojimus.

Ginklų Sistemų ir Platformų Gyvavimo Ciklo Valdymo Modulis

  • 1ERP sistemoje turi būti sprendimas specializuotos kovos įrangos ir kovos platformų turto valdymui.
  • 2Reikalinga galimybė planuoti įsigijimą, vykdyti įsigijimą, sukomplektuoti pilnai kovos platformas, atlikti jų remonto ir priežiūros funkcijas, vykdyti gyvavimo ciklo funkciją (ginkluotė, technika, įranga, atsargos).
  • 3ERP sistemoje turi būti galimybė aprašyti kovos platformų hierarchinio lygio sudedamųjų dalių/sistemų sąrašus, šiuos sąrašus importuoti iš failo/integruoti iš kitų sistemų.
  • 4Kiekvienai sistemos daliai (kaip ir pačiai platformai) turi būti galimybė aprašyti gyvavimo ciklą, fiksuoti aptarnavimus, remontus, būklės duomenis ir įvykius atskirai nuo visos kovos platformos.
  • 5ERP sistemoje turi būti funkcionalumas, susijęs su komponentų, atsarginių detalių ir medžiagų poreikiu kovos platformoms ir sistemoms išlaikyti.
  • 6Atsižvelgdama į parengties lygį, sistema vertina atsargas, sutartis, poreikius, skirtas lėšas, remontą ir aptarnavimo intervalus, susijusius su gamyklos gamintojo nustatytomis rekomendacijomis ir teikia siūlymą inicijuoti pirkimo procesą per centralizuotą pirkimų instituciją.
  • 7Kovos platformų, ginklų sistemų ar jų dalių įsigijimo planavimas turi būti susietas su pajėgumų vystymo planais, OSĮL/PAL ĮL poreikiais, finansavimo šaltiniais, pirkimų planais ir sutarčių vykdymu.
  • 8Sistema turi leisti identifikuoti, kokios kovos platformos, sistemos ar jų dalys yra reikalingos konkrečiam pajėgumui suformuoti, kokios jau yra turimos, kokios suplanuotos įsigyti ir kokios dar nėra suplanuotos.
  • 9Sistema turi įspėti, kai kovos platformos ar jos dalių įsigijimo, priežiūros, remonto arba eksploatavimo planai nesutampa su pajėgumo vystymo, palaikymo ar parengties terminais.
  • 10Sistemoje turi būti galimybė pilnai vykdyti grąžinimo tiekėjui procesą.
  • 11Gyvavimo ciklo duomenys turi atspindėti projekto, programos, atskiros platformoms, objekto išlaikymo kaštus, kas leistų tiksliau planuoti išlaikymo kaštus.
  • 12Gyvavimo ciklo duomenys turi būti pasitelkiami vykdant projektų inicijavimą ir planavimą.
  • 13Atsargų gyvavimo ciklo duomenys turi būti susiję su atsargų galiojimu (Shelf Life), atsargų planavimu, atsargų užsakymu.
  • 14Turi būti susijusiu su kariuomenės parengties lygiais ir su resursais, reikalingais reikalaujamam lygiui pasiekti.
  • 15Sistema turi gebėti realiu laiku pateikti sistemos, projekto, atskiro objekto išlaikymo kaštus, taip pat susieta kitais netiesioginiais kaštais (personalo parengimas, infrastruktūros išlaikymas, atnaujinimas, modernizacija ir t.t.).
  • 16ERP sistemoje turi būti galima vykdyti pripažinti netinkamo naudoti, sugedusio turto utilizavimo procesą, formuoti atitinkamai turto pripažinimo netinkamu naudoti veikloje, nurašymo/likvidavimo aktus.
  • 17Turi būti galimybė valdyti priežiūros planus, taip pat priežiūros planą grupuojant kelias dalis ar platformas, valdyti sistemos konfigūracijos keitimą, sekti remonto informaciją (peržiūrėti visą istoriją) ir atlikti remontuojamo turto/ jo detalės sekimą.
  • 18Sistemoje reikalingas sprendimas planuoti ir valdyti skrydžius (taip pat laivais) ir su jais susijusią informaciją, taip pat sekti ir valdyti pačios įrangos ir ginkluotės priežiūrą, fiksuoti ir valdyti kilusius incidentus.

Didžiosios Knygos ir Finansinės Atskaitomybės Funkcionalumas

  • 1Vieningas bendrų nustatymų valdymas organizacijų grupei: bendras sąskaitų planas, finansinės dimensijos ir pan.
  • 2Turi būti galimybė atskirai organizacijai turėti atskirus sąrašus ar tik tam tikras reikšmes, taip pat nustatyti pradžios ir pabaigos datas konkrečioms sąskaitų plano ar finansinių dimensijų reikšmėms.
  • 3Turi būti galimybė turėti neribotą kiekį finansinių dimensijų pagal organizacijos poreikį.
  • 4Apskaitą turi būti galima vesti pagal Lietuvos viešojo sektoriaus apskaitos standarto (VSAFAS) reikalavimus.
  • 5ERP Sistema turi palaikyti kaupimo principą, t. y. KAS institucijų ūkinės operacijos apskaitoje turi būti registruojamos tada, kai jos įvyksta, ir pateikiamos to laikotarpio finansinėse ataskaitose.
  • 6ERP sistemoje turi būti užtikrintas finansinės atskaitomybės pagal VSAFAS ruošimas.
  • 7Turi būti galima finansines ataskaitas konfigūruotis patiems ERP sistemos vartotojams, turintiems atitinkamas sistemos teises.
  • 8ERP turi turėti funkcionalumą vykdyti ataskaitų ir suderinimo informacijos eksportus į VSAKIS (Viešojo sektoriaus apskaitos ir ataskaitų konsolidavimo informacinė sistema).
  • 9Turi būti galimas finansinės atskaitomybės už grupės organizacijas konsolidavimas sistemoje, tiek biudžeto, tiek DK operacijų lygyje.
  • 10ERP sistemoje kiekvieno laikotarpio ir metų pabaigoje turi būti galima automatiškai registruoti laikotarpio pabaigos operacijas: pajamų kaupimą, gautinų sumų nuvertėjimą, beviltiškų sumų nurašymą, sąnaudų sukaupimą, atidėjinių suformavimą, valiutinių likučių perkainavimą, likučių sutikrinimą; metų pabaigoje papildomai registruojant atsargų ir turto inventorizaciją, ilgalaikio turto nuvertėjimą, atsargų grynosios vertės realizavimo vertės fiksavimą, gautinų ir gautinų sumų trumpalaikės dalies išskyrimą, sąskaitų uždarymą ir metų rezultato fiksavimą.
  • 11ERP sistema turi formuoti balanso, pinigų, mokėtinų ir gautinų sumų ataskaitas skirtingais pjūviais.

Dokumentai3

  • 2_Reikalavimai ERP sistemai_2.6.docx
  • 2356_7936304.pdf
  • 1_RINKOS KONSULTACIJA_ERP_2.0.docx
tendis.lt · Sukurta recodin.lt