Innovatsiooniprojekti ideekavand1 AVALIKU SEKTORI INNOVATSIOONIVÕIMEKUSE TÕSTMINE Ideekavandit täites palume tutvuda riigikantselei veebilehel toodud soovituste ja juhistega projekti esitajale.

Innovatsiooniprojekti nimi Teenuspõhist juhtimist toetav tehisaru rakendus

Innovatsiooniprojekti fookusvaldkond

☐ Droonitehnoloogiate valdkond

☒ Tehisintellekti lahenduste valdkond

Innovatsiooniprojekti panus valitsuse tegevuskava prioriteetidesse

☐ Riigi kriisikindluse suurendamine

☐ Majanduse kasvule kaasa aitamine

☒ Riigi tõhus juhtimine

Innovatsiooniprojekti esitajad (tulevased RK partnerid) (asutus/asutused)2

Projekti esitaja: Tallinna Strateegiakeskus

Projektijuht või ideekavandi esitaja kontaktisik (nimi, asutus, e–posti aadress ja telefon)

Ideekavandi esitaja: Joel Kotsjuba, Tallinna Strateegiakeskus, Teenusedisaini büroo juht, [email protected], Kaarli pst 1, 10119 Tallinn, +37258851100

Innovatsiooniprojekti kestus (kuudes)

24 kuud Ajaarvestust alustame üldjuhul partnerluslepingu sõlmimisest.

Innovatsiooniprojekti kogumaksumus (sh käibemaks, kui on abikõlblik)

Kogumaksumus: 899,000 eurot

Käibemaks ☒ jääb kulu tegija kanda (käibemaks abikõlblik)

☐ saab küsida riigilt tagasi (käibemaks ei ole abikõlblik)

Vastav info täita iga partneri kohta (kopeeri ridu ning kirjuta partneri nimi juurde)

1 Juhul kui ideekavand on mõeldud asutusesiseseks kasutamiseks, siis lisage vastav alus ideekavandi päisesse. 2 Partner EL struktuurivahendite mõttes, kes viib ise läbi innovatsiooniprojekti elluviimisega seotud hanked, sõlmib lepingud ning vastutab aruandluse eest.

1. Probleemikirjeldus (max 2 lk) Kirjeldage lahendamist vajavat probleemi, selle olulisust ning keda see probleem puudutab.

• Selgitage, miks on probleem aktuaalne.

• Hinnake probleemi mõju (nt rahaline kokkuhoid, keskkonna- või sotsiaalne kasu).Kirjeldage probleemi tausta. Mida on probleemi lahendamiseks Eestis juba tehtud või mis on tegemisel? Tooge välja relevantsed teiste riikide kogemused probleemi lahendamisel.

Teenuspõhisele juhtimisele üleminek eeldab uut teenuse andmemudelit Tallinna linn on üle minemas teenuspõhisele juhtimisele, mille eesmärk on juhtida avalike hüvede loomist terviklike väärtusahelatena ning parandada linnaelanike ja ettevõtete kasutajakogemust. Üleminekuga muutub teenus linna juhtimissüsteemi keskseks juhtimisobjektiks ning selle kvaliteeti juhitakse neljal omavahel seotud tasandil: toimingu, teenuse, tervikteenuse ja valdkonna tasandil. Selline juhtimismudel eeldab ühtset arusaama sellest, mis on teenus, kuidas teenuseid liigendada ning milliste andmete alusel neid juhtida. Täna selline ühtne alus puudub. Teenuseid kirjeldatakse erinevates infosüsteemides erinevatel eesmärkidel ning puudub kokkuleppeline teenuse andmemudel, mis seoks omavahel teenuse kirjelduse, protsessid, andmed, ressursid, rollid ja strateegilised eesmärgid. Erinevate juhtimisprotsesside toetamiseks on aastate jooksul kujunenud mitmed teenuste nimekirjad ja andmestikud, mis ei ole omavahel kooskõlas ega võimalda teenuseid käsitleda ühe tervikliku väärtusahelana. Selle tulemusena puudub linnal ühtne teenuste tõeallikas ning teenuse juhtimiseks vajalik info on killustunud erinevate infosüsteemide, dokumentide ja organisatsiooniüksuste vahel. Teenuse andmehalduse killustatus ei toeta aktiivset teenusjuhtimist Teenusejuhtimise seisukohalt tähendab killustunud andmehaldus seda, et teenuse juhtimiseks vajalikku infot tuleb koguda, kontrollida ja koondada käsitsi mitmest erinevast andmeallikast. Kuna teenuse kirjeldamiseks ja juhtimiseks puudub ühtne andmemudel ning keskne teadmistekiht, koguvad erinevad tugiteenused sama teenuse kohta andmeid oma juhtimisvajadustest lähtuvalt. Teenusejuht on seejuures sageli pigem andmete vahendaja kui teenuse sisuline juht. Pea igal tugiteenusel või valdkonnal on oma infosüsteem, andmekoosseis ja teenuse kirjeldamise loogika. Kuna puudub ühine tõeallikas, kulub märkimisväärne osa teenusjuhi tööajast sama info korduvaks esitamiseks, ajakohastamiseks ja erinevate juhtimisanalüüside koostamiseks. See vähendab võimalust juhtida teenuseid ennetavalt ning suunab tähelepanu probleemide lahendamisele, mitte teenuse süsteemsele arendamisele. Probleemi illustreerib kalmistuteenuse näide. Teenusejuht koostab keskmiselt 2–3 juhtimisanalüüsi kuus, mille ettevalmistamiseks tuleb koguda ja siduda andmeid vähemalt 6–8 erinevast allikast (sh Haudi, finantsandmed, investeeringud, hooldusteenused, kõnekeskus, järelevalve ning Exceli koondtabelid). Ühe analüüsi koostamine võtab keskmiselt kuus töötundi, mis tähendab ühe teenuse kohta ligikaudu 144–216 töötundi ehk 18–27 tööpäeva aastas. Valdav osa sellest ajast kulub andmete otsimisele, kontrollimisele ja ühendamisele, mitte nende analüüsimisele ega juhtimisotsuste ettevalmistamisele. Sarnane töökorraldus iseloomustab ka paljusid teisi linna teenuseid. Teenusejuhtimise töö muutub ajamahukaks, sest sama teenuse kohta tuleb pidevalt koostada uusi väljavõtteid erinevate juhtimisprotsesside jaoks. Ühtne teenuse andmemudel ja keskne teadmistekiht võimaldaksid teenuseandmeid kasutada iseteeninduslikult nii teenusjuhtidel kui ka tugiteenustel, vähendades käsitööd ning luues eelduse, et tehisaru (edaspidi TA) saab toetada andmete koondamist, analüüsimist ja probleemkohtade tuvastamist. See võimaldab suunata teenusjuhtide aega andmete töötlemiselt teenuse juhtimisele, arendamisele ja kvaliteedi parandamisele. Probleem väljendub eelkõige järgmistes juhtimisprotsessides:

• teenuse mahu ja kvaliteedi juhtimine;

• kasutajakogemuse terviklik juhtimine;

• tervikteenuste väärtusahelate juhtimine;

• teenuste arendamise planeerimine;

• strateegia, personali, finantside, IT, riskijuhtimise ja teiste tugiprotsesside sidumine teenuste juhtimisega.

• Prognooside loomine, kõigi juhtimisprotsesside osana. Kasutajakogemus ei kujune terviklikuks väärtusahelaks Teenuse kasutaja ei erista organisatsiooni, infosüsteeme ega ametkondi. Tema jaoks moodustavad erinevad teenused ühe tervikliku väärtusahela. Täna ei ole aga linna teenuste protsessid, andmed ega teenustevahelised seosed kirjeldatud viisil, mis võimaldaks seda väärtusahelat tervikuks juhtida. Sama eesmärki toetavad teenused võivad olla korraldatud erinevalt, kasutada erinevaid mõisteid ning tugineda erinevatele protsessidele. Selle tulemusena võib kasutajakogemus olla ebaühtlane nii erinevate asutuste kui ka teenuskanalite lõikes. Sama probleem ei puuduta ainult Tallinna linna. Justiits- ja Digiministeerium tegeleb kasutajakeskse väärtusahela kujundamisega elu- ja ärisündmusteenuste kaudu ning Eesti Linnade ja Valdade Liit toetab kohalikke omavalitsusi teenuste kvaliteedi ühtlustamisel. Ühiseks väljakutseks on teenuste kirjeldamine ja juhtimine viisil, mis võimaldaks teenuseid arendada organisatsioonide üleselt ning tagada riigi ja kohalike omavalitsuste teenuste koostoimelisus. Puudub teenuspõhist juhtimist toetav teadmistekiht Teenuspõhisele juhtimisele üleminek eeldab, et teenust on võimalik käsitleda ühtse juhtimisobjektina sõltumata sellest, kas seda juhitakse toimingu, teenuse, tervikteenuse, valdkonna või tugiprotsessi vaates. Selle eelduseks on teenuse kohta käiva info terviklik ja ühetaoline kirjeldamine ning seoste loomine teenuse protsesside, andmete, rollide, ressursside ja strateegiliste eesmärkide vahel. Täna selline keskne teadmistekiht puudub. Teenuse juhtimiseks vajalik info paikneb erinevates infosüsteemides, dokumentides ja andmeallikates ning seda hallatakse erinevatel eesmärkidel ja erinevate reeglite alusel. Seetõttu puudub ühtne alus, mille põhjal oleks võimalik käsitleda teenust ühe tervikliku juhtimisobjektina ning kasutada sama teenusekirjeldust erinevates juhtimis- ja tugiprotsessides. Selle tulemusena kogutakse sama teenuse kohta andmeid korduvalt, teenusekirjeldused ei ole omavahel võrreldavad ning teenuse juhtimiseks vajalik tervikvaade tuleb koostada mitmest erinevast allikast. Samuti puudub piisav alus andmete taaskasutamiseks, automatiseerimiseks ja tehisaru rakendamiseks.

