Grįžti į sąrašą

OKIS programavimo ir vystymo paslaugos

Išanalizuota

Valstybinė maisto ir veterinarijos tarnyba

Rinkos konsultacijaCPV: 72224000 - Projektų vadybos konsultacinės paslaugos
ID: 71846652026-03-31 08:59
Atidaryti CVP IS

Aprašymas

Valstybinė maisto ir veterinarijos tarnyba siekia įsigyti Oficialiosios kontrolės informacinės sistemos (OKIS) programavimo paslaugas. Šios paslaugos apima rizikos vertinimo ir valstybinės kontrolės planavimo komponentų vystymą, veterinarinės bei maisto kontrolės planų sukūrimą ir bendrųjų OKIS funkcionalumų tobulinimą. Taip pat bus perkamos papildomos programavimo, UX kūrimo, detalios analizės ir testavimo paslaugos pagal fiksuotą valandinį įkainį.

Kvalifikaciniai reikalavimai

  • 1Vienas žmogus negali būti siūlomas į daugiau nei į vieną poziciją.
  • 2Bent vieną Front-end programuotoją, turintį ne mažesnę kaip 36 (trisdešimt šešių) mėnesių patirtį programuojant Angular + dot.net core technologijomis.
  • 3Bent vieną Back-end programuotoją, turintį ne mažesnę kaip 36 (trisdešimt šešių) mėnesių patirtį programuojant Dot.net core, postgresql, Open API technologijomis.
  • 4Bent vieną sistemų analitiką / testuotoją, turintį ne mažesnę kaip 36 (trisdešimt šešių) mėnesių darbo patirtį šioje srityje.
  • 5Bent vieną UI/UX dizaino specialistą, turintį ne mažesnę kaip 36 (trisdešimt šešių) mėnesių darbo patirtį šioje srityje.

Techniniai reikalavimai

Išeities kodo reikalavimai

  • 1Išeities kodo pakeitimų istorija yra nuosekli ir informatyvi, galima suprasti, kokie pakeitimai ir kodėl atlikti.
  • 2Integraciniai testai parašyti, veikia ir apima svarbiausias dalis.
  • 3Kodas yra dokumentuotas: aprašyta kiekviena sukurta funkcija kode, įskaitant komentarus, techninę, API, architektūros dokumentaciją.
  • 4Paslaugos teikėjas turi užtikrinti išeities kodo kokybę, prieš priimant kodą kartu su Tarnybos vykdoma peržiūra (pull request), pagal pateiktus Tarnybos komentarus kodo trūkumai turi būti pašalinti ne vėliau nei iki sekančio sprinto pabaigos.
  • 5Repozitorijoje išeities kodo pagrindu yra suformuojamas sistemos diegimo paketas ir jis įkeliamas į Tarnybos bandomąją aplinką.
  • 6Tarnybai atlikus sprendimo UAT (vartotojo priėmimo testą) testavimą bandomojoje aplinkoje ir nenustačius trūkumų, minėtas repozitorijos suformuotas diegimo paketas yra įkeliamas į gamybinę aplinką.
  • 7Išeities kodas yra be žinomų kritinių klaidų, patalpintas į Tarnybos nurodytą repozitoriją.

Planavimas: teisių valdymas

  • 1Sistemoje turi būti galimybė teritoriniams padaliniams atvaizduoti ir suteikti galimybę tvarkyti tik teritoriniam padaliniui priskirtą plano dalį.
  • 2Visiems teritoriniams padaliniams turėtų būti prieinama bendra VMVT valstybinės kontrolės planų įgyvendinimo stebėsena, atvaizduota grafiškai.
  • 3Sistemoje turi būti sukurtos rolės (arba teisių rinkiniai priskirti esamoms): PRVPS specialistas, PRVPS vadovas, Priežiūros dep. specialistas, Priežiūros dep. vadovas, Teritorinio padalinio vadovas, VMVT direktorius, Pareigūnas / inspektorius.

Esamos OKIS sistemos technologijos

  • 1Programavimas: Angular 19.
  • 2API informacija: NET 8 RESTful API.
  • 3Kodas saugomas: GitHub.
  • 4Programavimas vykdomas: lokaliame kompiuteryje.
  • 5Testinėje aplinkoje keitimai daromi naudojant: GitHub Actions.
  • 6Naudojamos bibliotekos turi būti naujausios versijos.

OKIS planavimo komponento sukūrimas

  • 1Turi būti realizuotas Valstybinės kontrolės planų rengimo procesas.
  • 2Turi būti realizuota Valstybinės kontrolės planų duomenų struktūra ir jos atvaizdavimas.
  • 3Turi būti realizuoti kiti funkcionalumai (duomenys, reikalingi planavimui, žmogiškųjų išteklių valdymo, tikrintinų sąrašų sudarymo, kiti funkcionalumai).

Bendri OKIS tobulinimo funkcionalumai

  • 1Turi būti sukurtas funkcionalumas, skirtas atitikties vertinimo pažymų generavimui kontroliuojamoms veiklavietėms.
  • 2Turi būti galimybė sugeneruoti vertinimo pažymą su daugiau nei vienu klausimynu.
  • 3Turi būti galimybė peržiūrėti visus atliktų patikrinimų rezultatus. Prieš atveriant duomenis turi būti pateikiama iššokanti lentelė, kurioje vartotojas įveda paaiškinimą, kodėl peržiūrima informacija.
  • 4Sistemoje turi būti realizuotas dokumentų modulis, leidžiantis valdyti visus su kontrolės objektais susijusius dokumentus centralizuotai ir patogiai.
  • 5Kiekvieno kontrolės objekto kortelėje turi būti sukurta skiltis ar peržiūros langas dokumentų peržiūrai, įkėlimui, parsisiuntimui ir klasifikavimui.
  • 6Turi būti galimybė filtruoti ir rūšiuoti dokumentų sąrašą pagal pasirinktus laukus (tipą, datą, atsakingą asmenį, susijusį patikrinimą ir kt.).
  • 7Dokumentų klasifikavimo sistema turi būti suderinta su institucijos dokumentų valdymo tvarka.
  • 8Visi dokumentų įkėlimo, peržiūros, klasifikavimo, parsisiuntimo ar keitimo veiksmai turi būti registruojami sistemos audito žurnale.
  • 9Turi būti galimybė sekti laikino subjekto ar veiklavietės sustabdymo būseną (ataskaita, pranešimai apie artėjančią sustabdymo datą).
  • 10Turi būti sukurtas funkcionalumas, kuris informuotų atsakingą darbuotoją apie galiojimo pabaigą pagal nustatytas taisykles.
  • 11Turi būti galimybė veiklavietei įvesti kelis įsakymus, nurodant, kas buvo pakeista (data, numeris, prisegtas dokumentas, komentaras apie atliktus pakeitimus ir pan.).
  • 12Turi būti realizuotas priežiūros funkcionalumas, patikrinimas trūkumų šalinimo, mėginių šalinimo ar pan. tikslais.
  • 13Paslaugos teikėjas turi įgyvendinti realiu laiku įvestu duomenų pokyčių atvaizdavimą patikrinimo pildyme, kitiems sistemos naudotojams.
  • 14Sistema turi užtikrinti, kad visi inspektoriai galėtų matyti vienas kito įvestus duomenis ir pokyčius realiu laiku, naudojant Websocket arba lygiavertę technologiją.
  • 15Kiekvienas naudotojas aiškiai matytų, kokią informaciją redaguoja kitas naudotojas (pvz., per naudotojo inicialus ar spalvinį žymėjimą).
  • 16Nebūtų duomenų praradimo ar konfliktų dėl vienu metu atliktų pakeitimų.
  • 17Sistemoje turi būti realizuotas mėginių valdymo modulis, leidžiantis patikrinimo metu fiksuoti informaciją apie paimtus mėginius, juos administruoti ir gauti laboratorijų atsakymus.
  • 18Formuojamas pavedimas, patikrinimo metu turi būti užtikrinta galimybė registruoti mėginius, įvedant pagrindinius duomenis.
  • 19Remiantis užregistruotais duomenimis, sistema turi generuoti mėginių lydraščius (4 skirtingos formos).
  • 20Lydraštis turi būti išsiunčiamas nurodytu elektroniniu paštu.
  • 21Po mėginių perdavimo turi būti užtikrinta galimybė saugoti laboratorijų atsakymus sistemoje.
  • 22Laboratorijos atsakymai turi būti susiejami su konkrečiu mėginiu ir patikrinimu bei atvaizduojami naudotojui peržiūros lange.
  • 23Turi būti galimybė įkelti atsakymų dokumentus (pvz., PDF ar kitus formatus), taip pat įvesti pagrindinius rezultatų duomenis struktūrizuota forma.
  • 24Visi duomenys, susiję su mėginiais – nuo paėmimo iki atsakymo gavimo – turi būti registruojami audito žurnale.
  • 25Turi būti užtikrintas mėginių sekamumas ir atsekamumas.
  • 26Sistema turi užtikrinti galimybę generuoti ne mažiau kaip penkias pagrindines ataskaitas iš sistemoje kaupiamų duomenų.
  • 27Vartotojui turi būti sudaryta galimybė atsisiųsti visas sugeneruotas ataskaitas .xml formatu.
  • 28Apie 10 proc. valandų skirta vartotojo sąsajų kūrimui.
  • 29Apie 40 proc. valandų skirta detali reikalavimų analizei ir dokumentavimui, įgyvendintų reikalavimų testavimo darbams, dokumentacijos naujinimui.
  • 30Apie 50 proc. valandų skirta reikalavimų programavimui.

