+372 56 21 1146 info@agilecoach.ee

Merle Randlepp

Agile Coach

Merle Randlepp

Agile Coach

Kuidas koostada head veebihanget? Hindamiskriteeriumite valik22 min read

juuli 4, 2020 | blog

190 Views

Veebihanke hindamiskriteeriumid IT projektijuhile, kes hakkab uut hanket läbi viima

Viimasel ajal on mu töölauale sattunud järjest mitmeid veebihanke läbiviimise projekte, mille käigus olen tellijal aidanud koostada kas veebisaidi või mobiilirakenduse hanke dokumente, sh tehnilist lähteülesannet.

Kuna olen töötanud lõviosa oma tööelust veebiagentuurides ja kirjutanud kümneid ja kümneid riigihangete ja erasektori pakkumusi, on aja jooksul tekkinud päris hea pilt tüüpvigadest, mille otsa nii era- kui avaliku sektori tellijad tihtilugu komistavad.

Teiselt poolt, olles tellijate soovil läbi viinud erinevaid veebisaidi auditeid, näen kuidas probleemide algpõhjus on paraku juba hankesse sisse kirjutatud ning avaldab negatiivset mõju kogu projekti kulgemisele.

Teema valdkond on muidugi tohutult lai, aga hakkan otsast pihta. Alustame riigihangetest. Tellija tegevused on siin küll Riigihangete seadusega reguleeritud kuid vabadus koostada kvaliteetne veebihange on täiesti olemas ja teostatav.

Olen kindel, et pea iga hankija projektijuht, kelle ülesandeks on uue hanke läbiviimine, tahab olla targem IT tellija ja näha oma hankes palju tugevaid pakkujaid.
Nii et ma kirjutan seda juttu sulle, tellija veebi/IT projektijuht, kes sa hakkad uut veebihanget parajasti ette valmistama.

Hankija häid kavatsusi torpedeerivad tihtilugu terve rida takistusi, näiteks majasisesed eriarvamused või teadmatus hanketingimuste ja -kriteeriumide osas, klassikalise kolmiku – aja, eelarve, skoobi – fikseerimine, tehnilise kirjelduse puudulikkus, teadmatus moodsate veebitehnoloogiate trendidest, jne. Enamus vigu tekivad kas teadmatusest, kogemuse puudumisest, ajapuudusest või kahju küll, aga vahest ka ignorantsusest (“Ise tean, mis hanke kirjutan, küll agentuur pärast selle supi ära helbib”).

Tüüpviga nr 1 – hanke vastavustingimuste ja hindamiskriteeriumite vale valik

Räägime kõigepealt mõisted lahti.
Hankijal on võimalik parima koostööpartneri leidmiseks kasutada

  • kvalifitseerimistingimusi – minimaalsed nõuded, et pakkuja kvalifitseeruks
  • vastavustingimusi – minimaalsed nõuded pakkumise esitamise kohta
  • hindamiskriteeriumeid – kriteeriumid, mis on hankijale olulised ja ta soovib eluterve konkurentsi abil valida välja tugevaima pakkuja

Esimese asjana peab hankija otsustama kas hankeleping sõlmitakse majandusliku soodsuse või madalaima hinna kriteeriumi rakendades.
On oluline teada, et Riigihangete seadus eelistab just majanduslikku soodsust, mis püüab leida parima hinna ja kvaliteedi suhet.

Hankija, kes valib IT hankes madalaima hinna kriteeriumi, võib olla kindel, et suure tõenäosusega saab ta endale partneriks turul kõige odavama ja kehvema kvaliteediga arendaja.

Paraku tehakse seda ikka ja jälle ning seda ka IT hangetes. Miks ometi?

Pakun, et põhjusteks võivad olla laiskus (hindamiskriteeriumite väljamõtlemine, kaalumine ja kirjeldamine võtab aega), juristide vm mõjuisikute surve (nii on lihtsam, ärme riski, meil on eelarve piirid, teeme odavalt) ja teadmatus (meil on vastavustingimused paigas ja küll sellest piisab).

Ükskõik, mis on sinu põhjused, palun ära tee veebihankes odavhanget, sest ükski korralik pakkuja ei soovi sellel osaleda.
Jah, vahest harva nad siiski osalevad kui tegu on Eestis hästi tuntud kliendiga, keda nad soovivad väga oma portfelli, aga see on pigem erand kui reegel.