2. Projekti eesmärk Sõnastage konkreetne, selge ning mõõdetav eesmärki, mille saavutamist või mitte saavutamist on võimalik hinnata.

• Kirjeldage, kuidas plaanite projekti eesmärgi saavutamist mõõta.

Projekti eesmärk Katseprojekti eesmärk on testida, kas ühtne teenuse andmemudel võimaldab kasutada teenuskataloogi keskse teadmistekihina, mis toetab teenusjuhtide, tervikteenuste eest vastutajate, valdkonna juhtide ning tugiteenuste igapäevast tööd läbi tehisaru süsteemse rakendamise teenuspõhises juhtimises. Selleks luuakse teenuskataloogi prototüüp, mis toimib katse objektina. Prototüübi abil valideeritakse teenuse andmemudel, andmehalduse põhimõtted ja tehnilise lahenduse ülesehitus ning hinnatakse, millist praktilist väärtust loob tehisaru teenuste juhtimise erinevatel juhtimistasanditel. Teenuskataloogi eesmärk ei ole koondada kõiki teenuseandmeid ühte infosüsteemi, vaid kujuneda keskseks teadmistekihiks, mis seob teenuse juhtimiseks vajalikud andmed omavahel ning võimaldab neid kasutada iseteeninduslikult erinevates juhtimis- ja tugiprotsessides. Projekti tulemus Katseprojekti tulemusena valmib valideeritud teenuse andmemudel, teenuskataloogi prototüüp ja tehisaru rakendusmudel, mille abil hinnatakse teenuse juhtimiseks vajaliku teadmistekihi toimimist praktikas. Katse annab vastuse eelkõige järgmistele küsimustele:

• millised andmed on vajalikud teenuse juhtimiseks erinevatel juhtimistasanditel;

• kuidas kujundada teenuse andmehaldus nii, et see toetaks aktiivset teenusjuhtimist;

• kuidas võimaldada teenusjuhtidel ja tugiteenustel kasutada teenuseandmeid iseteeninduslikult;

• millised tehisaru kasutusvõimalused loovad teenusjuhtimisele suurimat praktilist väärtust;

• kuidas kujundada lahendus, mis on laiendatav teistele teenustele, kohalikele omavalitsustele ning koostoimeline riiklike teenusekirjelduse põhimõtetega.

• milline on eesmärke toetava teenuskataloogi tehniline ülesehitus, mis tagab andmemudeli ja tehisaru rakendamise võimalused?

Kuidas teame, et õnnestume? Projekti edukust hinnatakse järgmiste tulemuste kaudu:

1. Valminud on neljatasandilist teenuspõhist juhtimist toetav teenuse andmemudel. Mudel on dokumenteeritud ja testitud reaalsete teenuseandmete peal.

2. Loodud on teenuskataloogi tehniline prototüüp. Prototüübi tehniline ülesehitus toetab

teenuse andmemudeli- ja tehisaru paindlikku rakendamist ja selle funktsionaalsused on

demonstreeritavad ja kasutatavad vähemalt ühe alamvaldkonna teenuste ulatuses. Tehnilise

prototüübi osana selgub ka andmeallikate teenuskataloogiga sidumiseks vajalik adaptermustri

spetsifikatsioon.

3. Teenuskataloogis kirjeldatud teenuste andmed vastavad kokkulepitud andmekirjelduse

standardile ja on sobivad tehisaru rakenduste sisendiks (masinloetavad).

4. Katse skoobis on kokku lepitud teenuseandmete omanikud, vastutajad ja andmehalduse

põhimõtted.

5. Tehisaru kasutusvõimalusi testitakse eri teenuste juhtimistasandite töö tõhustamiseks.

Erinevate juhtimistasandite töö iseloomust lähtuvalt testitakse turul olemasolevaid tehisaru

rakendusi vähemalt 3-4 erineva tööprotsessi toetamiseks.

6. Katseprojekti tulemeid mõõdetakse nii kvalitatiivselt kui kvantitatiivselt. Tehisaru

rakendamisel eeldatav ajakulu teenusjuhtimise töös väheneb vähemalt 15% võrra.

Kui katse tulemusena väheneks teenusjuhtimise analüüside ettevalmistamise ajakulu vähemalt

15%, tähendaks see näiteks KEKO kalmistuteenuse näitel ühe teenuse kohta ligikaudu 22–32

töötunni ehk 3–4 tööpäeva kokkuhoidu aastas. Kui sama suurusjärku ajavõit oleks laiendatav

linna ligikaudu 500 teenusele, tähendaks see potentsiaalselt 10 800–16 200 töötundi ehk 1

350–2 025 tööpäeva aastas. See vastab ligikaudu 6–9 täistööaasta mahule, mida oleks

võimalik suunata andmete käsitsi koondamiselt teenuste sisulisele juhtimisele ja arendamisele.

Katsetetulemuslikkust hinnatakse nii kvantitatiivselt kui ka katses osalenutega tehtud pool-

struktureeritud tagasisideküsitluse või intervjuude põhjal.

7. Katseprojekti tulemusi arvestades luuakse tehisaru rakendusmudel. Mudelit on võimaik

laiendada ka teistele organisatsioonidele, valdkondadele ja teenustele.

3. Võimalikud lahendussuunad (max 2 lk) Kirjeldage võimalikke lahendusi ning tegevusi, millega projekti eesmärk saavutatakse.

• Kirjeldage võimalikke lahendussuundi, põhjendage eelistatud lahendussuuna valikut (NB! Valitud lahendussuund ei ole siduv, see võib projekti käigus muutuda).

• Kirjeldage probleemi lahendamiseks vajalikke tegevusi, mida antud katseprojekti raames plaanitakse teha.

• Selgitage, kuidas lahendust katsetatakse. Selgitage, kuidas läbi viidavat katsetust ja selle edukust hindate.

Tallinna linn on üle minemas teenuspõhisele juhtimisele, mille keskseks juhtimisobjektiks on teenus. Selle eelduseks on ühtse teenuse andmemudeli loomine, mis võimaldab siduda teenuse kirjelduse, protsessid, andmed, rollid ja mõõdikud terviklikuks juhtimissüsteemiks ning toetab teenuste juhtimist toimingu, teenuse, tervikteenuse ja valdkonna tasandil.

Katseprojekti keskne hüpotees on, et ühtne teenuse andmemudel võimaldab kujundada teenuskataloogi teenuspõhise juhtimise keskseks teadmistekihiks, mis toetab nii aktiivset teenusjuhtimist kui ka tehisaru rakendamist. Võimalikud lahendussuunad Probleemi lahendamiseks hinnati kolme võimalikku lähenemist. A. Valdkonna- või asutusepõhised tehisaru lahendused võimaldavad kiiresti lahendada konkreetseid tööülesandeid, kuid loovad asutusepõhiseid lahendusi, mis tuginevad erinevatele teenusekirjeldustele ja andmemudelitele ning ei ole hõlpsasti taaskasutatavad. B. Tehisaru rakendamine olemasolevate infosüsteemide peal võimaldab kasutada olemasolevaid andmeid, kuid ei lahenda teenuste kirjeldamise ja andmehalduse killustatust. Tehisaru kasutus jääb üksikute süsteemide ja tööprotsesside tasemele. C. Teenuskataloog kui teenuspõhise juhtimise keskne teadmistekiht loob ühtse teenuse andmemudeli, mis seob teenuse kirjelduse, protsessi, mõõdikud ja seosed teiste infosüsteemidega. Teenuskataloog ei dubleeri olemasolevaid süsteeme, vaid loob ühise teadmistekihi, millele saavad tugineda teenusjuhid, tugiteenused ja tehisaru rakendused. Katseprojektis valiti kolmas lahendussuund (C), kuna see ei optimeeri üksnes olemasolevaid tööprotsesse, vaid loob ühtse juhtimisaluse teenuspõhisele juhtimisele ning võimaldab hinnata tehisaru rakendamist kogu teenuse väärtusahela ulatuses. Teenuskataloog koondab teenuse juhtimiseks vajaliku kirjelduse ühte kohta. See sisaldab teenuse põhiandmeid, universaalseid juhtimisnäitajaid, protsessi kirjeldust ning seoseid teenusega seotud infosüsteemide, dokumentide ja teiste teenustega. Selline lähenemine võimaldab käsitleda teenust ühtse juhtimisobjektina sõltumata sellest, kus teenuse detailandmed paiknevad. Tehnilise lahendussuuna ideekavandiga saab tutvuda dokumendi lisas 1.

