Kuidas (riigi) hangete puhul hangitavale tarkvarale mõistlikke nõudeid püstitada ning mis on ebamõistlike nõuete tagajärjed

1. Selgepiirilistest nõuetest
Andres Kütt
RIA / Riigi Infosüsteemi Arhitekt
!
20.05.14

2. Täna kavas
"
Enne hanget
"
Kuidas pakkuja mõtleb
"
Hägusate nõuete tagajärjed
"
Nõuete kirjutamisest hankesse
"
Ports konkreetseid soovitusi

3. Pakkumise kirjutaja teeb korraga kolme asja:
!
"
Maksimiseerib käivet
"
Minimiseerib riske
"
Juhib oma aega
Kuidas pakkuja mõtleb?
• Käive on funktsioon ajast: pakkuja maksimeerib käivet kogu nähtava koostöö peale. Järelikult on hankija huvides võimalikult pikk koostööperiood mis
siiski ei tekita fataalset lock-in’i
• Maksimeeritakse just nimelt käivet, mitte kasumit. Kasumit hakatakse maksimeerima hiljem vahetades tiimi liikmeid odavamate vastu ja tehes nii vähe, kui
võimalik
• Pakkuja on reeglina ajalise surve all. Iga tema tööminut maksab
• Iga projektiga käivad kaasas riskid. Ei ole mõtet võita pakkumist ja selle eest pikas perspektiivis peale maksta. Järelikult peab pakkuja adekvaatselt
hindama projekti riske

4. 0 20 40 60 80 100
0.00.10.20.30.4 Tulu
Tõenäosus
Joonisel on kahe erineva riskihinnanguga pakkumise graafikud. Mõlema puhul on tõenäosus miinusesse jääda sama, kuid ühe puhul on hajuvus (st. risk või
ebamäärasus) oluliselt suurem. Kui hinnang riskidele ning seega ka potentsiaalsele tulu hajuvusele on suurem, on suurem ka küsitav hind - vastasel juhul
tuleks võtta oluliselt suurem risk miinusesse jääda.

5. "
Kõrgemat hinda
"
Kompetentsete pakkujate kõrvalejäämist
"
Riskide valesti hindamist võitja poolt
Hägusad nõuded tähendavad järelikult
Kogu riskianalüüs on loomulikult tõenäosuslik kuid need kolm järeldust kehtivad rõhuval enamikul juhtudest
• Mida suuremad on riskipuhvrid, seda suurem tuleb hind. Isegi, kui puhvrid ei realiseeru, on hinnas juba kokku lepitud ja mida tagasi saada reeglina ei
õnnestu
• Mingist piirist alates loobuvad kompetentsed pakkujad riske hindamast. Ühest küljest on neil definitsiooni järgi palju (vähemriskantset) tööd ja teisalt
suureneb tõenäosus hinna osas alla jääda
• Mida suurem on risk, seda suurem on tõenäosus, et riske alahinnates tehakse odav pakkumine. Seega suureneb ka tõenäosus, et võidetakse just nimelt
riske alahinnates

6. Hägusatest nõuetest kaotab reeglina hankija
!
Vähemalt kulutab ta aega ja vahendeid nurjunud
projektile
Järelikult…
Kuna tarnijal on tavaliselt oma kuludest selge ülevaade, saab ta aegsasti projektist väljuda, kui projekt kahjumile läheneb. Hankijal ei ole projektist kuhugi
minna ning kulude sisse nõudmine kohtu kaudu on hirmus ajamahukas.

7. Kõik algab ja lõpeb äriprotsessiga
Ilma äriprotsessi mõistmata ei ole võimalik kirjutada mõistlikku hankedokumenti. Äriprotsess (või selle puudumine) on kõigi tarkvaraprotsesside kriitiline
edutegur. Et riigis reeglina äriprotsessist ei räägita, seda asjaolu ei muuda.

