Hankija vastus

Vaidlustaja: Net Group OÜ Registrikood: 10585438 Aadress: A. H. Tammsaaretee 92, 13423 Tallinn Esindaja: Vandeadvokaat Keidi Kõiv Advokaadibüroo RASK Rotermanni 8, 10111 Tallinn tel: 618 0820, faks: 618 0821 e-post: [email protected] Hankija: Tervise ja Heaolu Infosüsteemide Keskus Registrikood: 70009770 Pärnu mnt 132, 11317 Tallinn Hankija esindaja: Kerli Lubja, e-post: [email protected] Vastus Net Group OÜ vaidlustusele riigihankes Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd, viitenumbriga 280265 Järgnevas seisukohas esitatud põhjendustel taotleb hankija: 1. Jätta vaidlustus rahuldamata. 2. Jätta vaidlustaja menetluskulud tema enda kanda. I Asjaolud 1.1. Tervise ja Heaolu Infosüsteemide Keskus (edaspidi: hankija) avaldas 31.05.2024 riigihangete registris riigihanke „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ (viitenumber 280265). Pakkumuste esitamise tähtajaks 10.07.2024 esitati hankes kokku kaksteist pakkumust.  1.2. Hankija tegi riigihankes otsused 08.08.2024, mille tunnistas aga 15.08.2024 otsusega riigihangete seaduse (edaspidi: RHS) § 73 lg 3 punkti 6 alusel kehtetuks. Kehtima jäi 15.08.2024 otsuse alusel 08.08.2024 vastavusotsus. 1.3. Hankija viis läbi pakkumuste hindamise kontrolli ja langetas 27.08.2024 otsused pakkujate edukaks tunnistamise, kvalifitseerimise ja kõrvaldamata jätmise osas, millest teavitati pakkujatele samal päeval riigihangete registri (edaspidi: RHR) vahendusel. 1.4. Vaidlustaja esitas 06.09.2024 riigihangete vaidlustuskomisjonile hankija 27.08.2024 otsustele vaidlustuse, kuna leiab, et hankija on eksinud vaidlustaja pakkumusele hindepunkti määramisel hindamiskriteeriumis nr 5.2 ning sellest tulenevalt ka edukate pakkujate otsustamisel. Hankija vaidlustaja hinnanguga ei nõustu ja esitab järgnevalt omapoolsed põhjendused. II Hankija otsuse õiguslik alus 1.5. RHS § 117 lõike 1 alusel hindab hankija vastavaks tunnistatud pakkumusi vastavalt riigihanke alusdokumentides nimetatud pakkumuste hindamise kriteeriumidele antud suhtelisele osakaalule. Hankija tunnistab põhjendatud kirjaliku otsusega edukaks pakkumuste hindamise kriteeriumide kohaselt majanduslikult soodsaima pakkumuse. 1.6. Kehtiva riigihanke alusdokumendi „Proovitöö_uuendatud 1806“ (edaspidi: proovitöö) punkt 2.4.5.1 näeb ette järgmist: „Protsessi juhtimiseks tuleb kasutada Zeebe töövoojuhtimise mootorit. https://github.com/camunda/zeebe“. 1.7. Kehtiva riigihanke alusdokumendi „Hindamismetoodika 1706“ (edaspidi: hindamismetoodika) kriteerium 5.2 „Kasutatud tehnoloogiad (TEHIK IT Profiil)“ osas on hankija määranud, et pakkumusele omistatakse kriteeriumi osas punktid järgmiselt: 1.7.1. 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.7.2. 1 punkt, kui proovitöö lahendus vastab järgmistele tingimustele: „Alternatiivsete tehnoloogiate kasutamise korral ei ole arusaadavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid.“ 1.8. Kehtiva riigihanke alusdokumendi „TK Lisa 4 - IT-profiil“ (edaspidi IT profiil), millele viitab hindamismetoodika punkt 5.2, näeb gRPC integratsiooni puhul ette, et tehnoloogia kasutamine „tuleb TEHIKu arhitektiga kooskõlastada“ (viidatud alusdokumendi lk 2). III Hankija põhjendused 1.9. Vaidlustaja hinnangul on pakkumuses arvestatud hindamismetoodika kriteeriumi 5.2 puhul tellija tehnoloogiatega ja ühtlasi ka esitatud üheselt mõistetav põhjendus teiste tehnoloogiate valiku kohta, mis peab vaidlustaja arvates tooma kaasa kriteeriumi osas kõrgema punktiskoori määramise. Hankija leiab, et pakkuja ei ole arvestanud kriteeriumi 5.2 osas hindamismetoodika tervikliku kirjeldusega, IT-profiilis toodud täieliku selgitusega ega vasta proovitöös hindamismetoodika kriteeriumile selliselt, mis võimaldaks määrata kriteeriumi osas pakkujale kõrgema punktiskoori. Hankija hinnangul on vaidlustus põhjendamatu ega kuulu rahuldamisele. 1.10.Arusaadavuse huvides soovib hankija esmalt välja tuua järgmised faktid. 1.10.1. Proovitöö punkti 2.4.5.1 kohaselt oli kohustuslik proovitöös kasutada protsessi juhtimiseks Zeebe töövoojuhtimise mootorit. Sama tuleneb ka IT profiilist, kus on ainsa eelistatud protsessimootorina välja toodud Zeebe. 1.10.2. 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. Riigihanke alusdokumentides 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 pakkuja puudus alternatiiv ja ainuvõimalik viis lahenduse loomiseks oli Zeebe pakutava klienditeek, ei vasta tõele. 1.10.3. Kui pakkuja soovis kasutusele võtta just Zeebe pakutava klienditeegi, mis oli üks võimalik alternatiiv, tuli pakkujal arvestada, et nimetatu kasutab integratsiooniks gRPC protokolli. Nimetatud protokolli valimisel on aga hanke alusdokumentides üheselt viidatud, et hankija nõuab põhjenduse esitamist. See tuleneb nii IT profiili punktist, mille kohaselt gRPC protokolli valimine on lubatav üksnes TEHIKu arhitekti kooskõlastuse saamisel kui ka hindamismetoodika selgitusest kriteeriumi 5.2 osas, kus on ühemõtteliselt just selle tehnoloogia osas toodud esile, et põhjendus on vältimatult nõutav: (...) on üheselt mõistetavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid, näiteks protsessimootori ja teenuste vahel gPRC kasutamine.“ 1.10.4. Vaidlustaja esitatud 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 ühelgi moel kohustuslikuks määratud ei olnud. 1.11. Vaidlustaja ei ole arvestanud proovitöö lahenduse loomisel hankija tehnoloogiatega, mistõttu ei saa sel argumendil kriteeriumi 5.2 osas pakkumusele kõrgemaid punkte määrata. 1.11.1. Hankija tehnoloogiatega arvestamisel tuli lähtuda IT profiilist. Hankija on nõus, et gRPC protokoll on märgitud IT profiilis „aktsepteeritav“ tehnoloogia lahtris, kuid sellele on lisatud ühemõtteline selge 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 TEHIKu arhitekti nõusoleku saanud. IT profiili kohaselt ei ole enne nõusoleku saamist gRPC protokolli valimine aga aktsepteeritav, mistõttu ei ole sellise valiku tegemisel pakkuja hankija tehnoloogiavalikutega arvestanud. 1.11.2. Pakkujale, kes tutvus hanke alusdokumentidega, ei saanud kuidagi jääda ka ebaselgelt arvamust, et gRPC protokolli kasutamisel põhjendust esitada ei tule, kuna hankija on selle must-valgelt hindamiskriteeriumis 5.2 välja toonud: (...) on üheselt mõistetavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid, näiteks protsessimootori ja teenuste vahel gPRC kasutamine.“ Hankija hinnangul kõrvaldab hindamiskriteeriumi 5.2 terviklik lugemine mistahes kahtluse, et IT profiili alusel saanuks pakkuja gRPC protokolli kasutamist automaatselt ilma põhjenduseta vastuvõetavaks pidada. 1.11.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 aga sellist alternatiivi valinud ei ole, vaid märgib, et soovib kasutada integratsiooniks gRPC protokolli, mille osas oli põhjendamine nõutav. Seega ei saanud hankija pakkujale hindamiskriteeriumis 5.2 määrata kõrgemaid hindepunkte. 1.12. Vaidlustaja ei ole proovitöös põhjendanud, miks on kasutanud teisi tehnoloogiaid, näiteks protsessimootori ja teenuste vahel gPRC kasutamine, mistõttu ei saa ka sel argumendil kriteeriumi 5.2 osas pakkumusele kõrgemaid punkte määrata. 1.12.1. Vaidlustuses on esitatud väide, et proovitöö README failis on esitatud pakkuja poolt põhjendus gRPC protokolli valimise osas, kuid see ei vasta tõele. Põhjendust konkreetse tehnoloogia valimise osas proovitöö lahenduses esitatud ei ole, mistõttu ei ole hankijal võimalik proovitööd kriteeriumi 5.2 osas kõrgema hindepunktiga hinnata.  1.12.2. Vaidlustuse kohaselt on põhjenduseks järgmine info proovitöö osana esitatud README failis järgmiselt: „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.“ 1.12.3. Hankija selgitab, et tegemist on üldistatud selgitusega proovitöö lahenduse kui terviku ülesehitamisel ja nimetatud lõik ei puuduta ühelgi moel otseselt just gRPC protokolli valiku argumente. Hankijal ei saa ise pakkumuse hindamisel selle osadele ei laiemat ega kitsamat tähendust omistada, kui pakkuja poolt kirja pandud on. Viidatud README faili selgituses on vaidlustaja toonud välja, miks on Zeebe protsessimootoriga liidestumiseks kasutatud sünkroonset suhtlusprotokolli asünkroonse asemel. Puudub aga põhjendus, miks on vaidlustaja otsustanud just Zeebe enda pakutavat rakendusega liidestumise klienditeeki ja sellega seotult ka gRPC protokolli kasutada. Hankija ei ole riigihanke alusdokumentides konkreetset klienditeeki sünkroonseks suhtlemiseks ette määranud. 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 aga ühelgi moel põhjendust konkreetse klienditeegi valiku ja gRPC protokolli kasutamise kohta. 1.12.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 API1 on stabiilses versioonis olemas,2 mis võimaldab võtta kasutusele erinevaid alternatiive. 1.12.5. Hankija rõhutab, et riigihanke alusdokumendis nõutud põhjendusena ei oleks piisav üksnes märkus, et "Zeebe klienditeek kasutab gRPC protokolli sisemiselt" (vaidlustuse p 2.10), isegi kui selline põhjendus proovtöös sisalduks. Selline väide kinnitab faktilist asjaolu, mis on ka hankijale teada, kuid ei sisalda taaskord põhjendust konkreetse klienditeegi ja sellega seotult ka gRPC protokolli valimise osas. 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 1 REST on arhitektuurilaad, mis kasutab olemasolevaid veebitehnoloogiaid ja -protokolle klientide ja serverite vahelises suhtluses. API võimaldab tarkvarakomponentidel omavahel suhelda. 2 Allikas kättesaadav avalikul veebilehel: https://docs.camunda.io/docs/apis-tools/zeebe-api-rest/zeebe-api- rest-overview/ (10.09.2024).  pakkumuse koosseisus esitatud asjaoludega. Hankija otsusest hankemenetluses tuleneb üheselt, et hankija hinnangul konkreetse tehnoloogia valimise põhjendust pakkumuse koosseisus ei nähtu. Hankija 27.08.2024 edukaks tunnistamise otsus vaidlustaja proovitöö hindamise osas sisaldab selgelt põhjendust: „5.2 Kasutatud tehnoloogiad 1p - Kasutusel on gRPC protokoll, kuid puudub põhjendus selle protokolli kasutamise õigustamiseks.“ (otsuse lk 10, allkirjastatud otsus on vaidlustuskomisjonile RHRi tulemdokumentide vahelehel kättesaadav). 1.13. Hankija menetluses langetatud otsuse kontrollitavuseks peab see sisaldama asjaolusid, mille alusel on pakkumus(ed) tunnistatud edukaks või viiteid dokumendile, kus on põhjendused edukaks tunnistamise osas toodud.3 Hankija on otsuses esitanud põhjenduse ja leiab, et see on kooskõlas nii riigihanke alusdokumentidega kui ka esitatud pakkumusega. 1.14.Hindamiskriteeriume saab ka hankija menetluses tõlgendada üksnes viisil, mis on hanke alusdokumentides sätestatud,4 hankijal lasub kohustus jääda hindamiskriteeriumi sama tõlgenduse juurde kogu hankemenetluse jooksul.5 Hankija on veendunud, et on hinnanud vaidlustaja pakkumust lähtudes avaldatud riigihanke hindamismetoodikast ja kriteeriumite selgitustest ega ole sellest kõrvale kaldunud. Hankija on kõikidele pakkumustele omistanud hindepunktid kriteeriumis 5.2 samadele põhimõtetele tuginedes ja kohelnud pakkujaid võrdselt. 1.15. Kokkuvõtvalt leiab hankija, et on teinud õiguspärase, RHS § 117 lõikega 1 kooskõlas oleva otsuse edukate pakkujate tuvastamisel ja pakkumuste hindamisel. Seetõttu puudub alus vaidlustuse rahuldamiseks ja hankija otsuste tühistamiseks. IV Menetluslikud küsimused 1.16.Hankija palub vaidlustus lahendada kirjalikus menetluses. 1.17. Hankija esindajale on määratud esindusõigus hankija hankekorra6 punkti 8.1 alusel. /allkirjastatud digitaalselt/ Kerli Lubja 3 RKHKo 3-3-1-45-12, p 29; VAKO 27.07.2018, 140-18/197708, p 21; 12.02.2019, 8-19/203288, p 9 4 TlnRKo, 3-15-2102, p 17. 5 EL C-19/00, p 43. 6 Kehtiv hankekord on kättesaadav avalikult lingilt: https://adr.rik.ee/tehik/dokument/14054385 (10.09.2024). Õigustiimi juht