Millal siis üldse madalaimat hinda oleks mõistlik kasutada? Ainult juhul kui hankija kirjeldab hankelepingu eesmärki ammendavalt ning kõiki nõudeid üheseltmõistetavalt. Seetõttu sobib madalaim hind hindamiskriteeriumina eelkõige lihtsate hangete puhul, näiteks konkreetse asja ostu puhul. Veebihanked on aga oma olemuselt keerukamad ja siia madalaim hind ka ei sobi.

Kvalifitseerimis- ja vastavustingimused

Kvalifitseerimis- ja vastavustingimused peavad olema tasakaalus nii, et üle selle lati läheks läbi piisavalt suur kogus agentuure, kes saaksid hankel osaleda.
Neis tingimustes on ära toodud formaalsed nõuded (ühispakkumus, ärisaladuse märkimine, eesti keele nõue jms) ja sisulised nõuded. Sisulised nõuded võivad ka täielikult puududa, sellisel juhul tugineb võitja valik ainult hindamiskriteeriumitele.

Soovitan kasutada vastavustingimustes sisulisteks nõueteks selliseid valikuid:

  • meeskonna koosseis ja nõuded meeskonna kompetentsile

vajadusel ka:

  • sarnaste referentside arv, igaüks min nõutud käibega

Märkus: uuenenud Riigihanke seaduse järgi tohib küsida meeskonna  töökogemust üksnes vastavustingimustes (ja mitte kvalifitseerimistingimustes). 

 

Hindamiskriteeriumid

Kvalifitseerimis- ja vastavustingimustest pääseb läbi (ja peabki pääsema) piisavalt palju firmasid, kes on vastavas valdkonnas tegutsenud, sh odavpakkujad. Sinu ülesanne on nüüd määrata sellised hindamiskriteeriumid, mille alusel saad valida parima hinna ja kvaliteedi suhtega partneri.
Hangete osakonna hankespetsialistil või  juristil võib olla selles teemas sinust erinev arusaam, aga arutage põhjendused läbi ja ära unusta, et rakenduse kvaliteetse valmimise eest vastutad ju lõpuks sina ja mitte hankespetsialist.

Olulise argumendina saad märkida, et Euroopa Kohus on seisukohal (C-234/03), et hankijad on vabad valima nii lepingu sõlmimise kriteeriume kui ka otsustama nende kaalukuse üle määral, mis võimaldab kasutatud kriteeriumitele üldise hinnangu andmist, et selgitada välja majanduslikult soodsaim pakkumine.
Samuti on oluline teada, et majanduslikult soodsaima pakkumuse väljaselgitamiseks kasutatavad kriteeriumid ei pea olema ilmtingimata kvantitatiivsed, need võivad olla ka strateegia, meetodite, töövahendite, kvaliteetse keskkonna asjakohasus jmt kui need nõuded puudutavad teenuste nõuetekohast osutamist. Veebiarenduses on näiteks arendusmetoodika väga oluliseks komponendiks.

Hindamiskriteeriumite valik on lai, näiteks:

  • pakkumuse kogumaksumus
  • arendus- ja hooldustööde tunni hind
  • testülesanne (nt avalehe disain või tehniline ülesanne)
  • sarnaste referentside arv
  • meeskonna ülesehitus ja kompetents
  • arendusprotsessi korralduse ja metoodika kirjeldus sh riskiplaan
  • projektiplaani detailsus ja realistlikkus
  • pakkumuse struktuur, selle selgus ja täielikkus
  • jm

Hankijal tuleb iga kriteeriumi kohta lisada osakaal ja detailne hindamismetoodika kirjeldus.

Nagu näed, on hindamiskriteeriumite kaalumine ja valik oluliselt aeganõudvam tee kui lihtsalt madalaima hinna valik (lisaks on inimlik hirm eksida), aga korralik hanke ettevalmistus on sinu projekti edu aluseks. Leia see aeg ja hoiad hiljem probleemide klaarimise arvelt kümnekordselt aega ja raha kokku.

Soovitan valida välja 3-4 hindamiskriteeriumit, mis on konkreetse hanke jaoks kõige olulisemad. Tellijal on täielik vabadus valida neid oma vajadustest lähtuvalt, samuti määrata osakaale nii nagu õigeks peab. Toon igaühe kohta välja mõned mõtted ja mõistliku osakaalu vahemiku.

Pakkumuse kogumaksumus

Esimene ja kõige tavalisem kriteerium. Osakaal võiks olla vahemikus 30..50%, sõltuvalt teiste kriteeriumite valikust ja eelarve suurusest.

Arendus- ja hooldustööde tunni hind

Juhul kui hankes sisaldub ka aastatepikkune arendus- ja hooldusteenus, lisa see kriteerium hilisemate üllatuste vältimiseks juurde. Osakaal võiks olla vahemikus 10..25%

