Otsus

< OTSUS Vaidlustusasja number 49-23/259711 Otsuse kuupäev 15.05.2023 Vaidlustuskomisjoni liige Angelika Timusk Vaidlustus Inversion Software OÜ vaidlustus ühishankijate Riigi Tugiteenuste Keskus ja SA Kutsekoda riigihankes „„Oskuste Süsteemi“ esimene arendusetapp - oskuste kirjeldamise keskkond (SA Kutsekoda)“ (viitenumber 259711) riigihanke alusdokumentidele Menetlusosalised Vaidlustaja, Inversion Software OÜ, esindaja Indrek Järve Ühishankija, Riigi Tugiteenuste Keskus ja SA Kutsekoda, esindaja Riina Loorpuu Vaidlustuse läbivaatamine Kirjalik menetlus RESOLUTSIOON RHS § 197 lg 1 p 5 ja RHS § 198 lg 2 alusel 1. Rahuldada vaidlustus osaliselt ja kohustada ühishankijaid Riigi Tugiteenuste Keskus ja SA Kutsekoda viima TK p 1.3 ja Nõuded meeskonnale p 1 vastavusse õigusaktidega ettenähtud nõuetega. 2. Mõista ühishankijatelt Riigi Tugiteenuste Keskus ja SA Kutsekoda Inversion Software OÜ kasuks välja tasutud riigilõiv 320 eurot proportsionaalselt vaidlustuse rahuldamisega. EDASIKAEBAMISE KORD Halduskohtumenetluse seadustiku § 270 lg 1 alusel on vaidlustuskomisjoni otsuse peale halduskohtule kaebuse esitamise tähtaeg kümme (10) päeva arvates vaidlustuskomisjoni otsuse avalikult teatavaks tegemisest. JÕUSTUMINE Otsus jõustub pärast kohtusse pöördumise tähtaja möödumist, kui ükski menetlusosaline ei esitanud kaebust halduskohtusse. Otsuse osalisel vaidlustamisel jõustub otsus osas, mis ei ole seotud edasikaevatud osaga (riigihangete seaduse § 200 lg 4). ASJAOLUD JA MENETLUSE KÄIK 1. 27.03.2023 avaldas ühishankija Riigi Tugiteenuste Keskus ja SA Kutsekoda, keda vaidlustusmenetluses esindab Riigi Tugiteenuste Keskus (edaspidi Hankija) riigihangete registris avatud hankemenetlusega läbiviidava riigihanke „„Oskuste Süsteemi“ esimene arendusetapp - oskuste kirjeldamise keskkond (SA Kutsekoda)“ (viitenumber 259711) (edaspidi Riigihange) hanketeate ja tegi kättesaadavaks muud riigihanke alusdokumendid (edaspidi RHAD), sh Oskuste süsteemi 1. arendusetapi detailanalüüs (edaspidi TK), Lisateave (edaspidi HD), Hindamismetoodika ja Raamlepingu projekt ühe pakkujaga (edaspidi Raamleping) ja Vastavustingimused (edaspidi Vastavustingimused). 2. 14.04.2023 laekus Riigihangete vaidlustuskomisjonile (edaspidi vaidlustuskomisjon) Inversion Software OÜ (edaspidi ka Vaidlustaja) vaidlustus riigihanke alusdokumentide vastavusse viimiseks õigusaktidega ettenähtud nõuetega. 3. Kooskõlas riigihangete seaduse (edaspidi RHS) § 195 lg-ga 2 ja § 196 lg-dega 1 ja 3 teatas vaidlustuskomisjon 21.04.2023 kirjaga nr 12.2-10/49 menetlusosalistele, et vaatab vaidlustuse läbi esitatud dokumentide alusel kirjalikus menetluses, tegi teatavaks otsuse avalikult teatavaks tegemise aja ning andis täiendavate seisukohtade ja dokumentide esitamiseks aega kuni 26.04.2023 ja neile vastamiseks 02.05.2023. Vaidlustuskomisjoni poolt määratud esimeseks tähtpäevaks esitas seisukoha Vaidlustaja ja teiseks Hankija. MENETLUSOSALISTE PÕHJENDUSED 4. Inversion Software OÜ põhjendab vaidlustust järgmiselt. 4.1. Hindamiskriteeriumide õigusvastasus 4.1.1. Hankija on sätestanud järgmised hindamiskriteeriumid: - lisaarenduse ja hoolduse tunnihind, osakaal 10% (edaspidi Hinnakriteerium); - arendustööde metoodika ja projektiplaani kvaliteet, osakaal 90% (edaspidi Kvaliteedikriteerium). Kvaliteedikriteerium on täiendavalt jaotatud kolme võrdse kaaluga alamkriteeriumisse: - metoodika ja projektiplaani tegevuste detailsus – hindamistulemus 1, 10, 20 või 30 punkti; - metoodika ja projektiplaani etappide ja nendega seotud tellijale esitatud ootuste selgus – hindamistulemus 1, 10, 20 või 30 punkti; - metoodika ja projektiplaani vastavus detailanalüüsile – hindamistulemus 1, 10, 20 või 30 punkti. 4.1.2. RHS § 85 lg-dest 1 ja 3 ning RHS § 3 lg 1 p-st 5 tulenevalt peavad hindamiskriteeriumid vastama vähemalt järgmisele kahele tingimusele: - peavad olema seotud hanke esemega; - peavad tagama parima hinna ja kvaliteedi suhtega pakkumuse edukuse. RHAD on vastuolus mõlema tingimusega. 4.1.3. Hindamiskriteeriumid ei ole seotud Riigihanke esemega. 4.1.3.1. Riigihanke tulemusel soovib Hankija sõlmida raamlepingu, millega soovitakse fikseerida arendustööde tunnihind Eesti Oskuste Infosüsteemi (OIS) väljatöötamiseks. Kvaliteedikriteerium on suunatud hindamaks projektiplaani OIS arendustöödele, kuid Riigihankes esitatavad pakkumused ei sisalda tarkvara arendustöid. 4.1.3.2. Tõenäoliselt soovib Hankija sõlmida hankelepingu konkreetse arendustöö tellimiseks raamlepingu sõlmimise järel, esitades tellimuse väljavalitud partnerile. RHAD-is ei ole ühtegi nõuet, mis sätestaks, et edukas pakkuja on tulevaste tellimuste puhul seotud Riigihanke 2 (13) pakkumuses esitatud projektiplaaniga, sh ajagraafiku ja töömahtudega. Hankija tellib abstraktset tunnihinda, kuid hindab Kvaliteedikriteeriumi alusel pakkujate esitatud hüpoteetilist ja mittesiduvat projektiplaani töö osas, mida Hankija Riigihankega ei telli ja ei pruugi esitatud kujul kunagi tellida. 4.1.4. Hindamiskriteeriumid ei taga parima hinna ja kvaliteedi suhtega pakkumuse edukust. 4.1.4.1. Hinna ja kvaliteedi suhtega seoses tuleb käsitleda olukorda, kus hindamiskriteeriumides on hinna ja kvaliteedi osakaal võrdne (50%-50%). 4.1.4.2. Olukorras, kus hankija rahalised vahendid on piiratud või kvaliteedinõuded on riigihanke alusdokumentides üheselt fikseeritud, võib hinna osakaal hindamiskriteeriumides olla suurem kui 50% ning kvaliteedikriteeriumi osakaal väiksem kui 50%. Kvaliteedikriteeriumi osakaal võib olla ka 0% (RHS § 85 lg 4). 4.1.4.3. Tulenevalt nõudest kasutada Hankija rahalisi vahendeid säästlikult ja otstarbekalt ning sõlmida hankeleping parima võimaliku hinna ja kvaliteedi suhte alusel ei ole Vaidlustaja hinnangul võimalik käsitleda kvaliteedikriteeriumi osakaalu olulisest tõstmisest üle 50% sama liberaalselt kui on võimalik hinnakriteeriumi osakaalu tõstmise puhul. Kvaliteedikriteeriumi osakaalu tõstmisel 50%-st kõrgemale hakkab Hankija eelistama natuke kvaliteetsemaid, kuid oluliselt kallimaid pakkumusi ning hinna-kvaliteedi suhte kasv on seejuures eksponentsiaalne. Nt osakaalu 75% kvaliteet ja 25% hind juures on pakkumused A ja B hindamispunktidelt sarnased, kui pakkumus A on pakkumusest B 1/3 kvaliteetsem ning samas 3x kallim (200% kallim). 4.1.4.4. Riigihankes on Hankija viinud hinna ja kvaliteedi osakaalu ekstreemsusesse. Kvaliteet on 9x (800%) olulisem kui hind ning 15% kvaliteetsema pakkumuse eest saab küsida kasvõi 100x suuremat hinda. Näiteks kui esitatakse pakkumused A ja B, kus pakkumus A saab kvaliteedikriteeriumi alusel 80 punkti ja B saab 90 punkti (~13% rohkem), siis isegi juhul, kui pakkumuse A tunnihind on 50 eurot (10 punkti) ning pakkumuse B tunnihind on 5000 eurot (0,1 punkti), võidab pakkumus B, sest ta saab kokku 90,1 p ja A saab 90 punkti. 4.1.5. Isegi kui Kvaliteedikriteerium oleks seotud hanke esemega ning Hinnakriteeriumi ja Kvaliteedikriteeriumi osakaal oleks 50-50, on hindamiskriteeriumid ikka õigusvastased. 4.1.5.1. Hinnakriteeriumiks on abstraktne tunnihind. Kvaliteedikriteeriumiks on hüpoteetilise projektiplaani kvaliteet. Nende kahe kriteeriumi vahel puudub kvantifitseeriv seos (pakkuja A ja pakkuja B töötunnid ei pruugi olla võrreldavad ega anda samaväärset tulemust). Hankija kulusid määravaks reaalseks asjaoluks on see, kui mitu ühiktundi kulub pakkujatel hanke eesmärgi saavutamiseks (infosüsteemi väljaarendamiseks). 4.1.5.2. Vaidlustaja hinnangul probleemi ei esineks, kui Hankija hindaks tunnihinna asemel või kõrval tarkvaraarendustööde (või selle esimese osa) kogumaksumust. 4.2. TK õigusvastasus 4.2.1. TK p 1.3 sätestab nõude Arenduse peamine tehnoloogiline lahendus on paika pandud järgnevalt: 1) Front-End – React.js 3 (13) 2) Back-End – Node.js 3) API - REST Nõue on vastuolus RHS § 88 lg-ga 6, kuna nimetatud on mitte üksnes kindlat kaubamärki ja tüüpi, vaid lausa konkreetsed tooted ja teenused. 4.2.2. HD p-s 8.1 on Hankija esitanud formalistliku klausli Iga viidet, mille hankija teeb riigihanke alusdokumentides ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. Selline kõikehõlmav klausel on sisutühi ja õigusvastane. RHS asetab RHS § 88 lg-s 6 toodud erandi põhjendamiskohustuse Hankijale ja lubab nimetatud erandit kasutada ainult juhul, kui muul viisil hankelepingu eseme kirjeldamine on võimatu. 4.2.3. Vaidlustajale on selge, et Hankija ei soovi samaväärseid tooteid, vaid just enda poolt nimetatuid, kuna ta on oma valikut põhjendanud RHAD-is. Hankija on nimetatud tooted ja kaubamärgid valinud seetõttu, et tegu on kõige populaarsemate tehniliste lahendustega (TK p 1.3), mis näitab, et tegemist on Hankija subjektiivsete eelistustega, mitte vältimatu võimatusega. Hankija esitatud põhjendused on lisaks ka faktiliselt väärad ning õiguslikult asjasse mittepuutuvad. 4.2.3.1. Hankija väide: Tegu on kõige populaarsemate tehniliste lahendustega. Nii Node.js kui React.js on JavaScript programmeerimiskeelega seotud tooted. Enamlevinud ja -tunnustatud programmeerimiskeelte turuosa ja kasutuspopulaarsuse edetabelite näitel ei saa kuidagi väita, et tegemist saaks olla kõige populaarsemate tehniliste lahendustega maailmas, kuna nt TIOBE Indexi 04.2023 edetabelis on JavaScript seitsmendal kohal (esikohast 6.1x madalam „osakaal“) ja PYPL PopularitY of Programming Language Indexi 04.2023 edetabelis on JavasScript kolmandal kohal (esikohast 2.8x madalam „osakaal“). 4.2.3.2. Hankija väide: React on paremini ja täielikumalt dokumenteeritud. Tegemist on subjektiivse ja põhistamata väitega, samuti on see asjakohatu RHS § 88 lg 6 kontekstis. Hästi dokumenteeritud programmeerimiskeeli, teeke ja raamistikke on palju. 4.2.3.3. Hankija väide: React skaleerub Nodega kõige paremini. Vaidlustaja ei välista, et suvalised eelvalitud tooted võivad koos kõige paremini töötada, kuid selline põhjendus ei ole asjakohane RHS § 88 lg 6 kontekstis. Kui Hankija jaoks on käideldavus ja skaleeritavus olulised, siis on vaja sätestada RHAD-is vastavad skaleeruvusnõuded. Praktiliselt kõigis enamlevinud programmeerimiskeeltes ja raamistikes eksisteerivad viisid hästi skaleeritavate lahenduste loomiseks. Käideldavusnõuete kehtestamine (nt päringut/sekundis, kasutajatoimingut/sekundis, paralleelsete kasutajate minimaalselt toetatud arv) on tarkvaraarenduse riigihangete alusdokumentide tehnilise kirjelduse tavapärane osa. Vaidlustaja hinnangul on TK p-s 3.5 viidatud käideldavusnõuded küllaltki tagasihoidlikud ega viita sellele, et loodav rakendus vajaks mingit erilist skaleeritavuse lahendust. 4.2.3.4. Hankija väide: Nii React kui Node kasutavad mõlemad JavaScripti ning läbi selle on kogu meie süsteemis ühtlasem keelekasutus. Hankija võib ühtlasema keelekasutuse hinnavõitu arvestada olelusringi kulude raames. 4.3. Vastavustingimuste õigusvastasus Kuivõrd eeltoodud põhjendustel on õigusvastane React.js ja Node.js nõudmine tehnoloogilise lahendusena, on asjakohatu ja õigusvastane viidata samadele kaubamärkidele ka RHAD 4 (13) „Nõuded meeskonnale“, mis on viidatud Vastavustingimustes „Nõuded meeskonnale“. 4.4. Vaidlustaja täiendavad seisukohad 4.4.1. Hindamiskriteeriumide õigusvastasus 4.4.1.1. Hankija on enda hinnangul fikseerinud hankelepingu hinna või kulu pakkujatele siduvalt ning hindab pakkumusi üksnes kvalitatiivsete, keskkonnaalaste või sotsiaalsete kriteeriumite alusel. Hankija väidab, et Hanke üldandmetes ja raamlepingu projekti punktis 2.2, on selgelt sõnastatud: „Esimese etapi valmimise hind on 250 000 eurot, millest 125 000 eurot MVP ja 125 000 eurot kogu toode“. Sellist tsitaati tegelikult raamlepingu projekti p-s 2.2 ei ole. Nimetatud lause on küll toodudhanketeate osas II Riigihanke lühikirjelduses terviklõiguna järgmiselt sõnastatult: Riigihanke eeldatav maksumus on 350 000 eurot nelja aasta peale. Esimese etapi valmimise hind on 250 000 eurot, millest 125 000 MVP ja 125 000 kogu toode. 100 000 nelja aasta arendus- ja hooldustöödeks. Raamlepingu p 2.2 on aga sõnastatud järgmiselt: Nimetatud eeldatav maksumus on 350 000 eurot nelja aasta peale. Esimese etapi valmimise hinnaks on arvestatud 250 000 eurot, millest 125 000 Minimal Viable Product (MVP) ja 125 000 kogu toode. 100 000 on arvestatud nelja aasta arendus- ja hooldustöödeks. Seega on RHAD omavahel vastuolus ja RHAD-i tuleb tõlgendada laiendavalt pakkujatele soodsamalt – Riigihanke eseme hinda ei tohi lugeda fikseerituks. 4.4.1.2. Raamlepingu p-s 2.2 toodud sõnastus ja keelekasutus on äärmiselt tinglik, kompaktne ja ebakonkreetne (ei räägita mitte hankelepingu maksumusest vaid eeldatavast maksumusest). Vaatamata Hankija väidetele on tegelikult kirjas hoopis infosüsteemi arenduse maksimaalne hind ja edukal pakkujal ei ole ühtegi õiguslikku takistust peale raamlepingu sõlmimist esitada pakkumus, mille maksumus ei ole 250 000 eurot, niikaua kuni esitatava pakkumuse maksumus ei ületa 250 000 eurot „põhiarenduse“ ja 100 000 eurot „4 aasta arendus- ja hooldustööde summa“ osas. 4.4.2. Kvalitatiivsete hindamiskriteeriumide õigusvastasus Hankija selgitused keskenduvad suures osas kas: - eksiarvamusele, et Hankija on infosüsteemi arenduse hinna Riigihankega fikseerinud või - eksiarvamusele, et Hankija ja edukas pakkuja on hankemenetluse tulemusel sõlmitava raamlepingu kaudu vältimatult kohustatud sõlmima esimese (raamlepingu sisese) hankelepingu Riigihanke hankemenetluses esitatud projektiplaani ja hinnaga. Vaidlustaja on seisukohal, et: - Riigihanke tulemusena vahetult infosüsteemi arendustöid ei tellita, vaid valitakse välja üks tarkvaraarendaja; - Riigihanke võitja väljaselgitamiseks kasutatakse mõõdikuna peamiselt hüpoteetilist projektiplaani kvaliteeti; - tegeliku infosüsteemi arenduse tellib Hankija eraldi pärast raamlepingu sõlmimist ja hankemenetluse lõppu; - tellimusele pakkumuse esitamisel puudub täitjal kohustus olla seotud raamlepingu pakkumuses esitatud algse projektiplaaniga (sh tähtaegade, töömahtude ja hinnaga), mida kasutati raamhanke hindamisel. 4.4.3. TK õigusvastasus Hankija ei ole kordagi isegi väitnud, et hankelepingu eset ei saaks kirjeldada ilma React ja Node tooteid mainimata. Hankija eksitab vaidlustuskomisjoni väites, et Hankija aktsepteerib kõiki 5 (13) programmeerimiskeeli ja tehnilisi lahendusi, mis on RHADis toodud või nendega samaväärsed. Hankija on viidanud turu-uuringule, mille käigus viis Hankija läbi ka videolindistatud infopäeva. Sellest nähtub, et Hankijal puudub kavatsus hinnata „samaväärseid“ lahendusi ja tal on plaan alternatiivseid platvorme sisaldavad pakkumused välistada või tagasi lükata. 5. Riigi Tugiteenuste Keskus vaidleb vaidlustusele vastu. 5.1. Hindamiskriteeriumide õigusvastasus 5.1.1. RHS § 85 lg 7 annab hankijale õiguse fikseerida hankelepingu hind või kulu pakkujatele siduvalt ning hinnata pakkumusi üksnes kvalitatiivsete, keskkonnaalaste või sotsiaalsete kriteeriumite alusel. Hankija on kasutanud seda võimalust ning tellib „Oskuste Süsteemi“ esimese arendusetapi tööd (MPV ja live-versioon) fikseeritud hinnaga ning selgitab parima pakkuja välja kvalitatiivsete hindamiskriteeriumide põhjal (90%). Kuna Hankijal võib olla vajadus tellida peale live-versiooni valmimist ka lisaarendusi ja hooldustöid, on Hankija lisanud hindamiskriteeriumiks ka lisaarenduse ja hoolduse 1 töötunni maksumuse (10%). See on olnud Hankija tahe ning teadlik ja kaalutletud otsus. 5.1.2. Vaidlustaja on hindamiskriteeriume valesti tõlgendanud. Hankija ei hangi põhiarenduse tunnihinda, kuna on arendustööde mahtu ja tööde struktuuri arvestades kogumaksumused tööde lõikude kaupa eelnevalt fikseerinud ja ka RHAD-is välja toonud. Hanke üldandmetes ja raamlepingu projekti p-s 2.2 on sõnastatud: Esimese etapi valmimise hind on 250 000 eurot, millest 125 000 eurot MVP ja 125 000 eurot kogu toode. Konkreetse hinna määramise aluseks on hanke osaks olev turu-uuring ja mahuhinnang, mis omakorda baseerub MVP (RHAD detailanalüüsi p-s 4.1) ja kogu toote vajalikel funktsionaalsustel (Detailanalüüsi dokument tervikuna). Hankija küsib vaid lisaarenduse ja hoolduse tunnihinda, olles ühtlasi paika pannud ka lisaarenduse ja hoolduse maksimaalse maksumuse – 100 000 eurot. Teisisõnu jaguneb töö kolme erinevasse etappi, millest kahe esimese etapi raames teostatakse kõik arendustööd, mis tellitakse Hankija poolt fikseeritud hinnaga (vastavalt MPV 125 000 eurot ning kogu toote valmimine 125 000 eurot) ning kolmandaks etapiks on vajaminevad hooldustööd ja lisaarendused, millele Hankija on planeerinud eelarvet kuni 100 000 eurot, kuid mille tööd tellitakse vastavalt vajadusele. 5.1.3. Vaidlustaja on vaidlustuses märkinud, et kehtestatud kvaliteedikriteerium on suunatud hindamaks projektiplaani OIS arendustöödele, kuid käesolevas hankemenetluses esitatavad pakkumused ei sisalda tarkvara arendustöid. Hankija ei nõua, et pakkujad pakkumuse esitamiseks teostaks mingeid arendustöid. Arendustöid hakkab teostama Riigihankes edukaks osutuv pakkuja. Pakkujad peavad pakkumuses esitama arendustööde metoodika ja projektiplaani kvaliteedi kirjelduse. Projektiplaani alusel pakkumuse kvaliteedi hindamine on väga levinud ja tunnustatud praktika, sest projektiplaanis saab pakkuja selgitada lähemalt, mil moel detailanalüüsis nõutud funktsionaalsused välja arendatakse. Eeldada tootearendust pakkumuse osana oleks ebaproportsionaalne. 5.1.4. Vaidlustaja väide, et RHAD-is ei ole ühtegi nõuet, mis sätestaks, et edukas pakkuja on seotud tulevaste tellimuste puhul raamhanke pakkumuses esitatud projektiplaaniga, sh ajagraafiku ja töömahtudega on ekslik, sest Raamlepingu p 1.1 sätestab lepingu alusdokumendina ka esitatud pakkumuse. Lisaks sätestab Raamlepingu p 1.4: Lepingu lahutamatuteks osadeks on riigihanke alusdokumendid, täitja pakkumus, sh projektiplaani, lepingu alusel sõlmitud hankelepingud, tööde üleandmisevastuvõtmise aktid (edaspidi akt), pooltevahelised kirjalikud teated ning lepingu muudatused ja lisad. Pakkumuses nõutud arendustööde metoodika ja projektiplaani kvaliteedi kirjeldust kasutatakse pakkumuste hindamiseks ning nende põhjal selgitatakse välja, kes pakkujatest on kõige paremini 6 (13) planeeritavatest töödest aru saanud, kas Hankija ootusetest on aru saadud, kas metoodika ja projektiplaan vastavad detailanalüüsile jne (täpsem kirjeldus on leitav Hindamismetoodikast). Hankijal on plaanis täiemahuliselt hanke tulem lõpuni viia ja raamlepingu alusel hankelepingud sõlmida ning saada vajaminev ja toimiv arendustööde tulem. 5.1.5. Vaidlustaja kahtleb selles, kas Hankija tellimuse sisse annab ning kas ta teeb seda RHAD- is viidatud kujul. Hankija selgitab, et pakkumuses esitatud projektiplaan on raamlepingu osa ning kirjeldab muuhulgas tehtavate tööde graafikut. Lisaks on Hankija nii Riigihanke üldandmetes kui ka raamlepingu projekti p-s 13.1 sõnastanud, et töö fikseeritud hinnaga osa (live-versioon) peab olema valmis 9 kuuga. See tähendab, et Hankija huvides ei ole tellimusega viivitada. Mis puudutab tellimuse esitamist RHAD-is viidatud kujul, siis tänapäevases IT- arenduses on üha enam levinum agiilsuse printsiip, mis on ka hanke detailanalüüsis (p 1.3) välja toodud. Agiilse arenduse printsiipide järgi on pooltel võimalik arendusplaani teha muudatusi, kui seda tingivad nt testimistulemused, saadud uus sisend tehnoloogilise lahenduse või vajaduse kohta vm. 5.1.6. Hankija ei nõustu, et hinna ja kvaliteedi suhtest rääkides tuleb vaikimisi käsitleda olukorda, kus hindamiskriteeriumides on hinna ja kvaliteedi osakaal võrdne (50%-50%). Milline osakaal hinnale määrata, on Hankija diskretsioon. Tulenevalt Riigihanke esemest ja sellest, et Riigihanke lisaarenduse ja hoolduse maht on kogu arendustegevusest pigem marginaalne osa, on Hankija lisaarenduse ja hooldustööde maksumusele määranud taotluslikult väikese osakaalu. Hankija eeldab, et pakkujad tulevad konkureerima ausate turuhindadega ning kui peaks juhtuma Vaidlustaja välja pakutud stsenaarium ning edukaks osutub pakkumus , mis on kvalitatiivsete näitajate poolest väga hea (ehk pakkuja teostab suure tõenäosusega tööd väga hästi), kuid mille tunnihind on väga kõrge, siis on Hankijal kaalutlusotsus, kas peale live- versiooni valmimist ja hilisema vajaduse tekkimisel tellida lisaarendusi ja hooldustöid või mitte. Raamlepingus fikseeritakse lisaarenduse ja hooldustööde maksimaalne 1 tunni maksumus, millest väiksemat maksumust võib pakkuja hilisema tellimuse käigus pakkuda ning kui Hankijal puuduvad rahalised vahendid sellise hinnaga tööde tellimiseks, siis puudub Hankijal kohustus raamlepingu alusel töid tellida. 5.2. TK õigusvastasus 5.2.1. Vaidlustaja on teinud rea ekslikke oletusi. Vaidlustaja peab formalistlikuks, kõikehõlmavaks ning sisutühjaks RHAD dokumendi „Lisateave“ p-i 8.1: Iga viidet, mille hankija teeb riigihanke alusdokumentides ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. Vaidlustaja väidab, et Hankija ei soovi samaväärseid tooteid, vaid just enda poolt nimetatuid, kuna ta on oma valikut põhjendanud RHAD-is. Tegemist on vale väitega. Märge “või samaväärne” ning TK-s esitatud põhjendused tähendavad Hankija jaoks seda, et pakkujal on kasutuses lai ring tarkvaralisi lahendusi ja etteantud võimalik lahendus on vaid üks alternatiividest, mille kaudu saab muuhulgas aimu, mis on Hankija jaoks tarkvaralise lahenduse juures oluline (kasutamissagedus, keelekasutuse ühtlus jm). TK-s nimetatuga samaväärse lahenduse pakkumine ei too kaasa pakkumuse mittevastavust, vaid Hankija peab kontrollima, kas pakutu on samaväärne ning kas samaväärsus on koos pakkumusega tõendatud. 5.2.2. Hankija viis ajavahemikus 21.12.2022–06.01.2023 läbi turu-uuringu ning üks turu- uuringu küsimustest oli: Kas hankija välja pakutud tehnoloogiline lahendus on osalejate hinnangul hanke eesmärkide saavutamiseks sobiv. Kõik turu-uuringus osalejad hindasid selle sobivaks ning seetõttu on Hankija kindel, et tegemist on selle IT-arenduse kontekstis ühe potentsiaalselt sobiva lahendusega, kuid see on näide Hankija soovitud Back-end ja Front-endi 7 (13) ühilduvuse ja sarnase programmeerimiskeele süntaksi (pidades silmas II ja III arendusetapi perspektiivi), dokumenteerituse ja API tehniliste omaduste kohta. RHAD-i lisateabe dokumendi p-i 8.1 alusel on ülaltoodud tarkvaraliste lahenduste loetelu hõlmav, mitte välistav. Kui projektiplaanis kirjeldatakse teist tehnoloogilist lahendust, ei käsitleta seda pakkumuste hindamisel veana. Hankija on seda selgitanud ka vastuses hankemenetluses osalemisest huvitatud isiku küsimusele (teabevahetus 734967). Hankija aktsepteerib kõiki programmeerimiskeeli ja tehnilisi lahendusi, mis on RHAD-is toodud või nendega samaväärsed. 5.3. Hankija täiendavad seisukohad 5.3.1. Hindamiskriteeriumide õigusvastasus 5.3.1.1. Vaidlustusest ja selle täiendusest nähtub, et Vaidlustaja ei ole mõistnud Riigihanke ülesehituse ja dokumentide omavahelist seost ja loogikat, samuti ei ole Vaidlustaja kasutanud võimalust selgitusi küsida. 5.3.1.2. Hankija kasutab sõna „eeldatav“ vaid siis, kui viidatakse kogumaksumusele. Hankija on fikseerinud arenduse kahe esimese etapi maksumused – 250 000 eurot, mistõttu Hankija küsib hinda vaid lisaarendusele ja hooldusele. Hindamiskriteeriumides on sõnastus Lisaarenduse ja hoolduse tunnihind, mis ei ole mitmeti mõistetav. 5.3.1.3. Arusaamatu on väide, et hindamiskriteeriumid ei ole seotud hankelepingu esemega. Lepingu esemeks on arendustööd ning seega on arendustööde metoodika ja projektiplaani kvaliteet väga otseselt seotud hankelepingu esemega. Hankija sooviks on jätta endale paindlik võimalus lisatööde tellimiseks. 5.3.1.4. TK p-i 1.3 õigusvastasus Hankija põhitegevuseks on kutsestandardite koostamine, kutseeksamite korraldamise koordineerimine ning Eesti tööjõu ja oskuste tulevikuvajaduste analüüsimine. Hankija põhitegevuseks ei ole IT-arendustööde tegemine. Hankija soov oli vältida olukorda, kus Hankija ei suuda kõiki oma soove funktsionaalsuste abil väljendada ja seetõttu on Hankija viidanud konkreetsetele lahendustele, mille osas on ta veendunud oma vajaduste täitmises. Selleks, et olla kindel, et Hankija ja pakkujad mõistavad Hankija ootusi tulevasele lepingu esemele samamoodi, on Hankija nimetanud detailanalüüsi p-s 1.3 React.js, Node.js ja REST lahendusi. Konkreetsed viited tuleb lugeda täiendatuks märkega „või sellega samaväärne“. Seda, millised teised lahendused Hankija hinnangul vastavad samaväärsuse tingimusele, ei saa Hankija ette kindlaks määrata. 5.3.1.4. Pakkuja, kes soovib pakkuda alternatiivseid lahendusi, peab selle oma pakkumuses välja tooma. Nimetades ära konkreetsed lahendused ja lubades esitada samaväärseid lahendusi, on kõikidele valdkonnas tegutsevatele ettevõtetele üheselt selged need kriteeriumid, mille alusel Hankija samaväärsust hindab. VAIDLUSTUSKOMISJONI PÕHJENDUSED 6. Hindamiskriteeriumid Hankija on sätestanud Hinnakriteeriumina lisaarenduse ja hoolduse tunnihinna, mille osakaal on 10% ja Kvaliteedikriteeriumina arendustööde metoodika ja projektiplaani kvaliteedi, osakaaluga 90%. Vaidlustuse kohaselt ei ole need seotud Riigihanke esemega ega taga parima hinna ja kvaliteedi suhtega pakkumuse edukust. 8 (13) 6.1. Hankija ja Vaidlustaja seisukohtade vahel on põhimõtteline eriarusaam RHAD-ist: 1) Hinnakriteerium - vaidlustus põhineb eeldusel, et Hinnakriteeriumiga hangib Hankija arendustööde tunnihinda kõikidele raamlepingu alusel sõlmitavate hankelepingutega tellitavatele teenustele; - Hankija väitel ei hangita põhiarenduse tunnihinda ja tööd tuleb teostada RHAD-is fikseeritud hinnaga: Esimese etapi valmimise hind on 250 000 eurot, millest 125 000 eurot MVP ja 125 000 eurot kogu toode (Riigihanke üldandmed ja raamlepingu projekti p 2.2); 2) Kvaliteedikriteerium - vaidlustus põhineb eeldusel, et Kvaliteedikriteeriumiga hinnatakse esitatud hüpoteetilist ja mittesiduvat projektiplaani töö osas, mida Hankija Riigihankega ei telli ja ei pruugi kunagi tellida; - Hankija väitel on esitatud projektiplaan raamlepingu osa ning kirjeldab muuhulgas tehtavate tööde graafikut. 6.2. Hinnakriteeriumi õiguspärasus 6.2.1. Vaidlustaja ei väida, et Hankija ei võiks Riigihankega tellida põhiarendust RHAD-is fikseeritud hinnaga, vaid leiab, et Hankija arvab ekslikult, et on selle RHAD-is ka selliselt sätestanud. Vaidlustuskomisjon on seisukohal, et kuna Vaidlustaja väited seoses Hinnakriteeriumi õigusvastasusega (osakaal 10% on ebaproportsionaalne, mis muudab võimatuks parima hinna ja kvaliteedi suhtega pakkumuse edukuse) põhinevad kõik eeldusel, et hangitakse arendustööde tunnihinda kõikidele raamlepingu alusel tellitavatele teenustele, siis olukorras, kus Hankija on üheselt mõistetavalt kinnitanud ja selgitanud, et sellist soovi tal ei ole, tuleb RHAD-ist kontrollida Hankija seisukohtade põhjendatust (arusaadavust). 6.2.1.1. RHS § 85 lg 7 annab Hankijale põhimõttelise õiguse määrata RHAD-is kindlaks hankelepingu hind või kulu suurus ja hinnata pakkumusi üksnes kvalitatiivsete, keskkonnahoidlikkuse või sotsiaalsete kriteeriumide alusel. Seega Hankija tahe fikseerida esimese etapi valmimise hind ei ole iseenesest õigusvastane. Hanketeate osa II p-s 1.4 (lühikirjeldus) on muuhulgas märgitud: Esimese etapi valmimise hind on 250 000 eurot, millest 125 000 MVP ja 125 000 kogu toode. Raamlepingu p-i 2.2 teine lause on sõnastatud järgmiselt: Esimese etapi valmimise hinnaks on arvestatud 250 000 eurot, millest 125 000 Minimal Viable Product (MVP) ja 125 000 kogu toode. Sõnastuses on mõningane erinevus hanketeate osa II p-ga 1.4, kuid mitte sisuline vastuolu, mis takistaks aru saamast, kas Hankija on või ei ole esimese etapi hinna Riigihankes kindlaks määranud. 6.2.1.2. Hankija on riigihangete registri teabevahetuse kaudu Riigihankes osalemisest huvitatud isikute küsimustele vastates oma tahet samuti korduvalt selgitanud: - 18.04.2023 sõnum 734798, kus Hankija vastuse p-des 1 ja 4 selgitas muuhulgas, et: [---] Hangitakse arendusteenust, mille raames tuleb püsti panna ka Live-versioon (detailanalüüs 3.2.) Kutsekoja poolt tagatud serverisse. Edasised lisaarendused ja hooldustööd pärast Live-versiooni püsti minemist tasustatakse eraldi tunnihinna alusel, mida hindame ka hindamiskriteeriumite all. [---] [---] Live-versiooni all on mõeldud arenduse lõpp-produkti, mille käigus on implementeeritud kõik nõutavad süsteemi osised ning see peab olema valmis 9 kuud peale raamlepingu sõlmimist. Nimetatud info on leitav hanke üldandmetest aga lisame selle ka lepingu projekti p 13.1, muudetud projekt manuses. MVP skoop on kirjeldatud detailanalüüsi punktis 4.1. MVP-le ei ole seatud hankija poolt eraldi tähtaega ja sellekohast sisendit ootame pakkujalt. MVP 9 (13) valmimisest sõltub esimese väljamakse aeg. [---]. - 04.05.2023 sõnumis 739168 on Riigihankes osalemisest huvitatud isik ka selgelt väljendanud Hankija tahtest arusaamist, alustades küsimuse esitamist järgmise sissejuhatusega: Kuna projekti kaks esimest arendusetappi MVP + live arendus on fikseeritud 250 000 EUR hinnaga, on pakkujal siiski vaja eelarves püsimiseks vaja aru saada, milline on fikseeritud summa eest tehtavate arenduste ulatus. [---]. Asjaolu, et küsimus on küsitud pärast vaidlustuse esitamist, kuid enne vaidlustusega seotud asjaolude avalikustamist näitab, et RHAD-ist ja Hankija varasematest selgitustest oli Hankija tahe hind fikseerida mõistetav ja vastav tõlgendus RHAD-ile ei selgu esmakordselt alles vaidlustusmenetluses. Isegi juhul, kui Hankija tahe ja eesmärk oleks RHAD-ist raskesti äratuntav, ei kohusta vaidlustuskomisjon Hankijat muutma RHAD-i selliselt, et põhiarendust tuleks tellida tunnihinnaga ja seoses sellega muuta Hinnakriteeriumi proportsionaalsemaks nagu soovib vaidlustuses Vaidlustaja. 6.2.1.3. Vaidlustaja väitel on RHAD selles osas, kas hind on fikseeritud või mitte, omavahel vastuolus ja RHAD-i tuleb tõlgendada laiendavalt (pakkujatele soodsamalt) selliselt, et Riigihanke eseme hinda ei tohi lugeda fikseerituks. Vaidlustuskomisjon juhib tähelepanu asjaolule, et antud juhul on vaidlus riigihanke alusdokumentide staadiumis, st pakkumusi ei ole esitatud ja pakkujaid Riigihankes veel ei ole (RHS § 7 lg 1 kohaselt on pakkuja RHS-i tähenduses riigihankes hankijale pakkumuse või esialgse pakkumuse esitanud ettevõtja), ning Hankija tahte väljaselgitamine enne pakkumuste esitamist on jätkuvalt võimalik. Isegi juhul, kui RHAD võis olla enne selgituste küsimist hinna fikseerimist puudutavas osas mitmeti tõlgendatav, on Hankija hankemenetluse käigus riigihangete registri kaudu kõikidele Riigihankes osalemisest huvitatud isikutele selgitanud, et Hankija tahtele vastab RHAD-i tõlgendus, mille kohaselt põhiarendus tuleb teostada fikseeritud hinnaga. Riigihankes osalemisest huvitatud isik, kes teab seda, kuidas Hankija RHAD-i tõlgendab, ei saa seda ignoreerida ja esitada pakkumust, mis oleks Hankija tahet teadmata talle soodsam. Veelgi enam - Vaidlustaja ei ole antud juhul kuidagi põhjendanud, miks on fikseerimata hind pakkujale soodsam ja isegi kui see nii peaks olema, siis saaks see väide seonduda vaidlustatud Hinnakriteeriumi õigusvastasusega vaid juhul, kui Hankija soov saada fikseeritud hinda oleks iseenesest õigusvastane. 6.2.2. Tulenevalt asjaolust, et Hankija ei olnud eksiarvamusel väites, et põhiarendus tuleb teostada fikseeritud hinnaga ja Hinnakriteerium on antud juhul seotud vaid lisaarenduse ja hooldusetööde tellimisega (Raamlepingu p-d 2.1.1 ja 3.3), ei ole asjakohased Vaidlustaja seisukohad Hinnakriteeriumi proportsioonist ja mõjust hindamise lõpptulemusele, mistõttu Hinnakriteerium ei ole vastuolus RHS § 3 p-ga 5. 6.3. Kvaliteedikriteeriumi õiguspärasus 6.3.1. Vaidlustuse kohaselt ei ole Kvaliteedikriteerium seotud Riigihanke esemega. Vaidlustuskomisjon on seisukohal, et Vaidlustaja eksib. Kuna arendustööde metoodika ja projektiplaan esitatakse Riigihankes hangitava teenuse kohta, siis ei saa väita, et teenuse osutamise metoodika ja projektiplaani kvaliteedi hindamisega seotud Kvaliteedikriteerium ei ole seotud Riigihanke esemega. 6.3.2. Vaidlustuse kohaselt pole Kvaliteedikriteerium Riigihanke esemega seotud põhjusel, et RHAD-is puudub nõue, mille kohaselt oleks edukaks pakkuja seotud pakkumuses esitatud projektiplaaniga ja puudub tagatis, et Hankija esitab raamlepingu alusel tellimuse RHAD-is 10 (13) toodud kujul. 6.3.2.1. Vastavustingimuste kohaselt peab pakkuja pakkumuses esitama: [---] Arendustööde metoodika ja projektiplaani kvaliteedi kirjelduse, mis vastab hankija eesmärkidele ja tagab hankijale parima teenuse kvaliteedi. Esitatud kirjeldus on hindamise aluseks, mis on leitav Hindamismetoodikas. Seega Vastavustingimustest tulenevalt tuleb pakkumuses igal juhul esitada arendustööde metoodika ja projektiplaani kvaliteedi kirjeldus, st et selle esitamisest sõltub pakkumuse vastavus RHAD-ile, ja arendustööde metoodika ja projektiplaani kvaliteedi kirjelduse esitamise sisuline eesmärk on Hankijale pakkumuste hindamiseks sisendi andmine. Vaidlustaja ei ole eeltoodud vastavustingimust vaidlustanud. Kuna arendustööde metoodika ja projektiplaani kvaliteedi kirjeldus on Vastavustingimuste kohaselt osa pakkumusest, siis Kvaliteedikriteerium, mille kohaselt seda hinnatakse, on selgelt seotud pakkumuse hindamisega. Vaidlustuskomisjoni arvates ei saa arendustööde metoodika ja projektiplaani kvaliteedi kirjeldus olla kohustuslik osa pakkumusest (pakkumuse vastavusest RHAD-ile), olemata sealjuures seotud Riigihanke esemega. 6.3.2.2. HD p-s 1 on Riigihanke ese kirjeldatud järgmiselt: Eesti Oskuste Süsteemi 1. etapi tulemusel valmib keskkond, mille funktsionaalsus toimib toetudes oskuste, ametite ja tegevusalade registritele. Riigihanke eseme täpsem kirjeldus on toodud riigihanke alusdokumentides. Hanketeate (lühikirjeldus) kohaselt Oskuste kirjeldamise keskkonna arendus on jaotunud kolme faasi: 1) MVP arendus; 2) live-versioon; 3) hooldus ja lisaarendused. CPV põhikood on 72200000 Tarkvara programmeerimis- ja nõustamisteenused. Seega arendustööd on Riigihanke esemeks ja arendustööde sooritamise meetodid (metoodika) ning projektiplaan (kirjeldus) ei ole lahutatavad Riigihanke esemest. 6.3.2.3. Raamlepingu p-i 1.4 kohaselt lepingu lahutamatuteks osadeks on riigihanke alusdokumendid, täitja pakkumus, lepingu alusel sõlmitud hankelepingud, tööde üleandmise- vastuvõtmise aktid [---]. Seega täitja pakkumus, sh arendustööde metoodika ja projektiplaani kvaliteedi kirjeldus, on Raamlepingu lahutamatu osa ja puudub alus kahtlusteks, et Hankija tellib Raamlepingu alusel lõpptulemusena midagi muud kui see, mida talle pakkumuses pakuti, seda eriti olukorras, kus Hankija on TK p-i 1.3 esimeses lauses pakkujatele juba teada andnud, et valdav enamik osa planeeritavast arendusest on paigas ja kus Hankija on otsustanud esimese etapi valmimise saavutada fikseeritud hinnaga. Vaidlustuskomisjon möönab, et RHAD-ist jääb arusaamatuks, kuidas kavatseb Hankija sobitada osaliselt fikseeritud hinnaga lepingu Raamlepingu sõlmimise konteksti (RHS § 4 p-i 15 kohaselt kehtestatakse raamlepinguga lepingu kehtivusaja vältel selle alusel sõlmitavaid hankelepinguid reguleerivad tingimused ja fikseeritud hinnaga lepingu täitmiseks ei toimi Raamlepingu p-des 3.1 ja 3.2 sätestatud lepingute mehhanism), kuid nimetatud arusaamatus ei muuda Kvaliteedikriteeriumi iseenesest Riigihanke esemega mitteseotuks, ning Hankija peaks hilisemate vaidluste vältimiseks sõlmitava hankelepingu tingimusi fikseeritud maksumusega esimese etapi arendustööde osas täpsustama. 6.3.4. Tulenevalt eespooltoodust on vaidlustuskomisjon seisukohal, et Kvaliteedikriteerium iseenesest on Riigihanke esemega seotud ja vastuolu RHS § 85 lg-ga 1 puudub. Vaidlustaja väide, et Kvaliteedikriteeriumi osakaal (90%) on põhjendamatult suur seondub Vaidlustaja eksliku väitega, et Hankija hangib OIS-i arendustööde tunnihinda kogu Riigihanke mahus. Olukorras, kus Hankija on Riigihanke esimese etapi hinna RHAD-is kindlaks 11 (13) määranud, on kvalitatiivsete kriteeriumide suur osakaal vastavalt RHS § 87 lg-le 7 lubatav. 7. Tehniline kirjeldus (TK p 1.3) ja Nõuded meeskonnale Vaidlustuse kohaselt on TK p 1.3, mis sätestab, et arenduse peamine tehnoloogiline lahendus on Front-End – React.js, Back-End – Node.js ja API – REST vastuolus RHS § 88 lg-ga 6 ning HD p-s 8.1 sätestatu, mille kohaselt iga viidet, mille hankija teeb riigihanke alusdokumentides ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“, on formaalne ega kõrvalda vastuolu. Samal põhjendusel on vaidlustuse kohaselt õigusvastased ka Vastavustingimused, osas, milles need sätestatavad meeskonnale esitatavate nõuete hulgas Rect.js ja Node.js nõuded. Vaidlustuskomisjon selgitab, et Vastavustingimustes iseenesest sellist nõuet ei ole, kuid need on RHAD-i dokumendi Nõuded meeskonnale (edaspidi Nõuded meeskonnale) p-s 1, millele viidatakse Vastavustingimuste punktis Meeskonna nõuded. 7.1. Hankija võib RHS § 88 lg-le 7 tugineda juhul, kui hankija soovib objektiivsetel põhjustel saada mingisuguste konkreetsete omadustega asja/teenust/ehitustööd ning hankija põhjendatud vajadustele ei vasta muud turul olevad (samaväärsed) lahendused, st tehnilises kirjelduses on algusest peale esitatud nõudeid, mis piiravad konkurentsi ja mille sisaldumisega tehnilises kirjelduses peavad pakkujad pakkumuse esitamisel arvestama. Antud juhul puudub vaidlus, et Hankija ei ole soovinud kehtestada TK p-i 1.3 RHS § 88 lg 7 alusel algusest peale konkurentsi piiravana. 7.2. RHS § 88 lg 6 kohaselt tehnilistes kirjeldustes ei nimetata kindlat ostuallikat, protsessi, kaubamärki, patenti, tüüpi, päritolu ega tootmisviisi, mis võiks anda mõnele ettevõtjale või tootele eeliseid teiste ees või nende osaluse välistada. See keeld ei kehti juhul, kui see on hankelepingu esemest tulenevalt vältimatult vajalik põhjusel, et tehnilise kirjelduse koostamine käesoleva paragrahvi lõigetes 1 ja 2 sätestatud alustel ei võimalda hankelepingu eset piisavalt täpselt ja mõistetavalt kirjeldada. Sellisele viitele lisatakse märge „või sellega samaväärne”. Seega üldreegel keelab TK-s kindla ostuallika, protsessi, kaubamärgi, patendi, tüübi, päritolu või tootmisviisi nimetamise, kuid sellest on lubatud kõrvale kalduda, kui kumulatiivselt on täidetud kaks tingimust: 1) see on hankelepingu esemest tulenevalt vältimatult vajalik põhjusel, et tehnilise kirjelduse koostamine RHS § 88 lg-des 1 ja 2 sätestatud alustel ei võimalda hankelepingu eset piisavalt täpselt ja mõistetavalt kirjeldada ja 2) sellisele viitele lisatakse märge „või sellega samaväärne”. Vaidlustuskomisjon on seisukohal, et üksnes HD p 8.1 ja Hankija kinnitused samaväärsete tehniliste lahenduste lubatavuse kohta RHS § 88 lg 6 koosseisu ei täida. 7.3. Hankija peamine argument vaidlustusmenetluses on, et samaväärse lahenduse pakkumine on lubatav, kuna HD p 8.1 võimaldab pakkuda sellega samaväärset. Vaidlustuskomisjon on seisukohal, et kui hankelepingu eset on võimalik piisavalt täpselt ja üheselt mõistetavalt kirjeldada, on kindla ostuallika, protsessi, kaubamärgi, patendi, tüübi, päritolu või tootmisviisi, mis võiks anda mõnele ettevõtjale või tootele eeliseid teiste ees või nende osaluse välistada, nimetamine RHAD-is keelatud ka juhul, kui sellele on lisatud „või sellega samaväärne“. Seega RHS § 88 lg 6 koosseisu täitmiseks pidi Hankija hiljemalt vaidlustusmenetluses esitama põhjused, miks antud juhul ei ole ilma konkreetseid tehnoloogilisi lahendusi nimetamata võimalik hankelepingu eset piisavalt täpselt ja mõistetavalt kirjeldada. Hankija ei ole seda teinud. Vaidlustuskomisjon juhib tähelepanu asjaolule, et Hankija on ise vastuses vaidlustusele 12 (13) sedastanud, et Hankija aktsepteerib kõiki programmeerimiskeeli ja tehnilisi lahendusi, mis võimaldavad Hankija jaoks saavutada detailanalüüsis kirjeldatud tulemust, millest vaidlustuskomisjon saab aru selliselt, et Hankija on enda arvates suutnud RHAD-is kirjeldada soovitavat tulemust, ja vaidlustuskomisjonile jääb arusaamatuks, miks on Hankija vaatamata sellele pidanud RHAD-is vajalikuks sätestada, kuidas pakkuja peaks Hankija arvates nõutava tulemuse saavutama. 7.3.1. TK p-i 1.3 kirjeldav osa on oma sõnastuses äärmiselt konkreetne (Arenduse peamine tehnoloogiline lahendus on paika pandud [---]; [---] Vastavad tehnoloogilised lahendused on valitud [---]; [---] oleme valinud Front-End lahenduse jaoks React.js; [---] oleme valinud Back- End lahenduse jaoks Node.js [---]; [---] oleme valinud REST API [---]) ja seal nimetatud lahenduse asemel „samaväärse“ kasutamine muudab kas TK p-i 1.3 kirjelduse HD p-ga 8.1 vastuolus olevaks või HD p-i 8.1 sisutühjaks: kui arenduse peamine tehnoloogiline lahendus on paika pandud, siis on see ära otsustatud (vt sõnaveeb.ee „paika panema“) ja kui vastavad tehnoloogilised lahendused on valitud, siis on kõik muu jäetud valimata. 7.3.2. Nõuded meeskonnale p 1 on sõnastatud järgmiselt: Arenduse tarkvaraline lahendus on paika pandud järgnevalt: 1 Front-End – React.js või samaväärne 1 Back-End – Node.js või samaväärne 1 API – REST või samaväärne. Vaidlustuskomisjon märgib, et kui arendustiimis peavad olema täidetud rollid Front-End arendaja, Back-End arendaja ja Projektijuht (Nõuded meeskonnale p 2), siis jääb arusaamatuks, miks on Hankija üldse meeskonnaga seotud nõuete hulgas pidanud vajalikuks sätestada seda, mis tarkvaraline lahendus TK-s on paika pandud. Vaidlustuskomisjon mõistab, et Hankija soov on, et arendaja oskaks nõutaval tasemel seda programmeerimiskeelt, millel põhinevat lahendust pakkuja Riigihankes pakub, mistõttu paika pandud tarkvaraliste lahenduste nimetamine on igal juhul ebavajalik, ebaproportsionaalne ja vastuolus RHS 3 p-ga 1 7.4. Tulenevalt eespooltoodust on vaidlustuskomisjon seisukohal, et TK p-s 1.3 esitatud selgitused konkreetsete tehniliste lahenduste valimise kohta, Hankija selgitused riigihankes osalemisest huvitatud isikutele riigihangete registris (nt sõnum 734967) ja hankija selgitused vaidlustusmenetluses näitavad üksnes Hankija eelistusi pakutava lahenduse osas, mitte seda, miks nende eelistuste nimetamine on hankelepingu esemest tulenevalt vältimatult vajalik [---], mistõttu TK p 1.3 ning Nõuded meeskonnale p 1 on vaidlustatud osas vastuolus RHS § 88 lg- ga 6 ja RHS § 3 p-dega 1 ja 2. 8. Vaidlustusmenetluse kulud Lähtudes sellest, et vaidlustus rahuldatakse RHS § 197 lg 1 p-i 5 alusel osaliselt (vaidlustuskomisjoni hinnangul jaguneb vaidlustus kahte suuremasse teemade plokki, millest rahuldati üks, st vaidlustus vaheldati 50% ulatuses), kuulub vaidlustusmenetluse kulude osas kohaldamisele RHS § 198 lg 3. Hankija ega Vaidlustaja ei taotlenud lepingulise esindaja kulude väljamõistmist. Vaidlustajale tuleb Hankijalt välja mõista tasutud riigilõiv proportsionaalselt vaidlustuse rahuldamisega summas 320 eurot. (allkirjastatud digitaalselt) Angelika Timusk 13 (13)