8. Ei tohi minna hankesse teadmata,
mida saada tahetakse
Kõlab triviaalselt, eks. Aga ometi läheb rõhuv enamus tarkvaraprojekte vasakule just sel põhjusel.

9. "
Miski, mille olulisuest pealik eile ajakirjast luges
"
Kolme erineva inimese vastuolulised
veendumused
"
Soov “nagu xxx.gov.uk aga vähema tiluliluga”
"
Määrus/seadus vms. juriidiline dokument
!
“Teadmine” ei ole
• Teadmine ei pea olema hankija peas, teadmine peab olema ühel või teisel viisil projektile (ja seega ka hankeprotsessile) kättesaadav
• Ülemuse peas olevast suuremal või vähemal määral selgest visioonist ei ole kasu, kui seda ei õnnestu konkreetseteks nõueteks tõlkida. Tavaliselt on
probleemiks juhi aja defitsiit kuid väga tihti ka tavaline võimust tingitud arrogants.
• Kui organisatsioonis on rida inimesi, kel kõigil on oma selge arusaam ärirptosessist kuid kellede arusaamad ei kattu (näiteks müügil ja tootmisel on
finantsaruandlusest tavaliselt risti vasutkäivad arusaamad), ei teata tegelikult, mida tahetakse. Puudu on otsus, mida ei saa keegi kolmas organisatsiooni
eest teha.
• xxx.gov.uk on konkreetne näide. Hämmastaval kombel on siiamaani elus “stiilsete www-eriefektide” mõtteviis mis vabastab selle väljendaja igasugusest
vastutusest midagi kuidagi kirjeldada. Reeglina on sedalaadi väited hankes suureks punaseks laternaks mille peale vähegi mõistlik pakkuja eemale astub
• Juriidiline dokument ei kirjelda äriprotsessi vaid seab sellele teatavad nõuded. Puhtalt juriidikale toetudes ei ole võimalik tarkvara hankida.

10. "
Hajus protsessikompetents organisatsioonis
"
Otsustusvõimekus ja -pädevus suuna õigsuse
kontrolliks
"
Toimiv mehhanism teadmise tekitamiseks
“Teadmine” on, muu hulgas,
Loomulikult on kõige praktilisem ja selgem teadmise vorm kompaktse grupi inimeste võimekus äriprotsessist omavahel oluliselt kaklemata pikalt ja
põhjalikult rääkida. Siiski on teadmisel ka teised vormid:
• Hajus. Keeruliste protsesside korral ei ole ei ühel inimesel ega väikesel grupil täit ülevaadet terviklikust protsessist. Küll aga võib eksisteerida rida inimesi,
kelle peades on arusaam konkreetsetest sammudest. Tüüpiliselt näiteks on letitöötajate vahetud juhid, kelle teadmisi reeglina ei ole kellelgi peakontoris.
• “ma ei tea, mida ma tahan aga ma tunnen selle ära, kui seda näen”. Agiilsed arendusmeetodid tuginevad just sedalaadi teadmisele. Ehk, kuskil on
inimene, kes suudab otsustada, kas miski samm viib soovitud tulemusele lähemale või mitte. Oluline on ka otsustuspädevus.
• Vahel ei olegi teadmist äriprotsessist võimalik ilmutatud kujul omada, seda eriti uudsete ning lõpptarbijale suunatud lahenduste puhul. Küll aga on
võimalik omada mõõdikuid lahenduse edu hindamiseks, läbi proovitud mehhanisme tarbija reaktsiooni mõõtmiseks jne.
!
Mõlemad variandid on mõistlik hankedokumentatsioonis spetsiifiliselt välja tuua, vastasel juhul võidakse hakata tegema eeldusi. Samuti on sobilik
lähenemine mõlemal juhul erinev standardsest küsitlen-kolme-inimest-ja-joonistan-pildi lähenemisest.

