Kiri

Jrk
Küsimus
Vastus
1.
Hankija on TK punktis 4.3.2. märkinud järgmist: Tabelis 1 on toodud I ja II prioriteedi nõuded. I prioriteedi nõuded on kohustuslikud ja peavad olema valmis või pakkuja peab olema valmis neid teostama enne lansseerimist, so maksimaalselt 90 päeva jooksul pärast lepingu sõlmimist. II prioriteedi tööd tuleb pakkujal välja tuua eraldi.
Küsimust ei ole I etapi töödes, mille sisu on TKs detailselt kirjeldatud.
-
2.
Selgitage, mida on hankija silmas pidanud korralduse all: II prioriteedi tööd tuleb pakkujal välja tuua eraldi?
Hankija viitab sellega sellele, et II prioriteedi tööd ei pea olema valmis samal ajal, kui I prioriteedi tööd, s.o 90 päeva jooksul. II prioriteedi töödele oli pakkujal võimalus esitada oma ajaraam ning soovi korral täpsem kirjeldus, kuidas ja millal töid teostatakse. Tööde funktsionaalsus ehk nõuded on hankija poolt piisavalt selgitatud, et selles konkreetses skoobis ei olnud võimalik pakkujal kaasa rääkida ning hankija seda ka ei oodanud.
3.
Selgitage, kus on antud pakkujale/töövõtjale RHADis sisend, milliste töödega peab töövõtja II etapis arvestama?
II prioriteedi tööd on nimetatud TK p 4.3.2.12, 4.3.2.13 ja 4.3.2.14 ning p 4.3.2 korraldus viitabki sellele, et pakkumuse koosseisus tuleb vastavustingimuse nr 1 küsimuse nr 3 vastusena see esitada. Nendes punktides on nimetatud funktsionaalsused, mis peavad äpil olema, mistõttu need ongi tööd, millega peab arvestama.
4.
Kas ma saan õigesti aru, et TKs toodud II prioriteedi tööd punktides 4.3.2.12-4.3.2.14 on tööde üldine nimetus? Mida siia lisama peaks veel pakkuja?
Jah, olete õigesti aru saanud, et prioriteedi II tööd on TK viidatud punktides. Tööde sisu on samuti nendes punktides, st tegemist ei ole üldiste nimetustega, vaid konkreetsete funktsionaalsustega, mis on kirjeldatud sama detailsusastmega kui I prioriteedi tööd. I prioriteedi töödel on ajaline piirang, kuna need on põhifunktsionaalsused, milleta teenust pakkuda ei saa. II prioriteedi tööd on olulised, ent on võimalik alustada teenuse pakkumisega I prioriteedi funktsionaalsusega.

Pakkumuse koosseisus esitatud dokument 1.3 vahelehel „Functional requirements“ ridadel 45-47 on pakkuja seda käsitlenud ning kohustusest aru saanud samamoodi, nagu hankija seda ette nägi. Pakkuja pidi lisama, mis ajaraamis tööd teostatud saavad, kuivõrd prioriteedi II tööd ei pidanud jääma 90 päeva sisse, nagu prioriteedi I tööd. Pakkuja siiski valis teostada need samas ajaraamis I prioriteedi töödega.
5.
Selgitage, kui 90 päeva jooksul lepingu sõlmimisest peavad I prioriteedi tööd olema teostatud, siis milliste töödega sisustab töövõtja ülejäänud raamlepingu perioodi?
Tellija võib ülejäänud perioodi tellida lisaarendusi. Näiteks, kui teenuse kasutamise käigus ilmneb, et mingi funktsionaalsus on puudu, mis teeks kasutaja elu mugavamaks.
6.
RHADis on sätestatud järgmised tingimused:
Raamlepingust:
2.3. Kui hankelepingu tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks hankelepingu tingimus. Kui lepingu lisades esinevad tingimused erinevad lepingu tingimustest, loetakse ülimuslikuks lepingu tingimus.
2.8. Kui lepingu täitmisel tekivad täitja ja tellija vahel erimeelsused, lähtutakse hankelepingu eesmärkidest esmalt tellija seisukohalt, võttes arvesse hanke alusdokumentides määratletud eesmärki ja sisu.
-
7.
Selgitage, kas ülal nimetatud punktised mainitud olukordi esines?
Ei, selliseid olukordi ei ole esinenud.
8.
Kui jah, kirjeldage olukorda ning esitage olukorra lahenduskäik.
-
9.
Hindamiskriteeriumina on hankija sätestanud järgmise kriteeriumi 1: Haldusteenuse ühe aasta maksumus. 40%-
Hankija hindab haldusteenuse maksumust, kuid ei ole kirjeldanud RHADis detailsemalt, milliseid töid haldusteenus peaks sisaldama.
-
10.
Selgitage, millises RHAD dokumendis on selgitatud, milliseid töid haldusteenus peaks sisaldama.
Haldusteenuseks lepingu kontekstis on tasu iga-aastase kasutamise eest lepingu alusel valminud teenuste funktsionaalsuste osas ehk siis tasu selle eest, et meil on võimalik lepingu eset kasutada ning teenus on kättesaadav eri platvormidel.
11.
Selgitage, millises RHAD dokumendis on sätestatud töövõtja kohustus neid töid teostada.
Raamlepingu p 4.1 sätestab aastatasu. Samale aastatasule viitab esimese hankelepingu ptk 3. Teenuse kirjeldus on toodud tehnilises kirjelduses. Pakkuja pakkuski hankijale tehnilise kirjelduse alusel haldusteenuse, mille raames kohandati pakkuja olemasolev toode 90 päeva jooksul vastavaks hankija vajadustele, misjärel pakub pakkuja seda toodet edasi haldusteenuse hinna alusel ning vajadusel eraldi tellitavate tööde puhul rakendatakse töötunni hinda.
12.
Hindamiskriteerium nr 2: tervikprojekti kirjeldus. Punktide omistamise kirjeldus ütleb omakorda, et hankija hindab pakkumuses: tervikprojekti kirjeldusest on selgelt aru saada, kuidas ja milliseid muudatusi tuleb teha kogu projekti käigus ning milliseid funktsionaalsusi tuleb juurde arendada.
-
13.
Saan aru, et hetkel on sarnase teenuse tarvitamiseks kasutusel Skype lahendus, mis soovitakse asendada Äpiga. Ehk siis ei saa olemasolevat lahendust ei muuta ega täiendada/arendada.
Jah, kasutusel on hetkel Skype, mis asendati hankelepingu raames osutatava teenusega ehk äpiga. Olemasoleva lahenduse funktsionaalsusi soovis hankija ikkagi ka uue lahenduse juures rakendada, seega olemasolevat lahendust küll ei täiendatud, kuid selle funktsionaalsused võeti üle uude lahendusse.
14.
Selgitage, mida hankija peab silmas hindamisel „kuidas ja milliseid muudatusi tuleb teha kogu projekti käigus“. Kui olemasolevat lahendust ei täiendata, vaid luuakse uus, siis mis sordi muudatustest saab jutt käia? Mida hankija pakkuja pakkumusest ootas ning mida täpsemalt hinnati.
Olemasoleva lahenduse funktsionaalsused on siiski üle võetavad ja kasutatavad ka uuel lahendusel. See tähendab, et hoolimata varasema lahenduse edasi arendamata jätmisest ei jäeta kõrvale selles toiminud funktsionaalsusi ning võimalusel kasutatakse neid ka edasi. Muudatused ongi seotud seega dokumentides ka just funktsionaalsustega, mitte konkreetse süsteemiga. Seega hankija ootus oli, et pakkuja selgitab, mida olemasolevates funktsionaalsustes tuleks muuta, et saavutada lepingu eesmärk. Samuti on oluline tähele panna, et hankija eeldas, et pakutakse suuresti olemasoleva äpi platvormile tehtavaid hankijale vajalikke funktsionaalsustega lahendust. Seega oli pakkuja kohustuseks juhul, kui arendus tehakse olemasolevale platvormile, anda teada, milliseid funktsionaalsusi muudetakse. Kui pakkuja arendaks algusest, siis tulnuks jääda üksnes selle selgituse juurde, mida nõuetes esitatud funktsionaalsustele lisaks oleks vaja, et lepingu eesmärgid sätestada.
15.
Selgitage, mida hankija hindab pakkujalt oodatava sisendi „milliseid funktsionaalsusi tuleb juurde arendada.“ puhul. Mida hankija pakkuja pakkumusest ootas ning mida täpsemalt hinnati
Pakkuja pidi esitama hinnangu, milliseid funktsionaalsui lisaks kohustuslikele oleks veel vaja, et lepingu eesmärk saavutada. Ehk siis hankija poolt tehnilises kirjelduses kirjeldatu oli hankijale teadaolevad vajadused, kuid pakkujal oli võimalik selgitada, kas pakkuja hinnangul oleks veel funktsionaalsusi, mida peaks arendama.
16.
Hindamiskriteeriumina on hankija sätestanud järgmise kriteeriumi 3. Täiendavate arendustööde teostamise aeg 10%
-
17.
Selgitage, kus RHADis on lahti selgitatud, millised on täiendavad arendustööd? Kui luuakse uus Äpp ehk rakendus, siis mida saab siinkohal täiendada? Vt vastust 5.
Hankija eelduseks oli eeldatavast maksumusest tulenevalt, et pakutakse juba olemasolevat lahendust, mida kohaldatakse hankija vajadustele vastavalt tehnilisele kirjeldusele. Uue arenduse teostamine ei olnud välistatud, kuid hankijale teadaolevalt oleks see osutunud kallimaks.

