Grįžti į sąrašą

Darbuotojų papildomų naudų valdymo sistemos nuomos kartu su pripažinimo moduliu ir papildomų naudų paketo, jų administravimo paslaugos

Išanalizuota

SĮ Susisiekimo paslaugos (PV)

118 000
Atviras konkursasCPV: 72267000 - Programinės įrangos priežiūros ir tvarkymo paslaugos
ID: 71599722026-03-31 05:12
Atidaryti CVP IS

Aprašymas

Perkamos darbuotojų papildomų naudų valdymo sistemos, apimančios pripažinimo modulį ir papildomų naudų paketus, nuomos ir administravimo paslaugos. Ši sistema padės efektyviai valdyti ir teikti darbuotojams įvairias naudas, įskaitant diegimą, priežiūrą ir vystymą. Paslaugos teikiamos 12 mėnesių laikotarpiu.

Kvalifikaciniai reikalavimai

Kvalifikacinių reikalavimų nerasta

Techniniai reikalavimai

Sistemos vystymas

  • 1Paslaugų teikėjas, gavęs Užsakymą vystymo paslaugoms, per 3 (tris) darbo dienas privalo pateikti Perkančiajai organizacijai užsakytų vystymo paslaugų apimtį (valandomis) ir pasiūlymus dėl vykdymo.
  • 2Vystymo paslaugų mato vienetas yra valanda.

Informacijos saugumas

  • 1Tiekėjo informacijos saugumas turi būti valdomas vadovaujantis ISO 27001 (arba lygiaverčio) arba ISO 27017 (arba lygiaverčio) arba ISO 27018 (arba lygiaverčio) informacijos saugumo valdymo standartais.
  • 2Sistema turi atitikti asmens duomenų apsaugos principus ir nuostatas kaip aprašyta Europos parlamento ir Tarybos Reglamente 2016/679 dėl fizinių asmenų apsaugos tvarkant asmens duomenis ir dėl laisvo tokių duomenų judėjimo ir kuriuo panaikinama Direktyva 95/46/EB (Bendrasis duomenų apsaugos reglamentas).
  • 3Turi būti naudojamas šifruotas ryšys (SSL/TLS arba lygiavertis) tarp Paslaugų teikėjo ir Perkančiosios organizacijos.
  • 4Naudojamas šifruotas ryšys (SSL/TLS arba lygiavertis) tarp Paslaugų teikėjo nutolusių lokacijų.
  • 5Naudojamas šifruotas ryšys (SSL/TLS arba lygiavertis) su trečiomis šalimis, kurios reikalingos Paslaugų teikėjui.
  • 6Sistemos ir kiti Kliento duomenys, saugomi Paslaugų teikėjo duomenų centruose, turi būti šifruojami visuotinai pripažintais saugiais algoritmais.
  • 7Paslaugų teikėjo duomenų centre turi būti taikomas dviejų faktorių autentifikavimas.
  • 8Paslaugų teikėjas turi užtikrinti duomenų konfidencialumą Sistemoje, t. y. kad tik autentifikuoti Naudotojai gali registruotis Sistemoje ir pasiekti tik jiems skirtus duomenis ar funkcionalumą.
  • 9Sistemoje testavimo ir gamybinės aplinkos privalo būti atskirtos.
  • 10Sistemoje neturi būti galimybės saugoti ir registruoti Naudotojo slaptažodžio atviru tekstu.
  • 11Paslaugų teikėjo duomenų centruose turi būti naudojamos DDoS valdymo priemonės (apsauga prieš DDoS atakas).
  • 12Perkančiosios organizacijos duomenys turi būti apriboti nuo aplinkos ir kitų klientų (pvz., virtualios talpyklos).
  • 13Perkančiosios organizacijos duomenys privalo būti visiškai ir negrįžtamai ištrinti Perkančiosios organizacijos pareikalavimu.
  • 14Turi būti ribojama prieiga Paslaugų teikėjo darbuotojams, subtiekėjams ir kitiems pasitelktiems tretiesiems asmenims prie Sistemos duomenų.

Aplinkosaugos kriterijai

  • 1Teikiamos tik nematerialaus pobūdžio paslaugos, t. y. intelektinės paslaugos, nesusijusios su materialaus objekto sukūrimu, kurių teikimo metu nėra numatomas reikšmingas neigiamas poveikis aplinkai, nesukuriamas taršos šaltinis ir negeneruojamos atliekos.