11. Mõtlemist ei saa sisse osta
On kummastav, kui tihti seda siiski üritatakse. Nii era- kui avalikus sektoris. Keegi ei saa teie eest otsustada, kuidas maksu koguda, riigi ITd koordineerida
või pensione välja maksta.

12. "
Mõtete üles kirjutamist ja konsolideerimist
"
Mõtete formaliseerimist
"
Mõtete analüüsi ja kriitikat
Sisse saab osta
Need tegevused aetakse tihti mõtlemisega segi. Samas, kui puudub teadmine äriprotsessist, on (äri)analüüsi tulemus paremal juhul läbikukkumine.
Halvemal juhul produtseeritakse paber, millel puudub reaalsete vajadustega igasugune seos, kuid millele tuginedes on siiski võimalik asuda
programmeerima. Loomulikult ei ole selliselt punutud tarkvara kellelegi kasulik.

13. Kõige parem märk teadmise puudumisest:
!
võimetus kirjutada mõistlikku
hankedokumenti
Enese rumaluse tunnistamine on inimesele peaaegu kõige raskem asi. Mida ägedam juht, seda raskem. Samuti on keeruline hinnata kollektiivset rumalust:
“mina ei tea, aga eks vanemad kolleegid ikka teavad”.
!
Elu näitab, et kõige parem märk teadmise puudumisest on raskused mõistliku hankedokumendi kirjutamisel. Kui ikkagi ei suudeta loetleda konkreetseid
tulemeid ning nende vastuvõtukriteeriume, on suure tõenäosusega asi äriprotsessi teadmise puudumises. Kui hankedokumendi kirjutamine jääb venima on
mõislik hange seisma panna ning uurida, milles ikkagi asi.

14. Konkreetsed soovitused
nõuete kirjutamiseks
Järnevas mõned konkreetsed soovitused, mis paraku enamasti tuginevad päriselulistele näidetele. Kui te oma kirjutatu ära tunnete, siis on põhjust
häbeneda.

15. Sest need ei anna pakkumiseks kasulikku infot.
Ja reeglina ei suudeta mõistlikke prioriteete
määrata.
!
!
!
Ära räägi prioriteetidest
Kui pakkumisest ei selgu, milline on prioriteetide mõju (näiteks: “faasis üks realiseeritakse tulemid prioriteetidega 1-3”) projektile, ei ole neid mõtet
loetleda. Kuna pakkujal nendega midagi teha pole, on tegu müraga.
!
Halvemal juhul kommunikeeritakse prioriteetidega (skaalal 1-5 80% - P1, 15% - P2, 5% - P3), et tegelikult ei suudeta prioretiseerida. Järgmine suur punane
latern mille peale head pakkujad eemale kõndida võivad.

16. Kui millegi tegemata jätmine ei mõjuta välja
makstavaid summasid, seda ei tehta.
!
Kui miskit on vaja teha, siis on seda vaja, kui seda
ei ole vaja teha, ei ole mõistlik sellele aega
kulutada.
Ära räägi “soovitavatest” asjadest
Tarnija soovib teha nii vähe, kui võimalik. Järelikult visatakse projekti skoobist esimesel võimalusel välja, kõik mis võimalik. Teisalt on projekti skoobil
kalduvus kasvada. Seega on hankedokumendis “soovitavate” asjade välja toomine vaid ebamäärasust suurendava mõjuga: pakkuja ei tea, kas tegemist on
hankekomisioni esimehe lemmikteemadega, millele rõhumine annab punkte juurde, miskil koosolekul saavutatud kompromissiga kümne inimese vahel või
mõne väikese ametniku tagasihoidliku sooviga.