Bendrieji paslaugų teikimo reikalavimai

  • 1Paslaugos teikimo vieta – Siesikų g. 19, Vilnius; paslaugos taip pat gali būti teikiamos nuotoliniu būdu.
  • 2OKIS programavimo paslaugos pagal fiksuotą kainą turi būti suteiktos ne ilgiau nei per 5 (penkis) mėnesius nuo jų užsakymo dienos.
  • 3OKIS programavimo paslaugos, perkamos pagal fiksuotą valandinį įkainį, gali būti užsakomos 24 mėnesius nuo sutarties įsigaliojimo dienos.
  • 4Sutarties galiojimo terminas – 24 mėn.
  • 5Paslaugų teikėjas per 10 (dešimt) darbo dienų nuo užsakymo privalo aptarti ir suderinti su Tarnyba paslaugų teikimo grafiką (darbų atlikimo etapus).
  • 6Diegimai į gamybinę aplinką turi būti vykdomi ne rečiau nei kas 5 savaites.
  • 7Paslaugos teikėjas parengia ir suderina testavimo scenarijus, pagal kuriuos atlieka testavimą, pateikia funkcinio testavimo ataskaitą pagal įgyvendintus reikalavimus.
  • 8Paslaugos teikėjas turi pašalinti nustatytus defektus per sutartą laiką, bet ne vėliau nei iki kito sprinto pabaigos.
  • 9Programavimo darbai turi būti vykdomi vadovaujantis analizės metu nustatytais naudotojų scenarijais, funkcine logika, duomenų srautais ir integracijos poreikiais.
  • 10Programavimo darbai turi būti vykdomi remiantis galutiniais „Figma“ prototipais, kurie atspindi UI struktūrą, komponentų išdėstymą, veiksmų logiką ir bendrą dizaino sprendimą.
  • 11Programavimo darbai turi būti vykdomi laikantis gerųjų programavimo praktikų (saugumo, našumo, prieinamumo, UX principų).
  • 12Užtikrinti, kad priėmimo metu identifikuotos klaidos būtų pilnai pašalintos.
  • 13Parengti galutinę administravimo ir naudotojų vadovų dokumentaciją prieš paleidžiant sprendimą į eksploataciją.
  • 14Visi sprendiniai turi atitikti Tarnybos IT architektūros, saugumo, integracijos bei teisės aktų reikalavimus.
  • 15Įgyvendinti funkcionalumai turi atitikti techninės specifikacijos ir analizės dokumentaciją.
  • 16Užtikrinti, kad sistemos komponentai būtų tinkamai dokumentuoti ir tinkamai perduoti Tarnybos priežiūrai.
  • 17Programavimo paslaugos pagal fiksuotą valandinį įkainį teikiamos iteraciniu-inkrementiniu būdu, naudojant Scrum metodologiją, formuojant ir įgyvendinant 10 darbo dienų arba trumpesnės trukmės užduotis (sprintus).
  • 18Tarnyba kiekvienam sprintui nurodo užduotis pagal prioritetą.
  • 19Paslaugos teikėjas iki 10 darbo dienų iki sprinto pradžios paruošia interaktyvius vartotojo sąsajos eskizus (interactive wireframes) pagal pateiktus prioritetus.
  • 20Kiekvieno sprinto pradžioje Paslaugos teikėjas organizuoja sprint planning sesiją, kurioje dalyvauja Tarnybos atstovai.
  • 21Kiekvienos dienos pradžioje Paslaugos teikėjo programuotojai raštu arba susitikime su Tarnybos atstovais pateikia: dienos darbo planą, pasiektus rezultatus, galimas rizikas, pagalbos poreikius.
  • 22Sprinto pabaigoje Paslaugos teikėjas organizuoja sprinto rezultatų pristatymą Tarnybai.
  • 23Tarnyba pateikia naudotojo istoriją (user story), Paslaugos teikėjas nurodo naudotojo istorijos įgyvendinimo laiką ir terminą, Tarnyba patvirtina naudotojo istorijos įgyvendinimą (užsakymą).
  • 24Paslaugos teikėjas atlieka detalią analizę, dokumentuoja, parengia ir suderina vartotojo sąsajos eskizus (wireframes).
  • 25Atliekami programavimo darbai pagal suderintą dokumentaciją.
  • 26Darbai diegiami testinėje aplinkoje.
  • 27Tarnyba atlieka galutinį testavimą ir patvirtina diegimą į produkcinę aplinką.
  • 28Paslaugos teikėjas atnaujina OKIS dokumentaciją pagal įgyvendintas užduotis.
  • 29Paslaugos teikėjo ekspertų darbų koordinavimas.
  • 30Paslaugos teikėjo ekspertų vykdomų darbų kontrolė.
  • 31Dalyvavimas Tarnybos organizuojamuose susitikimuose.
  • 32Dalyvavimas sprendžiant kritinius Tarnybos OKIS posistemių vystymo klausimus.
  • 33Paslaugos teikėjas, teikdamas paslaugas turi vadovautis aktualiais LR teisės aktais ir gerosiomis praktikomis bei standartais.
  • 34Paslaugos teikėjas turi turėti užduočių valdymo sistemą, kurioje turi būti registruojamos ir valdomos su projekto vykdymu susijusios užduotys.

OKIS rizikos vertinimo komponento vystymas

  • 1Akvakultūros subjektų veikloms turėtų būti priskirta maža rizika esant procentiniam rėžiui 0-50%.
  • 2Veikos, veiklų grupės ar veiklavietės rizikos duomenų atnaujinimas, atsižvelgiant į pasitvirtinusį incidentą.
  • 3Duomenys atnaujinami (papildomi) užfiksavus ir patvirtinus dar vieną incidentą.
  • 4Duomenys automatiškai atnaujinami tais atvejais, kai pagrįsti skundai/pranešimai nefiksuoti (nebuvo patvirtinti) metus ir daugiau nuo paskutinio incidento patvirtinimo.
  • 5Jei aktuali informacija nepateikta (ūkinis subjektas atsisakė pateikti duomenis), sistemoje kriterijui turėtų būti suteikiamas rizikos vertinimas „didelė“ automatiškai priskiriant atitinkamą balų skaičių.
  • 6Pareigūnui / inspektoriui pildant informaciją apie apimties / pajėgumų rodiklius, privalomai turėtų būti nurodomos reikšmės arba pažymima, kad aktuali informacija nepateikta, to nepadarius, sistema neturi leisti išsaugoti duomenų.
  • 7Sistemoje taip pat turi būti galimybė nurodyti, kad ūkio subjektas veiklą vykdo tik Lietuvos Respublikoje, šios reikšmės pasirinkimas neturėtų būti traktuojamas kaip kriterijaus riziką didinantis veiksnys.
  • 8Sistemoje, pasirinkus importo, eksporto ar platinimo į ES atvejus, turi būti galimybė nurodyti susijusias valstybes (iš ne ES valstybių sąrašo importui/eksportui, iš ES valstybių sąrašo (išskyrus LR) platinimui į ES), galimas kelių reikšmių pasirinkimas.
  • 9Turi būti galimybė užpildyti vieną klausimyną kelioms veikloms (pvz., veiklų grupei).
  • 10Sistemoje turi būti galimybė susieti neatitiktis su konkrečia veikla atliekant klausimyno pildymą.
  • 11Rizikos vertinimo kontekste patikrinimo kriterijaus reikšmė turi būti perskaičiuojama pagal konkrečiai veiklai priskirtas neatitiktis.
  • 12Tais atvejais, kai vykdant patikrinimą, pareigūnas / inspektorius pažymi, kad klausimynas nebus pildomas, sistemoje turi būti galimybė nurodyti klausimyno nepildymo priežastį (privalomas laukas).
  • 13Pasirinkus bet kurią iš klausimyno nepildymo priežasčių, patikrinimo kriterijaus reikšmė turėtų būti perskaičiuojama į didelę.
  • 14Bet kurios iš aukščiau paminėtų priežasčių nurodymas sistemoje neturėtų turėti įtakos pirminiam rizikos vertinimui.
  • 15Rizikos vertinimo duomenų atvaizdavimas (posistemis, skirtas administruoti rizikos vertinimo duomenis rizikos vertintojams).
  • 16Sistemoje turėtų būti galimybė kurti naujus rodiklius papildomų duomenų surinkimui.
  • 17Kuriant rodiklį turėtų būti galimybė nurodyti: Rodiklio kodas, Rodiklio pavadinimas, Privalomas rodiklis (taip/ne), Informacinio pranešimo tekstas, Rodiklio galiojimas nuo... iki..., Rodiklio tipas (text, integer, decimal, boolean, classifier, kombinacija).
  • 18Jei pasirinktas rodiklio tipas yra classifier, papildomai turėtų būti suvedama: Klasifikatoriaus reikšmės, Galimos kelios pasirinkimų reikšmės (taip/ne).
  • 19Tais atvejais, kai rodiklio reikšmės bus pateikiamos skirtingoms klasifikatoriaus reikšmėms, bendra rodiklio suma turėtų būti paskaičiuojama automatiškai.

