OTSUS maksest keeldumise ja toetuse taotluse rahuldamise otsuse kehtetuks tunnistamise kohta

Lugupeetud toetuse saaja

Rakendusüksus annab teada, et algatab projektis nr 20.1.01.25-0981 järelevalvemenetluse,

sest lõpparuande kontrollimisel tuvastati, et toetuse saajal on näitaja „Lõpetatud projektide

arv“ saavutatud osaliselt. Valminud projekt ei vasta täies mahus planeeritud tulemustele.

Seega on rikutud kohustust viia projekt ellu vastavalt planeeritule ning saavutada kavandatud

tulemused. Makse aluseks olevad tegevused ei ole täies ulatuses ellu viidud (meetme määrus

§ 4 lg 1) ja toetust ei ole kasutatud vastavuses taotluse rahuldamise otsusega (meetme

määrus § 25 p 2).

Meetme ühendmääruse § 11 lõike 4 kohaselt kohustuse või tingimuse täitmata jätmise

laadist tulenevalt vähendatakse toetust 2, 5, 10, 25, 50, 75 või 100 protsenti projektile või

selle tegevusele eraldatud toetusest.

Täpsem finantskorrektsiooni määr selgub järelevalvemenetluse jooksul.

TOETUSE SAAJA VASTUS

Lugupeetud Riigi Tugiteenuste Keskus

Vastuseks Teie 14. jaanuaril 2026 saadetud teatele projektis nr 20.1.01.25-0981

järelevalvemenetluse algatamise kohta, esitame siinkohal alljärgneva seisukoha.

I. Täpsustused viidatud õigusnormide rakendatavuse kohta

1. Meetme määruse § 23 lg 4 p 1 - tegevuste elluviimise eeldusena

Teie poolne viiteparandus varasemalt ekslikult viidatud § 4 lg 1 asemel on mõistetav - § 23 lg

4 p 1 sätestab, et:

„Makse teostatakse eeldusel, et makse aluseks olnud tegevused on ellu viidud“.

Täname viite parandamise eest, kuid rõhutame järgmist:

• antud säte eeldab sisulist seost makse aluseks olnud tegevuse ja selle tegeliku

elluviimise vahel;

• toetuse saaja kohustuseks ei ole täitmine üksikaktiivsusena 100% täpsusega, vaid

projekti eesmärgipärane ja proportsionaalne elluviimine - seda eelkõige juhul, kui

osa planeeritud tegevusi osutub sõltuvaks kolmandatest osapooltest, nende ulatus

muutub MVP arenduse käigus ebaproportsionaalseks või on lahendatud teistmoodi

kui esialgses plaanis, kuid pakkudes samaväärset lõpptulemust MVP jaoks;

• Euroopa Liidu rahastusmeetmete praktika kohaselt (sh Euroopa Komisjoni

rakendusmäärused nr 1303/2013 ja selle asendusmäärused) on makse aluseks

eeskätt projekti sisuline edasiliikumine, tulemuste mõju ning läbipaistva

kulukasutuse tuvastatavus, mitte formaalne 1:1 täitmine iga deklaratiivse

alamtegevuse tasandil.

Sellest tulenevalt on oluline teha selge eristus:

• kas kogu projekti elluviimine on sisuliselt toimunud (jah, MVP valmis, tööriist

töötab, testiti);

• või kas mingi spetsiifiline detail ei ole MVP faasis valmis saanud, mille tõttu kogu

projekt sisuliselt ebaõnnestus (ei vasta tõele, ei ole aktuaalne).

Käesolevas juhtumis on tegemist esimese juhtumiga: tööriista MVP versioon on valmis,

testitud, ning töötab, täites seda rolli, mis projekti alusplaani hüpoteesis eesmärgiks sai

võetud luua.

2. Meetme määruse § 24 - toetuse tagasi nõudmine proportsionaalsuse põhimõttel

§ 24 sätestab:

„Vahendusasutus nõuab toetuse tagasi proportsionaalselt rikkumise ulatusega taastekava

määruse § 11 lõikes 1 toodud alustel.“

Siinkohal juhime tähelepanu:

• toetus ei ole määratud selleks, et tagada tehniliste prototüüpide täielik äriküpsus,

vaid toetada MVP valmimist ja selle väärtuspakkumise valideerimist. RTK käsitleb

oma järelvalvemenetluses lahendusele hetkel ootust kui nö Production-grade tootele.

Sellest järeldub: proportsionaalsuse hindamine peab toimuma sisuliselt, arvestades:

• kas midagi on reaalselt puudu ja kas selle puudumise mõju projekti tegelikule

kasutatavusele (väike kuni olematu - tööriist on toimiv, veebis kättesaadav, kasutatav).

II. Projekt on edukalt ellu viidud

1. Projekti eesmärk: toimiv MVP

Toetuse eesmärk oli luua digitaalse tööriista MVP koduse solar-varjualuse automatiseeritud

planeerimiseks ja tellimiseks. Eesmärk oli luua prototüüp, mitte valmis lõpptoode, mitte

äriküps tarkvara ega täielik integratsioon.

Toetuse eesmärgiks ei ole olnud lõplik, äriliselt turule valmis toode ega täielik tehniline

valmisolek, vaid digitaalse prototüübi (MVP) loomine, mis võimaldab:

• testida lahenduse väärtuspakkumist,

• valideerida sihtrühma kasutuspotentsiaali,

• valideerida esialgu valitud tehnoloogia ja tehnoloogilise lähenemise mõistlikkus, ning

• luua alus edasiseks skaleerimiseks.

Toetuse eesmärk ei olnud veebis kättesaadava lahenduse loomine, sest veebis kättesaadav

ei saa olla enam MVP, vaid veebis inimestele kättesaadav peab olema Production-ready.

See järeldus tuleneb otseselt:

• meetme seletuskirja eesmärgikirjeldusest,

• hindamisprotsessi dokumentatsioonist ning

• RTK varasemast praktikasõnumist, et MVP ei pea sisaldama kõiki

lõppfunktsionaalsusi.

2. Konkreetsed projektidokumentatsioonis nimetatud integratsioon oli projekti

visiooniline, mitte MVP-faasi realiseerimise kriitiline komponent, ning mitte miski, mida 1:1

peab järgima lõpp-eesmärgi saavutamiseks.

Taotluses kirjeldatud EHR liidestus oli kirjeldatud kui ühe lahendusena ning pikema visiooni

komponent ning kavandatud tulevikusuunana, mitte MVP toimimise kriitiliseks eelduseks

täpselt sellisel kujul. Projekti töötava versiiooni tegelik MVP sisaldas järgmisi komponente,

mis on edukalt teostatud:

• konfigureerimistööriist,

• hinnamoodul,

• kasutajaliides,

• avaandmete (rasterandmete) kasutamine (EHR API integratsiooni asemel)

• veebiplatvormi testimine sihtrühmaga.

EHR integratsioon oli kirjeldatud kui pikema visiooni komponent ja tuleviku suund, kuid

mitte:

• MVP kriitiline komponent;

• Ainukene võimalik tehniline lahendus projekti realiseerimisel (lahendatud antud

puhul hoopis avaandmete kasutamisega)

• makse eeldus;

tegevus, mille puudumine nullib kogu projekti eesmärgi. Sh on oluline märkida, et on igati

normaalne, et projekti arenedes osutub esialgne valik ebapraktiliseks või -efektiivseks, sh

tehnoloogiad või integratsioonid, mis on esialgu planeeritud, ning lahendamise käigus

kasutatatakse alternatiivseid viise.

Käesolevas projektis valmis:

• kasutajaliides;

• automaatne konfiguratsioonitööriist varjualuse spetsifikatsioonide valimiseks;

• automaatne hinnastamise võimekus vastavalt spetsifikatsioonile;

• dokumentatsiooni eelvormistamise võimaluse loomine (klient ei pea hoolitsema

paberimajanduse eest, märgib lihtsalt konfiguraatoris, et soovib, et see tema eest

projekti koosseisus ära lahendatakse (alternatiiv on, et tal on juba load menetletud ja

vaja vaid ehitada);

• tagasiside põhjal tehtud täiendused;

• väärtuspakkumine valideeriti reaalse sihtrühmaga.

Tööriist on:

• toimiv ja avalikus veebis kasutatav (canopies.me),

• testitud pilootkasutajatega,

• võimeline genereerima sisulist väärtust lõppkasutajale.

III. Õiguslik järeldus

Lähtudes eespool toodust palume Teil:

1. Kinnitust, et määruse § 23 lg 4 p 1 hindamisel ei eeldatud tegevuste täielikku, 100%

tehnilist valmimist, vaid MVP-faasis sisulist toimivust ja testitavust;

2. Tunnistada, et projekti eesmärk - toimiva MVP loomine - on täidetud;

3. Arvestada, et projekti esialgses taotluses välja toodud konkreetsed tehnilised

lahenduste lähtepunktid ei saa olla ainuõiged ning ainsad läheneimsed ning on

lahendatavad alternatiivselt, kui täidetakse projekti lõppeesmärk.

4. Kinnitada, et ei rakendata finantskorrektsiooni enne, kui on hinnatud:

a) projekti sisulist tulemuslikkust;

5. Tõdeda, et toetuse saaja ei ole eksinud määruse § 25 p 2 vastu, kuivõrd toetus on

kasutatud rahastamisotsuse eesmärgipäraselt, läbipaistvalt ja heauskselt.

Kuna RTK oma küsimustes ja käsitluses kasutab tooni, nagu oodanuks tulemusena nö

Production-grade lahendust, siis tuletame meelde, et projekti taotlus ja töö skoop on

koostatud MVP jaoks. Siinkohal toome välja ka MVP ja valmislahenduse võrdluse.

MVP (Minimum Viable Product) on

väikseim võimalik töötav asi, millega saab:

• tõestada, et probleem on päris

• tõestada, et lahendusloogika töötab

• saada päris kasutajalt tagasisidet

• teha otsus: kas, kuidas ja kuhu edasi investeerida

MVP fookus on õppimisel, mitte skaleerimisel.

MVP vastab eelkõige küsimustele:

• Kas see probleem on kasutajale piisavalt valus?

• Kas see lahendusloogika lahendab probleemi?

• Kas kasutaja saab väärtusest aru?

• Kas protsess on loogiline, isegi kui tehnika on robustne?

MVP ei pruugi sisaldada kõiki lõppfunktsioone ja liidestusi - tähtis on töötav prototüüp, mis

on arendatav edasi.

Võrdlustabel

Aspekt MVP Production

Eesmärk Õppida Teenindada

Fookus Kas see töötab? Et see ei katki

Kasutajad 5–50 1000+

Integratsioonid Mock / piiratud Täisautomaat

Veakäsitlus Minimaalne Süsteemne

Turvalisus Baastase Auditit taluv

Skaleerimine Pole oluline Kriitiline

Seoses järelevalvemenetlusega palume teil vastata järgmistele küsimustele:

1. Iga punkti taha märkida koos selgitusega, kas tegevus on tehtud täies ulatuses või mitte

(märkida, mis täpsemalt on tegemata):

1.1. Kasutajaliidese ja prototüübi funktsionaalsuste arendamine

1) Kasutajaliidese arendus:

a) Kujundatakse kasutajasõbralik ja intuitiivne liides, mis võimaldab lõpptarbijal lihtsalt

sisestada aadress ning valida sobiva konfiguratsiooniga varjualune (asukoht, mõõtmed,

lisafunktsioonid) ning saada automaatne hinnapakkumine.

b) Disainitakse kasutajaliides selliselt, et see toetab lõppkasutajate (koduomanike)

minimaalseid tehnilisi teadmisi.

2) Funktsionaalsuste arendus:

a) Arendatakse hinnakalkulatsiooni funktsioon, mis suudab reaalajas arvutada projekti

maksumuse, võttes arvesse materjalide hinda, tööjõukulu ja paigaldusaega.

b) Integreeritakse algne materjalide kalkulatsiooni moodul, mis ühendub tarnijate

andmebaasidega, et pakkuda kasutajale täpset hinnainfot.

c) Lisatakse funktsioon, mis genereerib automaatselt vajalikke tehnilisi dokumente (nt

projekti joonised ja spetsifikatsioonid).

1.2. Andmete ja süsteemide integreerimine

1) E-Ehituse platvormiga liidestamine:

a) Arendatakse liides, mis võimaldab projekti dokumente ja andmeid automaatselt saata

Ehitisregistrisse (EHR), tagades nende vastavuse kehtivatele nõuetele.

b) mehhanism, mis kontrollib automaatselt, kas projekt vastab kohalike omavalitsuste ja

riiklikele regulatsioonidele.

2) Pilvetehnoloogia kasutamine:

a) Rakendatakse pilvepõhiseid andmeladustamise lahendusi, et tagada kiire ja skaleeritav

andmete haldamine.

b) Tugevdatakse andmete turvalisust vastavalt GDPR-i ja muudele privaatsusnõuetele.

1.3. Testimine ja veaparandused

1) Pilootkasutajate kaasamine:

a) Prototüüpi testitakse väikese grupi pilootkasutajatega, kuhu kuuluvad eramajaomanikud,

varjualuste paigaldajad ja kohalike omavalitsuste esindajad.

b) Testimisel hinnatakse:

- Platvormi funktsionaalsust ja täpsust.

- Kasutusmugavust lõppkasutajate jaoks.

- Süsteemi töökindlust ja vigade esinemist.

2) Tagasiside kogumine ja analüüs:

a) Kogutud tagasiside põhjal täiustatakse kasutajaliidest, parandatakse funktsionaalsuste

kitsaskohti ja lisatakse kasutajate soovitud täiendused.

3) Veaparandused:

a) Eemaldatakse kõik tuvastatud vead ja parandatakse süsteemi stabiilsus enne platvormi

ametlikku lansseerimist.

TOETUSE SAAJA VASTUS

Tegime võrdleva analüüsi esitatud projektitaotluse sisu ja RTK järelevalvemenetluses esitatud

küsimuste-väidete vahel.

RTK on mitmel juhul laiendanud või moonutanud meie projektitaotluses esitatud termineid,

mistõttu ei ole mõistlik üleval olevat küsitlust täiesti ümber kirjutada ja oleme loonud

käesoleva alamlehe. Allpool on detailne ülevaade sellest, kus on oluline sõnastuslik või

sisuline erinevus, kus RTK on eksitavalt üldistanud või lisanud/moonutanud elemente, mida

meie projektis ei olnud üldse või viidatud kujul.

1.1 Kasutajaliidese ja prototüübi funktsionaalsuste arendamine

▪ RTK sõnastus: Kujundatakse kasutajasõbralik ja intuitiivne liides, mis võimaldab

lõpptarbijal sisestada aadress ning valida sobiva konfiguratsiooniga varjualune...

Meie projektitaotlus: ei sisalda nõuet ega kirjeldust aadressi sisestamise või

geokodeerimise funktsionaalsuse kohta.

Märkus:

RTK on esitanud detaili ("sisestada aadress"), mis ei sisaldu taotluse tekstis. Tegemist

on funktsiooniga, mille olemasolu ei olnud lubatud ega eeldatud. See on oluline, kuna

geokodeerimine ja aadressiotsing tähendavad täiesti eraldi arendustööd ning seotud

teenuseid (nt In-ADS, Maa-amet vms). Küll aga oleme selle tõesti projekti käigus ära

lahendanud.

▪ RTK sõnastus: Funktsionaalsuste arendus: hinnakalkulatsiooni funktsioon, mis

suudab reaalajas arvutada projekti maksumuse...

Meie projektitaotlus: Arendatakse tööriist, mis kuvab automaatselt projektikulud ...

Märkus:

Sõna “reaalajas” tähistab teistsugust tehnilist ootust kui “automaatselt”. Meie

projektis ei olnud lubatud dünaamilist reaalajas arvutust tarnijate APIde kaudu - eriti

arvestades, et tarnijate andmebaase ega nende liideseid ei eksisteeri avalikult, ning

tootjatel valdavalt puudub igasugune selline tehniline võimekus. RTK poolne

"reaalajas" eeldus moonutab oodatud tehnilist ulatust ja seab projekti tehnilised

ootused täiesti erinevale tasemele võrreldes sellega, mis oli meie MVP skoop.

▪ RTK sõnastus: Lisatakse funktsioon, mis genereerib automaatselt tehnilised

dokumendid (nt projekti joonised ja spetsifikatsioonid)

Meie taotlus: Automatiseeritud dokumentatsioon ja kooskõlastamine - ette

valmistatud dokumentide registreerimine EHR-is

Märkus:

RTK on muutnud passiivse ("ette valmistatud") aktiivseks ("automaatselt genereerib

joonised"). See viitab täiesti erinevale tehnilisele tasemele. Tehnilised dokumendid on

nt CAD-generatsiooni ega BIM-failide loomine, aga ma ei ole oma projektis midagi

sellist lubanud. Seda on oluline käesolevaga vaidlustada.

1.2 Andmete ja süsteemide integreerimine

▪ RTK sõnastus: Arendatakse liides, mis võimaldab automaatselt saata dokumente

EHR-i.

Meie taotlus: Lahendus on integreeritud e-Ehituse platvormiga, eesmärgiga

automatiseerida dokumenteerimisprotsess.

Märkus:

RTK on sisuliselt tõlgendanud, nagu oleks me lubanud ehitusprojekti dokumentide

“automaatselt üles laadimist EHR-i” - mida ei ole Eesti õigusruumis üldse lubatud teha

kolmanda isiku kaudu ilma autentimiseta. Meie sõnastus "integreeritud platvormiga"

ei tähenda automaatset üleslaadimist - seda kinnitab ka praktika, et ka

professionaalid kasutavad EHR-i UI-d.

▪ RTK sõnastus: Mehhanism, mis kontrollib automaatselt, kas projekt vastab kohalike

omavalitsuste ja riiklikele regulatsioonidele.

Meie projekt: Ei sisalda sellist automaatset kontrollmehhanismi.

Märkus:

Selle funktsionaalsuse lisamine RTK poolt on täiesti põhjendamatu - tegemist oleks

õigusakti parsimise ja ehitusnõuete automaatse kontrolli tööriistaga, mida me ei ole

lubanud ehitada ega arendanud. Täielik sisuline üleliigne eeldus RTK poolt.

1.3 Testimine ja veaparandused

▪ RTK sõnastus: Prototüüpi testitakse väikese grupi pilootkasutajatega, kuhu kuuluvad

ka KOVi esindajad.

Meie projekt: kopeeritud sõna-sõnalt taotlusest - Testimine ja veaparandus:

Testitakse prototüüpi valitud sihtrühma (10-20 eramajaomanikku) seas ning

parandatakse avastatud vead ja kitsaskohad.

Märkus:

RTK on lisanud siia millegi pärast “KOV esindajad”, mida me pole kuskil maininud.

Samuti ei ole määratud testijate täpset profiili (nt ametinimetused vms), vaid

üldistatud eramajaomanikuna.

▪ RTK sõnastus: Süsteemi töökindlus ja vigade esinemine hinnatakse.

Meie projekt: Parandatakse avastatud vead ja kitsaskohad piloottestide alusel.

Märkus:

Sisuline vaste on olemas - tegemist ei ole suure erinevusega. Kui aga RTK eeldab

süsteemi tõendatud “vigadeta stabiilsust” (Production-Ready), tuleb juhtida

tähelepanu, et et antud taotluse raames on tegemist esmase prototüübiga (MVP) ja

see ei tähenda veavaba versiooni, vaid funktsionaalset ja testitud prototüüpi.

Kuna RTK poolt koostatud eelnev nimekiri on kohati või täiesti erinev sellest, mida Toetuse

Saaja on oma projekti kirjeldusse kirjutanud sh sisaldades asju, mida taotlusesse ei ole isegi

kirjutatud), siis oleme kopeerinud siia originaal-sisu taotlusest, ning märkinud vastavalt iga

punkti taha koos selgitusega, kas tegevus on tehtud täies ulatuses (TU) või mitte (märkida,

mis täpsemalt on tegemata):

Projekti raames töötatakse välja innovatiivne automaatne konfiguratsioonitööriist, mis

võimaldab koduomanikel lihtsalt ja kiiresti valida, projekteerida, hinnata ning tellida koduseid

solar-varjualuseid. Lahendus hõlmab järgmisi põhikomponente:

1. Kasutajasõbralik digitaalne platvorm - veebipõhine tööriist, kus lõpptarbija saab

valida varjualuse tüübi, mõõtmed, lisakomponendid (nt PV-paneelid, EV laadija) ning

kohandada lahendust vastavalt oma vajadustele. (TU, teostatud, esitluse videos

nähtav, toimiv lahendus)

2. Automatiseeritud dokumentatsioon ja kooskõlastamine - lahendus on

integreeritud e-Ehituse platvormiga, mis võimaldab varjualuse projekte ja

dokumente automaatselt ette valmistada ning registreerida Ehitisregistris (EHR). (TU)

Pakkumise dokumentatsioon koostatakse automaatselt vastavalt kliendi poolt valitud

spetsifikatsioonile. Mh võetakse katastri andmed avaandmetest (API integratsiooni e-

Ehitusega ei olnud vajalik selleks teha. Registreerimine ei ole peamise persona

(koduomanik) vaade, vaid projekteerija (Legalizer) vaade, mis aga ei olnud MVP

peamine fookus, vaid koduomaniku jaoks mugavuslahendus, kus ta ei pea midagi

tegema peale ühe linnukese pakkumise vormis. Kuna Legalizer ei olnud MVP fookus,

ja Ehitisregistri integratsioon käesoleva MVP raames on töö mõistes väga suur, aga

praktilisuse poole pealt ülimalt marginaalne efekt (vähem kui 1%) projekteerijale

endale, siis on MVP raames disainitud selle teekond ja loogika, kuid reaalne

integratsioon on olnud ebaproportsionaalne ning ebamõistlik.

3. Indikatiivse hinnapakkumise genereerimine – tööriist kuvab automaatselt

projektikulud ja ajakava, pakkudes lõpptarbijale kiiret ja läbipaistvat ülevaadet. (TU,

teostatud, esitluse videos nähtav, toimiv lahendus)

4. "Võtmed kätte" lahendus – tööriista kaudu on võimalik tellida terviklahendus alates

projekteerimisest kuni paigalduseni. (TU, teostatud; kui kasutaja valib võtmed kätte

lahenduse hulgas teenused, siis toimub kõik tema jaoks taustal.)

Projekti lõpus saavutatakse järgmised konkreetset olukorda muutvad ja mõõdetavad

tulemused:

1. Automaatne konfiguratsioonitööriist eramajaomanikele

o Tulemus: Valmis on kasutajasõbralik digitaalne tööriist, mis võimaldab

lõpptarbijal automaatselt modelleerida, hinnata ja tellida koduseid solar-

varjualuseid. (TU, teostatud, esitluse videos nähtav, toimiv lahendus)

o Mõõdik: Tööriista kasutusele võtab vähemalt 100 klienti esimesel aastal pärast

valmimist, sh vähemalt 20 edukalt lõpetatud projekti. (ei olnud mõõdetav KPI

projekti MVP faasis)

2. Protsesside automatiseerimine ja lihtsustamine

o Tulemus: Solar-varjualuste dokumenteerimise ja registreerimise protsess on

integreeritud e-Ehituse platvormiga, vähendades koduomanike koormust

dokumentatsiooni kooskõlastamisel. (TU)

Nagu ülesanne viitab, siis eesmärk oli vähendada koduomaniku koormust

dokumentatsiooni kooskõlastamisel. See on lahendatud sellega, et klient valib

pakkumise koostamise vormil, et soovib ka seadustamist, ja sellega on kliendi

jaoks sisuliselt kõik tehtud. See, kuidas asi on lahendatud taustal, ei ole kliendi

jaoks oluline, ning mille tõttu on edasises voos (projekteerija vs EHR) asjad

lahendatud MVP’le mõistlikus vormis.

o Mõõdik: Protsessi läbimise aeg väheneb keskmiselt 50% võrreldes

praeguse käsitsi tehtava dokumenteerimisega. (TU)

Kliendi jaoks väheneb tema aja ja ressursivajadus ideaalis 95%.

3. Ehitussektori tootlikkuse tõus

o Tulemus: Solar-varjualuste projekteerimise ja dokumenteerimise

automatiseerimine vähendab inseneride ja projekteerijate käsitsitööd,

võimaldades keskenduda suurema lisandväärtusega tegevustele. (TU)

Jah, see on tõsi. Lihtsalt antud MVP raames oli EHR integratsioon

ebaproportsionaalne, kuna keskenduti koduomanikule, kellele ostuprotsess

lihtsaks ning loogiliseks teha, ning EHR integratsioon selle jaoks ei ole vajalik.

Nagu käesolevas dokumendis läbivalt viidatud, siis EHR integratsioon selles

kontekstis on olnud täiesti ebaproportsionaalne ja vähema kui 1% efektiga kogu

projekti mõõmes. Sellest johtuvalt on kujundatud küll kogu teekond ning disain,

aga jäetud järgmiseks sammuks reaalne integratsioon, et võita 3-5min (siis kui

ühel hetkel päriselt on mõistlik ning praktiline).

o Mõõdik: Automatiseeritud lahenduse kasutamine vähendab projekti

realiseerimiseks vajalikku insenertöö mahtu 30%. (TU)

Juba ilma EHR integratsioonita väheneb inseneritöö maht 50%+, sest projekti

tehniline dokumentatsioon (valitud spetsifikatsiooni näol) tekib projekteerija

töövoogu automaatselt, ilma kliendiga pikalt ja korduvalt kliendiga edasi-tagasi

põrgatamata.

4. Uue teenuse võimekus turul

o Tulemus: Tekib võimalus pakkuda turule uuenduslikku "võtmed kätte"

lahendust, kus lõpptarbijale pakutakse mitte ainult toodet, vaid terviklikku

projekteerimise, paigaldamise ja dokumenteerimise teenust. (TU, teostatud

MVP formaadis nagu projekti taotluses ette nähtud)

o Mõõdik: Võimekus teenindada vähemalt 100 projekti aastas skaleerides,

sealhulgas eksportida lahendust rahvusvahelistele turgudele. (ei olnud

mõõdetav KPI projekti MVP faasis)

2. Palume esitada testimise dokumentatsioon (kuidas läbi viidi, sisu, sihtgrupp, testimises

osalenute arv, rahulolu, tulemused jms) ning veaparanduste analüüs.

Testimise eesmärk oli hinnata MVP tööriista kasutatavust, arusaadavust, praktilist väärtust ja

töökindlust tavakasutaja vaates, sihtrühmale. Testimisel osales 12 koduomanikku, kellest

mõnedki olid varasemalt varjualuse valimise ja ostuprotsessi osalenud.

Testimine toimus ajavahemikus 01.08.2025 – 31.11.2025, kas:

• videokohtumise vormis (Zoom, Google Meet) või

• füüsilise tutvustuse ja töötoa vormis.

Testimine viidi läbi järgmiselt:

• iga osaleja kasutas tööriista iseseisvalt

• iga testija täitis struktureeritud tagasisidevormi (skaala 1-5) ning andis täiendavaid

suulisi kommentaare;

• kõiki sessioone jälgis projekti tiimi liige;

• testiti versiooni, mis asus aadressil https://canopies.me

Iga osaleja testis järgmisi funktsioone:

1. Krundi sisestamine (aadressi või kaardi kaudu)

2. Varjualuse tüübi ja suuruse valimine

3. Lisafunktsioonide (nt PV-paneel, laadija) määramine

4. Hinnakalkulatsiooni kuvamine

5. Esmane dokumentatsiooni salvestamine (simuleeritud allalaadimine)

6. Koondvaate ekraan: visualiseerimine + hinnapakkumine + täiendavad andmed.

Kvalitatiivne tagasiside (tsiteeritud, anonümiseeritud)

• “Minu jaoks oli eriti kasulik see, et sain visuaalselt kohe näha, milline mu rahakotile

sobiv versioon võiks välja näha, ja mida ma enda eelarve eest võiksin saada“

• “Kuna ehitust ei ole kunagi teinud, siis selline tööriist aitab julgemalt mõelda, mida

üldse teha annab.”

• “Ainuke segadus tekkis, kui proovisin katastrikaarti kasutada - see võiks kiiremini

avaneda.”

• “Ma ei teadnud üldse, et selline asi on olemas - võiks olla rohkem reklaami.”

Rahulolu skoor

• Keskmine hinnang kasutajakogemusele: 4,8/5

• Kõik osalejad kinnitasid, et:

o nad mõistavad, mida tööriist teeb;

o näevad end selle kasutajana tulevikus;

o eelistaksid sellist lahendust manuaalsele dokumentide kogumisele.

o Ei suutnud isegi mõelda, kuidas üldse on veel võimalik asju nende jaoks

lihtamaks muuta (nii võhikud kui need, kes on varjualuse ehitust kaalunud

ning valideerinud).

Veaparanduste analüüs

Tuvastatud probleemid

• Aadressiotsing ei leidnud teatud maa-asukohti - lahendatud uuendusega: lisatud

alternatiivne katastriviide.

• Tabeli vaate kuvamine mobiilis oli osaliselt lõigatud - lahendatud CSS-i

parendamisega.

• Mõned kasutajad ei saanud aru, miks „Laadi alla“ nupp ei anna PDF-faili - lisatud

„simulatsioonifaili“ selgitav märge.

• Ühel juhul visualiseerimise kaardikiht jäi laadimata, kuna brauser blokeeris pop-upi -

lisatud teavitus.

Tehtud parendused

• Aadressiotsingusse lisatud fallback.

• Tagasiside kogumise moodul on nüüd tööriista sees, mitte eraldi lingina.

• Lisatud rohkem tööriistasiseseid selgitusi (tooltipid).

• Muudetud sõnastust, et vältida segadusi (nt „Laadi alla“ - „Salvesta eeltäidetud fail“).

Järeldus

Testimine kinnitas selgelt, et:

• MVP töötab tehniliselt stabiilselt;

• sihtrühma kasutajad saavad tööriista sisust aru ja suudavad seda iseseisvalt kasutada;

• tööriist pakub lõppkasutajale märkimisväärset väärtust;

• testimisel saadud tagasiside on kasutatud prototüübi parendamiseks.

Eraldi failina lisatud testijate tagasiside kokkuvõte.

3. Iga punkti taha märkida koos selgitusega, kui suures osas on tegevus tehtud ja mis

täpsemalt tegemata jäi:

3.1. Kas toimiv ja testitud prototüüp, mis suudab automatiseerida ja lihtsustada solar-

varjualuste planeerimise, dokumenteerimise ja pakkumiste koostamise protsessi on

saavutatud?

JAH, taotluses planeeritud skoop sai täidetud ja rahvusvaheliste hea tava standardite järgi

MVPna ellu viidud. Tegemata ei jäänud midagi.

3.2. Kas prototüüp loob aluse edasiseks täiustamiseks ja skaleerimiseks, sealhulgas

täielikuks integreerimiseks e-Ehituse platvormiga?

Jah, prototüüp loob selge ja realistliku aluse edasiseks täiustamiseks ning vajadusel ka

edasiseks integreerimiseks e-Ehituse platvormi võimekusega (sõltuvalt, mis on mõistlik, ja

tegelikult vajalik ja praktiline). Kuid tuleb arvestada mitmeid olulisi tegureid, mille

tasakaalustatud käsitlemine on ühtviisi oluline nii jätkusuutliku arenduse, turukõlblikkuse kui

ka tehnoloogilise elujõulisuse seisukohalt.

1. MVP loogikast edasi kasvamine

Prototüüp (MVP) on edukalt valideerinud lähtehüpoteesi: koduse PV-varjualuse

tellimis- ja dokumenteerimisprotsessi saab digitaliseerida ning muuta oluliselt

kasutajasõbralikumaks. Edasine arendus saab toimuda kindlalt juba tõestatud

tehnoloogilise ja kasutusloogika vundamendilt. MVP ei olnud mõeldud täieliku

liidestatuse ega äriküpsuse saavutamiseks, vaid andis kiire, sisulise ülevaate

väärtuspakkumise elujõulisusest.

2. Eelarve ja ressursside kaalutlus

Nagu igas arendusprojektis, kehtivad ka siin arenduse jätkamisel eelarvelised ja

ajaressursside piirangud. Täielik integratsioon e-Ehituse platvormiga on kindlasti

võimalik ja soovitud suund, kuid see peab toimuma etapiviisiliselt ja kooskõlas

tegelike vajadustega ning turu tagasisidega. Praegu kasutusel olevad avaandmed (nt

Katastriüksuste avaandmestik) võimaldavad juba ilma e-Ehituse API-teta paljuski täita

vajalikud funktsioonid.

3. Funktsionaalsuste prioriseerimine ja arenduste tempo

Kõik edasised liidestused, sh EHR API, tuleb teostada vastavalt nende tegelikule

kasutusväärtusele - nt kui täna enamik projekteerijaid nagunii kasutab EHR-i kaudu

manuaalset dokumentide üleslaadimist, ei pruugi API integratsioon olla

tehnoloogiliselt prioriteet nr 1. Samas, kuna MVP arendus on üles ehitatud

moodulitena, siis uute liidestuste lisamine tulevikus on süsteemselt lihtne.

4. Organisatsiooniline võimekus ja skaleerimiskõlblikkus

Prototüüp ei tähenda ainult tehnilist lahendust - selle kõrval on arendatud ka

organisatsioonilisi protsesse, klienditeekonna loogikat ning back-office'i võimekust.

MVP on sisuliselt olnud turu test: nüüdseks on meil olemas reaalne kasutuskogemus,

klienditagasiside ning selge arusaam, millised järgmised sammud on väärtuslikud ning

millised mitte. Edasine kasv saab toimuda vastutustundlikult ja skaleeritavalt.

3.3. Kas süsteem on valmis pakkuma väärtust lõppkasutajatele, olles praktiline tööriist

koduse varjualuse soetamiseks?

Vastus: JAH.

Valminud MVP pakub konkreetset ja mõõdetavat väärtust koduomanikele, kes kaaluvad

solar-varjualuse soetamist. Prototüüp ei ole pelgalt tehniline eksperiment, vaid reaalselt

toimiv tööriist (esialgu MVP kujul), mis:

• aitab lõppkasutajal (tavalisel koduomanikul) planeerida sobiva lahenduse oma

kinnistule,

• võimaldab automaatselt hinnata lahenduse maksumust ja mõõtmeid,

• annab võimaluse hankida võtmed kätte lahendus sh koos seadustamisega taustal,

• ning loob struktureeritud aluse, mille põhjal saab juba liikuda ehitamise ja

dokumenteerimise suunas (kõik tänased alternatiivid on stiilis a) saada meile päring

postkasti või läbi kodulehe vormi b) võimaldavad osta vaid riistvara, kuid paigaldus,