Seega pidi esitama pakkuja aja, mis kulub täiendavate arendustööde tegemiseks selliselt, et hankija saaks asuda kasutama kõiki prioriteet I funktsionaalsusi pakutava perioodi järel ehk maksimaalselt 90 päeva jooksul.

Kuivõrd antud hange oli kordushange (esimene hange viitenumbriga 258333) , siis oli tekkinud juba kasutajatel ootus uue rakenduse järele, mistõttu pidas hankija vajalikuks ka hinnata rakenduse kasutusele võtmise kiirust. Ühtlasi oli ajasurve tulenev ka välisrahastuse abikõlblikkuse perioodi piirangutest, mille sisse pidi hankija kõikide vajalike tegevustega jõudma. Esimene hange nurjus, kuna seal ei olnud piisavalt täpselt lahti kirjeldatud, mis tähtajaks lisaarendused valmis peavad olema. Samuti oli hankija ebaselgelt sätestanud soetatava teenuse tingimused just sellest vaatest, kui palju on vajalik olemasolevale rakendusele teha lisaarendusi selleks, et see vastaks hankija nõuetele. Täpsustati seega majutuse tingimusi ja asjaolu, et tegemist on selgelt kasutuslitsentsiga, mitte hankijale üleantava tootega.

Hankemenetluse kehtetuks tunnistamise otsuse väljavõte: „Pakkumuste läbivaatamisel on hankija tuvastanud, et hankes on jäänud hankijast tulenevalt küsimata täiendavat töötunni tasu ning arendustööde teostamise ajaraam. Seetõttu ei ole tagatud õiglane konkurents, pakkumuste ühetaoline menetlemine ja hindamine ega võimalik täita tõsikindlalt hankemenetluse eesmärki. Lisaks ei olnud hankija sätestanud üheselt mõistetavalt samaväärsusega seotud aspekte, millest tulenevalt ei pruukinud olla hankes tagatud konkurents.“
18.
Kas täiendavad tööd on TKs nimetatud I ja II prioriteedi töödele lisanduvad tööd?
Hankija on hindamiskriteeriumis selgitanud „Täiendavate arendustööde teostamise aeg on kuni 90 päeva.“, mis viitab sellele, et tegemist on tehnilise kirjelduse p-s 4.3.2 nimetatud töödega.
19.
Hindamiskriteeriumina on hankija sätestanud järgmise kriteeriumi 4: Arendusteenuse, sh konsultatsiooni ühe töötunni maksumus
-
20.
Milliste tööde puhul on tegemist arendustööga? Kus RHADis on arendustööde mõiste selgitatud?
Raamlepingu p 5 sätestab tööde tellimise, mis sisaldab endas vajaduspõhiselt ka arendustööde tellimist. Arendustööd on sellised tööd raamlepingu perioodil, mis ei ole sätestatud esimese hankelepingu funktsionaalsuste skoobis ning mille järele hankijal tekib vajadus raamlepingu perioodil.