Disainikriteeriumid loodavale teenuskataloogile Katse edukat läbiviimist toetab teenuskataloog, mis:

• toetab neljatasandilist teenuspõhist juhtimist ühtsel andmemudelil;

• seob teenuse kirjelduse, protsessi, mõõdikud, seotud andmed ja infosüsteemid terviklikuks vaateks;

• võimaldab teenusjuhtidel hallata teenuse kirjeldust ning tugiteenustel kasutada teenuseandmeid iseteeninduslikult;

• vähendab dubleerivat andmehaldust ning loob aluse aktiivsele ja andmepõhisele teenusjuhtimisele;

• võimaldab masinloetavust, ning on koostoimeline riiklike teenusekirjelduse põhimõtetega ning laiendatav teistele teenustele ja kohalikele omavalitsustele.

Katsekeskkonna valik Katseprojekt viiakse läbi Tallinna Keskkonna- ja Kommunaalameti kalmistu- ja matuseteenuste näitel, kuna see võimaldab lühikese aja jooksul saada võimalikult palju teadmisi loodava lahenduse rakendatavuse kohta. Pilootvaldkonna valikut toetavad kolm peamist põhjust:

• selge ärivajadus – teenuse juhtimiseks vajalikud andmed paiknevad mitmes infosüsteemis ning juhtimisanalüüside koostamine põhineb suures osas käsitsi andmete koondamisel;

• motiveeritud partner – Tallinna Keskkonna- ja Kommunaalamet osaleb aktiivselt teenuspõhise juhtimise arendamises ning on valmis katset läbi viima koos projektimeeskonnaga;

• hea õpikeskkond – kalmistu- ja matuseteenus hõlmab mitut organisatsiooni, protsessi ja infosüsteemi ning võimaldab hinnata lahenduse toimivust ka sündmusteenuse väärtusahela vaates koostöös Justiits- ja Digiministeeriumi ning Eesti Linnade ja Valdade Liiduga.

Katse annab võimaluse hinnata nii teenuse andmemudeli üldistatavust kui ka loodava lahenduse laiendatavust teistele teenustele ja kohalikele omavalitsustele. Katseprojekti olulisemad tegevused

1. töötatakse välja teenuse andmemudel, mis toetab neljatasandilist juhtimissüsteemi; 2. kirjeldatakse katse skoobis olevad teenused, protsessid ja seosed; 3. lepitakse kokku andmehalduse rollid ja vastutused; 4. töötatakse välja teenuskataloogi andme- ja tehnilise arhitektuuri lahendus; 5. luuakse teenuskataloogi prototüüp koos kasutajaliidesega; 6. sisestatakse teenuste andmed vastavalt kokkulepitud standarditele; 7. testitakse tehisaru rakendamist valitud kasutusjuhtumites; 8. liidestatakse teenuskataloog vähemalt kahe infosüsteemiga, et testida teenuse tasandi

andmete sidumist juhtimisvaadetega; 9. katsetatakse lahendust teises teenusvaldkonnas ning täiendatakse selle põhjal andmemudelit

ja tehnilist lahendust; 10. hinnatakse tulemusi ning koostatakse ettepanekud lahenduse edasiseks arendamiseks ja

kasutuselevõtuks.

Tehisaru võimalikud kasutusjuhtumid Katseprojekti käigus hinnatakse tehisaru praktilist väärtust kõigil teenuse juhtimistasanditel.

1. Toimingu juhtimine Tehisaru toetab teenuse osutamisega seotud tegevusahelate analüüsimist ja standardiseerimist. Võimalikud kasutusjuhud hõlmavad protsesside automaatset kirjeldamist, menetluste kitsaskohtade tuvastamist ning tööjuhiste koostamist.

2. Teenuse juhtimine Tehisaru toetab teenuse kvaliteedi, mahu ja kasutajakogemuse juhtimist. Võimalikud kasutusjuhud hõlmavad kasutajatagasiside analüüsi, teenuse kvaliteediprobleemide tuvastamist, mahu prognoosimist ning arendusettepanekute koostamist.

3. Tervikteenuse juhtimine Tehisaru toetab erinevate teenuste sidumist terviklikuks väärtusahelaks. Võimalikud kasutusjuhud hõlmavad teenustevaheliste sõltuvuste analüüsi, dubleerivate tegevuste leidmist ning väärtusahela kitsaskohtade tuvastamist.

4. Valdkonna juhtimine Tehisaru toetab strateegilist juhtimist ning avaliku hüve saavutamise hindamist. Võimalikud kasutusjuhud hõlmavad mõjuanalüüse, prognoose, arengustsenaariumite modelleerimist, investeeringute prioriseerimist ning strateegiliste riskide tuvastamist.

Katseprojekti hindamine Katseprojekti käigus hinnatakse, millist praktilist väärtust loob ühtne teenuse teadmistekiht erinevate juhtimistasandite töö toetamisel. Hindamine toimub nii kvalitatiivsete kui kvanitatiivsete meetodite kaudu (vt ka ptk 2, projekti edukuse hindamine). Katse edukuses hindame:

• Kuidas võimaldab teenuse andmemudel kirjeldada teenuseid toimingu, teenuse, tervikteenuse ja valdkonna juhtimistasandil?

• Milliseid praktilist väärtust loovaid tehisaru kasutusjuhtumeid on võimalik teenuskataloogi põhjal rakendada?

• Mil määral aitab keskne andmemudel vähendada andmete dubleerimist ning parandada andmete taaskasutatavust?

• Kui palju aitab tehisaru vähendada teenusjuhtide halduskoormust ning suurendada andmepõhist otsustamist?

• Millistel tingimustel on loodud lahendus laiendatav teistele teenustele, valdkondadele ja kohalikele omavalitsustele?

Katseprojekti peamine tulemus ei ole üksiku tehisaru rakenduse käivitamine, vaid teadmise loomine selle kohta, kuidas kasutada teenuse andmemudelit, teenuskataloogi ja tehisaru ühtse juhtimissüsteemina, mis toetab teenuste kvaliteeti, tõhusust ja kasutajakeskset arendamist.

4. Projekti uuenduslikkus

Tuua selgelt välja projekti uuenduslikkus –mida tehakse senisest teisiti kas see hõlmab uusi tehnoloogiaid, protsesse, toimemudeleid, disaini, turgu vms?

• Selgitage lahenduse uuenduslikkust nii Eesti kui globaalses kontekstis.

• Mis on projektis sellist, mis vajab katsetamist?

Projekti uuenduslikkus seisneb selles, et katsetatakse uut lähenemist teenuspõhisele juhtimisele, kus teenus on samaaegselt juhtimisobjekt, teadmisteobjekt ja tehisaru tööobjekt. Tänased avaliku sektori tehisaru lahendused keskenduvad valdavalt üksikute tööprotsesside automatiseerimisele või konkreetsete infosüsteemide andmete analüüsimisele. Käesolev projekt liigub sellest sammu edasi, luues esmalt ühtse teenuse teadmismudeli, millele saab rajada erinevaid tehisaru rakendusi sõltumata konkreetsest infosüsteemist. Projekti keskmes ei ole uue tehisaru lahenduse arendamine, vaid teenuse andmemudeli valideerimine ning teenuskataloogi kui keskse teadmistekihi katsetamine. See võimaldab hinnata, kuidas ühtne teenusekirjeldus toetab samaaegselt teenuste juhtimist, tugiprotsesse ja tehisaru kasutamist. Uuenduslikkus Eesti kontekstis Eestis on viimastel aastatel tehtud olulisi samme teenuspõhise juhtimise, sündmusteenuste ja andmepõhise juhtimise arendamisel. Käesolev projekt loob praktilise rakendusmudeli teenuspõhisele juhtimisele üleminekuks, kus teenuse kirjeldus muutub erinevate juhtimis- ja tugiprotsesside ühise teadmiskihi osaks. Katseprojekti tulemusena valmiv teenuse andmemudel, teenuskataloogi loogika ja tehisaru rakendamise mudel on taaskasutatavad ka teistes kohalikes omavalitsustes, kuna lähtuvad ühtsetest teenusekirjelduse põhimõtetest ning koostoimelisusest riiklike raamistikuga. Pikemas perspektiivis loob see eeldused sidusamaks teenuste arendamiseks üle organisatsiooniliste piiride ning toetab riigi ja kohalike omavalitsuste teenuste terviklikumat väärtusahelapõhist juhtimist. Mis vajab katsetamist? Projekti käigus testitakse mitut seni tõendamata eeldust:

• milline teenuse andmemudel on piisav tehisaru rakendamiseks erinevatel juhtimistasanditel;

• kuidas kirjeldada teenuse protsesse, rolle ja andmeid viisil, mis võimaldab nende masinloetavat kasutamist;

• millised andmed on vajalikud teenuse juhtimiseks toimingu, teenuse, tervikteenuse ja valdkonna tasandil;

• kuidas kujundada andmete omandi- ja vastutusmudel teenuspõhises juhtimises;

• millist praktilist väärtust loob tehisaru teenusjuhtidele nende igapäevatöös;

• kuidas kasutada tehisaru teenuse kvaliteedi, kasutajakogemuse, arendusvajaduste analüüsimiseks ja tulevikusuundumuste prognoosimiseks.

• milline on andmepõhist juhtimist ja tehisaru rakendamist toetava teenuskataloogi tehniline ülesehitus?

Uuenduslikkus rahvusvahelises kontekstis Rahvusvaheliselt on teenuspõhine juhtimine, teenuse arhitektuur ja tehisaru rakendamine avalikus sektoris kiiresti arenevad valdkonnad. Enamasti käsitletakse neid siiski eraldiseisvate teemadena – teenuseid kirjeldatakse kasutajakesksuse toetamiseks, andmeid hallatakse infosüsteemide vaates ning tehisaru rakendatakse üksikute tööprotsesside automatiseerimiseks. Teenusearhitektuuri põhimõtted, mille kohaselt teenuseid kirjeldatakse ühtsete mustrite, korduvkasutatavate komponentide ja selgete seoste kaudu on kooskõlas ka GOV.UK lähenemisega. Käesolev projekt laiendab seda loogikat teenuste juhtimise tasandile, luues eelduse, et sama teenuse kirjeldust saab kasutada samaaegselt teenuse juhtimises, arendamises, andmehalduses ning tehisaru rakendustes. Selline lähenemine suurendab lahenduse taaskasutatavust, koostoimelisust ja praktilist väärtust ning loob aluse teenuste juhtimise uuele kvaliteeditasemele nii kohalikus kui ka laiemalt avaliku sektori kontekstis. Rahvusvahelised viited

• Welcome to GOV.UK AI Studio (Suurbritannia) katsetab teenusetüpoloogiate ja teadmusgraafide kasutamist agentic AI skaleerimiseks. 75 teenuse analüüsi põhjal tuvastati 8 teenusetüüpi, mis võimaldavad tehisaru rakendusi luua mustripõhiselt.

• Bürokratt 2026+ (Eesti) liigub mudelile, kus iga asutus saab kasutada oma TA agenti osana ühtsest agentide võrgustikust. Tallinna teenuste kataloog võib toimida struktureeritud teadmusbaasina, mida Tallinna teenuste agent Bürokratti võrgustikus vajab.

• Helsinki Experimentation Accelerator (Soome) on rakendanud 40+ TA eksperimenti, sh tööjõuvajaduse prognoosimine — paralleel valdkonna tasandi mahuprognoosile.

• Singapore LifeSG demonstreerib teenuste sidumist kasutaja elusündmusega — paralleel tervikteenuse tasandi loogikale.

• Welcome to GOV.UK Chat on tõestanud RAG-arhitektuuri toimimist valitsusteenuste sisul. Kui enamus näiteid keskendub kasutajavaatele, siis Tallinna projekt lähtub teenusest kui andmeobjektist ja teenusjuhi vaatest — kuidas tehisaru toetab teenuse juhtimist ja strateegilist planeerimist. See nurk on rahvusvaheliselt vähem uuritud.

5. Projekti elluviimisega (katsetusega) seotud riskid ja nende maandamismeetmed Kirjelda peamisi riske, mis võivad takistada projekti elluviimist või eesmärkide saavutamist, ning kavanda maandamismeetmed.

Käesoleva projekti puhul ei seisne peamised riskid niivõrd tehnoloogia kasutuselevõtus, vaid teenuspõhise juhtimise, andmehalduse ja tehisaru rakendamise ühendamises ühtseks juhtimismudeliks. Katseprojekti eesmärk ongi maandada neid riske kontrollitud keskkonnas enne laiemat kasutuselevõttu. Võimalikud riskid ja nende maandamisvõimalused: 1. Puudub ühene arusaam teenuse andmemudelist ja juhtimistasanditest Teenuspõhine juhtimine eeldab kokkulepet selles, mida juhitakse toimingu, teenuse, tervikteenuse ja valdkonna tasandil ning milliseid andmeid igal tasandil kasutatakse. Ilma ühise mudelita võivad erinevad osapooled jätkata erinevate teenusekirjelduste, mõistete ja andmestike kasutamist. Riski maandamine

• projekti käigus töötatakse välja ühtne teenuse andmemudel;

• teenuste kirjeldamisel kasutatakse Justiits- ja Digiministeeriumi teenuse standardit;

• katse viiakse läbi piiratud skoobis, kus juhtimistasandid, mõisted ja andmeväljad lepitakse eelnevalt kokku.

• Katse viiakse läbi valdkonnas, mille erinevate tasandite juhid omavad teadmisi ja kogemusi mudeli ellu rakendamiseks

2. Andmete kvaliteet ja omand ei võimalda tehisaru tõhusat rakendamist Tehisaru rakenduste kvaliteet sõltub otseselt sisendandmete kvaliteedist. Kui teenuse andmed on puudulikud, killustatud või puudub selgus andmete omanike ja vastutajate osas, võivad ka tehisaru loodud soovitused olla ebatäpsed. Riski maandamine

• määratletakse andmete omanikud ja vastutajad;

• luuakse teenuse andmekirjelduse standard;

• katseprojekti käigus testitakse andmehalduse protsesse ja vastutusmudelit;

• keskne teenuskataloog toimib teenuse andmete koondina.

• katse läbiviimiseks valitakse teenusvaldkond, kus andmed on kättesaadavad või kus teenusejuhil on võimekus andmed kokku koondada ja nende haldamise kvaliteet tagada

3. Tehisaru rakendused kujunevad organisatsioonis killustunuks

Üks suuremaid pikaajalisi riske on olukord, kus erinevad üksused hakkavad rakendama tehisaru iseseisvalt, kasutades erinevaid andmeid, mõisteid ja tööprotsesse. Sellisel juhul suureneb süsteemide killustatus ning väheneb tulemuste võrreldavus ja taaskasutatavus. Riski maandamine

• tehisaru rakendusi testitakse keskse teenuskataloogi kaudu;

• kasutatakse ühist teenuse andmemudelit ja teadmistekihti;

• keskne lähenemine võimaldab hinnata, milliseid tehisaru kasutusjuhtumeid on mõistlik skaleerida üle linna ja hiljem üle KOVide

4. Tehisaru kasutamine ei loo piisavat praktilist väärtust teenusjuhtidele On võimalik, et osa tehisaru kasutusjuhtumeid ei anna oodatud efekti või ei vähenda teenusjuhtide töökoormust hüpoteesis ootusena sätestatud määral ehk 15% ulatuses. Riski maandamine

• katsetatakse konkreetseid teenusjuhtimise kasutusjuhtumeid (nt kasutajatagasiside analüüs, protsesside analüüs, probleemkohtade tuvastamine ja prognoosimine);

• hinnatakse kasutusjuhtumite mõju teenusjuhtide tööle;

• projekti käigus kogutakse sisendit edasisteks arendusteks. Ka negatiivne tulemus on projekti jaoks väärtuslik teadmine, sest aitab vältida ebatõhusaid investeeringuid tulevikus. 5. Õigusruum ei toeta kõiki võimalikke tehisaru rakendusi Tehisaru kasutamine avalikus sektoris peab vastama kehtivale õigusruumile, andmekaitse nõuetele ning avaliku võimu teostamise põhimõtetele. Samuti võivad ilmneda regulatiivsed kitsaskohad, mis takistavad teatud kasutusjuhtumite rakendamist. Riski maandamine

• projektis lähtutakse Eesti tehisaru arengusuundadest ja Euroopa Liidu tehisaru regulatsioonidest;

