3. isiku vastus vaidlustusele

12.09.2024 KOLMANDA ISIKU I VASTUS VAIDLUSTUSELE Riigihange: „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ viitenumber: 280265 Kolmas isik I: Wisercat Estonia OÜ registrikood: 14133207 aadress: Tartu mnt 80f, 10112 Tallinn Kolmanda isiku I esindajad: Erki Fels, vandeadvokaat Gregor Saluveer, vandeadvokaadi abi Advokaadibüroo TGS Baltic e-post: [email protected] Vaidlustaja: Osaühing Net Group registrikood: 10585438 aadress: A. H. Tammsaare tee 92, 13423 Tallinn Vaidlustaja esindaja: Keidi Kõiv, vandeadvokaat Advokaadibüroo RASK e-post: [email protected] Hankija Tervise ja Heaolu Infosüsteemide Keskus registrikood: 70009770 aadress: Pärnu mnt 132, 11317 Tallinn e-post: [email protected] Kolmas isik II: RingIT OÜ registrikood: 12039823 aadress: Roseni 10, 10111 Tallinn e-post: [email protected] Kolmas isik III: AKTSIASELTS HELMES registrikood: 10364097 aadress: Lõõtsa 6, 11415 Tallinn e-post: [email protected] TAOTLUSED 1. Jätta Osaühingu Net Group vaidlustus rahuldamata. 2. Jätta Wisercat Estonia OÜ menetluskulud Osaühingu Net Group kanda. Advokaadibüroo TGS Baltic AS Ahtri 6a, 10151 Tallinn Kaluri 2, 51004 Tartu [email protected] Telefon +372 626 4300 Telefon +372 730 1610 1. ASJAOLUD 1.1. 31.05.2024 avaldas Tervise ja Heaolu Infosüsteemide Keskus (hankija, TEHIK) avatud hankemenetlusena läbiviidava riigihanke „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ (vr 280265) (riigihange) hanketeate ja tegi kättesaadavaks riigihanke alusdokumendid (RHAD). 1.2. Riigihanke esemeks on sotsiaalkaitse infosüsteemi (SKAIS2) arendus- ja hooldustööd. Riigihanke tulemusel sõlmitakse raamleping kolme majanduslikult soodsaima pakkumuse esitanud pakkujaga. 1.3. 27.08.2024 tegi hankija otsused: a. tunnistada Wisercat Estonia OÜ (kolmas isik I), RingIT OÜ (kolmas isik II) ja AKTSIASELTSI HELMES (kolmas isik III) pakkumused edukaks; b. kvalifitseerida ja jätta kolmas isik I, kolmas isik II ja kolmas isik III kõrvaldamata. 1.4. 06.09.2024 esitas pingereas neljandale kohale jäänud Net Group OÜ (vaidlustaja) hankija otsustele riigihangete vaidlustuskomisjoni (VAKO) kaudu vaidlustuse. Vaidlustaja väitel on tema pakkumust ebaõigesti hinnatud. 1.5. 09.09.2024 teatega andis VAKO hankijale ja kolmandatele isikutele võimaluse esitada vastus vaidlustusele 12.09.2024. 1.6. Kolmas isik I vaidleb vaidlustusele vastu. Hankija on vaidlustaja pakkumust õigesti hinnanud. 2. PÕHJENDUSED 2.1. Vaidlusaluseks hindamise kriteeriumiks on „Proovitöö“, täpsemalt alakriteerium 5.2 „Kasutatud tehnoloogiad“ (Kriteerium 5.2): „Pakkumus saab 6 punkti, kui 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 gRPC kasutamine.“ „Pakkumus saab 1 punkti, kui alternatiivsete tehnoloogiate kasutamise korral ei ole arusaadavalt põhjendatud, miks on kasutatud teisi tehnoloogiaid.“ 2.2. Vaidlustaja sai Kriteeriumis 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 (ptk A) ega ka see, et ta on gRPC kasutamist põhjendanud (ptk B). Kolmas isik I selgitab ka seda, et vaidlustus tuleb vaidlustuse taotluse 3 osas jätta igal juhul rahuldamata (ptk C). A. VAIDLUSTAJA PIDI PÕHJENDAMA GRPC KASUTAMIST 2.3. Enamik vaidlustusest põhineb arutlustel, kas gRPC kvalifitseerub „tellija tehnoloogiaks“, mille kasutamist ei pidanud põhjendama, või „teiseks tehnoloogiaks“, mida pidi põhjendama. 1 2.4. Kriteeriumis 5.2 on näitena „teisest tehnoloogiast“ toodud just nimelt gRPC kasutamine protsessimootori ja teenuste vahel. Seega ei saa olla vaidlust, kas vaidlustaja pidi proovitöös põhjenduse esitama või mitte. Vaidlustaja on asunud analüüsima hankija IT-profiili (millest tegelikult tuleneb samuti, et gRPC ei ole tellija tehnoloogia), kuid on ilmselt teadlikult jätnud tähelepanuta selle lauseosa Kriteeriumis 5.2, mis annab vaidlusalusele küsimusele ühemõttelise vastuse. See, et gRPC kasutamist tuleb põhjendada, tuleneb niisiis ühemõtteliselt hindamismetoodikast. 1 Vaidlustus, p-d 2.4—2.10. 2/7 2.5. Vaidlustaja väited, et gRPC kvalifitseerub „tellija tehnoloogiaks“, on ka sisuliselt ebaõiged. Hankija IT-profiilis, millele vaidlustaja viitab, 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“. 2.6. Ühemõtteliselt kinnitab seda ka proovitöö dokumendi 2 punkt 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) 2.7. Nagu hankija IT-profiilist näha, ühendatakse RabbitMQ sõnumivahendaja külge AMQP suhtlusprotokoll, mitte gRPC suhtlusprotokoll: 2.8. Samasugune loogika on näha tellija soovituslikust paigaldusvaatest, mis on esitatud proovitöö dokumendi lk-l 5. Nagu näha, ühendatakse äriprotsessi juhtimise moodul (Zeebe) RabbitMQ külge AMQP protokolli, mitte gRPC-ga: 2 RHAD „Proovitöö_uuendatud 1806“. 3/7 2.9. Kuigi kolmas isik I ei ole vaidlustaja proovitööd näinud, saab ta vaidlustusest ja sellele lisatud materjalidest aru nii, et vaidlustaja on proovitöös realiseerinud järgmisel skeemil nähtava alternatiivse lahenduse: 2.10. Vaidlustaja lisatud teabevahetusest nähtub, et vaidlustaja saab tegelikult ka ise aru, et ta kasutab proovitöös alternatiivset tehnoloogiat. Vaidlustaja vastuses ei vasta küll tõele väide, et ta on gRPC kasutamist proovitöös põhjendanud, kuid siiski on näha, et vaidlustaja pidas põhjendamist iseenesest vajalikuks: „[Vaidlustajale] jääb mulje, et AMQP mittekasutamise ehk gRPC kasutamise argumentatsioon ReadMe failis on kahe silma vahele jäänud. Oleme omalt poolt veendunud, et vajalik tehniline selgitus on korrektselt vormistatud README failis.“ (vaidlustuse lisa 4) 2.11. Kui vaidlustaja oleks tegelikult arvamusel, et gRPC kasutamist ei pidanud põhjendama, ei oleks vaidlustaja hankijale sellist vastust andnud. Vaidlustaja kutsub ka ise tehnilist selgitust „vajalikuks“, kuna ta ei ole kasutanud AMQP suhtlusprotokolli, vaid gRPC-d. 2.12. Seega selgub nii RHADist, hankija IT-profiilist kui ka vaidlustaja teabevahetuses antud vastusest ühemõtteliselt, et vaidlustaja pidi proovitöös selgitama gRPC kasutamist. 2.13. Kui vaidlustaja pidas gRPC kasutamise põhjendamise kohustust õigusvastaseks või oli (ebaõigel) arvamusel, et gRPC kvalifitseerub hankija tehnoloogiaks, oleks ta pidanud Kriteeriumit 5.2 vaidlustama. Kuna vaidlustaja seda ei teinud, on RHAD kehtiv ja siduv nii pakkujatele kui ka hankijale. 3 Õigusvastaselt oleks hankija käitunud siis, kui oleks RHADist kõrvale kaldunud ja vaidlustaja puhul gRPC kasutamise kohta põhjenduse nõudmata jätnud. B. VAIDLUSTAJA EI OLE GRPC KASUTAMIST PÕHJENDANUD 2.14. Kuigi suur osa vaidlustusest põhineb ebaõigel väitel, et vaidlustaja ei pidanud gRPC kasutamist põhjendama, väidab vaidlustaja vastuoluliselt ikkagi ka seda, et ta on tegelikult gRPC kasutamist põhjendanud. See ei vasta tõele. 2.15. Vaidlustaja viitab järgmisele äriprotsesside mootori teenuse ReadMe failis esitatud lõigule: 3 RKHKo 3-3-1-24-13, p 25; RKHKo 3-3-1-50-15, p 14.2. 4/7  „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.“ (vaidlustus, p 2.11) 2.16. 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. Seetõttu on vaidlustaja ka ise nii teabevahetuses kui vastuses vaidlustusele rõhutanud (rasvases tekstis ja alla joonitult) just lõigu teist lauset, mis algab sõnadega “Kuigi BPM notatsioon /…/”.4 2.17. „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“. 2.18. Kriteerium 5.2 nõudis „üheselt mõistetavat põhjendust, miks on kasutatud teisi tehnoloogiaid“. Pakkumusele tuli anda üks punkt, kui proovitöös „ei ole arusaadavalt põhjendatud, 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 vaidlustaja esile toonud ei ole. 2.19. Arvestades vaidlustaja vastust ja punktis 2.9 visandatud eeldatavat vaidlustaja lahendust, mis toob kaasa terve hunnik IT-arhitektuurilisi küsimusi, oleks vaidlustaja pidanud proovitöös adresseerima vähemalt järgmist: a. miks on asünkroonne sõnumivahetus „ebavajalik“; b. miks on sünkroonne sõnumivahetus parem, kui asünkroonne; c. milles seisneb „mudelite äriperspektiiv“; d. miks on sõnumite korreleerimine ebavajalik; e. kuidas on muudetud arhitektuuris tagatud äriteenuste skaleerimine ja kõrgkäideldavus; f. kuna tekib tugev seos “Äriprotsessi juhtimise” ja “Äriteenuste” moodulite vahel, mis on vastuolus mikroteenuste arhitektuuri põhimõtetega, oleks pidanud selgitama, kuidas see vastuolu on gRPC protokolli puhul käsitletud; g. kuidas mõjub muudatus süsteemi keerukusele; h. kuidas mõjub muudatus süsteemi hallatavusele; i. kuidas käsitleda olukorda, kui süsteemis on palju erinevaid “Äriteenuseid”, mida protsessimootor peab juhtima. 2.20. On tõenäoline, et äriprotsesside mootori teenuse ReadMe failist leitud põhjendus on kontekstist välja rebitud ja tegelikult ei olegi vaidlustaja sellega üritanud põhjendada gRPC kasutamist. Sellele viitab asjaolu, et vaidlustuses on vaidlustaja esitanud teistsuguse põhjenduse. Vaidlustuses toob vaidlustaja põhjenduseks gRPC kasutamise kohta selle, et Zeebe poolt pakutav Java klienditeek kasutab gRPC suhtlusprotokolli. 5 Kui vaidlustaja tegelikult arvaks, et proovitöös oli põhjendus esitatud, oleks ta vaidlustuses jäänud sama põhjenduse juurde. 2.21. Vaidlustaja väidab ka seda, et kuna Zeebe klienditeegiga ei saagi kasutada muud protokolli, kui gRPC-d, siis oleks põhjenduse esitamine olnud tarbetu.6 See väide on selgelt 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 Kriteeriumis 5.2 „tellija tehnoloogiat“, mille 4 Vaidlustuse lisa 4; vaidlustus, p 2.11. 5 Vaidlustus, p 1.6; vaidlustuse lisa 4, lk 2, p 1. 6 Vaidlustus, p 2.16. 5/7  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. Hankija on vaidlustajale teabevahetuses õigesti selgitanud: „Proovitöös on kohustuslik kasutada Zeebe protsessimootorit, kuid 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.“ (vaidlustus, p 1.8) 2.22. Kolmas isik ei pea ta tõenäoliseks, et vaidlustaja proovitöös seisneb gRPC protokolli kasutamine ainult Zeebe klienditeegi siseses suhtluses. Kui see vastaks tõele, ei oleks vaidlustaja esitanud teabevahetuses sellist vastust: „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.“ (vaidlustuse lisa 4, lk 1) 2.23. Sellele selgitusele vastab skeem, mille esitas kolmas isik ülal punktis 2.9 ja mille puhul oleks vaidlustaja pidanud vastama ülal punktis 2.19 viidatud küsimustele, kuna see on väga põhimõtteline IT-arhitektuuriline muudatus. Väide, et „tellija lahendus ei ole vajalik“, ei ole sisuline põhjendus. 2.24. Kokkuvõttes on selge, et vaidlustaja ei ole proovitöös „üheselt mõistetavalt“ selgitanud, miks on ta otsustanud kasutada gRPC suhtlusprotokolli. Hankija oli kohustatud andma vaidlustaja pakkumusele Kriteeriumi 5.2 eest ühe punkti. C. VAIDLUSTUS TULEB VAIDLUSTUSE TAOTLUSE 3 OSAS JÄTTA IGAL JUHUL RAHULDAMATA 2.25. Vaidlustaja taotleb vaidlustusega ka nende hankija otsuste kehtetuks tunnistamist, millega kvalifitseeriti ja jäeti kolmandad isikud kõrvaldamata. Vaidlustaja ei ole aga esitanud nendele otsustele ühtegi sisulist etteheidet. Isegi kui vaidlustus rahuldataks, ei tulene sellest, et kolmandad isikud on ebaõigesti kvalifitseeritud või jäetud kõrvaldamata. 6/7 3. MENETLUSLIKUD KÜSIMUSED 3.1. Esindus. Vandeadvokaat Erki Fels ja vandeadvokaadi abi Gregor Saluveer kinnitavad, et on kolmanda isiku I lepingulised esindajad (RHS § 190 lg 11). 3.2. Tähtaegsus. VAKO määras vaidlustusele vastamise tähtpäevaks 12.09.2024. Vastus on tähtaegne. 3.3. Läbivaatamine. Kolmas isik I on nõus kirjaliku menetlusega (RHS § 190 lg 1 p 6). 3.4. Esitamine. Vastus on esitatud VAKO-le ([email protected]) ja menetlusosalistele e-posti teel. Lugupidamisega (digitaalselt allkirjastatud) Erki Fels, Gregor Saluveer, vandeadvokaat vandeadvokaadi abi 7/7