Raamlepingu p 4.2. selgitab ka, et töötunni hind on nii arendustööde kui konsulteerimistööde hind. „Raamlepingu kehtivuse ajal on ühe töötunni maksimaalne hind käibemaksuta vastavalt pakkumusele xx,xx (summa sõnadega) eurot. Töötund hõlmab endas nii arendust kui konsulteerimist.“
21.
Kui arendustööde mõiste ja sisu ei ole RHADis avaldatud, selgitage, kuidas saab pakkuja pakkuda arendustööde tunni maksumust, teadmata tööde mahtu ning sisu?
Arendustööd on laialt levinud mõiste ning olukorras, kus soetatakse olemasoleval platvormil kohandatud funktsionaalsusega äppi ehk rakendust, siis on võimalik tuvastada, et kõik valdkonna spetsialistid saanuks sellest sättest ja hindamiskriteeriumist samamoodi aru ehk tegemist on lisaarendustega olemasoleva rakenduse funktsionaalsustesse.
22.
Hindamiskriteeriumina on hankija sätestanud järgmise kriteeriumi 5. Pakutava toote nõuetele vastavusse viimise arendustööde maksumus 20%.
-
23.
Kas hankija eeldab, et pakkuja esitab juba osaliselt valmisoleva töö, mis ei vasta hankes seatud tingimustele ning esitab maksumuse, millega viiakse mittevastav töö RHADis esitatu I ja II prioriteedi nõuetega vastavusse?
Jah, kuivõrd olemasoleva rakenduse platvormile hankija nõuete arendamine on soodsam, kui rakenduse täielik väljaarendamine. Maailmas on sarnaseid tooteid ja rakendusi olemas, mistõttu oli hanke eeldatavat maksumust silmas pidades asjakohane võtta kasutusele kohendustega juba midagi, mis eksisteerib.
24.
Kas pakkuda võinuks ka nn nulllahendust, kus ei ole veel midagi ette loodud, vaid hakatakse looma rakendust alles konkreetse hanke nõudeis silmas pidades?
Jah, pakkuja oleks võinud öelda, et teeb kolme kuuga valmis rakenduse tellija soovidele vastavalt ning edaspidi pakub haldusteenuse raames selle kasutuslitsentsi hankijale.
25.
Vastavustingimused
-
26.
Vastavustingimus nr 3) Pakkuja esitab tehnilisele kirjeldusele vastava pakkumuse ning tervikprojekti kirjelduse. (Vabas vormis dokument)
Kas hankija on silmas pidanud, et tervikprojekt tuleb esitada nii I kui II prioriteedi tööde kohta, kuna mõlemad sisalduvad tehnilises kirjelduses.
Jah, „tervikprojekt“ viitab hankija soovile saada täielik ülevaade projektist, st nii prioriteetide I kui ka II lahendustest ja ajakavast.
27.
Vastavustingimus nr 4) Pakkuja esitab oma poolsed hankelepingu sõlmimise tüüptingimused ja/või hankelepingu vormi. (Vabas vormis dokument)
Selgitage, miks hankija pidas vajalikuks pakkujapoolset hankelepingu esitamist, kui RHS § 77 lg 4 kohaselt on hankelepingutingimised RHADi osa.
On tavapärane, et litsentsipakkujatel on oma väljatöötatud tüüptingimused, mis on just nende toote spetsiifilised. Sellest tulenevalt on hankija RHAD-s lisanud nii raamlepingu kui ka hankelepingu projekti, mis on täielikult kohalduvad ning andnud võimaluse pakkujal neid täiendada oma tüüptingimustega, mis kaasnevad pakutava toote kasutamisega. Seda nägi hankija ette juba hanketeatega, seega on see olukord kooskõlas RHS § 77 lg 4 p 4. Samuti on hankija lisateabefailis selgitanud, et kui hankija on sõnaselgelt võimaldanud alternatiivsete pakkumiste esitamist, siis on see lubatav ning tüüptingimuste puhul tehtud vastav erisus on kooskõlas ka RHS § 77 lg 4 p 3.
28.
Olelursingi kulud- kas ja millises RHADi dokumendis on hankija sätestanud olelusringi kuludega arvestamise/mittearvestamise. Mittearvestamise puhul esitage olelusringi kuludega mittearvestamise põhjendus.
RHS § 85 lg 6 sätestab, et tarkvaralahenduste hankimisel arvestab hankija majanduslikult soodsaima pakkumuse väljaselgitamisel lisaks pakkumuse hinnale ka olelusringi kulusid vastavalt käesoleva seaduse §-s 86 sätestatule või põhjendab riigihanke alusdokumentides olelusringi kulude arvestamata jätmist.
Hankija ei teinud seda seetõttu, et hankija ei hankinud tarkvara arendust RHS § 85 lg 6 mõttes. Hankija hankis sisuliselt tõlketeenuse rakenduse litsentsi, mille eelduseks oli rakenduse kohandamine hankija vajadustele koos võimalusega ka edaspidi hankijale vajalike arendustööde teostamist täitjale kuuluvas rakenduses. Hankija ei saa endale lepingu tulemusel mistahes arendust ega pea seda ka ülal pidama, mistõttu olelusringi kulude arvestamine ei olnud vajalik ning hankijal puudus kohustus nende arvestamata jätmist ka põhjendada.
29.
Kõrvaldamise aluste kontroll
eCertise andmetel on Tsehhi Vabariigis võimalik esitada erinevaid kõrvalamise aluste puudumist tõendavaid dokumente. Antud juhul on edukas pakkuja esitanud vaid maksuvõlgade puudumise ning kahe ettevõttega seotud eraisiku karistatuse puudumise tõendid, mis ei ole piisavad kõrvaldamise aluste puudumise tõendamiseks.
Puudu on ettevõtte karistatuse puudumise kohta tõend, mida eCertise andmetel saab pakkujariigilt välja küsida.

Esitage palun pakkuja ettevõtte kohta kõrvaldamise aluste puudumise tõend tagantjärele kui see on pakkumuse kontrollistaadiumis jäänud esitamata.