• tehisaru kasutatakse otsustamist toetava tööriistana;

• lõplikud otsused jäävad alati inimese pädevusse;

• hinnatakse iga kasutusjuhtumi vastavust õiguslikele nõuetele. 6. Andmekaitse piirangud on Tallinna sees juba praegu aktiivsed, mitte teoreetilised Tallinna digiteenistuse praktikas on andmekaitse hinnangu alusel hetkel piiratud isegi tavapärase analüütika kasutamine menetlusandmete peal — andmeid ei tohi puudutada rohkem, kui need on olemas algses menetlussüsteemis. See tähendab, et tehisaru kasutusjuhtumite (eriti tagasiside analüüs ja prognoosimine) elluviimine eeldab selgelt piiritletud andmekoosseisu, mis on andmekaitse mõttes juba ette kinnitatud. Riski maandamine — andmekaitse hindamine ja andmekoosseisu kokkulepe (I etapi tegevus) Enne teenuste kataloogi tehnilist arendust viiakse läbi andmekaitse mõjuhinnang (DPIA) koostöös Tallinna andmekaitsespetsialistiga:

• määratletakse, millised andmeväljad on lubatud teenuste kataloogi liikuda igast allikast — eristades selgelt agregeeritud/metaandmeid (lubatud) menetlustasandi üksikjuhtumi andmetest (ei kuulu skoopi)

• kinnitatakse andmete otstarbe piiritlus (purpose limitation) ja õiguslik alus TA-analüüsi jaoks

• määratletakse säilitustähtajad ja kustutamise põhimõtted

• nõutakse agregeerituse miinimumtaset (nt minimaalne rühma suurus), mis välistab kaudse tuvastatavuse

See hindamine on eelduseks järgnevatele tehnilistele tegevustele ja peab olema läbitud enne andmete sisestamise etappi (III etapp).

6. Projekti ajakava

Koostage realistlik ajakava, mis hõlmab kõiki projekti tegevusi ning annab sellega sisendi projekti eelarve koostamisele.

• Ajakava koostamisel arvestage vajalike eel- ja järel- või vahetegevustega (nt partnerluslepingu sõlmimise ettevalmistus kuni 2 kuud, vajalike lubade saamine projekti jooksul vms).

• Milliste võimalike puhvritega oleks ajakavas mõistlik arvestada?

• Jagage tegevused loogilisteks etappideks, arvestage tegevuste omavahelisi seoseid ning ajalist järgnevust või paralleelsust.

• Hangete läbiviimise ajaraami kavandamiseks kasuta hankekalkulaatorit Hankekalkulaator - EIS

Tegevused Tegevuse algus

(mitmes kuu)

Tegevuse lõpp (mitmes kuu)

Kestus kokku (mitu kuud)

AASTA 1 – Defineerimine, prototüüp ja kontseptsiooni valideerimine

Etapp 0 — Käivitamine ja hanked Kuu 1 Kuu 3 3 kuud

Projekti juhtrühma, töörühma ja juhtimismudeli paikaseadmine

Hangete ettevalmistus ja läbiviimine

Hankepartnerite lepingute sõlmimine

Etapp 1 – Kontseptsioon ja disain Kuu 2 Kuu 7 6 kuud

Katse valdkonna ja skoobi täpsustamine

Katsevaldkonna lõikes ärianalüüs

Teenuse andmemudeli väljatöötamine (iteratiivne, mitte ühekordne)

Teenuste kaardistamine (pilootvaldkonnas)

Andmehalduse põhimõtted ja rollid

Andmekaitse hindamine (DPIA)

Etapp 2 – Tehniline prototüüp (MVP) Kuu 5 Kuu 12 8 kuud

Andme ja tehnilise arhitektuuri väljatöötamine

Detailanalüüs ja UX-disain

Andmemudel ja API integratsioonid

Sisestusliides

Esmane liidestus andmebaasiga (nt ATAK)

Esmane andmete sisestus

Andmekvaliteedi korrastamine

Etapp 3 – Andmete täitmine ja piloot Kuu 9 Kuu 15 7 kuud

Teenuste andmete täiendamine

Teenusjuhtide koolitamine

Andmete sisestus ja valideerimine

Teenusejuhi töövoogude testimine

Etapp 4 – TA kasutusjuhtude katsetamine

Kuu 10 Kuu 16 7 kuud

3-4 kasutusjuhtumi katsetamine

Iteratiivne arendamine

Mõju hindamine

Etapp 5 – Hindamine ja MVP stabiliseerimine

Kuu 14 Kuu 18 5 kuud

Mõju hindamine ja katse edasiste otsuste tegemine

Kasutatavuse hindamine ja parandamine

Andmekvaliteedi hindamine ja korrastamine

AASTA 2 – Katse laiendamine, valideerimine ja skaleerimise võimaluste hindamine

Etapp 6 – Katse laiendamine ja integratsioonid

Kuu 16 Kuu 22 7 kuud

Taotlen liidestus (nt. Teenuse andmevahetuse sidumiseks kasutaja rahuloluga)

Planpro liidestus (nt. teenuse andmevahetuse sidumiseks strateegiliste eesmärkidega)

Andmemudeli täiendused

Etapp 7 – Teine piloot ja KOV valideerimine Kuu 18 Kuu 23 6 kuud

Teise valdkonna lõikes piloodi läbiviimine

Teise KOVi katsetamine (kui jõuab)

Adapterimustri valideerimine

Etapp 8 - Lõppväljundid ja ettevalmistus implementeerimiseks

Kuu 22 Kuu 24 3 kuud

Lõppmudeli väljatöötamine

Rakendusmudeli väljatöötamine

Soovitused riigile

Jätkuprojekti ettevalmistus

KOKKU 24 kuud

7. Projekti eelarve Koostage realistlik eelarve detailsusega, mis hõlmab kõiki projekti tegevusi ning võimaldab seeläbi hinnata planeeritud kulude vajalikkust ja mõistlikkust.

• Arvutage eelarves summad kogumaksumusena (st sisaldavad kõiki makse), sh projektijuhi kogukulu.

• Lisage eelarvele kirjeldusena selle kujunemise põhjendused, arvutuste ja hinnangute alused.

• Eelarve kogusumma palume esitada 1000 euro täpsusega. Kohandage eelarvetabelit oma projekti vajadustele vastavaks.

Tegevused Hanke- partner 1

kulud

Hanke- partner 2

kulud

Hanke- partner 3 kulud

Muud kulud

Kulud kokku

Etapp 0 — Käivitamine ja hanked

Etapp 1 – Kontseptsioon, ärianalüüs ja disain

81,000 81,000

Andmemudel, andmehaldus ja DPIA

29,000 29,000

Etapp 2 – Tehniline prototüüp (MVP)

240,000 240,000

ATAK liidestus 62,000 62,000

Etapp 3 – Andmete täitmine ja piloot

15,000 50,000 65,000

Etapp 4 – AI kasutusjuhtude katsetamine

44,000 44,000

Etapp 5 – Hindamine ja MVP stabiliseerimine

22,000 19,000 41,000

Etapp 6 – Katse laiendamine ja integratsioonid

87,000 108,000

Etapp 7 – Teine piloot ja KOV valideerimine

41,000 38,000 79,000

Etapp 8 - Lõppväljundid ja skaleerimise võimaluste hindamine

Tarkvara halduskulud 15,000 15,000

Projektijuhtimine 135,000 135,000

KOKKU 188,000 478,000 62,000 150,000 899,000

Eelarve selgitus

• IT-projektijuhi palgafondi arvestamisel on võetud aluseks tööandjakulu ühele täistööajaga

töökohale brutotasu suurusega 4200 eurot kuus 24 kuu jooksul, mis moodustab ligikaudu 19%

projekti kogueelarvest. Projektijuhtimise kulu hõlmab väljast sisse ostetavat täistööajaga

projektijuhi/tootejuhi rolli, kelle ülesanne on siduda ärivajadus, teenuse andmemudel, tehniline

lahendus ja tehisaru rakendused üheks terviklikuks arendusprotsessiks. Tegemist ei ole pelgalt

administratiivse projektijuhtimisega, vaid sisulise tootejuhtimise rolliga, mis on projekti

õnnestumiseks kriitilise tähtsusega.

• Tarkvara haldus- ja hoolduskulud on arvestatud 15,000€ / 12 kuud ehk u 1250€ / kuus katavad

teenuskataloogi prototüübi käitamiseks vajalikud pilvetaristu kulud, andmebaasi majutuse, API-de

ja integratsioonide töökindluse tagamise, tehisaru kasutusjuhtumite rakendamiseks vajalikud

teenustasud ning jooksva tehnilise halduse. Kulud sõltuvad kasutusmahust ja integratsioonide

