Vaidlustus

Riigihangete vaidlustuskomisjon Tartu mnt 85, Tallinn, Harju maakond, 10115 e-post: [email protected] Vaidlustus Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (riigihangete registri viitenumber 280554) hindamise ja edukaks tunnistamise otsustele 1. ASJAOLUD 12.06.2024 esitas Ettevõtluse ja Innovatsiooni Sihtasutus (edaspidi Hankija) riigihangete registri kaudu kutse pakkumuse esitamiseks avatud hankemenetluses „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (riigihangete registri viitenumber 280554) (edaspidi Hange). Pakkumuse esitamise tähtajaks määrati 16.08.2024. Pakkumuse koosseisus pidid pakkujad esitama muuhulgas vastavustingimustes sätestatud sisulise pakkumuse, mille koosseisus tuli esitada proovitöö, mille nõuded on toodud RHAD lisas 1b. Pakkumuse hindamistingimused olid toodud hanke alusdokumendis, punktis 5.7 (Lisa 1). Kokku oli võimalik pakkumuses esitatud proovitöö (kvaliteedikriteeriumi) eest saada kuni 50 hindepunkti, mis jagunesid kahe alakriteeriumi vahel (30+20 punkti). Lisaks hinnati pakkumuses ühe töötunni hinda (ilma käibemaksuta), mille eest oli võimalik saada kuni 50 hindepunkti (kokku maksimaalselt 100 punkti). Finest AS1 (edaspidi Vaidlustaja) esitas pakkumuse2 läbi riigihangete registri tähtaegselt. Pakkumuste avamise järgselt selgus, et hankes esitas lisaks Vaidlustajale pakkumuse veel 4 pakkujat (Aktsiaselts Helmes, ühispakkujad Krabu Grupp OÜ ja Catapult Labs OÜ, ühispakkujad Aktsiaselts Datel ja Trinidad Wiseman OÜ, Midori Virtuality OÜ). 19.09.2024 tegi Hankija riigihangete registri teabevahetuse kaudu (nr 886046) pakkujatele nähtavaks pakkumuste vastavaks ja edukaks tunnistamise ning eduka pakkuja kõrvaldamata jätmise otsused. Lisaks avaldati antud otsustega koos dokument „Hankekomisjoni protokoll Finestmedia.docx“ (Lisa 2). Nimetatud otsuste kohaselt tunnistati kõik esitatud pakkumused vastavaks ning edukaks tunnistati 1 Alates 19.09.2024 muutis Finestmedia AS oma ärinime. Uueks ärinimeks on Finest AS (reg. Nr. 10714404) 2 Kõik viidatud dokumendid on kättesaadavad riigihangete registri vahendusel Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (280554) vaidlustus. Finest AS ühispakkuja Krabu Grupp OÜ ja Catapult Labs OÜ pakkumus (edaspidi Edukas pakkuja), kui enim väärtuspunkte kogunud pakkumus. Edukas pakkuja oli saanud pakkumuse maksumuse eest 38.96 punkti ja kvaliteedikriteeriumi eesti 45 punkti (kokku 83.96 punkti). Vaidlustaja punktisummaks oli pakkumuse maksumuse eest 32.34 punkti ja kvaliteedikriteeriumi eest 50 punkti. Kokku omistati Vaidlustajale seega 82.34 punkti. Teistele pakkujatele omistati punkte järgmiselt: ühispakkujad Aktsiaselts Datel ja Trinidad Wiseman OÜ 79.85 punkti, Aktsiaselts Helmes 62.67 punkti ja Midori Virtuality OÜ 64.00 punkti. Tutvudes Hankija otsusega ja selles sisalduvate põhjendustega, leiab Vaidlustaja, et Hankija on edukaks tunnistatud pakkuja puhul punkte omistanud ebaõiglaselt ja ebakorrektselt ega vastavalt RHAD sätestatule. Vaidlustaja on seisukohal, et kuna Hankija on vähendanud Eduka pakkumuse puhul proovitöö eest punkte ühe alamkriteeriumi (Mockup`de ärinõuded) nõude kohaselt, siis oleks pidanud punkte vähendama ka vähemalt ühe teise antud alamkriteeriumi nõude kohaselt. Samuti on Hankija eksinud proovitöö teise alamkriteeriumi (Mockup`de visuaal ja kvaliteet) punktide andmisel. 20.09.2024 esitas Vaidlustaja Hankijale teabevahetusega vastavasisulise järelpäringu (Lisa 3), mille vastamistähtaeg registri andmetel on 26.09.2024. Hankija selgitas oma 23.09.2024 vastuses: „Veebirakenduse üldine stiil ja veebilehe vastavus disainisüsteemile on omavahel seotud, kuid neil on erinevad eesmärgid ja fookus, mida vastavalt kriteeriumitele ka hinnati. Brand Estonia ja Visit Estonia stiilinõuetele vastavuse osas hinnati, kas rakendus vastab brändi visuaalsetele nõuetele ning järgib täpselt etteantud disainisüsteemi. See tähendab, et hinnati, kas Pakkuja kasutas oma proovitöös disainisüsteemis toodud disainielemente nagu nupud, ikoonid, sisendväljad jne ning järgis CVI-d ehk kindlaid värvitoone ja fontide kombinatsioone. Visitestonia.com veebi ja kaardirakenduse kasutusloogika ja üldise stiili osas hinnati, kas kasutajakogemus on sama intuitiivne ning stiil ühtne ja järjepidev nagu visitestonia.com veebilehel. Üldise stiili osas ei hinnatud brändi visuaalsete nõuete täitmist (selle jaoks oli hindamiseks eraldi hindamiskriteerium), vaid kas proovitöö lahenduses toodud mockup'd pakuvad samasugust visuaalset ja funktsionaalset tunnetust nagu visitestonia.com veebilehel ning kas kõik mockup'd järgivad sarnast loogikat ja stiili, pakkudes kasutajatele järjepidevat kogemust nii nagu visitestonia.com veebilehel olles. Selle alusel oli Hankijal võimalik aru saada, kas Pakkuja on visitestonia.com veebikeskkonnaga tutvunud ja proovitöö jaoks olulisemad punktid läbi töötanud ega pakkunud lahendust, mis erineb täielikult visitestonia.com veebilehest või selle kasutusloogikast. Kahte aspekti hinnati eraldi, sest disainisüsteemi nõuete täitmine ei pruugi otseselt mõjutada rakenduse kasutusloogikat või stiili üldiselt. Rakenduse funktsionaalsus ja loogika võivad olla suurepärased isegi siis, kui visuaalset identiteeti pole täpselt järgitud.“ Lehekülg: 2 Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (280554) vaidlustus. Finest AS Vaidlustaja leiab ka täiendavatest selgitustest tulenevalt, et Hankija on hakanud hanke dokumentides olevaid hindamiskriteeriume sisustama, millega pakkujad ei olnud samaväärselt teadlikud ning juhul kui Hankija oleks pakkumuste hindamise läbi viinud vastavalt hindamiskriteeriumidele, siis oleks Vaidlustajal võimalus olla edukas pakkuja pärast Hankija poolt kõrvaldamiste aluste kontrolli läbiviimist. Eeltoodust tulenevalt ei ole Vaidlustaja hinnangul Hankija taganud Riigihanke eesmärki RHS § 2 alusel ja vastavust Riigihanke korraldamise üldpõhimõttele RHS § 3 p 1 alusel - tegutseda riigihanke korraldamisel läbipaistvalt, kontrollitavalt ja proportsionaalselt. Hankija on oma 19.09.2024 avaldatud teates märkinud, et Hankija otsuse peale võib esitada vaidlustuse Rahandusministeeriumi juures asuvale vaidlustuskomisjonile RHSis sätestatud korras ja tähtajal (10 päeva). Hankija ei või lepingut sõlmida enne 14 päeva möödumist käesoleva teate edastamisest. RHS § 189 lõike 1 kohaselt esitatakse vaidlustus kümne päeva jooksul alates päevast, kui vaidlustaja sai teada või pidi teada saama oma õiguste rikkumisest või huvide kahjustamisest, kuid mitte pärast hankelepingu sõlmimist. Vaidlustaja taotleb RHS § 185 lg 2 p 7 alusel edukaks tunnistamise otsuse kehtetuks tunnistamist. Nimetatud otsus on Vaidlustajale riigihangete registri kaudu teatavaks tehtud 19.09.2024, seega on vaidlustus esitatud tähtaegselt. 2. PUNKTIDE JAOTUS JA ARGUMENDID Hankija on sätestanud RHAD lisa 1b nõuded pakkumuse esitatavale proovitööle ning mh. sätestanud punktis 2 pakkuja ülesande: 1. luua Figma disainiprogrammi keskkonda vähemalt 4 mockup vaadet kohaldatuna mobiilivaatele visitestonia.com rattamatkateede kaardile. Pakkumus peab sisaldama veebilinki Figma disainiprogrammi vaataja õigustega. 2. kasutada mock up’de loomisel visitestonia.com kaardirakenduse UI komponente, mis on kättesaadavad Brand Estonia stiiliraamatusse loodud proovitöö projektist Figma keskkonnas. 3. Pakkuja edastab Tellijale veebilingi Figma disainiprogrammi vaataja õigustega. Hankija on hanke proovitöö ülesandepüstituses väga selgelt sätestanud, et mock up’de loomisel tuleb kasutada visitestonia.com kaardirakenduse UI komponente, mis on kättesaadavad Brand Estonia stiiliraamatus. Hankija poolt avaldatud edukaks tunnistamise otsusest järeldub, et Vaidlustaja pakkumuse kvaliteedi hindamise eest on saanud vastavalt 30 + 20 = 50 punkti ehk teisisõnu maksimaalsed punktid „Mockup`de ärinõuded“ alakriteeriumis ning „Mockup`de visuaal ja kvaliteet“ alakriteeriumis. Sama otsusega on Hankija vähendanud Eduka pakkuja Lehekülg: 3 Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (280554) vaidlustus. Finest AS 1) punkte „Mockup`de ärinõuded“ alakriteeriumis, kuna Hankija hinnangul ei ole täidetud tingimus „Kõikide mockup`de puhul on järgitud Brand Estonia ja Visit Estonia stiilinõudeid“. Samas ei ole Hankija oma otsusega vähendanud Eduka pakkuja punkte kategooriates “Järgitud on visitestonia.com kaardirakenduse stiili ja kasutusloogikat.” ega “Järgitud on visitestonia.com veebi üldist stiili ja kasutusloogikat.” (täiendav argumentatsioon vaidlustuse punktis 2.1). 2) punkte „Mockup`de visuaal ja kvaliteet“ alamkriteeriumi kategoorias „Mockup’de visuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning omavahel loogiliselt järjestatud“, kuna Hankija hinnangul „esitatud Mockupid ei vasta täielikult ärinõuetele ei omistata pakkumusele mitte 10 vaid 8 punkti“. Samas on Hankija antud kategooria hindamistingimustes (RHAD punkt 5.7.3) sätestanud 8 punkti vääriliselt, kui proovitöö vastab täielikult ärinõuetele ja 5 punkti oleks pidanud pakkuja saama, kui proovitöö vastab olulises osas etteantud kriteeriumidele. (täiendav argumentatsioon vaidlustuse punktis 2.2). Vaidlustaja ei nõustu Edukale pakkujale omistatud punktidega ning on seisukohal, et Hankija on pakkumuse punktide omistamisel eksinud või kriteeriumi tõlgendusi laiendanud. Hankija on RHAD sätestanud punktis 5.3.2 „Kriteeriumile antakse maksimaalsed punktid, kui hinnatav tunnus on võrdne kriteeriumi sisukirjeldusega“. Vaidlustaja toob alljärgnevalt ära täiendavad selgitused ja argumentatsiooni. Eeltoodust tulenevalt alljärgnev vaidlustus keskendub Hankija poolt Edukale pakkujale omistatud hindamise tulemustele proovitöö alamkriteeriumis „Mockup`de ärinõuded“ ja „Mockup`de visuaal ja kvaliteet“. 2.1. Proovitöö hindamine alamkriteeriumis „Mockup`de ärinõuded“ RHAD punktis 5.7.2 on Hankija toonud välja proovitöö „Mockup`de ärinõuded“ alamkriteeriumis omistatavate punktide omistamise loogika. Hankija on mh sätestanud, et antud alamkriteeriumis omistatakse punkte järgmiselt: • 3 punkti. Kõikide mockup`de puhul on järgitud Brand Estonia ja Visit Estonia stiilinõudeid. • 3 punkti. Järgitud on visitestonia.com kaardirakenduse stiili ja kasutusloogikat. • 3 punkti. Järgitud on visitestonia.com veebi üldist stiili ja kasutusloogikat. Hanke edukaks tunnistamise otsusega lisatud hankekomisjoni protokollis on Hankija põhjendanud Edukale pakkuja punktide vähendamist tingimuse „Kõikide mockup`de puhul on järgitud Brand Estonia ja Visit Estonia stiilinõudeid“ mittetäitmise eest järgmiselt: „Kõik mockup’d ei järgi Brand Estonia ja Visit Estonia stiilinõudeid. Kaardil on rattamatkateede joontel kasutusel disainisüsteemi mittekuuluvad värvid (#3366E1, #35753F, #C03600). Kaardil olevad rattamatkateede algus- ja lõpp-punktina on kasutusel disainisüsteemi mitte kuuluvad ikoonid (vormipõhised, mitte joongraafika). Tagasiside andmise nn rating’u tähekeste ikoonid ei sobitu disainisüsteemi ikooni stiili ega värvi (#FF9500) poolest. Kaardivaadetes ei kasuta mockup ikoonide Lehekülg: 4 Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (280554) vaidlustus. Finest AS vaates ühtset hierariat ega läbivat selget loogikat. Rattateed markeeriv element ei kasuta disainisüsteemi värve ja kasutusel on drop shadow efekt, mis ei vasta stiilinõuetele.” Samas ei ole Hankija vähendanud Eduka pakkuja punkte tingimuste „Järgitud on visitestonia.com kaardirakenduse stiili ja kasutusloogikat“ ega „Järgitud on visitestonia.com veebi üldist stiili ja kasutusloogikat“ mittetäitmise eest. Ehk Hankija on hindamise tulemusena seisukohal, et Edukas pakkumus on neid tingimusi täitnud. EKI Sõnaveebi kohaselt on sõna „stiil3“ selgitatud kui „ajastule, autorile, koolkonnale, teosele vm omane väljendus- või kujutuslaad, sellele iseloomulikud ühtsed jooned“. Viidatud tingimuste puhul on Vaidlustaja aru saanud Hankija soovist proovitöö teostamisel ja hilisemal hindamisel, et proovitöös tuleb järgida kaardirakenduse ja visitestonia.com veebi väljendus- või kujutuslaadi ja sellele iseloomulikke ühtseid reegleid ja nõudeid. Stiili reeglid, mida pakkujad järgima peavad, on Hankija poolt proovitöös ja hindamiskriteeriumides viidetega välja toodud ja Hankija on ka ise on leidnud hindamiskomisjonis, et kaardivaadetes neid ei järgita. Vaidlustajale on selge, et kui Eduka pakkuja proovitöös kasutatakse värve, ikoone, efekte, mis ei vasta stiilinõuetele, siis ei ole järgitud stiiliraamatus kirjeldatud ühiseid iseloomulike jooni ega järgitud tingimustes toodud stiili. Vaidlustaja järelpäringule Hankija poolt 23.09.2024 antud vastuses on Hankija selgitanud, et hindamiskomisjon on nende tingimuste täitmisel hinnanud, kas proovitöös stiil ühtne ja järjepidev ning on järgitud visuaalset tunnetust või järjepidevat kogemust ega pole täielikult eiratud stiilinõudeid. Samas ei saanud seda täpsustust pakkujad hindamistingimustest kuidagi eeldada, kui tingimus sätestab sõnaselgelt, et punktide saamiseks peab järgima nii stiili kui kasutusloogikat ning Hankija on viidanud ka stiili reeglitele. Ning kui pakkujad kasutavad proovitöös stiilinõuetele mittevastavaid ikoone, värve ja efekte, siis ei saa kehtida reegel, et stiil on ühtne ja järjepidev. Vaidlustaja on seisukohal, et nii visitestonia.com kaardirakenduse kui ka veebi stiil väga otseselt tulenevad Brand Estonia ja Visit Estonia stiilinõuetest ning neid tuleb proovitöös kasutada ja järgida. Brand Estonia ja Visit Estonia annab ette mh ka stiilinõuded kaardirakendusele kui ka veebile, sh värvidele ja ikoonidele. Edukas pakkuja on oma esitatud proovitöös eiranud Hankija hindamiskomisjoni hinnangul nö. peamiseid stiilinõudeid, seega on Vaidlustaja seisukohal, et Hankija on eksinud samas proovitöös kaardirakenduse ja veebi stiili tingimuse täitmise hindamisel, kui on omistanud tingimuste täitmise eest Edukale pakkujale maksimumpunktid. Hankija on ka enda hindamise selgitusena Eduka pakkumuse proovitöös puudustena välja toonud, et mockup’des (sh kaardil) on kasutatud disainisüsteemi mittekuuluvaid värve, ikoone ja stiile. Hankija hindamiskomisjoni selgitustest tulenevalt on Vaidlustaja seisukohal, et seega ei ole Edukas pakkuja oma proovitöös järginud ka tingimusi „Järgitud on visitestonia.com kaardirakenduse stiili ja 3 https://sonaveeb.ee/search/unif/dlall/dsall/stiil/1 Lehekülg: 5 Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (280554) vaidlustus. Finest AS kasutusloogikat.“ ja/või „Järgitud on visitestonia.com veebi üldist stiili ja kasutusloogikat.“ ning ei oleks pidanud saama nende tingimuste mittetäitmise korral punkte, mis Hankija samas neile on omistanud. 2.2. Proovitöö hindamine alamkriteeriumis „Mockup`de visuaal ja kvaliteet“ RHAD punktis 5.7.3 on Hankija toonud välja proovitöö „Mockup`de visuaal ja kvaliteet“ alamkriteeriumis omistatavate punktide omistamise loogika. Hankija on mh sätestanud, et antud alamkriteeriumis omistatakse kategoorias „Mockup’de visuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning omavahel loogiliselt järjestatud“ punkte järgmiselt: • „10“ punkti – vastab täielikult ärinõuetele ja lahendus sisaldab uudseid ettepanekuid/visiooni rattamatkateede kaardil kuvamise edasiarendamiseks ning nende rakendamine võib anda tööle täiendavat väärtust. Lahendus on tuginenud headele praktikatele, näidetele, andmetele, statistikale, uuringutele või muule veebiarendusega seotud põhimõtetele; • „8“ punkti – vastab täielikult; • „5“ punkti – vastab olulises osas etteantud kriteeriumitele; • „3“ punkti – vastab keskpärasel määral; • „1“ punkt – vastab vähesel määral etteantud kriteeriumitele. Hanke edukaks tunnistamise otsusega lisatud hankekomisjoni protokollis on Hankija põhjendanud edukale pakkujale punktide vähendamist ja 8 punkti andmist järgmiselt: „Mockup’de visuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning mockup’d omavahel loogiliselt järjestatud ja vastab täielikult etteantud kriteeriumitele ning lahendus sisaldab uudseid ettepanekuid/visiooni rattamatkateede kaardil kuvamise edasiarendamiseks ning nende rakendamine võib anda tööle täiendavat väärtust. Samuti on lahendus tuginenud headele praktikatele ja kasutajauuringutele, kuid täidetud ei ole kõik ärinõuded. Kasutajal on lihtne, loogiline ja huvitav mockup’des navigeerida. Uudsetest lahendutest on toodud funktsionaalsus kasutajatel hinnata, anda tagasisidet ja kommenteerida rattamatkateed ning tee lähedalasuvaid huvipunkte ning rattamatkatee detailinfos on kasutajal võimalik vaadata detailselt lõigu kaupa teekonna pinna infot (pinnatüübid ja protsendid). Kuna esitatud Mockupid ei vasta täielikult ärinõuetele ei omistata pakkumusele mitte 10 vaid 8 punkti“. Samas on Hankija sätestanud hindamiskriteeriumides, et 8 punkti antakse pakkujale, kui proovitöö vastab täielikult ärinõuetele ning 5 punkti antakse pakkujale, kui proovitöö vastab olulises osas etteantud kriteeriumile. Vaidlustaja on seisukohal, et Hankija poolt sätestatud hindamiskriteeriumide kohaselt oleks pidanud Hankija omistama Edukale pakkujale 5 punkti, kuna Hankija on ise tõdenud, et täidetud ei ole kõik ärinõuded. Lehekülg: 6 Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (280554) vaidlustus. Finest AS 2.3. Hindamiskriteeriumide kohaldamine Hindamiskriteeriume tuleb kohaldada objektiivselt ja ühetaoliselt kõigi pakkujate suhtes. Mida üldisemad on hindamiskriteeriumid ja -metoodika, seda avaram on hankija hindamisruum ning seda põhjalikumad peavad läbipaistvuse tagamiseks olema hinnete põhjendused4. Hankija on sätestanud proovitööle ja selle hindamisele väga lakoonilised kirjeldused ning see võib olla ka üks põhjuseid, miks on antud olukorras tekkinud erinevaid tõlgendusi punktide omistamisel. Vaidlustaja on seisukohal, et Hankija ei ole neid sätestatud reegleid hindamiskomisjonis järginud või teinud hindamisel vea. Hankija hindamiskomisjon on leidnud, et kaardil on kasutatud disainisüsteemi mittekuuluvaid ikoone ja värve. Seega ei saa olla tõene, et Eduka pakkuja proovitöös on komisjon samas leidnud, et visitestonia.com kaardirakenduse stiili ja kasutusloogikat on järgitud. Kui Hankija on sõnaselgelt väljendanud ja vähendanud punkte ühe stiilinõuete tingimuse mittetäitmise seetõttu, siis ei saa samaaegselt kehtida olukord, kus teiste stiilinõuete tingimused on täidetud. Samuti on Hankija omistanud Edukale pakkujale proovitöö visuaali ja kvaliteedi alamkategoorias 8 punkti ja põhjendanud seda „kuna esitatud Mockupid ei vasta täielikult ärinõuetele“. Hankija sätestatud hindamiskriteeriumi kohaselt oleks seega pidanud omistama Edukale pakkujale 5 punkti. Rõhutame, et Hankija otsuse õiguspärasust on võimalik hinnata üksnes põhjenduste alusel, mis tehti teatavaks otsuse vastuvõtmisel5. Põhjenduste esitamine vaidlustus- või kohtumenetluses ei muuda akti tagantjärele tõhusalt kontrollitavaks, sest pole võimalik tõendada, kas kohtumenetluse jooksul esitatud põhjendused on samad, millest tegelikult lähtuti6. Hilisemas menetluses esitatud hankija kaalutlusi saab arvestada erandjuhul, kui hankija on veenvalt tõendanud, et lähtus tagantjärele esitatud kaalutlustest otsuse tegemisel7. Hankija ei saa hakata vaidlustusmenetluses oma otsust parandama ja põhjendusi juurde mõtlema. Vaidlustusmenetluses esitatud selgitused ei saa asendada haldusorgani poolt hankemenetluses tegemata jäänud ülesandeid, st vajalike asjaolude tuvastamist, hindamist ja kaalumist otsustuse tegemisel. Hankemenetluse läbiviimine muutuks sisutuks, kui hankijal oleks lubatud alles kohtumenetlusega paralleelselt läbi viia vajalik tuvastamine, hindamine ja kaalumine. See kahjustaks ebamõistlikult ka teisi pakkujaid, sest lihtsustatult väljendudes oleks neil korrektse haldusmenetluse läbiviimise saavutamiseks vajalik algatada ka kohtumenetlus, riskides sealjuures võimalusega, et nende kanda jäävad menetluskulud, kui hankijal õnnestub tagantjärele seoses oma otsustusega ära näidata piisavad selgitused ja põhjendused8. 4 RKHKo 3-20-1198, p 21 5 VAKO 53-20/218279, p 26. 6 RKHKo 3-3-1-74-11, p 15; RKHKo 3-3-1-13-11, p 9; RKHKo 3-3-1-49-08, p 11; RKHKo 3-3-1-81-07, p 20; RKHKo 3-3-1-62-07, p 16; RKHKo 3-3-1-57-07, p 18; RKHKo 3-3-1-16-05, p 17; RKÜKo 3-3-1-85-10, p 44. 7 RKHKo 3-17-1927, p 23; RKHKo 3-3-1-46-14, p 15; RKHKo 3-3-1-29-12, p 20; RKHKo 3-3-1-33-12, p 16. 8 TrtRnKo 3-22-607, p 10. Lehekülg: 7 Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (280554) vaidlustus. Finest AS Eeltoodust tulenevalt on Vaidlustaja seisukohal, et hindamisprotokollis sisalduva põhjenduse alusel on Eduka pakkuja punkte vähendatud ebakorrektselt. Vaidlustaja leiab, et RHAD toodud tingimuste ning Hankija hindamiskomisjoni protokolli selgituste alusel oleks tulnud Edukale pakkujale alamkategoorias „Mockup`de ärinõuded“ omistada maksimaalselt 24 punkti (mitte omistatud 27 punkti) ja alamkategoorias „Mockup`de visuaal ja kvaliteet“ maksimaalselt 15 punkti (mitte omistatud 18 punkti). Seeläbi oleks korrektse hindamise tulemusena Eduka pakkuja pakkumus saama kvaliteedikriteeriumi eest maksimaalselt 24 + 15 = 39 punkti. Hankija on omistanud Vaidlustajale hinnakriteeriumi (Tarkvara arenduse ja hoolduse ühe töötunni maksumus käibemaksuta) eest 32.34 punkti ning kvaliteedikriteeriumi eest maksimaalsed 50 punkti (kokku 82.34 punkti). Edukale pakkujale on Hankija hinnakriteeriumi eest omistanud 38.96 punkti ning juhul, kui Hankija viib läbi pakkumuste korrektse kvaliteedikriteeriumide kohase hindamise, oleks Vaidlustajal võimalus olla edukas pakkuja pärast Hankija poolt kõrvaldamise aluste kontrolli läbiviimist. 3. VAIDLUSTAJA KOKKUVÕTLIKUD SEISUKOHAD 3.1. Vaidlustaja on seisukohal, et avatud hankemenetluse „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (riigihangete registri viitenumber 280554) hindamine ei ole läbi viidud korrektselt, hanke alusdokumentides sätestatud kohaselt ning pakkumustes sisaldunud informatsiooni objektiivselt tõlgendades ning hinnates. Hankija on eksinud Hanke alusdokumentides esitatud hindamiskriteeriumide rakendamisel. 3.2. Vaidlustaja on seisukohal, et Hankija otsusega Edukale pakkujale proovitöö eest omistatud hindamispunktid ei ole kooskõlas hindamiskriteeriumidega ning Hankija on eksinud punktide andmisega. Vaidlustaja leiab, et korrektselt läbi viidud hindamise tulemusena oleks pidanud Eduka pakkuja pakkumus koguma hindamisel maksimaalselt 38.96 + 39 = 77.96 hindepunkti, mitte Hankija poolt omistatud 83.96 punkti. 3.3. Vaidlustaja on jätkuvalt seisukohal, et tema esitatud sisuline pakkumus vastab kõikidele Hankija poolsele ülesandepüstitusele ja hindamismetoodikas (Lisa 1) toodud maksimaalseid punkte andvatele kriteeriumidele ning seega on Vaidlustaja hindamisel antud punktide 32.34 + 50 = 82.34 alusel Edukas pakkuja. 4. TAOTLUSED 4.1. Vaidlustaja taotleb RHS § 193 lg 1 kohaselt käesoleva riigihankemenetluse peatamist kuni antud vaidlustusmenetluse lõpuni sh keelata hankelepingu sõlmimine. Lehekülg: 8 Ettevõtluse ja Innovatsiooni Sihtasutuse riigihanke „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“ (280554) vaidlustus. Finest AS 4.2. Rahuldada vaidlustus ning tunnistada kehtetuks Hankija 19.09.2024 riigihangete registri kaudu teatavaks tehtud otsus, millega tunnistati edukaks ühispakkuja Krabu Grupp OÜ ja Catapult Labs OÜ pakkumus. 4.3. Kohustada Hankijat viima läbi pakkumuste uus hindamine ning koostada hankes uued otsused, lähtudes RHS §-st 117, mille kohaselt tuleb hindamine läbi viia riigihanke alusdokumentides pakkumuste hindamise kriteeriumitele vastavalt. 4.4. Mõista Hankijalt välja tasutud riigilõiv summas 1280 (üks tuhat kakssada kaheksakümmend) eurot. 4.5. Juhul, kui Hankija kasutab menetluses lepingulise esindaja abi, jätta tema õigusabikulud tema enda kanda. 4.6. Kuna Vaidlustaja pakkumuse dokumendid ja nendes sisalduv info, välja arvatud pakkumuse maksumus ja osamaksumus, on Vaidlustaja ärisaladus palume neid kolmandatele isikutele mitte avaldada. 4.7. Vaidlustaja nõustub kirjaliku menetlusega. Lugupidamisega, (allkirjastatud digitaalselt) Jan Urva Finest AS Tegevjuht, juhatuse liige Lisad Vaidlustusel on järgmised lisad: 1. RHAD, sh hindamismetoodika 2. Hankekomisjoni protokoll Finestmedia 3. Vaidlustaja pakkumuste hindamise teabepäring Hankijale 4. Riigilõivu tasumist tõendav maksekorraldus Lehekülg: 9  1. Üldandmed Hankijaks on Ettevõtluse ja Innovatsiooni Sihtasutus (edaspidi E I S või hankija), registrikood 900060 12 . Riigihanke nimetus on „ Visit Estonia t urismiinfosüsteemi arendus- , hooldus- ja majutus teenus “, mille riigihangete registri (edaspidi RHR) viitenumber on 280554 ja hankija sisene hankenumber on HNR 240093 Menetlusliik: avatud hankemenetlus (riigihangete seadus (RHS) 1. jagu 2. jaotis))/ e-menetlus. Raamleping sõlmitakse ühe pakkujaga. RHAD – riigihanke alusdokumendid, mis koosnevad käesolevas failis olevast põhitekstist koos selle lisadega e-riigihangete keskkonnas asuvatest hanketeatest (HT), veebivormidest ning alla laetavatest failidest või muudest dokumentidest, mida on loetletud RHS § 4 lg-s 1 p-is 17 . Riigihange ei ole ühe menetluse raames osadeks jaotatud, sest raamlepingu esemeks on funktsionaalselt koos toimivad ja sama eesmärgi saavutamiseks vajalikud teenused . Pakkumuse esitamine ei eelda raamlepingu täitmise kohaga tutvumist või RHADi selgitavate dokumentide kohapeal kontrollimist. Hankija võib kontrollida pakkumuste vastavust RHADis esitatud tingimustele ning hinnata vastavaks tunnistatud pakkumusi RHSis sätestatud korras enne pakkujate suhtes kõrvaldamise aluste puudumise ja kvalifikatsiooni kontrollimist. Sellisel juhul tagab hankija, et raamlepingut ei sõlmita sellise pakkujaga, kes oleks tulnud RHS § 95 lg 1 alusel hankemenetlusest kõrvaldada või kes ei vasta hankija kehtestatud kvalifitseerimise tingimustele vastavalt RHS § 52 lg-le 3 . RHS § 85 lg 6 kohane põhjendus olelusringi kulude arvestamata jätmise kohta: lepingu esemeks ei ole uue infosüsteemi arendus, vaid tegemist on hankijal juba olemas ja kasutuses oleva infosüsteemiga ning sellele vajaminevate (täiendavate) arendus- ja hooldustöödega. Vajalikud arendus-ja hoolduskulud on hankija arvestanud raam lepingu eseme hinna sisse. Iga viidet, mida hankija on teinud kindlale ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule, tootmisviisile ja RHS § 88 lg-s 2 nimetatud alustele, palume lugeda täiendatuks märkega „või sellega samaväärne“. Samaväärsus tähendab samu kasutusomadusi ja funktsionaalsusi. Samaväärsuse korral tuleb pakkujal pakkumuses esitada seda tõendavad dokumendid . Eestikeelse ja võõrkeelse dokumendi/teabe vastuolu korral lähtutakse eestikeelsest dokumendist/teabest. Riigihanke alusdokumentides kasutatavad mõisted (juhul, kui mõiste on avamata, tuleb lähtuda Eesti Keele Instituudi Sõnaveebist ( https://sonaveeb.ee/ ). Alternatiivsete lahenduste esitamine ei ole lubatud. Kogu riigihankega seotud teabevahetus hankija ja ettevõtja vahel toimub elektrooniliselt , RHRi vahendusel RHSis sätestatud alustel. Pakkuja, kelle suhtes esineb vähemalt üks RHSi § 95 lg 1 punktides 1–3 ja 5 ning lg 4 punktides 2–11 nimetatud alustest, esitab koos pakkumusega tõendid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Kui huvitatud isik ei ole esitanud hankemenetluse käigus küsimusi riigihanke alusdokumentides avastatud vastuolude, ebaselguste või puuduste kohta, on hankijal õigus lepingu sõlmimise ja täitmise käigus üleskerkinud vaidluste korral valida hankijale sobivam riigihanke alusdokumentide tõlgendus. Pakkumuse vormistamine Kõik RHADis nõutud dokumendid tuleb esitada elektrooniliselt RHRi kaudu aadressil https://riigihanked.riik.ee . Pakkumus vormistatakse eesti keeles. Muus keeles (v.a inglise keeles) esitatud dokumentidele peab olema lisatud eestikeelne tõlge. Pakkuja ei krüpteeri pakkumuse dokumente, kuna RHRis on tagatud pakkumuste konfidentsiaalsus ning hankija saab pakkumused avada ning tutvuda nende sisuga alles pärast esitamise tähtaja möödumist. Pakkuja võtab enda kanda pakkumuse õigeaegse esitamise kogu riski. Kõik pakkumuse ettevalmistamise ja esitamisega seotud kulud katab pakkuja. Ühispakkujad peavad nimetama riigihankega ning raamlepingu sõlmimise ja täitmisega seotud toimingute tegemiseks endi seast volitatud esindaja. Ühispakkujate volitatud esindajale antud volitus peab kehtima kuni raamlepingu täitmiseni. Pakkumus on konfidentsiaalne kuni nimetatud pakkumuse edukaks tunnistamise otsuse tegemiseni. 3 . Pakkumuse maksumus 3.1. Pakkuja esitab pakkumuse maksumuse d RHRis „hindamiskriteeriumid ja hinnatavad näitajad“ lehel . 3.2. Maksumus tuleb esitada eurodes täpsusega kaks kohta pärast koma. Juhul, kui pakkuja on käibemaksukohuslane, tuleb käibemaks kajastada eraldi. 3.3. Pakkumuse maksumuses kajastatud summad on hankijale lõplikud, sh sisaldavad tasusid või muid makse, v.a käibemaksu, mis kajastatakse eraldi ning selles toodud summadele ei lisandu täiendavaid väljamakseid ega kulutusi. 4. Pakkumuste vastavus ja tagasilükkamine Hankija lükkab pakkumuse tagasi : 4.1 .1. kui see ei vasta RHADis esitatud tingimustele; 4.1.2. kui pakkuja jätab esitamata pakkumuses nõutud andmed ja/või dokumendid; 4.1.3. kui pakkuja ei esita tähtajaks hankija nõutud selgitusi; 4.1.4. kui pakkuja selgituste põhjal ei ole võimalik üheselt hinnata pakkumuse vastavust RHADis esitatud tingimustele. Hankijal on õigus lükata tagasi kõik pakkumused igal ajal enne raamlepingu sõlmimist RHSis sätestatud juhtudel. Hankija jätab endale õiguse tunnistada hankemenetlus kehtetuks, kui: hankija juhtimisorgan teeb otsuse, millest tulenevalt riigihanke korraldamine osutub võimatuks; toimub muudatus hankija tegevuseesmärkides või prioriteetides ; hanke toimumise ajal on hankijale saanud teatavaks asjaolud, mis välistavad või muudavad ebaotstarbekaks hankemenetluse lõpuleviimise RHADis sätestatud korras ; kui esitatakse või tunnistatakse vastavaks ainult üks pakkumus; kui hindamiskriteeriumite alusel enim punkte saanud pakkumusele on antud vähem kui 6 0 punkti. 5. Pakkumuste hindamine Hankija sõlmib raamlepingu majanduslikult soodsaima pakkumuse alusel, võttes arvesse parimat võimalikku hinna ja kvaliteedi suhet. Pakkumuste hindamisel arvestatakse ainult RHADis kehtestatud pakkumuste hindamise kriteeriume ja nõudeid. Pakkumusele kõigi kriteeriumite eest antud punktid liidetakse ja edukaks tunnistatakse liitmise tulemusel enim punkte saanud pakkumus. Maksimaalne väärtuspunktide arv: 100 punkti. Pakkumusi hinnatakse järgmiselt: m aksumusega seotud hindamiskriteeriumite puhul: punktide andmine toimub hindamismeetodil „vähim on parim“ ning pakkumusi hinnatakse RHRis automaatselt. Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" x "osakaal" ; t eenuse sisu ja kvaliteedi ga seotud hindamiskriteerimite puhul: : hankija poolt moodustatud komisjon hindab proovitö ö d kollegiaalselt ning iga alakriteeriumi puhul leitakse komisjoni liikmete ühine , konsensuslik hinne. Kriteeriumile antakse maksimaalsed punktid, kui hinnatav tunnus on võrdne kriteeriumi sisukirjeldusega. Pakkumusi hinnatakse pakkumuses esitatud dokumentide alusel. Kui pakkumuses on esitamata hindamise kriteeriumi nõuetele vastavust tõendav nõuetekohane dokument, andmed ja/või kinnitus, ei omistata pakkumus ele nimetatud hindamise kriteeriumi eest punkte. Võrdsete pakkumuste korral tunnistatakse edukaks pakkumus, mis sai hindamiskriteeriumi „Tarkvara arenduse ja hooldusteenuse ühe töötunni maksumus käibemaksuta“ osas rohkem punkte. Juhul, kui ka pärast seda on punktide arv võrdne, toimub liisuheitmine. Liisuheitmise kord edastatakse osapooltele olukorra tekkimisel. Pakkumuste hindamiskriteeriumid ja osakaalud on järgmised: Nr Hindamiskriteerium Osakaal Pakkumuses esitatav dokument, mille alusel hankija kontrollib nõuetele vastavust. 5. 7 .1 . Tarkvara arenduse ja hooldusteenuse ühe töötunni maksumus käibemaksuta 50 RHR-s hindamiskriteeriumid ja hinnatavad näitajad“ lehel esitatud andmed. 5. 7 . 2 . Mockup`de ärinõuded 30 Proovitöös esitatud vähemalt 4 mo ckup -i kohaldatuna mobiilivaatele. Punkte omistatakse ärinõuete põhiselt: 3 punkti. Kõik m ockup`d on kohaldatud mobiilivaatele : 3 punkti. Kõik m ockup`d on loodud inglisekeelsele kasutajale. 3 punkti. Kõik ide m ockup`d e puhul on järgitud Brand Estonia ja Visit Estonia stiilinõudeid . 3 punkti . Järgitud on visitestonia.com kaardirakenduse stiili ja kasutusloogikat . 3 punkti. Järgitud on visitestonia.com veebi üldist stiili ja kasutusloogika t. 3 punkti. Rattamatkateede infos on kuvatud kasutaja le huvipakkuv info (nimekiri ei ole lõplik), näiteks rattatee pikkus, raskusaste, info tee läbitavuse kohta (nt kruusatee, asfaltkate, reljeefne tee vms), info rattatee viidastamise / mitteviidastamise kohta. 2 3 punkti. Kasutaja saab vaadata kaardil üldvaates kõiki rattamatkateid . 2 3 punkti. Rattamatkateid saab valida kaardil eraldi kategooriana teiste objektide kategooriate hulgas kaardil asuvas menüüs. 2 punkti. Kasutaja saab vaadata infot valitud rattamatkatee kohta. 1 2 punkt. Kasutaja saab vaadata infot rattamatkatee lähiümbruses asuvate huviväärsuste kohta . 1 punkt. Kasutaja saab rattamatkateed alla laadida GPX formaadis . 1 punkt. Rattamatkateel on kaardil tähistatud algus- ja lõpp-punkt. 1 punkt. Rattamatkateel on unikaalne rattatee number. 1 punkt. Rattamatkateed on üksteisest eristatavad. 1 punkt. Järgitud on WCAG 2.2 AA taseme nõuetega nii palju kui mockup loomine seda võimaldab. Kui ärinõue on täitmata, siis täitmata nõude eest punkte ei omistata . 5. 7 . 3 . Mockup`de visuaal ja kvaliteet 20 Proovitöös esitatud mockup’d kohaldatuna mobiilivaatele. Proovitöö s esitatud mockup’dele loodud lahendust hinnatakse järgnevate alakriteeriumite alusel: 5. 7 . 3 . 1. Mockup’de v isuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning omavahel loogiliselt järjestatud . „1 0 “ punkti – vastab täielikult ärinõuetele ja lahendus sisaldab uudseid ettepanekuid / visiooni rattamatkateede kaardil kuvamise edasiarendamiseks ning nende rakendamine võib anda tööle täiendavat väärtust . Lahendus on tuginenud heade le praktikatele, näidetele, andmetele, statistikale, uuringutele või muule veebiarendusega seotud põhimõtetele ; „ 8 “ punkti – vastab täielikult; „5“ punkti – vastab olulises osas etteantud kriteeriumitele; „3“ punkti – vastab keskpärasel määral; „ 1 “ punkt – vastab vähesel määral etteantud kriteeriumitele. 5.7.3.2. Kasutajamugavus. Mockupide põhjal on kasutamine lõppkasutajale väga mugav, kasutaja teekond on läbi mõeldud ning kutsub uuesti kasutama. „10“ punkti – vastab täielikult ; „ 7 “ punkti – vastab olulises osas etteantud kriteeriumitele; „ 4 “ punkti – vastab keskpärasel määral etteantud kriteeriumile; „1“ punkt – vastab vähesel määral etteantud kriteeriumitele. Pakkumusele omistatav punktisumma saadakse alakriteeriumite liitmisel. 6. Lisad: RHAD LISA 1 – raamlepingu eseme tehniline kirjeldus; RHAD LISA 2 – raamleping; RHAD LISA 3 – pakkumuse esitamise vormid. RHAD LISA 1. RAAMLEPINGU ESEME KIRJELDUS Hanke ese ja eesmärk Riigihanke esemeks on Visit Estonia turismiinfosüsteemi (edaspidi ka TIS) arendus - , majutus - ja hooldustööd . Raamleping hõlmab TIS analüüsi-, majutus-, haldus-, kasutajatoe-, hooldus-, testimis-, ja andmesisestusteenuste, veebilehtede ja IT-süsteemide arendustööde ning rikete või vigade kõrvaldamise tööde ning kasutajaliidese disaini ja UX/UI tööde tellimist. Riigihanke tulemusena sõlmitakse raamleping ühe pakkujaga. Raamleping kehtib alates allkirjastamisest kuni 48 kuu möödumiseni või kuni raamlepingu punktis 1. 5 sätestatud raamlepingu maksimaalse rahalise mahu saavutamiseni – sõltuvalt sellest kumb tingimus saabub varem. Raamlepingu eeldatavaks ja maksimaalseks mahuks on 3 000 000,00 eurot käibemaksuta. Hankija ei ole kohustatud teenuseid tellima raamlepingu maksimaalses eeldatavas mahus. Taustainfo Sissejuhatus Visit Estonia t urismiinfosüsteem (edaspidi ka TIS) on riigi turundusele ja turismiteenuste müügile suunatud infosüsteem, mille tegevuse eesmärgiks on Eesti kui reisisihi atraktiivsuse tõstmine ja tuntuse suurendamine läbi kvaliteetse ja ajakohase turismiinfo kogumise ja jagamise. Turismiinfosüsteemi avalikuks väljundiks on riiklik turismiinfo veebileht: www.visitestonia.com ( välisturistile ) ja www.puhkaeestis.ee ( siseturistile ). TIS on keskne kanal turistile ehk lõpptarbijale, turismi ettevõtjale ehk teenusepakkujale, meediale, turismiprofessionaalile ja turismi sihtkohtadele Eestis. Turismiinfosüsteemi haldab Ettevõtluse ja Innovatsiooni Sihtasutuse turismi osakond ( edaspidi turismiosakond ), kelle ülesandeks on seadusest ja õigusaktidest tulenevate kohustuste ja Turismistrateegias 2022-2025 sätestatud turismiinfosüsteemiga seotud eesmärkide täimine, mh tagada Eesti kui reisisihtkoha konkurentsivõime ja rahvusvaheline atraktiivsus ning aidata kaasa Eesti turismiteenuste ekspordile. Üheks strateegiliseks eesmärgiks on ühenduvuste tagamine ja sujuva külastaja teekonna kujundamine Eestis, sh online kättesaadavus, mis tähendab, et turismiinfo on külastajatele kiiresti kättesaadav kogu külastajateekonna ulatuses. Turismistrateegia seab turismivaldkonnale konkreetsema eesmärgi - “Turismiteenuste eksport on 2025. aastal 2,3 mld eurot.” Turismiinfosüsteem on custom made lahendusega ehitatud platvorm, mis praegusel uuendatud kujul on live toodangus alates mai 2024. Platvorm on loodud aastal 2009 ja läbinud aastate jooksul mitmeid uuendusi. Platvorm koosneb avalikust, turistidele suunatud kasutajaseadmele täielikult kohalduvast veebiväljundist ning turismiasjalistele suunatud autentimist eeldavast spetsialistikeskkonnast. Turisminfosüsteemi tehniline kirjeldus on toodud ptk REF _Ref158968394 \r \h 4 . Turismiinfosüsteemi kaks peamist funktsiooni on esiteks koguda ja korrastada infot turismiteenuste ja huviväärtuste kohta. Teiseks teha turismiinfo kättesaadavaks sellest huvitatud isikutele . Strateegilises plaanis peab TIS panustama eesmärgi saavutamisse läbi selle, et turismiinfosüsteem kogub infot turismiteenuste ja huviväärtuste kohta ja teeb selle atraktiivsel viisil kättesaadavaks sise - ja välisturistile . TIS koosneb: Sisekeskkond ehk admin - keskkond turismiosakonnale ; Sisemine iseteeninduskeskkond Eesti turismiettevõtjale ; Visitestonia.com – veebileht välisturistile ; Puhkaeestis.ee – veebileht siseturistile ; Eestikeelne profiveeb - veebileht Eesti turismisektorile ; Võõrkeelne veebileht ehk meediakeskus ja B2B profiveeb . TIS laiemad ülesanded on : Eesti kui reisisihi kohta teadlikkuse kasvu tagamine ning turismiteenuste ekspordi kasvule kaasa aitamine. Mõjutada võimalikult paljusid inimesi tegema oma reisiotsust Eesti kasuks, mõjutada neid tarbima võimalikult suures (rahalises) mahus teenuseid. Efektiivne turismiinfo kogumise, jagamise ning arendustegevuseks kasutatav infosüsteem kogu turismisektorile Eestis . Korrastatud, kliendikeskne, erapooletu ja kvaliteetne turismiinfo, mis on kättesaadav kõikidele huvigruppidele ja kasusaajaile. Turismiteenuste ja -toodete diginähtavus ja turundus, st t urismiettevõtjal esitleda oma tooteid ja teenuseid visitestonia.com keskkonnas välisturgudele parimas võimalikus kvaliteedis, kasutades kõiki kaasaegseid suhtlemisvorme ja väljundeid; Toetada ettevõtjaid turismiteenuste ekspordi arendamisel ning rahvusvahelise konkurentsivõime tõstmisel kasutades kaasaegseid tehnoloogilisi lahendusi (sh koostöövõrgustikud, (video)juhendid, arendustegevused , asjakohaste turismiandmete jagamine jne). Turismisektori info ja know-how vahendamine , st t agada info kättesaadavus turismiprofessionaalile ja sihtkohtadele riiklikult planeeritavatest tegevustest ning koondada infot tegevustest, üritustest, sündmustest jne. Tagada turismiprofessionaalile ja sihtkohtadele kaasaegsed töövahendid , võttes aluseks riikliku „ühe akna“ printsiibi ja soovitust lahenduste dubleerimist vältida (arenduse ja halduskulude kokkuhoid). Once and only põhimõte, ettevõtjate halduskoormuse vähendamine (API). Jagada visitestonia.com andmebaasist kvaliteetseid andmeid läbi otseliidestuste võimalikult paljude asjakohaste Eesti turismi edendavate veebikeskkondadega, avaldada visitestonia.com lehel kvaliteetsete andmebaaside sisendit. Koguda kasutajate andmeid (kooskõlas andmekaitse määrusega) uuringuteks, turu- ja kliendianalüüsiks, turundustegevuseks, tootearenduseks. Turismiinfosüsteemi v isioon, missioon ja põhiväärtus aastaks 2030 VISIOON: TIS teeb Eesti maailma turismikaardil suureks! TIS võimaldab maksimaalselt rakendada Eesti turismipotentsiaali, kasvatab Eesti turismitulu ja tuntust ning Eesti fännide võrgustikku üle maailma . MISSIOON: TIS on, e-riigi vääriliselt, kasutajale kiiresti kättesaadav ja toimib iga s seadmes. PÕHIVÄÄRTUS: TIS järgib parimaid trende ja rakendab kaasaegseid tehnoloogiaid, arvestades kasutaja individuaalsust. Turismiinfosüsteemi arendamise põhimõtted Turismiinfosüsteemi arendamisel lähtutakse järgmistest põhimõtetest: Kasutajakesksus . Disaini- ja arendusotsused tehakse eelkõige kasutajate vajadustest ja ootustest lähtuvalt. Huvipõhisus ja elamustele orienteeritus. Turismiosakonna välja töötatud huvipõhine ja elamustele orienteeritud lähenemine Eesti turundamisel peegeldub ka Visit Estonia veebis. See tähendab, et fookusteemad - loodus, kultuur, toit ja kestlikkus - saavad eraldi tähelepanu ning on ka navigatsioonis esile tõstetud, et huvipõhine info leidmine oleks mugav ja kiire. Minimalism . Nii info esitamisel kui disainis keskendutakse ainult kasutaja jaoks olulisimale, vältides informatsiooni ja valikute üleküllust ning visuaalset müra. Teenäitaja roll. Visit Estonia ambitsioon on võtta teednäitav roll valdkonnas, harides lehe kasutajaid ja luues uusi harjumusi (näiteks kestlikkuse teemadel). Mobile- first . Nii avalik keskkond kui ka spetsialistikeskkond on mobiilis mugavalt kasutatavad. Inspiratsiooniallikas . Visit Estonia veeb on nii kohaliku kui rahvusvahelise reisihuvilise jaoks eelkõige inspireeriv ja huvi tekitav keskkond. Eesti identiteedi ja unikaalsuse peegeldamine. Disain ja visuaalid (sh värvilahendus, fotod, videod jne) peegeldavad Eesti identiteeti ja unikaalsust ning loovad emotsiooni. Kestlikkus . Kestlikkuse põhimõtted on veebis integreeritud läbivalt. See tähendab muuhulgas, et jätkusuutlikud elamused on kergelt eristatavad (nt kvaliteedimärgiste abil) ning lihtsalt leitavad (nt asjakohaste filtrite rakendamise abil). Samuti tuleb veebilehe arendus-, disaini- ja andmekogumisotsuste tegemisel võtta arvesse süsinikujälje suurust, mida üks või teine lahendus kaasa toob ning võimalusel kasutada säästlikumat alternatiivi. Uute disainisuundade järgimine . Lehe disainis järgitakse uuemaid suundi nagu näiteks 3D, interaktiivne ja animeeritud kasutajaliides (tekstid, pildid, ikoonid, animatsioonid jne). AI ehk tehisintellekti kasutamine . Näiteks kasutada masintõlget tõlkeprotsesside efektiivistamiseks . Samuti saab AId kasutada personaliseeritud sisuloomeks ning otsimootorites . Aastaaegade esiletoomine . Eesti üks unikaalseid omadusi - viis aastaaega tõuseb veebis rohkem esile. Näiteks saab infot ja elamusi aastaaegade järgi sorteerida ja otsida. Ligipääsetavus . Turismiinfosüsteem on ligipääsetav (vastab WCAG 2.2 AA tasemele). Nii veebilehe disainis kui arendamisel peab arvestama, et seda saaks kasutada kõik inimesed, olenemata nende vanusest, haridusest ja erivajadustest. Näiteks rakendada häälkäskluste andmise ja teksti kuulamise võimekust ( texttospeech ). Liidestuste ja APIde kasutamine . Eesmärk on mitte dubleerida infot oma lehel, vaid teha koostööd teiste keskkondadega ja kasutada ära olemasolevat infot. Leivapuru kasutamine . Kasutusel on leivapuru, mis näitab kasutajale linkidena teekonda, mida mööda ta on liikunud. Niivõrd infomahukal lehel on see oluline, sest see tagab arusaadavuse, kus asutakse ja kuidas tagasi liikuda. Õhuke päisemenüü ja vähe menüüpunkte . Info kiireks leidmiseks ja kasutajate kognitiivse koormuse vähendamiseks on päisemenüü õhuke (kuni kaks taset) ning sisaldab pigem vähem menüüpunkte (megamenüüd väldime). Vaheavalehed navigatsiooni osana . Päisemenüüst saab enamasti liikuda vaheavalehtedele, mis koondavad konkreetse teemaploki infot ja kust saab omakorda edasi huvipakkuvale lingile liikuda. Ristviitamine teemaviidete abil . Kasutusel on ristviitamine, kus objektide ja artiklite juurde lisatakse teemaviited (tagid), mida järgides saab kasutaja lihtsalt ja kiirelt sarnase teemaga sisu leida. Lihtne ja intuitiivne filtreerimine . Filtreerimine on lihtne – tood e te kategooriad on vähem ja seega on nende vahel valida lihtsam. Teenuse ja kanali omavaheline sobivus . Eesmärk on, et Visit Estonia teistes keeltes olevatel lehtedel oleks kuvatud ainult rahvusvahelistele turgudele sobivad reisielamused. Nt on üheks välisturule kvalifitseerumise tingimuseks, et teenust suudetakse pakkuda inglise keeles. Visitestonia.com veebi külastatavus ja veebi statistilised näitajad aastal 2023 : 14 miljonit sessiooni aastas ( ehk ca 39 000 sessiooni ööpäevas, ca 27 sessiooni minutis ); 8,3 miljonit unikaalset külastajat aastas (ehk ca 22 600 unikaalset külastajat ööpäevas, 16 külastajat minutis); 1,6 miljonit naasvat külastajat (ca 4500 naasvat külastajat ööpäevas ; 3,1 külastajat minutis ); 91% user engagement rate ; 6,5% keskmine objekti click rate ( last click tegevused/sessioonid); Kliendirahulolu 4,3 ( Delighted NPS skaala 1-5). Peamiselt külastatakse veebilehte mobiiliseadmes ( 83 %) ; Ca 10 000 turismitoodet ja sündmust Ca 1000 sisuartiklit Ca 5000 turismiteenuse pakkujat 5 keelt (eesti, inglise, soome, läti, saksa keel). Iseteeninduskeskkonda kasutasid 6614 unikaalset kasutajat. Iga kasutaja külastas sama lehte umbes 86 korda. Turismiprofessionaali alamlehti külastati 91 000 korral Turismiinfosüsteemi sihtrühmad ja kasutajagrupid TISi osapoolte kategoriseerimisel eristatakse järgnevaid sihtrühmi: TISi sisu tarbijad , kes näevad ja tarbivad ainult TISi väliskeskkonda , mis meelitab neid Eestisse reisima. Nad on ise potentsiaalsed turismiteenuse või -toote tarbijad . Turismisektori pakkujad – TISi turismitoodete/teenuste sisu loojad , kelleks on Eesti turismisektoris teenuseid ja tooteid pakkuvad organisatsioonid või TISi sisu oma teenuste/toodete tarbeks kasutajad nii Eestis kui mujal, kes vaatavad seda oma kliendi silmade läb i ning kes teenivad selle abil otse või kaudselt kasu (nt sh ka edasimüüjad-reisibürood jmt) . TISi haldajad – kes on TISi sisu kvaliteedi tagajad ja ei ole tarbijad ega pakkujad. Va stutavad TISi turismitoodete/teenuste sisu, kvaliteedi ning süsteemi toimimise ja arendamise eest . Sihtrühmad jagunevad kasutajagruppideks ehk need on isikud , kellel on sarnane TISi kasutajaprofiil, -eesmärk ja TISis teostatavad tegevused (vt REF _Ref166055977 \h Joonis 1 ). Joonis SEQ Joonis \* ARABIC 1 . TIS iga seotud osapoolte jaotus ja seos TISi sisu ning haldamisega TISi osapoolte kategoriseerimisel eristatakse järgnevaid kasutajagruppe : Lõppkasutaja . Lõppkasutaja on sise - ja välisturist (sh diginomaad, äriturist) ja ka MICE osaleja ning reisikorraldaja klien t : Info tarbimine - l õppkasutaja külastab veebikeskkonda ja tarbib loodud sisu. Turismiteenuse omanik . Turismiteenuse omanik ehk turismiettevõtja ja sündmuse korraldaja on osapool, kes pakub turismiteenust (sh võib teenuse pakkujaks olla sihtkoht) . Turismiteenuse pakkuja peamised äriprotsessid on järgmised: Kasutajate haldus - Turismiteenuse pakkuja saab hallata endaga seotud kasutajaid . Toote vaatamine, lisamine, haldamine, muutmine ja kustutamine. Kasutaja saab lisada, muuta, hallata, muuta ja kustutada endaga seotud kõikvõimalikke tooteid ja objekte. Kasutajaks registreerimine - Kasutaja saab esitada avalduse saamaks õigusi pakkuja rolli täitmiseks . Turismiandmete tarbimine. Kasutaja saab vaadata asjakohast turismiinfot ja alla laadida asjakohaseid turismiandmeid. API võtme haldus. Kasutaja saab taotleda ligipääsuvõtmeid turismi objektide info jagamise API-le, neid võtmeid sulgeda ning taotleda uusi ( API ligipääs on juriidilistel põhjustel lubatud ainult pakkujate infosüsteemidele). Turismiteenuse edasimüüja. Turismiteenuse edasimüüja on võtmepartnerid , eralaliidud , reisikorraldajad jt edasimüüjad (Euroopa turg, Kaugturg, DMC ), sh võib edasimüüja olla sihtkoht , kes loob sisu (vt ka turismiteenuse omanik e pakkuja) : Info tarbimine - külastab veebikeskkonda ja tarbib sinna loodud sisu. Turismiandmete tarbimine. Kasutaja saab vaadata asjakohast turismiinfot ja alla laadida asjakohaseid turismiandmeid. K oostada kiiresti ja mugavalt kliendi vajadustele vastavaid toote pakette ning arendada välja oma tooteportfell. Äriklientide varustamine kvaliteetse infoga. Andmehaldur. Haldur on kasutaja, kes hankija esindajana tegeleb TISis sisalduvate andmete halduse ja äriprotsesside toega. Toote haldamine, lisamine, täiendamine, muutmine, kustutamine. Lisaks turismiteenuse pakkujale saab ka haldur toodet hallata, lisada, täiendada, muuta ja kustutada laiemate õigustega infosüsteemis . Teatud halduritel on vajadus lisada oma turismitooteid ning haldur saab olemasolevaid objekte muuta . Ettevõtja ja kasutaja haldus . Haldur saab kinnitada ettevõtja taotlust kasutajaks registreerimiseks ning abistada ettevõtjat tema kasutajate halduse juures . TIS on halduri igapäevane töövahend. Sisu haldur . Sisu haldur on kasutaja, kelle peamiseks ülesandeks on töö veebis avaldatud kõikvõimaliku sisuga: selle loomine, toimetamine ja tõlkimine. Sisu tootmine - Sisu haldur loob sisu (artiklid, teemalehed) lisades sellele meediat ja muid faile . Tõlkimine - Sisu haldur tõlgib ja toimetab talle suunatud sisu . E I S i Haldur . E I Si haldur on kasutaja, kes haldab ja arendab TISi kui infosüsteemi ning tagab selle toimimise. Administreerimine - Süsteemi üldiste parameetrite (rollid, domeenid, süsteemsed tõlked, API õigused jms ) haldus Kasutajate haldus - Süsteemi kasutajate haldus Statistika ja andmete kogumine ja väljastamine - TISis sisalduva info põhjal vajalik e andmete ja statistika genereerimine ja salvestamine , edastamine. Mõisted TIS Turismiinfosüsteem VISIT2 Turismiinfosüsteem . Termin on kasutusel TIS tehnilises dokumentatsioonis eristamaks maikuus 2024 live keskkonda paigaldatud uuenenud turismiinfosüsteemi selle eelmisest versioonist. E I S Ettevõtluse ja Innovatsiooni Sihtasutus Turismiosakond Ettevõtluse ja Innovatsiooni Sihtasutus e turismi osakond Turismiasjaline EIS töötajad, sihtkoha ja DMO töötajad, turismiprofessionaalid, tur i smiettevõtjad, sisuloojad, EIS hankepartnerid jt EIS koostööpartnerid. DMO DMO ehk Destination Management Organization on organisatsioon, mille eesmärk on edendada, kavandada ja koordineerida sihtkoha turismi arengut tervikuna (sh pakub külastaja teenuseid ja vajalikku infostruktuuri, et turustada sihtkohta kõige paremal viisil ja elanike heaolu suurendades) ja mis vastutab turismisihtkoha arendamise ja reklaamimise eest. Sihtkoht Turismisihtkoht on geograafiline piirkond ja turismitoodete kooslus, mis pakub külastajale integreeritud elamust ja mida külastajad mõistavad kui ühtset tervikut. Turismiettevõtja Turismiteenuse pakkuja, kes on sisestanud oma toodete/teenuste informatsiooni turismiinfosüsteemi ja kasutab www.visitestonia.com veebikeskkonda toodete/teenuste turundamiseks . Turismiprofessionaal Kõik asjaosalised (üksikisikud, grupid või organisatsioonid), kes mõjutavad ja keda mõjutavad turismivaldkonna otsused ja/või kes osalevad külastuselamuse protsessis. Peamisteks asjaliste gruppideks on: avalik sektor, mittetulunduslikud ühingud, sh: riigi- ja omavalitsusasutused ning nende poolt loodud tulundus- ja mittetulunduslikud organisatsioonid; üleriigilised ja regionaalsed turismi- ja tööandjate organisatsioonid; kolmas sektor, sh keskkonnakaitse ja teised organisatsioonid; turva-, tervise- ja muude teenuste pakkujad; meedia; akadeemilised institutsioonid ja muud uurimisasutused . Turismiobjekt (ka lihtsalt objekt) TISi loogiline andmeobjekt, mille alla kuuluvad kõikvõimalikud erinevad tooted ja teenused, mis on suunatud lõppkasutajale kui maksvale kliendile (ka turismitoode või turismiteenus) . SK TIS spetsialistikeskkond . SEO Search Engine Optimization Otsingumootorite mõistmine ja selle läbi otsingumootoritele sobiva kvaliteetse sisu loomise abil jõudmine otsingutulemuste esimestele lehtedele . CMS Content Management System – süsteem sisu haldamiseks, mis annab vajalikku infot avalikele veebidele, võimaldab ettevõtetel lisada ja hallata objekte ning spetsialistidel teostada vajalikke seadistusi. Once Only printsiip OOP – e-valitsuse kontseptsioon, mille eesmärk on tagada, et kodanikud, asutused ja ettevõtted peavad ametiasutustele ja ametiasutustele teatavat standardteavet esitama ainult üks kord . Riigi Autentimisteenus (TARA) Riigi autentimisteenus on keskselt osutatav teenus, millega asutus saab oma e-teenuses autentida ID-kaardi, mobiil-ID, smart -ID ja ka välisriigi kasutaja. Kasutajagrupp Kasutajagrupid moodustuvad sihtrühmadest ehk need on i sikud, kellel on sarnane TISi kasutajaprofiil, -eesmärk ja TISis teostatavad tegevused Sihtrühm Moodustub TISi teenuse kasutajagruppidest (pakkuja, tarbija, haldur) T urismiinfosüsteemi tehniline dokumentat si oon Arhitektuuri loomisel on arvestatud kaasaegsete infosüsteemide disainimise põhimõtetega, mittefunktsionaalsete nõuetega, süsteemi halduskuludega, skaleeritavusega , teenuste komponentide autonoomse publitseeritavusega , süsteemide monitooritavusega ja tarnete sõltumatu paigalduse põhimõtetega. Tehnoloogia vaade Süsteemi komponent Kasutatav tehnoloogia Versioon Andmebaas PostgreSQL /PostGIS 16.2 Arendusplatvorm Java OpenJDK 17 Kasutajaliidese raamistik Angular 17.0.7 Kasutajaliidese raamistik Next.js 14.1.0 Mikroteenuste rakendusplatvorm SpringBoot 3.1.7 Rakenduse põhiraamistik Spring Framework 6.0.15 Täistekstotsingu platvorm SOLR 9.5 Paigaldusvaade AWS Landing Zone Landing Zone on AWS arhitektuuri kontseptsioon, mis kirjeldab soovitusi mitmest kontost koosneva keskkonna seadistamisel. Regionaalne paigaldus Turismiinfosüsteemi kasutajate sihtturud paiknevad eri regioonides üle maailma. Selleks, et turismiportaal avaneks kiiresti kõigil sihtturgudel, on eesmärgi saavutamiseks sisu serveerimine tehniliselt lahutatud sisuhaldusest ja serverid on paigutatud regionaalselt. CI/CD protsess 74930 730250 0 0 Paigaldusportsessi eesmärk on automatiseerida rutiinsed tegevused, et hoida kokku tööaega ja vähendad inimvigu ning tagada pidev koodikvaliteedi mõõdikute kogumine ja kvaliteedinõuete jõustamine. Allolev diagramm illustreerib paigald a mise üldist protsessi. Komponentdiagramm Turismiinfosüsteemis ( tehnilises dokumentatsioonis edaspidi VISIT2 ) k omponentdiagrammil on kujutatud süsteemi peamised komponendid ja nendevahelised seosed. Loogiline vaade Turismiinfosüsteemi (Visit2) rakenduses on järgmised komponendid: Visit2 avalik keskkond (VE) - VE alamsüsteem hoolitseb www.puhkaeestis.ee ja www.visitestonia.com veebilehtede sisu kuvamise eest. VE jaguneb omakorda FE ( f rontend ) ja BE ( backend ) Spetsialisti keskkond (SK) jaguneb äriloogiliselt veel omakorda kaheks alamosaks: VE sisuhaldussüsteem - SK keskkonda kasutavad turismiarenduskeskuse töötajad ja turismiinfokeskuse töötajad. Ettevõtja keskkond - keskkonda kasutavad Eesti ettevõtjad oma toodete ja teenuste kirjeldamiseks. Tehnoloogiliselt jaguneb SK omakorda FE ( f rontend ) ja BE ( backend ) Välised komponendid Google Maps kaarditeenused - VE-s kuvatav staatiline kaart, kaardilink ja Google objektid, Reisiplaneerija yr.no - ilmaandmete API Äriregister Tilde tõlkerobot TARA - autentimissüsteem inADS - aadressandmete süsteem Mailiserver S3 - Amazoni pilveteenus pildi failide ja muude dokumentide hoidmiseks Cloudfront - CloudFront pilveteenus piltide ette laadimiseks vastavalt regioonile Visit2 taustaprotsesside rakendus - regulaarne andmete indekseerimine, SOLR otsingumootor - Visiti otsinguplatvorm avalikus keskkonnas otsingute teostamiseks PostgreSQL andmebaas - TIS salvestab andmed andmebaasi (turismiobjektid, Visiti sisumaterjal jne) VISIT2-FE ja VISIT2-BE konteinerdiagramm Diagramm kirjeldab Visit2 avaliku vaate (VE) komponendid ja suhtluse komponentide vahel. VISIT2-SK-FE ja VISIT2-SK konteinerdiagramm Diagramm kirjeldab Visit2 spetsialisti keskkonna (SK) vaate komponendid ja suhtluse komponentide vahel. Rajadokument Visit2 liidestused teiste süsteemidega põhinevad alljärgnevatel standardsetel tehnoloogiatel: Java rakenduste ja andmebaasi vahel on kasutusel JDBC liidestus . Rakenduse komponendid kasutavad omavahelises suhtluses HTTP/HTTPS REST API-sid. Meiliteenused kasutavad SMTP protokolli JMS sõnumivahetus kasutab AMQP/REST protokolli Tarbitavad teenused: Nimetus Teenuse kirjeldus Osapool Protokoll Liidestus S3ga Amazon'i veebiserveris S3 paikneb VISTI2 staatiline sisu failidena (pildid, dokumendid, kampaaniate välised failid, bannerid ). Amazon HTTP/HTTPS Liidestus E I S maili serveriga e-maili serveri kaudu saadetakse VISTI2-st välja süsteeemseid kirju (nt teavituskirjad). HTTP/HTTPS Statistika: Google Analytics Objektide vaatamiste statistika kuvamine. Kogu statistika päritakse iga kord uuesti Google Analytics-lt , statistikat VISTI2 andmebaasi ei salvestata. Teenuse sisendiks on objekti ID ja ajaperiood ning väljundiks objekti statistilised andmed. Google HTTP/HTTPS Google Tag Manager Tag Manageris toimub Google Analytics'i poolt kasutatavate tagide kirjeldamine ja haldamine Google HTTP/HTTPS Google Maps Google Maps teenust kasutame kaardiliideses Google HTTP/HTTPS Keycloak SSO autentimisteenus Youtube Youtube liidest kasutame videote staatuse kontrollimiseks Youtube'st Sisendiks on video ID ja väljundiks video staatus. Mitteavalikud või kustutatud videod kustutatakse VISTI2 süsteemis HTTP/HTTPS Smaily Uudiskirjade väljasaatmise platvorm Smaily HTTP/HTTPS inADS Aadressandmete register Äriregister Ettevõtete register yr.no Ilmateate API TARA Riiklik autentimisplatvorm Tilde tõlkerobot Tilde poolt pakiutav tõlkeroboti API Pakutavad teenused: Visitestonia.com andmete eksportliides on mõeldud turismiportaali andmete jagamiseks teistele veebisaitidele ja asutustele. Andmete eksportliides on lahendatud veebiteenusena, mille väljundi formaadiks on kindlatele JSON Schema'dele vastavad JSON dokumendid. Tehniliselt on eksportliides tavaline veebiaadress. Kuigi see teenus on mõeldud kasutamiseks teiste programmide poolt, on neid võimalik ka veebilehitsejaga kasutada. Nimetus Teenuse kirjeldus Protokoll Objektide veebiteenus (API) Turismiinfosüsteem VISTI2 jagab kolmandatele osapooltele kasutamiseks turismiobjektide eksportimise liidest. Kõik päringud andmete eksportimise liidesesse peavad olema autenditud ja autoriseeritud. HTTP/REST Domeenide veebiteenus (API) Turismiinfosüsteem VISTI2 jagab kolmandatele osapooltele kasutamiseks domeeniväärtuste eksportimise liidest. HTTP/REST Raamlepingu perioodil kavandatavad/eeldatavad liidetustööd : Riigi Infosüsteemi Haldussüsteemi RIHA liitumine. TIS poolt kogutud andmete jagamine avaandmetena RIHA keskkonnas. Külastajate tagasiside koondamise keskkonna API liides. Reviewpro API või samaväärne liides . Külastajate tagasiside koondamise keskkond ja selle info kuvamine TIS-s turismitoote juures. P ileti müügi keskkondadega API liides . Erinevad piletimüügikeskkonnad (nt Piletilevi, Fienta jt) pakuvad infot erinevate turismiväärtuslike ürituste toimumise kohta, mida kuvada välja ka turismiportaalis ning võimaldavad kasutajal mugavalt osta pilet üritusele. Piletilevi API on olnud kasutusel ka varasemas TIS versioonis. Riigimetsa Majandamise Keskus API liides RMK matkateede info (sh kaardil) kuvamiseks visitestonia.com veebis. Statistikaamet API liides andmevahetuseks. R attamatkateede kuvamine visitestonia.com veebis turismikaardil. Rattamatkateed on olnud kasutusel varasemas TIS versioonis (rattateede failid . shp ja . gpx kujul). Rattamatkateede kuvamiseks turismikaardil on vajalik teostada analüüs ja leida sobivaim tehniline võimalus. Täpne liidestuste nimekiri täpsustatakse raamlepingu täitmise käigus koostöös tell i jaga. Sisuhaldussüsteemi (CMS) tehnilise lahenduse kirjeldus TIS infosüsteemis kasutatakse custom made CMS lahendust. Sisulehe kujunduse haldamiseks ja templiitide loomiseks on kasutusel angular-gridster2 komponent, mis arhitektuuriliselt sobib TIS arendusplatvormiga ( https://www.npmjs.com/package/angular-gridster2 ). Sisekeskkonnas sisuhalduses on võimalik luua/muuta veebilehe sisu templiite. Kontreetse templiidiga seotud sisulehe eelvaates ja avalikus pooles esitlemisel on kasutusel Angular Materiali standardne Grid list komponenti ( https://material.angular.io/components/grid-list/examples ), mis seob kasutaja poolt kujundatud lehe (st templiidi ) paigutuse konkreetes sisulehe väljadega ja kuvab seda sellise paigutusega nagu kasutaja määratles. UX/UI disain TIS UX/UI disainikontseptsioon juhindub Eesti brändi ( https://brand.estonia.ee/ ) stiilinõuetest ja veebikomponentidest (https://brand.estonia.ee/design/web/) , mida on kohandatud vastavalt sobivaks Visit Estonia kasutajatest ja visioonist lähtuvalt. Põhimõtete loomisel on võetud arvesse vajaduste kaardistust ja parimate praktikate analüüsi, EISi sõnumi- ning digikanalite strateegiat ja üldiseid uuemaid tarkvaraarendus- ning disainisuundasid. Disainisuundade arendamisel lähtutakse peamiselt ptk REF _Ref158887276 \r \h \* MERGEFORMAT 2.3 toodud põhimõtetest : kasutajakeskus, mobiile first , minimalism, Eesti identiteet ja unikaalsus, uued disainisuunad, kestlikkus, ligipääsetavus. UI - kit , prototüübid, komponendi d ja veebivaated on loodud Figma keskkonda Visit Estonia stiiliraamatusse. Mittefunktsionaalsed nõuded Mittefunktsionaalsed nõuded (MFN) on koostatud EISi majasiseste infosüsteemide ja veebide üleselt. Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus võimalik. Ü ldised reeglid ja põhimõtted : Lisaarendused peavad vastama OWASP L2 nõuetele. Veebirakendus peab oluliste probleemi d eta läbima OWASP ASVS baasil põhineva kontrolli. Veebirakenduse kasutajaliides peab vastama vähemalt WCAG 2.1 tasemele AA. Tehniliste lahenduste edasiarendamisel või projekteerimisel peab arvestama selle võimaliku laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. Koormamata süsteem peab mõõdetud kordadest 95% juhtudel laadima 2 sekundi jooksul eeldades mõistliku suutlikkusega kliendiseadmeid ning sidekanali läbilaskemahtu. Tehn i liste lahenduste projek t eerimisel tuleb arvestada veebisirvikute Edge, Chrome, Safari ja Firefox toega. Veebisirvikute kohustuslik tugi peab olema tagatud kahe olulise (major) versiooni ulatuses alates värskeimast. Veebilehtede disainimisel tuleb järgida SEO põhimõtteid. Veebilahendus tuleb projekteerida kasutajaseadme võimekusi arvestavana ( Responsive Design) . Vanemate veebilehitsejate korral tuleb kuvada teadet veebisirviku uuendamise soovitusega ning võimalusel kuvada andmeid lihtsustatud visuaalsel kujul. Kõik veebilehel kuvatavad e-postiaadressid peavad olema teisendatud kujule, mis takistab lehe sisust e-postiaadresside automaatset kogumist. Kõikidele vormidele peab olema lisatud automaatse sisestuse kaitse (CAPTCHA) . Vigade ja erandite töötlus esitatakse kasutajale arusaadavalt avaldamata tehnilisi üksikasju. Veebilehel peab olema teavitusvõimalus küpsiste ( Cookies ) kasutamise kohta, mille kinnituse puhul samalt kasutajalt nõustumist enam uuesti ei küsita. Tarkvara lähtekood peab olema dokumenteeritud detailsuses, mis võimaldab hilisemat edasiarenduse jätkamist. Kõik kasutatavad teegid, teenused ja komponendid tuleb eelnevalt kooskõlastada tellijaga. Kui lahendus vajab andmevahetus X-Tee kaudu, tuleb lähtuda RIA nõuetest. Kui süsteemile on vajadus on lisada kasutajatuvastus tuleb projekteerimisel eelistada TARA autentimisteenuse kasutamist. Tehniline lahendus peab olema projekteeritud ja koostatud vastavalt kehtiva Eesti Infoturbestandardi (E-ITS) nõuetele veebirakenduste (APP.3.1) kohta. Digitaalse allkirjastamise vajaduse puhul tuleb kasutada riigi keskseid lahendusi ja teenuseid. Süsteemi või veebi loomisel kodanike ning ettevõtjate andmete kasutamisel lähtutakse andmete ristkasutamise põhimõttest. Nõuded rakenduse arhitektuurile Rakenduse, andmebaasi ja kolmanda osapoole komponendid peavad olema sellised, mille eluea lõpp (EOL) pole teadaolevalt vähem kui 2 aasta pärast . Projekteeritav lahenduse peab olema kooskõlas tellija IT profiiliga. Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril. Rakendust peab saama ilma ümber programmeerimata liigutada erinevate domeenide vahel. Rakenduse komponentide konfiguratsiooni peab olema võimalik ette anda käivitamisel. Konfiguratsiooni muudatus peab olema teostatav ilma rakendust kompileerimata. Rakenduse taaskäivitus , konfiguratsiooni muutmine vms peab toimuma mõistliku aja jooksul. Rakendus peab kasutama 64-bitist arvutiarhitektuuri. Kõik andmed, andmebaasid, SQL skriptid, lähtekood ja rakendus peavad kasutama UTF-8 kodeeringut. Rakenduserveri failisüsteemi ei tohi salvestada midagi püsivaks kasutamiseks. Ühest relatsioonilise andmebaasi andmetabelist teise viitamisel tuleb kasutada väliseid võtmeid ( Foreign key ) Kõik välised võtmed ( Foreign Key ) peavad olema indekseeritud. Tuleb kasutada päringumuutujaid ( Parameter Binding ) . Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti. Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest. Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat: Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Rakenduse piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus . Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis . Failide hoidmise tuleb kasutada S3 lahendust või analoogset. Rakendus peab olema võimeline kasutama keskkonnamuutujaid (serverinimi, kuu, päev jne) Kõik komponendid peavad töötama nö stateless režiimis, mis võimaldab neid vajadusel juurde lisada koormuse kasvamisel. Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Accent peab olema sisse lülitatud. Kui infosüsteem saadab e-kirju, tuleb kasutada välist SMTP serverit. Kirja saatmisel peab rakendus veenduma, et e-posti server võttis kirja vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322). Kõik projekteeritavad süsteemid peavad omama selgelt eristatavat esitluskihti ning tagasüsteemi ( back end; äriloogika kiht). Arhitektuuriliselt peavad need kihid olema selgelt lahutatud ja eraldi paigaldatavad. Rakenduse failid, mida kasutaja näha ei tohi, peavad asuma juurdepääsupiiranguga kaitstud kaustades. Erinevaid sama sisuga parameetreid ei tohi konfiguratsioonis eksisteerida. Tarkvaralahendus peab olema projekteeritud kõrgkäideldavust võimaldavana sõltumata sellest, kas dubleerimist rakendatakse või mitte. Keskkonnapõhised muutujad peavad olema konfiguratsioonifailist seadistatavad. Rakenduse äriloogika tuleb realiseerida andmebaasist eraldi sõltumatus rakenduskihis. Veebiteenuseid (REST, SOAP) pakkuv rakendus peab olema üles ehitatud nii, et see toetaks teenuste versioneerimist URL-i ja/või schema tasemel. Rakendus peab olema võimeline töötama koormusjaoturitega varustatud taristul. Sidusinfosüsteemide mitte kättesaadavus ei tohi segada rakenduse funktsioneerimist. Sidusinfosüsteemidega andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse. Automaatselt käivituvaid taustatöid peab saama käsitsi (taas)käivitada. Kui ajastatult käivitatav taustatöö, ei ole mõeldud töötama paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud. Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate tehnoloogiate ja standardite valik tuleb kooskõlastada t ellijaga . Rakenduse ühenduste (s.h. andmebaasi ja sidusinfosüsteemide ühendused) realiseerimisel tuleb kasutada ühenduste puulimist ( Connection Pooling ). Logimine Logimiseks tuleb kasutada standardseid komponente kogu logiahela ulatuses. Logikomponent peab võimalama rakenduse administraatoril määratleda ja muuta logide väljundit, logimise taset ja logimise formaati. Logid peavad olema jaotatud loogiliselt: Auditlogi (Seansilogi, tegevuslogi) - info sisselogimiste, väljalogimiste ja seansi aegumiste kohta. Vigased sisselogimise katsed. Info õiguste suurendamise kohta. Peab olema logitud ka tühja või puuduvate parameetritega logimise katsed. Kogu informatsioon kasutajate tegevuste kohta koos tegevuse tüübi, seansi parameetrite (korreleerimaks seansi- ja tegevuslogi) ja kasutaja poolt esitatud sisendparameetritega (sh. väliste ressursside kasutamise kohta). Logida tuleb nii õnnestunud kui ka ebaõnnestunud tegevusi. Tehniline logi - rakendusserveri poolt loodud logi . Vealogi - erinevate veaolukordade info . Silumislogi - arendajate jaoks vajalik debug info . Logides peab olema maksimaalselt üks sündmus ühel real. Logiväljade nimed peavad olema normaliseeritud. Üle terve logi peab olema kasutaja sessiooni käigus tehtud tegevusi või sama sündmust võimalik siduda loogiliselt kokku. Andmete loomise/vaatamise/muutmise/kustutamise tegevused peavad olema kajastatud logides. Logida tuleb kõiki päringud. Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega Logis tuleb kõik mitte kuvatavad (non- printable ) sümbolid kodeerida. Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu. Rakendus peab suutma logida kõiki X-tee teenuste kaudu vahetatavaid andmeid. Peab olema võimalus logimist sisse-välja lülitada. Rakenduse funktsionaalsuse kirjeldusega tuleb luua ka logimise dokumentatsioon ja loginäidised. Testimine Rakenduse kõik üleantavad versioonid peavad enne tellijale üle andmist olema läbinud vähemalt funktsionaalsed- ja regressioonitestid . Lahendus peab olema kaetud automaatsete komponenditestidega ( unit test). Lahenduse baasfunktsionaalsus peab olema kaetud automaatsete vastuvõtutestidega . Rakendusega peab olema kaasas skript jõudlustestide tegemiseks. Rakendusel peab olema masinloetav testleht (Health Check ) JSON formaadis. Rakendus peab pakkuma monitooringu lehte, kus leidub informatsioon rakenduse funktsionaalsuse toimimise kohta . Nõuded rakenduse lähtekoodile Lähtekoodi kommentaarid peavad kõigis lahenduse kihtides (rakenduse enda kood, andmebaas jne) olema kirjutatud inglise keeles. Lähtekoodi kommentaarid peavad olema selged, arusaadavad ja sisuliselt kirjeldama vastavat koodi, mille juures nad. Lähtekoodis kirjeldatud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses. Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad. Kasutuses mitteolev kood tuleb rakenduse lähtekoodist kõrvaldada. Arendamisel lähtutakse DRY, SOLID ja KISS põhimõtetest. Ka s utajaliides Kasutajaliidese kõik disainiotsused peavad olema kooskõlastatud tellijaga enne nende realiseerimist. Veebipõhine kasutajaliides peab olema kasutatav enamlevinud veebisirvikutega , sh nutiseadmetel (Android, IOS) Rakenduse värviskeem ja logo kasutamine peab vastama Tellija ametlikule visuaalsele identiteedile (CVI) ja disainijuhistele (UIG). Kasutajaliidese kõik osad ja teated peavad olema eestikeelsed. Avalikuks kasutamiseks projekteeritav rakendus peab olema graafiliselt skaleeruv ( Responsive Design) ja mugavalt kasutatav kõigi enamlevinud arvutite monitoride resolutsioonidega. Hüpikaknaid ( pop-up ) ei tohi kasutada. Modaalaknad on lubatud. Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja massmuutmiste kohta kui pole kokku lepitud teisiti. Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale eestikeelse kasutajasõbraliku veateatega, mis sisaldab soovituslikult ka vea koodi. Veateated peavad olema süsteemihalduri poolt hallatavad. Kasutajaliides peab olema ilma rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole kokkulepitud teisiti. Rakenduse tausta, menüüde ja teksti värvid peavad olema ilma rakenduse koodi muutmata vahetatavad. Rakenduse kasutajaliides peab teavitama kasutajat ette sessioon aegumisest. Kui vormile sisestatakse mahukaid andmevälju peab kasutajaliides kokku lepitud ajavahemike järel salvestama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks Sisestusvormidel andmete sisestamisel peab saama väljade vahel vastavalt äriloogikale liikuda klaviatuuri abil tabulaatoriga. Interaktiivsete vormide puhul ei tohi lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). Kui päring võtab aega kauem kui 3 sekundit, peab kasutaja saama visuaalse teate, et süsteem tegeleb päringu läbiviimisega. Esilehel ( sisselogimata ) ja ka pärast kasutaja autentimist peab olema lihtne võimalus teavitada kasutajat muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav Päringu vastusena kuvatud tabeli veerge on võimalik andmete/teksti tähestikulises järjekorras sorteerida Andmeväljade kohustuslikkus peab olema vormi väljadel märgitud tärniga (*) Rakenduse andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses eesti keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappide Kasutajaliidesel peab olema hooldusteate võimekus. Dokumentatsioon Lõppkasutajatele ja avalikkusele suunatud rakenduse dokumentatsioon peab olema kirjutatud eesti keeles. Dokumentatsioon peab olema versioneeritud , muutmiskuupäevadega, autori nimedega, korrektse keelekasutusega, selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et sõltumatu kolmas tehnliste IT baasteadmistega isik suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi). Iga uue versiooniga peab alati välja tooma versiooni muudatuse kirjeldused ( release notes ). Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto - ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh TLS sertifikaatide kasutuskohad. Versioonihaldus Kogu rakenduse testimiseks, koolituseks või implementeerimiseks üle antav lähtekood ja tarkvarapaketid peavad olema versioneeritud . Nii tarkvaraarenduse kui ka süsteemi hoolduse korral kasutatakse Tellija tööde ja veahalduse keskkonda Paigalduspaketi kooste Juhul kui versioonihalduse keskkond ei paku paigalduspaketile kontrollsumma ( checksum ) automaatset koostamist, siis koostatakse kontrollsumma arendaja poolt ja pannakse eraldi . sum failina tarnele kaasa. Tarnitava lahenduse koosseisus üle antava lähtekoodiga peavad kaasas olema kirjeldused sellest paigalduspaketi koosteks. Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada ainult minimaalse rakenduse käitamiseks vajamineva failikomplekti. Andmebaasi paigalduse skriptid peavad olema osa üleantavast arendustööst. Versioneeritud ja dokumenteeritud. Rakenduse lähtekoodi juures peavad leiduma skriptid rakenduse keskkonnast sõltumatult (konteinerlahenduses) kokku kompileerimiseks. Paigalduspakett koostatakse Tellija pideva integratsiooni ja levitus keskkonnas. Kubernetesel orkestreeritavate lahenduste paigalduste jaoks tuleb luua Helm chart . Raamlepingu perioodil teostatavad pakkuja ülesanded ja tegevused Raamlepingu perioodil teostatavad tegevused ja tellitavad tööd (loetelu ei ole lõplik, samuti ei ole hankija kohustatud ühe hankelepingu raames kõiki järgnevalt loetletud tegevusi/töid tellima): TIS arendus, majutus, haldus ja hooldus; t arkvarahooldusteenus– korralised tarkvarauuendused, veaparandused, tellija es i ndajate nõustamine ning tehniline tugi; t arkvara lahenduste dokumentatsioon, sh analüüsi, paigaldamise, administreerimise ja kasutamise juhendite koostamine; TIS veebikeskkonna arhitektuuri ja sõltuvuste uuendamine ja kaasajastamine; v eebikeskkondade ja süsteemide arendamine vastavalt tellija ärivajadustele; veebikeskkondade ja süsteemide töökindluse monitoorimine ja töökindluse tagamine vastavalt teenusetaseme kokkuleppele (täpsemalt p REF _Ref89767707 \r \h 6 ); t urvaintsitentide vaste ( security incident response ) ; süsteemidisain sh andmevood, liidesed ja andmemudelid; p rogrammeerimi ne ja clean code põhimõtete järgimi ne; tarkvara kvaliteediprotsessi disain ja läbiviimine; d okumenteerimine –valmis veebilahenduste tehnilise ja ärilise loogika kirjeld amine ; v ajaduste ja olukorra kaardistamine (ärianalüüsi ja teenusedisaini kombineerides); rakenduse eesmärgi, kasutajaskonna ja funktsionaalsuse kirjeldamine koostöös tellijaga või tellija esindajaga; k ülastatavuse ja kasutuskogemuse parendamine; UX ja UI disain , sh vajadusel kasutajatestide läbiviimine ja nende tulemuste analüüs ning disainiotsuste tegemine koostöös tellijaga või tellija esindajaga; testimine; v ajadusel tarkvara toimi miseks vajalike litsentside ja kasutajaõiguste tellimine ja tagamine; t äitja pea b koostama ja testima taasteplaani tagamaks teenuse taseme kokkuleppe täitmise ; r aamlepingu perioodil teostatavad tegevused ja saavutatavad tulemused ei ole üksikasjalikult ette antud, vaid need töötatakse välja koostöös täitjaga jooksvalt raamlepingu perioodi vältel ; TIS toimimiseks peab pakkuja vajadusel korraldama ning teostama tulemuste ja eesmärkide saavutamiseks vajalike teenuste ja liideste olemasolu väliste süsteemidega ning tehnoloogiatega või tagama nendega samaväärsetega jätkamise. Teadaolevad pakutavad ja tarbitavad teenused ja liidesed on loetletud p 4.4. Loetelu ei ole lõplik ; Eelnimetatud teenuse maksumus ei sisaldu tarkvara arenduse ja hooldus e ühe töötunni maksumuses, vaid tasutakse pakkuja esitatud arve alusel. Hankijal on õigus lepingupartnerilt küsida teostatud teenuste kohta kuludokumentide koopiaid. Nimetatud teenuse maksumused kajastuvad raamlepingu kogumaksumuses ; Pakkuja poolt digitaalsel kujul esitatavad materjalid peavad olema salvestatud ja edastatud optimaalse mahuga, et vältida otstarbetult suuri andmefaile ning seega vähendada digireostust. Üldised nõuded teenusele, majutusele, käideldavusele, hooldusele ja garantiile Majutus : Pakkuja kohustub tagama hanke käigus olemasoleva tarkvara kasutamise võimaluse AmazonWeb Services (AWS) teenustele ning lepingu kehtivuse perioodil kindlustama selle nõuetekohase funktsioneerimise ning vajalike arendusmuudatuste sisseviimise. Majutusteenuse maksumus kajastub raamlepingu kogumaksumuses, kuid ei sisaldu tarkvara arenduse ja hoolduse ühe töötunni maksumuses, vaid tasutakse vastavalt teenuse pakkuja poolt esitatud eest arve alusel. Hankijal on õigus lepingupartnerilt küsida teostatud teenuste kohta kuludokumentide koopiaid. Keskkond : v ajalik on kolm keskkonda: arendus, prelive ja live . Koodiuuendused ja hooldusteenused : Täitja vastutab kasutatava tehnoloogia korraliste tarkvarauuenduste, turvauuenduste, veaparanduste eest koostöös tellijaga. Vajadusel pakub pakkuja vastavasisulist tellija esindajate nõustamist. Tellija esindaja teavitamine tarkvarauuenduste vajalikkusest on täitja ülesanne . Vajadusel pakub täitja tellija esindajate tarkvara kasutamise koolituse teenust ning nõustamisteenust. Koolituse hind kokkuleppel tellijaga. Tarkvara dokumentatsioon, sh analüüsi, paigaldamise, administreerimise ja kasutamise juhendid on iga uue rakenduse ja veebilahenduse lahutamatu osa. Nende koosseis lepitakse kokku tellijaga või tellija esindajaga ning nende koostamise eest hiljemalt 6 kuu möödudes peale valmis rakenduse või veebilahenduse üle andmist vastutab pakkuja. H ooldustööd ja paigaldused peavad reeglina toimuma tööajal ja mitte reedeti. Nende järgselt tuleb vastavaid veebirakendusi ja -keskkondi hoida kõrgendatud järel e valve all ning võimalikud esinenud vead koheselt parandada. Hooldustööd/paigaldused võivad toimuda eelnevate kokkulepete alusel töövälisel ajal. Valmis arendatud lahendusele tehakse enne LIVE paigaldust turvalisuse ja töökindluse tagamise eesmärgil testid, nii automaatsed kui ka manuaalsed. Vigade avastamise korral peab tarnija need oma kulul parandama (garantiitöö). Kvaliteet ja garantiil i sed tööd : Täitja vastutab tööde kvaliteedi ning terviklikkuse eest . Pakutavad lahendused peavad olema otstarbekad ning arvestama Eestis kehtivaid õigusakte. Tellijal on õigus tööde teostamise käigus väliste partnerite abiga kontrollida täitja poolt teostatavate tööde kvaliteeti ja lepingu tingimustest kinnipidamist. L epingule mittevastavate tööde avastamisel informeerib tellija koheselt täitjaid kirjalikku taasesitamist võimaldavas vormis. Täitjal on kohustus viivitamatult kirjalikku taasesitamist võimaldavas vormis teavitada tellijat probleemidest, mis segavad lepingus toodud tööde teostamist ja tähtaegadest kinnipidamist ning õigus esitada tellija kontaktisikule ettepanekuid tööde ja tähtaegade muutmiseks. Kui tehniline viga ilmneb pärast pakkuja kinnitust, et lahendus/rakendus on töökindel, lahendus on paigaldatud LIVE keskkonda (ja kasutajatele kättesaadavaks tehtud) ning selgub, et lahendus on ikkagi vigane, rakendub tasuta garantiiline parandus. Täitja vastutab tööde teostamise kvaliteedi eest ja kõrvaldab 6 (kuue) kuulise garantiiperioodi jooksul ilmnevad vead omal kulul, välja arvatud juhul, kui puuduste tekkimise eest vastutab tellija. Garantiiperiood algab tööde vastuvõtmisest tellija poolt. Juhul, kui tööd antakse tellijale üle mitmes etapis, algab garantiiperiood viimase etapi vastuvõtmisest tellija poolt. Garantii hõlmab kõiki garantii tähtaja jooksul ilmnenud tööde ja lepingu tingimustele mittevastavusi, sealhulgas on täitja kohustatud uuendama või asendama kõik mittevastavus i sisaldavad dokumendid. Tellija informeerib täitjat vea iseloomust ja teadaolevast ulatusest otsekohe selle ilmnemisel. Täitja vastutab vea kogu ulatuse välja selgitamise, tellija sellest informeerimise ja vea parandamise eest. Kui täitja ei suuda viga mõistliku aja jooksul kõrvaldada oma meeskonna koos seisuga, peab täitja vea kõrvaldamiseks leidma kolmanda osapoole ning teostama lahenduse oma kulul ja riskil. Kui tellija poolt raporteeritud vea puhul ei ole tegemist mittevastavusega , kuulub täitja poolt nii probleemi väljaselgitamise ks kui ka selle kõrvaldamise ks kulunud aeg tasustamisele. Käideldavus , vigade ennetamine, raporteerimine ja parandamine (hankija nõuded teenuse tasemele) : Tellija jälgib käideldavust ning täitja on kohustatud teenust osutama vastavalt järgnevates punktides esitatud nõuetele. Kättesaadavus. Kõik funktsioonid peavad olema tehniliselt kättesaadavad ööpäevaringselt . Tehniline kasutajatugi tööpäevadel tööajal vahemikus kl 8-17. Keskkonnas võimalike hooldustööde tegemise aeg on tööpäeviti vahemikus kl 8-17 ja vaid erikokkulepetel muudel aegadel . Levituste ( live ) teostamine toimub kokkuleppel tellijaga, kuid soovitatavalt töönädala esimeses pooles, hommikustel kellaaegadel. Täitja vastutab andmebaasi ja veebilahenduse riketest teatamise eest. Täitja vastutab tehniliste vigade avastamiseks vajalike tellijaga kokkuleppel piisavalt ulatuslike automaattestide loomise eest. Kõik tehnilised vead peavad läbima 24 tunni jooksul triaaži (st saama esmase diagnoosi ning otsuse prioriteetsuse kohta) . Rikete kõrvaldamine vea prioriteedist lähtuvalt vastavalt alltoodule: kõrge – (süsteemi kriitiliste komponentide tõrge või rike, mis halvab suurema kasutajagrupi või kogu organisatsiooni töö). Sellisel juhul alustatakse probleemi likvideerimist viivitamatult p ärast teate saamist ja jätkatakse tööd kuni vea likvideerimiseni. keskmine – (süsteemi tõrge või rike, mis halvendab kasutajatele mingi süsteemi ühise ressursi ja/või jagatud teenuse kättesaadavust, kuid põhifunktsionaalsus on kasutatav). Sellisel juhul alustatakse probleemi likvideerimist võimalikult kiiresti, kuid mitte hiljem kui nelja (4) töötunni jooksul peale teate saamist ja jätkatakse tööd kuni vea likvideerimiseni. madal – (süsteemi tõrge või rike, mis tekitab kasutajatele kerge efektiivsuselanguse ja/või kasutamise ebamugavuse ja mis ei takista põhilist funktsionaalsust). Sellisel juhul võib alustada probleemi kõrvaldamist hiljemalt 2 tööpäeva jooksul peale teate saamist. Talitluspidevuse tagamine : Talitluspidevuse tagamisel lähtutakse järgmistest põhimõtetest: RPO – andmete taastamise korral ei tohi andmekadu olla rohkem, kui 24h ; RTO – teenus peab olema taastatav 6h jooksul, erandkorras eelneval kokkuleppel tellijaga maksimaalselt 24h jooksul ; Varundatavate andmete hulka peavad kuuluma vähemalt kõik andmed, mis on vajalikud teenuse nõuetekohaseks taastamiseks ja n ende kadu ei tohi olla suurem kui 24h ja taasteaeg 6h . Muuhulgas peab varundatavate andmete hulka kuuluma: Andmebaasis hoitavad struktureeritud andmed ; S3 objektisalvestuses hoitavad andmed ; Solr masteri index ; Konfiguratsioonihalduse andmed ; Rakenduse lähtekood ; I ga kuue kuu tagant peab toimuma taastetest (varukoopiast taast amine ) . Täitja kohustub tagama tellija konfidentsiaalse teabe, mh isikuandmete turvalise töötlemise lähtudes lepingus või selle lisades sätestatud tingimustest ning rakendades nõuetekohaseid turvameetmeid, et tagada andmete nõuetekohane kaitse ja loata juurdepääs. UX ja UI disain: Kasutada Eesti brändi põhimõtteid ( https://brand.estonia.ee/ ) ning veebikomponente (https://brand.estonia.ee/design/web/) vastavalt tellija päringule. Vajadusel võib arendada ka uusi komponente (kokkuleppel tellijaga), mis on kooskõlas nimetatud põhimõtetega ning mis tuleb salvestada Eesti Brändi Figma keskkonda Visit Estonia stiiliraamatusse. Komponentide ja veebivaadete loomisel tuleb kasutada Figma keskkonda. Veeb vastab WCAG 2. 2 AA nõutele (k.a navigeerimine klaviatuuriklahvidega) HYPERLINK "https://www.w3.org/TR/WCAG22/" WebContentAccessibilityGuidelines (WCAG) 2.2 (w3.org) Lahenduse loomisel tuleb lähtuda komponendipõhisest ( component based ) veebidisaini printsiibist ning maksimaalselt ära kasutada Figmas olevat library -komponente või neid vajadusel sinna täiendada. Veebileht on kiire (leht avaneb alla 3 sekundi - 3G ühenduse peal). Veebirakenduses tehtavate toimingute lubatud maksimaalne kestvus on 1 – 3 sekundit. Dokumentatsioon : Täitja varustab tellijat dokumentatsiooniga, mis on vajalik rakenduste efektiivselt kasutamiseks ja hooldamiseks/täiendamiseks. Dokumentatsioon sisaldab kasutus- ja administreerimisjuhen dit ning vähemalt alljärgnevat: süsteemi funktsionaalsuste spetsifikatsioonid; tarkvaras tehtud kohandused süsteemi toimimiseks; muudatuste logi; süsteemi arhitektuur; paigaldusjuhend . Dokumenta t sioon peab olema koostatud eesti keeles. Dokumentatsioon peab vastama tööde kirjelduses toodud töödele, sisaldama muudatusi ja olema terminoloogiliselt üheselt mõistetav . Täitja uuendavad või asendavad kõik esinenud vigade või puudustega dokumendid garantiiperioodi jooksul. Dokumentide valmistamiseks ja üleandmiseks kasutatakse elektroonilist infokandjat . Sta tistika / analüütika ja SEO : Kõikides rakendustes tuleb kasutajate tegevuste logimiseks kasutada Google Analytics`t , mis annab võimaluse detailselt mõõta lehekülastusi ja kasutajate käitumist, v.a juhul, kui ei ole võimalik andmekaitsega seotud piirangutest või nõudmistest või tehnoloogilistest piirangutest lähtuvalt. Täpsed komponendid lepitakse kokku töö käigus. Avalikus veebirakenduses tuleb arendamisel järgida TIS tarbeks praeguseks väljatöötatud SEO nõudeid ja põhimõtteid ning vajadusel teha ettepanekuid SEO parandamiseks. Muudatuste juhtimine Muudatused valmistab ette arendaja ja täitja paigaldab teenuse test- ning toodangkeskkonda vastavalt arendaja poolsele sisendile . Muudatusi viiakse sisse VE päevase madalaima kasutuskoormuse perioodil . Muudatuste paigaldamise täpse aja lepivad kokku tellija ja täitja. Muudatuste paigaldamise õigus test- ja toodangkeskkonda on ainult täitjal . Muudatuse ebaõnnestumisel vastutab täitja teenuse taastamise eest ( rollback ). Tellija võib tellida täiendavate muudatuste paigaldamise nii toodangu- kui testkeskkonda kampaaniate perioodil või kriitiliste vigade parandamiseks. Nõuded tööprotsessidele Kogu raamlepingu perioodi jooksul on täitja poolt projektile pühendatud meeskond tellija esindajale partneriks. Täitja meeskond pakub tellijale abi ja informatsiooni (sh konsultatsiooni) süsteemi töötamise, vigade ja tõrgete kohta, nõustatakse probleemide korral, koostatakse vajalikku dokumentatsiooni, tööplaane vms. Koostöö eesmärgiks ja tulemuseks peab iga uue lahenduse loomisel ning olemasoleva parendamisel olema töötav, kvaliteetne ja mõistlikus ajaraamis valminud rakendus, mis loob kasutajatele väärtust. Tööd teostab tellijaga eelnevalt kokku lepitud püsiva koosseisuga meeskond. Täitja võib meeskonna koosseisu muuta tellijaga vähemalt kuu aega varem kokku leppides või möödapääsmatutel erijuhtudel lühema etteteatamiseajaga. Tellijal on õigus täitjaga kokkuleppel 1-kuulise etteteatamisega paluda mõni meeskonnaliige mittesobivuse tõttu välja vahetada. Tellijal on õigus vähemalt 1-kuulise etteteatamisega meeskonna koosseisu vajadusel vähendada. Erijuhtudel, kokkuleppel täitjaga võib seda teha ka lühema etteteatamisega. Päevadel või kellaaegadel, mis on tellija ja täitja poolt kokku lepitud kui tellija projektidele pühendatud aeg, ei tohi arendajatel ega muudel meeskonnaliikmetel olla kohustusi täitja teiste klientide või muude projektide osas, v . a juhul, kui täitja ja tellija on erandkorras ajutiselt muid kokkuleppeid teinud. Arendustööde teostamisel kasutada agiilset arendustööde juhtimise metoodikat . Täpne metodoloogia ja detailid lepitakse kokku täitja ja tellija vahel. Tellija peab olema tööprotsessidesse (analüüsikoosolek, projektikoosolek, hindamiskoosolek vms) kaasatud vähemalt 1 kord nädalas ; Töö toimub eelistatult täitjaga kokku lepitud pikkusega sprintides. Iga sprindi planeerimine toimub koostöös tellija ja arendajaga. Igas sprindis prioritiseeritakse tööd enne iga sprindi algust ja igal sprindil on läbi mõeldud res s urss (aeg, inimene, raha). Tellija võib kokkuleppel täitjaga sprindi jooksul töid asendada või katkestada. Täitja kohustub sealjuures tellijat teavitama asendamise või katkestamisega seotud tagajärgedest eelarvele ja tähtaegadest kinni pidamisele. Ülesannete täitmine käib vastavalt tellija ja täitja koostöös kokku lepitud tegevustele. Lähteülesande koostab tellija koos täitja tiimiliikmega ning see edastatakse täitja le Jirasse , Confluence’i või muul digitaalsel kirjalikul kandjal (kokkuleppel tellijaga). Lähteülesanded ( story -d ja epicud ) arendustiimile koostab projektijuht, analüütik või mõni muu pakkuja tiimi liige koostöös tellijaga. Iga uue tellimuse kvaliteedi- ja edumõõdikud (vajadusel) ning teostamise ajaraam lepitakse tellija ja täitja vahel kokku enne tööde alustamist. Planeeritud tööde prioriteeti võib tellija vastavalt vajadusele muuta. Tellija vaatab töö üle ja võtab selle vastu või lükkab põhjendatult tagasi mõistliku tähtaja jooksul (täpne tähtaeg lepitakse kokku koostöös arendajaga). Loodav lahendus peab läbima järgmised etapid, kui tellija vajadusel viitab sellele: v ajaduste ja olukorra kaardistamine (ärianalüüsi ja teenusedisaini kombineerides) ; l ahenduse eesmärgi, kasutajaskonna ja funktsionaalsuse kirjeldamine koostöös tellijaga või tellija esindajaga. K asutaja vajaduste kaardistamine, persoonade formuleerimine; klienditeekonna kaardistamine, klienditeekonna puudulike kohtade väljaselgitamine , lahenduste ideede genereerimine ja süstematiseerimine; tellimuse kirjeldamine sobivas detailsusastmes koostöös tellijaga, tellija poolt antava sisendi põhjal, et alustada disainitööga. v iimistletud prototüübi loomine – kasutajakogemuse loogika disain, testimine kliendiga , kontseptsiooni kohandamine vastavalt valideerimise tulemustele; U X disain, UI disaini valideerimine ja testimine kasutajatega , muudatuste sisseviimine vastavalt testi tulemustele; kasutajatestide tulemuste analüüs ning kokkulepitud paranduste sisseviimine funktsionaalsuste kirjeldusse ; t ehniline analüüs ja sobivate tehnoloogiate leidmine; kujunduse või muu tellija poolt antud sisenddokumendi põhjal koostöös tellijaga täitjale sobivas detailsuses sisenddokumentatsiooni koostamine (mis salvestatakse osana rakenduse dokumentatsioonist ja mis kirjeldab kogu rakenduse funktsionaalsust)– sh sisendi kasutuslugudeks lahti kirjutamine ning arendusmeeskonnale sobivasse keelde ning formaati toimetamine. a rendustöö alustamine ärianalüüsi ja spetsifikatsiooni alusel ; t estimine ja kvaliteedi tagamine – loodava lahenduse test, vigade leidmise korral kirjeldatakse vajalikud tööd teostaja poolt tööde tellimise keskkonda (nt JIRA) järgmisteks tööülesanneteks meeskonnale; t ellija poolt tööde testimine prelive keskkonnad – vajadusel sisuliste muudatuste sisseviimine; a rendusetapi vastuvõtt – töö üleandmine toimub etappides vastavalt – 1 loogiliselt kasutatav osa (tükk) haaval. RHAD lisa 1a. Nõuded raamlepingut täitvatele spetsialistidele Pakkuja peab tagama teenuse osutamiseks meeskonna. Pakkuja meeskonnas peavad olema esindatud vähemalt järgmised rollid: IT projektijuht, kelle peamise ks ülesande ks on vastutada kõigi hanke tulemite tarne eest : infosüsteemi hooldus ja majutus , infosüsteemi arendus, UX ja UI tööd . J älgida ja parendada meeskonna tööprotsesse arvestades ka tellijapoolseid ettepanekuid ning võimekust nii turismiinfosüsteemi tellimuste ja projektide täitmisel ning pakkuda välja muudatusi nii meeskonnatöös kui koostöös täitja meeskonna ja tellija vahel. Samuti jälgida kokkulepitud tellimuste õigeaegset täitmist ning teavitada tellijat võimalikest takistustest ja tähtaegade viibimisest esimesel võimalusel. Samuti raporteerida tellijale igakuiselt meeskonna töötunde, mille alusel pärast tellija kinnituse saamist arve esitatakse. Äria nalüütik , kelle peamis ed ülesand e d on turismiinfosüsteemi ärivajadust e, äriprotsesside a nalüüs, arendusteks vajalike protsesside kirjeldamine, äriarenduseks vajaliku dokumentatsiooni loomine ja haldamine. Lisaks on äri analüütiku ülesande ks koostada olemasolevate või planeeritavate rakenduste dokumentatsioon, sh . detailne kirjeldus kõikide funktsionaalsuste ootuspärasest ja korrektsest toimimisest, kasutuslood, ning funktsionaalsed ning mittefunktsionaalsed nõuded. Ärianalüütik peab: 1 .2.1.1. olema viimase 36 kuu jooksul (riigihanke algamisest tagasiulatuvalt) teostanud ärianalüütikuna vähemalt 2 ärianalüüsi tarkvaraarenduse projekti, mille s mõlemas oli ärianalüütiku töömaht vähemalt 500 töötundi . Pakkuja esitab tingimuste täitmise tõendamiseks RHAD lisa 3 vormil „CV – ärianalüütik“ andmed meeskonnaliikme kompetentsuse kohta, mis võimaldavad hankijal kontrollida isiku vastavust esitatud tingimustele. Süsteemianalüütik , kelle peamis ed ülesande d on turismiinfosüsteemi tehniline a nalüüs, arendusteks vajalike protsesside kirjeldamine, tehnilise dokumentatsiooni loomine ja haldamine. Süsteemia nalüütik e sitab tarkvaraarendajatele täpse kirjelduse, kuidas soovitut saavutada. Süsteemi analüütik peab: 1 .3.1.1. olema viimase 36 kuu jooksul (riigihanke algamisest tagasiulatuvalt) teostanud süsteemia nalüütikuna vähemalt 2 tarkvaraarenduse a nalüüsi projekti, mille töömaht oli vähemalt 500 töötundi. Pakkuja esitab tingimuste täitmise tõendamiseks RHAD lisa 3 vormil „CV – süsteemi ärianalüütik“ andmed meeskonnaliikme kompetentsuse kohta, mis võimaldavad hankijal kontrollida isiku vastavust esitatud tingimustele. Süsteemiarhitekt , kelle peamise ks ülesande ks on koostada plaan, milliseid tarkvaralisi lahendusi, platvorme või muid tehnoloogilisi abivahendeid arendusmeeskond turismiinfosüsteemi arendamisel kasutab. Arhitekt vastutab lahenduste tervikuna toimimise ning valitud arendusvahendite ning platvormide otstarbeka kasutamise eest. Arhitekti ülesanne on tagada loodud arhitektuuri jätkusuutlikkus (kokkuleppel tellija ga) pidevalt suunates arendusmeeskonna aega arhitektuuri parendamisse. Arhitekt vastutab, et arendustegevuse keerukus muutuks ajas võimalikult aeglaselt. Arhitekti kohustuste hulka kuulub tellija nõustamine turismiinfosüsteemi arhitektuuri arendamisel ja välja töötamisel, sh. omal initsiatiivil kitsaskohtade välja toomine. Arhitekt pakub vajadusel tuge olemasoleva turismiinfosüsteemi arhitektuuriga seotud teemade s . Süsteemiarhitekt peab: 1 .4.1.1. ol ema o salenud arhitekt/juhtiv-arendajana projektis/projektides, kus kokku on kasutatud kõiki nimetatud tehnoloogiad : Arendusplatvorm: Java OpenJDK; Rakenduse põhiraamistik: Spring Framework; Mikroteenuse rakendusplatvorm: SpringBoot; Andmebaas : PostgreSQL, PostGIS, Amazon AWS ; Kasutajaliides e raamistik : Angular, Next.js; Täistekstotsingu platvorm: SOLR; Kaardirakendus: Google Maps Platform või samaväärne GIS-teenus . 1 .4.1. 2 . olema viimase 24 kuu jooksul (riigihanke algamisest tagasiulatuvalt) osalenud arhitekt/juhtiv-arendajana projektis/projektides, kus veebirakendus on majutatud AmazonWeb Services (AWS) (või samaväärsesse) . Pakkuja esitab tingimuste täitmise tõendamiseks RHAD lisa 3 vormil „CV – Süsteemiarhitekt “ andmed meeskonnaliikme kompetentsuse kohta, mis võimaldavad hankijal kontrollida isiku vastavust esitatud tingimustele. Testija , kelle peamise ks ülesande ks on tagada arendatud tarkvaralahenduste nõuetekohane toimimine nii manuaal- kui automaattestide läbiviimise tulemusena enne lahenduste kasutajale kätte saadavaks tegemist. Testija vastutab testide planeerimise ja läbiviimise eest ning testide tulemusena ilmsiks tulnud vigade kirjeldamise eest arendusmeeskonnale . Tarkvara kvaliteedi spetsialist (QA), kelle peamise ks ülesande ks on turismi - infosüsteemi kvaliteedi tagamine läbi testimisstrateegia planeerimise, arendamine ning osapooltega kokku leppimise; läbistrateegiale tuginevate kvaliteediprotsesside disainimise, realiseerimise ja ellu viimise. Tarkvara kvaliteedi spetsialist peab : olema viimase 36 kuu jooksul (riigihanke algamisest tagasiulatuvalt) osalenud tarkvara kvaliteedi spetsialistina (QA) vähemalt ühes projektis, milles tema töömaht oli vähemalt 160 töötundi. Pakkuja esitab tingimuste täitmise tõendamiseks RHAD lisa 3 vormil „CV – Tarkvara kvaliteedi spetsialist “ andmed meeskonnaliikmete kompetentsuse kohta, mis võimaldavad hankijal kontrollida isiku vastavust esitatud tingimustele. Vähemalt 2 programmeerijat , kelle peamis teks ülesan neteks on programmeerida turismiinfosüsteemi arendamiseks vajalikke lahendusi. Samuti tegeleb programmeerija ilmnevate vigade parandamisega. Programmeerija vastutab turismiinfosüsteemide arenduste teostamise ja kvaliteedi eest. Vajadusel koostab programmeerija ka tehnilist dokumentatsiooni ja teostab code review -d . Programm e erijate vahel peavad olema täidetud järgmised oskused/kogemused (st programmeerijate lõikes kokku): olema viimase 36 kuu jooksul (riigihanke algatamisest tagasiulatuvalt) teostanud veebis ligipääsetavusega seotud töid vastavalt WCAG 2.1 AA nõutele https://www.w3.org/TR/WCAG21/ ; omama kogemust AmazonWeb Services (AWS) (või samaväärse) teenustega. omama veebilehtede Front-end programmeerijana kogemust semantic HTML või Angular ja Next .js; omama kogemust relatsiooniliste andmebaaside ga ; omama kogemust arendusplatvormiga Java OpenJDK ; omama kogemust Spring Framework või samaväärne rakendusraamistikuga; omama kogemust m ikroteenuse rakendusplatvormiga SpringBoot või samaväärne ; omama kogemust turvalise logimise meetodi SSO tüüpi sisselogimise lahenduste kasutamisel ja loomisel; o mama kogemust kaardirakendusplatvormidega Google Maps Platform või samaväärne . omama kogemust platvormidega, kus on teostatud otsingumootorile optimeerimise (SEO) töid. Pakkuja esitab tingimuste täitmise tõendamiseks RHAD lisa 3 vormil „CV – programmeerija“ andmed meeskonnaliikmete kompetentsuse kohta, mis võimaldavad hankijal kontrollida isiku vastavust esitatud tingimustele. Süsteemiadministraator, kelle peamise ks ülesande ks on tagada turismiinfosüsteemi töökindlus vastavalt kokku lepitud teenus e tasemele . Lisaks vastutab süsteemiadministraator andmete ja lahenduse varundamise , taristu komponentide ajakohastamise, vajalike turvapaikade paigaldamise ning koostöös süsteemiarhitektiga pilvetaristu ressursikasutuse optimeerimise eest. Süsteemiadministraator peab: olema viimase 24 kuu jooksul (riigihanke algamisest tagasiulatuvalt) osalenud süsteemi administraatorina projektis/projektides, kus veebirakendus on majutatud AmazonWeb Services (AWS) (või samaväärsesse); olema viimase 24 kuu jooksul (riigihanke algamisest tagasiulatuvalt) osalenud süsteemi administraatorina projektis/projektides, kus on kasutusel relatsiooniline andmebaas: PostgreSQL , PostGIS või samaväärne. Pakkuja esitab tingimuste täitmise tõendamiseks RHAD lisa 3 vormil „CV – süsteemiadministraator “ andmed meeskonnaliikmete kompetentsuse kohta, mis võimaldavad hankijal kontrollida isiku vastavust esitatud tingimustele. Kasutajakogemuse (UX) disainer, kelle peamise ks ülesande ks on kavandada ning illustreerida uute funktsionaalsuste või protsesside toimimist kasutajasõbralikul viisil . Samuti olemasolevate funktsionaalsuste, rakenduste ja protsesside kasutajasõbralikkuse tõstmine ja parendusettepanekute tegemine. Kasutajakogemuse (UX) disainer peab : olema viimase 36 kuu jooksul (riigihanke algamisest tagasiulatuvalt) osalenud kasutajakogemuse (UX) disainerina vähemalt ühes projektis , mille veebirakendus on avaliku kasutajaskonnaga ja koosneb vähemalt kahest kasutajateekonnast . Pakkuja esitab tingimuste täitmise tõendamiseks RHAD lisa 3 vormil "CV - "Kasutajakogemuse (UX) disainer " andmed meeskonnaliikme kompetentsuse kohta, mis võimaldavad hankijal kontrollida isiku vastavust esitatud tingimustele. Kasutajaliidese (UI) disainer , kelle peamise ks ülesande ks on luua UX-disaineri või tellija poolt koostatud lähteülesandele vastavalt kasutajaliidese disain, mis on kooskõlas vastava projekti stiilinõuetega. Vajadusel luua uusi komponente, mis on kooskõlas stiilinõuetega. Samuti hoida ning parendada stiilinõuetes sisalduvaid komponente. Kasutajaliidese (UI) disainer peab: olema viimase 36 kuu jooksul (riigihanke algatamisest tagasiulatuvalt) teostanud veebis ligipääsetavusega seotud töid vastavalt WCAG 2.1 AA nõutele https://www.w3.org/TR/WCAG21 ; olema viimase 36 kuu jooksul (riigihanke algamisest tagasiulatuvalt) osalenud kasutaj aliidese (U I ) disainerina vähemalt ühes projektis , mille veebirakendus on avaliku kasutajaskonnaga ja koosneb vähemalt kahest kasutajateekonnast. Pakkuja esitab tingimuste täitmise tõendamiseks RHAD lisa 3 vormil "CV - "Kasutajaliidese (UI) disainer " andmed meeskonnaliikme kompetentsuse kohta, mis võimaldavad hankijal kontrollida isiku vastavust esitatud tingimustele. Kasutajakogemuse (UX) disaineri ja kasutajaliidese (UI) disaineri rolli võib täita üks isik. Mitut rolli täitev töötaja peab sellisel juhul vastama tema poolt täidetavate kõikide rollide tingimustele. Äria nalüütiku ja süsteemianalüütikurolli võib täita üks isik. Mitut rolli täitev töötaja peab sellisel juhul vastama tema poolt täidetavate kõikide rollide tingimustele. Testija ja t arkvara kvaliteedi spetsialist i (QA) rolli võib täita üks isik. Mitut rolli täitev töötaja peab sellisel juhul vastama tema poolt täidetavate kõikide rollide tingimustele. Meeskonnaga peab olema tagatud suhtlemine eesti keeles ja/või inglise keeles vähemalt tasemel B2. Teised meeskonnaliikmed ei tohi mitut rolli täita . Meeskonnaliikmeid on õigus vahetada või lisada ainult pärast raamlepingu sõlmimist tingimusel, et hankija on andnud eelneva nõusoleku kirjalikku taasesitamist võimaldavas vormis ja meeskonnaliige asendatakse vähemalt samaväärse kompetentsiga vastavalt RHAD l isa 1 b punktidele 1 . 1 ja 1.10 . Meeskonnaliikme kogemuse ajalist perioodi arvestatakse sel juhul hankijale vastava soovi esitamise hetkest tagasiulatuvalt. RHAD lisa 1 b . Nõuded pakkumuses esitatavale proovitööle Proovitöö kirjeldus: Taust. Paljude välisturistide poolt on üks populaarsemaid küsimusi, et kuhu Eestis rattaga saaks minna, millised on Eestis rattamarsruudid ning kust neid digitaalsel kujul leiab. Ka siseturistide hulgas on rattamatkad väga levinud puhkamisviis, sest eestlasele meeldib omal käel matkata. Kuni 2021. aastani olid ametlikud rattamatkateed leitavad ainult paberkujul Regio paberkaartidel . 2021. aasta suvel läks live’i arendus visitestonia.com kaardirakendus es, kus olid kuvatud rattamatkateed digitaalsel kujul koos muu turistile huvipakkuva infoga. Ekraani kuvatõmmised vanast kaardirakendusest koos rattamatkateedega on toodud proovitöö viimasel leheküljel. Vana rattamatkateede kaardilahendus on loodud tolle aja parimast teadmisest ja infosüsteemi võimalustest lähtuvalt ning praegu ei täida enam sellisel kujul oma eesmärki ja vajab ümberdisaini ( redesign ). Turismiinfosüsteem koos avaliku visitestonia.com veebirakendusega on läbinud uuenduskuuri ning on live’s alates 2024 mai, sh uuenes veebirakenduse kaart . Rattamatkateede lisamine kaardile on üks järgmistest TIS tööetappidest. Eestis on kokku 70 ametlikku rattamatkateed jalgratastega turvaliseks läbimiseks kogupikkusega üle 6500 kilomeetri. Rattamatkateid on igale suutlikkusele ja maitsele, alates kümne ja lõpetades rohkem kui tuhande kilomeetri pikkuse rattamatkateega. Kaetud on kõik maakonnad, põnevaid radu leiab kõikjal Eestis, et minna tutvuma Eesti loodusega, linnadega, saartel või kuppelmaastikul. Lisaks on mitmeid rattamatkateid, sh Eurovelo teid (nr 10, 11 ja 13), mis ühendavad Eestit ülejäänud Euroopaga. Ekraanikuvatõmmised 2021. a visitestonia.com veebirakendusest Ekraanikuvatõmmised 2021. aastal loodud visitestonia.com veebirakenduse kaardist, millel on kuvatud rattamatkateed Rattamatkateede üldvaade (kuvatud on 3 rattateed) Rattamatkateede kohta info vaatamise võimalus Rattamatkateede kohta info vaatamise võimalus Rattamatkateede valimine ja filtreerimine kaardi kategooriamenüüst Kasutaja. Proovitöö ülesandes on rattamatkateede kaardi kasutajaks reisi planeeriv, mõtteid ja inspiratsiooni otsiv potentsiaalne Eestit külastav välisturist , kes peamiselt tunneb huvi Eestis rattaga matkamise võimaluste vastu. Kasutaja on jõudnud visitestonia.com kaardirakendusse, kus on talle kuvatud Eesti rattamatkateede üldvaade . Kasutaja valib ja vaatab erinevaid rattamatkateid ning nende infot. Kasutaja otsib talle huvipakkuvas piirkonnas rattamatkateid. Kasutaja leiab huvipakkuva rattamatkatee ja vaatab selle kohta lisatud infot. Kasutajale pakub huvi, mida rattamatkateel olles veel näha ja kogeda saab. Proovitöö eesmärk. Proovitöö eesmärk on hinnata pakkuja oskust kasutada Figma disainiprogrammi, oskust luua mockup’e , oskust kasutada etteantud stiiliraamatut ja UI kit’i , arusaamist üldisest veebidisainist, arusaamist WCAG 2.2 AA taseme nõuetest nii palju kui ülesanne seda võimaldab, oskust mõelda kaasa tellija poolt antud ülesandele, oskust pakkuda tellijale prototüüplahendusi, mis on lõppkasutajale kasutajamugavad ja intuitiivsed, oskust mõelda kastist välja, oskust näha ja pakkuda lisavõimalusi lahenduse paremaks muutmiseks. Pakkuja ülesanne ehk nõuded proovitööle : luua Figma disainiprogrammi keskkonda vähemalt 4 mockup vaadet kohaldatuna mobiilivaatele visitestonia.com rattamatkateede kaardile. Pakku mus peab sisaldama veebilin k i Figma disainiprogrammi vaataja õigustega. kasutada mock up’de loomisel visitestonia.com kaardirakenduse UI komponente, mis on kättesaadavad Brand Estonia stiiliraamatusse loodud proovitöö projektist Figma keskkonnas . Pakkuja edastab Tellijale veebilingi Figma disainiprogrammi vaataja õigustega. RHAD LISA 2. RAAMLEPING Ettevõtluse ja Innovatsiooni Sihtasutus , registrikood 90006012 , aadressiga Sepise 7, 11415 Tallinn, mida esindab … (edaspidi hankija või tellija ), ja ___, registrikood ___, aadress ___, mida esindab ___ (edaspidi pakkuja või täitja ), edaspidi eraldi nimetatud ka kui pool ja mõlemad koos kui pooled , sõlmivad riigihanke “ Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutus teenus ” (tellija hankenumbriga 240093 ja riigihangete registri viitenumbriga 280554) tulemustest (edaspidi riigihange) lähtuvalt käesoleva raamlepingu (edaspidi ka leping) alljärgnevas: LEPINGU DOKUMENDID JA LEPINGU TÕLGENDAMINE Lepingu dokumendid koosnevad käesolevast lepingust, lepingu lisadest ning lepingu muudatustest ja kokkulepetest, milles lepitakse kokku pärast lepingu sõlmimist. Lepingul on selle sõlmimise ajal järgmised lisad: Lisa nr 1 – tellija RHAD; Lisa nr 2 – täitja esitatud pakkumus (edaspidi pakkumus); Lisa nr 3 – raam leping; Lisa nr 4 – andmetöötluse leping. Juhul, kui punktis REF _Ref137975894 \r \h \* MERGEFORMAT 1.2 nimetatud dokumentides toodud sätted on omavahel vastuolus või kui esineb vastuolu nimetatud dokumentidest tulenevate sätete ja muude lepinguga seonduvate õigusaktide või dokumentide vahel, lähtuvad pooled alljärgnevalt esitatud tähtsuse järjekorrast: RHAD; pakkumus; leping . Kõik punktis REF _Ref137980682 \r \h \* MERGEFORMAT 1.3 nimetatud dokumendid täiendavad üksteist ning täitja kohustub täitma kõiki nimetatud dokumentidest ja õigusaktidest tulenevaid kohustusi ning nõudeid. Lisaks on täitja kohustatud täitma mis tahes muid lepingus nimetamata kohustusi ning teostama mis tahes muid lepingus nimetamata toiminguid, mis on vajalikud lepingus nimetatud eesmärgi saavutamiseks, v.a kui taolised kohustused ja toimingud toovad täitjale kaasa täiendavaid olulisi kulutusi. Lepingus on pealkirju kasutatud ainult viitamise lihtsustamiseks ning need ei piira ega mõjuta mingil viisil lepingu sätete tähendust ega tõlgendamist. Lepingus viitavad ainsuses toodud sõnad ka mitmusele ja vastupidi, kui kontekstist ei tulene teisiti. Lepingus kasutatud mõistete ja terminite sisustamisel lähtutakse RHADis ja pakkumuses esitatust. LEPINGU ESE Lepingu esemeks on Visit Estonia turismiinfosüsteemi (edaspidi ka TIS) arendus-, majutus- ja hooldustööd (edaspidi töö) vastavalt RHADis ja selle lisades ning käesolevas lepingus ja selle lisades toodud tingimustel. Leping jõustub alates poolte allkirjastamisest ja kehtib kuni 48 kalendrikuud alates raamlepingu sõlmimisest või kuni punktis 7.1 toodud maksimaalse rahalise mahu saavutamiseni, sõltuvalt sellest, kumb tingimus saabub varem. Tellija vajaduste muutudes on võimalik leping lõpetada enne maksimaalse perioodi või maksimaalse mahu täitumis t, lepingus nimetatud etteteatamise tähtajaga. Hankelepingute kehtivus ei ole piiratud raamlepingu kehtivuse lõpptähtpäevaga ning võib olla kuni 12 kuud pikem lepingu täitmise tähtaja lõppemisest. Lepingu lõppemine ei mõjuta selliste kohustuste täitmist, mis oma olemuse tõttu kehtivad ka pärast lepingu lõppemist (nt konfidentsiaalsuskohustus). TÄITJA ÕIGUSED JA KOHUSTUSED Täitjal on õigus: saada tellijalt tööde teostamiseks vajalikku informatsiooni ja juhiseid; saada tellijalt kohaselt teostatud tööde eest tasu vastavalt lepingus sätestatule. Täitja kohustub: tööde elluviimiseks tegema koostööd tellijaga ja kõikide vajalike osapooltega, sh tellija koostööpartneritega. Tellijal on õigus nõuda täitja meeskonnaliikme väljavahetamist, kui koostöö tellija ja/või koostööpartneri(te) ga on problemaatiline või ei vasta ootustele; teostama töö õigeaegselt ja kvaliteetselt vastavalt RHADis ja selle lisades toodule. RHADis määratlemata omaduste osas peab töö olema vähemalt keskmise kvaliteediga ja vastama sarnastele töödele tavaliselt esitatavatele nõuetele; tegema töö käigus kõik tööd ja toimingud, mis ei ole RHADis sätestatud, kuid mis oma olemuselt kuuluvad töö teostamisega seotud tööde hulka; tagama isikuandmete kaitse vastavalt õigusaktides sätestatud tingimustele ja vastavalt andmetöötluse lepingus sätestatule; tagama lepingu täitmisel RHADis nõutud ja pakkumuses esitatud projektimeeskonna ning vajadusel sinna kuuluvate isikute väljavahetamise samaväärset kompetentsi omavate isikutega, kooskõlastades tellijaga selle eelnevalt kirjalikku taasesitamist võimaldavas vormis; arvestama töö käigus tellija antud juhiste ja tehtud märkustega ning kõrvaldama tellija nõudmisel töös esinevad puudused tellija määratud tähtpäevaks; informeerima viivitamatult tellija esindajat/esindajaid e-posti teel töö teostamist takistavatest asjaoludest, samuti sellest, kui täitja soovib kõrvale kalduda tellija poolt lepingu täitmiseks antud juhisest ning asjaoludest, mis võivad ajendada tellijat seda juhist muutma; kontrollima tellija juhiste sobivust ning mittesobivusel viivitamata teavitama sellest tellijat. Mittesobivusest teavitamata jätmisel vastutab täitja osutatud teenuse lepingutingimustele mittevastavuse eest; võtma osa tellija poolt korraldatud nõupidamistest, kui tellija on täitjale sellest vähemalt kolm (3) tööpäeva ette teatanud; esitama tellija nõudmisel koostööpartnerite ja/või alltöövõtjate poolt teostatud teenuste kohta kuludokumentide koopiaid; käituma heas usus, hoidma tellija mainet ning kuvandit, sh vastutama ka oma esindajate ja töötajate poolse vastava kohustuse täitmise eest; hoiduma negatiivsete hinnangute andmisest, tellija mainet riivavate initsieeritud artiklite ja/või info avaldamise taotlemisest meedias tellija igasuguse tegevuse või tegevusetuse kohta ükskõik millises valdkonnas lepingu täitmise perioodil; olema erapooletu ja sõltumatu, taotlema tellija eesmärkide ning huvide võimalikult ulatuslikku saavutamist ja juhinduma lepingus ning selle lisades määratletud eesmärkidest ja tingimustest ; kasutama Euroopa Regionaalarengu Fondi põhist kaksiklogo kõikidel tööga seotud materjalide l, kooskõlas Vabariigi Valitsuse 12.0 5 .20 22 määrusega nr 54 „Perioodi 2021-2027 ühtekuuluvus-ja siseturvalisuspoliitika fondide vahendite andmisest avalikkuse teavitamine “. Vt lisaks Logod ja sümboolika | Riigi Tugiteenuste Keskus (rtk.ee) . Täitja on kohustatud teavitusnõuete järgmisel lähtuma kehtivatest õigusaktidest ja muudetud juhenditest; kasutama kõikidel töö tulemitel, muudel materjalidel jms selgelt välja toodud tellija logo (EASi logo ja CVI on kättesaadav aadressil: https://www.eas.ee/logod/ ). Tellija nimetamata kolmandate isikute logode, visuaalide vms seda eesmärki kandvate elementide lisamine pole lubatud. TELLIJA ÕIGUSED JA KOHUSTUSED Tellijal on õigus: anda täitjale lepingu täitmiseks põhjendatud juhiseid lepingu ulatuses, mida täitja on kohustatud täitma; teostada jooksvat kontrolli tööde käigu ja tööde lepingus sätestatud nõuetele vastavuse üle; nõuda igal ajal informatsiooni lepingu täitmise kohta, mida täitja on kohustatud viivitamatult andma; nõuda töös ilmnevate puuduste kõrvaldamist täitja kulul; nõuda täitjalt koostööpartnerite ja/või alltöövõtjate poolt teostatud teenuste kohta kuludokumentide koopiaid. Tellijal on kohustus: teha täitjaga koostööd lepingu täitmisel; anda täitjale informatsiooni, mis on vajalik lepingu täitmiseks; tasuda täitjale kohaselt teostatud töö eest lepingus sätestatud tasu. TÖÖDE TELLIMINE JA HANKELEPINGUTE SÕLMIMINE Tööde tellimisel lähtutakse RHAD lisa 1 punktis REF _Ref167975820 \r \h \* MERGEFORMAT 7.8 sätestatust . Pakkuja esitab kohase hinnapakkumuse hiljemalt 5 tööpäeva jooksul. Poolte kokkuleppel võivad need tähtajad olla ka pikemad. Hankeleping( ud ) sõlmitakse kirjalikku taasesitamist võimaldavas vormis, nõustumuse andmisega. Tööde teostamisele kohaldatakse lepingus, hinnapäringus ja pakkumuses sätestatut ning õiguste ja kohustuste reguleerimisel lähtuvad pooled lepingus sätestatud tingimustest . Lepingu alusel sõlmitavate hankelepingute puhul peavad hankelepingu tingimused olema tellija jaoks samad või soodsamad, mis lepingus sätestatud (nt peavad töö tunnihindade maksumused olema samad või võivad olla madalamad lepingus sätestatud maksumustest); tellija ei ole kohustatud lepingu alusel hankelepingut(id) sõlmima. TÖÖDE ÜLEANDMINE JA VASTUVÕTMINE Tööde üleandmine- ning vastuvõtmine toimub kirjalikku taasesitamist võimaldavas vormis Jira keskkonna vahendusel. Töö vastuvõtmise kinnitus on arve esitamise aluseks, millel märgitakse Jira kandenumbrid ja töö tegemiseks kulud maht ning töötundide maksumused . Arvel tuleb lisaks märkida hankija sisene hankenumber ja lepingus märgitud kontaktisik Juhul, kui töö vastuvõtmisel on tellijal pretensioone kokku lepitud lepingu tingimustele vastavuse kohta, määrab ta täitjale täiendava tähtaja esinevate puuduste kõrvaldamiseks. Pretensioonid lepingu tingimustele vastavuse kohta märgitakse Jira keskkonnas kirjalikku taasesitamist võimaldavas vormis . Juhul, kui täitja ei kõrvalda puudusi nimetatud tähtajaks, on tellijal õigus alandada poolte vahel kokku lepitud tööde maksumust või nõuda vajalike kulutuste hüvitamist, mis tellija kandis esinenud puuduste parandamisel omade vahenditega ja/või kasutades kolmandaid isikuid. Kui puudused töös ilmnevad pärast seda, kui töö on vastu võetud, kohustub täitja kõrvaldama puudused oma kuludega, vastavalt punktis 9 sätestatule (nn garantiilised tööd). TÖÖDE MAKSUMUS JA ARVELDUSTE KORD Raamlepingu maksimaalne rahaline maht kokku on 3 0 00 000,00 ( kolm miljonit ) eurot käibemaksuta. Tellija ei ole kohustatud töid tellima raamlepingu maksimaalses eeldatavas mahus. Pakkumuses esitatud tarkvara arenduse ja hooldusteenuse ühe töötunni maksumus on ….. eurot käibemaksuta. Tellija tasub täitjale reaalselt ja kohaselt teostatud tööde eest, pärast tööde üleandmist/vastu võtmist, 14 kalendripäeva jooksul, alates vastavasisulise arve saamisest. Kui täitja on e-arvete operaatori klient, tuleb e-arve edastada tellijale oma e-arvete operaatori vahendusel. E-arve loetakse laekunuks selle operaatorile laekumise kuupäevast. Täitja, kes ei ole registreeritud Eestis, saab arve esitada e-arvena üle-Euroopalise elektrooniliste dokumentide ja e-arvelduse võrgustiku PEPPOL kaudu või PDF-vormingus tellija e-posti aadressile [email protected]. Arvel tuleb märkida tellimuses märgitud hankija hankenumber (HNR), riigihangete registri viitenumber ja tellija kontaktisik. Tähtaegselt tasumata arve eest on täitjal õigus nõuda viivist 0,02% ulatuses iga tasumisega viivitatud päeva eest. INTELLEKTUAALNE OMAND Täitja kinnitab lepingu allkirjastamisega, et talle kuuluvad või ta omandab raam - ja hankelepingu(te) täitmiseks kõik vajalikud autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on vajalikud lepingujärgse töö täielikuks teostamiseks ja vastavate õiguste andmiseks tellijale ning nende suhtes ei ole kolmandatel isikutel piiravaid õigusi ega nõudeid. Täitja loovutab tellijale kõik tööde teostamise käigus loodud töö tulemi (sh tarkvara, lähtekood dokumentatsioon, jne) varalised õigused ning annab ainulitsentsi autori isiklikele õigustele koos all-litsentsi andmise õigusega kogu autoriõiguste kehtivuse ajaks ilma geograafiliste piiranguteta. Pooled on kokku leppinud, et lepingule ei kohaldata VÕS § 374. Tellija võib üleantud tulemi autoriõigusi teostada mistahes olemasolevas või hiljem loodud keskkonnas, toel või formaadis. Täitja kinnitab, et on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks viisil, mis ei takista ega raskenda töö tulemi kasutamist ja autori varaliste õiguste teostamist ning tagab, et isiklikud õigused on ilma autori nõusolekuta teostatavad muuhulgas järgmises ulatuses: tellijal või tellija tellimusel kolmandatel isikutel on õigus teha üle antud tulemis muudatusi ning seda täiendada; tellijal või tellija tellimusel kolmandatel isikutel on õigus lisada teosele teiste autorite teoseid; tulemi üleandmisega tellijale kinnitab täitja, et tulem on üldsusele esitamiseks valmis ning autor on loobunud õigusest seda ise avalikustada. Varalised õigused ja litsentsid loetakse tellijale üle läinuks pärast hankelepingute alusel tehtud töö tulemi tellijale üleandmist. Täitja tagab tarkvara litsentsilepinguga kaasnevate litsentseerimistingimuste täitmise ning tagab tellijale vajadusel ligipääsu kaasnevatele õigustele: kasutusõigus, hooldus, versiooniuuendused, turvapaigad, litsentseerimise alane nõustamine ning spetsialistikoolitused. Täitja tagab tellijale kõik vajalikud autoriõigused lepingu täitmise käigus loodava töö tulemi (sh tarkvara, lähtekood dokumentatsioon, jne) kontrollimiseks, testimiseks ning süsteemi paigutamiseks ajaks, kuni tellija ei ole üleandmise-vastuvõtmise aktiga lepingu eset vastu võtnud. Tasu intellektuaalse omandi õiguste (sh autoriõigus) tellijale loovutamise ja litsentside eest sisaldub lepingu maksumuses ning täitjal ei ole õigust nõuda täiendavat tasu nende õiguste üleandmise ega litsentsimise eest. Täitja kohustub lahendama kõikvõimalikud lepingujärgse tööga seotud intellektuaalse omandi (sh autoriõiguse) õigustest tekkivad vaidlused kolmandate isikute või oma töötajate või koostööpartneritega. Juhul, kui eeltoodust tekib tellijale rahaline või muu kohustus või juhul, kui tellija on kohustatud lõpetama vastuvõetud töö tulemi kasutamise, on tellijal õigus nõuda täitjalt selle rahalise või muu kohustuse täitmist ja või samaväärse tulemi loomist tasuta ning võimalikult lühikese aja jooksul, hoidudes mistahes viivitustest tulemi arendamises, kasutuselevõtmises ja kasutamises tellija poolt. Täitja võib kasutada tarkvara arendamisel pakkumuses mittenimetatud tarkvara vaid tellija eelneval kirjalikul nõusolekul. GARANTII Täitja annab üle antud tulemile 6 ( kuue ) kuulise garantii. Garantiiaja kulgemine algab töö tellija poolt vastuvõtmisest (eraldi vastavalt igale Jira kandele). Juhul, kui tööd antakse tellijale üle mitmes etapis, algab garantiiperiood viimase etapi vastuvõtmisest tellija poolt. Garantii hõlmab kõiki garantii tähtaja jooksul ilmnenud tööde ja lepingu tingimustele mittevastavusi, sealhulgas on täitja kohustatud uuendama või asendama kõik mittevastavusi sisaldavad dokumendid. Täitja kõrvaldab garantiiperioodi jooksul kõik ilmnevad puudused oma kulul , välja arvatud juhul, kui puuduste tekkimise eest vastutab tellija. Puuduste kõrvaldamine peab toimuma vastavalt RHAD Lisas 1 punktis 6 kirjeldatud vea prioriteetidele. Kui t äitja ei suuda v igu kokkulepitud tähtajaks kõrvaldada, võib t ellija korraldada v igade kõrvaldamise kolmanda isiku abil, teavitades sellest eelnevalt t äitjat. Tellijal on õigus nõuda, et t äitja katab mõistlikud kulud, mis tekkisid seoses kolmanda isiku kaasamisega v ea kõrvaldamisse juhul, kui t ellija tõendab, et tegemist oli garantiiga hõlmatud v eaga. Kolmanda isiku poolt tehtud koodimuudatuste garantiikohustus lasub nimetatud kolmandal isikul, v.a juhul kui p ooled on kokku leppinud teisiti. Garantii ei välista ega piira tellija õigust kasutada muid seadusest ja lepingust tulenevaid õiguskaitsevahendeid. LEPINGU JA SELLE ALUSEL SÕLMITAVATE HANKELEPINGUTE ÜLESÜTLEMINE Tellijal on õigus leping ja hankeleping igal ajal ilma etteteatamise tähtajata üles öelda, kui: ilmneb, et täitja on esitanud (hinna)pakkumuses (sh selle lisades) või lepingus/hankelepingus tegelikkusele mittevastavaid andmeid; täitja ei vasta töö teostamisega seotud valdkonnas õigusaktidega ettenähtud nõuetele või tema majanduslik seisund või kompetentsus ei vasta töö teostamiseks vajalikele tingimustele; täitja suhtes algatatakse pankroti- või likvideerimismenetlus või tema majandustegevus on mis tahes põhjusel peatatud või takistatud; täitja on rikkunud lepingust, hankelepingust või seadusest tulenevat kohustust ega ole kõrvaldanud rikkumist tellija poolt antud täiendava tähtaja jooksul või on vaatamata tellija märkusele teistkordselt rikkunud mis tahes lepingu või hankelepingu tingimust. täitja ei ole esitanud tellijale raamlepingu kehtivuse perioodil tähtaegset hinnapakkumust kokku kolmel korral; täitjapoolne kohustuse rikkumine annab tellijale mõistliku põhjuse eeldada, et täitja ei täida kohustusi ka edaspidi; lepinguliste tegevuste elluviimine/kohustuste täitmine on muutunud võimatuks tellijast mitteolenevatel põhjustel . Täitjal on õigus leping ja hankeleping igal ajal ilma etteteatamise tähtajata üles öelda, kui: lepingust tulenevate täitja kohustuste täitmine on muutunud võimatuks tellija süül (st lepingu korduval rikkumisel tellija poolt); tellija on põhjendamatult viivitanud lepingujärgsete maksete tasumisega rohkem kui 40 (nelikümmend) kalendripäeva. Lepingujärgsete maksete tasumisega viivitamist ei loeta põhjendamatuks, kui tellija on asunud rakendama lepingu punktis 10.4 sätestatud leppetrahvi tasaarveldust. Tellija vajaduste muutudes (sh muudatused tellija tegevuseesmärkides, eelarves vms, millest tulenevalt on välistatud või ei ole otstarbekas lepinguga jätkamine ), on tellijal õigus leping üles öelda enne maksimaalse perioodi või maksimaalse mahu täitumist 60 päevase etteteatamise tähtajaga. Täitjal puudub õigus nõuda tellijalt lepingu ennetähtaegse lõpetamise korral kahju hüvitamist. Lepingu ennetähtaegsel lõpetamisel on täitjal õigus saada tasu faktiliselt ja kohaselt teostatud töö eest. Täitjal ei ole õigust tasule, kui tellija on lepingu üles öelnud täitja poolt lepingu olulise rikkumise tõttu. Lepingu ülesütlemisel täitja rikkumise tõttu on täitja kohustatud hüvitama tellijale kõik tema poolt seoses lepingu ülesütlemisega kantud kahjud. VASTUTUS Tellijal on õigus nõuda täitjalt leppetrahvi: kuni 10% hanke lepingu kogumaksumusest kui täitja on lepingut oluliselt või korduvalt rikkunud. Poole rahaline koguvastutus käesoleva lepingu täitmisest tekkivate nõuete eest kokku ei tohi ületada lepingu kogumaksumust, v.a. tahtliku rikkumise korral. Poole rahaline koguvastutus hankelepingu täitmisest tekkivate nõuete eest kokku ei tohi ületada konkreetse hankelepingu maksumust, v.a. tahtliku rikkumise korral. Lepingulise kohustuse oluliseks rikkumiseks loetakse muuhulgas, kuid mitte ainult, järgnevat: kokkulepitud tingimustele mittevastava töö teostamist või teostamata jätmist, kokkulepitud kvaliteedinõuetest või tähtaegadest mitte kinni pidamist. Lepingu korduvaks rikkumiseks peetakse nõuetele mittevastava töö teostamist vähemalt kahel korral; kuni 5% hankelepingu maksumusest kui täitja rikub kohustust asendada meeskonnaliige samaväärsega või kui täitja ei tõenda tellijale uue meeskonnaliikme samaväärsust pakkumuses esitatud meeskonnaliikmega (ehk asendamine mittesamaväärse isikuga); leppetrahvi võib nõuda iga isiku asendamise eest mittesamaväärse isikuga; leppetrahvi võib nõuda kui täitja ei suuda meeskonnaliiget asendada mõistliku aja jooksul. Mõistliku aja lepivad pooled kokku jooksvalt; kuni 5 000 ( viis tuhat) eurot iga lepingu konfidentsiaalsuskohustuse rikkumise eest. kuni 5000 (viis tuhat) eurot igakordse rikkumise korral, kui täitja rikub lepingu punktides 3.2. 10 - 3.2.1 2 nimetatud kohustust või tekitab muul viisil tellijale mainekahju. Tellijal on õigus leppetrahvi summa tasaarvestada vastavas ulatuses hankelepingus kokku lepitud ja täitja poolt esitatud arve alusel täitjale tasumisele kuuluvast summast. Leppetrahv on kokkulepitud kohustuse täitmise tagamiseks, mitte kohustuse täitmise asendamiseks. Lepingust tuleneva kohustuse täitmisega või õiguse kasutamisega viivitamine ei tähenda vabastust vastavast kohustusest ega loobumist vastavast õigusest ning samuti ei välista ühegi kohustuse eraldi või osaline täitmine või ühegi õiguse eraldi või osaline kasutamine vastava kohustuse täitmist või vastava õiguse kasutamist tulevikus, kui lepingust ei tulene teisiti. Kui täitja ei täida lepinguga võetud kohustusi, ei paranda puudustega tööd või ei teosta uut tööd ja täitja viivitust saab lugeda oluliseks lepingurikkumiseks, on tellijal õigus tellida mittetäidetud või mittenõuetekohaselt täidetud mahus teostatud tööd kolmandatelt isikutelt ning nõuda lisaks leppetrahvile kolmandatelt isikutelt tellitud töödele kulunud summa ning lepingu hinna vahe hüvitamist täitja poolt. ALLTÖÖVÕTT Täitja võib kasutada hankelepingu alusel tehtavate tööde teostamiseks alltöövõtjaid, ulatuses milles see pole vastuolus riigihanke tingimustega või mida täitja peab täitma iseseisvalt. Alltöövõtust tulenevad kohustused ja vastutus lasub täies mahus täitjal ja ei ole aluseks lepingu tingimuste muutmisele. Täitja vastutab täielikult lepingu ja hankelepingu täitmisesse kaasatud alltöövõtjate poolt tellijale tehtava töö lepingu eesmärgipärase ja kohase täitmise eest. Vastavalt punktile 4.1.5 on tellijal õigus lepingupartnerilt küsida alltöövõtjate poolt teostatud teenuste kohta kuludokumentide koopiaid. Täitja esitab lepingu täitmisel iga oma alltöövõtja, kellega sõlmitud alltöövõtulepingu käibemaksuta maksumus ületab 50 000 eurot, alltöövõtja nime ja registrikoodi ning alltöövõtulepingu nimetuse, kuupäeva, numbri ja summa. VÄÄRAMATU JÕUD Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta lepingu või selle lisade rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Vääramatuks jõuks loevad pooled võlaõigusseaduse § 103 lg 2 kirjeldatud ettenägematuid olukordi ja sündmusi, mis ei olene nende tahtest või mille saabumist pooled lepingu või selle lisade sõlmimisel ette ei võinud näha. Pool, kelle tegevus lepingujärgsete kohustuste täitmisel on takistatud vääramatu jõu tõttu, on kohustatud sellest teist poolt koheselt kirjalikult teavitama ning täitma oma kohustused vääramatu jõu lõppemisel. Vääramatu jõu asjaolude esinemisel pikenevad lepingust tulenevad tähtajad vääramatu jõu asjaolude esinemise perioodi võrra. Kui vääramatu jõu asjaolud kestavad enam kui 2 (kahe) kalendrikuu jooksul, on tellijal õigus leping erakorraliselt üles öelda. Sellisel juhul ei ole kummalgi poolel õigus nõuda teiselt poolelt lepingu mittetäitmise või mittekohase täitmisega tekitatud kahju hüvitamist. POOLTE KONTAKTISIKUD JA TEADETE EDASTAMINE Kõik õigusliku tähendusega teated ja muu informatsioon loetakse nõuetekohaselt edastatuks, kui see on lepingu kontaktisikule edastatud e-posti teel. Informatsioonilise sisuga teadet võib edastada ka telefoni teel. Poolte kontaktisikud ning -andmed seoses lepingu täitmisega on järgmised: 14.2.1. Tellija lepingu kontaktisik( ud ) on: …., e-post: ….. tel:....... 14.2.2. Täitja lepingu kontaktisik( ud ) on: ….., e-post: ….. tel:....... Punktis 14.2. nimetatud tellija kontaktisiku töökohustustest eemal viibimisel (puhkus, lähetus, haigus jmt), on samad õigused kontaktisiku asendajal. Tellija kontaktisiku pädevuses on kontrolli korraldamine lepingu täitmise tingimuste ja ajakava üle, viivitustest ja muudatustest teise poole teavitamine, tööde tellija nimel vastuvõtmine, üleandmise-vastuvõtmise aktide kinnitamine ja pretensioonide esitamine. Tellija kontaktisikul on õigus jooksvalt kontrollida töö tulemite vastavust lepingule ning töö käigus teostatavate tegevuste vastavust. Kontaktandmete muutusest on pool kohustatud viivitamatult informeerima teist poolt ja sellist muudatust ei käsitleta lepingu muudatusena. Kuni kontaktandmete muutusest teavitamiseni loetakse teade nõuetekohaselt edastatuks, kui see on saadetud poolele lepingus sätestatud kontaktandmetel. KONFIDENTSIAALSUS Täitja kohustub hoidma salajas talle seoses lepingu täitmisega teatavaks saanud konfidentsiaalset teavet. Konfidentsiaalseks teabeks loetakse informatsiooni, mis lepingu alusel sai täitjale teatavaks ja mis ei ole avaldatud ega kuulu avaldamisele kolmandatele isikutele seaduse või lepingu alusel. Konfidentsiaalsuskohustuse rikkumiseks ei loeta informatsiooni edastamist poole õigusnõustaja(te) le , audiitori(te) le ja raamatupidaja(te) le , välja arvatud juhul kui teave edastatakse vastavatele isikutele eesmärgiga, et informatsioon jõuaks vastavate isikute kaudu kolmandate isikuteni. Konfidentsiaalne ei ole teave, mis on üldiselt teada või mis on üldsusele või poolele õiguspäraselt kättesaadav avalikest teabeallikatest, samuti teave, mille avalikustamiseks on avaldav pool andnud nõusoleku või mille avalikustamise kohustus tuleneb õigusaktidest, tingimusel, et selline avaldamine viiakse läbi võimalikest variantidest kõige piiratumal viisil. Täitja kohustub tagama, et isikud, keda ta teenuse osutamisel kasutab, oleksid teadlikud lepingus sätestatud konfidentsiaalsuse kohustusest ning nõudma nimetatud isikutelt selle kohustuse tingimusteta ja lepingu punktis 1 5 .4 nimetatud tähtaja aja jooksul täitmist. Vastutus konfidentsiaalsuskohustuste täitmise eest lasub täitjal. Täitjal on kohustus hoida konfidentsiaalsust kogu lepingu kehtimise aja ja ka 10 (kümne) 5 (viie) järgneva aasta jooksul olenemata lepingu lõpetamise põhjustest. Konfidentsiaalsuskohustuse rikkumise korral on tellijal õigus nõuda punktis 15 .4 toodud ajavahemiku jooksul täitjalt leppetrahvi vastavalt lepingus sätestatud tingimustele (lepingu punkt 1 1 .1. 3 ), esitades leppetrahvi tasumiseks kirjaliku ja põhistatud nõude ning nõuda konfidentsiaalsuskohustuse igakordse rikkumise tulemusena tekkinud otsese varalise kahju (sh tellija mõistlikud õigusabikulud seoses konfidentsiaalsuskohustuse rikkumise tuvastamise ja menetlemisega ja tellija poolt kolmandatele isikutele makstud leppetrahvid ja kahjuhüvitised) hüvitamist osas, mida leppetrahv ei katnud. Kahju hüvitamist ei piirata lepingust tuleneva kohustuse tahtliku rikkumise korral. Sama ajavahemiku jooksul on tellijal õigus esitada lepingu punktis 10.1.5 leppetrahvi nõue ka täitja õigusjärglasele. LEPINGU MUUTMINE JA MUUD TINGIMUSED Pooltel on õigus lepingut muuta kooskõlas riigihangete seaduse ja lepingus endas sätestatuga. Pooltel on õigus lepingut muuta riigihangete seaduse § 123 lg 1 p 2 alusel, kui: esineb põhjendatud vajadus muuta lepingu täitmiseks nõutud tegevuste sisu või ajakava või muid lepingus sätestatud teenusega seotud asjaolusid, tingimusel, et tegevused asendatakse vähemalt samaväärsete vastu ning nendega saavutatakse teenuse osutamisega taotletav eesmärk. Muuhulgas võib põhjendatud vajadusel muuta lepingus sätestatud tähtaegasid (sh algus- või lõppkuupäeva). Tähtaegade muutmine peab olema tingitud teenuse osutamisega seotud objektiivsetest asjaoludest; lepingu sõlmimise viibimise tõttu, sh tulenevalt riigihankega seonduvatest võimalikest vaidlustus- ja kohtumenetlustest, ei osutu võimalikuks teenusega alustamine selliselt, et oleks võimalik järgida lepingu tähtaegu, alustatakse teenusega tellija poolt nimetatud kuupäeval pärast viivitust põhjustanud asjaolu äralangemist. Sellisel juhul lükatakse edasi ka lepingu lõppkuupäeva perioodi võrra, mille osas teenusega alustamine viibis. Kui teenuse osutamine lepingu tähtaegu järgides osutub seetõttu võimatuks, on tellijal õigus lükata tähtaega vastavalt edasi ja määrata uued tegevuste tähtajad; kui lepingu täitmise ajal esinevad inimeste tervise ja ohutu elukeskkonna tagamise vajadusest tingitud põhjused (nt COVID-19 sarnane haiguspuhang, sõjategevus, keemia- või loodusõnnetus vms), mistõttu ei osutu võimalikuks teenuse osutamine lepingus sätestatud tingimustel või alternatiivsete meetoditega, on pooltel õigus muuta lepingus esitatud aja-, tegevuskava ja/või pikendada lepingu täitmise tähtaega proportsionaalselt lepingu täitmist takistanud asjaolude esinemise aja võrra; Lepingu aja- ja/või tegevuskava ja/või tegevuste ja/või täitmise tähtaegu on lubatud pikendada lepingu nõuetekohast täitmist takistava asjaolu kehtivuse aja võrra. Täitja esitab aja- või tegevuskava muutmiseks või lepingu tähtaja pikendamiseks tellijale taotluse, milles näitab põhjendused ja selgitused, milliseid aja- või tegevuskavas olevaid tegevusi on võimalik kavandatud ajal läbi viia ning millised tegevused tuleks edasi lükata, sest neid ei ole võimalik läbi viia alternatiivsete meetoditega. Lepingu muudatused vormistatakse vähemalt kirjalikku taasesitamist võimaldavas vormis. Lepingut muutev kokkulepe on saavutatud üksnes juhul, kui tellija kontaktisik on selgesõnaliselt kinnitanud, et on täitja poolt nimetatud muudatusettepanekuga nõus. Kõik lepingust tulenevad või sellega seotud vaidlused lahendatakse läbirääkimiste teel ja kohaldatakse Eesti Vabariigi õigust. Kõik vaidlused, vastuolud või nõuded, mis tulenevad lepingust või selle rikkumisest, lõpetamisest või kehtetusest või on sellega seotud ja mida pooled ei ole suutnud lahendada läbirääkimiste teel, lahendatakse Harju Maakohtus. Lepingule kohaldatakse Eesti Vabariigis kehtivaid õigusakte. Koos lepingu sõlmimisega sõlmivad pooled andmetöötluse lepingu. Leping allkirjastatakse digitaalselt. Ettevõttega, kes ei ole registreeritud Eestis allkirjastatakse leping kirjalikult. POOLTE ALLKIRJAD Tellija: (allkirjastatud digitaalselt) Täitja: (allkirjastatud digitaalselt) LISA 4 RHAD LISA 2 juurde ANDMETÖÖTLUSE LEPING Käesolev isikuandmete töötlemist puudutav lepingu lisa (edaspidi: Lisa ) on lahutamatu osa kehtivale riigihankelepingule (edaspidi: Leping ), mis on sõlmitud Ettevõtluse ja Innovatsiooni Sihtasutuse (edaspidi: Vastutav töötleja ) ja Teie (edaspidi: Volitatud töötleja ) vahel, teostamaks Lepingus nimetatud tegevusi, võttes sealjuures arvesse teenuse iseloomust tulenevat andmesubjektide isikuandmete töötlemist. Lepingu eesmärk ja üldsätted Käesoleva lisa eesmärk on kokku leppida isikuandmete töötlemise sisu, eesmärk ja kestus volitatud töötleja poolt ning õigustes ja kohustuses isikuandmete töötlemisel, millest pooled juhinduvad lepingu täitmisel (edaspidi: teenused ). Lisa jõustub pärast selle allkirjastamist mõlema poole poolt. Lisa rakendatakse, kui volitatud töötleja töötleb vastutava töötleja nimel vastavalt lepingule andmesubjekti isikuandmeid. Käesolev lisa kujutab endast isikuandmete töötlemist puudutavat andmetöötlus lepingut vastavalt Euroopa Liidu isikuandmete kaitse üldmäärusele (2016/679) (edaspidi: GDPR ). Andmesubjektide kategooriad ja isikuandmete liigid, mida teenuse osutamisel töödeldakse, isikuandmete töötlemise kestus, iseloom ja eesmärgid ning vastutava töötleja poolt antud juhised on välja toodud igas lepingus ja selle lisades, mh andmetöötluse lepingus. Leping puudutab isikuandmete töötlemist volitatud töötleja poolt kuni teenuse osutamise lõpuni. Teenuse osutamisel on volitatud töötlejal vaja töödelda vastutava töötleja nimel isikuandmeid, mis on vajalikud lepinguliste kohustuste täitmiseks, sh nimi, töökoht. Pooled nõustuvad järgima pädeva jurisdiktsiooni ja Euroopa Liidu kehtestatud seadusi, regulatsioone, ametlikke määrusi ja juhendeid ning vajadusel viima sisse parandusi käesolevasse lisasse, et toimida kooskõlas eelmainitud seaduste ja regulatsioonidega. Vastuolude korral lepingu ja käesoleva lisa sätete vahel tuleb juhinduda käesoleva lisa sätetest. Definitsioonid Lähtuvalt käesoleva lisa eesmärkidest ja kooskõlas GDPR-iga on kasutusel järgmised väljendid: „Asjakohased tehnilised ja organisatsioonilised meetmed“ tähendavad selliseid protsesse ja protseduure, mis tehnoloogilist arengut ning rakendamise maksumust ja isikuandmeid arvesse võttes tagavad turvalisuse taseme vastavalt isikuandmete võimalikust volitusteta või ebaseaduslikust töötlemisest või juhuslikust kaotsiminekust või hävitamisest või kahjustamisest tulenevale kahju suurusele. „Andmekaitseseadused“ on GDPR ja Eesti Vabariigis kehtivad muud isikuandmete töötlemist reguleerivad õigusaktid ning nende rakendusaktid või täiendavad aktid koos nende paranduste, muudatuste või asendustega, mis tahes täitmisele kuuluvad juhendid ja tegevusjuhised, mis on väljastatud isikuandmete kaitse eest vastutava mis tahes kohaliku või EL reguleeriva asutuse poolt. „töötlemine” – igasugune toiming või toimingute jada, mida teostatakse isikuandmete või isikuandmete hulkadega kas automatiseeritud või automatiseerimata kujul, nagu näiteks kogumine, salvestamine, korrastamine, struktureerimine, säilitamine, kohandamine või muutmine, väljavõtete tegemine, päringute teostamine, kasutamine, avalikustamine edastamise, avaldamise või mis tahes muul viisil kättesaadavaks tegemise teel, liitmine või ühendamine, piiramine, kustutamine või hävitamine. „isikuandmed” – ükskõik milline informatsioon, mis on seotud tuvastatud või tuvastatava füüsilise isikuga (edaspidi: andmesubjektiga ). Tuvastatav füüsiline isik on isik, keda on võimalik kaudselt või otseselt tuvastada, viidates identifitseerimistunnustele nagu nimi, isikukood, asukoha andmed; internetipõhistele identifitseerimistunnusele või ühele või enamale identifitseerimistunnusele , mis on seotud antud isiku füüsilise, füsioloogilise, geneetilise, vaimse, majandusliku, kultuurilise või sotsiaalse identiteediga; „isikuandmetega seotud rikkumine” – turvarikkumine, mis põhjustab edastatavate, säilitatavate või muul viisil töödeldavate isikuandmete juhusliku või ebaseadusliku hävimise, kadumise, muutmise, loata avalikustamise või kättesaadavuse. Andmekaitse ja isikuandmete töötlemine Volitatud töötleja on kohustatud: töötlema andmesubjekti isikuandmeid vastavalt andmekaitseseadustele ja lepingule ning ainult sellisel minimaalsel määral, mis on vajalik teenuse osutamiseks ning üksnes seni kuni see on minimaalselt vajalik lepinguga antud ülesannete täitmiseks, aga mitte kauem kui lepingu lõppemiseni; tagama, et juurdepääs isikuandmetele võimaldatakse ainult nendele volitatud töötleja töötajatele, kes vajavad andmetele juurdepääsu lepingus ja selle lisades toodud kohustuste täitmiseks ning et kõik volitatud töötleja töötajad on teadlikud andmekaitseseadustest, mh isikuandmete kaitsest ja konfidentsiaalsusest ning on läbinud vastava koolituse või väljaõppe; mitte teostama täiendavalt mistahes muid töötlemise toiminguid, mis hõlmavad mistahes isikuandmeid või teavet, mis on saadud teenuse osutamise käigus ja mis jääb väljaspoole teenuse kohaldamisala, mh ei tohi volitatud töötleja teha mitte mingisuguseid muid uurimis-, analüüsi- või mistahes muid toiminguid. Samuti ei tohi lisada volitatud töötleja andmesubjekti isikuandmeid enda või kolmandate isikute toodetesse ja teenustesse; abistama vastutavat töötlejat võimaluste piires, võttes arvesse lepingu esemeks oleva teenuse iseloomu, täitmaks andmekaitseseadustest tulenevaid kohustusi. Volitatud töötleja kohustub tagama vastutavale töötlejale andmekaitseseadustes nõutava teavitustegevuse läbiviimise ja vajadusel vajalike nõusolekute, mille vormi põhja annab vastutav töötleja, kogumise ning edastab nõusolekuvormid vastutavale töötlejale. Vastutav töötleja vastutab volitatud töötlejale edastatud isikuandmete õigsuse eest; mitte tegema midagi sellist, mille tulemusel vastutav töötleja võiks rikkuda andmekaitseseadustest tulenevaid oma mis tahes kohustusi; töötlema isikuandmeid ainult vastutava töötleja dokumenteeritud (võib olla antud kirjalikku taasesitamist võimaldavas vormis) juhiste alusel, sh seoses isikuandmete edastamisega kolmandale riigile või rahvusvahelisele organisatsioonile, v. a juhul, kui ta on kohustatud tegema seda volitatud töötleja suhtes kohalduva õigusega. Sellisel juhul teatab volitatud töötleja selle õigusliku nõude enne isikuandmete töötlemist vastutavale töötlejale, kui selline teatamine ei ole olulise avaliku huvi tõttu kõnealuse õigusega keelatud; võtma mõistliku aja jooksul ühendust vastutava töötlejaga selgituste või täiendavate juhiste saamiseks, kui volitatud töötleja ei ole vastutava töötleja juhistes kindel. Volitatud töötleja teavitab vastutavat töötlejat kõigist avastatud vastuoludest juhendi ja Euroopa Liidu või pädeva jurisdiktsiooni andmekaitseseaduste või määruste vahel ja sellisel juhul võib volitatud töötleja koheselt keelduda vastutava töötleja juhendit täitmast; isikuandmete töötlemiseks kolmanda lepinguvälise isiku (edaspidi: teine volitatud töötleja ) kasutamise korral vastutab volitatud töötleja teise volitatud töötleja tegevuse eest samuti nagu enda tegevuse eest ning sõlmib teise volitatud töötlejaga isikuandmete töötlemiseks kirjalikud lepingud vastavalt GDPR artiklile 28 lõikele 4, mis on lepingus sätestatuga samaväärsed (ja mitte vähem ranged). Volitatud töötleja ei kaasa teist volitatud töötlejat ilma vastutava töötleja eelneva kirjaliku loata. Kui vastutav töötleja on andud volitatud töötlejale loa kasutada käesolevast lepingust tulenevate kohustuste täitmiseks teisi volitatud töötlejaid, on käesolevast lepingust tulenevate küsimuste vastamisel kontaktisikuks vastutavale töötlejale üksnes volitatud töötleja ning volitatud töötleja tagab, et kõnealune teine volitatud töötleja täidab käesoleva lepingu nõudeid ja on sellega seotud samal viisil nagu volitatud töötleja ise. Vastutav töötleja võib igal ajahetkel võtta tagasi volitatud töötlejale antud loa kasutada teisi volitatud töötlejaid; esitama vastutava töötleja nõudmisel ülevaatamiseks koopiad teiste volitatud töötlejatega sõlmitud lepingutest, kusjuures nendest lepingutest peab eemaldama sellise konfidentsiaalse äriteabe, mis ei ole käesoleva lepingu nõuete osas oluline; hoidma lepingu täitmise käigus teatavaks saanud isikuandmeid rangelt konfidentsiaalsena ning mitte kasutama ega avaldama andmeid, mis tahes muu kui käesolevas lepingus sätestatud eesmärgil. Samuti tagama, et isikuandmeid töötlema volitatud isikud (sh teised volitatud töötlejad, volitatud töötleja töötajad vm, kellel on ligipääs lepingu täitmise käigus saadud isikuandmetele) järgivad konfidentsiaalsusnõuet või nende suhtes kehtib konfidentsiaalsuskohustus ; võtma kasutusele kõik GDPR artiklis 32 nõutud meetmed isikuandmete töötlemisel, sellisel viisil, et töötlemine vastaks andmekaitseseadustes toodud nõuetele ning et vältida lepingu alusel toimuva isikuandmete töötlemise loata või ebaseadusliku töötlemise, juhusliku kaotamise või hävitamise või kahjustumise. Vastutaval töötlejal on õigus vajaduse korral kontrollida nõuete täitmist ja meetmete rakendamist volitatud töötleja poolt; aitama võimaluste piires vastutaval töötleja asjakohaste tehniliste ja korralduslike meetmete abil täita vastutava töötleja kohustusi vastata GDPR tähenduses kõigile andmesubjekti taotlustele oma õiguste teostamisel, muuhulgas edastades kõik andmesubjektidelt saadud andmete kontrollimise, parandamise ja kustutamise, andmetöötluse keelamise ja muud taotlused vastutavale töötlejale viivitamatult nende saamisest alates; tegema vastutavale töötlejale kättesaadavaks kogu teabe, mis on vajalik GDPR artiklis 28 sätestatud kohustuste täitmise tõendamiseks, ning võimaldama vastutaval töötlejal või tema poolt valitud muul audiitoril teha auditeid, sealhulgas kontrolle, ja panustama sellesse. Pooled lepivad auditi kuupäevas ja muudes üksikasjades eelnevalt kokku. Audit viiakse läbi selliselt, et see ei häiriks volitatud töötleja kohustuste täitmist vastutava töötleja või kolmandate isikute ees. suunama kõik järelevalveasutuste päringud otse vastutavale töötlejale, kuna suhtluses järelevalveasutustega pole volitatud töötlejal õigust vastutavat töötlejat esindada ega tema nimel tegutseda. Töötlemine väljaspool Euroopa Liitu / Euroopa Majanduspiirkonda Volitatud töötleja ja teised volitatud töötlejad ei tohi töödelda isikuandmeid väljaspool Euroopa Liitu / Euroopa Majanduspiirkonda ilma vastutava töötleja kirjaliku nõusolekuta. Pooled lepivad eelnevalt kirjalikult kokku igas väljaspool Euroopa Liitu / Euroopa Majanduspiirkonda toimuvas kliendiandmete edastamises või töötlemises. Isikuandmetega seotud rikkumisest teavitamine Volitatud töötleja teavitab vastutavat töötlejat kõigist isikuandmetega seotud rikkumistest või kui on alust arvata, et selline rikkumine on aset leidnud, ilma põhjendamatu viivituseta alates hetkest, kui volitatud töötleja või tema poolt kasutatav teine volitatud töötleja saab teada isikuandmetega seotud rikkumisest või on alust arvata, et selline rikkumine on aset leidnud, kuid mitte hiljem kui 48h jooksul alates isikuandmetega seotud rikkumisest või selle kahtlusest teada saamisest. Vastutava töötleja nõudmisel peab volitatud töötleja ilma põhjendamatu viivituseta edastama vastutavale töötlejale kogu isikuandmetega seotud rikkumist puudutava asjakohase informatsiooni. Määral, mil volitatud töötlejale on vastav informatsioon kättesaadav, peab teade kirjeldama vähemalt järgmist: toimunud isikuandmetega seotud rikkumise laad, eeldatav kuupäev ja kellaaeg; volitatud töötleja andmekaitseametniku või teise asjakohase kontaktisiku nimi ja kontaktandmed, kellelt saab täiendavat informatsiooni; asjaomaste andmesubjektide kategooriaid ja ligikaudset arv ning isikuandmete asjaomaste kirjete liik ja ligikaudne arv; isikuandmetega seotud rikkumise tõenäolised tagajärjed, ja meetmeid, mida volitatud töötleja rikkumise lahendamiseks on tarvitusele võtnud või võtab, et vältida isikuandmetega seotud rikkumisi tulevikus, ja vajaduse korral ka meetmeid, mille abil leevendada rikkumise võimalikke negatiivseid mõjusid. Volitatud töötleja peab vastutava töötleja jaoks viivitamatult dokumenteerima uurimise tulemused ja tarvitusele võetud meetmed. Volitatud töötleja teeb vastutava töötlejaga igakülgset koostööd selleks, et välja töötada ja täita tegevusplaani isikuandmetega seotud rikkumiste kõrvaldamiseks. Vastutav töötleja vastutab järelevalveasutustele vajaliku teavitustöö eest. Volitatud töötleja teavitab igast rikkumisest vastutava töötleja lepingulist esindajat ning andmekaitsespetsialisti ([email protected] ). Muud sätted Volitatud töötleja kohustub lepingu lõppemisel viivitamata lõpetama isikuandmete töötlemise ning tagastama või üle andma vastutavale töötlejale kõik andmesubjektide andmed või kustutama andmed ja nende koopiad vastavalt vastutava töötleja antud juhistele ning viisil, mis ei võimalda isikuandmete taastamist, juhul kui kehtiv seadusandlus ei nõua isikuandmete säilitamist. Volitatud töötleja väljastab vajaduselt vastutavale töötlejale volitatud töötleja esindusõigusega isiku poolt allkirjastatud tõendi kinnitades, et lisa punktis 6.1 nimetatud toimingud on teostatud tema ja kõigi tema poolt kasutatud teiste volitatud töötlejate poolt. Kui GDPR-i või käesoleva lisa rikkumine põhjustab andmesubjektile materiaalset või mittemateriaalset kahju, vastutab volitatud töötleja tekitatud kahju eest ainult ulatuses, mille osas volitatud töötleja ei ole täitnud GDPR-i või käesoleva lisa poolt selgesõnaliselt sätestatud kohustusi. Mõlemad pooled on kohustatud hüvitama ainult selle osa tekkinud kahjudest ja trahvidest, mis on kooskõlas järelevalveasutuse poolt või kohtuotsusega määratud vastava osapoole vastutusega tekitatud kahju eest. Muus osas määratleb poolte vastutuse nendevaheline leping. Volitatud töötleja teavitab vastutavat töötlejat kirjalikult kõigist muudatustest, mis võivad mõjutada volitatud töötleja võimet või väljavaateid pidada kinni käesolevast lisast ja vastutava töötleja kirjalikest juhistest. Pooled lepivad kõigis käesolevat lisa puudutavates täiendustes ja muudatustes kokku kirjalikult. Käesolev lisa jõustub selle allkirjastamisel mõlema poole poolt. Lisa kehtib, kuni (i) kehtib pooltevaheline leping või (ii) pooltel on omavahelisi kohustusi, mis on seotud isikuandmete töötlemisega. Kohustused, mis oma iseloomu tõttu peavad jääma jõusse hoolimata käesoleva lisa kehtivuse lõppemisest, jäävad pärast käesoleva lisa kehtivuse lõppemist jõusse. Volitatud töötleja igasugune vastutus (välja arvatud seadusest tulenevad piirangud) käesoleva Lisa punktide 6.3 ja 6.4 alusel piirdub volitatud töötleja poolt rikkumisele eelnenud 12 (kaheteistkümne) kuu jooksul laekunud tasude summaga. (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) Vastutav töötleja Volitatud töötleja RHAD LISA 3 VORM: CV – Ärianalüütik Ees- ja perekonnanimi: Sünniaeg: pp.kk.aaaa Keeleoskus: Keeletasemed vastavalt Euroopa Keeleõppe Raamdokumendi üldistele keeleoskustasemetele Eesti keel: märkida keeletase Inglise keel: märkida keeletase Töökogemus RHAD lisa 1a punkti 1 .2.1. 1 täitmiseks Projekti läbiviimise periood kk.aaaa – kk.aaaa T arkvaraarenduse projekti nimetus , tellija/omaniku kontaktandmed Isiku töötunnid projektis Tööülesannete lühikirjeldus Märkida ristiga, kui käesolevas vormis toodud info on pakkuja ärisaladus. RHAD LISA 3 VORM: CV – Süsteemianalüütik Ees- ja perekonnanimi: Sünniaeg: pp.kk.aaaa Keeleoskus: Keeletasemed vastavalt Euroopa Keeleõppe Raamdokumendi üldistele keeleoskustasemetele Eesti keel: märkida keeletase Inglise keel: märkida keeletase Töökogemus RHAD lisa 1a punkti 1 . 3 .1. 1 täitmiseks Projekti läbiviimise periood kk.aaaa – kk.aaaa T arkvaraarenduse analüüsi projekti nimetus, tellija/omaniku kontaktandmed Isiku töötunnid projektis Tööülesannete lühikirjeldus Märkida ristiga, kui käesolevas vormis toodud info on pakkuja ärisaladus. RHAD LISA 3 VORM: CV – Süsteemiarhitekt Ees- ja perekonnanimi: Sünniaeg: pp.kk.aaaa Keeleoskus: Keeletasemed vastavalt Euroopa Keeleõppe Raamdokumendi üldistele keeleoskustasemetele Eesti keel: märkida keeletase Inglise keel: märkida keeletase Töökogemus RHAD lisa 1a punkti 1.4 .1.1 täitmiseks Töökogemus RHAD lisa 1a punkti 1 . 4 .1. 1 täitmiseks T ehnoloogia Tarkvaraarenduse projekti nimetus, tellija/omaniku kontaktandmed Isiku roll projektis Andmebaas: PostgreSQL PostGIS Amazon AWS Arendusplatvorm : Java OpenJDK Rakenduse põhiraamistik: Spring Framework Mikroteenuse rakendusplatvorm: SpringBoot Kasutajaliides: Angular Next.js Kaardirakendus : Google Maps Platform või samaväärne GIS-teenus Täistekstotsingu platvorm: SOLR Töökogemus RHAD lisa 1a punkti 1.4.1. 2 täitmiseks Projekti läbiviimise periood kk.aaaa – kk.aaaa Tarkvaraarenduse projekti nimetus, tellija/omaniku kontaktandmed Kinnitan, et osale sin projektis arhitekt/juhtiv-arendajana ja veebirakendus on majutatud AmazonWeb Services (AWS) (või samaväärsesse) (jah/ei) Märkida ristiga, kui käesolevas vormis toodud info on pakkuja ärisaladus. RHAD LISA 3 VORM: CV – Tarkvara kvaliteedi spetsialist Ees- ja perekonnanimi: Sünniaeg: pp.kk.aaaa Keeleoskus: Keeletasemed vastavalt Euroopa Keeleõppe Raamdokumendi üldistele keeleoskustasemetele Eesti keel: märkida keeletase Inglise keel: märkida keeletase Töökogemus RHAD lisa 1a punkti 1.6 .1.1 täitmiseks Projekti läbiviimise periood kk.aaaa – kk.aaaa Tarkvaraarenduse projekti nimetus, tellija/omaniku kontaktandmed Isiku roll projektis Töömaht projektis RHAD LISA 3 VORM: CV – Programmeerija Ees- ja perekonnanimi: Sünniaeg: pp.kk.aaaa Keeleoskus: Keeletasemed vastavalt Euroopa Keeleõppe Raamdokumendi üldistele keeleoskustasemetele Eesti keel: märkida keeletase Inglise keel: märkida keeletase Töökogemus RHAD lisa 1a punkti 1 . 7 .1. 1 -1 . 7 .1. 10 täitmiseks tehnoloogia/platvormi nimetus Tähistada osalemine Tarkvaraarenduse projekti nimetus, tellija/omaniku kontaktandmed AmazonWeb Services (AWS) (või samaväärse) Teostanud veebis ligipääsetavusega seotud töid vastavalt WCAG 2.1 AA nõutele https://www.w3.org/TR/WCAG21/ Kogemus Front-end programmeerijana semantic HTML või Angular ja Next.js; kogemus relatsiooniliste andmebaasidega Kogemus arendusplatvormiga Java OpenJDK kogemus Spring Framework või samaväärne rakendusraamistikuga kogemus mikroteenuse rakendusplatvormiga SpringBoot või samaväärne kogemus turvalise logimise meetodi SSO tüüpi sisselogimise lahenduste kasutamisel ja loomisel Google Maps Platform või samaväärne kogemus platvormidega, kus on teostatud otsingumootorile optimeerimise (SEO) töid Märkida ristiga, kui käesolevas vormis toodud info on pakkuja ärisaladus. RHAD LISA 3 VORM: CV – Süsteemiadministraator Ees- ja perekonnanimi: Sünniaeg: pp.kk.aaaa Keeleoskus: Keeletasemed vastavalt Euroopa Keeleõppe Raamdokumendi üldistele keeleoskustasemetele Eesti keel: märkida keeletase Inglise keel: märkida keeletase Töökogemus RHAD lisa 1a punkti 1. 8 .1. 1 täitmiseks Projekti läbiviimise periood kk.aaaa – kk.aaaa Tarkvaraarenduse projekti nimetus, tellija/omaniku kontaktandmed Kinnitan, et osale sin projektis s üsteemi administraatorina ja veebirakendus on majutatud AmazonWeb Services (AWS) (või samaväärsesse) Töökogemus RHAD lisa 1a punkti 1.8.1.2 täitmiseks Projekti läbiviimise periood kk.aaaa – kk.aaaa Tarkvaraarenduse projekti nimetus, tellija/omaniku kontaktandmed Kinnitan, et osalesin projektis s üsteemi administraatorina ja kus on kasutusel relatsiooniline andmebaas: PostgreSQL , PostGIS või samaväärne. Märkida ristiga, kui käesolevas vormis toodud info on pakkuja ärisaladus. RHAD LISA 3 VORM: CV – Kasutajakogemuse (UX) disainer Ees- ja perekonnanimi: Sünniaeg: pp.kk.aaaa Keeleoskus: Keeletasemed vastavalt Euroopa Keeleõppe Raamdokumendi üldistele keeleoskustasemetele Eesti keel: märkida keeletase Inglise keel: märkida keeletase Töökogemus RHAD lisa 1a punkti 1. 9 .1.1 täitmiseks Projekti läbiviimise periood kk.aaaa – kk.aaaa Tarkvaraarenduse projekti nimetus, tellija/omaniku kontaktandmed URL ja k asutajagrupid (nt. sisuhaldur, pakkuja, tarbija jms.) Märkida ristiga, kui käesolevas vormis toodud info on pakkuja ärisaladus. RHAD LISA 3 VORM: CV – Kasutajaliidese (UI) disainer Ees- ja perekonnanimi: Sünniaeg: pp.kk.aaaa Keeleoskus: Keeletasemed vastavalt Euroopa Keeleõppe Raamdokumendi üldistele keeleoskustasemetele Eesti keel: märkida keeletase Inglise keel: märkida keeletase Töökogemus RHAD lisa 1a punkti 1.1 0 .1.1 täitmiseks Töötamise periood kk.aaaa – kk.aaaa Ettevõtte nimetus, kontaktandmed Kinnitan, et olen projektis teostanud ligipääsetavusega seotud töid vastavalt WCAG 2.1 AA nõutele https://www.w3.org/TR/WCAG21 (jah/ei) Tööülesannete lühikirjeldus Töökogemus RHAD lisa 1a punkti 1.11 .1.2 täitmiseks Projekti läbiviimise periood kk.aaaa – kk.aaaa Tarkvaraarenduse projekti nimetus, tellija/omaniku kontaktandmed URL ja k asutajagrupid (nt. sisuhaldur, pakkuja, tarbija jms.) Märkida ristiga, kui käesolevas vormis toodud info on pakkuja ärisaladus. H anke komisjoni protokoll „Visit Estonia turismiinfosüsteemi arendus-, hooldus- ja majutusteenus“, mille riigihangete registri (edaspidi RHR) viitenumber on 280554 ja hankija sisene hankenumber on HNR240093 Koosoleku käigus hinnati konsensuslikult hankes esitatud pakkumuse lahenduse kirjeldusi ning jõuti dokumendis märgitud hindamise tulemuseni : Mockup`de ärinõude d. Proovitöös esitatud vähemalt 4 mockup-i kohaldatuna mobiilivaatele. Märkida: Jah/ei (vajadusel lisada kommentaar) Ärinõue Pakkuja: Krabu Grupp OÜ, Catapult Labs OÜ Pakkuja: AS Finestmedia 3 punkti. Kõik mockup`d on loodud inglisekeelsele kasutajale. jah jah 3 punkti. Kõikide mockup`de puhul on järgitud Brand Estonia ja Visit Estonia stiilinõudeid . ei Kõik mockup’d ei järgi Brand Estonia ja Visit Estonia stiilinõudeid . Kaardil on rattamatkateede joontel kasutusel disainisüsteemi mittekuuluvad värvid (#3366E1, #35753F, #C03600). Kaardil olevad rattamatkateede algus- ja lõpp-punktina on kasutusel disainisüsteemi mitte kuuluvad ikoonid (vormipõhised, mitte joongraafika). Tagasiside andmise nn rating’u tähekeste ikoonid ei sobitu disainisüsteemi ikooni stiili ega värvi (#FF9500) poolest. Kaardivaadetes ei kasuta moc k up ikoonide vaates ühtset hierariat ega läbivat selget loogikat. Rattateed markeeriv element ei kasuta disainisüsteemi värve ja kasutusel on drop shadow efekt , mis ei vasta stiilinõuetele. . jah 3 punkti . Järgitud on visitestonia.com kaardirakenduse stiili ja kasutusloogikat. jah jah 3 punkti. Järgitud on visitestonia.com veebi üldist stiili ja kasutusloogikat. jah jah 3 punkti. Rattamatkateede infos on kuvatud kasutajale huvipakkuv info (nimekiri ei ole lõplik), näiteks rattatee pikkus, raskusaste, info tee läbitavuse kohta (nt kruusatee, asfaltkate, reljeefne tee vms), info rattatee viidastamise/mitteviidastamise kohta. jah jah 3 punkti. Kasutaja saab vaadata kaardil üldvaates kõiki rattamatkateid. jah jah 3 punkti. Rattamatkateid saab valida kaardil eraldi kategooriana teiste objektide kategooriate hulgas kaardil asuvas menüüs. jah jah 2 punkti. Kasutaja saab vaadata infot valitud rattamatkatee kohta. jah jah 2 punkt. Kasutaja saab vaadata infot rattamatkatee lähiümbruses asuvate huviväärsuste kohta. jah jah 1 punkt. Kasutaja saab rattamatkateed alla laadida GPX formaadis. jah jah 1 punkt. Rattamatkateel on kaardil tähistatud algus- ja lõpp-punkt. jah jah 1 punkt. Rattamatkateel on unikaalne rattatee number. jah jah 1 punkt. Rattamatkateed on üksteisest eristatavad. jah jah 1 punkt. Järgitud on WCAG 2.2 AA taseme nõuetega nii palju kui mockup loomine seda võimaldab. jah jah Hankekomisjoni kollegiaalne otsus on pakkumust hinnata : 27 punktiga 30 punktiga Proovitöös esitatud mockup’dele loodud lahendust hinnatakse järgnevate alakriteeriumite alusel: 5.7.3.1. Mockup’de visuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning omavahel loogiliselt järjestatud. „10“ punkti – vastab täielikult ärinõuetele ja lahendus sisaldab uudseid ettepanekuid/visiooni rattamatkateede kaardil kuvamise edasiarendamiseks ning nende rakendamine võib anda tööle täiendavat väärtust. Lahendus on tuginenud headele praktikatele, näidetele, andmetele, statistikale, uuringutele või muule veebiarendusega seotud põhimõtetele; „8“ punkti – vastab täielikult; „5“ punkti – vastab olulises osas etteantud kriteeriumitele; „3“ punkti – vastab keskpärasel määral; „1“ punkt – vastab vähesel määral etteantud kriteeriumitele. 5.7.3.2. Kasutajamugavus. Mockupide põhjal on kasutamine lõppkasutajale väga mugav, kasutaja teekond on läbi mõeldud ning kutsub uuesti kasutama. „10“ punkti – vastab täielikult; „7“ punkti – vastab olulises osas etteantud kriteeriumitele; „4“ punkti – vastab keskpärasel määral etteantud kriteeriumile; „1“ punkt – vastab vähesel määral etteantud kriteeriumitele. Pakkumusele omistatav punktisumma saadakse alakriteeriumite liitmisel. Pakkuja: Krabu Grupp OÜ, Catapult Labs OÜ Põhjendus: 5.7.3.1. Mockup’de visuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning omavahel loogiliselt järjestatud. Mockup’de visuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning mockup’d omavahel loogiliselt järjestatud ja v astab täielikult etteantud kriteeriumitele ning lahendus sisaldab uudseid ettepanekuid/visiooni rattamatkateede kaardil kuvamise edasiarendamiseks ning nende rakendamine võib anda tööle täiendavat väärtust. Samuti on lahendus tuginenud headele praktikatele ja kasutaja uuringutele, kuid täidetud ei ole kõik ärinõuded. Kasutajal on lihtne, loogiline ja huvitav mockup’des navigeerida. Uudsetest lahendutest on toodud funktsionaalsus kasutajatel hinnata, anda tagasisidet ja kommenteerida rattamatkateed ning tee lähedalasuvaid huvipunkte ning rattamatkatee detailinfos on kasutajal võimalik vaadata detailselt lõigu kaupa teekonna pinna infot (pinnatüübid ja protsendid) . Kuna esit atud Mockupid ei vasta täielikult ärinõuetele ei omistata pakkumusele mitte 10 vaid 8 punkti. 5.7.3.2 Kasutajamugavus. Mockupide põhjal on kasutamine lõppkasutajale väga mugav, kasutaja teekond on läbi mõeldud ning kutsub uuesti kasutama. Lahenduse k asutajamugavus vastab täielikult nõutud kriteeriumitele . Mockupide põhjal on kasutamine lõppkasutajale väga mugav, kasutaja teekond on põhjalikult läbi mõeldud ning kutsub uuesti kasutama. Kasutajateekond algab kaardi üldvaatest ning kasutaja liigub loogiliselt võimalusega , kas filtreeri des või otsingut kitsendades , teda hu v itava rattamatkatee detailsema info leidmise suunas. Rattamatkatee infoaken sisaldab sisukat, vajalikku ja hästi esitatud teavet, mida lõppkasutaja planeerides ja ka teel olles vajab. Samuti saab kasutaja mugavalt ja lihtsalt tutvuda huviväärsustega teekonnal . Kasutajal on huvitav ja kutsub rattamatkateede kaarti uuesti kasutama. 10 punkti. Hankekomisjoni kollegiaalne otsus on pakkumust hinnata 18 punktiga. Pakkuja: AS Finestmedia Põhjendus: 5.7.3.1. Mockup’de visuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning omavahel loogiliselt järjestatud. Mockup’de visuaalne lahendus on väga hästi, selgelt ja loogiliselt esitatud ning mockup’d omavahel loogiliselt järjestatud ning lahendus v astab täielikult ärinõuetele . Lahendus on põhjalik, detailne ning mockup’de vahel on lihtne navigeerida. L ahendus sisaldab uudseid ettepanekuid ja visiooni rattamatkateede kaardil kuvamise edasiarendamiseks ning nende rakendamine võib anda tööle täiendavat väärtust. Lahendus on tuginenud headele praktikatele ja kasutaja uuringutele . Uudsetest lahendutest on toodud mitmed funktsionaalsused näiteks kasutaja poolt rattateele tagasiside andmine ja kommenteerimine ning hooajaliste hoiatuste , nõuannete ja näpunäidete lisamine konkreetsel teelõigul , rattaraja lähiümbrusesse jäävad mugavusteenused (nt avalikud tualetid, toidupood jne) , kasutajale „Check weather forecast“ kuvamine ning võimalus muuta rattateeinfos tee algus- ja lõpp-punkti suunda, millega seoses muutub ka tee info lõikudes , kasutajal on võimalik vaadata detailselt lõigu kaupa teekonna pinna infot (pinnatüübid ja protsendid). 10 punkti. 5.7.3.2 Kasutajamugavus. Mockupide põhjal on kasutamine lõppkasutajale väga mugav, kasutaja teekond on läbi mõeldud ning kutsub uuesti kasutama. Lahenduse kasutajamugavus vastab täielikult nõutud kriteeriumitele. Mockupide põhjal on kasutamine lõppkasutajale väga mugav, kasutaja teekond on detailselt ja põhjendatult läbi mõeldud ning kutsub uuesti kasutama. Kasutajateekond algab kaardi üldvaatest ning kasutaja liigub loogiliselt võimalusega , kas filtreerida või otsingut kitsendades , teda hu v itava rattamatkatee detailsema info leidmise suunas. Rattamatkatee info sisaldab sisukat, vajalikku ja hästi esitatud teavet, mida lõppkasutaja planeerides ja ka teel olles vajab. Samuti saab kasutaja mugavalt ja lihtsalt tutvuda huviväärsustega teekonnal. Kasutajal on lahendust kasulik ja huvitav kasutada ning see kutsub kasutaja tagasi visitestonia.com keskkonda. 10 punkti. Hankekomisjoni kollegiaalne otsus on pakkumust hinnata 2 0 punktiga. Lgp. Hankija Olete oma 19.09 avaldatud otsuses ja lisatud hindamiskomisjoni protokollis toonud välja võitva pakkuja (Krabu Grupp, Catapult Labs OÜ) proovitööna esitatud mockup’de ärinõuete vastavuse. Lisatud protokollis nähtub, et hankija on võitva pakkuja proovitöös punkte vähendatud kategoorias „Kõikide mockup`de puhul on järgitud Brand Estonia ja Visit Estonia stiilinõudeid“ järgmise selgitusega: „Kõik mockup’d ei järgi Brand Estonia ja Visit Estonia stiilinõudeid. Kaardil on rattamatkateede joontel kasutusel disainisüsteemi mittekuuluvad värvid (#3366E1, #35753F, #C03600). Kaardil olevad rattamatkateede algus- ja lõpp-punktina on kasutusel disainisüsteemi mitte kuuluvad ikoonid (vormipõhised, mitte joongraafika). Tagasiside andmise nn rating’u tähekeste ikoonid ei sobitu disainisüsteemi ikooni stiili ega värvi (#FF9500) poolest. Kaardivaadetes ei kasuta mockup ikoonide vaates ühtset hierariat ega läbivat selget loogikat. Rattateed markeeriv element ei kasuta disainisüsteemi värve ja kasutusel on drop shadow efekt, mis ei vasta stiilinõuetele.” Samas ei ole hankija oma otsusega vähendanud võitva pakkuja punkte kategooriates “Järgitud on visitestonia.com kaardirakenduse stiili ja kasutusloogikat.” ega “Järgitud on visitestonia.com veebi üldist stiili ja kasutusloogikat.”. Eeltoodust tulenevalt palume hankijalt selgitust ja põhjendusi proovitöö hindamispunktide kohta. Pakkuja arusaama kohaselt on nii visitestonia.com kaardirakenduse kui ka veebi stiil väga otseselt tulenevad Brand Estonia ja Visit Estonia stiilinõuetest. Brand Estonia ja Visit Estonia annab ette mh ka stiilinõuded kaardirakendusele kui ka veebile, sh värvidele ja ikoonidele. Seega on üpris tõenäoline, et võitva pakkuja proovitöös ei saa olla järgitud kaardirakenduse ja/või veebi stiili. Kui proovitöös on eiratud nö. peamiseid stiilinõudeid, siis kuidas on hankija hinnangul võimalik, et samas proovitöös on kaardirakenduse ja veebi stiili järgitud ja saadud selle eest maksimumpunktid? Rõhutame, et hankija on ka enda hindamise selgitusena võitva pakkumuse proovitöös puudustena välja toonud, et mockup’des (sh kaardil) on kasutatud disainisüsteemi mittekuuluvaid värve, ikoone ja stiile. Kui hankija on proovitöö hindamisel punktide andmisel eksinud, siis palub pakkuja hankijal hindamine uuesti läbi viia. Punktide korrektne andmine võib mõjutada pakkujate järjestust ning otseselt ka Finest AS (endise nimega Finestmedia AS) võiduvõimalusi, kuna meie proovitööle on hankija omistanud maksimaalsed võimalikud punktid. Lugupidamisega  Luminor: BRIDGE Maksekorraldus nr. : 2240 Dokumendi kuupäev 24.09.2024 Maksja Finestmedia AS Registrikood 10714404 Maksja konto EE811700017004463526 (EUR) Makse saaja Rahandusministeerium Makse saaja riik Eesti Makse saaja konto EE701700017001577198 Makse saaja panga SWIFT RIKOEE22XXX Makse saaja panga riik Eesti kood LUMINOR BANK AS, ESTONIA (FORMER NORDEA BANK AB ESTONIA Makse saaja panga Makse saaja pank ESTONIA BRANCH) aadress Summa 1 280,00 EUR (üks tuhat kakssada kaheksakümmend eurot ja 0 senti) Makse info RH 280554 vaidlustuse riigilõiv Makse prioriteet Tavamakse Olemasolevad allkirjad 24.09.2024, 13:13 : A (Jan Urva) Maksealgataja viitenumber 50ign Allkirjastatud Lehekülg 1 alates 1