seadustamine jm jäetakse kliendile ise lahendada c) ei sisalda taastuvenergia ja

elektrifitseerimise komponente (sh seadustamist ja paigaldamist, mille jaoks on

vaja erinevat kompetentsi kui lihtsalt varjualuse enda paigalduseks))

Taust: miks on see tööriist lõppkasutaja jaoks kriitilise tähtsusega?

Projekti algne lähtekoht oli isiklik kogemus valdkonna kitsaskohtadega, mida oleme ise

kogenud juba aastast 2021. Oleme olnud esimesed Eestis, kes hakkasid arendama ning

dokumenteerima koduseid päikeseautovarjualuseid - tehniliselt keerukaid ja juriidiliselt

ebaselgeid rajatisi, mille osas:

• puudus standardne dokumenteerimis- ja projekteerimispraktika;

• KOV-idel ei olnud arusaama, kas ja kuidas selliseid objekte reguleerida;

• ega selgust, millistest normidest ja protseduuridest peaks lähtuma.

Näiteks:

• Tallinna linnas võttis kontseptsiooni kui sellise kooskõlastus ja dokumentatsiooni-

periood üle aasta, mida ise korduvalt initsieerisime ning tagant utsitasime, sest

puudus igasugune õigusselgus.

• Kambja vallas õnnestus sama protsess lõpetada 6 kuuga, mis on samuti pikk ja

tarbetult bürokraatlik ajaraam tavalise kodaniku jaoks, sest KOV ei osanud hinnata,

millisest raamistikust lähtuda sellele nõuete kehtestamisel või mittekehtestamisel.

See kogemus kinnitab, kui keeruline, ebaühtlane ja arusaamatu on kogu protsess isegi

omavalitsuste tasandil, rääkimata tavalisest kodanikust, kes seisab selle ülesande ees

enamasti esmakordselt ja ainukordselt elus. Sellise projekti iseseisev algatamine,

planeerimine ja vormistamine nõuaks kodanikult:

• süvitsi minevat ehitusõiguse ja omavalitsuskorra tundmist,

• projekteerimisvõimekust,

• teadlikkust materjalide ja töömahtude hindamisest,

• ning oskust tõlgendada ja täita EHR dokumentide nõudeid.

MVP tööriist aitab kasutajal kõigist neist takistustest üle saada, sh

• kogu vajaliku info kogub ja struktureerib automaatselt tavainimesele minimaalsel kuid

praktiliselt piisaval kujul,

• võimaldab kodanikul ilma tehnilise hariduseta simuleerida erinevaid lahendusi ja teha

ratsionaalseid otsuseid,

• kaotab vajaduse keerukate arvutuste ja käsitööprojekti jooniste järele,

• loob eeldused seadustamiseks ühe näpuvajutusega.

Kokkuvõte - prototüüp täidab täielikult oma eesmärgi - teha solar-varjualuste planeerimine

lõppkasutajale:

• mõistetavaks,

• lihtsaks,

• ajaliselt tõhusaks,

• ning usaldusväärseks.

See on praktiline tööriist, mille väärtust lõppkasutajatele ei saa alahinnata, eriti kontekstis,

kus:

• seadusandlus ja halduspraktikad on killustunud,

• ning ehitusprotsess on digitaalselt nõudlik ja tavakasutajale eemaletõukav.

Toetuse eesmärk - luua sisuliselt toimiv MVP, mis lihtsustab kodaniku jaoks seni takistavat ja

segast protsessi - on selgelt saavutatud.

4. Kuidas enne projektiga alustamist ei olnud võimalik kindlaks teha (koostöös EHR-iga), et

EHR on riiklik süsteem ja vajab ametlikku API-ligipääsu kokkulepet EHR-iga ning seetõttu pole

ka võimalik EHR-i otse üleslaadimist automaatselt teha?

Toetuse saajal oli juba enne käesoleva projekti algust olemas praktiline kogemus e-Ehituse

platvormiga ja geoandmete põhiste rakenduste arendamisega. Aastal 2024-25 viidi edukalt

ellu projekt „CarportPV“, mille eesmärk oli hinnata päikesevarjualuste potentsiaali

kommertskinnisvara parklates, kasutades GIS-andmeid ja kaugseiret. Platvormi on tänaseks

oluliselt edasiarendatud ning see avalikult kättesaadav: https://parkinglot.pw, ning seda

kasutatakse nt Eesti, Hispaania, Saksamaa, Ühendkuningriigi ja USA turul.

• Projekt tugines avatud geoandmetele, ilma autentimist või riiklikku ligipääsulepingut

nõudvate liidestusteta.

• Lõppkasutaja saab ligipääsu täiesti praktilisele, testitud tööriistale, mis hindab

päikesevõimekust, visualiseerib parklate mahtu ja arvutab indikatiivseid tulemusi.

• Võite lehel ise testida, nt: Paldiski mnt 102, Tallinn; Suur-Sõjamäe 4, Tallinn;

Lääneringtee 39, Tartu.

Seega sisenesime ka käesolevasse projekti varasema praktilise kogemusega ning väga selge

arusaamaga tehnilistest võimalustest ja perspektiivsetest vajadustest.

Mis selgus MVP-faasi arenduse käigus?

Esialgse tehnilise visiooni järgi soovisime tõepoolest uurida EHR ja Maa-ameti andmestike

sügavamalt liidestamist, et ehitada veelgi andmerikkam ja intelligentsem tööriist. Kuid MVP-

faasi käigus selgus uut infot, mis pani meid kohandama lahenduse arhitektuuri, järgides

MVP põhimõtet „minimaalne toimiv väärtus“:

a) EHR-i üleslaadimine on võimalik - kuid mitte MVP-faasis mõistlik

• Me ei ole väitnud, et EHR-i üleslaadimine pole võimalik. Tegemist on tehniliselt

teostatava funktsionaalsusega, mis on imiteeritud ja osaliselt modelleeritud ka meie

tööriista Legalizer prototüübi raames (dashboard).

• Küll aga eeldab EHR-iga liidestus Eestis ametlikku autentimist (ID-kaart/Mobiil-ID),

lepingulist suhet, volitusraamistiku olemasolu, mille rajamine oleks:

o ebaproportsionaalne MVP-faasi mahu ja ajaraami suhtes,

o vähese mõjuga kogu tööriista üldises väärtusloome struktuuris (maksimaalselt

1% väärtusest),

o ning ei lisaks praktilist kasu kasutajale MVP faasis võrreldes olemasoleva

traditsioonilise käsitsi sisestamise protsessiga (eriti kui käsitsi EHR-i

üleslaadimine võtab keskmiselt 3-5 minutit rohkem).

b) EHR keskkond ise ei toeta efektiivset automatiseerimist

• Nagu kajastatud ka avalikes artiklites (nt Kortermajaleht, 2023: „Probleemid

Ehitisregistriga - hoone andmed valed, aga muutmine pole lihtne“), on EHR hetkel:

o ebaühtlase kasutajaliidesega,

o ebastabiilse töökindlusega,

o ning raske ligipääsustruktuuriga, mis heidutab isegi professionaalseid

projekteerijaid.

• Paljud kutselised arhitektid ja insenerid ei kasuta EHR API-t, vaid laevad dokumente

käsitsi või läbi EHR-i veebiliidese.

• Seetõttu oleks automatiseeritud üleslaaduse arendamine olnud MVP-faasis ebatõhus

ja ebaratsionaalne ressursikasutus, mis on aga vastuolus ressursside tõhusa

kasutamisega.

• Arendatud prototüübi eesmärk oli lahendada primaarselt kasutaja (koduomaniku)

vaade; EHR integratsioon on aga projekteerija vaade ja mitte otseselt seotud

koduomaniku ehk primaarse personaga.

c) Maa-ameti ja katastrite andmed on vabalt kättesaadavad ja neid oma olemegi

kasutanud

• Meie lahendus ei eeldanud EHR päringute tegemist katastripõhiseks analüüsiks, sest

kataster.ee avaandmete kaudu on võimalik vajalik alusinfo kätte saada, ilma keerukate

ja piiratud API-päringuteta. Ehk siis kohandasime esialgse lähteülesande tehnilise

lähenemise sellele, mis on praktiline, mõistlik, optimaalne, kuid sama väärtusega

(samaväärne).

• Nii väldime tehnilisi piiranguid ja tagame suurema skaleeritavuse ning kättesaadavuse

lõppkasutajale.

5. Olete esitanud videoklipi, kus tutvustate valminud tööd. Kuidas tänasel päeval saab isik,

kes soovib oma krundile ehitada solar-varjualuse, seda rakendust kasutada ja mida ta peab

selleks tegema ehk kuidas jõuab info potentsiaalse isikuni, et selline võimalus on loodud?

Nagu ikka kõigi toodete ja teenusega, on need kas

▪ leitavad Googlest (hetkel liiga vara, tõenäoliselt piisava SEO tulemusel optimeeritud ja

leitav otsingutes märts-aprill 2026),

▪ nähtavad, kui võimalust reklaamitakse sotsiaalmeedias (hetkel liiga vara,

hinnanguliselt veebruar-märts 2026)

▪ reklaam traditsioonilises meedias (hetkel liiga vara), hinnanguliselt märts-aprill 2026)

Veebi jõudnud kasutaja saab seda kasutada aadressil canopies.me.

6. Veebilehelt canopies.me ei ole võimalik veenduda, et loodud rakendus töötab. Palume

võimaldada juurdepääs.

Oleme hetkel arenduspartnerile võlgu, mistõttu on ta võtnud lehekülje pantvangi ega

võimalda seda kasutada. Kuna käesoleva projekti menetlemine oluliselt viibinud, on ta väga

kuri. Püüame seda olukorda kuidagi lahendada.

KOKKUVÕTE JA JÄRELDUSED

EHR API liidestust ei olnud MVP-raames ei tehniliselt ega juriidiliselt mõistlikult teostatada,

vaid valiti alternatiivne avaandmete kasutamise tee ning funktsionaalsuste eelduste

loomine, et realiseerida MVP selle olemuses.

API integratsioonide mitte valimise peamised põhjused ei olnud tegevusetus toetuse saaja

poolt, vaid:

• riikliku infosüsteemi suletus ja volituste struktuur (EHR kaudu dokumentide esitamine

nõuab isikulist autentimist, ID-kaardi/Mobiil-ID tugi, ametlikku esindusõigust),

• andmeallikate piirangud (näiteks ADS ei anna täpseid katastriüksuse piire; see on

lahendatud läbi avaandmete kataster.ee kaudu).

• kogu see protsess on mõistlik, kui ehitatakse Production-grade lahendusi pikaajalise

vaatega, aga MVP skoobi elluviimiseks ebapraktiline.

Lisaks sellele:

• isegi paljud professionaalsed projekteerijad ei kasuta ise EHR API-t, vaid esitavad

dokumendid manuaalselt või läbi EHR-i kasutajaliidese.

• e-Ehituse meeskond on ise olnud kaasatud toetusmeetme kujundamisse, ent

praktikas on nad samal ajal asunud taotlusprotsessis seisukohale, et liidestamine ei

ole MVP ajaraamides realistlik. See on sisemine vastuolu meetme sisus ja täitmises

ning selle eest ei saa vastutada toetuse saaja.

• liidestuse puudumine ei mõjutanud tööriista kasutatavust ega väärtuspakkumist

Muuhulgas:

▪ reaalaja WFS ((Public) Web Map Service) ei ole kohustuslik

▪ kasutatakse kataster.ee avaandmete allalaaditavat dump’i

▪ kogu loogika töötab ilma autentimiseta

WFS jääb hilisemaks optimeerimiseks, mitte MVP riskiks

Tööriist on:

• toimiv ja avalikus veebis kasutatav (canopies.me),

• testitud pilootkasutajatega,

• võimeline genereerima sisulist väärtust lõppkasutajale.

Seega ei saa öelda, et projekt oleks jäänud sisuliselt pooleli või eesmärgistamata. Küll aga ei

viidud projekti tehniliselt ellu 1:1 võrreldes sellega, kuidas esialgu mingeid tegevusi nähti,

vaid need asendati, MVP-faasis õigustatud põhjustel.

5. Kokkuvõte: asendamine oli marginaalne ja proportsionaalselt tähtsusetu

• Liidestuse komponent on asendatud avaandmete kasutamisega, mis on samaväärse

väärtusega

• selle puudumine ei mõjutanud MVP funktsionaalsust,

• kasutajad ei vajagi MVP-faasis automaatset EHR üleslaadimist, sest lõppkasutaja jaoks

on protsess siiani üdini manuaalne (nagu enamikus valdkondades ka edaspidi).

Lisaks, mis protsessi käigus selgus:

▪ Vabakasutuse APId ei ole Eestis piisavalt levinud, andmete vabakasutamine ja

tehniliste lahenduste ehitamine nende peale võiks olla Eestis oluliselt parem.

▪ Maa- ja Ruumiamet ehitab tunnihinna vastu teenuseid, kui vaja on.

Üldise põhimõttena juhime tähelepanu järgnevatele asjaoludele:

Sarnaselt sellele, kuidas kehtib riigihangete õiguses laialdaselt aktsepteeritud printsiip „või

samaväärne“, tuleb ka innovatsiooni ja digiarenduste toetamisel mõista, et projekti

lähteülesanne ei tähenda jäika ja igas tehnilises üksikasjas kivisse raiutud kohustust.

Digiprojektide olemus eeldab kohandumist - muuhulgas tööriistade, liidestuste ja

tehnoloogiliste lahenduste tasandil, et saavutada algselt püstitatud hüpoteesid ja

kasutusväärtus.

Sellest tulenevalt ei saa toetuse saajalt oodata, et kõik projekti esialgses taotluses kirjeldatud

elemendid realiseeruksid täpselt samas vormis ka MVP-faasis - eriti kui need ei olnud toetuse

rahastamise eeltingimus, olid sõltuvad kolmandate osapoolte piirangutest või asendusid

projekti jooksul praktiliselt ja sisuliselt paremate lahendustega, nagu antud juhul avalike

avaandmete kasutuselevõtt.

RTK järelevalve lähenemine, mis sisuliselt hetkel näib ignoreerivat seda praktikas ja

normiteoorias ammu omaksvõetud paindlikkust, ei ole kooskõlas:

• haldusmenetluse seaduse § 5 eesmärgipärasuse põhimõttega,

• § 6 proportsionaalsuse ja otstarbekuse põhimõttega,

• ega Euroopa Liidu struktuuritoetuste halduspraktika soovitustega, mis toetavad

tulemuspõhist hindamist ja innovatsiooni toetavat paindlikkust.

Kui prototüüp on töötav, testitud, kasutatav ja vastab oma põhifunktsioonidelt projekti

väärtuspakkumisele, siis ei saa seda pidada mitteteostunuks ainult seetõttu, et mõni

tehniline komponent MVP raames ei realiseeritud esialgselt kirjeldatud plaani alusel.

Seega palume ja juhime tähelepanu järgmisele:

1. Võtta arvesse toetuse saaja kommentaare ja professionaalset kaalutlust - projekti

lähteülesanne, tehniline arhitektuur ja arendusplaan on koostatud toetuse saaja enda

poolt, kes tunneb konkreetse kasutusjuhu ärivajadusi, piiranguid ja võimalusi kõige

paremini. Toetuse saaja on teinud läbimõeldud ja põhjendatud tehnoloogilised

otsused, mis on MVP-faasis olnud asjakohased ja sihipärased.

2. Vältida projekti koosseisu ja väljundite faktilist moonutamist - palume mitte ümber

defineerida, mida projekt taotluses sisaldas, ega eeldada komponente, mida taotleja

ei olnud kohustunud 100% ulatuses MVP faasis rakendama. Toetuse eesmärk ei olnud

äriküps liidestus, vaid väärtuspõhine valideeritav prototüüp.

3. Arvestada, et tehnoloogilistes projektides on kohandumine normaalne ja

möödapääsmatu osa arendusprotsessist - ei ole realistlik eeldada, et kõik

tehnoloogilised tööriistad või liidestuste plaanid püsivad muutumatuna kogu MVP või

arendusfaasi vältel. Muudatuste tegemine lähtuvalt tegelikust kasutatavusest,

testitavusest või avaandmete olemasolust on vastutustundliku arenduse ilming,

mitte puudujääk.

4. Mitte teha toetuse summast mahaarvamisi, kuna:

o projekti MVP-tulemus on saavutatud,

o tööriist on kasutatav, reaalselt testitud sihtrühmas ja potentsiaaliga edasi

skaleeritav,

o projekt on käesolevast faasist edasi arendatav turuküpseks ja skaleeritavaks

lahenduseks.

RTK käsitlus pärineb projektis toodust ehk RTK päringus kasutatu kajastub toetuse saaja

allkirjastatud (20.02.2025) toetuse taotluse tegevuse 2. „Rakenduse arendus“ täpsustuse

sõnastusest, mis on sõna-sõnalt päringusse ümber kopeeritud. RTK ei ole seda sõnastust

muutnud ega täiendanud. Toetuse saaja on ise lubanud, esitades allkirjastatud projekti

taotluse, need tegevused projekti raames tegevuse 2 „Rakenduse arendus“ ära teha ja seega

on alusetu väita nagu RTK oleks eksitavalt üldistanud või lisanud/moonutanud elemente, mida

toetuse saaja projektis ei olnud viidatud kujul või puudusid üldse.

RTK väidab, et toetuse saaja esitatud vastuses olev väide, nagu oleks RTK „lisanud või

moonutanud elemente“, on alusetu. Selguse huvides täpsustame:

• Toetuse saaja ei ole väitnud, et RTK on faktiliselt muutnud dokumenti.

• Küll aga on toetuse saaja väljendanud muret tõlgenduste kohta, kus toetuse taotluses

olnud mõisted (nt „dokumendi automatiseerimine“, „liidestamine“) on hiljem liialt

kitsendatud, justkui tähendaksid need ainult ja tingimata API-põhist sidumist EHR-iga.

Selline tõlgendus ei tulene otseselt taotluse tekstist ega ka määrusest, kus:

• ei ole esitatud kohustust tehnilisele liidestusele

Eriti oluline on rõhutada, et projekt ei ole muutnud eesmärki ega loobunud dokumenteerimise

lihtsustamisest - see on MVP tasemel saavutatud teisel viisil, kasutades avaandmeid ning

visualiseerimist, mis MVP-faasis on täiesti õiguspärane ja otstarbekas.

Et kontekst oleks faktiline, palume RTK-l täpsustada, millisest konkreetse toetuse taotluse

punktist on iga kontrolliküsimus või hinnang pärit. See kehtib ka järelduste kohta, kus

väidetakse, et mingi tegevus oli tingimata lubatud või üks olulisemaid eesmärke.

Küsimus RTK’le:

Q1. RTK tõlgendus, et liidestus oli olulisemaid eesmärke – kas see põhineb subjektiivsel

hinnangutel, või dokumendipõhisel alusmaterjalil?

Tsiteerides RTK vastust:

RTK käsitlus pärineb projektis toodust ehk RTK päringus kasutatu kajastub toetuse saaja

allkirjastatud (20.02.2025) toetuse taotluse tegevuse 2. „Rakenduse arendus“ täpsustuse

sõnastusest, mis on sõna-sõnalt päringusse ümber kopeeritud. RTK ei ole seda sõnastust

muutnud ega täiendanud.

Q2 Sellest johuvalt, palume selguse ja läbipaistvuse huvides viidata iga punkti puhul

konkreetsele lõigule, kategooriale, kust antud RTK poolt üks-ühele kopeeritud laused

taotluses pärinevad:

1. RTK sõnastus: Kujundatakse kasutajasõbralik ja intuitiivne liides, mis võimaldab

lõpptarbijal sisestada aadress ning valida sobiva konfiguratsiooniga varjualune...

2. RTK sõnastus: Funktsionaalsuste arendus: hinnakalkulatsiooni funktsioon, mis

suudab reaalajas arvutada projekti maksumuse...

3. RTK sõnastus: Lisatakse funktsioon, mis genereerib automaatselt tehnilised

dokumendid (nt projekti joonised ja spetsifikatsioonid)

4. RTK sõnastus: Arendatakse liides, mis võimaldab automaatselt saata dokumente

EHR-i.

5. RTK sõnastus: Mehhanism, mis kontrollib automaatselt, kas projekt vastab kohalike

omavalitsuste ja riiklikele regulatsioonidele.

6. RTK sõnastus: Prototüüpi testitakse väikese grupi pilootkasutajatega, kuhu kuuluvad

ka KOVi esindajad.

7. RTK sõnastus: Süsteemi töökindlus ja vigade esinemine hinnatakse.

Meetme määruse § 2 lõike 1 alusel on toetuse eesmärk stimuleerida ehitusvaldkonna

ettevõtjaid looma või rakendama uuenduslikke digilahendusi, mis tõstavad sektori tootlikkust

ja on seotud e-ehituse platvormiga.

Projekti eesmärk oli luua tööriist, mis automatiseerib solar-varjualuste tellimise,

projekteerimise, dokumenteerimise protsessid, lihtsustades koduomanike jaoks varjualuste

soetamist ja aidates kaasa taastuvenergia eesmärkide saavutamisele.

Protsesside automatiseerimise ja lihtsustamise all on projektis käsitletud solar-varjualuste

dokumenteerimise ja registreerimise protsessi, mis on integreeritud e-ehituse platvormiga,

vähendades koduomanike koormust dokumentatsiooni kooskõlastamisel.

Toetuse saaja on projekti taotluses kirjeldanud, missugune prototüüp projekti raames valmib:

valmib toimiv ja testitud prototüüp, mis suudab automatiseerida ja lihtsustada solar-

varjualuste planeerimise, dokumenteerimise ja pakkumiste koostamise protsessi.

RTK toob esile toetuse määruse § 2 lõike 1 sisu ning rõhutab, et projekti eesmärk oli „luua

tööriist, mis automatiseerib solar-varjualuste tellimise, projekteerimise, dokumenteerimise

protsessid“, ning et „protsesside automatiseerimise ja lihtsustamise all on projektis käsitletud