17. Arendushind on ühekordne tulemi üle andmisel
makstav tasu. Mõõdetakse eurodes.
!
Operatiivhind on regulaarne teenuse kvaliteedist
sõltuv tasu. Mõõdetakse eurodes ajaühikus.
Operatiivne hind eraldi arendushinnast
Perioodilise ja ühekordse hinna sujuv kombineerimine on järjekordne punane latern. Tegu on kahe fundamentaalselt erineva hanke liigiga, mida isegi ühte
hankesse, rääkimata ühest numbrist, on keeruline mahutada.
!
Esimesel juhul on tarne vastu võtmine ühekordne tegevus ning väljamakse sõltub tarne omadustest (aeg, kvaliteet, ulatus jne.). Teisel juhul on tegu
igakuiste väljamaksetega, mis võivad (aga ei pruugi) olla sõltuvuses osutatud teenuse kvaliteedist.

18. 100 tundi tööd 10.- tunnihinnaga inimese poolt on
oluliselt erinev 10 tunnist tööst 100.-
tunnihinnaga inimese poolt
!
Hea võimalus tiim kontrolli alla ning pakkumised
võrreldavaks saada
Tunnid rollide lõikes, mitte lump sum
Ehk, pakkumises tuuakse välja rollid koos tunnihindadega (soovitavalt ka inimeste CVd, kes rolle täidavad) ning iga tarne kohta loetletakse:
1. Mis rollid tööd teevad
2. Kui mitme tunni ulatuses
3. Mis summas (mugavuse mõttes)
!
Selliselt vormistatud pakkumisel on järgmised head omadused:
1. Pakkumised on võrreldavad, alapakkumist on lihtsam ära tunda
2. Hilisem muudatuste juhtimine ja lisatööde tellimine muutub läbipaistvaks, kuna tunnihinnad on kokku lepitud
3. Saab kehtestada eraldi piirangud sellele, kuidas ja millal mingite rollide täitjaid vahetada saab

19. Alati hangitakse tulemust, mitte tööd
Hämmastavalt tihti hangitakse mingeid arusaamatuid “töid”. Viimati tegeles riik minu teada hädaabitöödega eelmise sajandi algupoolel. Sealt alates on
raha kulutamise eesmärgiks ikka olnud tulemi saamine, mitte inimestele töö pakkumine ning ei ole tõenäoline, et Eesti IT-sektor hetkel toetamist vajaks.

20. "
Mis täpselt üle antakse
"
Kuidas me teame, et see miski on kokku lepitud
(NB! Mitte soovitavas!) kvaliteedis
"
Kes võtab vastutuse vastu võtmise eest
"
Mil viisil sõltub rahade liikumine tarne
kvaliteedist
Seega tuleb fikseerida
Kuna hangitakse tulemust ja mitte tööd on hanke keskseks mõisteks “tarne”. Miski antakse täitjalt tellijale üle.
• Tuleb loetleda kõik, mis üle antakse. Sealhulgas dokumendid, koolitused, koodiread jne. jne. Kuna tarnija minimiseerib oma kulusid, siis kehtib põhimõte:
mida ei ole üle antavate asjade nimekirjas, seda ei tehta
• On oluline (sisemiselt) kokku leppida, kuidas toimub tarnete vastu võtmine. Selle kokkuleppe võib läbipaistvuse huvides ka hankedokumendis teatavaks
teha. Seejuures on oluline anda hankijale kindlus (ebamäärasuse vähendamine!), et hinnang kvaliteedile on pigem objektiivne kui subjektiivne.
• Kui puudub inimene, kes konkreetselt vastutab hanke kvaliteedi kontrolli eest, siis hangete kvaliteeti ei kontrollita. Peadirektor, kes arve viseerib, peab
saama toetuda kellegi hinnangule
• Tarnetest on mõtet rääkida vaid siis, kui sellel on mõju rahade liikumisele. Kui hankes/lepingus sätestatu ei võimalda tarnet tagasi lükata, osaliselt vastu
võtta vms., ei ole tarnete kirjeldamisel mõtet. Tarnija annab alati üle vähima, mille eest veel raha saab.

