Vaidlustus

Hankekomisjoni protokoll FOB SOLUTIONS OÜ PAKKUMUSE TAGASILÜKKAM I SE KOHTA Pakkuja FOB Solutions OÜ (edaspidi pakkuja) esitas pakkumuse riigihankele „ Võrgustikuanalüütika tarkvara“ (viitenumber 290035). Riigihanke nr 290035 pakkumuste vastavuse kontrollimisel tuvastas hankija FOB Solutions OÜ pakkumuses mitmeid puudusi. Alljärgnevalt on igas plokis esmalt viide hanke dokumentatsioonis „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabelis“ kirjeldatud nõuete ala m punktile ja kursiivis nõude sisule ning seejärel hankija tuvastatud mittevastavuse kirjeldus . 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 Pakutud süsteemi vastavuse kontrolli raames hankija ei tuvastanud, et pakutud süsteem suudab tuvastada nõudes nimetatud kõiki andmeelemente, s.h näiteks raha liikumise suunda. Pakkumuses sisalduva demovideoga ja süsteemi demokeskkonnaga tutvumise järel esitas hankija pakkujale selgitustaotlused, kas ja kuidas pakutav süsteem tuvastab nõudes loetletud andmeelemente. Pakkuja vastas muu hulgas: „ Elastic toote osa on funktsionaalsus, mis võimaldab konfigureerida GROK mustreid. Pakkuja koostab vajalikud GROK mustrid paigalduse osana.“ Hankija selgitas välja veebilehe https://x.ai/grok alusel, et GROK-i puhul on tegemist tehisintellektil põhineva arvutiprogrammide koostamise abivahendiga. Veelgi enam, iga andmeelemendi tuvastamiseks on vaja koostada eraldi koodilõik. Pakkuja vastustest kokkuvõtvalt järeldub, et nõude punktis 4.8 kirjeldatud funktsionaalsus veel ei sisaldu pakutavas süsteemis, vaid pakkuja realiseeriks nimetatud funktsionaalsuse süsteemi paigalduse osana. Hankija peab kontrollima pakkumuse vastavust pakkumuste esitamise kuupäeva seisuga ja kuna hankija tuvastas, et pakutud süsteem ei sisalda nõutud funktsionaalsust, s.h raha liikumise suuna tuvastamist, siis eelkirjeldatust järelduvalt on nõude punkt 4.8 täitmata. 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. Pakutud süsteemi vastavuse kontrolli raames hankija ei tuvastanud, et pakutud süsteem suudab tuvastada andmesubjekte nõude punktis 4.10 kirjeldatud põhimõtete kohaselt. Pakkumuses sisalduva demovideo ja süsteemi demokeskkonnaga tutvumise järel esitas hankija pakkujale selgitustaotlused, kas ja kuidas pakutav süsteem tuvastab andmeallikates erineval kujul ja lisaandmetega andmesubjektide isikusamasust. Pakkuja selgituste kohaselt sisaldab pakutav süsteem Elastic võimekaid päringukeeli, mis on võimelised etteantud andmeallikatest üles leidma erinevatel kujudel kirjutatud samu andmesubjekte, s.h võttes arvesse seadistatud tundlikkust ehk vastete kokkulangevuse tugevust. Vaadates süsteemi demovideot, tutvudes demokeskkonnaga ja analüüsides pakkuja vastuseid kogumis, ei saanud hankija kinnitust, et lisaks erineva kirjakujuga andmesubjektide vastete leidmisele suudaks süsteem tuvastada ka leitud isikute samasust. Täiendavalt märgib hankija, et süsteem ei leia otsitavate andmesubjektide seost läbi muude andmestikus leiduda võivate andmete, nagu näiteks sama pangakonto või e-posti aadress. Hankija peab kontrollima pakkumuse vastavust pakkumuste esitamise kuupäeva seisuga ja kuna hankija tuvastas, et pakutud süsteem ei suuda tuvastada andmesubjekti, mis põhineb nii otsestel kui ka osalisetel vastetel ega tuvastada nende isikusamasust läbi muude andmeelementide, on nõude punkt 4.10 täitmata. Nõue 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. Pakutud süsteemi vastavuse kontrolli raames hankija ei tuvastanud, et pakutud süsteem võimaldab rakenduse graafil (ehk lõppkasutaja kuval näidatavas võrgustiku seoste joonisel) teostada andmeelementide agregatsioone nõudes kirjeldatud põhimõtete kohaselt. Pakkumuses sisalduva demovideoga ja süsteemi demokeskkonnaga tutvumise järel esitas hankija pakkujale selgitustaotluse saamaks teada, kuidas toimub graafil andmeelementide agregeerimine. Pakkuja esitles oma vastuses analoogselt demovideole tunnusepõhist statistilist diagrammi, mitte seoste graafi. Joonis 1. Pakkuja selgitustaotluse vastuses esitatud statistiline diagramm (analoogne demovideole) Pakkuja vastuses välditi hankija soovi agregeerida graafil seoste sõlmpunkte ehk node’sid või ühendusjooni ehk link’e , ja viidati demovideos olevale statistilisele diagrammile. Statistiline diagramm ei vasta hankes esitatud nõudele rakenduse graafil andmete agregeerimiseks erinevate tunnuste lõikes, kuna erinevalt statistilisest diagrammist, mis näitab osahulkade suurust, näitab graaf andmeelementide vahelisi seoseid. Joonis 2. Google otsingu tulemus märksõnaga „link graph “ Vaadates süsteemi demovideot, tutvudes demokeskkonnaga ja analüüsides pakkuja vastuseid kogumis, ei saanud hankija kinnitust, et pakutud süsteem võimaldab rakenduse graafil (ehk lõppkasutaja kuval näidatavas võrgustiku seoste joonisel) teostada andmeelementide agregatsioone nõudes kirjeldatud põhimõtete kohaselt. Eelnevast järelduvalt on nõude punkt 4.24 täitmata. Nõue 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 ). Pakutud süsteemi vastavuse kontrolli raames hankija ei tuvastanud, et pakutud süsteem võimaldab rakenduse graafil (ehk lõppkasutaja kuval näidatavas võrgustiku seoste joonisel) kasutada spetsiifilisi võrgustikku iseloomustavaid funktsioone. Pakkumuses sisalduva demovideoga ja süsteemi demokeskkonnaga tutvumise järel esitas hankija pakkujale selgitustaotluse saamaks teada, milliseid nõudes nimetatud funktsioone võimaldab süsteem lõppkasutajal kasutada. Pakkuja vastas: „Lahendus võimaldab kasutajatel kasutada lisaks aritmeetilisele keskmisele paljusid matemaatilisi funktsioone ja Elastic platvorm sisaldab funktsionaalsust enda loodud valemite lisamiseks.“ Lisaks on pakkuja oma vastuses väitnud, et pakkujale on jäetud vabad käed vajalike näidisandmete loomeks, vastamaks nõutud funktsionaalsuse demonstreerimiseks. Kuid eeltoodu ei tähenda seda, et pakkumus ei pidanud vastama hankes kirjeldatud funktsionaalsetele nõuetele. Nimetatud nõuete täitmist peab hankija saama kontrollida pakkumusega esitatud demokeskkonnas. Nagu tõendab demovideo ekraanipilt (joonis 3), on demokeskkonna süsteemis kasutajale võimaldatud ainult statistilised funktsioonid, samas ei ole kasutajale tehtud kättesaadavaks ühtegi võrgustikku iseloomustavat funktsiooni: tsentraalsus ( centrality ), tihedus ( density ), vahendatus ( betweenness ), lähedus ( closeness ). Joonis 3. Pilt pakkumuse demovideost, kus punase kastiga on märgitud kasutajale võimaldatud funktsioonide loetelu. Hankija tuvastas, et pakutud süsteem ei sisalda võrgustikku iseloomustavaid funktsioone nagu näiteks tsentraalsus ( centrality ), tihedus ( density ), vahendatus ( betweenness ) ja lähedus ( closeness ), mistõttu on nõude punkt 4.25 täitmata. Nõue 4.30 Hanke dokumentatsioonis „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabelis“ punkti 4.30 „Visualiseerimise valiknõuded rakenduse graafile:“ juures on täpsustus: „NB! Punktis 4.30 loetletud valiknõuetest peavad olema täidetud vähemalt 4 (neli) nõuet, et pakkumus oleks vastav. Rohkem kui 4 valiknõude täitmise osakaal mõjutab pakkumuse hindamistulemust.“ Pakkuja märkis oma pakkumuses, et tal on täidetud nõude punkti 4.30 alampunktid 4.30.1, 4.30.2, 4.30.3, 4.30.4, 4.30.10 ja 4.30.11 (kokku 6 nõuet). Kuna hanke dokumentatsioonis oli täpsustamata, milliseid nõude punkti 4.30 alampunkte kontrollitakse pakkumuse vastavuse kontrolli käigus, siis esmalt kontrollis hankekomisjon pakkuja poolt väidetavalt täidetud nelja esimest ala m punkti (4.30.1 - 4.30.4) . Kuna hankija tuvastas, et pakkujal on täitmata ala m punktid 4.30.1 ja 4.30.2, siis jätkati ükshaaval järgmiste ala m punktide kontrolli tuvast amaks , kas pakkumus siiski täidab nõutud 4 ala m punkti nõuet . See tähendab, et hank ija kontrollis vast av use käigus ala m punkte 4.30.1 – 4.30.11. Hankija kontrollis punktis 4.30 nimetatud nõuete täidetust ja tuvastas: Nõue 4.30.1 raha liikumisel pangakontode või virtuaalvääringu rahakottide vahel peab süsteem ära tundma ringtehingute ahelad ja neid kuvama esile toodult Pakutud süsteemi vastavuse kontrolli raames hankija ei tuvastanud, et pakutud süsteem tunneb ära ringtehingute ahelad ja kuvab neid esile toodult. Pakkumuses sisalduva demovideoga ja süsteemi demokeskkonnaga tutvumise järel esitas hankija pakkujale selgitustaotluse saamaks teada, kuidas pakutav süsteem vastab nõudele. Pakkuja vastas: „Videos demonstreeritakse funktsionaalsust, mis võimaldab esile tuua tehingu, milles seotud ettevõtted teevad tehinguid üksteisele. Lisamaterjalides toome välja, et Elastic platvorm sisaldab rahapesu tuvastamiseks sobilikku masinõppe funktsionaalsust ja AI integratsioone.“ Hankija tuvastas pakkumuse koosseisus faili „Lisainfo ja näited – Elasticu rakendamine Rahapesu juhtumites.pdf“, kus lehekülgedel 4-5 on kirjas: „ Elasticu masinõpe (ML) ja tehisintellekti (AI) integratsioon saavad aidata tuvastada raha ringkäitlemist mitmel viisil: /…/ 2. Tehingute jada analüüs ( Sequence Analysis ): o Kiire raha liikumise tuvastamine: ML-mudelid saavad õppida tuvastama tehingute jadasid, kus raha liigub väga kiiresti ühelt kontolt teisele ja sealt edasi mitme erineva konto kaudu lühikese aja jooksul. See on tüüpiline raha ringkäitlemise tunnus. o Tsükliliste tehingumustrite tuvastamine: AI võib leida korduvaid tehingumustreid, kus raha liigub kindla arvu kontode vahel ringiratast, eesmärgiga varjata selle lõplikku sihtkohta ja algallikat.“ Pakkuja esitatud demovideos (joonis 4) viidatud kohas demonstreeriti ainult ühte tehingut, mis oli seotud kolme ettevõttega. Joonis 4. Pilt pakkumuse demovideost, kus esitletakse ainult ühte tehingut ( transfer ), millega on seotud 3 ettevõtet. Süsteemi d emovideo , demokeskkonna ja selgitustaotlusele pakkuja poolt antud vastuste põhjal leiab hankija, et pakutud süsteem ei ole võimeline leidma suurest hulgast tehingutest üksteisele järgnevad tehingu i d, läbi mille jõuab raha lõpuks tagasi algpunkti, s.t isikule või kontole. Pakkuja kirjeldab süsteemiga liidestatud masinõppe ja tehisintellekti funktsionaalsust kui alusvõimekust, mida alles tuleb hakata „treenima“ nõudes sõnastatud funktsionaalsuse tegelikuks täitmiseks. Kuna hankija peab kontrollima pakkumuse vastavust pakkumuste esitamise kuupäeva seisuga ja hankija tuvastas, et pakutud süsteem ei tunne ära ringtehingute ahelaid ega kuva neid esile toodult, siis on nõude alam punkt 4.30.1 täitmata. Nõue 4.30.2 võrgustiku andmesubjekti ( node ) suurus peab olema rakenduses määratud automaatselt ja muudetav käsitsi Pakutud süsteemi vastavuse kontrolli raames hankija ei tuvastanud, et süsteemi lõppkasutaja saaks võrgustiku graafil andmesubjekti ( node ) suurust käsitsi muuta. Pakkumuses sisalduva demovideoga ja süsteemi demokeskkonnaga tutvumise järel esitas hankija pakkujale selgitustaotluse saamaks teada, kuidas pakutav lahendus vastab nõudele, s.t võimaldab automaatselt ja käsitsi muutes reguleerida graafil andmesubjekti suurust. Pakkuja vastas: „ Elastic Canvas võimaldab lahendada antud eelduse, kombineerides andmepõhiseid reegleid ja interaktiivseid kasutajaliidese elemente.“ Hankija saab vastusest aru nii, et andmesubjekti suuruse automaatne muutmine on süsteemis võimalik läbi süsteemis täiendavate reeglite kirjutamise, kuid süsteemi lõppkasutaja saab graafi ainult sisse-välja suumida, s.t suurendada-vähendada pilti. Suumides ei saa muuta konkreetsete andmesubjektide suurust võrreldes teiste andmesubjektidega, muutub vaid kujutuse mastaap ekraanikuval. Hankija peab kontrollima pakkumuse vastavust pakkumuste esitamise kuupäeva seisuga ja kuna hankija tuvastas, et pakutud süsteemis ei saa lõppkasutaja käsitsi muuta andmesubjekti ( node ) suurust ja pakkuja ise kinnitab, et nõuet saaks täita kombineerides andmepõhiseid reegleid ja interaktiivseid kasutajaliidese elemente, siis on nõude alam punktis 4.30.2 sätestatud tingimused pakkumuse kontrollimise hetkel täitmata. Nõue 4.30.10 samale tunnusele vastavaid võrgustiku andmesubjekte ( node ) saab määratud tunnuse alusel agregeerida ja hiljem uuesti lahku eristada. Näiteks kõik samal aadressil asuvad isikud liita kokku üheks subjektiks ( node ) Pakutud süsteemi vastavuse kontrolli raames hankija ei tuvastanud, et süsteemi lõppkasutaja saaks võrgustiku graafil andmesubjekte ( node ) määratud tunnuse alusel agregeerida/grupeerida. Pakkumuses sisalduva demovideoga ja süsteemi demokeskkonnaga tutvumise järel esitas hankija pakkujale selgitustaotluse saamaks teada, kuidas pakutav lahendus vastab nõudele, s.t võimaldab tunnuste alusel andmesubjekte grupeerida. Pakkuja vastas: „videos on näha kuidas lõppkasutaja andmesubjektide valides määrabki grupeerimise tunnuse. Nõudest 4.30.10 ei loe välja kuidas tunnust on vaja määrata. Lisame juurde, et vajadusel Elastic Canvas pakub rohkem paindlikust võimaldades lahendada tunnuse määramise mooduseid kombineerides andmepõhiseid reegleid ja interaktiivseid kasutajaliidese elemente.“ Hankija tuvastas, et süsteemi lõppkasutaja saab andmesubjekte agregeerida neid hiirekursoriga ükshaaval märgistades, kuid mitte andmesubjekte iseloomustavate tunnuste määramise kaudu. Süsteem võimaldab grupeerida andmesubjekte ükshaaval valides ja anda grupile ühine nimi, kuid ei võimalda määratud tunnuse, näiteks aadressi, alusel grupeerida andmesubjekte, nagu nõudes sõnastatud. Süsteemis saab lõppkasutaja küll vaadata ükshaaval andmesubjektide tunnuseid, kuid isegi siis ei saa määrata tunnuseid, mille alusel andmesubjekte grupeerida ega seetõttu ka hiljem uuesti üksiksubjektideks lahku jagada. Ühtlasi kinnitab pakkuja oma vastuse teises pooles, et punkti 4.30.10 nõuet oleks süsteemis võimalik täita läbi süsteemis täiendavate reeglite programmeerimise, mis omakorda tõendab, et pakkumuse esitamise hetkeks oli nõue täitmata. Hankija peab kontrollima pakkumuse vastavust pakkumuste esitamise kuupäeva seisuga ja kuna hankija tuvastas, et pakutud süsteemis ei saa lõppkasutaja võrgustiku graafil andmesubjekte ( node ) määratud tunnuse alusel agregeerida ja pakkuja ise kinnitab, et nõuet saaks täita kombineerides andmepõhiseid reegleid ja interaktiivseid kasutajaliidese elemente, siis on nõude alam punktis 4.30.10 sätestatud tingimused pakkumuse kontrollimise hetkel täitmata. Nõue 4.30.11 rakendus valib vaikimisi andmestikust lähtuva võrgustiku graafi tüübi (seoste skeemi), kuid kasutaja saab graafi tüüpi vahetada ilma, et otsingu ja filtrite parameetrid muutuksid. Pakutud süsteemi vastavuse kontrolli raames hankija ei tuvastanud, et süsteemi lõppkasutaja saaks võrgustiku graafi tüüpi vahetada. Pakkumuses sisalduva demovideoga ja süsteemi demokeskkonnaga tutvumise järgselt esitas hankija pakkujale selgitustaotluse saamaks teada, kuidas pakutav lahendus vastab nõudele. Pakkuja vastas: „02.04.2025 esitasime nõude 4.30.11 kohta täpsustava küsimuse millele saime vastuse: 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. Antud näite puhul lähtuvalt saadud vastusest kasutasime erinevaid graafi tüüpe, kuid mitte võrgustik graafi, kuna võrgustik graafi tüüp on juba mitmes nõudes demonstreeritud. Pakutavas lahenduses on võimalik kasutada võrgustik graafi, kuid ka teisi visuaalse analüütika graafikuid, mis täidavad võrgustik graafiga sarnast eesmärki.“ Kuigi pakkuja väidab, et süsteemis on kasutuses erinevaid graafitüüpe, tuvastas hankija, et lõppkasutaja saab kasutada ainult ühte võrgustiku graafitüüpi – võrgustikudiagramm ( social network chart ) – seega puudub võimalus seda vahetada teistsuguse graafitüübi vastu. Pakkuja pakkus ja demonstreeris ka demovideos võrgustiku graafi tüübi valimist hoopis statistilisel diagrammil/graafikal, mida hankija ei olnud soovinud. Kuigi pakkuja väitis oma selgituses, et visuaalse analüütika graafikud täidavad võrgustiku graafiga sarnast eesmärki, siis pakkuja ei ole oma pakkumuses samaväärsust selgitanud ega esitanud tõendeid samaväärsuse kohta. Hankija hinnangul on võrgustiku graaf ja visuaalse analüütika graafik olemuselt erinevad visuaalsed kujutised, mida antud juhul ei saa käsitleda samaväärsetena, kuna visuaalse analüütika graafik ei näita andmesubjektide omavahelisi seoseid (seoste skeemi), mis on võrgustiku graafi peamine eesmärk. Eeltoodust järeldub selgelt, et pakutud süsteemis puudub võimalus kasutajal vahetada võrgustiku graafi tüüpe nagu oli kirjas nõude sõnastuses. Isegi kui eeldada, et võrgustiku graaf ja visuaalse analüütika graafik on samaväärsed, ei ole pakkujal täidetud nõudes nimetatud tingimus, mille kohaselt peab graafi tüüpe saama vahetada ilma, et otsingu ja filtrite parameetrid muutuksid. Pakutud süsteemi demokeskkonnas on näha, et võrgustiku graaf ja visuaalse analüütika graafikud asuvad erinevates alammenüüdes, mistõttu nende vahel liikudes peab kasutaja uuesti valima analüüsitava andmestiku ja sellele seatavad filtrid/otsingu parameetrid. Seega võrgustiku graafi vahetamisel ei säili seatud filtrite parameetrid. Hankija peab kontrollima pakkumuse vastavust pakkumuste esitamise kuupäeva seisuga ja kuna hankija tuvastas, et pakutud süsteemis ei saa lõppkasutaja võrgustiku graafi tüüpi vahetada, sest süsteemis on vaid üks võrgustiku graafi tüüp, ning isegi kui võrgustiku graafi vahetada visuaalse analüütika graafiku vastu, ei säili seatud filtrite parameetrid, siis on nõude alampunktis 4.30.11 sätestatud tingimused pakkumuse kontrollimise hetkel täitmata. Eeltoodust tulenevalt ei ole pakkuja pakkumuses täidetud ka nõude punktis 4.30 loetletud valiknõuet est vähemalt 4 , sest pakkuja pakkumuses märgitud 6-st valiknõudest vastas esitatud tingimustele vaid 2. RHS § 114 lg 2 esimese lause kohaseks pakkumuse tagasilükkamise otsuseks piisab, kui pakkuja pakkumuses esineb kas või üks mittevastavus riigihanke alusdokumentides esitatud nõudele, mis on sisuline ja mis ei ole selgitustega kõrvaldatav. Hankija on tuvastanud pakkuja pakkumuses mitmeid ülalpool mainitud mittevastavusi, mistõttu ei vasta pakkuja FOB Solutions OÜ pakkumus riigihanke alusdokumentides esitatud nõuetele (funktsionaalsetele nõuetele seatud tingimuste osas) ja tema pakkumus tuleb tagasi lükata (riigihangete seadus (RHS) § 114 lg 2) . Pakkuja, kelle pakkumus on tagasi lükatud, ei osale edasises menetluses (RHS § 114 lg 1). (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) Arvo Taar Marvin Palm Katre Noor Komisjoni esimees Komisjoni liige Komisjoni liige (allkirjastatud digitaalselt) Kairi Osolainen Komisjoni liige Riigihangete Vaidlustuskomisjon 7. november 2025 Tartu mnt 85, 10115 Tallinn [email protected] VAIDLUSTUS riigihankes nr 290035 „Võrgustikuanalüütika tarkvara“ Vaidlustaja: FOB Solutions OÜ registrikood 12449455 Valukoja tn 8/1, 11415 Tallinn e-post [email protected] esindaja: vandeadvokaat Kristo Kallas Advokaadibüroo DEM Maakri 30, 10145 Tallinn e-post [email protected] Hankija: Rahandusministeeriumi Infotehnoloogiakeskus registrikood 70009244 TAOTLUSED: 1. tunnistada kehtetuks Rahandusministeeriumi Infotehnoloogiakeskuse 28.10.2025 otsus riigihankes 290035, millega lükati tagasi FOB Solutions OÜ pakkumus ja tunnistati edukaks STATS Unities OÜ pakkumus; 2. jätta menetluskulud jätta Rahandusministeeriumi Infotehnoloogiakeskuse kanda. 1. ASJAOLUD 1.1. FOB Solutions OÜ (edaspidi pakkuja või vaidlustaja) esitas pakkumuse Rahandusministeeriumi Infotehnoloogiakeskuse (edaspidi hankija) korraldatud riigihankele „Võrgustikuanalüütika tarkvara“ (viitenumber 290035). 1.2. Hankija tegi 28.10.2025 otsused vaidlustaja pakkumuse tagasilükkamise ning STATS Unities OÜ pakkumuse edukaks tunnistamise kohta (lisa 1). 1 / 8 | Advokaadibüroo DEM OÜ | Registrikood 16453100 | Maakri 30, 10145 Tallinn | | E-post [email protected] | Telefon +372 56 66 4049 | www.abdem.ee | 1.3. Vaidlustaja pakkumuse tagasilükkamise põhjendused nähtuvad 27.10.2025 protokollist (lisa 2). Vaidlustaja hinnangul pole tema pakkumuse tagasilükkamine põhjendatud, mistõttu on hankija otsus väär ja tuleb tunnistada kehtetuks. 1.4. Vastavaks tunnistatud pakkumuste hindamine ja STATS Unities OÜ pakkumuse edukaks tunnistamine nähtub ka hankija 27.10.2025 protokollist (lisa 3). Sealjuures on viidatud, et hinnati kolme vastavaks tunnistatud pakkumust, kuid tabelis on toodud kaks pakkumust. 1.5. Kui vaidlustaja pakkumuse tagasilükkamise otsus tunnistatakse kehtetuks ja ta osaleb taas hankemenetluses, tema pakkumust hinnatakse, peab vaidlustajal olema võimalik saada edukaks. Seega tuleb tunnistada kehtetuks ka senine eduka pakkumuse otsus. 1.6. Ehkki hindamisdokumendis ei ole vaidlustaja pakkumust üldse hinnanud, oleks vaidlustaja pakkumus tema hankemenetluses jätkamise korral olnud soodsaim ning seega osutunud edukaks. Seega on vaidlustajal põhjendatud huvi tema pakkumuse tagasilükkamise otsuse kehtetuks tunnistamise osas, kuna see võimaldab tal osutuda edukaks ja sõlmida hankeleping. 2. PÕHJENDUSED 2.1. Hankija põhjendused vaidlustaja pakkumuse mittevastavuse ning selle tagasilükkamise kohta on toodud 27.10.2025 tagasilükkamise protokollis. Protokollis märgitud põhjendused ei ole asjakohased. 2.2. Tagasilükkamise protokollis märgitu kohaselt: „Riigihanke nr 290035 pakkumuste vastavuse kontrollimisel tuvastas hankija FOB Solutions OÜ pakkumuses mitmeid puudusi. Alljärgnevalt on igas plokis esmalt viide hanke dokumentatsioonis „Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabelis“ kirjeldatud nõuete alampunktile ja kursiivis nõude sisule ning seejärel hankija tuvastatud mittevastavuse kirjeldus.“ 2.3. Hankija otsus vaidlustaja pakkumuse tagasilükkamise kohta on õigusvastane, kuna see põhineb hankija poolsel olulisel eksimusel pakutava tarkvaraplatvormi (Elastic) tehnilise olemuse mõistmisel ning hankedokumentide meelevaldsel ja ebaõigel tõlgendamisel. Samuti ei ole hankija tegevus hanke alusdokumentide 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 parasjagu sobiv on. Nii on hankija otsus vaidlustaja pakkumuse tagasilükkamisel vastuolus hanke aluspõhimõtetega, ennekõike läbipaistvuse põhimõttega (RHS § 3 p 1). 2.4. Hankija on ekslikult tõlgendanud tarkvaraplatvormi standardset konfigureeritavust ja paigaldamise käigus teostatavat seadistamist kui pakkumuse puudust. Kaasaegsed ja 2/8  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. 2.5. Alljärgnevalt lükkab vaidlustaja ümber kõik tagasilükkamise protokollis toodud väited, mis on olnud hankija ebaõige otsuse aluseks. Viidatud nõude punktid tulenevad tehnilise kirjelduse (lisa 4) punktist 4 ja vastavustabelist ning neile on viidatud ka tagasilükkamise protokollis. Vaidlustaja on esitanud vastavustabelis viited oma pakutavale (lisa 5) 2.6. Nõue 4.8: Andmeelementide tuvastamine 2.6.1. Hankija leidis pakkumuse tagasilükkamise otsuses, 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 vaidlustaja selgituse pinnalt, et kuna funktsionaalsus realiseeritakse paigalduse osana GROK mustrite abil, siis see ei sisaldu pakutavas süsteemis pakkumuste esitamise hetkel. Lisaks tegi hankija olulise faktivea, kui samastas Elasticu GROK funktsionaalsuse veebilehelt x.ai/grok leitud tehisintellekti tööriistaga. 2.6.2. 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 ebaprofessionaalne ning on viinud täiesti vale järelduseni. Viide tootja dokumentatsioonile: https://www.elastic.co/docs/reference/logstash/plugins/plugins-filters-grok 2.6.3. Hankija väide on võrreldav olukorraga, kus ostetakse uus nutitelefon ja nõutakse, et selles oleksid kõik kontaktid juba olemas. Kontaktide lisamine (analoogne GROK mustrite konfigureerimisega) on telefoni kasutuselevõtu standardne osa, mitte telefoni puudus. Vaidlsutaja kinnitas, et tootes on olemas võimekus ja vajalikud mustrid koostatakse paigalduse osana. See ongi selliste platvormide tööpõhimõte. 2.6.4. 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. 3/8 2.6.5. Hankija on teinud otsuse olulise faktivea pinnalt, mis on menetlusnormide rikkumine. Vastavalt RHS § 114 lg 2-le saab pakkumuse tagasi lükata sisuliste mittevastavuste korral. Konfigureerimise vajadus ei ole sisuline puudus, vaid toote normaalne osa, ning pakkumuse tagasilükkamine sellel alusel on ebaproportsionaalne. 2.7. Nõue 4.10: Andmesubjekti tuvastamine 2.7.1. 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). 2.7.2. 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 2.7.3. See on analoogne moodsa muusikaäpi võimega leida "Madonna", isegi kui kasutaja kirjutas "Madona". Tegemist on sisseehitatud intelligentsusega. 2.7.4. Hankija väide, et ta "ei saanud kinnitust", on subjektiivne hinnang, mitte objektiivne puudus. 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). 2.7.5. Vaidlsutaja kinnitas vastavustabelis nõude täitmist ja selgitas tehnilist lahendust. Sellest piisab vastavuse tõendamiseks, kui hankedokumentides pole seatud konkreetseid, mõõdetavaid demo-nõudeid. Hankija on asetanud pakkuja ebavõrdsesse olukorda, nõudes midagi enamat, kui hankedokumendid 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. 2.8. Nõue 4.24: Agregeerimine rakenduse graafil 2.8.1. Hankija märkis pakkumuse tagasilükkamise otsuses, et pakkuja demonstreeris statistilist diagrammi, mitte andmeelementide agregeerimist võrgustiku graafil. 2.8.2. 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 4/8  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 2.8.3. 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 mitmetimõistetavusele vaidlustaja kahjuks. Selliselt on tegemist riigihangete läbipaistvuse ja võrdse kohtlemise põhimõtete rikkumisega (RHS § 3 p 1 ja 2). 2.9. Nõue 4.25: Statistilised ja võrgustikufunktsioonid 2.9.1. 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. 2.9.2. 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. 2.9.3. 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/anomaly- detection/ml-configuring-populations 5/8  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 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. 2.9.4. 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 hankedokumentides 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. 2.9.5. Kokkuvõttes: 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. 2.10. Nõue 4.30: Visualiseerimise valiknõuded 2.10.1. Hankija leidis, et Pakkuja 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). 2.10.2. Nõue 4.30.1 (Ringtehingute ahelad): Hankija väitis, et masinõppe funktsionaalsus vajab "treenimist" ja pole seega valmis. 6/8 2.10.3. 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 2.10.4. Nõue 4.30.2 (Node suuruse muutmine): Hankija väitis, et kuna seda saab teha reegleid kombineerides, pole funktsioon valmis. 2.10.5. 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 2.10.6. Nõue 4.30.10 (Node'de agregeerimine tunnuse alusel): Hankija leidis, et süsteem ei võimalda grupeerida tunnuse alusel, vaid ainult ükshaaval. 2.10.7. 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. 2.10.8. 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. 2.10.9. See näitab ilmselt hankija vähest arusaama kaasaegsetest analüütikaplatvormidest. 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. 2.11. Eeltoodust nähtuvalt on hankija eksinud vaidlustaja pakkumuse sisu hindamisel, pidades seda ekslikult mittevastavaks. Vaidlustaja pakkumuse tagasilükkamise otsus on seega õigusvastane ja põhineb hankija olulisel eksimusel nii pakutava tarkvara tehnilise olemuse mõistmisel kui ka hankedokumentide tõlgendamisel. Hankija on järjepidevalt pidanud tarkvara standardset seadistamist ja konfigureerimist puuduseks. See on põhimõtteliselt vale lähenemine, mis on viinud ebaõige ja põhjendamatu otsuseni. 7/8 2.12. 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. 2.13. Tuginedes eelnevale tuleb hankija 28.10.2025 otsus vaidlustaja pakkumuse tagasilükkamise kohta tunnistada kehtetuks ning sellest tulenevalt ka 28.10.2025 otsus STATS Unities OÜ pakkumuse edukaks tunnistamise kohta. 3. MENETLUSLIKUD KÜSIMUSED 3.1. Vaidlustustähtaeg. RHS § 189 lg 1 kohaselt peab vaidlustus olema laekunud vaidlustuskomisjonile kümne päeva jooksul alates päevast, kui vaidlustaja sai teada või pidi teada saama oma õiguste rikkumisest või huvide kahjustamisest, välja arvatud RHS § 189 lõigetes 2–5 nimetatud juhul, kuid mitte pärast hankelepingu sõlmimist. Hankija saatis teate tehtud otsuste kohta 28.10.2025 (vt lisa 1). Seega on vaidlustuse esitamise tähtaeg 07.11.2025 ning vaidlustus esitatud tähtaegselt. 3.2. Riigilõiv. RLS § 258 lg 1 p 2 kohaselt tasutakse rahvusvahelist piirmäära ületava riigihanke vaidlustuse esitamisel riigilõivu 1280 eurot. Hanke andmete järgi on tegemist rahvusvahelist piirmäära ületava hankega. Vaidlustaja on tasunud seega riigilõivu summas 1280 eurot (lisa 6). 3.3. Vaidlustuse läbivaatamise vorm. Tuginedes RHS § 195 lg-le 2 teatab vaidlustaja, et ei pea vaidlustuse läbivaatamist avalikul istungil vajalikuks ning nõustub kirjaliku menetlusega. Lugupidamisega /allkirjastatud digitaalselt/ Kristo Kallas vandeadvokaat FOB Solutions OÜ esindaja Lisad: 1. Hankija 28.10.2025 teade tehtud otsuste kohta; 2. Hankija 27.10.2025 otsus FOB Solutions OÜ pakkumuse tagasilükkamise kohta; 3. Hankija 27.10.2025 otsus STATS Unities OÜ pakkumuse edukaks tunnistamise kohta; 4. Tehniline kirjeldus; 5. FOB Solutions OÜ pakkumuse osaks olev vastavustabel; 6. Riigilõivu maksekorraldus. 8/8 Euroopa Liidu taaste - ja vastupidavusrahastu ( Recovery and Resilience Facility (RRF)) TEHNILINE KIRJELDUS „ Võrgustikuanalüü tika tarkvara “ hange Hange viiakse läbi R ahapesu Andmebüroo tellimusel taaste- ja vastupidavusrahastu (RRF) vahenditest rakendus plaani investeeringu „ Reaalaja strateegilise analüüsi süsteem “ ühe komponendina . 1. Hanke taust ja probleemikirjeldus Rahandusministeeriumi valitsemisalas paikneva Rahapesu Andmebüroo (edaspidi RAB) keskseks ülesan de ks on rahapesu ja terrorismi rahastamise tõkestamine. Peamisteks mehhanismideks on rahapesu ja terrorismi rahastamise ning finantssanktsioonide rakendamise teadete töötlemine ja järelevalve teostamine kohustatud isikute tegevuse üle . Eelnimetatud ning rahapesu ja terrorismi rahastamise tõkestamise seaduse (edaspidi RahaPTS ) § 54 lõikest 1 tulenevate teiste ülesannete täitmine eeldab andmete süsteemset analüüsi kolmel tasemel: operatiivanalüüs – konkreetse finantstehingu õiguspärasuse hindamine, analüüsides seotud tehinguid ja isikuid; taktikaline analüüs – RAB-i vastutusalasse kuuluva majandustegevusvaldkonna, teenusepakkuja, rikkumise liigi, tüpoloogia vms uurimine enamasti koos kahtlaste isikute tuvastamisega; strateegiline analüüs – rikkumiste trendide ja mustrite uurimine. Operatiivanalüüsi põhivajadused katab infosüsteem RABIS, taktikaliseks ja strateegiliseks analüüsiks kasutatakse Tableau tarkvara. Ülemaailmselt tegelevad rahapesu andmebürood eelkõige kohustatud isikute poolt esitatud kahtlaste tehingute teadete analüüsimisega ning vastavalt siseriiklikule pädevusele , kas ka nende kohtueelse uurimisega või vastava info edastamisega pädevale asutusele. Kohustatud isikud omakorda lähtuvad andmebüroo poolt levitatud tüpoloogiatest ja nende indikaatoritest . 202 4 .a esitati RAB-ile rekordiliselt üle 32 0 00 tea te . Andmekogus hoitakse viimase 15a teateid. Operatiivbaasi andmed sünkroniseeritakse reaalajalähedaselt andmelattu. Täiendavalt laetakse andmelattu eraldi protsessidega muude allikate andmeid. Nii operatiivbaas kui ka andmeladu baseeruvad Postgre andmebaasiplatvormil. Andmeladu haldab Rahandusministeeriumi Infotehnoloogiakeskus ( edaspidi RmIT). R mIT volitatud töötlejana tagab andmelao majutamiseks vajaliku infotehnoloogilise keskkonna ja selle tehnilise valmisoleku . A i nult teadetele tuginedes kulub mitmeid kuid, kuni koguneb märkimisväärne hulk rahapesuteateid, mis võivad viidata uudsele rahapesutüpoloogiale. Ja halvemini teavitatavates majandussektorites lausa aasta, kuni uuendatakse vastavat strateegilist analüüsi. Kogu selle perioodi jäävad uudset meetodit kasutavad rahapesijad tõenäoliselt märkamatuks, ning tõkestamatult saadakse kasutada rahasid uute kuritegude toimepanemiseks või nende abil saadud hüvede nautimiseks. RAB - i l on vaja süstemaatilis ema t ja paindlik ku vaadet andmetele , nii rahapesuteadete kui ka majandusalaste registrite ulatuses . 2. Hanke eesmärk , hanke ese ja soovitud tulemused Hanke e esmärgiks on rahapesujuhtumite varajane avastamine ja analüütikute käsitöö vähen da mine täiendava automatiseerimise abil. RAB - i l on vaja andmetest ära tunda rahapesu juhtumeid ja ilma liigse nn taustamürata tuvastada sündmuste käik ning faktilised asjaolud. Kohustatud isikute ja koostöö partnerite töö efektiivsemaks muutmiseks on vaja märgata ning kirjeldada valdkonna uusi trende. See aitab kõigil osapooltel keskenduda kõige tähtsamale ja vähendada seeläbi halduskoormust. Soovitud tulemus e saavutamiseks on vaja : 1. soetada nõuetele vastav analüütikatarkvara ; 2. liidestada analüütikatarkvara RAB-i andmelaoga ; 3. koolitada analüütikatarkvara haldamisega seotud DevOps insenerid ja administraatorid ning lõppkasutajad . Hanke esemeks on nõuetele vastava analüütikatarkvara kasutusõigused, analüütikatarkvara paigaldamise juhendamine, RAB-i andmelaoga analüütikatarkvara liidestami se juhendamine ning analüütikatarkvara haldamisega seotud DevOps inseneride ja administraatorite ning lõppkasutajate koolitamine. 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üütikatarkvara st . Rakendus omakorda võib olla vaid lõppkasutajale mõeldud kasutajaliides analüütikatarkvarast . 3. Hanke esemete kirjeldus Han kija hangib alljärgnevaid asju ja teenuseid : 3. 1. ANALÜÜTIKATARKVARA KASUTUSÕIGUSED Lepingu täitja teeb Tell ijale kättesaadavaks hanke nõuetele vastava analüütikatarkvara paigaldamis- ja seadistusfa ilid ning tarkvara tarneahelad (CI/CD pipeline ) , dokumentatsiooni ning kasutuslitsentsid . Tarkvara kasutuslitsentsid o stetakse üh eks aastaks, võimalusega samadel tingimustel pikendada üheks kuni kolmeks aastaks. Litsentside pikendamisel ei tohi aasta ne litsentsitasu erineda rohkem kui kümme protsenti eelneva aasta litsentsitasust . Litsentside kehtivusaega hakatakse arvestama kasutuselevõtuks vajalike tööde (tarkvara paigaldamine, andmelaoga liidestamine , seadistamine, kasutajate koolitamine) vastuvõtmise päevast. Tarkvara maksimaalne kasutajate arv on 60, neist samaaegseid kasutajaid maksimaalselt 30. Tarkvara litsents /litsentsid peavad katma live -, prelive , test - ja arendusk es k konna. 3. 2 . ANALÜÜTIKATARKVARA PAIGALDAMINE JA LIIDESTAMINE Lepingu täitja juhendab RmIT-i DevOps i nsenere analüütikatarkvara RmIT Azure pilve keskkonda paigald amisel , konfigureerimisel ja RAB-i andmelaoga liidestamisel , et tagad a andmete sünkroonsus ja tellija vajadustele vastav süsteemi töötamine. Liidestamine ei tohi nõuda t ellijalt omapoolset tarkvara arendamist. Kui liidestamiseks on vajalik abistava tarkvara kasutamine, siis on lubatud kasutada vabavara. Pakutud süsteemil peab olema automatiseeritud terviklahenduse paigalduspakett ( Installation Wizard ) Kubernetes klastrisse nii avalikule pilveplatvormile kui maapealsele privaatpilve platvormile ilma tellijapoolse täiendava ökosüsteemi või komponente omamata. 3. 3 . KOOLITAMINE L epingu täitja peab kooli tama välja RAB-i ja RmIT-i DevOps i nsenerid ning administraatorid (kuni 5 inimest) ja analüütikatarkvara esmased lõppkasutajad ( 2 0 inimest) . Koolitus ed pea vad toimuma eesti või inglise keeles. DevOps i nseneride ja administraatorite koolitus peab toimuma tellija pakutud ruumides hiljemalt kolme nädala jooksul lepingu sõlmimisest arvates, kuid mitte varem kui üks nädal enne süsteemi paigaldamise alustamist. DevOps i nsenerid peavad omandama oskuse juhendmaterjalide alusel süsteemi paigaldamiseks, andmeallikate liidestamiseks ja süsteemi konfigureerimiseks. Koolituse tulemusena DevOps i nsener : tunneb süsteemi terviklikku ülesehitust ja kasutatud tehnoloogiaid; oskab süsteemi paigaldada RmIT Azure keskkonda, paigaldada / hallata tarkvaratootja paranduspakette ja versiooniuuendusi; tunneb süsteemi seadete loogikat ja oskab neid konfigureerida; oskab süsteemiga liidestada uusi andmeallikaid, s.h API teenuseid; oskab luua ja administreerida analüütikatarkvara kasutajagruppe; saab aru süsteemi logidest. Lõppkasutajate koolitus toimub videokoosoleku vormis (nt Teams’is ) hiljemalt üks nädal pärast süsteemi paigaldamise lõpetamist . Lõppkasutajate koolitus peab olema praktilises vormis , tagades koolitatavatele ligipääs u täitja demo - või koolitus kes k kon da. K oolituse tulemusena lõppkasutajad omanda vad oskuse võrgustikuanalüüsi läbiviimiseks ning o n võimelised kasutama rakendust kogu funktsionaalsete nõuete ulatuses. Koolitus ed toimu vad lepingu täitja demo - või koolitus keskkonnas , mis on ehitatud Azure pilve . 3.4 . LEPINGULISTE TEGEVUSTE PERIOOD Tarkvara paigaldamine, andmelaoga liidestamine , seadistamine ja koolitused peavad toimuma maksimaalselt viie kuu jooksul arvates lepingu sõlmimisest. 4 . Süsteemi /rakenduse funktsionaalsed nõuded Andmete importimise ja seostamise nõuded: Süsteem peab võimaldama kasutada andmeallikaid läbi API (masin-masin rakendus liides) . Andmeid peab saama süsteemi laadida sünkroonis nii voona ( str eam ) kui ka paketina ( batch ) . Süsteemis peab lisaks saama andmeid lisada CSV- või XLSX-failina ja käsitsi sisestades. Rakendus peab suutma omavahel seostada erinevatest allikatest pärit andmeid, s.h andmemudelis defineerimata kujul. Andmete paketina ( batch ) laadimist süsteemi peab saama ajastada kellaajaliselt. Süsteem peab võimaldama dünaamiliselt lisada uusi erineva andmestruktuuriga andmeallikaid. Süsteem peab võimaldama seostada ( mapping ) uusi andmeallikaid konfiguratsiooni muutmise abil. Analüüsi käigus tuletatud ja sisestatud andmeid peab lõppkasutaja saama süsteemi salvestada nii, et andmed on kasutatavad ka teistel lõppkasutajatel . 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 . Andmesubjektide tuvastamise loogika t peab klient saama konfigureerida. 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 "2 6 -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. Süsteem peab oskama samastada Eesti keele ja rahvusvaheliselt üldlevinud keelte reeglite järgi kirjutatud nimesid, näiteks täpitähtede osas. Samuti üldlevinud nimelühendid, s.h teiste sõnatüvedega, näiteks Sass kui lühend Aleksandrist või Bob kui William. Nimede seostamisreeglite loogika peab olema konfigureeritav. Kui andme allikas on info isiku nime muutumisest, siis süsteem peab tuvastama isiku nii vanu kui ka uusi seoseid. Süsteem peab võimaldama ühendust relatsioonilise ja graph andmebaasiga. Süsteem peab võimaldama dünaamilist andmemudelit, s.t arvestama andmestiku täiendamisega (uued veerud, andmeallikad) Andmete visualiseerimise ja võrgustiku kuvamise nõuded : Rakenduse kasutajaliides peab olema brauseripõhine ( vt RFN nõudeid ) . Rakenduse kasutajaliides peab olema inglis - või eestikeelne. Rakendusest peab saama otsida/ filtreerida nii märksõnade kui ka tunnuste kombinatsioonide järgi. Märksõna otsing /filtreerimine peab võimaldama leida sarnase kujuga sõnu või sõnaühendeid ( Fuzzy matching ). Rakenduse k asutaja peab saama lihtsasti muuta kokkulangevuse tõenäosust. Rakenduse s peab saama valida ülesande täitmiseks asjakohaseid andmeallikaid. Süsteemis võivad seosed olla eelnevalt tuvastatud, kuid kuva da tuleb ka kõige värskemaid ja reaalajas kättesaadavaid andmeid. Rakenduse graafil ( graph ) kuvatud iga andmesubjekti ja seose kohta peab saama vaadata detailinfot. Rakendus peab võimaldama graafil kuvada seoseid suure hulga (üle 50 000) andmesubjekti vahel. Rakendus peab kasutama reaalajas API ühendusi, kui need on defineeritud. Rakenduse graafil peab saama agregeerida nii isikute, seoste kui ka tunnuste kaupa, kas läbi tunnuste määramise või graafil andmeelemente märgistades. Rakenduse graafil peab saama kasutada üldlevinud statistilisi ja võrgustikku iseloomustavaid funktsioone (näiteks aritmeetiline keskmine ( arithmetic average ) , mood ( mode ) , detsiil ( decile ) , tsentraalsus ( centrality ), tihedus ( density ), vahendatus ( betweenness ), lähedus ( closeness ) ) . Loetelust p eab olema täidetud vähemalt 4 funktsiooni. Rakenduse graafi peab saama salvestada nii rakenduses edaspidiseks kasutamiseks kui ka üldlevinud formaadis failina (nt PDF, JPG, CSV) edastamiseks. Punktis REF _Ref180473969 \r \h 4.21 nimetatud detailinfot ei pea pildiformaadis eksportimisel kuvama. Rakenduse graafil peab saama märgistada andmesubjektid, mille osas soovi takse võrgustikku laiendada, koos laiendamise aluseks olevate tunnuste määramisega. Rakenduse graafil peab saama muuta aja dimensiooni, näiteks kuidas seosed on muutunud kuude jooksul. Rakendus peab võimaldama otsingu parameetrina (näiteks riigid, isikud või kontod) lisada CSV või XLSX faili. Visualiseerimise valiknõuded rakenduse graafile : r aha liikumisel pangakontode või virtuaalvääringu rahakottide vahel peab süsteem ära tundma ringtehingute ahelad ja rakendus neid kuvama esile toodult ; võrgustiku andmesubjekti ( node ) suurus peab olema rakenduses määratud automaatselt ja muudetav käsitsi; võrgustiku andmesubjekti ( node ) kuju/ikoon/pilt peab olema rakenduses määratud automaatselt ja muudetav käsitsi; võrgustiku andmesubjekti ( node ) värv peab olema rakenduses määratud automaatselt ja muudetav käsitsi; võrgustiku kahe andmesubjekti ( node ) vahelise ühendusjoone ( link ) paksus peab olema rakenduses määratud automaatselt ja muudetav käsitsi; võrgustiku kahe andmesubjekti ( node ) vahelise ühendusjoone ( link ) värv peab olema rakenduses määratud automaatselt ja muudetav käsitsi; võrgustiku kahe andmesubjekti ( node ) vahelisele ühendusjoonele ( link ) peab kasutaja saama määrata suunda ehk nooleotsa; võrgustiku kahe andmesubjekti ( node ) vahelise mõlemasuunalise suhte korral saab kasutaja mõlema suuna jooni ( link ) modifitseerida eraldi (joone jämedus, värv, väärtus); kui võrgustiku kahe andmesubjekti ( node ) vahel on mitu samasuunalist ühendust ( link ), siis saab need agregeerida üheks ühenduseks ( link ); samale tunnusele vastavaid võrgustiku andmesubjekte ( node ) saab määratud tunnuse alusel agregeerida ja hiljem uuesti lahku eristada . Näiteks kõik samal aadressil asuvad isikud liita kokku üheks subjektiks ( node ); rakendus valib vaikimisi andmestikust lähtuva võrgustiku graafi tüübi (seoste skeemi) , kuid kasutaja saab graafi t üüpi vahetada ilma , et otsingu ja filtrite parameetrid muutuksid . NB! Punktis REF _Ref180485235 \r \h 4.30 loetletud valiknõuetest peavad olema täidetud vähemalt 4 (neli) nõuet. Valiknõuete täitmise osakaal mõjutab p akkumuse hindamistulemust. 5 . Süsteemi mitte funktsionaalsed nõuded Pakutav analüütikatarkvara võib koosneda mitmetest komponentidest, kuid need peavad olema integreeritud tõrgeteta koostoimivaks süsteemiks. Lõppkasutaja peab saama oma ülesandeid täita ühes rakenduses. Süsteem peab täitma kõiki üldisi mittefunktsionaalseid nõudeid: Vastavalt Majandus- ja kommunikatsiooniministeeriumi poolt väljatöötatud "Avalike pilveteenuste kasutuselevõtu kontseptsioon ja tegevuskava" dokumendile kasutatakse vaikimisi esimese eelistusena uute teenuste loomisel ja olemasolevate teenuste versiooniuuenduste käigus avaliku pilve platvormi. See põhimõte kehtib juhul, kui vajalikud eeldused on täidetavad ja ärinõuded seda võimaldavad. Dokumendi viide: https://rit.ee/sites/default/files/documents/2024-06/kontseptsioon%20ja%20tegevuskava_0.pdf Infosüsteem peab olema projekteeritud arvestades rakenduse käideldavuse taset. Lahendus peab vastama RMIT IT-profiilile. Rakenduse, andmebaasi ja kolmanda osapoole komponentide platvorm(id)/versioon(id) peavad olema sellised, mille eluea lõpp (EOL) pole teadaolevalt vähem kui 2 aasta pärast ning mis ei ole alles arenduse algusjärgus (alfa, beeta või snapshot staatuses). Samuti ei tohi kasutada komponentide taunitud ( deprecated ) funktsionaalsust. Rakenduse käivitus (saidi taaskäivitus , konfiguratsiooni muutmine vms) peab toimuma mõistliku aja jooksul. Andmebaas ja rakendus peavad kasutama UTF-8 kodeeringut. Uniform resource identifier (URI) pikkus ei tohi ületada ühegi toetatava brauseri maksimaalset lubatud väärtust. Kasutajate autentimiseks tuleb kasutada haldusalas kasutuses olevaid teeke või rakendust. Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades. Kõik paroolid peab rakendus salvestama vaid räsitud kujul. Süsteemis esinevate tehniliste vigade sisu ei tohi lõppkasutajale kuvada. Koos veaga peab kuvama unikaalse vea tunnuse , mis on logidest lihtsalt leitav. Süsteemil on olemas detailne kirjalik dokumentatsioon, mis võimaldab iseseisvat paigaldamist keskkondadesse, administreerimiseks ja integreerimiseks ning rakenduse kasutusjuhendid piisavad lõppkasutaja abistamiseks. Süsteem peab toimima s õ ltumata teenusepakkuja teenuste kättesaadavusest Süsteemil ei tohi tekkida jõudlusprobleeme andmemahu 2,5 TB ja 30 samaaegse kasutaja korral, kelle päringud ei ole optimeeritud. Lahenduse funktsioone saab konfigureerida läbi konfiguratsioonihalduse. Süsteem peab võimaldama kätte saada süsteemi- ja kasutuslogi. Lahenduse paigaldus privaatpilves peab olema konteineri põhine. Privaatpilve paigalduse korral p eab k onteinerite orkestreerimi ne olema võimalik kasutades Kubernetes’t teenusena . Lahendus peab olema paigaldatav Azure pilve keskkonda . 6. Lisainfo 6.1 Nõuetele vastavuse hindamiseks esitab p akkuja Funktsionaalsete ja mittefunktsionaalsete nõuete vastavustabel.xlsx vastavustabel i , 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 v astavustabelis 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) . HINDAMISE JA PAKKUJA EDUKAKS TUNNISTAMISE KOONDPROTOKOLL Võttes aluseks riigihangete seaduse ja riigihanke „ Võrgustikuanalüütika tarkvara “ (viitenumber 2 90035 ) alusdokumentides esitatud tingimused ning pakkumuse tagasilükkamise protokollis ja pakkumuste vastavaks tunnistamise protokolli de s tehtud otsused ning pakkumuste hindamis protokollide tulemused, hindas hankija kolme vastavaks tunnistatud pakkumus t alljärgnevate hindamiskriteeriumide alusel: Kriteeriumid Osakaal 1. Pakkumuse kogu maksumus 7 0 2. Funktsionaalsed valiknõuded 15 3. Tarkvara kasutamise lihtsus 15 Kokku: 100 Edastatud pakkumuste numbrilised näitajad ja neile antud väärtuspunktid eelnimetatud hindamiskriteeriumide eest: Pakkuja 70 % 15 % 1 5 % Väärtus punktid kokku Pakkumuse kogu maksumus eurodes km-ta Pakkumuse kogu maksumus e eest saadud punktid Funktsio naalsed valiknõuded arvuliselt Funktsio naalsete valik nõuete eest saadud punktid Tarkvara kasutamise lihtsuse hindamis punktid Tarkvara kasutamise lihtsuse eest saadud punktid Aktsiaselts Fujitsu Estonia 653 859 5 0, 8 5 6 1 2 , 85 15 15,00 78 , 70 STATS Unities OÜ 475 000 70,00 3 6 , 42 1 1 1 1 ,00 8 7 ,42 1. Hindamiskriteeriumi alusel saadud väärtuspunktid liidetakse ja saadakse pakkumust iseloomustav väärtuspunktide summa. Väärtuspunkte omistatakse täpsusega kaks kohta pärast koma. 2. Edukaks tunnistatakse pakkumus, mis saab hindamiskriteeriumite alusel kujunevate väärtuspunktide summeerimisel kõige rohkem väärtuspunkte ja on seega majanduslikult soodsaim pakkumus. 2.1. Lähtudes antud tingimusest esitas majanduslikult soodsaima ja seega ka eduka pakkumuse STATS Unities OÜ saades kokku 8 7 ,42 väärtuspunkti . (Allkirjastatud digitaalselt) (Allkirjastatud digitaalselt) (Allkirjastatud digitaalselt) Arvo Taar Marvin Palm Katre Noor Komisjoni esimees Komisjoni liige Komisjoni liige (Allkirjastatud digitaalselt) Kairi Osolainen Komisjoni liige                   ! " ! #$$!%& $              !""#"$$ %& & ' () * +,--  (-& . ' () & - & //00 1 1!!1! 0 0"!!# /   ! " !!'#(#%)& $    (2( 3 //3 %& & ' ()  (-& . ' () //0# 1 1!!114"5#61 * 7& 89 & *    & :; <& 89 & &   //2//!=9 ( / >(%9  3?/ !9( $1 19/  ( 3 - '&-< * @& ) * +,--  (-& : 7 & '& &-<  & A) & - & !01.11 'B -C  C B & .11) / ,-   , : 7 & ,@+ +,-- , C&  !#114$ D &-<    :  & . !#1110! !6  &--  8& :  &--& * +,--  8& : -& & - & 1.11 * ##$+ " & (,'#% $#, ?, & & & 7& -&  & &  <&  "1 # #5655 16. .!1!$ #E4!E1 ( / >&9 &F !9 $1 1 ,,&&9 / 9  111"!$! ! ! 4$4