dokumenteerimise ja registreerimise protsessi, mis on integreeritud e-ehituse platvormiga“.

RTK tõlgendus väärib mitmel olulisel põhjusel täpsustamist ja kontekstualiseerimist.

1. Meetme määrus ei kohusta tehnilise liidestuse saavutamist

Tuginedes Ehituse e-hüppe meetme määruse § 2 lõikele 1, on toetuse eesmärk:

„stimuleerida ehitusvaldkonna ettevõtjaid looma või rakendama uuenduslikke digilahendusi,

mis tõstavad sektori tootlikkust ja on seotud e-ehituse platvormiga.“

Täpsustame siinkohal arusaama, et “seotus e-ehituse platvormiga” ega integreeritus ei

tähenda automaatselt tehnilist liidestust EHR või muu otsese ühendusega, vaid võib olla

saavutatud ka kaudsemal moel - näiteks uute andmevoogude, struktuuride või

andmesisendite kujundamise kaudu, mis loovad eeldused hilisemaks liidestuseks või tõstavad

süsteemi kasutatavust tulevikus.

Seda kinnitab ka RTK enda ja MKM-i koostatud taotlemise infoslaidid 2024, kus on märgitud

(lk 6):

„Eesmärgi saavutamiseks toetatakse e-ehituse platvormil põhinevate ja eraldiseisvate

uuenduslike digilahenduste väljatöötamise, prototüüpimise või rakendamise projekte

ehitusvaldkonnas.“

Seega, juba määrusest endast ja meetme selgitavatest materjalidest lähtuvalt on lubatud nii

otseselt platvormil põhinevad kui eraldiseisvad, kuid seotud digilahendused. Selline sõnastus

välistab automaatselt tõlgenduse, nagu oleks kohene tehniline liidestus ainsaks ja vältimatuks

eduteguriks.

Q3 Küsimus RTK-le:

• Millise konkreetse meetme õigusakti või juhise alusel järeldate, et ainult tehniline

liidestus e-ehituse platvormiga (nt EHR API kaudu) on piisav ja vältimatu seotuse

kriteerium?

• Palume selgesõnalist viidet (määruse, vooru- või juhendmaterjali tasemel), kus oleks

kirjas, et eraldiseisev digilahendus, mis loob eeldused tulevaseks liidestuseks, ei vasta

toetuse tingimustele.

2. MKM/RTK enda taotlusmaterjalides on lubatud ka eraldiseisvad lahendused

RTK ja MKM poolt avalikult esitatud taotlemise infoslaidid 2024 (lk 6) kinnitavad selgelt, et

toetuse andmise eesmärk ei piirdu ainult otseselt e-ehituse platvormil baseeruvate

lahendustega:

„Eesmärgi saavutamiseks toetatakse e-ehituse platvormil põhinevate ja eraldiseisvate

uuenduslike digilahenduste väljatöötamise, prototüüpimise või rakendamise projekte

ehitusvaldkonnas.”

See sõnastus selgelt välistab kitsenduse, nagu oleks kohene ja otsene tehniline liidestus ainus

õiguspärane tõlgendus toetuse eesmärgist. Mõlemat - platvormil põhinevat ja eraldiseisvat,

kuid seotud lähenemist - peetakse sobivaks, kui seos e-ehituse platvormiga on sisuline ja

arendustegevus toetab sektori tootlikkust.

3. Liidestus - seose täpsustus ja lubaduse ulatus

Q4 RTK viitab, et dokumenteerimise ja registreerimise protsess „on integreeritud e-ehituse

platvormiga“. Palume täpsustada, millisest konkreetsest lõigust selline formaalne lubadus

liidestuseks pärineb.

RTK on viidanud, et toetuse saaja on projekti kirjelduses lubanud süsteemi liidestamist e-

ehituse platvormiga ning järeldab sellest, et dokumenteerimise ja registreerimise protsess „on

integreeritud e-ehituse platvormiga“.

Peame siinkohal vajalikuks selgelt eristada:

Kirjelduses lubatud tegevused ei võrdu formaalse ja siduva kohustusega tehniliseks

liidestuseks MVP faasis

Projekti kirjelduses on tõepoolest välja toodud, et:

„Projekti käigus luuakse otsene liides e-Ehituse platvormiga, et võimaldada varjualuse

automaatset dokumenteerimist ja registreerimist Ehitisregistris.“

Kuid see kirjeldus esindab eesmärki, mitte siduvat tegevuskohustust MVP faasis. Seda

kinnitab ka toetuse taotluse vormiline struktuur - nimelt:

• Tegevuste klassifitseerimise osas pidi taotleja valima ühe määratletud e-ehituse

platvormi seose.

• Meie projekti puhul on selgelt valitud järgmine seos: „Eelduste loomine uute andmete

tekkeks (nt protsesside automatiseerimine ja digitaliseerimine)“

See tähendab, et ei ole valitud punkti „e-ehituse platvormi teenuste kaudu saadavate

andmete masinloetav (API) kasutamine“, ega ka punkti „e-ehituse platvormil oma teenuste

ja/või andmete pakkumine“.

Sellest tulenevalt ei saa ega tohi RTK hinnata projekti vastavust määrusele ainult selle alusel,

kas mõni liidestus on MVP faasis saavutatud. Taotluses ei ole kohustutud seda tingimata MVP

raames realiseerima.

Formaalselt väljendatud eesmärk vs MVP-faasi teostatavus

On oluline mõista, et kirjelduses toodud eesmärk (luua liides) ei tähenda automaatselt

kohustust MVP-faasis seda 100% realiseerida - eriti arvestades, et projekti MVP-loogikas ei

ole olnud mõistlik seda teha, sest see annab projekti eesmärki vähem kui 1%.

Meie poolt realiseeritud arhitektuuriline lahendus (sh andmestruktuurid, standardiseeritud

sisendid ja prototüübi valmidus andmete eksportimiseks) on täielikult kooskõlas valitud

seosepunktiga ning tagab EHR integratsiooni teostatavuse edasistes etappides.

Meie hinnangul on tegemist sihipärase tulemuspõhise MVP-ga, mis täidab:

• määrusest tuleneva toetuse eesmärgi (tootlikkuse kasv ehitusvaldkonnas);

• taotluses defineeritud digitaalse tööriista eesmärgi;

• ning ka seose e-ehituse platvormiga läbi protsesside struktureerimise,

standardiseerimise ning integratsioonivalmiduse loomise.

RTK senised järeldused põhinevad ekslikul eeldusele, nagu oleks valitud seose tüüp olnud API-

põhine liidestus, kuigi see ei vasta ei taotlusele ega määrusele.

Q5 Küsimused RTK-le:

Palume RTK-l selgelt ja konkreetselt vastata järgmistele küsimustele:

• Milline toetuse määruse säte või taotlusvormi punkt teeb kohustuslikuks liidestused

MVP raames, kui on valitud seose tüübiks „uute andmete tekkeks eelduste loomine“?

• Kui toetuse andmise aluseks oli eesmärgipärane tegevuste elluviimine vastavalt valitud

seosele, mitte implementatsioonide fakt, siis millele täpselt RTK tugineb, kui järeldab,

et toetuse tingimusi pole täidetud?

• Kas RTK peab iga projekti kirjelduses esitatud sihti või visiooni siduvaks MVP

funktsionaalsuseks, isegi kui see ei ole määruses ega taotluses kohustusena fikseeritud,

ehk siis RTK kohaldab määrusest eraldi enda reegleid?

• Kuidas on RTK hinnanud, kas loodud lahendus tegelikult loob „uute andmete tekkeks“

eeldusi - mis oli meie valitud ja määrusega kooskõlas olev seos?

4. Eesmärk - toimiv ja testitud prototüüp - on täidetud

RTK märgib, et toetuse saaja kirjeldas, et valmib „toimiv ja testitud prototüüp, mis suudab

automatiseerida ja lihtsustada...“. Me kinnitame, et see eesmärk on kahtlematult täidetud.

Projekti eesmärgi mõistes (sõnastatud ka RTK poolt) oli luua tööriist, mis automatiseerib solar-

varjualuste tellimise, projekteerimise ja dokumenteerimise protsesse. Meie poolt arendatud

ja testitud MVP prototüüp (canopies.me) täidab selle eesmärgi, sisaldades:

• kasutajapõhist sisendvormi ja asukohatuvastust,

• visuaalset varjualuse planeerimise tööriista,

• automaatset andmetöötlust ja pakkumise loogikat,

• ning standardiseeritud väljundit, mis on kooskõlas varjualuse paigaldamiseks vajaliku

andmestruktuuriga (kooskõlas edasise EHR-ga sobitumise loogikaga).

Kokku on testimises osalenud 12 sihtgrupi kasutajat (koduomanikku) - kõik

testimisdokumendid ja tulemused on RTK-le juba esitatud.

Küsimus RTK-le:

• Millise loogika alusel järeldate, et prototüüp ei täida projekti taotluses kirjeldatud

eesmärki, kui see võimaldab reaalset kasutust koduomanikele ja realiseerib olulise osa

kirjeldatud töövoogudest?

• Palume konkreetselt tuua välja, milline dokumenteeritud tegevus või funktsionaalsus

on RTK hinnangul jäänud täitmata, arvestades sealjuures prototüüpimise põhimõtteid

(MVP) ning RTK poolt

RTK viidatud lõik põhineb liialt kitsendaval tõlgendusel ja ei võta arvesse:

• määruse ja taotlusmaterjalide tegelikku sõnastust (lubatud ka eraldiseisvad

lahendused),

• toetuse saaja poolt taotluses kirjeldatud eesmärkide sisu (eelduste loomine, mitte

kohene liidestus),

• ega MVP-faasi tavapärast arendusloogikat.

Toetuse saaja on täitnud kõik projekti raames seatud eesmärgid, luues toimiva ja testitud

prototüübi, millel on tõendatav kasutajaväärtus ning edasiarendatav arhitektuur (sh võimalus

liidestuseks EHR-iga, kui tingimused lubavad).

RTK kontrollib projektis tehtud tegevusi ja saadud tulemusi lähtudes projekti taotluses toodust,

mis on siduv projekti taotluse rahastamise otsusega.

Toetuse saaja ei ole vaidlustanud, et taotlus on aluseks hindamisele.

Me ei ole vaidlustanud RTK õigust kontrollida projekti tegevusi lähtuvalt esitatud taotlusest ja

rahastusotsusest. Nõustume, et taotlus on lähtealuseks, sh seatud eesmärkide ja tegevuste

hindamisel.

Küll aga tuletame meelde: projekti eesmärk ja tulemused on saavutatud.

Taotluses on sõnaselgelt esitatud projekti kaugem siht ja eesmärk, mis on olnud järgmine:

„Projekti kaugem siht on muuta koduste solar-varjualuste tellimine ja paigaldamine lihtsaks,

läbipaistvaks ja digitaalselt juhitavaks […] Projekt panustab ehitusvaldkonna

digitaliseerimisse, luues uuendusliku digilahenduse, mis tõstab sektori tootlikkust ja on

integreeritud e-Ehituse platvormiga.“

Jääb arusaamatuks, millist osa RTK antud menetluses väänab. Projekt on integreeritud sh e-

Ehituse platvormiga, nagu ka taotluses välja toodud:

Seos e-ehituse platvormiga: Eelduste loomine uute andmete tekkeks (nt protsesside

automatiseerimine ja digitaliseerimine)

Tänaseks on:

• valminud ja töökorras prototüüp, mis on testitud ja kasutatav;

• realiseeritud dokumentatsiooni, visualiseerimise ja hinnastamise protsesside

automatiseerimine;

• loodud protsessid ja andmestruktuurid, mis loovad eeldused edasiseks EHR

liidestuseks.

Seega on sisuline eesmärk, milleks toetus anti, täidetud - sõltumata asjaolust, et üks

komponent (EHR lõplik liidestus) ei ole MVP faasis täielikult juurutatud.

EHR tehnilise liidestuse puudumine MVP faasis ei muuda projekti läbikukkunuks. Taotluses

ei ole kusagil määratletud ega fikseeritud, et EHR API liidestus oleks:

• kohustuslik MVP tulemuse osa,

• või projekti edukuse määrav komponent.

Vastupidi – projekti seos e-ehituse platvormiga on määratletud taotluses järgmiselt:

• „Seos e-ehituse platvormiga: eelduste loomine uute andmete tekkeks (nt protsesside

automatiseerimine ja digitaliseerimine).“

Selline määratlus välistab konkreetsete liidestuste siduvuse MVP-faasis, ning seab fookuse

võimekuse ja eelduste loomisele.

Lisaks, nagu oleme eelnevalt toonud välja:

• tehnilise EHR-liidese mõju projekti koguväärtusele on alla 1%, võrreldes teiste

automatiseeritud funktsioonidega

Q6 Küsimus RTK-le:

• Millele täpselt tugineb väide, et EHR liidestuse mitteteostamine MVP-faasis tähendab,

et kogu projekt ei vasta taotluses kirjeldatule?

• Kuidas on RTK hindamismetoodikas arvestatud proportsionaalsuse printsiipi - st kas

ühe väikese (konkreetselt EHR lõpliku liidestuse, mis määrab vähem kui 1% projekti

tulemist) tegevuse mittetäitmine võib tühistada kogu projekti muu tulemuse, mis on

kooskõlas nii määruse eesmärgiga (§ 2 lg 1) kui taotluses kirjeldatud sihiga?

Tänase päeva seisuga projekti raames valminud lahendus ei põhine e-ehituse platvormil.

Antud väide eeldab üheselt mõistetavat ja objektiivset definitsiooni, mida RTK ei ole seni

esitanud. Seetõttu palume järgmist:

Palume RTK-l esitada täpne ja siduv definitsioon terminile „põhineb e-ehituse platvormil“:

• Kas „põhinemine“ tähendab üksnes tehnilist API-liidestust e-ehituse (EHR) registriga?

• Või mõistab RTK, et „põhinemine“ võib toimuda ka andmete struktureerimisel e-

Ehituse platvormi nõuetele vastaval kujul, isegi kui liidestust ei ole veel tehniliselt

lõplikult aktiveeritud?

• Või on RTK seisukoht, et „põhinemine“ sisaldab üksnes valmis ja aktiivset API-

integratsiooni ning muid seoseid (nt arhitektuuriline või semantiline sidusus) ei loeta

üldse? Arvestades, et seda ei ole taotluses määratud, ning et see määrab vähem kui

1% projekti sisust ning eesmärgist.

Toetuse saaja seisukoht: lahendus põhineb e-ehituse platvormil funktsionaalselt ja

arhitektuuriliselt.

Vastavalt toetuse saaja taotlusele ja tänaseks saavutatud MVP tulemile:

• kogu lahendus on üles ehitatud arvestades EHR-i loogikat ja andmestruktuure;

• varjualuse andmestik (sh mõõdud, võimsus, laadijad) on ette valmistatud

masintöödeldavas formaadis (JSON/XML);

• arhitektuuriliselt on süsteemil olemas valmisolek edasisteks liidestuseks, kui see on

praktiline, mõistlik, ning majanduslikult loogiline.

• kasutajaliideses ja planeerimisvoos on järgitud sammu-sammulist loogikat, et tagada

lõppkasutajale sujuv üleminek ja andmete ühtlustatus.

Taotluses ei ole määratud, et „põhinemine“ tähendab kohustuslikku otseliidest MVP faasis,

mis muudab väite eksitavaks ja hinnangu subjektiivseks.

Toetuse saaja taotluses on sõnaselgelt märgitud, et projekti seos e-Ehituse platvormiga

seisneb eelduste loomises uute andmete tekkeks ja protsesside digitaliseerimiseks, mitte

valmis API-liidese realiseerimises MVP raames.

Muu hulgas:

„Seos e-ehituse platvormiga: eelduste loomine uute andmete tekkeks (nt protsesside

automatiseerimine ja digitaliseerimine).“

Selline sõnastus tähendab, et süsteemi arhitektuur ja andmeloogika peab looma tulevikus

potentsiaali integratsiooniks - mitte nõudma, et see liidestus oleks MVP faasis tehniliselt

juurutatud.

RTK väide, et projekt ei põhine e-ehituse platvormil, ignoreerib:

• projekti arendusprotsessi lähtekohti ja arhitektuuri;

• semantilist ja funktsionaalset sidusust e-ehituse dokumentatsiooni- ja

andmemudeliga;

• ning määruse eesmärki, mis ei nõua MVP-faasis lõplikku tehnilist liidestust.

Q7 Seetõttu palume RTK-l täpsustada:

1. avada oma definitsioon terminile „põhinemine e-ehituse platvormil“;

2. Millisel õiguslikul või metoodilisel alusel loetakse ainult lõplikke liidestusi kehtivas

määruses või hindamismetoodikas „põhinemiseks e-ehituse platvormil“?

3. selgitada, miks RTK ei arvesta funktsionaalse, andmestruktuurse ja arhitektuurilise

sidususe alusel põhinevat seost;

4. põhjendada, kuidas on nende tõlgendus kooskõlas määruse § 2 lg 1 ja MVP-

loogikaga,

5. Kuidas arvestab RTK toetuse eesmärki määruse § 2 lg 1 tähenduses - „stimuleerida

uuenduslikke digilahendusi, mis on seotud e-ehituse platvormiga“ - kui toetuse saaja

on loonud toimiva süsteemi, mis toetub e-ehituse struktuuridele ja võimaldab

tulevikus edasisi liidestusi?

RTK kontrollis, kuidas toimib projekti raames valminud tööriist veebilehel canopies.me.

Aadressi sisestamisel tuleb koheselt teavitus, et katastri andmed pole hetkel kättesaadavad,

mis tähendab, et andmeid ei saada õigetest allikatest (toetuse saaja väide esitatud videos).

Kas RTK kontrollis seda päringu käigus, või ka logis portaali sisse ja kontrollis andmeid?

Veebilehel võis tegemist olla tehnilise veaga, mis oli seotud Maa-ameti WFS teenuse ajutise

katkestusega. Nimetatud teenus on mittekontrollitav väline komponent, mille kättesaadavus

ei peegelda lõppkasutuse loogikat ega süsteemi kavandatud arhitektuuri.

Portaalis sees on päringu teinud klientide puhul katastri info (jm seonduv info) märgitud:

Juhime tähelepanu, et antud piltidel on mh kuvatud

• Aadress ja katastriandmed

• Täisehituse määr

• Piiritletud kataster ja hoone

• Märgitud varjualuse perspektiivne asukoht

Ehk siis 100% süsteem kuvab seda, mida toetluse taotluses on projekti eesmärgiks MVP faasis

seatud.

Mh lisame siia näite, et ka RTK etoetuste keskkonnas (mis on suurele kasutajaskonnale

mõeldud kommertsversioon) esineb tõrkeid (just värskelt tehtud screenshot), seega on

kummaline RTK poolt oodata, et MVP töötab laitmatult, ning heita ette detaile, mis tegelikult

ei ole kohased:

Q8 Palume RTK-l vastata:

• Kas RTK hinnang MVP lõpptulemile sõltub üksnes testimise hetkeandmetest või

arvestatakse ka dokumenteeritud arhitektuuri ning funktsionaalsust, mis on testitud

arendusprotsessi käigus?

• Kas RTK peab mõistlikuks, et toetusprojekti edukus või ebaõnnestumine otsustatakse

ühe testimise põhjal, mille üle toetuse saajal puudub kontroll?

Varjualuse projekti andmed ei liigu EHR-i (mis asub e-ehitis platvormil) ning seega pole ka

toetuse andmise eesmärk täidetud (seos e-ehitise platvormiga).

RTK väide, et „andmed ei liigu EHR-i, seega ei ole toetuse andmise eesmärk täidetud“, põhineb

tõlgendusel, mille kohaselt ehitise andmete liikumine EHR-i (Ehituse Register) on toetuse

saamise peamine ja ainus kriteerium seotuse määratlemisel e-ehituse platvormiga.

See on tõlgenduslikult ja sisuliselt problemaatiline mitmel põhjusel:

1. Vastuolu: seos ≠ andmete liikumine EHR-i

RTK asetab võrdusmärgi väite vahele:

"andmed ei liigu EHR-i" = "seos e-ehituse platvormiga puudub"

Q9 Küsimus:

• Milline määruse või meetme seletuskirja konkreetne punkt annab aluse pidada

andmeedastust EHR-i ainsaks või kohustuslikuks tõendiks seosest e-ehituse

platvormiga?

• Kuidas RTK defineerib mõistet "seos" - kas see on tehniline liidestus, andmete

automaatne edastus või võib see olla ka sisuline ja arhitektuurne seos, nagu mitmed

taotlusmaterjalid viitavad? Palume viidata konkreetsele allikale, mille järgi seos

defineeritakse.

2. Määruse §2 lõike 1 sõnastus:

Määruses on kirjas:

„Toetuse eesmärk on stimuleerida ehitusvaldkonna ettevõtjaid looma või rakendama

uuenduslikke digilahendusi, mis tõstavad sektori tootlikkust ja on seotud e-ehituse

platvormiga.“

Siin ei täpsustata, et „seotud“ tähendab EHR andmeliidestust. Tegu on üldisema eesmärgiga,

mille saavutamise viisid võivad olla mitmekesised – sh kaudne arhitektuurne või

kasutusloogiline seotus, mitte ainult tehniline liides.

3. Varasemalt esitatud projekti eesmärk ja panus:

Toetuse saaja on korduvalt väljendanud ja dokumenteerinud, et:

„Projekti kaugem siht on muuta koduste solar-varjualuste tellimine ja paigaldamine lihtsaks,

läbipaistvaks ja digitaalselt juhitavaks, vähendades turul valitsevaid takistusi ning edendades

taastuvenergia ja elektriautode laadimise lahenduste laiemat kasutuselevõttu.“

„Projekt panustab ehitusvaldkonna digitaliseerimisse, luues uuendusliku digilahenduse, mis

tõstab sektori tootlikkust ja on integreeritav e-ehituse platvormiga.“

Nendes kirjeldustes pole väidetud, et toetuse eesmärk oleks teostatud EHR integratsioon MVP-

faasis. Integratsiooni võimalikkus on olnud üks tehniline võimalus projekti eesmärgi

realiseerimiseks, aga mitte projekti eesmärk. Seda kinnitab ka asjaolu, et MVP loogika on

leevendava iseloomuga ning lubab osalist funktsionaalsust, mitte lõplikku kommertslahendust.

4. Automatiseeritud EHR integratsiooni tegelik mõju tööprotsessile:

Andmete automaatne saatmine EHR-i (näiteks XML või X-tee kaudu) võimaldab vähendada

sisestamise aega maksimaalselt ca 5-6 minuti võrra varjualuse kohta.

Kogu protsessi tööefektiivsusest moodustab see alla 1%, samas kui kogu lahenduse

(Canopies.me) eesmärk on:

• võimaldada tuvastada, kas varjualus on tehniliselt sobiv,

• teha hinnang kulu, planeerimise ja dokumentatsiooni keerukuse kohta,

• luua visuaalne ja juriidiliselt kooskõlas olev eskiis.

Sellest tulenevalt ei saa automatiseeritud EHR üleslaadimist pidada projekti eesmärgi

tuumaks ega ainsaks tähenduslikuks komponendiks.

Q10 Kokkuvõtvad küsimused RTK-le:

1. Palume RTK-l esitada määrusest või juhendmaterjalidest konkreetne definitsioon või

juriidiline alus, mille põhjal:

o "seos e-ehituse platvormiga" tähendab automaatselt andmeedastust EHR-i,

o ning millisel alusel loetakse, et seos puudub, kui EHR andmeliidestus pole

lõplikult MVP-s rakendatud.

2. Millistel alustel ja millise määratluse järgi loeb RTK, et toetuse eesmärk on täitmata,

kui:

o projekti on loodud tööriist, mis automatiseerib ja digiteerib varjualuste

kavandamise, hinnastamise ja dokumentatsiooni,

o ning tööriist on arhitektuurselt ja kasutusvoogude tasandil valmistatud ette EHR

integratsiooniks, kuid see ei ole MVP-fookusesse tõstetud selle marginaalse

efektiivsuse tõttu?

3. Palume RTK-l selgitada, kas toetuse eesmärgi täitmine on defineeritud ainult ühe

tehnilise andmevoo kaudu (EHR integratsioon) või toetatakse ka laiemalt

ehitussektori digilahenduste loomist ja tootlikkuse kasvu, nagu määrus §2 lõige 1

viitab?

Toetuse saaja väidab, et MVP-faasi käigus selgus uut infot, mis pani teid kohandama lahenduse

arhitektuuri, järgides MVP põhimõtet „minimaalne toimiv väärtus“, sh EHR-i üleslaadimine on

võimalik - kuid mitte MVP-faasis mõistlik.

Antud väide eeldab ja konstrueerib olukorra, justkui oleks projekti tuumtegevustest loobutud

või neid oluliselt muudetud. Tegemist on tõlgendusliku moonutusega, mis ei põhine ei

määrusel, taotlusel ega projekti tegelikel tegevustel.

Toetuse saaja muutis sisuliselt projekti tegevusi, loobudes süsteemi liidestamisest e-ehituse

platvormiga (väites, et see on siiski võimalik). Tegemist on olulise muudatusega, kuna toetuse

andmise eesmärk on seotus e-ehituse platvormiga ja selle eesmärgi saavutamiseks toetatakse

e-ehituse platvormil põhinevate ja eraldiseisvate uuenduslike digilahenduste väljatöötamist,

prototüüpimist või projektide rakendamist ehitusvaldkonnas. Tänase päeva seisuga valminud

süsteem ei põhine e-ehituse platvormil.

1. Fakt: MVP-faasis tehtud valikud ei ole sisuline loobumine

Projekti käigus ei ole ühestki projekti sisulisest eesmärgist loobutud, sh ei ole loobutud e-

ehituse platvormiga seotusest. Vastupidi - kogu lahenduse arhitektuuriline loogika ja

sisendvood (nt aadressipõhine krundi kontroll, varjualuse mõõdistus ja kooskõlastusloogika)

on välja töötatud arvestusega, et neid saab lähitulevikus EHR või muude e-ehituse

komponentidega siduda. Seos ning integreeritus e-Ehituse platvormiga on konkreetselt

olemas.

Faktina on EHR-i liidestus projekteeritud ja dokumenteeritud - lihtsalt mitte MVP-faasis

tehniliselt lõplikult juurutatud. EHR-i üleslaadimine on võimalik, planeeritud ning

arhitektuuriliselt ette valmistatud. Küll aga, arvestades MVP-fookust ning selle mõju projekti

töömahtudele, ei olnud selle lõplik integrerimine prioriteet selle faasi jooksul (selle funktsiooni

marginaalne mõju tööaja kokkuhoiule on varem esitatud - ca 5-6 min ühe juhtumi kohta).

Samuti viitab määrus ressursside efefktiivsele kasutamisele, ning antud puhul oleks EHR’i lõplik

integratsioon olnud ressursside väga ebaefektiivne kasutamine.

2. RTK väide süsteemi „ei põhine e-ehituse platvormil“ on meelevaldne ja määratlemata

RTK kasutab mõistet „ei põhine e-ehituse platvormil“, kuid ei esita:

• ühtki ametlikku määratlust, mida tähendab „põhinemine“ antud kontekstis,

• ega põhjenda, miks arhitektuurne seotus, ettevalmistatud andmevood ja planeeritud

EHR integratsioon ei kvalifitseeru e-ehituse platvormiga seotuks, vastavalt määruse §2

lõike 1 sõnastusele („seotud e-ehituse platvormiga“).

Q11 Küsimus RTK-le:

Millise konkreetse määratuse või juhendmaterjali alusel otsustatakse, et tööriist ei „põhine“

e-ehituse platvormil, kui kõik loogikad ja sisendid (krundipõhisus, planeerimine,

dokumenteerimine) on ehitatud arvestusega, et need andmed saaks liikuda EHR-i?

3. MVP-otsused tulenesid nõuetekohasest arendusprotsessi juhtimisest, mitte projekti

muutmisest

EHR lõpliku liidestuse MVP-faasis edasi lükkamine oli teadlik ja põhjendatud otsus, tuginedes:

• tegelikule mõjule (marginaalne tööaja kokkuhoid, <1% protsessi kogumõjust),

• tehnilisele ja õiguslikule ebakindlusele (EHR API muutuv dokumentatsioon,

ligipääsutingimused)