21. Ei tohi eeldada mingeid eelteadmisi hangitavast
objektist
!
On kasulik hanke läbipaistvusele
!
Ka su kolleegid või järeltulijad võivad olla pärit
sealtsamast!
Pakkuja on Montevideost
Alati tuleb eeldada, et pakkumise koostaja on sama päeva hommikul astunud maha lennukilt, mis tuleb Montevideost ning ei tea mitte midagi ei
konkreetsest süsteemist ega üldse Eesti riigist.
!
Põhjus (lisaks sellele, et tänapäeval võibki pakkuja olla pärit Uruguaist), on pakkujate ühetaoline kohtlemine ning eelduste (seega ebamäärasuse!)
vähendamine. Kui kaks pakkujat eeldab, et kasutatakse nende koodihoidlat ja kaks, et hankija oma, ei pruugi pakkumised olla võrreldavad.
!
Oluline on ka meeles pidada, et hankes tegelikult dokumenteeritakse projekti ning et tarne vastu võtmisel on aluseks hankedokument. Ebamäärane
hankedokument eeldab, et tarne vastu võtja omab hankedokumendi kirjutajaga sama taustainfot. See aga ei pruugi sugugi tõele vastata.

22. Rusikareegel: kui tükk infot võib pakkumise
tegemiseks kasulik olla, lisa see hankele
!
Taustainfoga koonerdamine süvendab lock-in’i
ning läheb mingist piirist alates paragrahvi alla
!
Kui infot pole, tuleb nii öeldagi
Anna kogu olemasolev taustainfo
Tänapäeval on üliharuldased juhtumid, kus on võimalik ehitada nullist täiesti uus, ühegi liideseta, infosüsteem. Reeglina peab uus asi elama vanade
asjadega koos või nende funktsioone üle võtma või nendega infot vahetama, sobituma protsessidesse jne. jne. Kõike seda on pakkumise tegemisel oluline
teada.
!
Rusikareegel: “Kui miski võib olla pakkumise tegemisel kasulik siis pane see sisse. Kui miski ei mõjuta ei otsust võitja osas ega pakkumist, jäta see välja.”
!
Kehtib oluline seaduspärasus: kui hankes eeldatakse pakkujalt eelteadmist süsteemsit, saavad hankes osaleda vaid eelteadmisega pakkujad mistõttu hanke
võitja teadmised süsteemist aina süvenevad mistõttu muutub järjest raskemaks hankimine kelleltki teiselt mistõttu on mõistlikum tellida samalt ettevõttelt
mistõttu on kasulik eeldada eelteadmisi. Ehk, nii tekivadki puukidest partnerid.
!
Oluline on teha vahet info puudumise ja selle mitte jagamise vahel. Kui näiteks hankega ei ole kaasas mittefunktsionaalseid nõudeid, siis peab pakkuja
nende eksisteerimise kohta tegema oletusi (ebamäärasus!) ning ei ole tingimata selge, millise eelduse milline pakkuja tegi. Kui aga pakkumiskutses on
kirjas “mittefunktsionaalsed nõuded puuduvad” on pakkujatel vabad käed ning eeldusi tegema ei pea.

23. Milline on tugi ning ressursid, mida hankija
pakub?
!
Serverid? Nõupidamisteruumid? Küpsised?
Koolitus? Kollaboratsioonikeskkond?
Mida sa pakkujale pakud
Igasugune tarkvaraarendus on koostöö ning iga koostöö aluseks on selge arusaam osapoolte poolt laua äärde toodavast. Jällegi on oluline märksõna
ebamäärasus. Hea näide on kõikvõimalik keskkondadega seotu: kas tarnijalt eeldatakse oma testkeskkonna jooksutamist või on see hankija poolt? Samuti
on tüüpiliseks arusaamatuse allikaks kontoripindade ning arvutivõrguga seonduv ning reisikulud.

24. Aitäh!
Andres Kütt
andres.kutt@ria.ee