mahust, kuid on hinnatud katseprojekti realistlikust vajadusest lähtuvalt.

• Tarkvara arenduskulud on kujunenud valitud tehnilise lahendussuuna põhjal, mis hõlmab

teenuskataloogi prototüübi arendamist PostgreSQL andmebaasi ja REST API baasil, liidestusi

olemasolevate infosüsteemidega (ATAK, Taotlen, PlanPro), kasutajaliidese loomist ning tehisaru

rakendamiseks vajaliku RAG- ja vektorbaasi lahenduse katsetamist. Lisaks hõlmab arendus

backend- ja integratsioonikihi ning test- ja arenduskeskkondade loomist. Kulude suurus tuleneb

mitme tehnilise komponendi koosarendusest ning vajadusest tagada nende koos toimivus

katseprojekti ulatuses.

• Eelarvetabel kajastab kulu jaotust kolme võimaliku hankepartneri vahel, lähtudes lahenduse

väljatöötamiseks vajaminevast erinevast ekspertiisist. Oleme teadlikud, et mitme hankepartneri

kaasamine kaheaastases projektis suurendab elluviimise keerukust ja seepärast kavandame

lõpliku hankestrateegia ning hankemenetluse ülesehituse ja läbiviimise koostöös EIS-iga, et valida

parim lähenemine ja maandada võimalikke riske.

8. Võimalikud lahenduste pakkujad Tooge välja võimalikud hankepartnerid, kes soovitud lahendussuunas tooteid/ teenuseid/ pakuvad.

• Otsige ja nimetage võimalikke probleemile lahenduste pakkujaid (nt erinevate valdkondade eksperdid, teadlased, ettevõtted, kes on probleemi lahendamisega varasemalt tegelenud).

Mõelge nii Eesti kui rahvusvaheliste pakkujate peale.

Projekti hankestruktuur on kolmeosaline. Hange 1 — Andmemudel, KOV-ülesus ja adapterimustri spetsifikatsioon See töö on võimalik teha kas jaotatuna Tallinna linna teenusedisaini meeskonnaga või hangituna täielikult välispartnerilt . Välispartneri kaasamine on põhjendatud, sest hõlmab mitme osapoole ja valdkonna kokkujuhtimist ning olukorras, kui soovitakse tuua katseprojekti lõikes sisse võrdluspilt mõne teise KOV-i teenustega, mida sisetiimil ei pruugi olla. Velvet OÜ — viisid läbi ELVL KOV digitaalse platvormi eelanalüüsi uuringu, mille järeldused käsitlevad otseselt vajadust ühtlustava proxykihi järele erinevate KOV-ide teenuste kirjelduste vahel. Omavad unikaalset ülevaadet erinevatest KOV-ide andmeallikatest ja teenuste kirjeldamise praktikatest. Kaasamine tagab, et adapterimustri spetsifikatsioon arvestab teiste KOV-ide vajadustega algusest peale ning loob otsese sideme KOV platvormi riikliku algatusega. Trinidad Wiseman — laialdane kogemus avaliku sektori teenusedisainis ja teenuste kirjeldamise metoodikas (Eesti.ee , ministeeriumite teenusportaalid). Sobiv partner andmemudeli disaini etapis, kuna mõistavad nii teenusjuhi vajadustepõhist lähenemist kui ka tehnilist andmestruktuuri. Eriti sobiv juhul, kui II etapi tehnilist arendust ei tehta Trinidad Wisemani poolt. PwC Eesti — avaliku sektori protsesside ja andmearhitektuuri nõustamine, kogemus teenuste standardiseerimise projektides. Hange 2 — Teenuste kataloog ja tehisaru kiht tervikuna (konkureeriv hange) Teenuste kataloog ja RAG-kiht arendatakse ühe partneri poolt, et tagada andmemudeli ja AI-sisendi kooskõla algusest peale. Trinidad Wiseman — haruldane kombinatsioon teenusedisaini mõtlemisviisist ja tehnilisest arenduskompetentsist. Kogemus avaliku sektori teenusplatvormide arenduses nii disaini kui tehnilise teostuse poolel. Eriti sobiv, kui Tallinna sisetiim on töösse aktiivselt kaasatud — sel juhul toob Trinidad Wiseman tehnilisse arendusse teenusedisaini mõtlemisviisi, mis tagab teenuste kataloogile kasutajakeskse ülesehituse. Mindtitan — Eesti juhtiv AI-rakenduste spetsialist, kogemus RAG-arhitektuuri ja suurmudelite rakenduslikes lahendustes avaliku sektori kontekstis. Eriti tugev AI-kihi poolel. Kombineeritud skoobis

tasub hankedokumentides täpsustada andmeplatvormi arenduse nõuded, et hinnata nende sobivust teenuste kataloogile. Nortal — täisspektri IT-partner, kogemus nii avaliku sektori andmeplatvormide kui AI-rakenduste arenduses. Maht ja kompetents sobivad kombineeritud skoobiga, kus teenuste kataloog ja AI kiht on üks tervik. Helmes — tugevad andmeplatvormide poolel, kasvav AI-arenduse kompetents, pikk avaliku sektori kogemus Eestis. Hange 3, ainupakkuja— ATAK liidestus AS Spin TEK — ATAK-i ainuarendaja. Hange RHS § 49 alusel, kuna ainult Spin TEK omab süsteemile vajalikku ligipääsu ja teadmust. Skoobiks API endpointi avamine, IP-whitelisti laiendamine Teenuste kataloogile ning andmeväljade kaardistuse kokkulepe. Konsultatiivsed koostööpartnerid (ei ole pakkujad, kuid olulised sidusrühmad) RIA — X-tee ja koostalitlusvõime standardi kogemus. Adapterimustri spetsifikatsiooni valideerimisel oluline konsultant, et tagada ühilduvus riiklike andmevahetuse standarditega. JDM (Justiits- ja Digiministeerium) — teenuse standardi ja teenuse elutsükli mudeli omanik. Teenuste kataloogis kasutatav andmemudel peab olema kooskõlas JDM-i teenuse standardiga — koostöö tagab, et projekti tulemused toetavad otseselt riiklikku teenuste standardimise algatust. ELVL — koordineerib väiksemate KOV-ide arengut. Adapterimustri spetsifikatsiooni valideerimisel oluline partner, tagamaks, et standard on rakendatav ka ressursipiiratud KOV-ides. TalTech / Tallinna Ülikool — akadeemiline partner tulemuste hindamiseks ja dokumenteerimiseks. Lisab projekti väljunditele teaduslikku legitiimsust ning loob võimaluse tulemuste publitseerimiseks rahvusvahelises kontekstis.

9. Projekti meeskond ja töökorraldus Tooge välja projekti edukaks elluviimiseks kaasatavad või vajalikud osapooled (asutused ja/või inimesed) ning täiendav ekspertiis, mida meeskonda juurde vajate.

• Kirjeldage rollide ja töö jaotust projektimeeskonnas.

• Kirjeldage projekti juhtimise korraldust.

• Märkige ära, kui suure koormusega projektijuht (võimalusel ka teised võtmeisikud) projekti panustavad.

• Kirjeldage, missugust täiendavat ekspertiisi tuleb juurde kaasata (nt tehniline ekspertiis, andmekaitse), mis on meeskonnaliikmete poolt katmata.

NB! Kui nimetate konkreetseid meeskonnaliikmeid, siis nendega (või nende juhtidega) peab olema projektis osalemine läbi räägitud!

Tallinna Strateegiakeskus, Strateegilise planeerimise teenistus, teenusedisaini büroo - projekti omanik ja eestvedaja Digiteenistus – Tehnilise teostuse vastutaja Juhtrühm

• Joel Kotsjuba, Teenusedisaini büroo juht – Projekti äripoole omanik ja vastutaja

• Martin Männil, Digiteenistuse direktor – Linna IT juhtimine, tehnilise lahenduse omanik ja tehnilise teostuse eest vastutaja

• Raido Roop, Strateegilise planeerimise teenistuse direktor, linna äripoole sponsor teenuspõhisele juhtimisele üleminekul

Projektitiim

• IT-arenduse projektijuht / tootejuht – värvatav roll ja isik selgumisel. Juhib kokku ärivajaduse, tehnilise- ja andmelahenduse ning AI rakenduse arenduse üheks tootevisiooniks ning juhib arendusprojekti edukalt lõpuni, 1 FTE (täistööajaga koht)

• Teele Kumm, Strateegilise planeerimise teenistus, teenusedisain – Teenuste kataloogi ja arendusprojekti ärivisiooni kujundamine ja ärisuuna sisuline eestvedamine

• Seidi Vilba, Digiteenistus, Andmete valdkond – andmete valdkond, andmekvaliteet

• Peeter-Marko Mikk, Digiteenistus, AI valdkond – AI rakendamine linna infosüsteemides

