Pöördumine

Lisa 1

Tehniline kirjeldus

1. Mõisted ja lühendid

Mõiste / Lühend Kirjeldus

ADR Arhitektuuriline otsus (Architecture Decision Record)

Consul HashiCorp Consul – teenuste registri ja teenuse avastamise tarkvara; käesolevas

töös hinnatav alternatiiv Istiole

DoD

Valmisoleku kriteeriumid (ingl k Definition of Done) – Tellija ja Täitja vahel kokku

lepitud tingimuste kogum, mille täitmisel loetakse töö edukalt lõpetatuks ja

vastuvõetuks

EBS Majandustarkvara Oracle E-Business Suite

Edasimineku või

peatamise otsus

Ingl k Go/No-Go decision – projekti vaheetapi lõpus tehtav otsus, kas projekt on

järgmise etapi käivitamiseks valmis (edasi minna) või vajab parandusi enne

edasiliikumist (peatada)

GAP-analüüs

Lahknevusanalüüs, milles võrreldakse olemasolevat SKA infosüsteemi arhitektuuri

tulevikuvisiooniga (TO-BE), et selgitada välja ja prioriseerida lahknevuste (GAP)

likvideerimiseks vajalikud tööd

Istio Avatud lähtekoodiga (Apache License 2.0) teenuse võrgu ja teenuse avastamise

platvorm; käesolevas töös eelistatud tehnoloogiavalik

Koormuse jaotamine

(load balancing) Päringute jaotamine teenuse mitme eksemplari vahel

Kubernetes (K8s) Konteineritöökoormuste orkestreerimise platvorm

mTLS Vastastikune TLS (mutual TLS) – kahepoolne krüptograafiline autentimine

teenuste vahel, mis annab igale teenusele tagatud identiteedi

Pilootkasutuselevõtt Valitud teenuste piiratud ulatusega kasutuselevõtt, mis valideerib pakutud

lähenemist praktikas enne täismahulist kasutuselevõttu

SKA Sotsiaalkindlustusamet

SKAIS1 Sotsiaalkaitse infosüsteem (vananenud platvormil)

SKAIS2 Sotsiaalkaitse infosüsteem uus rakendus (hõlmab Ametnikurakendust ja

Iseteenindust)

Spring Cloud Spring-põhiste rakenduste hajussüsteemi mustreid (sh teenuse avastamine ja

konfiguratsioon) toetav teek

Teenuse avastamine

(Service Discovery)

Muster ja mehhanism, mille abil teenused leiavad üksteise otspunktid keskse

registri kaudu, ilma et otspunkte tuleks igasse sõltuvasse teenusesse käsitsi

konfigureerida

Teenuse võrk

(Service Mesh)

Teenustevahelise suhtluse haldamise infrastruktuurikiht (turvalisus,

marsruutimine, töökindlus ja jälgitavus), mis on teenuse avastamise loomulik

edasiarendus

2. Ülevaade

Sotsiaalkindlustusamet (SKA) kasutab ülesannete täitmiseks sotsiaalkaitse infosüsteemi, mis koosneb SKAIS1,

EBS ja SKAIS2 rakendustest. Tegemist on infosüsteemiga, mida on arendatud hulk aastaid nii, et uute

funktsionaalsuste loomise kõrval ei ole jätkunud ressurssi tehnoloogilise ajakohasuse tagamiseks. Süsteemis

tekkinud oluliste kitsaskohtade leevendamiseks käivitati 2025. aastal SKA infosüsteemi arhitektuuri

tulevikuvisiooni (TO-BE lahenduse) väljatöötamise projekt, mille käigus loodi arhitektuuri reeglistik, millele

peavad vastama teostatavad arendused ning migreerimisplaan. Ühtlasi kaardistati probleemid ja eesmärgid,

teostati GAP-analüüs, st võrreldi olemasolevat lahendust TO-BE arhitektuuriga, et selgitada välja ja

prioriseerida GAP likvideerimiseks vajalikud tööd. Lisaks oli juba varasemast teada kitsaskohti (nt seotud

teenustevahelise suhtlusega), mis vajavad lahendamist.

Käesolev leping koondab SKAIS2 teenustevahelise suhtluse arhitektuuriliste tööde eeltööd, et tagada süsteemi

operatiivne töökindlus ja skaleeritavus teenuste arvu kasvades. Selle lepingu tööde tulem võimaldab edasi

