Otsus

< OTSUS Vaidlustusasja number 253-25/290035 Otsuse kuupäev 03.12.2025 Vaidlustuskomisjoni liige Ulvi Reimets Vaidlustus FOB Solutions OÜ vaidlustus Rahandusministeeriumi Infotehnoloogiakeskuse riigihankes „Võrgustikuanalüütika tarkvara“ (viitenumber 290035) FOB Solutions OÜ pakkumuse tagasi lükkamise ja STATS Unities OÜ pakkumuse edukaks tunnistamise otsustele Menetlusosalised Vaidlustaja, FOB Solutions OÜ, esindaja vandeadvokaat Kristo Kallas Hankija, Rahandusministeeriumi Infotehnoloogiakeskus, esindaja Kairi Osolainen Kolmas isik, STATS Unities OÜ, esindaja vandeadvokaat Heidi Rajamäe-Parik Vaidlustuse läbivaatamine Kirjalik menetlus RESOLUTSIOON RHS1 § 197 lg 1 p 4 ja § 198 lg-de 3 ja 8 alusel 1. Jätta FOB Solutions OÜ vaidlustus rahuldamata. 2. Mõista FOB Solutions OÜ-lt STATS Unities OÜ kasuks välja lepingulise esindaja kulud 1720 eurot käibemaksuta. 3. Jätta FOB Solutions OÜ vaidlustusmenetluse kulud tema enda kanda. EDASIKAEBAMISE KORD Otsuse peale võib esitada kaebuse halduskohtule kümne päeva jooksul otsuse avalikult teatavaks tegemisest arvates (halduskohtumenetluse seadustiku § 270 lg 1). 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 (RHS § 200 lg 4). ASJAOLUD JA MENETLUSE KÄIK 1. 30.01.2025 avaldas Rahandusministeeriumi Infotehnoloogiakeskus (edaspidi Hankija) 1 Riigihangete seadus riigihangete registris avatud hankemenetlusena läbi viidava riigihanke „Võrgustikuanalüütika tarkvara“ (viitenumber 290035) (edaspidi Riigihange) hanketeate. 2. 07.11.2025 laekus Riigihangete vaidlustuskomisjonile (edaspidi vaidlustuskomisjon) FOB Solutions OÜ (edaspidi ka Vaidlustaja) vaidlustus tunnistada kehtetuks Rahandusministeeriumi Infotehnoloogiakeskuse 28.10.2025 otsused, millega lükati tagasi FOB Solutions OÜ pakkumus ja tunnistati edukaks STATS Unities OÜ (edaspidi ka Kolmas isik) pakkumus. 3. Vaidlustuskomisjon teatas 14.11.2025 kirjaga nr 12.2-10/253 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 19.11.2025 ja neile vastamiseks 24.11.2025. Vaidlustuskomisjoni poolt määratud esimeseks tähtpäevaks esitas täiendavad seisukohad ja menetluskulude välja mõistmise taotluse Vaidlustaja, menetluskulude välja mõistmise taotluse Kolmas isik, teiseks tähtpäevaks esitas täiendavad seisukohad Hankija ja vastuväite Kolmanda isiku menetluskulude osas Vaidlustaja. MENETLUSOSALISTE PÕHJENDUSED 4. Vaidlustaja, FOB Solutions OÜ, põhjendab taotlusi järgmiselt. 4.1. Vaidlustaja pakkumuse tagasilükkamise põhjendused nähtuvad 27.10.2025 protokollist (vaidlustuse lisa 2). Vaidlustaja pakkumuse tagasilükkamine pole põhjendatud. 4.2. Hankija otsus lükata Vaidlustaja pakkumus tagasi põhineb Hankija poolsel olulisel eksimusel pakutava tarkvaraplatvormi (Elastic) tehnilise olemuse mõistmisel ning Riigihanke alusdokumentide (edaspidi RHAD) meelevaldsel ja ebaõigel tõlgendamisel. Samuti ei ole Hankija tegevus RHAD ja vastavustingimuste selgitamisel ning selle järgi pärast pakkumuste kontrollimisel läbipaistev, kuna esmalt on vastustes antud pakkujale „vabad käed“ otsustamaks, kuidas ja mida esitada, hiljem aga toodud just see puuduseks, justkui pole pakkuja suutnud piisavalt aimata, mis Hankijale sobiv on. 4.3. Hankija on ekslikult tõlgendanud tarkvaraplatvormi standardset konfigureeritavust ja paigaldamise käigus teostatavat seadistamist kui pakkumuse puudust. Kaasaegsed ja võimekad platvormid nagu Elastic ei ole „karbitoode“, vaid nende täielik funktsionaalsus realiseeritakse vastavalt kliendi spetsiifilistele andmetele ja vajadustele. Vaidlustaja pakkumus hõlmas nii litsentsi kui ka paigaldustöid, mis tagavad kõigi nõuete täitmise. Seega, kui tootes on võimekus olemas ja selle seadistamine on osa paigaldusest, on nõue täidetud. Nõuded tulenevad tehnilise kirjelduse (vaidlustuse lisa 4) p-st 4 ja vastavustabelist ning neile on viidatud ka tagasilükkamise protokollis. Vaidlustaja on esitanud vastavustabelis viited oma pakutavale (vaidlustuse lisa 5) 4.4. Nõue 4.8: Andmeelementide tuvastamine Hankija leidis, et Vaidlustaja pakkumus ei vasta nõudele, kuna ei tuvastatud, et süsteem suudaks tuvastada kõiki nõutud andmeelemente (nt raha liikumise suund). Hankija järeldas 2 (26) Vaidlustaja selgituse pinnalt, et kuna funktsionaalsus realiseeritakse paigalduse osana GROK mustrite abil, siis see ei sisaldu pakutavas süsteemis pakkumuste esitamise hetkel. Hankija on teinud fundamentaalse ja otsust mõjutava vea GROK olemuse mõistmisel. Elasticu GROK ei ole mingil moel seotud veebilehega x.ai/grok. See on Elastic Stacki standardne, laialdaselt kasutatav ja võimas komponent, mis on mõeldud struktureerimata tekstiandmete parsimiseks ja struktureerimiseks. See on toote sisseehitatud funktsionaalsus. Vaidlustaja viitas oma vastuses korrektsele tehnoloogiale. Hankija poolt suvalise ja eksitava veebiotsingu tulemuse kasutamine pakkumuse hindamisel on viinud vale järelduseni. Viide tootja dokumentatsioonile: https://www.elastic.co/docs/reference/logstash/plugins/plugins-filters-grok Vaidlustaja kinnitas, et tootes on olemas võimekus ja vajalikud mustrid koostatakse paigalduse osana. See ongi selliste platvormide tööpõhimõte. Nõue 4.8 sätestab, et süsteem peab... tuvastama teatud andmeelemendid. Nõue ei keela selleks süsteemi sisseehitatud konfigureerimisvahendite kasutamist. Vaidlustaja pakkus terviklahendust, mis hõlmab tarkvara ja selle paigaldust, mille käigus toimub konfigureerimine vastavalt kliendi vajadustele. 4.5. Nõue 4.10: Andmesubjekti tuvastamine Hankija väidab, et ei saanud kinnitust, et süsteem suudab tuvastada erineval kujul esitatud isikute samasust ning leida seoseid läbi muude andmeelementide (nt pangakonto). Elastic on oma olemuselt maailmatasemel otsingu- ja analüütikaplatvorm. Isikute samasuse tuvastamine (ingl Entity Resolution) on üks selle põhilisi kasutusvaldkondi. Pakkuja selgitas korrektselt, et Elastic sisaldab võimekaid päringukeeli, mis lubavad kasutada fuzziness (hägususe) parameetreid, et leida sarnaseid, kuid mitte identseid vasteid. Seoste leidmine läbi ühiste andmeelementide on Elasticus fundamentaalne võimekus. Viide tootja dokumentatsioonile: https://www.elastic.co/docs/reference/query- languages/query-dsl/query-dsl-fuzzy-query On ebamõistlik eeldada, et pakkuja peaks looma keeruka, Hankija vajadusi simuleeriva andmekogu ja seadistama selle baasil täisfunktsionaalse lahenduse pelgalt demo eesmärgil, eriti kui Hankija andis ise pakkujale vabad käed näidisandmete loomiseks (nähtub teabevahetuses toodud Hankija vastustest). Vaidlustaja kinnitas vastavustabelis nõude täitmist ja selgitas tehnilist lahendust. Sellest piisab vastavuse tõendamiseks, kui RHAD-s pole seatud konkreetseid, mõõdetavaid demo-nõudeid. Hankija on asetanud pakkuja ebavõrdsesse olukorda, nõudes midagi enamat, kui RHAD ette nägid ning seda enam olukorras, kus vastava nõude osas on selgitust küsitud ning Hankija on vastanud, et annab pakkujale vabad käed. 4.6. Nõue 4.24: Agregeerimine rakenduse graafil Hankija märkis pakkumuse tagasilükkamise otsuses, et pakkuja demonstreeris statistilist diagrammi, mitte andmeelementide agregeerimist võrgustiku graafil. 3 (26) Hankija ajab paraku segamini andmete agregeerimise protsessi ja selle visuaalse väljundi. Vaidlustaja demonstreeris andmete agregeerimise võimekust tunnuste alusel. See, kas agregeeritud tulemus kuvatakse statistilise diagrammi või võrgustiku graafina, on visualiseerimisviisi valiku küsimus. Elastic platvormi visualiseerimistööriistad (nt Kibana Lens) võimaldavad agregeeritud andmeid kuvada kümnetel erinevatel viisidel, sh võrgustikugraafina. Viited tootja dokumentatsioonile: https://www.elastic.co/docs/explore-analyze/visualize/lens https://www.elastic.co/docs/explore-analyze/visualize/graph Vaidlustaja küsis Hankijalt täpsustust „seoste“ ja „tunnuste“ kohta selles konkreetses punktis. Hankija andis laia ja näidetega vastuse. Vaidlustaja demonstreeris funktsionaalsust vastavalt Hankija enda antud selgitustele. Hankijal pole õigust tagantjärele pakkumusi hinnates hakata tuginema enda ebaselgest sõnastusest tulenevale mitmeti mõistetavusele Vaidlustaja kahjuks. Selliselt on tegemist riigihangete läbipaistvuse ja võrdse kohtlemise põhimõtete rikkumisega (RHS § 3 p 1 ja 2). 4.7. Nõue 4.25: Statistilised ja võrgustikufunktsioonid Hankija märkis tagasilükkamise otsuses, et pakutud süsteemist ei leitud spetsiifilisi võrgustikuanalüüsi funktsioone (tsentraalsus, tihedus, vahendatus, lähedus), vaid ainult üldiseid statistilisi funktsioone. Hankija on teinud ennatliku järelduse eeldades, et kõik funktsioonid peavad olema lõppkasutaja graafilises liideses ühe nupuvajutusena kättesaadavad. Elastic on platvorm, mitte lihtne tööriist ning pakub nõutud funktsionaalsust läbi oma laiemate andmeteaduse ja masinõppe võimekuste. Kuigi spetsiifilised meetrikad nagu betweenness centrality ei ole standardvisualiseerimises vaikimisi nupuna olemas nende arvutusliku keerukuse tõttu, on Elastic platvormil mitu standardset ja dokumenteeritud viisi nende arvutamiseks ja kasutamiseks: 1) Andmete rikastamine läbi masinõppe (Machine Learning): Kõige kaasaegsem ja platvormisisene meetod on kasutada Elasticu masinõppe funktsioone, et tuvastada andmestikust anomaaliaid ja mõjukaid sõlmpunkte (influential nodes). See on praktiline ekvivalent tsentraalsuse analüüsile. Süsteem saab õppida andmetest, millised isikud või kontod on võrgustikus kõige kesksemad või käituvad ebatavaliselt, täites seega nõude sisu. Viide tootja dokumentatsioonile: https://www.elastic.co/docs/explore-analyze/machine- learning/anomalydetection/ml-configuring-populations See dokumentatsioon kirjeldab, kuidas analüüsida indiviidide käitumist grupi suhtes, mis on tsentraalsuse tuvastamise üks aluseid. 2) Andmetöötlusprotsessid (Data Transforms): Elastic võimaldab luua pidevalt uuenevaid, agregeeritud andmevaateid, kasutades Data Transforms funktsionaalsust. Selle abil on võimalik andmeid ette töödelda ja arvutada lihtsamaid võrgustikumeetrikaid (nt sõlme ühenduste arv, mis on degree centrality aluseks) ning salvestada need uute andmeväljadena. Viide tootja dokumentatsioonile: https://www.elastic.co/docs/explore- analyze/transforms/transform-overview 3) Välised andmeteaduse teegid: Standardne praktika keerukamate analüüside puhul on kasutada Elasticu kliente (nt Pythoni teeki), et tuua andmed platvormist välja, rakendada spetsialiseeritud graafianalüüsi teeke (nt Pythoni NetworkX), arvutada vajalikud meetrikad (tsentraalsus, tihedus jne) ning seejärel laadida tulemused tagasi Elasticusse uute 4 (26) andmeväljadena. Seejärel on need meetrikad graafil visualiseeritavad, filtreeritavad ja kasutatavad nagu iga teine andmeelement. See muster on täielikult toetatud ja laialt levinud. Nõue 4.25 sätestab, et rakenduse graafil peab saama kasutada vastavaid funktsioone. See ei sea piiranguid sellele, kuidas tehniliselt nende funktsioonide tulemused saavutatakse – kas läbi otse liideses oleva nupu, masinõppe mudeli või andmete rikastamise protsessi. Vaidlustaja pakub platvormi, millel on võimekus nõue täita. Vaidlustaja pakkumus sisaldab ka paigaldust, mille käigus vastav funktsionaalsus Hankija vajadustest lähtuvalt seadistatakse. Hankija on tõlgendanud nõuet ebaproportsionaalselt kitsalt, eeldades üht kindlat tehnilist lahendust, mida RHAD-s pole kirjeldatud. See on vastuolus pakkujate võrdse kohtlemise põhimõttega, kuna eelistab üht võimalikku tehnilist implementatsiooni teistele, platvormi-põhistele lahendustele. Vaidlustaja on selgitanud, et platvormil on võimekus olemas ja sellest piisab nõude täitmiseks. Platvorm pakub kõiki tööriistu, et nõutud arvutused teostada ja tulemused graafil kättesaadavaks teha. Hankija eeldus, et see peab toimuma kindlal viisil (nt rippmenüüst valides), on põhjendamatu ja ei lähtu nõude tegelikust sisust. 4.8. Nõue 4.30: Visualiseerimise valiknõuded Hankija leidis, et Vaidlustaja poolt väidetavalt täidetud kuuest valiknõudest on neli (4.30.1, 4.30.2, 4.30.10, 4.30.11) täitmata, mistõttu ei ole täidetud nõutud miinimum. 4.8.1. Nõue 4.30.1 (Ringtehingute ahelad): Hankija väitis, et masinõppe funktsionaalsus vajab „treenimist“ ja pole seega valmis. See on fundamentaalne arusaamatus tehisintellekti olemusest. Kõik masinõppemudelid vajavad treenimist kliendi spetsiifilistel andmetel. Elastic platvorm sisaldab neid võimekusi standardse osana. Hankija nõuab sisuliselt valmis, treenitud tehisintellekti lahendust, mis on ebareaalne ootus riigihanke pakkumuse faasis. Viide tootja dokumentatsioonile: https://www.elastic.co/docs/explore-analyze/machine- learning/anomaly-detection 4.8.2. Nõue 4.30.2 (Node suuruse muutmine): Hankija väitis, et kuna seda saab teha reegleid kombineerides, pole funktsioon valmis. See on järjekordne konfigureerimise ja puuduva funktsionaalsuse segiajamine. Vaidlustaja vastus, et „Elastic Canvas“ võimaldab lahendada antud eelduse, kombineerides andmepõhiseid reegleid ja interaktiivseid kasutajaliidese elemente“, on tehniliselt korrektne kirjeldus, kuidas see funktsioon töötab, mitte puuduse tunnistamine. Tõendav viide tootja dokumentatsioonile: https://www.elastic.co/docs/explore- analyze/visualize/canvas 4.8.3. Nõue 4.30.10 (Node'de agregeerimine tunnuse alusel): Hankija leidis, et süsteem ei võimalda grupeerida tunnuse alusel, vaid ainult ükshaaval. Hankija on fikseerunud demos näidatud ühele meetodile, ignoreerides platvormi laiemat võimekust. Vaidlustaja kinnitas oma vastuses, et platvormi paindlikkus võimaldab erinevaid tunnuse määramise mooduseid, mis on tõene. 5 (26) 4.8.4. Nõue 4.30.11 (Graafi tüübi vahetamine): Hankija leidis, et süsteemis on vaid üks graafi tüüp ja filtrid ei säili. Elasticu lahendus sellele nõudele on interaktiivne töölaud (dashboard), kus mitu erinevat graafikut (sh võrgustik) on ühendatud sama filtrikomplektiga. See täidab nõude sisu – näha andmeid erineval moel, ilma et otsingu- ja filtriparameetrid kaoksid – isegi paremini kui nõudes kirjeldatud. Hankija on tõlgendanud nõuet liiga kitsalt ja sõna-sõnalt, mõistmata pakutava lahenduse olemuslikku paremust. 4.9. Vaidlustaja täiendavad seisukohad. 4.9.1. Vaidlustaja ei nõustu, et Riigihanke puhul oleks tegemist „karbitoote“ hankega. Kolmas isik väidab oma seisukoha mitmes punktis (nt p 10 ja 11, samuti 14), et peab pakkuma valmislahendust, kus funktsionaalsus on olemas ilma täiendava arenduseta. Hankija toetab sama seisukohta, väites, et konfigureerimine on „arendustegevus“ (Hankija vastuse lk 7 alt kolmas lõik). See on RHAD ilmselge väärtõlgendus või vähemalt ei saa sellele tagantjärele anda sellist tõlgendust ja pidada Vaidlustaja pakkumust mittevastavaks. Riigihanke objektiks ei ole staatiline „karbitoode“, vaid dünaamiline platvorm koos selle paigaldamise ja seadistamise teenusega. Seda tõendab üheselt ka hankelepingu projekt ja tehniline kirjeldus, mis määratleb detailselt Pakkuja kohustused, sh: 1) Hankelepingu projekti p 1.3 (lepingu ese) ja p 1.4 (üleandmine pärast lõppkasutajate koolitust) viitavad selgelt teenuse osutamisele ja protsessile, mitte ainult litsentsi üleandmisele ehk „karbitoote“ üleandmisele. 2) Tehnilise kirjelduse p 2 hanke eesmärgina on märgitud, et lisaks tarkvara litsentside soetamisele ostetakse ka selle liidestamise teenust. Tehnilise kirjelduse p 3.2 määratleb samuti liidestamise ja konfigureerimise funktsiooni. On endastmõistetav ja lepinguga ette nähtud, et „paigaldusteenus“ hõlmab tarkvara konfigureerimist vastavalt kliendi (Hankija) spetsiifilistele andmetele ja vajadustele. Hankija eksib ka selles, et Vaidlustaja pakutav toode oleks alfa, beeta või snapshot staatuses (lk 2 lõpus). Alfa, beeta vms staatusega oleks tegemist siis, kui Vaidlustaja pakutavas süsteemis vastavad funktsionaalsused puuduvad ning need tuleks alles arendada (programmeerida). Seda arendusvajadust aga pole, funktsionaalsused on olemas, kuid need tuleb lihtsalt Hankija soovi järgi seadistada. 4.9.2. Hankija vastas Vaidlustaja täpsustavatele küsimustele (nt demoandmete ja funktsionaalsuse demonstreerimise kohta) korduvalt, et jätab pakkujatele „vabad käed”. Hindamisfaasis on aga Hankija asunud Vaidlustaja pakkumust tagasi lükkama, tuginedes äärmiselt kitsastele ja spetsiifilistele tehnilistele tõlgendustele (nt „nupp peab olema liideses”), mida mitte kuskil RHAD-s ei nõutud. See on selge RHS § 3 p 1 (läbipaistvus) ja § 3 p 2 (võrdne kohtlemine) rikkumine. Oleks Hankija andnud Vaidlustajale teistsugused ja sisukad, mitte pakkumuse koostamisel „vabu käsi“ jätva selgituse, oleks Vaidlustaja ilmselgelt ka oma pakutavat toodet täpsemalt kirjeldanud. 6 (26) Hankija selgituste andmisel ja pakkujate küsimustele vastamisel „vabade käte“ jätmise osas eksib Hankija nüüd ise selles, mille osas ta vabad käed andis. Hankija märgib oma vastuses (lk 1 lõpus), et Hankija antud ükski selgitus ei muuda RHAD-d (RHS § 46 lg 3) ja Hankija kinnitab, et ei ole andnud ka ühtegi selgitust, mis võimaldaks mitte täita RHAD-s toodud nõudeid. Ainukesed selgitused nn „vabade käte“ kohta on Hankija andnud vajalike näidisandmete loomeks, vastamaks nõutud funktsionaalsuse demonstreerimiseks. Vaidlustaja ei nõustu Hankijapoolse tagantjärgi antud tõlgendusega seoses „vabade käte“ andmisega ja selle piiritlemisega. Vaidlustaja esitas Hankijale kuus küsimust, millest nelja osas andis Hankija pakkujale „vabad käed“ ega andnud sisulist selgitust ja suunist, kuidas peaks pakkumuse vormistama ja mida neis küsitud aspektides käsitlema ning kuidas presenteerima (lisa 1 – koond Vaidlustaja ja Hankija küsimustest-vastustest). Näiteks esimeses küsimuses, kuidas või milliste demo andmete pealt näidata nõudes 4.30.1 tehingute ringahelate funktsionaalsust, jättis Hankija pakkujatele vabad käed ega vaevunud midagi täpsustama. Teises küsimuses graafi tüüpide kohta vastas Hankija erinevate graafi tüüpide nimetuse kohta, kuid täpsustas, et Hankija ei ole püstitanud nõuet, millised neist peavad olema pakutavas süsteemis. Ehk siin Hankija ise ütles, et nõuet, millised täpsed tüübid olema peavad, ei ole püstitatud, nii ei saa ka tagantjärele võimalik seda puudusena nimetada. Kolmandas küsimuses nõude 4.25 ja rakenduse graafil näidatavate funktsionaalsuste kohta vastas Hankija taas, et jätab „vabad käed“ ega vaevunud midagi täpsustama. Kui pakkujad võivad luua erievat tüüpi informatsiooni, siis lähtuvalt sellest informatsioonist võisid ka pakkujad, sh vaidlustaja, otsustada, kuidas seda kuvada. Vastavat esitlusviisi ei saa seetõttu tagantjärele puuduseks ja mittevastavuseks pidada. Neljandas küsimuses nõude 4.24 ja seoste loomise kohta vastas Hankija üldistava näitega, millised võivad seosed olla ning jättis siis taas vabad käed näidisandmete loomiseks. Tagantjärele ei saa hakata Riigihanke tingimuste sisu laiendama ega otsima pakkumusest puudusi, mida hanke tingimustes ega ka selgitustes pole sõnaselgelt nõutud. Teistes küsimuste vastuse sektsioonides „vabad käed“ määratlust ei olnud, samas Hankija vastustest ilmneb, et Hankija ei oska vastata näiteks isegi andmeallikate osas, mis võiks selgelt viidata sellele, et tegu on teenusega, kus teenuse käigus tuleb esmalt need andmeallikad samuti defineerida. Ehk RHAD-sse on juba eos sisse kirjutatud pakkujate võimalus Riigihanke tingimusi vastavas valdkonnas pakutava parima praktika järgi ning Riigihanke tingimusi oma parema teadmise/arusaamise järgi tõlgendada. 4.9.3. Nõue 4.8: Andmeelementide tuvastamine – GROK Hankija väidab (lk 4) ja Kolmas isik toetab (p 13), et GROK mustrite kirjutamine on koodi kirjutamine ja programmeerimine, mis on arendustegevus ning seega ei ole funktsionaalsus valmis. Hankelepingu projekt ja tehniline kirjeldus näevad ette paigaldust ja seadistamist. Andmeallikate ühendamine ja nende parsimise seadistamine (mida GROK teeb) on iga andmeanalüütika platvormi paigalduse fundamentaalne ja ootuspärane osa. See ei ole 7 (26) „arendus“, see on „seadistus“ ehk pannakse pakutav süsteem toimima nii nagu Hankija seda vajab, mitte ei looda ega kirjutata lepingu täitmise käigus Hankija jaoks midagi uut, nagu Hankija ja Kolmas isik püüavad Vaidlustaja pakkumuse puhul väita. Väide, et GROK on programmeerimine, on tehniliselt ebakorrektne ja eksitav. GROK on Elastic platvormi standardne, sisseehitatud mustrisobituse (pattern matching) tööriist, mida kasutatakse andmete vastuvõtmisel (ingest pipeline). See on toote standardne konfigureerimise vahend. Elasticu ametlik dokumentatsioon kirjeldab GROK-i kui üht paljudest standardsetest protsessoritest andmete töötlemiseks. Vt https://www.elastic.co/docs/reference/enrich-processor/grok-processor 4.9.4. Nõue 4.25: Võrgustiku funktsioonid – Centrality, Density, Betweenness, Closeness Hankija ja Kolmas isik väidavad, et need funktsioonid puuduvad Vaidlustaja pakkumusest. Erilist rõhku pannakse Vaidlustaja varasemale selgitusele Pythoni teekide kohta, väites, et see on väline arendus. Hankija ja Kolmas isik on takerdunud kitsastesse akadeemilistesse terminitesse, ignoreerides nõude sisulist eesmärki: tuvastada võrgustikus olulisi ja anomaalseid sõlmi. RHAD ei nõua, et liideses peab olema nupp nimega „Betweenness Centrality“ (nagu on märgitud pakkumuse tagasilükkamise protokollis). See on meelevaldne kitsendus. Kaasaegsed platvormid, nagu Elastic, ei lahenda neid probleeme alati staatiliste arvutustega, vaid dünaamiliste, AI-põhiste mudelitega. Vaidlustaja pakutav platvorm sisaldab kõiki neid võimekusi standardsete, konfigureeritavate moodulitena. Elasticu standardne „Fraud Detection“ lahendus on loodud täpselt nõuete 4.25 ja 4.30.1 äriliste eesmärkide täitmiseks – leida anomaaliaid, mõjukaid sõlmi ja kahtlaseid mustreid (nagu ringtehingud). See on platvormisisene, konfigureeritav funktsionaalsus. Elasticu ametlik blogi kirjeldab, kuidas AI-d kasutatakse pettuste avastamiseks: Vt https://www.elastic.co/blog/elastic-ai-fraud-detection-financial-services Tsentraalsus/Vahendatus/Lähedus (Centrality/Betweenness/Closeness): Nende eesmärk on leida mõjukaimad sõlmed. Elasticu sisseehitatud masinõppe (ML) moodulid teevad täpselt seda (anomalous/influential node detection), analüüsides sõlmede käitumist ja ühendusi reaalajas. See on nõude kaasaegne ja parem täitmine. Tihedus (Density): See on statistiline arvutus (tegelikud seosed / võimalikud seosed). Selle saab arvutada ja kuvada, kasutades platvormi-sisest „Kibana Agregatsioonide“ mootorit ja visualiseerida „Kibana Canvas“ tööriistaga. See on konfigureerimine, mitte arendus. 4.9.5. Nõue 4.30.1: Ringtehingute ahelad Hankija väidab (vastuse lk 6), et ML-lahendus pole „valmis lahendus“, kuna see vajab treenimist. Iga masinõppelahendus vajab olemuslikult treenimist kliendi spetsiifilistel andmetel. Pakutav Elastic platvorm sisaldab ML-mootorit ja spetsiifilisi mudeleid ringtehingute ja 8 (26) muude anomaalsete mustrite tuvastamiseks. See on toote osa. Treenimine on osa hankelepingu projektis kirjeldatud paigaldus- ja seadistusteenusest. See, et hankelepingu ja tehnilise kirjelduse järgi ei paigalda pakkuja toodet ise, vaid juhendab Hankija spetsialiste selle paigaldamisel ja seadistamisel, ei välista käsitlemast seda kui seadistamisel treenitavat süsteemi. Ka juhendamine hõlmab spetsiifilist seadistamist vastavalt Hankija soovidele ja vajadustele. Elasticu pettuste avastamise lahendused on spetsiaalselt ehitatud selliste mustrite leidmiseks. Vt https://www.elastic.co/blog/financial-services-fraud-generative-ai-attack- surface 4.9.6. Nõue 4.30.2 ja 4.30.10: Node'i suuruse muutmine ja agregeerimine Hankija (lk 6-8) väidab, et kuna Vaidlustaja viitas Elastic Canvas tööriistale, on tegemist „arendamisega“ ja Hankija nõutavad funktsioonid puuduvad. RHAD ei keela standardsete konfigureerimisvahendite (nagu Canvas) kasutamist. Väide, et Canvas'e kasutamine on „arendus“, on vale. Elastic Canvas on platvormisisene „PowerPoint“ või „PowerBI“ – see on lohista-põhine (drag-and-drop) visualiseerimise ja konfigureerimise tööriist. Nii node'i suuruse dünaamiline sidumine andmeväljaga (nt tehingute arvuga) kui ka node'ide automaatne grupeerimine tunnuse (nt aadress) alusel on Canvas'e standardne, hiire-kliki-põhine funktsionaalsus. Elasticu dokumentatsioon kirjeldab Canvas't kui tööriista „live data“ visualiseerimiseks, täpselt nagu nõutud. Vt https://www.elastic.co/docs/explore-analyze/visualize/canvas 4.9.7. Vaidlustaja ei nõustu ka Kolmanda isiku märkusega, et Vaidlustaja oleks pidanud Riigihanke tingimustega mittenõustumisel need vaidlustama (lk 3, p 7 lõpus). Printsiibis on see küll õige, ehk õigusvastased tingimused tulekski vaidlustada, kuid Riigihanke tingimusi lugedes ei tekkinud Vaidlustajal sellist arusaama, et need oleks kuidagi piiravad ja kahjustavad. See arusaam tekkis alles tagantjärgi Hankija käsitlust mõistes, ehk kuivõrd Hankija on tagantjärele asunud ise Riigihanke tingimusi tõlgendama Vaidlustajale ebasoodsalt. Ehk õigusvastased pole mitte Riigihanke tingimused, vaid Hankija otsus, mis käsitles neid tingimusi vääralt ja lõi sellega Vaidlustaja jaoks ebasoodsa ja tema huve kahjustava olukorra, kõrvaldades Vaidlustaja pakkumuse edasisest hankemenetlusest. 5. Hankija, Rahandusministeeriumi Infotehnoloogiakeskus, palub jätta vaidlustus rahuldamata ning kulud Vaidlustaja enda kanda. 5.1. Vaidlustuse p-is 2.3 on Vaidlustaja asunud seisukohale, et kuna Hankija ei mõista Vaidlustaja poolt pakutud tarkvaraplatvormi (Elastic) tehnilist olemust, siis on Hankija otsus pakkumuse tagasilükkamise kohta õigusvastane. Vaidlustaja seisukoht põhineb asjaolul, et tema hinnangul ei ole Hankija RHAD-s määratlenud, millised konkreetsed pakutava rakenduse funktsionaalsed nõuded peavad olema täidetud, sest väidetavalt on Hankija jätnud vastustes pakkujatele „vabad käed“. Nii see ei ole. Hankija antud ükski selgitus ei muuda RHAD-d (RHS § 46 lg 3) ja Hankija kinnitab, et ei ole andnud ka ühtegi selgitust, mis võimaldaks mitte täita RHAD-s toodud nõudeid. Ainukesed selgitused nn „vabade käte“ kohta on Hankija andnud vajalike näidisandmete loomeks, vastamaks nõutud funktsionaalsuse demonstreerimiseks. 9 (26) Vastavalt RHS § 87 lg-le 1 on tehniline kirjeldus hankelepingu eseme kirjeldamiseks vastavas valdkonnas tegutsevatele isikutele arusaadavat terminoloogiat ja täpsusastet kasutades hankija kehtestatud asjade või teenuste omaduste ja neile esitatavate nõuete loetelu. Seega peaks ettevõtjale olema ilmne, et nõuete loetelu, millele pakkumus peab vastama, tuleb otsida tehnilisest kirjeldusest. 5.2. Hankija loetles tehnilise kirjelduse p-is 4 üles rakenduse funktsionaalsed nõuded ja p-is 5 mittefunktsionaalsed nõuded, millele pakutav rakendus või lahendus pidi vastama. P-des 4.1 kuni 4.29 loetletud nõuded olid kohustuslikud funktsionaalsed nõuded ehk need olid nõuded, mida Hankija soovis, et oleks kindlasti täidetud. Vaidlustaja pakutud tarkvaraplatvormil esinesid puudused nimetatud nõuete täitmise osas (tagasilükkamise protokolli mittevastavuse kirjelduste p-id 4.8, 4.10, 4.24 ja 4.25). Kuid lisaks kohustuslikele rakenduse funktsionaalsetele nõuetele jättis Hankija pakkujatele valikuvabaduse rakenduse graafile esitatud visualiseerimise nõuete täitmise osas (tehnilise kirjelduse p 4.30). Seega alates tehnilise kirjelduse p-st 4.30, mis puudutasid visualiseerimist, määratles Hankija RHAD-s selgelt ja ühemõtteliselt, et tegemist on valiknõuetega, kuid ühtlasi märkis Hankija ka seda, et p-des 4.30.1 kuni 4.30.11 loetletud valiknõuetest peavad olema täidetud vähemalt 4 nõuet. Antud selgitus on kirjas nii tehnilises kirjelduses kohe pärast p-i 4.30.11 kui ka RHAD-s „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabel“. Teiste sõnadega jättis Hankija pakkujale võimaluse valida tehnilise kirjelduse p-is 4.30 sätestatud 11 valiknõude seast vähemalt 4 nõuet, mis kindlasti peavad olema täidetud, et pakkumus oleks vastav RHAD-is toodud nõuetele. Millist nelja valiknõuet pakkuja täita tahab/suudab, jättis Hankija pakkujate otsustada, sest Hankija soovis pakutava tarkvaralahendusega saavutada erinevaid visualiseerimisvõimalusi graafil, kuid kuidas pakutav rakendus seda lõpuks teeks, ei olnud Hankijale määrava tähtsusega. Vaidlustaja pakutud tarkvaraplatvormil esines puudusi lisaks kohustuslike nõuete täitmise osas ka valiknõuete täitmise osas. Vaidlustaja märkis oma pakkumuses, et tal on täidetud 6 valiknõuet: 4.30.1, 4.30.2, 4.30.3, 4.30.4, 4.30.10 ja 4.30.11. Nagu nähtub tagasilükkamise protokolli mittevastavuse kirjeldustest, siis märgitud 6-st valiknõudest vastas esitatud tingimustele siiski vaid 2. (vt tagasilükkamise protokolli mittevastavuse kirjeldusi p-des 4.30.1, 4.30.2, 4.30.10 ja 4.30.11). 5.3. Hankija jaoks on arusaamatu, millest Vaidlustaja järeldab, et pakkujatele on jäetud „vabad käed“ otsustamaks, kuidas ja mida esitada. Riigihankes oli Hankija RHAD-s (tehnilises kirjelduses) sätestanud konkreetsed tingimused, mida pakkujad pidid täitma. RHS § 114 lg 1 kohaselt peab hankija kontrollima pakkumuse vastavust riigihanke alusdokumentide tingimustele ja tegema põhjendatud kirjaliku otsuse pakkumuse vastavaks tunnistamise või tagasilükkamise kohta. Pakkumuse vastavuse kontroll ei tohi olla sisutühi ja formaalne. Hankija ei kontrolli pelgalt kinnituste andmist, samuti ei saa pakkumuste vastavust kontrollida tulevikus tehtavate tööde arvelt. Risti vastupidi väljakujunenud vaidlustus- ja kohtupraktikale (Tartu Ringkonnakohus 04.09.2015, 315-1587, p 12; VAKO 08.09.2017, 125- 17/188223, p 18; VAKO 03.10.2017, 146-17/186866, p 13) eeldab Vaidlustaja, et Hankijapoolne vastavustingimuste kontroll oleks õiguspärane siis, kui Hankija piirduks pakkuja antud kinnitustega ega teostaks pakkumuste sisulist kontrolli. 10 (26) 5.4. Hankija juhib tähelepanu asjaolule, et Riigihankele oli kaasa pandud ka Exceli tabel „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabel“, et pakkujad saaksid üle kontrollida kas ja millised RHAD-s esitatud nõuded on pakutava tarkvaralahendusega täidetud. Kuid lisaks tabelile küsis Hankija pakkujatelt ka demovideot, millelt pidi näha olema kõigi funktsionaalsete nõuete täitmise lahendus (tehnilise kirjelduse p 6.2) ning ühtlasi võimaldama ka juurdepääsud pakutavale tarkvaralahendusele (tehnilise kirjelduse p 6.3), et Hankija saaks ise veenduda nõuete täidetuses ja tabelis antud kinnituste tõesuses. Veelgi enam, Hankija on tehnilise kirjelduse p-is 5.4 sätestanud nõude, et pakutav lahendus ei tohi olla alles arenduse algusjärgus (alfa, beeta või snapshot staatuses). Vaidlustaja on aga vaidlustuses korduvalt rõhutanud, et ta lahendab ühe või teise RHAD tingimuse täitmise tulevikus. Vaidlustaja viitab vaidlustuses korduvalt, et Hankija on nõudnud pakkujatelt liiga palju ja keerulisi funktsioone, et neid lihtsalt ühekordselt demo jaoks valmis teha (nt vaidlustuse alamp-id 2.7.4 ja 2.9.2). Hankija ei salga, et RHAD-s nõutud funktsionaalsused võivad olla keerulised, kuid Riigihankes osalesid pakkujad, kelle pakutavas tarkvaralahenduses olid RHAD-s nõutud funktsionaalsused olemas. Hankija ei tea, kas need funktsionaalsused loodi spetsiaalselt vaidlusaluse riigihanke jaoks või oli arendustöö juba varem tehtud. Hankija ei ole RHAD-s kordagi maininud, et soovib arendusprojekti, vaid RHAD-s on üheselt kirjeldatud, millised funktsionaalsed omadused peavad pakutaval tootel olemas olema. Seega soovis Hankija RHAD-s esitatud nõuetele vastavat lahendust, mitte tulevikus saavutatavat potentsiaalset funktsionaalsust. 5.5. Hankija on 07.04.2025 selgituses (Sõnumi ID: 949836) Vaidlustaja enda küsimise peale selgitanud, kuidas toimub RHAD-s esitatud nõuete vastavuse kontroll: /Funktsionaalsete ja mittefunktsionaalsete nõuete/ „Vastavustabel on nii pakkujale kui hankijale kontroll-leheks hankes esitatud tingimuste täitmise kontrollimisel. Vastavustabelit tuleb tõlgendada koos tehnilise kirjeldusega. Pakkuja pakutav süsteem (palume tutvuda tehnilises kirjelduses toodud tähendusega!) peab täitma kõik nõuded vastavustabeli punktides 4.1 - 4.29 ja 5.1 - 5.19 ning lisaks 4 vabalt valitud nõuet vastavustabeli punkti 4.30 alapunktidest. Siinkohal juhime tähelepanu, et vastavustabelis küsitud videofail ja video ajaline viide tuleb esitada nõuete täitmise tõenduseks kõikidele vastavustabeli punktide 4.1-4.29 ja punkti 4.30 alapunktide osas, mille kohta pakkuja soovib tõendada pakutava süsteemi funktsionaalsuse olemasolu (olgu siis nõude täitmiseks või hindamisel lisapunktide saamiseks). Vastavustabelis toodud info põhjalt kontrollib hankija esitatud andmete õigsust sisuliselt ja teeb sisulise kontrolli põhjal otsuse pakkumuse vastavuse või mittevastavuse kohta.“ Kuigi Vaidlustaja on pakkumusele lisatud „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabelis“ kinnitanud RHAD-s esitatud kohustuslike- ja valiknõuete täitmist, tuvastas Hankija, et vaid osad Vaidlustaja kinnitused vastasid tõele. Hankija on oma seisukohad koos põhjendustega pakkumuse tagasilükkamise protokollis ka välja toonud. Hankija hinnangul on Vaidlustaja pakkumuse esitamisel väga hästi aru saanud, mida tuli esitada ja millised tingimused pidid olema täidetud, kuid lootis, et Hankija ei teosta sisulist kontrolli ega kontrolli tegelikkuses RHAD nõuete täidetavust, mistõttu on vaidlustuses esitatud argumendid „vabadest kätest otsustamaks, kuidas ja mida esitada“ ilmselgelt otsitud. 5.6. Vaidlustaja on eeldanud, et Hankija võib pakkumuse vastavuse kontrolli teostades 11 (26) piirduda pakkuja kinnituste olemasolu kontrollimisega ja uskuda pakkuja antud kinnitusi tarkvaralahenduse vastavuse osas, sest küll lepingu täitmise käigus seadistatakse ja konfigureeritakse pakutud tarkvaralahendus Hankija vajadustele sobivaks. Nii see ei ole. Vastasel juhul kaoks igasugune mõte nõuda pakkujatelt demovideo esitamist ja demokeskkonnale juurdepääsu. Lisaks sätestas RHAD (nii tehnilise kirjelduse p 3.2 kui hankelepingu p 1.3.3) üheselt, et pakutud lahenduse paigaldab ja seadistab tellija ise, mitte täitja. Lepingu täitmise käigus ei toimu täitjapoolset seadistamist ega konfigureerimist. Täitja vaid juhendab tellijat paigaldamisel. Lisaks eksitab Vaidlustaja oma vaidlustuses vaidlustuskomisjoni terminite „seadistamine“ ja „konfigureerimine“ kasutamisega. 5.7. Vaidlustaja on nii pakkumuses kui vaidlustuses korduvalt kinnitanud, et Vaidlustaja poolt pakutud Elastic on platvorm, mille peale saab palju asju ehitada. Kuid oma väidete tõendamiseks ei ehitanud Vaidlustaja oma pakkumuses sellele platvormile sellist toodet, mida Hankija Riigihankega ostma läks. Oluline on eristada ja aru saada, et Hankija läkski ostma endale vajalike funktsionaalsustega toodet, mitte platvormi, kuhu saaks hakata nõutud funktsionaalsust tulevikus looma. Vaidlustaja leiab oma vaidlustuse p-is 2.4, et Vaidlustaja pakutud tarkvaraplatvormil on RHAD-s nõutud võimekus, kuid Vaidlustaja ei pidanud vajalikuks seda Hankijale pakkumusega tõendada. Vaatamata eeltoodule kinnitab Vaidlustaja veendunult, et kui Vaidlustaja pakkumus edukaks tunnistada, siis toimib platvorm täpselt nii nagu RHAD-s nõutud. Esitatud pakkumuste vastavuse kontroll selliselt ei toimi. Hankija peab veenduma pakkumuse vastavuses pakkumuste esitamise kuupäeva seisuga, Hankija ei saa hinnata RHAD nõuete täitmist hankelepingu sõlmimise ajal. 5.8. Nõue 4.8: Andmeelementide tuvastamine Vaidlustuse p-is 2.6. on Vaidlustaja juhtinud tähelepanu, et Hankija on kasutanud ekslikku viidet samanimelisele tarkvarale. Kahjuks Vaidlustaja ei kajastanud oma pakkumuses GROKi kui süsteemi osa, samuti ei täpsustanud Vaidlustaja Hankija täpsustavale selgitustaotlusele antud vastustes GROKi paiknemist Elasticu süsteemis ega viidatud asjakohasele dokumentatsioonile. Arvestades asjaoluga, et Vaidlustaja viitas veebilingile https://www.elastic.co/docs/reference/logstash/plugins/plugins-filters-grok esmakordselt alles vaidlustuses, tuvastas Hankija, et tegemist on lisandmooduliga, mida eelkõige kasutatakse struktureerimata logimisandmetest huvipakkuvate elementide leidmiseks. GROKi olemasolevatest vastavusmustritest saaks kasutada kuupäeva tuvastust, kuid mitte teiste „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabeli“ Nõudes 4.8 nimetatud andmeelementide tuvastamist. Lisandmooduli GROKi kasutamine eeldab, et iga andmeelemendi tuvastamiseks on vaja koostada eraldi koodilõik (täiendav arendustöö), nagu pakkumuse tagasilükkamise protokollis märgitud. Sellest tulenevalt on Hankija järeldus siiski korrektne, et Nõude 4.8 kirjeldatud funktsionaalsus veel ei sisaldu pakutavas süsteemis, mistõttu Nõue 4.8 on täitmata. Vaidlustuse alamp-is 2.6.3. Vaidlustaja ka ise tunnistab, et „tootes on olemas võimekus ja vajalikud mustrid koostatakse paigalduse osana. See ongi selliste platvormide tööpõhimõte“. 12 (26) Nõutud funktsionaalsuse programmeerimist tarkvara paigalduse käigus ei saa nimetada konfigureerimiseks. Hankija ei ole seadnud piirangut platvormipõhise tarkvaralahenduse pakkumisele, kuid kõigile pakkujatele võrdsete aluste ning Hankijale tarkvara kasutatavuse tagamiseks olid kehtestatud konkreetsed funktsionaalsed nõuded. Nende nõuete täitmiseks mõnele pakkujale pikema tähtaja andmine rikuks nii pakkujate võrdse kohtlemise põhimõtet kui ka Hankija tegevuse kontrollitavuse ja läbipaistvuse põhimõtet (RHS § 3). 5.9. Nõue 4.10: Andmesubjekti tuvastamine Hankija ei ole ühegi pakutava tarkvara/platvormi spetsialist. Hankijal ei ole iseenesest spetsiifilisi teadmisi pakutavast tarkvarast. See on pakkuja ülesanne – demonstreerida Hankijale arusaadavalt pakutava tarkvara vastavust Hankija esitatud nõuetele. Hankija on ostja ning Hankijal peab tekkima veendumus, et ostetav toode vastab tema esitatud nõuetele. Sellepärast oli Riigihankes ka tingimus, et funktsionaalsuste kontrollnimekirja kõrval oleks ka demovideod ja demokeskkond, mis koos või eraldi võimaldavad Hankijal veenduda vastava nõude täidetuses. Kui demokeskkonnas või -videos nõutavat funktsionaalsust ei esitleta ja seda ei tehta ka täpsustavate selgitustaotluste peale, siis ei ole Hankijal võimalik saada kinnitust, et vastav funktsionaalsus on ka tegelikult tarkvaralahenduses olemas. Vaidlustuse alamp-is 2.7.4. väidab Vaidlustaja, et „on ebamõistlik eeldada, et pakkuja peaks looma keeruka, hankija vajadusi simuleeriva andmekogu ja seadistama selle baasil täisfunktsionaalse lahenduse pelgalt demo eesmärgil, eriti kui hankija andis ise pakkujale vabad käed näidisandmete loomiseks“. Hankija juhib tähelepanu faktile, et pakkumuse üheks osaks oli Eesti äriregistri avaandmete kasutamine (vaata tehnilise kirjelduse p 6.3), mis andis hea aluse demo jaoks kasutatava andmekogu loomiseks. Kuna äriregistri andmed ei ole sobilikud kõigi funktsionaalsete nõuete demonstreerimiseks või selle struktuuri eripärad võivad muuta demo ettevalmistamise töömahukamaks, siis tõepoolest lubas Hankija pakkujatel demo jaoks kasutada kas osaliselt või täielikult omaloodud näidisandmeid. Vastupidiselt vaidlustuse alamp-is 2.7.5. väidetule, mille kohaselt RHAD-s polevat seatud konkreetseid, mõõdetavaid demo-nõudeid, on Hankija vastupidisel seisukohal. Tehnilise kirjelduse p-is 4.10 on toodud näitlik loetelu, milliseid isikusamasuse vastavusi peab tarkvara olema suuteline tuvastama ning vastavalt tehnilise kirjelduse p-ile 6.2 pidi pakkuja esitatav videopresentatsioonilt olema näha kõigi funktsionaalsete nõuete täitmise lahendus. Vaidlustaja näitas oma pakutud tarkvaralahendusega erinevate nimekujude üheks isikuks kokku liitmist, kuid nõutud oli eri nimekujude sarnasuse tuvastamist. Seega on ilmne, et Vaidlustaja ei täitnud RHAD-s esitatud nõuet. 5.10. Nõue 4.24: Agregeerimine rakenduse graafil Funktsionaalse Nõude 4.24 demonstreerimise pealt pakkumuses ja vaidlustuse p-i 2.8 pealt jääb Hankijale mulje, et Vaidlustaja ei ole mõistnud, mis tüüpi tarkvaralahendust Riigihankes osta soovitakse. Hankijale jääb mulje, et Vaidlustaja arvab, et osaletakse universaalse analüüsitarkvara hankel, kus on vaja võimalikult laia funktsionaalsuse platvormi koos klassikalise ärianalüüsi (Business Intelligence) (edaspidi BI) väljundiga. Millest omakorda on siis üks visuaali võimalus kuvada andmeid võrgustiku kujul. Sarnaseid väljundeid ja funktsionaalsusi, nagu vaidlustuse alamp-is 2.8.2 toodud uutel linkidel kuvatud, pakuvad paljud erinevad BI tööriistad, s.h. võrgustiku kujul visuaali. Näiteks: Microsofti Power BI tarkvara võimaldab ka andmeid erineval kujul võrgustikuna visualiseerida, kuid see ei ole 13 (26) võrgustikanalüüsi tööriist. Riigihange on võrgustikuanalüütika tarkvara, mitte ärianalüüsitarkvara hange. Seetõttu ongi oluline eristada, et Riigihankes ei käsitleta võrgustikku kui ühte paljudest andmete visualiseerimise viisidest, vaid fookuses on võrgustikuanalüüs kui omaette analüütika meetod koos sellele omase spetsiifikaga nii funktsionaalsuses, andmete ladustamises kui ka visualiseerimises. Erinevalt Vaidlustaja arvamusest vaidlustuse alamp-is 2.8.2, et Hankija ajab segamini andmete agregeerimise protsessi ja selle visualiseerimise, siis nii see kindlasti ei ole. Hankija teeb neil asjadel väga hästi vahet ning Hankija jaoks ongi antud pakkumuses oluline, kus ja kuidas toimub agregeerimine. Sellepärast on ka tehnilise kirjelduse p-is 4.24 öeldud, et agregeerimine peab olema võimalik rakenduse graafil. Ja „rakenduse graaf“ tähendab RHAD-is läbivalt võrgustiku graafi, mitte suvalist graafikut (joon- või tulpdiagrammi või pirukat vms.). Hankija juhib tähelepanu, et ühelgi teisel Riigihankes osalenud pakkujal ei olnud antud asjast arusaamisel raskusi. Seega vaidlustuse alamp-is 2.8.2. tuleb selgelt välja Vaidlustaja poolt segiajamine ärianalüüsi ja võrgustikuanalüüsi töömeetodite olemuse vahel. Vaidlustuses kirjeldatud esmalt andmete agregeerimine ja siis nende esitlemine mistahes esitlusgraafikul on iseloomulik ärianalüüsile. Võrgustikuanalüüsis toimub uurimistöö visuaalsel graafil seoste võrgustikuna esitletud andmetega, kus tähenduslikkuse leidmiseks on sageli vaja teatud üheliigilisi andmeid agregeerida. Vaidlustaja selgitused ega vaidlustuses viidatud veebilinkidelt leitav dokumentatsioon ei kinnita pakutud tarkvaralahenduses RHAD-s nõutud funktsionaalsuse olemasolu. 5.11. Nõue 4.25: Võrgustiku statistikud Vaidlustaja ei ole mõistnud, millise tarkvara(lahenduse) Riigihankel osaletakse. Tehnilise kirjelduse p-is 4.25 on nõutud statistikuid, mis on iga teise võrgustikuanalüüsi tarkvara standardpaketi osa. Nende kohta ei saa kindlasti öelda, et neid ei ole võimalik nupuna kuvada „nende arvutusliku keerukuse tõttu“ nagu on toodud vaidlustuse alamp-is 2.9.3. Vaidlustaja kinnitab antud alamp-is taas, et ta ei pakugi ei võrgustikuanalüüsi tarkvara ega valmis toodet. Ehk Vaidlustaja ise kinnitab, et ta ei paku asja, mida Hankija läks Riigihankega hankima. Vaidlustuse p-is 2.9 Vaidlustaja sarnaselt mitmetele teistele vaidlustuse punktidele ja Hankija täpsustavale selgitustaotlusele antud vastuses püüab RHAD konkreetsele nõudele pakkuda midagi ligilähedast. Nii ka siinkohal, tehnilise kirjelduse p-is 4.25 nimetatud võrgustikuanalüüsi funktsioonide asemel, kiidab Vaidlustaja oma tarkvaraplatvormi lahenduste headust. Hankija ei võta seisukohta, kas ja kui head need alternatiivid on, vaid tõdeb, et RHAD-s esitatud nõue ei ole täidetud. 5.12. Nõuet 4.30: Visualiseerimise valiknõuded Vaidlustuse p-iga 2.10 ja selle alamp-idega ilmneb taas, et Vaidlustaja ei ole mõistnud, millise tarkvaralahenduse Riigihankega antud juhul tegu on. Vaidlustuses on taas segi aetud, mis on nn klassikaline analüüsitarkvara koos sinna juurde käiva BI lahendusega ja mis on võrgustiku ehk elementide vahelise seoste analüüsi tarkvara. Tehnilise kirjelduse p-is 4.30 loetletud valiknõuded on peaaegu kõik võrgustikuanalüüsi 14 (26) tarkvarade tüüpelemendid, mille puhul ei peaks olema mingit vajadust täiendavaks arendamiseks. Kuna kõik nõutud elemendid ei pruugi olla kõigi võrgustikanalüüsi vahendite standardlahenduse osa, siis sellepärast oli ka nõue, et pakutav lahendus peab vastama vähemalt 4-le tingimusele 11-st. Vaidlustaja suutis video ja demokeskkonnaga demonstreerida vastavust 2-le tingimusele. Vaidlustuse alamp-is 2.10.3. ei kritiseeri Vaidlustaja hankija hinnangut pakkumusele, vaid tehnilise kirjelduse alamp-i 4.30.1 sisulist olemust: „Hankija nõuab sisuliselt valmis, treenitud tehisintellekti lahendust, mis on ebareaalne ootus riigihanke pakkumuse faasis.“ Vaidlustaja ei ole vaidlustanud Riigihanke alusdokumente, mistõttu tuleb neid täita. Hankija ei nõudnud tehisintellektil põhineva lahenduse kasutamist. Kuid sõltumata funktsionaalsuse realiseerimiseks kasutatud tehnoloogilisest lahendusest, peab pakutav tarkvaralahendus vastama Riigihankes esitatud nõuetele pakkumuste esitamise kuupäeva seisuga. Vaidlustuse alamp-is 2.10.5. ei arvesta Vaidlustaja tehnilise kirjelduse alamp-i 4.30.2 olemust. Nõutud on, et rakenduse graafil, mis on analüütiline tööriist võrgustiku seoste ja elementide interaktiivseks uurimiseks, peab saama kasutaja graafi elemente – antud juhul andmesubjekti – teistest eristamiseks suuremaks või väiksemaks muuta. Antud nõude täitmiseks viitas Vaidlustaja oma vaidlustuses Canvas dokumentatsioonile ehk tarkvaralahenduse täiendavale moodulile. Vaidlustaja pakkumuses antud viide puudub. Vaidlustaja demovideo näitas aga vaid kogu kuva suumimist. Vaatamata eeltoodule märgib Hankija, et vaidlustuses viidatud Canvas ei ole mitte analüüsi-, vaid esitlusmoodul, mida kinnitab vaidlustuses viidatud veebilehe avalause: „Canvas is a data visualization and presentation tool …“. See võimaldab kujundada esitlusgraafikuid, kuid ei aita andmeanalüütikul teostada interaktiivset võrgustiku uurimist, mida viiakse läbi Vaidlustaja pakutava tarkvaralahenduse teises moodulis Graph (vt seisukohadele lisatud joonis 1 - Hankija on punase allakriipsutusega esile toonud menüüvalikus moodulite Canvas ja Graph lingid.). Seega ka täiendava info valguses on selge, et RHADi nõue on täitmata. Vaidlustuse alamp-is 2.10.7. apelleerib Vaidlustaja oma tarkvaraplatvormi laiale võimekusele, kuid ei tõenda, kuidas tarkvara lõppkasutaja saab analüütilisel graafil agregeerida või uuesti lahku eristada võrgustiku andmesubjekte. Vaidlustuse alamp-is 2.10.9. viitab Vaidlustaja oma tarkvaraplatvormi veel ühele moodulile Dashboards, mis mõnevõrra sarnaselt mooduliga Canvas võimaldab luua ja soovi korral samale töölehele paigutada erinevat tüüpi esitlusgraafikuid, kuid see ei aita andmeanalüütikul teostada interaktiivset võrgustiku uurimist, mida viiakse läbi Vaidlustaja pakutava tarkvaralahenduse teises moodulis Graph (vt joonis 1). Hankija andmeanalüütikul on vajadus oma uurimistöö käigus nö jooksvalt vahetada võrgustiku graafi tüüpi, et paremini märgata võimalikke uusi nn mustreid andmetes. Kummaski nimetatud moodulis pole võimalik teostada eelnimetatud toiminguid ehk võrgustiku visuaalsel graafil pidi saama teha neid konkreetseid toiminguid, mida Hankija tehnilises kirjelduses nõudis. Vaidlustuse p-is 2.10.9 demonstreerib Vaidlustaja ilmekalt, et ta räägib klassikalisest tänapäeva BI tarkvarast. Vaidlustaja kirjeldab seal BI tarkvara funktsionaalsust. Hankija läks aga Riigihankega ostma võrgustikuanalüüsi tarkvara. 5.13. Võrgustikuanalüütika nö karbitooted ehk valmis tarkvarapaketid on arendatud 15 (26) spetsiifiliselt võrgustike analüüsiks vajalike funktsionaalsustega. Neid funktsionaalsusi on erinevate klientide poolt praktikas rakendatud aastaid, mille käigus ilmnenud puudusi on tarkvaratootjad arvesse võtnud tarkvara täiustamisel. Vaidlustaja poolt pakutav nö platvorm on väidetavalt võimeline pakkuma analoogseid funktsionaalsusi, kuid mitmed Hankija poolt kohustuslikult nõutud funktsionaalsused vajavad kasutamiseks alles arendamist, rääkimata testimisest ja kasutamise käigus ilmneda võivate muudatusvajaduste sisseviimisest. Vaidlustaja poolt korduvalt nimetatud „paigaldamise käigus toimuv seadistamine ja konfigureerimine“ tähendab tegelikult tarkvara arendustööd, kus Hankija osutub testijaks ja halvemal juhul ka arendajaks, kuna hankelepingu kohaselt piirduvad pakkuja kohustused tarkvara paigaldamise nõustamisega ja Hankija töötajate koolitamisega. 5.14. Vastavalt väljakujunenud vaidlustus- ja kohtupraktikale tuleb pakkumus tagasi lükata, kui pakkumus ei võimalda Hankijal tuvastada, kas see võimaldab hankelepingu nõuetekohast täitmist (Tartu Ringkonnakohus 04.09.2015, 3-15-1587, p 12; VAKO 08.09.2017, 125- 17/188223, p 18; 03.10.2017, 146-17/186866, p 13). Antud juhul on FOB Solutions OÜ pakkumus koostatud sedasi, et selles esitatud andmete pinnalt ei ole kuidagi võimalik veenduda, kas pakutav tarkvaralahendus vastab RHAD nõuetele ja võimaldab seeläbi hankelepingu nõuetekohast täitmist. 5.15. Hankija täiendavad seisukohad. 5.15.1. Vaidlustaja täiendava seisukoha p 2.2. käsitleb karbitoote ja platvormi tehnilist erinevust. Hankija sätestas RHAD-s nõuded, mida pakutav süsteem peab täitma. Et mitte piirata pakkujate võimalusi Riigihankel osaleda erinevalt lahendatud süsteemide korral, siis oli tehnilise kirjelduse p-is 2 kirjas: „kuna tarkvaratootjatel on erinevaid lähenemisi toodete kompaktsuse ja modulaarsusega, siis ei pruugi kõik hankija soovitud nõuded olla lahendatud ühtses rakenduses. Hanke dokumentatsioonis on seetõttu kasutatud termineid analüütikatarkvara, süsteem ja rakendus. Süsteemi all peame silmas kõiki nõudeid täitvat terviklikku lahendust, mis ei pruugi koosneda ainult analüütikatarkvarast. Rakendus omakorda võib olla vaid lõppkasutajale mõeldud kasutajaliides analüütikatarkvarast.“ Seega võisid pakkujad pakkuda nii karbitoodet kui ka erinevad platvorme või süsteeme, kuid arvestada tuli sellega, et täita tuli tehnilise kirjelduse p-is 4 toodud tingimused. Seega Hankija ei nõudnud nö karbitoodet nagu väidab Vaidlustaja, kuid RHAD-s sätestatud osa funktsionaalsetest nõuetest peab olema lõppkasutajale kasutatav rakenduse graafil. Karbitoodetel on see tavapärane, platvormide pakkumise korral oleks pakkujal tulnud nõutud funktsionaalsused koondada ühtsesse kasutajaliidesesse ja tõendada demovideol nende töötamist ja vastavust RHAD-le. Riigihanke tehnilises kirjelduses kõiki nõutud funktsionaalsusi Vaidlustaja pakutud platvormil ei esinenud, sh neid, mis pidid olema rakenduse graafil. 5.15.2. Vaidlustaja ajab oma seisukoha p-is 2.3 jätkuvalt segamini funktsionaalsed nõuded ja demoandmed. Hankija selgitused „vabadest kätest“ ei olnud mitte funktsionaalsete nõuete täitmiseks, vaid funktsionaalsuse toimimise kinnitamiseks kasutatavate andmete kohta. Hankija andis pakkujale vabad käed milliseid andmeid kasutada funktsionaalsuse tõendamiseks, mitte ei andnud vabu käsi milliseid funktsionaalsusi lahendada. Isegi, kui Hankija selgitused oleks vastuolus RHAD-s toodud nõuetega, siis RHS § 46 lg-st 3 tulenevalt ei muuda selgitused RHAD. Hankija kinnitab, et Riigihankes antud selgitused ei 16 (26) ole RHAD-ga vastus. 5.15.3. Vaidlustaja vaatab seisukoha p-is 2.4 mööda RHAD nõudest, mille kohaselt pakutav tarkvaralahendus peab olema valmis arendatud ja täitma funktsionaalseid nõudeid. Kui Hankijal ei ole võimalik pakkumuse põhjal veenduda, et pakutav tarkvaralahendus täidab tehnilises kirjelduses nõutud funktsionaalseid nõudeid, sest need ei ole veel „seadistatud“, peab Hankija pakkumuse tagasi lükkama, sest pakkumus ei vasta RHAD-s toodud tingimustele. 5.15.4. Vaidlustaja seisukoha p 2.5 käib spetsiifiliste võrgustikuanalüüsis kasutatavate funktsioonide kohta. Hankija möönab, et võrgustikuanalüütikas on kasutusel palju erinevaid funktsioone, kuid Hankija lähtus RHAD nõuete koostamisel oma vajadustest. RHAD-s loetletud võrgustikuanalüüsi funktsioonid on rahvusvaheliselt üldlevinud. Hankijal ei ole midagi selle vastu, kui pakutav tarkvara võimaldab kasutada ka teistsuguseid lahendusi, kuid RHAD kohustuslikud nõuded on vähim, mis pakkumuses peab olema täidetud. Ja Vaidlustajal ei olnud need nõuded täidetud. Vaidlustaja ei saa „ägedamate“ lahenduste pakkumistel jätta täitmata RHAD-s esitatud nõuded. Veelgi enam, tegemist on vaid lubadustega, mida Vaidlustaja sooviks realiseerida/Hankijale pakkuda hankelepingu täitmisel. 6. Kolmas isik, STATS Unities OÜ, vaidlustusega ei nõustu ja palub selle jätta rahuldamata. 6.1. Kolmas isik leiab, et Hankijal on õigus otsustada, mida ta hangib. RHAD ei jäta kahtlusi selles, et hangitakse võrgustikuanalüütika tarkvara. Termin võrgustik viitab siinjuures olemite (nt isikute, spetsiifiliste andmete) võrgustikule. Spetsiifilise võrgustikuanalüütika tarkvara hankimine kajastub ka tehnilise kirjelduse p 5, milles on toodud, et „pakutav analüütikatarkvara võib koosneda mitmetest komponentidest, kuid need peavad olema integreeritud tõrgeteta koostoimivaks süsteemiks.“. Juhul, kui Riigihanke tingimused rikkunuks Vaidlustaja õigusi, pidanuks vaidlustama RHAD- d (RHS § 185 lg 2 p 1). Vaidlustaja seda ei teinud ja vastav võimalus on tänaseks minetatud (RHS § 189 lg 1). 6.2. Vaidlust ei tohiks olla selles, et Vaidlustaja pakutav tarkvara ei ole võrgustikuanalüütika integreeritud tõrgeteta koostoimiv süsteem. Asjaolu, et Vaidlustaja võib pakkuda kaasaegset analüütikaplatvormi, ei tähenda, et spetsiifilisem rahapesu andmebüroo jaoks vajaliku funktsionaalsusega analüütikatarkvara ei oleks kaasaegne. Tõdemust, justkui peaks kaasaegsed organisatsioonid eelistama üldisemaid tarkvaraplatvorme ja mitte nn karbilahendusi, ei eksisteeri ja suund on tegelikkuses hoopis vastupidine. Nn karbitarkvara kasutuselevõtuga säästetakse organisatsiooni ressursse (sh oluliselt just organisatsiooni IT osakonna ressursid). Asjaolu, et rahapesu andmebüroode tegevuse tarbeks on arendatud spetsiifilised tarkvaratooted, annab tunnistust sellest, et turu suund ongi spetsiifilise tarkvaratoote kasutuselevõtule. Arvestades, et süsteemi hakkavad lõppkasutajatena kasutama rahapesu uurijad, on igati mõistlik hankida spetsiifiline kergesti käsitsetav vastav tarkvara. Seega pole õige ega tõendatud Vaidlustaja väide, nagu pakuks Vaidlustaja lahendust, mis on „olemuslikult parem.“ 17 (26) 6.3. Vaidlustaja on vaidlustuses mitu korda viidanud, et Vaidlustaja pakkumus sisaldab ka paigaldust, mille käigus vastav funktsionaalsus Hankija vajadustest lähtuvalt seadistatakse. Vaidlustuses on toodud, et „Kõik hankija poolt mittevastavaks tunnistatud punktid on tegelikult täidetud läbi pakutava Elastic platvormi standardse ja dokumenteeritud funktsionaalsuse, mis rakendatakse vaidlustaja poolt osutatava paigaldusteenuse käigus.“. Tehnilise kirjelduse kohaselt ei ole pakkujate poolset paigaldusteenust hangitud. Tehniliste kirjelduse p 3.2 toodult kujutab hangitava tarkvara paigaldamine ja liidestamine Hankija poolt ja pakkuja üksnes „juhendab RmIT-i DevOps insenere analüütikatarkvara RmIT Azure pilve keskkonda paigaldamisel, konfigureerimisel ja RAB-i andmelaoga liidestamisel, et tagada andmete sünkroonsus ja tellija vajadustele vastav süsteemi töötamine.“. Kolmas isik ei näe, et Vaidlustaja poolt pakutava analüütikaplatvormi kohandamist rahapesu andmebüroo tegevuseks saaks nimetada selliseks tarkvara paigaldamiseks või konfigureerimiseks, mida on silmas peetud hankes. Selline konfigureerimine oleks tegelikkuses ulatuslik disainimine ja rakendamine (vt kõik Hankija poolt tehnilise kirjelduse p-is 4.8 kirjeldatud andmeelemendid, visualiseerimise nõuded jne), suure töömahuga teenus (mida pole hangitud), mille jaoks peaks Hankija kulutama olulist inim-, aja- ja finantsilist ressurssi. 6.4. Hankija tegutses igati õigesti, kui soovis näha iga soovitava funktsionaalsuse töötamist, sealhulgas klikkidega otse user-interface’il ehk kasutajaliideses. Kui aga Vaidlustaja ei ole kasutajaliidest valmiskujule teinud, siis puudus Hankijal ka võimalus kontrollida kõigi vajalike funktsionaalsuste töötamist. 6.5. Vaidlustaja nõuab vaidlustuses endale pakkumuse soodsamaid tingimusi. Kolmanda isiku arvamusel olid Riigihanke demo nõuded üksikasjalikud (nt esitada tuli video ning tabel iga vastavusnõude demonstreerimise ajahetke kohta) ja Hankija eesmärk nõudmisel oli (peale funktsiooni olemasolu kontrollimise) ka hinnata süsteemi kasutamise lihtsust, et anda kvaliteedipunkte (vt hindamismetoodika kirjeldus). 6.6. Tehnilise kirjelduse ptk 3.3 on toodud koolitusnõuded näevad ette Hankija paigaldus- ja hooldusmeeskonna koolitamise kolme nädala jooksul lepingu sõlmimisest, juhendmaterjalide alusel, kusjuures Hankija DevOps insenerid peavad omandama oskuse juhendmaterjalide alusel süsteemi paigaldamiseks, andmeallikate liidestamiseks ja süsteemi konfigureerimiseks. Kolmandale isikule ei ole selle teostamine kujutletav, kui Vaidlustajal oleks lepingu sõlmimisel olemas ainult üldine analüütikaplatvorm, mille peale hakata kasutajaliidest alles arendama. Vaidlustaja vajanuks tegelikkuses ulatuslikku aega disaini- ja arendustöödeks selleks, et üldisest analüütikaplatvormist teostada võrgustikuanalüütika keskkond. Tegemist on väga spetsiifilise kasutajaliidesega, mis liidestatakse mitmete Hankija andmebaasidega ja selle väljaarendamine ei ole mõstagi nii lihtne, nagu Vaidlustaja proovib esitada. Lõppkasutajate (uurijate) koolituse tingimuseks on Riigihanke tehnilises kirjelduses toodud, et „Koolituse tulemusena lõppkasutajad omandavad oskuse võrgustikuanalüüsi läbiviimiseks ning on võimelised kasutama rakendust kogu funktsionaalsete nõuete ulatuses.“. Arvestades, 18 (26) et Vaidlustaja pakub üldist analüütikatarkvara, ei ole usutav, et tal on võimekus pakkuda nimetatud sisulist koolitust. VAIDLUSTUSKOMISJONI PÕHJENDUSED 7. Vaidlustaja pakkumuse tagasi lükkamise otsuse õiguspärasuse kontrollimine 7.1. Hankijal on RHS § 114 lg 2 esimeses lauses sätestatud õigus pakkumus tagasi lükata juhul, kui pakkumus ei vasta vähemalt ühele riigihanke alusdokumentides sätestatud tingimusele. Lahendades käesoleval juhul vaidlust RHS § 114 lg 2 esimese lause alusel tehtud Vaidlustaja pakkumuse tagasilükkamise otsuse üle tuleb vaidlustuskomisjonil tuvastada, kas Riigihanke alusdokumentides (edaspidi RHAD) on sätestatud tingimus, millele Hankija Vaidlustaja pakkumuse tagasilükkamisel tugines ning kui on, siis kas Vaidlustaja pakkumus sellele tingimusele vastab või mitte. 7.2. 28.10.2025 otsusega on Hankija Vaidlustaja pakkumuse tagasi lükanud. Hankekomisjoni 27.10.2025 allkirjastatud protokollis on välja toodud mittevastavused järgmistele Lisa 4 „Hanke tehniline kirjeldus“ (edaspidi TK) nõuetele ja vastavad põhjendused: 1) Nõue 4.8 2) Nõue 4.10 3) Nõue 4.24 4) Nõue 4.25 5) Nõue 4.30.1 6) Nõue 4.30.2 7) Nõue 4.30.10 8) Nõue 4.30.11 Vaidlustaja pakkumuse mittevastavus Nõutele 4.8, 4.10, 4.24 ja 4.25 on tuvastatud Vaidlustaja pakkumuses sisalduva demovideo ja süsteemi demokeskkonna ning Vaidlustaja Hankijale antud selgituste alusel: 1) Nõudes 4.8 kirjeldatud funktsionaalsus veel ei sisaldu Vaidlustaja pakutavas süsteemis, Vaidlustaja realiseeriks nimetatud funktsionaalsuse süsteemi paigalduse osana; 2) Hankija ei saanud kinnitust, et Nõue 4.10 on täidetud; 3) Hankija ei saanud kinnitust, et Nõue 4.24 on täidetud; 4) Nõue 4.25 on täitmata, sest pakutud süsteem ei sisalda võrgustikku iseloomustavaid funktsioone nagu näiteks tsentraalsus (centrality), tihedus (density), vahendatus (betweenness) ja lähedus (closeness). Nõuete 4.30.1, 4.30.2, 4.30.10 ja 4.30.11 osas on protokollis põhjendused ja selgitus, et Vaidlustaja pakkumuses ei ole täidetud Nõude 4.30 loetletud valiknõuetest vähemalt 4, 6-st valiknõudest vastas esitatud tingimustele vaid 2. Vaidlustaja on seisukohal, et tema esitatud pakkumus hõlmas nii litsentsi kui ka paigaldustöid, mis tagavad kõigi nõuete täitmise - kui tootes on võimekus olemas ja selle seadistamine on osa paigaldusest, on kõik nõuded täidetud, Hankijal tuli lähtuda Vaidlustaja kinnitusest, et vastav võimekus on Vaidlustaja pakutud tarkvaraplatvormi Elastic olemas. 19 (26) Vaidlustuskomisjon on seisukohal, et Vaidlustaja on saanud TK nõuetest valesti aru (või nii nagu Hankija arvas – Vaidlustaja ei eeldanud, et Hankija sisuliselt pakkumuse vastavust RHAD-le kontrollima hakkab). Vaidlustuskomisjon ei nõustu Vaidlustajaga, et Riigihankes ei pidanud pakkuja tõendama pakkumuse vastavust TK-s toodud nõuetele oma pakkumuses. 7.3. TK p-is 3 on toodud sõlmitava hankelepingu esemed: 1) analüütikatarkvara kasutusõigused ( TK p 3.1); 2) analüütikatarkvara paigaldamine ja liidestamine (TK p 3.2); 3) koolitamine (TK p 3.3). TK p-is 4 on toodud süsteemi/rakenduse funktsionaalsed nõuded (sh on sätestatud, et Punktis Tõrge! Ei leia viiteallikat. loetletud valiknõuetest peavad olema täidetud vähemalt 4 (neli) nõuet. Valiknõuete täitmise osakaal mõjutab pakkumuse hindamistulemust.). TK p-is 5 on toodud süsteemi mittefunktsionaalsed nõuded. TK p 6 on sõnastatud järgmiselt: „6.1 Nõuetele vastavuse hindamiseks esitab pakkuja Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabel.xlsx vastavustabeli, märkides ära, millised nõuded on täidetud. 6.2 Lisaks peab Pakkuja esitama üldlevinud failiformaadis videopresentatsiooni, millel on näha vaid kõigi funktsionaalsete nõuete täitmise lahendus. Punktis 6.1 nimetatud vastavustabelis peab iga funktsionaalse nõude juures olema viide video ajakavale, mitmendal minutil ja sekundil vastava nõude täitmise esitlus algab ja vajadusel viide videofaili nimele. Video kogupikkus ei tohi olla rohkem kui 1,5 tundi. Kui videos on oluline suuline või tekstiline selgitus, siis peab see olema kas eesti või inglise keeles. 6.3 Pakkumuste avamise kuupäevaks peab olema Hankijale avatud pakutava tarkvara demokeskkond Azure platvormil, kuhu on integreeritud Eesti äriregistri avaandmed (lihtandmed, üldandmed, registrikaardid, kaardile kantud isikud, osanikud)2.“ TK p-is 6 sätestatud nõuded on toodud ka „Vastavustingimustes“. Seega lisaks „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabelile“ (TK p 6.1), kus märgitakse seda, kas nõue on täidetud ja viidatakse kohale esitatud videos, kus nõude täitmine on nähtav (TK p 6.2), tuli pakkujal pakkumuses esitada videopresentatsioon kõigi funktsionaalsete nõuete täitmise lahenduse kohta ja pakkumuse avamise kuupäeval pidi Hankijale olema avatud pakutava tarkvara demokeskkond Azure platvormil. Vaidlustuskomisjon on seisukohal, et pakkujatele, st Vaidlustajale, pidi TK-st ja „Vastavustingimustest“ olema selgelt aru saadav, et pakkumuses ja demoversioonis pidi olema tõendatud vastavus kõigile TK p-is 4 toodud süsteemi/rakenduse funktsionaalsetele nõuetele, pidi olema esitatud iga nõude lahendus. 7.4. Vaidlustuskomisjon ei nõustu Vaidlustajaga selles, et Hankija on vastusetes selgitustaotlustele andnud pakkujatele nö „vabad käed“ otsustamaks, kuidas ja mida esitada. 2 https://avaandmed.ariregister.rik.ee/et/avaandmete-allalaadimine 20 (26) 02.04.2025 on Hankijale esitanud järgmine selgitustaotlus:3 „1. Kuidas või milliste demo andmete pealt näidata nõudes 4.30.1 tehingute ringahelate funtsionaalsust. Demo andmetes ei ole raha liikumiste andmeid, mille osas saaks seda demoda. Ehk palun tooge mingi näide/ärinõue/usecase, mis võiks demo andmete kontekstis olla sarnane tehingute ringahelate funktsionaalsusega. 2. Mida hankija on mõelnud nõudes 4.30.11 nimetatud graafi "tüübi" all. Palun selgitada näitega. 3.Punktis 4.25 Rakenduse graafil peab saama kasutada üldlevinud statistilisi ja võrgustikku iseloomustavaid funktsioone, s.h aritmeetiline keskmine, mood, detsiil, tsentraalsus (centrality), tihedus (density), vahendatus (betweenness), lähedus (closeness). Küsimus: Kas saaksite selle punkti kohta tuua näited demo andmete kontekstis, mida täpsemalt soovitud funktsionaalsuse all silmas peetakse 4. Punktis: 4.24 Rakenduse graafil peab saama agregeerida nii isikute, seoste kui ka tunnuste kaupa, kas läbi tunnuste määramise või graafil andmeelemente märgistades. Küsimus: Palun täpsustage/kirjutage lahti Demo andmete kontekstis, mis mõeldakse siin punktis "Seoste" ja "Tunnuste" all 5.Failis Funktsionaalsete ja mittefunktsionaalsete nõuete vastavaustabelis küsite kinnitust/mittevastavust nõuetele numbritega: 4.8 - 4.29 ja 5.1 - 5.19. Vastavuskriteeriumites punkt: Pakkuja esitab funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabeli, märkides ära, kas ja millised funktsionaalsed ja mittefunktsionaalsed nõuded on pakutava tarkvara näol täidetud. Nende nõuete numbritega ei tehta midagi ka kõrvaldamisealustes ega hindamiskriteerimites seega seda nõuet käsitletakse ainult vastavuskriteeriumites meie hinnangul Selleselt sõnastatud kriteeriumist loeme välja, et vastavuskriteeriumiks on selle tabeli esitamine täidetud infoga, kuid isegi kui ükski nõue ei ole täidetud, siis tuleks pakkumus endiselt vastavaks tunnistada selliselt sõnastatatud vastavuskriteeriumi suhtes, sest mingid mõõdikud ei ole defineeritud. Teeme ettepaneku antud vastavuskriteeriumit täpsustada selliselt, et Hankija defineeriks ikkagi mingi numbrilise miinimum väärtuse kui mitu nõuet peab olema "kinnitatud/jah" staatuses, et pakkuja vastavaks tunnistada. Vastasel juhul jääb mõistmatuks selliselt sõnastatud vastavuskriteeriumi olemus ja eesmärk, sest ka siis kui kõik nõuded on mitte vastavad, siis endiselt tuleks pakkuja vastavaks tunnistada 6.Kas hankija saaks veel anda ajalist pikendust 1 nädala ehk kuni 18.04“ Hankija on 7.04.2025 vastanud järgmiselt: „Edastame vastused esitatud selgitustaotlusele: 1. Hankija on pakkujatele jätnud vabad käed vajalike näidisandmete loomeks, vastamaks nõutud funktsionaalsuse demonstreerimiseks. Pakkuja võib lisaks äriregistri andmetele luua erinevat tüüpi informatsiooni, mis aitab demonstreerida hankija poolt nõutud funktsionaalsust (näiteks ettevõtete omavahelisi makseid). 2. Graafitüüpe on palju ja nende kohta kasutatakse mitmesuguseid erinevaid nimetusi. Hankija arvab, et enim võiksid tal töö käigus kasutust leida näiteks võrgustikudiagramm (social network chart), hajuvusdiagramm (scatter chart), ajajoone diagramm (timeline chart), radardiagramm (radar chart), statistiline kaart (map chart), Sankey diagramm. Kuid hankija ei ole püstitanud nõuet, millised neist peavad olema pakutavas süsteemis. 3. Hankija on pakkujatele jätnud vabad käed vajalike näidisandmete loomeks, vastamaks nõutud funktsionaalsuse demonstreerimiseks. Pakkuja võib lisaks äriregistri andmetele luua 3 Sõnumi ID: 949 836 21 (26) erinevat tüüpi informatsiooni, mis aitab demonstreerida hankija poolt nõutud funktsionaalsust. 4. Tuginedes äriregistri andmetele saavad olla: “Seosed” näiteks - ühe ettevõtte osalus mitmes ettevõttes - füüsilise isiku osalus mitmes ettevõttes, kas juhatuses või omanikuna - mitme ettevõtte registreerimine samale aadressile “Tunnused” näiteks - ettevõtte vanus ehk aeg registreerimise kuupäevast - ettevõtte aastakäive Loetelu ei ole ammendav, hankija on pakkujatele jätnud vabad käed vajalike näidisandmete loomeks, vastamaks nõutud funktsionaalsuse demonstreerimiseks. 5. Vastavustabel on nii pakkujale kui hankijale kontroll-leheks hankes esitatud tingimuste täitmise kontrollimisel. Vastavustabelit tuleb tõlgendada koos tehnilise kirjeldusega. Pakkuja pakutav süsteem (palume tutvuda tehnilises kirjelduses toodud tähendusega!) peab täitma kõik nõuded vastavustabeli punktides 4.1 - 4.29 ja 5.1 - 5.19 ning lisaks 4 vabalt valitud nõuet vastavustabeli punkti 4.30 alapunktidest. Siinkohal juhime tähelepanu, et vastavustabelis küsitud videofail ja video ajaline viide tuleb esitada nõuete täitmise tõenduseks kõikidele vastavustabeli punktide 4.1-4.29 ja punkti 4.30 alapunktide osas, mille kohta pakkuja soovib tõendada pakutava süsteemi funktsionaalsuse olemasolu (olgu siis nõude täitmiseks või hindamisel lisapunktide saamiseks). Vastavustabelis toodud info põhjalt kontrollib hankija esitatud andmete õigsust sisulist ja teeb sisulise kontrolli põhjal otsuse pakkumuse vastavuse või mittevastavuse kohta. 6. Hankija ei näe põhjendatud vajadust hanke tähtaja pikendamiseks. “ 21.03.20254 on Hankijale esitatud järgmine selgitustaotlus: „Tehnilises kirjelduses on punkt: 6.3 Pakkumuste avamise kuupäevaks peab olema Hankijale avatud pakutava tarkvara demokeskkond Azure platvormil, kuhu on integreeritud Eesti äriregistri avaandmed (lihtandmed, üldandmed, registrikaardid, kaardile kantud isikud, osanikud) . Kas Demo keskkonna osas on aktsepteeritav, et see on üles pandud mujale kui Azure pilve keskkonda? Näiteks toote enda poolsesse pilve keskonda. Antud juhul toodet saab panna ükskõik millisesse pilve, kuid Demo keskkonna kontekstis on see lisatöö, mis ei lisa mingit väärtust toote soovitud funktsionaalsuste demomisele ja proovimisele hankija poolt. Lisaks kui pakkujal endal ei ole spetsiifiliselt enda organisatsioonis kasutuses Azure pilv vaid on mõni alternatiivne pilv, siis antud nõue tundub piirav ja teeb pakkujale pakkumuse tegemise keerulisemaks, ilma et see tegelikult omaks moju pakkuja poolt pakutava toote funktsionaalsusele ja selle hindamisele hankja poolt. Kui alternatiivne keskkond kui Azure on aktsepteeritav, siis palume täiendada antud punkti laiendusega "Azure või samaväärsel platvormil" Lisaks küsimus: ei ole suutnud täpselt dokumentidest leida, et kui pikalt peab antud demo keskkond olema kätte saadav, ehk kui pikaks ajaks peab pakkuja demokeskkonna olemasolu hankijale võimaldama. Palume see täpselt kirja panna. “ Hankija on 24.03.2025 vastanud järgmiselt: 4 Sõnumi ID: 944 655 22 (26) „Hankija aktsepteerib demokeskkonnana ainult Azure pilve keskkonda, sest ainult seeläbi saab hankija veenduda süsteemi toimimises nimetatud keskkonnas. Lepingu täitmisel on hankijal ainult Azure keskkonna võimekus. Demokeskkond peab olema kättesaadav hankemenetluse lõpuni ehk hankelepingu sõlmimiseni (Riigihangete seaduse § 73 lõige 3 punkt 1).“ Mitte ühestki Hankija vastusest ei tulene see, et TK p-i 6.2 oleks võimalik tõlgendada nii, et pakkuja otsustab, mida pakkumuses esitatav videopresentatsioon kajastab ja et ei pea olema näha kõigi funktsionaalsete nõuete täitmise lahendusi. Hankija vastustest selgitustaotlustele tuleneb üheselt aru saadavalt, et pakkumuses esitatav videofail ja demokeskkond peavad võimaldama Hankijal kontrollida kõigi TK p-is 4 sätestatud funktsionaalsete nõuete täitmist. Vaidlustuskomisjon nõustub Hankijaga, et Hankija andis pakkujale vabad käed selles, milliseid andmeid kasutada funktsionaalsuste tõendamiseks, mitte ei andnud vabu käsi selles, milliseid funktsionaalsuste lahendusi esitada. 7.5. Tallinna Halduskohtu 25.01.2024 otsuses 3-23-2824 (p 32) on kohus asunud seisukohale, et pakkumuse sisulise vastavuse kontroll RHS § 114 mõttes saab hõlmata üksnes nõudeid, mille täitmine oli nõutav pakkumuse esitamise hetke seisuga, kuid tulevikku (hankelepingu sõlmimise järgsesse perioodi) suunatud dokumendi esitamise tingimus ei pea olema täidetud pakkumuse esitamise hetke seisuga. Kohus on selles otsuses viidanud ka Euroopa Kohtu otsusele asjas nr C-927/19 (p 89) - hankelepingu täitmise tingimuste järgimist ei tule hinnata hankelepingu sõlmimise hetkel. Hankija peab rangelt kinni pidama enda poolt kindlaks määratud tingimustest, milline kohustus seondub võrdse kohtlemise põhimõttega ja sellest tuleneva läbipaistvuskohustusega (Euroopa Kohtu lahend asjas nr C-42/13, p 42 ja 43), mis pakkumuse vastavuse kontrollimise kontekstis tähendab seda, et antud juhul saaks RHS § 114 lg 2 esimese lause alusel kolmanda isiku pakkumuse tagasilükkamise kaasa tuua üksnes pakkumuse mittevastavus TK nendele nõuetele, mis pidid olema täidetud juba pakkumuse esitamise hetke seisuga. Vaidlustuskomisjon on seisukohal, et kõik TK p-is 4 toodud süsteemi/rakenduse funktsionaalsed nõuded pidid olema täidetud pakkumuse esitamisel ja nõuete lahendused pidid olema näha videopresentatsioonis. Mitte ühestki RHAD tingimusest ei tulene see, et Hankija oleks saanud nõuete täitmist kontrollida üksnes kinnituste ja selgituste alusel. 7.6. Vaidlustaja on pakkumuses esitanud: 1) „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabeli“, kus iga nõude täitmise kohta on toodud link; 2) videopresentatsioonid; 3) andmed demokeskkonna kohta. Vaidlustaja on 10.06.2025 vastanud Hankija selgitustaotlustele seonduvalt Nõuetega 4.8 ja 4.10. Vaidlustaja on 01.07.2025 vastanud Hankija selgitustaotlustele seonduvalt Nõuetega 4.8, 4.10, 4.24, 4.25, 4.28, 4.30.1, 4.30.2, 4.30.10 ja 4.30.11. 23 (26) Hankija on kontrollinud Vaidlustaja pakkumuse vastavust pakkumuses esitatu ja Vaidlustaja vastuste alusel. 7.7. Nõue 4.8 - süsteem peab andmeallikatest, struktureeritud andmetest ja vabatekstist, tuvastama järgmised andmeelemendid: • füüsilise isiku nimi • juriidilise isiku nimi • isiku sünniaeg • isiku identifikaator (registrikood või isikukood) • aadress • pangakonto või virtuaalvääringu rahakoti number • e-posti aadress • telefoninumber • kuupäev • rahasumma • valuutatähis • raha liikumise suund 7.7.1. Vaidlustuskomisjon tuvastas Vaidlustaja pakkumuses viidatud lingilt, et demovideos tutvustati erinevaid protsessoreid (sh GROK), kuid ei näidatud seda, kuidas Nõue 4.8 on täidetud seal nimetatud algelementide puhul. Pakkumuses sisalduva demovideoga ja süsteemi demokeskkonnaga tutvumisel ei tuvastanud Hankija teatud Nõuded 4.8 nimetatud algelemente ja küsis Vaidlustajalt selgitusi (Vaidlustaja ei ole esitanud vastuväiteid sellele, et demovideo ja demokeskkond Nõude 4.8 täitmist ei tõendanud). Teises vastuses (01.07.2025) andis Vaidlustaja Hankijale teada, et Elastic toote osa on funktsionaalsus, mis võimaldab konfigureerida GROK mustreid. Pakkuja koostab vajalikud GROK mustrid paigalduse osana. Vaidlustaja selgituste kohaselt näevad hankelepingu projekt ja TK ette paigaldust ja seadistamist - andmeallikate ühendamine ja nende parsimise seadistamine (mida GROK teeb) on iga andmeanalüütika platvormi paigalduse fundamentaalne ja ootuspärane osa. Esmakordselt alles vaidlustuses viitas Vaidlustaja veebilingile https://www.elastic.co/docs/reference/logstash/plugins/plugins-filters-grok. Vaidlustuskomisjon on seisukohal, et Nõude p 4.8 funktsionaalsust polnud võimalik Hankijal Vaidlustaja pakkumuse vastavuse kontrollimisel tuvastada. Seega pakkumuse esitamise hetke seisuga Vaidlustaja pakutaval Elastic platvormil ei ole Nõue 4.8 täidetud. RHAD pole koostatud selliselt, et Hankija saaks piirduda Vaidlustaja kinnitusega vastava võimekuse olemasolu kohta – Nõue 4.8 pidi olema pakutaval platvormil täidetud ja täitmine tõendatud pakkumuses. 7.7.2. TK p 3.2. ei näe ette, et lepingu täitja ise paigaldamise ja seadistamisega tegeleks – lepingu täitja üksnes juhendab. RHAD anna alust järelduseks, et alles paigaldamisel ja seadistamisel võib TK-s toodud süsteemi/rakenduse funktsionaalsete nõuete täitmist tagada. 24 (26) Vaidlustuskomisjon on seisukohal, et Hankija on õigesti järeldanud Nõudes 4.8 kirjeldatud funktsionaalsuse puudumist Vaidlustaja pakutud platvormil - Vaidlustaja realiseeriks selle alles paigalduse osana. 7.8. Nõue 4.10 - andmesubjekti tuvastus peab põhinema nii otsestel kui ka osalistel vastetel. Näiteks peab süsteem aru saama, et "Jaan Tamm, sünniaasta 1999" ja "Jaan Tamm, I.K. 39901011234" ja "26-aastane Jaan Tamm" ja "Tamm Jaan, sündinud 01.01.1999" võivad olla samad isikud ja seda võidakse tuvastada ka muude seotud andmeelementide kaudu nagu kontonumber või aadress. Vaidlustuskomisjon tuvastas Vaidlustaja pakkumuses toodud lingilt, et demovideos näidati teatud tegevusi, aluseks olid Nõudes 4.10 toodud näited. Hankija selgituste kohaselt Vaidlustaja näitas erinevate nimekujude üheks isikuks kokku liitmist, kuid õige on see, et Nõudest 4.10 tulenes see, et pidi olema eri nimekujude sarnasuse tuvastamine. Seda funktsionaalsust demovideost näha ei olnud. Vaidlustaja selgituste kohaselt sisaldab pakutav platvorm Elastic võimekaid päringukeeli, mis on võimelised etteantud andmeallikatest üles leidma erinevatel kujudel kirjutatud samu andmesubjekte. Vaidlustaja arvates on ebamõistlik eeldada, et pakkuja peaks looma keeruka, Hankija vajadusi simuleeriva andmekogu ja seadistama selle baasil täisfunktsionaalse lahenduse pelgalt demo eesmärgil, eriti kui Hankija andis ise pakkujale vabad käed näidisandmete loomiseks (nähtub teabevahetuses toodud Hankija vastustest). Vaidlustaja leiab, et „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabelis“, toodud kinnitus ja Hankijale antud tehnilise lahenduse selgitus on piisavad, RHAD-s pole seatud konkreetseid, mõõdetavaid demo-nõudeid. Vaidlustuskomisjon on seisukohal, et ka Nõude 4.10 täitmine pakutaval platvormil pidi olema tõendatud eelkõige demovideos. Vaidlustaja ei saanud eeldada, et tema pakutava platvormi kohta esitatakse nn mõõdetavad demo-nõuded. Oma pakkumuse ja seal esitatud platvormi TK-s toodud nõuetele vastavuse tõendamine on pakkuja kohustus ja käesoleval juhul ei saanud pakkuja, sh Vaidlustaja, RHAD-st aru saada selliselt, et TK p-is 4 toodud nõuded võivad olla täidetud alles pärast hankelepingu sõlmimist. Seega ei saa olla vaidlust selles, et pakkumuse esitamise hetke seisuga Vaidlustaja pakutaval Elastic platvormil ei ole Nõue 4.10 täidetud. Vaidlustuskomisjon on seisukohal, et Hankija on õigesti järeldanud Nõudes 4.10. kirjeldatud funktsionaalsuse puudumist Vaidlustaja pakutava platvormi puhul. 7.9. Vaidlustuskomisjon on seisukohal, et puudub vajadus võtta seisukoht teiste Vaidlustaja pakkumuse tagasi lükkamise otsuse põhjendustes toodud Nõuete täitmise osas, sest Vaidlustaja pakkumuse tagasilükkamise otsus on kooskõlas RHS-iga juba siis, kui on tuvastatav üks sisuline mittevastavus RHAD-s toodud nõuetele. Vaidlustuskomisjon on seisukohal, et Hankija on õigesti tuvastanud Vaidlustaja pakkumuse mittevastavuse vähemalt Nõuetele 4.8 ja 4.10 ning on õigesti Vaidlustaja pakkumuse RHS § 114 lg 2 alusel tagasi lükanud. Vaidlustaja pakkumuse mittevastavused on tingitud eelkõige sellest, et Vaidlustaja ei ole 25 (26) mingil põhjusel pidanud vajalikuks tõendada pakkumuses TK nõuete täitmist, kuigi see kohustus otseselt TK-st tulenes. 8. Vaidlustaja ei ole toonud välja iseseisvaid õiguslikke või faktilisi asjaolusid, millest tulenevalt võiks seada kahtluse alla Kolmanda isiku pakkumuse edukaks tunnistamise otsuse, vaid lähtub selle otsuste vaidlustamisel eeldusest, et õiguspärane ei ole Hankija otsus Vaidlustaja pakkumuse tagasi lükkamise kohta. Kuna vaidlustuskomisjon on seisukohal, et Hankija otsus Vaidlustaja pakkumuse tagasi lükkamise kohta on õige, on õiguspärane ka Hankija otsus, millega Kolmanda isiku pakkumus tunnistati edukaks. 9. 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. Hankija ei taotlenud kulude väljamõistmist. Kolmas isik on esitanud taotluse 3117,50 eurot käibemaksuta välja mõistmiseks (ühe tunni hind 215 eurot käibemaksuta, õigusteenuse maht 14,5 tundi). Vaidlustuskomisjon leiab, et lepingulise esindaja kulude välja mõistmisel on oluline see, et esindaja kulude suurus lähtuks asja keerukusest ja materjalide mahukusest. Kolmanda isiku kirjalikest seisukohtadest ei saa järeldada, et lepinguline esindaja osutas selles vaidlustusasjas Kolmandale isikule õigusabi 14,5 tundi. Vaidlustuskomisjon leiab, et käesoleval juhul ei ole põhjendatud see, et Kolmandale isikule osutatud õigusteenuste maht on suurem Vaidlustajale osutatud õigusteenuste mahust. Vaidlustuskomisjoni hinnangul on vajalik ja põhjendatud Kolmanda isiku aeg õigusabi osutamiseks 8 tundi ja 1720 eurot kuulub Vaidlustajalt välja mõistmisele. Vaidlustaja kulud jäävad tema enda kanda. (allkirjastatud digitaalselt) Ulvi Reimets 26 (26)