• Mari Roots, Digiteenistus, infosüsteemide arendamise osakonna juhataja– lahenduse IT-tehniline sidusus linna infosüsteemidega

Koostööpartnerid

• Keskkonna- ja Kommunaalamet, - Roll: Partnerasutus arendusprojekti piloodi läbiviimiseks ühe teenusvaldkonna näitel

o Urvi Kaljas, Kalmistute teenusejuht o Kaili Tamm, Otseste teenuste teenistuse juht

• Justiits- ja Digiministeerium, Digiriigi osakond, Teenuste talitus – Roll: Riigipoolne koostööpartner riikliku teenuste kataloogiga koostoimelisuse tagamiseks Õnne Kivinurm, Riikliku teenuste kataloogi projektijuht

• Eesti Linnade- ja Valdade Liit – Roll: ELVL poolne koostööpartner ELVL teenuste kataloogiga koostoimelisuse tagamiseks

o Annemarii Hunt, ELVL teenuste kataloogi projektijuht o Kaimo Käärmann-Liive, Lähedase surma sündmusteenuse juht

10. Projekti tulemuste elluviimine Kirjeldage oma valmisolekut ja võimekust pärast katseprojekti edukat lõppu projekti tulemusi kestlikult ellu viia.

.

• Kas projekti tulemuste edasine arendus ja kasutuselevõtt seostub asutuse prioriteetsete tegevustega, on tööplaanis vms?

• Kas tulemuste hilisemaks elluviimiseks vajalik rahastus ja muud ressursid on olemas või tegeletakse selle leidmisega?

• Tooge välja olulisemad riskid projekti tulemuste hilisemal kasutuselevõtul. Kuidas plaanite neid riske maandada?

• Kirjeldage, kas ja mil määral on tulemused skaleeritavad ning kasutatavad avalikus sektoris laiemalt.

Katseprojektis testitud lahendus võetakse kasutusele Tallinna teenuskataloogi arendamisel ning õpitut rakendatakse avalike teenuste andmekogu ehk ATAK edasiarendamiseks, mille äriline, tehniline ja andmealane kontseptsioon on uuendamisel. Projekti käigus tehakse tehnilised otsused kooskõlas riiklike standarditega, eesmärgiga tagada lahenduse koostoimelisus riikliku teenuse kataloogiga. Projekti käigus valminud tulemusi ja õpikohti jagatakse partnerasutustega ELVL ja Justiits- ja Digiministeerium, et võimaldada selle kasutuselevõttu ka ELVL ja riiklikus teenuse kataloogis. Tallinna linnaorganisatsioonis on teenuse kataloogi arendamine eesmärgistatud, lepinguline partner ja eelarve olemas. Vastavalt projekti tulemile ja ajakavale on linnaorganisatsioonil valmisolek ressursse juurde taotleda katseprojekti tulemuste kasutuselevõtuks. Peamiseks riskiks on

• Arendatav tehniline lahendus ei ole integreeritav linna olemasolevate infosüsteemidega.

Riski maandamiseks: Linna infosüsteemide eest vastutavad rollid on projekti kaasatud, tehnilises lahenduses arvestatakse linna infosüsteemide tehnilise arhitektuuri tänaseid ja tulevasi nõudeid.

• Arendatav tehniline lahendus ei ole koostoimeline uue riikliku teenuse kataloogi tehnilise lahendusega

Riski maandamiseks: Arendusprojektis arvestatakse riiklikku tehnilist koostoimeraamistikku koos tehniliste nõuetega, arendusprojekti käigus hoitakse Justiits- ja Digiministeeriumi tiimi kursis projekti arengutega ja võetakse arvesse arendatava riikliku teenuse kataloogi tehnilise lahenduse valikuid võimaluste piires.

11. Mõju ettevõtlusele

☒ Projekt omab positiivset mõju innovatsioonile ettevõtlussektoris. Kõige otsesemalt väljendub mõju

läbi ettevõtete, kes osalevad tegevuste elluviimiseks korraldatavatel hangetel ja/või konkurssidel.

Innovatsiooni hankimine avaliku sektori poolt aitab kaasa innovatsioonitegevuste kasvule erasektoris.

12. Seos nutika spetsialiseerumise valdkondadega