Hankija edastab pakkuja poolt esitatud tõendi, mille abil on tuvastatav muuhulgas riigihanke läbiviimise ja hankelepingu sõlmimise ajahetkel kõrvaldamise aluste puudumine.
30.
RHADist tervikuna jääb mulje, justkui hankija oleks arvestanud juba ette eduka pakkuja olemasoleva lahendusega, mida on vaja hankijale sobivaks arendada. Kordagi ei jää muljet, et RHAD oleks koostatud arvestades alles nn turule tulevaid pakkujaid, kes alustanuks nn nullist rakenduse loomisega.
Seda tõdemust kinnitab ka hankijapoolne I prioriteedi nõuete suur hulk ja väga lühike teostamise tähtaeg (90 päeva maksimaalselt, mida mh hinnati), ehk siis nullist toote loomine ei ole sellise ajaplaani juures võimalik.
Vastavaks tunnistatud pakkumuse on esitanud vaid üks pakkuja. Juhime tähelepanu, et keelatud on koostada tehniline kirjeldus nii, et see on konkreetsele ettevõtjale sobiv ja soosib vaid ühte konkreetset pakkujat.
Palun selgitada, kuidas olete taganud, et tehniline kirjeldus on koostatud objektiivselt ja kõigile vastavas valdkonnas tegutsevatele ettevõtjatele võrdselt (RHS § 88 lg 1 ja 7).
Kas hankijal on teadmine, et mõni teine pakkuja vastaks reaalselt sammuti kõikidele üksikasjalikele hankes seatud tingimustele arvestusega, et on suuteline teostama tööd 90 päeva jooksul?

Selgitage, millistele tõenditele tuginedes hindab hankija, et hankes seatud kitsas ajaraam (teostada I prioriteedi tööd 90 päeva jooksul) POLE piirav ning konkurentsi ahendav hanketingimus.

RHAD arvestas tõepoolest sellega, et pakutakse olemasolevat rakendust, mitte nullist tehtud lahendust, kuivõrd see on soodsam. See aga ei ole korrektne järeldus, et selle rakenduse pidi pakkuma just edukas pakkuja. Rakendusi, mida saanud hankija vajadustele kohaldada, on rohkemgi ning iga soovija oleks saanud seda teha.
Asjaolu, et hankija oli tuvastanud soodsama lahenduse ning soovis seda just selliselt ka hankida, st olemasoleva rakenduse kohandustega, mitte uue arenduse, ei ole võimalik hankijale ette heita. Hankijal on kohustus riigi ja ka Euroopa Liidu vahendeid kasutada mõistlikult ja säästlikult. Sisuliselt olemasoleva rakenduse nullist arendamise nõudmine seda RHS § 3 põhimõtet kindlasti ei täitnuks.
Hankija ei soovi võtta seisukohta selle osas, kas keegi saanuks nullist soovi korral arendada vajaliku rakenduse etteantud ajaraamis või mitte, kuivõrd hankija ei varjagi kuidagi soovi soetada olemasolevat rakendust kohendustega. Siin ei tohi aga asuda ekslikule arusamaale, et hankija soovis just eduka pakkuja lahendust. Hankija soovis mistahes valmis rakendust hankija nõuetele vastavusse viimise järel.
Lisaks pakkujale oli hanke eelselt teada, et sellise teenuse pakkumise võimekus on ka vähemalt Rootsi ettevõttel nWise, keda oodati hankes osalema.

Esiteks märgib hankija, et hankijal ei ole kohustus hankida ebamõistlikku teenust ehk nullist arendamist juhul, kui eksisteerib soodsamaid ja mõistlikemaid lahendusi (olemasoleva rakenduse kohandamine). Teiseks on hankija viinud teadlikult läbi hanke inglise keeles, et see jõuaks võimalikult paljude potentsiaalsete pakkujateni, kes saaksid tulla oma lahendusi pakkuma. On näha, et hankel oli kaks huvilist veel - OÜ TEHNILISE TÕLKE KESKUS ja Mobi Lab OÜ.

Seega on hankija seisukohal, et võimalikult soodsa lahenduse hankimiseks läbiviidud hanke puhul ei ole tegemist kuidagi piirava hankega – vastupidi, hankija tegi kõik endast oleneva, et oleks võimalik saavutada kiiresti vajaliku teenuse olemasolu, mõistliku hinnaga teenus ning võimalikult lai konkurents tõlgitud hankedokumentide abil. Hankija ei saa kahjuks anda sisendit sellest, miks keegi pakkumuse esitamata jättis.
31.
Hankija on seadnud vastavustingimuse, mille kohaselt peab pakkuja esitama omapoolsed hankelepingu sõlmimise tüüptingimused ja/või hankelepingu vormi.

Juhin tähelepanu, et RHS § 77 kohaselt peab hankija lepingutingimused esitama RHADis ning hilisemalt tuleb poolte vahel sõlmida leping RHADis esitatud tingimuste kohaselt. Pakkujapoolne lepingutingimuste esitamine on vaadeldav tingimusliku pakkumusena juhul kui pakkujapoolsed tingimused erinevad hankijapoolsetest RHADis esitatud tingimustest. Minu hinnangul on pakkuja poolt esitatud tingimused osaliselt vastuolus pakkujapoolsete RHADis esitatud tingimustega.

Siinjuures palun hankijal kinnitada, et hankija ei ole lähtunud lepingu täitmisel ega sõlmimisel pakkuja poolt esitatud lepingutingimustest.
Hankija selgitas juba eespool, miks põhjusel pakkuja võis oma tüüptingimused esitada ning see oli lubatav alternatiivne lahendus. Küll aga on selge, et hankija sõlmis nii raam- kui ka hankelepingu oma põhjal ning kõik nendes olevad tingimused on selgelt ülimuslikud juba raamlepingu p 2.3 tulenevalt. „Kui hankelepingu tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks hankelepingu tingimus. Kui lepingu lisades esinevad tingimused erinevad lepingu tingimustest, loetakse ülimuslikuks lepingu tingimus.“
Seega kui pakkuja esitatud dokumentides on vastuolusid raam- või hankelepingu tingimustega, siis on need raamlepingu kohaselt automaatselt tühised. Hankija kinnitab, et lepingu täitmisel lähtutakse eeskätt hankelepingust, seejärel raamlepingust ja kolmandas järgus kõikidest raamlepingus nimetatud lisadest, sh pakkuja poolsetest tüüptingimustest.