Kokkuvõttes võiks hinna kriteeriumite summaarne osakaal jääda 40…60% vahele.

Testülesanne (nt avalehe disain või tehniline ülesanne)

Suhteliselt levinud kriteerium, eriti disaini hindamisel.
Kui hanke skoobis sisaldub veebi visuaalne disain ja prototüüp, siis on disaini näidisülesande nõue põhjendatud kuid arvesta, et see vähendab siiski osalevate pakkujate arvu. Kvaliteetsetel tegijatel on käed-jalad tööd täis ja neil on keeruline ja ka kallis lasta disaineril pakkumise jaoks nullist loovlahendust teha. Sama kehtib arendajate kohta, kes peaksid tehnilist ülesannet lahendama. Pakkuja otsus sõltub siin palju ka hanke planeeritud maksumusest – kui planeeritud eelarve on piisavalt suur, ei ole testülesanne takistuseks.
Kui sa juba testülesannet küsid, siis ilmselt soovid sellele ka suuremat osakaalu, nt vahemikus 25..40%

Sarnaste referentside arv

“Sarnane” saab olla kas rahaliselt või sisult. Sisult sarnane tähendab üldjuhul kas sama tehnilise platvormiga (WordPress, Drupal, vms) või funktsionaalsuselt sarnaseid projekte (e-pood, iseteenindus, intranet, avalik veeb jms). Rahaliselt sarnane tähendab sinu planeeritud eelarvega samas suurusjärgus projekte.
Tavaliselt määratakse ka ajapiir – nt teostatud viimase 3..5 aasta jooksul ja ka minimaalne nõutud projektide arv – nt 3….8. Konkreetne number sõltub mh sinu planeeritud eelarve suurusest, kui eelarve on suurem (>100k), siis on mõistlik panna väiksem arv.
NB! Üks oluline nüanss: küsi pakkumuses alati ka projekti tellija kontaktisiku andmeid, see annab sulle võimaluse kontrollida kliendi reaalset rahulolu pärast projekti valmimist ja nii saad pakkujate kohta rohkem taustinfot. Olen näinud piisavalt juhtumeid, kus agentuuri projektide loetelu veebis on küll muljetavaldav, aga kliendid reeglina ääretult pahased ja tegijat hea sõnaga ei meenuta. Püüa seda lõksu vältida. (Teine variant on küsida agentuuride taustinfot turgu tundva sõltumatu eksperdi käest.)
Osakaal võiks olla 15..20%

Meeskonna ülesehitus ja kompetents

Üldiselt ma soovitan panna see kriteerium pigem vastavustingimuste alla, sest nagu me kõik hästi teame, siis pakkumusse pannakse alati agentuuri parimad tegijad. Tegelikkuses aga asutakse juba kohe projekti alguses meeskonna vahetamisest rääkima. Sellises hetkel on tellijal küll võimalik keelduda ja nõuda sama meeskonda mis hankes lubati, aga reaalselt teevad seda vähesed tellijad. Kuna tahetakse alustada uut koostööd positiivselt, siis enamasti lepitakse uue (ja kahjuks vähemkogenud) meeskonnaga.
Kui sa siiski otsustad selle kriteeriumite hulka lisada, võiks osakaal olla väike, nt 5…10%.

 Arendusprotsessi korralduse ja metoodika kirjeldus sh riskiplaan

See on vastuolulisi arvamusi tekitav kriteerium. Ühed ütlevad, et see on ainult ilujutu kirjutamine ja ei ole midagi kergemat kui mahukas ilujutt kuskilt (kasvõi nt kõvema konkurendi pakkumisest kui kätte juhtub) maha kirjutada. Teised ütlevad, et selle jutu põhjal saab teha väga olulisi järeldusi agentuuri töökorralduse kvaliteedi kohta. Kui varem olin nõus rohkem esimestega, siis tänaseks olen oma arvamust kardinaalselt muutnud. Miks? Tarkvara auditeid tehes olen võrrelnud alati pakkumuses lubatud arendusprotsessi kirjeldust ja tegeliku elu kattuvust ning olen näinud, et agentuurid kasutavad tegelikult ikkagi omaenda tööprotsessi ideaalset kirjeldust, st suurt kopeerimiskommet ei paista.
Juhul kui me saame eeldada, et pakkuja kirjeldab enam-vähem omaenda reaalset töökorraldust (või vähemalt unistust sellest), siis omandab see kriteerium väga olulise tähtsuse. Ausalt öeldes on see lausa mu lemmik.
Arendusprotsessi ja riskiplaani kirjeldus paljastab kogenud silmale kõik pakkuja tööprotsessi nõrkused. Võid mind uskuda, et juba pakkumuses oleva “ilujutu” põhjal saab välja tuua võimalikud projektiriskid selle konkreetse agentuuriga. Ja kui juba ideaalversioon on vildakas, võib vaid ette kujutada, milline reaalne projektielu hakkab olema.
Oluline fookus on ka riskiplaanil. On kohe näha, kas pakkuja ei saa üldse aru selle sisulisest tähtsusest ja teeb lihtsalt copy-paste oma eelmisest pakkumusest või on ta riskid selle konkreetse hanke jaoks läbi mõelnud ja need vastavalt esile toonud.
Kui sul on olemas hindamiseks vajalik IT ekspertiis, soovitan selle kriteeriumi komplekti valida. Osakaal võiks olla 20..40%