Mokymai ir dokumentacija

  • 1Paslaugų teikėjas turi parengti pristatymą Perkančiosios organizacijos darbuotojams.
  • 2Pristatymą Paslaugų teikėjas turi įrašyti pagal Perkančiosios organizacijos pareikalavimą, tam, kad pristatymo medžiaga būtų demonstruojama pristatyme nedalyvavusiems darbuotojams.
  • 3Paslaugų teikėjas, remiantis parengtu ir su Perkančiąja organizacija suderintu mokymų planu, turi apmokyti būsimus Sistemos Naudotojus (administravimo platformos ir mobilios aplikacijos gyvi mokymai atskiroms tikslinėms Naudotojų grupėms).
  • 4Mokymų metu dalyvių skaičius neribojamas.
  • 5Paslaugų teikėjas atsakingas už mokymų medžiagos ir priemonių mokymams parengimą (apimant Sistemos funkcionalumą, mokymų duomenis, mokymų dokumentaciją, Sistemos konfigūravimą ir kt.).
  • 6Naudotojų mokymai turi vykti lietuvių kalba.
  • 7Visa dokumentacija turi būti parengta lietuvių kalba vadovaujantis bendrinės lietuvių kalbos taisyklėmis.
  • 8Dokumentų galutinės versijos turi būti pateiktos dviem formatais: redagavimui tinkamu elektroniniu (.doc, .docx, .pdf arba kitu su Perkančiuoju subjektu suderintu formatu). Dokumentų tarpinės versijos teikiamos tik elektroniniu formatu.

Nefunkciniai reikalavimai

  • 1Paslaugų teikėjo duomenų centras turi atitikti ne mažesnius nei Tier 3 kategorijos reikalavimus.
  • 2Paslaugų teikėjas turi turėti Debesies technologijų pagrindu teikiamą Sistemos nuomos paslaugos platformą. Fizinė 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).
  • 4Paslaugų teikėjas turi užtikrinti, kad Sistemos vystymo ar testavimo darbai, nedarys įtakos Perkančiosios organizacijos teikiamų Paslaugų veikimo / Sistemos darbo.
  • 5Sistemos įrašų skaičius neturi būti ribojamas.
  • 6Sistemos kūrėjas įsipareigoja palaikyti Sistemą be trikdžių naudojantis pagrindinėmis naršyklėmis, naujausiomis jų versijomis: Microsoft Edge, Google Chrome, Mozilla FireFox, Apple Safari.
  • 7Sistema turi tenkinti funkcinius reikalavimus ne tik Sistemos Paruošimo eksploatacijai paslaugų metu, bet visą Sistemos naudojimo laiką, įskaitant Tiekėjo atliekamus Sistemos naujinimus ir Sistemos tobulinimus.
  • 8Sistemoje turi būti priemonės, užtikrinančios vieningą unikalių duomenų suvedimą (angl. Single Data Entry), t. y. suvedus tam tikrą duomenų reikšmę, tam pačiam objektui dubliuojančių reikšmių suvedimas nebūtų galimas.
  • 9Sistema, priklausomai nuo apkrautumo, turi automatiškai (be Sistemos sustabdymo) prasiplėsti architektūrinius komponentus taip, kad gebėtų aptarnauti didesnį Naudotojų kiekį.
  • 10Paslaugų teikėjas turi suteikti Perkančiajai organizacijai galimybę išbandyti konfigūracijas, kuriamas integracijas arba naujus Sistemos funkcionalumus (Sistemos versijų atnaujinimo atveju) testavimo aplinkoje, kad nebūtų daroma įtaka Sistemos Naudotojams ir kitoms naudojamoms funkcijoms.
  • 11Sistema turi gebėti leisti prisijungti neribotam Naudotojų skaičiui vienu metu.
  • 12Sistema turi dinamiškai prisitaikyti prie augančių duomenų srautų, duomenų bazių dydžio, Naudotojų kiekio.
  • 13Sistema turi turėti mechanizmą, kuris informuotų apie vykdomus planinius techninius darbus, Sistemos neveikimą ir galimus laikinus sutrikimus.

Naudotojų autentifikavimas

  • 1Sistemoje turi būti palaikomas 2 (dviejų) faktorių autentifikavimas (pvz., Microsoft Authenticator app).
  • 2Autentifikavimas turi atitikti OAuth 2.0, SAML 2.0 arba OpenID Connect standartus.
  • 3Sistemos autorizavimo mechanizmas turi būti realizuotas vadovaujantis rolių modeliu (angl. Role-based Model) ir valdomas centralizuotai visiems Sistemos architektūros modelio lygiams.
  • 4Sistema turi reikalauti tik stipraus Sistemos administratoriaus slaptažodžio, kurį turi sudaryti mažiausiai 6 simboliai, didžiosios ir mažosios raidės, skaičiai ir simboliai.
  • 5Sistemoje Naudotojas turi turėti galimybę saugiai nustatyti naują slaptažodį jį pamiršus.
  • 6Keičiant slaptažodį, Naudotojas privalo pateikti seną ir naują slaptažodį.
  • 7Reikalauti Naudotojo papildomai autentifikuotis jei yra keičiamas įrenginys ar išvaloma naršyklės istorija.
  • 8Sistema turi užtikrinti HTTP sesijos apsaugą, įskaitant sesijos ID neįtraukimą į URL ar užklausos antraštę, sesijos ID sudėtingumą, sesijos ID nesaugojimą, sesijos ID pakeitimą perjungiant į SSL, sesijos objekto išvalymą išsiregistravus ar sesijai nustojus galioti, autentifikacijos/sesijos duomenų siuntimo GET užklausose draudimą.
  • 9Apsaugoti Naudotojo visą sesiją SSL/TLS pagalba.
  • 10Sistema, sukūrus prieigą Naudotojui, turi automatiškai išsiųsti pranešimą Naudotojui apie galimybę prisijungti.