minna laiaulatuslikuma teenuse avastamise kasutuselevõtu ja teenuse võrgu töödega. Käesoleva lepingu

skoobis on teenuse avastamise arhitektuuri ja tehnoloogiavaliku kirjeldus (ADR-ide kujul) ning valitud

teenustega pilootkasutuselevõtt, mis valideerib pakutud lähenemist praktikas (nii Kubernetese kui

virtuaalmasinate keskkonnas) ja kalibreerib edasiste etappide töömahuhinnangud.

2.1. GAP 2.2. Teenuse avastamine (Service Discovery)

SKAIS on välja arenenud monoliitsest infosüsteemist, kus teenustevahelist suhtlust praktiliselt ei olnud.

Eraldiseisvate teenuste arvu kasvades hakati igale teenusele käsitsi sõltuvate teenuste otspunkte

konfigureerima ja tänaseks on dubleeritud otspunktide konfiguratsioon kasvanud suureks. GAP 2.2 töö eesmärk

on võtta kasutusele keskne teenuste register, mis võimaldab teenustel üksteist leida ilma otspunkte igasse

teenusesse käsitsi konfigureerimata ja toimib nii Kuberneteses kui virtuaalmasinates, säilitades samal ajal selge

arengutee kõikehõlmava teenuse võrgu suunas.

GAP-analüüsi raames on koostatud teenuse avastamise arhitektuuriettepanek (vt lisainfo allpool), mis annab

tervikpildi probleemist, peamistest riskidest, soovituslikust tehnoloogiavalikust ja edasisest arengusuunast.

Ettepaneku peamised järeldused:

1. Dubleeritud ja käsitsi hooldatav otspunktide konfiguratsioon muudab süsteemi operatiivselt hapraks:

see soodustab süsteemi tööd häirivaid inimlikke vigu, ei võimalda teenuseid skaleerida nii, et lisatud

eksemplarid muutuksid sõltuvatele teenustele kättesaadavaks, ega paku keskset koormuse jaotamise

võimalust.

2. Lahenduseks on keskne teenuste register, mis peab olema piisavalt paindlik, et pakkuda teenuse

avastamise võimekust nii virtuaalmasinates kui Kuberneteses käivitatavatele teenustele.

3. Tehnoloogiavaliku puhul on praegu parim valik Istio, võimaliku alternatiivina HashiCorp Consul. Istio

kasuks räägivad avatud ja tingimusteta litsents (Apache License 2.0), de facto standardi seisund teenuse

avastamise ja teenuse võrgu pakkujana, tugi Spring-põhistele rakendustele väheste

koodimuudatustega, iga teenuse krüptograafiliselt tagatud identiteet (mTLS ja asukohast sõltumatu

adresseerimine) ning selge arengutee kõikehõlmava teenuse võrgu suunas.

4. Peamised puudused on oma olemuselt ajutised ja seotud Kubernetese ja virtuaalmasinate keskkondade

ühildamisega: esialgne ülesseadmise keerukus, suurem esialgne õppimisvajadus, hilisema

tehnoloogiavahetuse kulukus ja vajadus eraldi lahenduse järele kohalikus arenduskeskkonnas. Mida

suuremas ulatuses SKAIS Kubernetese platvormile üle läheb, seda väiksemat mõju need puudused

avaldavad.

5. Teenuse avastamise kasutuselevõtul peab säilima võimalus käivitada rakendusi ka ilma teenuse

avastamise funktsionaalsuseta (oluline nii kohaliku arenduskeskkonna kui tagasiühilduvuse

seisukohast). Teenuse registreerimist saab juhtida Spring Cloud parameetritega

(spring.cloud.discovery.enabled) ja klientide puhul saab kasutada varulahendust, mis pöördub

otspunkti URL-i poole teenuse registrinime asemel.

Käesoleva lepingu skoobist jäävad välja teenuse avastamise täismahuline kasutuselevõtt kõikidele SKAIS2

teenustele, täieliku teenuse võrgu funktsionaalsuse realiseerimine (täpsem marsruutimine, töökindlusmustrid

ja kõikehõlmav teenustevaheliste päringute turvapoliitika) ning SKAIS2 üleminek Kubernetese platvormile.

Need kuuluvad GAP 3.3 (Teenuse võrk) ja GAP 3.1 (Kubernetes) skoopi ning tellitakse eraldi lepingutega

käesoleva lepingu väljundite alusel.

2.2. Sõltuvus paralleelsete GAP-töödega

