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

2 (26)

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

3 (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.

4 (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

5 (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.

6 (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.

7 (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

8 (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

9 (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.

10 (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.

11 (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

12 (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“.

13 (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

14 (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

15 (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

16 (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

17 (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.“

18 (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,

19 (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.

20 (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

21 (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

22 (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

23 (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.

24 (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.

25 (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

26 (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