Jrk
Küsimus
Vastus
1.
Hankija on TK punktis 4.3.2. märkinud järgmist: Tabelis 1 on toodud I ja II prioriteedi nõuded. I prioriteedi nõuded on kohustuslikud ja peavad olema valmis või pakkuja peab olema valmis neid teostama enne lansseerimist, so maksimaalselt 90 päeva jooksul pärast lepingu sõlmimist. II prioriteedi tööd tuleb pakkujal välja tuua eraldi.
Küsimust ei ole I etapi töödes, mille sisu on TKs detailselt kirjeldatud.
-
2.
Selgitage, mida on hankija silmas pidanud korralduse all: II prioriteedi tööd tuleb pakkujal välja tuua eraldi?
Hankija viitab sellega sellele, et II prioriteedi tööd ei pea olema valmis samal ajal, kui I prioriteedi tööd, s.o 90 päeva jooksul. II prioriteedi töödele oli pakkujal võimalus esitada oma ajaraam ning soovi korral täpsem kirjeldus, kuidas ja millal töid teostatakse. Tööde funktsionaalsus ehk nõuded on hankija poolt piisavalt selgitatud, et selles konkreetses skoobis ei olnud võimalik pakkujal kaasa rääkida ning hankija seda ka ei oodanud.
3.
Selgitage, kus on antud pakkujale/töövõtjale RHADis sisend, milliste töödega peab töövõtja II etapis arvestama?
II prioriteedi tööd on nimetatud TK p 4.3.2.12, 4.3.2.13 ja 4.3.2.14 ning p 4.3.2 korraldus viitabki sellele, et pakkumuse koosseisus tuleb vastavustingimuse nr 1 küsimuse nr 3 vastusena see esitada. Nendes punktides on nimetatud funktsionaalsused, mis peavad äpil olema, mistõttu need ongi tööd, millega peab arvestama.
4.
Kas ma saan õigesti aru, et TKs toodud II prioriteedi tööd punktides 4.3.2.12-4.3.2.14 on tööde üldine nimetus? Mida siia lisama peaks veel pakkuja?
Jah, olete õigesti aru saanud, et prioriteedi II tööd on TK viidatud punktides. Tööde sisu on samuti nendes punktides, st tegemist ei ole üldiste nimetustega, vaid konkreetsete funktsionaalsustega, mis on kirjeldatud sama detailsusastmega kui I prioriteedi tööd. I prioriteedi töödel on ajaline piirang, kuna need on põhifunktsionaalsused, milleta teenust pakkuda ei saa. II prioriteedi tööd on olulised, ent on võimalik alustada teenuse pakkumisega I prioriteedi funktsionaalsusega.

Pakkumuse koosseisus esitatud dokument 1.3 vahelehel „Functional requirements“ ridadel 45-47 on pakkuja seda käsitlenud ning kohustusest aru saanud samamoodi, nagu hankija seda ette nägi. Pakkuja pidi lisama, mis ajaraamis tööd teostatud saavad, kuivõrd prioriteedi II tööd ei pidanud jääma 90 päeva sisse, nagu prioriteedi I tööd. Pakkuja siiski valis teostada need samas ajaraamis I prioriteedi töödega.
5.
Selgitage, kui 90 päeva jooksul lepingu sõlmimisest peavad I prioriteedi tööd olema teostatud, siis milliste töödega sisustab töövõtja ülejäänud raamlepingu perioodi?
Tellija võib ülejäänud perioodi tellida lisaarendusi. Näiteks, kui teenuse kasutamise käigus ilmneb, et mingi funktsionaalsus on puudu, mis teeks kasutaja elu mugavamaks.
6.
RHADis on sätestatud järgmised tingimused:
Raamlepingust:
2.3. Kui hankelepingu tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks hankelepingu tingimus. Kui lepingu lisades esinevad tingimused erinevad lepingu tingimustest, loetakse ülimuslikuks lepingu tingimus.
2.8. Kui lepingu täitmisel tekivad täitja ja tellija vahel erimeelsused, lähtutakse hankelepingu eesmärkidest esmalt tellija seisukohalt, võttes arvesse hanke alusdokumentides määratletud eesmärki ja sisu.
-
7.
Selgitage, kas ülal nimetatud punktised mainitud olukordi esines?
Ei, selliseid olukordi ei ole esinenud.
8.
Kui jah, kirjeldage olukorda ning esitage olukorra lahenduskäik.
-
9.
Hindamiskriteeriumina on hankija sätestanud järgmise kriteeriumi 1: Haldusteenuse ühe aasta maksumus. 40%-
Hankija hindab haldusteenuse maksumust, kuid ei ole kirjeldanud RHADis detailsemalt, milliseid töid haldusteenus peaks sisaldama.
-
10.
Selgitage, millises RHAD dokumendis on selgitatud, milliseid töid haldusteenus peaks sisaldama.
Haldusteenuseks lepingu kontekstis on tasu iga-aastase kasutamise eest lepingu alusel valminud teenuste funktsionaalsuste osas ehk siis tasu selle eest, et meil on võimalik lepingu eset kasutada ning teenus on kättesaadav eri platvormidel.
11.
Selgitage, millises RHAD dokumendis on sätestatud töövõtja kohustus neid töid teostada.
Raamlepingu p 4.1 sätestab aastatasu. Samale aastatasule viitab esimese hankelepingu ptk 3. Teenuse kirjeldus on toodud tehnilises kirjelduses. Pakkuja pakkuski hankijale tehnilise kirjelduse alusel haldusteenuse, mille raames kohandati pakkuja olemasolev toode 90 päeva jooksul vastavaks hankija vajadustele, misjärel pakub pakkuja seda toodet edasi haldusteenuse hinna alusel ning vajadusel eraldi tellitavate tööde puhul rakendatakse töötunni hinda.
12.
Hindamiskriteerium nr 2: tervikprojekti kirjeldus. Punktide omistamise kirjeldus ütleb omakorda, et hankija hindab pakkumuses: tervikprojekti kirjeldusest on selgelt aru saada, kuidas ja milliseid muudatusi tuleb teha kogu projekti käigus ning milliseid funktsionaalsusi tuleb juurde arendada.
-
13.
Saan aru, et hetkel on sarnase teenuse tarvitamiseks kasutusel Skype lahendus, mis soovitakse asendada Äpiga. Ehk siis ei saa olemasolevat lahendust ei muuta ega täiendada/arendada.
Jah, kasutusel on hetkel Skype, mis asendati hankelepingu raames osutatava teenusega ehk äpiga. Olemasoleva lahenduse funktsionaalsusi soovis hankija ikkagi ka uue lahenduse juures rakendada, seega olemasolevat lahendust küll ei täiendatud, kuid selle funktsionaalsused võeti üle uude lahendusse.
14.
Selgitage, mida hankija peab silmas hindamisel „kuidas ja milliseid muudatusi tuleb teha kogu projekti käigus“. Kui olemasolevat lahendust ei täiendata, vaid luuakse uus, siis mis sordi muudatustest saab jutt käia? Mida hankija pakkuja pakkumusest ootas ning mida täpsemalt hinnati.
Olemasoleva lahenduse funktsionaalsused on siiski üle võetavad ja kasutatavad ka uuel lahendusel. See tähendab, et hoolimata varasema lahenduse edasi arendamata jätmisest ei jäeta kõrvale selles toiminud funktsionaalsusi ning võimalusel kasutatakse neid ka edasi. Muudatused ongi seotud seega dokumentides ka just funktsionaalsustega, mitte konkreetse süsteemiga. Seega hankija ootus oli, et pakkuja selgitab, mida olemasolevates funktsionaalsustes tuleks muuta, et saavutada lepingu eesmärk. Samuti on oluline tähele panna, et hankija eeldas, et pakutakse suuresti olemasoleva äpi platvormile tehtavaid hankijale vajalikke funktsionaalsustega lahendust. Seega oli pakkuja kohustuseks juhul, kui arendus tehakse olemasolevale platvormile, anda teada, milliseid funktsionaalsusi muudetakse. Kui pakkuja arendaks algusest, siis tulnuks jääda üksnes selle selgituse juurde, mida nõuetes esitatud funktsionaalsustele lisaks oleks vaja, et lepingu eesmärgid sätestada.
15.
Selgitage, mida hankija hindab pakkujalt oodatava sisendi „milliseid funktsionaalsusi tuleb juurde arendada.“ puhul. Mida hankija pakkuja pakkumusest ootas ning mida täpsemalt hinnati
Pakkuja pidi esitama hinnangu, milliseid funktsionaalsui lisaks kohustuslikele oleks veel vaja, et lepingu eesmärk saavutada. Ehk siis hankija poolt tehnilises kirjelduses kirjeldatu oli hankijale teadaolevad vajadused, kuid pakkujal oli võimalik selgitada, kas pakkuja hinnangul oleks veel funktsionaalsusi, mida peaks arendama.
16.
Hindamiskriteeriumina on hankija sätestanud järgmise kriteeriumi 3. Täiendavate arendustööde teostamise aeg 10%
-
17.
Selgitage, kus RHADis on lahti selgitatud, millised on täiendavad arendustööd? Kui luuakse uus Äpp ehk rakendus, siis mida saab siinkohal täiendada? Vt vastust 5.
Hankija eelduseks oli eeldatavast maksumusest tulenevalt, et pakutakse juba olemasolevat lahendust, mida kohaldatakse hankija vajadustele vastavalt tehnilisele kirjeldusele. Uue arenduse teostamine ei olnud välistatud, kuid hankijale teadaolevalt oleks see osutunud kallimaks.