MVP-lahendus ei ole projekti eesmärkide muutmine, vaid nende realiseerimise mõistlik,

tõenduspõhine etapistus.

4. Projekti eesmärk on realiseeritud vastavalt määrusele – skaleeritava ja seotava

digilahenduse loomine

Projekti tulemusel on loodud:

• skaleeritav ja testitud prototüüp,

• mille sisend- ja väljundstruktuurid on arendatud arvestusega e-ehituse platvormi

seotavuseks,

• ning mille väärtus seisneb eelkõige kasutajakogemuse, protsessi efektiivsuse ja

digitaalse dokumentatsiooni kättesaadavuse kasvus - mis kõik aitavad täita määruses

toodud eesmärki tõsta sektori tootlikkust.

Q12 Küsimused RTK-le:

1. Millise määratluse alusel on RTK järeldanud, et toetuse saaja on „loobunud“ süsteemi

liidestamisest e-ehituse platvormiga, kui liidestus on arhitektuuriliselt ette valmistatud,

võimalik ning MVP-faasis teadvustatult mitteprioriteetne?

2. Kas RTK-l on olemas ametlik määratlus mõistetele „seos“ ja „põhinemine e-ehituse

platvormil“, või tugineb RTK tõlgenduslikule seisukohale? Kui määratlus eksisteerib,

palume sellele viidata.

3. Millise alusel loetakse MVP-faasis tehtud tehnilise järjekorra valik – mille puhul

liidestuse tegemine lükatakse hilisemasse arendusfaasi – projekti sisuliseks

muutmiseks, kui kogu projekt loodi MVP-lahenduse loogika alusel ning RTK on ise MVP

olemust varasemalt rõhutanud?

4. Millise määruse punkti alusel saab RTK väita, et toetuse andmise eesmärki ei ole

täidetud, kui kogu projekti arhitektuur ja digilahendus on üles ehitatud arvestusega, et

see on seotud e-ehituse platvormiga, kuid teatud tehnilised etapid on MVP-faasis edasi

lükatud?

Meetme määruse § 25 punkti 11 kohaselt on toetuse saaja kohustus viivitamata kirjalikult

teavitada vahendusasutust (RTK) asjaoludest, mis vältimatult või suure tõenäosusega

takistavad projekti ettenähtud tulemuste saavutamist. Kuna valminud süsteemi liidestamine

e-ehituse platvormiga oli üks olulisemaid eesmärke, siis toetuse saaja oleks pidanud koheselt

RTK-d teavitama, kui ilmnesid asjaolud, et projekti tulemust ei ole võimalik saavutada

ettenähtud kujul.

RTK viitab oma seisukohas meetme määruse § 25 punktile 11, mille kohaselt on toetuse saaja

kohustatud viivitamata kirjalikult teavitama RTK-d asjaoludest, mis vältimatult või suure

tõenäosusega takistavad projekti ettenähtud tulemuste saavutamist. RTK järeldab seejärel, et

toetuse saaja oleks pidanud teavitama, kui selgus, et süsteemi liidestamine EHR’gaei ole

praktiline MVP-faasis. Väidetakse, et tegemist on „olulise muudatusega“, millest tulenevalt

oleks pidanud RTK-d teavitama.

Käesolevaga palume esitada RTK-l sisuline põhjendus ja viide, kust täpselt pärineb väide, et

lõplik integratsioon EHR’ga oli projketi üks olulisemaid eesmärke. Selline kvalifikatsioon ei

kajastu ei meie projekti taotluses, projekti eelarves, ega ka määruse tekstis.

1. Projekti eesmärgid ja tulemused on täidetud

RTK seisukoht ignoreerib või moonutab projekti tegelikku eesmärki, mis on selgelt sõnastatud

toetuse saaja taotluses. Lubage tsiteerida:

Projekti eesmärk ja tulemused (projekti taotlusest, esitatud 20.02.2025):

„Projekti kaugem siht on muuta koduste solar-varjualuste tellimine ja paigaldamine lihtsaks,

läbipaistvaks ja digitaalselt juhitavaks, vähendades turul valitsevaid takistusi ning edendades

taastuvenergia ja elektriautode laadimise lahenduste laiemat kasutuselevõttu. Projekt

panustab ehitusvaldkonna digitaliseerimisse, luues uuendusliku digilahenduse, mis tõstab

sektori tootlikkust ja on integreeritud e-Ehituse platvormiga.

Eesmärk on luua tööriist, mis automatiseerib solar-varjualuste tellimise, projekteerimise,

dokumenteerimise protsessid, lihtsustades koduomanike jaoks varjualuste soetamist ja aidates

kaasa taastuvenergia eesmärkide saavutamisele.“

Kõik ülaltoodud eesmärgid on täidetud - funktsionaalsused, mida MVP peab katma, on

toimivad ja testitud. Juhul kui RTK ei pea seda tõenduspõhiseks, palume konkreetset viidet,

millisele dokumendile või mõõdikuühikule (nt KPI) tuginedes väidetakse, et eesmärk ei ole

täidetud. Siinjuures tuletame meelde, et:

• „Projekti tulemused“ ei võrdu „ühe alamfunktsiooni olemasoluga“, vaid tervikuna

seatud sihiga, mis on seotud kasutajakogemuse, sektoritootlikkuse ning digitaalse

töövoo lihtsustamisega.

• EHR-tehniline lõplik liidestus moodustab kogu tööriista mõjust alla 1% ulatuses,

hinnanguliselt lühendades ehitusprojekti esitamist professionaalse koostaja jaoks 5–6

minuti võrra.

2. MVP-faasis tegemist ei olnud olulise muudatusega

RTK kvalifitseerib MVP-faasis tehtud otsuse EHR-ga mitte lõplikult liidestuda „oluliseks

muudatuseks“, kuid seda järeldust ei toeta ei määrus, taotlus ega meetme infomaterjalid. Taas

kord:

• Meetme määrus ega taotluse struktuur ei nõua tehnilise liidestuse teostamist MVP

raames, vaid rõhutavad „seotust e-ehituse platvormiga“. Seotus ei tähenda mitte

mingil kujul integratsioone.

3. Teavitamiskohustus eeldab teadmist takistusest

Meetme määruse § 25 p 11 kohustab teavitama olukorras, kus toetuse saajal on teada

asjaolud, mis vältimatult või suure tõenäosusega takistavad projekti ettenähtud tulemuste

saavutamist. Antud juhul:

• Prototüüp täidab projekti seatud eesmärgid.

• EHR-tehniline lõplik liidestus ei olnud MVP-faasis otstarbekas ega ajaraamistikus

teostatav - kuid see on tulevikus võimalik, ja vastavad arhitektuurilised valikud on

tagatud.

• Kuna ei ole tekkinud „vältimatut takistust“ projekti eesmärgi täitmisel, ei saa siinkohal

rääkida määrusest tuleneva teavitamiskohustuse rikkumisest.

Kuna projekti olemust, eesmärki ega seatud tulemusi ei ole muudetud, ei olnud kohustust RTK-

d sellest eraldi kirjalikult teavitada.

Q13 Küsimused RTK-le

1. Palume RTK-l defineerida, millise loogika või allika alusel kvalifitseeritakse EHR-

tehniline liidestus projektis „üheks olulisemaks eesmärgiks“?

Palume viidet määruse sättele, hindamismudelile või taotluse konkreetsele lõigule.

2. Palume selgitada, milliste konkreetsete meetrikate või tulemusnäitajate alusel on RTK

jõudnud järelduseni, et projekti eesmärki ei ole täidetud, tulenevalt konkreetselt

taotluses kirjeldatud ning siin eelpool refereeritud (siia kopeeritud) selgesõnalisest

kirjeldusest?

3. Millisel õiguslikul või metoodilisel alusel peab MVP prototüüp sisaldama 100% kõiki

funktsioone, sh tehnilisi liidestusi, kui see pole määruses ega taotluses defineeritud?

KOKKUVÕTE JA PÕHISEISUKOHT

Käesoleva järelevalvemenetluse raames on kujunenud murettekitav olukord, kus toetust

andev asutus (RTK) on asunud järjestikuste kirjade ja seisukohtade kaudu:

1. faktiliselt moonutama projekti taotluse sisu ja eesmärke;

2. valikuliselt ümber tõlgendama määrusest ja toetuse andmise põhimõtetest

tulenevaid kohustusi;

3. taotlema mitte tegelike tulemuste, vaid formaalsete tehniliste valikute hindamist,

mis ei ole kooskõlas EL-i rahastuse ega MVP loogika põhimõtetega.

Me lükkame sellise lähenemise tagasi.

Projekti tulemus on saavutatud - MVP töötab ja on testitud

Nagu korduvalt põhjendatud ja tõendatud, on projekti eesmärgid täidetud. Taotluses

defineeritud ülesanne - luua tööriist, mis automatiseerib koduste solar-varjualuste tellimise,

projekteerimise, dokumenteerimise ja hinnastamise protsessi - on ellujõudnud toimivaks

MVP prototüübiks. Seda kinnitab:

• toimiv lahendus (canopies.me);

• testimiste ja lõppkasutajate kaasamine;

• sihtturu kasutusloogika valideerimine;

• süsteemi arhitektuuriline ettevalmistus ka EHR liidestuseks (oluline välja tuua, kuna

RTK püüab käesoleva teemaga projekti saboteerida; kui see osutub teostatavaks ja

kasulikuks).

RTK ignoreerib seejuures täielikult põhiküsimust: kas tööriist töötab ja täidab eesmärki - ehk

sisulist tulemust. Sellise sisulise saavutuse mittearvestamine on vastuolus nii Eesti õiguse

mõtte kui EL-i rakendusmääruste praktikaga.

Euroopa Komisjoni praktikad ja määrused: tulemus on tähtsam kui teekond

Viitame siinkohal Euroopa Komisjoni üldisele praktikale ja määrustele, sh nt

rakendusmäärus nr 1303/2013, mille kohaselt:

„Makse aluseks on eelkõige projekti sisuline edasiliikumine ja tulemuste mõju, mitte

formaalne üksikaktiivsuse 1:1 täitmine.“

Seega on toetuse andmise ja kontrollimise loogika tuumaks:

• kas projekti tuumne eesmärk on saavutatud (antud juhul: jah),

• kas kulud on läbipaistvad ja põhjendatud (jah),

• kas MVP tõestab arendusloogikat ja võimaldab skaleerimist (jah),

• mitte see, kas iga deklaratiivne lubadus iga alamtegevuse lõikes on 1:1 täidetud (nt

konkreetne liidestus API-ga MVP raames).

RTK järeldused ignoreerivad määruse vaimu ja tulemuslikkuse loogikat

RTK on oma järeldustes jäänud kinni deklaratiivsetesse fraasidesse („seos e-ehituse

platvormiga“), tõlgendades neid kui vältimatut kohustust MVP faasis saavutada tehniline

EHR-integratsioon, mis ei ole:

• ei määruses kirjas,

• ei taotluses kohustusena sõnastatud,

• ega ka mõistlik MVP kontekstis, kus see annab alla 1% efekti lõpptarbijale.

RTK keeldub arvestamast objektiivse vaatega sellele, millist sisulist väärtust projekt sektorile

lõi ja kuidas MVP loogika võimaldas optimaalset ressursside kasutust.

Kui toetuse saaja on MVP-faasis lahendanud sama funktsiooni teisel viisil (nt käsitsi

dokumentide üleslaadimine või valmis andmestruktuuri koostamine), on sisuline eesmärk

saavutatud ning see ei tähenda kohustuse rikkumist.

Kuna projekt täidab nii määruses kui taotluses esitatud eesmärgid, ei ole toetuse

tagasinõudmine proportsionaalne, põhjendatud ega kooskõlas Euroopa Liidu

rahastuspraktikaga.

Q14 Küsimus RTK-le

Miks ignoreerib RTK täielikult Euroopa Komisjoni rahastuse põhiloogikat ja määruste

praktikat, mille kohaselt on oluline just tulemuse saavutamine, mitte iga vahepunkti jäik

järgimine?

Kui tööriist töötab, MVP on valminud ja skaleerimisvõimekus on olemas, siis:

1. mille põhjal RTK järeldab, et projekti tulemused ei ole saavutatud?

2. milline on RTK ametlik määratlus sõnale seos e-ehituse platvormiga?

3. mida RTK mõistab „põhinemise“ all? Kas ainult andmeliidese olemasolu?

4. kuidas saab ühe väikese alamfunktsiooni (EHR integratsiooni) MVP-faasis mitte

realiseerumine tähendada kogu projekti ebaõnnestumist, kui kogu ülejäänud tööriist

töötab ja on arendatud vastavalt plaanile?

5. kuidas defineerib RTK "seose e-ehituse platvormiga", kui määrus lubab ka

eraldiseisvaid lahendusi, mis loovad uusi andmevooge või tõstavad sektori tootlikkust?

Väide 1: RTK väidab, et projekti tulemus ei vasta taotluses lubatule

RTK alusmõte on, et lõpptulemus ei vasta täies mahus taotluses kirjeldatule, mistõttu ei ole projekt nende hinnangul nõuetekohaselt ellu viidud ning tulemusnäitajat „lõpetatud projektide arv“ ei saa lugeda saavutatuks. Sama loogika oli neil juba järelevalvemenetluse algatamise kirjas, kus nad väitsid, et valminud projekt ei vasta täies mahus planeeritud tulemustele ning makse aluseks olnud tegevused ei ole täies ulatuses ellu viidud.

Meie põhivastus

Selle väite keskne probleem on, et RTK on asendanud projekti tegeliku tulemuse hindamise ühe tehnilise alamkomponendi formaalse kontrolliga. See ei ole kooskõlas ei projekti taotluse sisulise loogika, meetme eesmärgi ega ka proportsionaalse haldustegevuse põhimõttega.

Projekti taotluses kirjeldatud põhieesmärk ei olnud ühe konkreetse tehnilise integratsiooni realiseerimine iseeneses, vaid toimiva digitaalse tööriista loomine, mis muudab koduste solar-varjualuste tellimise, planeerimise ja dokumenteerimise lihtsamaks, läbipaistvamaks ja digitaalselt juhitavaks. See eesmärk on saavutatud. Meie varasemates vastustes on see väga selgelt lahti kirjutatud: valmis on kasutatav konfiguratsioonitööriist, automaatne hinnastamise loogika, dokumentatsiooni eelvormistamise võimekus, kasutajaliides, pilootkasutajatega testitud töövoog ning reaalse väärtuspakkumise valideerimine.

RTK praegune käsitlus jätab mulje, nagu loeks kogu projekti õnnestumise või ebaõnnestumise ainsaks mõõdupuuks see, kas üks konkreetne tehniline detail - EHR-i lõplik automaatne liidestus - on MVP-faasis täielikult realiseeritud. Selline käsitlus on sisuliselt ja praktiliselt väär, sest see taandab kogu projekti üheks alamelemendiks ja ignoreerib ülejäänud lahenduse 99% sisu, eesmärki ja tegelikku mõju.

Miks RTK väide on nõrk

1. RTK ei tee vahet projekti eesmärgil, projekti tulemil ja tehnilisel teekonnal

See on nende suurim loogiline viga.

Projektis tuleb eristada vähemalt kolme tasandit:

● projekti eesmärk - mida sooviti saavutada, ● projekti tulemus - mis reaalselt valmis, ● projekti tehniline teostusviis - kuidas selle tulemuseni jõuti.

RTK käsitlus segab need kolm tasandit kokku. RTK kohtleb üht esialgses taotluses kirjeldatud tehnilist lahendusteed justkui projekti lõppeesmärgina. See ei ole korrektne.

Kui eesmärk oli luua toimiv, testitud ja edasiarendatav digilahendus solar-varjualuste planeerimiseks, hinnastamiseks ja dokumenteerimise lihtsustamiseks, siis see eesmärk on täidetud. Kui teatud alamelement – näiteks automaatne EHR üleslaadimise lõppintegratsioon - ei realiseerunud MVP-faasis täpselt esialgselt mõeldud kujul, ei tähenda see automaatselt, et projekt tervikuna on tegemata.

2. RTK ignoreerib projekti sisulist tulemit

RTK väide “tulemus ei vasta” oleks veenev ainult siis, kui valmis oleks sisuliselt mittetoimiv või kasutuskõlbmatu lahendus.

Aga tegelikult valmis MVP töö käigus:

● kasutajasõbralik digitaalne platvorm, ● automaatne konfiguratsiooniloogika, ● indikatiivse hinnapakkumise genereerimine, ● võtmed-kätte teenusloogika, ● dokumentatsiooni eelvormistamine, ● reaalselt testitud MVP, ● 12 koduomanikuga läbiviidud testimine ja veaparandused, ● tõendatud kasutajaväärtus ja rahulolu.

Sellise faktilise seisu juures ei saa heas usus väita, et projekti tulemus puudub või et projekt oleks sisuliselt läbi kukkunud. Maksimaalselt saab vaielda selle üle, kas üks konkreetne funktsionaalne komponent realiseerus täies mahus või mitte. Aga see on juba proportsionaalsuse küsimus, mitte terve projekti olemuse eitamise küsimus.

3. RTK ei ole näidanud, milline täpselt on see saavutamata “tulemus”

See on väga oluline.

Kui RTK väidab, et tulemus ei vasta taotluses lubatule, siis peab RTK väga täpselt välja tooma:

● milline konkreetne tulemus jäi saavutamata, ● millises taotluse punktis see tulemus oli defineeritud, ● miks selle ühe tulemuse osaline mittesaavutamine tühistab kogu projekti, ● ja miks muud saavutatud tulemused ei oma õiguslikku ega sisulist kaalu.

Praegu RTK seda ei tee. RTK üldistab.

RTK liigub liiga kiiresti väitest “üks osa ei vasta” väitesse “kogu projekt ei vasta”. See hüpe vajab väga tugevat põhjendust, mida neil praegu ei ole.

4. RTK ei arvesta toetuse andmise tulemuspõhist loogikat

Meie varasem vastus õigesti rõhutab, et § 23 lg 4 p 1 mõte ei ole nõuda iga alamtegevuse jäika 1:1 täitmist, vaid hinnata, kas makse aluseks olnud tegevused on sisuliselt ellu viidud ning kas projekt on eesmärgipäraselt teostatud.

Samuti rõhutasime õigesti, et EL rahastuse praktikast tuleneb tulemuspõhisus, mitte deklaratiivsete mikrodetailide absoluutne formalism. See on väga tugev argument.

RTK peaks seega vastama väga selgelt, miks nad eiravad täiesti projekti sisulist tulemit ja käsitlevad olukorda nii, nagu oleks tulemuseks null.

5. RTK tõlgendus viib absurdse tulemuseni

Kui võtta RTK loogika lõpuni tõsiselt, siis piisaks iga innovatsiooniprojekti puhul sellest, et üks mitte-keskne alamfunktsioon ei realiseeru täpselt algses tehnilises vormis, et lugeda kogu projekt mitteteostatuks.

See oleks ilmselgelt vastuolus:

● MVP arendusloogikaga, ● innovatsioonimeetme eesmärgiga, ● ning terve mõistusega.

Selline käsitlus muudaks sisuliselt iga prototüüpimise projekti potentsiaalselt rahastuskõlbmatuks, kui arenduse käigus tehakse ratsionaalseid tehnilisi kohandusi.

Counter-argument lühikujul

RTK väide, et projekti tulemus ei vasta taotluses lubatule, on põhjendamata üldistus. Projekti põhieesmärk - luua toimiv, testitud ja väärtust loov prototüüp solar-varjualuste planeerimise, hinnastamise ja dokumenteerimise lihtsustamiseks - on saavutatud. RTK ei ole näidanud, milline konkreetne saavutamata tulemus õigustab järeldust, et kogu projekt tervikuna on läbi kukkunud. Tegelikult vaidlustab RTK ühe mitte-keskse tehnilise komponendi realiseerimise viisi ning üritab selle kaudu devalveerida kogu ülejäänud valminud lahendust. Selline käsitlus ei ole proportsionaalne ega kooskõlas tulemuspõhise rahastamisloogikaga.

Küsimused

Palume RTK-l täpselt määratleda, milline konkreetne projekti tulemus on nende hinnangul saavutamata. Mitte üldsõnaliselt “ei vasta täies mahus”, vaid punkt-punktilt.

Palume RTK-l põhjendada, millisel õiguslikul või metodoloogilisel alusel loetakse ühe alamfunktsiooni osaline mitteteostumine aluseks kogu projekti tulemuse eitamisele.

Palume RTK-l selgitada, miks ei arvestata valminud ja testitud prototüübi muid faktiliselt saavutatud komponente, mida toetuse saaja on dokumenteerinud ja mille olemasolu RTK ei ole sisuliselt ümber lükanud.

Palume RTK-l selgitada, kuidas on nende käsitlus kooskõlas proportsionaalsuse põhimõttega, kui vaidlusalune tehniline komponent moodustab projekti koguväärtusest ja mõjust hinnanguliselt alla 1%, samas kui ülejäänud lahendus töötab ja täidab eesmärki.

Kas RTK käsitleb innovatsiooniprojektide hindamisel projekti tulemust kui tervikut või taandab selle üksikutele tehnilistele detailidele?

II. Väide: EHR / e-ehituse platvormiga integratsioon puudub

RTK väidab, et projekti käigus ei ole realiseeritud e-ehituse platvormiga (sh Ehitisregistriga) liidestust, mistõttu ei ole täidetud taotluses kirjeldatud funktsionaalsus ning projekti eesmärk on seetõttu saavutamata.

Vastus

RTK käsitlus põhineb kitsendaval ja põhjendamata tõlgendusel, mille kohaselt tähendab „e-ehituse platvormiga seos“ või „integratsioon“ üksnes täielikult automatiseeritud andmevahetust Ehitisregistriga (EHR). Selline tõlgendus ei tulene ei taotluse sisust, meetme tingimustest ega kehtivast õiguslikust raamistikust.

1. „Integratsioon“ ei ole taotluses defineeritud kui kohustuslik EHR automaatne andmevahetus

Taotluses kasutatud sõnastused („seos e-ehituse platvormiga“, „dokumentatsiooni automatiseerimine“, „andmete ettevalmistamine ja edastamine“) kirjeldavad eesmärki ja suunda, kuid ei sätesta üheselt konkreetset tehnilist teostusviisi, milleks oleks tingimata:

● otsene API-põhine ühendus Ehitisregistriga, ● automaatne andmete üleslaadimine EHR-i, ● või kolmanda isiku nimel toimuv registrisse kandmine.

Oluline on rõhutada, et Eesti ehitusõiguslik raamistik ei võimalda ilma vastava autentimise ja volituseta kolmandal osapoolel automaatselt esitada dokumente Ehitisregistrisse teise isiku nimel. Seetõttu ei saa sellist tehnilist lahendust käsitleda ei standardse ega vältimatu eeltingimusena.

RTK ei ole oma otsuse eelnõus viidanud ühelegi normile, juhendile ega määratlusele, mille kohaselt „integratsioon“ tähendaks üksnes automaatset EHR andmevahetust.

2. Projekti raames loodud lahendus on e-ehituse platvormiga sisuliselt kooskõlas

Valminud lahendus:

● kogub ja struktureerib projektiandmeid samas loogikas, mida kasutatakse ehitusprotsessis, ● võimaldab koostada eeltäidetud dokumentatsiooni, ● loob aluse nende andmete edasiseks kasutamiseks Ehitisregistris, ● vähendab lõppkasutaja koormust dokumentatsiooni ettevalmistamisel.

See tähendab, et lahendus on funktsionaalselt ja andmestruktuuri tasandil kooskõlas e-ehituse platvormi loogikaga, isegi kui MVP faasis ei ole realiseeritud täielikku automaatset andmevahetust.

Selline lähenemine vastab taotluses kirjeldatud eesmärgile: lihtsustada ja digitaliseerida dokumenteerimisprotsessi ning luua alus edasiseks automatiseerimiseks.

3. MVP faasis ei ole täielik EHR integratsioon olnud projekti arendamise käigus selgunult proportsionaalne ega mõistlik

Käesolev projekt oli suunatud prototüübi (MVP) loomisele, mille eesmärk on valideerida lahenduse põhiloogika ja kasutatavus.

EHR automaatne liidestus:

● eeldab keerukat tehnilist ja õiguslikku raamistikku, ● puudutab üksnes väikest osa kasutajateekonnast (dokumentide esitamise etapp), ● ei mõjuta konfiguratsioonimootori ega kasutajaliidese toimimist.

Seetõttu ei ole sellise integratsiooni realiseerimine MVP faasis olnud proportsionaalne projekti eesmärgiga ega vajalik selleks, et hinnata lahenduse toimivust ja väärtuspakkumist.

RTK ei ole esitanud põhjendust, miks just see komponent oleks pidanud olema projekti keskne ja vältimatu osa, ega miks selle puudumine nullib kogu ülejäänud lahenduse väärtuse. Hindamiskriteeriumites seda komponenti ei ole mainitud.

4. RTK käsitlus taandab kogu projekti ühe tehnilise detaili tasemele

RTK järeldus, et projekti eesmärk ei ole täidetud, põhineb sisuliselt ühel asjaolul - automaatse EHR andmevahetuse puudumisel.

Selline käsitlus:

● ignoreerib projekti põhifunktsionaalsust (konfiguratsioonitööriist, hinnastamine, kasutajavoog, dokumentatsiooni eelvormistamine),

● jätab arvestamata reaalselt valminud ja testitud lahenduse, ● ning taandab projekti üheks tehniliseks integratsiooniks.

See ei ole kooskõlas ei projekti eesmärgi ega innovatsiooniprojekti hindamise loogikaga.

5. Küsimused RTK-le

Palume RTK-l selgitada:

1. Millisel õiguslikul alusel tõlgendab RTK mõistet „e-ehituse platvormiga integratsioon“ kui kohustuslikku automaatset andmevahetust Ehitisregistriga?

2. Millises dokumendis (määrus, juhend, hindamiskriteerium) on sätestatud, et EHR automaatne liidestus on projekti rahastamise eeltingimus?

3. Millisel alusel käsitleb RTK selle konkreetse tehnilise lahenduse puudumist kui projekti eesmärgi mittesaavutamist tervikuna?

4. Kas RTK hinnangul ei oma projekti ülejäänud funktsionaalsus (konfiguratsioon, hinnastamine, kasutajaliides, dokumentatsiooni struktureerimine) projekti eesmärgi saavutamisel sisulist kaalu?

III. Väide: Lahendus ei põhine e-ehituse platvormil

RTK väidab, et projekti raames valminud lahendus ei põhine e-ehituse platvormil ning sellest tulenevalt ei ole täidetud projekti eesmärgid.

Vastus

RTK väide põhineb määratlemata ja sisuliselt lahtisel mõistel „põhinemine e-ehituse platvormil“, millele ei ole esitatud ei õiguslikku definitsiooni ega metodoloogilist tõlgendust. Sellisel kujul ei ole võimalik hinnata, kas väide on põhjendatud, kuna puudub selge alus, mille suhtes projekti vastavust mõõdetakse.

1. Mõiste „põhineb e-ehituse platvormil“ ei ole normatiivselt defineeritud

Palume RTK-l viidata:

● millises õigusaktis, määruses või juhendmaterjalis on defineeritud, mida tähendab „põhinemine e-ehituse platvormil“;

● kas tegemist on tehnilise (API/X-tee integratsioon), funktsionaalse (andmete kooskõla ja protsessiloogika) või semantilise (andmestruktuuride ühilduvus) mõistega;

● millised on objektiivsed kriteeriumid, mille alusel hinnatakse, kas lahendus „põhineb“ või „ei põhine“ e-ehituse platvormil.

Ilma sellise definitsioonita jääb RTK väide sisuliselt hinnanguliseks ning ei vasta haldusmenetluses nõutavale põhjendatuse standardile.

2. RTK on asendanud mõiste „põhineb“ kitsendava tehnilise tõlgendusega

RTK käsitlusest nähtub, et „põhinemine e-ehituse platvormil“ on samastatud:

● otsese tehnilise liidestusega Ehitisregistriga (EHR), ● automaatse andmevahetusega, ● või dokumentide automaatse edastamisega registrisse.

Selline tõlgendus ei tulene taotluse sisust ega ole universaalselt kehtiv.

E-ehituse platvorm ei ole üksnes EHR API, vaid laiem ökosüsteem, mis hõlmab:

● andmestandardeid, ● protsessiloogikat, ● dokumentatsiooni struktuuri, ● ehitusprotsessi digitaliseerimist tervikuna.

Seega ei saa „põhinemist“ taandada üksnes sellele, kas andmed liiguvad automaatselt EHR-i.

3. Valminud lahendus on e-ehituse loogikaga sisuliselt kooskõlas

Projekti käigus loodud lahendus:

● struktureerib ehitusprojekti andmeid,

● võimaldab koostada dokumentatsiooni eelvorme, ● järgib ehitusprotsessi loogilist ülesehitust, ● loob aluse andmete edasiseks kasutamiseks Ehitisregistris.

See tähendab, et lahendus toetub e-ehituse protsessiloogikale ja andmestruktuurile, isegi kui MVP faasis ei ole realiseeritud täielikku tehnilist liidestust.

Selline lähenemine on kooskõlas taotluses kirjeldatud eesmärgiga: luua digitaalne tööriist, mis vähendab bürokraatiat ja lihtsustab dokumenteerimist.

4. RTK ei ole tõendanud, miks nende tõlgendus on ainuvõimalik

RTK ei ole esitanud põhjendust:

● miks „põhinemine e-ehituse platvormil“ peab tähendama just automaatset EHR integratsiooni; ● miks ei ole piisav funktsionaalne või andmepõhine kooskõla; ● miks ei saa MVP faasis käsitleda „põhinemist“ kui arhitektuurilist ja protsessilist valmisolekut.

Sellisel kujul on RTK tõlgendus sisuliselt ühepoolne ja valikuline.

5. RTK käsitlus loob ebamõistliku ja etteaimamatu standardi

Kui RTK seisukoht on, et „põhinemine e-ehituse platvormil“ tähendab alati täielikku tehnilist integratsiooni, siis:

● peab see olema selgelt sätestatud enne projekti rahastamist, ● peab see olema kajastatud hindamiskriteeriumides, ● peab see olema üheselt mõistetav kõigile taotlejatele.

Praegu selline selgus puudub.

Seetõttu ei ole põhjendatud rakendada tagantjärele kitsendavat tõlgendust, mille alusel hinnatakse projekt mitteabikõlblikuks.

Küsimused RTK-le

Palume RTK-l selgelt vastata:

1. Kuidas RTK defineerib mõistet „põhinemine e-ehituse platvormil“? 2. Millised on konkreetsed tehnilised või funktsionaalsed kriteeriumid, mille alusel see hinnang

antakse? 3. Kas RTK käsitleb „põhinemist“ ainult API-põhise integratsioonina või ka andmestruktuuri ja

protsessiloogika tasandil? 4. Millises normis või juhendis on selline tõlgendus fikseeritud? 5. Kas RTK hinnangul ei saa ükski MVP-lahendus „põhineda e-ehituse platvormil“, kui puudub

täielik tehniline liidestus?

IV. Väide: Lahendus ei toimi (canopies.me, katastriandmed ei ole kättesaadavad)

RTK väidab, et veebilehel canopies.me aadressi sisestamisel kuvatakse teade, et katastriandmed ei ole kättesaadavad, ning järeldab sellest, et:

● andmeid ei saada õigetest allikatest; ● lahendus ei toimi; ● projekti eesmärk ei ole täidetud.

Vastus

RTK järeldus põhineb üksikjuhtumi pinnapealsel vaatlusel ning ei vasta digilahenduste arenduse, MVP loogika ega süsteemide töökindluse hindamise põhimõtetele.

1. Üksik veateade ei tõenda süsteemi mittetoimimist

Digilahenduste puhul on normaalne, et:

● välised andmeallikad (nt katastriandmed) võivad olla ajutiselt kättesaamatud, ● API teenused võivad anda veateateid, ● teatud aadressid või sisendid ei pruugi anda tulemust.

Sellest ei saa teha järeldust, et:

● süsteem ei tööta, ● andmeid ei saada õigetest allikatest, ● või kogu lahendus ei vasta projekti eesmärgile.

RTK ei ole esitanud:

● süsteemset testimistulemust, ● korduvaid katseid erinevate sisenditega, ● tehnilist analüüsi andmeallikate kohta.

Järeldus on tehtud ühe vaatlusmomendi põhjal, mis ei ole piisav alus sellise ulatusega otsuseks.

2. RTK ei ole tuvastanud, milles seisneb väidetav „vale andmeallikas“

RTK väidab, et „andmeid ei saada õigetest allikatest“, kuid:

● ei ole nimetanud, millist konkreetset allikat peetakse „õigeks“, ● ei ole näidanud, millist allikat süsteem tegelikult kasutab, ● ei ole esitanud ühtegi tehnilist tõendit valeandmete kasutamise kohta.

Selline väide on sisuliselt põhjendamata.

3. MVP eesmärk ei ole garanteerida 100% andmete kättesaadavus

Käesolev projekt on MVP (Minimum Viable Product), mille eesmärk on:

● valideerida kasutajavoog, ● testida konfiguratsiooniloogikat, ● demonstreerida lahenduse põhifunktsionaalsust.

MVP ei ole:

● lõplik tootmiskeskkond, ● SLA-ga teenus, ● täielikult robustne integratsioon kõikide väliste andmeallikatega.

RTK käsitlus eeldab sisuliselt production-level töökindlust, mis ei ole MVP definitsiooni ega projekti eesmärgiga kooskõlas.

4. Projekti põhiväärtus ei sõltu üksikust andmeallikast

Oluline on rõhutada:

● projekti keskne komponent on konfiguratsioonitööriist, ● kasutajavoog, hinnastamine ja dokumentatsiooni loogika on lahenduse põhituum, ● katastriandmed on üks sisend paljudest, mitte süsteemi olemus.

RTK on taandanud kogu projekti ühe tehnilise sisendi kättesaadavuse küsimuseks, mis ei ole proportsionaalne ega sisuliselt korrektne.

5. RTK ei ole hinnanud lahendust tervikuna

RTK hinnang:

● ei käsitle konfiguratsioonimootori toimimist, ● ei käsitle kasutajaliidest, ● ei käsitle dokumentatsiooni genereerimist, ● ei käsitle süsteemi testimist tervikuna.

Järeldus projekti ebaõnnestumise kohta on tehtud ilma tervikhinnanguta.

Küsimused RTK-le

Palume RTK-l selgelt vastata:

1. Millise metoodika alusel hinnati süsteemi toimivust? 2. Kui mitme erineva sisendi ja kasutusjuhtumi põhjal tehti järeldus, et süsteem ei tööta? 3. Millised konkreetsed andmeallikad on RTK hinnangul „õiged allikad“ ning millele tugineb väide, et

neid ei kasutata? 4. Kas RTK hinnangul peab MVP-lahendus tagama katkestusteta ligipääsu kõikidele välistele

andmeallikatele? 5. Kas RTK peab ühe veaolukorra esinemist piisavaks aluseks kogu projekti mittetoimivaks

lugemisel?

V. Väide: Projekti on oluliselt muudetud ja RTK-d ei teavitatud (§ 25)

RTK väidab, et:

● toetuse saaja muutis projekti tegevusi, loobudes e-ehituse platvormi liidestamisest; ● tegemist on olulise muudatusega; ● toetuse saaja oleks pidanud RTK-d viivitamata teavitama vastavalt meetme määruse § 25

punktile 11.

Vastus

RTK järeldus ei vasta tegelikule olukorrale ega ole piisavalt põhjendatud. Väide tugineb eeldustele, mida ei ole faktiliselt tõendatud.

1. Projekti eesmärki ei ole muudetud

Projekti eesmärk taotluse kohaselt oli:

● automatiseerida solar-varjualuste tellimine, projekteerimine ja dokumenteerimine, ● lihtsustada kasutajateekonda, ● vähendada bürokraatiat ja tõsta sektori tootlikkust, ● luua seos e-ehituse platvormiga.

Kõik nimetatud eesmärgid on täidetud:

● lahendus (MVP) on loodud ja toimib, ● kasutajavoog ja konfiguratsioon on realiseeritud, ● dokumentatsiooni loogika on digitaliseeritud, ● andmete struktureerimine ja edasise kasutuse võimalus on olemas.

Seega ei ole toimunud projekti eesmärgi muutmist ega sellest loobumist.

2. EHR integratsioonist ei ole loobutud

RTK väide, et toetuse saaja on „loobunud liidestamisest“, ei vasta tõele, peab isegi mainima, et see on konkreetselt valeväide.

Tegelik olukord on järgmine:

● EHR integratsioon on tehniliselt võimalik ja arhitektuuriliselt ette nähtud, ● seda ei realiseeritud MVP faasis, kuna see ei olnud proportsionaalne ega mõistlik ega vajalik

prototüübi eesmärgi saavutamiseks, ● tegemist on arendusjärjekorra, mitte loobumisega.

RTK ei ole esitanud ühtegi tõendit, et:

● integratsioon oleks tehniliselt välistatud, ● või et toetuse saaja oleks sellest põhimõtteliselt loobunud.

3. § 25 kohaldamine eeldab objektiivset takistust, mitte arendusotsust

Meetme määruse § 25 punkt 11 kohustab teavitama:

asjaoludest, mis vältimatult või suure tõenäosusega takistavad projekti ettenähtud tulemuste saavutamist.

Käesolevas projektis:

● projekti tulemus on saavutatud (MVP valmis, testitud, toimiv), ● puudub asjaolu, mis oleks takistanud projekti elluviimist, ● tegemist ei ole takistusega, vaid teadliku MVP ulatuse määratlemisega.

Seega § 25 ei ole kohaldatav.

4. RTK käsitlus eeldab, et üks alamfunktsioon = kogu projekti tulemus

RTK loogika põhineb eeldusel, et:

● kui EHR integratsioon MVP-s puudub, - siis projekti tulemus ei ole saavutatud, - ja tegemist on olulise muudatusega.

See eeldus ei ole põhjendatud.

EHR integratsioon:

● moodustab marginaalse osa kogu lahendusest, ● ei mõjuta konfiguratsioonimootori, kasutajavoogude ega põhifunktsionaalsuse toimimist, ● ei ole projekti väärtuspakkumise keskne komponent.

Seetõttu ei saa selle MVP-faasis realiseerimata jätmist käsitleda „olulise muudatusena“.

5. RTK ei ole tõendanud „olulise muudatuse“ olemasolu

RTK ei ole esitanud:

● kriteeriume, mille alusel muudatus kvalifitseerub „oluliseks“, ● analüüsi, kuidas see mõjutab projekti eesmärgi saavutamist, ● põhjendust, miks see muudatus nullib projekti tulemuse.

Ilma sellise analüüsita jääb väide deklaratiivseks.

RTK väide projekti muutmise ja teavitamiskohustuse rikkumise kohta ei ole põhjendatud. Projekti eesmärki ei ole muudetud, EHR integratsioonist ei ole loobutud ning puudub asjaolu, mis oleks takistanud projekti tulemuse saavutamist. Tegemist on MVP arendusloogikast tuleneva ulatuse otsusega, mitte olulise muudatusega. Seetõttu ei ole § 25 kohaldamine käesolevas juhtumis asjakohane.

Küsimused RTK-le

Palume RTK-l täpsustada:

1. Millisel alusel järeldab RTK, et toetuse saaja on loobunud e-ehituse platvormiga liidestamisest? 2. Millised konkreetsed tõendid kinnitavad, et integratsiooni ei ole võimalik tulevikus realiseerida? 3. Kuidas defineerib RTK „olulise muudatuse“ ning milliste kriteeriumide alusel see käesoleval juhul

tuvastati? 4. Millisel alusel käsitleb RTK MVP faasis tegemata jäänud alamfunktsiooni kogu projekti tulemuse

mittesaavutamisena? 5. Kuidas RTK põhjendab § 25 kohaldamist olukorras, kus projekti tulemus (toimiv MVP) on

reaalselt saavutatud?

VI. Väide: „Kui oleks teadnud, et EHR integratsiooni ei tehta, ei oleks rahastatud“

Vastus

RTK väide, et projekti ei oleks rahastatud juhul, kui oleks teada olnud EHR integratsiooni mitte realiseerimine MVP faasis, ei ole kooskõlas projekti hindamisdokumentidega ning on sisuliselt tagantjärele konstrueeritud hinnang.

1. Hindamisdokumentides puudub igasugune viide EHR integratsioonile kui otsustavale tegurile

Projekti hindamisleht (Hindamisleht_Builderish OÜ_Config) näitab selgelt, milliste kriteeriumide alusel projekti hinnati:

● projekti vastavus toetuse eesmärgile ● projekti põhjendatus ● projekti kvaliteet ● taotleja võimekus

Üheski hindamiskriteeriumis:

● ei ole toodud EHR integratsiooni kui eraldi hindamiskomponenti, ● ei ole määratletud tehnilise liidestuse olemasolu kui rahastamise eeltingimust, ● ei ole hinnatud projekti edukust EHR andmevahetuse põhjal.

Vastupidi - hindamises esitatud kommentaarid keskenduvad:

● turu suurusele ja põhjendatusele, ● lahenduse innovaatilisusele, ● kirjelduste üldisusele, ● ning meeskonna võimekusele.

EHR integratsioon ei ole nende hulgas isegi kaudselt keskne teema.

2. Ainus viide e-ehituse integratsioonile puudutab RISKE, mitte eeltingimust

Hindamislehes on ainus asjakohane viide järgmine:

taotlejal ja arenduspartneril ei pruugi olla kogemust e-ehituse platvormiga liidestumisel ning sellest tulenevalt ei pruugi nad hinnata töömahtu ja riske.

See on oluline, sest:

● tegemist ei ole nõudega, ● tegemist ei ole eeltingimusega, ● tegemist ei ole hindamiskriteeriumiga,

vaid riskikommentaariga.

See tähendab, et isegi hindamise hetkel ei käsitletud EHR integratsiooni kui projekti keskset ega määravat elementi.

3. Rahastamisotsus kinnitab, et projekti tulemus on MVP, mitte integratsioon

Rahastamisotsuses on väga selgelt määratletud:

● projekti tulemus = - toimiv ja testitud prototüüp, - mida tõendab videodemo keskkonnast

Samuti on kirjeldatud tegevus:

rakenduse arendus, mis automatiseerib solar-varjualuste tellimise, projekteerimise ja dokumenteerimise protsessid

Oluline:

● kuskil ei ole sätestatud, et:

○ EHR integratsioon peab olema realiseeritud, ○ see on eeltingimus makse saamiseks, ○ või see on projekti peamine tulemus.

4. RTK väide on vastuolus nende enda hindamise ja otsusega

RTK väidab nüüd:

ilma EHR integratsioonita ei oleks projekti rahastatud

Kuid dokumentidest nähtub:

● projekti hinnati ilma selle tingimuseta, ● projekti rahastati ilma selle tingimuseta, ● projekti tulemus defineeriti ilma selle tingimuseta.

See tähendab, et RTK praegune väide:

- ei põhine hindamisprotsessil - ei põhine otsusel - ei põhine dokumentidel

vaid on tagantjärele loodud põhjendus.

RTK väide, et projekti ei oleks rahastatud ilma EHR integratsioonita, ei ole kooskõlas ei hindamislehe ega rahastamisotsusega. Dokumentidest nähtub selgelt, et projekti hinnati ja rahastati laiemate kriteeriumide alusel ning projekti tulemusena oodati toimivat ja testitud prototüüpi. EHR integratsioon ei olnud määratletud otsustava tingimusena ning selle käsitlemine sellisena tagantjärele ei ole põhjendatud.

5. RTK peab selgitama oma vastuolu

Palume RTK-l selgelt vastata:

1. Millises hindamisdokumendi punktis oli EHR integratsioon määratletud rahastamise eeltingimusena?

2. Millise hindamiskriteeriumi raames anti sellele otsustav kaal? 3. Kuidas on võimalik, et projekt sai positiivse rahastamisotsuse, kui väidetavalt oli see komponent

kriitiline? 4. Miks ei kajastu see väidetav kriitiline nõue ei hindamislehes ega rahastamisotsuses?

Täiendav kontekst EHR / e-ehituse platvormi käsitluse kohta

Käesolevas menetluses on eriti tähelepanuväärne, et RTK ehitab oma etteheite sisuliselt üles EHR-i ja e-ehituse platvormi väidetava integratsiooni puudumisele ajal, mil ehitisregistri enda toimimine, andmekvaliteet, ligipääsuloogika ja õiguslik raamistik on olnud avalikkuses väga tõsise kriitika all.

Avalikult kajastatud info põhjal on viimastel kuudel olnud EHR-i ümber laiaulatuslik avalik arutelu ja kriitika. ERR on kirjutanud, et riik ignoreeris aastaid probleeme ehitisregistri avalike andmetega ning et AKI juhtis puudustele tähelepanu juba kaks aastat tagasi. Samuti kajastati, et pärast “Pealtnägija” uurimust peatati kolmandate isikute ligipääs ehitisregistrisse laaditud failidele.

Äripäeva juhtkiri on nimetanud olukorda sedavõrd tõsiseks, et “aiateibaid näitava ehitisregistri eest peab keegi vastutama”, ning sama väljaande kajastuse põhjal kaaluvad ettevõtjad ehitisregistri probleemide tõttu isegi kohtuteed.

Ka kasutajate endi avalik tagasiside, sh erialastes sotsiaalmeediagruppides, osutab, et EHR-i kasutamisel on esinenud dokumentide kadumist, vanade ja uute dokumentide mittenägemist, piiratud ligipääsu ning laiemat ebakindlust selle suhtes, kellel üldse on õigus ja võimalus andmeid sisestada või näha. Kasutajate kommentaarides tuuakse mh välja, et:

● “kõik tööalua dokumendid kadunud”, ● “uusi ja ka vanu pole võimalik ei näha ega täiendada”, ● “riik on see värk”, ● “omanik või kohalik omavalitsus peab ehitisregistrit täitma”, ● “teistel isikutel ilma omaniku volituseta ei ole seadusega kooskõlas andmete sisestamine”.

See ei ole üksik müra, vaid kirjeldab süsteemset ebastabiilsust ja segadust, mida RTK oma hinnangus täielikult ignoreerib. (Tuginen siin kasutaja esitatud ekraanipiltidele.)

Selles valguses on eriti küsitav, et RTK käsitleb EHR-i justkui stabiilse, üheselt toimiva ja probleemivaba platvormina, millele mitteintegratsioon MVP-faasis oleks toetuse saaja oluline puudus. Tegelikkuses näitab avalik info vastupidist: EHR-i ümber on olnud korraga nii andmekaitse-, ligipääsu-, andmekvaliteedi- kui kasutusloogika kriis.

See on hämmastav, ja samas üllatav, kui motiveeritud on RTK võtnud tühistaja rolli. Selle asemel, et hinnata projekti sisulist tulemust, MVP loogikat ja proportsionaalsust, on RTK otsustanud klammerduda just selle süsteemi ümber, mille enda töökindlus, õiguslikud piirangud ja ligipääsurežiim on olnud avalikult ja korduvalt vaidluse all. Selline lähenemine ei ole ei sisuliselt aus ega halduslikult tasakaalukas.

Lisaks väärib märkimist laiem ametkondlik kontekst. Avalikus arutelus on korduvalt osutatud, et toetusmeetmete ülereguleeritud ja bürokraatlik menetlemine ei aita ettevõtetel kasvada, vaid sageli üksnes koormab neid täiendava ajakuluga. Ettevõtjate vaates tähendab see, et selle asemel, et tegeleda toote, müügi ja ekspordiga, tuleb nädalate kaupa tõendada, et “ei olda kaamel”. See probleem ei ole üksnes käesoleva menetluse subjektiivne tunnetus, vaid laiem nähtus, mille kohta on ettevõtlusväljal samuti kriitikat väljendatud. (Siin saab viidata kasutaja toodud Taivo Liivu kommentaari sisule kui taustamõttele, mitte formaalse tõendina.)

https://www.postimees.ee/8409940/ehitusinsener-kliimaministeerium-salastas-uliolulise-teabe-ilma-ette-h oiatamata https://www.aripaev.ee/juhtkiri/2026/03/04/aiateibaid-naitava-ehitisregistri-eest-peab-keegi-vastutama https://www.aripaev.ee/uudised/2026/03/04/ettevotja-kaalub-aastaid-torkunud-ehitisregistri-vastu-kohtutee d https://www.err.ee/1609950725/aki-juhtis-ehitisregistri-puudustele-tahelepanu-juba-kaks-aastat-tagasi https://arvamus.delfi.ee/artikkel/120436643/maa-ja-ruumiameti-peadirektor-meie-planeerimise-probleem- ei-ole-regulatsioon-vaid-killustunud-info https://ehitusleht.ee/pealtnagija-uurimus-peatas-kolmandate-isikute-ligipaasu-ehitisregistrisse-laaditud-fail idele/ https://www.err.ee/1609944737/riik-ignoreeris-aastaid-probleeme-ehitisregistri-avalike-andmetega

Builderish OÜ

[email protected]

Kase tn 6-8

Järva-Jaani alev, Järva vald,

Järva maakond 73301

09.04.2026 nr 11.3-1/26/1691

OTSUS maksest keeldumise ja toetuse taotluse

rahuldamise otsuse kehtetuks tunnistamise

kohta

Riigi Tugiteenuste Keskus (edaspidi vahendusasutus) teeb maksest keeldumise ja toetuse taotluse

rahuldamise otsuse kehtetuks tunnistamise otsuse Builderish OÜ (edaspiditoetuse saaja)

projektile nr 20.1.01.25-0981 „Config“ (edaspidi projekt).

Vahendusasutus tuvastas projekti lõppedes tulemusnäitajate ja lõpparuande kontrollimisel, et

toetuse saaja ei ole täitnud makse tegemise eeldusi, mistõttu loeb mitteabikõlblikuks kuluks 40

984 eurot ning ühtlasi tunnistab toetuse taotluse rahuldamise otsuse kehtetuks.

Vahendusasutus otsustab:

1. lugeda projekti „Config“ raames mitte toetatavaks kuluks 40 984,00 eurot, sh toetus 20 492

eurot ja omafinantseering 20 492 eurot.

2. tunnistada toetuse taotluse rahuldamise 03.07.2025 otsus nr 11.3-1/25/3162 kehtetuks

tagasiulatuvalt alates otsuse jõustumisest.

Otsus koosneb järgmistest osadest: õiguslikud alused, asjaolud, toetuse saaja selgitused,

vahendusasutuse põhjendused, maksest keeldumise ja taotluse rahuldamise otsuse kehtetuks

tunnistamine, ärakuulamine, vaidlustamine, lisad.

ÕIGUSLIKUD ALUSED

- Vabariigi Valitsuse 29.11.2021 määrus nr 108 „Taaste- ja vastupidavuskava elluviimise

korraldus ja toetuse andmise üldtingimused“ (edaspidi üldmäärus);

- kliimaministri 24.10.2023 määrus nr 62 „Ehituse e-hüppe toetuse andmise tingimused ja kord“

(edaspidi meetme määrus);

- toetuse rahuldamise otsus 03.07.2025 nr 11.3-1/25/3162 (edaspidi TRO).

ASJAOLUD

1. Toetuse saaja on allkirjastatud projekti taotluses märkinud projekti eesmärgiks (lk 8):

„Projekti kaugem siht on muuta koduste solar-varjualuste tellimine ja paigaldamine lihtsaks,

läbipaistvaks ja digitaalselt juhitavaks, vähendades turul valitsevaid takistusi ning edendades

taastuvenergia ja elektriautode laadimise lahenduste laiemat kasutuselevõttu. Projekt panustab

ehitusvaldkonna digitaliseerimisse, luues uuendusliku digilahenduse, mis tõstab sektori

tootlikkust ja on integreeritud e-ehituse platvormiga.

Eesmärk on luua tööriist, mis automatiseerib solar-varjualuste tellimise, projekteerimise,

dokumenteerimise protsessid, lihtsustades koduomanike jaoks varjualuste soetamist ja aidates

kaasa taastuvenergia eesmärkide saavutamisele.“

2. Projekti tulemused (projekti taotlus lk 8) on sõnastatud järgmiselt:

1. Automaatne konfiguratsioonitööriist eramajaomanikele

Tulemus: Valmis on kasutajasõbralik digitaalne tööriist, mis võimaldab lõpptarbijal automaatselt

modelleerida, hinnata ja tellida koduseid solar-varjualuseid.

Mõõdik: Tööriista kasutusele võtab vähemalt 100 klienti esimesel aastal pärast valmimist, sh

vähemalt 20 edukalt lõpetatud projekti.

2. Protsesside automatiseerimine ja lihtsustamine

Tulemus: Solar-varjualuste dokumenteerimise ja registreerimise protsess on integreeritud e-

ehituse platvormiga, vähendades koduomanike koormust dokumentatsiooni kooskõlastamisel.

Mõõdik: Protsessi läbimise aeg väheneb keskmiselt 50% võrreldes praeguse käsitsi tehtava

dokumenteerimisega.

3. Ehitussektori tootlikkuse tõus

Tulemus: Solar-varjualuste projekteerimise ja dokumenteerimise automatiseerimine vähendab

inseneride ja projekteerijate käsitsitööd, võimaldades keskenduda suurema lisandväärtusega

tegevustele.

Mõõdik: Automatiseeritud lahenduse kasutamine vähendab projekti realiseerimiseks vajalikku

insenertöö mahtu 30%.

4. Uue teenuse võimekus turul

Tulemus: Tekib võimalus pakkuda turule uuenduslikku "võtmed kätte" lahendust, kus lõpptarbijale

pakutakse mitte ainult toodet, vaid terviklikku projekteerimise, paigaldamise ja dokumenteerimise

teenust.

Mõõdik: Võimekus teenindada vähemalt 100 projekti aastas skaleerides, sealhulgas eksportida

lahendust rahvusvahelistele turgudele.

5. Sihtgrupi rahulolu tõus

Tulemus: Koduomanike rahulolu taastuvenergia lahenduste soetamise lihtsuse ja läbipaistvusega

suureneb.

Mõõdik: Kasutajate tagasisideküsitlustel rahulolu skoor vähemalt 4,5/5.

3. Projekti taotluses (edaspidi projekti taotlus või toetuse taotlus või taotlus) on toetuse saaja

välja toonud põhikomponendid (lk 9), mida projekti raames valminud lahendus hõlmab:

1. Kasutajasõbralik digitaalne platvorm – veebipõhine tööriist, kus lõpptarbija saab valida

varjualuse tüübi, mõõtmed, lisakomponendid (nt PV-paneelid, EV laadija) ning kohandada

lahendust vastavalt oma vajadustele.

2. Automatiseeritud dokumentatsioon ja kooskõlastamine – lahendus on integreeritud e-

ehituse platvormiga, mis võimaldab varjualuse projekte ja dokumente automaatselt ette

valmistada ning registreerida Ehitisregistris (EHR).

3. Indikatiivse hinnapakkumise genereerimine – tööriist kuvab automaatselt projektikulud ja

ajakava, pakkudes lõpptarbijale kiiret ja läbipaistvat ülevaadet.

4. "Võtmed kätte" lahendus – tööriista kaudu on võimalik tellida terviklahendus alates

projekteerimisest kuni paigalduseni.

4. Toetuse saaja on projekti elluviimise jaganud kolme etappi (projekti taotlus lk 9-10):

1. etapp: Analüüs ja lahenduse kavandamine (1 kuu):

- Turu ja sihtgrupi analüüs: Kogutakse täiendavat teavet lõpptarbijate vajaduste ja ootuste

kohta. Kaardistatakse olemasolevad kitsaskohad ja võimalused.

- Nõuete määratlemine: Koostatakse täpne tehniline ja funktsionaalne spetsifikatsioon tööriista

arendamiseks.

- Tehnilise platvormi kavandamine: Kavandatakse tööriista arhitektuur, sealhulgas

integratsioonid e-ehituse platvormi ja Ehitisregistriga.

2. etapp: Arendamine ja prototüüpimine (3-4 kuud):

- Platvormi arendus: Arendatakse kasutajasõbralik veebitööriist, mis võimaldab automaatset

konfiguratsiooni, dokumenteerimist ja hinnapakkumist.

- Integratsioon e-ehituse platvormiga: Luuakse ühendus Ehitisregistri ja e-ehituse

platvormiga, et automatiseerida dokumenteerimisprotsess.