Projektiplaani detailsus ja realistlikkus

Eeldades, et sa ei sea ise hankes liiga lühikest teostuse tähtaega (sellest rohkem edaspidi), siis on siin hea võimalus hinnata pakkuja kogemust sarnaste projektide teostamisel. Pakkumise koostamise käigus teeb korralik agentuur niikuinii ligikaudse projekti- ja ressursiplaani, et hanke mahtu hinnata ja tal ei ole raske seda ka pakkumuses välja tuua. Tegelikult ma siinkohal liiga detailset projektiplaani ei poolda, see ei anna terviklikku ülevaadet. Piisab kui on välja toodud projekti üldised etapid, funktsionaalsete moodulite etapid, lõpptestimise etapid jmt. Realistlikkuse hindamiseks vajad taas tehnilist ekspertiisi või omaenda kogemust. Osakaal võiks olla 10..20%

Pakkumuse struktuur, selle selgus ja täielikkus

Midagi see kriteerium tõesti näitab, aga ma pole kindel, kas see ikka näitab pakkuja kvaliteedi taset. See näitab rohkem pakkumuse kirjutamise oskust ja ei ütle just palju pakkuja kogemuse kohta. Kasuta ettevaatusega. Osakaal võiks olla väike, nt 5..10%

Hindamiskriteeriumite näide

Olen nüüd kirjeldanud tervet rida võimalikke kriteeriumeid ja toon ka ühe näite.
Oletame, et plaanid hankida avaliku veebi teostuse. Sul on eelnevalt olemas juba eelmises hankes tellitud visuaalne disain, UX/UI analüüs ja prototüüp. Ärianalüüs on läbitud, eesmärgid on selged ja nüüd vajad tehnilist arendust. Lisaks soovid 2a pikkust arendust ja hooldust pärast veebi lansseerimist.
Sinu planeeritud eelarve on ca 100k, millest pool oled arvestanud veebi valmistamiseks ja pool edasiseks arenduseks ja hoolduseks.

Üks võimalik hindamiskriteeriumite komplekt on järgmine:

Jrk
nr
Nimetus Tüüp/ hindamismeetod Osakaal
1 Pakkumuse kogumaksumus Maksumus – vähim on parim 30
2 Arendus- ja hooldustööde tunni hind Kulu – vähim on parim 20
3 Arendusprotsessi korralduse ja metoodika kirjeldus sh riskiplaan Kvaliteet – hankija hinnatav 35
4 Sarnaste referentside arv Kvaliteet – suurim on parim 15

Selline valik peaks andma sulle vajaliku hindamise vabaduse parima hinna ja kvaliteedi suhtega koostööpartneri leidmiseks.

Kui arvad, et mul jäi mõni hea kriteerium välja toomata, anna mulle märku!

See lugu läheb edasi. Järgmisena võtan ette tüüpvead “Hanke tingimuste vale valik” ja “Tehnilise kirjelduse puudulik koostamine”.

PS Soovitan ka lahedat lugemist “Maailm kontoris” blogis: “Kuidas uuendatakse veebilehte

 

Viimati muudetud (faktitäpsustused): 16.07.2020

 

Merle profiilipilt väike

Iga uus kontakt on võimalus uueks ja põnevaks koostööks - kirjuta või helista mulle ja arutame kuidas saaksin Sind aidata. 

Esimene konsultatsioon ja pakkumise tegemine on alati tasuta. 

Liitu uudiskirjaga

Liitu uudiskirjaga

Liitudes uudiskirjaga, saad osa väärtuslikust materjalist tarkvaraarenduse teemadel. Liitumise saad igal hetkel tühistada. Privaatsuspoliitika

Aitäh liitumast!

Share This