Seega pidi esitama pakkuja aja, mis kulub täiendavate arendustööde tegemiseks selliselt, et hankija saaks asuda kasutama kõiki prioriteet I funktsionaalsusi pakutava perioodi järel ehk maksimaalselt 90 päeva jooksul.

Kuivõrd antud hange oli kordushange (esimene hange viitenumbriga 258333) , siis oli tekkinud juba kasutajatel ootus uue rakenduse järele, mistõttu pidas hankija vajalikuks ka hinnata rakenduse kasutusele võtmise kiirust. Ühtlasi oli ajasurve tulenev ka välisrahastuse abikõlblikkuse perioodi piirangutest, mille sisse pidi hankija kõikide vajalike tegevustega jõudma. Esimene hange nurjus, kuna seal ei olnud piisavalt täpselt lahti kirjeldatud, mis tähtajaks lisaarendused valmis peavad olema. Samuti oli hankija ebaselgelt sätestanud soetatava teenuse tingimused just sellest vaatest, kui palju on vajalik olemasolevale rakendusele teha lisaarendusi selleks, et see vastaks hankija nõuetele. Täpsustati seega majutuse tingimusi ja asjaolu, et tegemist on selgelt kasutuslitsentsiga, mitte hankijale üleantava tootega.

Hankemenetluse kehtetuks tunnistamise otsuse väljavõte: „Pakkumuste läbivaatamisel on hankija tuvastanud, et hankes on jäänud hankijast tulenevalt küsimata täiendavat töötunni tasu ning arendustööde teostamise ajaraam. Seetõttu ei ole tagatud õiglane konkurents, pakkumuste ühetaoline menetlemine ja hindamine ega võimalik täita tõsikindlalt hankemenetluse eesmärki. Lisaks ei olnud hankija sätestanud üheselt mõistetavalt samaväärsusega seotud aspekte, millest tulenevalt ei pruukinud olla hankes tagatud konkurents.“
18.
Kas täiendavad tööd on TKs nimetatud I ja II prioriteedi töödele lisanduvad tööd?
Hankija on hindamiskriteeriumis selgitanud „Täiendavate arendustööde teostamise aeg on kuni 90 päeva.“, mis viitab sellele, et tegemist on tehnilise kirjelduse p-s 4.3.2 nimetatud töödega.
19.
Hindamiskriteeriumina on hankija sätestanud järgmise kriteeriumi 4: Arendusteenuse, sh konsultatsiooni ühe töötunni maksumus
-
20.
Milliste tööde puhul on tegemist arendustööga? Kus RHADis on arendustööde mõiste selgitatud?
Raamlepingu p 5 sätestab tööde tellimise, mis sisaldab endas vajaduspõhiselt ka arendustööde tellimist. Arendustööd on sellised tööd raamlepingu perioodil, mis ei ole sätestatud esimese hankelepingu funktsionaalsuste skoobis ning mille järele hankijal tekib vajadus raamlepingu perioodil.