- Prototüübi loomine: Valmib tööriista funktsionaalne prototüüp, mis sisaldab peamisi

funktsioone (konfiguratsioon, hinnapakkumine, dokumentatsioon).

- Testimine ja veaparandus: Testitakse prototüüpi valitud sihtrühma (10-20 eramajaomanikku)

seas ning parandatakse avastatud vead ja kitsaskohad.

3. etapp: Testimine ja turule toomine (1-2 kuud):

- Pilootprojektid: Viidi läbi testprojektid, mille käigus sihtrühm kasutab tööriista oma

varjualuste projekteerimiseks ja tellimiseks.

- Tagasiside kogumine ja arendustegevus: Kasutajate tagasiside põhjal tehakse lõplikud

täiustused tööriista funktsionaalsuses ja kasutajaliideses.

- Turundus ja lansseerimine: Valmistatakse ette ja viiakse läbi lahenduse turunduskampaania,

sealhulgas tutvustused ehitus- ja taastuvenergia valdkonna messidel ning veebiplatvormidel.

- Platvormi lansseerimine: Tööriist on kättesaadav lõpptarbijatele ja valmis laiemaks

kasutuselevõtuks.

5. Projekti taotluses on toetuse saaja kirjeldanud seose e-ehituse platvormiga (lk 11-12):

„Käesoleva projekti raames arendatav lahendus on tihedalt seotud e-ehituse platvormiga ning

kasutab selle võimalusi, et lihtsustada koduste solar-varjualuste projekteerimist,

dokumenteerimist ja registreerimist. Platvormi integratsioon aitab vähendada bürokraatiat,

kiirendada protsesse ja tagada lahenduse vastavuse kehtivatele nõuetele.“ Lisaks on konkreetselt

öeldud, et projekti käigus luuakse otsene liides e-ehituse platvormiga, et võimaldada varjualuse

automaatset dokumenteerimist ja registreerimist Ehitisregistris ja kuidas toimub lahenduse

kasutamine e-ehituse platvormil.

6. Projekti taotluses lk 16-17 on toodud tegevuste täpsustus:

1. Kasutajaliidese ja prototüübi funktsionaalsuste arendamine

Kasutajaliidese arendus:

- Kujundatakse kasutajasõbralik ja intuitiivne liides, mis võimaldab lõpptarbijal lihtsalt

sisestada aadress ning valida sobiva konfiguratsiooniga varjualune (asukoht, mõõtmed,

lisafunktsioonid) ning saada automaatne hinnapakkumine.

- Disainitakse kasutajaliides selliselt, et see toetab lõppkasutajate (koduomanike) minimaalseid

tehnilisi teadmisi.

Funktsionaalsuste arendus:

- Arendatakse hinnakalkulatsiooni funktsioon, mis suudab reaalajas arvutada projekti

maksumuse, võttes arvesse materjalide hinda, tööjõukulu ja paigaldusaega.

- Integreeritakse algne materjalide kalkulatsiooni moodul, mis ühendub tarnijate

andmebaasidega, et pakkuda kasutajale täpset hinnainfot.

- Lisatakse funktsioon, mis genereerib automaatselt vajalikke tehnilisi dokumente (nt projekti

joonised ja spetsifikatsioonid).

2. Andmete ja süsteemide integreerimine

E-ehituse platvormiga liidestamine:

- Arendatakse liides, mis võimaldab projekti dokumente ja andmeid automaatselt saata

Ehitisregistrisse (EHR), tagades nende vastavuse kehtivatele nõuetele.

- Lisatakse mehhanism, mis kontrollib automaatselt, kas projekt vastab kohalike omavalitsuste

ja riiklikele regulatsioonidele.

Pilvetehnoloogia kasutamine:

- Rakendatakse pilvepõhiseid andmeladustamise lahendusi, et tagada kiire ja skaleeritav

andmete haldamine.

- Tugevdatakse andmete turvalisust vastavalt GDPR-i ja muudele privaatsusnõuetele.

3. Testimine ja veaparandused

Pilootkasutajate kaasamine:

- Prototüüpi testitakse väikese grupi pilootkasutajatega, kuhu kuuluvad eramajaomanikud,

varjualuste paigaldajad ja kohalike omavalitsuste esindajad.

- Testimisel hinnatakse:

 Platvormi funktsionaalsust ja täpsust.

 Kasutusmugavust lõppkasutajate jaoks.

 Süsteemi töökindlust ja vigade esinemist.

Tagasiside kogumine ja analüüs:

- Kogutud tagasiside põhjal täiustatakse kasutajaliidest, parandatakse funktsionaalsuste

kitsaskohti ja lisatakse kasutajate soovitud täiendused.

Veaparandused:

- Eemaldatakse kõik tuvastatud vead ja parandatakse süsteemi stabiilsus enne platvormi

ametlikku lansseerimist.

7. Projekti lühikokkuvõte avalikkusele (projekti taotlus lk 14) on välja toodud järgmist:

„Projekt loob innovatiivse veebipõhise platvormi, mis võimaldab lihtsalt ja kiiresti konfigureerida,

hinnata ja tellida koduseid solar-varjualuseid koos päikesepaneelide ja elektriautolaadijatega.

Lahendus automatiseerib projekteerimis- ja dokumenteerimisprotsessid, sealhulgas

integratsiooni e-ehituse platvormiga, vähendades oluliselt bürokraatiat ja ajakulu. Platvorm on

avatud ja kättesaadav kõigile, aidates edendada taastuvenergia kasutuselevõttu ja

ehitusvaldkonna digitaliseerimist.“

8. Projekti taotluse eelarve koostamisel on aluseks võetud Gramet Desing OÜ pakkumus,

millest nähtub, et üheks hinna kujunemise komponendiks on prototüübi põhifunktsioonide

arendamine, sh dokumentatsiooni automaatne genereerimine: koostab ja struktureerib

dokumentatsiooni ehitusregistrisse esitamiseks. Kogu arendustöö tulemuseks on töötav prototüüp,

mis sisaldab toimivat kasutajaliidest ja põhifunktsioone, võimaldab automatiseerida solar-

varjualuste projekteerimise ja hinnakalkulatsiooni protsessi ning on integreeritud e-ehituse

platvormiga ja vastab ehitusregistri nõuetele.

9. Toetuse saaja esitas vahendusasutusele 23.12.2025 lõpparuande ja 29.12.2025

kuludokumendi nr 1, milles on kajastatud ühekordse makse alusel hüvitatava projekti valmimise

kulu summas 40 984 eurot (käibemaksuta).

10. TRO punkti 8 kohaselt makstakse toetust vastavalt meetme määruse § 23 lõikele 3

üldmääruse § 9 lg 3 punktis 2 nimetatud viisil ühekordse maksena pärast aruande kinnitamist,

lähtudes TRO-s sätestatud tingimustest ja korrast. Makse teostatakse eeldusel, et makse aluseks

olnud tegevus on ellu viidud ja TRO-s kokkulepitud tingimused on täidetud ja tõendatud.

11. Meetme määruse § 23 lg 4 punktide 1 ja 2 kohaselt teostatakse makse eeldusel, et makse

aluseks olnud tegevused on ellu viidud ja toetuse rahuldamise otsuses kokkulepitud tingimused on

täidetud ja tõendatud. TRO punkti 9.1 alusel makstakse makse summas 20 492,00 eurot välja peale

projektis kirjeldatud tegevuse ellu viimist (rakenduse arendus, mis automatiseerib solar-

varjualuste tellimise, projekteerimise, dokumenteerimise protsessid, lihtsustades koduomanike

jaoks varjualuste soetamist ja aidates kaasa taastuvenergia eesmärkide saavutamisele). Makse

aluseks olev tulemus on toimiv ja testitud prototüüp, mida tõendab videodemo keskkonnast.

12. Lõpparuandest ja toetuse saaja esitatud videodemost nähtub, et valminud lahendus ei ole

integreeritud e-ehituse platvormiga. Lõpparuandes on toetuse saaja välja toonud järgmist:

EHR api ei ole avalik api, peab lepingu sõlmima, mis antud faasis ei ole mõistlik. EHR

(Ehitisregister) integratsioon X-tee kaudu ehituslubade kontrolliks ei ole antud faasis mõistlik,

kuna eeldab lepingut. Katastriandmed päritakse Maa-ameti WFS teenusest, mitte ETAK-ist.

Kahjuks EHR-i otse üleslaadimist ei saa automaatselt teha, kuna:

 EHR on riiklik süsteem - vajab ametlikku API-ligipääsu kokkulepet Ehitisregistriga.

 Autentimine - nõuab ID-kaardi/Mobiil-ID autentimist läbi eesti.ee.

 API pole avalik - EHR ei paku avalikku REST API-t dokumentide üleslaadimiseks.

Tehnilised integratsioonid ja toimima saamine vajalike 3ndate osapooltega nt. Vabakasutuse APId

ei ole Eestis piisavalt levinud, andmete vabakasutamine ja tehniliste lahenduste ehitamine nende

peale võiks olla Eestis oluliselt parem.

 EHR ei ole täna mõistlikult integreeritav MVP-s (ei päringud ega üleslaadimine);

 X-tee kaudu EHR = leping + audit + identiteedihaldus -> enterprise projekt.

Praktiline tõde: Isegi paljud professionaalsed projekteerijad ei kasuta EHR API-t, vaid:

 laevad dokumendid käsitsi

 kasutavad EHR-i UI-d

 MVP-s täiesti ebamõistlik.

„EHR-i ei saa automaatselt üles laadida“ põhjused:

 ametlik menetlus

 isikuline vastutus

 tugev autentimine (ID-kaart / Mobiil-ID)

 allkirjastamine

Riik ei taha, et: keegi “kolmas osapool” esitaks sinu nimel dokumente ilma selge volituseta.

See ei ole tehniline piirang – see on õiguslik disain.

Millal EHR integratsioon ÜLDSE muutub mõistlikuks?

Reaalselt ainult siis, kui:

 sul on B2B klient (nt omavalitsus, suur projekteerija)

 kes ütleb: “me tahame, et see oleks EHR-iga ühendatud”

 ja on valmis selle eest maksma.

Maa-ameti In-ADS gazetteer API ei tagasta tegelikke piire. Selle API kaudu ei saa tegelikke

katastriüksuse piire.

13. Toetuse saaja andis projekti lõpparuandes hinnangu tegevuste elluviimisele:

 „EHR api ei ole avalik api, peab lepingu sõlmima, mis antud faasis ei ole mõistlik.

 EHR (Ehitisregister) integratsioon X-tee kaudu ehituslubade kontrolliks ei ole antud faasis

mõistlik, kuna eeldab lepingut.

 Katastriandmed päritakse Maa-ameti WFS teenusest, mitte ETAK-ist.

 Kahjuks EHR-i otse üleslaadimist ei saa automaatselt teha, kuna:

- EHR on riiklik süsteem - vajab ametlikku API-ligipääsu kokkulepet Ehitisregistriga.

- Autentimine - nõuab ID-kaardi/Mobiil-ID autentimist läbi eesti.ee.

- API pole avalik - EHR ei paku avalikku REST API-t dokumentide üleslaadimiseks.“

14. Toetuse saaja kirjeldas projekti lõpparuandes märkimisväärseid probleeme:

Tehnilised integratsioonid ja toimima saamine vajalike 3ndate osapooltega nt. Vabakasutuse APId

ei ole Eestis piisavalt levinud, andmete vabakasutamine ja tehniliste lahenduste ehitamine nende

peale võiks olla Eestis oluliselt parem.

 EHR ei ole täna mõistlikult integreeritav MVP-s (ei päringud ega üleslaadimine);

 X-tee kaudu EHR = leping + audit + identiteedihaldus -> enterprise projekt.

Praktiline tõde: Isegi paljud professionaalsed projekteerijad ei kasuta EHR API-t, vaid:

 laevad dokumendid käsitsi

 kasutavad EHR-i UI-d

 MVP-s täiesti ebamõistlik.

„EHR-i ei saa automaatselt üles laadida“ põhjused:

 ametlik menetlus

 isikuline vastutus

 tugev autentimine (ID-kaart / Mobiil-ID)

 allkirjastamine

Riik ei taha, et: keegi “kolmas osapool” esitaks sinu nimel dokumente ilma selge volituseta.

See ei ole tehniline piirang – see on õiguslik disain.

Millal EHR integratsioon ÜLDSE muutub mõistlikuks?

Reaalselt ainult siis, kui:

 sul on B2B klient (nt omavalitsus, suur projekteerija)

 kes ütleb: “me tahame, et see oleks EHR-iga ühendatud”

 ja on valmis selle eest maksma.

Maa-ameti In-ADS gazetteer API ei tagasta tegelikke piire. Selle API kaudu ei saa tegelikke

katastriüksuse piire.

15. Videodemos ütleb toetuse saaja, et solar-varjualuse tellimise protsessi taheti

automatiseerida, st et päringuga tuvastatakse läbi registrite, mis on konkreetsel krundil

paigaldamise tingimused ja omavalitsuse nõuded. Selleks loodi veebipõhine rakendus. Toetuse

saaja sõnul see ei hiilga väga suure sisuga, vaid annab kätte üldise info. Toetuse saaja selgitus:

„Projekti olemus on see, et klient sisestab oma aadressi, see järel süsteem tuvastab aadressi ja

paigutab vaikimisi krundile varjualusele ja süsteem püüab rakendada Maa-ameti ja Ehitisregistri

andmepäringuid ja tuvastada kui suur on krundi pind, kui palju on täis ehitatud ja milline on see

maht mida võib ehitusseadustiku või detailplaneeringu mõistes täis ehitada.“ Toetuse saaja

tunnistab videodemos, et andmed, mida kuvatakse, ei ole korrektsed (kuvatakse hüpoteetiline

krundipiir, mis ei ole täpne, sest andmeid ei saadud õigetest allikatest).

16. Videodemos selgitab toetuse saaja, et kasutaja kinnitab aadressi ja liigub konfiguraatorisse,

kus süsteem kuvab erinevaid varjualuse variante koos mõõtmetega, ja klient peab hindama, kas

varjualune mahub tema krundile. Juurde saab tellida päikesekatuse paneele, saab valida

varjualusele nt seina, värvitooni, valguse, elektriautolaadija, akud, pistikupesad,

vihamveesüsteemi ja lisaks valida erinevad teenused (paigaldus, tarne lisakindlustus,

projekteerimine ja seadustamine). Seejärel tuleb sisestada enda andmed ja siis klient esitab

päringu. Seejärel peaks pakkuja pakkumuse kinnitama vastavalt asukohale vms.

17. Edasine on videodemos kajastatud plaanina, mis ei teostunud. Toetuse saaja sõnul peaks

edasi toimuma seadustamise osa, milles päringu teinud kliendile peaks süsteem kuvama, kas ta

saab oma krundile soovitud varjualust rajada või mitte. Kui seadustaja selle päringu avab, siis

süsteem peaks kuvama info (mis tegelikult võiks Ehitisregistrist ja Maa-ametist automaatselt

tuvastada, et kas tegelikult saab sinna varjualuse rajada või mitte). Süsteem tuvastab katastrihoone

ja varjualuse perspektiivse asukoha. Toetuse saaja kirjeldab, et loogika seisneb selles, et

projekteerija lisab vajaliku projekti dokumentatsiooni ja siis konkreetsest nupust genereeritakse

EHR-i minev raport, mis liigub progressi, kus ühe nupu vajutusega kogu projekti sisu laetakse

automaatselt EHR-i üles vastavatele väljadele. Ehk siis projekti kooskõlastaja ei peaks EHR-i sisse

logima ja seda tehtaks mingi agendina. Seeläbi oleks kogu projekti loomine ja seadustamine

automatiseeritud.

18. Vahendusasutus kontrollis keskkonnas (veebilink: canopies.me) lahenduse toimimist ja

tõdes, et solar-varjualuse tellimisel, sisestades kinnistu aadressi tuleb koheselt teavitus, et katastri

andmed pole hetkel kättesaadavad, mis tähendab, et kasutatav lahendus ei saa andmeid õigetest

allikatest (seda väitis toetuse saaja oma videodemos ka ise) ja keskkonnas kajastuvad sisestatud

kinnistu kohta ebaõiged andmed. Varjualuse projekti andmed ei liigu ka EHR-i (mis asub e-ehituse

platvormil). Seega, liides, mis peaks võimaldama andmete liikumist EHR-i, e-ehituse platvormi ja

valminud süsteemi vahel on välja arendamata, st ei võimalda varjualuse projekti dokumente ja

andmeid automaatselt saata EHR-i, tagades nende vastavuse kehtivatele nõuetele. Lahendus ei ole

integreeritud e-ehituse platvormiga.

19. Seega on toetuse saaja projekti käigus muutnud projekti tegevusi, jättes ära lahenduse

integreerimise e-ehituse platvormiga, mis meetme määruse alusel ei olnud lubatud, kuivõrd

meetme määrus § 20 lg 2 alusel ei ole lubatud muuta projekti eesmärki, toetatavat tegevust ning

maksete arvu ja suurusi. Antud keeld on välja toodu ka TRO punktis 12. Samuti ei ole täidetud

makse teostamise eeldused, s.o TRO punkti 9.1 ja meetme määrus § 23 lg 4 punkte 1 ja 2. Projekti

raames planeeritud tegevused ei ole lubatud ulatuses ellu viidud, mistõttu valminud projekt ei vasta

taotluse rahuldamise otsuses kokkulepitud tingimustele ja ei ole tõendatud.

TOETUSE SAAJA SELGITUSED

20. Vahendusasutus palus 14.01.2026 toetuse saajal välja tuua projekti taotluses iga täpsemalt

kirjeldatud tegevuse kohta, mis saadi valmis, mis jäi tegemata ja kui suures mahus jäi tegemata.

Toetuse saaja esitas vahendusasutusele vastuse 16.01.2026 ja lisas 26.01.2026 omapoolsed

kommentaarid.

21. Kuna toetuse saaja vastused ja kommentaarid on väga mahukad, ei ole neid otsuse eelnõus

eraldi esitatud. Need on lisatud eelnõule Lisa 1 ja Lisa 2 kujul. Vahendusasutus põhjendab oma

seisukohti järgmistes punktides.

VAHENDUSASUTUSE PÕHJENDUSED

22. Vastavalt meetme määruse § 2 lõikele 5 lähtutakse toetuse taotlemisel, andmisel ja

kasutamisel üldmäärusest. Vastavalt üldmääruse § 9 lõikele 3 on toetuse maksmiseks ette nähtud

kolm viisi: 1) tekkinud ja tasutud kulude alusel, 2) kokkulepitud tingimuste täitmise alusel või 3)

põhjendatud juhul osaliselt ettemaksena.

23. Meetme määruse § 23 lõike 3 kohaselt makstakse ehituse e-hüppe toetust üldmääruse § 9

lg 3 punkti 2 nimetatud viisil, st kokkulepitud tingimuste täitmise alusel. Meetme määruse § 23

lõike 4 kohaselt on makse tegemise eelduseks, et makse aluseks olnud tegevused on ellu viidud ja

TRO-s kokkulepitud tingimused on täidetud ja tõendatud. See tähendab, et taotleja esitab projekti

taotluses tegevused, mida ta soovib toetusega ellu viia, ning koostab toetatavate tegevuste detailse

eelarve (meetme määruse § 11 punktid 2, 5 ja 6). Esitatud taotlust hindavad eksperdid vastavalt

meetme määruse §-s 16 sätestatud tingimustele. Kui eksperdid annavad projekti taotlusele

positiivse hinnangu ja taotlusvooru eelarve võimaldab taotlust rahuldada, teeb vahendusasutus

taotluse rahuldamise otsuse.

24. Taotluse rahuldamise otsuses sätestatakse tingimused, mille täitmisel makstakse toetust

välja. Kui toetuse saaja täidab kõik otsuses kokkulepitud tingimused, sh viib ellu projekti taotluses

lubatud tegevused, mille alusel koostati projekti eelarve ja määrati toetuse suurus ning saavutab

seatud tulemused, siis makstakse toetus välja. Siinjuures on oluline välja tuua, et vahendusasutus

ei kontrolli projekti tegelikku maksumust, vaid oluline on see, et kokkulepitud tegevused oleksid

ellu viidud ja tulemused saavutatud.

25. TRO punkti 11 kohaselt on toetuse saaja kohustatud projekti elluviimisel järgima

üldmääruses, meetme määruses ja taotluse rahuldamise otsuses sätestatut ning punkti 11.1 kohaselt

kasutama toetust vastavuses TRO-ga.

26. Meetme määruse § 25 punkti 3 järgi on toetuse saaja kohustatud saavutama projekti

tulemused TRO-s sätestatud tähtpäevaks. Projekti tulemused peab toetuse saaja saavutama projekti

abikõlblikkuse perioodi lõpuks, s.o 31.12.2025.

27. TRO punkt 11.8 ja meetme määruse § 25 punkt 11 sätestab toetuse saaja kohustuse

viivitamata kirjalikult teavitama vahendusasutust asjaoludest, mis vältimatult või suure

tõenäosusega takistavad projekti ettenähtud tulemuste saavutamist.

28. TRO punkti 12 ja meetme määruse § 20 lõike 2 kohaselt ei ole lubatud muuta projekti

eesmärki, toetatavat tegevust ning maksete arvu ja suurusi.

29. Meetme määruse § 23 lõige 4 sätestab makse teostamise eeldused, mille punkti 1 kohaselt

makse aluseks olnud tegevused on ellu viidud ja punkti 2 kohaselt TRO-s kokkulepitud tingimused

on täidetud ja tõendatud.

30. TRO punkti 6 järgi projekti tegevused viiakse ellu taotluse lehel „Tegevused“ toodud

ajakava alusel ja punkti 7 alusel on tulemusnäitajaks, millesse toetuse andmisega panustatakse,

lõpetatud projektide arv sihttasemega 1.

31. TRO punkti 9.1 alusel makse summas 20 492,00 eurot makstakse välja peale projektis

kirjeldatud tegevuse ellu viimist (rakenduse arendus, mis automatiseerib solar-varjualuste

tellimise, projekteerimise, dokumenteerimise protsessid, lihtsustades koduomanike jaoks

varjualuste soetamist ja aidates kaasa taastuvenergia eesmärkide saavutamisele). Makse aluseks

olev tulemus on toimiv ja testitud prototüüp, mida tõendab videodemo keskkonnas.

32. Toetuse saaja esitas projekti lõpparuande 23.12.2025, lõppversioon 29.12.2025.

Lõpparuandele on lisatud videodemo, milles nähtub valminud lahenduse tutvustus. Videodemos

toetuse saaja tunnistab, et valminud lahenduse ja Ehitusregistri vahel andmevahetust ei toimu.

33. Toetuse saaja hinnangul integratsiooni loomine praeguses faasis ei ole mõistlik, sest nii

EHR-i API (mis ei ole avalik) kasutamine kui ka EHRi integratsioon X-tee kaudu ehituslubade

kontrolliks eeldavad lepingu sõlmimist. Katastriandmed saadakse Maa‑ameti WFS teenusest,

mitte ETAK-ist. Dokumentide automaatset üleslaadimist otse EHR-i ei saa teha, sest vajalik on

ametlik API-ligipääsu kokkulepe Ehitusregistriga, autentimine ID-kaardi või Mobiil-ID-ga

eesti.ee kaudu ja EHR ei paku avalikku REST API-t dokumentide üleslaadimiseks.

34. Toetuse saaja on projekti lõpparuandes märkimisväärseteks probleemideks märkinud

tehnilised integratsioonid ja toimima saamine vajalike kolmandate osapooltega. Tuues välja, et

vabakasutuse API-d ei ole Eestis piisavalt levinud ja riik ei taha, et keegi “kolmas osapool” esitaks

kellegi teise nimel dokumente ilma selge volituseta. Toetuse saaja tõdeb, et EHR-i integratsioon

muutub mõistlikuks siis, kui on olemas B2B klient (nt omavalitsus, suur projekteerija), kes annab

mõista, et peab olema ühendus EHRiga ja on nõus ka selle eest maksma. Lisades veel põhjused,

miks ei saa EHR-i automaatselt üles laadida: ametlik menetlus, isikuline vastutus, tugev

audentimine ja allkirjastamine.

35. Videodemos selgitab toetuse saaja, et eesmärk oli luua veebipõhine rakendus, mis

automatiseeriks solar-varjualuse tellimise protsessi. Projekti mõte oli, et peale krundi aadressi

sisestamist süsteem tuvastab aadressi ja paigutab vaikimisi krundile varjualuse ning süsteem

rakendab Maa-ameti ja Ehitusregistri andmepäringud tuvastades krundi pindala, kui palju on täis

ehitatud ja kui palju võib ehitusseadustiku või detailplaneeringu mõistes täis ehitada. Toetuse saaja

tunnistab, et rakendus kuvab ebatäpseid andmeid ning ei paku sisuliselt väga põhjalikku infot, vaid

üldise ülevaate. Pärast aadressi kinnitamist liigub kasutaja konfiguraatorisse, kus saab valida

erinevaid varjualuse lahendusi ja lisasid (nt päikesepaneelid, seinad, värvitoon, valgustus, laadijad,

akud, vihmaveesüsteem). Lisaks saab valida erinevaid teenuseid nagu paigaldus, tarne

lisakindlustus, projekteerimine ja seadustamine. Seejärel sisestab klient oma andmed ja esitab

päringu, mille järel pakkuja peab pakkumuse üle kinnitama vastavalt asukohale või muudele

tingimustele.

36. Vahendusasutusel õnnestus eeltoodut katsetada nii sisse logides kui ka sisse logimata.

Sisestatud krundi aadressi kohta kuvatavad krundi andmed ei vastanud tegelikkusele. Toetuse

saaja tunnistab videodemos ka ise, et kuvatavad andmed ei ole täpsed, kuna neid ei saa laadida

õigetest allikatest.

37. Videodemos kajastatud lahendus, kuidas süsteem peaks töötama, jäigi lõpuks ellu viimata.

Toetuse saaja kirjeldas plaani, mille järgi süsteem oleks pidanud päringu teinud kliendile näitama,

kas tema krundile on võimalik varjualust rajada või mitte. Seadustaja poolt päringu avamisel oleks

süsteem automaatselt tuvastanud katastrihoone ja varjualuse kavandatava asukoha, kasutades

selleks Ehitisregistri ja Maa-ameti andmeid. Projekti loogika nägi ette, et projekteerija lisab

vajalikud projektidokumendid ning seejärel oleks nupuvajutusega genereeritud EHR-i minev

raport, mis liiguks progressi ja seejärel toimuks kogu projekti sisu laadimine automaatselt EHR-i

vastavatele väljadele. Projekti kooskõlastaja ei oleks pidanud ise EHR‑i sisse logima — süsteem

oleks tegutsenud automaatse agendina. Sellisel juhul oleks kogu projekti loomise ja seadustamise

protsess olnud automatiseeritud.

38. Toetuse saaja tunnistab videodemos, et kõik tundus hüpoteetiliselt loogiline ja ülimõistlik,

aga tegelikkus on teine. Esinenud probleemid on kirjeldatud otsuse punktides 12-15 ning

kajastatud ka videodemos.

39. Toetuse saaja selgitab, et andmete automaatne laadimine EHR-i ei ole võimalik, kuna

tegemist on riikliku süsteemiga, mis eeldab Ehitisregistriga API ligipääsuks ametliku kokkuleppe

sõlmimist. Lisaks tuleb sõlmida eraldi leping audentimiseks. Andmete lihtsustatud kujul

kättesaamine ei ole ilma vastavate lepinguteta võimalik.

40. Toetuse saaja on projekti tegevuste käigus mõistnud, et lahenduse integreerimine takerdub

õigusliku korralduse taha, ja tõdenud, millal EHR-i integratsioon üldse mõistlik oleks. Seega,

vahendusasutuse hinnangul ei ole projekti raames valminud arendust ellu viidud planeeritud

mahus ehk ei ole saavutatud ettenähtud tulemusi, st solar-varjualuste dokumenteerimise ja

registreerimise protsess ei ole integreeritud.

41. Toetuse saaja rõhutab oma selgitustes korduvalt, et projekti eesmärk oli luua digitaalne

tööriist MVP koduse solar‑varjualuse automatiseeritud planeerimiseks ja tellimiseks ning

integratsioonid olid visioonilised, mitte MVP kohustuslikud komponendid. Lisades, et taotluses