Sistemos veiksmų atsekamumas

  • 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ą: naudotojų vardai; prisijungimo laikai; kokius veiksmus atliko.

Rezervinės kopijos ir patikimumas

  • 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).
  • 2Paslaugų teikėjas, Klientui paprašius, turi užtikrinti galimybę gauti nurodytam laikotarpiui Sistemoje sukauptų Naudotojų duomenų kopiją (organizacijos specifinius duomenis, pavyzdžiui - Naudotojų profilių duomenis).
  • 3Įvykus incidentui, dėl kurio Sistemos programinė įranga paleidžiama iš naujo (pvz., elektros energijos tiekimo sutrikimas), programinės įrangos paleidimas turi įvykti automatiškai be žmogaus įsikišimo, negali dingti į Sistemą suvesti ir incidento metu apdorojami duomenys ar programinės įrangos konfigūracijos duomenys.
  • 4Sistemos rezervinių kopijų, archyvavimo arba duomenų versijavimo mechanizmas negali turėti įtakos duomenų vientisumui ir negali sukelti įvedamų duomenų praradimo.

Prieiga per mobiliuosius įrenginius

  • 1Darbuotojams skirta aplinka turi būti mobilios aplikacijos formos.
  • 2Mobili aplikacija turi būti palaikoma naudojant iOS ir Android operacines sistemas.

Sistemos diegimas ir konfigūravimas

  • 1Neribotas prenumeratų naudotojų skaičius.
  • 2Diegimo laikotarpis iki 30 (trisdešimt) darbo dienų.
  • 3Sistemos analizė ir paruošimas eksploatacijai pagal Perkančiosios organizacijos poreikį.
  • 4Sistemos diegimas į Paslaugos teikėjo valdomą debesų kompiuterijos IT infrastruktūrą.
  • 5Galimybė importuoti Perkančiosios organizacijos struktūrą iš Azure Active Directory, kurioje yra priskiriami Naudotojai.
  • 6Funkcionalumo pristatymas ir testavimas, atsiradusių klaidų taisymas.
  • 7Mokymai ir apmokymų dirbti su Sistema organizavimas (mokymų medžiagos, Sistemos administratorių ir Naudotojų instrukcijų parengimas ir suderinimas su Perkančiąja organizacija).
  • 8Paslaugų teikėjas per 15 darbo dienų nuo testavimo darbų pabaigos, turės įdiegti ir pagal perkančiosios organizacijos poreikį sukonfigūruoti darbuotojų papildomų naudų valdymo sistemą.
  • 9Turi būti įdiegtos dvi Sistemos aplinkos: naudotojų testavimo aplinka (angl. user acceptance testing) ir gamybinė aplinka (angl. production).
  • 10Pasirašius Sutartį per 3 (tris) darbo dienas, Paslaugų teikėjas turi parengti ir su Perkančiąja organizacija suderinti detalų Projekto įgyvendinimo planą, apimantį Sistemos įdiegimo, sukonfigūravimo, parengimo naudojimui, testavimo, paleidimo, mokymų ir kitus susijusius darbus, jų tarpusavio priklausomybes, terminus, atsakomybes, rezultatus.
  • 11Paslaugų teikėjas Sistemos diegimo metu teiks konsultavimo paslaugas Sistemos techniniais ir funkciniais klausimais Šalių suderinta apimtimi.
  • 12Paslaugų teikėjas įsipareigoja papildomai neapmokestinti nenumatytų Sistemos analizės ir projektavimo etapuose konfigūravimo ir programavimo darbų, be kurių Sistema neatitiktų specifikacijoje aprašyto funkcionalumo.

Testavimas ir bandomoji eksploatacija

  • 1Sistemos priėmimo testavimas bus vykdomas tik Paslaugų teikėjui atlikus vidinį testavimą, pateikus vidinio testavimo ataskaitą ir patvirtinus, kad Sistema veikia taip, kaip yra nurodyta šios techninės specifikacijos reikalavimuose.
  • 2Paslaugų teikėjas pagal suderintą testavimo planą 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, išsakyti savo komentarus ir siūlymus dėl rekomenduojamo klaidos kritiškumo lygio, informuoti testavimo dalyvius apie klaidos šalinimo terminą, taisyti klaidas.
  • 3Visa informacija apie klaidų kritiškumo lygį, jos šalinimo terminus, šalinimo eigą ir priskirtus atsakingus asmenis bus registruojama klaidų registre (įrankį klaidų registravimui pateikia Paslaugų teikėjas).
  • 4Paslaugų teikėjas, pagal testavimo klaidų registre užregistruotą informaciją ir parengtą klaidų šalinimo planą, turės šalinti visas užregistruotas klaidas ir neatitikimus, nustatytus priėmimo/testavimo metu.
  • 5Bandomosios eksploatacijos vykdymui turi būti numatyta ne mažiau nei 1 sav.
  • 6Paslaugų teikėjas bandomosios eksploatacijos metu pagal suderintą klaidų šalinimo grafiką turi šalinti visus suderinto Sistemos funkcionalumo ir veikimo trūkumus, užregistruotus bandomosios eksploatacijos problemų registre. Įrankį klaidų registravimui pateikia Paslaugų teikėjas.
  • 7Paslaugų teikėjas bandomosios eksploatacijos metu turi skirti bent 1 (vieną) konsultantą, atsakingą už funkcinės darbo su Sistema pagalbos teikimą (gyvai, telefonu, el. paštu, kt.) Naudotojams.

