| Dokumendiregister | Riigimetsa Majandamise Keskus |
| Viit | 1-18/25 |
| Registreeritud | 12.02.2026 |
| Sünkroonitud | 16.05.2026 |
| Liik | Leping |
| Funktsioon | 1-18 |
| Sari | Põhitegevusega seotud lepingud |
| Toimik | |
| Juurdepääsupiirang | Avalik |
| Adressaat | OIXIO Digital AS |
| Saabumis/saatmisviis | OIXIO Digital AS |
| Vastutaja | Infotehnoloogia arenduste osakond |
| Originaal | Ava uues aknas |
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
1
LISA 1 – TEHNILINE KIRJELDUS 1. Hanke eesmärk ja üldised tingimused 1.1. Käesoleva hanke eesmärgiks on sõlmida raamleping ühe pakkujaga, kes hakkab juurutama RMK
(Hankija) personali- ja palgaarvestuse ja iseteeninduse lahendust (lisaks võimalikud lisaarendused). Hankega on hõlmatud lisaks koolitused ning tugi- ja hooldusteenus ning pakkuja lahenduse spetsiifilised litsentsid.
1.2. Eesmärgiks on võtta kasutusele ühtne MS Business Central HRM4Baltics personali- ja palgaarvestuse ja iseteeninduse tarkvara lähtuvalt HD Lisast 1 ja 2.
2. Tehnoloogilised nõuded 2.1. Tarkvara peab olema liidestatav hankija poolt kasutusel olevate ning tulevikus kasutusele
võetavate infosüsteemidega. Hanke väljakuulutamise hetkeks olevad infosüsteemid on kirjeldatud HD Lisas 2 (funktsionaalsusnõuded) ning Lisas 2.1.
2.2. Arendus- ja testkeskkondades kasutatakse ainult testandmeid. Andmetöötluse vajaduse ilmnedes LIVE (siin ja edaspidi tähenduses: töökeskkond, kus lahendus on hankijale kättesaadavaks tehtud) keskkonnast antakse töödeldavad andmed reeglina hägustatud või muul viisil anonümiseeritud kujul (v.a. juurutusperioodil).
3. Üldised nõuded tarkvarale Lahenduse funktsionaalsed nõuded on detailselt kirjeldatud HD Lisas 2 (funktsionaalsusnõuded). 3.1. Funktsionaalsuse ulatus ja kvaliteet:
3.1.1. Tarkvara peab katma kõik hanke alusdokumentides nõutud funktsionaalsused või pakkuma vähemalt samaväärset funktsionaalsuse taset.
3.1.2. Infosüsteem peab sisaldama mooduleid töötajate iseteeninduseks, personalihalduseks, palgaarvestuseks ja tööjõu planeerimiseks.
3.2. Äriprotsesside automatiseerimine: 3.2.1. Tarkvara peab sisaldama tööriistu äriprotsesside automatiseerimiseks, personali- ja
palgaarvestuse protsessis. 3.2.2. Peab võimaldama töövoogude loomist ja kohandamist, mis toetavad ettevõtte konkreetseid
äriprotsesse. 3.2.3. Moodulid peavad olema omavahel seotud (st standardlahenduses järgitakse läbivalt ühe
kliki põhimõtet eesmärgiga maksimeerida automatiseerimine ning tekitada protsessides efektiivsus). Andmesisestus peab olema läbivalt üle tarkvara ühekordne, st andmed on kasutatavad/kuvatavad teises moodulis (nt iseteeninduses või personalimoodulis sisestatud andmetest vajalikud väljad on nähtavad tööaja- ja palgaarvestuse moodulites).
3.3. Skaleeritavus ja paindlikkus: 3.3.1. Süsteem peab olema skaleeritav vastavalt hankija kasvavatele või kahanevatele
vajadustele ning toetama kohandusi ja konfiguratsiooni muudatusi vastavalt hankija spetsiifilistele nõuetele.
3.4. Pilvepõhisus ja turvalisus: 3.4.1. Tarkvara peab olema pilvepõhine lahendus, mis tagab kõrge turvalisuse ja andmete
kättesaadavuse. 3.4.2. Peab olema saadaval ülemaailmselt ja vastama EL-i isikuandmete kaitse üldmäärusele
(GDPR). 3.4.3. Juurutatav tarkvara lokalisatsioon ja tema komponendid peavad olema paigaldatud Hankija
haldusalas olevasse pilveruumi. 3.5. Kasutusmugavus ja kasutajaliides:
3.5.1. Tarkvara peab olema kasutajasõbralik ja intuitiivne, et tagada tõhus kasutamine organisatsiooni eri tasanditel.
3.5.2. Kõikidele funktsioonidele peab olema võimaldatud juurdepääs töölaua kaudu. 3.5.3. Palgaarvestuse moodul peab arvestama, et lisaks töötajatele teostatakse palgaarvestuse
süsteemi kaudu igakuiselt väljamakseid.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
2
4. Andmete korrastus ja andmete migratsioon 4.1. Pakutav tarkvaraline lahendus peab võimaldama andmete migratsiooni Hankija olemasolevatest
süsteemidest ja Hankija poolt välja töötatud reeglite alusel kus: 4.1.1. Defineeritakse andmete koosseis ja formaat; 4.1.2. Migreeritavate andmete maht; 4.1.3. Migreeritavate andmete eluiga.
4.2. Pakkuja peab pakkuma migratsiooni jaoks vajalikud tehnilised lahendused, milleks võivad olla: 4.2.1. Exceli kokkulepitud vormid; 4.2.2. Pakkuja võib pakkuda teistsugust lahendust, mis on aja- ja kuluefektiivsuse poolest sama
või parem. 4.3. Pakkuja peab pakkumist tegemisel arvestama, et andmed võivad migreerimisel vajada töötlust
ning nende kvaliteet testimist.
5. Litsentsid 5.1. Pakkuja peab tagama toote kasutamiseks vajalikud litsentsid Hankija poolt määratud ulatuses. 5.2. Pakkuja võib tarkvara loomisel kasutada järgnevaid komponente ja litsentse:
5.2.1. Üleantav tarkvara (või tarkvara üleantavad komponendid) – täitja loovutab kõik varalised autoriõigused tarkvarale tervikuna (või selle teatavatele osadele) tellijale.
5.2.2. Jagatav tarkvara (või komponendid) – täitja annab kõik varalised autoriõigused (või osa neist) tellijale ja jätab samad õigused ka endale. Jagatavate õiguste sisu ja maht tuleb pakkumuses selgelt määratleda.
5.2.3. Litsentseeritav tarkvara (või komponendid) – täitja annab tellijale enda loodud tarkvara suhtes litsentsi ning mis tuleb kirjeldada vastavalt punktile 5.6.
5.3. Hankija soetab Microsofti litsentsid personali- ja palgaarvestuse töötajatele ning iseteeninduse kasutajatele, mis on minimaalselt vajalikud MS Business Central lahenduses personali- ja palgaarvestuse protsesside haldamiseks ning iseteeninduse kasutamiseks, ning nende litsentside maksumust ei arvestata olelusringi kulude hulka.
5.4. Pakkuja pakkumus võib sisaldada lisaks punktis 5.2 nimetatud litsentsidele veel teisi Microsoft litsentse, mis peab olema lahti kirjeldatud litsentsikirjelduses (vt p 5.6).
5.5. Pakkuja võib rakendada eraldi litsentsitasusid pakkuja olemasolevate funktsionaalsuste, moodulite vm toodete osas. Nimetatud litsentsid peavad olema lahti kirjeldatud litsentsikirjelduses (vt p 5.6) ning võtma arvesse, et:
5.5.1. litsentside kogus on eeldatav lähtuvalt kasutajate arvust, kuid kasutajate arv võib muutuda raamlepingu täitmise ajal ning hankija ei ole kohustatud soetama litsentse käesolevas dokumendis märgitud kogustes;
5.5.2. litsentside maksumuse määramisel arvestatakse, et kõik kasutajad hakkavad LIVE keskkonda kasutama pärast I etapi LIVE;
5.5.3. arvesse võetakse kasutajate profiilid, mis võivad ühe isiku puhul kattuda, ning kasutajate kogused. Näiteks palgaarvestaja võib olla samuti ka tavakasutaja ehk lähtuma peaks loogikast, et kõrgema järgu litsents katab ära vastava isiku rollist tulenevad kõik tarkvara funktsionaalsused, mida tal on vaja kasutada.
Kasutajate profiil Arv ettevõttes Peakasutaja 1
Personalitöötaja 4 Tööaja märkija 8
Masin-masin liides 1 Iseteeninduse kasutaja 700
5.6. Pakkuja esitab vastavustingimustes litsentsikirjelduse, mis sisaldab: 5.6.1. kõikide pakkumusega seotud litsentside nimetust, kogust kasutajagruppide lõikes jm
oluline info; 5.6.2. pakkuja olemasolevate funktsionaalsuste, moodulite vm toodete pakutavate litsentside
osas lisaks kirjeldust ja maksumust, nn masin-masin litsentsid; 5.6.3. samaväärse platvormi litsentside jm seotud litsentside kirjeldust ja maksumust vastavalt
arenduse etappidele.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
3
5.7. Maksumusena märgitakse HD Lisas 3 ühikuhinnad kuu- ja/või aastapõhise hinnastamisega. Kasutajate arvu määramisel lähtutakse punktis 5.3.4 esitatud tabelist või HD Lisas 3 toodud kogusest, mis on eelduslikud.
5.8. Punktis 5.5.2 ja 5.5.3 nimetatud maksumused arvestatakse hanke maksumuse hulka vastavalt hindamiskriteeriumites toodule.
5.9. Microsofti litsentse Hankija käesoleva hanke raames edukalt pakkujalt ei osta, vaid ostab need eraldi. Samaväärsed litsentsid, mis on vajalikud lahenduse toimimiseks ja mis peavad olema pakkumuses välja toodud, ostab hankija edukalt pakkujalt käesoleva hanke raames otse vastavalt esitatud pakkumusele.
5.10. Hankija hindab vastavusena sh litsentside vajaduse realistlikkust (sh kas pakkuja poolt pakutud litsentside sisu ja kogusega on võimalik kasutada tarkvara hanke alusdokumentides märgitud funktsionaalsuses ja kasutajate arvuga).
5.11. Pakkuja võib pakkumusse lisada omapoolsed litsentsilepingu tingimused, mis ei tohi olla vastuolus hanke alusdokumentides sätestatuga ega esitada hankijale kitsendavaid või piiravamaid tingimusi hanke alusdokumentides sätestatust.
6. Juurutustööd ja lisaarendustööd 6.1. Juurutustööde aluseks on Pakkuja poolt pakkumusega esitatud Lisa 2, milles on esitatud iga
nõude eeldatav töötundide maht. Täpsem töötundide maht täpsustub peale analüüsifaasi koostatud projektiplaanis, kus on välja toodud töömahud tundide kaupa. Kui tegelik töömaht osutub projektiplaanis toodud tundidest rohkem kui 5% suuremaks, on Täitja kohustatud sellest Tellijat kirjalikult teavitama ning ootama ära Tellija kirjaliku kinnituse töödega jätkamiseks. Ilma Tellija eelneva kirjaliku kooskõlastuseta ületatud töötunnid ei kuulu Tellija poolt tasumisele.
6.2. Lisaarendustööde maht esitatakse arendusdokumendis töötundide kaupa. Kui tegelik töömaht osutub arendusdokumendis toodud tundidest rohkem kui 5% suuremaks, on Täitja kohustatud sellest Tellijat kirjalikult teavitama ning ootama ära Tellija kirjaliku kinnituse töödega jätkamiseks. Ilma Tellija eelneva kirjaliku kooskõlastuseta ületatud töötunnid ei kuulu Tellija poolt tasumisele.
6.3. Lisaarendustööd tähendavad nii uute süsteemide liidestamist tarkvaraga kui ka uute funktsionaalsuste lisamist.
6.4. Lisaarendustööd seisnevad tarkvara täiendava funktsionaalsuse eesmärgipärase funktsioneerimise tagamiseks teostatavatest töödest, mis ei ole käsitletavad tugiteenusena ja ei tulene seadusandluse muudatustest. Lisaarendustööd võivad olla ka täiendavad juurutamistööd raamlepingu kestvusel pärast esialgse juurutusperioodi lõppu. Hankijal on õigus, kuid mitte kohustus tellida täiendavaid lisaarendustöid.
6.5. Lisaarendus peab ühilduma tarkavaga selliselt, et see ei häiri tarkvara muud funktsionaalsust. Üleantud lisaarendus loetakse tarkvara osaks ning sellele laieneb ka tugiteenus olemasolevas mahus.
7. Arendustööde nõuded 7.1. Tarnida RMK jaoks arendatud Business Central laiendused koos lähtekoodiga. 7.2. Tarnida RMK jaoks arendatud Business Central laiendused koos tehnilise ja kasutaja
dokumentatsiooniga. 7.3. Kui tarnitav lahendus või selle osa ei ole Business Centrali platvormi komponent, siis sellistel
lahendustel peab olema eraldi turva / vastavuse sertifikaat. 7.4. Business Central äppide arendamisel peab tarnija jälgima Microsofti poolt kehtestatud nõuded ja
parimat praktikat, näiteks https://learn.microsoft.com/en-us/dynamics365/business-central/dev- itpro/compliance/apptest-bestpracticesforalcode.
7.5. Jälgima RMK tarkvara arenduse põhimõtted ja praktikat (vt HD Lisa 3). 7.6. Tarnija peab olema valmis kasutama RMK poolt ette antud IT haldusvahendid – JIRA, Confluence,
Azure DevOps jne. 7.7. Juhul, kui RMK-le tarnitakse kohandatud Business Centrali laiendus, mis põhineb sama tarnija
teise baasäppi peal ja laiendab selle funktsionaalsuse, peab tarnija hoidma ka põhirakenduste koodi up-to-date.
8. Koolitused 8.1. Riigihanke arendustööde mahtu kuulub tarkvara kasutamise eestikeelse üldjuhendi koostamine
ja hankijale kättesaadavaks tegemine hiljemalt arendusetapi lõpuks. Lisaks peab olema tagatud
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
4
kogu tarkvara kasutamise ajal ajakohastatud kasutusjuhendite kättesaadavus, sh lisaarenduste kirjeldused.
8.2. Riigihanke arendustööde mahtu kuulub tarkvara kasutamise koolitus kasutajatele rollist lähtuvates gruppides. Koolitus peab toimuma eesti keeles. Koolituse toimumisvorm (veebis või kohapeal) ja täpsed koolitusajad kokkuleppel hankijaga. Koolitus tuleb salvestada ning salvestus edastada hankijale. Koolitusel peavad olema käsitletud tarkvara funktsionaalsused. Täpsemad koolituste sihtgrupid ja arvud on funktsionaalsuste tabelis.
9. Tugiteenus ja hooldusteenus 9.1. Tugiteenus peab sisaldama pakutava lahenduse toimimisega seotud kasutajatuge (tugiisik kõigi
lokalisatsioonide jaoks) ja tarkvarauuendusi (sh versiooniuuendused) kogu raamlepingu kehtivusperioodil vastavalt hanke alusdokumentidele.
9.2. Seadusemuudatustest tulenevad versiooniuuendused peavad olema Tellijale kättesaadavad ilma täiendava tasuta.
9.3. Hankija nõuded tugiteenusele on järgmised: 9.3.1. raamlepingu täitmise ajal tagab pakkuja tarkvara kasutusteenuse nõuetekohase toimise,
sh intsidentide tekkimise korral reageerima ja probleemi lahendama vastavalt teenustasemetele;
9.3.2. parandama turvanõrkuseid ja uuendama tarkvara vastavalt lepingus sätestatule; 9.3.3. hoidma tarkvara kohalikule seadusandlusele vastavana; 9.3.4. hoidma tehnilist ja lõppkasutaja dokumentatsiooni ajakohasena; 9.3.5. nõustama hankijat süsteemis muudatuste tegemisel ja kasutamisel.
9.4. Tugi- ja hooldusteenust tellitakse vastavalt vajadusele ning arveldatakse tunnitasupõhiselt. 9.5. Tugiteenus peab olema tagatud tööpäevadel kella 08.00 kuni 17.00. Tööpäevadeks loetakse kõiki
nädalapäevi, välja arvatud laupäev, pühapäev ja riigipühad. 9.6. Teenusetasemed:
Raskusaste Probleemi definitsioon Reageerimisaeg Lahendamise
aeg
Tase 1 Kriitiline viga
Kogu rakendus pole saadaval või Kriitiline funktsionaalsus ei toimi. Kriitiline funktsionaalsus - tegevused, mis on seotud õigeaegse rahalise väljamaksega ja mille mitte toimimisest tekib hankijale rahaline kahju. Tegevused, mis tulenevalt mingist olukorrast on muutunud aegkriitiliseks.
1 töötund Kuni 4 tundi
Tase 2 Kõrge
tasemega viga
Osa kriitilisest funktsionaalsusest ei toimi, tagatud on workaround väljamakse tegemiseks.
1 töötund Kuni 24 tundi
Kriitiline funktsionaalsus toimib piiratud viisil; süsteemi või teenuse halvenemine, mis mõjutab lõppkasutajat või kahjustab oluliselt äriprotsesside kontrolli või tegevuse tõhusust (vaja on täiendavat tööaega).
Tase 3 Keskmise
tasemega viga
Viga mitte kriitilises funktsionaalsuses ja kõik muud probleemid
1 tööpäev kokkuleppel
Tase 4 Madala
tasemega viga
Kõik muud toenõuded, millega ei kaasne probleeme. 3 tööpäeva kokkuleppel
9.7. Kriitiliste funktsionaalsuste planeeritud katkestustest tuleb ette teatada vähemalt kaks (2)
tööpäeva, planeerimata katkestuste kogukestvus kuus ei tohi ületada 16 tundi ning aastas 192
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
5
tundi. Kriitiliste funktsionaalsuste varundamine peab toimuma igapäevaselt, varukoopiaid tuleb LIVE keskkonnal säilitada 365 päeva, testkeskkonnal 185 päeva.
9.7.1. Iga kuu 1.-5. tööpäeval ei tohi Tellija teostada planeeritud katkestusi. 9.8. Keskmiste funktsionaalsuste planeeritud katkestustest tuleb ette teatada vähemalt kaks (2)
tööpäeva, planeerimata katkestuste kogukestvus kuus ei tohi ületada 96 tundi ning aastas 1152 tundi. Keskmiste funktsionaalsuste varundamine peab toimuma igapäevaselt, varukoopiaid tuleb nii LIVE kui ka testkeskkonnal säilitada 35 päeva.
9.8.1. Iga kuu 1.-5. tööpäeval ei tohi Tellija teostada planeeritud katkestusi. 9.9. Tase 1 viga tuleb lahendada maksimaalselt 4 tunni jooksul, isegi kui lahendamise aeg väljub
punktis 9.5 nimetaud ajalisest piirist. 9.10. Reageerimisaeg on aeg, mille jooksul pakkuja annab hankijale esialgset tagasisidet probleemide
uurimise kohta. 9.11. Lahendusaeg on probleemi lahendamise maksimaalne aeg või Tellijale vastuvõetava alternatiivse
lahenduse rakendamine ja lõpliku lahenduse tähtaja kokkuleppimine Tellijaga ilma lisakuludeta hankijale.
9.12. Funktsioonide kasutamist häirivate plaaniliste hooldustööde kestus ei tohi ületada 12 tundi (kumulatiivselt) kuus.
9.13. Pakkuja esitab eelmise kvartali lõpus järgmisse kvartalisse tooteomaniku, kui tootja, poolt planeeritud tarkvarauuenduste info e-kirja teel lepingus kokku lepitud kontaktisikutele.
9.14. Pakkuja peab teostama tugiteenuse käigus ka korrapäraseid hooldustöid, mis tagavad pakutava tarkvara kasutusteenuse terviku (kaasa arvatud selle juurde kuuluvate andmete ja andmebaaside) toimivuse (korrasoleku, terviklikkuse, jõudluse, turvalisuse jms).
9.15. Pakkuja peab tagama tarkvara käideldavuse ja lahendama pöördumisi vastavalt raamlepingus sätestatud tähtaegadele.
9.16. Teenustaseme puhul loetakse oluliseks lepingu rikkumiseks mh, kui on rohkem kui 1 (üks) "Tase 1" või "Tase 2" viga kvartalis või 2 (kaks) "Tase 3" viga kvartalis eraldi või koos, mis ei ole punktis 9.5 etteantud ajal jooksul parandatud.
9.17. Järgmisi asjaolusid ei loeta rikkumisteks: 9.17.1. kokkulepitud plaanilised hoolduspausid; 9.17.2. rike, mis on põhjustatud võrguühendusest väljaspool taristu teenuse (IaaS)
teenusepakkuja võrku; 9.17.3. seisak, mille on põhjustanud vääramatu jõud.
9.18. Teenustasemete reageerimisaja rikkumiste korral kasutab Hankija tööaja kompenseerimise mudelit ehk tasuta tööaja pakkumist järgnevalt:
9.18.1. Tase 1 rikkumise korral on Hankijal õigus saada kuni 8 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.18.2. Tase 2 rikkumise korral kuni 4 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.18.3. Tase 3 ja tase 4 rikkumise korral kuni 2 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.19. Hankijal on õigus punkti 9.18. kompenseerimise mudel asendada leppetrahviga raamlepingu punktis 6.6 sätestatud määradega.
10. Raamhanke struktuur ja eeldatav ajakava 10.1. Raamleping kehtib 48 kalendrikuud või maksimaalse maksumuse täitumiseni (kohaldub esimene
täituv tingimus). 10.2. Tarkvara arenduse struktuur:
10.2.1. Arendusetapid võivad käivituda samaaegselt; 10.2.2. Funktsionaalsusnõuetes (HD Lisa 2) on kõik arendusnõuded defineeritud kui
„kohustuslikud“. 10.3. Lisaarenduse protsess kohaldub vaid nendele võimekustele, mida kohustuslikes funktsionaalsetes
nõuetes ei ole loetletud. 10.4. Ajakava:
10.4.1. LIVE kuupäev on eelduslikult 01.10.2026. 10.5. Pärast iga alametapi LIVE-i pakub pakkuja kaks kalendrinädalat nö hüperhooldust ehk
suurendatud järelevalvet LIVE-s tuvastatud esmaste vaegtööde lahenduseks, mille käigus keskendutakse tarkvara stabiilsuse tagamisele, varajaste vigade ja probleemide kiirele lahendamisele ning kasutajate tagasiside integreerimisele süsteemi täiustamiseks.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
6
10.6. Pärast alametapi hüperhoolduse perioodi lõppu hakkab kehtima antud alametapi osas ühe kalendriaastane garantii periood.
10.7. Juhul kui pakkumus sisaldas pakkuja poolt pakutavaid tarkvara litsentse, peab pakkuja võimaldama litsentsiga kaetud tarkvarale ligipääsu alates LIVEst. Vastav leping sõlmitakse enne LIVE ja hakkab kehtima LIVE kuupäevast.
11. Testimine 11.1. Enne töö üleandmist viib Täitja töö nõuetelevastavuse kindlakstegemiseks läbi testid. 11.2. Kui töö või mistahes selle osa ei läbi teste, viiakse viivitamatult pärast seda, kui Täitja on teinud
vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel tingimustel. Tellija nõudmisel viib kordustestid läbi Täitja.
12. Dokumentatsioon 12.1. Arenduste teostamisel peab Täitja koostama dokumendi(d), millede eesmärgiks on anda selge ja
konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest. 12.2. Eraldiseisvaid dokumente üle ei anta vaid Tellija keskkonda kirjutatakse analüüsi jooksvalt projekti
käigus. 12.3. Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust. 12.4. Üle antavad dokumendid peavad sisaldama:
12.4.1. Infosüsteemi terviku kirjeldus – olemasoleva süsteemi täiendamisel lisatud/muudetud osade kirjeldus. Tegemist on süsteemi ärisisul põhinevate baaskomponentidega, millele toetuvad kasutaja tegevused, ekraanivormid, kasutuslood/protsessid, teenused jms;
12.4.2. Vormide (ekraanivormide) kirjeldused; 12.4.3. Kasutuslugude / vormide kasutamise protsesside / tegevuste kirjeldused.
12.5. Infosüsteemi teenuste kirjeldused. 12.6. Juurutuse faasis ja lõpus peab Täitja esitama arhitektuuri kirjeldus dokumendi, mille eesmärgiks
on kirjeldada loodava ja/või juurutatava süsteemi tehnilist ülesehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise.
12.7. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest.
12.8. Täitja sisemiste koosolekute eest, mille töötunde esitatakse Tellijale tasumiseks, peab Täitja koostama ja esitama ülevaatliku memo, mis peab sisaldama vähemalt järgmist infot:
12.8.1. Koosolekul osalenud isikute nimekiri; 12.8.2. Koosoleku eesmärk ja arutatavad teemad; 12.8.3. Koosolekust projektile tekkiv väärus või mõju; 12.8.4. Põhiotsused ja järgmised sammud (kui rakendub); 12.8.5. Koosoleku kuupäev ja kestus.
Memo eesmärk on tagada tööde läbipaistvus ning võimalus hinnata koosoleku asjakohasust projekti täitmise seisukohast. Ilma nõuetekohase memota ei ole Täitjal õigust esitada Tellijale arvet nende töötundide eest.
13. Garantiitingimused 13.1. Täitja garanteerib tööde vastavuse lepingule ja seadusega sätestatud töövõtu tingimustele,
tarkvara kirjeldusele ning tellija põhitegevuse tavapärastele ja mõistlikele nõuetele kokkulepitud aja jooksul pärast tööde vastuvõtmist tellija poolt.
13.2. Täitja tagab garantii perioodiks 12 (kaksteist) kuud, mis algab tööde kogumina vastuvõtmisest. 13.3. Garantii korras vea parandamine hõlmab kõigi tarkvara osade, sealhulgas abistava
dokumentatsiooni parandamist või muutmist.
14. Nõuded projektiplaanile 14.1. Pakkumuse osana esitatakse tarkvara arenduse projektiplaan, mis sisaldab ajakava (tegevuste
ajalist kestvust) kõikide funktsionaalsuste loomiseks ja vajalike tööde läbiviimiseks. 14.2. Projektiplaanis peab olema selgelt eristatavad tööde etapid ning vajadusel jätku ja/või muud
tegevused. Tegevused peavad olema välja toodud nädala täpsusega. Projektiplaan peab olema koostatud arvestusega, et kõik hanke alusdokumentides nimetatud arendusega seotud tegevused oleks teostatud ja kogu lahendus kasutatav eelduslikult 01.10.2026.
14.3. Pakkumuses esitatav projektiplaan peab vastama järgmistele tingimustele:
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
7
14.3.1. projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud projekti eesmärk ja soovitud funktsionaalsus;
14.3.2. iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) sh vastutaja roll/nimi, ajaline kestus töötundides või tööpäevades ja tähtaeg vastavalt tööde mahule;
14.3.3. projektiplaanis peavad kajastuma töö tegemiseks vajalikud eeldused/lähteandmed ning töö mõõdetav(ad) tulem(id). Projektiplaan peab sisaldama mh. tööde ajalist kestvust.
14.3.4. kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud; 14.3.5. projektiplaan peab sisaldama varuaega (puhvrit) arvestades riiklike pühade,
puhkepäevade, projektimeeskonna puhkustega/vahetustega ja muu taolisega; 14.3.6. Projekti ajakohastamine toimub vaid poolte kirjalikul kokkuleppel.
14.4. Pakkuja peab kirjeldama, kuidas ta kavatseb maandada tarkvara arenduse projekti realiseerimise riske (HD Lisa 3).
14.5. Projektiplaan ja riskide maandamise plaan esitatakse Exceli kujul. Pakkuja võib lisaks pakkumusse lisada projektiplaani Microsoft Project formaadis.
15. Nõuded meeskonnale 15.1. Juhul, kui Täitja ei ole tooteomanik, kui tootja, peab Täitja kaasama läbiviidavatesse analüüsi
töötubadesse ka tooteomaniku, kui tootja esindaja, et tagada: 15.1.1. nõuetele vastavus ja toote funktsionaalne terviklikkus; 15.1.2. funktsionaalsuste ja tehniliste piirangute korrektne tõlgendamine; 15.1.3. süsteemi arhitektuuri ja konfiguratsioonipõhimõtete kinnitamine; 15.1.4. analüüsi tulemuste vastavus tarkvara tegelikele võimalustele; 15.1.5. hilisemate arenduste ja seadistuste valideerimine tootja pädevuse alusel.
15.2. Pakkuja peab raamlepingu täitmiseks komplekteerima piisava suurusega meeskonna, et oleks tagatud vajalik ning asjakohane inimressurss kogu arenduse ja juurutusperioodiks, kuid ka tugi- ja hooldusteenuse osutamiseks ja lisaarenduste tellimiseks.
15.3. Kõik meeskonnaliikmed peavad olema kättesaadavad projekti jooksul. 15.4. Kõik meeskonna rollid peavad olema lepingu kestel kaetud ja kättesaadavad vastavalt lepingus
kokkulepitud ulatusele. Kui mõne rolli täitja vahetub, peab Täitja teavitama Tellijat rollis oleva liikme asendamisest kirjalikult vähemalt 5 tööpäeva ette. Rolli ajutine või püsiv katmata jätmine on lubatud üksnes juhul, kui Tellija on selleks andnud eelneva kirjaliku nõusoleku.
15.5. Pakkuja asendab töid teostava isiku viivitamatult Lepingu eseme täitmise seisukohast võrdväärse kvalifikatsiooni ja kogemustega ning hankijale vastuvõetava isikuga, kui nimetatud töid teostav isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine pidevalt kahjustab raamlepingu korrektset ja õigeaegset täitmist.
15.6. Tellija ei ole kohustatud tasuma Täitja töötajate väljaõppe, sisseelamise ega koolitamisega seotud töötundide eest. Juhul kui Täitja vahetab projekti rollis oleva isiku, peab uus töötaja omandama vajalikud teadmised ja projektiga seonduva info Täitja enda kulul. Tellija ei tasu töötundide eest, mis on seotud:
15.6.1. uue töötaja koolitamise või väljaõppega; 15.6.2. projekti teemadega tutvumisega (sh dokumentatsiooni läbilugemine); 15.6.3. Täitja sisese duubeldamise või varjutamisega koosolekutel (nt olukord, kus uus või noorem
konsultant osaleb koosolekul ilma Tellijale lisaväärtust loomata). Sellised tunnid ei kuulu arveldamisele ja neid ei või Tellijale esitada sõltumata sellest, kas Täitja märgib need sisemiselt projekti tööajaks või mitte.
15.7. Arendusmeeskonna liikmetel peab olema varasem kogemus pakutava lahenduse juurutamisel (alates lahenduse analüüsist kuni juurutatava tarkvara kasutuselevõtuni). Meeskonna tööd koordineerib projektijuht, kelle suhtluskeel on eesti keel, sh peavad eesti keelt valdama B2 tasemel spetsialistid, kes on Tellijaga otsesuhtluses.
15.8. Pakkuja kannab kõik nimetatud asendusest tulenevad või sellega kaasnevad kulud. 15.9. Pakkuja meeskonna poolt täidetavad rollid on esitatud alljärgnevalt, kusjuures üks spetsialist ei
tohi katta mitte rohkem kui kahte rolli. 15.10. Projektijuht, kes korraldab suhtlust arendusmeeskonna ja hankija kontaktide vahel ning
vastutab lepingu igapäevase täitmise eest, sealhulgas: 15.10.1. koostöös tellijaga koostab ja jälgib arenduste teekaarti (sh ajakava, riskid); 15.10.2. korraldab ja juhib arenduste planeerimise ja retroperspektiivi koosolekuid; 15.10.3. korraldab ja juhib projektimeeskonna teisi korralisi koosolekuid;
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
8
15.10.4. juhib ja korraldab arendusmeeskonna igapäevatööd; 15.10.5. küsib tellija poolset tagasisidet ja lahendab sealt ülesse kerkinud probleeme; 15.10.6. korraldab tarkvara hooldamise ja toe pakkumise protsesse; 15.10.7. korraldab intsidentide ja probleemide lahendamise vastavalt lepingutingimustele; 15.10.8. korraldab tööde üleandmise ja arveldamise, planeerib tööde üleandmise tellijale
ning veendub enne üleandmist nende vastavuses tellija soovidele; 15.10.9. koostab ja esitab tellijale projekti aruandluse ning korraldab infovahetuse tellijaga. 15.10.10. Projektijuhil peab olema vähemalt 3-aastane kogemus tarkvaraprojektide juhtimisel
avalikus sektoris või samas mahuklassis erasektoris. 15.11. Arhitekt, kes kooskõlastab kõik suuremad arendustööd ja seisab selle eest, et
tarkvara arendatakse vastavalt baastoote loogikale ja arendussuunistele, sealhulgas: 15.11.1. töötab välja koostöös tellijaga tarkvara arhitektuuri (komponendid, andmestruktuurid,
algoritmid) ning suhtlusprotokollid teiste süsteemide ja kasutajatega; 15.11.2. vaatab üle suuremad muudatused teenustes ning uut tüüpi teenusesoovid ning liidesed; 15.11.3. vaatab üle muudatused andmemudelis; 15.11.4. otsustab ja kooskõlastab tellijaga kasutusele võetavad tehnoloogiad; 15.11.5. teeb ettepanekuid paremateks lahendusteks tarkvaras; 15.11.6. kirjutab tarkvara koodi ja andmelaadimise tingimused; 15.11.7. teostab koodi ülevaatust.
15.12. Analüütik/konsultant, kes kirjeldab kasutajate vajadused, seadistab süsteemi ja loob vajadusel lähteülesande arendusteks, sealhulgas:
15.12.1. analüüsib, millised on ärilised vajadused töö käigus väljatöötatavate lahenduste taga ning millised on lahenduste toimimiseks vajalikud ärilised protsessid;
15.12.2. analüüsib tellija soove ja vajadusi seoses tarkvaralahendusega ja formuleerib vajadused ning nõuded süsteemile;
15.12.3. töötab välja vajadustele vastavad lahenduste kavandid või täiendamisvajadused olemasolevas tarkvaras;
15.12.4. loob ärilistele vajadustele vastavad prototüübid; 15.12.5. tunneb tarkvara funktsionaalsust ning konsulteerib vajadusel peakasutajaid; 15.12.6. kaardistab ja dokumenteerib süsteemide ja süsteemi osade vahelised liidesed; 15.12.7. koostab lähteülesandeid arendusteks ja tehnilise dokumentatsiooni. 15.12.8. Analüütik peab omama varasemat kogemust palga- ja personali (HRM) valdkonna
lahenduste analüüsimisel ja seadistamisel. 15.12.9. Konsultandil peab olema vähemalt 2-aastane kogemus Microsoft Business Centrali või
samaväärse ERP-süsteemi personalimooduli kasutuselevõtul ning ta peab omama HRM4 Baltics toote ametlikku sertifikaati.
15.13. Arendaja, kes teostab vastavalt lähteülesandele ja MS Dynamicsi arendussuunistele kliendispetsiifilised eriarendused, sealhulgas:
15.13.1. hoolitseb selle eest, et tarkvara andmebaas, komponendid ja liidestused erinevate infosüsteemide vahel kõik omavahel hästi töötaksid;
15.13.2. konsulteerib konsultante/analüütikuid vajadustele vastavate lahenduste variantide osas; 15.13.3. kirjutab tarkvara koodi; 15.13.4. kirjutab automaattestid; 15.13.5. teostab koodi ülevaatust. 15.13.6. Arendajal peab olema vähemalt 2-aastane kogemus Business Centrali (AL-keele) arenduses
ning ta peab omama HRM4 Baltics toote ametlikku sertifikaati, mis kinnitab pädevust konkreetse toote laienduste ja integratsioonide loomisel.
15.14. Testija/dokumenteerija, kes dokumenteerib nõuetekohaselt teostatud arendused ja testib nende toimimist, sealhulgas:
15.14.1. loob testjuhtumid valminud lahenduste testimiseks; 15.14.2. genereerib vajadusel testandmed loodud lahenduste testimiseks; 15.14.3. testib tarkvara; 15.14.4. loob ja täiendab testlugusid; 15.14.5. loob kasutusjuhendeid; 15.14.6. teostab kasutajate konsulteerimist ja koolitamist; 15.14.7. võib kirjutada kasutajaliidese automaat-teste. 15.14.8. Testijal peab olema kogemus ERP-lahenduste testimise metoodikate ja
kvaliteediprotsesside rakendamisel.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
9
15.15. Hankija meeskonda kuuluvad arendusprojekti projektijuht, peakasutajad, IT tooteomanikud, analüütikud, arhitektid, tehnilised konsultandid.
15.16. Juhul, kui Täitja ei ole tooteomanik, kui tootja, siis on Hankijal õigus kaasata tooteomaniku, kui tootja, esindaja olulisemaid projekti etappe ja mahte sõltumatu osapoolne valideerima.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
1
LISA 1 – TEHNILINE KIRJELDUS 1. Hanke eesmärk ja üldised tingimused 1.1. Käesoleva hanke eesmärgiks on sõlmida raamleping ühe pakkujaga, kes hakkab juurutama RMK
(Hankija) personali- ja palgaarvestuse ja iseteeninduse lahendust (lisaks võimalikud lisaarendused). Hankega on hõlmatud lisaks koolitused ning tugi- ja hooldusteenus ning pakkuja lahenduse spetsiifilised litsentsid.
1.2. Eesmärgiks on võtta kasutusele ühtne MS Business Central HRM4Baltics personali- ja palgaarvestuse ja iseteeninduse tarkvara lähtuvalt HD Lisast 1 ja 2.
2. Tehnoloogilised nõuded 2.1. Tarkvara peab olema liidestatav hankija poolt kasutusel olevate ning tulevikus kasutusele
võetavate infosüsteemidega. Hanke väljakuulutamise hetkeks olevad infosüsteemid on kirjeldatud HD Lisas 2 (funktsionaalsusnõuded) ning Lisas 2.1.
2.2. Arendus- ja testkeskkondades kasutatakse ainult testandmeid. Andmetöötluse vajaduse ilmnedes LIVE (siin ja edaspidi tähenduses: töökeskkond, kus lahendus on hankijale kättesaadavaks tehtud) keskkonnast antakse töödeldavad andmed reeglina hägustatud või muul viisil anonümiseeritud kujul (v.a. juurutusperioodil).
3. Üldised nõuded tarkvarale Lahenduse funktsionaalsed nõuded on detailselt kirjeldatud HD Lisas 2 (funktsionaalsusnõuded). 3.1. Funktsionaalsuse ulatus ja kvaliteet:
3.1.1. Tarkvara peab katma kõik hanke alusdokumentides nõutud funktsionaalsused või pakkuma vähemalt samaväärset funktsionaalsuse taset.
3.1.2. Infosüsteem peab sisaldama mooduleid töötajate iseteeninduseks, personalihalduseks, palgaarvestuseks ja tööjõu planeerimiseks.
3.2. Äriprotsesside automatiseerimine: 3.2.1. Tarkvara peab sisaldama tööriistu äriprotsesside automatiseerimiseks, personali- ja
palgaarvestuse protsessis. 3.2.2. Peab võimaldama töövoogude loomist ja kohandamist, mis toetavad ettevõtte konkreetseid
äriprotsesse. 3.2.3. Moodulid peavad olema omavahel seotud (st standardlahenduses järgitakse läbivalt ühe
kliki põhimõtet eesmärgiga maksimeerida automatiseerimine ning tekitada protsessides efektiivsus). Andmesisestus peab olema läbivalt üle tarkvara ühekordne, st andmed on kasutatavad/kuvatavad teises moodulis (nt iseteeninduses või personalimoodulis sisestatud andmetest vajalikud väljad on nähtavad tööaja- ja palgaarvestuse moodulites).
3.3. Skaleeritavus ja paindlikkus: 3.3.1. Süsteem peab olema skaleeritav vastavalt hankija kasvavatele või kahanevatele
vajadustele ning toetama kohandusi ja konfiguratsiooni muudatusi vastavalt hankija spetsiifilistele nõuetele.
3.4. Pilvepõhisus ja turvalisus: 3.4.1. Tarkvara peab olema pilvepõhine lahendus, mis tagab kõrge turvalisuse ja andmete
kättesaadavuse. 3.4.2. Peab olema saadaval ülemaailmselt ja vastama EL-i isikuandmete kaitse üldmäärusele
(GDPR). 3.4.3. Juurutatav tarkvara lokalisatsioon ja tema komponendid peavad olema paigaldatud Hankija
haldusalas olevasse pilveruumi. 3.5. Kasutusmugavus ja kasutajaliides:
3.5.1. Tarkvara peab olema kasutajasõbralik ja intuitiivne, et tagada tõhus kasutamine organisatsiooni eri tasanditel.
3.5.2. Kõikidele funktsioonidele peab olema võimaldatud juurdepääs töölaua kaudu. 3.5.3. Palgaarvestuse moodul peab arvestama, et lisaks töötajatele teostatakse palgaarvestuse
süsteemi kaudu igakuiselt väljamakseid.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
2
4. Andmete korrastus ja andmete migratsioon 4.1. Pakutav tarkvaraline lahendus peab võimaldama andmete migratsiooni Hankija olemasolevatest
süsteemidest ja Hankija poolt välja töötatud reeglite alusel kus: 4.1.1. Defineeritakse andmete koosseis ja formaat; 4.1.2. Migreeritavate andmete maht; 4.1.3. Migreeritavate andmete eluiga.
4.2. Pakkuja peab pakkuma migratsiooni jaoks vajalikud tehnilised lahendused, milleks võivad olla: 4.2.1. Exceli kokkulepitud vormid; 4.2.2. Pakkuja võib pakkuda teistsugust lahendust, mis on aja- ja kuluefektiivsuse poolest sama
või parem. 4.3. Pakkuja peab pakkumist tegemisel arvestama, et andmed võivad migreerimisel vajada töötlust
ning nende kvaliteet testimist.
5. Litsentsid 5.1. Pakkuja peab tagama toote kasutamiseks vajalikud litsentsid Hankija poolt määratud ulatuses. 5.2. Pakkuja võib tarkvara loomisel kasutada järgnevaid komponente ja litsentse:
5.2.1. Üleantav tarkvara (või tarkvara üleantavad komponendid) – täitja loovutab kõik varalised autoriõigused tarkvarale tervikuna (või selle teatavatele osadele) tellijale.
5.2.2. Jagatav tarkvara (või komponendid) – täitja annab kõik varalised autoriõigused (või osa neist) tellijale ja jätab samad õigused ka endale. Jagatavate õiguste sisu ja maht tuleb pakkumuses selgelt määratleda.
5.2.3. Litsentseeritav tarkvara (või komponendid) – täitja annab tellijale enda loodud tarkvara suhtes litsentsi ning mis tuleb kirjeldada vastavalt punktile 5.6.
5.3. Hankija soetab Microsofti litsentsid personali- ja palgaarvestuse töötajatele ning iseteeninduse kasutajatele, mis on minimaalselt vajalikud MS Business Central lahenduses personali- ja palgaarvestuse protsesside haldamiseks ning iseteeninduse kasutamiseks, ning nende litsentside maksumust ei arvestata olelusringi kulude hulka.
5.4. Pakkuja pakkumus võib sisaldada lisaks punktis 5.2 nimetatud litsentsidele veel teisi Microsoft litsentse, mis peab olema lahti kirjeldatud litsentsikirjelduses (vt p 5.6).
5.5. Pakkuja võib rakendada eraldi litsentsitasusid pakkuja olemasolevate funktsionaalsuste, moodulite vm toodete osas. Nimetatud litsentsid peavad olema lahti kirjeldatud litsentsikirjelduses (vt p 5.6) ning võtma arvesse, et:
5.5.1. litsentside kogus on eeldatav lähtuvalt kasutajate arvust, kuid kasutajate arv võib muutuda raamlepingu täitmise ajal ning hankija ei ole kohustatud soetama litsentse käesolevas dokumendis märgitud kogustes;
5.5.2. litsentside maksumuse määramisel arvestatakse, et kõik kasutajad hakkavad LIVE keskkonda kasutama pärast I etapi LIVE;
5.5.3. arvesse võetakse kasutajate profiilid, mis võivad ühe isiku puhul kattuda, ning kasutajate kogused. Näiteks palgaarvestaja võib olla samuti ka tavakasutaja ehk lähtuma peaks loogikast, et kõrgema järgu litsents katab ära vastava isiku rollist tulenevad kõik tarkvara funktsionaalsused, mida tal on vaja kasutada.
Kasutajate profiil Arv ettevõttes Peakasutaja 1
Personalitöötaja 4 Tööaja märkija 8
Masin-masin liides 1 Iseteeninduse kasutaja 700
5.6. Pakkuja esitab vastavustingimustes litsentsikirjelduse, mis sisaldab: 5.6.1. kõikide pakkumusega seotud litsentside nimetust, kogust kasutajagruppide lõikes jm
oluline info; 5.6.2. pakkuja olemasolevate funktsionaalsuste, moodulite vm toodete pakutavate litsentside
osas lisaks kirjeldust ja maksumust, nn masin-masin litsentsid; 5.6.3. samaväärse platvormi litsentside jm seotud litsentside kirjeldust ja maksumust vastavalt
arenduse etappidele.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
3
5.7. Maksumusena märgitakse HD Lisas 3 ühikuhinnad kuu- ja/või aastapõhise hinnastamisega. Kasutajate arvu määramisel lähtutakse punktis 5.3.4 esitatud tabelist või HD Lisas 3 toodud kogusest, mis on eelduslikud.
5.8. Punktis 5.5.2 ja 5.5.3 nimetatud maksumused arvestatakse hanke maksumuse hulka vastavalt hindamiskriteeriumites toodule.
5.9. Microsofti litsentse Hankija käesoleva hanke raames edukalt pakkujalt ei osta, vaid ostab need eraldi. Samaväärsed litsentsid, mis on vajalikud lahenduse toimimiseks ja mis peavad olema pakkumuses välja toodud, ostab hankija edukalt pakkujalt käesoleva hanke raames otse vastavalt esitatud pakkumusele.
5.10. Hankija hindab vastavusena sh litsentside vajaduse realistlikkust (sh kas pakkuja poolt pakutud litsentside sisu ja kogusega on võimalik kasutada tarkvara hanke alusdokumentides märgitud funktsionaalsuses ja kasutajate arvuga).
5.11. Pakkuja võib pakkumusse lisada omapoolsed litsentsilepingu tingimused, mis ei tohi olla vastuolus hanke alusdokumentides sätestatuga ega esitada hankijale kitsendavaid või piiravamaid tingimusi hanke alusdokumentides sätestatust.
6. Juurutustööd ja lisaarendustööd 6.1. Juurutustööde aluseks on Pakkuja poolt pakkumusega esitatud Lisa 2, milles on esitatud iga
nõude eeldatav töötundide maht. Täpsem töötundide maht täpsustub peale analüüsifaasi koostatud projektiplaanis, kus on välja toodud töömahud tundide kaupa. Kui tegelik töömaht osutub projektiplaanis toodud tundidest rohkem kui 5% suuremaks, on Täitja kohustatud sellest Tellijat kirjalikult teavitama ning ootama ära Tellija kirjaliku kinnituse töödega jätkamiseks. Ilma Tellija eelneva kirjaliku kooskõlastuseta ületatud töötunnid ei kuulu Tellija poolt tasumisele.
6.2. Lisaarendustööde maht esitatakse arendusdokumendis töötundide kaupa. Kui tegelik töömaht osutub arendusdokumendis toodud tundidest rohkem kui 5% suuremaks, on Täitja kohustatud sellest Tellijat kirjalikult teavitama ning ootama ära Tellija kirjaliku kinnituse töödega jätkamiseks. Ilma Tellija eelneva kirjaliku kooskõlastuseta ületatud töötunnid ei kuulu Tellija poolt tasumisele.
6.3. Lisaarendustööd tähendavad nii uute süsteemide liidestamist tarkvaraga kui ka uute funktsionaalsuste lisamist.
6.4. Lisaarendustööd seisnevad tarkvara täiendava funktsionaalsuse eesmärgipärase funktsioneerimise tagamiseks teostatavatest töödest, mis ei ole käsitletavad tugiteenusena ja ei tulene seadusandluse muudatustest. Lisaarendustööd võivad olla ka täiendavad juurutamistööd raamlepingu kestvusel pärast esialgse juurutusperioodi lõppu. Hankijal on õigus, kuid mitte kohustus tellida täiendavaid lisaarendustöid.
6.5. Lisaarendus peab ühilduma tarkavaga selliselt, et see ei häiri tarkvara muud funktsionaalsust. Üleantud lisaarendus loetakse tarkvara osaks ning sellele laieneb ka tugiteenus olemasolevas mahus.
7. Arendustööde nõuded 7.1. Tarnida RMK jaoks arendatud Business Central laiendused koos lähtekoodiga. 7.2. Tarnida RMK jaoks arendatud Business Central laiendused koos tehnilise ja kasutaja
dokumentatsiooniga. 7.3. Kui tarnitav lahendus või selle osa ei ole Business Centrali platvormi komponent, siis sellistel
lahendustel peab olema eraldi turva / vastavuse sertifikaat. 7.4. Business Central äppide arendamisel peab tarnija jälgima Microsofti poolt kehtestatud nõuded ja
parimat praktikat, näiteks https://learn.microsoft.com/en-us/dynamics365/business-central/dev- itpro/compliance/apptest-bestpracticesforalcode.
7.5. Jälgima RMK tarkvara arenduse põhimõtted ja praktikat (vt HD Lisa 3). 7.6. Tarnija peab olema valmis kasutama RMK poolt ette antud IT haldusvahendid – JIRA, Confluence,
Azure DevOps jne. 7.7. Juhul, kui RMK-le tarnitakse kohandatud Business Centrali laiendus, mis põhineb sama tarnija
teise baasäppi peal ja laiendab selle funktsionaalsuse, peab tarnija hoidma ka põhirakenduste koodi up-to-date.
8. Koolitused 8.1. Riigihanke arendustööde mahtu kuulub tarkvara kasutamise eestikeelse üldjuhendi koostamine
ja hankijale kättesaadavaks tegemine hiljemalt arendusetapi lõpuks. Lisaks peab olema tagatud
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
4
kogu tarkvara kasutamise ajal ajakohastatud kasutusjuhendite kättesaadavus, sh lisaarenduste kirjeldused.
8.2. Riigihanke arendustööde mahtu kuulub tarkvara kasutamise koolitus kasutajatele rollist lähtuvates gruppides. Koolitus peab toimuma eesti keeles. Koolituse toimumisvorm (veebis või kohapeal) ja täpsed koolitusajad kokkuleppel hankijaga. Koolitus tuleb salvestada ning salvestus edastada hankijale. Koolitusel peavad olema käsitletud tarkvara funktsionaalsused. Täpsemad koolituste sihtgrupid ja arvud on funktsionaalsuste tabelis.
9. Tugiteenus ja hooldusteenus 9.1. Tugiteenus peab sisaldama pakutava lahenduse toimimisega seotud kasutajatuge (tugiisik kõigi
lokalisatsioonide jaoks) ja tarkvarauuendusi (sh versiooniuuendused) kogu raamlepingu kehtivusperioodil vastavalt hanke alusdokumentidele.
9.2. Seadusemuudatustest tulenevad versiooniuuendused peavad olema Tellijale kättesaadavad ilma täiendava tasuta.
9.3. Hankija nõuded tugiteenusele on järgmised: 9.3.1. raamlepingu täitmise ajal tagab pakkuja tarkvara kasutusteenuse nõuetekohase toimise,
sh intsidentide tekkimise korral reageerima ja probleemi lahendama vastavalt teenustasemetele;
9.3.2. parandama turvanõrkuseid ja uuendama tarkvara vastavalt lepingus sätestatule; 9.3.3. hoidma tarkvara kohalikule seadusandlusele vastavana; 9.3.4. hoidma tehnilist ja lõppkasutaja dokumentatsiooni ajakohasena; 9.3.5. nõustama hankijat süsteemis muudatuste tegemisel ja kasutamisel.
9.4. Tugi- ja hooldusteenust tellitakse vastavalt vajadusele ning arveldatakse tunnitasupõhiselt. 9.5. Tugiteenus peab olema tagatud tööpäevadel kella 08.00 kuni 17.00. Tööpäevadeks loetakse kõiki
nädalapäevi, välja arvatud laupäev, pühapäev ja riigipühad. 9.6. Teenusetasemed:
Raskusaste Probleemi definitsioon Reageerimisaeg Lahendamise
aeg
Tase 1 Kriitiline viga
Kogu rakendus pole saadaval või Kriitiline funktsionaalsus ei toimi. Kriitiline funktsionaalsus - tegevused, mis on seotud õigeaegse rahalise väljamaksega ja mille mitte toimimisest tekib hankijale rahaline kahju. Tegevused, mis tulenevalt mingist olukorrast on muutunud aegkriitiliseks.
1 töötund Kuni 4 tundi
Tase 2 Kõrge
tasemega viga
Osa kriitilisest funktsionaalsusest ei toimi, tagatud on workaround väljamakse tegemiseks.
1 töötund Kuni 24 tundi
Kriitiline funktsionaalsus toimib piiratud viisil; süsteemi või teenuse halvenemine, mis mõjutab lõppkasutajat või kahjustab oluliselt äriprotsesside kontrolli või tegevuse tõhusust (vaja on täiendavat tööaega).
Tase 3 Keskmise
tasemega viga
Viga mitte kriitilises funktsionaalsuses ja kõik muud probleemid
1 tööpäev kokkuleppel
Tase 4 Madala
tasemega viga
Kõik muud toenõuded, millega ei kaasne probleeme. 3 tööpäeva kokkuleppel
9.7. Kriitiliste funktsionaalsuste planeeritud katkestustest tuleb ette teatada vähemalt kaks (2)
tööpäeva, planeerimata katkestuste kogukestvus kuus ei tohi ületada 16 tundi ning aastas 192
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
5
tundi. Kriitiliste funktsionaalsuste varundamine peab toimuma igapäevaselt, varukoopiaid tuleb LIVE keskkonnal säilitada 365 päeva, testkeskkonnal 185 päeva.
9.7.1. Iga kuu 1.-5. tööpäeval ei tohi Tellija teostada planeeritud katkestusi. 9.8. Keskmiste funktsionaalsuste planeeritud katkestustest tuleb ette teatada vähemalt kaks (2)
tööpäeva, planeerimata katkestuste kogukestvus kuus ei tohi ületada 96 tundi ning aastas 1152 tundi. Keskmiste funktsionaalsuste varundamine peab toimuma igapäevaselt, varukoopiaid tuleb nii LIVE kui ka testkeskkonnal säilitada 35 päeva.
9.8.1. Iga kuu 1.-5. tööpäeval ei tohi Tellija teostada planeeritud katkestusi. 9.9. Tase 1 viga tuleb lahendada maksimaalselt 4 tunni jooksul, isegi kui lahendamise aeg väljub
punktis 9.5 nimetaud ajalisest piirist. 9.10. Reageerimisaeg on aeg, mille jooksul pakkuja annab hankijale esialgset tagasisidet probleemide
uurimise kohta. 9.11. Lahendusaeg on probleemi lahendamise maksimaalne aeg või Tellijale vastuvõetava alternatiivse
lahenduse rakendamine ja lõpliku lahenduse tähtaja kokkuleppimine Tellijaga ilma lisakuludeta hankijale.
9.12. Funktsioonide kasutamist häirivate plaaniliste hooldustööde kestus ei tohi ületada 12 tundi (kumulatiivselt) kuus.
9.13. Pakkuja esitab eelmise kvartali lõpus järgmisse kvartalisse tooteomaniku, kui tootja, poolt planeeritud tarkvarauuenduste info e-kirja teel lepingus kokku lepitud kontaktisikutele.
9.14. Pakkuja peab teostama tugiteenuse käigus ka korrapäraseid hooldustöid, mis tagavad pakutava tarkvara kasutusteenuse terviku (kaasa arvatud selle juurde kuuluvate andmete ja andmebaaside) toimivuse (korrasoleku, terviklikkuse, jõudluse, turvalisuse jms).
9.15. Pakkuja peab tagama tarkvara käideldavuse ja lahendama pöördumisi vastavalt raamlepingus sätestatud tähtaegadele.
9.16. Teenustaseme puhul loetakse oluliseks lepingu rikkumiseks mh, kui on rohkem kui 1 (üks) "Tase 1" või "Tase 2" viga kvartalis või 2 (kaks) "Tase 3" viga kvartalis eraldi või koos, mis ei ole punktis 9.5 etteantud ajal jooksul parandatud.
9.17. Järgmisi asjaolusid ei loeta rikkumisteks: 9.17.1. kokkulepitud plaanilised hoolduspausid; 9.17.2. rike, mis on põhjustatud võrguühendusest väljaspool taristu teenuse (IaaS)
teenusepakkuja võrku; 9.17.3. seisak, mille on põhjustanud vääramatu jõud.
9.18. Teenustasemete reageerimisaja rikkumiste korral kasutab Hankija tööaja kompenseerimise mudelit ehk tasuta tööaja pakkumist järgnevalt:
9.18.1. Tase 1 rikkumise korral on Hankijal õigus saada kuni 8 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.18.2. Tase 2 rikkumise korral kuni 4 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.18.3. Tase 3 ja tase 4 rikkumise korral kuni 2 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.19. Hankijal on õigus punkti 9.18. kompenseerimise mudel asendada leppetrahviga raamlepingu punktis 6.6 sätestatud määradega.
10. Raamhanke struktuur ja eeldatav ajakava 10.1. Raamleping kehtib 48 kalendrikuud või maksimaalse maksumuse täitumiseni (kohaldub esimene
täituv tingimus). 10.2. Tarkvara arenduse struktuur:
10.2.1. Arendusetapid võivad käivituda samaaegselt; 10.2.2. Funktsionaalsusnõuetes (HD Lisa 2) on kõik arendusnõuded defineeritud kui
„kohustuslikud“. 10.3. Lisaarenduse protsess kohaldub vaid nendele võimekustele, mida kohustuslikes funktsionaalsetes
nõuetes ei ole loetletud. 10.4. Ajakava:
10.4.1. LIVE kuupäev on eelduslikult 01.10.2026. 10.5. Pärast iga alametapi LIVE-i pakub pakkuja kaks kalendrinädalat nö hüperhooldust ehk
suurendatud järelevalvet LIVE-s tuvastatud esmaste vaegtööde lahenduseks, mille käigus keskendutakse tarkvara stabiilsuse tagamisele, varajaste vigade ja probleemide kiirele lahendamisele ning kasutajate tagasiside integreerimisele süsteemi täiustamiseks.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
6
10.6. Pärast alametapi hüperhoolduse perioodi lõppu hakkab kehtima antud alametapi osas ühe kalendriaastane garantii periood.
10.7. Juhul kui pakkumus sisaldas pakkuja poolt pakutavaid tarkvara litsentse, peab pakkuja võimaldama litsentsiga kaetud tarkvarale ligipääsu alates LIVEst. Vastav leping sõlmitakse enne LIVE ja hakkab kehtima LIVE kuupäevast.
11. Testimine 11.1. Enne töö üleandmist viib Täitja töö nõuetelevastavuse kindlakstegemiseks läbi testid. 11.2. Kui töö või mistahes selle osa ei läbi teste, viiakse viivitamatult pärast seda, kui Täitja on teinud
vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel tingimustel. Tellija nõudmisel viib kordustestid läbi Täitja.
12. Dokumentatsioon 12.1. Arenduste teostamisel peab Täitja koostama dokumendi(d), millede eesmärgiks on anda selge ja
konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest. 12.2. Eraldiseisvaid dokumente üle ei anta vaid Tellija keskkonda kirjutatakse analüüsi jooksvalt projekti
käigus. 12.3. Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust. 12.4. Üle antavad dokumendid peavad sisaldama:
12.4.1. Infosüsteemi terviku kirjeldus – olemasoleva süsteemi täiendamisel lisatud/muudetud osade kirjeldus. Tegemist on süsteemi ärisisul põhinevate baaskomponentidega, millele toetuvad kasutaja tegevused, ekraanivormid, kasutuslood/protsessid, teenused jms;
12.4.2. Vormide (ekraanivormide) kirjeldused; 12.4.3. Kasutuslugude / vormide kasutamise protsesside / tegevuste kirjeldused.
12.5. Infosüsteemi teenuste kirjeldused. 12.6. Juurutuse faasis ja lõpus peab Täitja esitama arhitektuuri kirjeldus dokumendi, mille eesmärgiks
on kirjeldada loodava ja/või juurutatava süsteemi tehnilist ülesehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise.
12.7. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest.
12.8. Täitja sisemiste koosolekute eest, mille töötunde esitatakse Tellijale tasumiseks, peab Täitja koostama ja esitama ülevaatliku memo, mis peab sisaldama vähemalt järgmist infot:
12.8.1. Koosolekul osalenud isikute nimekiri; 12.8.2. Koosoleku eesmärk ja arutatavad teemad; 12.8.3. Koosolekust projektile tekkiv väärus või mõju; 12.8.4. Põhiotsused ja järgmised sammud (kui rakendub); 12.8.5. Koosoleku kuupäev ja kestus.
Memo eesmärk on tagada tööde läbipaistvus ning võimalus hinnata koosoleku asjakohasust projekti täitmise seisukohast. Ilma nõuetekohase memota ei ole Täitjal õigust esitada Tellijale arvet nende töötundide eest.
13. Garantiitingimused 13.1. Täitja garanteerib tööde vastavuse lepingule ja seadusega sätestatud töövõtu tingimustele,
tarkvara kirjeldusele ning tellija põhitegevuse tavapärastele ja mõistlikele nõuetele kokkulepitud aja jooksul pärast tööde vastuvõtmist tellija poolt.
13.2. Täitja tagab garantii perioodiks 12 (kaksteist) kuud, mis algab tööde kogumina vastuvõtmisest. 13.3. Garantii korras vea parandamine hõlmab kõigi tarkvara osade, sealhulgas abistava
dokumentatsiooni parandamist või muutmist.
14. Nõuded projektiplaanile 14.1. Pakkumuse osana esitatakse tarkvara arenduse projektiplaan, mis sisaldab ajakava (tegevuste
ajalist kestvust) kõikide funktsionaalsuste loomiseks ja vajalike tööde läbiviimiseks. 14.2. Projektiplaanis peab olema selgelt eristatavad tööde etapid ning vajadusel jätku ja/või muud
tegevused. Tegevused peavad olema välja toodud nädala täpsusega. Projektiplaan peab olema koostatud arvestusega, et kõik hanke alusdokumentides nimetatud arendusega seotud tegevused oleks teostatud ja kogu lahendus kasutatav eelduslikult 01.10.2026.
14.3. Pakkumuses esitatav projektiplaan peab vastama järgmistele tingimustele:
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
7
14.3.1. projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud projekti eesmärk ja soovitud funktsionaalsus;
14.3.2. iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) sh vastutaja roll/nimi, ajaline kestus töötundides või tööpäevades ja tähtaeg vastavalt tööde mahule;
14.3.3. projektiplaanis peavad kajastuma töö tegemiseks vajalikud eeldused/lähteandmed ning töö mõõdetav(ad) tulem(id). Projektiplaan peab sisaldama mh. tööde ajalist kestvust.
14.3.4. kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud; 14.3.5. projektiplaan peab sisaldama varuaega (puhvrit) arvestades riiklike pühade,
puhkepäevade, projektimeeskonna puhkustega/vahetustega ja muu taolisega; 14.3.6. Projekti ajakohastamine toimub vaid poolte kirjalikul kokkuleppel.
14.4. Pakkuja peab kirjeldama, kuidas ta kavatseb maandada tarkvara arenduse projekti realiseerimise riske (HD Lisa 3).
14.5. Projektiplaan ja riskide maandamise plaan esitatakse Exceli kujul. Pakkuja võib lisaks pakkumusse lisada projektiplaani Microsoft Project formaadis.
15. Nõuded meeskonnale 15.1. Juhul, kui Täitja ei ole tooteomanik, kui tootja, peab Täitja kaasama läbiviidavatesse analüüsi
töötubadesse ka tooteomaniku, kui tootja esindaja, et tagada: 15.1.1. nõuetele vastavus ja toote funktsionaalne terviklikkus; 15.1.2. funktsionaalsuste ja tehniliste piirangute korrektne tõlgendamine; 15.1.3. süsteemi arhitektuuri ja konfiguratsioonipõhimõtete kinnitamine; 15.1.4. analüüsi tulemuste vastavus tarkvara tegelikele võimalustele; 15.1.5. hilisemate arenduste ja seadistuste valideerimine tootja pädevuse alusel.
15.2. Pakkuja peab raamlepingu täitmiseks komplekteerima piisava suurusega meeskonna, et oleks tagatud vajalik ning asjakohane inimressurss kogu arenduse ja juurutusperioodiks, kuid ka tugi- ja hooldusteenuse osutamiseks ja lisaarenduste tellimiseks.
15.3. Kõik meeskonnaliikmed peavad olema kättesaadavad projekti jooksul. 15.4. Kõik meeskonna rollid peavad olema lepingu kestel kaetud ja kättesaadavad vastavalt lepingus
kokkulepitud ulatusele. Kui mõne rolli täitja vahetub, peab Täitja teavitama Tellijat rollis oleva liikme asendamisest kirjalikult vähemalt 5 tööpäeva ette. Rolli ajutine või püsiv katmata jätmine on lubatud üksnes juhul, kui Tellija on selleks andnud eelneva kirjaliku nõusoleku.
15.5. Pakkuja asendab töid teostava isiku viivitamatult Lepingu eseme täitmise seisukohast võrdväärse kvalifikatsiooni ja kogemustega ning hankijale vastuvõetava isikuga, kui nimetatud töid teostav isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine pidevalt kahjustab raamlepingu korrektset ja õigeaegset täitmist.
15.6. Tellija ei ole kohustatud tasuma Täitja töötajate väljaõppe, sisseelamise ega koolitamisega seotud töötundide eest. Juhul kui Täitja vahetab projekti rollis oleva isiku, peab uus töötaja omandama vajalikud teadmised ja projektiga seonduva info Täitja enda kulul. Tellija ei tasu töötundide eest, mis on seotud:
15.6.1. uue töötaja koolitamise või väljaõppega; 15.6.2. projekti teemadega tutvumisega (sh dokumentatsiooni läbilugemine); 15.6.3. Täitja sisese duubeldamise või varjutamisega koosolekutel (nt olukord, kus uus või noorem
konsultant osaleb koosolekul ilma Tellijale lisaväärtust loomata). Sellised tunnid ei kuulu arveldamisele ja neid ei või Tellijale esitada sõltumata sellest, kas Täitja märgib need sisemiselt projekti tööajaks või mitte.
15.7. Arendusmeeskonna liikmetel peab olema varasem kogemus pakutava lahenduse juurutamisel (alates lahenduse analüüsist kuni juurutatava tarkvara kasutuselevõtuni). Meeskonna tööd koordineerib projektijuht, kelle suhtluskeel on eesti keel, sh peavad eesti keelt valdama B2 tasemel spetsialistid, kes on Tellijaga otsesuhtluses.
15.8. Pakkuja kannab kõik nimetatud asendusest tulenevad või sellega kaasnevad kulud. 15.9. Pakkuja meeskonna poolt täidetavad rollid on esitatud alljärgnevalt, kusjuures üks spetsialist ei
tohi katta mitte rohkem kui kahte rolli. 15.10. Projektijuht, kes korraldab suhtlust arendusmeeskonna ja hankija kontaktide vahel ning
vastutab lepingu igapäevase täitmise eest, sealhulgas: 15.10.1. koostöös tellijaga koostab ja jälgib arenduste teekaarti (sh ajakava, riskid); 15.10.2. korraldab ja juhib arenduste planeerimise ja retroperspektiivi koosolekuid; 15.10.3. korraldab ja juhib projektimeeskonna teisi korralisi koosolekuid;
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
8
15.10.4. juhib ja korraldab arendusmeeskonna igapäevatööd; 15.10.5. küsib tellija poolset tagasisidet ja lahendab sealt ülesse kerkinud probleeme; 15.10.6. korraldab tarkvara hooldamise ja toe pakkumise protsesse; 15.10.7. korraldab intsidentide ja probleemide lahendamise vastavalt lepingutingimustele; 15.10.8. korraldab tööde üleandmise ja arveldamise, planeerib tööde üleandmise tellijale
ning veendub enne üleandmist nende vastavuses tellija soovidele; 15.10.9. koostab ja esitab tellijale projekti aruandluse ning korraldab infovahetuse tellijaga. 15.10.10. Projektijuhil peab olema vähemalt 3-aastane kogemus tarkvaraprojektide juhtimisel
avalikus sektoris või samas mahuklassis erasektoris. 15.11. Arhitekt, kes kooskõlastab kõik suuremad arendustööd ja seisab selle eest, et
tarkvara arendatakse vastavalt baastoote loogikale ja arendussuunistele, sealhulgas: 15.11.1. töötab välja koostöös tellijaga tarkvara arhitektuuri (komponendid, andmestruktuurid,
algoritmid) ning suhtlusprotokollid teiste süsteemide ja kasutajatega; 15.11.2. vaatab üle suuremad muudatused teenustes ning uut tüüpi teenusesoovid ning liidesed; 15.11.3. vaatab üle muudatused andmemudelis; 15.11.4. otsustab ja kooskõlastab tellijaga kasutusele võetavad tehnoloogiad; 15.11.5. teeb ettepanekuid paremateks lahendusteks tarkvaras; 15.11.6. kirjutab tarkvara koodi ja andmelaadimise tingimused; 15.11.7. teostab koodi ülevaatust.
15.12. Analüütik/konsultant, kes kirjeldab kasutajate vajadused, seadistab süsteemi ja loob vajadusel lähteülesande arendusteks, sealhulgas:
15.12.1. analüüsib, millised on ärilised vajadused töö käigus väljatöötatavate lahenduste taga ning millised on lahenduste toimimiseks vajalikud ärilised protsessid;
15.12.2. analüüsib tellija soove ja vajadusi seoses tarkvaralahendusega ja formuleerib vajadused ning nõuded süsteemile;
15.12.3. töötab välja vajadustele vastavad lahenduste kavandid või täiendamisvajadused olemasolevas tarkvaras;
15.12.4. loob ärilistele vajadustele vastavad prototüübid; 15.12.5. tunneb tarkvara funktsionaalsust ning konsulteerib vajadusel peakasutajaid; 15.12.6. kaardistab ja dokumenteerib süsteemide ja süsteemi osade vahelised liidesed; 15.12.7. koostab lähteülesandeid arendusteks ja tehnilise dokumentatsiooni. 15.12.8. Analüütik peab omama varasemat kogemust palga- ja personali (HRM) valdkonna
lahenduste analüüsimisel ja seadistamisel. 15.12.9. Konsultandil peab olema vähemalt 2-aastane kogemus Microsoft Business Centrali või
samaväärse ERP-süsteemi personalimooduli kasutuselevõtul ning ta peab omama HRM4 Baltics toote ametlikku sertifikaati.
15.13. Arendaja, kes teostab vastavalt lähteülesandele ja MS Dynamicsi arendussuunistele kliendispetsiifilised eriarendused, sealhulgas:
15.13.1. hoolitseb selle eest, et tarkvara andmebaas, komponendid ja liidestused erinevate infosüsteemide vahel kõik omavahel hästi töötaksid;
15.13.2. konsulteerib konsultante/analüütikuid vajadustele vastavate lahenduste variantide osas; 15.13.3. kirjutab tarkvara koodi; 15.13.4. kirjutab automaattestid; 15.13.5. teostab koodi ülevaatust. 15.13.6. Arendajal peab olema vähemalt 2-aastane kogemus Business Centrali (AL-keele) arenduses
ning ta peab omama HRM4 Baltics toote ametlikku sertifikaati, mis kinnitab pädevust konkreetse toote laienduste ja integratsioonide loomisel.
15.14. Testija/dokumenteerija, kes dokumenteerib nõuetekohaselt teostatud arendused ja testib nende toimimist, sealhulgas:
15.14.1. loob testjuhtumid valminud lahenduste testimiseks; 15.14.2. genereerib vajadusel testandmed loodud lahenduste testimiseks; 15.14.3. testib tarkvara; 15.14.4. loob ja täiendab testlugusid; 15.14.5. loob kasutusjuhendeid; 15.14.6. teostab kasutajate konsulteerimist ja koolitamist; 15.14.7. võib kirjutada kasutajaliidese automaat-teste. 15.14.8. Testijal peab olema kogemus ERP-lahenduste testimise metoodikate ja
kvaliteediprotsesside rakendamisel.
Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“
Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus
9
15.15. Hankija meeskonda kuuluvad arendusprojekti projektijuht, peakasutajad, IT tooteomanikud, analüütikud, arhitektid, tehnilised konsultandid.
15.16. Juhul, kui Täitja ei ole tooteomanik, kui tootja, siis on Hankijal õigus kaasata tooteomaniku, kui tootja, esindaja olulisemaid projekti etappe ja mahte sõltumatu osapoolne valideerima.
Arendusnõuded Avalikustamine: RMK sisene teave
Teavet ei ole lubatud jagada kolmandate osapooltega, v.a juhul, kui selleks on õiguslik alus ja/või see on vajalik tööprotsesside toimimiseks.
Avalikustamise lisainfo: “Arendusnõuded (MFN)” lisatakse tarkvara arendamise, hankimise ja juurutamise hangete korral hankedokumen de juurde, v.a dokumendi punk s 2.1 viidatud “RMK Töö- ja koodihaldus” ja punk s 5 viidatud “Logimise spetsifikatsioon”, mis väljastatakse hanelepingu sõlmimise järel ning punk s 2.3 viidatud “Eelistatud tehnoloogiate nimekiri”, mis väljastatakse konfidentsiaalsusleppe (NDA) või hankelepingu sõlmimise järel. Riigihangete portaali hankedokumen de juurde koos “Arendusnõuded (MFN)” dokumendiga neid vaikimisi ei lisata.
Sisukord Arendusnõuded ...................................................................................................................................... 1
1. Ülevaade ja skoop ........................................................................................................................... 2
2. Üldnõuded ...................................................................................................................................... 2
2.1 Töö- ja koodihaldus ................................................................................................................... 2
2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release ............................................................ 2
2.3 Platvorm .................................................................................................................................... 3
2.4 Koodi kvaliteet ja arendusprotsess ........................................................................................... 3
2.5 Dokumenteerimine ................................................................................................................... 4
2.6 Haldus ....................................................................................................................................... 4
2.7 Välised sõltuvused .................................................................................................................... 5
2.8 Muud üldised nõuded ............................................................................................................... 5
3. Frontend nõuded (UX/UI) ............................................................................................................... 5
3.1 Tehnilised .................................................................................................................................. 5
3.2 Kasutuskogemus ....................................................................................................................... 6
4. Backend nõuded (API/teenused) .................................................................................................... 7
4.1 Konfiguratsioon ja deploy ......................................................................................................... 7
4.2 API disain ja dokumentatsioon ................................................................................................. 7
4.3 Töökindlus ja monitooring ........................................................................................................ 7
4.4 Koodistruktuur ja arendus ........................................................................................................ 8
4.5 Integratsioon ............................................................................................................................. 8
5. Logimine .......................................................................................................................................... 8
6. Andmebaasi ja andmetöötluse nõuded .......................................................................................... 9
6.1 Üldpõhimõ ed .......................................................................................................................... 9
6.2 Iden fikaatorid ja audit ............................................................................................................. 9
6.3 Platvorm ja tööriistad................................................................................................................ 9
6.4 Turvalisus ja juurdepääs ............................................................................................................ 9
7. Turvanõuded ................................................................................................................................. 10
7.1 Üldised põhimõ ed ................................................................................................................ 10
7.2 Sessioonid ............................................................................................................................... 10
7.3 Lähtekood ja arendusvahendid ............................................................................................... 10
9. Hooldatavus ja toetatavus ............................................................................................................ 11
1. Ülevaade ja skoop Käesolev dokument kirjeldab kuidas RMK-s arendatakse, hangitakse ja juurutatakse tarkvara. See hõlmab nii tarkvara arendust kui ka karbitoodete ja SaaS (So ware as a Service) teenuste kasutusele võ u. Nõuded ei kirjelda ärifunktsionaalsust.
Dokumendis viidatakse ka teistele välistele dokumen dele, mis moodustavad käesoleva dokumendiga ühtse terviku.
2. Üldnõuded
2.1 Töö- ja koodihaldus Kõik tööd peavad olema kirjeldatud pile na RMK JIRA-s. Täpsemad JIRA ja versioonihalduse
kasutamise nõuded on kirjeldatud dokumendis „RMK Töö- ja koodihaldus“(välisele arenduspartnerile väljastatakse dokument peale hankelepingu sõlmimist).
Git repod: RMK kood asub Azure DevOps repodes.
2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release Lokaalne käivitus: Rakendused peavad olema lokaalselt käivitatavad ilma väliste
sõltuvusteta. Vajalikud sõltuvused peaksid olema lokaalselt käivitatavad Docker Compose-i konteineriga. Välised sõltuvused(API-d) võivad olla mockitud. Rakenduse käivitamiseks ja tes miseks vajalikud andmed peavad olema rakenduses seadistatud. Peale käivitamist peab olema rakendus kasutatav. Rakenduse Vajalikud käsud ja sammud rakenduse lokaalseks käivitamiseks peavad olema välja toodud koodi repos README.md failis.
Koodi formaadi kontroll: koodi formaadi kontroll peab olema build protsessi osa. Kood peab vastama RMK-s kokku lepitud formaadile.
Staa line analüüs: staa line analüüs(nt Sonar) peab olema build protsessi osa selliselt, et kui kvaliteedi lävendit ei ületata, siis build ei õnnestu. Uus kood ei tohi tekitada juurde Sonari vigu. Lokaalselt seda sammu ei ole(võimalusel kasutada Sonarit IDE pluginana, või minna eraldi Sonari liidesesse ja kontrollida vigasid).
Tes mise üldnõuded: vt peatükk 9.
Release strateegiad: kasutusel võivad olla erinevad väljalaskmise mustrid (nt blue-green, canary). Täh s on, et uue versiooni kasutuselevõ oleks kontrollitud ja võimaldaks vajadusel kiiret tagasipööramist.
Produc on ressursivajadus: arendusmeeskonna ülesanne on tes da rakenduse jõudlust ja selle põhjal teha e epanek rakenduse ressursivajaduse kohta produc on keskkonnas, mis on sisendiks haldusosakonnale.
2.3 Platvorm Versioon: Ükskõik mis programmeerimiskeelte, raamis ke või teekidega infosüsteeme
realiseeritakse, keh b sama põhimõte: ala kasutatakse kas viimast LTS(Long Term Support) versiooni, või selle puudumisel viimast stabiilset versiooni. Kui arendustöö käigus tuleb uus LTS versioon välja, siis see uuendatakse kohe ära, kui ei esine seda takistavaid asjaolusid.
Eelistatud tehnoloogiate nimekiri: Nimekiri programmeerimiskeeltest, raamis kest, teekidest ja nende versioonidest, mida võib ilma täiendava kooskõlastamiseta kasutada on kirjeldatud dokumendis „Eelistatud tehnoloogiate nimekiri“(välisele arenduspartnerile väljastatakse dokument riigihanke käigus NDA alusel või peale hankelepingu sõlmimist). Juhul kui on soov kasutada midagi muud, siis tuleb see valik kooskõlastada RMK tarkvaraarhitek ga.
Keskkond: backend, frontend ja andmebaasid töötavad Azure pilvekeskkonnas.
CI/CD: kasutatakse Azure CI/CD. Build protsessi osana käivitatakse koodi formaadi kontroll, staa line analüüs, tes d.
Sõltuvused: kasutatakse ainult toetatud ja turvauuendusi saavaid teeke.
Skaleeruvus: rakenduste arendamisel peab arvestama võimalusega, et need jooksevad mitme õla peal.
Docker: rakendus peab olema tarnitav Dockeri konteineritena.
2.4 Koodi kvaliteet ja arendusprotsess Põhiharu kvaliteet: main haru peab ala olema tes tud ja valmis produc on keskkonda
paigaldamiseks.
Sisendi valideerimine: kõik kasutajalt või teistest süsteemidest tulevad sisendid valideeritakse. Kui rakendusel on nii kliendi- kui serveripool, toimub valideerimine mõlemas komponendis. Samu rakendatakse valideerimist teistes integratsioonipunk des(andmebaas, välised liidesed).
Väljundandmete kontroll: Rakenduse poolt kasutajale või teisele süsteemile väljastatavad andmed peavad olema õiges vormindatud, äriliselt korrektsed ja turvalised.
o Formaadi kontroll: kõik väljastatavad väärtused vastavad kokkulepitud skeemile või standardile. Näiteks kuupäevad esitatakse ISO 8601 formaadis (2025-09-
02T12:00:00Z), rahasummad kahe komakohaga, ning API vastus vastab OpenAPI kirjeldatud struktuurile.
o Äriline korrektsus: väljastatav info järgib ärireegleid ja loogikat. Näiteks ei väljastata nega ivset saldo väärtust, kui süsteemi reeglid seda ei luba; ID viitab ala reaalselt olemasolevale kirjetele; staatuse väljad sisaldavad ainult eeldefineeritud väärtusi.
o Turvalisus: väljund ei tohi sisaldada tundlikke või sisemisi andmeid, mida kasutaja või partner ei pea nägema (nt paroole, võtmeid, sisemisi tehnilisi tunnuseid). Teks d peavad olema korrektselt escape’itud, et väl da XSS või sarnaseid ründeid. Logidesse ei tohi sa uda täielikud isikuandmed ega salajased iden fikaatorid.
Staa line koodianalüüs: kasutatakse staa list koodianalüüsi(Sonar); kõrge prioriteediga turvavead tuleb lahendada enne live keskkonda paigaldamist. Kõik Sonari vead vaadatakse enne arenduse üleandmist üle, vead mida ei peeta otstarbekaks parandada kooskõlastatakse RMK tarkvaraarhitek ga.
Kompilaatori hoiatused: build-i hoiatused ja staa lise analüüsi tulemused vaadatakse üle ja arvestatakse.
Kiirlahenduste väl mine: ei kasutata tes mata lahendusi, mis eiravad häid prak kaid või RMK nõudeid.
Tes mise põhimõ ed: vt peatükk 9.
2.5 Dokumenteerimine Dokumentatsiooni põhielemendid:
o süsteemi funktsionaalne ja tehniline kirjeldus,
o kasutatavad liidesed (API-d, integratsioonid),
o perioodilised tööd (schedulerid, batch-protsessid),
o arenduskeskkonna seadistamine
o andmebaasi struktuuri kirjeldus (tabelid, seosed, migratsioonid),
o keskkonnad ja paigaldus
o peamised hooldustegevused (nt logide ülevaatus, varunduse kontroll, sõltuvuste uuendamise tsükkel)
Dokumentatsiooni asukoht: RMK Confluence keskkond
Diagrammid: süsteemi arhitektuuri ja komponente visualiseeritakse eelistatult PlantUML või Mermaid formaadis.
Arhitektuur: iga süsteemi kohta peab olema arhitektuuriülevaade, sealhulgas API spetsifikatsioonid (nt OpenAPI).
2.6 Haldus Tehniline võlg: arenduse käigus tuleb dokumenteerida teadaolevad piirangud ja tehniline
võlg (nt TODO-d, aju sed lahendused) ning soovitused nende likvideerimiseks.
Sõltuvuste ja platvormi uuendused: arenduse käigus tuleb kirjeldada süsteemi kaasaegsena hoidmise strateegiat (nt milliseid raamis kke ja teeke tuleb regulaarselt uuendada, millal tuleb planeerida üleminek LTS-versioonidele).
Monitooringu vajadused: tarnija peab kirjeldama arendatava süsteemi monitooringu aspek d (nt vealogid, jõudlusmõõdikud, integratsioonide toimivus, job scheduler-i töö).
Teavitused: tarnija peab defineerima soovitatud häirete künnised (nt kui API annab vea, kui mingi protsess ei lõpeta näiteks 15 minu ga).
Elutsükli planeerimine: tarnija peab andma hinnangu, millised tehnoloogiad või komponendid võivad lähiaastatel vajada moderniseerimist või väljavahetamist.
Andmete säilitustähtajad: kui süsteemis talletatakse andmeid, millel on määratud säilitustähtaja (vastavalt teabe liigitusskeemile Jira Asse s), tuleb see dokumenteerida. Dokumentatsioonis peab olema kirjeldatud, millised andmed kustutatakse automaatselt, millal ja kuidas.
2.7 Välised sõltuvused Teekide kasutamine: kasutada ainult laialdaselt toetatud ja turvauuendusi saavaid teeke.
Sõltuvuste miinimum: sõltuvusi hoitakse minimaalsena, et vähendada turvariske ja halduskoormust.
Litsentsid: sõltuvuste litsentsi ngimusi, turvalisust ja ajalugu hinnatakse; eelistatakse vabavaralisi komponente.
Jätkusuutlikkus: hinnatakse teekide jätkuarenduse ja toe kä esaadavust. Vajadusel analüüsitakse mõju RMK protsessidele, kui komponendi arendus lõpeb.
Ühilduvus: analüüsitakse kasutatavate komponen de ühilduvust teiste süsteemidega.
2.8 Muud üldised nõuded Kodeering ja locale: kogu süsteemis (lähtekoodis, andmebaasis, jne) kasutatakse UTF-8
kodeeringut; vaikekeel on et-EE (laiendatav i18n); ajatsoon on UTC (UI-s kohalik aeg).
3. Frontend nõuded (UX/UI)
3.1 Tehnilised Tehnoloogia: kui rakenduse nõuded võimaldavad siis eelistame serveris renderdatud HTML-i
(Thymeleaf, HTMX).
Raamis kud: kui kasutatakse mingit raamis kku, siis eelistame laialdaselt toetatud raamis kku (nt React, Angular või Vue).
Raamis ku versioon: projek s kasutatavad raamis kud peavad olema toetatud ja saama turvauuendusi.
Build: sõltuvused hallatakse pake halduriga, arvestades kasutatavat tehnilist lahendust:
o SPA: npm / yarn / pnpm (lock fail versioonihalduses; build deterministlik).
o Java SSR (Server-Side Rendering nt Thymeleaf): Gradle (või Maven) hoiab nii backendi kui frontendi build-i .
o PHP SSR: Composer.
o Python SSR: pip. Build peab olema deterministlik ja versioonitav (lock failid, build-config git-s).
Keskkonnaspetsiifilised seaded: hoitakse välises konfiguratsioonis (nt .env).
API kasutus: kõik API-päringud käivad läbi konfiguratsiooni alusel määratud lõpp-punk de; otselinke koodis ei kasutata.
Turvalisus: tundlikke andmeid ei salvestata brauseri püsivasse vahemällu (LocalStorage, SessionStorage) ilma krüpteerimiseta.
Jõudlus: rakendus peab laadima mõistliku aja jooksul – esmase laadimise vaikimisi nõue on 2s. Täpsem kontekst (nt mõõdik, tüüpiline seade ja võrguolud) lepitakse projek alguses kokku ja fikseeritakse rakenduse/projek dokumentatsioonis. Pildid, skrip d ja s ilid peavad olema op meeritud (lazy load, cache, minify).
Telemeetria: krii lised kliendipoolsed vead (JavaScript errorid, katkised API päringud) peavad jõudma tsentraalsesse monitooringusse.
3.2 Kasutuskogemus Reageeriv(responsive) disain: rakendus peab olema kasutatav erineva ekraanisuurusega
seadmetel (desktop, mobiil, tahvel).
Navigatsioon: menüüd ja liikumisloogika on rakenduse eri vaadetes ühtsed. Sama funktsionaalsus on ala leitav samast kohast.
Nuppude paigutus ja järjestus: sama tüüpi tegevused (nt “Salvesta”, “Tühista”) paiknevad ala samas järjekorras ja paigutusega.
Veateated: esitatakse ühtses formaadis (struktuur, sõnastus, värvilahendus). Teated on arusaadavad ja ei sisalda tehnilist müra. Veateated ei sulgu automaatselt, et kasutajal oleks võimalik neid adekvaatselt edastada toe saamiseks.
Kinnitused ja dialoogid: riskantsete tegevuste (nt kustutamine, lõplik kinnitamine) puhul küsitakse ala kinnitust. Dialoogid järgivad sama s ili ja loogikat.
Abiteks d ja juhendid: tool pid, sisestusväljade placeholderid ja abiteks d on s ililt ja positsioonilt ühtsed. Kõik väljad ja tegevused on varustatud abiteks ga, mis aitab kasutajal mõista, mis juhtub enne kui ta midagi teeb.
Laadimise tagasiside: pikemate tegevuste puhul (nt päring serverisse, faili üleslaadimine) peab kasutaja nägema visuaalset indikaatorit (spinner, progress bar).
E eaimatavus: süsteemi käitumine peab olema selge ja ootuspärane – väldime olukorda kus kasutaja peab mõtlema „mis siis juhtub, kui ma siia vajutan“. Tegevuste tagajärjed on nähtavad või selgitatud enne sooritamist.
Ikonograafia ja sümbolid: sama tegevuse tähistamiseks kasutatakse ala sama ikooni ja tähendust.
S il ja kujundus: värvipale , kirjatüübid ja komponen de kujundus vastavad ühtsele disainisüsteemile või s ilijuhendile.
Klahvikombinatsioonid ja kiirtoimingud (kui rakendatud): töötavad järjepidevalt kõigis vaadetes.
Terminoloogia: teks d ja nimetused (nt “kasutaja”, “konto”, “fail”) on järjepidevalt samad kogu rakenduses.
Andmete sisestuse valideerimine: sisestusväljade puhul kasutatakse valideerimist enne serverisse saatmist, et ilmseid vigu kasutajale kiiremini esile tuua.
4. Backend nõuded (API/teenused)
4.1 Konfiguratsioon ja deploy Seadistused: keskkonnaspetsiifilised väärtused hoitakse rakendusest väljas (Azure Key
Vault, keskkonnamuutujad), aga konfiguratsioon ise on koodi juures vastavates failides.
Konfiguratsioon: konfiguratsioon on versioneeritav ja muudatused jälgitavad.
Ehitamine: Java projek de ehitamisel eelistatakse Gradle-t.
4.2 API disain ja dokumentatsioon Versioonimine: REST/HTTP liidesed on versioonitud (nt /v1). Dokumentatsioon: kõik REST/HTTP liidesed peavad olema dokumenteeritud nii, et
partneritel ja RMK-l on võimalik neid kasutada ja tes da. Dokumentatsiooni võib teha erineval viisil (nt kirjalik juhend, Postman collec on, README näidised). Soovitatavalt kasutatakse masinloetavat standardit OpenAPI ja sellest genereeritud Swagger liidest.
Asukoht: kui kasutatakse OpenAPI/AsyncAPI dokumentatsiooni, peab vastav fail asuma samas Git repo-s koos lähtekoodiga, et see oleks ala koodiga kooskõlas.
Koormuse juh mine: kasutatakse mehhanisme ülekoormuse väl miseks (nt rate limi ng, thro ling).
Veakäsitlus: veateated on standardiseeritud, inimloetavad ja ei sisalda tundlikku sisemist infot.
Sisend, väljund: API sisend ja väljund peab jälgima REST põhimõ eid (h ps://res ulapi.net/).
Protokoll, formaat: kasutatakse HTTP protokolli ja API väljund on JSON, välja arvatud binaarfailide puhul.
4.3 Töökindlus ja monitooring Health-checkid: rakendus peab pakkuma health-check ja readiness liideseid(Spring Boot
Actuator).
Observability: rakendused edastavad minimaalselt request count, response me, error rate mõõdikuid Azure Monitori(Micrometer)
API töökindlus: API peab olema kasutatav (vastab päringutele) ja enamus päringuid peab lõppema mõistliku aja jooksul ning ilma veata. Täpsemad jõudluse või töökindluse eesmärgid määratakse projek põhiselt.
Tes mine: Integratsiooniteste ja end-to-end teste võib kirjutada. Nende puudumisel tuleb enne release-i teha regressioonites mist käsitsi.
4.4 Koodistruktuur ja arendus Struktuur: Java projek des kasutatakse kihipõhist package struktuuri, kus komponendid on
jaotatud package-tesse tehnilise rolli järgi (nt controllers, services, repositories). Perioodilised tööd: kõik schedulerid, batchid ja stored procedures dokumenteeritakse
README-s. Perioodiliste tööde käivitamine eraldi klassis äriloogikast. Automaatne andmete kustutamine: kui süsteemis on andmeid, millel on määratud
säilitustähtaja (vastavalt teabe liigitusskeemile), tuleb rakendada automaatne kustutamise funktsionaalsus. Automaatne kustutamine toimub perioodilise tööna (scheduler, batch), mis kontrollib andmete vanust ja kustutab andmeid, mis on ületanud säilitustähtaja. Kustutamise protsess peab olema logitud.
Teenusklassid: äriloogika peab olema realiseeritud Service kihis, mille sisendiks ja väljundiks on domeeniobjek d. Teenuseklassi tes deks on unit tes d.
Kontrollerid: Kontrollerite tes d tuleb kirjutada kasutades MockMvc raamis kku, kus teenuste kihi vastused on mockitud.
Presentatsioonikiht: presentatsioonikiht ei tohi kasutada sisendiks ja väljundiks domeeniobjekte, vaid eraldi Request ja Response ressursse.
Autoriseerimine: päringute autoriseerimine peab toimuma kontrollerite kihis. Tes mine: koodi unit tes de haru-ka uvus(branch coverage) peab olema 80%. Unit tes d
tuleb jooksutada CI/CD süsteemis iga buildiga uues . Build peab katki minema, kui tes d pole edukad. Repository (ja messaging) kihi tes d tuleb kirjutada integratsioonites dena vastu mockitud (nt rest apid) või konteineris jooksva päris välise süsteemi vastu (näiteks rakenduse Postgres baas TestContainers abil). Iga test hoolitseb ise oma testandmete loomise ja esialgse seisu taastamise eest. Erinevates tes des samade andmete kasutamine ei ole lubatud.
Koodistandard: vaikimisi kasutatakse Google Java koodistandardit, mille kontrollimine on osa buildist.
4.5 Integratsioon Andmebaasid, välised liidesed: andmebaasi ja teiste väliste andmete küsimine peab olema
lahendatud eraldi repository kihis, mis väljastab äriloogika kihile ainult domeeniobjekte.
Sõnumid, even d: even de saatmine ja vastuvõtmine peab olema realiseeritud äriloogikast eraldi consumerites ja producerites.
5. Logimine Logimisnõuded on kirjeldatud dokumendis „Logimise spetsifikatsioon“.
NB! Välisele arenduspartnerile väljastatakse “Logimise spetsifikatsioon” dokument peale hankelepingu sõlmimist.
6. Andmebaasi ja andmetöötluse nõuded
6.1 Üldpõhimõ ed Andmete terviklikkus: kõik andmebaasi struktuurid (tabelid, seosed, indeksid) peavad
tagama andmete terviklikkuse ja väl ma duplikaate või orvuks jäänud kirjeid.
Normaliseeritus: andmemudel peab olema vähemalt 3. normaalkujus või põhjendatult denormaliseeritud (näiteks jõudluse kaalutlustel).
Järjepidevus: andmete formaat ja tähistus (nt kuupäevad, valuutad, staatuse väljad) peab olema ühtne kogu süsteemis.
Äriloogika: relatsioonilisse baasi tuleb suhtuda kui andmete hoidlasse, äriloogika peab olema implementeeritud rakenduskihis. Stored procedure kasutamine ei ole lubatud.
6.2 Iden fikaatorid ja audit Primaarvõtmed: numbrilised ID-d on eelistatud, mi e UUID, välja arvatud kui on tehniline
vajadus globaalseks unikaalsuseks.
Auditväljad: igas tabelis, kus toimub andmete muutmine, peavad olema väljad created_by, created_at, modified_by, modified_at. Ajatemplid (created_at, modified_at) on vajalikud ka andmete automaatseks kustutamiseks vanuse järgi.
Kustutuse logimine: kõik andmete kustutamise operatsioonid (nii automaatsed kui käsitsi) peavad olema logitud koos kustutatud andmete tüübi, kustutamise ajaga, põhjuseks ja tegijaga (süsteem või kasutaja).
Auditlogi või event sourcing: kasutatakse sõltuvalt süsteemi iseloomust ja ärivajadusest.
6.3 Platvorm ja tööriistad Andmebaasi tarkvara: RMK eelistatud andmebaas on PostgreSQL. Arenduse ja tes mise
eesmärgil võib kasutada ka mäluandmebaase (nt H2, SQLite3).
Migratsioonid: kõik struktuurimuudatused hallatakse migratsioonitööriistadega ja versioonihalduses (soovitatavalt Flyway). Käsitsi tehtud muudatused ei ole lubatud, välja arvatud erandkorras ja RMK-ga eelnevalt kooskõlastatult. Kõik sellised muudatused tuleb dokumenteerida ja kanda tagasi migratsiooniskrip desse, et tagada keskkondade ühtsus.
6.4 Turvalisus ja juurdepääs Paroolid ja auten misandmed: salvestatakse ainult soolatud räsi kujul (nt Argon2, bcrypt,
scrypt). Lih eks na talletamine on keelatud.
Õiguste haldus: andmebaasis kasutatakse eraldi kontosid rakenduse ja haldustööde jaoks (väikseima privileegi põhimõte).
7. Turvanõuded
7.1 Üldised põhimõ ed Auten mine ja iden teet: rakendused ja kasutajad tuvastavad end RMK auten misnõuete
alusel (Entra ID, TARA väliskasutajatele).
Autoriseerimine: juurdepääs rakendustes toimub rollipõhiselt. Rollide nimetusvorming: APP- {env}-{teenus}-{roll}.
Andmete liigitus: rakenduse planeerimisel määratakse andmete tüüp ja liigitus, dokumenteeritakse nende käsitlemise alused. Säilitustähtajad määratakse vastavalt teabe liigitusskeemile Jira Asse s ja andmesäilituse teemapolii kale.
Turvaline arendus: rakenduse arendamisel järgitakse RMK dokumente Arenduse elutsükkel ja Turvaline arhitektuur.
Andmekaitse: mi eavalikud andmed kaitstakse vastavalt teabe liigitusskeemile ja andmekaitse nõuetele. Töötlemisel järgitakse keh vaid andmekaitse õigusakte, sh GDPR.
Andmevahetus: kogu andmevahetus on krüpteeritud (TLS 1.2+); kasutatakse RMK krüptograafia juhendis määratud protokolle ja vorminguid.
Auditväljad ja -logi: rakendustes logitakse, millal ja kes kirje lõi ning viima muu s (audit trail).
Saladuste haldus: kõik võtmed ja paroolid hoitakse Azure Key Vault-s, mi e lähtekoodis või konfiguratsioonifailides.
Keskkondade eraldatus: live keskkond peab olema rangelt eraldatud arendus- ja testkeskkondadest. Toodanguandmeid ei tohi kasutada arendus- ega testkeskkondades.
Vajaduspõhine ligipääs: kõik ligipääsud lähtuvad vajaduspõhimõ est (default deny).
Vähima privileegi põhimõte: kõik protsessid töötavad vähimate vajalike õigustega.
Auten mise integreerimine: kasutajate õiguseid arvestatakse läbivalt igal tasemel (UI, äriloogika, andmebaas, integratsioonid).
7.2 Sessioonid Timeout: serveripoolne sessiooni idle meout ≤ 30 minu t, absoluutne meout ≤ 12 tundi.
Sessiooni turvalisus: sessiooni ID logitakse vajadusel maskitult või räsitult.
Sessiooni lõpetamine: sessioon suletakse automaatselt, kui kasutaja logib välja või jõuab meout.
7.3 Lähtekood ja arendusvahendid Ligipääs: lähtekood asub RMK Azure DevOps keskkonnas, kus ligipääsu hallatakse projek
põhiselt.
o RMK arendajatele antakse ligipääs vajaduspõhiselt töölepingu keh vuse ajal.
o RMK töötajatele antakse ligipääs ainult vajaduse korral ja vaikimisi lugemisõigus.
o Välistele arendajatele antakse projek põhine ligipääs, mis eemaldatakse projek lõppedes.
Lähtekoodi turvalisus: tuleb väl da lubamatute funktsioonide lisamist ja tagada, et lähtekood, arendusvahendid ja teegid on kaitstud tahtmatute või pahatahtlike muudatuste eest.
Koodi kvaliteet: turvavigade automaatne analüüs (nt Sonar).
8. Hooldatavus ja toetatavus Koodistandardid: rakenduse kood peab olema ühtses s ilis, loetav ja järgitav, et ka uus
arendaja saaks töö kiires üle võ a.
Juhendite prak lisus: dokumentatsioon peab olema piisavalt selge, et uuel arendajal või administraatoril oleks võimalik süsteem kiires üle võ a.
Tes d: rakenduse põhitöövood peavad olema kaetud automaatsete tes dega. See võimaldab veenduda, et süsteemi põhifunktsioonid töötavad ka pärast muudatusi. Täpsemalt vt peatükk 9.
Runbook-d (käitamis- ja taastamisjuhendid): krii liste töövoogude ja häireolukordade jaoks peab olema lühike samm-sammuline juhend, mis kirjeldab, kuidas probleem lahendada või süsteem taastada.
Tugi ja eskaleerimine: peab olema selge, kes ja kuidas reageerib süsteemi tõrgetele ning millised on reageerimisajad erineva tõsidusega olukordades.
9. Tes mine CI/CD ja build: unit- ja integratsioonites d peavad jooksma igal ehitusel. Build peab
ebaõnnestuma, kui tes d ei ole edukad.
Peaharu: main haru peab ala olema tes tud ja valmis produc on keskkonda paigaldamiseks.
Tes de ka uvus: unit tes de haru-ka uvus (branch coverage) peab vaikimisi olema 80%. Projek - või hankepõhisel kokkuleppel võib tase olla madalam ning erand tuleb fikseerida kirjalikult.
Tes de liigid ja kasutus:
o Unit tes d: puhta loogika tes miseks, kus on konkeete sisend ja väljund. Unit tes d ei sobi tes deks, mille osaks on I/O, võrguga seotud funktsionaalsus või aeg.
o Integratsioonites d: katavad liideseid ja sõltuvusi(andmebaas, failisüsteem, MQ, REST liidesed jne)
o End-to-end tes d: katavad kasutaja töövooge (nt Playwright); vaikimisi katame E2E tes dega ainult põhitöövood.
Testandmed: iga test loob ise testandmed ja vajadusel taastab esialgse seisu; erinevates tes des samu testandmeid kasutada ei tohi.
Integreerimis- ja E2E tes d: kui neid ei ole, tuleb enne release'i teha regressioonites mine käsitsi.
Testkeskkonnad ja -andmed: tes mise käigus ei tohi kasutada toodanguandmeid arendus- ega testkeskkondades (vt 7.1).
Turva- ja jõudlustes d: tehakse projek ja vajaduspõhiselt.
Lisa 3 RMK ja OIXIO Digital AS vahelise lepingu nr 1-18/2026/25 juurde
ISIKUANDMETE TÖÖTLEMISE NÕUDED VOLITATUD TÖÖTLEJALE
(hiliseima digitaalallkirja kuupäev)
1. Üldine 1.1. Riigimetsa Majandamise Keskus (RMK) (edaspidi vastutav töötleja) edastab
OIXIO Digital AS (edaspidi volitatud töötleja) punktis 2.1 nimetatud andmed ja volitab volitatud töötlejat neid andmeid töötlema ainult juhul, kui andmete töötlemine on lepingust tulenevalt vajalik.
1.2. Käesoleva lisa eesmärk on kokku leppida volitatud töötleja õigustes ja kohustuses lepingu täitmise käigus saadud isikuandmete töötlemisel, millest pooled juhinduvad lepingu täitmisel.
1.3. Vastuolude korral lepingu ja käesoleva lisa sätete vahel tuleb juhinduda käesoleva lisa sätetest.
2. Isikuandmete töötlemise eesmärk ja kirjeldus 2.1. Vastutav töötleja kirjeldab ära isikuandmete töötlustoimingud tabelis 1, milles
sätestatakse: 2.1.1. andmete töötlemise eesmärgi/eesmärgid, milleks isikuandmeid vastutava
töötleja nimel töödeldakse; 2.1.2. andmesubjektide kategooriad, kelle isikuandmeid töödeldakse; 2.1.3. töödeldavate isikuandmete koosseisu; 2.1.4. töötlemise alused; 2.1.5. andmete säilitustähtajad.
Töötlemise eesmärk
Andmete kategooriad
Andmete koosseis Töötlemise alused Säilitustähtajad
Töösuhte haldamine, palgaarvestus, palkade välja maksmine ja maksude deklareerimine
Töölepingulised töötajad
Näiteks: ees- ja perekonnanimi, isikukood, ametikoht, tööle asumise kuupäev, töölepingu lõpetamise kuupäev, IBAN, brutopalk, maksuvaba tulu määr, töötasude ja maksude arvestus, toetuste ja hüvitiste või muu väljamaksed
GDPR art 6(1)(b), (c); Töölepinguseadus, Tulumaksuseadus, Raamatupidamise seadus, Keskmise töötasu määrus
7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele ning vastavalt töölepinguseadusele 10 või 50 aastat
Leingute haldamine, tasude väljamaksmisne ja maksude deklareerimine
RMK töötajaskond (va töölepingulised töötajad)
Näiteks: ees- ja perekonnanimi, isikukood, lepingu ese, lepingu alguskuupäev, lepingu lõpetamise kuupäev, IBAN, väljamakstava tasu liik, väljamakstav summa, maksuvaba
GDPR art 6(1)(b), (c); Töölepinguseadus, Tulumaksuseadus, Raamatupidamise seadus
7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele
tulu määr, tasu ja maksude arvestus
Kontaktandmete haldamine
RMK töötajaskond
Näiteks: e-post, telefoninumber, elukoha aadress
GDPR art 6(1)(b), (f); Töölepinguseadus
Kuni 1 aasta pärast töösuhte lõppu
Puhkuste ja tööaja arvestus
Töölepingulised töötajad, juhatuse liikmed
Näiteks: tööajaarvestuse info, puhkuste liigid ja kestus, tasu maksmise eelistus, puhkuse liigi kasutamise õigust tõendav info
GDPR art 6(1)(b); Töölepinguseadus, Keskmise töötasu määrus, Riigieelarvest hüvitamise kord
7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele
Töövõimetuse ja hoolduslehtede haldamine
Töölepingulised töötajad
Näiteks: arstitõendid, töövõimetuse algus- ja lõppkuupäevad, tööõnnetuse toimumine
GDPR art 9(2)(b); Töölepinguseadus, Ravikindlustuse seadus, Riigieelarvest hüvitatava puhkusetasu kord
7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele
Hariduse, kvalifikatsiooni ja koolituste arvestus
RMK töötajaskond
Näiteks: haridust või selle omandmaist tõendavad dokumendid, koolituste info, kutsetunnistused
GDPR art 6(1)(f); Täiskasvanute koolituse seadus, Töölepingu seadus
Kuni 1 aasta pärast töösuhte lõppu
Muud andmed, mille kogumiseks ja töötlemiseks on tööandjal õigustatud huvi
RMK töötajaskond
Näiteks: lähedased isikud, foto, tervisekontrolli andmed
GDPR art 9(2)(b); Töölepinguseadus,
Reeglina kuni 1 aasta pärast töösuhte lõppu
Töölähetuste ja kuluhüvitiste arvestus
Töölepingulised töötajad, juhatuse liikmed
Näiteks: lähetuse sihtkoht ja kestus, sõidukulud, majutuskulud, päevaraha, kuluarved
GDPR art 6(1)(b), (c); Töölähetuse kulude määrus, Raamatupidamise seadus, Liiklusseadus
7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele
Töötajate esindajate ja kollektiivsete suhete haldamine
Usaldusisikud Näiteks: usaldusisiku nimi, kontaktandmed, tasu
GDPR art 6(1)(c); Töötajate usaldusisiku seadus, Kollektiivlepingu seadus
7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele
Kutsehaiguste menetlemine
Töölepingulised töötajad, endine töötaja
Näiteks: nimi, IBAN, ametikoht, maksude arvestus vms
GDPR art 9(2)(b); Töölepinguseadus. Töötervishoiu ja tööohutuse seadus
7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele
Tabel 1. Isikuandmete töötlustoimingute tabel 3. Isikuandmete töötlemise kestus ja säilitamise nõuded 3.1. Volitatud töötleja töötleb isikuandmeid üksnes minimaalses vajalikus mahus ja lepingus
kindlaksmääratud aja jooksul, välja arvatud juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes kohalduva seaduse alusel.
3.2. Käesoleva lisa raames tuleb andmeid säilitada vastavalt tabelis 1 sätestatud ajale. Selle aja möödudes tuleb andmed volitatud töötleja süsteemidest kustutada.
3.3. Peale teenuslepingu lõppemist tuleb vastutava töötleja teave volitatud töötleja hallatavatest süsteemidest turvaliselt kustutada, küsides enne selleks vastutavalt töötlejalt kirjaliku kinnituse. Kinnituse küsimisel tuleb kirjeldada plaanitav turvalise kustutuse meetod.
4. Nõuded volitatud töötlejale 4.1. Volitatud töötleja on kohustatud kasutama ja töötlema tabelis 1 olevaid andmeid üksnes
lepingu täitmiseks ja vastutava töötleja dokumenteeritud juhiste alusel, välja arvatud juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab volitatud töötleja vastutavat töötlejat vastava kohustuse olemasolust enne teabe töötlemist, kui selline teavitamine ei ole olulise avaliku huvi tõttu volitatud töötleja suhtes kohalduva õigusega keelatud.
4.2. Volitatud töötleja peab täitma kõiki kehtivaid andmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning andmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja muid eeskirju.
4.3. Volitatud töötleja on kohustatud aitama vastutavat töötlejat järgmiste nõuete täitmise tagamisel, võttes arvesse andmetöötluse laadi ja volitatud töötlejale kättesaadavat teavet: 4.3.1. kohustus hinnata kavandatavate töötlemistoimingute mõju isikuandmete kaitsele
(edaspidi „andmekaitsealane mõjuhinnang“), kui teatava töötlemisviisiga kaasneb tõenäoliselt suur oht füüsiliste isikute õigustele ja vabadustele;
4.3.2. kohustus tagada isikuandmete õigsus ja ajakohasus, teavitades vastutavat töötlejat viivitamata, kui volitatud töötleja saab teada, et tema töödeldavad isikuandmed on ebaõiged või aegunud;
4.3.3. kohustus teavitada vastutavat töötlejat kohe, kui vastutava töötleja nõuded ja juhised lähevad volitatud töötleja arvates vastuollu isikuandmete kaitse üldmäärusega või kohaldatavate liidu või liikmesriigi andmekaitsealaste sätetega.
5. Alamtöötleja kaasamine 5.1. Volitatud töötleja ei telli käesolevate nõuete kohaselt vastutava töötleja nimel tehtavate
töötlemistoimingute tegemist alamtöötlejalt ilma vastutava töötleja eelneva kirjaliku eriloata. Volitatud töötleja esitab eriloa taotluse vähemalt 14 kalendripäeva enne kõnealuse alamtöötleja kaasamist koos teabega, mis on vajalik, et vastutav töötleja saaks loa kohta otsuse teha. Luba registreeritakse lepingu külge lisana.
5.2. Kui volitatud töötleja kaasab konkreetsete töötlemistoimingute tegemiseks (vastutava töötleja nimel) alamtöötleja, teeb ta seda lepinguga, millega kehtestatakse alamtöötlejale sisuliselt samad andmekaitsealased nõuded, mis on volitatud töötlejal käesolevate nõuete kohaselt.
5.3. Volitatud töötleja tagab, et alamtöötleja täidab volitatud töötleja suhtes käesolevaid nõudeid.
5.4. Volitatud töötleja jääb vastutava töötleja ees täielikult vastutavaks alamtöötleja nõuete täitmise eest vastavalt volitatud töötlejaga sõlmitud lepingule. Volitatud töötleja teavitab vastutavat töötlejat, kui alamtöötleja ei täida oma lepingulisi nõudeid.
6. Tehnilised ja korralduslikud meetmed, sealhulgas tehnilised ja korralduslikud
meetmed andmete turvalisuse tagamiseks 6.1. Volitatud töötleja kohustub tarvitusele võtma asjakohased tehnilised ja korralduslikud
meetmed lepingu alusel toimuva andmete töötlemise loata või ebaseadusliku töötlemise, juhusliku kaotamise või hävitamise või kahjustumise vältimiseks.
6.2. Volitatud töötleja tagab organisatsioonisisese metoodilise ja süstemaatilise infoturbe haldamise, eelistatult laialdaselt tunnustatud turvasmetoodika põhjal (nt ISO/IEC 27001, SOC2, CIS Security Controls, Eesti riiklik infoturbe standard E-ITS vms), sh rakendades: 6.2.1. infoturbe riskihalduse; 6.2.2. varahalduse, sh arvestades RMK varadega; 6.2.3. infoturbe rollide ja vastutuse kindlaksmääramine; 6.2.4. pääsuõiguste halduse; 6.2.5. turvaintsidentide halduse; 6.2.6. jätkuvuse halduse, sh oma tarneahela ulatuses; 6.2.7. tööjaamade ja teiste IT-seadmete ja tarkvarade tugevdamise ja
konfiguratsioonihalduse; 6.2.8. kahjurvara tõrje; 6.2.9. krüptograafiliste meetmete halduse; 6.2.10. auditilogi ja turvaseire olemasolu; 6.2.11. nõrkuse ja paigahalduse; 6.2.12. füüsiliste turvameetmete halduse; 6.2.13. turvameetmete perioodilise läbivaatuse (vähemalt kord aastas).
6.3. Kõik need infoturbe protsessid peavad tagama RMK varade konfidentsiaalsuse, tervikluse, käideldavuse ja organisatsiooni kohanemisvõime muutuvas küberohtude keskkonnas.
7. Andmete turvalisus edastamisel ja talletamisel 7.1. Volitatud töötleja on kohustatud hoidma lepingu täitmise käigus teatavaks saanud
andmeid rangelt konfidentsiaalsena ning mitte kasutama ega avaldama andmeid, mis tahes muul kui käesolevas lepingus sätestatud eesmärgil.
7.2. Konfidentsiaalse teabe edastamisel arvutivõrgu kaudu peab teave olema krüpteeritud turvalise krüptomeetme abil vastavalt kokkulepitud andmeedastuse viisile, kas: 7.2.1. rakenduste vahelisel suhtlusel üle API kasutades turvalist šifrikomplektiga TLS
(HTTPS) veebiseanssi; 7.2.2. inimkasutajale andmete jagamisel üle veebiliidese kasutades turvalist
šifrikomplektiga TLS (HTTPS) veebiseanssi; 7.2.3. kaugpääsuga andmete jagamisel kasutades VPN ühendust turvalise
konfiguratsiooniga; 7.2.4. e-kirjaga andmete edastamisel kasutades krüpteeritud manuseid (.cdoc).
7.3. Konfidentsiaalse teabe talletamisel (andmed jõudeolekus) peab rakendama turvalisi krüptomeetmeid. Näiteks kogu ketta krüpteerimine, mälupulga krüpteerimine, krüpteeritud andmebaas või andmebaasi kirjed.
7.4. Turvaline krüptomeede on lahendus, mis rakendab turvalist krüptoalgoritmi, võtmepikkust, krüptovõtme käsitlust, tarkvara jms. Valikul peab lähtuma uusimast RIA avaldatud krüptograafiliste algoritmide elutsükli uuringust (https://www.ria.ee/amet- uudised-ja-kontakt/uudised-pressikontakt/uuringud-ja- analuusid?view_instance=2¤t_page=1&sort_property=1&sort_direction=desc# kruptouuringud).
7.5. Volitatud töötlejal pole lubatud edastada andmeid väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma vastutava töötleja sellekohase selgesõnalise kirjaliku nõusolekuta.
8. Pääsuhalduse meetmed 8.1. Volitatud töötleja on kohustatud oma töötajatele andma töödeldavatele isikuandmetele
juurdepääsu üksnes ulatuses, mis on vajalik lepingu täitmiseks, haldamiseks ja selle täitmise üle tehtavaks järelevalveks. Volitatud töötleja tagab, et isikuandmeid töötlema hakkavad volitatud isikud on kohustatud järgima isikuandmete töötlemise nõudeid või nende suhtes kehtivaid asjakohaseid seadusjärgseid konfidentsiaalsuskohustusi.
8.2. Juurdepääs RMK varadele, sh teabele on lubatud, vastavalt: 8.2.1. veebiliidese kaudu RMK rakenduses Microsoft Dynamics 365 Business Central;
8.3. Vastutava töötleja konfidentsiaalse teabega dokumentatsioon peab olema vastavalt märgistatud, kui vastav märgistus on juba seotud alusdokumentatsioonil või kui need juhised on vastutava töötleja poolt antud. Dokumentatsioonil saab kasutada märgistust: asutusesiseks kasutamiseks ning vastav viide õigusaktile või “RMK siseseks kasutamiseks”.
8.4. Vastutava töötleja süsteemides talletatud ja üksnes seal töötlemiseks mõeldud teavet ei tohi kopeerida volitatud töötleja süsteemidesse, kui ei ole kirjalikult kokku lepitud teisiti.
8.5. Vastutava töötleja konfidentsiaalsele teabele juurdepääsu jagamisel tuleb arvestada konkreetsete töötajate teadmisvajadusega ning rakendada minimaalõiguste printsiipi.
8.6. Juurdepääsu võimaldavat teavet (nt paroolid, PIN-koodid, salajased või privaatvõtmed, tookenid jne) tohib talletada ainult krüpteeritud kujul (nt tarkvaraline paroolihoidla, vault) või füüsiliselt kaitstud hoidlas (nt seifis).
8.7. Juurdepääsul peab kõikidele kasutajatele jõustama mitmetasemelised autentimisviisid ja keelama üksnes ühetasemelised autentimisviisid.
8.8. Vastutava töötleja süsteemides loodud kasutajakontosid võib kasutada ainult volitatud töötleja töötaja, kellele nimeline konto on loodud ja kellele on pääsuõigused üle antud. Konto jagamine on keelatud.
8.9. Volitatud töötleja peab vastutavat töötlejat viivitamata teavitama kasutajakonto sulgemisese vajadusest, kui mõni volitatud töötleja töötajatest on töölt lahkunud, ei ole enam seotud lepingu täitmisega või pääsuandmed on sattunud ohtu (nt lekkinud).
9. Töötluskoha füüsilise turbe meetmed 9.1. Vastutava töötleja konfidentsiaalset teavet tohib töödelda ainult nendes ruumides, kus
on tagatud piisav kaitse füüsiliste turvaohtude eest, näiteks seadme vargus või volitamata juurdepääs, ekraani või klaviatuuri jälgimine jms.
10. Andmete kvaliteedi tagamise meetmed 10.1. Volitatud töötleja peab vastutava töötleja konfidentsiaalset teavet töötlema viisil, et
andmete õigsus, täielikkus ja ajakohasus oleks tagatud. Võimalusel peab rakendama sisendandmete valideerimist, töödeldud andmete testimist ja kindlustama volitatud töötleja poolt kasutatava tarkvara korrektne toimimine.
11. Sündmuste logimine ja seire 11.1. Volitatud töötleja tagab konfidentsiaalse teabe töötlemisega seotud revisjonlogi (audit
logi) olemasolu ja pideva turvaseire. 11.2. Logisid peab säilitama 2 aastat. 12. Jätkuvuse ja muudatuse meetmed 12.1. Volitatud töötleja teavitab vastutavat töötlejat kirjalikult kõigist muudatustest, mis
võivad mõjutada volitatud töötleja võimet või väljavaateid pidada kinni käesolevast
lisast ja vastutava töötleja kirjalikest juhistest. Pooled lepivad kõigis käesolevat lisa puudutavates täiendustes ja muudatustes kokku kirjalikult.
12.2. Volitatud töötleja tagab oma teenuste kättesaadavuse, arvestades võimalike probleemidega enda tarneahelas.
12.3. Vastutava töötleja poolsel pärimisel annab volitatud töötleja teavet oma toodetes kasutatavatest süsteemi-komponentidest ja turvafunktsioonidest.
12.4. Teenuseid mõjutavatest muudatustest ja võimalikest plaanilistest katkestustest antakse vastutavale töötlejale teada enne muudatust või katkestust.
13. Turvameetmete teavitus ja kontroll 13.1. Vastutav- ja volitatud töötleja peavad suutma tõendada käesolevate nõuete täitmist. 13.2. Volitatud töötleja peab võimaldama vastutaval töötlejal või tema poolt volitatud
audiitoril teha auditeid ja kontrolle ning panustama nendesse. 13.3. Vastutav- ja volitatud töötleja teevad auditi käigus saadud teabe ja auditite tulemused
taotluse korral kättesaadavaks pädevale järelevalveasutusele. 13.4. Volitatud töötleja tagab oma töötajate teavitamise käesolevatest turvameetmetest. 13.5. Volitatud töötleja tagab iseseisvalt enda ja alltöövõtjate organisatsioonis pideva
turvameetmete rakendatuse kontrolli. 13.6. Volitatud töötleja organisatsioonisisest infoturbehaldust peab auditeerima sõltumatu
osapool vähemalt üks kord aastas. Selle korraldab volitatud töötleja. 13.7. Tunnustatud turvasertifikaadi (nt ISO/IEC 27001, SOC2) või auditiaruande (E-ITS
auditi aruanne) korral ei pea eraldiseisvat sõltumatud auditit lisaks läbi viima, kui sertifikaat või auditi aruanne: 13.7.1. on kehtiv; 13.7.2. käsitlusala katab ära RMK varadega seotud teenused või tooted; 13.7.3. tehakse vastutavale töötlejale kättesaadavaks.
13.8. Võimalikud erandid ja kõrvalekalded nimetatud meetmetest tuleb kirjalikult kooskõlastada vastutava töötlejaga enne erandi rakendamist.
13.9. RMK võib igal ajahetkel kontrollida ja auditeerida nimetatud turvameetmete rakendatust ja volitatud töötleja peab seda toetama.
14. Andmetega seotud rikkumisest teavitamine 14.1. Volitatud töötleja teavitab vastutavat töötlejat andmetega seotud rikkumistest või kui on
alust kahtlustada, et selline rikkumine on aset leidnud, ilma põhjendamatu viivituseta alates hetkest, kui volitatud töötleja või tema poolt kasutatav alamtöötleja saab teada andmetega seotud rikkumisest või on alust kahelda, et selline rikkumine on aset leidnud, kuid mitte hiljem kui kakskümmend (20) tundi pärast sellest teada saamist.
14.2. Volitatud töötleja teeb vastutava töötlejaga igakülgset koostööd turvaintsidentide käsitlemisel, sh analüüsimisel, isoleerimisel ja normaalse olukorra taastamisel.
14.3. Volitatud töötleja peab oma sisemised lahendused ja protsessid korraldama selliselt, et intsidendi korral vastutava töötlejaga seotud äriprotsessid ja -teenused toimiksid võimalikult vähese häiringuga.
14.4. Vastutava töötleja nõudmisel peab volitatud töötleja ilma põhjendamatu viivituseta edastama vastutavale töötlejale kogu andmetega seotud rikkumist puudutava asjakohase informatsiooni.
14.5. Teates tuleb kirjeldada vähemalt järgmist: 14.5.1. toimunud andmetega seotud rikkumise laad, andmesubjekti kategooriad ja
ligikaudne arv ning isikuandmete liigid ja ligikaudne arv; 14.5.2. eeldatav kuupäev ja kellaaeg; 14.5.3. isikuandmetega seotud rikkumise tõenäolised tagajärjed;
14.5.4. volitatud töötleja asjakohase kontaktisiku nimi ja kontaktandmed, kellelt saab täiendavat informatsiooni;
14.5.5. meetmeid, mida volitatud töötleja rikkumise lahendamiseks on tarvitusele võtnud või võtab, et vältida andmetega seotud rikkumisi tulevikus, ja vajaduse korral ka meetmeid, mille abil leevendada rikkumise võimalikke negatiivseid mõjusid;
14.5.6. esitama muud teavet, mis on mõistlikult nõutav, et vastutav töötleja saaks täita kohaldatavaid andmekaitsealaseid nõudeid, sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks;
14.5.7. Juhul kui kogu teavet ei ole võimalik esitada korraga, peab esialgne teade sisaldama sel ajal kättesaadavat teavet ning täiendav teave esitatakse viivituseta pärast selle saamist.
14.6. Teavet andmetega seotud rikkumistest ja turvaintsidentide kohta loetakse konfidentsiaalseks ja see tuleb edastada krüpteeritult.
14.7. Teavitus tuleb edastada: 14.7.1. E-posti aadress: [email protected]; 14.7.2. telefon: +372 676 7000.
14.8. Vastutav töötleja teavitab vajadusel kolmandaid osapooli, avalikkust ja järelevalveasutusi, sh Andmekaitse Inspektsiooni, Riigi Infosüsteemi Ametit ja Politsei- ja Piirivalveametit. Volitatud töötleja ei teosta avalikku suhtlust osas, mis võimaldab tuvastada vastutavat töötlejat ja tema kliente.
15. Lõppsätted 15.1. Kui volitatud töötleja ei täida käesolevatest nõuetest tulenevaid kohustusi, võib vastutav
töötleja anda volitatud töötlejale korralduse peatada isikuandmete töötlemine seniks, kuni volitatud töötleja järgib käesolevaid nõudeid või leping lõpetatakse. Volitatud töötleja teavitab vastutavat töötlejat viivitamata, kui ta ei suuda käesolevaid nõudeid mis tahes põhjusel täita.
15.2. Vastutaval töötlejal on õigus lõpetada leping , kui: 15.2.1. vastutav töötleja on volitatud töötleja poolse isikuandmete töötlemise punkti
15.1 kohaselt peatanud ja kui käesolevaid nõudeid ei hakata järgima mõistliku aja jooksul või hiljemalt ühe kuu jooksul pärast peatamist;
15.2.2. volitatud töötleja rikub oluliselt või jätkuvalt käesolevaid nõudeid või isikuandmete kaitse üldmäärusest tulenevaid nõudeid.
15.3. Volitatud töötlejal on õigus lõpetada leping isikuandmete töötlemise osas pärast seda, kui ta on vastutavat töötlejat punkti 4.3.3 kohaselt teavitatud, et tema juhised lähevad vastuollu kohaldatavate õigusnõuetega, kuid vastutav töötleja nõuab nende juhiste järgimist.
15.4. Pärast lepingu lõpetamist kustutab volitatud töötleja vastutava töötleja valikul kõik vastutava töötleja nimel töödeldud isikuandmed ja kinnitab vastutavale töötlejale, et ta on seda teinud, või tagastab kõik isikuandmed vastutavale töötlejale ja kustutab olemasolevad koopiad, välja arvatud juhul, kui seaduses kohaselt nõutakse isikuandmete säilitamist. Volitatud töötleja jätkab nendele nõuetele vastavuse tagamist seni, kuni andmed kustutatakse või tagastatakse.
1
RAAMLEPING nr 1-18/2026/25
Riigimetsa Majandamise Keskus, registrikoodiga 70004459, asukohaga Mõisa/3, Sagadi küla,
Haljala vald, 45403 Lääne-Virumaa (edaspidi tellija), keda esindab seaduse alusel juhatuse liige Agne
Aija, ühelt poolt
ja
OIXIO Digital AS, registrikoodiga 10351019, asukohaga Veskiposti tn 2/1, 10138 Tallinn (edaspidi
täitja), keda esindab esindab tegevjuht Liie Strenze per procura, teiselt poolt,
keda edaspidi nimetatakse ka eraldi pool või koos pooled, on sõlminud raamlepingu (edaspidi leping)
alljärgnevas:
1. Üldsätted 1.1. Käesolev leping sõlmitakse riigihanke „Personali- ja palgaarvestuse tarkvara soetamine ja
hooldus koos iseteenindusega“ (edaspidi nimetatud riigihange, viitenumber 302765, DHS 1- 47.3516/1) tulemusena.
1.2. Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse riigihanke alusdokumendid (RHAD),
täitja riigihankes esitatud pakkumus ja riigihankes tellija antud selgitused ning pooltevahelised kirjalikud teated, mida lepingu lisadena eraldi ei allkirjastata.
1.3. Lepingul on sõlmimisel järgmised lisad, mis on lepingu lahutamatuteks osadeks: 1.3.1. Lisa 1 – Tehniline kirjeldus;
1.3.2. Lisa 2 – Arendusnõuded;
1.3.3. Lisa 3 – Isikuandmete töötlemise nõuded volitatud töötlejale. 1.4. Vastuolu korral lepingu ja lisa vahel, kohaldatakse lepingu lisas sätestatut, kui konkreetsest
lepingu sättest ei tulene teisiti. 1.5. Leping ei kohusta tellijat täitjalt teenust tellima. Tellija tellib teenust vastavalt reaalsele vajadusele
ja olemasolevatele võimalustele, kooskõlas tehnilise kirjeldusega.
2. Lepingu ese
2.1. Lepingu esemeks on RMK-le (Hankija) personali- ja palgaarvestuse ja iseteeninduse rakenduse arendus- ja hooldustööd (edaspidi „teenus“ või „töö“), mida täitja kohustub läbi viima vastavalt
RHAD-le, sõlmitud lepingule ja selle lisadele. 2.2. Pooled täpsustavad teenuse osutamise käigus teenuse sisu, ulatust ja ajakava lähtuvalt kiiruse,
kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest. Pooltel on õigus teha nimetatud küsimustes
omapoolseid ettepanekuid ja pakkumisi, mis tagaks teenuse parima teostuse. 2.3. Täitja teostab töö kooskõlas tehnilise kirjeldusega ja parimate praktikatega tarkvaraarenduses.
2.4. Lepingu täitmise keel on eesti keel, muuhulgas on see ka lepingu sõlmimise, töökoosolekute jm suhtluse ning tööde dokumenteerimise keel.
2.5. Täitja on kohustatud lepingu alusel ja selles sätestatud maksumuse eest teostama ka nn sidustöid,
mis ei ole lepingus sõnaselgelt sätestatud, kuid mille teostamine on headest tavadest ja täitja ametialasest professionaalsusest lähtudes nõutavad ja/või vajalikud lepingust tuleneva eesmärgi
saavutamiseks. Tööde teostamisel tuleb lähtuda tõhususe, kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest ning arvestades vastavas tegevusvaldkonnas kehtivaid õigusakte, standardeid ja
head tava.
3. Lepingu täitmine, tööde teostamine
3.1. Töid teostatakse üldjuhul täitja valitud asukohas tellija ja täitja poolt nimetatud arendusmetoodikaid kasutades. Täitja teostab kogumaksumuse eest ka nn sidustöid, mis ei ole
lepingus sõnaselgelt sätestatud, kuid mille teostamine on headest tavadest ja täitja ametialasest professionaalsusest lähtudes nõutavad ja/või vajalikud lepingust tuleneva eesmärgi
saavutamiseks
3.2. Täitja alustab lepingu täitmist esimesel võimalusel pärast selle sõlmimist. Tellija annab täitjale teada lepingu täitmise algustähtaja e-kirja teel. Tellijal on õigus ühepoolselt nimetatud tähtaega
2
edasi lükata vajaliku perioodi võrra põhjendatud vajaduse esinemisel. Tellija teavitab täitjat
lepingu täitmise hilisemast algustähtajast ja täitmisega viibimise põhjusest e-kirja teel. 3.3. Tugiteenused peavad olema tagatud tööpäevadel kella 08:00 kuni 17:00 ning lähtudes hanke
tehnilises kirjelduses toodud teenustasemetest. Tööpäevadeks loetakse kõiki nädalapäevi, välja arvatud laupäev, pühapäev ja riigipühad. Tugiteenus peab sisaldama pakutava lahenduse
toimimisega seotud kasutajatuge (tugiisik kõigi lokalisatsioonide jaoks) ja tarkvarauuendusi (sh
versiooniuuendused) kogu raamlepingu kehtivuse aja. 3.4. Täitja kohustub rakendama tööde teostamisel meeskonnaliikmeid, kelle ta on esitanud lepingu
sõlmimise aluseks olevas hankemenetluses. 3.5. Lisaks meeskonnaliikmetele, kelle CV-d on lisatud pakkumusele, võib täitja vajadusel kaasata
lepingu täitmisesse meeskonnaliikmeid, kes ei pea vastama hankemenetluses vastavatele spetsialistidele tellija poolt kehtestatud nõuetele. Nimetatud spetsialistid osalevad lepingu
täitmisel ainult koos hankemenetluses kehtestatud nõuetele vastavate spetsialistidega, ilma
lisatasu küsimata. Täitja peab tellijat piisav aeg ette kirjalikult informeerima planeeritavast meeskonnaliikme lisamisest ning spetsialisti lisamine võib toimuda ainult tellija kirjalikku
taasesitamist võimaldavas vormis antud nõusolekul ja kooskõlas RHAD-ga. Tellijal on õigus täitja poolt pakutavast lisa meeskonnaliikmest keelduda.
3.6. Täitja tagab lepingu täitmise eesti keeles. Lepingu täitmisesse kaasatud meeskonnaliikme(te)
eesti keele oskus kõnes ja kirjas peab olema vähemalt tasemel, mis võimaldab meeskonnaliikme(te)l vahetult osaleda nii meeskonnatöös (koosolekud jmt) kui teostada lepingu
esemeks olevaid arendustöid ja saada iseseisvalt, ilma täiendava tellija poolse juhendamiseta, aru tööülesannete ja tehniliste juhiste sisust ja tellijal kasutusel olevate töökeskkondade juhistest.
Juhul, kui meeskonnaliikme(te) eesti keele oskus ei ole piisaval tasemel, tagab täitja meeskonnaliikme(te)le omal kulul tõlgi, sh juba sõlmitud lepingu täitmise olukorras, kui ilmnevad
probleemid eespoolviidatud kompetentsidega. Taolisel kujul lepingu täitmine ei tohi kahjustada
lepingu täitmise kvaliteeti ega kiirust, vastasel juhul on tegu lepingu olulise rikkumisega. 3.7. Töid vahetult teostavate spetsialistide asendamine/lisamine võib toimuda tellija kirjalikku
taasesitamist võimaldavas vormis antud nõusolekul. Täitja on kohustatud teavitama tellijat meeskonnaliikme asendamisest/lisamisest kirjalikku taasesitamist võimaldavas vormis vähemalt
14 päeva enne meeskonnaliikme asendamist/lisamist, kusjuures täitja on kohustatud tagama, et
uue meeskonnaliikme kompetents on vähemalt võrdne lepingu sõlmimise aluseks olevas hankes vastavale meeskonnaliikmele esitatud nõuetega. Tellijal on õigus keelduda täitja poolt lepingu
täitmiseks esitatud meeskonnaliikme asendamiseks/lisamiseks pakutavast meeskonnaliikmest, kui pakutav spetsialist ei vasta eelnimetatud nõuetele või kui pakutava isiku kompetentside
hindamisel ei oleks täitja pakkumus olnud hankemenetluses edukas (so kohtleks teisi pakkujaid
ebavõrdselt). 3.8. Lisaks punktis 3.6 sätestatule kohustub täitja tellijat vähemalt 14 päevaette teavitama kirjalikku
taasesitamist võimaldavas vormis meeskonnaliikmete planeeritud puhkustest ja lähetustest juhul, kui puhkuse või lähetuse kestus on 4 või rohkem kalendripäeva.
3.9. Täitja annab kogu lepingu täitmise perioodi vältel jooksvalt tagasisidet tellija küsimustele ja arupärimistele ning annab tellija nõudmisel jooksvalt ülevaate ja esitleb juba teostatud või
teostamisel olevaid töid.
3.10. Pretensioonid töö tulemi plaanipärase edenemise, teostamise efektiivsuse ja kvaliteedi kohta annab tellija teada lisaks meeskonnaliikmele ka täitja lepingulisele kontaktisikule. Olulises ulatuses
või korduvaid kõrvalekaldeid tellija juhiste järgimata jätmisel loetakse lepingu rikkumiseks. 3.11. Tellijal on õigus igal ajal lepingu täitmise käigus kolme kalendripäevase etteteatamisega kokku
kutsuda koosolekuid, kus täpsustatakse töökorraldust, tellija ja täitja ootuseid vmt.
3.12. Tellija on kohustatud kõikidele täitja lepingu täitmisega seotud põhjendatud küsimustele vastama hiljemalt kolme tööpäeva jooksul. Juhul, kui küsimusele vastamine nõuab tellijalt pikemat
analüüsi, on tellija kohustatud andma eeltoodud kolme tööpäeva jooksul täitjale täpse kuupäeva, millal tagasisidet antakse, sellisel juhul on täitjal õigus nõuda tarne tähtaja proportsionaalset
pikendamist. 3.13. Täitja tagab ja vastutab tööks vajalike töövahendite, litsentside ja autoriõiguste eest iseseisvalt.
4. Analüüsi-, hooldus- ja arendustööde teostamine 4.1. Tööde teostamiseks esitab tellija täitjale tellimuse. Eraldiseisvaid kirjalikke hankelepinguid ei
sõlmita.
3
4.2. Tugi- ja hooldusteenuseid teostatakse agiilselt tunnipõhise arvestusega, akteeritakse ja
arveldatakse 1 (üks) kord kuus eelmise kuu töötundide ja lepingus sätestatud tunnitasu alusel. Seejuures tellija kontrollib täitja esitatud akti tundide vastavust tehtud tööle ning kinnitab või
esitab küsimusi/tagasisidet hiljemalt 14 päeva jooksul peale akti esitamist. 4.3. Arendus- ja analüüsi töid teostatakse etapipõhise arvestusega, mille aluseks on üleandmise akt.
Seejuures tellija kontrollib täitja esitatud akti vastavust tehtud tööle ning kinnitab või esitab
küsimusi/tagasisidet hiljemalt 14 päeva jooksul peale akti esitamist. 4.4. Täitja koostöös tellija kontaktisikuga valmistavad ette (analüüsib ja kirjeldab) tööülesanded tellija
tööülesannete projektirühmas. Täidetavad ülesanded (tulemid) lepitakse kokku kohtumistel (ehk projektirühma koosolekul). Sellele eelnevalt hinnatakse ja täiendatakse tulevaste tööde/tulemite
sisu ja töömahtu selleks ettenähtud kohtumisel. Täitja peab lepingu täitmisel juhinduma tellija poolt edastatud juhistest ja ülesannetest.
4.5. Konkreetse töö teostamisel lepitakse projektirühmas kokku rakendatava meeskonna suurus ja
rakendatavad rollid vastavalt pakkumusele, tellija vajadustele ja prioriteetidele tulenevalt tellitava teenuse konkreetsest sisust.
4.6. Loodavad tulemid antakse üle tellija koodirepositooriumi kaudu vastavalt tellija juhistele. Arendustööde raames tehtud lähtekoodi paneb täitja tellija koodirepositooriumisse ja paigaldab
tellija arenduskeskkonda vähemalt 1 (üks) kord nädalas. Täitja meeskonnaliikmetele luuakse
tellija poolt ligipääs koodirepositooriumile lähtekoodide, andmebaasimuudatuste ning muude tulemite või nende muudatuste üleandmiseks.
4.7. Enne lähtekoodi repositooriumisse lisamist peab kood/teostatud töö/tulem olema: 4.5.1 iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga vastuolus
funktsionaalsust); 4.5.2 üldharu/muu haru tulemiga kooskõlas;
4.5.3 edaspidi mugavalt kasutatav ja mõistetav, ehk sellel on olemas oma enda sisseehitatud
testid, mis peale järgnevaid võimalikke arendusi/tegevusi näitaks, kas see konkreetne funktsionaalsuse osa on endiselt korras, või läks katki ja tuleb korrastada.
4.6 Äriliselt võtmetähtis funktsionaalsus peab olema loodavas koodis varustatud kommentaaridega (klasside ja meetodite kommentaarid).
4.7 Tarnitav lepingu ese peab ühilduma tellija poolt nõutud tehnilise lahendusega (erisused on
lubatud tellija kontaktisiku kirjalikku taasesitamist võimaldavas vormis esitatud nõusolekuga), sealhulgas:
4.7.1 järgima tellija poolt nõutud tehnilise lahenduse ideoloogiat süsteemsete protseduuride osas ja infosüsteemi arhitektuurset lahendust ja kasutusloogikat;
4.7.2 taaste- ja varundusprotseduurid peavad olema ühilduvad tellija poolt soovitud tehnilise
lahendusega; 4.7.3 lepingu ese ei tohi põhjustada süsteemi töö terviklikkuse või muid toimimise häireid ega
jõudluse langust; 4.7.4 lepingu ese peab olema tellija poolt nõutud infosüsteemiga ühetaoline ning sobituma
olemasolevatesse ekraanivormidesse ja töövoogu; 4.7.5 lepingu ese peab vastama hankes esitatud arendusnõuetele, välja arvatud nendele, millele
loodav infosüsteem ei kohaldu või on täitja poolt kirjalikult välja toodud ja põhjendatud
ning tellija poolt kirjalikult kinnitatud erand. 4.8 Tööde teostamise käigus tuleb täitjal vajadusel uuendada ka lepingu eseme dokumentatsiooni
(kirjeldused, juhised, protsessianalüüs jmt) ja dokumentatsioon tellijale üle anda. 4.9 Tööde üldisteks vastuvõtukriteeriumiteks on:
4.9.1 vastavus lähteülesandes toodud ja projektirühmas kokkulepitud ärilisele- ja tehnilisele
kirjeldusele; 4.9.2 vigade ja kõrvalmõjude puudumine.
4.10 Tellijal on 14 tööpäeva aega kontrollida vastuvõtmiseks esitatud tööde lepingutingimustele vastavust. Tellija kontaktisik võib nimetatud tähtaega pikendada, kui pikendamine on
põhjendatud. 4.11 Üleandmis-vastuvõtmisakti valmistab ette täitja vastavalt tellija poolt etteantud vormile ning see
allkirjastatakse poolte kontaktisikute poolt digitaalselt. Täitja esitab tellijale punktis 4.2 nimetatud
ja akteeritud tööde teostamise järel üleandmis-vastuvõtmisakti, milles on sätestatud täitja poolt teostatud tööde tulemi kirjeldus, ning vastava töö maksumus. Vajadusel täpsustatakse aktis üle
antud tulemit. Üleandmise-vastuvõtmise akti on õigus allkirjastada lepingu kontaktisikutel.
4
4.12 Peale üleandmise-vastuvõtmise akti allkirjastamist esitab täitja tellijale arve teostatud tööde eest
vastavalt üleandmise-vastuvõtmise aktile ja punktile 4.11. 4.13 Kui Tellijal puuduvad lepingu eseme osas pretensioonid, allkirjastavad pooled Lepingu eseme
üleandmise-vastuvõtmise akti. 4.14 Mistahes Teenuse osa valmimisel võib Tellija anda välja vastuvõtuakti vastava osa kohta ning
aktis fikseeritakse puudused koos puuduste kõrvaldamise tähtajaga. Selline vastuvõtmine ei
mõjuta Täitja kohustust täita kõiki Lepingus ettenähtud kohustusi. 4.15 Tellija poolt Teenuse vastuvõtmine ei vabasta Täitjat vastutusest Teenuse üleandmisel-
vastuvõtmisel avastamata jäänud vigade või Teenuse mittenõuetekohasuse eest.
5. Garantiitingimused 5.1 Üle antud tulemi osas kohaldub garantii alljärgnevatel põhimõtetel:
5.1.1 garantiiaeg on 12 (kaksteist) kuud alates hetkest, mil viimase etapi tulem on tellija poolt
lepingu kohaselt vastu võetud; 5.1.2 olukorras, kus töö pole akti alusel vastu võetud, on etapi tulemi osaline või täielik toodangus
kasutuselevõtt aluseks nende osade garantiiperioodi algusele; 5.1.3 täitja on kohustatud tagama garantiiajal tulemil ilmnenud puuduste tasuta kõrvaldamise
vastavalt vea prioriteetsusele järgnevalt:
5.1.3.1 kriitilised vead 2 tööpäeva jooksul peale sellekohase teate edastamist tellija poolt täitjale. Kriitiliseks veaks loetakse tarkvara arendusega seotud viga, mille tõttu: tarkvara
tervikuna ei ole võimalik kasutada; tarkvara põhifunktsionaalsus ei tööta või on oluliselt häiritud; tarkvara lubab/teostab mitteautoriseeritud operatsioone; kahjustatud on
süsteemis olevad andmed; kasutajale või seotud infosüsteemidele/andmebaasidele väljastatakse ebaõigeid andmeid/tulemusi. Kriitiliseks veaks loetakse sealhulgas
ebamõistliku sagedusega esinevad sarnased mittekriitilised vead;
5.1.3.2 mittekriitilised vead 5 tööpäeva jooksul peale sellekohase teate edastamist tellija poolt täitjale. Mittekriitiliseks veaks loetakse infosüsteemi toimehäiret, mis ei ole põhjustatud
riistvarast või muust tarkvarast või muust arendustööst ja mida ei saa käsitleda kriitilise veana.
5.2 Veateade loetakse esitatuks, kui tellija või tellija kontaktisik on veateate esitanud kirjalikku
taasesitamist võimaldavas vormis täitjale või täitja lepingujärgse kontaktisiku e-posti aadressil. 5.3 Täitja teostab garantiiaja vältel vajalikud tööd kasutades lepingukohast meeskonda, milles on
võimalik muudatusi teha vastavalt lepingu punktile 3.6.
6. Poolte vastutus
6.1. Pooled vastutavad lepinguliste kohustuste rikkumise eest. Kohustuse rikkumisel on teisel poolel õigus kasutada kõiki seadusest või lepingust tulenevaid õiguskaitsevahendeid vastavalt
võlaõigusseadusele. 6.2. Lisaks mujal lepingudokumentides sätestatule, on tellijal õigus nõuda ja täitjal on kohustus
maksta leppetrahvi tarne üleandmisega või garantiitööde teostamisega viivitamisel 0,5% vastava töö maksumusest iga viivitatud tööpäeva eest.
6.3. Poolte hankelepingust tulenev koguvastutus on piiratud hankelepingu kogumaksumusega.
6.4. Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue 10 000 eurot iga rikkumise eest. Täitja poolse olulise hankelepingu rikkumise korral ei pea tellija määrama täitjale
lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud täiendavat tähtaega ning tellijal on muu hulgas õigus hankeleping üles öelda või hankelepingust taganeda.
6.5. Oluliseks rikkumiseks loevad pooled lisaks võlaõigusseaduses ja mujal lepingus sätestatule
muuhulgas: 6.5.1. mõjuva põhjuseta lepingu täitmise katkestamine või täitmisele mitte asumine;
6.5.2. valeinfo esitamine; 6.5.3. lepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid, intellektuaalse omandi
õigused) puudumine; 6.5.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine;
6.5.5. korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei vasta kokku
lepitud nõuetele või meeskonnaliikme asendamine ilma tellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta;
6.5.6. konfidentsiaalsuskohustuse rikkumine; 6.5.7. lepingujärgsete kohustuste korduvat (vähemalt kahel korral) täitmata jätmist;
5
6.5.8. tähtaegselt lepingu täitmata jätmist selliselt, et tehnilises kirjelduses sätestatud eesmärgi
täitmine ei ole enam tähtaegselt realistlik ja/või täitja poolse tegevuse või tegevusetuse tõttu ei ole võimalik enam kasutada lepingu rahastamiseks ettenähtud vahendeid;
6.5.9. lepingujärgsete kohustuste üleandmine kolmandale isikule. 6.5.10. RMK infoturbe nõuetele mittevastavus.
6.6. Kui Täitja ei paranda teenuses esinevaid probleeme garantiitingimuste punktis 5.1.3 sätestatud
lahendamise aja jooksul, on Tellijal õigus nõuda leppetrahvi järgmiselt: 6.6.1. kriitiline viga – 400 (nelisada) eurot iga ületatud tunni eest;
6.6.2. mittekriitilised vead – 200 (kakssada) eurot iga ületatud tunni eest. 6.7. Teenustasemete reageerimisaja rikkumiste korral kasutab Hankija tööaja kompenseerimise
mudelit ehk tasuta tööaja pakkumist järgnevalt: 6.7.1. Tase 1 rikkumise korral on Hankijal õigus saada kuni 8 tundi tasuta hooldustööd, mida võib
kasutada järgmise 30 kalendripäeva jooksul.
6.7.2. Tase 2 rikkumise korral kuni 4 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
6.7.3. Tase 3 ja tase 4 rikkumise korral kuni 2 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
6.8. Hankijal on õigus punkti 6.7 kompenseerimise mudel asendada leppetrahviga punktis 6.6
sätestatud määradega.
7. Tasu maksmine 7.1. Pooled lähtuvad teenuse eest tasumisel pakkumuses toodud tunnihindadest.
7.2. Lepingu maksimaalne kogumaksumus on 1 500 000 eurot, millele lisandub käibemaks (edaspidi lepingu hind). Lepingu hind sisaldab muuhulgas ka kõiki intellektuaalomandiga seotud tasusid,
kui need kohalduvad.
7.3. Tellijal on õigus lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised maha arvata lepingu alusel täitjale tasumisele kuuluvatest summadest.
7.4. Täitja esitab arve vaid elektrooniliselt. Arve esitamiseks tuleb kasutada elektrooniliste arvete esitamiseks mõeldud raamatupidamistarkvara või raamatupidamistarkvara E-arveldaja, mis asub
ettevõtjaportaalis https://www.rik.ee/et/e-arveldaja.
7.5. Arved kuuluvad Tellija poolt tasumisele 15 (viieteistkümne) päeva jooksul arve edastamisest Tellijale. E-arve peab sisaldama Teenuse tegelikku tellimust vormistanud kontaktisiku nime või
lepingust tulenevat tellija kontaktisiku nime ning selgelt ja üheselt viitama lepingu numbrile ja arve perioodile.
8. Lepingu kehtivus, täiendamine, muutmine ja lõpetamine
8.1. Raamleping jõustub selle allkirjastamisest ja kehtib 48 kuud või kuni rahalise mahu täitumiseni,
olenevalt sellest kumb olukord saabub varem. 8.2. Lepingu muutmine on võimalik üksnes poolte kirjalikul kokkuleppel ja kooskõlas riigihangete
seadusega. 8.3. Pooltel on õigus leping üles öelda seaduses ja lepingus sätestatud alustel.
8.4. Tellijal on õigus leping olenemata põhjusest ilma täiendavat tasu või hüvitist maksmata korraliselt
üles öelda, teatades sellest täitjale kirjalikult üks (1) kuu ette. 8.5. Täitjal on õigus leping erakorraliselt üles öelda, kui:
8.5.1. lepingust tulenevate täitja kohustuste täitmine on muutunud võimatuks tellijast põhjustatud tingimustel;
8.5.2. tellija on põhjendamatult viivitanud lepingujärgsete maksete tasumisega rohkem kui 40 (nelikümmend) kalendripäeva.
8.6. Tellijal on õigus leping erakorraliselt etteteatamise tähtaega järgimata üles öelda ja nõuda täitjalt
tekkinud otsese varalise kahju kompenseerimist, kui: 8.6.1. täitja rikkus oluliselt lepingu kohustust, mille järgimine oli täitja kohustus;
8.6.2. puudus on tekkinud täitjast tingitud asjaoludel, puuduste kõrvaldamine teenuse osutamisel ei ole võimalik ja puudus mõjutab oluliselt teenuse osutamise väärtust tellija jaoks;
8.6.3. täitja rikub muul moel lepingut sedavõrd oluliselt, et ei saa mõistlikult eeldada lepingu
jätkamist tellija poolt;
6
8.6.4. kui täitja ei täida lepingus ja selle lisades kokku lepitud nõudeid või on tema tegevus muul
viisil vastuolus lepingu ja selle lisadega ning kui hoolimata tellija nõudmisest ei ole olukord paranenud;
8.6.5. kui esinevad riigihangete seaduse §-s 124 toodud lepingu ülesütlemise alused; 8.6.6. kui täitja on teadlikult esitanud enne või peale lepingu sõlmimist või lepingu täitmise käigus
tellijale valeinformatsiooni.
8.7. Lepingu lõppemisel jäävad kehtima kõik sellised sätted, mille osas on lepingus sätestatud nende kehtima jäämine pärast lepingu lõppemist.
8.8. Lepingu ülesütlemine, lõpetamine või lõppemine ei vabasta pooli kohustuste täitmisest, mis neil tekkisid enne lepingu ülesütlemist, lõpetamist või lõppemist. Lepingu ülesütlemisel, lõppemisel
või lõpetamisel teostavad pooled kõik teenuse osutamise kulude ja arvete tasaarvestused 30 päeva jooksul alates lepingu lõpetamise kuupäevast, juhindudes sealjuures faktiliselt tehtud
kulutustest ja nõuetekohaselt osutatud teenusest.
8.9. Lepingu ülesütlemisel, lõpetamisel või lõppemisel tuleb täitjal edastada tellijale viivitamatult (ülesütlemise teate saamisest või kokkuleppe allkirjastamisest 3 tööpäeva jooksul lepingu
lõppemise tähtaja saabumisel hiljemalt 10 tööpäeva enne lepingu lõppemist) kõik seni lepingu raames tehtud ja üle andmata tööd ja seonduv materjal, informatsioon ja dokumendid (sh
poolelioleva projekti või objektiga seonduv materjal).
9. Konfidentsiaalsus ja andmekaitse
9.1. Pool kohustub tähtajatult hoidma saladuses teise poole poolt lepingu täitmise raames saadud, edastatud või muul moel teatavaks saanud teabe ja dokumendid, mis vastavalt avaliku teabe
seaduse või muu kehtiva õigusakti nõuetele ei ole avaldamiseks kohustuslik (konfidentsiaalne informatsioon).
9.2. Konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele on lubatud vaid teise poole
eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. Lepingus sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele poolte esindajatele, töötajatele,
audiitoritele, advokaatidele, pankadele, kindlustusandjatele, allhankijatele või teenusepakkujatele ja muudele isikutele, keda ta oma kohustuste täitmisel kasutab (seotud isikud).
9.3. Pool kohustub tagama, et temaga seotud isikud oleksid lepingus sätestatud konfidentsiaalsuse
kohustusest teadlikud ning rakendama temaga seotud isikutele samaväärseid nõudeid konfidentsiaalse informatsiooni töötlemisel ja kasutamisel, kui kehtib poolele endale lepingu ja
seaduse alusel. 9.4. Täitja kohustub mitte kasutama konfidentsiaalset teavet isikliku kasu saamise eesmärgil või
kolmandate isikute huvides.
9.5. Pool kohustub tagama lepingu täitmise käigus isikuandmete töötlemise õiguspärasuse ning vastavuse isikuandmete kaitse üldmääruses (EL 2016/679) ja teistes andmekaitse õigusaktides
sätestatud nõuetele, sh täitma organisatsioonilisi, füüsilisi ja infotehnoloogilisi turvameetmeid konfidentsiaalsete andmete kaitseks juhusliku või tahtliku volitamata muutmise, juhusliku
hävimise, tahtliku hävitamise, avalikustamise jms eest.
10. Load ja litsentsid
10.1. Tellija võib tarkvara litsentsid soetada sõltumatult käesolevast hankest, valides litsentside müüja või tootja vastavalt oma vajadustele ja äranägemisele.
10.2. Tellija võib ilma ette teatamata lepingu lõpetada, kui täitja ei saa lepingu täitmiseks vajalikku luba või litsentsi.
10.3. Tellija tagab täitjale ligipääsu tellija kontorisse ja infosüsteemidele ulatuses, milles see on lepingu
täitmiseks vajalik.
11. Intellektuaalne omand 11.1. Täitja loovutab tellijale kõik varalised õigused autoriõiguse seaduse tähenduses käesoleva lepingu
alusel üle antud tulemitele, kaasa arvatud õiguse neid reprodutseerida, levitada ja üldsusele kättesaadavaks teha mistahes vormis ja kandjal, ilma geograafiliste piiranguteta. Autori varalised
õigused loetakse tellijale üle läinuks pärast tulemi lepingukohast vastuvõtmist tellija poolt.
11.2. Juhul kui lepingus või tellimuses ei ole sõnaselgelt sätestatud teisiti, on tellijal muuhulgas õigus: 11.2.1. lepingu eset kasutada mis tahes eesmärgil ja viisil;
11.2.2. originaalteost muuta; 11.2.3. lepingu eset või selle koopiaid laenutada ja rentida;
7
11.2.4. anda all-litsentse lepingu eseme või selle koopiate suhtes kehtivate õiguste kohta.
11.3. Täitja annab tellijale vastavalt valdkonnas kehtivatele parimatele praktikatele dokumenteeritud lähtekoodi, va punktis 11.6 sätestatud juhtudel, kui on tegemist standardtarkvaraga.
11.4. Juhul kui lepingus või tellimuses ei ole sõnaselgelt sätestatud teisiti, kehtivad nimetatud õigused kogu autoriõiguste kehtivuse aja ja nende kehtivuse territooriumiks on kogu maailm.
11.5. Lepingu alusel üle antud õigused ja litsents hõlmab kõiki edasisi tulemi arendusi. Lepingu alusel
annab täitja tellijale õiguse luua oma äranägemisel tuletatud teoseid tulemi edasiarendamise teel. 11.6. Juhul kui riigihankes on pakutud tehnilises kirjelduses kirjeldatud samaväärset platvormi ning
pakkumus sisaldab vastavaid litsentse, annab täitja tellijale õiguse litsentsiga määratletud tarkvara kasutada lepingus sätestatud ulatuses ja määras. Sellisel juhul täitja:
11.6.1. tagab lepingu täitmiseks vajalike litsentside ja vajadusel muude intellektuaalse omandi õiguste olemasolu ja kehtivuse lepingu täitmise ajal;
11.6.2. kinnitab, et kasutusõiguse andmisega tellijale ei rikuta kolmandate isikute autoriõigusi ega
muid intellektuaalse omandi õigusi lepingu kehtivuse ajal; 11.6.3. hüvitab tellijale kõik täitja poolt käesoleva punkti rikkumisest tulenevad tellijale tekkivad
kulud ja kahjud juhul, kui täitja poolt pakutavad litsentsid rikuvad teiste isikute õigusi; 11.6.4. esitab tellijale kõigi litsentside autoriõiguste ja muude intellektuaalomandi õiguste
kasutamisõigust tõendavad kinnitused hiljemalt ajaks, kui tellijal tekib vajadus kasutada
nimetatud õigusi; 11.6.5. annab tellijale üle dokumendid ja teabe, mis on vajalikud litsentsidest tulenevate õiguse
kasutamiseks lepingu alusel; 11.6.6. kannab kõik otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul on või
väidetavalt on intellektuaalsest omandist tulenevaid õigusi lepinguga seotud intellektuaalse omandi objektile.
11.7. Täitja tagab tellijale kõik vajalikud õigused lepingu täitmise käigus loodava tulemi kontrollimiseks,
testimiseks ning süsteemi paigutamiseks ka ajaks, mil tarne on üle antud, kuid pole veel lepingukohaselt tellija poolt vastu võetud.
12. Probleemihalduse rakendus
12.1. Täitja koostöös tellija kontaktisikuga valmistavad ette (analüüsib ja kirjeldab) tööülesanded tellija
tööülesannete haldussüsteemis JIRA. Täidetavad ülesanded (tulemid) lepitakse kokku projektimeeskonna kohtumistel. Sellele eelnevalt hinnatakse ja täiendatakse tulevaste
tööde/tulemite sisu ja töömahtu selleks ettenähtud kohtumisel. Täitja peab lepingu täitmisel juhinduma tellija poolt edastatud juhistest ja ülesannetest.
12.2. Kasutatav probleemihalduse rakendus on tellija Atlassian Jira, mida kasutatakse teenuse
osutamisel avastatud probleemide, küsimuste jms ülesannetena registreerimiseks ja järelevalveülesannete täitmiseks. Tellija registreerib tuvastatud probleemid, küsimused jms
probleemihalduse rakenduses ülesannetena. Pooled võivad kokku leppida, et kasutavad Atlassian Jira asemel muud lahendust.
12.3. Probleemihalduse rakenduse tarkvarale pääseb juurde turvaliselt ja autoriseerituna veebiaadressi kaudu.
12.4. Tellija võib Täitjat teavitada tuvastatud probleemidest, küsimustest jms e-posti ja telefoni teel,
kuid ülesande käsitlemise eelduseks on nende registreerimine probleemihalduse rakenduses. 12.5. Vajaduse korral lepivad Pooled kokku täpsemas kasutuskorras probleemihalduse rakenduse
puhul, milles selgitatakse ülesannete lisamise nõudeid (rubriigid, teemad, ülesannete prioriteetsed kategooriad jne).
13. Dokumentatsioon 13.1. Täitja varustab tellijat piisava, adekvaatse ja ajakohase dokumentatsiooniga tarkvara
funktsioneerimise kohta, mis on vajalik, et tellija saaks tarkvara ja teenuseid efektiivselt kasutada. 13.2. Kasutusjuhendid ja muud tehnilised dokumendid tuleb esitada eesti keeles.
13.3. Dokumentatsioon peab vastama tarkvarale, sisaldama muudatusi ja olema terminoloogiliselt üheselt mõistetav.
13.4. Dokumentide valmistamiseks ja levitamiseks kasutatakse Atlassian Confluence keskkonda, mille
juurdepääsu täitjale tagab tellija.
8
14. Vääramatu jõud
14.1. Kui mistahes vääramatu jõu tingimustele vastav asjaolu toob kaasa lepingu mittetäitmise lepingus
või selle lisades ettenähtud tähtajal ning selle mõju on ajutine, on lepingust tulenevat kohustust
rikkunud poole käitumine vabandatav üksnes ajal, mil vääramatu jõud kohustuse täitmist takistas.
Vääramatu jõud on mistahes asjaolu, mida pool ei saanud mõjutada ja mõistlikkuse põhimõttest
lähtudes ei saanud temalt oodata, et ta lepingu sõlmimise ajal selle asjaoluga arvestaks või seda
väldiks (nt loodusõnnetused, sõda, mobilisatsioon, võimu- ja valitsusorganite aktid jms).
14.2. Vääramatu jõu esinemise tõttu lükatakse lepingulise kohustuse täitmise tähtaeg edasi vastavalt
asjaolu mõjumise ajale, kuid mitte enamaks kui 90 päeva.
14.3. Pool, kes ei suuda oma kohustusi vääramatu jõu tõttu täita, peab viivitamatult teatama teisele
poolele nimetatud olukorra tekkimisest ja lõppemisest. Mitteteatamine või mitteõigeaegne
teatamine võtab poolelt õiguse viidata rikkumise vabandatavusele, s.o vääramatu jõu esinemisele
ning teavitamise kohustust rikkunud pool vastutab lepingulise kohustuse rikkumise eest vastavalt
lepingus sätestatule.
14.4. Kui vääramatu jõu mõju on alaline ning ei võimalda pooltel täita lepingulisi kohustusi täielikult või
osaliselt, on pooltel õigus leping üles öelda või taganeda, tehes teisele poolele vastava lepingust
ülesütlemis- või taganemisavalduse.
15. Tellija ja Täitja esindajad
15.1. Tellija esindaja(d), kes omavad õigust ja kohustust jälgida lepinguga tellija ja täitja poolt võetud kohuste täitmist, on: infotehnoloogia arenduste osakonna juhataja Annika Brauer, tel:
+372 5348 9984, e-post: [email protected] ja infotehnoloogia arenduste osakonna IT tootejuht Kairi Kessler, tel: +372 507 3702, e-post: [email protected].
15.2. Täitja esindaja(d), kes omavad õigust ja kohustust jälgida lepinguga tellija ja täitja poolt võetud kohuste täitmist, on: BC ärijuht Kairi Kallas, tel: +372 5620 0805, e-post: [email protected] ja
projektijuht Anni Haasma, tel: +372 563 3094, e-post: [email protected].
16. Lõppsätted
16.1. Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel pöördutakse lahenduse saamiseks Harju Maakohtusse.
16.2. Täitja ei või anda lepingust tulenevaid kohustusi üle kolmandale isikule ilma tellija kirjaliku
nõusolekuta. 16.3. Lepinguga seotud informatsioonilise iseloomuga teated edastatakse poolte vahel e-posti teel, sh
pretensioonid. Muud pooltele õiguslikke tagajärgi kaasatoovad teated vormistatakse kirjalikult ning edastatakse e-posti teel. Kontaktisiku e-posti aadressile edastatud teate ja pretensiooni
loevad pooled kätte saaduks koheselt pärast teate või pretensiooni saatmist.
16.4. Kontaktide muutumisest kohustub pool teist poolt koheselt teavitama. 16.5. Lepingu lisad kuuluvad poolte poolt allakirjutatud lepingu juurde ja kehtivad selle lahutamatute
osadena. 16.6. Leping on allkirjastatud digitaalselt.
Poolte rekvisiidid:
Tellija Täitja Riigimetsa Majandamise keskus OIXIO Digital AS
Rg-kood: 70004459 10351019 Mõisa/3, Sagadi küla, Haljala vald, Veskiposti tn 2/1, 10138 Tallinn
45403 Lääne-Virumaa
Tel: +372 676 7500 Tel: +372 606 2600 E-post: [email protected] E-post: [email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt) Agne Aija Liie Strenze
Juhatuse liige Tegevjuht