Planavimas: plano įgyvendinimo stebėsena

  • 1Sistemoje turi būti galimybė stebėti valstybinės kontrolės planų įgyvendinimo progresą.
  • 2Valstybinės kontrolės plane turi būti aiškiai atvaizduojami įvykdyti patikrinimai.
  • 3Sistemoje turi būti galimybė valstybinės kontrolės planų įgyvendinimo stebėseną atvaizduoti grafiškai.
  • 4Sistemoje turi būti atvaizduojamas bendras valstybinės kontrolės įgyvendinimo progresas (suplanuotų ir įgyvendintų patikrinimų / auditų palyginimas), išskiriant: Įgyvendintų VMVT planinių patikrinimų dalį (OKIS), Įgyvendintų VMVT planinių patikrinimų dalį ne OKIS sistemoje, Neįgyvendintų VMVT planinių patikrinimų dalį (su priežastimis), Neįgyvendintų patikrinimų, kuriems sistemoje nėra nurodyta patikrinimo neįvykdymo priežastis, dalį.
  • 5Bendrą valstybinės kontrolės įgyvendinimo progresą turi būti galimybė „išskleisti“ (angl. drill down), atvaizduojant sistemoje progresą pasirinktinai pagal: Kontroliuojamas sritis, Veiklų grupes, Veiklas, Atrankos kriterijus, Riziką, Periodus.
  • 6Sistemoje papildomai turėtų būti galimybė stebėti patikrinimų vykdymą pagal patikrinimų rūšis ir porūšius (bendrai VMVT ir atskirai pagal teritorinius padalinius).
  • 7Sistemoje bendrą ir detalizuotą planą pagal pasirinktus kriterijus turi būti galimybė atvaizduoti kiekvieno teritorinio padalinio lygmeniu atskirai.
  • 8Sistemoje papildomai turi būti galimybė atvaizduoti, kuri patikrinimų dalis nėra detaliai suplanuota.
  • 9Sistemoje pasirinkus bet kurį progreso atvaizdavimo lygį turi būti aiškiai indikuojamas plano įgyvendinimo statusas.
  • 10Sistemoje turi būti atvaizduojamas progresas planų, kurie turi (arba turėjo) būsenas „patvirtintas“ ir „atnaujintas, patvirtintas“.
  • 11Progresas yra skaičiuojamas tik plano įgyvendinimo apimtyje.
  • 12Patvirtinus atnaujintus planus, sistemoje atitinkamai turėtų būti perskaičiuotas valstybinės kontrolės plano įgyvendinimo progresas.
  • 13Tiekėjas turi parengti duomenų struktūras duomenų perdavimui į Power BI.

Planavimas: naudotojo sąsajos reikalavimai

  • 1Sistemoje turi būti sukurta papildoma skiltis „Planas“. Valstybinės kontrolės planas turėtų būti pasiekiamas viršutinėje meniu juostoje.
  • 2Sistemoje turi būti galimybė į planą įtraukti bet kurią ūkio subjekto vykdomą veiklą.
  • 3Sistemoje turėtų būti galimybė plano duomenis filtruoti, grupuoti ir vykdyti paiešką pagal kriterijus (visi plano duomenų struktūros stulpeliai, veiklos būsena, ūkio subjekto būsena, atlikimo statusas).
  • 4Filtravimas, rūšiavimas ir paieška vykdoma tik pasirinktų metų kontekste.
  • 5Sistemoje vykdant duomenų filtravimą turi būti galimybė pasirinkti kelias reikšmes vienu metu (angl., multiple selection).
  • 6Sistemoje turi būti galimybė rūšiuoti duomenis pagal visus plano duomenų struktūros stulpelius.
  • 7Sistemoje turi būti galimybė vykdyti paiešką pagal plano duomenų struktūros stulpeliuose pateikiamus duomenis.
  • 8Paieškos laukuose ir / arba naudojamuose filtruose nepasirinkus jokių reikšmių, pagal nutylėjimą sistema turėtų atvaizduoti visus valstybinės kontrolės planų įrašus.
  • 9Sistemoje turi būti galimybė eksportuoti kiekvieną iš pasirinktų planų (csv, xls, kt.), visą sąrašą arba tik atfiltruotus duomenis.
  • 10Eksporto rinkmenoje turi būti atvaizduojamos tekstinės rizikos vertinimo reikšmės (didelė, maža, kt.).
  • 11Papildomai, sistemoje turi būti galimybė eksportuoti parengtus valstybinės kontrolės planus (dokumentus).
  • 12Sistemoje turi būti galimybė PRVPS specialistui ir PRVPS vadovui matyti plano būsenų kaitos istoriją (būseną, jos atnaujinimo datą ir laiką, naudotoją).
  • 13Sistemoje turi būti galimybė matyti detalaus įgyvendinimo planavimo duomenų kaitos istoriją.
  • 14Sistemoje patikrinimo / audito įrašo lygmenyje turi būti galimybė matyti detalius planavimui aktualius duomenis.
  • 15Sistemoje naudotojui turi būti pateikiamas grįžtamasis ryšys apie atliktus veiksmus.

Garantinis laikotarpis ir klaidų šalinimas

  • 1Visiems atliktiems programavimo darbams privalomas ne trumpesnis kaip 6 mėnesių garantinis laikotarpis.
  • 2Garantijos metu Paslaugos teikėjas privalo nemokamai šalinti visas atsiradusias klaidas, sutrikimus ar neatitikimus, tiesiogiai susijusius su atliktų darbų kokybe.
  • 3Užtikrinti, kad sistema veiktų pagal Techninės Specifikacijos reikalavimus garantijos laikotarpiu.
  • 4Paslaugos teikėjas įsipareigoja sureaguoti ir pašalinti atsiradusias klaidas ne ilgiau nei per 5 darbo dienas nuo pranešimo apie klaidą (-as) momento Tiekėjui.
  • 5Reakcijos laikas į technines klaidas produkcinei aplinkai – ne ilgiau kaip 2 (dvi) Tarnybos darbo val. nuo pranešimo iš Tarnybos gavimo.
  • 6Išsprendimo laikas kritinių klaidų atveju – ne ilgiau kaip 4 (keturios) Tarnybos darbo valandos.
  • 7Kritinė klaida – tai nustatyta OKIS klaida, dėl kurio daugiau nei 10 OKIS naudotojų dėl OKIS klaidų negali vykdyti būtinų funkcijų.
  • 8Išsprendimo laikas kitų klaidų atveju - ne ilgiau kaip 2 (dvi) Tarnybos darbo dienos.