Sistemos priežiūra ir administravimas

  • 1Darbuotojų informacijos įkėlimas.
  • 2Pateiktų PNP įkėlimas.
  • 3PNP priskyrimas darbuotojams.
  • 4Darbuotojų grupių formavimas.
  • 5PNP turinio aprašymai, pagal pateiktus duomenis, sisteminis suskirstymas.
  • 6Naujai atėjusių, išėjusių iš darbo darbuotojų įtraukimas, išbraukimas pagal pateiktą informaciją.
  • 7Automatizuotų užduočių kūrimas.
  • 8Komunikacijos žinučių paruošimas, pagal pateiktą informaciją.
  • 9Garantinis aptarnavimas.
  • 10Techninė priežiūra.
  • 11Palaikymas eksploatacijos metu.
  • 12Sistemos priežiūros ir palaikymo paslaugų trukmė – 12 (dvylika) mėnesių, skaičiuojant nuo Sistemos priėmimo-perdavimo akto pasirašymo dienos.
  • 13Visi gedimų ar pastabų kreipiniai turi būti registruojami į Tiekėjo nurodytu kanalu, kuris suderinamas pasirengimo eksploatacijai metu.
  • 14Sistemos gedimai turi būti šalinami (Sistemos gedimų šalinimo paslaugų teikimo (darbo) valandos I-V 08:00 – 17:00).
  • 15Kritinių gedimų atveju per 4 darbo val. nuo gedimo užregistravimo momento (atvejai, kai Sistema sustoja ir ja nėra įmanoma naudotis).
  • 16Ne kritinių gedimų atveju (kai gedimas reikšmingai neįtakoja Sistemos veikimo, Sistema galima naudotis) per 8 darbo val. nuo gedimo užregistravimo momento.

Naudotojo sąsaja ir duomenų pateikimas

  • 1Sistemoje Naudotojo 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 duomenims.
  • 4Į Sistemą duomenis turi būti įvedami ir / ar importuojami. Sistemos Naudotojas turi pats pasirinkti, kokiu būdu nori įvesti duomenis.
  • 5Importuojant duomenis Sistemoje turi būti galimybė tikrinti kontrolinę informaciją ir duomenų atitikimą saugumui (negali būti įkeliami programinio kodo elementai) ir pateikti informaciją apie aptiktas klaidas.
  • 6Sistemos Naudotojui atlikus neteisingą (neleidžiamą) komandą arba nekorektiškai įvedus unikalius duomenis (klaidingas telefono numeris), Sistema turi Naudotojui rodyti atitinkamus pranešimus darbalaukyje.
  • 7Sistema turi užtikrinti, kad Sistemoje realizuoti procesai veikia deterministiškai nepriklausomai nuo Naudotojo laiko zonos, naudojamos naršyklės, darbuotojo prisijungimo vietos.