Raamlepingu p 4.2. selgitab ka, et töötunni hind on nii arendustööde kui konsulteerimistööde hind. „Raamlepingu kehtivuse ajal on ühe töötunni maksimaalne hind käibemaksuta vastavalt pakkumusele xx,xx (summa sõnadega) eurot. Töötund hõlmab endas nii arendust kui konsulteerimist.“
21.
Kui arendustööde mõiste ja sisu ei ole RHADis avaldatud, selgitage, kuidas saab pakkuja pakkuda arendustööde tunni maksumust, teadmata tööde mahtu ning sisu?
Arendustööd on laialt levinud mõiste ning olukorras, kus soetatakse olemasoleval platvormil kohandatud funktsionaalsusega äppi ehk rakendust, siis on võimalik tuvastada, et kõik valdkonna spetsialistid saanuks sellest sättest ja hindamiskriteeriumist samamoodi aru ehk tegemist on lisaarendustega olemasoleva rakenduse funktsionaalsustesse.
22.
Hindamiskriteeriumina on hankija sätestanud järgmise kriteeriumi 5. Pakutava toote nõuetele vastavusse viimise arendustööde maksumus 20%.
-
23.
Kas hankija eeldab, et pakkuja esitab juba osaliselt valmisoleva töö, mis ei vasta hankes seatud tingimustele ning esitab maksumuse, millega viiakse mittevastav töö RHADis esitatu I ja II prioriteedi nõuetega vastavusse?
Jah, kuivõrd olemasoleva rakenduse platvormile hankija nõuete arendamine on soodsam, kui rakenduse täielik väljaarendamine. Maailmas on sarnaseid tooteid ja rakendusi olemas, mistõttu oli hanke eeldatavat maksumust silmas pidades asjakohane võtta kasutusele kohendustega juba midagi, mis eksisteerib.
24.
Kas pakkuda võinuks ka nn nulllahendust, kus ei ole veel midagi ette loodud, vaid hakatakse looma rakendust alles konkreetse hanke nõudeis silmas pidades?
Jah, pakkuja oleks võinud öelda, et teeb kolme kuuga valmis rakenduse tellija soovidele vastavalt ning edaspidi pakub haldusteenuse raames selle kasutuslitsentsi hankijale.
25.
Vastavustingimused
-
26.
Vastavustingimus nr 3) Pakkuja esitab tehnilisele kirjeldusele vastava pakkumuse ning tervikprojekti kirjelduse. (Vabas vormis dokument)
Kas hankija on silmas pidanud, et tervikprojekt tuleb esitada nii I kui II prioriteedi tööde kohta, kuna mõlemad sisalduvad tehnilises kirjelduses.
Jah, „tervikprojekt“ viitab hankija soovile saada täielik ülevaade projektist, st nii prioriteetide I kui ka II lahendustest ja ajakavast.
27.
Vastavustingimus nr 4) Pakkuja esitab oma poolsed hankelepingu sõlmimise tüüptingimused ja/või hankelepingu vormi. (Vabas vormis dokument)
Selgitage, miks hankija pidas vajalikuks pakkujapoolset hankelepingu esitamist, kui RHS § 77 lg 4 kohaselt on hankelepingutingimised RHADi osa.
On tavapärane, et litsentsipakkujatel on oma väljatöötatud tüüptingimused, mis on just nende toote spetsiifilised. Sellest tulenevalt on hankija RHAD-s lisanud nii raamlepingu kui ka hankelepingu projekti, mis on täielikult kohalduvad ning andnud võimaluse pakkujal neid täiendada oma tüüptingimustega, mis kaasnevad pakutava toote kasutamisega. Seda nägi hankija ette juba hanketeatega, seega on see olukord kooskõlas RHS § 77 lg 4 p 4. Samuti on hankija lisateabefailis selgitanud, et kui hankija on sõnaselgelt võimaldanud alternatiivsete pakkumiste esitamist, siis on see lubatav ning tüüptingimuste puhul tehtud vastav erisus on kooskõlas ka RHS § 77 lg 4 p 3.
28.
Olelursingi kulud- kas ja millises RHADi dokumendis on hankija sätestanud olelusringi kuludega arvestamise/mittearvestamise. Mittearvestamise puhul esitage olelusringi kuludega mittearvestamise põhjendus.
RHS § 85 lg 6 sätestab, et tarkvaralahenduste hankimisel arvestab hankija majanduslikult soodsaima pakkumuse väljaselgitamisel lisaks pakkumuse hinnale ka olelusringi kulusid vastavalt käesoleva seaduse §-s 86 sätestatule või põhjendab riigihanke alusdokumentides olelusringi kulude arvestamata jätmist.
Hankija ei teinud seda seetõttu, et hankija ei hankinud tarkvara arendust RHS § 85 lg 6 mõttes. Hankija hankis sisuliselt tõlketeenuse rakenduse litsentsi, mille eelduseks oli rakenduse kohandamine hankija vajadustele koos võimalusega ka edaspidi hankijale vajalike arendustööde teostamist täitjale kuuluvas rakenduses. Hankija ei saa endale lepingu tulemusel mistahes arendust ega pea seda ka ülal pidama, mistõttu olelusringi kulude arvestamine ei olnud vajalik ning hankijal puudus kohustus nende arvestamata jätmist ka põhjendada.
29.
Kõrvaldamise aluste kontroll
eCertise andmetel on Tsehhi Vabariigis võimalik esitada erinevaid kõrvalamise aluste puudumist tõendavaid dokumente. Antud juhul on edukas pakkuja esitanud vaid maksuvõlgade puudumise ning kahe ettevõttega seotud eraisiku karistatuse puudumise tõendid, mis ei ole piisavad kõrvaldamise aluste puudumise tõendamiseks.
Puudu on ettevõtte karistatuse puudumise kohta tõend, mida eCertise andmetel saab pakkujariigilt välja küsida.

Esitage palun pakkuja ettevõtte kohta kõrvaldamise aluste puudumise tõend tagantjärele kui see on pakkumuse kontrollistaadiumis jäänud esitamata.