Planavimas: atranka pagal nustatytą riziką

  • 1Į valstybinės kontrolės planą turėtų būti įtraukiama visa didelės rizikos pagal pirminį rizikos vertinimą veiklų imtis (privalomas periodiškumas 12 mėn., rikiavimas mažėjančia tvarka nuo didžiausią rizikos vertinimo balą turinčios veiklos).
  • 2Į valstybinės kontrolės planą turėtų būti įtraukiama visa didelės rizikos veiklų imtis (privalomas periodiškumas 12 mėn., rikiavimas mažėjančia tvarka).
  • 3Į valstybinės kontrolės planą turėtų būti įtraukiama visa vidutinės rizikos pagal pirminį rizikos vertinimą veiklų imtis, kurių planinio patikrinimo data sistemoje nėra nurodyta (privalomas periodiškumas 12 arba 24 mėn.).
  • 4Į valstybinės kontrolės planą turėtų būti įtraukiama visa vidutinės rizikos pagal pirminį rizikos vertinimą veiklų imtis, kurių planinio patikrinimo data sistemoje yra ankstesnė nei 12 mėn. (privalomas periodiškumas 12 arba 24 mėn.).
  • 5Į valstybinės kontrolės planą turėtų būti įtraukiamos visos vidutinės rizikos veiklų veiklos, kurių planinis patikrinimas buvo vykdytas daugiau nei prieš 12 mėn. (privalomas periodiškumas 24 mėn.).
  • 6Sistemoje taisyklės turėtų būti taikomos ir tikrintinų subjektų sąrašas sudaromas prioritetine tvarka.
  • 7Sudarant tikrintinų subjektų sąrašą pagal nustatytą riziką sistemoje turi būti vadovaujamasi plano parengimo patvirtinimo metu užfiksuota rizika.

Planavimas: žmogiškųjų išteklių valdymas

  • 1Sistemoje turi būti galimybė valdyti VMVT žmogiškuosius išteklius (inspektorių skaičių), reikalingus valstybinės kontrolės vykdymui.
  • 2Sistemoje turi būti galimybė planavimo metu suvesti / atnaujinti informaciją apie VMVT galimybes atlikti suplanuotus patikrinimus.
  • 3Žmogiškieji ištekliai turėtų būti suvedami remiantis planuojama metų, kuriems sudaromas planas, situacija.
  • 4Sistemoje turi būti galimybė suvesti kiekvieno teritorinio padalinio valstybinės kontrolės žmogiškųjų išteklių skaičių atskirai pagal kontroliuojamas sritis (Veterinarija; Maistas, geriamasis vanduo, su maistu besiliečiančios medžiagos ir gaminiai).
  • 5Sistemoje suvedant duomenis apie žmogiškuosius išteklius, naudotojui turi būti atvaizduojamos prielaidos, kuriomis remiantis yra paskaičiuojamas kiekvieno teritorinio padalinio galimų atlikti planinių patikrinimų skaičius per metus pagal kontroliuojamas sritis.
  • 6Suvedus duomenis apie planuojamus žmogiškuosius išteklius, sistema turi automatiškai paskaičiuoti kiekviename teritoriniame padalinyje galimą atlikti planinių patikrinimų skaičių bei bendrą VMVT galimą atlikti planinių patikrinimų skaičių.

Kibernetinio ir nacionalinio saugumo reikalavimai

  • 1Paslaugos neturi kelti grėsmės nacionaliniam saugumui.
  • 2Tiekėjas paslaugų teikimo metu privalo užtikrinti, kad jis ir jo pasitelkiami subjektai atitinka Lietuvos Respublikos Vyriausybės 2018-08-13 nutarimu Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įstatymo įgyvendinimo patvirtintame Kibernetinio saugumo reikalavimų apraše” esminiams kibernetinio saugumo subjektams nustatytus kibernetinio saugumo reikalavimus.
  • 3Perkančiajai organizacijai paprašius, Tiekėjas privalo pateikti paaiškinimus ir (ar) kitus įrodymus (pvz.: sertifikatus ir (ar) politikas, ir (ar) procesų aprašus, ir (ar) išorinio audito išvadas), kurie patvirtintų, kad Tiekėjas užtikrins atitiktį Aprašo reikalavimams.
  • 4Visi informacijos saugumo ir duomenų apsaugos reikalavimai, taikomi Tiekėjui, yra taikomi ir jo pasitelktam subtiekėjui (-ams), ūkio subjektui (-ams), kurio (kurių) pajėgumais remiasi ar kitais pagrindais pasitelkiamiems ūkio subjektams.
  • 5Tiekėjas galės vykdyti sutartį tik jam (subtiekėjui (-ams), ūkio subjektui (-ams), kurio pajėgumais remiamasi), jų specialistams pasirašius Konfidencialumo pasižadėjimo formą.
  • 6Konfidencialumo pasižadėjimo formos turi būti pasirašytos ir pateiktos Perkančiajai organizacijai per 1 d. d. nuo Viešojo pirkimo Sutarties įsigaliojimo dienos.
  • 7Keičiant / pasitelkiant naujus subtiekėjus, keičiant specialistus sutarties vykdymo metu – kartu su raštu sudaromu susitarimu turi būti pateikti šių subtiekėjų specialistų konfidencialumo pasižadėjimai.
  • 8Tiekėjas įsipareigoja nedelsiant informuoti Tarnybą apie informacinių ir ryšių technologijų infrastruktūroje pastebėtus didelius ir (ar) kitus elektroninės informacijos saugos incidentus, neveikiančias arba netinkamai veikiančias saugos užtikrinimo priemones, informacijos saugumo reikalavimų nesilaikymą, nusikalstamos veikos požymius, aptiktas saugumo spragas.
  • 9Būtina informuoti Tarnybą, bet ne vėliau kaip per 24 val., kai tiekėjo valdomoje informacinių sistemų infrastruktūroje buvo nustatyti minėti atvejai, kurie turi įtakos Tarnybos tvarkomiems duomenims.
  • 10Tiekėjas privalo Tarnybai pateikti kibernetinio incidento tyrimo ataskaitą, kurioje būtų išdėstyta visa turima informacija bei duomenys, susiję su incidentu, kai tyrimas bus užbaigtas.
  • 11Tiekėjas įsipareigoja sudaryti sąlygas Tarnybai arba jos įgaliotiems paslaugų teikėjams atlikti tiekėjo atitikties auditą (įskaitant neplaninį) Sutarties vykdymo laikotarpiu ar įvykus dideliam kibernetiniam incidentui.