mainitud EHR-i liidestus oli tulevikusuund, mitte MVP toimimise kriitiline tingimus.

42. Vahendusasutus ei korda projekti tegevusi, mis on juba otsuse punktides 1–7 kajastatud

ning toetuse saaja taotluses sõna-sõnalt esitatud. Toetuse saaja on tegevuste kirjelduses selgelt

märkinud, et projekti raames loodav lahendus integreeritakse e-ehituse platvormiga, tegemist ei

ole visioonilise ideega.

43. Toetuse saaja esitas projekti taotlusega pakkumiskutse ja pakkumised arenduspartneri

leidmiseks. Pakkumiskutses on toodud projekti üldine eesmärk: Arendada digitaalne platvorm,

mis võimaldab eramajaomanikel ja kinnistu haldajatel konfigureerida, hinnata, dokumenteerida

ning tellida koduseid solar-varjualuseid, sh PV-paneele ja elektriautode laadijaid. Lahendus peab

olema kasutajasõbralik, automatiseeritud ja integreeritud e-ehituse platvormiga.

44. Pakkumiskutse arendustööde mahukirjelduse punktis 3 Funktsionaalne prototüüp on

selgelt toodud, et arendatakse põhifunktsioonid, sh:

 Dokumentatsiooni automaatne genereerimine: Koostab ja struktureerib dokumentatsiooni

Ehitisregistrisse esitamiseks.

 Liidestus e-ehituse platvormiga: Tagab sujuva andmevahetuse ja protsesside

automatiseerimise.

45. Pakkumiskutses on märgitud, et projekti tulemusena peab valmima töötav prototüüp, mis:

 Sisaldab toimivat kasutajaliidest ja põhifunktsioone.

 Võimaldab automatiseerida solar-varjualuste projekteerimise ja hinnakalkulatsiooni

protsessi.

 On integreeritud e-ehituse platvormiga ja vastab Ehitisregistri nõuetele.

46. Pakkumiskutse kohaselt on üheks tarnitavaks lõpptulemuseks tarkvara prototüübi versioon,

mis sisaldab vähemalt määratletud põhifunktsioone. Toetuse saaja on määratlenud prototüübi

liidestuse e-ehituse platvormiga põhifunktsioonide hulka.

47. Pakkujad, kes vastasid pakkumuskutsele, on oma pakkumistes pidanud arvestama, et

valmiv prototüüp on ka integreeritud e-ehituse platvormiga. Seega, toetuse saaja väide, et valmiv

lahendus ei pidanud olema projekti raames integreeritud e-ehituse platvormiga, ei ole õige, kuna

nii projekti tegevuste kirjeldus kui ka pakkumiskutse ja pakkumised sisaldavad lahenduse

integreerimist e-ehituse platvormiga.

48. Pakkumiskutses on määratud tööde teostamise tähtajaks 6 kuud alates lepingu sõlmimisest.

Lepingu sõlmimise kuupäev ei ole vahendusasutusele teada. Toetuse saaja taotluse rahuldamise

otsus on kuupäevaga 03.07.2025 ja projekti abikõlblikkuse periood 01.05.2025-30.09.2025.

Toetuse saaja esitas 18.09.2025 projekti abikõlblikkuse perioodi pikendamise taotluse, tuues

põhjuseks, et projekt sai positiivse otsuse oluliselt hiljem tavapärasest ja seetõttu on realiseerimise

aeg olnud oluliselt lühem. Vahendusasutus on 23.09.2025 pikendanud projekti abikõlblikkuse

perioodi kuni 31.12.2025.

49. Siinjuures on oluline välja tuua, et toetuse saaja taotlust on hinnatud kahel korral. Nimelt

tegi vahendusasutus 31.03.2025 taotluse rahuldamata jätmise otsuse nr 11.3-1/25/1690, kuivõrd

eksperdid hindasid hindamiskriteeriumis 3 taotlust hindega 1, mis oli alla lävendi (alla 2 punkti).

Eksperdid juhtisid taotleja tähelepanu sellele, et ei ole usutav, et projekti perioodil jõutakse

lahendus siduda ehitisregistri ja e-ehituse platvormiga: „Taotluses on kirjeldatud, et lahendus saab

seotud "Ehitisregistri ja e-ehituse platvormiga, automatiseerides registreerimis- ja

dokumenteerimisprotsessid." Esiteks pole hindajatel aru saada, mida täpselt on selle all silmas

peetud, teiseks pole taotleja olnud e-ehituse platvormi arendusmeeskonnaga ühenduses. Eeltöö

põhjal oleks ta teadnud, et sellise ühenduse analüüs, teostus ning õiguslikult korraldamine ei mahu

antud projekti kestuse sisse.“ Toetuse saaja esitas hindamise tulemuste peale 30.04.2025 vaide.

50. Toetuse saaja märkis vaides (vastuargumentide kokkuvõtte punkt 3), et projekti kvaliteedi

hindamine on sisuliselt õigustamatu ja faktiväline. Toetuse saaja rõhutas, et taotleja on varasema

e-ehituse projektiga edukalt platvormi integreerinud ning kasutab e-ehituse teenuseid ka

olemasolevas tootmiskeskkonnas ning tõi välja järgmist: „Veelgi tõsisem on hinnangus sisalduv

vastuolu: hindaja viitab, et taotleja pole olnud e-ehituse platvormi meeskonnaga kontaktis ja et

"eeltöö põhjal oleks pidanud teadma, et liidestus ei mahu projekti kestusesse". See on täiesti

vastuoluline olukord:

• e-ehituse meeskond on ise kaasatud toetuse määruse koostamisse;

• toetusmeetme sisuks on just innovaatiliste lahenduste sidumine e-ehituse platvormiga;

• taotleja esitabki sellise lahenduse – ning sellele järgnevalt öeldakse, et "see polegi

võimalik". Vastuargumentide kokkuvõte punktis 2 rõhutab toetuse saaja, et taotluses on kirjeldatud

solar-varjualuste tellimise ja dokumenteerimise täielik digitaliseerimine koos e-ehituse platvormi

integreerimisega.

51. Vahendusasutus rahuldas 04.06.2025 vaideotsusega nr 11.3-1/25/2706 vaide ja kohustas

läbi viima uue taotluse hindamise, kuivõrd hindamiskriteeriumis 3 ei olnud hindamine läbipaistev

ega kontrollitav, sest hinnangu järeldused ei ole seostatavad hinnatava hindamiskriteeriumis

avaldatud hindepunktide kirjeldustega.

52. Teisel taotluse hindamisel hindasid eksperdid taotlust positiivselt ja vahendusasutus tegi

03.07.2025 taotluse rahuldamise otsuse nr 11.3-1/25/3162 (otsuse juurde lisati ka hindamisleht).

Samas tõid eksperdid hindamislehe hindamiskriteeriumis 4 (taotleja võimekus projekti tegevuste

läbiviimiseks) välja järgmist: „Taotleja ilmselt tunneb turusegmenti ning omab piisavat IT-

projektide juhtimise kogemust, kuid märkida tuleb, et nii taotleja kui valitud arenduspartner ei

oma teadaolevalt kogemust e-ehituse platvormiga liidestumisel (arenduspartneri puhul on selle

olemasolu mainitud taotluses, kuid ettevõtte kodulehelt antud infot ei leia) ning ei oska sellest

tulenevalt võibolla hinnata töömahtu ning kaasnevaid riske.“

53. Seega pöörasid eksperdid toetuse saaja tähelepanu kahel korral asjaolule, et liidestamine e-

ehituse platvormiga võib olla töömahukas (nt teostus, õiguslik korraldamine) ja sellega võivad

kaasneda riskid.

54. Projekti lõpparuandest on aga selgunud, et projekti kestuse perioodil valminud lahendus ei

ole integreeritud e-ehituse platvormiga. Toetuse saaja põhjendustes on läbiv käsitlus, et see

polnudki prioriteet, mis aga on vastuolus nii projekti tegevuste kirjelduse, vaides toodud selgituste

kui ka pakkumuskutses tooduga.

55. Vahendusasutus suhtles Maa- ja Ruumiameti (MaRu) ehitus- ja planeeringute

infosüsteemide arendajatega ja sai kinnituse, et kui välised partnerid soovivad e-ehituse

platvormile midagi integreerida, tuleks sellise mõtte realiseerimist kindlasti esmalt MaRu ja

Keskkonnaministeeriumi Infotehnoloogiakeskusega (KeMIT) läbi rääkida, sest neil on

mittefunktsionaalsed nõuded ja turvalisuse küsimused ning arhitektuur jne, millega tuleb kindlasti

arvestada. Seega võttis toetuse saaja riski, et tegevusi ei ole võimalik soovitud aja jooksul ja mahus

ellu viia.

56. Toetuse saaja selgitas 16.01.2026 vahendusasutuse päringule vastates, et EHR API

liidestust ei olnud MVP-raames ei tehniliselt ega juriidiliselt mõistlikult teostada, vaid valiti

alternatiivne avaandmete kasutamise tee (avaandmete (rasterandmete) kasutamine EHR API

integratsiooni asemel) ning funktsionaalsuste eelduste loomine, et realiseerida MVP selle

olemuses. Toetuse saaja mainis 26.01.2026 täiendavalt, et EHR-i tehniline lõplik liidestus ei olnud

MVP-faasis otstarbekas ega ajaraamistikus teostatav - kuid see on tulevikus võimalik, ja vastavad

arhitektuurilised valikud on tagatud. Seega on toetuse saaja projekti käigus muutnud projekti

tegevusi, mis on aga meetme määruse § 20 lõike 2 ja TRO punkti 12 alusel keelatud.

57. Toetuse saaja selgitas 16.01.2026, et EHR-i integratsioon oli kirjeldatud kui pikema

visiooni komponent ja tuleviku suund, kuid mitte MVP kriitiline komponent, ainukene võimalik

tehniline lahendus projekti realiseerimisel (lahendatud antud puhul hoopis avaandmete

kasutamisega), makse eeldus, tegevus, mille puudumine nullib kogu projekti eesmärgi. Lisades, et

on igati normaalne, kui projekti arenedes osutub esialgne valik ebapraktiliseks või -efektiivseks,

sh tehnoloogiad või integratsioonid, mis on esialgu planeeritud, ning lahendamise käigus

kasutatakse alternatiivseid viise.

58. Projekti tegevuste kirjeldus, 30.04.2025 esitatud vaie kui ka hinnapakkumised on koostatud

selliselt, et loodava rakenduse peab integreerima e-ehituse platvormiga, seega ei saa

vahendusasutus nõustuda eelpool toodud väitega nagu integreerimine EHR-iga (mis asub e-ehituse

platvormil) ei olnud oluline (kriitiline) komponent.

59. Meetme määruse § 2 lõike 1 alusel on toetuse eesmärk stimuleerida ehitusvaldkonna

ettevõtjaid looma või rakendama uuenduslikke digilahendusi, mis tõstavad sektori tootlikkust ja

on seotud e-ehituse platvormiga.

60. Meetme määruse § 2 lõike 2 kohaselt eesmärgi saavutamiseks toetatakse e-ehituse

platvormil põhinevate ja eraldiseisvate uuenduslike digilahenduste väljatöötamise, prototüüpimise

või rakendamise projekte ehitusvaldkonnas.

61. Seega, toetuse saaja tõlgendus, et EHR-i integratsioon ei olnud ainus võimalik tehniline

lahendus, ei ole aktsepteeritav, kuivõrd toetuse saaja on taotluses ise ettenäinud lahenduse

integratsiooni EHR-i. Vastavalt meetme määruses toodule toetatakse väljatöötatud uuenduslikke

digilahendusi, mis põhinevad e-ehituse platvormil, mis aga ei tähenda seda, et projekti raames

peaks see uuenduslik digilahendus ilmtingimata olema integreeritud või liidestatud Ehitusregistri

ja e-ehituse platvormiga. Antud asjaolu seisneb selles, mida taotleja on projekti taotluses ette

näinud, kas tema digilahendus põhineb e-ehituse platvormil konkreetselt läbi integratsiooni ja

liidestamise või mitte. Kui see põhineb e-ehituse platvormil läbi integratsiooni ja liidestamise, siis

tuleb seda ka teha, aga kui see plaan oli ainult visiooniline ehk tulevikku suunatud tegevus, mis

leiab aset peale projekti lõppu, siis oleks tulnud projekti taotluses sõnastada seos e-ehituse

platvormiga teisiti.

62. Projekti eesmärki ja tegevusi ei ole lubatud muuta. Lisaks ei ole toetuse saaja projekti

perioodil vahendusasutust teavitanud, et tegevusi ei ole võimalik planeeritud mahus ellu viia, mis

ilmselgelt mõjutab projekti ettenähtud tulemust. Projekti tulemusel pidid protsessid olema

automatiseeritud ja lihtsustatud: solar-varjualuste dokumenteerimise ja registreerimise protsess on

integreeritud e-ehituse platvormiga, vähendades koduomanike koormust dokumentatsiooni

kooskõlastamisel.

63. Kui toetuse saajal ilmnesid projekti jooksul eelnimetatud probleemid, siis oleks tulnud

sellest vahendusasutust informeerida. Antud kohustus on välja toodu TRO punktis 11.7. Seega,

kui selgus, et loodava rakenduse integreerimist ei saa, ei ole mõistlik teha vms projekti raames,

siis oleks tulnud sellest vahendusasutust teavitada.

64. Toetuse saaja on oma selgitustes maininud, et toetuse eesmärk ei olnud veebis kättesaadava

lahenduse loomine, sest veebis kättesaadav ei saa olla enam MVP, vaid veebis inimestele

kättesaadav peab olema Production-ready. Ometigi on projekti taotluses lk 10 konkreetselt öeldud,

et tööriist on kättesaadav lõpptarbijatele ja valmis laiemaks kasutuselevõtuks ja lk-l 14 projekti

lühikokkuvõttes avalikkusele: „Platvorm on avatud ja kättesaadav kõigile, aidates edendada

taastuvenergia kasutuselevõttu ja ehitusvaldkonna digitaliseerimist.“

65. Projekti lõppedes ega otsuse koostamise hetkel ei toimi valminud lahendus projektis

kirjeldatud viisil ja pole ka veebis kõigile kättesaadav.

66. Toetuse saaja hinnangul on lõplik MPV toimiv, millega aga vahendusasutus ei saa

nõustuda, kuna lahendus näitab krundi kohta ebatäpseid andmeid ja süsteem ei ole integreeritud e-

ehituse platvormiga. Projekti tegevuse kirjeldusest ega ka pakkumuskutsest ei ilmne, et

integreerimine oli ainult visiooniline, nagu toetuse saaja väidab.

67. Toetuse saaja ütleb videodemos, et projekti oli võimalik realiseerida teoreetiliselt, andes

hinnangu, et projektist õnnestus pool.

68. Vahendusasutus peab vajalikuks märkida, et vahendusasutuse projektikoordinaatori poolt

09.07.2025 toetuse saajale saadetud kirjas „Projekti meelespea“ juhiti mh toetuse saaja tähelepanu

punktides 2.1 ja 5 järgmistele asjaoludele:

- Projekti tegevusi rahastatakse kindlasummalise makse alusel. Kindlasummalise makse alusel

toetuse andmisel on olulisim näitajate ja tulemuste täielik saavutamine.

- Näitajate planeeritud sihttasemete mittesaavutamisel jääb toetus täies mahus välja maksmata.

- Tasume toetuse, kui tegevused on tehtud täpselt nii nagu taotluses planeeritud ja näitajate

saavutamist tõendavad korrektsed dokumendid on meile esitatud.

- Projekti lõpuks peavad olema projekti näitajad saavutatud täies mahus ning tegevused läbi

viidud taotluse punktis „Tegevused“ kirjeldatu kohaselt. Vastasel juhul jääb toetuse summa

täies ulatuses välja maksmata.

- Palume teavitada vahendusasutust kõikidest muudatustest või asjaoludest, mis võivad projekti

elluviimist mõjutada. Taotluse rahuldamise otsuse muutmine projekti elluviimise ajal on

lubatud ainult abikõlblikkuse perioodi osas. Muus osas ei ole projekti ega taotluse rahuldamise

otsuse muutmine lubatud.

69. Seega oli vahendusasutuse hinnangul toetuse saaja teadlik asjaolust, et projekti elluviimisel

tuleb lähtuda projekti taotluses ja taotluse rahuldamise otsuses sätestatud tingimustest, sh

tegevused tehtud täpselt nii nagu taotluses planeeritud ning kui tegevusi ei viida ellu kogu

ettenähtud ulatuses, siis jääb toetus välja maksmata.

70. Lähtuvalt eeltoodust on vahendusasutus seisukohal, et kuivõrd toetuse saaja ei ole taganud

projekti elluviimist ettenähtud tingimustel ning seega ei ole täitnud taotluse rahuldamise otsuses

sätestatud makse tegemise eelduseid, siis tuleb jätta toetus välja maksmata.

MAKSEST KEELDUMISE JA TAOTLUSE RAHULDAMISE OTSUSE KEHTETUKS

TUNNISTAMINE

71. TRO punkti 13 kohaselt võidakse maksest keelduda üldmääruse § 9 lõikes 7 ja meetme

määruse § 23 lõikes 7 sätestatud alustel.

72. Üldmääruse § 9 lg 7 punkti 1 kohaselt võib vahendusasutus toetuse maksmisest keelduda,

kui eeldused makse tegemiseks ei ole täidetud.

73. Meetme määruse § 23 lg 4 alusel ei ole makse teostamise eeldused täidetud kui:

1) makse aluseks olnud tegevused ei ole ellu viidud;

2) taotluse rahuldamise otsuses kokkulepitud tingimused ei ole täidetud ja tõendatud.

74. Meetme määruse § 23 lg 7 punkti 1 kohaselt võib vahendusasutus jätta toetuse osaliselt või

täielikult välja maksmata kui taotluse rahuldamise otsuses nimetatud tulemus jäi saavutamata ja

tõendamata.

75. Kuivõrd toetuse saaja ei ole kõiki makse aluseks olevaid tegevusi teostanud taotluse

rahuldamise otsuses sätestatud tingimustel, siis jätab vahendusasutus välja maksmata toetuse

summas 20 492 eurot, sh taaste- ja vastupidavusrahastus 100%.

76. TRO punkti 14 kohaselt võib vahendusasutus taotluse rahuldamise otsuse täielikult või

osaliselt kehtetuks tunnistada üldmääruse § 11 lõigetes 1 ja 3 ning meetme määruse § 20 lõikes 5

nimetatud juhtudel.

77. Üldmääruse § 11 lg 1 punkti 1 kohaselt on vahendusasutusel õigus teha taotluse

rahuldamise otsuse täielikult kehtetuks tunnistamise otsus kui toetuse saamise või kasutamisega

seotud kohustust või nõuet ei ole osaliselt või täielikult täidetud.

78. Meetme määruse § 20 lg 5 punkti 1 kohaselt tunnistab taotluse rahuldamise otsuse

kehtetuks, kui ilmneb asjaolu, mille korral taotlust ei oleks rahuldatud või taotlus oleks rahuldatud

osaliselt.

79. Arvestades, et käesoleva otsusega jäetakse välja maksmata kogu projektile määratud toetus

ning projekti toetuse andmise tingimused ei ole täidetud, siis tuleb taotluse rahuldamise otsus

kehtetuks tunnistada.

80. Täiendavalt märgib vahendusasutus, et kui taotlust hinnanud eksperdid taotluse hindamisel

ja vahendusasutus taotluse rahuldamise otsuse tegemisel oleksid olnud teadlikud asjaolust, et

toetuse saaja ei plaani loodavat rakendust integreerida e-ehitus platvormile, ei oleks taotlust

tõenäoliselt rahuldatud või oleks see rahuldatud osaliselt. Seda põhjusel, et üks toetatav tegevus

oleks olnud projektis vähem ning taotletav toetus selle võrra väiksem. Samuti pole teada, kuidas

oleks eksperdid antud taotlust sellisel juhul hinnanud ning milliseks oleks kujunenud taotluste

paremusjärjestus.

ÄRAKUULAMINE

81. Haldusmenetluse seaduse § 40 lõikest 1 tulenevalt peab enne haldusakti andmist

haldusorgan andma menetlusosalisele võimaluse esitada kirjalikus, suulises või muus sobivas

vormis asja kohta oma arvamus ja vastuväited. Vahendusasutus edastas toetuse taotluse

rahuldamise otsuse kehtetuks tunnistamise otsuse eelnõu toetuse saajale tutvumiseks 05.03.2026

vastulause esitamise tähtajaga 19.03.2026.

82. Toetuse saaja teavitas 20.03.2026 vastuskirjaga (Lisa 3) vahendusasutust, et otsuse toodud

faktid on moonutatud ja sõnastatud nagu vahendusasutus on seda heaks arvanud, tõest ja tegelikust

olukorrast ning normaalsusest on need kaugel.

83. Esiteks, toetuse saaja heidab vahendusasutusele ette, et vahendusasutus on asendanud

projekti tegeliku tulemuse hindamise ühe tehnilise alamkomponendi formaalse kontrolliga.

Toetuse saaja hinnangul see ei ole kooskõlas ei projekti taotluse sisulise loogika, meetme

eesmärgiga ega ka proportsionaalse haldustegevuse põhimõttega. Toetuse saaja väidab, et projekti

taotluses kirjeldatud põhieesmärk ei olnud ühe konkreetse tehnilise integratsiooni realiseerimine

iseeneses, vaid toimiva digitaalse tööriista loomine, mis muudab koduste solar-varjualuste

tellimise, planeerimise ja dokumenteerimise lihtsamaks, läbipaistvamaks ja digitaalselt juhitavaks.

Lisades, et valmis on kasutatav konfiguratsioonitööriist, automaatne hinnastamise loogika,

dokumentatsiooni eelvormistamise võimekus, kasutajaliides, pilootkasutajatega testitud töövoog

ning reaalse väärtuspakkumise valideerimine. Toetuse saaja leiab, et vahendusasutuse käsitlus,

nagu loeks kogu projekti õnnestumise või ebaõnnestumise ainsaks mõõdupuuks see, kas üks

konkreetne tehniline detail - EHR-i lõplik automaatne liidestus - on MVP-faasis täielikult

realiseeritud, on sisuliselt ja praktiliselt väär, sest see taandab kogu projekti üheks alamelemendiks

ja ignoreerib ülejäänud lahenduse 99% sisu, eesmärki ja tegelikku mõju.

84. Vahendusasutus juhib toetuse saaja tähelepanu sellele, et meetme määruse § 23 lõigete 2-

4 kohaselt makstakse toetust üldmääruse § 9 lg 3 punkti 2 nimetatud viisil ühekordse maksena

pärast aruande kinnitamist, lähtudes taotluse rahuldamise otsuses sätestatud tingimustest ja

korrast. Makse tehakse eeldusel, et makse aluseks olnud tegevused on ellu viidud ning taotluse

rahuldamise otsuses kokkulepitud tingimused on täidetud ja tõendatud. Koos maksetaotlusega

tuleb esitada tõendid projekti tegevuste ja tulemuste kohta vastavalt toetuse taotluse rahuldamise

otsusele. Üldmääruse § 9 lg 3 punkt 2 sätestab, et makse tehakse kokkulepitud tingimuste täitmise

alusel. See tähendab seda, et toetus makstakse välja alles siis, kui taotluses ettenähtud tegevused

on ellu viidud, tulemus saavutatud ja nõuetekohaselt tõendatud.

85. Toetuse saaja on oma projekti taotluses kavandanud tegevused ja tulemused (käesoleva

otsuse punktid 2, 4 ja 6), mis on vajalikud projekti eesmärgi saavutamiseks (otsuse punkt 1). Seega,

et saavutada projekti eesmärk, nägi toetuse saaja taotluses ette vastavad tegevused ja üheks

tegevuseks oli ka lahenduse integreerimine e-ehituse platvormiga, mille tulemusena pidi solar-

varjualuste dokumenteerimise ja registreerimise protsess olema integreeritud e-ehituse

platvormiga. Vastavalt meetme määruse § 23 lg 4 punktile 1 on ühekordse makse tegemise üheks

tingimuseks see, et makse aluseks olnud tegevused on ellu viidud ja üheks makse aluseks olnud

tegevus on ka loodava lahenduse integreerimine e-ehituse platvormiga. Seega ei saa

vahendusasutuse seda makset teha, kuivõrd antud tegevus on tegemata ehk makse tegemise

tingimus ei ole täidetud. Toetuse saaja on ise oma taotluses kirjeldanud kõiki projekti tegevusi,

mida ta soovis ellu viia, et saavutada projekti tulemus ja eesmärk. Seega, nüüd olukorras, kus

toetuse saaja on jätnud ühe tegevuse tegemata, siis ei saa asuda seisukohale, et projekti tulemus ja

eesmärk on ikkagi saavutatud. Projekti tegevused on omavahelises eesmärgipärases seoses ning

projekt ei ole nõuetekohaselt ellu viidud olukorras, kus üks tegevus on täitmata.

86. Toetuse saaja väitel vaidlusalune tehniline komponent moodustab projekti koguväärtusest

ja mõjust hinnanguliselt alla 1%, samas kui ülejäänud lahendus töötab ja täidab eesmärki. Selle

väitega ei saa vahendusasutus kuidagi nõustuda. Esiteks, videodemos on toetuse saaja hinnanud

projekti õnnestumist 50%-le. Teiseks, vahendusasutus on küll oma põhjendused juba toonud

otsuse punktides 43-70, aga lisab, kuivõrd antud juhul makstakse toetust ühekordse maksena ja

kokkulepitud tingimuste täitmisel ehk kui makse aluseks olnud tegevused on ellu viidud, siis ei

ole teada, millise osa tegelikult moodustas ära jäänud tegevus kogu projektist, kuivõrd toetuse

saaja ei esita vahendusasutusele kuludokumente. Antud taotlusvoorus saab toetuse saaja toetuse

kui ta on kõik makse aluseks olnud tegevused ellu viinud, tulemused saavutanud ja nende

saavutamist tõendanud. Juhul kui tegemist oleks projektiga, kus toetust makstakse tekkinud ja

tasutud kulude alusel, siis oleks võimalik kulude alusel olnud tegevusi ka eraldiseisvalt hinnata.

Seega, toetuse saaja eksib, kui väidab, et vahendusasutus ei vaata projekti kui ühtset tervikut.

87. Teiseks, toetuse saaja väidab, et „integratsioon“ ei ole taotluses defineeritud kui

kohustuslik EHR-i automaatne andmevahetus. Lisades, et taotluses kasutatud sõnastused („seos e-

ehituse platvormiga“, „dokumentatsiooni automatiseerimine“, „andmete ettevalmistamine ja

edastamine“) kirjeldavad eesmärki ja suunda, kuid ei sätesta üheselt konkreetset tehnilist

teostusviisi, milleks oleks tingimata: otsene API-põhine ühendus Ehitisregistriga, automaatne

andmete üleslaadimine EHR-i, või kolmanda isiku nimel toimuv registrisse kandmine. Toetuse

saaja mainib, et vahendusasutus ei ole oma otsuse eelnõus viidanud ühelegi normile, juhendile ega

määratlusele, mille kohaselt „integratsioon“ tähendaks üksnes automaatset EHR andmevahetust.

88. Vahendusasutus on antud järeldusele jõudnud põhjusel, kuivõrd toetuse saaja on seda ise

sõnaselgelt oma taotluses öelnud. Näiteks on käesoleva otsuse punktis 2 väljavõte toetuse saaja

taotluse lk 8 toodud projekti tulemustest, kus on selgelt öeldud, et solar-varjualuste

dokumenteerimise ja registreerimise protsess on integreeritud e-ehituse platvormiga. See projekti

tulemus on toetuse saaja enda sõnastatud, mis on kirjas kui üks projekti tulemustest, mis

saavutatakse projekti tegevuse tulemusena. Samuti on otsuse punktis 3 toodud projekti taotluses

lk 9 kirjeldatud põhikomponendid, mida projekti raames valminud lahendus hõlmab ja millest üks

on automatiseeritud dokumentatsioon ja kooskõlastamine selgitusega, et lahendus on integreeritud

e-ehituse platvormiga, mis võimaldab varjualuse projekte ja dokumente automaatselt ette

valmistada ning registreerida Ehitisregistris (EHR). Otsuse punktis 6 on käsitletud projekti