GAP 2.2 on eeltingimuseks GAP 3.3 (Teenuse võrk / Service Mesh) tööde sisukokkuleppele: SKAIS Arhitektuur TO-BE lehel on GAP 3.3 sõnastatud nii, et see tugineb GAP 2.2 raames loodud teenuse avastamise võimekusele ja laiendab Istio kasutust kõikehõlmava teenuse võrgu mustriks. Käesoleva lepingu väljundid (kinnitatud ADR- id, pilootkasutuselevõtu tulemid ja edasimineku või peatamise otsus) on sisendiks GAP 3.3 ja teenuse avastamise täismahulise kasutuselevõtu kava koostamisele.

 SKAIS Arhitektuur TO-BE, GAP 2.2 Teenuse avastamine (Service Discovery) arhitektuuriettepanek:

o SKAIS2 wiki (https://wiki.sm.ee/spaces/SKAIS2/) → SKAIS Arhitektuur TO-BE → GAP analüüsist tulenevad tööd → GAP projektid → 2.2. Teenuse avastamine (Service Discovery)

 Seotud GAP-projektid SKAIS Arhitektuur TO-BE lehel:

o 3.3 Teenuse võrk (Service Mesh) (tugineb GAP 2.2 tulemitele)

o 3.1 Kubernetes (Istio on Kubernetese-põhine tehnoloogia; teenuse avastamine peab toimima ka virtuaalmasinates)

o 2.1 API lüüsi loomine (väline liiklus, erinevalt sisemisest teenustevahelisest avastamisest)

o 3.2 Tarneprotsessi moderniseerimine (paigaldus ja konfiguratsioonihaldus)

o 2.3 Jälgitavus (teenustevaheliste päringute seire)

3. Töö eesmärk

Töö eesmärk on luua SKAIS2 teenuse avastamise kasutamise põhimõtted ja neid toetavad arhitektuurilised

otsused (ADR-id), sh kinnitada keskse teenuste registri tehnoloogiavalik. Lähtudes GAP-analüüsi raames

koostatud teenuse avastamise arhitektuuriettepanekust, valideeritakse loodud põhimõtteid valitud teenuste

pilootkasutuselevõtu kaudu nii Kubernetese kui virtuaalmasinate keskkonnas. Töö tulemina esitatakse

järgmiste tööde (GAP 3.3 ja teenuse avastamise täismahuline kasutuselevõtt) skoop ja sellest tulenev

mahuhinnang.

Pilootkasutuselevõtu lähtekood ja konfiguratsioon loovutatakse Tellijale tootmiskvaliteediga kujul. Tellija

(TEHIK või Tellija valitud kolmanda osapoole partner) paigaldab need toodangusse omal valitud ajal ja viisil.

4. Tellitavad tööd

Lepinguga tellitakse SKAIS2 teenuse avastamise kasutuselevõtu põhimõtted ja nende valideerimine valitud

mikroteenustega vähemalt järgmises ulatuses:

 Teenuse avastamise arhitektuuri ja tehnoloogiavaliku otsuste lukustamine ADR-idena, sh näiteks:

o keskse teenuste registri tehnoloogiavalik (Istio eelistatud, HashiCorp Consul alternatiivina) koos valiku põhjenduse ja hindamiskriteeriumidega;

o teenuse avastamise toimimine hübriidkeskkonnas (Kubernetes ja virtuaalmasinad) ning sellega seotud halduslahendus;

o teenuste krüptograafilise identiteedi (mTLS) ning teenusepõhise, asukohast sõltumatu adresseerimise mudel;

o klientide adresseerimismudel ja varulahendus (teenuse registrinimi või otspunkti URL);

o kohaliku arenduskeskkonna ja tagasiühilduvuse mudel (teenuse avastamise väljalülitatavus, spring.cloud.discovery.enabled);

o koormuse jaotamise ning teenuse mitme eksemplari adresseerimise põhimõtted.

 Keskse teenuste registri pilootkeskkonna ülesseadmine ja valitud SKAIS2 mikroteenuste liidestamine teenuse avastamisega. Teenused valitakse Tellija ja arhitektuuripartnerite ühisarutelu tulemusena selliselt, et kaetud oleks nii Kuberneteses kui virtuaalmasinas käivitatav teenus ja vähemalt üks tegelik teenustevaheline päring (kliendi ja teenuse vahel).

 Olemasolevate teenuste väheste koodimuudatustega liidestamise valideerimine ning dubleeritud otspunktide konfiguratsiooni asendamine teenuse avastamisega piloodi ulatuses.

 Kohaliku arenduskeskkonna lahendus, mis võimaldab rakendusi käivitada ka ilma teenuse avastamise funktsionaalsuseta (varulahendus), ning tagasipööramise strateegia teenuse avastamiselt senisele konfiguratsioonipõhisele adresseerimisele.

 Taaskasutatav teenuse avastamisega liidestamise muster ja juhend (sh konfiguratsioon ja Helm- chartide muudatused), mis on aluseks järgnevatele teenuste liidestamise lainetele ja GAP 3.3 (Teenuse võrk) tööle.

 Testimisstrateegia ja valmisoleku kriteeriumid (DoD) iga pilootteenuse jaoks, sh vastutuste jaotus testimisel, nõutavate automaattestide minimaalne kogum ja kvaliteedikriteeriumid piloodi vastuvõtuks.

 Pilootkasutuselevõtu tulemuste tagastusring koos töömahu kalibreerimisega ning edasimineku või peatamise otsus järgmise faasi (täismahuline kasutuselevõtt ja GAP 3.3) käivitamiseks.

 Muud arendusvajadused, mis selguvad analüüsi käigus ja on olulised realiseerida käesoleva lepingu skoobis.

 Tööde loetelu tekib eelnevalt kokkulepitud backlogi alusel ja hallatakse Jiras.

5. Tööprotsess ja tulemid

Järgnevalt täpsustatakse Täitjaga sõlmitud lepingus kirjeldatud tingimusi tööprotsessi, dokumenteerimise,

töökorralduse, testimise ja mittefunktsionaalsete nõuete osas.

5.1. Tööprotsess

 Tööraamistik peab tuginema etapiviisilisele planeerimisele, võimaldades arendusmeeskonna prioriteete jooksvalt muuta;

 Tööraamistik peab võimaldama süsteemset ülevaadet iga kokkulepitud töö saavutustest;

 Tööraamistik peab võimaldama arendusmeeskonna tulemuslikkuse (kasvu) jälgimist ajas;

 Tööraamistik peab tagama, et arendusmeeskond tegeleb omal initsiatiivil enda tulemuslikkuse parandamisega ja parendusettepanekute esitamisega.

 Täpsem protsess lepitakse kokku tööde käigus.

5.2. Dokumentatsioon

Vastavalt tehnilise kirjelduse punktis 4 (tellitavad tööd) tuleb töö käigus luua ja täiendada SKAIS2

dokumentatsiooni, milleks on minimaalselt:

 Funktsionaalsuse ja äriprotsesside kirjeldused kokkulepitud kujul (nt BPMN standard, diagrammid ja kirjeldused Confluence’is) koos ärireeglitega, mida peab olema hiljem võimalik täiendada järgnevates etappides lisanduva funktsionaalsuse alusel ning siduda tervikliku protsessi- ja ärireeglite kirjeldusega.

 Tehniline dokumentatsioon (nt paigaldusjuhendid, Confluence keskkonnas).

 Andmemudel.

 Kasutusjuhendid.

 Dokumentatsiooni täpsed liigid ja sisu formaat lepitakse kokku tööde käigus, kuid see peab vastama minimaalselt järgnevatele nõuetele: Nõuded arendusprojektide dokumentatsioonile SKAISi näitel - SKAIS2 - Sotsiaalministeeriumi wiki

5.3. Töökorraldus

Projekti töökorraldus toetub raamlepingu kodukorrale (lisa 5) ja töökorralduslikele kokkulepetele. Täitja peab

tagama piisava kaasamise ja ülevaadete andmise Tellijale.

5.4. Tööde üleandmine

Arendustööde lähtekoodi tarne toimub pideva integreerimise (continuous integration) teel. Tööde järjekord,

üleandmise aeg ja UAT tagasiside andmise aeg lepitakse kokku tööde käigus taasesitamist võimaldavas vormis

(tellija ja täitja poolt).

Töö üleandmisel kontrollib tellija üle töö nõuetekohasuse ning annab vajadusel tähtaja töö parandamiseks.

Täitja teab, et tellija võib igat üle antud funktsionaalsust paigaldada toodangusse ning täitja peab tagama, et

lõplikult valmimata funktsiooni protsessid on võimalik toodangust välja lülitada (feature flags). Funktsioonide

sisse-välja lülitamise võimekus lepitakse tellija ja täitja vahel kokku tööde käigus.

5.5. Nõuded automaattestimisele

Automaattestimise nõuete täitmisel tuleb lähtuda nõuetest, mis on leitavad siit: Automaattestide nõuded.

Testidega kaetakse serveripoolne ja kasutajaliidese kood. Kaetavuse kontrolliks ja raporteerimiseks seatakse

tellija koodihoidla keskkonnas (Gitlab) üles pideva integratsiooni töövoog, mis seadistatakse koostoimima

SonarQube koodi ja testide kaetavuse analüsaatoriga.

Automaattestid peavad üle antavas lähtekoodis continuous-integration’i töövoo edukalt läbima. Samuti peab

täitja hoolt kandma, et varasemalt loodud testid jäävad töö lõpetamisel edukalt läbitavaks. Nõuete muutumisel

peab täitja viima testid vastavusse uute nõuetega või neid eemaldama, kui selliseid nõudeid enam ei eksisteeri.

Teenuse avastamisega liidestatud pilootteenus peab edukalt läbima ka olemasolevad süsteemiülesed

regressiooni- ja suitsutestid, tõendamaks, et üleminek teenuse avastamisele ei ole rikkunud teenuse väliseid

API-lepinguid ega teenuste vahelist suhtlust.

5.6. Koormustestimised

Iseteenindus peab toetama paralleelset minimaalselt 200 päringut (siinkohal on oodatav arendajapoolne

hinnang, kas see on piisav päringute maht, vajadusel tõsta arvu).

API teenustele ning keskmine päringu teenindamise aeg ei tohi olla suurem kui 2 sekundit.

Nõude täitmise kontrolliks tuleb luua koormustestid. Koormustestide tegemine lepitakse tellija ja täitja poolt

kokku tööde käigus.

Nõudest eraldi tuleb vaadelda staatiliste failide allalaadimist – need tuleb http serveris puhverdada.

5.7. Mittefunktsionaalsed nõuded

Mittefunktsionaalsete nõuete täitmisel tuleb lähtuda järgnevast:

 Uue funktsionaalsuse loomisel tuleb lähtuda raamlepingu (nr 3-9/3443-1) ja selle lisades kirjeldatud nõuetest

 Täpsemad mittefunktsionaalsed nõuded, millest lähtuda on leitavad siit: Mittefunktsionaalsed nõuded

5.8. Tulemid

Valminud ja üleantavate tööde tulemid peavad sisaldama:

 Teenuse avastamise arhitektuuri ja tehnoloogiavaliku ADR-e (sh Istio ja Consuli vahelise valiku põhjendus);

 Pilootkasutuselevõtu käigus tuvastatud täiendavate otsustuskohtade kaardistust;

 Keskse teenuste registri pilootkeskkonna konfiguratsiooni ning pilootteenuste teenuse avastamisega liidestatud tootmiskvaliteediga lähtekoodi ja konfiguratsiooni (sh Helm-chartide muudatused);

 Taaskasutatavat teenuse avastamisega liidestamise mustrit ja juhendit (sh kohalik arenduskeskkond ja varulahendus);

 Töömahu kalibratsioonidokumenti ja tagastusringi protokolli koos edasimineku või peatamise otsusega;

 Viiteid dokumentatsioonile Confluence’is;

 Viiteid tehtud töödele (Jira piletitena);

 Viiteid koodile GitLabis;

5.9. Tööde teostamise tähtaeg

Tööde üleandmise (so Jira piletid "Ready for AT" ja toodangu keskkonda paigaldatav kvaliteetne lähtekood) tähtaeg on 30.09.2026. Tööde üleandmisele järgneb tellija poolne tööde testimine mõistliku aja jooksul ja

vajadusel täitja poolne paranduste või täienduste tegemine, kui tööd ei ole tähtajaks teostatud nõuetekohaselt või tellijal tekib vajadus väiksemamahuliste täienduste koheseks realiseerimiseks. Tööd loetakse teostatuks tööde üleandmise-vastuvõtmise akti tellija poolt allkirjastamise hetkest. Tellijal on õigus pikendada tööde üleandmise tähtaega, kui ilmneb tööde ajakavas täitjast sõltumatuid olulisi viivitusi.

Hankelepingu projekt

Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Pärnu

mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm ja

_____ (edaspidi täitja), registrikood_______., aadress ________, keda esindab põhikirja alusel _____,

edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr ____ alusel käesoleva hankelepingu

(edaspidi leping) alljärgnevas:

1. Lepingu ese

1.1. Lepingu esemeks „SKAIS2 GAP 2.2 Teenuse avastamine“ on tehnilises kirjelduses nimetatud

tööd (edaspidi tööd).

1.2. Lepingu tööde maht on kuni 110 000 (sadakümme tuhat) eurot ilma käibemaksuta.

2. Töö üleandmise ja vastuvõtmise tingimused

2.1. Täitja annab töö üle 30.09.2026.

2.2. Töötunni põhise lepingu korral esitab täitja eelmise kuu töötundide ajaaruande, mis sisaldab

teostatud töötunde ja nende jooksul teostatud töid. Ajaaruanne esitatakse allkirjastatult

hiljemalt järgmise kalendrikuu 5. tööpäeval. Viimane ajaaruanne esitatakse koos aktiga.

2.3. Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu tehnilises kirjelduses

kokkulepitud tingimustele.

2.4. Tellija vaatab töö üle vastavalt raamlepingu tingimustele.

2.5. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused

vastavalt raamlepingus kirjeldatule.

3. Lepingu hind

Kui tegemist on töötunnipõhise lepinguga:

3.1. Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel

tellitud ja teostatud töötundide eest.

3.2. Ühe töötunni maksumuseks lepingu täitmisel on ____ (maksumus sõnadega) eurot

käibemaksuta.

4. Poolte vahelised teated ja kontaktisikud

4.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist.

4.2. Tellija kontaktisikuks lepingu täitmisel on Ranel Tasane tel 56252707, e-post

[email protected] või tema asendaja.

4.3. Täitja kontaktisikuks lepingu täitmisel on ________, tel ________, e-post ______ või tema

asendaja.

5. Lõppsätted

5.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma

lepinguliste kohustuste täitmiseni.

5.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu

muudatustest ja pakkumusest.

5.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid, mida

ei allkirjastata koos lepinguga:

5.3.1. Lisa 1 - Tehniline kirjeldus;

5.3.2. Lisa 2 – Pakkumus;

6. Poolte allkirjad

Tellija: Täitja:

HANKIJA NIMI: Tervise ja Heaolu Infosüsteemide Keskus Pakkumusettepaneku nimetus: „SKAIS2 GAP 2.2 Teenuse avastamine“ Käesolevaga teeb Tervise ja Heaolu Infosüsteemide Keskus (Hankija) Teile ettepaneku esitada pakkumus „SKAIS2 GAP 2.2 Teenuse avastamine“ teostamiseks raamlepingu nr 3-9/4283-1 alusel.

Hankija soovib hankelepingu sõlmida ühe partneriga. Pakkumuse esitamise tähtaeg on 26.06.2026

kell 12:00. Pakkumus saata e-posti aadressile [email protected].

Pakkumus tuleb esitada eesti keeles ja digitaalselt allkirjastatuna.

Pakkumus esitatakse Hankelepingu tehnilises kirjelduses (lisa 1) toodud tööde teostamiseks.

Alternatiivsete pakkumuste esitamine ei ole lubatav. Pakkumus peab olema jõus minimaalselt 30

päeva.

Pakkumusena tuleb esitada:

- Tööde teostamiseks planeeritud meeskonnaliikmed isikuliselt, tuues välja ka

meeskonnaliikmete roll;

- Tööde teostamise ühe töötunni hind (ilma käibemaksuta).

Töid teostatakse jooksva tunnihinna arvestuse põhiselt. Tööde ajaaruandes tuuakse välja tööde

teostamiseks kulunud töötunnid isikute lõikes, seostades nimetatud isikud Jiras logitud

tööülesannete ja kirjeldatud tegevustega.

Töid tellitakse mahus kuni 110 000 (sadakümme tuhat) eurot (ilma km-ta). Pakkumuse esitamisega

kinnitab pakkuja, et lepingu tähtaja saabumiseks on teostatud Hankelepingu eseme tehnilises

kirjelduse (lisas 1) punktis 4 kirjeldatud tööd. Pakkujal ei ole õigust tööde teostamiseks nõuda

ajapikendust, täiendavat tasu või väljamakseid.

Küsimuste tekkimise korral palun võtke ühendust enne pakkumuse esitamise tähtaega aadressil [email protected]. Pakkumusettepanekuga koos edastatavad dokumendid:

Lisa 1. Hankelepingu eseme tehniline kirjeldus; Lisa 2. Hankelepingu projekt.