Sprendimai

Sprendimai viešajam sektoriui

Sistemos įstaigoms, kuriose reikalavimai ateina ne tik iš naudotojų, bet ir iš teisės aktų. Prieinamumas, duomenų apsauga ir pirkimo dokumentai numatomi nuo pradžios.

Aptarti projektą Specifikacija ir projektavimas

Viešojo sektoriaus projektas nuo verslo projekto skiriasi ne technologijomis, o procedūra. Sistema turi ne tik veikti, bet ir atitikti teisės aktus, būti nupirkta pagal viešųjų pirkimų taisykles ir likti perimama, kai prižiūrėtojas pasikeis. Šie trys dalykai nulemia daugiau nei bet koks technologinis pasirinkimas.

Ką kuriame įstaigoms

Dirbame ne su reprezentacinėmis svetainėmis, o su sistemomis, kuriose vyksta darbas: priimamos paraiškos, vertinami dokumentai, tvarkomi registrai ir aptarnaujami gyventojai.

Paraiškų priėmimo ir vertinimo sistemos. Kvietimai, paraiškų teikimas, ekspertų vertinimas pagal formas, balai, sprendimai ir sutartys su pasirašymu. Visa eiga lieka viename įraše su veiksmų žurnalu.
Registrai ir apskaitos sistemos. Nariai, objektai, leidimai, įrenginiai. Su prieigos teisėmis pagal roles ir istorija, kuri rodo, kas ir kada įrašą keitė.
Elektroninės paslaugos gyventojams. Prašymų teikimas, registracija į priėmimą, užsakymai ir mokėjimai, kai jie reikalingi.
Vidinės sistemos darbuotojams. Dokumentų srautai, užduočių paskirstymas ir ataskaitos, kurios šiandien renkamos rankomis iš kelių skaičiuoklių.
Renginių ir veiklų administravimas. Registracijos, dalyvių sąrašai, lankomumas ir mokėjimai, kai veikla mokama.

Techniškai tai tos pačios web aplikacijos, tik su papildomu reikalavimų sluoksniu, kurio privatūs pirkėjai neturi.

Atitiktis, kuri numatoma iš anksto

Prieinamumą ir duomenų apsaugą pigiausia įdėti projektuojant. Pridėti juos prie baigtos sistemos kainuoja kelis kartus brangiau, o kartais reiškia sąsajos perdarymą.

Bendrųjų reikalavimų aprašas. Valstybės ir savivaldybių įstaigų svetaines reglamentuoja Vyriausybės nutarimu Nr. 480 patvirtintas aprašas. Jis nustato ne tik prieinamumą, bet ir privalomą struktūrą: kokios skiltys turi būti, kokia informacija skelbiama ir kaip ji atnaujinama.

WCAG 2.1 AA. Prieinamumo reikalavimai kyla iš Europos Parlamento ir Tarybos direktyvos 2016/2102 ir taikomi kaip privalomas minimumas. Praktiškai tai kontrastas, valdymas klaviatūra, tekstinės alternatyvos, susietos formų etiketės ir prieinami dokumentai. Tikriname ne tik automatiniais įrankiais, nes dalies reikalavimų automatas neaptinka.

Prieinamumo paraiška. Įstaiga privalo viešai paskelbti, kiek svetainė atitinka reikalavimus ir kur yra neatitikimų. Techninę šio dokumento dalį parengiame pagal patikrinimo rezultatus, o ne pagal nuojautą.

Asmens duomenys. Prieigos teisės pagal roles, veiksmų žurnalas, saugojimo terminai ir duomenų ištrynimas pasibaigus terminui. Duomenų vieta nurodoma sutartyje, o ne paliekama tiekėjo nuožiūrai.

Pirkimui reikalingi dokumentai

Dažniausia kliūtis įstaigose yra ne sprendimas pirkti, o dokumentas, pagal kurį pirkti. Be jo tiekėjai skaičiuoja skirtingas apimtis, o pasiūlymų palyginti neįmanoma.

Techninė specifikacija rengiama funkciniais reikalavimais ir rezultato apibūdinimu, be nuorodų į konkrečius gaminius, prekės ženklus ar patentus, kurie sudarytų sąlygas vienam tiekėjui. Tai atskira paslauga, kuri gali baigtis ir tuo, kad sistemą sukurs kitas: IT konsultacijos ir sistemų projektavimas.

Kad prižiūrėtoją būtų galima pakeisti

Viešajame sektoriuje prižiūrėtojas keičiasi kas kelerius metus per naują pirkimą. Sistema, kurios negali perimti kitas tiekėjas, tampa įstaigos problema, o ne kūrėjo.

Todėl kodas, duomenų bazė, dokumentacija ir prieigos perduodami įstaigai, o sistema statoma ant atviro kodo pagrindo be uždarų komponentų, kurių licencijuoti niekas kitas negalėtų. Tas pats principas galioja ir integracijoms: jungtys aprašomos taip, kad jas galėtų prižiūrėti kitas.

Kaip vyksta darbas

