Vaidlustus

Riigihangete vaidlustuskomisjon Endla 13, 10122 Tallinn [email protected] 06.09.2024 VAIDLUSTUS Hankija otsuste peale riigihankes nr 280265 Vaidlustaja: Net Group OÜ Registrikood: 10585438 A. H. Tammsaaretee 92, 13423 Tallinn Vaidlustaja 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 kontaktisik Annika Rokk, e-post: [email protected] Vaidlustaja taotlused: 1. RHS § 185 lg 2 punkti 8 alusel tunnistada kehtetuks Tervise ja Heaolu Infosüsteemide Keskuse 27.08.2024 edastatud hindamisotsus osas, millega Net Group OÜ-le määrati proovitöö hindamisel hindamiskriteeriumi nr 5.2 eest 1 punkt; 2. RHS § 185 lg 2 p 7 alusel tunnistada kehtetuks Tervise ja Heaolu Infosüsteemide Keskuse 27.08.2024 edastatud edukaks tunnistamise otsus, millega otsustati riigihankes nr 280265 „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ tunnistada edukaks RingIT OÜ, AS HELMES ja Wisercat Estonia OÜ pakkumused, kui majanduslikult soodsaimad pakkumused; 3. RHS § 185 lg 2 p 4 ja 5 alusel tunnistada kehtetuks Tervise ja Heaolu Infosüsteemide Keskuse 27.08.2024 edastatud kvalifitseerimise ja kõrvaldamata jätmise otsus, millega otsustati riigihankes nr 280265 „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ jätta RingIT OÜ, AS HELMES ja Wisercat Estonia OÜ pakkumused kvalifitseerimata ja kõrvaldamata; 4. RHS § 198 lg 1 alusel mõista Tervise- ja Heaolu Infosüsteemide Keskus’elt Net Group OÜ kasuks välja lepingulise esindaja kulud ja vaidlustuse esitamisel tasutud riigilõiv. 1/6 1. 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). 1.2. Hanketeate (edaspidi HT) p. 5.1 kohaselt oli hanke esemeks leida Sotsiaalkaitse infosüsteemi (SKAIS2) arendus- ja hooldustööde raamhange, milline sõlmitakse kolme pakkujaga. Hankes esitasid pakkumused kokku kaksteist (12) pakkujat. 1.3. Esmakordselt teavitas hankija pakkujaid enda otsustest 08.08.2024, millise hindamise tulemil omistati kõige kõrgemad hindepunktid pakkujatele AS Helmes (96,74), Wisercat OÜ (96,67) ja Dolm IT OÜ (96,02) ning vaidlustajale omistati 85,37 punkti. Sealjuures toimus vaidlustaja hindepunktide vähendamine hindamiskriteeriumites nr 3.2, 5.1 ja 5.2 osas (Lisa 1). 1.4. 08.08.2024 otsuse andmise järgselt tegi vaidlustaja hankijale pöördumise, milles viitas hankija hindamise ebaõigsustele ning palus ellu viia ümberhindamine. Hankija tunnistas minetusi hindamises, tunnistas 15.08.2024 otsusega hindamise tulemused kehtetuks (Lisa 2) ning viis ellu uue hindamise, millise hindamise tulemil omistati kõige kõrgemad hindepunktid seekord pakkujatele RingIT OÜ (97), AS Helmes (96,74) ja Wisercat OÜ (96,67). Vaidlustajale omistati 85,37 punkti, kusjuures hindamiskriteeriumites 3.2 ja 5.1 omistati vaidlustajale seekordselt maksimaalsed punktid, kuid hindamiskriteeriumis 5.2 antud hindepunktid jäid samaks. Hankija määras vaidlustajale hindamiskriteeriumi 5.2 eest 1 punkti maksimaalsest võimalikust 6-st punktist ning põhjendas seda asjaoluga, et „kasutusel on gRPC protokoll, kuid puudub põhjendus selle protokolli kasutamise õigustamiseks“ (Lisa 3). 1.5. Kuivõrd vaidlustaja hankija hindamistulemusega ka punkti 5.2 osas ei saanud nõustuda, siis pöördus vaidlustaja taaskord hankija poole ja selgitas, et hankija põhjendust sellest, et gRPC protokolli kasutamine proovitöö kirjelikus sisus ei ole kirjeldatud on ekslik ning viitas asukohale, kust selgitus leitav (Lisa 4). 1.6. Nimetatule esitas hankija vastuse, milles selgitas järgmist: Rakenduse dokumentatsioonis (readme failis) on küll viidatud gRPC kasutamisele ("Java rakendus suhtleb Zeebe'iga kasutades gRPC protokolli."), aga puudu on see oluline osa: nimelt et miks seda kasutatakse. 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. 1.7. Eelnevale edastas vaidlustaja veelkordselt selgitused, milles selgitas miks vaidlustaja leiab, et hankija seisukoht on ekslik (Lisa 5). 1.8. Viidatule vastas hankija järgmist: Rõhutame, et proovitöös on kohustuslik kasutada Zeebe protsessimootorit. Proovitöös pole ühtegi ettekirjutust selle protsessimootoriga suhtlemise osas. Zeebe poolt pakutav Java klienditeegi kasutamine pole nõutud. Pakkuja oleks võinud ka ise oma kliendi arendada, sest Zeebe pakub REST API otspunkte. Samuti ei ole võimalik dokumentatsioonis pidada midagi iseenesestmõistetavaks ega selgelt tuletatavaks, kui asi puudutab nõutud standardist erinevaid suhtlusprotokolle. Zeebe ametliku Java klienditeegi poolt kasutusel olev gRPC protokoll on proovitöös lubatud koos põhjendusega, aga pakkuja proovitöös on puudu põhjendus selle protokolli kasutamiseks. Hankija ei saa siinkohal võtta iseenesestmõistetavalt asjaolu, et gRPC protokolli kasutamine on ainuke võimalus ja et proovitöö kirjelduse põhjal ei saakski ülesannet teisiti lahendada. 1.9. Nimetatule järgnevalt edastas hankija pakkujatele 27.08.2024 vastavaks ja edukaks tunnistamise otsuse (Lisa 3) ning kõrvaldamise ja kvalifitseerimise aluste otsuse (Lisa 6). 1.10. Käesolevaga esitab vaidlustaja vaidlustuse hankija 27.08.2024 koostatud otsustele. Vaidlustaja on seisukohal, et hankija on eksinud vaidlustaja pakkumusele hindepunkti määramisel hindamiskriteeriumis nr 5.2 ning sellest johtuvalt ka RingIT OÜ, AS HELMES ja Wisercat Estonia OÜ pakkumuste edukaks tunnistamisel. 2/6 2. VAIDLUSTUSE PÕHJENDUSED 2.1. Riigihankes nr 280265 on esemeks raamlepingu alusel Sotsiaalkaitse infosüsteemi (SKAIS2) arendus- ja hooldustööde teostamine. Riigihanke alusdokumendid nägid sealjuures ette, et riigihankesse laekunud pakkumuste hindamine toimub hindamiskriteeriumite alusel, milleks oli hankija ette näinud ühe töötunni hinna (25%); proovitöö hindamise (70%) ning sotsiaalselt vastutustundlike nõuete järgimise (5%). Proovitöö ülesandena tuli pakkujatel luua kolme erineva rolliga lahendus, milliste hindamine toimus vastavalt hindamismetoodikale. 2.2. Proovitöös hinnatava hindamiskriteeriumi punkti 5.2 kohaselt hindas hankija kasutatud tehnoloogiaid vastavalt TEHIK IT profiilile selliselt, et (i) „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. (ii) „1“ punkti saab lahendus, milles alternatiivsete tehnoloogiate kasutamise korral ei ole arusaadavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid. 2.3. Eeltoodust nähtuvalt nägi proovitöö hindamismetoodika ette nõude kasutada (a) kas hankija poolt riigihanke alusdokumentides kirjeldatud tehnoloogiaid või (b) nende mittekasutamise korral esitada põhjendused, miks selliseid tehnoloogiaid ei kasutatud ning kasutati miskit muud, mis oli riigihanke alusdokumentides nimetamata. 2.4. Hankija poolt riigihanke alusdokumentides esitatud TEHIK IT profiil nägi sealjuures ette nii eelistatud, aktsepteeritavad kui mitte valitavad süsteemid ja rakenduskihid. 2.5. Nii oli protsessimootor (Workflow Engine1) osas ette nähtud ainsa aktsepteeritava rakenduskihina Zeebe töövoohaldussüsteem ning integratsiooni võimalused eelistatult AMQP, REST ning aktsepteeritavana GraphQL, gRPC ning SOAP. 2.6. Zeebe puhul on tegemist Camunda loodud hajutatud töövoohaldussüsteemiga, millise eesmärgiks on võimaldada mikroteenuste ja äriprotsesside orkestreerimist skaleeritavalt ja efektiivselt. Ehk Zeebe oma olemuses pakub tööriistu keerukate protsesside haldamiseks ja jälgimiseks. 2.7. Oma toimimises kasutab Zeebe aga üksnes ja ainult väga kindlaid tehnoloogiad nagu gRPC, Protobuf, Raft konsensusalgoritm, BPNM 2.0, actor-model jms. Vastav arhitektuur toetab selliselt mikroteenuste orkestreerimist, keerulise äriprotsesside haldamist ja horisontaalset skaleerimist, olles samal ajal lihtsasti integreeritav teiste süsteemidega. Sealjuures kasutab Zeebe gRPC protokolli alates selle 1 Workflow Engine ehk töövoo mootor on tarkvarakomponent, mis haldab ja automatiseerib protsesse või töövooge organisatsioonis või süsteemis. See mootor suudab määratleda, täita ja jälgida järjestikuseid samme (ülesandeid), mida kasutajad või süsteemid peavad teostama kindla töövoo raames. Töövoo mootorid on keskne osa äriprotsesside automatiseerimisel, aidates tagada, et töövood toimivad tõrgeteta ja järjepidevalt. 3/6  loomisest, s.o 9. augustist 2017 aastal.2 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.3 Viimaseni jõutakse ilmselt järgmise 8.6.0 versiooni avaldamisel, kuid nimetatu ei ole veel kinnitatud. 2.8. Hankija on enda vastustes (vt p 1.6) sealjuures ka ise kinnitanud, et Zeebe töövoohaldussüsteem, millise hankija on ise TEHIK IT profiili järgi määranud aktsepteeritavaks rakenduseks, on võimalik kasutada eeskätt gPRC protokolliga. gRPC (Google Remote Procedure Call) on kaasaegne, avatud lähtekoodiga suhtlusprotokoll, mida kasutatakse serverite ja klientide vahelise suhtluse lihtsustamiseks ja optimeerimiseks. Seega olukorras, kus kasutada tuli hankija poolt kindlaksmääratud tehnoloogiat, milline oma olemuses ühildub gRPC (Google Remote Procedure Call) suhtlusprotokolliga, milline hankija enda poolt on määratud aktsepteeritavaks lahenduseks (mitte alternatiivseks või standardist erineva võimalusega nagu püüab hankija ekslikult väita), tuleb hindamiskriteeriumi sisustamisel lähtuda eeskätt kirjelduse osast (a) millise loomisel on arvestatud tellija tehnoloogiatega. Nimetatu aga hindamiskriteeriumi järgi ei nõudnud põhjendusi. 2.9. Eelnevast ei saa seega olla küsimust, et vaidlustaja on arvestanud kõigi tellija tehnoloogiatega, millised olid TEHIK IT protokollis välja toodud. Nagu juba öeldud, siis 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 järelikult on vaidlustaja arvestanud kõigi tellija tehnoloogiatega. Seega on ebaõige ja otseselt väär hankija väide, nagu oleks vaidlustaja kasutanud midagi standardist erinevat ja et vaidlustaja oli kohustatud põhjendama teiste tehnoloogiate kasutamist. Kui tegemist on hankija poolt aktsepteeritava ja protokollis välja toodud tehnoloogiaga, siis ei ole tegemist selgesti alternatiivse tehnoloogiaga. Vaidlustaja ei kasutanud muid tehnoloogiaid, kui neid mida hankija oli ette näinud. Seega väljub hankija enda otsuste põhistamisel enda poolt kehtestatud hindamiskriteeriumitest, milline on tervikus viinud ebaõige otsuseni. 2.10. Kõike eelkirjeldatut kinnitab muuhulgas ka hankija seisukoht, kus hankija on pidanud piisavaks põhjenduseks viidet, et "Zeebe klienditeek kasutab gRPC protokolli sisemiselt". Nimetatud lause aga asjaolude kogumis ei kvalifitseeru teise tehnoloogia kasutamise põhjendusena, vaid selgitusega sellest, et hankija poolt ettenähtud tehnoloogiat on kasutatud. Tegemist ei ole standardist erineva suhtlusportaaliga nagu püüab eksitavalt väita. 2.11. Teisalt, isegi kui asuda seisukohale, et põhjendamine oli vajalik, siis ka seda on vaidlustaja tegelikult teinud. 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 läbi Hankija poolt ettekirjutatud teegi (gRPC kasutuse põhjendus). Vastav selgitus oli esitatud ä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.“ 2.12. 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. Seega on vaidlustaja põhjendanud gRPC kasutust kirjalikult, ühtlasi korduvalt rõhutanud, et seesuguse lisaselgituse nõudmine olukorras, kus hankija poolt ette kirjutatud tarkvara kasutusnõudest lähtuvalt on rakenduses gRPC protokolli sisemine kasutus hankija ja pakkuja poolt vältimatu. 2 GitHub - camunda/camunda at 0.1.0 ja https://github.com/camunda/camunda/tree/8.5.0/zeebe/gateway- protocol/src/main/proto 3 Streamlining Camunda APIs: Building ja selgitus, et REST ja gRPC liidesed 8.6.0-alpha3 versioonis, kus vajalik võimekus tekib, aga see on "alpha versioon" ehk vahereliis avaldamata 8.6 suunas järgmisel lingil: Zeebe REST API | Camunda ja https://github.com/camunda/camunda/tree/8.6.0-alpha3/zeebe/gateway- protocol/src/main/proto 4/6  2.13. Eeltoodust johtuvalt, kui asuda seisukohale, et vaidlustaja ei ole kasutanud hankija tehnoloogiaid, siis on vaidlustaja igal juhul enda README failis esitanud põhjendused sõnumivahetuse valiku osas. 2.14. Kokkuvõttes jääb vaidlustaja seisukoha juurde, et hankija on vaidlustaja pakkumust hindepunkti 5.2 osas hinnanud ebaõigesti, jättes tegelikult nõutud asjaolud kohaldamata. Vaidlustajale tulnuks antud hindamiskriteeriumi osas omistada 6 hindepunkti, mida hankija aga teinud ei ole. Seega ei saa hankija hindamine olla toimunud õiguspäraselt. 2.15. Vaidlustaja hinnangul on oluline veelkordselt rõhutada, et hankija on ise enda vastustes jaatanud, et on teadlik, et Zeebe klienditeek kasutabki sisemiselt gRPC protokolli, kuid hankija hinnangul nõudis see siiski vaidlustaja jaoks arusaamatul põhjusel täiendavat põhjendamist. Vaidlustaja hinnangul on hankija selline seisukoht arusaamata ja vastuoluline, jättes kogumis otsistud mulje. 2.16. Nimelt oma vastusega jaatab hankija ka ise, et Zeebe klienditeegiga, ei saagi kasutada muud protokolli kui gRPC-d. Seega sellekohase põhjenduse nõudmine, kus pakkuja viitab üldsõnaliselt nö. võimatuse puudumisele, puuduks mistahes sisuline tähendus. Sellest johtuvalt, kui võtta arvesse gRPC-d kui ainuvalikulist production-ready andmevahetusprotokolli, mis võimaldab vajalikul kujul käskluste edastamist Zeebe'is käitatavatele protsessimudelitele (mida nt alles arenduses olev REST ei võimalda), ongi Net Group andnud sisulised põhjendused selleks, miks seda protokolli kasutatakse ja millist eesmärki ta hanke juures täidab. „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.“ 2.17. Eelkirjeldatud vastab detailselt hindamismetoodikas esitatud küsimusele „miks on kasutatud“ antud tehnoloogiat – saavutamaks arhitektuuriliselt soovitud tasakaalu, kus käivitatavad protsessimudelid on abstraktsed ning ärilises mõistes hoomatavad,4 kuid siiski käivitatavad nii nagu seda proovitöö oma tervikus nõudis. 3. MENETLUSLIKUD KÜSIMUSED 3.1. Vaidlustaja subjektiivsete õiguste riive. RHS § 185 lg 1 järgi võib hankija tegevuse vaidlustada juhul, kui see rikub vaidlustaja õigusi. Seega peab vaidlustuse esitamiseks olema põhjendatud huvi, milleks kinnistunud kohtupraktika järgi saab ainsana olla majanduslik huvi sõlmida hankeleping (vt nt TlnRnKo 3-11-2403, p 16). Käesoleval juhul on vaidlustaja õiguseid rikutud põhjusel, et vaidlustajale on hindepunkti 5.2 osas omistatud ebaõigesti hindepunkte, s.o 6 hindepunkti asemel 1 hindepunkt. Juhul 4 Camunda maailmas nimetatakse kirjeldatud kontseptsioone vastavalt “Täidetavad protsessimudelid” ja “Abstraktsed protsessimudelid”. 1. Täidetavad protsessimudelid: 1. Need mudelid sisaldavad kõiki tehnilisi detaile, mis on vajalikud protsessi täitmiseks, näiteks spetsiifilisi API-päringuid, teenuste ülesandeid ja muid elemente, mis suhtlevad otse süsteemidega. Näiteks võivad need määrata, kuidas ühendada asünkroonse sõnumivahetusega, kutsuda kaugteenust või integreerida andmebaasidega. Need mudelid on otse Camunda mootorisse juurutatavad ja neid saab käivitada töövoo või protsessiautomaatika osana. 2. Abstraktsed protsessimudelid: 1. Need mudelid keskenduvad protsessi kõrgetasemelisele loogikale ja voole, ilma tehnilisi detaile lisamata. Need on puhtad ja kavandatud selgelt äriloogika edasiandmiseks, kasutades sageli teenuste ülesandeid või muid elemente, et tähistada tehnilise integratsiooni kohta. Tehnilised üksikasjad, näiteks kuidas ühendada väliste teenustega, on abstraheeritud ja käsitletakse hiljem rakendusfaasis või eraldi tehnilistes artefaktides. 5/6  kui hankija oleks vaidlustaja pakkumust õigesti hinnanud, oleks vaidlustaja punktide koguarv kokku 97,37 punkti, milline asetaks vaidlustaja kõige kõrgemale asukohale pingereas.5 3.2. Käesoleva vaidluse rahuldamine aitab kaasa vaidlustaja õiguste kaitsele ning rikutud õiguste taastamisele. Seega esineb vaidlustajal põhjendatud huvi vaidlustuse esitamiseks. 3.3. Vaidlustuse esitamise tähtaegsus. RHS § 189 lg 1 kohaselt peab laekuma vaidlustus VAKO-le 10 päeva jooksul alates hetkest, kui vaidlustaja sai teada või pidi teada saama oma õiguste rikkumisest. Vaidlustaja sai hankija koostatud otsuse kätte selle edastamise päeval, ehk 27.08.2024. Viimane päev sellele vaidlustuse esitamiseks on seega 06.09.2024. Järelikult on vaidlustus esitatud tähtaegselt. 3.4. Vaidlustuse läbivaatamise viis. Vaidlustaja soovib vaidlustuse kirjalikku menetlemist. 3.5. Riigilõiv. Vaidlustaja on tasunud kooskõlas RLS § 258 lg 1 p 2 vaidlustuse esitamisel riigilõivu summas 1280 eurot (lisa 7). 3.6. Esindusõigus. Vaidlustaja nimel vaidlustuse esitanud isik kinnitab esindusõiguse olemasolu. Lugupidamisega /digitaalselt allkirjastatud/ Keidi Kõiv vandeadvokaat Net Group OÜ lepinguline esindaja Lisad: 1. Hankija 08.08.2024 hindamisotsus; 2. Hankija 15.08.2024 otsus hindamistulemuste kehtetuks tunnistamise kohta; 3. Hankija 27.08.2024 hindamisotsus; 4. Vaidlustaja pöördumine hankijale; 5. Vaidlustaja pöördumine hankijale; 6. Hankija 27.08.2024 otsus kõrvaldamise ja kvalifitseerimise tingimuste kontrolli kohta; 7. Riigilõivu tasumise maksekorraldus. 5 Võrdluses RingIT OÜ 97 punkti (hind 24 punkti, proovitöö 68 punkti ning sotsiaalne vastutustundlikkus 5 punkti), Wisercat 96,67 punkti (hind 21,67 punkti, proovitöö 70 punkti ning sotsiaalne vastutustundlikkus 5 punkti) ning AS HELMES 96,74 punkti (hind 21,74 punkti, proovitöö 70 punkti ning sotsiaalne vastutustundlikkus 5 punkti). 6/6