Mobilios aplikacijos, skirtos papildomų naudų valdymui, nuoma, palaikymo (priežiūros) ir vystymo paslaugos
Išanalizuota
AB „Miesto gijos“ (PV)
Skelbiamos derybos pagal PĮCPV: 48445000 - Ryšių su klientais valdymo programinės įrangos paketai
ID: 79490622026-05-20 12:47Pasiūlymai iki: 2026-06-02 14:00
Atidaryti CVP ISAprašymas
Perkama mobiliosios aplikacijos, skirtos darbuotojų papildomoms naudoms valdyti, nuoma bei su ja susijusios palaikymo ir vystymo paslaugos. Sistema apims administravimo platformą ir mobiliąją aplikaciją, kurios veiks 24 mėnesius ir bus pritaikytos apie 750 naudotojų.
Kvalifikaciniai reikalavimai
- 1Tiekėjas turi būti įsidiegęs ir Sutarties vykdymo laikotarpiu perkamoms paslaugoms taikys organizacinės ir techninės saugumo valdymo priemones pagal standartą ISO 27001 arba kitus informacijos saugumo valdymo sistemos standartus, pagrįstus atitinkamais Europos arba tarptautinių standartizacijos organizacijų priimtais standartais, ar kitais tiekėjo pateiktais lygiaverčiais įrodymais. Pateikiamas nepriklausomos įstaigos išduotas sertifikatas, patvirtinantis, kad tiekėjas laikosi nurodytų informacijos saugumo valdymo sistemos standartų arba lygiaverčių standartų.
Techniniai reikalavimai
Sistemos diegimas
- 1Tiekėjas privalo per ne ilgesnį kaip 1 (vieno) mėnesio laikotarpį nuo Sutarties įsigaliojimo dienos įdiegti Sistemą ir parengti ją naudojimui Perkančiojo subjekto aplinkoje.
- 2Per 1 (vieno) mėnesio laikotarpį Tiekėjas privalo parengti ir su Perkančiuoju subjektu suderinti Sistemos diegimo planą.
- 3Sistemos diegimo plane turi būti aiškiai aprašyti pagrindiniai diegimo etapai, jų seka, numatomi terminai bei Šalių atsakomybės.
- 4Diegimo plane turi būti apimami ne mažiau kaip šie elementai: Sistemos parengimo ir konfigūravimo darbai; importuojamų duomenų apimtys, formatai ir importavimo tvarka; testavimo ir priėmimo etapai; Sistemos paleidimas į eksploataciją ir perdavimas naudoti.
- 5Diegimo metu turi būti suderinti importuojami duomenys, jų apimtys ir formatai.
- 6Sistemos diegimo planas turi būti parengtas taip, kad užtikrintų Sistemos įdiegimą ir pradėjimą naudoti per nustatytą terminą, nedarant neigiamo poveikio Perkančiojo subjekto veiklai.
Mokymo reikalavimai
- 1Jei Perkantysis subjektas pageidauja, Tiekėjas turi atlikti Sistemos Naudotojams nemokamus mokymus apie Užsakyme numatytų funkcionalumų naudojimą.
- 2Iki mokymų pradžios Tiekėjas turi parengti ir su Perkančiuoju subjektu suderinti mokymų medžiagą (mokymų medžiaga turi būti suskirstyta pagal tam tikriems naudotojams aktualias mokymų sritis) ir Naudotojams, Sistemos administratoriams vaizdo instrukcijas.
- 3Tiekėjas, remdamasis parengtu ir su Perkančiuoju subjektu suderintu mokymų planu, turi apmokyti būsimus Sistemos Naudotojus (administravimo platformos ir mobiliosios aplikacijos gyvi mokymai atskiroms tikslinėms Naudotojų grupėms).
- 4Tiekėjas atsakingas už mokymų medžiagos ir priemonių mokymams parengimą (apimant Sistemos funkcionalumą, mokymų duomenis, mokymų dokumentaciją, Sistemos konfigūravimą ir kt.).
- 5Tiekėjas naujų funkcionalumų mokymus turi atlikti nemokamai. Naudotojų mokymai turi vykti lietuvių kalba.
Sistemos nuomos paslaugos
- 1Tiekėjas Perkančiajam subjektui kartu su sąskaita kas ketvirtį pateikia priėmimo-perdavimo aktą, kuriame nurodomas faktinis tuo ketvirčiu Sistemoje esančių aktyvių naudotojų prenumeratų skaičius.
Dokumentacijos reikalavimai
- 1Visa dokumentacija turi būti parengta lietuvių kalba, vadovaujantis bendrinės lietuvių kalbos taisyklėmis.
- 2Dokumentų visos versijos turi būti pateiktos elektroniniu formatu. Dokumentų galutinės versijos papildomai turi būti pateiktos redagavimui tinkamu formatu (.doc, .docx, .pdf arba kitu su Perkančiuoju subjektu suderintu formatu).
Rezervinių kopijų valdymas
- 1Sistemos konfigūracija ir duomenys turi būti apsaugoti rezervinėmis kopijomis, kad būtų užtikrintas nepertraukiamas Sistemos pasiekiamumas ir duomenų atstatymas po incidento (angl. Disaster Recovery).
- 2Tiekėjas, Perkančiajam subjektui paprašius, turi užtikrinti galimybę pateikti Sistemoje sukauptų Naudotojų duomenų kopiją už nurodytą laikotarpį (Perkančiojo subjekto specifinius duomenis, pavyzdžiui – Naudotojų profilių duomenis).
Sistemos moduliai ir apimtis
- 1Sistemą privalo sudaryti Darbuotojų naudų modulis ir lanksčių naudų/ pasirinkimų modulis, Komunikacijos modulis ir Nuolaidų modulis.
- 2Sistema turi užtikrinti darbuotojų papildomų naudų valdymą, naudojant Sistemos administravimo platformą ir mobiliąją aplikaciją.
- 3Bendras planuojamas Naudotojų kiekis ~ 750 vnt.
- 4Tiekėjas negali siūlyti Prekių (įskaitant jų sudedamąsias dalis, pakuotes) ar paslaugų, jei prekių (įskaitant jų sudedamąsias dalis, pakuotes) kilmė yra ar paslaugos teikiamos iš Viešųjų pirkimų įstatymo 92 straipsnio 15 dalyje numatytame sąraše nurodytų valstybių ar teritorijų.
Sistemos patikimumo reikalavimai
- 1Įvykus incidentui, dėl kurio Sistemos programinė įranga paleidžiama iš naujo, programinės įrangos paleidimas turi įvykti automatiškai, be žmogaus įsikišimo. Negali dingti į Sistemą suvesti ir incidento metu apdorojami duomenys, taip pat programinės įrangos konfigūracijos duomenys.
- 2Sistemos rezervinių kopijų, archyvavimo arba duomenų versijavimo mechanizmas negali turėti įtakos duomenų vientisumui ir negali sukelti įvedamų duomenų praradimo.
Teisinių reikalavimų atitikimas
- 1Tiekėjas privalo laikytis teisės aktų reikalavimų, nustatančių duomenų apsaugą bei teikti Paslaugas taip, kad visi su teikiamomis paslaugomis susiję veiksmai atitiktų BDAR (ES) 2016/679 reglamentą.
Informacijos ir kibernetinė sauga
- 1Prieš įdiegiant Sistemą į darbinę aplinką ir perkeliant Perkančiojo subjekto duomenis, Tiekėjas turi pateikti dokumentus, įrodančius, kad Sistema neturi kritinių, aukšto ir vidutinio lygio kibernetinių pažeidžiamumų, aptiktų NKSC atliktų skenavimu metu arba kai skenavimas yra atliktas vienu iš TOP 10 vyraujančių rinkoje profesionalių pažeidžiamumų skenavimo įrankiu.
- 2Sistemoje turi būti užtikrinama, kad Perkančiojo subjekto duomenys (angl. data at rest), jų perdavimas (angl. data in transit) ir jų atsarginės kopijos (angl. data backups) yra šifruojami, parenkant naujausias NIST, EISA ar BSI organizacijų rekomendacijas atitinkančius šifravimo algoritmus, šifravimo raktų ilgius ir kt.. Naudojamų šifravimo priemonių detalus sąrašas ir (arba) raktai turi būti pateikti Perkančiajam subjektui.
- 3Sistemos naudotojų paskyros turi būti valdomos per Perkančiojo subjekto valdomą aktyvaus katalogo (angl. Active Directory (AD)) ir (arba) Entra ID sistemą, užtikrinant vieno prisijungimo (angl. Single Sign On (SSO)) principus ir autentikavimui naudojant bent vieną iš šių protokolų: Open ID Connect, SAML 2.0, WS-Fed. Sistemos vidinės (default, built-in) naudotojų paskyros turi būti užblokuotos.
- 4Sistemoje turi būti realizuotas privilegijų ir (arba) rolių funkcionalumas, užtikrinantis Sistemos naudotojų ir Sistemos administratorių funkcijų atskyrimą, o Sistemoje turi būti sukurtos atskiros rolės naudotojams, atliekantiems skirtingas funkcijas.
- 5Sistemoje turi būti galimybė valdyti (prisijunti prie Sistemos, keisti slaptažodžius) privilegijuotų, sisteminių vartotojų parametrus (User name, slaptažodis), naudojant Perkančiojo subjekto privilegijuotų vartotojų valdymo sprendimą sistemą (PAM).
- 6Sistemos įvykių žurnaluose turi būti registruojami ir saugomi visų naudotojų atlikti veiksmai kartu su veiksmų turiniu, visi Naudotojų paskyrų ir privilegijų/rolių keitimo veiksmai kartu su veiksmų turiniu. Sistema turi turėti galimybę perduoti išsaugotus veiksmų/pakeitimų žurnalinius įrašus į Perkančiojo subjekto SIEM sistemą.
- 7Perkantysis subjektas turi būti nedelsiant informuojamas apie Sistemos informacijos ir kibernetinio saugumo įvykius ir incidentus, taip pat asmens duomenų saugumo pažeidimus, jų įtaką Perkančiojo subjekto informacijos ir duomenų saugumui bei jų valdymo būklę, nuo jų nustatymo momento. Perkantysis subjektas turi turėti galimybę susisiekti su asmenimis, atsakingais už saugumo įvykių ir incidentų valdymą.
- 8Kritinis pažeidžiamumas (CVSS 9.0-10) turi būti išspręstas per 5 kalendorines dienas nuo pažeidžiamumo nustatymo momento.
- 9Aukšto prioriteto pažeidžiamumas (CVSS 7-8.9) turi būti išspręstas per 10 kalendorinių dienų nuo pažeidžiamumo nustatymo momento.
- 10Vidutinio prioriteto pažeidžiamumas (CVSS 4-6.9) turi būti išspręstas per 30 kalendorinių dienų nuo pažeidžiamumo nustatymo momento.
- 11Žemo prioriteto pažeidžiamumas (CVSS 0.1-3.9) turi būti išspręstas per 60 kalendorinių dienų nuo pažeidžiamumo nustatymo momento.
- 12Jeigu Sistema turi zero-day arba kritinį pažeidžiamumą, turi būti galimybė visiškai izoliuoti Sistemą nuo pasiekiamumo iš išorinio tinklo.
- 13Turi būti galimybė apriboti Sistemos administravimo modulio pasiekiamumą pagal Perkančiojo subjekto pateiktus išorinius IP adresus.
- 14Sistemos lygyje turi būti galimybė Perkančiajam subjektui laikinai arba visiškai atjungti tarnybas (angl. services), kurių naudojimas nėra būtinas ar reikalingas Sistemos veikimui užtikrinti.
- 15Produktai (Sistema) ir (arba) Paslaugos turi būti sukonfigūruoti taip, kad leistų Perkančiajam subjektui įgyvendinti BDAR numatytas duomenų subjektų teises: teisę būti informuotam apie duomenų tvarkymą, teisę susipažinti su asmens duomenimis, teisę reikalauti ištaisyti duomenis, teisę būti pamirštam, teisę apriboti duomenų tvarkymą, teisę nesutikti su duomenų tvarkymu, teisę į duomenų perkeliamumą. Visi duomenų subjektų prašymai neturi būti papildomai apmokestinami.
- 16Tiekėjas turi užtikrinti, kad Perkančiojo subjekto duomenys nebus perduodami už Europos ekonominės erdvės ribų, nebent būtų taikoma bent viena iš BDAR V skyriuje numatytų perdavimo už Europos ekonominės erdvės ribojimo išimčių.
- 17Tiekėjas privalo užtikrinti, kad visą Sistemos veikimui reikalinga aparatinė ir programinė įranga, įskaitant licencijas, programinį kodą, saugos (šifravimo) raktus ir kt., būtų valdoma ir kontroliuojama taip, kad Sistemos kūrimui, palaikymui ir vystymui būtų naudojama tik leistina ir licencijuota aparatinė ir programinė įranga.
- 18Sistema ir jos komponentai negali turėti nutrauktos gamybos komponentų (angl. end-of-life product).
- 19Tiekėjas turi užtikrinti galimybę Perkančiajam subjektui ar jo įgaliotam partneriui ne rečiau kaip vieną kartą per metus atlikti Sistemos palaikymo ir vystymo veiklos auditą ar patikrą.
- 20Tiekėjas turi užtikrinti galimybę Perkančiajam subjektui ar jo įgaliotam partneriui, iš anksto suderinus su Tiekėju, atlikti kibernetinio saugumo pažeidžiamumo testą.
- 21Tiekėjas privalo pateikti dokumentaciją, kurioje būtų nurodyta kaip Tiekėjo Sistema bus integruojama su Perkančiojo subjekto sistema(-omis), detalizuojant kokia programinė ir techninė įranga, kokios IT/OT technologijos, protokolai ir panašiai bus naudojamos, taip pat kokiu būdu/protokolais tarpusavyje bus sujungiami Sistemos elementai ir panašiai.
- 22Tiekėjas privalo užtikrinti, kad Kibernetinio saugumo reikalavimai būtų taikomi jo partneriams ir kitiems pasitelktiems asmenims, dalyvaujantiems Sistemos kūrimo, vystymo ir palaikymo veikloje.
- 23Lietuvos Respublikos Vyriausybės 2018-08-13 nutarimo Nr. 818 reikalavimai taikomi Tiekėjo siūlomai Sistemai tais atvejais, kai ji turi integracijas su Perkančiojo subjekto kritinėmis sistemomis arba yra priskiriama kritinei sistemai.
Sistemos veiksmų atsekamumas (Log)
- 1Sistema, pagal Sistemos taisykles, turi kaupti duomenis apie Naudotojų veiksmus.
- 2Sistemoje turi matytis Sistemos Naudotojų veiksmai, pagal Sistemos taisykles.
- 3Sistema turi kaupti ir išsaugoti prisijungimų prie Sistemos informaciją.
- 4Prisijungimų prie Sistemos informacijoje turi būti fiksuojami naudotojų vardai.
- 5Prisijungimų prie Sistemos informacijoje turi būti fiksuojami prisijungimo laikai.
- 6Prisijungimų prie Sistemos informacijoje turi būti fiksuojama, kokius veiksmus Naudotojas atliko.
Prieiga per mobiliuosius įrenginius
- 1Darbuotojams skirta Sistemos aplinka turi būti mobilios aplikacijos formos.
- 2Mobili aplikacija turi būti palaikoma iOS ir Android operacinėse sistemose.
Bendrieji architektūros reikalavimai
- 1Tiekėjo duomenų centras turi atitikti ne mažesnius nei Tier 3 kategorijos reikalavimus.
- 2Fizinė duomenų saugojimo vieta turi būti Europos Sąjungoje.
- 3Sistemoje Naudotojų komunikacija, taip pat Sistemos architektūros modelio lygių komunikacija, turi vykti tik per šifruotus duomenų perdavimo protokolus (pvz. standartinius SSL/TLS).
- 4Tiekėjas turi užtikrinti, kad Sistemos vystymo ar testavimo paslaugos nedarys įtakos Klientui teikiamų Paslaugų veikimui / Sistemos darbui.
- 5Sistemos kūrėjas įsipareigoja palaikyti Sistemą be trikdžių naudojantis pagrindinėmis naršyklėmis ir jų naujausiomis versijomis: Microsoft Edge, Google Chrome, Mozilla FireFox, Apple Safari.
- 6Sistema turi tenkinti funkcinius reikalavimus ne tik Sistemos diegimo metu, bet ir visą Sistemos naudojimo laikotarpį, įskaitant Tiekėjo atliekamus Sistemos naujinimus ir Sistemos tobulinimus.
- 7Sistemoje turi būti priemonės, užtikrinančios vieningą unikalių duomenų suvedimą (angl. Single Data Entry).
- 8Sistema, priklausomai nuo apkrautumo, turi automatiškai (be Sistemos sustabdymo) išplėsti architektūrinius komponentus taip, kad galėtų aptarnauti didesnį Naudotojų kiekį.
- 9Tiekėjas turi suteikti Klientui galimybę testuoti vykdomas konfigūracijas, kuriamas integracijas arba naujus Sistemos funkcionalumus testavimo aplinkoje.
- 10Sistema turi užtikrinti galimybę vienu metu prisijungti visiems Naudotojams pagal pasirinktą paslaugos modelį.
- 11Sistema turi dinamiškai prisitaikyti prie augančių duomenų srautų, duomenų bazių dydžio, Naudotojų kiekio.
- 12Sistema turi turėti mechanizmą, kuris informuotų apie vykdomus planinius techninius darbus, Sistemos neveikimą ir galimus laikinus sutrikimus.
Naudotojų autentifikavimo reikalavimai
- 1Sistemoje turi būti palaikomas kelių veiksnių autentifikavimas, kai tai taikoma pagal naudojamą autentifikavimo sprendimą.
- 2Sistemos autorizavimo mechanizmas turi būti realizuotas vadovaujantis rolių modeliu (angl. Role-based Model) ir valdomas centralizuotai visiems Sistemos architektūros modelio lygiams.
- 3Sistema turi užtikrinti saugią Sistemos administratoriaus autentifikaciją, laikantis naudojamos autentifikavimo sistemos (pvz., Active Directory ar Entra ID) saugumo reikalavimų.
- 4Sistemoje Naudotojas turi turėti galimybę saugiai nustatyti naują slaptažodį jį pamiršus.
- 5Keičiant slaptažodį, Naudotojas privalo pateikti seną ir naują slaptažodį.
- 6Reikalauti Naudotojo papildomai autentifikuotis, jei yra keičiamas įrenginys ar išvaloma naršyklės istorija.
- 7Privalomas funkcionalumas HTTP sesijos apsaugai: neįtraukti sesijos ID į URL adresą arba nesiųsti jo siunčiamos užklausos antraštėje (angl. Referrer header).
- 8Privalomas funkcionalumas HTTP sesijos apsaugai: užtikrinti, kad sesijos ID turi būti ilgas, sudėtingas, sugeneruotas iš atsitiktinių skaičių ir negali būti lengvai atspėjamas.
- 9Privalomas funkcionalumas HTTP sesijos apsaugai: draudžiama saugoti sesijos ID.
- 10Privalomas funkcionalumas HTTP sesijos apsaugai: sesijos ID turi būti pakeičiamas, jeigu įvyksta perjungimas į SSL.
- 11Privalomas funkcionalumas HTTP sesijos apsaugai: išvalomas sesijos objektas Naudotojui išsiregistravus arba sesijai nustojus galioti.
- 12Privalomas funkcionalumas HTTP sesijos apsaugai: negalima naudoti autentifikacijos arba sesijos duomenų siuntimui GET užklausose.
- 13Privalomas funkcionalumas HTTP sesijos apsaugai: visa Naudotojo sesija turi būti apsaugota SSL/TLS pagalba.
- 14Sistema, sukūrus prieigą Naudotojui, turi automatiškai išsiųsti pranešimą Naudotojui apie galimybę prisijungti.
Sistemos vystymo / programavimo paslaugos
- 1Paslaugos teikiamos pagal Perkančiojo subjekto poreikį, Perkančiajam subjektui raštu (el. paštu) pateikiant Užsakymus Tiekėjui. Užsakymų skaičius neribojamas.
- 2Prieš pateikiant Užsakymą, Perkantysis subjektas ir Tiekėjas raštu suderina Užsakymą, jame nurodydami perkamas Paslaugas, jų apimtis (darbo valandas) ir įvykdymo terminus.
- 3Užsakymas privalo būti suderintas ir patvirtintas ne vėliau kaip per 5 (penkias) darbo dienas nuo Užsakymo pateikimo dienos.
- 4Tiekėjas įsipareigoja suteikti Paslaugas Užsakyme sutartomis sąlygomis ir terminais, įvertinant konkretaus Užsakymo apimtį ir sudėtingumą.
- 5Už darbo valandas, viršijančias Užsakyme nurodytas Paslaugų suteikimo apimtis, Perkantysis subjektas neapmoka.
- 6Tiekėjas, po Užsakymo gavimo, privalo pateikti Paslaugų vertinimą pagal su Perkančiuoju subjektu suderintą formą, kuriame turi būti nurodyta: užsakyme numatytų programavimo paslaugų trumpas aprašymas / techninė dokumentacija / architektūrinio sprendimo aprašymas; apimtis (darbo valandos, detalizuota 4 val. lygyje, jei įmanoma); užsakymo įvykdymo kaina; Paslaugų suteikimo grafikas ir terminas.
- 7Užsakyme numatytų IT pakeitimų Sistemoje priėmimo testavimas vykdomas tik Tiekėjui atlikus vidinį testavimą, pateikus vidinio testavimo ataskaitą ir patvirtinus, kad Sistema veikia taip, kaip nurodyta Užsakyme.
- 8Tiekėjas, vadovaudamasis suderintu testavimo planu, turės fiziškai arba nuotoliniu būdu dalyvauti testavime, teikti konsultacijas, kaip turi būti atliekamas testuojamas veiksmas / funkcija / operacija pagal pateiktus testavimo scenarijus, pateikti savo komentarus ir siūlymus dėl rekomenduojamo klaidos kritiškumo lygio, informuoti testavimo dalyvius apie klaidų šalinimo terminus bei atlikti klaidų taisymą. Visa informacija apie klaidų kritiškumo lygį, jų šalinimo terminus, šalinimo eigą ir priskirtus atsakingus asmenis bus registruojama klaidų registre (įrankį klaidų registravimui pateikia Tiekėjas).
- 9Tiekėjas, pagal klaidų registre užregistruotą informaciją ir parengtu klaidų šalinimo planu, privalo pašalinti visas užregistruotas klaidas ir neatitikimus, nustatytus priėmimo/testavimo metu.
- 10Bandomosios eksploatacijos vykdymui turi būti numatyta ne trumpesnė kaip 2 sav. trukmė.
- 11Tiekėjas bandomosios eksploatacijos metu, pagal suderintą klaidų šalinimo grafiką, šalina visus suderinto Sistemos funkcionalumo ir veikimo trūkumus, užregistruotus bandomosios eksploatacijos problemų registre. Įrankį klaidų registravimui pateikia Tiekėjas.
- 12Bandomosios eksploatacijos metu Tiekėjas turi skirti bent 1 konsultantą, atsakingą už funkcinės pagalbos teikimą Perkančiajam subjektui (gyvai, telefonu, el. paštu ir kt.).
Mobiliosios aplikacijos nuolaidų valdymas
- 1Mobiliojoje aplikacijoje visos nuolaidos Naudotojui turi būti matomos vienoje vietoje.
- 2Nuolaidas turi būti galima filtruoti ar patogiai ieškoti (pvz, pagal raktinį žodį).
- 3Turi būti pateiktas pilnas nuolaidos aprašymas su jos panaudojimo instrukcijomis.
- 4Mobiliojoje aplikacijoje Naudotojas turi turėti galimybę pasižymėti nuolaidą kaip mėgstamiausią.
Administravimo platformos nuolaidų valdymas
- 1Tiekėjas turi užtikrinti ne mažiau kaip 350 skirtingų nuolaidų asortimentą Lietuvoje, siūlančių nuolaidas fizinėse ir (ar) elektroninėse parduotuvėse. Nuolaidų Tiekėjai Sutarties vykdymo metu gali kisti, tačiau jų skaičius bet kuriuo Sutarties vykdymo metu negali būti mažesnis už nustatytą minimalų kiekį.
- 2Sistema turi leisti visiems Naudotojams pasinaudoti nuolaidomis.
- 3Sistemoje turi būti sudaryta galimybė pridėti Perkančiojo subjekto partnerių (pvz., paslaugų ar prekių teikėjų) teikiamas nuolaidas.
- 4Sistemos administratoriui turi būti sudaryta galimybė paslėpti bet kurią siūlomą nuolaidą, jeigu ji prieštarauja Perkančiojo subjekto vertybėms.
- 5Sistemoje turi būti užtikrinta galimybė suformuoti .xlsx formato ataskaitą apie nuolaidų panaudojamumą.
Mobiliosios aplikacijos komunikacijos valdymas
- 1Mobilioje aplikacijoje turi būti funkcionalumas, kuris leistų Naudotojui pateikti pasiūlymą ar atsiliepimą Perkančiojo subjekto komandai, susijusį su darboviete. Atsiliepimą Naudotojas turi galėti pateikti ir anoniminiu būdu.
- 2Mobilioje aplikacijoje turi būti funkcionalumas, leidžiantis Naudotojui paskelbtas naujienas matyti vienoje vietoje, jas perskaityti, filtruoti ir pakomentuoti.
- 3Mobilioje aplikacijoje turi būti funkcionalumas užpildyti Perkančiojo subjekto komandos pateiktą apklausą.
- 4Mobilioje aplikacijoje Naudotojui turi būti pateikiama informacija apie jam priskirtus patobulinimus. Skiriant patobulinimus, Naudotojui turi būti siunčiamas pranešimas (el. paštu ir į mobiliąją aplikaciją).
- 5Mobilioje aplikacijoje Naudotojas turi galėti pakomentuoti jam priskirtą patobulinimą.
Administravimo platformos komunikacijos valdymas
- 1Sistemoje turi būti funkcionalumas, leidžiantis kurti turinį, skirtą komunikacijai su darbuotojais elektroniniu paštu ir mobiliąja aplikacija.
- 2Kuriant turinį, skirtą komunikacijai su darbuotojais, Sistema turi leisti prisegti nuotraukas (prisegamo failo dydis turi būti ne didesnis kaip 25Mb).
- 3Sistemoje turi būti funkcionalumas nustatyti komunikacinės žinutės gavėjus per darbuotojų grupes.
- 4Sistemoje turi būti funkcionalumas nustatyti komunikacinės žinutės kanalus (el. paštu ir į mobiliąją aplikaciją).
- 5Sistemoje turi būti funkcionalumas ištrinti komunikacinę žinutę ar sukurti esamos žinutės kopiją.
- 6Sistemoje visos komunikacinės žinutės turi būti matomos vienoje vietoje.
- 7Visos komunikacinės žinutės turi turėti statusą ir laiko žymą.
- 8Sistemoje turi būti funkcionalumas matyti, kiek Naudotojų gavo komunikacinę žinutę.
- 9Sistemoje turi būti patogus komunikacinių žinučių paieškos funkcionalumas (pvz.: pagal žinutės pavadinimą).
- 10Sistemoje turi būti funkcionalumas eksportuoti visą informaciją apie komunikacines žinutes į Excel failą.
- 11Sistemoje turi būti galimybė komunikacines žinutes valdyti šiomis kalbomis: lietuvių, anglų.
- 12Sistemoje turi būti galimybė kurti komunikacinės žinutės juodraštį.
- 13Sistemoje turi būti funkcionalumas numatyti komunikacinės žinutės paskelbimą į ateitį ar iš anksto numatyti jos skelbimo pabaigą ateityje.
- 14Naudotojas turi būti automatiškai informuojamas apie jam priskirtą komunikacinę žinutę.
- 15Sistemoje turi būti galimybė Naudotojui priskirti taškus už patobulinimus, nurodant patobulinimo įgyvendinimo datą, taškų kiekį ir aprašymą.
Sistemos priežiūros ir palaikymo paslaugos (SLA)
- 1Tiekėjas įsipareigoja per visą teikiamos priežiūros ir palaikymo paslaugų laikotarpį užtikrinti visus šioje techninėje specifikacijoje keliamus reikalavimus, įskaitant SLA reikalavimus, savalaikį gedimų šalinimą, serverių priežiūrą, Sistemos nepertraukiamo veikimo užtikrinimą.
- 2Sistemos palaikymo (priežiūros) paslaugų trukmė – 24 (dvidešimt keturi) mėnesiai, skaičiuojant nuo Sutarties įsigaliojimo dienos.
- 3Visi gedimų ar pastabų kreipiniai turi būti registruojami į Tiekėjo šiam tikslui pritaikytą sistemą.
- 4Kritinių gedimų atveju gedimai šalinami per 4 val. nuo užregistravimo momento, reakcijos laikas ne ilgesnis kaip 2 val.
- 5Vidutinio kritiškumo gedimų atveju gedimai šalinami per 16 val. nuo užregistravimo momento, reakcijos laikas ne ilgesnis kaip 4 val.
- 6Ne kritinių gedimų atveju gedimai šalinami per 72 val. nuo užregistravimo momento, reakcijos laikas ne ilgesnis kaip 8 val.
Naudotojo sąsajos ir duomenų pateikimo reikalavimai
- 1Naudotojo grafinė sąsaja turi būti orientuota į Naudotoją (angl. User-Centred).
- 2Duomenų bazė(-ės)/duomenų saugojimo šaltiniai Sistemoje turi palaikyti UCS (angl.: „Universal Character Set“) daugiabaitį simbolių kodavimą ir gebėti dirbti su lietuviška abėcėle.
- 3Sistema turi palaikyti daugiakalbystę sisteminiams laukams, klasifikatoriams ir Sistemoje įvedamiems / saugomiems duomenims.
- 4Į Sistemą duomenys turi būti įvedami ir / ar importuojami. Sistemos Naudotojas turi turėti galimybę pasirinkti duomenų įvedimo būdą.
- 5Importuojant duomenis, Sistemoje turi būti galimybė tikrinti kontrolinę informaciją ir duomenų atitikimą saugumo reikalavimui ir pateikti informaciją apie aptiktas klaidas.
- 6Sistemos Naudotojui atlikus neteisingą (neleidžiamą) veiksmą arba nekorektiškai įvedus unikalius duomenis, Sistema turi Naudotojui rodyti atitinkamus pranešimus darbalaukyje.
- 7Sistema turi užtikrinti, kad Sistemoje realizuoti procesai veikia deterministiškai ir nepriklausomai nuo Naudotojo laiko zonos, naudojamos naršyklės, darbuotojo prisijungimo vietos.
Administravimo platformos darbuotojų duomenų valdymas
- 1Sistema turi užtikrinti galimybę valdyti įmonės struktūrą, kurioje galima: sukurti įmonę/-es ir joms priskirti darbuotojus; sukurti įmonių grupes ir joms priskirti įmones; darbuotojus turi būti galima priskirti ne tik įmonėms, bet ir jų padaliniams; kurti atskiras darbuotojų grupes, nepriklausomai nuo įmonės struktūros.
- 2Sistemoje turi būti galima nustatyti darbuotojų kortelių galiojimo terminus.
- 3Perkančiojo subjekto ir darbuotojų kortelės Sistemoje turi būti žymimos statusu pagal jų galiojimo būseną.
- 4Sistemoje turi būti galima suvesti šią darbuotojų informaciją: Vardas ir pavardė; Asmens kodas ar kitas ID kodas; Telefono numeris; Elektroninio pašto adresas; Gimimo data; Įmonė; Padalinys; Pareigybė/Pareigos; Įdarbinimo statusas (etato tipas); Įdarbinimo data; Kiti papildomų naudų valdymui aktualūs požymiai, Šalių suderinti Sistemos diegimo eigoje; Numatoma įdarbinimo ir darbo pasibaigimo data.
- 5Sistemoje turi būti galima iš anksto numatyti darbuotojo įdarbinimo arba darbuotojo darbo pasibaigimo datą. Pagal pasirinktą datą, automatiškai, turi būti pakeista darbuotojo būsena.
- 6Sistemoje turi būti funkcionalumas koreguoti įmonių, įmonių grupės ir darbuotojų duomenis.
- 7Sistemoje turi būti funkcionalumas perkelti pavienį darbuotoją į kitą įmonę (jei taikoma), padalinį ar pakeisti darbuotojo pareigybę.
- 8Sistemoje turi būti galimybė eksportuoti darbuotojų informaciją į Excel failą.
- 9Sistema turi suteikti galimybę naudoti ir keisti įmonių logotipus.
- 10Sistemoje turi būti galimybė atlikti pagrindinius masyvius veiksmus su darbuotojais (pvz.: pakeisti keleto darbuotojų komandą, aktyvuoti ar deaktyvuoti pasirinktus darbuotojus).
- 11Sistemoje turi būti įdiegta filtravimo sistema pagal suderintą organizacijos struktūrą.
- 12Sistemoje turi būti galima kurti personalizuotus išskleidžiamojo sąrašo tipo darbuotojų laukus.
- 13Turi būti realizuoti 2 Naudotojų prisijungimo būdai prie mobiliosios aplikacijos: MS paskyra (el. pašto trumpasis adresas ir slaptažodis) ir/arba Sistemos administravimo platformoje esančių Darbuotojų duomenų rinkiniai (Darbuotojo telefono numerį ir keturis paskutinius asmens kodo skaičius).
Bendrieji sistemos administravimo platformos reikalavimai
- 1Sistemoje turi būti funkcionalumas, leidžiantis kurti, pridėti, naikinti darbuotojo profilyje esančią informaciją.
- 2Sistemoje turi būti funkcionalumas, leidžiantis kurti, pridėti, naikinti Perkančiojo subjekto profilyje esančią informaciją.
- 3Sistemoje turi būti funkcionalumas eksportuoti duomenis į Excel failą.
- 4Sistema turi turėti galimybę integruotis su kitomis Perkančiojo subjekto naudojamomis sistemomis (pvz., personalo valdymo sistemomis) pagal Šalių suderintas sąlygas.
- 5Sistemoje turi būti funkcionalumas kurti bei siųsti grupinius/masinius, vienkartinius pranešimus, nereikalaujančius veiksmo iš Naudotojo.
- 6Sistemos administratorius turi turėti teisę kurti ir deaktyvuoti Naudotojų paskyras Sistemoje.
- 7Sistemoje turi būti galimybė bet kuriuo metu keisti Sistemos administratorių teises.
- 8Sistemoje turi būti paieškos funkcija, kuri įgalintų Sistemos administratorių, pagal jam suteiktas teises/prieigas ir pagal įvestą atitinkamą paieškos tekstą, gauti išfiltruotus Sistemoje saugomus duomenis.
- 9Sistemoje turi būti ataskaitų generavimo funkcionalumas, kuris leistų kurti ataskaitas iš ataskaitų modulyje esančių duomenų xlsx formatu.
- 10Ataskaitų kūrimo ir generavimo priemonės Sistemoje turi turėti funkcionalumą keisti atitinkamų ataskaitų šablonus (formą).
- 11Sistemoje turi būti funkcionalumas palaikyti ir filtruoti skirtingų struktūrinių vienetų duomenis bendrai ir atskirai (pvz. pagal įmonę, padalinį ar kitus struktūrinius vienetus).
- 12Sistemoje turi būti funkcionalumas matyti tiek visų organizacinių vienetų suvestinius duomenis, tiek kiekvieno organizacinio vieneto duomenis atskirai.
Mobiliosios aplikacijos darbuotojų naudų ir pasirinkimų valdymas
- 1Mobili aplikacija turi būti publikuota viešai prieinamose mobiliųjų aplikacijų parduotuvėse (Google Play ir (ar) Apple App Store).
- 2Naudotojas turi galėti pažymėti lanksčių naudų pasirinkimą per mobiliąją aplikaciją, kad nori gauti lanksčią naudą pagal pateiktus pasirinkimus.
- 3Naudotojas turi būti automatiškai informuojamas apie jam priskirtą naudą, naujieną ar apklausą (mobiliojoje aplikacijoje ir/arba el. paštu).
- 4Mobilioje aplikacijoje, atskirame polangyje, Naudotojas turi matyti jam suteiktą galimų išlaidų naudoms limitą ir suteiktų naudų paketo santrauką pagal Sistemoje apibrėžtas naudų kategorijas.
- 5Sistema turi užtikrinti galimybę kurti, redaguoti ir valdyti naudų kategorijas.
- 6Naudotojui turi būti pateikiama informacija apie atsakingą asmenį už papildomų naudų valdymo procesą (nurodant kontaktinę informaciją).
- 7Mobilioje aplikacijoje, atskirame polangyje, Naudotojas turi matyti jam skirtas naudas vienoje vietoje. Naudotojas turi galėti susipažinti su visų naudų turiniu, įskaitant nuorodas bei prisegtus dokumentus (PDF, WORD, PPT, XLSX formatus).
- 8Mobilioje aplikacijoje turi būti funkcionalumas pateikti pasiūlymą/atsiliepimą (taip pat ir anonimiškai).
- 9Mobilioje aplikacijoje turi būti funkcionalumas Perkančiojo subjekto paskelbtas naujienas matyti vienoje vietoje ir jas perskaityti.
Administravimo platformos darbuotojų naudų ir pasirinkimų valdymas
- 1Sistemoje turi būti galima kurti naudas darbuotojams ir jas priskirti darbuotojams per darbuotojų grupes ar individualiai.
- 2Darbuotojų naudos turi turėti būsenas, atitinkančias naudų galiojimo statusą.
- 3Sistemoje turi būti funkcionalumas valdyti darbuotojų naudų likučius pagal Sistemoje nustatytas taisykles. Išlaidos registruojamos įvedant datą, sumą, aprašymą (ne mažiau nei 255 simboliai).
- 4Sistema turi leisti kurti darbuotojų naudas su įtrauktomis darbuotojų naudų išlaidomis ir/ar vertėmis.
- 5Sistemoje darbuotojų naudos turi būti planuojamos pagal nustatytas planavimo taisykles, kurias nustato paslaugos Naudotojas, su galimybe šį kontrolės mechanizmą išjungti.
- 6Ruošiant darbuotojų naudą turi būti galimybė prisegti nuotraukas ir dokumentus (prisegamo failo dydis ne didesnis nei 25Mb).
- 7Ruošiant darbuotojų papildomos naudos aprašymą (kortelę) turi būti galimybė pridėti aktyvią nuorodą į šaltinį.
- 8Ruošiant darbuotojų naudą, sistema turi automatiškai informuoti, jei yra neužpildytų privalomų laukų.
- 9Sistemoje turi būti užregistruojamos darbuotojų naudos pradžios ir pabaigos datos. Apie besibaigiančią naudą, sistema turi automatiškai informuoti priskirtus atsakingus asmenis.
- 10Sistemoje turi būti matomos visos darbuotojų naudos vienoje vietoje (bendroje naudų lentelėje); sistema turi siųsti priminimus Naudotojui apie jam priskirtas, bet nepasirinktas naudas, šias naudas turi būti galima filtruoti administravimo platformoje.
- 11Sistemoje turi būti funkcionalumas Sistemos administratoriui pasirinkti darbuotojų naudas pagal klasifikatorių.
- 12Sistemoje turi būti patogus naudų paieškos funkcionalumas (pvz., pagal naudos pavadinimą).
- 13Sistemoje turi būti funkcionalumas eksportuoti informaciją apie darbuotojų naudas į PDF ar Excel failą.
- 14Sistemoje turi būti funkcionalumas ištrinti arba nukopijuoti naudą.
- 15Sistemoje turi būti užtikrinta galimybė sukurti lanksčių naudų pasirinkimo galimybę ir nustatyti atitinkamas atrinktas naudas. Sukūrus pasirinkimą, Sistema turi leisti Naudotojui pasirinkti nustatytą kiekį naudų iš galimo lanksčių naudų sąrašo.
- 16Sistemoje turi būti galimybė nustatyti lanksčių naudų pasirinkimo laikotarpį.
- 17Sistemoje turi būti sudaryta galimybė Sistemos administratoriui pažymėti Naudotojo pasirinkimą teisiai Sistemoje.
- 18Sistemoje turi būti galimybė vienoje vietoje matyti visų Naudotojų atliktus pasirinkimus. Taip pat turi būti galimybė išsitraukti sąrašą su atliktais pasirinkimais xlsx formatu.
- 19Sistemoje turi būti užtikrinta galimybė kiekvienam lanksčių naudų pasirinkimui nustatyti pavadinimą bei aprašymą dviem kalbomis: lietuvių ir anglų kalbomis.
- 20Pasibaigus pasirinkimų laikotarpiui, Naudotojui turi būti priskirtas jo pasirinkimas. Naudotojo atlikti pasirinkimai turi būti aiškiai matomi bendroje Naudų valdymo zonoje.
- 21Sistemoje turi būti galimybė formuoti ataskaitą apie lanksčių naudų pasirinkimus.
Dokumentai18
tendis.lt · Sukurta recodin.lt