Duomenys, aktualūs planavimui (būtinosios sąlygos)

  • 1Sistemoje turi būti importuotas pilnas veiklų, priklausančių veterinarijos, maisto, su maistu besiliečiančių medžiagų ir geriamojo vandens kontrolės grupėms, sąrašas su aktualia veiklų konfigūracija.
  • 2Sistemoje pakeitus veiklos būseną į „sustabdyta“ turi būti galimybė nurodyti veiklos stabdymo priežastį (reikšmių sąrašas pasirenkamas iš klasifikatoriaus) bei datą, nuo kurios veikla buvo / bus sustabdyta.
  • 3Sistemoje turi būti importuotas pilnas subjektų ir jiems aktualių duomenų (ūkio subjektai, veiklavietės, veiklų grupės, vykdomos veiklos), sąrašas.
  • 4Turi būti užtikrinta, kad visi patikrinimai, įskaitant ir RVASVT auditus, visiems ūkio subjektams bus inicijuojami ir vykdomi OKIS.
  • 5Sistemoje fiksuojant neatitiktis (trūkumus), turi būti aiškiai identifikuojama (ir saugoma) trūkumų fiksavimo data bei susiję kontrolės tikslai.
  • 6Sistemoje turi būti renkama ir saugoma informacija apie leidimo (licencijos) ūkio subjektui vykdyti veiklą išdavimo datą (registracijos / patvirtinimo data).
  • 7Sistemoje veiklos konfigūracijos lange turi būti papildomai sukonfigūruotas požymis „privalomas veiklos patikrinimas (vertinimas) vietoje iki leidimo išdavimo“.
  • 8Sistemoje veiklos konfigūracijos lange turi būti papildomai sukonfigūruotas požymis „kontrolė vykdoma visai veiklų grupei“.
  • 9Sistemoje veiklos konfigūracijos lange turi būti nustatyti / atnaujinti kontrolės tikslai.
  • 10Sistemoje veiklos konfigūracijos lange visoms maisto kontrolės grupės veikloms, kurioms aktualus audito kriterijus, turi būti sukonfigūruota papildoma galimybė nurodyti taikomo audito tipą.
  • 11Sistemoje turi būti galimybė nurodyti, kokiomis sąlygomis esant ūkio subjektai apie planinius patikrinimus / auditus turi būti privalomai informuojami iš anksto.
  • 12Sistemoje turi būti galimybė informaciją apie išankstinį ūkio subjektų informavimą konfigūruoti pagal veiklas, kontrolės tikslus, galimus taikyti atrankos kriterijus, patikrinimų porūšius.
  • 13Sistemoje turi būti galimybė skirtingiems atvejams numatyti skirtingą laiką, prieš kurį turi būti informuojamas ūkio subjektas.
  • 14Sistemoje pagal iš anksto apibrėžtas taisykles turi būti fiksuojami incidentai.
  • 15Sistemoje turi būti sukurta nauja VKO kontrolės grupei priklausanti veikla – ūkinių gyvūnų laikytojas su aktualia veiklos konfigūracija.
  • 16Sistemoje turi būti galimybė naujai sukurtai ūkinių gyvūnų laikytojo veiklai nurodyti laikomų gyvūnų rūšis pagal bendrą gyvūnų rūšių klasifikatorių (aktualios rūšys: avys, ožkos, galvijai, arklinių šeimos gyvūnai, kiaulės).
  • 17Sistemoje turi būti galimybė fiksuoti ir atnaujinti (rankiniu būdu) Lietuvos Respublikos teritorijoje esančių ūkių, kuriuose laikomi galvijai, avys, ožkos ir arklinių šeimos gyvūnai, skaičių.
  • 18Sistemoje turi būti užtikrintas savalaikis duomenų gavimas iš ŽŪDC ir tinkamas jų apdorojimas (realizuojant API arba importuojant XLS failą).
  • 19Sistemoje vykdant ūkinių gyvūnų laikytojų, kurie augina kiaules, veiklos patikrą turi būti įgyvendinta galimybė (privalomas laukas) nurodyti / atnaujinti vieną iš reikšmių: Verslinė kiaulių laikymo vieta, Neverslinė kiaulių laikymo vieta.
  • 20Sistemoje turi būti automatiškai užfiksuota, kurie ūkinių gyvūnų laikytojai, auginantys kiaules, yra priskirtini verslinėms kiaulių laikymo vietoms.
  • 21Sistemoje turi būti galimybė kaupti ūkinių gyvūnų laikytojų, auginančių kiaules, kiaulių skaičių ir paršavedžių skaičių (duomenys turėtų būti sinchronizuojami su ŽŪDC turimais duomenimis).
  • 22Sistemoje turi būti galimybė nurodyti patvirtintas apribojimų taikymo zonas (seniūnijų, savivaldybių ir rajonų lygmeniu) (I, II, III AKM zona).
  • 23Sistemoje turi būti galimybė apribojimų taikymo zonas atnaujinti metų eigoje.
  • 24Sistemoje turi būti galimybė kiekvienais metais kiekvienam rajonui fiksuoti patvirtintų AKM atvejų skaičių.
  • 25Sistema turėtų automatiškai paskaičiuoti Lietuvos Respublikos patvirtintų AKM atvejų vidurkį ir pažymėti visus rajonus, kuriuose patvirtintų AKM atvejų skaičius viršija vidurkį.
  • 26Sistemoje vykdant skerdimo veiklą ar skerdimo veiklų grupės veiklas turi būti galimybė nurodyti informaciją apie skerdenų klasifikavimą (privalomas laukas): Skerdenų klasifikavimas privalomas, Skerdenų klasifikavimas vykdomas savanoriškai, Skerdenos nėra klasifikuojamos.
  • 27Sistemoje turi būti automatiškai užfiksuotos pirminės skerdenų klasifikavimo reikšmės aktualioms veikloms.
  • 28Sistemoje turi būti galimybė prieš formuojant patikrinimų planus atitinkamoms veikloms nurodyti paskutinio planinio patikrinimo ir paskutinio planinio audito datas (tais atvejais, kai duomenų nėra OKIS).

Planavimas: atsitiktinės subjektų atrankos algoritmas

  • 1Sistemoje turi būti įgyvendintas funkcionalumas atsitiktinės tikrintinų subjektų atrankos vykdymui, naudojant statistiškai pagrįstą atsitiktinumo mechanizmą.
  • 2Algoritmas turi užtikrinti, kad kiekvienas nustatytus parametrus atitinkantis subjektas turėtų vienodą tikimybę būti atrinktas.
  • 3Sistema turėtų užtikrinti, kad per tą patį atrankos ciklą tas pats subjektas nebūtų parinktas daugiau nei vieną kartą.
  • 4Vykdant atsitiktinę atranką, sistema neturėtų siūlyti į planą įtraukti jau įtrauktų veiklų pagal kitus kriterijus ir / arba veiklų, kurios į valstybinės kontrolės planą jau pateko kaip veiklų grupės dalis.
  • 5Sistema turi palaikyti stratifikacijos galimybę – atsitiktinę atranką vykdyti skirtingose duomenų grupėse.
  • 6Sistemoje turi būti galimybė nustatyti atrankos dydį (visą pasirinktą patikrinimų imtį, procentinę dalį arba tikslų tikrintinų subjektų skaičių).
  • 7Sistemoje atsitiktinės atrankos taikymo taisyklės turi būti konfigūruojamos, PRVPS specialistas turi turėti galimybę nustatyti papildomus parametrus atsitiktinei atrankai (kontrolės grupė, veiklų grupė, veikla, rizikos vertinimo statusas, rizikos vertinimas, rinkos kriterijus, teritorinis padalinys, paskutinio planinio patikrinimo data yra ankstesnė nei..., paskutinio planinio audito data yra ankstesnė nei...).
  • 8Sistemoje turi būti galimybė atsitiktinę atranką vykdyti kombinuojant kelis skirtingus parametrus.
  • 9Sistemoje turi būti galimybė pasirinkti kelias skirtingas parametro (filtro) reikšmes.
  • 10Vykdant atsitiktinę atranką sistemoje privalomai turi būti atrenkami subjektai iš visų duomenų grupių.
  • 11Sistemoje atrinkus tikrintinus subjektus naudojant atsitiktinės atrankos algoritmą, valstybinės kontrolės plane atrankos kriterijaus skiltyje turi būti automatiškai nurodomas kriterijaus pavadinimas.
  • 12Sistemoje turi būti galimybė atrinktai imčiai nurodyti patikrinimų periodiškumą (metinio plano ribose).
  • 13Atrankos proceso trukmė neturi būti ilgesnė nei 60 s.

Planavimas: valstybinės kontrolės planų atnaujinimas

  • 1Patvirtintas planas gali būti atnaujintas metų eigoje. Planą atnaujina PRVPS specialistas.
  • 2Planas gali būti koreguojamas tik pakeitus plano būseną į „Atnaujinamas“.
  • 3Prieš atnaujinant planą PRVPS specialistas turi turėti galimybę sistemoje pasitikrinti aktualius atnaujinimus.
  • 4Sistemoje turi būti galimybė pasirinkti pokyčių patikros laikotarpį.
  • 5Sistema vykdant plano atnaujinimą turėtų informuoti naudotoją apie identifikuotus pokyčius.
  • 6Plano įrašų perkėlimas „virš brūkšnio“ ir / ar patikrinimų / auditų pašalinimas vykdomas rankiniu būdu.
  • 7Atnaujinant planą sistema neturėtų leisti iš plano pašalinti jau atliktų patikrinimų.
  • 8Sistemoje turi būti galimybė PRVPS specialistui patvirtinti, kad atitinkamas valstybinės kontrolės planas yra atnaujintas.
  • 9Teikiant atnaujintą planą tvirtinimui, sistemoje turi būti aiškiai matomos atliktos korekcijos (pašalinti ir / ar naujai pridėti tikrintinų subjektų įrašai turi būti pažymėti).
  • 10Atnaujinto plano tvirtinimo eiga sistemoje turėtų būti identiška įprastai valstybinės kontrolės plano tvirtinimo eigai, išskyrus tai, kad papildomai prie būsenų turėtų būti pridedama indikacija, nurodanti, kad planas yra atnaujintas.
  • 11Tik planui įgavus būseną „Atnaujintas, patvirtintas VMVT direktoriaus“, jis turėtų būti atvaizduojamas teritoriniams padaliniams.
  • 12Sistemoje turi būti galimybė atnaujintam patvirtintam planui nurodyti aktualaus įsakymo numerį.
  • 13Sistemoje turi būti galimybė plano įgyvendinimą detalizuojančius duomenis (teritorinius padalinius, numatomas patikrinimo datas, priskirtus pareigūnus) keisti metų eigoje, remiantis aktualia situacija.

