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 09.04.2026 nr 11.3-1/26/1691 Järva-Jaani alev, Järva vald, Järva maakond 73301 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Ü (edaspidi toetuse 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]