Otsus

< OTSUS Vaidlustusasja number 175-24/280265 Otsuse kuupäev 07.10.2024 Vaidlustuskomisjoni liige Angelika Timusk Vaidlustus Net Group OÜ vaidlustus Tervise ja Heaolu Infosüsteemide Keskuse riigihankes „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ (viitenumber 280265) RingIT OÜ, AS-i HELMES ja Wisercat Estonia OÜ pakkumuste edukaks tunnistamise ning nende kvalifitseerimise ja kõrvaldamata jätmise otsuste kehtetuks tunnistamise nõudes Menetlusosalised Vaidlustaja, Net Group OÜ, esindaja vandeadvokaat Keidi Kõiv Hankija, Tervise ja Heaolu Infosüsteemide Keskus, esindaja Kerli Lubja Kolmas isik I, RingIT OÜ, esindaja Rando Mäeots Kolmas isik II, AS HELMES, esindaja vandeadvokaat Kadri Matteus Kolmas isik III, Wisercat Estonia OÜ, esindajad vandeadvokaat Erki Fels ja advokaat Gregor Saluveer Vaidlustuse läbivaatamine Kirjalik menetlus RESOLUTSIOON RHS § 197 lg 1 p 4 ja RHS § 198 lg-de 3 ja 8 alusel 1. Jätta Net Group OÜ vaidlustus rahuldamata. 2. Mõista Net Group OÜ-lt AS-i HELMES kasuks välja lepingulise esindaja kulud summas 1440 eurot käibemaksuta ja Wisercat Estonia OÜ kasuks välja lepinguliste esindajate kulud summas 2250 eurot käibemaksuta. 3. Jätta Net Group OÜ kulud tema enda kanda. 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. 31.05.2024 avaldas Tervise ja Heaolu Infosüsteemide Keskus (edaspidi ka Hankija) riigihangete registris avatud hankemenetlusena läbiviidava riigihanke „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ (viitenumber 280265) (edaspidi Riigihange) hanketeate ja tegi kättesaadavaks muud riigihanke alusdokumendid (edaspidi RHAD), sh Proovitöö_uuendatud 1806 (edaspidi Proovitöö), Hindamismetoodika 1706 (edaspidi Hindamismetoodika) ja TK Lisa 4 - IT-profiil (edaspidi IT-profiil). Riigihanke eesmärk on sõlmida raamleping kuni kolme pakkujaga. Pakkumuste esitamise tähtpäevaks, 10.07.2024, esitasid pakkumuse 17 pakkujat, nende hulgas Net Group OÜ, RingIT OÜ, AS HELMES ja Wisercat Estonia OÜ. 2. 27.08.2024 otsusega tunnistas Hankija edukaks RingIT OÜ, AS-i HELMES ja Wisercat Estonia OÜ pakkumused, kvalifitseeris nimetatud pakkujad ja jättis nad kõrvaldamata. 3. 06.09.2024 laekus Riigihangete vaidlustuskomisjonile (edaspidi vaidlustuskomisjon) Net Group OÜ (edaspidi ka Vaidlustaja) vaidlustus RingIT OÜ (edaspidi ka Kolmas isik I), AS-i HELMES (edaspidi ka Kolmas isik II) ja Wisercat Estonia OÜ (edaspidi ka Kolmas isik III) (edaspidi ka koos Kolmandad isikud) pakkumuste edukaks tunnistamise ja nende kvalifitseerimise ning kõrvaldamata jätmise otsustele. 4. Vaidlustuskomisjon teatas 13.09.2024 kirjaga nr 12.2-10/175 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 18.09.2024 ja neile vastamiseks 23.09.2024. Vaidlustuskomisjoni määratud esimeseks tähtpäevaks esitasid täiendava seisukoha Vaidlustaja ja Kolmas isik II ning menetluskulude nimekirja Vaidlustaja, Kolmas isik II ja Kolmas isik III. Teiseks tähtpäevaks esitasid täiendavad seisukohad Hankija, Kolmas isik II ja Kolmas isik III. Vaidlustaja esitas vastuväited Kolmanda isiku III menetluskuludele. Kolmas isik I vaidlustusmenetluses oma seisukohti ei esitanud. MENETLUSOSALISTE PÕHJENDUSED 5. Vaidlustaja, Net Group OÜ, põhjendab vaidlustust järgmiselt. 5.1. Pakkumuste hindamise tulemusel omistati kõige kõrgemad hindepunktid Kolmandale isikule I (97), Kolmandale isikule II (96,74) ja Kolmandale isikule III (96,67). Vaidlustajale omistati 85,37 punkti, kusjuures hindamiskriteeriumides 3.2 ja 5.1 omistati Vaidlustajale maksimaalsed punktid, kuid hindamiskriteeriumi 5.21 eest anti 1 punkt maksimaalsest võimalikust 6-st punktist ning Hankija põhjendas seda asjaoluga, et kasutusel on gRPC protokoll, kuid puudub põhjendus selle protokolli kasutamise õigustamiseks. 5.2. Hindamiskriteeriumi 5.2 kohaselt hindas Hankija kasutatud tehnoloogiaid vastavalt IT-profiilile selliselt, et: - 6 punkti saab lahendus, millise loomisel on arvestatud tellija tehnoloogiatega või on üheselt mõistetavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid, näiteks protsessimootor ja teenuste vahel gPRC kasutamine; 1 Hindamiskriteeriumiks 5.2 nimetatakse otsuses Hindamismetoodikas sätestatud proovitöö hindamiskriteeriumi alakriteeriumi p 5.2 Kasutatud tehnoloogiad (TEHIK IT Profiil). 2 (13) - 1 punkti saab lahendus, milles alternatiivsete tehnoloogiate kasutamise korral ei ole arusaadavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid. Eeltoodust nähtuvalt nägi proovitöö Hindamismetoodika ette nõude kasutada kas Hankija poolt RHAD-is kirjeldatud tehnoloogiaid või nende mittekasutamise korral esitada põhjendused, miks selliseid tehnoloogiaid ei kasutatud. RHAD-is esitatud IT-profiil nägi ette nii eelistatud, aktsepteeritavad kui mitte valitavad süsteemid ja rakenduskihid. 5.3. Protsessimootori (Workflow Engine) osas oli ette nähtud ainsa aktsepteeritava rakenduskihina Zeebe töövoohaldussüsteem ning integratsiooni võimalused eelistatult AMQP, REST ning aktsepteeritavana GraphQL, gRPC ning SOAP. Zeebe puhul on tegemist Camunda loodud hajutatud töövoohaldussüsteemiga, mis oma olemuses pakub tööriistu keerukate protsesside haldamiseks ja jälgimiseks. Oma toimimises kasutab Zeebe aga üksnes kindlaid tehnoloogiad nagu gRPC, Protobuf, Raft konsensusalgoritm, BPNM 2.0, actor-model jms. Zeebe kasutab gRPC protokolli alates selle loomisest (09.08.2017). Kuigi Zeebe arendab täna lisaks REST API protokolli versiooni, siis ei ole see veel käesolevaks hetkeks avaldatud viimase stabiilse versiooni 8.5 alusel kasutatav selliselt, et see täidaks proovitöö eesmärki. 5.4. Olukorras, kus kasutada tuli Hankija poolt kindlaksmääratud tehnoloogiat, milline oma olemuses ühildub gRPC (Google Remote Procedure Call) suhtlusprotokolliga, milline on Hankija poolt määratud aktsepteeritavaks lahenduseks (mitte alternatiivseks või standardist erineva võimalusega nagu Hankija püüab väita), tuleb hindamiskriteeriumi sisustamisel lähtuda eeskätt kirjelduse selle osast, millise loomisel on arvestatud tellija tehnoloogiatega. Nimetatu ei nõudnud hindamiskriteeriumi järgi põhjendusi. 5.5. Vaidlustaja on arvestanud kõigi Hankija tehnoloogiatega, millised olid TEHIK IT protokollis välja toodud. Kuivõrd Zeebe puhul on käesoleval hetkel ametlikult toimivaks lahenduseks gRPC protokolli kasutamine, milline on nimetatud otsesõnu ReadMe failis ja Hankija on seda oma vastuses kinnitanud, siis on Vaidlustaja arvestanud kõigi tellija tehnoloogiatega ja ebaõige ning väär on Hankija väide nagu oleks Vaidlustaja kasutanud midagi standardist erinevat ja et Vaidlustajal oli kohustus põhjendada teiste tehnoloogiate kasutamist. 5.6. Isegi kui asuda seisukohale, et põhjendamine oli vajalik, siis on Vaidlustaja ka seda teinud. Proovitöö sisus on kirjalikult põhjendatud ja selgitatud, et kasutatud on gRPC protokolli, samuti seda, miks ei kasutatud protsessimudelites otseühendust asünkroonse sõnumivahetusega (AQMP mittekasutamine) ning selgitatud sünkroonse suhtluse kasutamist läbi Hankija poolt ettekirjutatud teegi (gRPC kasutuse põhjendus). Vastav selgitus esitati äriprotsesside mootori teenuse ReadMe failis, milles on selgitatud järgnev: Protsessimudelite disainimisel on eelistatud nö puhtaid/müravabasid ja tänu sellele abstraktsemaid ja hoomatavamaid mudeleid. Kuigi BPM notatsioon võimaldab detailselt defineerida ka asünkroonset sõnumivahetust ning sõnumite korreleerimist, on otsustatud seda käsitleda kui mudelite äriperspektiivi kontekstis ebavajalikku sisevaadet ning selle asemel on see loogika viidud käesolevasse teenusesse. Lause selgitab otseselt, miks ei ühendata protsessimudeleid AMQP-ga RabbitMQ külge vaid tehakse päringuid läbi äriprotsesside mootori teenuse ehk kasutab kliendi etteantud teeki, mis oma korda kasutab gRPC-d. 5.7. Kui Hankija oleks Vaidlustaja pakkumust õigesti hinnanud, oleks Vaidlustaja punktide koguarv kokku 97,37 punkti, mis asetaks Vaidlustaja kõige kõrgemale kohale pingereas. 5.8. 18.09.2024 täiendas Vaidlustaja oma seisukohti. 5.8.1. Hankija on oma seisukohas omistanud Vaidlustajale väiteid, mida Vaidlustaja ei ole 3 (13) esitanud. Nt väidab Hankija, et: 1) Vaidlustaja seisukohad põhinevad väitel, et pakkujal puudus alternatiiv ja ainuvõimalik viis lahenduse loomiseks oli Zeebe pakutav klienditeek; 2) Vaidlustaja on esitanud väite, et gRPC protokolli kasutamine on vältimatu. Selliseid väiteid Vaidlustaja esitanud ei ole. 5.8.2. Vaidlustaja on kasutanud proovitöö teostamisel tellija tehnoloogiaid. Hankija on kinnitanud ja rõhutanud, et protsessi juhtimine oli Proovitöö kohaselt ette nähtud vaid Zeebe töövoojuhtimise mootoriga. Lisaks on Hankija kinnitanud, et gRPC oli üks Hankija kinnitatud ja RHAD-is välja toodud klientiteegi alternatiiv. Seega ühtivad Hankija seisukohad Vaidlustaja selgitustega, et proovitöö Hindamismetoodika nägi ette nõude kasutada (a) kas Hankija poolt RHAD-is kirjeldatud tehnoloogiaid või (b) nende mittekasutamise korral esitada põhjendused, miks selliseid tehnoloogiaid ei kasutatud ning kasutati midagi muud, mis oli RHAD-is nimetamata. Sellele vaatamata väidab Hankija , et RHAD-is oli esitatud nõue, et teatavate lahenduste puhul oli sellele tuginemine lubatav üksnes TEHIK arhitekti kooskõlastuse saamisel ning püüab vältida enda poolt Hindamismetoodikas kasutatavate sõnaosade „tellija tehnoloogia“, „teisi tehnoloogiaid“, „aktsepteeritav tehnoloogia“ ja „alternatiivne tehnoloogia“ avamist ja selgitamist. Sellise käsitlusega püüab Hankija väljuda vaidlusalusest küsimusest. Hankija on sätestanud RHAD-is omal valikul kasutatava tehnoloogiaga seonduvalt 4 erinevat mõistet ja seda erinevates kontekstides. Nüüd püüab Hankija need koondada kaheks. See ei ole korrektne kahel põhjusel: 1) RHAD nägi väga konkreetselt ette tellija poolt eelistatud ja aktsepteeritud tehnoloogiad (edaspidi tellija tehnoloogia). Lisaks tellija tehnoloogiale oli sätestatud ka alternatiivne tehnoloogia (edaspidi teine tehnoloogia), mille kasutamine hinnastati Hindamismetoodika kohaselt hindepunktiga 1 ning mis ei olnud Hankija poolt RHAD-is välja toodud tellija tehnoloogia; 2) RHAD ei näinud ette TEHIK arhitekti poole pöördumise ja kinnitamise protsessi/korda, mida pakkumuse koostamise ajal teostada. Seda seetõttu, et IT-profiili (mis oli TK lisa 2) dokumendi puhul on tegemist Sotsiaalministeeriumi valitsemisala riist- ja tarkvara ning e-teenuste üldine haldamise ja arendamise infotehnoloogilise profiiliga, mis omab enim rolli siiski hankelepingu täitmise ajal. Nimetatud kinnitab Tehnilise kirjelduse p 8.3: Täitja kohustub tööde teostamisel järgima tellija arendusjuhiseid (TK lisad 2-6). Seda kinnitab ka Hankija selgitades, et Seega ei ole võimalik gRPC protokolli kasutada üheski loodavas IT lahenduses enne, kui see on TEHIKu arhitekti nõusoleku saanud. Loodav IT lahendus ei ole aga sama, mis proovitöö. Proovitöö ei näe ette arhitektiga kooskõlastamise nõuet vastavalt IT-profiilile ega viita üldse IT-profiilile. 5.8.3. Vaidlustaja on ReadMe failis esitanud ka põhjendused 5.8.3.1. Kuigi Hankija on teabevahetuses esitatud vastuses selgesõnaliselt märkinud, et Kuigi nüüd riigihanke sõnumites nimetatud põhjus („Zeebe klienditeek kasutab gRPC protokolli sisemiselt“) on piisav põhjus, ei ole see põhjendus esitatud proovitöö osana ning seda ei saa arvestada kriteeriumi täitmise osas. Sellise vastusega on Hankija andnud selge sõnumi, et tegemist on piisava põhjendusega hindamiskriteeriumi p-i 6 mõttes. Sellele vaatamata väidab Hankija, et tegelikult ei ole Hankija sellist piisavust kinnitanud. 5.8.3.2. Hankija kinnitab vaidlustusmenetluses, et kui pakkuja soovis kasutusele võtta just Zeebe pakutava klienditeegi, mis oli üks võimalik alternatiiv, siis tuli pakkujal arvestada, et nimetatu kasutab integratsiooniks gPRC protokolli. Antud vastus jaatab, et Zeebe poolt gPRC protokolli kasutamine on teadatuntud tõde ja see on piisav põhjendus. 5.8.3.3. Vaidlustaja proovitöö sisus on kirjalikult põhjendatud ja selgitatud, et kasutatud on gRPC protokolli ning miks ei kasutatud protsessimudelites otseühendust asünkroonse sõnumivahetusega (AQMP mitte-kasutamine) ning selgitatud sünkroonse suhtluse kasutamist 4 (13) läbi Hankija poolt ettekirjutatud teegi (gRPC kasutuse põhjendus). Proovitöös on selgitatud, miks ei ühendata protsessimudeleid AMQP-ga RabbitMQ külge vaid tehakse päringuid läbi äriprotsesside mootori teenuse ehk kasutatakse kliendi etteantud teeki, mis omakorda kasutab gRPC-d. Java teenuses on gRPC protokolli kasutamine vältimatu, sest Zeebe'il puuduvad alternatiivsed liidesed (nt REST) protsessimudelitega vajalikul moel suhtlemiseks. 6. Hankija, Tervise ja Heaolu Infosüsteemide Keskus, vaidleb vaidlustusele vastu. 6.1. Proovitöö p 2.4.5.1 näeb ette järgmist: Protsessi juhtimiseks tuleb kasutada Zeebe töövoojuhtimise mootorit. https://github.com/camunda/zeebe. Hindamiskriteeriumi 5.2 Kasutatud tehnoloogiad (TEHIK IT Profiil) osas on Hankija määranud, et pakkumusele omistatakse punktid järgmiselt: - 6 punkti, kui proovitöö lahendus vastab järgmistele tingimustele: Lahenduse loomisel on arvestatud tellija tehnoloogiatega või on üheselt mõistetavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid, näiteks protsessimootori ja teenuste vahel gPRC kasutamine. - 1 punkt, kui proovitöö lahendus vastab järgmistele tingimustele: Alternatiivsete tehnoloogiate kasutamise korral ei ole arusaadavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid. RHAD IT-profiil, millele viitab hindamiskriteerium 5.2, näeb gRPC integratsiooni puhul ette, et tehnoloogia kasutamine tuleb TEHIKu arhitektiga kooskõlastada. 6.2. Vaidlustaja ei ole arvestanud hindamiskriteeriumi 5.2 osas Hindamismetoodika tervikliku kirjeldusega, IT-profiilis toodud täieliku selgitusega ega vasta tema proovitöö Hindamismetoodikale selliselt, et pakkumusele saaks määrata kõrgema punktiskoori. 6.2.1. Proovitöö p-i 2.4.5.1 kohaselt oli proovitöös kohustuslik kasutada protsessi juhtimiseks Zeebe töövoojuhtimise mootorit. Sama tuleneb ka IT-profiilist, kus on ainsa eelistatud protsessimootorina välja toodud Zeebe. Protsessimootori käivitamiseks tuleb seejärel teha valik Java rakendustega liidestumise klienditeegi osas. Klienditeek on arendajate poolt pakutav tarkvara pakett, mis võimaldab Zeebe protsessimootoriga liidestuda ilma, et peaks kirjutama liidestumiseks vajalikku koodi. Samas on arendajal võimalus kood ka ise kirjutada. RHAD-is ei ole Hankija määranud kohustuslikku kasutatavat klienditeeki ega määranud, et kasutada tuleks just Zeebe pakutavat klienditeeki – see valik tuli teha pakkujal proovitööd lahendades ning vajadusel esitada ka sellekohane põhjendus. Üheks võimalikuks valikuks on ka klienditeegi mitte kasutamine. Vaidlustuses esitatud väide, et pakkujal puudus alternatiiv ja ainuvõimalik viis lahenduse loomiseks oli Zeebe pakutava klienditeek, ei vasta tõele. 6.2.2. Kui pakkuja soovis kasutusele võtta just Zeebe pakutava klienditeegi, mis oli üks võimalik alternatiiv, tuli pakkujal arvestada, et see kasutab integratsiooniks gRPC protokolli. Nimetatud protokolli valimisel on aga RHAD-is üheselt viidatud, et Hankija nõuab põhjenduse esitamist. See tuleneb nii IT-profiili punktist, mille kohaselt gRPC protokolli valimine on lubatav üksnes TEHIK-u arhitekti kooskõlastuse saamisel kui ka Hindamismetoodika selgitusest hindamiskriteeriumi 5.2 osas, kus selle tehnoloogia osas on toodud esile, et põhjendus on vältimatult nõutav, et: [---] on üheselt mõistetavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid, näiteks protsessimootori ja teenuste vahel gPRC kasutamine. 6.2.3. Vaidlustaja väide, et gRPC protokolli kasutamine on vältimatu, on eksitav. Proovitöö lahenduse loomiseks oli võimalik valida ka teistsugune tehnoloogiline lahendusviis. Vaidlustaja valitud gRPC protokolli kasutamine on vältimatu üksnes sellisel juhul, kui tehnoloogiliseks lahenduseks on valitud konkreetne klienditeek, mis aga Hankija poolt kohustuslikuks määratud ei olnud. Vaidlustaja ei ole arvestanud proovitöö lahenduse loomisel Hankija tehnoloogiatega, mistõttu ei saa sel argumendil hindamiskriteeriumi 5.2 osas pakkumusele kõrgemaid punkte määrata. 5 (13) 6.2.4. Hankija tehnoloogiatega arvestamisel tuli lähtuda IT-profiilist. 6.2.4.1. Hankija on nõus, et gRPC protokoll on märgitud IT-profiilis „aktsepteeritava“ tehnoloogia lahtris, kuid sellele on lisatud ühemõtteline lisamärkus, mis ei saa IT-profiiliga tutvudes tähelepanuta jääda: Tuleb TEHIKu arhitektiga kooskõlastada. Seega ei ole võimalik gRPC protokolli kasutada üheski loodavas IT lahenduses enne, kui see on TEHIK- u arhitekti nõusoleku saanud. IT-profiili kohaselt ei ole enne nõusoleku saamist gRPC protokolli valimine aktsepteeritav, mistõttu ei ole sellise valiku tegemisel pakkuja Hankija tehnoloogiavalikutega arvestanud. 6.2.4.2. Vaidlustajale ei saanud jääda RHAD-ist arvamust, et gRPC protokolli kasutamisel põhjendust esitada ei tule, kuna Hankija on selle must-valgelt hindamiskriteeriumis 5.2 välja toonud. 6.2.4.3. Selleks, et teenida hindamiskriteeriumi 5.2 esimese alternatiivi (lahenduse loomisel on arvestatud tellija tehnoloogiatega) alusel 6 punkti, oli üheks võimaluseks arvestada Hankija etteantud tehnoloogiatega, mis oleksid lubatavad tingimusteta. Vaidlustaja oma proovitöö lahenduses sellist alternatiivi ei valinud vaid märgib, et soovib kasutada integratsiooniks gRPC protokolli, mille osas oli põhjendamine nõutav. Seega ei saanud Hankija hindamiskriteeriumis 5.2 määrata kõrgemaid hindepunkte. 6.3. Vaidlustaja ei ole proovitöös põhjendanud, miks on kasutatud teisi tehnoloogiaid, nt protsessimootori ja teenuste vahel gPRC-d, mistõttu ei saa ka sel argumendil hindamiskriteeriumi 5.2 eest pakkumusele kõrgemaid punkte määrata. Tõele ei vasta Vaidlustaja väide, et proovitöö ReadMe failis on esitatud põhjendus gRPC protokolli valimise kohta. Vaidlustaja väidab, et põhjenduseks on ReadMe failis esitatu: Protsessimudelite disainimisel on eelistatud nö puhtaid/müravabasid ja tänu sellele abstraktsemaid ja hoomatavamaid mudeleid. Kuigi BPM notatsioon võimaldab detailselt defineerida ka asünkroonset sõnumivahetust ning sõnumite korreleerimist, on otsustatud seda käsitleda kui mudelite äriperspektiivi kontekstis ebavajalikku sisevaadet ning selle asemel on see loogika viidud käesolevasse teenusesse. Hankija selgitab, et tegemist on üldistatud selgitusega proovitöö lahenduse kui terviku ülesehitamisel ja nimetatud lõik ei puuduta otseselt just gRPC protokolli valiku argumente. Viidatud ReadMe faili selgituses on Vaidlustaja toonud välja, miks on Zeebe protsessimootoriga liidestumiseks kasutatud sünkroonset suhtlusprotokolli asünkroonse asemel. Puudub põhjendus, miks on Vaidlustaja otsustanud kasutada just Zeebe enda pakutavat rakendusega liidestumise klienditeeki ja sellega seotult ka gRPC protokolli. Hankija ei ole RHAD-is konkreetset klienditeeki sünkroonseks suhtlemiseks ette määranud ja ainsaks lahendusviisiks ei olnud Zeebe pakutava klienditeegi kasutamine. Selle valiku pidi tegema Vaidlustaja proovitöö lahendamisel ja lisama vajadusel asjakohase põhjenduse. Vaidlustaja viidatud põhjendusest ei tulene põhjendust konkreetse klienditeegi valiku ja gRPC protokolli kasutamise kohta. 6.4. Vaidlustaja väidab, et Zeebe protsessimootori puhul on käesoleval hetkel ametlikult toimivaks lahenduseks üksnes gRPC protokolli kasutamine. See ei vasta tõele. Zeebe ametlik kasutusjuhend kinnitab, et REST API on stabiilses versioonis olemas. 6.5. RHAD-is nõutud põhjendusena ei oleks piisav üksnes märkus, et Zeebe klienditeek kasutab gRPC protokolli sisemiselt isegi siis, kui selline põhjendus proovtöös sisalduks. Kuivõrd sellist märkust pakkumuse osana esitatud proovitöö aga ka ei sisaldanud, ei oma see asja lahendamisel tähtsust, kuna RHS § 117 lg 1 alusel saab hankija hindamisel arvestada üksnes pakkumuse koosseisus esitatud asjaoludega. 6 (13) 6.6. Hankija esitas 23.09.2024 täiendava seisukoha. 6.6.1. Tõele ei vasta Vaidlustaja väide justkui oleks Hankija enda vastuses kinnitanud, et gRPC oli üks Hankija poolt kinnitatud ja RHAD-is välja toodud klienditeegi alternatiiv. 6.6.2. Pakkumuse koosseisus tuli esitada gPRC protokolli kasutamise korral põhjendus ja see on selgesõnaliselt RHAD-is nõutud. Kuivõrd konkreetselt gPRC protokolli kasutamise on Hankija Hindamismetoodikas selgelt välja toonud kui põhjendamist nõudva tehnoloogia valiku, ei oma tähtsust Vaidlustaja arutelud teemal, kas tegemist võiks siiski olla Hankija IT-profiilis kajastatud automaatselt aktsepteeritava tehnoloogiaga, mis oleks toonud Vaidlustajale ilma põhjendust esitamata kõrgemad hindepunktid. 6.6.3. gPRC protokolli kasutamiseks pakkumuses põhjendust esitatud ei ole. Vaidlustaja viitab lõigule pakkumusest, mis konkreetset protokolli arusaadavalt ei käsitle. See on selge juba tulenevalt asjaolust, et Vaidlustaja peab menetluses esitama täiendavaid selgitusi, kuidas vastav lõik saaks tema hinnangul olla vaidlusaluse hindamiskriteeriumiga seotud. 6.6.4. Pakkumuse koosseisus tuli esitada põhjendus selliselt, et see käsitleks gPRC protokolli valikut. Vastasel juhul selle eest pakkujale kõrgemaid hindepunkte omistada lubatav ei ole. Selline põhjendus puudub. Arvestades, et põhjenduse olemasolu või selle puudumine oli Hindamismetoodika järgi lisapunktide määramise aluseks, ei saa ühtki sellekohast hiljem esitatud täiendust arvesse võtta. 6.6.5. Vaidlustaja tõstatab küsimuse, kuidas oli Hankija IT-profiiliga arvestamise kohustusele RHAD-is viidatud. Hindamiskriteeriumi 5.2 juures oli nii viide kui ka link tellija IT-profiilile, mida tuli selles kriteeriumis arvestada tehnoloogiate valikul. Proovitöö ülesannet tulebki vaadelda koos hindamiskriteeriumi ja -metoodikaga. Sellele viitab Hankija selgelt ka riigihangete registrisse lisatud vastavustingimuses nr 2: Nõuded proovitööle on esitatud alusdokumendis „Proovitöö“ ja proovitööd hinnatakse vastavalt alusdokumendile „Hindamismetoodika“. Isegi kui Vaidlustaja mingil põhjusel ei soovinud IT-profiiliga tutvuda ja seda arvestada, on hindamiskriteeriumis 5.2 selgelt kirjas, et gPRC protokolli kasutamisel tuleb proovitöös lisada põhjendus. 6.6.6. Vaidlustaja on selgitanud, et tema hinnangul ei ole proovitöö ülesande lahendamine REST liidese abil võimalik vaid selleks tuleb kasutada gPRC protokolli. Kui see ka nõnda oleks, siis nimelt sellist põhjendust saanuks Vaidlustaja pakkumuses kasutada ning esitada enda nägemus, kuidas on proovitöö võimalik nõuetele vastavalt lahendada. Vaidlustuses esitatud argumendid ei ole Hankija otsuse vaidlustamisel asjakohased. 7. Kolmas isik II, AKTSIASELTS HELMES, vaidleb vaidlustusele vastu. 7.1. Kolmas isik II tõlgendas vaidluse all olevat hindamiskriteeriumi 5.2 samamoodi Hankijaga (ja Kolmanda isikuga III). 7.2. Vaidlust ei ole, et Vaidlustaja kasutas enda proovitöös protsessimootori ja teenuste vahel gRPC protokolli. Samuti ei saa olla vaidlust selles, et Hindamismetoodikas viidatud IT-profiilis on gRPC protokolli kasutamise osas lisatud märge, et seda võib kasutada vaid TEHIK-u arhitekti eelneval kooskõlastamisel. Juba see tähendab, et gRPC protokoll ei ole tellija tehnoloogiana automaatselt aktsepteeritav. Vaidlustaja selgitus proovitöö ReadMe failis ei kujuta endast üheselt mõistetavalt põhjendatud selgitust, et miks Vaidlustaja valis proovitöö teostamiseks gRPC protokolli. 7.3. Vaidlustaja väide, et gRPC protokolli kasutamine on vältimatu, on eksitav. Samuti nõustub 7 (13) Kolmas isik II Hankija väitega, et ReadMe faili selgituses on Vaidlustaja toonud välja, miks on Zeebe protsessimootoriga liidestumiseks kasutatud sünkroonset suhtlusprotokolli asünkroonse asemel, kuid puudub põhjendus, miks on Vaidlustaja otsustanud kasutada just Zeebe enda pakutavat rakendusega liidestumise klienditeeki ja sellega seotult ka gRPC protokolli. 7.4. Proovitööde hindamise mõte on hinnata nende kvaliteeti täpselt sellisel kujul nagu nad piiratud ajaraamis esitati. Seega ei ole võimalik arvestada Vaidlustaja poolt vaidlustusmenetluses ega isegi täiendavates selgitustes esitatud täiendavat informatsiooni, juhendeid või muid dokumente, mis sisuliselt muudaks esitatud pakkumust. Kui Hankija lubanuks Vaidlustajal selgitada proovitööga seonduvat, siis oleks Hankija sisuliselt võimaldanud selgituse küsimisega Vaidlustajal esitada uue pakkumuse ega oleks saanud objektiivselt kontrollida esitatud töö vastavust seatud nõuetele. 7.5. Kolmas isik esitas 23.09.2024 täiendava seisukoha. 7.5.1. Vaidlustaja kaldub teemast mööda, kui asub väitma, et Lisaks Tellija tehnoloogiale oli sätestatud ka alternatiivne tehnoloogia (ehk teisisõnu teine tehnoloogia) millise kasutamine hinnastati hindamismetoodika kohaselt hindepunktiga 1 ning milline ei olnud hankija poolt riigihanke alusdokumentides välja toodud „tellija tehnoloogia“ – ehk see ei olnud ei eelistatud ega aktsepteeritav tehnoloogia. Alternatiivseid tehnoloogiaid võis kasutada ja selle eest võis ka 6 punkti saada, kui see oli selgelt põhjendatud. 7.5.2. Vaidlustaja tõlgendab ebaõigelt IT-profiilis olevat arhitekti kooskõlastuse nõude väljatoomist. Ükski menetlusosalistest ei ole väitnud, et proovitöö raames oleks pidanud gRPC kooskõlastama arhitektiga, vaid viide toodi välja selleks, et täiendavalt selgitada ja põhjendada, miks ei oleks tohtinud Vaidlustaja tekkida kahtlust selles, et gRPC protokoll ei ole tellija tehnoloogia ja automaatselt aktsepteeritav. IT-profiil aitab tõlgendada hindamiskriteeriumi sisu ning keegi ei ole väitnud, et proovitöö raames oleks pidanud Vaidlustaja midagi Hankija arhitektiga kooskõlastama. 7.5.3. Vaidlustaja leiab jätkuvalt, et ReadMe-s esitatu peaks endast kujutama gRPC kasutamise üheselt mõistetavat selgitust, kuid jätkuvalt ei ütle see otseselt midagi gRPC kasutamise kohta. Esitatud tehnoloogilised põhjendused proovitöö osas ja miks see teostati sellisel viisil ei sisaldunud esialgses proovitöös ja seda ei ole võimalik otsuse järelkontrollis arvesse võtta. Isegi kui see on tehnoloogiliselt täpne ja õige, ei omaks see tähendust, sest vaidlust ei olegi selles, kas gRPC protokolli võis kasutada (võis) vaid selles, kas see oli üheselt mõistetavalt põhjendatud. 7.5.4. Vaidlustaja üritab tõendada asjaolu, mida ei ole vaja tõendada – kas ja mil moel sai tehnoloogiliselt proovitööd lahendada. Vaidlustajal on vaja tõendada vaid ühte asja – kas proovitöös oli üheselt mõistetavalt põhjendatud gRPC protokolli kasutamine ning seda ei ole Vaidlustaja tõendanud. 8. Kolmas isik III, Wisercat Estonia OÜ, vaidleb vaidlustusele vastu. 8.1. Vaidlustaja sai hindamiskriteeriumis 5.2 ühe punkti, kuna ei ole gRPC kui alternatiivse tehnoloogia kasutamist proovitöös põhjendanud. Tõele ei vasta Vaidlustaja väited, et ta ei pidanudki gRPC kasutamist põhjendama ega ka see, et ta on gRPC kasutamist põhjendanud. 8.2. gRPC kasutamist pidi põhjendama 8.2.1. Enamik vaidlustusest põhineb arutlustel, kas gRPC kvalifitseerub tellija tehnoloogiaks, mille kasutamist ei pidanud põhjendama, või teiseks tehnoloogiaks, mida pidi põhjendama. 8 (13) Hindamiskriteeriumis 5.2 on näitena teisest tehnoloogiast toodud just nimelt gRPC kasutamine protsessimootori ja teenuste vahel. 8.2.2. Vaidlustaja on asunud analüüsima IT-profiili, kuid on jätnud tähelepanuta selle lauseosa hindamiskriteeriumis 5.2, mis annab küsimusele ühemõttelise vastuse. See, et gRPC kasutamist tuleb põhjendada, tuleneb Hindamismetoodikast. 8.2.3. Vaidlustaja väited, et gRPC kvalifitseerub tellija tehnoloogiaks, on ka sisuliselt ebaõiged. Hankija IT-profiilis on gRPC kohta kirjutatud, et selle kasutamine tuleb TEHIKu arhitektiga kooskõlastada. See, et vajalik on kooskõlastus, viitabki, et gRPC ei ole tellija tehnoloogia. Seda kinnitab ka Proovitöö p 2.4.4, milles on kirjutatud, et teenuste omavaheliseks suhtlemiseks kasutatakse RabbitMQ sõnumivahendaja tarkvara, mis on ka täna kasutusel: Teenuste omavaheliseks suhtlemiseks kasutatakse RabbitMQ lahendust (p 2.4.4.1); RabbitMQ on täna kasutusel oleva süsteemi sõnumivahetusena (p 2.4.4.2). IT-profiilist on näha, et RabbitMQ sõnumivahendaja külge ühendatakse AMQP suhtlusprotokoll, mitte gRPC suhtlusprotokoll. 8.2.4. Kui Vaidlustaja pidas gRPC kasutamise põhjendamise kohustust õigusvastaseks või oli (ebaõigel) arvamusel, et gRPC kvalifitseerub Hankija tehnoloogiaks, oleks ta pidanud hindamiskriteeriumi 5.2 vaidlustama. 8.3. Vaidlustaja ei ole gRPC kasutamist põhjendanud 8.3.1. Vaidlustaja viitab järgmisele äriprotsesside mootori teenuse ReadMe failis esitatud lõigule: Protsessimudelite disainimisel on eelistatud nö puhtaid/müravabasid ja tänu sellele abstraktsemaid ja hoomatavamaid mudeleid. Kuigi BPM notatsioon võimaldab detailselt defineerida ka asünkroonset sõnumivahetust ning sõnumite korreleerimist, on otsustatud seda käsitleda kui mudelite äriperspektiivi kontekstis ebavajalikku sisevaadet ning selle asemel on see loogika viidud käesolevasse teenusesse. Selle lõigu esimene lause ei ole põhjendus gRPC kasutamise kohta – gRPC on sõnumivahetuse protokoll, esimene lause räägib aga protsessimudelitest. Need pole omavahel seotud. Asünkroonne sõnumivahetus, millele Vaidlustaja viitab, on AMQP suhtlusprotokoll, mis on praegu tellijal kasutusel. Kuigi lõigu teine lause on ka IT-alasele inimesele segane, ütleb Vaidlustaja sisuliselt, et kuigi oleks võimalik kasutada tellija praegust tehnoloogiat, on see ebavajalik. 8.3.2. Hindamiskriteerium 5.2 nõudis üheselt mõistetavat põhjendust, miks on kasutatud teisi tehnoloogiaid. Väide, et tellija tehnoloogia ei ole vajalik, ei ole sisuline põhjendus. Üheselt mõistetav põhjendus oleks see, kui Vaidlustaja oleks selgitanud, miks ei ole tellija tehnoloogia vajalik. Niisuguseid põhjendusi ei ole esitatud. On tõenäoline, et äriprotsesside mootori teenuse ReadMe failist leitud põhjendus on kontekstistvälja rebitud ja tegelikult ei olegi Vaidlustaja sellega üritanud põhjendada gRPC kasutamist. 8.3.3. Vaidlustaja väidab, et kuna Zeebe klienditeegiga ei saagi kasutada muud protokolli, kui gRPC-d, siis oleks põhjenduse esitamine olnud tarbetu. See väide on vale juba seetõttu, et sellisel juhul oleksid ka kõik teised pakkujad pidanud kasutama gRPC protokolli, mida aga tehtud ei ole. Samuti ei oleks Hankija pidanud eristama hindamiskriteeriumis 5.2 tellija tehnoloogiat, mille kasutamist ei pea põhjendama, ja teisi tehnoloogiaid, mille kasutamist pidi. Tõele vastab, et Java klienditeek kasutab gRPC-d, kuid Vaidlustaja ei olnud kohustatud kasutama Java klienditeeki. 8.3.4. Proovitöös on kohustuslik kasutada Zeebe protsessimootorit, kuid proovitöös pole ühtegi ettekirjutust selle protsessimootoriga suhtlemise osas. Zeebe poolt pakutav Java klienditeegi 9 (13) kasutamine pole nõutud. Zeebe ametliku Java klienditeegi poolt kasutusel olev gRPC protokoll on proovitöös lubatud koos põhjendusega, aga Vaidlustaja proovitöös on puudu põhjendus selle protokolli kasutamiseks. 8.4. Kolmas isik III esitas 23.09.2024 täiendava seisukoha. 8.4.1. Vaidlustaja väidab jätkuvalt, et on kasutanud proovitöös tellija tehnoloogiat, mille tõttu ei pidanud ta proovitöös gRPC suhtlusprotokolli kasutamist põhjendama. Kolmas isik III sellega ei nõustu. Vaidlustaja on eiranud hindamiskriteeriumi 5.2 sõnastust ning analüüsib vaid IT-profiili. Kuigi IT-profiilist tuleneb samamoodi, et gRPC ei ole tellija tehnoloogia, ei ole IT-profiili analüüs vaidlusalusele küsimusele vastamisel oluline. Olukorras, kus RHAD annab ühemõttelise vastuse, et gRPC kasutamist tuleb proovitöös põhjendada, pidi põhjenduse esitama olenemata pakkuja arusaamast, milliseks tehnoloogiaks gRPC kvalifitseerub. 8.4.2. Vaidlustaja on eiranud Proovitöö p-i 2.4.4, milles on kirjas, et tellijal on täna kasutusel RabbitMQ tarkvara, mis kasutab omakorda AMQP protokolli (mitte alternatiivset gRPC protokolli), samuti Proovitöö lk-l 5 esitatud paigaldusvaadet, milles toimub suhtlus protsessimootori ja teenuste vahel AMQP protokolliga. Kuna RHAD annab vaidlusalusele küsimusele selge vastuse, puudub põhjus analüüsida IT-profiili. Ainuüksi sellest, et IT-profiilis on gRPC protokoll nimetatud „aktsepteeritava tehnoloogiana“, ei tulene, et tegemist on tellija tehnoloogiaga. 8.4.3. Vaidlustaja väide, et gRPC kasutamise kohta on proovitöös põhjendus esitatud, on tagantjärele otsitud. ReadMe failis esitatud lause on ebaselge ega sisalda hindamiskriteeriumile 5.2 vastavat „üheselt mõistetavat“ põhjendust. Ühe punkti võis anda ka siis, kui põhjendus ei ole arusaadav. Juba asjaolu, et Vaidlustaja on pidanud vaidlustusmenetluses selgitama, mida viidatud lausega on mõeldud, näitab, et põhjendus ei olnud üheselt mõistetav. 8.4.4. Vaidlustaja vaidlustusmenetluses esitatud põhjendus ei ole sama, mille ta väidetavalt esitas proovitöös. Vaidlustuses tõi Vaidlustaja põhjenduseks gRPC kasutamise kohta selle, et Zeebe poolt pakutav Java klienditeek kasutab gRPC suhtlusprotokolli (see ei tähenda, et gRPC kasutamine oli ainuvõimalik). Kui Vaidlustaja tegelikult arvaks, et proovitöös oli põhjendus esitatud, oleks ta vaidlustuses jäänud sama põhjenduse juurde. 8.4.5. Vaidlustaja väitel seisneb gRPC protokolli kasutamine Zeebe klienditeegi siseses suhtluses, mis oli ühtlasi ainuvõimalik lahendus. Vaidlustaja eksib. Kolmas isik III ei pea tõenäoliseks, et Vaidlustaja proovitöös seisneb gRPC protokolli kasutamine vaid Zeebe klienditeegi siseses suhtluses. Kui oleks nii, ei oleks Vaidlustaja vastanud Hankija päringule: Lause selgitab otseselt, miks ei ühendata protsessimudeleid AMQP-ga RabbitMQ külge, vaid tehakse päringuid läbi äriprotsesside mootori teenuse ehk kasutab kliendi etteantud teeki, mis oma korda kasutab gRPC-d. Isegi kui Vaidlustaja kasutas gRPC protokolli ainult Zeebe klienditeegi siseses suhtluses, ei vasta tõele väide, et see oli ainuvõimalik lahendus. Zeebe Java klienditeek kasutab gRPC-d, kuid Vaidlustaja ei olnud kohustatud kasutama Java klienditeeki. VAIDLUSTUSKOMISJONI PÕHJENDUSED 9. Puudub vaidlus, et juhul, kui Hankija on omistanud Vaidlustaja pakkumusele hindamiskriteeriumi 5.2 alusel punkte valesti (6 punkti asemel 1), oleks Vaidlustaja hindamiskriteeriumide kohaselt üks kolmest pakkujast, kellega Hankija sõlmiks Riigihanke tulemusel raamlepingu. Veelgi enam - Vaidlustaja oleks pakkuja, kelle poole Hankija pöörduks tööde tellimiseks esimesena (raamlepingu projekti p 6.2.1: Tellija esitab tellimuse riigihankes 10 (13) parima pakkumuse teinud raamlepingu täitjale [---]). Seega on Vaidlustajal huvi Kolmandate isikute pakkumuste edukaks tunnistamise otsuste kehtetuks tunnistamiseks selleks, et saavutada Riigihankes lõpptulemusel parima pakkumuse teinud raamlepingu täitja positsioon . 10. Vaidlustuskomisjon peab vaidlustatud otsuse õiguspärasuse kontrollimiseks kontrollima, kas Vaidlustaja pakkumuse hindamine toimus RHAD-is teatavaks tehtud hindamise kriteeriumide kohaselt (vastavalt RHS § 117 lg-le 1) ja kas Hankija põhjendustest nähtuvalt on hindepunktide omistamine pakkumusele põhjendatud. Vaidlust ei ole Kolmandate isikute pakkumustele hindepunktide omistamises. 11. Hankija edukaks tunnistamise otsusest nähtuvalt on Vaidlustaja pakkumusele omistatud hindamiskriteeriumi 5.2 alusel 1 punkt järgmise põhjendusega: Kasutusel on gRPC protokoll, kuid puudub põhjendus selle protokolli kasutamise õigustamiseks. Ei saa olla vaidlust, et Vaidlustaja proovitöös on kasutusel gRPC protokoll. Seega Hankija otsus on õigusvastane ja hindamiskriteeriumi 5.2 alusel 1 punkti omistamine Vaidlustaja proovitööle on vale, kui: 1) põhjendust, miks on lahenduse loomisel kasutatud gRPC protokolli, pakkumuse hindamiseks pakkumuses esitama ei pidanud või 2) üheselt mõistetavad põhjendused, miks on gRPC protokolli lahenduse loomisel kasutatud, on pakkumuses esitatud. 11.1. Hindamiskriteerium 5.2 on Hindamismetoodikas sätestatud järgmiselt: Kriteerium 6 1 5.2 Kasutatud Lahenduse loomisel on arvestatud Alternatiivsete tehnoloogiate tehnoloogiad tellija tehnoloogiatega või on üheselt kasutamise korral ei ole (TEHIK IT mõistetavalt põhjendatud, miks on arusaadavalt põhjendatud, miks on Profiil) kasutatud teisi tehnoloogiaid, näiteks kasutatud teisi tehnoloogiaid. protsessimootori ja teenuste vahel gPRC kasutamine. 11.1.1. Vaidlustuskomisjon märgib esmalt, et Hankija on hindamiskriteeriumis 5.2 teinud ilmse vea, kasutades näites lühendit gPRC, mis ei ole teadaolevalt ühegi tehnoloogia või protokolli nimi, lühendi gRPC (Google Remote Procedure Call) asemel, mis on laialdaselt kasutatav avatud lähtekoodiga protokoll (millele viitab ka nt IT-profiil). Hankija kasutab lühendeid läbisegi samatähenduslikena ka vaidlustusmenetluses. See selgelt äratuntav ja ilmne viga iseenesest ei ole viinud Hankijat vale otsuseni. 11.1.2. Vaidlustuskomisjon möönab, et hindamiskriteeriumist 5.2 endast ei nähtu, mis on tellija tehnoloogia, kuid sealt nähtub üks tehnoloogia, mis seda hindamiskriteeriumi mõttes kindlasti ei ole: näiteks protsessimootori ja teenuste vahel gRPC kasutamine. Hankija poolt hindamiskriteeriumis toodud näide ilmestab üksnes ja ainult teist tehnoloogiat, mille kasutamisel lahenduse loomisel oli maksimaalsete hindepunktide saamiseks kohustuslik kasutatava tehnoloogia üheselt mõistetav põhjendamine. Seega vaidlustuskomisjon on seisukohal, et hindamiskriteerium 5.2 on RHAD-is sõnastatud selgelt ja üheselt mõistetavalt selliselt, et lahenduse loomisel gRPC kasutamine on käsitletav teise tehnoloogia kasutamisena, millisel juhul omistatakse 6 punkti pakkuja proovitööle üksnes juhul, kui pakkumuses on üheselt mõistetavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid. Seega vaidlustuskomisjon on seisukohal, et vastavalt RHS § 117 lg-le 1 on pakkujatele RHAD-is tehtud teatavaks hindamiskriteerium, mille kohaselt gRPC protokolli kasutamist lahenduse loomisel pidi maksimaalsete hindepunktide saamiseks põhjendama. 11 (13) 11.1.3. Vaidlustuskomisjon jätab vaidluses hindamiskriteeriumi 5.2 kohaldamise kontekstis tähelepanuta kõiki Vaidlustaja väiteid, mille eesmärk on veenda Hankijat ja vaidlustuskomisjoni selles, et vaatamata hindamiskriteeriumis 5.2 esitatud näitele teisest tehnoloogiast (gRPC) on gRPC ikkagi tellija tehnoloogia, mille kasutamise põhjendusi proovitöös üldse esitama ei pidanud. 11.2. Vaidlustaja väidab, et isegi kui põhjendamine oli vajalik, siis on Vaidlustaja nõuetekohase selgituse esitanud äriprotsesside mootori teenuse ReadMe failis, järgnevalt: Protsessimudelite disainimisel on eelistatud nö puhtaid/müravabasid ja tänu sellele abstraktsemaid ja hoomatavamaid mudeleid. Kuigi BPM notatsioon võimaldab detailselt defineerida ka asünkroonset sõnumivahetust ning sõnumite korreleerimist, on otsustatud seda käsitleda kui mudelite äriperspektiivi kontekstis ebavajalikku sisevaadet ning selle asemel on see loogika viidud käesolevasse teenusesse. Vaidlustuskomisjon nõustub Hankija ja Kolmandate isikutega II ja III, et eespooltoodu ei ole põhjendus, mis üheselt mõistetavalt põhjendab, miks on Vaidlustaja lahenduse loomisel kasutatud teisi tehnoloogiaid, antud juhul gRPC protokolli. ReadMe failis on esitatud selgitus otsuse kohta mitte modelleerida asünkroonset sõnumivahetust ja sõnumite korreleerimist otse BPM mudelites, kuid see ei põhjenda, miks on selleks valitud just gRPC protokoll. Kuna antud juhul ei nähtu ka viidatud selgitusest üheselt mõistetavat vastust Hankija püstitatud küsimusele miks on kasutatud teisi tehnoloogiaid, antud juhul gRPC-d, on Hankija jätnud õigesti Vaidlustaja proovitööle hindamiskriteeriumi 5.2 alusel 6 hindepunkti omistama. Kui alternatiivsete tehnoloogiate kasutamise korral ei ole arusaadavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid, omistatakse Hindamismetoodika ja hindamiskriteeriumi 5.2 kohaselt proovitööle 1 punkt ja seda ongi Hankija teinud. 11.3. Tulenevalt eespooltoodust on vaidlustuskomisjon seisukohal, et Hankija on Vaidlustaja pakkumusele (proovitööle) hindamiskriteeriumi 5.2 eest omistanud õigesti ja põhjendatult 1 hindepunkti, mistõttu Hankija otsus Kolmandate isikute pakkumuste edukaks tunnistamise kohta on kooskõlas RHS § 117 lg-ga 1 ja RHS § 3 p-iga 1 (läbipaistev ja kontrollitav) ning selle kehtetuks tunnistamiseks alused puuduvad. 12. Kolmandate isikute kõrvaldamata jätmise ja kvalifitseerimise otsused Vaidlustusest nähtuvalt on sisulised põhjendused esitatud Kolmandate isikute pakkumuse edukaks tunnistamise otsusele (täpsemalt Vaidlustaja pakkumuse hindamisele) ja Kolmandate isikute kvalifitseerimise ja kõrvaldamata jätmise otsused on vaidlustatud vaid tulenevalt otsuste järgnevuse põhimõttest. Kuna vaidlustuskomisjon on seisukohal, et Hankija otsus Kolmandate isikute pakkumuste edukaks tunnistamiseks on õige (Vaidlustaja pakkumusele on hindepunkte antud õigesti), siis tuleb jätta rahuldamata ka Vaidlustaja taotlus Kolmandate isikute kõrvaldamata jätmise ja kvalifitseerimise otsuste kehtetuks tunnistamiseks. 13. Vaidlustusmenetluse kulud Lähtudes sellest, et vaidlustus jääb RHS § 197 lg 1 p-i 4 alusel rahuldamata, kuuluvad vaidlustusmenetluse kulude osas kohaldamisele RHS § 198 lg-d 3 ja 8. 13.1. Hankija ei taotlenud kulude väljamõistmist. 13.2. Kolmandatele isikutele mõistetakse kulud välja Hankijaga samade reeglite alusel. Tähtaegselt (18.09.2024 ja 23.09.2024) esitasid menetluskulude taotlused Kolmas isik II ja Kolmas isik III. 13.2.1. Kolmas isik II taotleb menetluskulude välja mõistmist kogusummas 1440 eurot (käibemaksuta) kokku 8 tunni õigusabi teenuse eest tunnihinnaga 180 eurot. 12 (13) Vaidlustuskomisjon on seisukohal, et Kolmanda isiku II kulud on vajalikud ja põhjendatud ning tuleb Vaidlustajalt välja mõista. 13.2.2. Kolmas isik III taotleb kahe esindaja kasutamisel menetluskulude välja mõistmist summas 4680 eurot (käibemaksuta) kokku 31,2 tunni õigusabi teenuse osutamise eest keskmise tunnihinnaga 150 eurot. Kolmanda isiku III kulude osas nõustub vaidlustuskomisjon Vaidlustajaga, et esitatud menetluskulude suurus ja maht ei ole põhjendatud. Kuigi Vaidlustaja on paisutanud hindamiskriteeriumi 5.2 kohaldamise kontekstis ebavajalikult vaidlustusasja mahtu tehniliste küsimustega ja mõistetav on Kolmanda isiku III soov nendele vastata, siis vaatamata sellele ei olnud asi kogumis tavapäraselt keerukam ega mahukam, mistõttu vaidlustuskomisjoni hinnangul oleks piisanud ühe professionaalse esindaja kasutamisest kogumahus 15 tundi ning vastav õigusabi kulu summas 2250 eurot (käibemaksuta) tuleb Vaidlustajalt välja mõista. 13.3. Vaidlustaja kulud jäävad tema enda kanda. (allkirjastatud digitaalselt) Angelika Timusk 13 (13)