Hankija vastus

Pr Ulvi Reimets Riigihangete vaidlustuskomisjon Tartu mnt 85 Teie: 07.11.2025 nr 12.2-10/253 10115 Tallinn [email protected] Meie: 12.11.2025 nr 1.1-5/112-1 Hankija: Rahandusministeeriumi Infotehnoloogiakeskus, registrikood: 70009244 Hankija esindaja: Kairi Osolainen e-post: [email protected]; [email protected] Vaidlustaja: FOB Solutions OÜ, registrikood: 12449455 Vaidlustaja esindaja: vandeadvokaat Kristo Kallas Advokaadibüroo DEM e-post: [email protected] Kolmas isik: STATS Unities OÜ, registrikood: 12873532 e-post: [email protected] VASTUS VAIDLUSTUSELE Riigihange: „Võrgustikuanalüütika tarkvara“ Riigihanke viitenumber: 290035 FOB Solutions OÜ (edaspidi vaidlustaja) on esitanud vaidlustuse seoses riigihankes „Võrgustikuanalüütika tarkvara“ (edaspidi riigihange) hankija otsustega lükata vaidlustaja pakkumus tagasi ja tunnistada STATS Unities OÜ pakkumus edukaks. Hankija ei nõustu vaidlustusega ja palub jätta vaidlustus rahuldamata ning kulud vaidlustaja enda kanda. Hankija on nõus kirjaliku menetlusega. Vaidlustuse punktis 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 riigihanke alusdokumentides (edaspidi RHAD) 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 siiski ei ole. Hankija antud ükski selgitus ei muuda riigihanke alusdokumente (RHS § 46 lg 3) ja hankija kinnitab, et ei ole andnud ka ühtegi selgitust, mis võimaldaks mitte täita RHADis toodud nõudeid. Ainukesed selgitused nn „vabade käte“ kohta on hankija andnud vajalike näidisandmete loomeks, vastamaks nõutud funktsionaalsuse demonstreerimiseks. Vaidlusalusele riigihankele on lisatud tehniline kirjeldus. Vastavalt RHS § 87 lõikele 1 on tehniline kirjeldus hankelepingu eseme kirjeldamiseks vastavas valdkonnas tegutsevatele isikutele arusaadavat Lõõtsa 8a, 11415 Tallinn / [email protected] / www.rmit.ee / registrikood 70009244  2 (8) terminoloogiat ja täpsusastet kasutades hankija kehtestatud asjade või teenuste omaduste ja neile esitatavate nõuete loetelu. Seega peaks igale riigihankes osalevale ettevõtjale olema ilmne, et nõuete loetelu, millele pakkumus peab vastama, tuleb otsida tehnilisest kirjeldusest. Hankija loetles tehnilise kirjelduse punktis 4 üles rakenduse funktsionaalsed nõuded ja punktis 5 mittefunktsionaalsed nõuded, millele pakutav rakendus või lahendus pidi vastama. Punktis 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 (vaata tagasilükkamise protokolli mittevastavuse kirjeldusi punktides 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 punkt 4.30). Seega alates tehnilise kirjelduse punktist 4.30, mis puudutasid visualiseerimist, määratles hankija RHADis selgelt ja ühemõtteliselt, et tegemist on valiknõuetega, kuid ühtlasi märkis hankija ka seda, et punktides 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 punkti 4.30.11 kui ka RHADis „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabel“. Teiste sõnadega jättis hankija pakkujale võimaluse valida tehnilise kirjelduse punktis 4.30 sätestatud 11 valiknõude seast vähemalt 4 nõuet, mis kindlasti peavad olema täidetud, et pakkumus oleks vastav RHADis 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. (vaata tagasilükkamise protokolli mittevastavuse kirjeldusi punktides 4.30.1, 4.30.2, 4.30.10 ja 4.30.11). Hankija jaoks on arusaamatu, millest vaidlustaja järeldab, et pakkujatele on jäetud „vabad käed“ otsustamaks, kuidas ja mida esitada?! Vaidlusaluses hankes oli hankija RHADis (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, 3- 15-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. Hankija juhib vaidlustuskomisjoni tähelepanu asjaolule, et hankele oli kaasa pandud ka Exceli tabel „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabel“, et pakkujad saaksid üle kontrollida kas ja millised RHADis 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 punktis 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, võiks isegi öelda, et läbivalt, rõhutanud fakti, et ta lahendab ühe või teise RHADi 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 alampunktid 2.7.4 ja 2.9.2). Hankija ei salga, et RHADis nõutud funktsionaalsused võivad olla keerulised, kuid hankes osalesid pakkujad, kelle pakutavas tarkvaralahenduses olid RHADis 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 RHADis kordagi maininud, et soovib arendusprojekti, vaid RHADis on üheselt  3 (8) kirjeldatud, millised funktsionaalsed omadused peavad pakutaval tootel olemas olema. Seega soovis hankija RHADis esitatud nõuetele vastavat lahendust, mitte tulevikus saavutatavat potentsiaalset funktsionaalsust. Hankija on 7.04.2025 selgituses (ID 949836) vaidlustaja enda küsimise peale selgitanud, kuidas toimub RHADis 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.“ Hankija kinnitab, et ta ei osta põrsast kotis. Kuigi vaidlustaja on pakkumusele lisatud „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabelis“ kinnitanud RHADis 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 RHADi nõuete täidetavust, mistõttu on vaidlustuses esitatud argumendid „vabadest kätest otsustamaks, kuidas ja mida esitada“ ilmselgelt otsitud. Vaidlustuse punktis 2.4. leiab vaidlustaja, et „hankija on ekslikult tõlgendanud tarkvaraplatvormi standardset konfigureeritavust ja paigaldamise käigus teostatavat seadistamist kui pakkumuse puudust.“ Vaidlustaja selgitab, et „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.“ Hankija saab vaidlustaja antud seisukohast aru nii, et vaidlustaja on eeldanud, et hankija võib pakkumuse vastavuse kontrolli teostades piirduda pakkuja kinnituste olemasolu kontrollimisega ja uskuda pakkuja antud kinnitusi tarkvaralahenduse vastavuse osas ehk osta „põrsast kotis“, sest küll lepingu täitmise käigus seadistatakse ja konfigureeritakse pakutud tarkvaralahendus hankija vajadustele sobivaks. Nii see siiski 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. Kuid „seadistamine“ ega „konfigureerimine“ ei tähenda lisafunktsioonide loomist, mida vaidlustaja aga soovib oma tarkvaraplatvormile luua hankelepingu täitmise käigus. Kokkuvõtlikult võib nentida, et 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 vaidlusaluse 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 punktis 2.4, et vaidlustaja pakutud tarkvaraplatvormil on RHADis 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 RHADis nõutud. Teatavasti riigihankes esitatud pakkumuste vastavuse kontroll selliselt ei toimi. Hankija peab veenduma pakkumuse vastavuses pakkumuste esitamise kuupäeva seisuga, hankija ei saa hinnata  4 (8) RHADi nõuete täitmist hankelepingu sõlmimise ajal. Hankija on vastava kontrolli teostanud ja tuvastanud ning protokollis põhjendanud, et vaidlustaja esitatud pakkumus ei vastanud RHADis esitatud nõuetele (täpsemalt on mittevastavused kirjeldatud pakkumuse tagasilükkamise protokollis). Vaatamata eeltoodule vastab hankija ka vaidlustuse konkreetsetele punktidele alljärgnevalt. Vaidlustuse punkt 2.6 (puudutab funktsionaalset nõuet 4.8: Andmeelementide tuvastamine) Vaidlustuse punktis 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, mis viiski hankijapoolsele eksimusele. 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 punktis 4.8 kirjeldatud funktsionaalsus veel ei sisaldu pakutavas süsteemis, mistõttu nõude punkt 4.8 on täitmata. Vaidlustuse alampunktis 2.6.3. on vaidlustaja ka ise tunnistab, et „tootes on olemas võimekus ja vajalikud mustrid koostatakse paigalduse osana. See ongi selliste platvormide tööpõhimõte“. 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). Vaidlustuse punkt 2.7 (puudutab funktsionaalset nõuet 4.10: Andmesubjekti tuvastamine) Vaidlustaja unustab korduvat, et hankija ei ole ühegi pakutava tarkvara/platvormi spetsialist. Hankijal ei ole iseenesest spetsiifilisi teadmisi pakutavast tarkvarast. See ongi 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 hankes 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 alampunktis 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 vaidlustuskomisjoni ja vaidlustaja 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 alampunktis 2.7.5. väidetule, mille kohaselt hankedokumentides polevat seatud konkreetseid, mõõdetavaid demo-nõudeid, on hankija vastupidisel seisukohal. Tehnilise kirjelduse punktis 4.10 on toodud näitlik loetelu, milliseid isikusamasuse vastavusi peab tarkvara  5 (8) olema suuteline tuvastama ning vastavalt tehnilise kirjelduse punktile 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 pakkuja ei täitnud RHADis esitatud nõuet. Vaidlustuse punkt 2.8 (puudutab funktsionaalset nõuet 4.24: Agregeerimine rakenduse graafil) Funktsionaalse nõude 4.24 demonstreerimise pealt pakkumuses ja vaidlustuse punkti 2.8 pealt jääb hankijale mulje, et vaidlustaja ei ole mõistnud, mis tüüpi tarkvaralahendust vaidlusaluses 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 alampunktis 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 võrgustikanalüüsi tööriist. Vaidlusalune riigihange on võrgustikuanalüütika tarkvara, mitte ärianalüüsitarkvara hange. Seetõttu ongi oluline eristada, et antud hankes 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 alampunktis 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 punktis 4.24 öeldud, et agregeerimine peab olema võimalik rakenduse graafil. Ja „rakenduse graaf“ tähendab RHADis läbivalt võrgustiku graafi, mitte suvalist graafikut (joon- või tulpdiagrammi või pirukat vms.). Hankija juhib tähelepanu, et ühelgi teisel hankes osalenud pakkujal ei olnud antud asjast arusaamisel raskusi. Seega vaidlustuse alampunktis 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 RHADs nõutud funktsionaalsuse olemasolu. Vaidlustuse punkt 2.9 (puudutab funktsionaalset nõuet 4.25: Võrgustiku statistikud) Vaata eelmist punkti: Hankija hinnangul ei ole vaidlustaja mõistnud, millise tarkvara(lahenduse) hankel osaletakse. Tehnilise kirjelduse punktis 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 alampunktis 2.9.3. Vaidlustaja kinnitab antud alampunktis 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 hankega hankima. Vaidlustuse punktis 2.9 vaidlustaja sarnaselt mitmetele teistele vaidlustuse punktidele ja hankija täpsustavale selgitustaotlusele antud vastuses püüab RHADi konkreetsele nõudele pakkuda midagi ligilähedast. Nii ka siinkohal, tehnilise kirjelduse punktis 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 RHADis esitatud nõue ei ole täidetud. Vaidlustuse punkt 2.10 (puudutab funktsionaalset nõuet 4.30: Visualiseerimise valiknõuded)  6 (8) Vaidlustuse punktiga 2.10 ja selle alampunktidega ilmneb taas, et vaidlustaja ei ole mõistnud, millise tarkvaralahenduse hankega 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 punktis 4.30 loetletud valiknõuded on peaaegu kõik võrgustikuanalüüsi 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 alampunktis 2.10.3. ei kritiseeri vaidlustaja hankija hinnangut pakkumusele, vaid tehnilise kirjelduse alampunkti 4.30.1 sisulist olemust: „Hankija nõuab sisuliselt valmis, treenitud tehisintellekti lahendust, mis on ebareaalne ootus riigihanke pakkumuse faasis.“ Esmalt rõhutame, vaidlustaja ei ole vaidlustanud riigihanke alusdokumente, mistõttu tuleb neid täita. Teiseks märgime, et hankija ei nõudnud tehisintellektil põhineva lahenduse kasutamist. Kuid sõltumata funktsionaalsuse realiseerimiseks kasutatud tehnoloogilisest lahendusest, peab pakutav tarkvaralahendus vastama hankes esitatud nõuetele pakkumuste esitamise kuupäeva seisuga. Vaidlustuse alampunktis 2.10.5. ei arvesta vaidlustaja tehnilise kirjelduse alampunkti 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 joonis 1). Seega ka täiendava info valguses on selge, et RHADi nõue on täitmata.  7 (8) Joonis 1. Ekraanipildi väljavõte vaidlustaja pakutavast tarkvaralahendusest, kus hankija on punase allakriipsutusega esile toonud menüüvalikus moodulite Canvas ja Graph lingid. Vaidlustuse alampunktis 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 alampunktis 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 punktis 2.10.9 demonstreerib vaidlustaja ilmekalt, et ta räägib klassikalisest tänapäeva BI tarkvarast. Vaidlustaja kirjeldab seal BI tarkvara funktsionaalsust. Kuid tuleb meeles pidada, et hankija läks riigihankega ostma võrgustikuanalüüsi tarkvara. Eeltoodu näitlikustamiseks rõhutame, et hankija soovis saada nö „võtmed kätte“ lahendust. Pakkuja aga pakkus nö majakarpi ja selle kõrvale ehitusmaterjali ning tööriistu, millega soovib vaidlustusmenetluses tõendada, et selle ehitusmaterjali ning tööriistadega on võimalik täita kõik RHADi nõuded ja saada „võtmed kätte“ valmidusega maja. Võrgustikuanalüütika nö karbitooted ehk valmis tarkvarapaketid on arendatud 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. 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 RHADi nõuetele ja võimaldab seeläbi hankelepingu nõuetekohast täitmist. Vaidlustaja ei ole oma pakkumuses märkinud ärisaladuseks muid andmeid, kui vaid spetsialistide isikuandmeid, mida hankija oma vastuses ei kajasta. Lähtudes eeltoodust ei sisalda hankija vastus ärisaladust. Lugupidamisega  8 (8) (allkirjastatud digitaalselt) Kairi Osolainen riigihangete juht Lisa: Volikiri hankija esindamiseks  10.11.2025 nr 1.1-3/113 VOLIKIRI Rahandusministeeriumi Infotehnoloogiakeskus, registrikood 70009244, asukoht Lõõtsa 8 a, Tallinn 11415, keda esindab Rahandusministeeriumi Infotehnoloogiakeskuse põhimääruse alusel direktor Meelis Riimaa, volitab käesoleva volikirjaga Kairi Osolainen’i, isikukood 47501280279 esindama Rahandusministeeriumi Infotehnoloogiakeskust kõigi volitajale kuuluvate õiguste teostamisel Riigihangete vaidlustuskomisjonis seoses riigihankes „Võrgustikuanalüütika tarkvara“ (viitenumber 290035) esitatud vaidlustuse läbivaatamisega. Volikiri kehtib kuni 31.01.2026.a ning on antud edasivolitamise õiguseta. Lugupidamisega (allkirjastatud digitaalselt) Meelis Riimaa direktor Lõõtsa 8a, 11415 Tallinn / [email protected] / www.rmit.ee / registrikood 70009244