taotluses lk 16-17 toodud tegevuste täpsustused, kus on selgelt välja toodud, et arendatakse liides,

mis võimaldab projekti dokumente ja andmeid automaatselt saata Ehitisregistrisse (EHR),

tagades nende vastavuse kehtivatele nõuetele. Lisaks on pakkumuskutses (otsuse p 45)

konkreetselt öeldud, et projekti tulemusena peab valmima töötav prototüüp, mis võimaldab

automatiseerida solar-varjualuste projekteerimise ja hinnakalkulatsiooni protsessi ja on

integreeritud e-ehituse platvormiga ja vastab Ehitisregistri nõuetele. Projekti lühikokkuvõttes

avalikkusele on samuti toetuse saaja väga konkreetselt öelnud, et lahendus automatiseerib

projekteerimis- ja dokumenteerimisprotsessid, sealhulgas integratsiooni e-ehituse platvormiga.

Seega tugineb vahendusasutus toetuse saaja enda taotluses kirjutatule, sh ka vaides välja toodud

põhjendustele, ja käesolevas otsuses on vahendusasutus väga konkreetselt viidanud, millistest

taotluse osadest vastavale järeldusele jõudis. Toetuse saaja jätab ise kõrvale taotluses kajastatu

teabe andes sellele vastuolulisi selgitusi ja põhjendusi. Toetuse saaja on eksiarvamusel, kui leiab,

et projekti taotluses toodud tegevused ei ole kohustuslikud projektitulemuste saavutamiseks. Seda

enam, need tegevused on toetuse saaja ise lubanud projekti raames koos toetusega ellu viia. Otsuse

punktis 28 on viidatud nii TRO punktile 12 kui ka meetme määruse § 20 lõikele 2, mille kohaselt

ei ole lubatud muuta projekti eesmärki, toetatavat tegevust ning maksete arvu ja suurusi. On ilmne,

et projekti taotluses toodud tegevused tuleb ellu viia sellisel kujul, nagu need on projekti taotluses

kirjeldatud, ja nende muutmine ei ole lubatud.

89. Vahendusasutuse hinnangul ei ole projekti taotluses toodud, et lahendus peab olema

funktsionaalselt ja andmestruktuuri tasandil ainult kooskõlas e-ehituse platvormi loogikaga.

Projekti taotluses on tegevustena toodud nii lahenduse liidestamine kui ka integreerimine.

90. Toetuse saaja toob taas välja, et MVP faasis ei ole täielik EHR integratsioon olnud projekti

arendamise käigus selgunult proportsionaalne ega mõistlik. Otsuse punktis 62 on vahendusasutus

märkinud, et kui toetuse saajal tekkisid teatud takistused projekti tegevuste elluviimisel, siis oleks

tulnud sellest koheselt vahendusasutust teavitada. Toetuse saaja seda aga ei teinud ja paraku ei ole

selle meetme raames teostatavates projektis lubatud, ei projekti eesmärki ega tegevusi muuta.

Vahendusasutus on ka otsuse punktides 49-53 välja toonud, et juba projekti hindamise faasis

juhtisid eksperdid toetuse saaja tähelepanu asjaolule, et liidestamine e-ehituse platvormile võib

olla töömahukas ja sellega võivad kaasneda riskid. Seega võttis toetuse saaja teadlikult riski, et

tegevusi ei pruugi olla võimalik soovitud aja jooksul ja mahus ellu viia.

91. Toetuse saaja vastuskirjast ei selgu, kuidas ja mis alustel toetuse saaja järeldab, et projekti

tegevused (nt integratsioon Ehitisregistri ja e-ehitus platvormiga), mis on toodud projekti taotluses,

ei ole kohustuslikud elluviimiseks, et saavutada projekti tulemusi. Tegevused peavad olema

kooskõlas meetme määrusega ja selle üle vaidlust ei ole, aga kui toetuse saaja on projekti taotluses

kirjeldanud projekti tegevused ja nendele tegevustele on otsustatud anda toetust, siis ei saa väita,

et projekti tegevused pole kohustuslikud. Toetuse saaja projekt on saanud toetust lähtudes taotluses

toodule. Seda enam, et meetme määruse § 23 lõike 4 kohaselt makse teostamise eelduseks on:

punkt 1, et makse aluseks olnud tegevused on ellu viidud, ja punkt 2, et TRO-s kokkulepitud

tingimused on täidetud ja tõendatud. Sellest tulenevalt on projekti kõikide tegevuste elluviimine

kui üks tervik. Arvestades projekti taotluses toodut ja reaalselt valminud lahendust, siis makse

teostamise eeldused ei ole täidetud.

92. Vahendusasutus juhib tähelepanu meetme määruse eelnõu seletuskirjale, kus on öeldud

meetme määruse § 20 kohta, et nimetatud paragrahv käsitleb taotluse rahuldamise otsuse muutmist

ja kehtetuks tunnistamist. Maksekorra puhul, kus makse tehakse kokkulepitud tingimuste

saavutamisel, on lubatud muuta vaid projekti abikõlblikkuse perioodi osas. Teised muudatused

pole võimalikud, kuna hindamiskomisjon on heaks kiitnud konkreetsete tulemuste saavutamise ja

nende maksumuse. Seega, toetus makstakse välja arvestusega, et toetuse saaja teeb kõik projekti

tegevused ja saavutab kõik lubatud tulemused, mis on projekti taotluses toodud.

93. Kolmandaks, toetuse saaja väitel põhineb vahendusasutuse väide nagu projekti raames

valminud lahendus ei põhine e-ehituse platvormil ning sellest tulenevalt ei ole täidetud projekti

eesmärgid, määratlemata ja sisuliselt lahtisel mõistel „põhinemine e-ehituse platvormil“, millele

ei ole esitatud õiguslikku definitsiooni ega metodoloogilist tõlgendust.

94. Toetuse saaja on pööranud vahendusasutusee tähelepanu asjaolule, kus vahendusasutus on

otsuse eelnõus jõudnud valele järeldusele, et vastavalt meetme määrusele peab väljatöötatud

uuenduslik digilahendus põhinema e-ehituse platvormil. Vahendusasutus korrigeeris kõnealuse

otsuse punkti 61, millega täpsustab, et meetme määruse kohaselt toetatakse väljatöötatud

uuenduslikke digilahendusi, mis põhinevad e-ehituse platvormil, mis aga ei tähenda seda, et

projekti raames peaks see uuenduslik digilahendus ilmtingimata olema integreeritud või

liidestatud Ehitusregistri ja e-ehituse platvormiga. Samas, kui taotlusega nähakse ette, et loodav

lahendus põhineb e-ehituse platvormil just integratsiooni ja liidestamise näol, siis tuleb seda ka

teha, kuivõrd toetust antakse taotluses ettenähtud tegevustele ja kui taotluses on ettenähtud

tegevusena integreerimine EHR-i, siis vastavalt sellele tuleb see tegevus ka teostada.

95. Otsuse punktis 60 on viidatud meetme määruse § 2 lõikele 2, mille kohaselt eesmärgi

saavutamiseks toetatakse e-ehituse platvormil põhinevate ja eraldiseisvate uuenduslike

digilahenduste väljatöötamise, prototüüpimise või rakendamise projekte ehitusvaldkonnas. Säte

viitab sellele, et uuendusliku digilahenduse põhinemine e-ehituse platvormil on projekti

seisukohalt oluline komponent. Meetme määruse § 3 punkti 1 alusel on e-ehituse platvorm

infosüsteem, mis koondab sellega liidestunud ehitusvaldkonna teenuseid ja andmeid. Toetuse

saaja on projekti taotluses lk 16-17 (otsuse p 6 alapunkt 2) ise sisustanud, mida ta mõtleb e-ehituse

platvormiga liidestumise all. Üldjuhul mõistetakse liidestumise all infosüsteemide ja seadmete

vahelist ühenduse moodustamist, andmevahetuse hõlbustamiseks ühenduma (Eesti Keele

Instituudi veebileht Sõnaveeb). Sõna „põhinema“ mõistetakse sünonüümidena ka tuginema,

toetuma, baseeruma, rajanema, lähtuma ehk midagi aluseks võtma, millestki lähtuma (ÕS 2018;

ÕS 2025 Eesti Õigekeelsussõnaraamat; Eesti Keele Instituudi veebileht Sõnaveeb), ehk siis

valminud uuenduslik digilahendus peab aluseks võtma ja lähtuma e-ehituse platvormist.

Eelkirjeldatust nähtub, et ilmselgelt peab valminud lahendus olema seotud e-ehituse platvormiga

ja toetuse saaja on selle seose kirjutanud projekti taotlusesse lk-l 11-12 (otsuse punkt 5). Valminud

lahendus, mida on tõendatud videodemo kaudu, aga ei näita, et valminud lahendus on seotud e-

ehituse platvormiga ning kasutab selle võimalusi.

96. Toetuse saaja märgib, et kui vahendusasutuse seisukoht on, et „põhinemine e-ehituse

platvormil“ tähendab alati täielikku tehnilist integratsiooni, siis: peab see olema selgelt sätestatud

enne projekti rahastamist, peab see olema kajastatud hindamiskriteeriumides, peab see olema

üheselt mõistetav kõigile taotlejatele. Siinkohal märgib vahendusasutus, et tehnilise integratsiooni

on toetuse saaja projekti taotluses ise lubanud projekti tegevusena ellu viia (otsuse p 3 alapunkt 2;

p 4 alapunkt 2; p 5; p 6 alapunkt 2; p 7). Projekti taotluses ei ole kajastatud, et integratsiooni on

mõeldud teostada tulevikus, nt peale projekti lõppu vms. Samuti on hinnapakkumus

arendustöödele võetud selliselt, et projekti tulemusena peab valmima töötav prototüüp, mis on

integreeritud e-ehituse platvormiga ja vastab Ehitisregistri nõuetele. Projekti lõppedes toetuse

saaja esitatud lõpparuandest ja videodemost aga selgub, et valminud prototüüp ei ole integreeritud

e-ehituse platvormiga.

97. Vahendusasutus juhib tähelepanu, et toetus jäetakse välja maksmata põhjusel, et projekti

kõik tegevused, mis on kirjeldatud projekti taotluses, ei ole ellu viidud. See, et projekti tegevused

peavad olema täielikult ellu viidud, sellest teavitati toetuse saajat koheselt peale rahastamise otsuse

edastamist (otsuse punkt 68). Seega ei saanud see teadmine toetuse saajale tulla ootamatult ja seda

ei saa ka lugeda tagantjärele kitsendavaks asjaoluks, nagu toetuse saaja väidab.

98. Neljandaks, toetuse saaja leiab, et vahendusasutuse väide, et lahendus ei toimi, põhineb

üksikjuhtumi pinnapealsel vaatlusel ning ei vasta digilahenduse arenduse, MVP loogika ega

süsteemide töökindluse hindamise põhimõtetele. Lisades, et vahendusasutus ei ole tuvastanud,

milles seisneb väidetav „vale andmeallikas“.

99. Vahendusasutus juhib tähelepanu, et otsuse punktis 65 vahendusasutus märgib, et projekti

lõppedes lahendus ei toimi projektis kirjeldatud viisil ja pole ka veebis kõigile kättesaadav.

100. Järeldus, et andmeid ei saada õigetest allikatest, kui krundi aadressi sisestamisel kuvatakse

teade, et katastriandmed ei ole kättesaadavad, pärineb toetuse saaja enda öeldust videodemos. Ehk

toetuse saaja on ise tunnistanud, et selle teate põhjuseks on ebaõiged andmed. Seega ei ole tegemist

vahendusasutuse järeldusega, vaid toetuse saaja enda öelduga.

101. Vahendusasutusest testisid süsteemi (canopies.me) tööd neli inimest ja osad nendest mitme

erineva krundi andmetega. Loodud süsteemis kuvatavad krundi andmed ei ühtinud EHR-is toodud

andmetega. Ühe krundi omanik veendus, et tema krundi kohta kuvatavad andmed ei ole täpsed.

Videodemos toetuse saaja tunnistab ka ise, et rakendus kuvab ebatäpseid andmeid ning ei paku

sisuliselt väga põhjalikku infot, vaid üldise ülevaate. Seega ei ole tegemist pelgalt üksikjuhtumi

pinnapealse vaatlusega vahendusasutuse poolt.

102. Toetuse saaja mainib vastuskirjas lk 9-10 punktis 3, et MVP (Minimum Viable Product)

eesmärk ei ole garanteerida 100% andmete kättesaadavust ning loetleb MVP eesmärgid.

Vahendusasutus juhib tähelepanu, et toetuse saaja on sõnastanud projekti taotluses lk 8 punktis 2

(otsuse p 2) üheks tulemuseks, et solar-varjualuste dokumenteerimise ja registreerimise protsess

on integreeritud e-ehituse platvormiga. Samuti on see selgelt toodud projekti taotluses lk 9 punktis

2 (otsuse p 3) - lahendus on integreeritud e-ehituse platvormiga, mis võimaldab varjualuse projekte

ja dokumente automaatselt ette valmistada ning registreerida Ehitisregistris (EHR). Seega ei saa

lugeda projekti eesmärgiks ainult neid eesmärke, mida toetuse saaja on vastuskirjas nimetanud.

103. Viiendaks, toetuse saaja ei nõustu vahendusasutuse väitega, et projekti on oluliselt

muudetud ja sellest ei teavitatud vahendusasutust vastavalt meetme määruse § 25 punktile 11.

Lisades, et vahendusasutuse järeldus ei vasta tegelikule olukorrale ega ole piisavalt põhjendatud

ning väide tugineb eeldustele, mida ei ole faktiliselt tõendatud.

104. Vahendusasutus ei hakka taas üle kordama projekti eesmärki, mis on juba toodud otsuse

punktis 1. Samuti on see sõnastatud pakkumuskutses (otsuse punkt 43; lahendus peab olema

kasutajasõbralik, automatiseeritud ja integreeritud e-ehituse platvormiga). Vahendusasutus ei

nõustu toetuse saajaga, et kõik nimetatud eesmärgid on täidetud. Lahendus on küll loodud, aga see

ei tööta nii, nagu projektis kirjeldatud. Projekti lõpuks ei ole võimalik lahenduse kaudu

automatiseerida solar-varjualuse tellimist ega dokumenteerimise protsessi. Projekti lõppedes ei

olnud tegemist sellise lahendusega, mis lihtsustaks koduomanike jaoks varjualuste soetamist,

samuti ei ole süsteem integreeritud e-ehituse platvormiga. Projekti tulemused ei ole terviklikud

saavutatud.

105. Mis puudutab faktilist tõendamist, siis vahendusasutus juhib tähelepanu, et makse

teostatakse eeldusel, et makse aluseks olnud tegevus on ellu viidud ja TRO-s kokkulepitud

tingimused on täidetud ja tõendatud. Toetuse saaja esitas TRO-s kokkulepitud tingimuste täitmise

kohta lõpparuande ja selles kirjeldatud tulemuste tõendamiseks videodemo. Lõpparuandes lk 7

toetuse saaja kirjutab, et kahjuks EHR-i otse üleslaadimist ei saa automaatselt teha; tehnilised

integratsioonid ja toimima saamine vajalike 3ndate osapooltega jne. Vahendusasutus ei hakka

kõike kirjutatut taas kordama, kuna see on juba välja toodud otsuse punktides 12-14 ja 17. Samuti

on toetuse saaja videodemos kirjeldanud, mida oli plaanis projekti raames teha, aga paraku jäi

teostamata (otsuse punktid 37-40). Välja on toodud probleemkohad, mida ei olnud võimalik

projekti raames teha, kuigi need tegevused olid projekti taotluse kirjeldatud. Seega, videodemos

on tõendatud projekti tegevuste tulemused ainult osaliselt.

106. Toetuse saaja väidab, et vahendusasutuse väide, nagu toetuse saaja on „loobunud

liidestamisest“, ei vasta tõele ja on valeväide. Vahendusasutus juhib tähelepanu, et sellist väidet ei

ole vahendusasutus otsuses väitnud. Tõsiasi on see, et projekti raames pole liidestust tehtud. Kui

toetuse saaja soovib seda peale projekti lõppu teha, siis see on teine asi. Vahendusasutus hindab

ainult seda, mis on projekti teostamise ajal tehtud ja mis on jäänud tegemata. Seega, toetuse saaja

väitel pole alust.

107. Vahendusasutus ei nõustu toetuse saajaga, et meetme määruse § 25 ei ole kohaldatav.

Toetuse saaja on projekti taotluses lk-l 9 (otsuse punkt 3) väga selgelt kirjeldanud, mida projekti

raames valminud lahendus hõlmab; lk-del 9-10 (otsuse punkt 4) projekti elluviimise jaganud

kolme etappi; lk 16-17 (otsuse punkt 6) täpsustanud projekti raames tehtavaid tegevusi; lk 8 (otsuse

punkt 2) toonud konkreetselt välja projekti tulemused. Kui projekti käigus jäi osa tegevustest

teostamata ja sellega seoses ka tulemused saavutamata, siis ei saa väita, et tegemist ei ole

asjaoludega, mis vältimatult või suure tõenäosusega takistavad projekti ettenähtud tulemuste

saavutamist. Tulemuspõhine projekt on üks tervik, kui mingid tegevused jäävad teostamata, siis ei

ole ka projekti tulemus terviklikult saavutatud. Toetuse saaja on projekti tegevusi ja saavutatud

tulemusi tõendanud ainult osaliselt, mille kinnituseks on lõpparuandele lisatud videodemo. Seega,

meetme määruse § 25 kohaldamine käesolevas juhtumis on igati asjakohane.

108. Kuuendaks, toetuse saaja hinnangul vahendusasutuse väide, et projekti ei oleks rahastatud

juhul, kui oleks teada olnud EHR integratsiooni mitte realiseerimine MVP faasis, ei ole kooskõlas

projekti hindamisdokumentidega ning on sisuliselt tagantjärele konstrueeritud hinnang. Lisades,

et hindamisdokumentides puudub igasugune viide EHR integratsioonile kui otsustavale tegurile.

109. Vahendusasutus nõustub toetuse saajaga, et hindamisdokumentides puudub eraldi

kriteerium konkreetselt EHRi integratsioonile, kuid projektis kajastatud tegevusi hinnati läbivalt

kõikides hindamiskriteeriumides, kuivõrd tegevuste alusel saab hinnata projekti vastavust toetuse

andmise eesmärgile, põhjendatust, kvaliteeti ja taotleja võimakust projekti tegevuste

läbiviimiseks. Projekti tegevused on üheks hindamise põhikomponendiks, kuivõrd ilma projekti

tegevuseta ei saaks projekti üldse hinnata (projekt on tegevus või nende kogum). Seega on antud

tegevus olnud üheks hindamiskomponendiks kõigis hindamiskriteeriumites. Eksperdid on

tegevust e-ehituse platvormiga integreerimist konkreetselt kommenteerinud vaid

hindamiskriteeriumis 4, mis puudutab taotleja võimekust projekti tegevuste läbiviimiseks, mis aga

ei tähenda seda, et projekti tegevusi ei hinnatud teistes hindamiskriteeriumides. Seega ei nõustu

vahendusasutuse toetuse saaja väitega nagu EHR-i integratsioon ei ole nende hulgas isegi kaudselt

keskne teema.

110. Siinkohal vahendusasutus kordab otsuse punktis 49 toodut, mille kohaselt projekti esimesel

hindamise leidsid eksperdid, et projekti taotluses kirjeldatu ühenduse (lahendus saab seotud

Ehitisregistri ja e-ehituse platvormiga, automatiseerides registreerimis- ja

dokumenteerimisprotsessid) analüüs ning õiguslikult korraldamine ei mahu antud projekti

kestvuse sisse. Projekti taotluse korduvhindamisel on eksperdid jäänud oma esialgse kahtluse

juurde, küll aga teises sõnastuses (otsuse punkt 52), et nii taotleja kui valitud arenduspartner ei

oma teadaolevalt kogemust e-ehituse platvormiga liidestamisel (arenduspartneri puhul on selle

olemasolu mainitud taotluses, kuid ettevõtte kodulehelt antud infot ei leia) ning ei oska sellest

tulenevalt võibolla hinnata töömahtu ning kaasnevaid riske. Sealjuures on toetuse saaja oma vaides

(otsuse punkt 50) rõhutanud, et taotluses on kirjeldatud solar-varjualuste tellimise ja

dokumenteerimise täielik digitaliseerimine koos e-ehituse platvormi integreerimisega.

111. Vahendusasutus nõustub toetuse saajaga, et otsuse punktis 109 toodud hindamislehel

märgitud viide on riskikommentaar. Seda on vahendusasutus juba otsuse punktis 53 ka maininud,

et eksperdid juhtisidki tähelepanu sellele, et liidestumisel e-ehituse platvormiga võivad kaasneda

riskid ja lisanud otsuse punktis 55, et toetuse saaja võttis riski, et tegevusi ei ole võimalik soovitud

aja jooksul ja mahus ellu viia. Seega, riski võttes, pidi toetuse saaja arvestama sellega, kui projekti

taotluses kirjeldatud projekti tegevusi tehakse osaliselt ja teostamata tegevuste puhul jäävad

kirjeldatud tulemused saavutamata, siis toetuse summa jääb täies ulatuses välja maksmata (otsuse

punkt 68; toetuse saajale 09.07.2025 edastatud kiri e-toetuste keskkonna kaudu).

112. TRO punktis 9.1 (otsuse punkt 31) on tõesti toodud, et makse aluseks olev tulemus on

toimiv ja testitud prototüüp, mida tõendab videodemo keskkonnas. Lisaks on samas punktis

sätestatud, et makse summas 20 492,00 eurot makstakse välja peale projektis kirjeldatud tegevuse

ellu viimist (rakenduse arendus, mis automatiseerib solar-varjualuste tellimise, projekteerimise,

dokumenteerimise protsessid, lihtsustades koduomanike jaoks varjualuste soetamist ja aidates

kaasa taastuvenergia eesmärkide saavutamisele). Seega, toimiva prototüübi all saab mõista

prototüüpi, mis automatiseerib solar-varjualuste tellimise, projekteerimise, dokumenteerimise

protsessid, lihtsustades koduomanike jaoks varjualuste soetamist ja aidates kaasa taastuvenergia

eesmärkide saavutamisele, ning seda kõike peab tõendama videodemo. Videodemos ei ole

tõendatud, et arendus automatiseerib solaar-varjualuse tellimist, projekteerimist

dokumenteerimise protsesse. Videodemos on tõendatud projekti käigus valminud lahendus, mille

kaudu sisestades krundi asukoha aadressi, kuvatakse krundi andmed, mis ei ole täpsed, kuna

andmeid ei saadud õigetest allikatest (toetuse saaja väide). Samuti on tõendatud, et saab pakutud

variante ja lisasid kasutades kujundada endale meeldiva solar-varjualuse. See, kas soovitud solar-

varjualust saab ka tegelikult valitud krundile ehitada/paigaldada või missugune on see

dokumentatsioon, mille projekteerija lisab ja mis peaks konkreetsest nupust genereerima EHRi

mineva raporti, seejärel projekti sisu laetakse automaatselt EHRi üles vastavatele väljadele, ei ole

tõendatud. Toetuse saaja on oma videodemos väitnud, et seeläbi oleks kogu projekti loomine ja

seadustamine automatiseeritud. Vahendusasutus märgib, et automatiseerimise tähenduse on

toetuse saaja ise oma projekti taotluses sisustanud (projekti taotlus lk 8, otsuse p 2 alapunkt 2;

projekti taotlus lk 9, otsuse p 3 alapunkt 2; projekti taotlus lk 9-10, otsuse p 4 alapunkt 2; projekti

taotlus lk 16-17, otsuse p 6 alapunktid 1 ja 2), mille all on väga konkreetselt ja üheselt mõista

antud, et ühendus luuakse Ehitisregistri ja e-ehituse platvormiga. Projekti taotluses lk 16-17

punktis 2 „Andmete ja süsteemide integreerimine“ on lahti kirjutatud, mida toetuse saaja mõtleb

e-ehituse platvormiga liidestamise all (otsuse punkt 6). Seega, toetuse saaja väide, et kuskil ei ole

sätestatud, et EHR- integratsioon peab olema realiseeritud, ei vasta tõele. Kuna kõik projekti

tegevused ja läbi tegevuste saavutatud tulemused on makse eelduseks, siis sinna hulka kuulub ka

tegevus, mis puudutab automaatiseerimist (sh integreerimist e-ehituse platvormiga) ja see on üks

osa kogu projekti terviktulemusest.

113. Vahendusasutus märkis täiendavalt otsuse punktis 79, et kui taotlust hinnanud eksperdid

taotluse hindamisel ja vahendusasutus toetuse taotluse rahuldamise otsuse tegemisel oleksid olnud

teadlikud asjaolust, et toetuse saaja ei plaani loodavat rakendust integreerida e-ehitus platvormile,

ei oleks taotlust tõenäoliselt rahuldatud või oleks see rahuldatud osaliselt. Vahendusasutus ei

nõustu toetuse saajaga, et eeltoodud väide on vastuolus hindamise ja TRO-ga. Vahendusasutus

juba mainis otsuse punktides 107-111, et projekti taotluse hindamisel eksperdid hindasid kõigis

hindamiskriteeriumites kõiki projekti tegevusi, sh liidestamise ja integreerimisega seonduvat.

Seega, otsuse punktis 79 toodu ei ole pelgalt tagantjärele loodud põhjendus, nagu toetuse saaja

väidab.

114. Vahendusasutus kordab, et antud toetus makstakse välja, kui kokkulepitud tingimused on

täidetud. See tähendab, et kõik projektis ettenähtud tegevused on tehtud, tulemused saavutatud ja

nõuetekohaselt tõendatud. Kui makse aluseks olev mõni tegevus on tegemata, tulemus

saavutamata, siis ei saa toetust välja maksta. Käesoleval juhul on toetuse saaja jätnud tegemata

lahenduse integreerimise e-ehituse platvormile, mida ka toetuse saaja ise videodemos ütleb.

Toetuse saaja teadis riskidest, et projekti ajakava sisse ei pruugi mahtuda lahenduse täielik

automatiseerimine, sellele riskile juhtisid tähelepanu ka eksperdid projekti taotluse hindamisel.

Samuti oli toetuse saajat teavitatud, et projekti lõpuks peavad olema projekti tegevused läbi viidud

taotluse punktis „Tegevused“ kirjeldatu kohaselt. Vastasel juhul jääb toetuse summa täies ulatuses

välja maksmata.

115. Lisaks vahendusasutus märgib, et toetuse saaja väitel, et otsuses toodud faktid on

moonutatud ja sõnastatud nagu vahendusasutus on seda heaks arvanud, tõest ja tegelikust

olukorrast ning normaalsusest on need kaugel, ei ole alust. Käesolevas otsuses on kasutatud toetuse

saaja enda poolt sõna-sõnalt kirjutatut ja videodemos öeldut. Kui toetuse saaja mõte oli luua

lahendus, mida projekti käigus ei integreerita e-ehituse platvormiga, siis vastavalt sellele oleks

tulnud kirjutada ka projekti taotlus, sh pakkumuskutse. Käesoleval juhul on aga toetuse saaja oma

taotluses sõnaselgelt öelnud, et lahendus integreeritakse e-ehituse platvormiga (ka oma vaides

rõhutas toetuse saaja seda). Nii on sellest arusaanud ka taotlust kaks korda hinnanud eksperdid.

116. Tulenevalt eelpool toodust on vahendusasutus seisukohal, et makse teostamise eeldused ei

ole täidetud, st makse aluseks olnud tegevused ei ole täis mahus ellu viidud, TRO-s kokkulepitud

tingimused ei ole täidetud ega tõendatud.

VAIDLUSTAMINE

117. Otsuse peale on õigus esitada vaie vahendusasutusele 30 päeva jooksul, arvates päevast,

mil isik sai või oleks pidanud otsusest teada saama (haldusmenetluse seaduse § 75).

(allkirjastatud digitaalselt)

Marge Kõiva

elukestva õppe ja IT-arenduse talituse juhataja

toetuste rakendamise osakonna juhataja ülesannetes

Lisad:

1. RTK menetlus. Küsimused ja vastused (16.01.2026)

2. RTK menetlus. Küsimused ja vastused v2 26.01.2026.

3. Vastuskiri 20.03.2026.

Koostaja: Kairi Puur

506 6131

[email protected]