Bendrieji valstybinės kontrolės planavimo reikalavimai

  • 1Sistemoje turi būti galimybė automatizuoti valstybinės kontrolės planavimo proceso eigą, užtikrinant tinkamą proceso žingsnių eiliškumą, atskirų planų būsenų atnaujinimą bei atsakomybes.
  • 2Kiekvienas valstybinės kontrolės planas sistemoje turi turėti šias būsenas: Rengiamas, Laukiama patikslinimo, Duomenys patikslinimui pateikti, Parengtas, Patvirtintas PRVPS vadovo, Patvirtintas Priežiūros departamento specialisto, Patvirtintas Priežiūros departamento vadovo, Patvirtintas VMVT direktoriaus, Tikslinamas, Atnaujinamas, Atnaujintas, Atnaujintas, patvirtintas PRVPS vadovo, Atnaujintas, patvirtintas Priežiūros departamento specialisto, Atnaujintas, patvirtintas Priežiūros departamento vadovo, Atnaujintas, patvirtintas VMVT direktoriaus.
  • 3Sistemoje turi būti galimybė valstybinės kontrolės planus rengti iš OKIS duomenų.
  • 4Tais atvejais, kai kitos institucijos pateikia informaciją apie tikrintinus ūkio subjektus, kurių nėra OKIS, tokius ūkio subjektus su visais plano parengimui aktualiais duomenimis turi būti galimybė į OKIS sistemą importuoti ir/arba suvesti ranka.
  • 5Turi būti galimybė nurodyti daugiau nei vieną atrankos kriterijų, kuriuo remiantis ūkio subjektai turėtų būti įtraukti į valstybinės kontrolės planą.
  • 6Sistemoje turi būti galimybė valdyti plano galiojimo statusus: galiojantis, negaliojantis.
  • 7Planas galiojimą statusą „galiojantis“ turėtų įgauti automatiškai planui įgijus būseną „patvirtintas VMVT direktoriaus“ bei prasidėjus laikotarpiui, kuriam yra parengtas planas (ne anksčiau nei sausio 1 d.).
  • 8Plano statusas sistemoje automatiškai turėtų būti pakeičiamas į „negaliojantis“ kitų metų sausio 1 d., kai visi suplanuoti patikrinimai yra įvykdyti, arba prie visų neįgyvendintų patikrinimų teritoriniai padaliniai yra nurodę patikrinimų neįvykdymo priežastis.
  • 9Sistemoje turi būti galimybė PRVPS specialistui plano būseną į „Negaliojantis“ pakeisti rankiniu būdu.
  • 10Sistema neturėtų leisti inicijuoti patikrinimų remiantis negaliojančiu planu.
  • 11Sistemoje patvirtinti planai turi būti versijuojami.
  • 12Sistemoje turi būti galimybė atitinkamas teises turinčiam naudotojui peržiūrėti ankstesnes plano versijas.
  • 13Sistemoje turi būti saugomi istoriniai valstybinės kontrolės planai ir su jų įgyvendinimu susiję duomenys.

Planavimas: pavedimų formavimas ir patikrinimų vykdymas

  • 1Sistemoje turi būti galimybė vykdyti detalų plano įgyvendinimo planavimą (priskirti tikslias patikrinimų datas, konkrečius VMVT darbuotojus ir pan.) plano įgyvendinimo skiltyse.
  • 2Sistemoje suplanuotam patikrinimui / auditui priskiriant pareigūnus, naudotojas turi būti automatiškai informuojamas, jei priskiriamas pareigūnas jau anksčiau dalyvavo tikrinant ūkio subjektą (sistemoje turėtų būti vertinamas pareigūno dalyvavimas vykdant du paskutinius patikrinimus / auditus).
  • 3Sistemoje turi būti galimybė teritorinių padalinių vadovams valstybinės kontrolės plane patikrinimus ir / arba auditus susirūšiuoti pagal ūkio subjektus ir jiems priklausančias veiklavietes.
  • 4Sistema plano įgyvendinimo skiltyje turėtų iš anksto informuoti naudotoją apie patikrinimus, kuriems yra taikomas periodiškumo kriterijus.
  • 5Sistema plano įgyvendinimo skiltyje turėtų identifikuoti patikrinimus / auditus, kurių įgyvendinimui yra būtinas išankstinis ūkio subjekto informavimas.
  • 6Planavimo lango įgyvendinimo skiltyje priskyrus planuojamo patikrinimo datą ir pareigūnus, sistemoje turėtų būti automatiškai suformuojamas įvykis, kurio pagrindu turėtų būti galimybė formuoti pavedimą (duomenys turėtų būti užpildoma automatiškai).
  • 7Sistemoje formuojant pavedimą patikrinimui, kuris į tikrintinų subjektų sąrašą pateko pagal atrankos kriterijų „žemės ūkio veiklą vykdantis ūkio subjektas, pateikęs paraišką valstybės paramai gauti (NMA)“ naudotojui prie kontrolės tikslų turi būti papildomai atvaizduojamas informacinis pranešimas.
  • 8Naudotojas, formuojantis pavedimą, turėtų turėti galimybę automatiškai užpildytus duomenis koreguoti.
  • 9Sistemoje turi būti galimybė inicijuoti patikrinimus (formuoti pavedimus) tik konkrečiam teritoriniam padaliniui priskirtiems patikrinimams.
  • 10Sistemoje formuojant pavedimus turi būti galimybė pasirinkti tik pareigūnus / inspektorius, priskirtus atitinkamam teritoriniam padaliniui.
  • 11Tais atvejais, kai vienam patikrinimui ar auditui yra priskirtas daugiau nei vienas padalinys, pavedimą formuoja Priežiūros departamento vadovas.
  • 12Sistemoje nustatant patikrinimo datas neturėtų būti leidžiama pasirinkti ankstesnės datos, nei šiandiena.
  • 13Planuojant tikslias pavedimų atlikimo datas naudotojui turi būti aiškiai atvaizduojami rekomendacijos / apribojimai (pagal įvairius kriterijus ir periodiškumą).
  • 14Sistemoje turi būti galimybė atitinkamais atvejais: pasirinkti kitą patikrinimo datą, patvirtinti savo pasirinkimą, apjungti patikrinimus į vieną.
  • 15Tuo atveju, jei funkcionalumo įgyvendinimo metu dalis tikrintinų ūkio subjektų patikrinimų / auditų bus vykdomi už OKIS sistemos ribų, sistemoje turi būti galimybė patikrinimo / audito atlikimo datą suvesti rankiniu būdu.
  • 16Tais atvejais, kai suplanuotų patikrinimų atlikti nėra galimybės, sistemoje turi būti galimybė nurodyti dėl kokių priežasčių patikrinimas nebuvo įvykdytas OKIS (sąrašas priežasčių: Ūkio subjektas nebevykdo veiklos ir/arba ūkio subjektas yra panaikintas, Didelis darbuotojų sergamumas, Inspektorių trūkumas, Transporto priemonių trūkumas, Atlikto patikrinimo/audito duomenys užfiksuoti kitoje VMVT naudojamoje informacinėje sistemoje, Kita (su laisvo teksto lauku)).