Hankija edastab pakkuja poolt esitatud tõendi, mille abil on tuvastatav muuhulgas riigihanke läbiviimise ja hankelepingu sõlmimise ajahetkel kõrvaldamise aluste puudumine.
30.
RHADist tervikuna jääb mulje, justkui hankija oleks arvestanud juba ette eduka pakkuja olemasoleva lahendusega, mida on vaja hankijale sobivaks arendada. Kordagi ei jää muljet, et RHAD oleks koostatud arvestades alles nn turule tulevaid pakkujaid, kes alustanuks nn nullist rakenduse loomisega.
Seda tõdemust kinnitab ka hankijapoolne I prioriteedi nõuete suur hulk ja väga lühike teostamise tähtaeg (90 päeva maksimaalselt, mida mh hinnati), ehk siis nullist toote loomine ei ole sellise ajaplaani juures võimalik.
Vastavaks tunnistatud pakkumuse on esitanud vaid üks pakkuja. Juhime tähelepanu, et keelatud on koostada tehniline kirjeldus nii, et see on konkreetsele ettevõtjale sobiv ja soosib vaid ühte konkreetset pakkujat.
Palun selgitada, kuidas olete taganud, et tehniline kirjeldus on koostatud objektiivselt ja kõigile vastavas valdkonnas tegutsevatele ettevõtjatele võrdselt (RHS § 88 lg 1 ja 7).
Kas hankijal on teadmine, et mõni teine pakkuja vastaks reaalselt sammuti kõikidele üksikasjalikele hankes seatud tingimustele arvestusega, et on suuteline teostama tööd 90 päeva jooksul?

Selgitage, millistele tõenditele tuginedes hindab hankija, et hankes seatud kitsas ajaraam (teostada I prioriteedi tööd 90 päeva jooksul) POLE piirav ning konkurentsi ahendav hanketingimus.

RHAD arvestas tõepoolest sellega, et pakutakse olemasolevat rakendust, mitte nullist tehtud lahendust, kuivõrd see on soodsam. See aga ei ole korrektne järeldus, et selle rakenduse pidi pakkuma just edukas pakkuja. Rakendusi, mida saanud hankija vajadustele kohaldada, on rohkemgi ning iga soovija oleks saanud seda teha.
Asjaolu, et hankija oli tuvastanud soodsama lahenduse ning soovis seda just selliselt ka hankida, st olemasoleva rakenduse kohandustega, mitte uue arenduse, ei ole võimalik hankijale ette heita. Hankijal on kohustus riigi ja ka Euroopa Liidu vahendeid kasutada mõistlikult ja säästlikult. Sisuliselt olemasoleva rakenduse nullist arendamise nõudmine seda RHS § 3 põhimõtet kindlasti ei täitnuks.
Hankija ei soovi võtta seisukohta selle osas, kas keegi saanuks nullist soovi korral arendada vajaliku rakenduse etteantud ajaraamis või mitte, kuivõrd hankija ei varjagi kuidagi soovi soetada olemasolevat rakendust kohendustega. Siin ei tohi aga asuda ekslikule arusamaale, et hankija soovis just eduka pakkuja lahendust. Hankija soovis mistahes valmis rakendust hankija nõuetele vastavusse viimise järel.
Lisaks pakkujale oli hanke eelselt teada, et sellise teenuse pakkumise võimekus on ka vähemalt Rootsi ettevõttel nWise, keda oodati hankes osalema.

Esiteks märgib hankija, et hankijal ei ole kohustus hankida ebamõistlikku teenust ehk nullist arendamist juhul, kui eksisteerib soodsamaid ja mõistlikemaid lahendusi (olemasoleva rakenduse kohandamine). Teiseks on hankija viinud teadlikult läbi hanke inglise keeles, et see jõuaks võimalikult paljude potentsiaalsete pakkujateni, kes saaksid tulla oma lahendusi pakkuma. On näha, et hankel oli kaks huvilist veel - OÜ TEHNILISE TÕLKE KESKUS ja Mobi Lab OÜ.

Seega on hankija seisukohal, et võimalikult soodsa lahenduse hankimiseks läbiviidud hanke puhul ei ole tegemist kuidagi piirava hankega – vastupidi, hankija tegi kõik endast oleneva, et oleks võimalik saavutada kiiresti vajaliku teenuse olemasolu, mõistliku hinnaga teenus ning võimalikult lai konkurents tõlgitud hankedokumentide abil. Hankija ei saa kahjuks anda sisendit sellest, miks keegi pakkumuse esitamata jättis.
31.
Hankija on seadnud vastavustingimuse, mille kohaselt peab pakkuja esitama omapoolsed hankelepingu sõlmimise tüüptingimused ja/või hankelepingu vormi.

Juhin tähelepanu, et RHS § 77 kohaselt peab hankija lepingutingimused esitama RHADis ning hilisemalt tuleb poolte vahel sõlmida leping RHADis esitatud tingimuste kohaselt. Pakkujapoolne lepingutingimuste esitamine on vaadeldav tingimusliku pakkumusena juhul kui pakkujapoolsed tingimused erinevad hankijapoolsetest RHADis esitatud tingimustest. Minu hinnangul on pakkuja poolt esitatud tingimused osaliselt vastuolus pakkujapoolsete RHADis esitatud tingimustega.

Siinjuures palun hankijal kinnitada, et hankija ei ole lähtunud lepingu täitmisel ega sõlmimisel pakkuja poolt esitatud lepingutingimustest.
Hankija selgitas juba eespool, miks põhjusel pakkuja võis oma tüüptingimused esitada ning see oli lubatav alternatiivne lahendus. Küll aga on selge, et hankija sõlmis nii raam- kui ka hankelepingu oma põhjal ning kõik nendes olevad tingimused on selgelt ülimuslikud juba raamlepingu p 2.3 tulenevalt. „Kui hankelepingu tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks hankelepingu tingimus. Kui lepingu lisades esinevad tingimused erinevad lepingu tingimustest, loetakse ülimuslikuks lepingu tingimus.“
Seega kui pakkuja esitatud dokumentides on vastuolusid raam- või hankelepingu tingimustega, siis on need raamlepingu kohaselt automaatselt tühised. Hankija kinnitab, et lepingu täitmisel lähtutakse eeskätt hankelepingust, seejärel raamlepingust ja kolmandas järgus kõikidest raamlepingus nimetatud lisadest, sh pakkuja poolsetest tüüptingimustest.