Pripažinimo modulio (PM) funkcionalumas

  • 1Paslaugų teikėjas turi užtikrinti galimybę bei veikiantį funkcionalumą Perkančiosios organizacijos darbuotojams dalyvauti PM programoje skiriant įsitraukimo taškus kitiems darbuotojams.
  • 2Paslaugų teikėjas turi užtikrinti galimybę bei veikiantį funkcionalumą skirti įsitraukimo taškus už dalyvavimą atrinktose iniciatyvose, projektuose, kurie siejasi su Perkančiosios organizacijos vertybėmis ir strateginiais tikslais, ir/arba įgyvendina veiklos patobulinimus.
  • 3Paslaugų teikėjas turi užtikrinti galimybę ir veikiantį funkcionalumą, Perkančiosios organizacijos darbuotojams pripažinti kitus darbuotojus ir jiems skirti įsitraukimo taškus pasirenkant specialius ženklelius, atitinkančius Perkančiosios organizacijos vertybes.
  • 4Paslaugų teikėjas turi užtikrinti galimybę ir veikiantį funkcionalumą, leidžiantį Perkančiajai organizacijai pačiai susikurti pripažinimo ženklelius, jų tipus neribojant ženklelių skaičiaus.
  • 5PM modulyje turi būti veikiantis funkcionalumas nustatyti įsitraukimo taškų piniginį ekvivalentą pagal Perkančiosios organizacijos numatytus kriterijus ir biudžetą.
  • 6Taškai pripažįstamiems darbuotojams turi būti skiriami eilės tvarka pagal pripažinimo eiliškumą laike.
  • 7Paslaugų teikėjas turi užtikrinti veikiantį funkcionalumą kurti įsitraukimo taškų skyrimo taisykles, numatyti taškų skyrimo krepšelį, dažnumą, Perkančiosios organizacijos darbuotojų grupes, taškų skyrimo limitus ir kt. taisykles.
  • 8Paslaugų teikėjas turi užtikrinti galimybę ir veikiantį funkcionalumą Perkančiosios organizacijos Darbuotojams pripažįstant kitus darbuotojus ir skiriant jiems įsitraukimo taškus palikti komentarą, dėl ko pripažinimas yra skiriamas.
  • 9Paslaugų teikėjas turi užtikrinti galimybę ir veikiantį funkcionalumą Perkančiosios organizacijos darbuotojams skirti įsitraukimo taškus PM modulyje už Perkančiosios organizacijos registre užregistruotus ir įgyvendintus veiklos patobulinimus ir / arba dalyvavimą iniciatyvose.
  • 10Paslaugų teikėjas turi užtikrinti galimybę ir veikiantį funkcionalumą skirti įsitraukimo taškus Perkančiosios organizacijos darbuotojams (idėjų autoriui bei įgyvendintojui ir PP iniciatyvų dalyviams) užkeliant juos į PNP administravimo sistemą ir atvaizduojant juos Perkančiosios organizacijos darbuotojams mobilioje programėlėje.
  • 11Sistemoje turi būti veikiantis įsitraukimo taškų importo iš XLS/XLSX failo funkcionalumas. Taškų importą iš failo turi turėti galimybę įvykdyti Perkančiosios organizacijos darbuotojas, turintis administratoriaus teises PNP valdymo sistemoje.
  • 12Turi būti veikiantis funkcionalumas į PM modulio elektroninę prekyvietę integruoti ir atvaizduoti išskirtinai tik Perkančiosios organizacijos darbuotojams siūlomus fizinius prizus su Perkančiosios organizacijos logotipu ir/arba kita Perkančiosios organizacijos prekės ženklo atributika, kuriuos Perkančioji organizacija įsigyja pati, pagal kitas sutartis.
  • 13Paslaugų teikėjas turi užtikrinti veikiantį funkcionalumą išskirtinai Perkančiosios organizacijos fizinių prizų likučių valdymui.
  • 14Turi būti galimybė ir funkcionalumas kiekvienam išskirtinai Perkančiosios organizacijos siūlomiems prizams (tiek fiziniams, tiek elektroniniams) sukurti ir įjungti prizo įsigijimo apribojimą (limitą). Sistemoje turi veikti funkcionalumas kurti prizo apribojimą (limitą) per darbuotoją ir/arba laikotarpį, ir/arba prizo kiekį.
  • 15Turi būti galimybė eksportuotis visus užsakymus (elektroninius ir fizinius) xls formatu nurodant visą su jais susijusią informaciją: kainą (vertę (be PVM ir įskaitant PVM) rūšį (spalvą/dydį ir kt) kiekį, išlaidų šaltinį.
  • 16Paslaugų teikėjas turi užtikrinti galimybę ir funkcionalumą pateikti PM statistiką, įskaitant, bet neapsiribojant įsitraukimo taškų skyrimo detalizacija, pripažinimo gavėjų/siuntėjų registru, įsitraukimo taškų balansu ir išlaidų išklotine. Sistemoje turi veikti funkcionalumas eksportuotis ataskaitas Excel formatu.
  • 17Paslaugų teikėjas turi užtikrinti galimybę ir funkcionalumą Perkančiosios organizacijos darbuotojams dalyvauti PM skiriant įsitraukimo taškus mobilioje valdymo programėlėje.
  • 18Paslaugų teikėjas turi užtikrinti funkcionalumą Perkančiosios organizacijos darbuotojams asmeniniame PM profilyje: matyti ir sekti įsitraukimo taškų balansą; matyti ir sekti aktyvius (naudojamus) PM įsitraukimo taškus; matyti ir sekti turimų įsitraukimo taškų piniginę vertę; pasirinkti pripažįstamą kolegą (ieškant pagal vardą, pavardę), skirti pripažinimo ženklelį, palikti komentarą; gauti pripažinimus ir įsitraukimo taškus iš kolegų; matyti ir sekti visus Perkančiosios organizacijos darbuotojų skiriamus pripažinimus bendrame pripažinimų naujienų sraute; matyti elektroninėje prekyvietėje galimų fizinių ir elektroninių prizų sąrašą, kainas, rūšis/variantus (dydį, spalvą ir kt.); užsisakyti norimą fizinį/elektroninį prizą iš elektroninės prekyvietės sukaupto biudžeto ribose.

Funkciniai reikalavimai (administravimo platforma)

  • 1Mobilioje aplikacijoje turi būti funkcionalumas visas įmonės Naudotojui paskelbtas naujienas matyti vienoje vietoje ir jas perskaityti.
  • 2Mobilioje aplikacijoje turi būti funkcionalumas užpildyti Personalo skyriaus pateiktą apklausą.
  • 3Turi būti realizuoti 2 Naudotojų prisijungimo būdai prie mobiliosios aplikacijos, naudojant: MS (Azure AD) paskyrą ir Sistemos administravimo platformoje esančių Darbuotojų duomenų rinkinius (Darbuotojo telefono numerį ir keturis paskutinius asmens kodo skaičius).
  • 4Mobilioje aplikacijoje turi būti funkcionalumas kurti norimas Naujienų kategorijas ir priskirti naujienas kategorijoms.
  • 5Mobilioje aplikacijoje turi būti funkcionalumas ieškoti naujienos pagal jos pavadinimą.
  • 6Sistema turi talpinti/įgyvendinti organizacinę struktūrą, kurioje galima: sukurti įmonę/-es ir jiems priskirti darbuotojus.
  • 7Darbuotojus turi būti galima priskirti ne tik įmonėms, tačiau įmonei priklausančiam padaliniui, taip pat, turi būti galima kurti atskiras darbuotojų grupes, nepriklausomai nuo organizacijos struktūros.
  • 8Įmonės ir darbuotojų kortelės turi būti žymimos statusu pagal jų galiojimo būseną.
  • 9Sistemoje turi būti galima suvesti šią informaciją apie darbuotojus: Vardas ir pavardė; Asmens kodas ar kitas ID kodas; Telefono numeris; Elektroninio pašto adresas; Gimimo data; Įmonė; Padalinys / Skyrius; Pareigybė/Pareigos; Įdarbinimo statusas (etato tipas); Įdarbinimo data; Kiti papildomų naudų valdymui aktualūs požymiai; Numatoma įdarbinimo ir darbo pasibaigimo data.
  • 10Sistemoje turi būti galima iš anksto numatyti darbuotojo įdarbinimo arba darbuotojo darbo pasibaigimo datą ir pagal sistemos taisykles (tiksli data ir laikas) automatiškai pakeisti darbuotojo būseną.
  • 11Sistemoje turi būti funkcionalumas koreguoti įmonės ir darbuotojų duomenis.
  • 12Sistemoje turi būti funkcionalumas perkelti pavienį darbuotoją į kitą padalinį ar pakeisti darbuotojo pareigybę.
  • 13Sistema turi suteikti galimybę naudoti ir keisti įmonės logotipus.
  • 14Sistemoje turi būti galimybė eksportuoti darbuotojų informaciją į Excel failą.
  • 15Sistemoje turi būti galimybė atlikti pagrindinius masyvius veiksmus su darbuotojais (pvz., aktyvuoti/deaktyvuoti pasirinktus darbuotojus).
  • 16Sistemoje turi būti įdiegta globali filtravimo sistema pagal trijų lygių organizacijos struktūrą.
  • 17Sistemoje turi būti galima kurti personalizuotus išskleidžiamojo sąrašo tipo darbuotojų laukus.
  • 18Sistemoje turi būti funkcionalumas, leidžiantis kurti turinį, skirtą komunikacijai su darbuotojais elektroniniu paštu ir mobiliąja aplikacija.
  • 19Kuriant turinį, skirtą komunikacijai su darbuotojais, sistema turi leisti prisegti nuotraukas (prisegamo failo dydis turi būti ne didesnis nei 25Mb).
  • 20Sistemoje turi būti funkcionalumas nustatyti komunikacinės žinutės gavėjus per darbuotojų grupes.
  • 21Sistemoje turi būti funkcionalumas nustatyti komunikacinės žinutės kanalus (el. paštu ir į mobiliąją aplikaciją).
  • 22Sistemoje turi būti funkcionalumas ištrinti komunikacinę žinutę ar sukurti esamos žinutės kopiją.
  • 23Sistemoje turi būti matomos visos komunikacinės žinutės vienoje vietoje.
  • 24Visos komunikacinės žinutės turi turėti statusą ir laiko žymą.
  • 25Sistemoje turi būti funkcionalumas matyti kiek Naudotojų gavo komunikacinę žinutę.
  • 26Sistemoje turi būti patogus komunikacinių žinučių paieškos funkcionalumas (pvz., pagal žinutės pavadinimą).
  • 27Sistemoje turi būti galimybė komunikacines žinutes valdyti šiomis kalbomis: lietuvių, anglų, rusų.
  • 28Sistemoje turi būti galimybė kurti komunikacinės žinutės juodraštį.
  • 29Sistemoje turi būti funkcionalumas numatyti komunikacinės žinutės paskelbimą į ateitį ar iš anksto numatyti jos skelbimo pabaigą ateityje.
  • 30Naudotojas turi būti automatiškai informuojamas apie jam priskirtą komunikacinę žinutę.
  • 31Sistemoje turi būti funkcionalumas, leidžiantis kurti, pridėti, naikinti darbuotojo profilyje esančią informaciją.
  • 32Sistema turi turėti galimybę integruotis su kitomis sistemomis pagal Šalių suderintas sąlygas.
  • 33Sistemoje turi būti funkcionalumas kurti bei siųsti grupinius/masinius, vienkartinius pranešimus, nereikalaujančius veiksmo iš Naudotojo.
  • 34Sistemos administratorius turi turėti teisę kurti ir deaktyvuoti Naudotojų paskyras Sistemoje.
  • 35Sistemoje turi būti galimybė bet kuriuo metu keisti Sistemos administratorių teises.
  • 36Sistemoje turi būti paieškos funkcija, kuri įgalintų sistemos administratorių, pagal jam suteiktas teises/prieigas ir pagal atitinkamą paieškos tekstą, gauti išfiltruotus Sistemoje saugomus duomenis.
  • 37Sistemoje turi būti ataskaitų generavimo funkcionalumas, kuris leistų kurti ataskaitas iš ataskaitų modulyje esančių duomenų pdf formatu.
  • 38Ataskaitų kūrimo ir generavimo priemonės Sistemoje turi turėti funkcionalumą keisti atitinkamų ataskaitų šablonus (formą).
  • 39Sistemoje turi būti funkcionalumas palaikyti ir filtruoti skirtingų organizacinių vienetų duomenis bendrai (įmonių grupė) ir atskirai (įmonės, padalinio).
  • 40Sistemoje turi būti funkcionalumas matyti tiek skirtingų organizacinių vienetų suvestinius duomenis už visus organizacinius vienetus, tiek kiekvieno organizacinio vieneto duomenis atskirai.
  • 41Paslaugų teikėjas privalo laikytis teisės aktų reikalavimų, nustatančių duomenų apsaugą bei teikti Paslaugas taip, kad visi su teikiamomis paslaugomis susiję veiksmai atitiktų Bendrąjį duomenų apsaugos reglamentą (ES) 2016/679.

Papildomų naudų paketų (PNP) reikalavimai (e-parduotuvė)

  • 1Galimybė Sistemoje rinktis Paslaugų teikėjo siūlomas trečiųjų šalių Teikėjų PNP.
  • 2Galimybė PNP priskirti Naudotojams per darbuotojų grupes ar individualiai.
  • 3Galimybė Lietuvoje rinktis iš ne mažiau kaip 100 atskirų trečiųjų šalių PNP teikėjų.
  • 4Galimybė Naudotojams įsigyti paslaugų ar prekių kuponus už skirtingos vertės sumas, pvz., už 5, 10, 15, 20, 50 Eur su PVM ir pan.
  • 5Galimybė Naudotojams įsigyti viešojo transporto bilietų (Vilniaus m.).
  • 6Galimybė Perkančiajai organizacijai kurti savo PNP (pvz., laisvos dienos Naudotojams ir pan.).
  • 7Galimybė Perkančiajai organizacijai kuriant savo PNP pateikti kiekvieno Naudotojo Sistemos profilyje informaciją apie Naudotojo sveikatos draudimą (nurodant ar sveikatos draudimas pasirinktas ar ne) bei (jeigu draudimas pasirinktas), nurodyti pasirinkto draudimo variantą. Galimybė minėtą informaciją į Sistemą įkelti pavieniu būdu.
  • 8Prie PNP turi būti galimybė teikti aprašymą (ne mažiau 2000 simbolių) ir pridėti nuotrauką (ne mažesnę kaip 20 MB) bei aktyvias nuorodas.
  • 9Galimybė nustatyti naudos galiojimo datą. Apie PNP galiojimo pasibaigimą Sistema turi teikti pranešimą priskirtiems administratoriams el. paštu.
  • 10Galimybė Naudotojui pateikti informaciją apie atsakingą asmenį už PNP administravimą (atsakingo asmens vardas, pavardė, el. paštas).
  • 11Automatinis Naudotojų informavimas pranešimu Naudotojo el. paštu arba Sistemoje apie naujos PNP atsiradimą.
  • 12Galimybė ieškoti PNP pagal pavadinimą.
  • 13Galimybė ieškoti PNP pagal panaudojimo šalį.
  • 14Galimybė Sistemoje suformuoti ataskaitą apie Naudotojams priskirtas PNP *xlsx formatu.
  • 15Galimybė pagal pasirinktą Sistemos kalbos turinį nustatyti naudų aprašymus skirtingomis (lietuvių, anglų) kalbomis.
  • 16Galimybė, pagal Užsakovo poreikį įtraukti Tiekėjo partnerių arba naujų partnerių papildomas PNP.
  • 17Galimybė Užsakovui ir Naudotojams įsigyti paslaugas ar prekes Paslaugų teikėjo vardu, o Paslaugų teikėjas užtikrina paslaugų ar prekių kuponų įsigijimą.
  • 18Galimybė sistemoje pašalinti PNP arba sustabdyti jų galiojimą.
  • 19Paslaugų teikėjas turi užtikrinti galimybę ir veikiantį funkcionalumą, esant Perkančiosios organizacijos poreikiui, įtraukti naujus PNP.
  • 20Naujų PNP kaina turi būti nedidesnė nei ji yra siūloma įsigyti viešai bet kuriam to pageidaujančiam fiziniam ar juridiniam asmeniui.
  • 21Nauji PNP turi atitikti Perkančiosios organizacijos vertybes ir strateginius tikslus. Turi būti galimybė siūlyti PNP Lietuvoje.
  • 22Nauji PNP yra įtraukiami tik šalims dėl to susitarus (informacinis pranešimas elektroniniu paštu).
  • 23Paslaugų teikėjas gauna PNP Užsakymą iš Perkančiosios organizacijos.
  • 24Paslaugų teikėjas įsigyja rinkoje užsakytą PNP Perkančiosios organizacijos vardu arba pats suteikia užsakytą PNP Perkančiajai organizacijai Užsakyme nustatyta tvarka, jeigu galutinis paslaugų teikėjas, užtikrina technines galimybes kupono įsigijimui.
  • 25Paslaugų teikėjas turi užtikrinti galimybę ir veikiantį funkcionalumą Perkančiajai organizacijai naudotis ir administruoti PNP lietuvių ir anglų kalbomis.
  • 26Minimalūs reikalavimai PNP informacijai: Pateiktas naudos pavadinimas; Naudos pavadinimas (matoma darbuotojui); Suma EUR; Vertė EUR (darbuotojui); Vertė rodoma Perkančiosios organizacijos turimoje PNP valdymo sistemoje (darbuotojui); Naudos galiojimo laikotarpis nuo iki (matoma darbuotojui); Naudos aprašymas (matoma darbuotojui); Nuoroda; Dažniausiai užduodami klausimai (D.U.K.); Segmentavimo kriterijai; Priedai (PDF, word, png, jpg ar kitais formatais).
  • 27Paslaugų teikėjas atsakingas už parengtos informacijos suderinimą su Perkančiąja organizacija.
  • 28Suderintą naudos informaciją Paslaugų teikėjas patalpina ir į Perkančiosios organizacijos PNP sistemą.
  • 29Papildomos paslaugos gali būti siūlomos Perkančiosios organizacijos darbuotojams, aiškiai nurodant, kad už jas Perkančiosios organizacijos darbuotojai turės susimokėti savarankiškai.
  • 30Paslaugų teikėjas papildomai kaip PNP gali siūlyti verslo partnerių taikomas nuolaidas, kurios atitinka Perkančiosios organizacijos vertybes, nustatytus kriterijus ir keliamus reikalavimus elektroninėje platformoje (elektroninėje parduotuvėje).
  • 31Paslaugų teikėjas prisiima atsakomybę pašalinti negaliojančias nuolaidas iš elektroninės platformos po nuolaidų galiojimo pasibaigimo datos.
  • 32Paslaugų teikėjas turi užtikrinti, kad Perkančiosios organizacijos darbuotojai PNP galėtų sklandžiai užsisakyti Paslaugų teikėjo elektroninėje platformoje.
  • 33Paslaugų teikėjas turi valdyti Perkančiosios organizacijos užklausas PNP pasirinkimo metu, išspręsti Perkančiosios organizacijos darbuotojų klausimus, formuoti DUK bazę, dalintis ja sistemoje su Perkančiosios organizacijos darbuotojais ir / ar Perkančiąja organizacija.
  • 34Perkančioji organizacija apmoka tik už laikotarpius, kada PNP Perkančiosios organizacijos darbuotojui galiojo arba jei Perkančiosios organizacijos darbuotojas pasinaudojo PNP pilna jo apimtimi iki Perkančiosios organizacijos darbuotojo išėjimo arba atleidimo (ar kitų PNP galiojimo pasibaigimo atvejų).
  • 35Perkančiosios organizacijos darbuotojai turi būti informuojami apie sėkmingą PNP užsakymą ir gauti patvirtinimą, instrukciją, kad gali naudotis PNP.
  • 36Perkančioji organizacija turi būti informuojama apie darbuotojų PNP pasirinkimus. Informacija turi automatiškai pasiekti Perkančiosios organizacijos darbuotojų valdymo sistemas. Informacijos pateikimo formos, būdas turi būti iš anksto suderintas su Perkančiąja organizacija.
  • 37Esant poreikiui, Paslaugų teikėjas turi užtikrinti galimybę ir veikiantį funkcionalumą skaidyti vieno PNP vertę ketvirčiais/ arba kitaip siekiant suvaldyti PNP skirtą biudžetą bei naujų darbuotojų prisijungimo / atsijungimo grafikus.
  • 38Perkančioji organizacija apmoka už faktiškai Perkančiosios organizacijos darbuotojų pasirinktus ir įsigytus PNP.
  • 39Paslaugų teikėjas turi užtikrinti ne mažiau kaip 100 skirtingų trečiųjų šalių nuolaidų Teikėjų.
  • 40Nuolaidomis turi galėti pasinaudoti visi Naudotojai.
  • 41Galimybė pridėti Perkančiosios organizacijos partnerių nuolaidas.
  • 42Galimybė ištrinti, bet kurią siūlomą nuolaidą.
  • 43Galimybė suformuoti *xlsx ataskaitą apie nuolaidų panaudojamumą su informacija apie panaudotų nuolaidų atvejų skaičių kiekvieną mėnesį.

Dokumentai12

  • 2_1_priedas_Technine_specifikacija.docx
  • 3_2 priedas_Pasiūlymo_forma.docx
  • SS_Papildomu naudu paslaugu teikimo sutartis.docx
  • espd-request.xml
  • espd-request.pdf
  • README.txt
  • 6_4 priedas _Pašalinimo pagrindai.docx
  • 7159972_Contract notice - general directive, standard regime_0.pdf
  • 1_Pirkimo sąlygos.docx
  • BS_Papildomu_naudu_paslaugos.docx
  • 7_c4t_7159972_1.xml
  • 1774_7159972.pdf