Planavimas: tikrintinų subjektų sąrašų sudarymas ir valdymas

  • 1Sistemoje turi būti galimybė prieš formuojant patikrinimų planus atnaujinti rizikos vertinimo skaičiavimą.
  • 2Sistema turėtų automatiškai suformuoti du tikrintinų subjektų sąrašus / planus pagal kontroliuojamas sritis: Veterinarinės kontrolės subjektų valstybinės kontrolės planas; Maisto, geriamojo vandens ir su maistu besiliečiančių medžiagų bei gaminių subjektų valstybinės kontrolės planas.
  • 3Sistemoje tikrintinų subjektų sąrašai sudaromi pagal skirtingus atrankos kriterijus, kurių kiekvienam atitinkamai turėtų būti sistemoje priskirti prioritetai.
  • 4Sistemoje turi būti galimybė tvarkyti atrankos kriterijus ir keisti jų prioritetus.
  • 5Tam tikrais atvejais, kai subjektų atrankos nėra galimybės automatizuoti, sistemoje turi būti galimybė naudojantis paieškos funkcionalumu tokius tikrintinus subjektus pridėti į planą rankiniu būdu, nurodant atrankos kriterijų (-us).
  • 6Rankiniu būdu priskyrus atrankos kriterijus, pasirinkti kriterijai turėtų būti fiksuojami to plano ribose.
  • 7Formuojant planą, sistema turi automatiškai patikrinti veiklos būseną ir ūkio subjekto būseną.
  • 8Esant veiklos būsenai „Panaikinta“ ir / arba ūkio subjekto būsenai „Panaikintas“, šis tikrintinas subjektas arba veikla neturi būti traukiami į planą.
  • 9Esant veiklos būsenai „sustabdyta“, veiklos / veiklų grupės patikrinimas turėtų būti traukiamas į planą, tik tuo atveju, kai nuo veiklos sustabdymo yra praėję 12 ar daugiau mėnesių.
  • 10Sistemoje turi būti galimybė automatiškai suformuoti tikrintinų subjektų sąrašą, remiantis atrankos kriterijų prioritetais bei duomenimis apie suvestus žmogiškuosius išteklius.
  • 11Sistemoje turi būti galimybė pasirinkti, ar valstybinės kontrolės planas formuojamas visa apimtimi iš karto, ar planai formuojami atskirai planą pildant kiekvieno pasirinkto atrankos kriterijaus apimtimi.
  • 12Sistemoje tikrintinų subjektų atranka yra vykdoma pagal veiklas, tačiau valstybinė kontrolė planuojama veiklų grupei (papildomai atrenkant visas veiklas, susijusias su veikla).
  • 13Sistemoje turi būti galimybė peržiūrėti kiekvieno plano už brūkšnio esančius patikrinimus ir priimti sprendimą dėl jų perkėlimo į planą arba pašalinimo iš plano.
  • 14Sistemoje turi būti galimybė bet kurį ūkio subjektą rankiniu būdu pašalinti iš valstybinės kontrolės plano.
  • 15Įrašas iš plano gali būti pašalinamas tik tuo atveju, kai planas dar nėra patvirtintas, arba tuomet, kai plano būsena yra „atnaujinamas“.
  • 16Pašalinant iš plano įrašą privalomai turi būti nurodomos tokio veiksmo priežastys.
  • 17Sistemoje turi būti galimybė bet kurį ūkio subjektą rankiniu būdu įtraukti į valstybinės kontrolės planą.
  • 18Norint įtraukti papildomus įrašus į valstybinės kontrolės planą, privalomai turi būti nurodomas įtraukimo pagrindas / priežastis (atrankos kriterijus).
  • 19Sistemoje turi būti atvaizduojama, kurie subjektai pagal kuriuos atrankos kriterijus pateko į valstybinės kontrolės planą.
  • 20Nepriklausomai nuo kriterijų skaičiaus, toks atvejis turėtų būti planuojamas kaip vienas patikrinimas (su išimtimis RVASVT auditams ir atnaujinamiems planams).
  • 21Suformavus tikrintinų subjektų sąrašus, sistemoje kiekvienam patikrinimui turi būti atvaizduojamas priskirtas teritorinis padalinys.
  • 22Valstybinės kontrolės plano užpildymą turi būti galimybė atvaizduoti pagal: Kontroliuojamas sritis, Veiklų grupes, Veiklas, Atrankos kriterijus.
  • 23Sistemoje turi būti užtikrinta, kad pirmą kartą planinis patikrinimas gali būti atliekamas praėjus ne mažiau kaip 6 mėnesiams po leidimo (licencijos) ūkio subjektui vykdyti veiklą išdavimo (išskyrus atvejus, kai leidimas ūkio subjektui išduotas be jo veiklos patikrinimo vietoje).
  • 24Užtikrinant asmens duomenų apsaugą, valstybinės kontrolės planuose neturi būti atvaizduojami tikrintinų fizinių asmenų vardai, pavardės, asmens kodai, o šie duomenys plane turėtų būti nuasmeninami.

Valstybinės kontrolės planų duomenų struktūra ir atvaizdavimas

  • 1Sistemoje valstybinės kontrolės planai turi būti atvaizduojami viename lange, suteikiant galimybę naudotojui kiekvieno plano duomenis tvarkyti atskirai.
  • 2Sistemoje turi būti galimybė viename lange atvaizduoti visą valstybinės kontrolės planavimui ir įgyvendinimo priežiūrai aktualią informaciją.
  • 3Valstybinės kontrolės planų skiltys, kurių duomenys sistemoje turėtų būti užpildomi automatiškai suformavus kontrolės planus (šie duomenys plane neturėtų būti koreguojami): Nr., Subjektas (Kodas, Pavadinimas), Veiklavietė (Kodas, Pavadinimas, Adresas, Padalinys), Veikla (Grupė, Kodas, Pavadinimas, Registravimo data), Rizika (Veikla, %, Veiklų grupė, %, Veiklavietė, Subjektas), Paskutinio planinio patikrinimo data, Paskutinio RVASVT audito data, Patikrinimų / auditų apimtis, vnt., Atrankos kriterijai, Kontrolės tikslai.
  • 4Skiltys, kuriose duomenis pildo (arba duomenys užpildomi automatiškai) Priežiūros departamento atsakingi specialistai: Priskirtas padalinys, Planuojamo patikrinimo / audito data, Priskirti pareigūnai, Įvykis, Įgyvendinimas, Atlikimo data, Kontrolės turinys, Pastabos, Priežastis.
  • 5Sistemoje kiekvienam patikrinimui valstybinės kontrolės plane turi būti automatiškai suteikiamas patikrinimo numeris, sudaromas remiantis tokia struktūra: kontrolės grupės trumpinys (VKO, MST, GER, MBM)/metai/įrašo numeris (pvz., VKO/2027/0001).
  • 6Paskutinio planinio patikrinimo data – paskutinio planinio patikrinimo data, sistemoje užpildoma automatiškai.
  • 7Paskutinio RVASVT audito data – paskutinio RVASVT audito data, sistemoje užpildoma automatiškai.
  • 8Patikrinimų / auditų apimtis, vnt. – automatiškai paskaičiuojama patikrinimų / auditų apimtis.
  • 9Atrankos kriterijai – užpildoma automatiškai pagal atrankos kriterijų (-us).
  • 10Kontrolės tikslai – užpildomi automatiškai pagal veiklos konfigūracijoje nurodytus duomenis.
  • 11Priežiūros departamento pateikiami duomenys: Priskirtas padalinys (pagal nutylėjimą sistemoje atvaizduojamas teritorinis padalinys, su galimybe pakeisti).
  • 12Teritorinių padalinių pateikiami duomenys: Planuojamo patikrinimo / audito data, Priskirti pareigūnai, Įvykis (aktyvi nuoroda, kurią paspaudus turėtų būti formuojamas pavedimas), Įgyvendinimas (įrašas, pažymimas automatiškai, priklausomai nuo planuojamo patikrinimo datos ir atlikimo datos), Atlikimo data (data, užpildoma automatiškai atlikus patikrinimą / auditą, išskyrus atvejus, kai patikrinimas / auditas nebus fiksuojamas OKIS sistemoje), Kontrolės turinys (užpildoma automatiškai, pagal pavedime nurodytus / atnaujintus kontrolės tikslus), Priežastis (patikrinimo neatlikimo priežastis, nurodoma rankiniu būdu reikšmes pasirenkant iš klasifikatoriaus reikšmių).
  • 13Pastabų laukas gali būti užpildytas automatiškai.
  • 14Sistemoje 'daugiaveikliai' ūkio subjektai turėtų būti atvaizduojami taip, kad vieną eilutę skiriant vienai veiklai.

