Vastamaks teie poolt täiendavalt esitatud küsimusele ja selgitamaks, miks teenusedisain ja arendustööd ei ole sama eesmärgi nimel tehtavad tööd peame vajalikuks selgitada teenusedisaini olemust. Käesolevaga esitame selgitused, miks teenusedisaini ja arendustööde hanke eesmärgid on oma olemuselt erinevad. Ühtlasi märgime, et vastus ei hõlma selgitusi riigihanke „Rahvastikuregistri uue menetlustarkvara testimistööd“ (viitenumber 292608) osas, sest kõnesolev hankemenetlus tunnistati kehtetuks.
Teenusedisaini ei ole seotud pelgalt tarkvaraarendusega, teenusedisaini teostatakse erinevates valdkondades ja oma olemuselt on see protsess, mille käigus planeeritakse ja kujundatakse teenuseid nii, et need vastaksid kasutajate vajadustele ja ootustele ning oleksid samal ajal efektiivsed ja lihtsasti kasutatavad. Teenusedisain hõlmab nii teenuse kasutajakogemuse loomist kui ka teenuse taga olevate protsesside, süsteemide ja ressursside korraldamist.
Rääkides avaliku sektori vaates teenustest, siis räägime eelkõige kuidas inimene (kasutaja) suhtleb riigiga. Teenuse puhul aga sellest, kuidas toimub elukoha registreerimine. Teenusedisaini puhul võetakse kogu „teenus“ pulkadeks lahti ja vaadeldakse seda „kasutaja“ perspektiivist. Lihtsamalt öeldes on teenusedisaini eesmärk, hästi toimiv teenus nii kliendi (inimese) kui ka teenusepakkuja (riigi) jaoks — teenus oleks meeldiv, mugav ja toimiks probleemivabalt.
Teenusedisain on oma sisult tööriistade kogum, mis võimaldab parendada nii tänaseid kui ka luua uusi teenuseid kasutajakeskselt. Tegemist on loova probleemilahendamise metoodikaga, mille edukas rakendamine toetab järjepidevalt arendada väärtustloovaid, äriliselt jätkusuutlikke ning kasutajakeskseid teenuseid.
Arendustööde eesmärk on konkreetse tarkvara arendamine, konkreetse funktsionaalsuse loomine, puuduste parandamine tarkvaras. Teenuse puhul võib küll olla kasutusel ka tarkvara nagu see Eestis tavapärane on, aga see on pelgalt üks osas teenusest tervikuna. Samamoodi on teenuse osadeks ametnikud, kes viivad läbi menetlusi ja menetluste tähtajad jmt.
Teenusedisaini tulemusena võib ka selguda, et olemasolev protsess on piisav ja muudatusi teenus ei vaja, samuti, et mõistlik on kitsaskohti lahendada luues juurde uus töökoht või muuta seadusandlust.
1. Teenusedisain kujutab endast visiooni ja kasutajate ootuste kaardistamist, mis võib, kuid ei pruugi otseselt tarkvara arendusi mõjutada. Teenusedisain keskendub lõppkasutajate intervjuudele, eesmärgiga koguda väärtuslikku infot kasutajate ootuste ja protsesside muudatusettepanekute kohta. Selle lõpus võidakse protsesse ümber mõtestada ja kujundada. Peame siinjuures vajalikuks selgitada, et teenusedisain ei hõlma enda tarkvara detailanalüüsi ja UI/UX disaini ning tarkvara arendus järgneb alles siis, kui on tehtud otsus, et esineb vajadus tarkvara arendada. On täiesti realistlik, et teenusedisaini tulemusena pakutud lahendustest üksnes kolmandik või veel vähem eeldab tarkvara arendustöid.
2. Tarkvara arendamine on võimalik ka ilma eelneva teenusedisainita. Tarkvara arendamine ei eelda teenusedisaini ning tarkvara arendustöid on võimalik teostada ka ilma teenusedisainita. Tarkvaraarendusprojekti elluviimiseks on vajalik teostada detailanalüüs ning jätkata UI/UX disaini ja seejärel teostada tarkvara arendustööd. Just detailanalüüs ja UI/UX disain on otseselt seotud tarkvara arendustöödega ning selliste hangete eraldi korraldamisel tuleks nende maksumused arusaadavalt summeerida, sest need on sama eesmärgil teostatavad tööd.
3. Teenusedisain ei ole tarkvaraarenduse keskne osa, vaid vaatleb laiemat pilti. See hõlmab organisatsiooni sisemisi protsesse, lõppkasutajate kaasamist ning keskendub kogu teenuse väärtusahelale. Tarkvara on üksnes osa tervikteenusest.
Selleks, et paremini selgitada, miks teenusedisain ei ole sama eesmärgi nimel teostatav teenus kui tarkvara arendustööd oleme allolevas tabelis loetlenud teenusedisaini ja UX/UI disaini erinevused.
UX/UI disaini erinevus teenusedisainist:
Aspekt
Teenusedisain
UX/UI disain
Fookus
Kogu teenuse kogemus algusest lõpuni
Konkreetne digitaalne toode (rakendus, veebileht)
Eesmärk
Sujuv ja väärtust loov teenus nii kliendile kui organisatsioonile
Mugav ja meeldiv kasutajakogemus liideses
Tööriistad
Klienditeekonna kaardid, teenuse blueprint, töötoad, prototüüpimine päris teenuse stsenaariumides
Wireframe’id (kasutajaliidese mustand või skeem, mis näitab kuidas erinevad elemendid on ekraanil paigutatud. Tavaliselt lihtsad, must-valged, ei sisalda lõplikku disaini, keskenduvad rohkem sellele, kuidas informatsioon ja funktsioonid on organiseeritud. Wireframe aitab planeerida kasutajakogemust (UX) ja kujundada loogilist ja kasutajasõbralikku liidest), prototüübid, kasutajaliidese testid, disainisüsteemid
Uurimisobjekt
Kasutaja, töötajad, protsessid, süsteemid
Kasutaja ja tema interaktsioon tootega
Ulatus
Holistiline – hõlmab kõiki kontaktpunkte ja taustaprotsesse
Piiratud toote või liidese tasemel
Kokkuvõtvalt ütleme, et teenusedisaini ja UI/UX disaini eesmärgid on erinevad, nad tegelevad disainiga erinevatel tasemetel, teenusedisain on palju laiem kui UI/UX disain, mis on üks osa tarkvara arendusprotsessist.
Lisaks eeltoodule peame vajalikuks rõhutada, et RHS § 28 lg 2 viimasel lause kohaselt võib hankija võib jaotada riigihanke osadeks, kui see on objektiivsetel põhjustel õigustatud (vt ka klassikalise direktiivi art 5 lg 3). Seega näeb nii seadus kui ka direktiiv ette õiguse jaotada riigihange erinevateks riigihangete menetlusteks ilma summeeritud kogumaksumust arvestamata, kui see on objektiivsetel põhjustel õigustatud.
Hankija hinnangul isegi juhul kui asuda seisukohale, et teenusedisaini hange ja arendustööde hange kannavad sama eesmärki, siis esinevad sellised objektiivsed asjaolud, mis võimaldavad RHS § 28 lg 2 alusel jaotada riigihange erinevateks riigihangete menetlusteks ilma summeeritud kogumaksumust arvestamata.
Lisaks eeltoodud selgitustele, et tarkvara arendustööd ja teenusedisain on oma olemuselt erinevad teenused, millel on erinevad väljundid ja eesmärgid:
• Teenusedisaini puhul: luua visioon teenusest vaadeldes seda tervikuna.
• Tarkvara arendustööde puhul: luua, täiustada ja hooldada tarkvaralahendusi, mis hõlmab funktsionaalse, töökindla ja kvaliteetse tarkvara väljatöötamist.
Peame vajalikuks rõhutada järgmist:
1. Kahe kõnesolevate hankelepingute ese on erinev. Teenusedisaini hankelepingu esemeks on viia läbi teenusedisain, sh kasutajauuring, luua prototüüp ja stiiliraamat. Tarkvara arendustööde hanke ese on rahvastikuregistri uue menetlustarkvara analüüsi - ja arendustööd. Tarkvara arendustööde hankeleping hõlmab ka mh detailanalüüsi (sh ka UX/UI disain), mis kätkeb endas kõigi nõuete spetsifitseerimist ja kogu tehnilise dokumentatsiooni läbivaatamist koos hankijaga, et leida hanke eesmärgi saavutamiseks parim lahendus. Detailanalüüsi tulemusel lepivad hankija ja pakkuja kokku, mida pakkuja realiseerib ning hankija hangib. Detailanalüüs peab andma vastused küsimusele: mida, millal, kuidas, mis tulemiga ja kes peab saama erinevaid protsesse/töövooge tarkvaras läbi viia. Eeltoodust nähtub üheselt, et rahvastikuregistri arendustööde hanke eseme hulgas on detailanalüüs (UX/UI disain), mis on otseselt ja vahetult seotud arendustöödega, mitte teenusedisain, mis nendele küsimustele ei vasta.
2. Teenuste puhul ka pakkujate ring erineb (teenusedisaini hanke registreerimislehelt nähtub, et registreerunud on suur hulk ettevõtjaid, kes ei tegele tarkvaraarendustöödega)1.
3. Objektiivelt ei ole mõistlik kohustada hankijat hankemenetluste maksumusi summeerima, kui hankelepingute eesmärk on täiesti erinev pelgalt seetõttu, et üks võib mõjutada teist.
Vastuseks küsimusele, kas rahvastikuregistri arendamine toimub agiilse metoodika alusel märgime, et kuivõrd teenusedisain ei hõlma endas tarkvaraarendustöid, siis jääb küsimuse sisu hankijale natuke arusaamatuks. Küll aga selgitame, et töövõtulepingute puhul ei ole hankijale oluline, millist arendusmetoodikat kasutatakse, oluline on üksnes hankelepingu esemeks olevate eesmärkide saavutamine. Millisel moel täitja otsustab need eesmärgid saavutada – kas ta kasutades agiilset arendusmetoodikat või otsustab waterfall metoodika kasuks – ei ole hankijale oluline. Kui see vastus ei ole RTK-le piisav, siis palub hankija küsimuse sisu ja eesmärki avada, et saaksime vajadusel sisulisemalt teie küsimusele vastata.