Pradedame nuo analizės, kuri baigiasi apimtimi ir sąmata. Toliau prototipas, kūrimas etapais, testavimas ir paleidimas su apmokymais. Kiekvienas etapas baigiasi apčiuopiamu rezultatu, kurį galima pateikti kaip pasiekimo įrodymą, jei projektas finansuojamas ES lėšomis. Detaliau apie metodiką.

Panašūs projektai, kuriuose eiga nuo paraiškos iki sutarties vyksta vienoje sistemoje, aprašyti sutarčių valdymo ir pasirašymo platformos bei asociacijos narių ir renginių sistemos atvejuose.

Gatavas produktas įstaigoms ir individuali sistema

Abu keliai teisėti. Skiriasi tai, kur atsiduria atsakomybė.

Kriterijus	Gatavas produktas	Individuali sistema
Procedūros atitikimas	Procedūra derinama prie produkto	Sistema derinama prie procedūros
Prieinamumo atsakomybė	Priklauso nuo gamintojo plano	Įrašoma į sutartį kaip sąlyga
Diegimo laikas	Savaitės	Mėnesiai, priklausomai nuo apimties
Duomenų vieta	Gamintojo infrastruktūra	Įstaigos pasirinktas serveris
Integracijos su registrais	Tik numatytos gamintojo	Bet kuri sistema su API
Prižiūrėtojo keitimas	Priklauso nuo gamintojo	Perduodamas kodas ir duomenys
Ilgalaikė kaina	Auga su naudotojų skaičiumi	Priežiūra, nesusieta su naudotojais

DUK

Dažniausiai užduodami klausimai

Ar galite parengti techninę specifikaciją pirkimui?

Taip. Specifikacija rašoma funkciniais reikalavimais ir rezultato apibūdinimu, be nuorodų į konkrečius gaminius ar prekės ženklus, kurie sudarytų sąlygas vienam tiekėjui. Tai atskira paslauga, kuri gali baigtis ir tuo, kad sistemą kuria kas nors kitas.

Ką WCAG 2.1 AA reiškia praktikoje?

Tekstas turi turėti bent 4,5:1 kontrastą su fonu, visą svetainę galima valdyti klaviatūra, kiekvienas paveikslėlis turi tekstinę alternatyvą, formos laukai turi susietas etiketes, o vaizdo įrašai - subtitrus. Prisideda ir tai, kas dažnai pamirštama: PDF dokumentai svetainėje irgi turi būti prieinami.

Kas yra prieinamumo paraiška ir kas ją rengia?

Tai viešai skelbiamas dokumentas, kuriame įstaiga nurodo, kiek svetainė atitinka reikalavimus, kurios dalys neatitinka ir kodėl, bei kaip pranešti apie problemą. Paraišką skelbia pati įstaiga, bet techninę jos dalį parengiame mes, remdamiesi atlikto patikrinimo rezultatais.

Ar sistema atitiks Nutarimo Nr. 480 reikalavimus?

Taip, ir tai įrašoma į sutartį kaip priimtinumo sąlyga, o ne kaip pažadas. Bendrųjų reikalavimų aprašas nustato ne tik prieinamumą, bet ir privalomą struktūrą: kokios skiltys turi būti, kokia informacija skelbiama ir kaip ji atnaujinama.

Kur laikomi duomenys?

Ten, kur nurodo įstaiga. Dažniausiai tai serveriai Lietuvoje arba Europos Sąjungoje. Sistema kuriama taip, kad nebūtų pririšta prie vieno debesijos tiekėjo, todėl vietą galima keisti ir vėliau.

Kas nutinka pasibaigus sutarčiai?

Perduodame kodą, duomenų bazę, dokumentaciją ir prieigas. Sistemą galima perkelti kitam prižiūrėtojui be techninių kliūčių, nes ji nesiremia uždarais mūsų komponentais. Tai svarbu būtent viešajame sektoriuje, kur prižiūrėtojas keičiasi kas kelerius metus per naują pirkimą.

Ar galite perimti kito tiekėjo sukurtą sistemą?

Taip, jei yra prieiga prie kodo ir duomenų. Pradedame nuo peržiūros, kurios metu įvertiname būklę, saugumo spragas ir tai, kiek sistema atitinka dabartinius reikalavimus. Po jos aišku, ar pigiau tvarkyti esamą, ar kurti naują.

Ar sistemą galima sujungti su valstybės registrais ir kitomis sistemomis?

Taip, jei jos turi API arba kitą duomenų mainų būdą. Integracijos aprašomos dar analizės etape, nes nuo jų dažniausiai priklauso ir terminai, ir kaina.

Kaip vyksta darbas, kai projektas finansuojamas ES lėšomis?

Darbai skaidomi į etapus su aiškiais rezultatais, kuriuos galima pateikti kaip pasiekimo įrodymą. Kiekvienas etapas baigiasi kažkuo apčiuopiamu: dokumentu, veikiančia versija arba testavimo ataskaita, todėl ataskaitiniai reikalavimai neužklumpa projekto pabaigoje.