• Eesti teadus- ja arendustegevuse, innovatsiooni ning ettevõtluse (TAIE) arengukaval 2021-2035 on fookusvaldkonnad, s.o Eesti arenguvajadustele ja -võimalustele vastavad riigi, ettevõtete ja teadusasutuste koostöös eelisarendatavad teadus- ja arendustegevuse, innovatsiooni ja ettevõtluse valdkonnad. Ettevõtluse ja majandusliku arengupotentsiaaliga TAIE fookusvaldkonnad on ühtlasi Eesti nutika spetsialiseerumise valdkonnad (täpsem info: https://www.hm.ee/korgharidus-ja- teadus/teadus-ja-arendustegevus/taie-fookusvaldkonnad).

• Kirjeldage teie projekti võimaliku lahenduse seost vähemalt ühe valdkonnaga (rõhuasetusega teadmus- ja tehnoloogiasiirdel).

Digilahendused igas eluvaldkonnas (vt teekaarti)

Prioriteetne alamsuund “Teadus- ja arendustegevus andmevaldkonna arendamiseks” (andmevahetuse võimekus, paremad otsused, ligipääsetavad ja kvaliteetsed andmed).

Tervisetehnoloogiad ja - teenused (vt teekaart)

Kohalike ressursside (toit, puit, maapõueressursid, teisene toorme ja jäätmed) väärindamine (vt teekaart)

Nutikad ja kestlikud energialahendused (vt teekaart)

13. Seos strateegias Eesti 2035 toodud arenguvajadustega

• Selgitage, kuidas panustavad projekti tegevused ja valitud lahendussuund “Eesti 2035” strateegias kirjeldatud arenguvajadustesse.

• Tooge välja, kui projekti tegevused panustavad muudesse olulistesse valdkondlikesse arengukavadesse või -dokumentidesse.

https://valitsus.ee/sites/default/files/documents/2021- 06/Eesti%202035_PUHTAND%20%C3%9CLDOSA_210512_1.pdf Vajalik muudatus: Parandame riigi ja kohaliku omavalitsuse üksuste teenuste kvaliteeti ja kättesaadavust ning vaatame üle vastutuse jaotumise

• Avalike teenuste kujundamisel muudame kasutajakogemuse maksimaalselt lihtsaks ja inimest toetavaks (sh pakkudes kasutajatuge eesti keeles ja vajaduse korral teistes enamlevinud keeltes).

• Viime teenused võimalikult palju taustal toimivaks ja etteaimavaks, kasutades seejuures kõiki riigil olemasolevaid andmeid turvaliselt ning arvestades inimese tahte ja põhiõigustega.

• Rakendame ühtse asjaajamiskoha põhimõtet nii füüsilises kui ka digiruumis.

14. Avalike ülesannete täitmine projekti elluviimisel

• Selgitada ning tuua välja seosed ja viited, missuguse seaduse, määruse, haldusakti või lepingu alusel täidab ideekavandi esitaja asutus innovatsiooniprojekti ellu viies avalikke ülesandeid.

• Kui ideekavandi esitaja on MTÜ, siis selgitada, kuidas ta pakub otsest avalikku teenust (loe Teenuste korraldamise ja teabehalduse alused–Riigi Teataja, §2 lg2).

Esitatud innovatsiooniprojekt puudutab teenuseid, mida osutab kohalik omavalitsus, nende teenuste kvaliteedi ja kättesaadavuse parandamist. Teenuste osutamise näeb ette Kohaliku omavalitsiuse korralduse seadus, §6 Omavalitsusüksuse ülesanded ja pädevus https://www.riigiteataja.ee/et/akt/110022026012?leiaKehtiv

15. Rahastus mitmest allikast

• Kas probleemi lahendamiseks või planeeritud lahenduse katsetamiseks on taotletud või taotletakse toetust teistest rahastamisallikatest?

• Kui jah, siis tuua välja rahastusallikas, summa ja tegevused ning kas toetus on taotlemisel või projekt on saanud rahastusotsuse.

Käesoleva projekti probleemi lahendamiseks või planeeritud lahenduse katsetamiseks ei ole taotluse

esitamise hetkel esitatud ega menetluses ühtegi muud toetustaotlust teistest rahastamisallikatest ning

projektil puudub ka varasem rahastusotsus samade tegevuste elluviimiseks.

Kinnitused

☒ Oleme teadlikud, et Riigikantselei võib saata ideekavandi eksperthinnangu saamiseks valdkonna

ekspertidele.

☒ Kinnitan, et esitatud innovatsiooniprojekt on teiste partnerite juhtkondadega kirjalikult

kooskõlastatud.

Allkirjastamine

• Ideekavand tuleb allkirjastada projekti esitava(te) asutus(t)e allkirjaõigusliku juhtkonnaliikme

poolt (nt kantsler, asekantsler, KOVi juht, KOVi volikogu esimees, ministeeriumi allasutuse

juht/asejuht vms) ja saata [email protected].

LISA 1 – Tehniline lahendussuund Tehniline lahendussuund

Eelistatud lahendussuund tehisaru rakenduste sidumiseks on keskne teenuste kataloog koos ühtse

teenuse andmemudeliga. Allpool on see lahendussuund tehnilisel tasandil kokkuvõtvalt lahti seletatud.

Mis Teenuste kataloog on ja mis ta ei ole

Teenuste kataloog on erinevate infosüsteemidega suhtlev vahekiht, millest päritakse infot, mitte uus

menetlussüsteem ega andmeladu. Kataloog ei kogu ega koonda menetlustasandi üksikjuhtumite

andmeid ning ei asenda olemasolevaid infosüsteeme (ATAK, Taotlen, PlanPro jms) – ta loeb nendest

ja ei sõltu nende sisemisest loogikast. Kataloog sisaldab teenuse profiili tasandi infot: kirjeldus,

hierarhia, seosed, agregeeritud mõõdikud, protsessikirjeldused – andmeid, mis toetavad teenuse

juhtimist, mitte andmeid, millega tehakse üksikjuhtumi tasandil haldusotsuseid. See piiritlus on oluline,

kuna eristab Teenuste kataloogi andmelaost ja hoiab andmekaitse riski katseprojektile sobival

tasemel.

Tehniline ülesehitus – kolm kihti

Kiht 1 – andmeallikate integratsioon. Esimese aasta skoobis luuakse üks tehniline liidestus –

Tallinna ATAK-iga, kasutades JSON-põhist REST liidest, mis ekspordib Teenuste kataloogile teenuste

põhiandmed (teenuse ID, nimetus, kirjeldus, osutamiskanal, vastutav asutus). Liidestuse loomine

eeldab koostööd süsteemi ainuarendaja AS Spin TEK-iga ning praeguse IP-põhise

juurdepääsupiirangu laiendamist Teenuste kataloogile. Teise aasta skoobis on plaanis kaaluda

täiendavaid liidestusi (nt Taotlen, PlanPro), kus need annaksid Teenuste kataloogile agregeeritud

tagasiside- ja mõõdikuandmeid samalaadse liidestusloogika alusel. Täpne valik, milliseid liidestusi ja

millises ulatuses teisel aastal luuakse, sõltub esimese aasta tulemustest ja allikate tehnilisest

valmidusest.

Kiht 2 – Teenuste kataloog. Eraldiseisev andmekiht (PostgreSQL andmebaas koos REST API-ga),

kuhu liidestustest tulev baasinfo jõuab ja kus teenusjuhid saavad seda rikastada lihtsa

veebirakenduse kaudu, agregeeritud, mitte juhtumitasandil – neljatasandiline hierarhia (toiming →

osateenus → tervikteenus → valdkond), teenustevahelised seosed, andmeomanikud ja vastutajad,

kerge protsessikirjeldus, agregeeritud kvaliteedinäitajad. Esimesel aastal on andmete sisestamine

teenusjuhtide poolt käsitsi tehtav – see on üks projekti keskseid katsetatavaid hüpoteese: kas

teenusjuhid on võimelised ja motiveeritud andmeid ise sisestama ning kas tulemuseks saadav

andmekvaliteet on tehisaru rakendamiseks piisav.

Kiht 3 – tehisaru rakendused Teenuste kataloogi andmete põhjal. Teenuste kataloog toimib

struktureeritud teadmusbaasina, millele saab ehitada ja liidestada tehisaru rakendusi. Tehniliselt

eeldab see kataloogi andmete eksportimist vektoribaasi (nt pgvector laiendus PostgreSQL peal) ning

olemasoleva suurmudeli rakendamist koos kataloogi andmetega kontekstina (RAG-loogika), või

vajadusel kitsamalt piiritletud lahenduse ehitamist andmemudeli peale. Projektis ei ehitata neid

rakendusi kataloogi sisemise osana, vaid katsetatakse, kas andmemudel võimaldab nende loomist.

Täpne tehniline tee – kas konkreetse kasutusjuhtumi jaoks rakendatakse olemasolevat suurmudelit

kataloogi andmete peal või ehitatakse valdkonnaspetsiifilisem lahendus – selgub projekti käigus.

Katseprojekti raames katsetatakse kasutusjuhtumeid kõigil neljal juhtimistasandil: toimingu (nt taotluse

hindamise ettevalmistus), osateenuse (nt kodaniku küsimustele vastamine), tervikteenuse (nt

kasutajateekonna kaardistus üle asutuste piiride) ja valdkonna (nt stsenaariumianalüüs strateegiliste

otsuste toetamiseks) tasandil. Kõigi kasutusjuhtumite puhul on tehisaru roll juhtimist toetava

tööriistana – lõplikud otsused jäävad inimese pädevusse.

Adapterimustri liidestumise spetsifikatsioon

Projekti oluline lisaväljund on adapterimustri spetsifikatsioon, mis dokumenteerib, milline on

minimaalne andmemudel, mida Teenuste kataloog teenuselt ootab, ning kuidas uus andmeallikas end

kataloogiga liidestab – olenemata sellest, kas allikaks on ATAK, mõne teise KOV-i register, CSV-

eksport või käsitsi täidetud vorm. ATAK-i liidestus on selle spetsifikatsiooni esimene rakendus, mitte

eesmärk omaette. Teised KOV-id saavad sama spetsifikatsiooni järgides luua oma adapteri ilma

Teenuste kataloogis muudatusi tegemata, mis haakub otseselt ELVL-i koordineeritava KOV-ide

digitaalse platvormi algatusega.

Tehnilise liidestuse lahendussuunad

Andmeallikate liidestamiseks Teenuste kataloogiga on suuremas plaanis kaks võimalikku tehnilist

lähenemist, mille vahel valitakse igal liidestusel eraldi, lähtudes konkreetse allika tehnilisest

valmidusest ja olemasolevast liidesest:

A) Otseliidestus olemasoleva API peale. Kui andmeallikal on juba olemasolev struktureeritud liides

(nt JSON-põhine REST API), luuakse otsene sünkroonimisühendus, mis perioodiliselt (nt kord

ööpäevas) või sündmuspõhiselt toob ajakohased andmed Teenuste kataloogi vastava API

otspunkti (endpoint) kaudu. See on eelistatud lähenemine kõikjal, kus see on tehniliselt võimalik,

kuna ei tekita lisahaldust ega -süsteeme ja võimaldab andmete automaatset ajakohastamist.

B) Struktureeritud vahevormingu kaudu. Kui andmeallikal puudub sobiv liides või selle avamine ei

ole esimese aasta jooksul realistlik, liidestatakse allikas struktureeritud ekspordi (nt perioodiline

CSV- või XML-eksport) kaudu, mis kaardistatakse adapterimustri spetsifikatsioonile vastavaks.

Selline lähenemine on aeglasem ja vajab rohkem käsitsi koordineerimist, kuid võimaldab liidestust

ka allikatega, mille tehniline liides ei ole katseprojekti ajaks valmis.

ATAK-i liidestus on esimese lähenemise (otseliidestus) näide, kuna liides on juba olemas, kuid praegu

kasutusel ainult sisemiselt. Esimese aasta käigus selgub, kas teiste allikate puhul on otstarbekas

kasutada sama loogikat, või on mõnel allikal mõistlikum minna struktureeritud vahevorminguga.

Kumma lähenemise vahel igal konkreetsel juhul valitakse, dokumenteeritakse adapterimustri

spetsifikatsioonis, mis muudab valiku põhjenduse läbipaistvaks ning korratavaks ka teistele KOV-

idele.

Katsetuse läbiviimine

Katse esimene etapp viiakse läbi ühe katsevaldkonna ulatuses, mida täpsustatakse projekti

ettevalmistusetapis koos teenusjuhtidega.

i Katsetamine vastab küsimusele: kas see töötab? Katsetuse puhul ei vaadata alati, kas lahendus praktiliselt toimib.

Piloteerimine vastab küsimusele: kas see töötab päriselus ja on mõistlik kasutusele võtta? Hinnata praktilist

toimivust.

Eksperiment: Igasuguse eksperimendi eesmärk on kontrollida hüpoteese põhjuslike seoste kohta. Eksperiment on

selline katse, mis on kavandatud põhjuslike seletusteni jõudmiseks: kui teeme x siis juhtub y.

Prototüüp on masina, seadme või mingi rakenduse esialgne teostus, algne mudel, mida edasi arendatakse.