Planavimas: kontrolės planų tvirtinimas ir perdavimas įgyvendinimui

  • 1Sistemoje turėtų būti įgyvendintas kelių lygių valstybinės kontrolės planų tvirtinimas (derinimas): PRVPS specialisto patvirtinimas, PRVPS vadovo tvirtinimas, Priežiūros departamento specialisto tvirtinimas / derinimas, Priežiūros departamento vadovo tvirtinimas / derinimas, VMVT direktoriaus tvirtinimas.
  • 2Sistemoje turi būti galimybė patvirtinti vieną, kelis ar visus kontrolės planus vienu metu.
  • 3Tik galutinai (VMVT direktoriaus) patvirtintas planas gali būti pradėtas įgyvendinti.
  • 4Sistemoje turi būti galimybė administratoriui konfigūruoti el. pranešimus, siunčiamus proceso dalyviams.
  • 5Jei planas nėra patvirtinamas per nustatytą laiko tarpą, naudotojui turėtų būti siunčiami papildomi priminimai.
  • 6Sistemoje turi būti galimybė PRVPS specialistui patvirtinti, kad atitinkamas valstybinės kontrolės planas yra parengtas.
  • 7Sistemai turėtų automatiškai patikrinti, ar užpildyti visi planui reikalingi duomenys tvirtinimo metu.
  • 8Tuo atveju, kai dalis duomenų nėra užpildyta, sistema turėtų atvaizduoti klaidos pranešimą.
  • 9Sistemoje planui įgavus būseną „Parengtas“ turi būti automatiškai siunčiamas informacinis pranešimas PRVPS vadovui.
  • 10Valstybinės kontrolės planas yra tvirtinamas be subjektų „už brūkšnio“.
  • 11PRVPS vadovo rolę turintis naudotojas turi turėti galimybę planą patvirtinti arba grąžinti tikslinti nurodant grąžinimo priežastį.
  • 12PRVPS vadovo patvirtintas planas sistemoje automatiškai turėtų įgauti būseną „Patvirtintas PRVPS vadovo“.
  • 13Planui įgavus būseną „Patvirtintas PRVPS vadovo“ turi būti automatiškai siunčiamas informacinis pranešimas Priežiūros departamento specialistui.
  • 14Priežiūros departamento specialistas turi turėti galimybę planą patvirtinti arba grąžinti tikslinti nurodant grąžinimo priežastį.
  • 15Priežiūros departamento specialisto patvirtintas / suderintas planas sistemoje automatiškai turėtų įgauti būseną „Patvirtintas Priežiūros departamento specialisto“.
  • 16Prieš tvirtinant planą, turi būti suteikiama galimybė įvertinti kiekvieno teritorinio padalinio galimybes patikrinti automatiškai priskirtų patikrinimų skaičių.
  • 17Sistemoje susidarius situacijai, kuomet bendras VMVT tikrintinų subjektų sąrašas neatitinka atskirų teritorinių padalinių galimybių, Priežiūros departamento atsakingam asmeniui turi būti suteikiama galimybė: Perskirstyti tikrintinų subjektų sąrašus kitiems teritoriniams padaliniams ir/arba priskirti papildomus padalinius, arba patvirtinti, kad susipažinta su pranešimu, tačiau planas yra paliekamas toks, kokį suformavo sistema.
  • 18Teritorinių padalinių perskirstymas turėtų būti vykdomas tik planavimo kontekste, t.y., neturi būti pakeistas objektui priskirtas teritorinis padalinys.
  • 19Priežiūros departamento vadovo patvirtintas / suderintas planas sistemoje automatiškai turėtų įgauti būseną „Patvirtintas Priežiūros departamento vadovo“.
  • 20VMVT direktoriaus patvirtintas planas sistemoje automatiškai turėtų įgauti būseną „Patvirtintas VMVT direktoriaus“.
  • 21Sistemoje VMVT direktoriaus patvirtintam planui turėtų būti automatiškai priskiriamas plano numeris, identifikuojantis plano apimtį bei valstybinės kontrolės plano metus (pvz., VKO/2027/v1 ir / arba MST,GER,MBN/2027/v1).
  • 22Sistemoje turi būti galimybė patvirtintam planui nurodyti aktualaus VMVT direktoriaus įsakymo numerį.

Planavimas: valstybinės kontrolės planų sąsaja su neplaniniais patikrinimais

  • 1Sistema turėtų suteikti galimybę užkirsti kelią taisyklių nesilaikymui, pvz., inicijuojant neplaninį patikrinimą, kai tai pačiai veiklai / veiklų grupei jau yra suplanuotas planinis patikrinimas, rekomenduoti apjungti patikrinimus į planinį patikrinimą.
  • 2Sistema inicijuojant patikrinimą rankiniu būdu neturėtų leisti pasirinkti planinio patikrinimo (išskyrus atitinkamas teises turinčiam naudotojui).
  • 3Valstybinės kontrolės kalendoriaus grafiniame atvaizdavime planiniai ir neplaniniai patikrinimai turi būti aiškiai atskirti.
  • 4Vertinant valstybinės kontrolės plano įgyvendinimo progresą, turi būti vertinami tik planiniai patikrinimai, išskyrus atvejus, kai naudotojas pasirenka patikrinimų peržiūrą pagal patikrinimų rūšis ir / ar porūšius.

Veterinarinės kontrolės subjektų valstybinės kontrolės (planinių patikrinimų) plano sukūrimas

  • 1Paslaugos teikėjas privalės sukurti funkcionalumą taip, kaip jis aprašytas Valstybinės kontrolės planavimo modelio (Techninės specifikacijos priedėlis Nr. 1) 4.2.4 punkte, įskaitant atrankos kriterijus.

Planavimas: veterinarinės kontrolės subjektų valstybinės kontrolės (planinių patikrinimų) planas

  • 1Veterinarinės kontrolės subjektų valstybinės kontrolės planas sudaromas veterinarinei kontrolei priskiriamoms ūkio subjektų vykdomoms veikloms / veiklų grupėms (VKO kontrolės grupė).
  • 2Planas sudaromas remiantis kriterijais ir jų prioritetais: Žemės ūkio veiklą vykdantis ūkio subjektas, pateikęs paraišką valstybės paramai gauti (NMA), Ūkinių gyvūnų laikymo vieta dėl registravimo ir ženklinimo ir kitų reikalavimų laikymosi (3%), Verslinė kiaulių laikymo vieta, Valstybinės kontrolės dažnumas numatytas ES ir / arba LT teisės aktuose, Akvakultūros subjektų veiklos grupei priklausantis ūkio subjektas, Bandomųjų gyvūnų naudojimo įmonė, Veterinarinių vaistų, veikliųjų medžiagų gamybos, importo veiklą vykdanti įmonė, Didmeninės veterinarinių vaistų prekybos, veikliųjų medžiagų platinimo veiklą vykdanti įmonė, Privalomas RVASVT auditas, Atranka, pagal nustatytą riziką, Neverslinė kiaulių laikymo vieta, Tikslinė atranka (atsitiktinė atranka), Kita.

Maisto, geriamojo vandens ir su maistu besiliečiančių medžiagų bei gaminių valstybinės kontrolės (planinių patikrinimų) plano sukūrimas

  • 1Paslaugos teikėjas privalės sukurti funkcionalumą taip, kaip jis aprašytas Valstybinės kontrolės planavimo modelio (Techninės specifikacijos priedėlis Nr. 1) 4.2.5 punkte, įskaitant atrankos kriterijus.

Planavimas: maisto, geriamojo vandens ir su maistu besiliečiančių medžiagų bei gaminių valstybinės kontrolės (planinių patikrinimų) planas

  • 1Maisto, geriamojo vandens ir su maistu besiliečiančių medžiagų bei gaminių kontrolės subjektų valstybinės kontrolės planas sudaromas MST, GER ir MBM kontrolės grupėms.
  • 2Planas sudaromas remiantis kriterijais ir jų prioritetais: Žemės ūkio veiklą vykdantis ūkio subjektas, pateikęs paraišką valstybės paramai gauti (NMA), Valstybinės kontrolės dažnumas numatytas ES ir / arba LT teisės aktuose, Privalomas RVASVT auditas, Atranka, pagal nustatytą riziką, Tikslinė atranka (atsitiktinė atranka), Kita.

Dokumentai5

  • 2_1 priedas_Technine specifikacija.docx
  • 1516_7184665.pdf
  • 3_1 priedo priedelis 1_Kontrolės planavimas (planiniai patikrinimai).docx
  • 1_KVIETIMAS DALYVAUTI RINKOS KONSULTACIJOJE_OKIS.docx
  • 4_2 priedas Kvalifikacijos reikalavimai.docx
tendis.lt · Sukurta recodin.lt