Tööelu Infosüsteemi arendustööd Nõuded pakkuja meeskondadele T ööde teostamiseks peab pakkujal ol ema võimekus teostada järgmisi töid: detailanalüüs (sh ärianalüüs, süsteemianalüüs); tarkvara arhitektuuri disain; esitluskihi disain; arendus; testimine. Pakkuja peab esitama kaks meeskonda, sh mõlemasse meeskonda peavad kuuluma: projektijuht (1); analüütik (1) ; arendajad (2) ; arhitekt (1) ; testija (1). Esitluskihi arendamise meeskonda peab kuulu ma ka veebidisainer/UX disainer. Mõlemas meeskonnas peab ühel meeskonnaliikmetest olema Scrum Master i kogemus se lle rakend amisel vähemalt kahes projektis . Meeskondade liikmed ei tohi kattuda, st sama isik ei tohi olla mõlemas meeskonnas. S amuti ei tohi sa ma isik olla erinevates rollides. Erandiks on p rojektijuht ja arhitekt , kes võ ib olla 2 meeskonna peale ühine, pakkuja pe ab esitama seega minimaalselt 11 meeskonnaliiget, kes hakkavad töid teostama . MEESKOND 1 Taustsüsteemide arendusmeeskond Projektijuht (nimi, isikukood) : ..... .................... ......... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1 Omab vähemalt 3 -aastast töökogemust tarkvara arenduse projektijuhina. 2 On juhtinud vähemalt ühte tarkvara arendusprojekti viimase kahe aasta jooksul, mille p rojekti maht ületab 5000 tundi. 3 * Scrum Master kogemus vähemalt kahes projektis *Kohustuslik ühel meeskonnaliikmetest . Analüütik (nimi, isikukood) : ..................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1a * Omab kõrgharidust ja O mab vähemalt 3-aastast töökogemust tarkvara arenduse projektides analüütikuna või tarkvara projekteerijana . 1b * Omab vähemalt 5-aastast töökogemust tarkvara arenduse projektides analüütikuna või tarkvara projekteerijana . 2 O n osalenud vähemalt ühes IT projektis viimase kahe aasta jooksul, mille arendusmaht on rohk em kui 5000 tundi . 3 Omab töökogemust: 3.1 M enetlussüsteemide a rendamisel ja/või analüüsimisel 3.2 äriprotsesside optimeerimisel 3.3 T sentraalsete süsteemidega 3.4 UML-iga ( Unified Modeling Language ) 3.5 P rototüüpide koostamisel 3 .6 K onteinerlahenduse loomisel 4 * * Scrum Master k ogemus vähemalt kahes projektis * Täita tuleb kas väli 1a või 1b. ** Kohustuslik ühel meeskonnaliikmetest . Arendaja 1 (nimi, isikukood): ..................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1a * Omab kõrgharidust infotehnoloogia, majanduse või m atemaatika – füüsika valdkonnas ja O mab vähemalt 3-aastast töökogemust IT arendajana. 1b * Omab vähemalt 5-aastast töökogemust IT arendajana . 2 On osalenud vähemalt ühes IT projektis viimase kahe aasta jooksul, mille arendusmaht on rohkem kui 5000 tundi ning projektis on kasutatud Spring ja Hibernate raamistikke ning REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab vähemalt 2 - a astast töökogemust relatsiooniliste andmebaaside ja Java’ga . 4 Omab töökogemust järgmiste töövahendite , raamistike ja keskkondadega: 4 .1 GIT 4 .2 Jenkins 4 .3 Intellij IDEA/ Eclipse 4 . 4 Spring raamistik 4 . 5 Hibernate raamistik 4 . 6 REST ja SOAP veebiteenused 4. 7 Konteinerlahenduse loomisel 4. 8 PostgreSQL 4.9 ** Scrum Master kogemus vähemalt kahes projektis * Täita tuleb kas väli 1a või 1b. ** Kohustuslik ühel meeskonnaliikmetest . Arendaja 2 (nimi, isikukood): ..................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a * Omab kõrgharidust infotehnoloogia, majanduse või m atemaatika – füüsika valdkonnas ja O mab vähemalt 3-aastast töökogemust IT arendajana. 1b * Omab vähemalt 5-aastast töökogemust IT arendajana 2 On osalenud vähemalt ühes IT projektis viimase kahe aasta jooksul, mille arendusmaht on rohkem kui 5000 tundi ning projekts kasutatud Spring ja Hibernate raamistikke ning REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab vähemalt 2-aastast töökogemust relatsiooniliste andmebaaside ja Java’ga . 4 Omab töökogemust järgmiste töövahendite, raamistike ja keskkondadega: 4.1 GIT 4.2 Jenkins 4.3 Intellij IDEA/ Eclipse 4. 4 Spring raamistik 4. 5 Hibernate raamistik 4. 6 REST ja SOAP veebiteenused 4. 7 Konteinerlahenduse loomisel 4. 8 PostgreSQL 4.9 ** Scrum Master kogemus vähemalt kahes projektis *Täita tuleb kas väli 1a või 1b. ** Kohustuslik ühel meeskonnaliikmetest . Arhitekt (nimi, isikukood): .................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a * Omab kõrgharidust infotehnoloogia valdkonnas ja o mab vähemalt 5-aastast töökogemust süsteemi - või tarkvara arhitektina. 1b * Omab vähemalt 10 -aastast töökogemust süste emi - või tarkvara ar hi t ektina. 2 On osalenud vähemalt ühes IT projektis viimase 2 aasta jooksul, mille arendusmaht on rohkem kui 5000 tundi . 3 Omab vähemalt 5 -aastast töökogemust relatsiooniliste andmebaaside ja Java’ga . 4 Omab töökogemust menetlus- ja finantssüsteemide projekteerimisel ja arendamisel. 5 Omab töökogemust järgmiste töövahendite , raamistike ja keskkondadega : 5 .1 Liquibase 5 .2 Enterprise Architect 5 .3 Jenkins 5 .4 Linux/Unix operatsioonisüsteemidega 5 .5 V irtualiseerimistehnoloogiate ning „ continuous integration “ töövõtete ning seadistamisega 5 .6 SOA ja Mikroteenustel põhinevate arhitektuurilahenduste projekteerimisel ning realiseerimisel 5 .7 Konteinerlahenduse loomisel 5 . 8 Spring raamistikuga 5 . 9 Hibernate raamistikuga 5 . 10 SOAP 5 .1 1 Angular raamistikuga 5 .1 2 Apache HTTPD ja Apache Tomcat tehnoloogiatega 5 .13 PostgreSQL 5.14 ** Scrum Master kogemus vähemalt kahes projektis *Täi ta tuleb kas väli 1a või 1b . ** Kohustuslik ühel meeskonnaliikmetest . Testija (nimi, isikukood): .................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1 Omab vähemalt 3 -aastast töökogemust testijana või programmeerijana . 2 On osalenud vähemalt kahes (2) tarkvara arenduse projektis, kus on teostanud testide automatiseerimist . 3* Scrum Master kogemus vähemalt kahes projektis * Kohustuslik ühel meeskonnaliikmetest MEESKOND 2 Esitluskihi arenduse meeskond Projektijuht (nimi, isikukood): .................................. Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1 Omab vähemalt 3-aastast töökogemust tarkvara arenduse projektijuhina. 2 On juhtinud vähemalt ühte tarkvara arendusprojekti viimase 2 aasta jooksul, mille projekti maht ületab 5000 tundi . 3* Scrum Master kogemus vähemalt kahes projektis * Kohustuslik ühel meeskonnaliikmetest Analüütik (nimi, isikukood): ..................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1a* Omab kõrghar idust ja omab vähemalt 3-aastast töökogemust tarkvara arenduse projektides analüütikuna või tarkvara projekteerijana . 1b* Omab vähemalt 5-aastast töökogemust tarkvara arenduse projektides analüütikuna või tarkvara projekteerijana . 2 On osalenud vähemalt ühes IT projektis viimase 2 aasta jooksul, mille arendusmaht on rohkem kui 5000 tundi . 3 Omab töökogemust: 3.1 menetlussüsteemide arendamisel ja/või analüüsimisel 3.2 äriprotsesside optimeerimisel 3.3 tsentraalsete süsteemidega 3.4 UML-iga ( Unified Modeling Language ) 3.5 prototüüpide koostamisel 4** Scrum Master kogemus vähemalt kahes projektis * Täita tuleb kas väli 1a või 1b . ** Kohustuslik ühel meeskonnaliikmetest Arendaja 1 (nimi, isikukood): ..................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1a* Omab kõrgharidust infotehnoloogia, majanduse või matemaatika – füüsika valdkonnas ja omab vähemalt 3-aastast töökogemust IT arendajana. 1b* Omab vähemalt 5-aastast töökogemust IT arendajana. 2 On osalenud vähemalt ühes IT projektis viimase kahe aasta jooksul, mille arendusmaht on rohkem kui 5000 tundi ning projektis on kasutatud Angular raamistikke ning REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab vähemalt 2-aastast töökogemust esitluskihi arendamisel . 4 Omab töökogemust järgmiste töövahendite, raamistike ja keskkondadega: 4.1 GIT 4.2 Jenkins 4.3 Intellij IDEA/ Eclipse 4.4 Angular 4. 5 REST ja SOAP veebiteenused 4. 6 HTML5 ja CSS (SASS) 4.7 ** Scrum Master kogemus vähemalt kahes projektis *Täita tuleb kas väli 1a või 1b. ** Kohustuslik ühel meeskonnaliikmetest . Arendaja 2 (nimi, isikukood): ..................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1a* Omab kõrgharidust infotehnoloog ia, majanduse või matemaatika– füüsika valdkonnas ja omab vähemalt 3-aastast töökogemust IT arendajana. 1b* Omab vähemalt 5-aastast töökogemust IT arendajana 2 On osalenud vähemalt ühes IT projektis viimase kahe aasta jooksul, mille arendusmaht on rohkem kui 5000 tundi ning projektis on kasutatud Angula r raamistikke ning REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab vähemalt 2-aastast töökogemust esitluskihi loomisel . 4 Omab töökogemust järgmiste töövahendite, raamistike ja keskkondadega: 4.1 GIT 4.2 Jenkins 4.3 Intellij IDEA/ Eclipse 4.4 Angular 4.5 REST ja SOAP veebiteenused 4.6 ** Scrum Master kogemus vähemalt kahes projektis *Täita tuleb kas väli 1a või 1b. ** Kohustuslik ühel meeskonnaliikmetest . Arhitekt (nimi, isikukood): .................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1a* Omab kõrgharidust infotehnoloogia valdkonnas ja omab vähemalt 5-aastast töökogemust süsteemi- või tarkvara arhitektina. 1b* Omab vähemalt 10-aastast töökogemust süsteemi- või tarkvara arhitektina. 2 On osalenud vähemalt ühes IT projektis viimase 2 aasta jooksul, mille arendusmaht on rohkem kui 5000 tundi . 3 Omab vähemalt 5-aastast töökogemust relatsiooniliste andmebaaside ja Java’ga . 4 Omab töökogemust järgmiste töövahendite, raamistike ja keskkondadega: 4 .1 Liquibase 4 .2 Enterprise Architect 4 .3 Jenkins 4 .4 Linux/Unix operatsioonisüsteemidega 4 .5 V irtualiseerimistehnoloogiate ning „ continuous integration “ töövõtete ning seadistamisega 4 .6 SOA ja Mikroteenustel põhinevate arhitektuurilahenduste projekteerimisel ning realiseerimisel 4 . 7 Spring raamistikuga 4 . 8 Hibernate raamistikuga 4 . 9 SOAP 4 .1 0 Angular raamistikuga 4 .1 1 Apache HTTPD ja Apache Tomcat tehnoloogiatega 4.12 PostgreSQL 4.13 ** Scrum Master kogemus vähemalt kahes projektis * Täita tuleb kas väli 1a või 1b . ** Kohustuslik ühel meeskonnaliikmetest . Veebidisainer/UX disainer (nimi, isikukood): ..................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1a* Omab vähemalt rakenduskõrgharidust graafilise disaini, interaktsioonidisaini või veebitehnoloogiate erialal ja omab vähemalt 3-aastast töökogemust veebidisainerina. 1b* Omab vähemalt 5-aastast töökogemust veebidisainerina. 2 On osalenud veebidisainerina vähemalt 6 veebilehe kasutajaliidese (e-kommerts, iseteenindus või samaväärne) disaini projektis viimase 3 aasta jooksul. Tõenduseks esitab enda poolt loodud veebidisaini visuaalse faili . Tööde esitamiseks võib kasutada enim levinuid failiformaate. 3 Omab töökogemust: 3.1 veebilehtede graafilise disaini loomisel 3.2 persoonade loomisel 3.3 töövoogude kirjeldamisel 3.4 Wireframe ja prototüüpide loomisel (HTML5; CSS(SASS); Javascript ) 3.5 kasutatavuse (UX) analüüside teostamisel 4 On osalenud vähemalt kahes projektis viimase 2a jooksul, kus järgiti vähemalt WCAG 2.0 AA-taset ja W3C standardit. 5** Scrum Master kogemus vähemalt kahes projektis *Täita tuleb kas väli 1a või 1b ning 5a või 5b ** Kohustuslik ühel meeskonnaliikmetest Testija (nimi, isikukood): .................................................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1 Omab vähemalt 3-aastast töökogemust testijana või programmeerijana. 2 On osalenud vähemalt kahes tarkvara arenduse projektis, kus on teostanud testide automatiseerimist. 3* Scrum Master kogemus vähemalt kahes projektis* * Kohustuslik ühel meeskonnaliikmetest
Tööelu infosüsteemi arendustööd Lisa 2. Kodukord EESMÄRK Kodukorra ee smärgiks on täpsustada hanke lepingu te alusel ( edaspidi nimetatud ka projekt) tööde tellimise kord ja põhimõtted, Täitja ja Tellija omavaheli ne suhtlus ning tagasiside andmise kord. Tellija võib teha kodukorda muudatusi, teavitades Täitjat kodukorra muutmisest. M ÕISTED Töö – Lepingus (hankeleping või tellimuskiri) fikseeritud töö(d)/tegevus( ed ) ja üle antav( ad ) tulem(id), mida saab testida või mille valmimist saab kinnitada Tellija. Üleandmise ja vastuvõtmise akt (Akt) - Töö üleandmist ja vastuvõtmist kinnitav dokument, mis allkirjastatakse nii Täitja kui Tellija poolt ja mis on Täitjale aluseks arve esitamiseks ning Tellijale arve tasumiseks. Teenuse kasutaja – Tööinspektsioon (TI) , kes hakkab Töös tellitud teenuseid kasutama , sh testib üle antud töid sisuliselt . TÄITJA JA TELLIJA ÜLESANDED Täitja põhiülesanded: teostada kokkulepitud tööd kokkulepitud ulatuses , mahus ja ajakavas; koostada ja täiendada tööde teostamise eelselt ja käigus kokkulepitud dokumentatsioon i ; anda selgitusi ja konsultatsioone teostatud tööde kohta ; k oolitada Tellijat tööde valmimise järgselt ; esitama Tellija le tööde teostamise detailsed ajaaruanded n ing täit m a muid Lepingust tulenevaid kohustusi. P ooled täpsustavad Täitja ülesandeid L epingu sõlmimisel . Tellija põhiülesanded on: tagada Täitjale tööde teostamiseks vajalik informatsioon, dokumentatsioon ja juurdepääsud; üle vaad ata, testida ja kooskõlastada Täitja esitatavad tulemid, parandus- ja täiendusettepanekud kokkulepitud tähtaegade jooksul; tagada Tellija hallatavate infotehnoloogiliste keskkondade korrektne toimimine Tööde teostamise vältel, mis on olulised T äitja poolsete kohustuste täitmiseks ; m aksta tasu nõuetekohaselt teostatud tööde eest. Vajadusel täpsustavad Pooled Tellija ülesandeid L epingu sõlmimisel . ÜLDINE TÖÖKORRALDUS Arenduste läbiviimise metoodika kehtestab Tellija konkreetse Lepingu sõlmimise tingimusena. Arenduste läbiviimine toimub kas: funktsionaalsuse põhiselt, kus sisendiks on konkreetse tulemi (skoobi) tellimus, sh tähtaeg ja/või piirsumma või arendusmeeskonna töötundide põhiselt, kus arendused realiseeritakse agiilse arendusprotsessi põhimõtetel. Agiilse arenduse all peame silmas, et me hindame inimesi, oleme ise motiveeritud ja motiveerime teisi, tihedat koostööd, kohtumisi, koostöötamist, suutlikkust muutuvas olukorras langetada teenuse kasutajat silmas pidades parim otsus, soovi otsida pidevalt parimaid lahendusi. Lisaks eeldame, et iga töö tellimise puhul Täitja esitab Tellijale töö teostamiseks vajamineva hinnangulise tundide arvu ja Pooled püüavad leida konsensus e iga otsuse langetamisel – näiteks sprintide tööde prioritiseerimine . Tellija esitab tööde tellimusi vastavalt reaalsele vajadusele ning Täitja peab olema valmis võimalike ajaliste pauside tekkimiseks tööde tellimuste esitamise vahepealsel ajal. Täitja peab arvestama, et Tellija võib vajada tellimuste esitamisel tööde teostamiseks erinevaid meeskonnaliikmeid erinevas koosseisus (st iga tellimuse täitmisel ei ole vajalik 6-liikmelise meeskonna rakendamine). Lepingus fikseerivad Tellija ja Täitja selle alusel teostatavad Tööd. Iga Töö osas fikseeritakse selle maht ja valmimise tähtaeg , sh agiilse arendusmeetodi kasutamise korral . Arendustööde puhul fikseeritakse tarne tähtaeg (-ajad) ja planeeritav Live keskkonda panemise tähtaeg. Arendustööde v ahetarnete tsükkel on kaks nädalat , kui Lepingus ei ole kokku lepitud teisiti . Lepingu eesmärgi saavutamiseks vajalik e tegevuste täpsem kirjeldus ja tähtajad fikseerit akse Lepingus . Töökorraldus arendustööde testimisel: Täitja annab Tellijale üle omalt poolt testitud Töö. Tellija poolel testivad Tööd TEHIK kui Tellija esindaja (testib tehnilist osa) ja TI kui Teenuse kasutaja (testib sisulist osa). Tellija esindaja ja Teenuse kasutaja testivad Tööd Testkeskkonnas ja Prelive keskkonnas. Üldjuhul viiakse Töö Testkeskkonnast Prelive keskkonda pärast vigade parandamist. Pisivigadega Tööd võib viia Prelive keskkonda, kui Tellija ja Täitja vahel on kokku lepitud pisivigade kõrvaldamise aeg. Juhul kui Töö valmib etapiviisiliselt , kuid tuleb kasutusele võtta tervikuna, toimub pärast Töö etappide valmimist ja enne L ive keskkonda panemist kogu Töö Tellija poolne vastuvõtutestimine Prelive keskkonnas ( kindlustamaks Töö nõuetele vastamine ja toimimine tervikuna ) . Tellija projektijuht otsustab, kas Töö on võimalik viia järgmisesse testimise etappi (nt Testkeskkonnast Prelive keskkonda jmt). Akteerimisele kuulub Töö , mis on edukalt läbinud vastuvõtutestimise Prelive keskkonnas . Täitja poolne T ööde teostamine ei tohi tekitada häireid Tellija mistahes teiste liidestatud süsteemide või teenuste talitluse s, v.a juhul kui Täitja lähtus T öö teostamisel Tellija poolsetest juhistest ja kokkulepetest, kuid sellele vaatama ta tekkisid häired. Juhul, kui T öö teostamine toimub Tellija ruumides, peavad Tellija ruumides viibivad Täitja esindajad kinni pidama Tellija juures kehtivatest sisekorraeeskirjadest, sh turvanõuetest, mis on Tellija poolt teatavaks tehtud . Lepingu täitmisest tulenev suhtlus toimub eesti keeles. TÖÖDE TEOSTAMISE MEESKOND JA VASTUTUSED T ööde teostamiseks moodustatakse projektimeeskond. Kumbki Pool nimetab tööde teostamiseks omapoolse projektijuhi. Täitja projektijuht juhib Täitja poolt tööde tulemi kokkuleppimist, vastutab tööde teostamise ajaplaani koostamise eest ning tagab kokkulepitud tööde tulemi valmimise ja ajaplaani täitmise. Tellija projektijuht juhib Tellija poolt tööde tellimuse ja ajaplaani kokkuleppimist ning tööde teostamist. Tellija projektijuhil on õigus kontrollida Lepingu täitmise käiku ning kohustus anda T äitjale töödega seotud informatsiooni ja juhiseid vastava nõude esitamisel. Kumbki Pool peab tagama, et tema projektijuhil on vajalik ajaressurss ning kõik vajalikud õigused ja pädevus vastava Poole nimel tegutseda. Projektimeeskonna liikmed (teostajad) vastutavad, et nende poolt teostatud tööd on teostatud ja dokumenteeritud vastavalt kokkulepitud töö eesmärgile ning Tellija suunistele ja nõuetele ning valdkonnas kehtivatele parimale praktikale. Kumbki Pool peab tagama, et tema kaasatud teostajal on kõik vajalikud teadmised, oskused ja kogemused ning piisav ajaressurss vastava Poole nimel töid teostada. Juhul kui ilmnevad takistused, mille tõttu vähemalt üks Pooltest ei saa kokkulepitud töid teostada , tuleb sellest koheselt informeerida mõlema Poole projektijuhte. Sõltuvalt sellest, millise ulatusega on tööde teostamise viivitus, tuleb vajadusel korrigeerida ka seotud tööde plaani. Sõltuvalt probleemi ulatusest peavad vastavad projektorganisatsiooni liikmed analüüsima tekkinud olukorra põhjusi ja vajadusel võtma tarvitusele abinõud, et ennetada sarnase olukorra tekkimist. T äitja on kohustatud kasutama tööde teostamisel p akkumuses nimetatud meeskonnaliikmeid ning meeskonnaliikmete lisandumisel või asendamisel järgima raamlepingus sätestatud tingimusi. Tellija poolt kuuluvad tasustamisele üksnes reaalselt töö teostamiseks kulutatud efektiivsed töötunnid, mis loovad Tellijale väärtust. Tellija ei tasusta ega aktsepteeri ajaaruannetes seadusest tulenevate pauside arveldamist (nt lõunapausid, paus silmade puhkamiseks jmt). Vajadusel täpsustavad Pooled hankelepingu sõlmimisel meeskonnas teostajate rollid. Tellija juures töötab projekti juhtrühm, mis jälgib raamlepingu alusel sõlmitud L epingute täitmist tervikuna. Tellija juures töötab projekti töörühm, mis koordineerib igapäevast tegevust. Juhtrühmal on pädevus teha otsuseid mikrotasandil. LEPINGU TÄITMISEGA SEOTUD INFOVAHETUS Lepingute täitmisega seotud dokumentatsiooni haldamiseks ja jagamiseks kasutatakse Tellija dokumendihalduskeskkonda Confluence . Dokumentide hoidmise struktuur, selle täiendused ja muudatused lepitakse kokku Poolte projektijuhtide vahel. Dokumentide lisamise, muutmise ja kustutamise reeglid lepitakse kokku Poolte projektijuhtide vahel, kes tagavad kokkulepitud reeglite järgimise oma meeskonna poolel. Konfiguratsiooni- ja arendustööde ülesannete suunamiseks ja jälgimiseks, vigade ja probleemide haldamiseks ning tööaja arvestuseks kasutatakse T ellija projektik eskkonda Jira . Tellija võib lisaks Jiras registreerimisele viidata leitud vigadele ka e-kirja vm suhtluskanali vahendusel, kuid vea/tööülesandega tegelema hakkamise eelduseks T äitja poolel on vea registreerimine Jiras ning lepingus toodud nimetatud tööde eest vastutava isiku poolt antud korraldus tööde alustamiseks. Vajadusel täpsustavad Pooled tööülesannete lisamise nõuded (pealkirjad, teemad, ülesannete prioriteetide kategooriad jmt). Kui ülesande lahendamise prognoositav aeg ületab kolm tööpäeva, peab Täitja ülesande tükeldama väikesemateks alamülesanneteks . Rakenduse lähte koodi hoidmiseks kasutatakse https://gitlab.sotsiaalministeerium.ee . Lähtekoodi haldamisel ja versioneerimisel tuleb lähtuda http://nvie.com/posts/a-successful-git-branching-model/ mudelist. Lepingu täitmisega seotud muu, igapäevane teabevahetus toimub e-kirja , telefoni, Skype teel või koosoleku vormis. Poolte projektijuhid tagavad teabe edastamise ja saamise. Teabevahetuse vormid ja reageerimisajad: Koosolek – koosoleku kokkukutsumisel esitatakse päevakord ja eesmärk. Võimaluse korral lepitakse Projekti alguses kokku korralised koosolekud. Korralisi koosolekuid võib Poolte kokkuleppel tühistada (hiljemalt samal päeval 2-tunnise etteteatamise ajaga). Muude koosolekute kutsed tuleb esitada vähemalt 2 tööpäeva enne koosoleku toimumist. Iga koosoleku kohta tehakse (vastutab koosoleku korraldaja) memo, otsused protokollitakse ja saadetakse e-kirjaga koosolekul osalenutele teadmiseks/ vajadusel kinnitamiseks . E - kiri – kasutatakse igapäevase suhtluskanalina (v.a kui konkreetset infot tuleb vastavalt kodukorrale edastada T äitja projektikeskkondade kaudu). Kui e- kirjale oodatakse vastust, tuleb subjekti real või kirja alguses see üheselt määratleda. Vastust eeldavale e-kirjale tuleb vastata hiljemalt järgneva t ööpäeva jooksul . Kui e-kirjale ei ole võimalik anda selle aja jooksul sisulist vastust, tuleb hiljemalt järgneva tööpäeva jooksul saata sisulise va stuse andmise aeg. Telefon, Skype – kasutatakse kiireloomuliseks ja operatiivseks suhtluseks. S kype’i kõneteenuse või telefoni kaudu kokkulepitud olulised otsused tuleb kinnituseks fikseerida e-kirjaga või arutada ja protokollida koosolekul. Pooled säilitavad projekti e-kirjad ja Skype vestluse d projekti ja garantiiperioodi kehtivuse ajal. Poolte projektijuhid lepivad kokku e-posti ja Skype gruppide loomise. Stand-up – Toimub Täitja ja Tellija esindajate osalusel iga tööpäev. Stand - up-e ei toimu juhul, kui Täitjal ei ole Tellija poolt esitatud tellimusi töös. Stand-upi osalejad ja täpsem formaat lepitakse kokku enne esimese töö tellimist. NÕUDED DOKUMENTEERIMISELE Projekti dokumentat sioon peab olema terviklik ja terminoloogiliselt üheselt mõistetav. Dokumentatsiooni kvaliteedi eest vastutavad Poolte projektijuhid. Tellija projektijuhil on õigus nõuda Täita poolt koostatud või parandatud dokumentatsiooni täiendamist või muul viisil muutmist, kui dokumentatsioon ei vasta nõuetele või on muul viisil puudulik. Nõuded dokumenteerimisele on esitatud dokumendis „Mittefunktsionaalsed nõuded“: https://wiki.sm.ee/pages/viewpage.action?pageId=3834694 alapunktis 8 ja selle alamdokumendis „Nõuded infosüsteemi dokumentatsioonile“: https://wiki.sm.ee/pages/viewpage.action?pageId=3834696 . ARENDUS-, TEST-, PRELIVE - ja LIVE KESKKONNAD A renduskeskkond asub Tellija juures, kes tagab selle olemasolu ja toimimise. Tellija testkeskkond koosneb vähendatud võimsusega komponentidest. T äitja l on T ellija testkeskkonnale lugemisõigusega ligipääs. Tellija P relive keskkond koosneb Live keskkonnale sarnastest komponentidest, sh a ndmebaasid, rakendusserverid ning väliste süsteemide liidesed. T äitjal puudub alaline ligipääs T ellija P relive keskkonnale. Live keskkonna konfiguratsioon lepitakse kokku arenduse käigus. T äitja l puudub ligipääs Tellija Live keskkonnale. Pooled teevad mõistlikud pingutused tagamaks, et T ellija t estkeskkond sarnaneks Live keskkonnale järgmises osas: (a) arvutivõrgu konfiguratsioon; (b) liidesed kolmandate süsteemidega; (c) andmemahud; (d ) k ui maksimaalne sarnasus ei ole majanduslikult põhjendatud või tulenevalt andmekaitse piirangutest võimalik , kohustub Pool informeerima teist Poolt T est- ja Liv e keskkondade disainitud erinevustest. Vajadusel lepivad Pooled kokku alternatiivse võimaluse keskkondade erinevuse puudujäägi kompenseerimiseks. K eskkondade ning nende ligipääsude haldamise ja tarnete paigalduse reegli d lepitakse kokku projekti alguses. VEA PARANDAMINE ARENDUSE, JUURUTAMISE VÕI GARANTIIPERIOODI KÄIGUS Vigade menetlemise käigus registreeritakse kõik Poolte leitud vead Jira projektikeskkonnas. Täitja analüüsib vea kirjeldust ning selgitab välja vea põhjuse. Vigadele määratakse kriitilisuse aste ning neid asutakse parandama kriitilisuse järjekorras. Garantiiperioodil asub Täitja viga parandama vastavalt raamlepingus sätestatud tingimustele. KRIISISITUATSIOONIDE HALDAMINE Kriisisituatsiooniks loetakse olukorda, kus Poolte esindajad ei suuda kokkuleppele jõuda või on muutunud võimatuks võtmeisikute osalemine tööde teostamisel või ilmnenud on muud asjaolud, mis võivad oluliselt mõjutada tööde edukat elluviimist ja/või satuvad olulisse ohtu kokkulepitud tähtajad ja/või funktsionaalsus. Kriisi tekkimisel on Pool kohustatud sellest teise Poole esindajat viivitamatult kirjalikult teavitama. Kriisist väljumiseks teevad mõlemad Pooled kõik endast sõltuva kriisist väljatulekuks ja mõlemat Poolt rahuldava lahenduse leidmiseks. Kriisi vältimise ja kriisist väljumise eest vastutavad Poolte projektijuhid. Kriisi tekkel informeerib Tellija projektijuht koheselt Projekti juhtrühma, kes rakendab meetmed kriisi lahendamiseks . Kui kriisi ei suudeta P rojekti juhtrühma poolt likvideerida, kasutatakse T äitja ja Tellija vahelises lepingus sätestatud meetmeid.
www.pwc.ee Lõpparuanne
Tööelu
infosüsteemi
eelanalüüs
Lõpparuanne
Tervise ja Heaolu
Infosüsteemide
Keskus
15. mai 2018
Projekt „ Tööelu infosüsteemi eelanalüüs“ täitmist rahastatakse Euroopa Sotsiaalfondi
meetme töövõime toetamise skeemi loomine ja juurutamine alusel (projekti nr 2014-
2020.3.01.002003.01.15-0002) raames.
Lõpparuanne
Rainer Rohtla
Tervise ja Heaolu Infosüsteemide Keskus
Uus-Tatari 25/Veerenni 13
10134, Tallinn
15. mai 2018
Austatud Rainer Rohtla
Oleme läbi viinud projekti „Tööelu infosüsteemi eelanalüüs“. Töö teostamisel lähtusime Tervise ja
Heaolu Infosüsteemide Keskuse ja AS PricewaterhouseCoopers Advisors (PwC) vahel 23.01.2018
sõlmitud lepingust.
Käesoleva dokumendi näol on tegemist lõpparuandega. Juhul kui järeldused lõppversioonis erinevad
meie varasemate diskussioonide käigus väljaöeldust või vahearuandes kirjeldatust, tuleb eelistada
neid, mis esitatakse lõpparuandes.
Meie analüüs põhineb Kliendilt saadud andmetel ja informatsioonil ning avalikult kättesaadavatel
andmetel (sh uurimustööd, statistika). Meie ülesannete hulka ei kuulunud lähteandmete õigsuse
kontrollimine, mistõttu AS PricewaterhouseCoopers Advisors (PwC) ei vastuta algandmete õigsuse
eest ega ka tulemuste eest juhul, kui need põhinevad puudulikel või ebaõigetel algandmetel. Meie töö
oli piiratud lepingus sätestatud tegevustega.
Lisaks juhime Teie tähelepanu, et AS PricewaterhouseCoopers Advisors ei võta vastutust kolmandate
osapoolte ees, kellele käesolev dokument on avaldatud või mõnel muul moel kättesaadavaks saanud.
Lugupidamisega
/allkirjastatud digitaalselt/
Teet Tender
AS PricewaterhouseCoopers Advisors
AS PricewaterhouseCoopers Advisors, Pärnu mnt 15, 10141 Tallinn, Registrikood: 10325507
T: 614 1800, F: 614 1900,
[email protected], www.pwc.ee
Lõpparuanne
Oluline teadaanne isikutele, kes ei ole aruande adressaadid
Isikud, kes ei ole käesoleva aruande adressaadid ja seda aruannet loevad, loetakse ta nõustunuks
alljärgnevate tingimustega:
1. Aruannet lugev isik võtab teadmiseks, et AS PricewaterhouseCoopers Advisors on selle
koostanud vastavalt oma kliendilt saadud juhistele ning üksnes kliendi huvisid ja kasu silmas
pidades.
2. Aruannet lugev isik tunnistab asjaolu, et ta pole selle aruande adressaat ning vastamaks tema
huvidele ja vajadustele oleks võinud aruande koostamiseks osutuda vajalikuks läbi viia
teistsuguseid või täiendavaid töid.
3. Lugejal pole vastuväited asjaolule, et AS PricewaterhouseCoopers Advisors, selle juhtorganid,
töötajad ega esindajad ei vastuta mingil kujul kahju ega saamata jäänud tulu eest, mis
õigusvastaselt aruandega tutvunud isikule sellega seoses kaasneda võivad.
PwC 3
Tööelu infosüsteemi eelanalüüs Lõpparuanne
1 Sisukord
Analüüsi autorid ........................................................................................................................... 6
Analüüsi juhtrühm ....................................................................................................................... 6
Mõisted ja lühendid ...................................................................................................................... 6
1 Kokkuvõte ................................................................................................................................ 7
2 Sissejuhatus ............................................................................................................................. 8
2.1 Valdkonna kirjeldus ................................................................................................................................................. 8
2.1.1 Tööelu infosüsteemi loomist toetavad riiklikud strateegiad ................................................................. 8
2.1.2 Analüüsi probleemistik ........................................................................................................................... 11
2.2 Analüüsi eesmärk ................................................................................................................................................... 18
2.3 Kasutatav metoodika ............................................................................................................................................. 18
3 Tulevaste äriprotsesside kirjeldused TO-BE ........................................................................... 20
3.1 Üldprotsess .............................................................................................................................................................20
3.2 Töökeskkonnaga seotud osapoolte õiguste määramine....................................................................................... 22
3.3 Riskianalüüsi korraldamine .................................................................................................................................. 24
3.4 Järelevalve protsessid ............................................................................................................................................ 27
3.4.1 Automaatkontrolli läbiviimine .............................................................................................................. 29
3.4.2 Kontaktivaba järelevalve läbiviimine .................................................................................................... 31
3.4.3 Kontaktjärelevalve läbiviimine.............................................................................................................. 33
3.5 Tööst põhjustatud haigestumise menetlemine..................................................................................................... 35
3.6 Kutsehaigestumise menetlemine .......................................................................................................................... 37
3.7 Tööõnnetuse menetlemine .................................................................................................................................... 39
4 Infosüsteemi lähteülesanne ................................................................................................... 42
4.1 Lühiülevaade infosüsteemi hetkeolukorrast ........................................................................................................ 42
4.2 Infosüsteemi loogiline mudel/vaade..................................................................................................................... 43
4.3 Funktsionaalsed nõuded ........................................................................................................................................ 44
4.3.1 Rollide mudel ......................................................................................................................................... 44
4.3.2 Kasutuslood ............................................................................................................................................ 45
4.4Mittefunktsionaalsed nõuded ................................................................................................................................ 76
4.4.1 Integratsioon (Integration) ................................................................................................................... 76
4.4.2 Turvalisus (Security) .............................................................................................................................. 76
4.4.3 Kasutatavus (Usability) ......................................................................................................................... 77
4.4.4 Töökindlus (Reliability) ......................................................................................................................... 78
4.4.5 Jõudlus (Performance) .......................................................................................................................... 78
PwC 4
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.4.6 Toetatavus (Supportability)................................................................................................................... 78
5 Infosüsteemi realiseerimine ..................................................................................................80
5.1 IT-arenduse maksumus ........................................................................................................................................ 80
5.2 IT Arendusprojekt .................................................................................................................................................. 81
6 Lisad ....................................................................................................................................... 83
6.1 Intervjueeritavad .................................................................................................................................................... 83
PwC 5
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Analüüsi autorid
Meeskonna liige Roll
Mihkel Lauk Projektijuht
Kaarel Koosapoeg Vanemanalüütik
Jako Ülenõmm Analüütik
Janar Linros Analüütik
Analüüsi juhtrühm
Juhtrühma liige Asutus/organisatsioon/ettevõte
Maret Maripuu Tööinspektsioon
Apo Oja Tööinspektsioon
Meeli Miidla-Vanatalu Tööinspektsioon
Rauno Piirsalu Sotsiaalministeerium
Seili Suder Sotsiaalministeerium
Thea Treier Sotsiaalministeerium
Rainer Rohtla Tervise ja Heaolu Infosüsteemide Keskus
Kaido Kütt Tervise ja Heaolu Infosüsteemide Keskus
Meelis Kerbo Tervise ja Heaolu Infosüsteemide Keskus
Mõisted ja lühendid
Nr Mõiste, lühend Selgitus
1 TI Tööinspektsioon
2 POLIS Politsei infosüsteem
3 eTI Tööinspektsiooni kliendiportaal
4 ITI Tööinspektsiooni infosüsteem järelevalvemenetluse läbiviimiseks
5 TPH Tööst põhjustatud haigestumine
6 TK Töökeskkond
PwC 6
Tööelu infosüsteemi eelanalüüs Lõpparuanne
1 Kokkuvõte
Käesoleva projekti eesmärgiks oli analüüsida ja leida parim lahendus uue tööelu infosüsteemi loomiseks ja
tuvastada optimaalne lahendus selle tehnoloogiliseks realiseerimiseks. Analüüsiprojekt on sisendiks
infosüsteemi arendamisele.
Analüüsis vaadeldakse tööandjapoolset riskianalüüsi koostamise ja TI järelevalvega seotud protsesse.
Lisaprotsessidena on vaatluse all tööõnnetuste uurimine, kutsehaigestumiste uurimine, tööst põhjustatud
haigestumiste registreerimine ja töökeskkonnaga seotud isikute määratlemine. Analüüsi tellijapoolne otsus oli
hetkeolukorda (AS-IS) mitte kirjeldada ja seetõttu keskendutakse ainult tulevikuvaatele (TO-BE).
Analüüsi probleemistik jaguneb mitmeks omavahel tihedalt seotud teemaks, mis mõjutavad nii tööandjaid kui
ka TI-d. Valdava osa probleemide lahendamisele aitab kaasa uus infotehnoloogiline lahendus ehk uue tööelu
infosüsteemi loomine. Lisaks on vaja infosüsteemi väliseid muutuseid. Näiteks muutuseid ettevõtete
ohutuskultuuris, sellele metoodilises lähenemises kui ka ohutuskultuuri puudutavates tööprotsessides.
Analüüsi peamine problemaatika:
1. TI jõuab käesoleval hetkel kontrollida ainult väikest osa ca paar protsenti Eesti ettevõtetest.
2. Puudub efektiivne võimalus rakendada ettevõtte suhtes kontaktivaba järelevalvet. TI võib ka hetkel
kontaktivaba järelevalvet läbi viia, kuid kuna dokumendid ja info ei ole elektrooniliselt kättesaadav ei saa
seda edukalt rakendada, sest see ei vähenda vajaliku töö hulka.
3. TI teostatav järelevalve protsess ei ole tehniliste lahenduste poolt piisavalt toetatud. See on inspektorile
koormav ja vajab muutmist. Hetkel kasutusel olev infotehnoloogiline lahendus lähtub paberdokumentide
loomise loogikast.
4. Andmete taaskasutus on madal. Hetkel sisestatakse süsteemidesse valdav osa infot topelt.
5. Võimalused kogutud andmeid analüüsida ja selle põhjal olulisi järeldusi teha on piiratud.
6. Ettevõtjatel on madal teadlikkus neile seadusega pandud kohustustest.
7. Riskianalüüsi tegemine on tänasel päeval keskmisele ettevõttele keeruline ja riskianalüüside kvaliteet
väga erinev.
8. Tööelu valdkonda puudutavad infosüsteemid ja e-teenused on aegunud, killustatud ja ei suhtle omavahel.
Käesoleva projekti raames koostati tööelu infosüsteemi arenduse lähteülesanne (vt Infosüsteemi
realiseerimine). Lähteülesande koostamise käigus saadeti kolmele tarkvaraarendusega tegelevale eraettevõttele
päring uue tööelu infosüsteemi loomise mahu teadasaamiseks.
Arendaja I hinnangul maksab uue tööelu infosüsteemi loomine 232 700 eurot +km.
Arendaja II hinnangul maksab uue tööelu infosüsteemi loomine 259 800 eurot +km.
Arendaja III hinnangul maksab uue tööelu infosüsteemi loomine 200 000 eurot +km.
Võttes kolme arendusettevõtte saadetud hinnangute keskmise, saame uue
tööelu infosüsteemi maksumuseks 230 833 eurot +km . Infosüsteemi loomine
võtab aega 6-9 kuud.
Analüüsi tulemid:
1. Oodatava lõpptulemuse (TO-BE kirjeldus).
2. Tööelu infosüsteemi kahe mooduli IT arenduse lähteülesanne.
3. Projekti dokumentatsioon.
PwC 7
Tööelu infosüsteemi eelanalüüs Lõpparuanne
2 Sissejuhatus
2.1 Valdkonna kirjeldus
Käesolev sissejuhatav peatükk annab ülevaate uuest planeeritavast tööelu infosüsteemist ja selle olulisusest.
Sealhulgas tuuakse esile seosed riiklike strateegiliste juhtimisdokumentide ja arengukavadega. Lisaks on
peatükis kirjeldatud probleemistik ja kitsaskohad, mis on tinginud vajaduse uue infosüsteemi järele ja ka
analüüsi tellimise.
2.1.1 Tööelu infosüsteemi loomist toetavad riiklikud strateegiad
Tööinspektsiooni (edaspidi TI) põhiülesandeks on töökeskkonnapoliitika elluviimine. Asutuse igapäevane töö ja
peamine eesmärk on teostada järelevalvet Eesti ettevõtete üle tööohutuse, -tervishoiu, -suhete ja -keskkonna
nõuete täitmise kontekstis. Samuti tegeleb TI töötajate ja tööandjate teadlikkuse tõstmisega ja aitab lahendada
töövaidlusi. 1 Mida kõrgem on tööhõive ja rahulolu töökeskkonnaga, seda suurem on oma eluga toimetulevate ja
ühiskonnas väärtuste loomises panust andvate inimeste hulk. Väheneb riigi koormus sotsiaaltoetuste
maksmisel, haiguspäevade hüvitiste vähenemine ning suureneb piirkondlik konkurentsivõime.
Sotsiaalministeeriumi Heaolu arengukava 2016-2023 2 toob välja, et tööhõives osalemine sõltub olulisel
määral tööelu kvaliteedist ja selle kvaliteedi tagamiseks on oluline tõhus riiklik järelevalve. Arengukava üks
eesmärk on tööohutuskultuuri arendamine, mille üheks väljundiks on riskide juhtimine. Pööratakse suuremat
tähelepanu, et ettevõtted on teadlikud riskidest ja võtavad ette samme nende maandamiseks. Järelevalve osas
on soov tõhustada järelevalvet, ehk siis jõuda suurema hulga ettevõteteni, kuid järelevalve kõrval on üha
olulisemat rolli omandamas nõustamine, mille läbi tõstetakse teadlikkust. Tehnilise poole pealt toob
arengukava välja IT lahenduste vähese sidususe ja innovaatilisuse. Riiklikul tasemel eksisteerib mitmeid
andmeid, mida saaks taaskasutada ja seeläbi vähendada halduskoormust ja tõhustada järelevalvet.
Eesti tööelu uuringu 2015 3 andmetel puutub 91% töötajatest töökohal olulisel määral kokku mõne
töökeskkonna ohuteguriga. Eesti kaotab igal aastal tööõnnetuste tagajärjel umbes 118 000 tööpäeva. Aastatel
2009–2014 sai töökohal toimunud õnnetuste tõttu raskelt viga 4593 töötajat ning kaotas elu 105 inimest. 2015.
aastal oli juhtunud tööõnnetus ligi 9% organisatsioonides ja 2,4% töötajatega. TI andmetel registreeriti 2016.
aastal 5081 tööõnnetust, sh raskeid tööõnnetusi 1019 ja surmaga lõppenud tööõnnetusi 26. Rasked
tööõnnetused moodustavad ligi 20% kõikidest registreeritud tööõnnetustest. Eesti Haigekassa andmetel oli
2016. aastal iga päev tööõnnetuse tõttu haiguslehel ligi 600 tööga hõivatut ning ühe tööõnnetusega kaasnes
keskmiselt 27,5 haiguspäeva.
Lisaks hindab 15% töötajatest, et viimase 12 kuu jooksul on töö põhjustanud või süvendanud nende
terviseprobleeme. Tööga seotud tervisekahjustused toovad kaasa töölt puudumise, mis on otsene kulu töötajale,
tööandjale ja riigile. Tööga seotud tervisekahjustused takistavad töötajal pikka aega ja aktiivsena tööelus
osalemist.
Tööhõives osalemine sõltub olulisel määral tööelu kvaliteedist. Selle kvaliteedi tagamiseks
on oluline ettevõtjate teadlikkus ja tõhus riiklik järelevalve.
1 Tööinspektsiooni põhimäärus https://www.riigiteataja.ee/akt/123122017026
2 Heaolu arengukava 2016–2023 https://www.sm.ee/et/heaolu-arengukava-2016-2023
3 Eesti tööelu-uuring 2015 https://www.sm.ee/sites/default/files/content-
editors/Ministeerium_kontaktid/Uuringu_ja_analuusid/eesti_tooelu_uuring_2015.pdf
PwC 8
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Eesti tööelu uuring adresseerib ka uutmoodi töötamise vorme, mis väljuvad reeglina tavapärase
reguleeritud ja kaitstud töösuhte raamidest (näiteks kodust töötamine), mille põhjal on üles ehitatud töötegija ja
tööandja õigused, kohustused, sotsiaalsüsteem ning töötaja tervise kaitse. Töötajad ja tööandjad ei ole piisavalt
kursis tööalaste õiguste ja kohustuste ning õigusaktidest tulenevate nõuetega. Samuti ei olda kursis konkreetse
tööga seonduvate riskidega ja võimalustega.
Tööinspektsiooni arengukava 2016-2020 4 on enim uue tööelu infosüsteemi loomist toetav strateegiline
dokument, mille peamised ja käesolevat analüüsi toetavad eesmärgid on:
1. Uue tsentraalse tööelu portaali loomine. Tööelu portaal peab arenema peamiseks tööohutuse-,
töötervishoiu- ja töösuhtealase teabe vahendamise kanaliks.
2. Automaatne ja kontaktivaba järelevalve. Tööinspektsiooni ressursside kasvu järelevalve
teostamiseks ei ole ette näha. Tulemaks toime kasvanud järelevalve vajadusega on otstarbekas kasutada
automaatseid kontrolle ja ohuhinnangul põhinevaid valimeid. Rakendades automaatseid kontrolle, on
võimalik tõsta järelevalve mahtu ja tõhusust. Sealhulgas üks alternatiivne võimalus on rakendada
kontaktivaba järelevalvet, mille kesksel kohal on idee, et kokkupuude seaduskuuleka ettevõtjaga oleks
võimalikult väike. Automatiseeritusest hoolimata peab olema Tööinspektoril võimalik veenduda, et
ettevõte, kes kontrolle läbib, tegeleb töökeskkonna ohutusega.
3. Halduskoormuse vähendamine ettevõtjatele. TI eesmärk on vähendada ettevõtete
halduskoormust ja rakendada riiklikus järelevalves laiapõhjaliselt e-lahendusi, mille raames on võimalik:
a. luua veebipõhiseid interaktiivseid lahendusi, mis aitavad vähendada halduskoormust ja ei
suurenda töökeskkonna ohutegurite avaldumise riski;
b. vähendada mikro-, väikese ja keskmise suurusega ettevõtete halduskoormust madalate riskidega
sektorites, kasutades e-teenuseid.
4. Tööohutuskultuuri parendamine ettevõtetes. Ettevõtete ja organisatsioonide ohutuskultuuri
parandamiseks muudetakse riskianalüüsi põhimõtteid. Mitmed teised tegevused seostuvad teadlikkuse
tõstmisega:
a. tööohutuse ja töötervishoiu strateegilised eesmärgid on kajastatud riiklikes arengukavades ja
programmides;
b. edendada avalikku arutelu huvi- ja sidusrühmadega, kelle kaudu levivad mõjud Eestis kaugemale;
c. koguda ja levitada valdkondlikku parimat praktikat;
d. levitada töökohaga seotud psühhosotsiaalsete probleemide ennetamise häid tavasid;
e. jätkata teadlikkuse tõstmist nii jooksvalt kui ka kampaaniate kaudu;
f. tõsta inimeste teadlikkust vajadusest eelistada töölepingu põhist tööd;
g. tuvastada ja teavitustegevusega ennetada uutest tehnoloogiatest tulenevaid uusi riske
töökeskkonnas.
5. Tööõnnetuste ja kutsehaigestumiste vähendamine. Selleks, et tööõnnetusi ja kutsehaigestumisi
reaalselt vähendada, peab tõhustama kommunikatsiooni ettevõtjate ja TI vahel. Kommunikatsioon peab
olema kiire, vähese bürokraatiaga ja toimuma e-kanalis nt läbi uue tööelu infosüsteemi. Kui infosüsteem
on asjakohane ja tõhus, siis avaldab see ettevõtetele positiivseid tulemusi. Kui süsteemid on kohmakad,
killustatud ja ei suhtle omavahel, siis ettevõtja pigem loobub TI-ga suhtlemisest ja see peegeldub ka
tööõnnetuste ja kutsehaigestumiste statistikas negatiivselt. Tööõnnetuste ja kutsehaigestumiste
vähendamise seisukohalt on oluline ka järelevalve tegevate inspektorite kompetentsi tõstmine, kui ka
tööandjate pidev harimine.
Oluline on nii tööandjale kui TI-le pidevalt kohaneda igapäevaste muutustega töökeskkonnas.
Tööõnnetusi ja seeläbi inimeste töövõime vähenemist põhjustavad ohutegurid, töökeskkond ja töövormid
4 Tööinspektsiooni Arengukava 2016-2020
https://www.ti.ee/fileadmin/user_upload/failid/dokumendid/Organisatsioon/Strateegia__tooplaan__progra
mmid/Tooinspektsiooni_Arengukava_2016_2020.pdf
PwC 9
Tööelu infosüsteemi eelanalüüs Lõpparuanne
on valdkonniti väga erinevad. Seetõttu tuleb nii strateegiliste kui lühiajaliste eesmärkide edukaks
rakendamiseks TI teenistujaid pidevalt koolitada, soetada riikliku järelevalve tõhustamiseks vajalikke
tehnilisi vahendeid ning rakendada uusi e-lahendusi (sh infosüsteemide automaatseid kontrolle).
Suuremat tähelepanu tuleb pöörata kutsehaigestumise juurpõhjuste väljaselgitamisele. Tihti on
kutsehaigestumist põhjustavad tegurid välditavad, kui neile tähelepanu pöörata. Näiteks monotoonsed
liigutused töökohal, mis on üha suurema osakaaluga põhjused kutsehaigestumistes ning tööst
põhjustatud haigustes. Vähese teadlikkuse tõttu ei oska tööandjad ja töötajad neid riske arvesse võtta ja
ohutegureid märgata. Samuti on töötajate teadlikkus füüsilisest ülekoormusest ja sellest põhjustatud
tervisehäiretest vähene.
6. Samuti pöörab TI 2016-2020 perioodil rohkem tähelepanu mikro-, väikese ja keskmise suurusega
ettevõtete nõustamisele, koolitamisele ja kaasamisele, et tõsta teadlikkust, tööohutusse ja töötervishoidu
panustamist. Järelevalves lähtutakse ohuhinnangust ja eelkõige kontrollitakse ettevõtteid ja
organisatsioone, mille riskiaste on kõrge.
Euroopa Liidu töötervishoiu ja tööohutuse strateegiline raamistik aastateks 2014-2020 5
seab liikmesriikidele töökeskkonna ohuteguritega tegelemiseks kolm väljakutset:
1. suurendada mikro- ja väikeettevõtjate suutlikkust kehtestada toimivad ja tõhusad riskiennetusmeetmed;
2. parandada tööga seotud haiguste ennetamist, vältides olemasolevaid ning uusi ja tekkivaid riske;
3. tulla toime demograafiliste muutustega.
Rahvastiku tervise arengukava 2009-2020 6 üheks alaeesmärgiks on elu-, õpi- ja töökeskkonnast
tulenevate terviseriskide vähendamine, millel on otsene seos tööelu kvaliteedi tagamisega ja töötingimuste
parandamisega. Tööõnnetuste vähendamine ja töökeskkonna psühhosotsiaalsete ohutegurite teadvustamine ja
tegelemine aitab parandada rahvastiku tervist ning tagada võimaluse majanduse arenguks.
Konkurentsivõime kava „Eesti 2020“ 7 toob välja, et tervist hoidva ja säästva töökeskkonna tagamine on
võtmetähtsusega konkurentsivõime kava eesmärkide saavutamise suhtes. Kava sätestab vajaduse jätkata
tööõnnetus- ja kutsehaiguste kindlustussüsteemi loomisega.
Eesti Infoühiskonna Arengukava aastaks 2020 8 üheks suureks eesmärgiks, mis toetab ka käesoleva
analüüsi eesmärki, on nutikam riigivalitsemine. Soovitakse saavutada olukorda, kus avaliku sektori juhtimine ja
toimimine on tänu IKT võimaluste oskuslikule kasutamisele nutikam, tõhusam, terviklikum, jätkusuutlikum
ning ka avatum. Kodanike ja ettevõtjate jaoks toob see kaasa vähekoormavad, mugavad ja üha enam
koosloomes sündinud teenused. Samuti sunnib IKT areng arendama TI teenistujate kompetentse, et olla
võimeline inspekteerima erinevates majandusvaldkondades kasutatavaid kaasaegseid masinaid ja seadmeid.
Efektiivsemat menetlusprotsessi riigiasutuste ning kodanike vahel toetab ka Majandus- ja
Kommunikatsiooniministeeriumi nullbürokraatia projekt 9, mille peamine eesmärk on bürokraatia ja
halduskoormuse vähendamine riigiasutustega suhtlemisel.
5 EU Occupational Safety and Health (OSH) Strategic Framework 2014-2020
http://ec.europa.eu/social/main.jsp?catId=151&langId=en
6 Rahvastiku tervise arengukava 2009–2020
http://www.tai.ee/images/PDF/Rahvastiku_tervise_arengukava_2009-2020.pdf
7 Konkurentsivõime kava „Eesti 2020“ https://riigikantselei.ee/sites/default/files/content-
editors/Failid/konkurentsivoime_kava_eesti_2020_2011.pdf
8 Infoühiskonna Arengukava 2020
https://www.mkm.ee/sites/default/files/elfinder/article_files/eesti_infouhiskonna_arengukava.pdf
9 MKM Nullbürokraatia projekt https://www.mkm.ee/et/nullburokraatia
PwC 10
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Töökeskkonna ohutus on erinevates riiklikes arengukavades läbiv teema ja omab olulist
rolli majanduse arengus.
Kokkuvõttes on töökeskkond oluline teema mitmetes riiklikes arengukavades ja sellesse panustamist nähakse
prioriteetse suunana. Samuti rõhutatakse vajadust, et panus töökeskkonna arendamisse peab olema
läbimõeldud ja omama positiivset mõju nii ettevõtetele kui ka Eestile tervikuna. Üks mitmetest vahenditest, mis
aitab seatud eesmärke saavutada on kaasaegne infosüsteem, mis võimaldab TI-l tõhusalt järelevalvet teostada ja
tööandjatel oma igapäevases töökeskkonnas riske paremini tuvastada ja maandada.
2.1.2 Analüüsi probleemistik
Analüüsi probleemistik jaguneb mitmeks omavahel tihedalt seotud teemaks, mis mõjutavad nii tööandjaid kui
ka TI-d. Valdava osa probleemide lahendamisele aitab kaasa uus infotehnoloogiline lahendus ehk uue
infosüsteemi loomine. Lisaks on vaja infosüsteemi väliseid muutusi. Näiteks ettevõtete ohutuskultuuris, selle
metoodilises lähenemises kui ka ohutuskultuuri puudutavates tööprotsessides.
Järgnevalt on temaatiliste blokkidena välja toodud ülevaade tööelu valdkonna probleemidest. Esmalt on
kirjeldatud probleemid ettevõtjate osas ja seejärel TI osas.
Käesolevat peatükki kokkuvõttes eksisteerivad tööelu valdkonnas tänasel päeval järgmised
probleemkohad, mis on kaardistatud ettevõtjate, Sotsiaalministeeriumi spetsialistide,
Tööinspektsiooni töötajate ja juhtkonnaga läbi viidud intervjuude käigus:
• Ettevõtjate madal teadlikkus seadusega pandud kohustustest oma töötajate tervise ja ohutuse tagamiseks.
• Ohutuskultuuri madal prioriteetsus.
• Riskianalüüsi tegemine on tänasel päeval keskmisele ja väiksemale ettevõttele keeruline. Riskianalüüside
kvaliteet on väga erinev.
• Riskianalüüsi ei kontrollita ettevõttes regulaarselt üle. Tihti on need aastaid uuendamata.
• Töökeskkonna riskianalüüsi teenuseosutajate kvaliteeti ei kontrollita.
• Kui ettevõte tellib riskianalüüsi inspektoritele esitamiseks, siis tõenäoliselt seda sisuliselt ei kasutata.
• Ettevõtjatel ei ole seadusest tulenevate nõuete rakendamiseks piisavat abimaterjali. Riskianalüüsi
läbiviimiseks puudub soovitatud metoodika.
• Ettevõtjatel on vaja arusaama, milliste vahenditega tehtud mõõtmised nende ettevõttes on
aktsepteeritavad riskianalüüsi kontekstis.
• TI jõuab järelevalvet teha väga väikesele osale ettevõtetest.
• Järelevalve objektide valikul tehakse palju käsitööd.
• Kontaktivaba järelevalve rakendamise kasud on hetkel piiratud.
• Järelevalve protsess ei ole tehniliste lahenduste poolt piisavalt toetatud ja on TI inspektorile ajaliselt
koormav.
• Andmete taaskasutus on madal.
• Ettevõtete tegevusaadress on riiklikes registrites sageli uuendamata ja seetõttu on järelevalve teostamine
keeruline.
• Võimalused kogutud andmeid analüüsida ja selle põhjal olulisi järeldusi teha on piiratud.
• Tööbiku infosüsteem loodi töökeskkonna teemades teadlikule kasutajale ja on vähekogenud kasutajal
keeruline kasutusele võtta.
• Tööbiku portaalis riskianalüüsi tegemise suurimaks barjääriks on esmase pingutuse suurus.
• ITI-s puudub teavituse saatmise funktsionaalsus, mille abil saab kontrollida teavituse kättesaamist.
• ITI kasutusloogika lähtub dokumendihaldusest.
• Klienditeenindusportaali eTi-t kasutatakse küllaltki vähe.
• eTI-s kasutajatele õiguste andmine on lahendatud eesti.ee kaudu, see on keeruline ja nõuab u 24 erinevat
sammu.
PwC 11
Tööelu infosüsteemi eelanalüüs Lõpparuanne
2.1.2.1 Tööandjate problemaatika
Tööandjal on töötervishoiu ja tööohutuse seadusest 10 tulenevalt hulk kohustusi töötajate tervise ja ohutuse
tagamiseks ning nende töövõime säilitamiseks. Seejuures on ettevõtjate üheks probleemiks madal teadlikkus
seadusega pandud kohustustest. Eestis on ligikaudu 120 00 ettevõtet (neist ca 55 000 ettevõttel on
vähemalt 1 töötaja) ja nendest valdaval osal puudub riskianalüüs. Ettevõtetel, kus ei ole töötajaid, ei ole sageli
tegevust, mis Tööinspektsioonile huvi pakuks või mida oleks otstarbekas kontrollida. Samas tegeletakse
aktiivselt sellega, et tuvastada ettevõtted, kus ei ole ametlikult kedagi tööl, kuid toimub aktiivne tegevus. Samuti
ei teadvustata kohustust olemasolevat riskianalüüsi töötajatele tutvustada. Mitmetes ettevõtetes ollakse
teadlikud kohustusest määrata TK-spetsialist, kuid sellega sageli ka teadlikkus kohustustest piirdub.
Eesti tööelu uuring 2015 11 toob esile, et aastal 2015 oli ainult 45% uuringus osalenud ettevõtteid määranud TK-
spetsialisti. Sama uuring kinnitab ka, et mida väiksem ettevõte seda väiksemal hulgal on valitud TK-volinik (ei
ole kohustuslik alla 10 töötajaga ettevõtete puhul). Näiteks aastal 2015 oli 10-49 töötajaga ettevõtetest valitud
TK-volinik 62%. Samas on oluline esile tuua, et võrreldes 2009. aastal läbi viidud samalaadse uuringuga on
olukord tervikuna paranenud.
Töötervishoiu ja tööohutuse seaduse pandud kohustuste vähest täitmist põhjustab ka teema vähene
prioriteetsus ettevõtte kontekstis. Vähesed ettevõtted määravad oma ettevõttes TK-spetsialisti ja tihti
esineb olukord, kus ühele töötajale on töökeskkonna nõuete täitmine üheks täiendavaks ülesandeks tema
põhitöö kõrval. Töökeskkonna ohutus ei ole tema jaoks prioriteetne. Inimesel on ettevõttes mitu erinevat rolli ja
töökeskkonna spetsialisti roll on sekundaarse tähtsusega.
Teisalt võib töökeskkonna ohutuse juhtimine olla ettevõtte sisemise kultuuri kontekstis marginaalse tähtsusega.
Näiteks tootmisettevõttega läbi viidud intervjuus toodi esile, et TK-spetsialisti roll on antud tootmisdirektorile,
sest madalamal positsioonil olev töötaja ei omaks kogenud spetsialistide üle piisavat võimu, et muudatusi esile
kutsuda või töötajaid ohutusreegleid järgima panna. Samuti võib positiivse näite tuua ehitusettevõttest, kus TK-
spetsialistiks on tegevjuht, kes tegeleb aktiivselt töökeskkonna ohutuse tagamisega.
Riskianalüüsi tegemine on tänasel päeval keskmisele ettevõttele keeruline ja riskianalüüside
kvaliteet väga erinev. Töötervishoiu ja tööohutuse seadus sätestab ettevõtjal kohustuse läbi viia riskianalüüs,
kuid selle koostamise soovituslikku metoodikat ei ole ette antud. Tööelu.ee veebilehel on teoreetiline ülevaade
riskianalüüsi tegemiseks, kuid see on tervikuna raskesti hoomatav ja käesolevas analüüsis intervjueeritud
ettevõtjad ei olnud sellest ka teadlikud. Igal ettevõtjal on vaba voli otsustada, milline nende riskianalüüs välja
näeb või, kes selle koostanud on. Ettevõtted kasutavad sageli veebist leitud riskianalüüside näiteid, mis
kohandatakse enda vajadustele sobivaks. Sellise lähenemisega puudub ettevõtjal kindlustunne, et riskianalüüs
on adekvaatne ja TI seda aktsepteerib. Ka nendel juhtudel, kus ettevõte ei kohanda leitud riskianalüüsi oma
vajadustele, vaid töötab selle ise välja, puudub kindlustunne selle adekvaatsuse ja ulatuse osas. Ettevõtjad
väljendasid intervjuudel vajadust selge riskianalüüsi koostamise metoodika järele.
Riskianalüüsi ei vaadata ettevõttesiseselt regulaarselt üle. Sellel puudub aegumistähtaeg, mis
iseenesest ei oleks probleem kui ettevõtte töökeskkond püsiks muutumatuna. Reaalsuses muutub töökeskkond
kiiresti, kuid ettevõtted ei uuenda koos nende muudatustega riskianalüüsi. Muutustest tingitud riske hindamata
puudub ettevõttel kindlustunne maandamismeetmete vajalikkuse ja rakendamise osas. Muutunud töökeskkond
võib esile tuua uusi ohte, mida ettevõte ei pruugi näha ja mille maandamise vajadust ei teadvustata. Teatava
regulaarsusega nt kord poole aasta jooksul standardiseeritud riskianalüüsi tehes saab kergemini tuvastada, kas
olukord on muutunud ja kuidas nende muudatustega kaasa minna.
Tööandja saab riskianalüüsi tegemise kolmandalt osapoolelt sisse osta ja seda võib pakkuda ükskõik milline
ettevõte. Probleemiks on see, et töökeskkonna riskianalüüsi teenuseosutajate kvaliteeti ei
kontrollita. Puudub teadmine, mille põhjal tuvastada kompetentsed teenusepakkujad. Inspektorite sõnul
esineb olukordi, kus erinevaid riskianalüüside dokumente lihtsalt kopeeritakse teistele ettevõtetele ja
10 Töötervishoiu ja tööohutuse seadus https://www.riigiteataja.ee/akt/12883561
11 Eesti tööelu-uuring 2015 https://www.sm.ee/sites/default/files/content-
editors/Ministeerium_kontaktid/Uuringu_ja_analuusid/eesti_tooelu_uuring_2015.pdf
PwC 12
Tööelu infosüsteemi eelanalüüs Lõpparuanne
muudetakse ainult mõningaid andmeid. Näitena toodi olukord, kus restorani riskianalüüs läks sujuvalt üle
lasteaia riskianalüüsiks. Kopeerimisest tingitud probleeme kinnitasid ka ettevõtjad. Samas oli ka ettevõtteid, kes
olid sisse ostetud teenusega rahul, sest analüüsis toodi esile aspekte, mis muidu oleksid neil tähelepanuta
jäänud. Samas oli neil ka kogemusi, kus kõik teenusepakkuja soovitused ei olnud piisavalt adekvaatsed.
Teenusepakkujatega seotud kvaliteediküsimusi aitaks lahendada kutsestandardi loomine või sertifitseerimine.
TI inspektorite hinnangul on riskianalüüsi tellimise eesmärgiks luua dokument inspektoritele
esitamiseks ja kontrolli läbimiseks. Puudub arusaam, et riskianalüüs on vajalik ettevõttesisese tegevuse
planeerimiseks. Teenuse sisse ostmisega ei kaasne alati ka teadmiste ülekannet ja riskihalduse juurutamist
ettevõttesse endasse, sest ettevõtte esindajad ei osale riskianalüüsi tegemise protsessis.
Seadusandlus sätestab ära peamised ohutegurid neljas erinevas kategoorias (füüsikalised, keemilised,
bioloogilised, füsioloogilised ja psühholoogilised tegurid), ning vabariigi valitsuse määrused kirjeldavad neid
täpsemalt ja sätestavad täiendavad tingimused mõõtmise osas. Seadusandlus ja määrused on piisavad
spetsialistidele, kellele töökeskkonnaga tegelemine on peamine tööülesanne. Väikeettevõttes, kus
töökeskkonnaga tegelemine on ühele töötajale üks paljudest ülesannetest, ei ole seadusest tulenevate
nõuete rakendamiseks piisavat abimaterjali. Intervjuudel väljendati vajadust selge ja konkreetse juhendi
järele.
Tööandjal on vaja teada, milliste vahenditega tehtud mõõtmised on aktsepteeritavad riskianalüüsi
kontekstis. Teatud juhtudel on vajalik ettevõttel riskianalüüsi käigus teostada töökeskkonnas erinevaid
mõõtmisi (nt müra, valgustugevus, kemikaalide hulk õhus ja elektromagnetlained). See muudab riskianalüüsi
teostamise ettevõtjale keerulisemaks ja soodustab teenuse sisse ostmist, mis omakorda tähendab ettevõttele
täiendavat kulu. Seetõttu ei ole see eelistatud tegevus.
Ettevõtjatel võiks võimalus olla lihtsamaid mõõtmisi ka ise läbi viia, nt valgustugevuse ja müra mõõtmine
nutitelefoni rakendusega. Tööandjal on vaja aru saada, milliste parameetrite mõõtmine on otstarbekas sisse
tellida ja millega võiks ettevõte ise hakkama saada. Esimeste mõõtmiste teostamine tööandja poolt on suur
samm edasi ettevõttesisese olukorra teadvustamisele ja üldise ohutuskultuuri parandamise suunal.
2.1.2.2 Tööinspektsiooni problemaatika
TI jõuab käesoleval hetkel kontrollida ainult väikest osa ettevõtetest. TI peab piiratud ressursside
tingimustes tegema järelevalvet kõikide Eesti ettevõtete üle. See tähendab, et reaalselt jõutakse suhelda väikese
osaga ettevõtetest, sest Eestis on registreeritud üle 120 000 ettevõtte.
Aastal 2017 oli 54 652 ettevõttes vähemalt üks töölepinguga töötaja, mis tähendab TI poolset järelevalve
vajadust. Aastal 2017 suutis TI läbi viia ainult 4300 järelevalve menetlust, millega hõlmati 3777 ettevõtet. 12
Oluline tähelepanek on järelevalvemenetluste hulga langus aastatel 2015-2017. 2015. aastal toimus 5350
menetlust, 2016. aastal 4750 menetlust ja 2017. aastal 4300 menetlust.
TI võib ka hetkel kontaktivaba järelevalvet läbi viia, kuid kuna dokumendid ja info ei ole elektrooniliselt
kättesaadav ei saa seda edukalt rakendada, sest see ei vähenda vajaliku töö hulka. Kontaktivaba järelevalve
rakendamise kasu on piiratud, sest dokumendid ei ole TI-le lihtsalt kättesaadavad. Kontaktivaba
järelevalve rakendamiseks peaksid tööandjad hetkel dokumendid inspektoritele eraldi edastama e-posti teel,
mis lõppkokkuvõttes ei võta vähem aega kui inspektoril nende dokumentidega kohapeal tutvumine.
TI teostatav järelevalve protsess ei ole tehniliste lahenduste poolt piisavalt toetatud. See on
inspektorile koormav ja vajab muutmist. Hetkel kasutusel olev infotehnoloogiline lahendus lähtub
paberdokumentide loomise loogikast, järelevalve protsessis tekib palju pabertoimikuid ja teostatakse palju
käsitööd (vormide täitmine, info topelt sisestamine infosüsteemidesse).
12 Töökeskkond 2017
http://www.ti.ee/fileadmin/user_upload/failid/dokumendid/Meedia_ja_statistika/Toeoekeskkonna_uelevaat
ed/2015/Tookeskkond_2017_veebi.pdf
PwC 13
Tööelu infosüsteemi eelanalüüs Lõpparuanne
On inspektoreid, kes täidavad vorme järelevalve käigus paberil ja seejärel sisestavad need andmed TI
infosüsteemi, et kontrolli protokoll seejärel edastada ettevõtte esindajale. Tööandja ja TI teevad oma toiminguid
ja töötlevad infot eraldi süsteemides. Tööandja saadab inspektorile enda info (e-mailid, paberdokumendid,
elektroonilised dokumendid), kes need seejärel ITI järelevalve infosüsteemi sisestab. Valdav osa infovahetusest
toimub e-posti teel. TI on infovahetuse toetamiseks loonud e-kanali eTI kuid seda kasutatakse vähe.
Infovahetuse viimine infosüsteemi ja seal vajalike andmete kättesaadavaks tegemine võimaldab mõlemal
osapoolel aega kokku hoida.
Andmete taaskasutus on madal. Hetkel sisestatakse süsteemidesse valdav osa infot topelt. Kui andmed on
juba kuskile sisestatud, siis peab neid saama ka teiste infosüsteemide poolt uuesti kasutada. Näiteks järelevalve
protokolli täitmisel peab inspektor käsitsi sisestama juriidilise isiku andmed (nimetus, rg-kood, tegevusala,
töötajate arv, ja aadressid). Nendest andmetest suur osa on juba olemas ITI infosüsteemis ja riiklikes registrites
(Äriregister ja Töötamise register).
Inspektorile on keeruline kontrollitavate ettevõtete õige tegevusaadressi ja kontaktandmete leidmine, sest
ettevõte on tegevuskohta ja e-posti aadressi muutnud ning seejuures jätnud info Äriregistris uuendamata.
Ettevõtete tegevusaadress on riiklikes registrites sageli uuendamata ja see probleem mõjutab
tõenäoliselt ka teisi riigiasutusi. TK-spetsialisti kontakteerumise info ei ole samuti otseselt leitav. Hetkel on
ettevõtte õige kontaktinfo otsimine internetist ajamahukas käsitöö. Samuti eksisteerib olukord, kus ühel
postiaadressil on registreeritud viis erinevat ettevõtet. Kokkuvõttes suurendavad puudulikud või aegunud
andmed vigade tekkimise ohtu (nt teavitus läheb valele aadressile).
Võimalused kogutud andmeid analüüsida ja selle põhjal olulisi järeldusi teha on piiratud.
Sisuliselt kogub TI ITI infosüsteemi vahendusel järelevalvet tehes erinevaid andmeid, kuid nende
analüüsimiseks on vaja käsitööd teha (andmed eksportida Excelisse ja seal neid analüüsida). Järelevalve
protokolli vahendusel tekkivad andmed ei ole kõik masintöödeldaval kujul, mistõttu tuleb andmed eksportida,
korrastada ja viia masintöödeldavale kujule. Analüütika piiratus ei võimalda seetõttu TI tegevuse kohta
kaugeleulatuvaid järeldusi teha. Puudub selge ülevaade, kas see, et tööõnnetuste arv mingil aastal vähenes oli
tänu suuremale pingutusele järelevalves või oli seal taga muu põhjuslik seos.
Näiteks vaadates all olevat tabelit (vt Tabel 1) ja selles väljatoodud statistikat, on näha, et valdaval osal
järelevalve menetluste käigus tuvastati ettevõtetes üks või enam puudust. Pole teada, kas nende puuduste
kõrvaldamine reaalselt vähendab järgmistel aastatel potentsiaalsete tööõnnetuste arvu. Hetkel puudub
funktsionaalsus, mille abil saaks kontrollida, kas näiteks ettevõtetes, kes rikkumised kõrvaldasid, toimus hiljem
ka vähem tööõnnetusi. Sarnaselt saab kontrollida ka korrelatsiooni ettevõtete tervisekontrollide läbiviimise,
haigusjuhtumite ja haiguspäevade vahel.
Tabel 1. Järelevalve menetluste statistika kolme aasta lõikes
Järelevalve menetluste moodul 2015 2016 2017
Järelevalve menetluste arv kokku: 5350 4750 4300
Järelevalve menetluste arv, kus tuvastati puuduseid: 3900 4100 3700
2.1.2.3 Infosüsteemide problemaatika
Tööandjatele, töötajatele ja TI-le on tööelu valdkonnas loodud erinevatel perioodidel mitmeid elektroonilisi
töövahendeid, kuid nimetatud valdkonna infosüsteemid ja e-teenused on aegunud, killustatud ja ei
suhtle omavahel.
Tööelu infoportaal 13 on loodud tööandjate ja töötajate teadlikkuse tõstmiseks ja avalikkuse
üldiseks informeerimiseks. Portaal koondab endasse TI, Sotsiaalministeeriumi, Terviseameti ja Tervise
13 Tööelu veebileht http://www.tooelu.ee
PwC 14
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Arengu Instituudi info, mis on seotud töökeskkonna, -tervishoiu, -ohutuse ja -suhetega. Lisaks infomaterjalidele
avaldatakse portaalis valdkonnaga seotud uudised, üritused ja kampaaniad. Tööelu infoportaal on kavas jätta ka
edaspidi tööelu infosüsteemi arendamise käigus tsentraalseks töövaldkonna infoallikaks, kuid selle külge tuleb
uus Tööelu infosüsteem, mille kaudu saab riik erinevaid teenuseid pakkuda. 2015. aasta alguses kustutati
tehnilise vea tõttu Tööelu portaalist osa uuendusi ja sisu. Sellest tulenevalt kannatas kasutajate arv ja tegeletud
on selle arvu taastamisega. Viimastel aastatel on infoportaali kasutajate arv olnud vaikselt kasvav, kuid see jääb
siiski alla 2500 kasutaja nädalas.
Joonis 1. Tööelu portaali kasutajate arv
Tööandjatele on suunatud kaks peamist töövahendit Tööbik 14 ja Stressikaardistaja 15. Nende põhiliseks
eesmärgiks on lihtsustada töötervishoiu ja tööohutuse valdkonna tegevuste läbiviimist ja parandada seeläbi
ettevõtte töökeskkonda ja tõsta ohutuskultuuri.
Üheks riskianalüüsi teostamise vahendiks on Tööbiku infosüsteem, mis sisaldab endas ettevõtte töökeskkonna
riskide analüüsimist, juhendamist, väljaõppe registreerimist, isikukaitsevahendite väljastamise registreerimist,
töötajate teavitamist, tervisekontrollide üle arvestuse pidamist ja isikupõhise riskitaseme määramist.
Tööbiku infosüsteem loodi töökeskkonna teadlikule kasutajale, st töökeskkonna spetsialistile mitte
vähemteadlikule kasutajale. Tavakasutajad 16 on enamasti väikesemate erialaste teadmistega töökeskkonna
ohutuse valdkonnas ja nende jaoks tundub keskkond esmapilgul pigem liiga keeruline. Tööbik on äärmiselt
funktsionaalsete võimalustega töövahend, mis võimaldab töökeskkonna ja riskide üle detailset arvestust pidada.
Liigne detailsus põhjustab probleemi uutele kasutajatele, kelle põhitööks ei ole töökeskkonna haldus ja kes pole
niivõrd kompetentsed selles valdkonnas. Kasutajale, kes logib portaali esmakordselt sisse, ei kuvata vajalike
tegevuste tegemiseks (nt riskianalüüs) lihtsaid ja loogilisi juhendeid. Portaali kasutusloogika on keeruline.
Keerukuse tõttu ei ole see sobiv väikeettevõttele ja portaali katsetanud suurettevõtte töökeskkonna spetsialist
kinnitas intervjuul, et tema hinnangul ei ole see kasutajasõbralik ka sellisele suurele ettevõttele, kus on mitmeid
tegutsemiskohti või palju erinevaid rolle.
Tööbiku portaalis riskianalüüsi tegemine on keeruline ja aeganõudev tegevus, sest seal on riskianalüüsi vaade
isikupõhine. Ära tuleb kirjeldada iga isikuga seotud tööruumid ja töövahendid, misjärel kuvatakse iga töötaja
kohta riskiprofiil ja vajalikud tegevused. Kasutajate tagasiside põhjal on esmane pingutus Tööbikus
riskianalüüsi tegemiseks küllaltki suur, kuid hilisem haldamine on lihtsam. Samas on just see esimesest
pingutusest tingitud barjäär tööandjale oluliseks takistuseks. Tööbik ei võimalda ettevõtjal anda inspektorile
järelevalve ajaks riskianalüüsile elektrooniliselt juurdepääsu. Seetõttu tuleb kontrolli ajal teha Tööbikust
väljatrükk või näidata ettevõtja konto alt Tööbiku riskianalüüsi.
Tööbiku kasutatavus tööandjate seas on madal ja statistika ei ole usaldusväärne. Valdav osa Tööbiku
külastustest (u 89%) kestavad alla 30 sekundi ja TEHIK-u hinnangul on tegu kasutajatega, kes juhuslikult
satuvad Tööbiku lehele ja sealt kohe edasi liiguvad.
Stressikaardistaja on loodud ühe konkreetse psühhosotsiaalse ohuteguri levimuse ja ohtlikkuse hindamiseks
ettevõttes töötajate küsitlemise kaudu. Stressikaardistaja võeti kasutusele 2010. aastal ja on sisuliselt töötav
14 Tööbik http://toobik.ee/site/login
15 Tööstressi kaardistaja https://www.stressivastu.ee/hse
16 Ettevõtja esindaja, kelle üheks sekundaarseks ülesandeks on töökeskkonnaspetsialisti roll.
PwC 15
Tööelu infosüsteemi eelanalüüs Lõpparuanne
lahendus. Teisalt vajab see samuti kaasajastamist, sest analüütika aluseks olevad teadusuuringud on muutunud.
Sellest tulenevalt ei pruugi stressikaardistaja tulemused olla kõige relevantsemad.
Järelevalve läbiviimiseks kasutab TI infosüsteemi ITI, mis võeti kasutusele 2004. aastal. See on loodud
standardsele dokumendihaldussüsteemi platvormile Webdesktop 17. Infosüsteemi on edasi arendatud
dokumendihalduse süsteemist infohalduse süsteemiks, kuid keskseks objektiks selles on endiselt dokumendid.
ITI on liidestatud erinevate X-tee teenustega:
• Äriregister (Registrite ja Infosüsteemide Keskus, tööandjate andmed).
• Rahvastikuregister (Siseministeerium, füüsiliste isikute andmed).
• Töötamise register (Maksu- ja Tolliamet, ettevõtte töötajad ja ettevõtte andmed).
• Majandustegevuse register (Majandus- ja Kommunikatsiooniministeerium, tööandjate tegevusalad ja
tegevusload).
• Aadressandmete andmekogu (Riigi Infosüsteemi Amet, aadressandmed).
• E-toimik (Registrite ja Infosüsteemide Keskus, väärteomenetlused).
ITI-s puudub teavituse saatmise funktsionaalsus, mille abil saab kontrollida teavituse
kättesaamist. Näiteks tööandjale teavitust saates ja puuduste kõrvaldamise tähtaega määrates ei ole aru
saada, kas teavitus jõudis kohale. On juhtumeid, kus tööandjale sihtkontrolli teavitust saates väidetakse, et nad
ei ole teavitust kätte saanud, mis põhjustab ebavajalikku segadust ja vaidlusi. Väärtegude korral on alusandmed
ITI-s olemas, kuid väärtegude menetlemiseks tuleb need uuesti sisestada Politsei infosüsteemi. Kasutajate
tagasiside põhjal on ITI-s ka positiivseid omadusi, näiteks võimalus igal kasutajal luua just oma vajadustele
vastav töölaud. Samuti on võimalus luua ja kohandada järelevalve menetluseks kasutatavaid vorme.
Lisaks on ITI liidestatud ka Haigekassa infosüsteemidega, mis võimaldab Haigekassal kontrollida, kas
töövõimetusele on registreeritud tööõnnetuse raport.
ITI probleemiks on kohati keeruline kasutusloogika, mis tuleneb sellest, et infosüsteemi keskseks objektiks
on dokument. Näiteks tuleb ITI-st kirja välja saates märkida peale kirja saatmist eraldi kasti linnuke, et kiri on
välja saadetud. ITI infosüsteemi dokumentide lisamiseks tuleb e-posti teel saadetud dokumendid ITI-sse
eksportida ja seejärel need käsitsi juhtumiga siduda. Paberkandjal dokumentide puhul tuleb need enne ITI-sse
importimist ja juhtumiga sidumist skaneerida.
Samuti toimub e-mailide käsitsi skaneerimine ja ITI-sse sisestamine igapäevase infovahetuse (nt rikkumiste
tõendite esitamine inspektorile) käigus TI ja subjektide vahel. ITI-s puudub võimalus e-maile otse importida.
See protsess pärineb dokumendihalduse põhimõtetest. Uuemates infosüsteemides on keskseks objektiks
ettevõte, kellega tehakse erinevaid tegevusi, mitte dokument.
ITI baasil on arendatud ka kliendiportaal eTI 18, mis on keskkond TI, tööandjate ja töötajate vaheliseks
infovahetuseks. Portaali kaudu on tööandjal ja töötajal võimalik vaadata endaga seotud menetlusi ning koostada
ja edastada teateid ja raporteid. Portaal on liidestatud ITI infosüsteemiga, kuid eTi-t kasutatakse küllaltki
vähe. Intervjuudes ettevõtjatega tunti mitmel juhul huvi eTi portaali uuendamise kohta. Samuti toodi välja, et
eTI on visuaalselt ja kasutajamugavuse osas vananenud, kuid samas see töötab ja võimaldab elektroonilist
infovahetust TI-ga.
Portaali kasutamise aja jooksul on toimunud mitmeid muudatusi ja seetõttu on portaali jäänud erinevaid
artefakte. Näiteks varasemalt kandsid järelevalvemenetlused teist nime ja need on eTI menüüvalikutes siiani
alles, viidates vajadusele kasutajaliidest uuendada.
Kliendiga suhtlemine käib eTI, telefoni ja e-posti kaudu ning harvematel juhtudel tavapostiga. Valdav osa
suhtlusest käib e-posti teel, mitte läbi selleks mõeldud kliendiportaali. See suurendab TI koormust ja ajalist
kulu.
17 Webdesktop https://www.webware.ee/et/webdesktop
18 eTI https://eti.ti.ee
PwC 16
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Kliendiportaali eTI autentimine ja autoriseerimine toimub läbi eesti.ee portaali, mis on kasutajale ebamugav ja
aeganõudev tegevus. Samuti on kasutajatele õiguste andmine on lahendatud eesti.ee kaudu ja nõuab
u 24 erinevat sammu ja detailset juhendit. Sellise keerukuse tõttu jäetakse see tegevus pigem ära, sest
ettevõtete juhtide ajaressurss on piiratud.
Joonis 2. TI kasutatavad infosüsteemid
Väärtegude menetlemisel kasutab TI e-toimiku kaudu ühendatud politsei menetluse infosüsteemi POLIS 19 (vt
Joonis 3). Inspektor sisestab väärteo juhtumi korral käsitsi andmed politsei infosüsteemi ja lisaks ka ITI-sse.
Topelt sisestamine on hetkel vajalik seetõttu, et oleks võimalik ITI-st ajalugu ja statistikat vaadata.
19 Politsei infosüsteem POLIS https://www.riha.ee/Infos%C3%BCsteemid/Vaata/polis
PwC 17
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Joonis 3. E-toimiku infosüsteemide ülevaade
2.2 Analüüsi eesmärk
Käesoleva analüüsiga soovitakse leida parim lahendus töökeskkonna riskianalüüsi ja järelevalvemenetluse
läbiviimiseks ning tuvastada optimaalne lahend selle tehnoloogiliseks realiseerimiseks. Analüüsiprojekt on
sisendiks uue tööelu infosüsteemi arendamiseks.
Arendusprojekti realiseerimine aitab lahendada eelnevalt väljatoodud probleemistikku. Toimuma peab
üleminek paberivabale asjaajamisele, vähenema halduskoormus ja suurenema andmete taaskasutamine
infosüsteemide vahel. Lisaks luuakse uue infosüsteemi loomisega eeldused andmeanalüütika rakendamiseks.
Analüüs on osa suuremast visioonist töötada välja keskne Tööelu infosüsteem. Antud analüüsi käigus
uuritakse eelkõige riskianalüüsi ja järelevalve moodulitega seonduvat temaatikat. Uue Tööelu IS
moodulite nimekiri ei ole veel lõplik, kuid sisaldab järgnevat:
• Järelevalve – TI peab saama teha järelevalvet nii töökeskkonna kui töösuhete üleselt kiirelt, mobiilselt,
lihtsalt, loogiliselt ja paberivabalt, kasutades selleks digitaalset rakendust.
• Riskianalüüs – lihtne, kiire, sisukas ja kasutajasõbralik riskianalüüs: ohtude tuvastamine, vajadusel
isikute sidumine, abinõude rakendamise kontroll, tegevuskava koostamine ja selle haldamine.
• Juhendamine – ettevõtetele mõeldud töövahend juhendamise läbiviimiseks ja selle toimumise fakti
tõendamiseks. Võimaldab hallata juhendatud töötajate nimekirja ja planeerida uusi juhendamisi.
• Tervisekontroll – ettevõtetele mõeldud töövahend töötajate tervisekontrollide haldamiseks, mis
võimaldab ka TI inspektoril veenduda tervisekontrollide toimumises.
• Infoportaal – kasutajate teavitamiseks mõeldud informatiivne portaal, kus kuvatakse ka uuemat
analüütikat valdkondliku olukorra kohta.
2.3 Kasutatav metoodika
Käesolev analüüs viidi läbi perioodil jaanuar - aprill 2018 ja see keskendus TI järelevalvemenetluse ja tööandja
riskianalüüsi protsessile ning infotehnoloogilise lähteülesande väljatöötamisele.
PwC 18
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Analüüs viidi läbi kolmes etapis:
1. Esimeses etapis toimus sisendinfo kogumine ja intervjuude läbiviimine (vt Intervjueeritavad). Selle etapi
käigus koguti kokku peamine info hetkeolukorra ja tulevikuvisiooni kohta. Samuti koostati erinevad
andmepäringud kvantitatiivsete andmete kogumiseks.
2. Teises etapis toimus arenduse lähteülesande koostamine ja selgitati välja, millised funktsionaalsed ning
mittefunktsionaalsed nõuded uuele tööelu infosüsteemile vajalikud on. Seejärel oli võimalik välja
selgitada ligikaudne arendustööde maksumus.
3. Kolmandas etapis koostati arenduse lähteülesandele mahuhinnang ja tegevuskava. Selle etapi käigus
küsiti vastavalt koostatud lähteülesandele tarkvaraarenduse ettevõtetelt hinnapakkumised uue tööelu
infosüsteemi arendusele.
Analüüs keskendus järgmistele protsessidele:
• Tööandja riskianalüüsi protsess.
• TI järelevalvemenetluse tööprotsess.
• Kutsehaigestumise, tööst põhjustatud haigestumise ja tööõnnetuse menetlemise alamprotsessid.
Intervjuude käigus arutati järgnevaid teemasid:
• Riskianalüüsi ja järelevalve tööprotsesside kirjeldus.
• Riskianalüüsi ja järelevalve tööprotsesside problemaatika ja kitsaskohad.
• Riskianalüüsi ja järelevalve tööprotsessides kasutatavad infosüsteemid.
• Töökeskkonnaga seotud osapooltele õiguste andmine.
• Tööst põhjustatud haigestumiste menetlemine
• Kutsehaiguste menetlemine.
• Tööõnnetuse menetlemine.
• Visioon nimetatud protsesside ümberkujundamiseks.
Protsesside kirjeldamine - Protsessikaardid on koostatud BPMN notatsioonis kasutades Bizagi 20 vabavara.
Protsessikaartidel on kajastatud täitja (rolli) sissetulevad andmed, menetluskäigud, väljundandmed ja seotud
andmebaasid. Protsessivoo kirjeldamisel oleme kasutanud Business Process Model and Notation formaati.
Protsessikaartidel kajastatud sümbolite tähendused on kirjeldatud Bizagi vabavara kasutusjuhendis 21.
IT arenduse lähteülesanne koosneb kahest osast: 1) funktsionaalsed nõuded (sh rollid ja kasutuslood) ja 2)
mittefunktsionaalsed nõuded.
IT arenduse lähteülesande funktsionaalsed ja mittefunktsionaalsed nõuded on kirjeldatud kasutades Rational
Unified Process raamistiku nõuete analüüsi FURPS+ mudelit 22. Selle komponendid on funktsionaalsus,
kasutatavus, töökindlus, jõudlus ja paindlikkus ning muud nõuded. Lähteülesande koostamiseks on piisav
nõuete ja andmestruktuuri loogiline kontseptuaalne vaade. Tulemused on kirjeldatud detailsuses, mis
võimaldab arendajal läbi viia vajalikud arendustööd. Samuti on need piisavalt täpsed, mille põhjal erinevad
ettevõtted saavad hinnata arenduse maksumust.
Kasutuslood on UML kasutuslugude diagrammidena välja toodud iga rolli jaoks. Samuti on kirjeldatud kõikide
kasutuslugude kohta vastavad nõuded ning ärireeglid neid läbivate persoonide vaatepunktist. Iga kasutusloo
protsess ja selle reeglid on kirjeldatud vabatekstilises vormis lühikirjeldusena.
20 Bizagi BPM Modelerhttps://www.bizagi.com/en/products/bpm-suite/modeler
21 Bizagi kasutusjuhend http://download.bizagi.com/docs/modeler/2511/en/Modeler_user_Guide.pdf - LK 38
- 48
22 Wikipedia sub FURPS https://en.wikipedia.org/wiki/FURPS
PwC 19
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3 Tulevaste äriprotsesside
kirjeldused TO-BE
Käesolevas peatükis vaadeldakse tööandjapoolset riskianalüüsi koostamise ja TI järelevalvega seotud protsesse.
Analüüsi tellijapoolne otsus oli hetkeolukorda (AS-IS) mitte kirjeldada ja seetõttu keskenduvad protsesside
kirjeldused ainult tulevikuvaatele (TO-BE).
Esmalt on kirjeldatud protsesside üldine tervikvaade ja seejärel antakse detailsem ülevaade teistest
protsessidest. Protsesse vaadeldakse üheksa erineva protsessiskeemina:
1. Üldprotsess.
2. Töökeskkonnaga seotud osapoolte õiguste määramine.
3. Riskianalüüsi korraldamine.
4. Automaatkontrolli läbiviimine.
5. Kontaktivaba järelevalve läbiviimine.
6. Kontaktjärelevalve läbiviimine.
7. Tööst põhjustatud haigestumise menetlemine.
8. Kutsehaigestumise menetlemine.
9. Tööõnnetuse menetlemine.
3.1 Üldprotsess
Järelevalve ja riskianalüüsi protsesside (vt Joonis 4) kaks peamist osapoolt on TI ja tööandja. Tööandjal on
vastavalt seadustele kohustus tagada oma ettevõttes töökeskkonna ohutus ja TI-l teostada tööandja üle
järelevalvet.
Tööandjal tuleb oma töökeskkonna ohutuse tagamiseks läbi viia ettevõtte riskianalüüs. Enne riskianalüüsi
koostamist võib tööandja oma ettevõttes määrata inimesed, kes ohutu töökeskkonna eest vastutavad ja anda
neile infosüsteemis õigused.
Järelevalve ja riskianalüüsi kõikide osapoolte tegevused sh õiguste määramised toimuvad uues tööelu
infosüsteemis. Protsessid on kirjeldatud viisil, mis eeldab nende läbiviimiseks uue infosüsteemi olemasolu.
TI-l on järelevalve tegemiseks kolm võimalust, mis on kirjeldatud pikemalt vastavates alapeatükkides:
1. Automaatne kontroll, mis teostatakse infosüsteemi poolt erinevate automaatkontrollidega ning mille
eesmärk on puuduste tuvastamine ettevõtte töökeskkonna korralduses. Inspektori töökoormus puudub.
Sellist tüüpi kontroll on esmane vahend tuvastamaks ettevõtteid, kus inspektor jõuab eelanalüüsi käigus
seisukohale, et ettevõte töötervishoiu ja tööohutuse juhtimisega pigem soovib tegeleda. Need ettevõtted,
kellel selles etapis puudusi tuvastatakse, liiguvad edasi sõltuvalt rikkumise olulisusest kontaktivabasse
järelevalvesse või kontaktjärelevalvesse.
2. Kontaktivaba järelevalve, kus inspektor teostab ettevõtte järelevalvet ainult tööelu infosüsteemis,
kasutades juba infosüsteemis olevaid andmeid või küsides neid infosüsteemi kaudu juurde. Inspektori
töökoormus on vähene ja puudub otsene vajadus ettevõtet kontrolli käigus külastada. Sobilik eelkõige
ettevõtete kontrollimiseks, kus riskid on pigem madalad ja töökeskkonna ohutuse juhtimisega aeg-ajalt
tegeletakse. Kontaktivaba järelevalvet on võimalik rakendada ka mitmete sihtkontrollide osas.
3. Kontaktjärelevalve, kus inspektor külastab ettevõtet järelevalve läbiviimiseks. Inspektori töökoormus on
suur. Kontaktjärelevalvet rakendatakse ettevõtetele, kus riskid on suuremad ja eksisteerib varasemaid
töökeskkonna rikkumisi , tööõnnetusi, kutsehaigestumisi või tööst põhjustatud haigestumisi. Lisaks
rakendatakse seda järelevalvet ohuhinnangust lähtuva valimi peal ja ka kindlate sihtkontrollide osas.
PwC 20
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Joonis 4. Järelevalve ja riskianalüüsi üldprotsess
Joonisel kujutatud tegevused sisaldavad ainult käesoleva analüüsi kontekstis kirjeldatud protsesse. Hilisemate
analüüside ja arenduste käigus lisandub täiendavaid protsesse ja tegevusi.
PwC 21
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3.2 Töökeskkonnaga seotud osapoolte õiguste määramine
Töökeskkonnaga seotud osapoolte õiguste andmine (vt Joonis 5) käib tööelu infosüsteemis ja sellel protsessil on
sõltuvalt ettevõtte suurusest 4-7 erinevat osapoolt:
1. ettevõtte juhatuse liige;
2. TK-spetsialist;
3. TK-volinik;
4. TK-nõukogu liikmed;
5. TK-esmaabiandja;
6. töötajate usaldusisik;
7. ettevõtte töötaja.
Protsessi keskne roll on TK-spetsialistil, kellele on määratud vastavad õigused ja kelle ülesandeks on tagada
ettevõttes ohutu töökeskkond. TK-spetsialisti määramise protsessi saab algatada kas ettevõtte juhatuse liige või
ettevõtte töötaja, kes soovib seda rolli endale taotleda. Taotlemise protsess on võimalikult lihtne. Rolli
taotlemiseks või andmiseks tuleb osapoolel tööelu infosüsteemi sisse logida. Sisse logimisel saab kasutaja
valida, millise rolliga ta sisse soovib logida. Näiteks inimene, kes on ühes ettevõttes juhatuse liikmeks ja teises
töötajaks, saab valida, kas ta soovib sisse logida oma ettevõtte esindajana või teise ettevõtte töötajana. Ettevõtte
töötaja peab esmalt sisse logima eraisikuna ja seejärel näeb ta infosüsteemis, milliste ettevõtetega ta seotud on.
Seejärel saab ta sobiva ettevõtte valimisel TK-spetsialisti rolli taotluse esitada.
Ettevõtte juhatuse liige on infosüsteemis oma ettevõtte puhul n-ö peakasutaja, kes saab ka vajadusel oma
ettevõttega seotud vajalike rollide õiguseid määrata ja rolle hallata. Samuti peab saama jaotada ettevõtte
filiaalideks (erinevateks tegevuskohtadeks), et igas kohas määrata õigusi ja rolle.
TK-spetsialistil on infosüsteemis õigus määrata:
1. uus TK-spetsialist (nt kui loobub rollist või lahkub töölt) (sh väline teenusepakkuja saab infosüsteemis
TK-spetsialisti rolli);
2. TK-volinik (kohustuslik üle 10 töötajaga ettevõtte puhul);
3. TK-nõukogu liikmed (kohustuslik üle 150 töötajaga ettevõttes);
4. TK-esmaabiandja;
5. Töötajate usaldusisik.
Vajadusel saab määrata ka teisi TK-spetsialiste (nt suurettevõtted). TK-spetsialistiks saab määrata ka ettevõtte
välise teenusepakkuja nt riskianalüüsi koostamiseks.
Tööelu infosüsteem on õiguste andmiseks liidestatud töötamise registriga (TÖR). Kõikide töökeskkonnaga
seotud osapoolte õiguste andmised käivad läbi tööelu infosüsteemi ja on isikukoodi põhised, st vajaliku
osapoole määramisel tuleb sisestada isikukood ja süsteem tuvastab TÖR-i kaudu infopäringut tehes
automaatselt kõik isikukoodiga seotud info, sh kontaktandmed.
Infosüsteemis õiguse määramisel saadetakse inimesele sellekohane teavitus e-posti teel ja suunatakse ta tööelu
infosüsteemi sisse logima. Infosüsteemi sisse logimisel kuvatakse neile uue määratud rolli kohta info ja
küsitakse rolli vastuvõtmise kinnitust.
Kui töötamise registrisse tehakse muudatuse kanne, nt määratud õigustega isik lahkub töölt, siis eemaldatakse
ka tööelu infosüsteemis senise ettevõttega seotud õigused ja rollid ning infosüsteem informeerib TK-spetsialisti
või ettevõtte juhatuse liiget. Muudel juhtudel, sh ettevõttevälistele kolmandatele osapooltele õiguste andmisel
jääb vastutus TK-spetsialisti või ettevõtte juhatuse liikme kanda, et õigel hetkel õigused infosüsteemist
eemaldatakse (nt riskianalüüsi valmimisel). Isikul säilivad tema isikuga seotud otsesed seosed – tööõnnetuste,
tööst põhjustatud haigestumiste ja kutsehaigestumiste info.
PwC 22
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Joonis 5. Töökeskkonnaga seotud osapoolte õiguste määramine
PwC 23
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3.3 Riskianalüüsi korraldamine
Riskianalüüs on tegevus, millega tööandja selgitab välja ja hindab töökeskkonna ohutegureid, mis
töökeskkonnas esinevad ja võivad töötajaid ning kliente kahjustada. Näiteks ebapiisav valgustus, sundasendis
töötamine, kokkupuude kemikaalide või pideva müraga. Riskianalüüsi tegemine on tööandjale seadusega
kohustuslik.
Joonis 6. Riskianalüüsi korraldamine
3.3.1.1.1 Tööandja töölaua kirjeldus
Tööandja töölaua riskianalüüsi vaates kuvatakse tööandja esindajale järgnevat infot:
• Ülevaade, millises olukorras on tema töökeskkond nõuetele vastavuse osas – n-ö foori tüüpi lahendus,
kus roheline staatuse korral on kõik korras, kollane staatus vajab täiendavaid tegevusi ja punane
töökeskkond ei ole korras.
• Tegevuste nimekiri, mida tuleb teha töökeskkonna vastavuses hoidmiseks või vastavusse viimiseks – (nt
TK-spetsialist või TK-volinik määrata, viia läbi riskianalüüs, uuendada riskianalüüs).
• Töötajale määratud ülesanded ja tähtajad – tulenevad riskianalüüsi tegevuskavast.
• Kvantitatiivsed ettevõtet puudutavad andmed.
3.3.1.1.2 Tööandja riskianalüüsi vaade
Riskianalüüs viiakse läbi tööelu infosüsteemis (vt Joonis 6) riskianalüüsi moodulis viisardipõhisele 23
kontrollküsimustikule vastamisega ja selle läbiviimise eelduseks on see, et tööandja on tööelu infosüsteemis
vajalike õigustega määranud TK-spetsialisti, kes riskianalüüsi läbi viib või jagab RA läbiviimiseks laiali
ülesanded meeskonnale. TK-spetsialist on vastutav riskianalüüsi tulemuste eest.
Riskianalüüsi läbiviimine infosüsteemis on tööandjale võimalikult lihtne ja selgesti arusaadav. Tal on võimalik
riskianalüüsi tegemine pooleli jätta ja sobival hetkel jätkata. Tal on igal hetkel süsteemi sisse logides teada,
millises etapis või staatusega tema ettevõtte riskianalüüs on. Lihtne viisardipõhine lähenemine ja
23 Interaktiivne abivahend, mis aitab kasutajal teha keerukamaid operatsioone. Sisuliselt tagab see riskianalüüsi
tegemist samm sammult ja terviklikult.
PwC 24
Tööelu infosüsteemi eelanalüüs Lõpparuanne
kasutusloogika võetakse üle Iirimaa Tööinspektsiooni (Irish Health and Safety Autohority) loodud
riskianalüüsi portaalist BeSMART 24 ja kohandatakse Eestile sobivaks.
Riskianalüüsi korraldamise protsess algab tööelu infosüsteemis ettevõtte tüübi ja tegevusala valimisega. Tüübi
ja tegevusala valimine toimub EMTAK koodi 25 põhjal. Lisaks on võimalus teostada märksõnapõhine otsing.
Järgmisena valitakse ettevõtte tegevuskoht, kus rakendatakse filiaalipõhist lähenemist. Kui tegemist on
suurema ettevõttega, millel on mitu tegutsemise kohta (nt AS Selver), siis kuvatakse TK-spetsialistile kõik
filiaalid (tegutsemiskohad) ja tal on võimalus iga koha kohta teha eraldi riskianalüüs. Iga filiaali kohta võib luua
riskianalüüsi läbimisel oma riskiprofiili. Sarnast filiaalipõhist loogikat saab soovi korral kasutada ka läbi
erinevate osakondade defineerimise, kus igale osakonnale saab eraldi riskianalüüsi koostada.
Pärast ettevõtte tegevuskoha valimist kuvatakse valitud ettevõtte tüübile vastavad standardsed riskimoodulid
(vt BeSMART restorani näidet Joonis 7 ja Joonis 8). Toidu jaemüügiga tegeleva ettevõtte näitel kuvatakse
standardne poe riskimoodul. Need riskimoodulid on soovituslikud riskid, mis võivad (kuid ei pruugi)
konkreetsele ettevõtte tüübile vastata. TK-spetsialist saab neid ükshaaval eemaldada või vajadusel täiendavaid
riskimooduleid juurde lisada. Iga riskimooduli kohta tuleb TK-spetsialistil vastata lihtsate JAH/EI vastustega
küsimustele riskide maandamisabinõude kohta ettevõtte tegevuskohas (vt Joonis 8). Kui mõne abinõu puhul
vastatakse EI, siis tuleb lisada põhjendus, miks see abinõu ettevõttele ei sobi või ei ole vajalik.
Riskimoodulid peavad olema kavandatud nii, et vajaduse korral saab nende juures tulevikus minna
isikupõhiseks ehk märkida ettevõtte töötajad, keda mingi oht puudutab. Sellisel juhul on võimalik arendada
uusi teenuseid seoses juhendamise ja tervisekontrolliga (nt tervisekontrolli jaoks peab arst teadma, mis
ohtudega töötaja kokku puutub).
Joonis 7. BeSMART riskianalüüsi viisardi näide
24 BeSMART https://www.besmart.ie/
25 EMTAK klassifikaatori otsing https://emtak.rik.ee/EMTAK/pages/klassifikaatorOtsing.jspx
PwC 25
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Kui kõikidele riskimoodulitele on vastatud, siis genereeritakse infosüsteemis tegevuskava riskide maandamiseks
(nt tuleb välja ehitada ventilatsioon või parandada valgustust). TK-spetsialist lisab tegevustele vastutajad ja
tähtajad. Tegevuskava tuleb TK-spetsialistil kinnitada. Tegevuskaval on maandamismeetmete (abinõude)
rakendamisel määratud vastutaja ja tähtaeg. Kui maandamismeetmeid (abinõusid) ei rakendata, siis on
ettevõtte tegevuskoha profiil punane ja TI inspektor tunneb ettevõtte vastu suuremat huvi.
Joonis 8. BeSMART riskianalüüsi viisardi maandamismeetmed
Peale riskianalüüsi ja tegevuskava kinnitamist saadab süsteem selle kohta teate juhatuse liikmele. Vajadusel
saab tegevuskava ja riskianalüüsi genereerida vormis, mis võimaldab selle välja printida TK-spetsialist saab
tutvustada riskianalüüsi tulemusi ja tegevuskava ettevõtte siseselt kõigile töötajatele (sh TK-volinikule, TK-
nõukogu liikmetele jne) Tutvustamist saab teha nii infosüsteemi kaudu, e-posti teel või ka koosoleku vormis.
Juhatuse liikmel ja TK-spetsialistil avaneb igal ajahetkel infosüsteemi sisse logides lihtne ja loogilise
ülesehitusega töölaud. Töölaual on selged ja lihtsad visualiseeritud numbrilised indikaatorid ja staatus tema
ettevõtte kohta, teavitused ja vajalike tegevuste nimekiri.
3.3.1.1.3 TI inspektori infosüsteemi vaade
TI inspektorile avaneb infosüsteemi järelevalve moodulisse sisse logides lihtne ja loogilise ülesehitusega
töölaud. Töölaual on inspektoril nimekiri järelevalve subjektidest ja nende staatusest. Subjekte on võimalik
filtreerida ja analüüsida vastavalt nende staatusele. Staatusena kasutatakse lihtsat foori tüüpi lahendust:
1. roheline (automaatkontroll, riskianalüüs on korras);
2. kollane (kontaktivaba järelevalve võimalus);
3. punane (kontaktivaba või kontaktjärelevalve).
Selline lähenemine võimaldab inspektoril keskenduda ainult olulisele ja tähelepanu vajavatele (punase
staatusega) ettevõtetele ja suunata suurim pingutus sinna.
Inspektor ei saa vabalt infosüsteemis erinevate järelevalve subjektide riskianalüüsiga tutvuda. Vajalikud õigused
antakse infosüsteemi poolt siis, kui inspektor alustab järelevalve menetlust näiteks mõne punases oleva
ettevõtte suhtes.
PwC 26
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3.4 Järelevalve protsessid
TI korraldatava järelevalve eesmärk on tagada ohutu, turvaline ja tervislik töökeskkond ning õigusaktide
nõuetele vastavad töösuhted.
Kõikidele järelevalveprotsessi osapooltele on uue tööelu infosüsteemi kaudu järelevalve protsessis osalemine
võimalikult lihtne, kergesti arusaadav ja kiire. Osapooli toetavad automaatsed ja poolautomaatsed
(kontaktivabad) kontrollid ja paberivaba menetlemine. Märksõnadeks on veel andmete taaskasutamine, lihtne
omavaheline suhtlus inspektori ja ettevõtja vahel ning vähene halduskoormus.
Ettevõtetele on oluline anda uuele järelevalve süsteemile üle minemiseks üleminekuaeg, mille jooksul tuleb teha
laiaulatuslikku teavituskampaaniat.
Järelevalve käigus toimuvat suhtlust TI inspektori ja ettevõtja vahel peab toetama Tööelu infosüsteemi lisatud
teadete vahetamise funktsionaalsus, millest tekib osapooltele ülevaatlik struktureeritud vestlus. Mõlemale
osapoolele on vestluse kulg ja selle ajalugu lihtsasti leitav. Kogu menetluse jaoks vajalik info on alati
tsentraalselt ühes kohas. Selline lähenemine aitab mõlemal osapoolel aega kokku hoida. Väheneb vigade
tekkimise võimalus nt e-kiri ei jõudnud osapoolele kohale (liiga suur manus, läks rämpsposti jne) või esines
infokadu (nt oluline e-mail kustutati serverist).
Kõikidele järelevalveprotsessi osapooltele on infosüsteemis kasutusel lihtne töölaud, kuhu on kokku koondunud
just neile vajalik info. Kogu osapoolte omavaheline suhtlus protsessi algusest lõpuni käib teadete vahetamisega
tööelu infosüsteemis.
Järelevalve on peamiselt kahte tüüpi – üldine või sihtkontroll.
Üldkontroll on asutuse või selle territoriaalselt eraldatud struktuuriüksuse (edaspidi ettevõtte) töötervishoiu,
tööohutuse ja töösuhete õigusaktidest tulenevate nõuete täitmise kontrollimine, mille käigus kontrollitakse ja
hinnatakse ettevõtte töökeskkonna seisundit, tööandja tegevust töökeskkonnaalase töö, töösuhete ning töö- ja
puhkeaja korraldamisel. Võib toimuda ka viisil, kus tööandjat kontrolli toimumisest ette ei teavitata.
Sihtkontroll on järelevalve liik, mille käigus teostatakse kontrolli piiritletud subjektide või objektide suhtes, st
sihtkontrolli käigus kontrollitakse ettevõttes töösuhete, töötervishoiu ja tööohutuse õigusaktide nõuetest
kinnipidamist eelnevalt kindlaksmääratud töökeskkonna valdkondades. Sihtkontroll võib toimuda nii kindla
valdkonna või kindla üksikjuhtumi (ettevõtte) osas. Võib toimuda ka viisil, kus tööandjat kontrolli toimumisest
ette ei teavitata.
Seire on järelevalve liik, kus inspektor oma piirkonnas liigub ringi ja tuvastab ettevõtte, kus töökeskkonnaga ei
tundu kõik korras olevat või näiteks kui külastatakse piirkonnas mõnda ehitusobjekti ja pärast vestlust
objektijuhiga tuvastatakse puudused. Seire toimumine registreeritakse ja kui asi menetlusse võetakse siis
algatatakse üldkontroll või sihtkontroll.
Järelevalve ja sihtkontrolli võib viia läbi nii ettevõttega otse kontaktis olles kui ka kontaktivabalt.
Järelevalve läbiviimise protsessis on olulisel kohal sellele eelnev sisendinfo. Järelevalve protsessi võivad
käivitada välised sündmused nt saabub inspektorile vihje või kaebus, mille põhjal otsustatakse järelevalve
algatamine. Juhul kui kontrolli aluseks on kaebus või vihje, siis ei avalikusta inspektor kontrollitavale
ettevõttele kaebuse või vihje sisu ega selle esitajat
Ettevõttes kohapeal kontrolli teostamisel koostab inspektor kontrolli protokolli (vt Kontrolli protokolli
koostamine), millele märgitakse kontrolli eesmärk, teostatud toimingu ja avastatud rikkumised. Avastatud
rikkumistena saab protokolli kirja panna ainult need avastatud rikkumised, mille osas TI-l on järelevalve
pädevus.
Kui ettevõte ei likvideeri tuvastatud rikkumisi inspektori määratud tähtajaks, siis inspektor otsustab, kas teha
ettekirjutus ja selle käigus ka sunniraha rakendamise hoiatus. Sunniraha hoiatus tehakse infosüsteemis nende
PwC 27
Tööelu infosüsteemi eelanalüüs Lõpparuanne
rikkumiste kõrvaldamiseks, mille puhul võib eeldada, et ettekirjutuses toodud kohustused jäetakse tähtajaks
täitmata. Inspektor võib teha korduvalt sunniraha hoiatusi ja rakendada sunniraha kuni ettekirjutusega
taotletava eesmärgi saavutamiseni. Kui otsustatakse rakendada sunniraha, siis see vormistatakse kohe
ettekirjutuses. Ettekirjutus koostatakse ainult selle õigusakti sätte rikkumise kõrvaldamiseks, mille üle TI-l on
seadusest tulenev järelevalve pädevus. Sunniraha määramise protsessis on infosüsteem liidestatud TARN 26
infosüsteemiga, millest saadakse andmed TI poolt määratud sunnirahade ning väärteokaristuste sundtäitmise
kohta. TARN on täitemenetlusregistri alaminfosüsteem.
Kui avastatud rikkumine on väga ohtlik, võib järgneda inspektori poolt ka väärteomenetluse algatamine koos
trahvi määramisega. Väärteomenetluse läbiviimine ei peata ega katkesta järelevalvemenetlust, st väärteo- ja
järelevalvemenetlus võivad kulgeda samaaegselt. Väärteomenetlus peatub kriminaalmenetluse alustamise ajaks
(nt kui on juhtunud surmaga lõppenud tööõnnetus). Väärtegusid menetletakse eraldi politsei infosüsteemis.
Tööelu infosüsteemi jääb märge väärteomenetluse alustamise kuupäevast, alusest ja otsusest ning politsei
infosüsteemist võetakse automaatselt andmed TI kui kohtuvälise menetleja poolt läbi viidud ja TI-ga seotud
kohtumenetluste kohta. Kuna väärtegusid menetletakse eraldi politsei infosüsteemis, siis käesolevas analüüsis
seda detailselt ei käsitleta.
Ettevõte saab ka ise TI-d neile kohapeale kontrollima kutsuda, näiteks sisestab ehitusettevõte andmed
ehitamise alustamisest ehitisregistrisse ja sealt saadetakse automaatselt TI-le teade. Uue või rekonstrueeritud
ehitise ülevaatuse käigus kontrollib TI seal töötingimuste vastavust töötervishoiu ja tööohutuse nõuetele. Taolist
ülevaatust teostatakse kohaliku omavalitsuse taotlusel või juhul, kui ettevõte ise on andnud TI-le sellekohase
teavituse. Tulevikus ei pea ettevõte enam käsitsi ehitisega seotud andmeid topelt sisestama, vaid andmed, mis
sisestati ehitisregistrisse 27, saadetakse automaatselt TI-le läbi ehitisregistri andmebaasi liidestuse. Samuti saab
TI läbi ehitisregistri automaatselt andmed kavandatava või ehitatava ehitise asukoha ja nendega seotud isikute
kohta.
Järelevalve protsessi käigus kasutatakse infosüsteemis erinevaid templiite, mille kaudu ettevõte läbi tööelu
infosüsteemi TI-ga suhtleb ja teatiseid esitab. Näiteks teavitab ettevõte TI-d tööõnnetuse toimumisest või
edastab lähetatud töötaja või alaealise töötamise kohta info. Alaealise töötamise info võetakse automaatselt
töötamise registrist.
Ettevõte saab TI-lt tellida ka konsulteerimise ja nõustamise teenust, mis on reguleeritud TI nõustamisteenuse
töökorraga. Teenuse tellimisel registreerib inspektor infosüsteemis uue nõustamise (infosüsteemis on
nõustamine lisatud ühe järelevalve liigina) ja ettevõttele läheb teavitus uue nõustamisteenuse alustamisest. TI
poolt saadetakse seejärel konsultant (infosüsteemis roll TI inspektor) teda nõustama. Nõustamine toimub
peamiselt individuaalnõustamise vormis. Inspektor märgib peale teenuse osutamist infosüsteemi märke
teenuse osutamise kohta ja lisab detailid nõustamise valdkonna kohta. Nõustada saab ka ilma ettevõttesse
kohapeale minemata nt kasutada infosüsteemis sõnumite vahetamist.
Ohuhinnangu põhjal valimi koostamine
Järelevalve subjektid valitakse välja ohuhinnangu alusel – ehk siis määratakse ettevõtete riskitase.
Ohuhinnangu arvutamiseks on vajalikud järgnevad atribuudid:
• Riskianalüüs on tehtud ja uuendatud.
• TK-spetsialist on määratud.
• TK-volinik on määratud, rakendub alates 10 töötjatega ettevõtete puhul.
• TK-nõukogu liikmed on määratud, rakendub alates 150 töötjatega ettevõtete puhul.
• Ettevõttes toimunud tööõnnetuste arv.
• Ettevõttes toimunud tööst põhjustatud haigestumiste arv.
• Ettevõttes toimunud kutsehaigestumiste arv.
• Ettevõtte töövaidluste arv.
• Tööinspektori viimane külastus ettevõttesse.
• Ettevõtte varasemate rikkumiste arv.
26 TARN infosüsteem - https://www.riha.ee/Infos%C3%BCsteemid/Vaata/tarn
27 Ehitisregister - https://www.ehr.ee
PwC 28
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Ettevõttele tehtud varasemate ettekirjutuste arv.
• Ettevõtte vastu algatatud väärteomenetluste arv ja sunniraha määramiste arv.
• TI konsultatsiooni teenuse kasutamine.
• Ettevõtte töötajate arv.
• EMTAK tegevusala ohtlikkuse hinnang.
Erinevatele atribuutidele antavad kaalud ja ohuhinnangu koostamise valem töötatakse välja detailanalüüsi
faasis. Ohuhinnangu koostab infosüsteem kord aastas või tihedamini automaatselt TI poolt defineeritud ajal.
Järelevalve valdkonna eest vastutava juhi nõusolekul võib ohuhinnangut uuendada. Ehk siis lasta infosüsteemil
ohuhinnangud ümber arvutada. Ohuhinnangu põhjal koostatud valimi jagab Tööelu infosüsteem kord kvartalis
inspektorite vahel võttes arvesse tööpiirkondi. Sihtkontrollide läbiviimiseks saab infosüsteemil lasta koostada
ka väiksem valim tuginedes mingile kindlale atribuudile (nt EMTAK koodi põhjal valida välja ehitusettevõtted).
3.4.1 Automaatkontrolli läbiviimine
Automaatjärelevalve ehk infosüsteemi pool teostatav järelevalve võimaldab kõikidel protsessi osapooltel
saavutada suurema ressursside kokkuhoiu (vt Joonis 9). Automaatse järelevalve läbimise eelduseks on
riskianalüüsi tegemine uues tööelu infosüsteemis ja ettevõttes selleks vajalike rollide (nt TK-spetsialisti)
määramine.
Selleks, et oleks võimalik piirduda ainult automaatse järelevalvega läbiviimisega tuleb automaatne järelevalve
siduda ettevõtte riskitaseme ja selle arvutamisega. Riskitaseme arvutamisel võetakse arvesse mitmeid aspekte ja
statistikat (nt varasemad tööõnnetused, tööst põhjustatud haigestumised, töövaidlused jne).
Mida suurem on tööandjate hulk, kes automaatse järelevalve läbivad, seda suuremad
võidud ja kokkuhoiu saavutab riik sh Tööinspektsioon.
Automaatse järelevalve korral teostab infosüsteem tööandjate suunal lihtsad kontrollid ja koostab päringute
põhjal tööandjale fooripõhise staatusega profiili:
1. Roheline staatus (automaatjärelevalve läbitud, inspektor ei tunne huvi, inspektori sekkumist ei ole vaja).
Teatud regulaarsusega nt korra aastas tuleb mingi osa rohelise staatusega ettevõtetest võtta juhuvalimiga
lisakontrolli, et kontrollida andmete korrektsust. Kui näiteks selgub, et andmeid on manipuleeritud, saab
rakendada nende suunal väärteomenetlust.
2. Kollane staatus (kontaktivaba või kontaktjärelevalve võimalus, inspektori vähene huvi, inspektor otsustab
sekkumise vastavalt ettevõtte ohuhinnangule).
3. Punane (kontaktivaba või kontaktjärelevalve võimalus, inspektori suur huvi, inspektor otsustab
sekkumise vastavalt ettevõtte ohuhinnangule).
Kontrollid, mida infosüsteem tööandja suunal teostab:
1. Milline on tööandja riskianalüüsi staatus (korras, aegunud, puudub).
2. Tööandja töökeskkonna tegevuskava olemasolu, selle kvaliteet ja kava täitmise kontrollimine.
3. Tööst põhjustatud haigestumise statistika.
4. Tööõnnetuste statistika.
5. Kutsehaiguste statistika.
6. Kas TK-spetsialist, TK-volinik (üle 10 töötajaga ettevõte) ja TK-nõukogu (üle 150 töötajaga ettevõte) on
määratud.
7. Kas töötaja on läbinud juhendamised ja tutvunud ohutusjuhenditega (eelduseks on tulevikus loodav
tööelu infosüsteemi juhendamise moodul).
8. Kas töötajate tervisekontrollid on läbitud (läbi liidestamise e-tervise infosüsteemiga). (Tervisekontrolli
moodul on tööelu infosüsteemi tulevikuarendus, mida selles analüüsis detailselt ei käsitleta).
9. Regulaarne (nt korra kvartalis) töökeskkonna ohutuse sisekontroll.
PwC 29
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Joonis 9. Automaatjärelevalve läbiviimine (sh juhendamise moodul, mis realiseeritakse hilisema arenduse käigus)
Tööõnnetuste, kutsehaigestumiste ja tööst põhjustatud haigestumiste statistika korral peab TI infosüsteemi
detailanalüüsi faasis määrama nende seosed fooripõhise staatusega. Näiteks mitu tööõnnetust viimase aasta
jooksul määrab tööandjale automaatselt punase staatuse.
Ohuhinnangu koostamisel võetakse valimisse ka teatud protsent ettevõtteid, kes automaatse kontrolli käigus on
saanud rohelise staatuse. Seeläbi valideeritakse, et sisestatud andmed on õiged ja rohelises staatuses ettevõtted
tegelevad töökeskkonna ohutuse juhtimisega.
PwC 30
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3.4.2 Kontaktivaba järelevalve läbiviimine
Kontaktivaba järelevalve peamine eesmärk on sarnaselt automaatjärelevalvele osapoolte halduskoormuse ja aja
kokkuhoid (vt Joonis 10). Sarnaselt automaatjärelevalve protsessile puudub ka siin inspektoril vajadus
järelevalve subjekti külastada. Kogu menetlus viiakse kõikidele osapooltele läbi tööelu infosüsteemis.
Järelevalve menetluse algatab inspektor infosüsteemis kollase või punase staatusega ettevõtte suhtes.
Järelevalve algatamisel antakse inspektorile infosüsteemi poolt õigused antud tööandjaga seotud infot näha. Kui
järelevalve on algatatud, siis läheb kõikidele osapooltele teavitus e-kirjaga menetluse toimumisest, mis suunab
osapooled tööelu infosüsteemi sisse logima ja teavitust lugema.
Inspektor defineerib ära enne teavituse saatmist, mis infot tal kontaktivaba järelevalve läbiviimise jaoks vaja on.
Tööandjal on siis infosüsteemis võimalik vajalikud andmed sisestada või üles laadida. Kui tööandja andmeid
teatud aja jooksul ei sisesta või dokumente üles ei lae, siis läheb tööandja automaatselt kontaktjärelevalvesse.
Kui tööandja sisestab infosüsteemi inspektorile vajaliku info, saab inspektor otsustada, kas esineb rikkumisi ja
vajadust kontaktjärelevalve jaoks. Inspektorile otsuse tegemiseks vajalikud andmed on järgnevad:
1. TK riskianalüüs ja selle kvaliteet;
2. tegevuskava;
3. tööohutusjuhendid (kuuluvad juhendamise moodulisse, mis on tulevikuarendus, mida selles analüüsis
detailselt ei käsitleta);
4. TK-spetsialistid;
5. TK-volinikud (vajadusel);
6. TK-nõukogu (vajadusel);
7. TK esmaabi andjad;
8. tervisekontrolli läbimise andmed (kuuluvad tervisekontrolli moodulisse, mis on tulevikuarendus, mida
selles analüüsis detailselt ei käsitleta);
9. ettevõtte ajalugu (sh TPH, KH ja tööõnnetused).
Kontrolli tulem on kontrolli protokoll, kus on kirjas andmed tuvastatud rikkumiste kohta ning info, millised
kontrollid läbi viidi ja kontrollis osalenud isikud. Kui kontrolli protokoll on koostatud, läheb ka tööandjale
teavitus protokolli koostamise kohta ja infosüsteemi sisse logides on tal võimalus sellega tutvuda. Kui
protokollis on kirjas rikkumised, siis on tööandjal võimalus esitada viie tööpäeva jooksul nende kohta
vastuväiteid.
Rikkumiste kõrvaldamisel sisestab tööandja infosüsteemi inspektorile analüüsimiseks tõendusmaterjali, peale
mida saab inspektor otsustada, kas teha ettekirjutus või mitte. Ettekirjutus on tööandjale esitatud kohustusliku
iseloomuga teavitus puuduste ja rikkumiste olemasolu kohta ettevõttes ning nõue nende kõrvaldamiseks.
Ettekirjutuse teeb inspektor tööelu infosüsteemi kaudu, mis saadab tööandjale ka sellekohase teavituse.
Ettekirjutuse tegemisele järgneb tõenäoliselt tööandja jaoks järelkontroll tulevikus, kui inspektor soovib
täielikult veenduda rikkumiste kõrvaldamises. Järelkontroll on käsitletav uue järelevalvemenetlusena.
Kui järelevalve menetlus algatatakse sõidukijuhi suhtes, siis saadab inspektor päringu konkreetse juhi kohta ja
tööandja saab infosüsteemi juhi ja sõiduauto logifailid üles laadida. Inspektor laeb failid oma arvutis olevasse
Tachoscani 28 sõidutarkvarasse ja teostab sellele kontrolli rikkumiste tuvastamiseks. Kui tööandja saadab
inspektorile paberkandjale skaneeritud sõidumeerikute koopiad, siis on nende lugemiseks inspektoril
spetsiaalne skänner.
Täisautomaatse kontrolli jaoks on eelduseks infosüsteemi liidestus Tachoscani enda serveriga, mida tänasel
päeval teadaolevalt ei eksisteeri, aga mille tekkimist ei saa tulevikus välistada. Sõidukijuhi andmed saab
infosüsteem töötamise registri liidestuse kaudu.
28 TachoScani ametlik maaletooja Ametikoolitus OÜ http://www.tachoscan.ee/
PwC 31
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Joonis 10. Kontaktivaba järelevalve läbiviimine
PwC 32
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3.4.3 Kontaktjärelevalve läbiviimine
Kontaktjärelevalve on kõige vähem eelistatud järelevalve liik järelevalve menetlemise protsessis (vt Joonis 11),
sest inspektor peab järelevalvesubjekti juurde kohale sõitma. Selline lähenemine on TI-le ressursikulukas ja
tööandjale koormav.
Kontaktjärelevalve menetluse algatab inspektor infosüsteemis kollase või punase staatusega ettevõtte suhtes,
kelle suhtes pole võimalik kontaktivaba menetlust kasutada. Lisaks võib ettevõtte tegevusvaldkonnast tuleneda,
et kontaktivaba järelevalve ei ole optimaalne.
Järelevalve algatamiseks valib inspektor tööelu infosüsteemis ettevõtte, kellele soovib järelevalvet teha ja
vajutab ettevõtte juures olevale nupule „alusta järelevalvet“. Seejärel antakse inspektorile infosüsteemi poolt
automaatselt õigused antud tööandjaga seotud detailsemat infot (nt riskianalüüs) näha. Kui järelevalve on
algatatud, siis läheb ettevõttele teavitus e-kirjaga menetluse alustamisest, mis suunab tööelu infosüsteemi sisse
logima.
Inspektor defineerib ära enne teavituse saatmist, mis infot tal kontaktjärelevalve läbiviimise jaoks vaja on.
Tööandjal on siis infosüsteemis võimalik vajalikud andmed sisestada või inspektorile tutvumiseks vajalikud
dokumendid infosüsteemi üles laadida. Selline lähenemine võimaldab osapooltel aega kokku hoida, sest
inspektor saab juba enne ettevõttesse kohapeale minemist andmetega tutvuda ja ei pea seda kohapeal tegema
ning tööandja saab vajalikud andmed enne inspektori visiiti välja otsida.
Kohapeal tööandja juures toimub inspektori poolt töökeskkonna vaatlus ja kontroll. Kontrolli läbiviimisel
kasutab inspektor tahvelarvutit, mis on ühendatud tööelu infosüsteemiga ja mis võimaldab täita ettevalmistatud
(universaalseid ja tegevusvaldkonna või sihtkontrolli fookuse põhiseid) küsimustikke ning protokolli.
Võimaldatud on ka tõendusmaterjali (nt pildi ja videomaterjal) üleslaadimise funktsioon. Tööinspektsioon saab
koostada järelevalve käigus kasutatavaid standardseid hinnangulehti.
Inspektoril on kohapeal õigus töö või töövahendi kasutamine peatada või keelustada, kui see töötaja tervise
seisukohalt vajalik on. Sellele ei eelne kontrollprotokolli koostamist, kuid selle kohta koostatakse akt (mis läheb
otse infosüsteemi).
Kontaktjärelevalve tulem on kontrollprotokoll, mida vajadusel on pärast ettevõttes kohal käimist kontoris
võimalik viimistleda. Kui kontrolli protokoll on infosüsteemis koostatud, läheb ka tööandjale teavitus protokolli
koostamise kohta ja infosüsteemi sisse logides on tal võimalus sellega tutvuda.
Kui protokollis on kirjas rikkumised, siis on tööandjal võimalus esitada viie tööpäeva jooksul nende kohta
vastuväiteid. Rikkumiste kõrvaldamisel sisestab tööandja infosüsteemi inspektorile analüüsimiseks
tõendusmaterjali, peale mida saab inspektor otsustada, kas teha ettekirjutus või mitte. Kõikide kontrollide
puhul toimub protokollis või ettekirjutustes märgitud puuduste kõrvaldamise kontroll. IS korrigeerib ettevõtte
kohta antavat hinnangut vastavalt. Ettekirjutuse tegemisele võib järgneda ka järelkontroll tulevikus.
PwC 33
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Joonis 11. Kontaktjärelevalve läbiviimine
PwC 34
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3.5 Tööst põhjustatud haigestumise menetlemine
Tööst põhjustatud haigestumine (TPH) on töökeskkonna ohuteguri põhjustatud haigus, mida ei loeta
kutsehaiguseks. TPH võib, kuid ei pruugi olla kutsehaigestumisele eelnevaks diagnoosiks. TPH diagnoositakse
valdavalt perioodiliste tervisekontrollide käigus, mida tööandjad on kohustatud korraldama vastavalt töötajate
tervisekontrolli korrale 29. Tihti diagnoositakse TPH ka erakorraliste arstivisiitide käigus, kui isik pöördub arsti
poole mingi vaevuse tõttu. TPH menetlemist reguleerib Tööõnnetuse ja kutsehaigestumise registreerimise,
teatamise ja uurimise kord 30.
TPH diagnoosib töötervishoiuarst. TPH menetlemise protsessides (vt Joonis 12, Joonis 13) on kolm osapoolt: 1)
töötervishoiuarst 2) patsient ja 3) tööinspektor. Menetlemine toimub protsessi algusest lõpuni tööelu
infosüsteemis, kus seotud osapooltele on määratud vajalikud õigused.
Töötervishoiuarst kasutab patsiendi andmete sisestamiseks e-tervise infosüsteemi, kus tuleb vastavad teenused
alles arendada (ei ole käesoleva analüüsi skoobis) ja liidestada tööelu infosüsteemiga. Andmete vahetamine ja
teadete edastamine infosüsteemide vahel käib edaspidi automaatselt.
Patsiendi ja tööandja info tuvastatakse läbi tööelu infosüsteemi liidestuse töötamise registri (TÖR) ja
äriregistriga.
Kui inspektor on teavituse kätte saanud ja selle menetlemiseks registreerib, võetakse automaatselt
töötervishoiuarsti sisestatud infost vajalikud andmed üle. Andmete korduvat sisestamist ei toimu. Olulised
andmed menetlusprotsessis on: 1) töötaja ja tööandja(te) andmed 2) diagnoosi nimetus 3) töökeskkonna
ohutegurid 4) töötaja amet ja tööstaaž ja 5) tööandja tegevusala. Seni kuni automaatne andmete vahetamine
puudub peab TI saama sisestada TPH teavituse käsitsi.
TPH registreerimisel infosüsteemis saadetakse sellekohane teavitus ka Terviseametile.
TPH korral on uurimine pigem erandlik ja üldjuhul seda läbi ei viida.
Eeldused:
• Protsessi peamiseks eelduseks on, et TEHIK arendab e-tervise infosüsteemis välja funktsionaalsuse tööst
põhjustatud haigestumiste registreerimiseks ja vastava info vahetamiseks Tööelu IS-iga.
• Juhtrühma hinnangul on tööst põhjustatud haigestumised hetkel alaregistreeritud, seda võrdluses
naaberriikidega. Protsessi kasu avaldumiseks on vaja, et meditsiini valdkonnas toimuks muudatused ja
rohkem tööst põhjustatud haigestumisi diagnoositaks ja registreeritaks.
29 Töötajate tervisekontrolli kord https://www.riigiteataja.ee/akt/1005703
30 Tööõnnetuse ja kutsehaigestumise registreerimise, teatamise ja uurimise kord
https://www.riigiteataja.ee/akt/105082014014
PwC 35
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Joonis 12. Tööst põhjustatud haigestumise menetlemine
PwC 36
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3.6 Kutsehaigestumise menetlemine
Kutsehaigus on haigus, mille on põhjustanud kutsehaiguste loetelus 31 nimetatud töökeskkonna ohutegur või töö
laad. Kutsehaigusele on valdavatel juhtudel iseloomulik aeglane, järkjärguline areng. Kutsehaigus on pikaajaline
tervisehäire (üldjuhul tervistumist ei toimu) ja tema põhiline põhjustaja on tööga seotud füüsikaline,
füsioloogiline, keemiline või bioloogiline ohutegur. Ühel inimesel võib samaaegselt olla ka mitu kutsehaigust.
TPH ja kutsehaigestumise menetlemist reguleerib Tööõnnetuse ja kutsehaigestumise registreerimise, teatamise
ja uurimise kord 32.
Kutsehaiguse diagnoosib töötervishoiuarst Põhja-Eesti Regionaalhaigla (PERH) Kutsehaiguste ja Töötervishoiu
keskuses. Töötervishoiuarst teeb kindlaks töötaja terviseseisundi ning kogub andmed töötaja praeguste ja
varasemate tööolude ning töö laadi kohta. Selleks nõuab töötervishoiuarst tööandjalt (tööandjatelt) töötaja
eelnevate tervisekontrollide otsused ja töökeskkonna riskianalüüsi tulemused ja töötajalt väljavõtte
tervisekaardist ja tööraamatust.
Kutsehaigestumise menetlemise protsessides (vt Joonis 13) on neli osapoolt: 1) töötervishoiuarst 2) tööandja 3)
patsient ja 4) tööinspektor. Menetlemine toimub protsessi algusest lõpuni tööelu infosüsteemis, kus seotud
osapooltele on määratud vajalikud õigused.
Töötervishoiuarst kasutab patsiendi andmete sisestamiseks e-tervise infosüsteemi, kus tuleb vastavad teenused
alles arendada (ei ole käesoleva analüüsi skoobis) ja liidestada tööelu infosüsteemiga. Andmete vahetamine ja
teadete edastamine infosüsteemide vahel käib automaatselt.
Menetlemise protsess (vt Joonis 13) algab tööelu infosüsteemis siis, kui töötervishoiuarst on kutsehaiguse
tuvastanud ja selle kohta e-tervise infosüsteemi andmed sisestanud. Sisestatud andmed saadetakse e-tervise
infosüsteemist automaatselt tööelu infosüsteemi. Seni kuni automaatne andmete vahetamine puudub peab TI
saama sisestada KH teavituse käsitsi. Tööelu infosüsteem saadab teavituse seotud osapooltele e-posti teel, mis
suunab nad tööelu infosüsteemi sisse logima ja teavitust lugema. Kui töötervishoiuarst tuvastab, et töötaja
kutsehaigestumise võis põhjustada töötamine eelmiste tööandjate juures, kaasatakse ka nemad teavituse saajate
hulka.
Kutsehaigestumist uurib ka tööandja ja esitab sellekohase raporti vastavatele osapooltele 20 tööpäeva jooksul
alates teavituse kätte saamisest. Tööinspektor uurib valdavat osa kutsehaigusjuhtumeid, eriti pööratakse
tähelepanu rasketele või surmaga lõppenud kutsehaigusjuhtumitele (uurimine toimub tööandjast sõltumatult).
Kergemad juhtumid, mis on sarnased juba uuritud juhtumitele, jäetakse üldiselt uurimata.
Patsiendi ja tööandja info tuvastatakse läbi tööelu infosüsteemi liidestuse töötamise registri (TÖR) ja
äriregistriga.
Kui inspektor on teavituse kätte saanud ja selle menetlemiseks registreerib, võetakse automaatselt
töötervishoiuarsti sisestatud infost vajalikud andmed üle. Andmete korduvat sisestamist ei toimu. Olulised
andmed menetlusprotsessis on: 1) töötaja ja tööandja(te) andmed 2) diagnoosi nimetus3) töökeskkonna
ohutegurid, millega töötaja kokku puutus 4) töötaja amet ja tööstaaž ja 5) tööandja tegevusala.
Peale kutsehaiguse registreerimist infosüsteemis otsustab töötervishoiu talituse juhataja, kas vaja on läbi viia
uurimine. Kui otsustatakse läbi viia uurimine, siis on võimalus seda teha kas kontaktivabalt ainult infosüsteemis
või kontaktjärelevalvena läbi tööandja külastamise.
Kutsehaigestumise uurimise tulemused peavad olema nähtavad Tööinspektsioonile, töötervishoiuarstile ja
tööandja töötajatele.
31 Kutsehaiguste loetelu https://www.riigiteataja.ee/akt/897867
32 Tööõnnetuse ja kutsehaigestumise registreerimise, teatamise ja uurimise kord
https://www.riigiteataja.ee/akt/105082014014
PwC 37
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Eeldused:
• Protsessi peamiseks eelduseks on, et TEHIK arendab e-tervise infosüsteemis välja funktsionaalsuse
kutsehaiguste registreerimiseks ja vastava info vahetamiseks Tööelu IS-iga.
Joonis 13. Kutsehaigestumise menetlemine
PwC 38
Tööelu infosüsteemi eelanalüüs Lõpparuanne
3.7 Tööõnnetuse menetlemine
Tööõnnetus on töötaja tervisekahjustus või surm, mis toimus tööandja poolt antud tööülesannet täites või muul
tema loal tehtaval tööl, tööaja hulka arvataval vaheajal või muul tööandja huvides tegutsemise ajal. Tööõnnetus
liigitatakse raskusastme järgi kergeks, raskeks või surmaga lõppenud tööõnnetuseks. Tööõnnetuse menetlemist
reguleerib Tööõnnetuse ja kutsehaigestumise registreerimise, teatamise ja uurimise kord 33, kuid mis läheb
Töötervishoiu ja tööohutuse seaduse tõttu muutmisele.
Menetlemise protsessis (vt Joonis 14) on neli osapoolt:
1. tööandja;
2. uurimistalituse juhataja;
3. inspektor-uurija;
4. arst.
Menetlemine toimub protsessi algusest lõpuni tööelu infosüsteemis, kus seotud osapooltele on määratud
vajalikud õigused.
Menetlemise protsess algab siis, kui on toimunud tööõnnetus. Teavitus tööõnnetuse kohta tuleb arstilt. TI võib
ka ise algatada tööõnnetuse uurimist talle laekunud info põhjal.
Tööandja uurib kõiki tööõnnetusi. Töötaja peab esimesel võimalusel teatama tööandjale igast temaga juhtunud
tööõnnetusest, samuti selle tagajärjel ajutise töövõimetuse määramisest. Tööandja sisestab peale tööõnnetuse
uurimist 10 tööpäeva jooksul tööelu infosüsteemi uurimise raporti ja salvestab selle tööelu infosüsteemi TI.
Automaatselt (läbi kannatanu isikukoodiga sidumist) läheb uurimise raport ka kannatanule.
Tööinspektor uurib kõiki surmaga lõppenud tööõnnetusi peale politsei kriminaalmenetluse uurimise lõppemist.
Kui selgub, et tegemist on raske tööõnnetusega, siis otsustab TI uurimistalituse juhataja uurimise toimumise.
Kui tegemist on kerge tööõnnetusega, millega kaasneb töövõimetus, siis otsustab uurimise jätkamise
uurimistalituse juhataja.
Uurimistoimingute läbiviimisel on oluliseks sisendinfoks:
1. töötaja tööleping ja ametijuhend;
2. töötaja juhendamise kaart, töövahendi kasutusjuhend ning juhendid tehtava töö kohta;
3. tervisekontrolli otsus;
4. isikukaitsevahendite väljastamine;
5. riskianalüüsi väljavõte
6. riskianalüüsi hinnang õnnetuskoha kohta;
7. tööandja tegevuskavad ja sisekontrolli dokumendid;
8. töötervishoiu ja tööohutusnõuete eest vastutav isik;
9. Sündmuste tunnistajad, kaastöölised;
10. tööandja poolne uurimisraport ja sündmuskoha vaatlus.
Uurimisel ja tööandja külastusel on tööinspektor-uurijal õigus koheselt õnnetuse põhjustanud töövahendi
kasutamine või töö peatada.
Tööõnnetuse uurimise lõpetamisel koostab tööinspektor uurimiskokkuvõtte ja esitab selle koopiad 3 tööpäeva
jooksul tööandjale ja kannatanule või tema huvide kaitsjale. Koopiate esitamise tähtaega võib pikendada juhul,
kui tööõnnetuse uurimiseks on alustatud kriminaalmenetlust. Tööandjal on võimalik edastada
uurimiskokkuvõttele vastuväide. Peale tööandja saadetud vastuväidetega tutvumist otsustab tööinspektor-
33 https://www.riigiteataja.ee/akt/12950663
PwC 39
Tööelu infosüsteemi eelanalüüs Lõpparuanne
uurija, kas teha ettekirjutus või alustada väärteomenetlus. Juhtumi lõpetamisel infosüsteemis delikaatsed
isikuandmed kodeeritakse 34.
Eeldused:
• Protsessi peamiseks eelduseks on, et TEHIK arendab e-tervise infosüsteemis välja tööõnnetuste
registreerimise funktsionaalsuse ja vastava info vahetamiseks Tööelu IS-iga.
34 Kodeerimine toimub iga tööõnnetuse puhul. Andmeid kasutatakse Eurostati statistika jaoks.
PwC 40
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Joonis 14. Tööõnnetuse menetlemine
PwC 41
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4 Infosüsteemi lähteülesanne
Käesolevas peatükis on kirjeldatud osapoolte ja TO-BE nägemusel põhinevad nõuded tulevasele Tööelu
infosüsteemile. Tehniliste ja funktsionaalsete nõuete väljaselgitamisel kasutatakse Rational Unified Process
raamistiku nõuete analüüsi FURPS+ mudelit 35.
Käesoleva arenduse käigus tuleb luua kõikidele tööelu osapooltele lihtsasti kasutatav
tsentraalne keskkond, kus muuhulgas TI saab läbi viia järelevalvet ning tööandja täita TI
poolt seatud kohustusi.
4.1 Lühiülevaade infosüsteemi hetkeolukorrast
Täna kasutab TI 2004. aastal kasutusele võetud tehnoloogilist lahendust, mis on loodud standardsele
dokumendihaldussüsteemi platvormile Webdesktop 36 (ITI), millele on juurde lisatud vastavalt TI
põhiülesannetele erimenetluste lahendused. ITI baasil on arendatud ka kliendiportaal eTI, mis on mõeldud
osapoolte vaheliseks infovahetuseks. Selle kaudu saab kodanik vaadata endaga seotud menetlusi ja edastada
vajalikke dokumente.
ITI-s sisaldub kogu TI andmekogu, mida reguleerib Töökeskkonna andmekogu põhimäärus 37.
Andmekogu kasutatakse:
• TI järelevalvetegevuse planeerimiseks, operatiivseks juhtimiseks ja ülesannete täitmiseks;
• töövaidluste menetlemiseks, põhjuste väljaselgitamiseks ja rakenduspraktika kujundamiseks;
• töötervishoiu-, tööohutus- ja töösuhtealase tegevusega seotud ametkondade koostööks;
• töötervishoiu-, tööohutus- ja töösuhete alaseks ennetustööks, ohtlike tegevusalade ning töö- ja
ametikohtade väljaselgitamiseks.
Andmekogusse kantakse andmed 38:
• tööandja kohta;
• tööõnnetuse kohta;
• kutsehaigestumise kohta;
• tööst põhjustatud haigestumise kohta;
• tööandja juurde tehtud külastuse kohta;
• töökeskkonna kontrolli kohta;
• töösuhete kontrolli kohta;
• sõidukijuhtide töö- ja puhkeaja kontrolli kohta;
• järelkontrolli kohta;
• sihtkontrolli kohta;
• isikukaitsevahendite (turujärelevalve) kontrolli kohta;
• uue ja rekonstrueeritud ehitise ülevaatamise kohta;
• tuvastatud rikkumiste kohta;
• sunniraha kohta;
• väärteomenetluse kohta;
35 https://en.wikipedia.org/wiki/FURPS
36 Webdesktop - https://www.webware.ee/et/webdesktop
37 Töökeskkonna andmekogu põhimäärus - https://www.riigiteataja.ee/akt/123072014006
38 Töökeskkonna andmekogusse kantavad andmed -
https://www.riigiteataja.ee/aktilisa/1230/7201/4006/SOM_m47_lisa.pdf#
PwC 42
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• taotletud nõusolekute kohta;
• tööandja teatiste kohta;
• töövaidlusasjade kohta.
Kavandatavasse tööelu infosüsteemi soovitakse kogu eelkirjeldatud funktsionaalsus liita, et anda kõikidele
osapooltele kiire ja tõhus töövahend oma kohustuste täitmiseks, info saamiseks ning info edastamiseks. Samuti
on vajadus varem kogutud andmete kasutamiseks uues infosüsteemis, et menetlusi läbi viia.
4.2 Infosüsteemi loogiline mudel/vaade
Uus tööelu infosüsteem muutub kõikidele järelevalve protsessis osalejatele tsentraalseks infosüsteemiks, kus
toiminguid teostada. Infosüsteem on läbi X-tee liidestatud vajalike andmebaasidega, et menetluseks vajalikku
infot hankida. Kõik andmed on infosüsteemis seotud kas ettevõtte registrikoodi ja/või isikukoodiga. Kõik
kasutuslood toimuvad tööelu infosüsteemis, kuid eksisteerib vajadus liidestada see väliste infosüsteemidega.
Joonis 15. Uue tööelu infosüsteemi skoop
PwC 43
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3 Funktsionaalsed nõuded
4.3.1 Rollide mudel
Joonis 16. Rollide mudel
Rollide mudel (vt Joonis 16) on koostatud põhimõttel, et suuremate õigustega rollid pärivad ühised õigused
väiksemate õigustega rollidelt. Noole suund erinevate rollide vahel näitab õiguste pärimist.
Näiteks pärib infosüsteemi peakasutaja roll enda õigused TI juhataja rollilt ja tööandja juhatuse liikme rollilt,
mis tähendab, et peakasutaja rollil kehtivad omakorda samad kasutuslood, mis nendel rollidel. Lisaks on
peakasutaja rollil oma unikaalsed kasutuslood.
Järgnevalt on kirjeldatud tööelu infosüsteemi kasutamise põhirollid. Rolle on võimalik jaotada süsteemisisese
rollihalduse abil väiksemateks rollideks, määrates nendele täpsemaid vastutusi. Järgnevas kirjelduses on
infosüsteemi kasutaja isik, kellele on infosüsteemis nimetatud roll määratud.
• Anonüümne kasutaja – Tuvastamata infosüsteemi kasutaja, kes näeb Tööelu.ee veebilehel avalikke
andmeid. Näiteks tutvub anonüümne kasutaja enne portaali sisselogimist erineva tööelu puudutava
infomaterjaliga. Lisaks näeb anonüümne kasutaja avalikke uudiseid, teateid ja juhendeid. Ülejäänud
rollid on autoriseeritud.
PwC 44
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Töötaja – Autoriseeritud infosüsteemi kasutaja. Töötaja võib olla seotud ühe või mitme tööandjaga.
Töötaja andmed päritakse läbi infosüsteemi liidestuse töötamise registriga (TÖR). Töötaja näeb tööelu
infosüsteemis enda kui füüsilise isiku ja enda ettevõttega seotud andmeid (nt riskianalüüs). Samuti saab
kasutaja taotleda ja vastu võtta TK-spetsialisti rolli ja saata ning vastu võtta sõnumeid ja teavitusi.
• Töötaja esindaja – Autoriseeritud infosüsteemi kasutaja. Töötaja esindaja saab infosüsteemis olla: 1)
TK-volinik, kes valitakse üle 10 töötajaga ettevõttes 2) TK-nõukogu liige, kes valitakse üle 150 töötajaga
ettevõttes 3) usaldusisik ja 4) esmaabiandja.
Töötaja esindaja saab infosüsteemis vaadata kutsehaigestumise, tööst põhjustatud haigestumise ja
tööõnnetuse andmeid. Lisaks vaadata riskianalüüsi tulemusi ja tegevuskava ning inspektori edastatud
protokolli ja ettekirjutust.
• TK-spetsialist – Autoriseeritud infosüsteemi kasutaja. TK-spetsialist esindab ettevõtet TI-ga
suhtlemisel ja vastutab ettevõtte ohutu töökeskkonna eest. TK-spetsialist saab infosüsteemis täiendavalt
määrata ettevõtte töökeskkonna eest vastutajad, viia läbi riskianalüüs koos tegevuskava kinnitamisega,
esitada läbi infosüsteemi dokumente ja tõendeid TI inspektorile.
• Juhatuse liige – Autoriseeritud infosüsteemi kasutaja. Juhatuse liige aktiveerib esmalt tööelu
infosüsteemi sisselogimisel ära oma ettevõtte konto ja kinnitab ettevõtte kontaktandmed. Seejärel
määrab ta ettevõtte töökeskkonna eest vastutajaks TK-spetsialisti, kes hakkab tema ettevõtet TI-ga
suhtlemisel esindama.
• TI inspektor – Autoriseeritud infosüsteemi kasutaja. TI inspektor saab infosüsteemis vaadata
ettevõtete statistikat ja TI inspektorite töö statistikat. Inspektor saab infosüsteemis algatada uue
järelevalve koos õigusega detailsemalt järelevalvesubjekti infot näha (nt riskianalüüs). Inspektor viib
samuti läbi tööõnnetuste uurimist ja sekretär registreerib infosüsteemis tööst põhjustatud haigestumisi ja
kutsehaigestumisi.
• TI analüütik – Autoriseeritud infosüsteemi kasutaja, kes analüüsib TI andmeid. (Ei ole käesoleva
analüüsi skoobis, roll sisustatakse tulevaste tööelu infosüsteemi analüüside käigus).
• TI juhataja – Autoriseeritud infosüsteemi kasutaja, kes otsustab infosüsteemis, kas ja milliseid
juhtumeid uurida ning millisele inspektorile uuritav juhtum määrata.
• Peakasutaja – Peakasutaja on süsteemi mõistes kõige kõrgemate õigustega kasutaja, kellel on toe
tagamise eesmärgil võimalik astuda igasse teise infosüsteemi kasutajaks. Ta toetab teisi kasutajaid
süsteemis tekkinud takistuste lahendamisega. Peakasutaja võib töökoormuse hajutamiseks oma
organisatsioonis jagada oma õigusi väiksemate õigustega kasutajate vahel.
4.3.2 Kasutuslood
Järgnevalt on kirjeldatud tööelu infosüsteemi funktsionaalsed nõuded süsteemi kasutuslugudena. Igas
kasutusloos on välja toodud vastava kasutuslooga seotud nõuded. Nõude sõnastuses kasutatud rolliviide
„kasutaja“ viitab konkreetses rollis olevale isikule, kes vastava kasutusloo käivitab ja selles tegutseb.
4.3.2.1 Anonüümse kasutaja kasutuslood
Joonis 17. Anonüümse kasutaja kasutuslood
Anonüümse kasutaja kasutuslugude eesmärgiks on tagada, et infosüsteemi kasutajate isikud on kindlaks tehtud
ja nad saavad infosüsteemis tegutseda vaid oma volituste ja õiguste ulatuses.
PwC 45
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.1.1 Autentimine
Kirjeldus:
1. Kasutaja navigeerib tööelu infosüsteemi autentimise leheküljele.
2. Kasutajale kuvatakse autentimiseks kolm võimalust: 1) ID-kaart 2) mobiili-ID või 3) smart-ID.
3. Kasutaja valib sobiva autentimisvõimaluse.
4. Kasutaja tuvastab ennast, toimub infosüsteemi poolt autoriseerimine ja käivitatakse autoriseerimise
kasutuslugu (vt Autoriseerimine).
Ärireeglid:
• Anonüümsel kasutajal tuleb enda isik infosüsteemis tegutsemiseks tuvastada.
• Anonüümne kasutaja peab saama tuvastada infosüsteemis oma isiku ID-kaardi 39 abil.
• Anonüümne kasutaja peab saama tuvastada infosüsteemis oma isiku mobiili-ID 40 abil.
• Anonüümne kasutaja peab saama tuvastada infosüsteemis oma isiku smart-ID 41 abil.
4.3.2.1.2 Autoriseerimine
Kirjeldus:
1. Kasutaja autoriseeritakse infosüsteemi poolt ja talle antakse infosüsteemi poolt määratud õigused.
Ärireeglid:
• Autoriseerimise läbinud kasutaja saab infosüsteemis tegutseda vaid talle määratud õiguste ulatuses.
• Autoriseerimine toimub rollipõhiselt vastavalt kasutajale infosüsteemis määratud rollile.
• Kui autoriseeritud kasutaja on seotud mõne ettevõttega, siis ta peab saama infosüsteemi sisenemisel
valida: 1) kas ta soovib siseneda juhatuse liikmena (andmed päritakse äriregistrist) või 2) ettevõtte
töötajana (andmed päritakse töötamise registrist (TÖR).
• Kui autoriseeritud kasutaja pole seotud ühegi ettevõttega (nt mittetöötav isik või erinevas vormis
iseendale tööd andev isik), siis ta peab saama infosüsteemi sisse logida.
• Infosüsteem peab juhatuse liikme allkirjaõigust kontrollima.
• Kui juhatuse liikme allkirjaõigus puudub, siis äriregistril on arendamisel teenus olukorras, kus mitmel
juhatuse liikmel puudub allkirjaõigus, muudetakse lihtsamaks nt konkreetne taotlus saadetakse kõigile
juhatuse liikmetele ja kõik peavad taotluse allkirjastama.
• Infosüsteem peab olema liidestatud läbi X-tee teenuse äriregistriga, töötamise registriga (TÖR) ja
rahvastikuregistriga, et seda kasutuslugu realiseerida.
39 ID-kaart - https://www.id.ee/index.php?id=10585
40 Mobiili-ID - https://www.id.ee/index.php?id=36809
41 Smart-ID - https://www.smart-id.com/et/
PwC 46
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.2 Töötaja kasutuslood
Joonis 18. Töötaja kasutuslood
Töötaja kasutuslugude eesmärgiks on võimaldada autoriseeritud kasutajal tööelu infosüsteemis protsess enda ja
temaga seotud ettevõtte info haldamiseks ja vaatamiseks, rollide haldamiseks ja osapooltele sõnumite ning
teavituste saatmiseks ja vastuvõtmiseks.
4.3.2.2.1 Ettevõtte info vaatamine
Kirjeldus:
1. Kasutajale kuvatakse tema personaalne töölaud.
2. Kasutaja valib valiku minu ja ettevõtte info haldamine.
3. Kasutajale kuvatakse teemakategooriad.
4. Kasutaja valib kategooria ettevõtte info.
5. Kasutaja vaatab temaga seotud ettevõtte infot.
Ärireeglid:
• Kui kasutaja töötab rohkem kui ühes ettevõttes, siis kasutaja peab saama sisse logides valida, millise
ettevõtte töötajana infosüsteemi sisenetakse.
• Kui kasutaja on ühe või mitme ettevõtte juhatuse liige ja sh ka töötaja, siis kasutaja peab saama sisse
logides valida, millise ettevõtte esindajana või töötajana infosüsteemi sisenetakse.
• Kasutaja seos ettevõttega (või mitme ettevõttega) tuvastatakse läbi infosüsteemi liidestuse töötamise
registriga (TÖR) ja äriregistriga.
• Kui kasutaja on sisse loginud töötajana või juhatuse liikmena, siis ta peab saama vaadata oma tööandja
(sisse loginud töötajana) või oma ettevõtte (sisse loginud juhatuse liikmena) infot:
− Ettevõtte kontaktandmed.
− Töötajate sh töökeskkonna eest vastutajate info.
− Täies mahus ettevõtte riskianalüüs.
− Kasutajale infosüsteemi poolt konkreetse ettevõttega seotud rollid.
PwC 47
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.2.2 Enda info haldamine
Kirjeldus:
1. Kasutaja valib valiku minu ja ettevõtte info haldamine.
2. Kasutajale kuvatakse teemakategooriad.
3. Kasutaja valib kategooria enda info.
4. Kasutaja vaatab temaga seotud infot nt kontaktandmed sh aadress, telefoninumber ja e-posti aadress,
tervisekontrolli andmed (tuleviku tööelu infosüsteemi arendus) ja temaga seotud menetlused.
a. Kasutaja saab soovi korral oma kontaktandmeid muuta, valides kontaktandmete muutmine.
b. Käivitub kasutuslugu enda info muutmine (vt Enda info muutmine).
Ärireeglid:
• Kui kasutaja on sisse loginud töötajana või juhatuse liikmena, siis ta peab saama vaadata enda kui
füüsilise isiku infot:
− Kasutaja kontaktandmed (kui andmed on äriregistris olemas kasutatakse vaikimisi neid).
− Kasutaja tervisekontrolli andmed (realiseeritakse hilisemate arenduste käigus).
− Kasutajaga seotud menetlused.
− Kasutajale määratud rollid (nt TK-spetsialist, TK-nõukogu liige jne).
• Kasutaja peab lisaks endaga seotud menetlustele nägema ka endaga seotud menetluste täielikku ajalugu
ja saama teostada ajaloost märksõna järgi otsingut.
4.3.2.2.3 Enda info muutmine
Kirjeldus:
1. Kasutaja muudab enda kui füüsilise isiku kontaktandmeid.
2. Kasutaja salvestab muudatused.
3. Infosüsteem salvestab kasutaja uued kontaktandmed.
Ärireeglid:
• Kasutaja peab saama enda kui füüsilise isiku kontaktandmeid muuta.
• Kasutaja ei saa muuta infot, mida infosüsteem kuvab automaatselt läbi töötamise registri (nt temaga
seotud ettevõtte info).
4.3.2.2.4 Rollide haldus
Kirjeldus:
1. Kasutaja valib valiku minu ja ettevõtte info haldamine.
2. Kasutajale kuvatakse teemakategooriad.
3. Kasutaja valib kategooria rollide haldamine.
4. Kasutaja vaatab talle infosüsteemi poolt määratud ja konkreetse ettevõttega seotud rolle.
5. Siit vaatest saab algatada ka teisi kasutuslugusid: 1) Rolli taotlemise kasutuslugu (vt Rolli taotlemine) 2)
Rolli vastuvõtmise kasutuslugu (Rolli vastuvõtmine) ja 3) Rollist loobumise kasutuslugu (vt Rollist
loobumine).
Ärireeglid:
• Kasutajale kuvatakse selgelt, kui talle on konkreetses ettevõttes mingi roll määratud või kui talle
soovitakse mõnda rolli määrata.
PwC 48
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.2.4.1 Rolli taotlemine
Kirjeldus:
1. Kasutaja valib TK-spetsialisti rolli, mida ta soovib konkreetses ettevõttes (mille alt ta on infosüsteemi
sisse loginud) taotleda.
2. Kasutaja taotleb TK-spetsialisti rolli.
3. Infosüsteem saadab teatise TK-spetsialistile (kui on juba määratud) või juhatuse liikmele (kui TK-
spetsialist hetkel puudub) rolli andmise kinnitamiseks.
4. Käivitub kasutuslugu TK esindajate määramine (vt TK esindajate ).
Ärireeglid:
• Kasutaja peab saama temaga seotud ettevõttes TK-spetsialisti rolli taotleda.
• Juhul, kui ettevõttel ei ole TK-spetsialisti määratud, saadetakse roll kinnitamiseks ettevõtte juhatuse
liikmele.
• Kui juhatuse liikmeid on mitu, kellel on iseseisev allkirjaõigus, siis saadetakse taotlus kõigile juhatuse
liikmetele ja piisab ühe juhatuse liikme kinnitusest.
• Kui juhatuse liikmeid on mitu, kellel puudub allkirjaõigus, siis saadetakse taotlus kõigile juhatuse
liikmetele ja kõik liikmed peavad taotluse kinnitama.
• Juhul, kui ettevõttes on TK-spetsialisti roll juba määratud, saadetakse rolli taotlus olemasolevale TK-
spetsialistile.
• Kui ettevõttes on juba mitu TK-spetsialisti määratud, siis saadetakse rolli taotlus kõikidele TK-
spetsialistidele ja piisab ühe TK-spetsialisti kinnitusest.
4.3.2.2.4.2 Rolli vastuvõtmine
Kirjeldus:
1. Kasutajale kuvatakse roll, mida talle soovitakse määrata.
2. Kasutajale kuvatakse rolliga peamised ülesanded (rolliga seonduvad ülesanded on kirjeldatud seadustes
ja määrustes).
3. Kasutaja kinnitab temale määratud rolli vajutades nupule kinnita.
4. Infosüsteem annab kasutajale ettevõttes rolli.
a. Kasutajal on võimalus temale kinnitamiseks saadetud rolli mitte vastu võtta.
b. Kasutaja ei võta rolli vastu ja vajutab nupule keeldu.
c. Käivitub rollist loobumise kasutuslugu (vt Rollist loobumine).
d. Infosüsteem ei anna kasutajale ettevõttes rolli.
e. Infosüsteem teavitab rolli määrajat rolli mitte vastu võtmisest.
Ärireeglid:
• Kasutaja peab saama ühe või mitu rolli vastu võtta.
• Rolle võetakse vastu ükshaaval iga määrangu kohta eraldi.
• Rollid, mida kasutaja saab vastu võtta: 1) TK-spetsialist 2) TK-volinik 3) TK-nõukogu liige 4)
Esmaabiandja ja 5) Usaldusisik.
4.3.2.2.4.3 Rollist loobumine
Kirjeldus:
1. Kasutajale kuvatakse temale määratud rollid.
2. Kasutaja valib konkreetse rolli juures loobu rollist.
3. Infosüsteem eemaldab kasutajalt selle rolli ja viib tema õigused infosüsteemis vastavaks.
Ärireeglid:
PwC 49
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Kasutaja peab saama loobuda kõigist rollidest peale ettevõtte Töötaja.
• Ettevõtte töötaja rollist loobumine käib automaatselt kui TÖR-i andmete põhjal ei ole kasutaja enam selle
ettevõtte töötaja.
• Kasutaja rollist loobumisel saadetakse teavitus TK-spetsialistile.
• Juhul, kui kasutaja loobub rollist TK-spetsialist ja ettevõttes ei ole teist TK-spetsialisti, saadetakse
teavitus ettevõtte juhatuse liikmele.
• Kui ettevõttes on mitu TK-spetsialisti määratud, siis saadetakse rollist loobumise taotlus kõikidele TK-
spetsialistidele ja piisab ühe TK-spetsialisti kinnitusest.
• Kui juhatuse liikmeid on mitu, kellel on iseseisev allkirjaõigus, siis saadetakse rollist loobumise taotlus
kõigile juhatuse liikmetele ja piisab ühe juhatuse liikme kinnitusest.
• Kui juhatuse liikmeid on mitu, kellel puudub allkirjaõigus, siis saadetakse taotlus kõigile juhatuse
liikmetele ja kõik liikmed peavad taotluse kinnitama.
4.3.2.2.5 Sõnumite saatmine ja vastuvõtmine
Kirjeldus:
1. Kasutajale kuvatakse tema personaalne töölaud ja teavitus uue sõnumi kohta.
2. Kasutaja valib oma töölaualt otsetee sõnumite vaatamiseks.
3. Kasutaja vaatab talle saadetud sõnumeid.
4. Kasutaja soovib sõnumile vastata ja valib uue sõnumi koostamise.
5. Kasutaja koostab sõnumi ja valib sõnumi saajaks TI inspektori või endaga seotud ettevõttes mõne teise
osapoole nt TK-spetsialist.
6. Kasutaja saadab sõnumi.
Ärireeglid:
• Kasutaja peab tööelu infosüsteemis nägema talle saadetud sõnumeid.
• Kasutaja peab tööelu infosüsteemis saama saata ja vastu võtta sõnumeid.
• Kasutaja peab sõnumitele saama lisada ühe või mitu manust.
• Manusena on toetatud kõik enamlevinud failiformaadid (nt bdoc, jpeg, PDF, docx, xlsx, txt, rtf). Detailne
failiformaatide koosseis lepitakse kokku infosüsteemi realisatsiooni etapis detailanalüüsi käigus.
• Manuste saatmisel peab kasutama infosüsteemi poolt seatud mahupiirangut 150MB ühe faili kohta.
• Infosüsteem peab kasutajat teavitama, kui teda ootab tööelu infosüsteemis uus sõnum.
• Kui kasutaja on uue sõnumi saabumisel tööelu infosüsteemi sisse logitud, siis tuleb talle töölauale selle
kohta selge teavitus.
• Infosüsteemi saadetud teavitusele ei saa kasutaja vastata.
• Infosüsteem teavitab kasutajat uuest sõnumist temaga seotud e-posti aadressile, mis suunab kasutaja
infosüsteemi uut sõnumit lugema.
• Kui mingi teavitus on veel seotud mõne konkreetse töötajaga, siis on see automaatselt nähtav ka sellele
töötajale tema töölaual.
• Sõnumite puhul kuvatakse sõnumi saatmise aega ja saatja nime.
PwC 50
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.3 Töötaja esindaja kasutuslood
Joonis 19. Töötaja esindaja kasutuslood
Töötaja esindaja kasutuslugude eesmärgiks on võimaldada kasutajal infosüsteemis vaadata valimiste protokolli
ja otsustada selle kinnitamine. Töötaja esindaja võib olla TK-volinik, TK-nõukogu liige või usaldusisik. Lisaks
antakse kasutajale infosüsteemis õigus vaadata kutsehaigestumise, tööst põhjustatud haigestumise ja
tööõnnetuse andmeid 42.
4.3.2.3.1 Valimiste protokolli vaatamine ja kinnitamise otsustamine
Kirjeldus:
1. Kasutajale kuvatakse tema personaalne töölaud.
2. Kasutaja valib oma töölaualt otsetee talle määratud ülesanded.
3. Kasutaja vaatab talle määratud ülesandeid ja valib sealt talle saadetud valimiste protokolli.
4. Kasutaja vaatab valimiste protokolli.
5. Kasutaja kinnitab valimiste protokolli.
6. Infosüsteem registreerib uue valimiste protokolli.
a. Kui kasutaja ei ole valimiste protokolliga nõus, siis ta saab selle kinnitamisest keelduda, valides
mittekinnitamise.
b. Infosüsteem saadab TK-spetsialistile teavituse valimiste protokolli mittekinnitamise kohta.
Ärireeglid:
• Valimiste protokoll koostatakse töötaja esindajate valimisel.
• Töötaja esindaja võib olla TK-volinik, TK-nõukogu liige või usaldusisik.
• Juhul, kui tegu on TK-nõukogu liikmete valimiste protokolliga, peavad selle kinnitama kõik TK-nõukogu
liikmed.
• Kasutaja peab tööelu infosüsteemis nägema valimiste protokolli.
• Valimiste protokoll (sh varasemad protokollid) ja kinnitused peavad salvestuma infosüsteemis.
• Infosüsteemis salvestatud valimiste protokolli (sh varasemate protokollide) andmeid peab infosüsteem
kasutama automaatkontrolli ja kontaktivaba järelevalve läbiviimisel.
4.3.2.3.2 Kutsehaigestumise, tööst põhjustatud haigestumise ja tööõnnetuse andmete vaatamine
Kirjeldus:
1. Kasutaja valib valiku töötervishoid.
2. Kasutajale kuvatakse teemakategooriad.
3. Kasutaja saab valida kolme teemakategooria vahel: 1) kutsehaigestumine 2) tööst põhjustatud
haigestumine või 3) tööõnnetused.
42 Töötervishoiu ja tööohutuse seadus - https://www.riigiteataja.ee/akt/128042017009 - § 24 lõige 3
PwC 51
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4. Kasutaja vaatab andmeid nt tööõnnetuse raportit.
Ärireeglid:
• Tööõnnetuse ja kutsehaigestumise uurimise käigus ning tööst põhjustatud haigestumisest saadud
andmed töötaja terviseseisundi kohta on delikaatsed isikuandmed, mida töödeldakse isikuandmete kaitse
seaduses 43 sätestatud korras.
• Kasutajale ei kuvata juhtumi diagnoosi.
• Tööõnnetuse ja kutsehaigestumise uurimise andmeid säilitatakse 55 aastat.
• Kasutaja peab saama vaadata nii TI tehtud uurimise lõppraportit, kui ka TK-spetsialisti poolt saadetud
raportit TI-le.
4.3.2.4 TK-spetsialisti kasutuslood
Joonis 20. TK-spetsialisti kasutuslood
TK-spetsialisti kasutuslugude eesmärgiks on võimaldada kasutajal tööelu infosüsteemis riskianalüüsi ja
tegevuskava hallata, määrata ettevõttele TK esindajad, esitada dokumente ja täiendavaid tõendeid TI
43 Isikuandmete kaitse seadus - https://www.riigiteataja.ee/akt/130122010011
PwC 52
Tööelu infosüsteemi eelanalüüs Lõpparuanne
inspektorile ja uurida tööõnnetusi. Kasutusloo tulemina registreeritakse infosüsteemis lisaks üks või mitu uut
TK eest vastutajat.
4.3.2.4.1 Riskianalüüsi haldamine
Kirjeldus:
1. Kasutaja valib valiku töökeskkonna ohutus.
2. Kasutajale kuvatakse teemakategooriad.
3. Kasutaja valib riskianalüüsi haldamise.
4. Kasutajale kuvatakse riskianalüüsi haldamise vaade.
5. Siit vaatest saab käivitada ka teisi kasutuslugusid: 1) Riskianalüüsi koostamise volitamise kasutuslugu (vt
Riskianalüüsi koostamise volitamine) 2) Riskianalüüsi lisamise kasutuslugu (vt Riskianalüüsi lisamine)
3) Riskianalüüsi muutmise kasutuslugu (vt Riskianalüüsi muutmine) ja 4) Riskianalüüsi kustutamise
kasutuslugu (vt Riskianalüüsi kustutamine).
Ärireeglid:
• Kasutaja peab saama riskianalüüsi lisada.
• Kasutaja peab saama riskianalüüsi muuta.
• Kasutaja peab saama riskianalüüsi kustutada.
4.3.2.4.1.1 Riskianalüüsi koostamise volitamine
Kirjeldus:
1. Kasutaja soovib volitada riskianalüüsi koostamise teisele isikule.
2. Kasutaja valib volitamiseks välja teatud riskianalüüsi ohumoodulid või kogu riskianalüüsi.
3. Kasutaja valib kas:
a. Ta soovib volitada riskianalüüsi koostamise teisele ettevõtte töötajale tehes valiku ettevõtte
töötajate nimekirjast, seejärel vajutab salvesta ja saada vastutajatele.
b. Ta soovib volitada välise teenusepakkuja, kelle ta lisab isikukoodi kasutades, seejärel vajutab
salvesta ja saada volitus.
4. Infosüsteem võimaldab volitatud kasutajale ligipääsu riskianalüüsi tegemiseks.
5. Siit vaatest saab käivitada Riskianalüüsi lisamise kasutusloo (vt Riskianalüüsi lisamine).
Ärireeglid:
• Pärast TK-spetsialisti poolset riskianalüüsi kinnitamist, välise teenusepakkuja infosüsteemi volitused
riskianalüüsi koostamisele tühistatakse.
• Kasutaja peab saama volitada nii kogu riskianalüüsi tegemise kui ka ühe ohumooduli kontekstis riskide
analüüsimise.
• Kasutaja peab saama riskianalüüsi tegemise volitamise käigus valida nimekirjast oma ettevõtte töötaja või
sisestada volitamiseks välise teenusepakkuja isikukoodi.
• Riskianalüüsi peab saama genereerida viisil, mis võimaldab selle välja printida.
4.3.2.4.1.2 Riskianalüüsi lisamine
Kirjeldus:
1. Kasutaja valib uue riskianalüüsi koostamise.
2. Kui ettevõttel on mitu tegutsemiskohta, siis kasutaja valib sobiva tegevuskoha.
3. Riskianalüüsi alustamiseks valib kasutaja infosüsteemi poolt etteantud ettevõtte tüüpide hulgast endale
sobiva tüübi nt ehitusettevõte või:
PwC 53
Tööelu infosüsteemi eelanalüüs Lõpparuanne
a. Kasutaja valib juba varasema tehtud riskianalüüsi malli ja kopeerib uude riskianalüüsi selle
andmed.
4. Kasutajale kuvatakse sõltuvalt valitud ettevõtte tüübist ohupaneel, kus on kirjas mingi hulk infosüsteemi
poolt valitud ohumooduleid.
5. Vajadusel lisab kasutaja vastavalt enda ettevõtte profiilile ohumooduleid juurde.
6. Kasutajal on võimalus volitada riskianalüüsi osaline või täielik koostamine teisele osapoolele (ettevõtte
töötaja või väline teenusepakkuja).
7. Kasutaja valib ohumooduli.
8. Kasutajale kuvatakse ohumoodul, mille esimene küsimus valideerib ohumooduli olulisuse ettevõtte
kontekstis.
9. Juhul, kui ohumoodul on ettevõtte kontekstis oluline, siis kuvatakse kasutajale valitud ohumooduli
temaatikaga ca 3-15 kontrollküsimust etteantud abinõudega.
10. Kasutaja saab ohumooduli väitele vastata „JAH“ või „EI“. JAH on süsteemi mõttes positiivne vastus
(roheline), EI on negatiivne vastus (punane). Mida rohkem on positiivseid vastuseid, seda parem on
tööandja tegevus konkreetse ohu maandamisel.
11. Kasutaja kordab sama tegevust kõikide ohumoodulite puhul.
12. Peale ohumoodulite küsimustike täitmist kuvatakse kasutajale ohumoodulite kaupa kokkuvõte, kus on
välja toodud küsimused, millele vastati eitavalt.
13. Kasutajal on siin võimalus määrata, kas ta tahab konkreetse abinõu oma ettevõttes kasutusele võtta (valib
tegevuskavasse lisamise) või see ei ole tema ettevõttes vajalik/võimalik (valib põhjenduse, miks ei sobi
see tema ettevõttesse).
14. Kasutaja kinnitab tehtud riskianalüüsi.
15. Infosüsteem märgib ettevõttele peale riskianalüüsi tegemist positiivse staatuse, et riskianalüüs on tehtud.
Seda staatust näeb ka TI inspektor.
Ärireeglid:
• Kõik riskianalüüsi etapid koostatakse infosüsteemis algusest lõpuni elektrooniliselt.
• Kasutaja peab saama koostada riskianalüüsi mitmele ettevõtte tegevuskohale.
• Kasutaja peab saama koostada riskianalüüsi ettevõtte igale filiaalile eraldi.
• Kasutaja peab saama defineerida eraldi osakonnad enda ettevõttes ja luua igale osakonnale eraldi
riskianalüüsi.
• Kasutaja peab saama ka vajadusel hoolimata mitmest tegevuskohast teha ühe riskianalüüsi, mis on
rakendatav kõigile tegutsemiskohtadele.
• Kasutaja peab saama juba tehtud varasema riskianalüüsi andmeid lihtsasti uude riskianalüüsi kopeerida,
st kasutaja salvestab riskianalüüsi malli endale sobiva nimega ja selle malli andmeid saab kasutada uue
riskianalüüsi sisendiks.
• Kasutaja peab saama riskianalüüsi ohumooduleid juurde lisada.
• Kasutaja peab saama riskianalüüsi ise juurde lisatud ohumooduleid ise kustutada.
• Kasutaja ei saa infosüsteemi poolt automaatselt lisatud ohumooduleid kustutada.
• Infosüsteem peab kasutajal võimaldama vaadata eelnevalt infosüsteemis ära defineeritud ettevõtete
tüüpide nimekirja, millest kasutaja saab endale sobiva valida.
• Ettevõtte tüübi ja tegevusala valikul peab kasutaja saama eelnevalt teostada märksõnapõhist otsingut.
• Ettevõtte tüübi ja tegevusala valikul kasutab tööelu infosüsteem EMTAK klassifikaatorite süsteemi.
• Kui infosüsteem tuvastab ja pakub kasutajale valimiseks ettevõtte tüübi ja tegevusala, siis kasutaja peab
saama seda endale sobivaks muuta.
• Infosüsteem peab eelnevalt infosüsteemis ära defineeritud ettevõtete tüüpide valimi ära siduma eelnevalt
ära defineeritud ohumoodulitega.
• Infosüsteem peab peale ohumoodulite küsimustike täitmist kuvama kasutajale kokkuvõtte eitavalt
vastatud küsimustega.
• Kasutaja peab saama tegevuskavasse lisatud tegevustele lisada vastutaja sisestades vastutaja isikukoodi
või valides vastutaja ettevõtte töötajate nimekirjast.
• Kasutaja peab saama riskianalüüsi koostamise protsessi käigus igal ajahetkel oma tegevus salvestada ja
hiljem jätkata.
• Kasutajal peab olema võimalik printida kogu riskianalüüsi mooduli protsessi tulemus ühtse
tervikdokumendina.
PwC 54
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Infosüsteem salvestab info riskianalüüsi ja erinevate moodulite täitjate kohta.
4.3.2.4.1.3 Riskianalüüsi muutmine
Kirjeldus:
1. Kasutaja valib sobiva riskianalüüsi, mida soovib muuta.
2. Kasutajale kuvatakse juba täidetud andmetega riskianalüüs.
3. Kasutaja vaatab täidetud riskianalüüsi üle ja vajadusel saab erinevaid osasid riskianalüüsist muuta või
ohumooduleid juurde lisada.
4. Kasutaja muudab riskianalüüsis andmeid ja kinnitab selle.
5. Infosüsteem salvestab uue versiooni riskianalüüsist ja jätab vana versiooni arhiivi.
Ärireeglid:
• Kasutaja peab saama muuta täies mahus olemasolevat riskianalüüsi, sh sinna uusi ohumooduleid juurde
lisada.
• Kasutaja peab riskianalüüsi muutmisel saama suvalisel hetkel muudatused salvestada ja nende juurde
hiljem tagasi tulla ning jätkata riskianalüüsi muutmist.
• Infosüsteem peab säilitama arhiveerimise eesmärgil varasemad riskianalüüsi versioonid.
4.3.2.4.1.4 Riskianalüüsi kustutamine
Kirjeldus:
1. Kasutaja soovib olemasolevat riskianalüüsi kustutada.
2. Kasutaja valib sobiva riskianalüüsi, mida ta soovib kustutada.
3. Kasutaja käest küsitakse riskianalüüsi kustutamise kinnitust.
4. Kasutaja kustutab riskianalüüsi.
5. Infosüsteemis muudetakse ettevõtte riskianalüüsi staatuseks puudub riskianalüüs.
6. Kustutatud riskianalüüsiga seotud osapooli teavitatakse infosüsteemi poolt riskianalüüsi kustutamisest.
Ärireeglid:
• Kasutaja peab saama olemasolevat riskianalüüsi kustutada.
• Infosüsteem peab kasutaja käest küsima kustutamise kinnitust.
• Infosüsteem peab riskianalüüsi kustutamisel muutma ettevõtte staatust nii, et ettevõttel puudub
riskianalüüs.
• Infosüsteem peab riskianalüüsiga seotud osapooli riskianalüüsi kustutamisest teavitama.
• Infosüsteem peab säilitama kustutatud riskianalüüsi arhiveerimise eesmärgil enda andmebaasis.
4.3.2.4.2 TK esindajate haldamine
Kirjeldus:
1. Kasutaja valib valiku minu ja ettevõtte info.
2. Kasutajale kuvatakse teemakategooriad.
3. Kasutaja valib töökeskkonna rollid.
4. Kasutajale kuvatakse TK rollide ja TK esindajate haldamise vaade.
5. Siit vaatest saab käivitada ka teisi kasutuslugusid: 1) TK esindaja lisamise kasutuslugu (vt TK esindaja
lisamine) 2) TK esindaja muutmise kasutuslugu (vt TK esindaja muutmine) ja 3) TK esindaja kustutamise
kasutuslugu (vt TK esindaja kustutamine).
Ärireeglid:
• Kasutaja peab saama TK esindajaid hallata sh neid: 1) lisada 2) muuta ja 3) kustutada.
PwC 55
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.4.2.1 TK esindaja lisamine
Kirjeldus:
1. Kasutaja valib töökeskkonnaga seotud rollide muutmise.
2. Kasutaja lisab oma ettevõttes sobiva TK esindaja valides sobiva TK esindaja rolli ja sobiva töötaja või
sisestades isikukoodi (ka välise teenusepakkuja).
3. TK esindaja lisamisel peab kasutaja lisama valimiste protokolli faili või nt TK-spetsialisti koolituse
sertifikaadi.
4. Kasutaja vajutab TK esindaja lisamiseks nuppu lisa.
5. Infosüsteem omistab lisatud kasutajale valitud TK esindaja rolli.
6. Infosüsteem teavitab lisatud kasutajat talle omistatud uuest TK esindaja rollist.
7. Kasutaja peab talle omistatud uue TK esindaja rolli kinnitama või sellest loobuma. (vt kasutuslugusid
Rolli vastuvõtmine ja Rollist loobumine).
8. Infosüsteemis muudetakse vastavalt muudetud rolli kinnitamisele või loobumisele kasutaja õigused
vastavaks.
Ärireeglid:
• Kasutaja peab infosüsteemis saama lisada järgmised TK esindajad:
− TK-spetsialist.
− TK-volinik.
− TK-nõukogu liige.
− Esmaabi andja.
− Usaldusisik.
• Kasutaja (kes on ise ettevõttes TK-spetsialist) ei saa iseennast infosüsteemis lisada samasse ettevõttesse:
1) TK-volinikuks ja 2) usaldusisikuks enne, kui tema TK-spetsialisti roll on eemaldatud.
• Kõikidele infosüsteemis määratud TK esindajatele saadetakse infosüsteemi poolt neile määratud rolli
kohta teade.
• Kõik määratud TK esindajad peavad infosüsteemis neile määratud rolli kinnitama või sellest loobuma.
• TI saab järelevalve käigus tutvuda ettevõttes määratud TK esindajatega.
• TK-spetsialist tuleb määrata kõikides ettevõtetes:
− Kasutaja peab saama lisaks iseendale lisada ka ühe või mitu TK-spetsialisti, kes pärivad
infosüsteemis temaga samad õigused.
− Kasutaja peab isikukoodi sisestades saama määrata ettevõttevälise teenusepakkuja TK-
spetsialistiks, kes pärib infosüsteemis kõik TK-spetsialistiga samad õigused. Ettevõttevälise
teenusepakkuja lisamisel peab saama kasutaja lisada aegumistähtaja, mille saabumisel antud
õigused tühistatakse.
• TK-voliniku valimine on kohustuslik alates 10 töötajaga ettevõttes.
− Valitud TK-voliniku volitused peavad kehtima kuni neli aastat.
− Ettevõtte üleminekul (nt müümisel) kehtivad TK-voliniku volitused nende lõppemiseni, kuid mitte
kauem kui üks aasta üleminekust arvates.
− Ettevõttes võib olla mitu TK-volinikku.
− TK-voliniku valimine toimub infosüsteemi väliselt, kuid valimiste protokoll tuleb lisada TK-
voliniku määramisel.
− Määratud TK-volinikule antakse ülesanne kinnitada valimiste protokoll.
• TK-nõukogu liikmed valitakse vähemalt 150 töötajaga ettevõttes.
− Nõukogu liikmeid peab olema vähemalt neli ja nende volitused kehtivad kuni neli aastat.
− Sõltuvalt ettevõtte ohuteguritest ning ettevõttes aset leidnud tööõnnetuste ja kutsehaigusjuhtude
arvust on TI-l õigus nõuda TK-nõukogu moodustamist ka alla 150 töötajaga ettevõttes.
PwC 56
Tööelu infosüsteemi eelanalüüs Lõpparuanne
− TK-nõukogu liikmete valimine toimub infosüsteemi väliselt, kuid valimiste protokoll tuleb lisada
TK-nõukogu liikmete määramisel.
− Määratud TK-nõukogu liikmetele antakse ülesanne kinnitada valimiste protokoll.
• Igas ettevõttes peab olema määratud vähemalt üks esmaabi andja.
− Esmaabi andjaks saab olla koolituse läbinud ettevõtte töötaja. Koolitus peab olema toimunud
hiljemalt üks kuu alates temale rolli määramisest. Koolituste registreerimine lahendatakse Tööelu
IS juhendamise moodulis, mis ei kuulu selle analüüsi skoopi.
− Ettevõtte mitme territoriaalselt eraldatud struktuuriüksuse või vahetustega töö korral peab igas
struktuuriüksuses või vahetuses olema kohal vähemalt üks esmaabiväljaõppe läbinud töötaja.
• Tähtaegade lähenedes peab infosüsteem vastavaid osapooli sellest teavitama.
• Teavitus saadetakse infosüsteemist e-kirjana, mis suunab kasutaja infosüsteemi seda lugema.
• Kõik TK esindajad on vaikimisi infosüsteemis seotud töötamise registri kandega. Kui TK esindaja
kustutatakse töötamise registrist, siis võetakse ka tööelu infosüsteemis neilt vastavad õigused.
• Uue TK esindaja lisamisel lisatakse infosüsteemi poolt talle külge automaatselt e-posti aadress kujul
[email protected].
• Infosüsteem peab lisatud TK esindajale saatma meeldetuletuse oma e-posti aadressi õigsus üle vaadata,
kui tema infosüsteemi viimasest sisse logimisest on möödas üks aasta.
• Usaldusisik valitakse salajasel hääletusel. Usaldusisiku kandidaate võivad esitada kõik töötajad ja
tööandja juures tegutsev ametiühing.
− Usaldusisiku volitused kehtivad kolm aastat, kui üldkoosolek ei ole otsustanud teisiti.
− Usaldusisiku valimine toimub infosüsteemi väliselt.
− Usaldusisiku valimise ja tagasikutsumise tingimused ning kord peavad tagama kõigile töötajatele
võimaluse osaleda usaldusisiku valimisel ja tagasikutsumisel.
− Üldkoosolek võib kokkuleppel tööandjaga valida mitu usaldusisikut.
− Usaldusisikud võivad endi hulgast valida peausaldusisiku (ei ole infosüsteemis eraldiseisev roll),
kes korraldab usaldusisikute tegevust.
4.3.2.4.2.2 TK esindaja muutmine
Kirjeldus:
1. Kasutaja valib töökeskkonnaga seotud rollide muutmise.
2. Kasutaja valib konkreetse töötaja (või välise teenusepakkuja) nime juures rolli muutmise valiku.
3. Kasutaja muudab töötaja (või välise teenusepakkuja) rolli sobivaks ja vajutab kinnita roll.
4. Infosüsteem teavitab muudetud rolliga kasutajat rolli muutumisest.
5. Kasutaja, kelle rolli infosüsteemis muudeti, peab rolli muudatuse kinnitama või sellest loobuma. (vt
kasutuslugusid Rolli vastuvõtmine ja Rollist loobumine).
6. Infosüsteemis muudetakse vastavalt muudetud rolli kinnitamisele või loobumisele kasutaja õigused
vastavaks.
Ärireeglid:
• Kasutaja peab infosüsteemis saama ettevõttega (mille alt infosüsteemi sisse logiti) seotud TK esindajaid
muuta.
• Kui kasutaja muudab iseenda TK-spetsialisti rolli mõneks muuks rolliks, siis selle muudatuse peab
kinnitama ettevõtte juhatuse liige või teine TK-spetsialist, kellele infosüsteem saadab vastavasisulise
teavituse.
• Kasutaja (kes on ise ettevõttes TK-spetsialist) ei saa iseenda rolli infosüsteemis muuta samas ettevõttes:
1) TK-volinikuks ja 2) usaldusisikuks enne, kui tema TK-spetsialisti roll on muudetud või kustutatud. Siit
võib algatada ka TK esindaja kustutamise kasutusloo (vt TK esindaja kustutamine).
• Kui TK esindaja rolli muutmise tõttu puudub ettevõttes TK-spetsialist, siis muutub infosüsteemis
vastavalt sellele ettevõtte ohuhinnang (täpsustatakse detailanalüüsi käigus).
PwC 57
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.4.2.3 TK esindaja kustutamine
Kirjeldus:
1. Kasutaja valib töökeskkonnaga seotud rollide muutmise.
2. Kasutaja valib konkreetse töötaja (või välise teenusepakkuja) nime juures rolli kustutamise valiku.
3. Infosüsteem küsib kasutajalt kustutamise kinnitust.
4. Kasutaja, kelle roll infosüsteemis kustutati, saab infosüsteemilt sellekohase teavituse.
5. Infosüsteemis muudetakse vastavalt kustutatud rollile kasutaja õigused vastavaks.
Ärireeglid:
• Kasutaja peab infosüsteemis saama ettevõttega (mille alt infosüsteemi sisse logiti) seotud TK esindajaid
kustutada.
• TK esindaja kustutamisel peab infosüsteem küsima kustutamise kinnitust.
• TK esindaja kustutamisel peab infosüsteem kasutajat, kelle roll kustutati, sellest teavitama.
• Kui kasutaja soovib iseennast TK esindajana kustutada, siis selle muudatuse peab kinnitama ettevõtte
juhatuse liige või teine TK-spetsialist.
• Kui TK esindaja kustutamise järgselt puudub ettevõttes TK-spetsialist, siis muutub infosüsteemis
vastavalt sellele ettevõtte ohuhinnang (täpsustatakse detailanalüüsi käigus).
4.3.2.4.3 Dokumentide ja tõendite esitamine
Kirjeldus:
1. Kasutajale tuleb teavitus, et temaga seotud ettevõtte suhtes on algatatud järelevalvemenetlus (vt
kasutuslugu Järelevalve alustamine) ja TI-inspektoril on vaja täiendavaid dokumente või:
a. Kasutaja on juba seotud konkreetse alustatud menetlusega ja TI inspektor saadab peale ettevõtte
külastust kontrolli protokolli koos rikkumistega, kuhu kasutaja saab rikkumise kõrvaldamise
tõendeid ja vastuväiteid esitada.
2. Kasutajale kuvatakse tema personaalne töölaud.
3. Kasutaja valib töölaualt menetluste hulgast konkreetse menetluse.
4. Kasutaja tutvub inspektori edastatud kontrolli protokolliga ja märgib protokollis välja toodud rikkumise
kõrvaldatuks ning lisab juurde tõendi kas failina või vabatekstilise kirjeldusena või ta ei nõustu
rikkumisega või:
a. Kasutaja tutvub inspektori edastatud ettekirjutusega ja märgib ettekirjutuses välja toodud
rikkumise kõrvaldatuks ning lisab juurde tõendi kas failina või vabatekstilise kirjeldusena või ta ei
nõustu ettekirjutusega.
b. Kasutaja edastab TI inspektorile infosüsteemis sõnumite vahetamise vormis soovitud dokumendid
(lisades sõnumile faili manusena) nt ettevõtte riskianalüüsi dokumendi või:
5. Infosüsteem registreerib uue dokumendi või tõendi lisamise.
a. Kasutaja võib ka loobuda dokumentide ja tõendite esitamisest TI inspektorile.
Ärireeglid:
• Kasutaja peab saama TI-le iga käimasoleva menetluse käigus digitaalselt dokumente ja tõendeid esitada.
• Kasutaja peab saama tõendeid, dokumente ja vastuväiteid esitada vabatekstilises vormis või lisades
juurde faili.
• Kontrollprotokolli puhul peab kasutaja saama rikkumiste juures igale rikkumisele eraldi lisada
dokumendi, tõendi või vabatekstilise selgituse.
PwC 58
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Infosüsteemi poolt on toetatud kõik enamlevinud failiformaadid (nt bdoc, jpeg, PDF, docx, xlsx, txt, rtf).
(detailne failiformaatide koosseis lepitakse kokku infosüsteemi realisatsiooni etapis detailanalüüsi
käigus).
• Failide edastamisel peab kasutama infosüsteemi poolt seatud mahupiirangut 150MB ühe faili kohta.
• Kasutaja võib ka loobuda dokumentide ja tõendite esitamisest TI inspektorile.
4.3.2.4.4 Tegevuskava tegevuste haldamine
Kirjeldus:
1. Kasutaja valib valiku töökeskkonna ohutus.
2. Kasutajale kuvatakse teemakategooriad.
3. Kasutaja valib töökeskkonna tegevuskava.
4. Kasutajale kuvatakse tegevuskava haldamise vaade koos tegevuste nimekirjaga.
5. Siit vaatest saab käivitada ka teisi kasutuslugusid: 1) Tegevuskavasse tegevuse lisamise kasutuslugu (vt
Tegevuse lisamine) 2) Tegevuskava tegevuse muutmise kasutuslugu (vt Tegevuse muutmine) ja 3)
Tegevuskava tegevuse kustutamise kasutuslugu (vt Tegevuse kustutamine).
Ärireeglid:
• Kasutaja peab saama tegevuskava tegevusi hallata, sh tegevusi: 1) lisada 2) muuta ja 3) kustutada.
• Juhatuse liige ja TK-spetsialist näevad kogu ettevõtte tegevuste loetelu ja vastutajaid.
• Ülejäänud rollides olevad kasutajad näevad ainult nendele määratud tegevusi.
• Tegevuskava peab saama genereerida viisil, mis võimaldab selle välja printida.
4.3.2.4.4.1 Tegevuse lisamine
Kirjeldus:
1. Kasutajal endal tekib vajadus lisada mingi tegevus enda tegevuskavasse või:
a. Keegi teine lisab kasutajale mingi tegevuse tegevuskavasse (nt riskianalüüsi läbiviimisel), määrates
ta tegevuse eest vastutajaks.
2. Infosüsteem registreerib uue tegevuse ja kasutajal tekib uus tegevus tegevuskavasse.
Ärireeglid:
• Kasutaja peab saama tegevuskavasse lisada uusi tegevusi sh ka teistest tulevikus realiseeritavatest tööelu
moodulitest nt töötajate tervisekontroll (ei ole käesoleva analüüsi skoobis) või koolitusmoodul (ei ole
käesoleva analüüsi skoobis).
• Kasutaja peab saama riskianalüüsis kirjeldatutud tegevustele lisada vastutajad.
• Kasutaja peab saama tegevuskavasse lisatud tegevustele lisada vastutaja sisestades vastutaja isikukoodi
või valides vastutaja ettevõtte töötajate nimekirjast.
• Vastutaja isikukoodi sisestamisel tekib automaatselt vastutaja tegevuskavasse uus tegevus.
• Tegevusele lisatud vastutajale saadetakse infosüsteemi poolt vastavasisuline teavitus.
• Info, mis tekib peale kasutaja läbiviidud riskianalüüsi, peab olema kasutatav tegevuskava sisendina.
• Infosüsteem koostab pärast riskianalüüsi koostamist tegevuskava, kus kasutajal on võimalik märkida
tegevuskavasse lisatud abinõu 1) „tehtuks“ või 2) määrata selle kasutuselevõtmiseks vastutaja ja tähtaeg.
4.3.2.4.4.2 Tegevuse muutmine
Kirjeldus:
1. Kasutajal tekib vajadus muuta mingit tegevust enda tegevuskavas või:
PwC 59
Tööelu infosüsteemi eelanalüüs Lõpparuanne
a. Keegi teine muudab kasutajale määratud tegevust (nt muudab tegevuse täitmise tähtaega).
2. Infosüsteem registreerib tegevuse muudatuse, mis kajastub kasutaja tegevuskavas.
Ärireeglid:
• Kasutaja peab saama enda lisatud tegevusi tegevuskavas muuta.
• Kasutaja ei saa temale teiste poolt määratud tegevusi muuta.
• Kui muudetakse tegevusele lisatud vastutav isik, siis saadetakse talle infosüsteemi poolt vastavasisuline
teavitus.
4.3.2.4.4.3 Tegevuse kustutamine
Kirjeldus:
1. Kasutajal tekib vajadus kustutada mingi tegevus enda tegevuskavas või:
a. Keegi teine muudab kasutajale määratud tegevust (nt muudab tegevuse vastutajat).
2. Infosüsteem registreerib tegevuse kustutamise, mis kajastub kasutaja tegevuskavas.
Ärireeglid:
• Kasutaja peab saama enda lisatud tegevusi tegevuskavas kustutada.
• Kasutaja ei saa temale teiste poolt määratud tegevusi kustutada.
• Kui muudetakse tegevusele lisatud vastutav isik, siis kustutatakse infosüsteemi poolt see tegevus teise
kasutaja tegevuskavast.
• Kui kasutaja märgib tegevuskava tegevuse tehtuks, siis kustutatakse see tegevus kasutaja tegevuskavast.
4.3.2.4.5 Tööõnnetuse ja kutsehaigestumise uurimine
Kirjeldus:
1. Kasutajale saabub TI inspektori või arsti poolt tööelu infosüsteemi teavitus tööõnnetuse toimumise või
KH juhtumi kohta.
2. Kasutaja valib otse teatisest tööõnnetuse või KH juhtumi otsetee või kasutaja valib temaga seotud
tööõnnetuse või KH juhtumi.
3. Kasutaja valib konkreetse tööõnnetuse või KH juhtumi.
4. Kasutaja hindab, kas tegu on tema arvates tööõnnetusega või alustab KH juhtumi puhul selle uurimist.
a. Kui kasutaja nõustub, et tegu on tööõnnetusega, siis kasutaja viib läbi tööõnnetuse uurimise, täidab
infosüsteemis tööõnnetuse raporti ja edastab selle läbi infosüsteemi TI-le (vt kasutuslugu
Dokumentide ja tõendite esitamine).
b. Kui kasutaja ei nõustu, et tegu on tööõnnetusega, siis kasutaja märgib mittenõustumise ja kirjutab
juhtumi juurde vabatekstilises vormis mittenõustumise põhjenduse.
5. Kasutaja uurib tööõnnetuse või KH juhtumit.
6. Kasutaja täidab ära kutsehaigestumise raporti ja edastab selle TI-le.
7. Tööõnnetuse või KH uurimine on lõpetatud.
Ärireeglid:
• Kasutaja peab saama infosüsteemis vastu võtta tööõnnetuse või KH teatise.
• Kasutaja peab saama infosüsteemis täita tööõnnetuse või KH raporti.
• Kasutaja peab saama edastada tööõnnetuse või KH raporti TI-le.
• Tööõnnetuse uurimine peab toimuma infosüsteemis viisardi kaudu ja sisaldama järgmiseid
andmeväljasid:
PwC 60
Tööelu infosüsteemi eelanalüüs Lõpparuanne
− Tööandja andmed (eeltäidetud IS andmete põhjal).
− Töötaja andmed (valib ettevõtte töötajate nimekirjast ja eeltäidetakse osaliselt IS andmete põhjal).
− Tööõnnetuse andmed.
− Tööõnnetuse asjaolude kirjeldus.
− Põhjused, mis viisid tööõnnetuseni (valikvariandid).
− Muu põhjus, mis viis tööõnnetuseni (kirjeldus).
− Andmed riskianalüüsi kohta (kui ettevõttel tehtud Tööelu IS-is riskianalüüs tehakse märge,
kasutaja hindab, kas tööõnnetuse asjaolud on riskianalüüsis arvestatud).
− Samalaadse tööõnnetuse ärahoidmiseks rakendatavad abinõud.
− Tööandja esindaja (juhatuse liige või volitatud isik lisatakse automaatselt).
− TK-volinik või usaldusisik (kui on valitud lisatakse automaatselt).
• KH uurimine peab toimuma infosüsteemis viisardi kaudu ja sisaldama järgmiseid andmeväljasid:
− Tööandja andmed (eeltäidetud IS andmete põhjal).
− Töötaja andmed (valib ettevõtte töötajate nimekirjast ja eeltäidetakse osaliselt IS andmete põhjal).
− Kutsehaigestumise põhjustanud ohutegur (füüsikaline, keemiline, bioloogiline, füsioloogiline,
psühholoogiline).
− Töötaja läbitud tervisekontrollid (siis kui arendatakse välja tervisekontrollide moodul, täidetakse
andmed automaatselt IS-is olevate andmete põhjal).
− Põhjused, mis viisid kutsehaigestumiseni (valikvariandid).
− Muu põhjus, mis viis kutsehaigestumiseni (kirjeldada).
− Andmed riskianalüüsi kohta (kui ettevõttel tehtud Tööelu IS-is riskianalüüs tehakse märge,
kasutaja hindab, kas kutsehaigestumise asjaolud on riskianalüüsis arvestatud).
− Samalaadse kutsehaigestumise ärahoidmiseks rakendatavad abinõud.
− Tööandja esindaja (juhatuse liige või volitatud isik lisatakse automaatselt).
− TK-volinik või usaldusisik (kui on valitud lisatakse automaatselt).
• Tööõnnetuse ja KH uurimise viisardi lõpus tuleb kasutajalt küsida sisestatud andmetele kinnitust.
• Kasutaja peab saama infosüsteemis esitada uurimiskokkuvõttele vastuväite (vt Dokumentide ja tõendite
esitamine).
• Uurimiskokkuvõttele vastuväite esitamisel peab kasutaja saama vastuväitele lisada manuseid ja
vabatekstilise kirjelduse.
• Kasutaja peab KH uurimise läbi viima hiljemalt 20 tööpäeva jooksul pärast KH teatise saamist.
• Kasutaja peab tööõnnetuse uurimise läbi viima hiljemalt 10 tööpäeva jooksul pärast tööõnnetuse
toimumist.
4.3.2.5 Juhatuse liikme kasutuslood
Joonis 21. Juhatuse liikme kasutuslood
Kasutusloo eesmärgiks on infosüsteemis tööandja poolt määrata esmane TK-spetsialist, kes hakkab ettevõtte
töökeskkonna eest vastutama. Kasutusloo tulemina registreeritakse infosüsteemis üks või mitu töökeskkonna
eest vastutavat isikut.
PwC 61
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.5.1 Ettevõtte konto haldamine
Kirjeldus:
1. Kasutaja logib esimest korda sisse tööelu infosüsteemi temaga seotud ettevõtte esindajana ja aktiveerib
sellega infosüsteemis ettevõtte konto.
2. Kasutaja kinnitab, et tööelu infosüsteemi poolt kuvatavad ettevõtte kontaktandmed on korrektsed või
vajadusel muudab neid või:
a. Kasutaja logib sisse tööelu infosüsteemi temaga seotud ettevõtte esindajana
b. Kasutaja vaatab ja muudab vajadusel ettevõtte kontaktandmeid.
3. Infosüsteem registreerib vastavalt tehtud muudatused.
Ärireeglid:
4.3.2.5.2 Esmase TK-spetsialisti määramine
Kirjeldus:
1. Kasutaja valib valiku minu ja ettevõtte info.
2. Kasutajale kuvatakse teemakategooriad.
3. Kasutaja valib töökeskkonna rollid.
4. Kasutajale kuvatakse TK rollide ja TK esindajate haldamise vaade või:
a. Kasutaja valib oma töölaualt tegevuskavast otsetee esmase TK spetsialisti määramiseks.
5. Kasutaja valib esmaseks TK-spetsialistiks sobiva töötaja või sisestab töötaja isikukoodi.
6. Kasutajal on võimalus ka oma TK-spetsialistiks valida ettevõtte väline kolmas osapool sisestades
teenusepakkuja isikukoodi.
7. Kasutaja lisab esmase TK-spetsialisti.
8. Infosüsteem registreerib uue TK-spetsialisti.
Ärireeglid:
• Ettevõtte tööelu infosüsteemi konto peab saama aktiveerida ainult juhatuse liige.
• Ettevõtte esindajana sisenemisel kuvatakse tema ja tema ettevõtte andmed äriregistrist (sh teavitusteks
ettevõtte ametlik meiliaadress) ja palutakse andmeid kontrollida, vajadusel muuta ja kinnitada.
PwC 62
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.6 TI inspektori kasutuslood
Joonis 22. TI inspektori kasutuslood
TI inspektori kasutuslugude eesmärgiks on võimaldada TI inspektori kasutajal vaadata ettevõtete andmeid ja
viia ettevõtete suhtes läbi järelevalvet, vaadata teiste inspektorite töö statistikat, uurida tööõnnetusi ja
registreerida uus TPH ja KH juhtum. Kasutusloo tulemina registreeritakse süsteemis üks või rohkem uut
järelevalvemenetlust.
4.3.2.6.1 Ettevõtete statistika vaatamine
Kirjeldus:
1. Kasutajale kuvatakse tema personaalne töölaud.
2. Kasutaja valib ettevõtete statistika vaatamine.
3. Kasutaja vaatab ettevõtete statistikat.
Ärireeglid:
• Kasutaja peab nägema kõikide tööelu infosüsteemis olevate ettevõtete statistikat (täpne statistika
koosseis täpsustatakse detailanalüüsi käigus).
• Ettevõtete statistika on jaotatud kolme suurde fooripõhisesse kategooriasse:
− Rohelised ettevõtted (automaatjärelevalve läbitud, inspektor ei tunne huvi, inspektori sekkumist ei
ole vaja).
− Kollased ettevõtted (kontaktivaba või kontaktjärelevalve võimalus, inspektori vähene huvi,
inspektor otsustab sekkumise).
− Punased ettevõtted (kontaktivaba või kontaktjärelevalve võimalus, inspektori suur huvi, inspektor
otsustab sekkumise).
PwC 63
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Kasutaja peab saama ettevõtete valikule rakendada filtreid nt tegevusala, ettevõtte suurus jne. Täpne
filtrite koosseis selgub detailanalüüsi käigus.
4.3.2.6.2 Järelevalve läbiviimine
Kirjeldus:
1. Kasutajale kuvatakse tema personaalne töölaud.
2. Kasutaja alustab järelevalvet ettevõtte suhtes ja saadab infosüsteemist järelevalve alustamise teate.
3. Kasutaja määratleb dokumendid, mida ta soovib, et ettevõte esitaks enne kontrolli (vt kasutuslugu
Dokumentide ja tõendite esitamine).
4. Ettevõtja saab seejärel inspektorile vajalikud dokumendid infosüsteemi üles laadida ja inspektor saab
nendega tutvuda).
5. Kasutaja otsustab, kas ettevõtte läbib kontaktivaba või kontaktjärelevalve.
6. Kui viiakse läbi kontaktjärelevalve, täidab kasutaja selle käigus kontrolli protokolli ja vajadusel hinnangu
lehe.
7. Kasutaja edastab kontrolli tulemused läbi infosüsteemi kontrollitud ettevõttele.
8. Ettevõte saab kontrollprotokollis välja toodud rikkumisele juurde lisada tõendid (nt laeb üles pildifaili
rikkumise kõrvaldamisest) (vt kasutuslugu Dokumentide ja tõendite esitamine).
9. Pärast tõendite esitamist saab kasutaja otsustada, kas menetlus lõpetada või teha ettekirjutus ja
järelkontroll.
10. Järelevalve on läbi viidud.
Ärireeglid:
• Kasutaja peab nägema infosüsteemis kõikide ettevõtete üldist statistikat.
• Kasutaja peab saama järelevalve menetluse käigus ettevõttele ettekirjutust teha, väärteomenetlust
alustada ja menetlust lõpetada.
• Kui ettevõte on kõrvaldanud rikkumisi osaliselt, siis määrab kasutaja uue tähtaja kõrvaldamata
rikkumiste kõrvaldamiseks ja vajadusel koostab sunniraha hoiatuse või rakendab sunniraha.
• Kasutaja peab saama järelevalve läbiviimise käigus koostada ettekirjutust v.a juhul, kui järelevalve
menetluse liigiks valiti nõustamine.
• Kasutajal on järelevalve läbiviimiseks vajalikud järgmised ettevõtte andmed:
− Ettevõtte andmed äriregistri andmetel, sh seosed jagunemiste/ühinemiste kohta
◦ Registrikood.
◦ Ärinimi.
◦ Õiguslik vorm.
◦ Registreerimise kuupäev.
◦ Põhitegevusvaldkond (k.a kood).
◦ Muud tegevusalad.
◦ Aadress.
◦ Olek.
◦ Töötajate arv – EMTA/TÖR.
− Ettevõtte tegevuskoha aadressid ja nimetused – kui automaatselt muudest registritest ei saa, siis
peavad olema ettevõtte ja kasutaja poolt täidetavad
◦ Tegevuskoha nimetused ja aadressid – seos aadresside registriga
◦ E-post.
◦ Telefon.
◦ Koduleht.
− Seotud juhatuse liikmed (äriregistri andmetel sh kõik seosed erinevate ettevõtetega):
◦ Nimi.
PwC 64
Tööelu infosüsteemi eelanalüüs Lõpparuanne
◦ Isikukood.
◦ Kehtivus.
− Töökeskkonnaalane informatsioon:
◦ TK-spetsialist – nimi, kehtivus.
◦ TK-volinik(ud) – nimi, kehtivus.
◦ TK-nõukogu liikmed – nimi, kehtivus.
◦ Usaldusisik – nimi, kehtivus.
◦ Esmaabiandja – nimi, kehtivus.
− Kontaktid TI-ga:
◦ Viimane ettevõtte külastus TI poolt.
◦ Ettevõtte ohuhinnang – moodustub lõpuks kokkulepitud andmestiku pealt (selgub
detailanalüüsi käigus).
◦ Ettevõtte riskianalüüsi olemasolu.
◦ Ohtlikkuse kategooria (SEVESO – Päästeameti andmetel).
− Järelevalve ajalugu:
◦ Menetlused – menetluse aluse klassifikaator; valdkond, asukoht (muud märksõnad
intervjuude läbiviimiseks: tööalane ärakasutamine, võõrtööjõud, ühiskontroll).
◦ Külastused – koos oma andmeväljadega.
◦ Töökeskkonna kontroll + töökeskkonna hinnanguleht.
◦ Sihtkontroll + sihtkontrolli eripärale vastav hinnanguleht.
◦ Sõidukijuhtide kontroll koos oma andmeväljadega.
◦ Järelkontroll.
◦ IKV turujärelevalve.
◦ Sh tuvastatud rikkumised.
◦ Ettekirjutused, kontrolli protokoll.
◦ Sunniraha määramised.
◦ Ehituste ülevaatus – (täna veel kasutusel, kuid võib edaspidi kaduda).
◦ Konsulteerimine.
◦ Nõustamine.
◦ Tööst põhjustatud haigestumiste registreerimine – andmevahetus Terviseametiga.
◦ Kutsehaigestumise registreerimine/uurimine + seotud dokumendid – tulemuseks.
uurimistoimik säilitamisajaga 55 aastat.
◦ Tööõnnetuste registreerimine/uurimine + seotud dokumendid – tulemuseks uurimistoimik
säilitamisajaga 55 aastat – töökord olemas.
◦ Registreerimised, mis võivad omakorda üle minna menetlusteks:
> Lähetamise teade.
> Alaealise teade.
> Tööandja teatised – erinevad teatised, mida saab üle kanda vormidele.
> Vihjed/kaebused.
> Väärteomenetlused – kui läheb üle e-toimikusse, siis jääb märge siiski
väärteomenetluse alustamise kuupäevast, alusest ja otsusest.
• Kasutaja peab järelevalve käigus saama ettevõttega sõnumite vahetamise vormis suhelda, täiendavat infot
küsida ja ettevõtte poolt saadetud dokumente ja sõnumeid vastu võtta (vt Sõnumite saatmine ja
vastuvõtmine ja Dokumentide ja tõendite esitamine).
• Kui kasutaja saadab ettevõttele sõnumi, siis peab infosüsteem ettevõttele sellekohase teavituse e-kirjaga
saatma, mis suunab ettevõtte infosüsteemi sõnumit lugema.
• Kui tegu on sõidukijuhtide kontrolliga, siis peab infosüsteem toetama digitaalsete sõidumeerikute failide
vastuvõtmist.
PwC 65
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.6.2.1 Ohuhinnangu andmine
Kirjeldus:
1. Infosüsteem analüüsib ettevõtete vastavust erinevatele kriteeriumitele (täpsustatakse detailanalüüsi
käigus).
2. Infosüsteem võtab arvesse kriteeriumitele TI poolt omistatud kaalusid.
3. Infosüsteem koostab järelevalvatavate ettevõtete valimi.
4. Infosüsteem määrab kasutajale ettevõtted, mille osas tuleb järelevalve läbi viia.
5. IS saadab automaatselt koostatud valimi TI juhile valideerimiseks (ülevaatamiseks, muutmiseks,
kinnitamiseks)
6. Kasutaja saab alustada valimis olevate ettevõtete suhtes järelevalvet (vt Järelevalve alustamine).
Ärireeglid:
• Igal ettevõttel on infosüsteemis foori tüüpi staatus: 1) roheline 2) kollane ja 3) punane.
• Foori tüüpi staatus sõltub ettevõtte profiilist ja ettevõtte tegutsemisest infosüsteemis:
− Riskianalüüs on tehtud ja uuendatud.
− TK-spetsialist on määratud.
− TK-volinik on määratud (kui ettevõttes on rohkem kui 10 töötajat).
− TK-nõukogu liikmed on määratud (kui ettevõttes on rohkem kui 150 töötajat).
− Ettevõttes toimunud tööõnnetuste arv.
− Ettevõttes toimunud tööst põhjustatud haigestumiste arv.
− Ettevõttes toimunud kutsehaigestumiste arv.
− Ettevõtte töövaidluste arv.
− Tööinspektori viimane külastus ettevõttesse.
− Ettevõtte varasemate rikkumiste arv.
− Ettevõttele tehtud varasemate ettekirjutuste arv.
− TI konsultatsiooniteenuse kasutamine. (ei ole realiseeritav selle arenduse käigus).
− Ettevõtte töötajate arv.
− EMTAK tegevusala ohtlikkuse hinnang.
• See, kuidas ettevõtte staatus määratletakse ja millised on näiteks tööõnnetuse statistika kaalud, mis selle
staatuse määravad, selgub hilisemas detailanalüüsi projektis.
• Infosüsteem peab eelnevalt defineeritud kriteeriumite ja statistika nt tööõnnetused (kaalud defineeritakse
detailanalüüsi käigus) alusel automaatselt kasutajale kontrollimiseks ettevõtteid lisama.
4.3.2.6.2.2 Järelevalve alustamine
Kirjeldus:
1. Kasutajale kuvatakse tema töölaual aktiivsed menetlused.
2. Kasutaja saab järelevalvet alustada: 1) alustada talle infosüsteemi poolt automaatselt määratud või TI
juhataja poolt määratud ettevõtte suhtes menetlust. 2) otsides märksõna või registrikoodiga ja lisades
käsitsi uue ettevõtte.
3. Kasutaja koostab järelevalve alustamise kohta teate.
4. Kasutaja määrab teemad, mida järelevalve käigus kontrollitakse.
5. Sihtkontrolli teemad ulatuse alusel valib kontrolliobjektid.
6. Kasutaja määrab dokumendi, mida ta järelevalve käigus kontrollida soovib (vt Dokumentide ja tõendite
esitamine).
7. Kasutaja saadab info järelevalve alustamise kohta.
8. Pärast järelevalve alustamise teate saatmist antakse kasutajale õigused tutvuda ettevõtte profiiliga
detailsemalt, st tal tekib võimalus lugeda ettevõtte riskianalüüsi ja tutvuda ettevõtte poolt määratud TK
esindajate andmetega.
PwC 66
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Ärireeglid:
• Kasutaja peab saama otsida sobivat ettevõtet märksõna või registrikoodi alusel.
• Kasutajale kuvatakse järelevalvemenetlused, mida ta saab valida, liigiti: 1) töötervishoiu ja tööohutuse
nõuete täitmise kontrollimine 2) töösuhete nõuete täitmise kontrollimine 3) sõidukijuhtide töösuhete
nõuete kontrollimine 4) nõustamine ja 5) ehituse eelteade.
• Valides pooleliolevate menetluste hulgast, saab kasutaja jätkata juba alustatud järelevalve protsessi.
• Uute menetluste hulgas kuvatakse kasutajale TI juhataja poolt järelevalveks määratud ettevõtteid või
infosüsteemi poolt ohuhinnangu baasil koostatud nimekiri.
• Kasutaja saab alustada järelevalvet kõikide ettevõtete suhtes, kes on infosüsteemis registreeritud.
• Kui kasutaja alustab ettevõtte profiililt järelevalvemenetlust, peab selle kohta automaatselt ettevõtte e-
posti aadressile teavitus minema.
• Kasutaja peab saama märkida ka seire käigus külastatud ettevõtteid (külastuse toimumise aeg ja
ettevõte), kuid sellele ei järgne järelevalve läbiviimist.
• Enne järelevalve alustamist peab kasutaja saama vaadata ettevõtte profiili, kus on kuvatud 1) ettevõtte
andmed 2) ettevõtte töökeskkonna olukord sh määratud TK esindajad 3) juba algatatud menetluste info.
4.3.2.6.2.3 Kontrolli protokolli koostamine
Kirjeldus:
1. Kasutaja avab kontrolli protokolli.
2. Infosüsteemi poolt on eeltäidetud kontrollitava ettevõtte andmed, kontrolli eesmärk, toimumise koht ja
aeg.
3. Kasutaja kontrollib ettevõtet ja täidab infosüsteemis kontrolliprotokolli, lisades sinna kontrolli juures
viibivad isikud, kontrolli tegevuste kirjelduse, kontrolli käigus ettevõtte poolt tehtud taotlused, avastatud
rikkumised, vastuväited.
4. Töökeskkonna kontrolli puhul täidab kasutaja ka hinnangulehe (vt Hinnangulehtede täitmine).
5. Kasutaja otsustab rikkumiste põhjal, kas järelevalve jätkub.
6. Kasutaja kinnitab kontrolli protokolli.
7. Kontrolli protokoll edastatakse ettevõttele.
Ärireeglid:
• Ettevõte võib kontrolli protokolli kättesaamisel esitada viie tööpäeva jooksul täiendavaid dokumente,
arvamusi ja vastuväiteid kontrolli käigus avastatud rikkumiste kohta (vt Dokumentide ja tõendite
esitamine).
• Kui kontrolli käigus rikkumisi ei tuvastatud, märgib kasutaja kontrolli protokollis menetluse lõpetatuks ja
saadab kontrolli protokolli ettevõttele.
• Kontrolli protokolli rikkumiste reale kantakse üle hinnangulehelt hindamiskriteerium koos
kommentaariga, kus hinnang oli märgitud halvaks.
• Kontrolli protokoll peab sisaldama järgmiseid andmeid:
− menetlustoimingu teostamise aeg ja koht.
− menetlustoimingut läbiviiva haldusorgani nimi ning kohal viibivate menetlusosaliste, tõlkide,
ekspertide ja tunnistajate nimed ja kontaktandmed.
− menetlustoimingu eesmärk.
− menetlustoimingu käigus esitatud taotlused.
− menetlusosalise seletuste, eksperdi või tunnistaja ütluste sisu või paikvaatluse tulemused.
− avastatud rikkumised.
• Uute rikkumiste tuvastamisel (nt ettevõtte tõendite esitamisel tuvastas kasutaja uue rikkumise) koostab
kasutaja uue kontrolli protokolli samale juhtumile lisaks ning saadab selle ettevõttele tõendite ja
vastuväidete esitamiseks.
• Ettevõttel on aega viis tööpäeva, et esitada kontrolli protokollile vastuväiteid (vt Dokumentide ja tõendite
esitamine).
• Kasutaja võib nõuda ettevõttelt täiendavate dokumentide või tõendite esitamist.
PwC 67
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Kasutaja peab saama kontrolli protokolliga seotud rikkumiste põhjal koostada ettekirjutuse v.a
nõustamise valimisel.
• Kui tegu on sõidukijuhtide kontrolliga, siis peab kontrollprotokolli koostamisel saama valida avastatud
rikkumise lahtri juures rikkumisega seotud töötaja nime.
4.3.2.6.2.4 Hinnangulehtede täitmine
Kirjeldus:
1. Kasutajale kuvatakse hinnanguleht.
2. Kasutaja hindab olukorda iga hindamiskriteeriumi puhul neljas kategoorias (hea, pigem hea, pigem halb,
halb).
3. Kasutaja saab lisada selgitava kommentaari.
Ärireeglid:
• Hindamiskriteeriumid, kus hinnang oli pigem halb või halb lisatakse kontrolli protokolli rikkumiste
osasse.
• Kasutaja peab saama hinnangukriteeriumi juurde lisada vabatekstilise selgitava kommentaari.
4.3.2.6.3 Inspektorite tööstatistika vaatamine
Kirjeldus:
1. Kasutajale kuvatakse tema personaalne töölaud.
2. Kasutaja vaatab töölaualt TI inspektorite töö üldist statistikat.
Ärireeglid:
• Kasutaja peab oma töölaual nägema enda ja teiste TI inspektorite kogu töö statistikat, mis hõlmab:
− Kui palju menetlusi on konkreetsel ajahetkel käimas.
− Kui palju ettevõtteid on läbinud automaatjärelevalve, kontaktivaba järelevalve ja
kontaktjärelevalve.
− Kui palju on väljastatud ettekirjutusi, tehtud väärteomenetlusi ja järelkontrolle.
• Täpne vajalik statistika otsustatakse projekti detailanalüüsi käigus.
4.3.2.6.4 Tööst põhjustatud haigestumise ja kutsehaigestumise registreerimine
Kirjeldus:
1. Kasutajale kuvatakse tema personaalne töölaud.
2. Kasutaja valib TPH ja kutsehaiguse registreerimise otsetee.
3. Kasutaja registreerib TPH või kutsehaiguse.
4. Infosüsteemis registreeritakse uus TPH või kutsehaiguse juhtum.
Ärireeglid:
• Kasutaja peab saama vastu võtta arsti poolt saadetud teatist TPH või kutsehaiguse kohta.
• Kasutaja peab saama infosüsteemi TPH või kutsehaigus registreerida. (Tööelu IS integreeritakse
hilisemas faasis e-tervise infosüsteemiga, et teateid automaatselt vahetada).
• Kasutaja peab saama edastada TPH või kutsehaiguse andmed infosüsteemist Terviseametile.
• TPH ja kutsehaiguse andmed säilitatakse edasise analüüsi eesmärgil.
• Registreeritud TPH ja kutsehaiguse andmeid võetakse arvesse ohuhinnangute juures.
PwC 68
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.6.5 Tööõnnetuse ja kutsehaigestumise uurimine
Kirjeldus:
1. Kasutajale saabub ettevõtte või arsti poolt tööelu infosüsteemi teavitus TÕ toimumise kohta või:
a. Kasutaja valib uurimiseks otse teatisest TÕ juhtumi otsetee; või
b. Kasutaja registreerib ise infosüsteemi uue TÕ juhtumi ja alustab selle uurimist; või
c. Kasutaja valib uurimiseks juba infosüsteemi registreeritud KH juhtumi.
2. Kasutajale kuvatakse sisselogimisel tema personaalne töölaud.
3. Kasutaja valib uurimiseks konkreetse TÕ või KH juhtumi.
4. Kasutaja tutvub infosüsteemis ettevõtte andmetega.
5. Kasutaja teostab vajadusel paikvaatluse.
6. Kasutaja täidab infosüsteemis paikvaatluse protokolli, kuhu märgib vaatlusega tuvastatud asjaolud.
7. Kasutaja protokollib erinevate osapoolte ütlused TÕ või KH juhtumi kohta.
8. Kasutaja koostab uurimistoimingute protokolli, kus on kirjas ettevõtte andmed, kontrollimise juures
viibinud isikud, toimingud, menetlusosaliste taotlused, kogutud dokumendid, esitamata dokumendid.
9. Kasutaja koostab TÕ uurimisel asjaolusid selgitava fototabeli ja tööõnnetuse toimumist illustreeriva
paikkonna skeemi.
10. Kasutaja tutvub ettevõtte poolt saadetud TÕ või KH uurimise raportiga (vt Tööõnnetuse ja
kutsehaigestumise uurimine).
11. Kasutaja koostab TÕ või KH uurimiskokkuvõtte, kus sisalduvad ettevõtte andmed, kannatanud andmed,
tööõnnetuse asjaolud, tööõnnetuse raskusaste, tööõnnetuse põhjused ja tuvastatud rikkumised, abinõud
samalaadsete tööõnnetuste ärahoidmiseks.
12. Kasutaja edastab ettevõttele TÕ või KH uurimise kokkuvõtte.
13. Ettevõte võib esitada vastuväiteid (vt Dokumentide ja tõendite esitamine).
14. Kasutaja koostab otsuse.
15. Kasutaja otsustab juhtumi lõpetamise.
16. Kasutaja võib koostada ettekirjutuse või alustada väärteomenetlust.
Ärireeglid:
• Kasutaja peab saama infosüsteemis vastu võtta arsti poolt saadetud teatise.
• Kasutaja peab saama infosüsteemis ise registreerida uue TÕ või KH juhtumi.
• Kasutaja peab saama infosüsteemis vastu võtta ettevõtte poolt saadetud TÕ või KH uurimise raporti.
• Kasutaja peab saama koostada TÕ või KH uurimisraporti ja edastada selle ettevõttele.
• Kasutaja peab saama vaadata ettevõtte poolt saadetud vastuväiteid uurimiskokkuvõttele.
• Kasutaja peab saama teha ettevõttele ettekirjutust.
• Kasutaja peab saama algatada ettevõtte suhtes väärteomenetlust.
• Kasutaja peab saama TÕ või KH juhtumit infosüsteemis lõpetada.
• Kasutaja peab KH ja TÕ uurimise läbi viima 30 tööpäeva jooksul pärast uurimise otsustamist.
4.3.2.6.6 Sündmuse registreerimine
Kirjeldus:
1. Kasutajale kuvatakse tema personaalne töölaud.
2. Kasutaja valib sündmuse registreerimise otsetee.
3. Kasutaja registreerib uue sündmuse nt saabunud vihje/kaebus või seire toimumine.
4. Infosüsteemis registreeritakse uus sündmus.
Ärireeglid:
• Kasutaja peab saama infosüsteemis uut sündmust registreerida.
PwC 69
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Sündmuse registreerimisel peab kasutaja saama valida sündmuse liigi ja sinna juurde vabatekstina
kirjelduse. Sündmuse liigid kirjeldatakse detailanalüüsi käigus, kuid minimaalselt on need: vihje, kaebus,
seire, konsultatsioon, lähetamise teade, nimekiri ei ole lõplik.
• Kasutaja peab saama registreeritud sündmuse põhjal algatada järelevalvet (vt Järelevalve alustamine).
4.3.2.7 TI juhataja kasutuslood
Joonis 23. TI juhataja kasutuslood
TI juhataja kasutuslugude eesmärgiks on TI juhataja poolt infosüsteemis juhtumite uurimise otsustamine ja
inspektoritele uuritavate juhtumite määramine.
4.3.2.7.1 Uurimise otsustamine
Kirjeldus:
1. Kasutajale saabub inspektor-uurija poolt tööelu infosüsteemi teavitus tööõnnetuse toimumise kohta.
a. Kasutaja valib otse teatisest tööõnnetuse juhtumi otsetee või
2. Kasutajale kuvatakse sisselogimisel tema personaalne töölaud.
3. Kasutaja valib uurimiseks konkreetse tööõnnetuse juhtumi.
4. Kasutaja tutvub tööõnnetuse juhtumi andmetega (vt Kutsehaigestumise, tööst põhjustatud haigestumise
ja tööõnnetuse andmete vaatamine).
5. Kasutaja otsustab, kas juhtumit uurida või mitte.
6. Kui kasutaja otsustab juhtumit uurida, siis infosüsteem registreerib uue juhtumi uurimise.
Ärireeglid:
• Inspektor-uurija peab saama kasutajale infosüsteemis konkreetse tööõnnetuse juhtumi kohta teavituse
saata.
• Kasutaja peab saama otsustada, kas juhtumit uurida või mitte.
• Kui kasutaja otsustab juhtumit mitte uurida, siis kasutaja peab saama juhtumi infosüsteemis lõpetada ja
vabatekstilise kirjeldusena lisada põhjuse uurimise mittetoimumise kohta.
4.3.2.7.2 Inspektoritele juhtumite määramine
Kirjeldus:
1. Kasutaja otsustab, et konkreetset tööõnnetuse juhtumit tuleb uurida.
2. Kasutaja määrab tööõnnetuse uurimise konkreetsele inspektorile valides sobiva inspektori nime või
sisestades inspektori isikukoodi.
3. Infosüsteem saadab inspektorile teavituse uue juhtumi kohta.
Ärireeglid:
PwC 70
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Kasutaja peab saama inspektoritele uurimiseks juhtumeid määrata.
• Kasutaja peab saama mitmele inspektorile ühte juhtumit määrata. Sellisel juhul kehtivad infosüsteemis
mõlemale inspektorile juhtumis võrdsed õigused.
4.3.2.8 Peakasutaja kasutuslood
Joonis 24. Peakasutaja kasutuslood
Peakasutaja kasutuslugude eesmärgiks on võimaldada infosüsteemis kasutajakonto ja rollide, ohumoodulite ja
hinnangulehtede haldamine ja monitoorida infosüsteemi toimimist ja logisid. Peakasutaja saab vastavalt
vajadusele endale lisada kõik olemasolevad infosüsteemi rollid, et vigade esinemisel korrata kõikide kasutajate
tegevusi. Kasutusloo tulemina registreeritakse infosüsteemis uusi rolle või muudetakse olemasolevaid rolle.
4.3.2.8.1 Kasutajakontode ja rollide haldamine
Kirjeldus:
1. Peakasutaja navigeerib infosüsteemi kasutajakontode või rollide loendisse.
PwC 71
Tööelu infosüsteemi eelanalüüs Lõpparuanne
2. Peakasutajale kuvatakse kasutajakontode või rollide haldamise vaade.
3. Siit vaatest saab käivitada ka teisi kasutuslugusid: 1) Konto ja/või rolli lisamise kasutuslugu (vt Konto ja
rolli lisamine) 2) Konto ja/või rolli muutmise kasutuslugu (vt Konto ja rolli muutmine) ja 3) Konto ja/või
rolli kustutamise kasutuslugu (vt Konto ja rolli kustutamine).
Ärireeglid:
• Peakasutaja peab saama hallata kõiki infosüsteemis olevaid kasutajakontosid sh neid 1) lisada 2) muuta ja
3) kustutada.
• Peakasutaja peab nägema infosüsteemis kõikide kasutajate ja rollide nimekirja.
• Peakasutaja peab nägema infosüsteemis kõikide kasutajate ja nendega seotud rolle.
• Peakasutaja peab saama kasutajate ja rollide nimekirja filtreerida vabatekstilise otsingu abil.
• Peakasutaja peab saama kasutajate ja nendega seotud rollide nimekirja sorteerida nimekirja tunnuste
abil.
• Peakasutaja peab saama vaadata rolli nime, kirjeldust, rolli liikmete nimekirja ja rollile määratud
õiguseid.
• Peakasutaja peab saama avada rollide nimekirjast vaate valitud rolli andmetele.
4.3.2.8.1.1 Konto ja rolli lisamine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole uue kasutajakonto ja/või rolli lisamiseks.
2. Peakasutaja navigeerib infosüsteemi kasutajakontode ja/või rollide loendisse.
3. Peakasutaja valib uue kasutajakonto või rolli lisamise.
4. Peakasutaja lisab uue kasutajakonto ja määrab talle rolli või:
a. Peakasutaja lisab uue rolli ja seob selle konkreetse kasutajakontoga.
b. Peakasutaja lisab uue rolli ja ei seo seda konkreetse kasutajakontoga.
5. Infosüsteem registreerib muudatuse.
Ärireeglid:
• Peakasutaja peab saama uut kasutajakontot lisada.
• Peakasutaja peab saama uut rolli lisada.
• Uue kasutajakonto lisamisel peab saama sellele ühe või mitu rolli lisada.
• Uue rolli lisamisel peab saama selle kasutajakontodega siduda.
• Uue rolli lisamisel peab saama määrata rollile süsteemi kasutusõigused.
• Peakasutaja peab saama vastavalt vajadusele endale lisada kõik olemasolevad rollid, et vigade esinemisel
korrata kõikide kasutajate tegevusi.
• Peakasutaja peab saama rollile määrata isikuid isikukoodi põhiselt.
4.3.2.8.1.2 Konto ja rolli muutmine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole kasutajakonto ja/või rolli muutmiseks.
2. Peakasutaja navigeerib infosüsteemi kasutajakontode või rollide loendisse.
3. Peakasutaja valib kasutajakonto või rolli, mida muuta.
4. Peakasutaja muudab kasutajakontot või rolli.
5. Infosüsteem registreerib muudatuse.
Ärireeglid:
PwC 72
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Rolli muutmisel lõpetatakse vana roll muutmise ajaga ja alustatakse uue rolli kehtivust.
• Peakasutajal peab olema võimalus vajadusel muuta juba olemasolevaid rolle.
• Rolli muutmisel peab saama määrata rolli uusi ja eemaldada rollis olemasolevaid kasutajakontosid.
• Rolli muutmisel peab saama ümber seadistada rollile määratud süsteemi kasutusõiguseid.
4.3.2.8.1.3 Konto ja rolli kustutamine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole kasutajakonto ja/või rolli kustutamiseks.
2. Peakasutaja navigeerib infosüsteemi kasutajakontode või rollide loendisse.
3. Peakasutaja valib kasutajakonto või rolli mida kustutada.
4. Peakasutaja kustutab kasutajakonto või rolli.
5. Infosüsteem registreerib muudatuse.
Ärireeglid:
• Peakasutaja peab saama kõiki kasutajakontosid kustutada.
• Peakasutaja peab saama kõiki rolle kustutada.
• Kasutajakonto kustutamisel eemaldatakse ka kõik sellega seotud rollid.
• Rolli kustutamisel eemaldatakse kustutatud roll kõikidelt kasutajakontodelt, millele see roll oli määratud.
• Kasutajakonto kustutamisel peab infosüsteem selle andmed arhiveerimise eesmärgil säilitama.
4.3.2.8.2 Auditlogi monitooring
Kirjeldus:
1. Peakasutaja navigeerib auditlogi vaatesse.
2. Peakasutaja määratleb soovitud auditlogi parameetrid.
3. Peakasutaja vaatab auditlogi.
Ärireeglid:
• Auditlogi kuvatavad ärireeglid ja parameetrite määramise ulatus täpsustatakse detailanalüüsis.
• Peakasutaja peab saama kõikide kasutajakontode, mis on seotud konkreetse juhtumiga, omavahel
vahetatud sõnumeid vestluse vormis PDF fail kujul välja printida.
4.3.2.8.3 Ohumoodulite haldamine
Kirjeldus:
1. Peakasutaja navigeerib infosüsteemi ohumoodulite loendisse.
2. Peakasutajale kuvatakse ohumoodulite haldamise vaade.
3. Siit vaatest saab käivitada ka teisi kasutuslugusid: 1) Ohumooduli lisamise kasutuslugu (vt Ohumooduli
lisamine) 2) Ohumooduli muutmise kasutuslugu (vt Ohumooduli muutmine) ja 3) Ohumooduli
kustutamise kasutuslugu (vt Ohumooduli kustutamine).
Ärireeglid:
• Peakasutaja peab saama hallata kõiki infosüsteemis olevaid ohumooduleid sh neid 1) lisada 2) muuta ja
3) kustutada.
• Peakasutaja peab nägema infosüsteemis kõikide ohumoodulite nimekirja.
• Peakasutaja peab saama ohumoodulite nimekirja filtreerida vabatekstilise otsingu abil.
• Peakasutaja peab saama avada ohumoodulite nimekirjast vaate valitud ohumooduli andmetele.
PwC 73
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4.3.2.8.3.1 Ohumooduli lisamine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole uue ohumooduli lisamiseks.
2. Peakasutaja navigeerib infosüsteemi ohumoodulite loendisse.
3. Peakasutaja valib uue ohumooduli lisamise.
4. Peakasutaja lisab uue ohumooduli.
5. Infosüsteem registreerib muudatused.
Ärireeglid:
• Peakasutaja peab saama uut ohumoodulit lisada.
• Sõltuvalt lisatud ohumooduli valdkonnast, ei pea ettevõtted, kes antud valdkonna riskianalüüsi juba
teinud on, uuesti riskianalüüsi tegema, vaid uus ohumoodul lisatakse neile hilisema riskianalüüsi
uuendamise käigus.
• Uutele ettevõtetele, kes veel riskianalüüsi teinud ei ole, rakendub muudatus koheselt.
4.3.2.8.3.2 Ohumooduli muutmine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole ohumooduli muutmiseks.
2. Peakasutaja navigeerib infosüsteemi ohumoodulite loendisse.
3. Peakasutaja valib ohumooduli muutmise.
4. Peakasutaja muudab ohumooduli andmeid, nt täiendab ohumooduli nõutud kaitsevahendite nimekirja.
5. Infosüsteem registreerib muudatused.
Ärireeglid:
• Peakasutaja peab saama ohumooduleid muuta.
• Sõltuvalt muudetud ohumooduli valdkonnast ei pea ettevõtted, kes antud ohumooduli riskianalüüsi
käigus juba täitnud on, uuesti riskianalüüsi tegema, vaid muudetud ohumooduli muudatused lisatakse
neile hilisema riskianalüüsi uuendamise käigus.
• Uutele ettevõtetele, kes veel riskianalüüsi teinud ei ole, rakendub muudatus koheselt.
4.3.2.8.3.3 Ohumooduli kustutamine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole ohumooduli kustutamiseks.
2. Peakasutaja navigeerib infosüsteemi ohumoodulite loendisse.
3. Peakasutaja valib ohumooduli kustutamise.
4. Peakasutaja kustutab ohumooduli.
5. Infosüsteem registreerib muudatused.
Ärireeglid:
• Peakasutaja peab saama ohumooduleid kustutada.
• Sõltuvalt kustutatud ohumooduli valdkonnast ei pea ettevõtted, kes antud ohumooduli riskianalüüsi
käigus juba täitnud on, uuesti riskianalüüsi tegema, vaid kustutatud ohumoodulit ei kuvata neile enam
hilisema riskianalüüsi uuendamise või täiesti uue riskianalüüsi tegemise käigus.
• Uutele ettevõtetele, kes veel riskianalüüsi teinud ei ole, rakendub muudatus koheselt.
4.3.2.8.4 Hinnangulehtede haldamine
Kirjeldus:
PwC 74
Tööelu infosüsteemi eelanalüüs Lõpparuanne
1. Peakasutaja navigeerib infosüsteemi hinnangulehtede loendisse.
2. Peakasutajale kuvatakse hinnangulehtede haldamise vaade.
3. Siit vaatest saab käivitada ka teisi kasutuslugusid: 1) Hinnangulehe lisamise kasutuslugu (vt
Hinnangulehe lisamine) 2) Hinnangulehe muutmise kasutuslugu (vt Hinnangulehe muutmine) ja 3)
Hinnangulehe kustutamise kasutuslugu (vt Hinnangulehe kustutamine).
Ärireeglid:
• Peakasutaja peab saama hallata kõiki infosüsteemis olevaid hinnangulehti sh neid 1) lisada 2) muuta ja 3)
kustutada.
• Hinnangulehed tuleb üle vaadata vähemalt üks kord aastas.
• Peakasutaja peab nägema infosüsteemis kõikide hinnangulehtede nimekirja.
• Peakasutaja peab saama hinnangulehtede nimekirja filtreerida vabatekstilise otsingu abil.
• Peakasutaja peab saama avada hinnangulehtede nimekirjast vaate valitud hinnangulehe andmetele.
4.3.2.8.4.1 Hinnangulehe lisamine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole uue hinnangulehe lisamiseks.
2. Peakasutaja navigeerib infosüsteemi hinnangulehtede loendisse.
3. Peakasutaja valib uue hinnangulehe lisamise.
4. Peakasutaja lisab uue hinnangulehe ja defineerib seotud kriteeriumid.
5. Infosüsteem registreerib muudatused.
Ärireeglid:
• Kasutaja peab saama uut hinnangulehte lisada.
• Hinnangulehe kriteeriumid:
− Märge, kas tegevus pole nõutav/ohutegur puudub.
− Hinnang nelja palli skaalas: 1) Hea 2) Pigem hea 3) Pigem halb ja 4) Halb.
− Märge kas tegevus/ohutegur on kajastatud ettevõtte riskianalüüsis.
− Märge kas, tegevus/ohutegur on kajastatud ettevõtte tegevuskavas.
− Muud märkused.
4.3.2.8.4.2 Hinnangulehe muutmine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole hinnangulehe muutmiseks.
2. Peakasutaja navigeerib infosüsteemi hinnangulehtede loendisse.
3. Peakasutaja valib hinnangulehe, mida muuta.
4. Peakasutaja muudab hinnangulehe.
5. Infosüsteem registreerib muudatused.
Ärireeglid:
• Kasutaja peab saama kõiki hinnangulehti muuta.
4.3.2.8.4.3 Hinnangulehe kustutamine
Kirjeldus:
1. Infosüsteemi kasutaja pöördub peakasutaja poole hinnangulehe kustutamiseks.
2. Peakasutaja navigeerib infosüsteemi hinnangulehtede loendisse.
3. Peakasutaja valib hinnangulehe, mida kustutada.
PwC 75
Tööelu infosüsteemi eelanalüüs Lõpparuanne
4. Peakasutaja kustutab hinnangulehe.
5. Infosüsteem registreerib muudatused.
Ärireeglid:
• Kasutaja peab saama kõiki hinnangulehti kustutada.
4.4 Mittefunktsionaalsed nõuded
4.4.1 Integratsioon (Integration)
• Infosüsteem peab olema liidestatud järgmiste X-tee teenustega:
− Haigekassa infosüsteem– andmed tööõnnetuste ja töövõimetuspäevade kohta.
− PPA infosüsteem – andmed lähetatud töötajate kohta.
− Ehitisregister - andmed kavandatava või ehitatava ehitise asukoha, ehitamise ja ehitamisega seotud
isikute andmete kohta. Automaatne teade TI-le, kui uue ehituse andmed sisestatakse
ehitisregistrisse.
− Äriregister – andmed ettevõtte registrikoodi, ärinime, registreerimise aja, õigusliku vormi,
juriidilise aadressi, seaduslike ja volitatud esindajate kohta.
− Aadressandmete infosüsteem – andmed ettevõtte aadressandmeväljade täitmiseks.
− EMTA Töötamise register (TÖR) – andmed töötamise, tööd tegeva isiku, tööd võimaldava isiku,
töötamise alustamise aja, töötamise peatumise aja, töötamise lõpetamise aja, töötamise õigusliku
aluse, alla 15-aastase töötegija töötingimuste ning eelloetletud kannete tegemise ja muutmise aja
kohta.
− Liiklusregister – andmed ettevõtte autopargi koosseisu kohta, sõidukijuhtide järelevalve info.
− Liiklusjärelevalve infosüsteem – andmed järelevalvemenetluste ning süüteomenetluse käigus
määratud karistuste õigusliku aluse kohta.
− Majandustegevuse register – andmed ettevõtte tegevusalade, tegevuslubade ning tegevuse
maakonna kohta.
− Rahvastikuregister – andmed isiku perekonnanime, eesnime, soo, sünniaja, isikukoodi,
kodakondsuse, elukoha, sideandmete ning surma kohta.
− E-toimik - andmed TI kui kohtuvälise menetleja poolt läbi viidud väärteomenetluste ning TI-ga
seotud kohtumenetluste kohta.
− Karistusregister - andmed TI kui kohtuvälise menetleja poolt määratud karistuste kohta.
− TARN infosüsteem - andmed TI poolt määratud sunnirahade ning väärteokaristuste sundtäitmise
kohta.
• Kogu infosüsteem on kontopõhine – ettevõtte konto tekib registrikoodi põhjal, isikukonto tekib
isikukoodi põhjal.
• Kõik andmed on infosüsteemis seotud kas ettevõtte registrikoodi ja/või isikukoodiga.
• Olemasolevast ITI infosüsteemist tuleb migreerida vajalikud andmed uude tööelu infosüsteemi. Andmete
koosseis täpsustatakse detailanalüüsi käigus.
4.4.2 Turvalisus (Security)
• Rakendus peab olema kirjutatud arvestades selle rakenduse poolt töödeldavatele andmetele määratud
ISKE 44 turvaklassi nõudeid T2K2S2.
• Süsteem peab võimaldama kasutajate tegevuse logimist ja logide monitooringut.
• Süsteem peab säilitama logid süsteemi ja kasutajate tegevuste kohta.
44 https://www.ria.ee/ee/iske-kkk.html
PwC 76
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Süsteemi auditlogi ei kustutata infosüsteemist mitte kunagi ei infosüsteemi ega peakasutaja poolt.
• Süsteem peab kasutajaid tuvastama kasutades 1) ID-kaarti 2) Mobiili-ID-d või 3) Smart-ID-d.
• Süsteemis olevaid kinnitusi peab kasutaja saama vajadusel kinnitada (sh digiallkirjastada)
tuvastusvahenditega (ehk tuvastusvahendite PIN2).
• Veebirakendus peab probleemideta läbima OWASP ASVS baasil põhineva testi. Kui pole arenduses eraldi
kokku lepitud teisiti, siis on OWASP ASVS 3.0 tasemeks 2 45. Kinnise lähtekoodiga kommertstoote
kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile. Tellija poolset turvatestimist teostab kolmas
sõltumatu pool. Selline esmane kolmanda poole turvatestimine tellitakse tellija finantseeringul. Ilmnenud
vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui
tellija vastava nõudmise esitab.
4.4.3 Kasutatavus (Usability)
• Süsteem peab olema kasutatav kaasaegsetes veebisirvijates, sh mobiilipõhistes (Android, IOS, Windows
Phone). Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel
tootja poolt toetatud versioonid.
• Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale eestikeelse
kasutajasõbraliku veateatega, mis sisaldab soovituslikult ka vea koodi. Veateated peavad olema sellised,
mis võimaldavad IT-abil võimalikult lihtsalt tuvastada vea olemuse ja asukoha.
• Süsteem tuleb luua nii, et süsteemi kasutamine on lihtne sellega igapäevaselt töötavale kasutajale, kui ka
neil, kes sellega igapäevaselt ei tegele, st muuhulgas, et erinevatele kasutajarollidele tuleb tagada erinev
andmemaht ja igale kasutajarollile kuvatakse ainult talle vajalikku funktsionaalsust. Igale kasutajarollile
kuvatakse talle vajalik töölaud, talle vajaliku informatsiooni ja funktsionaalsusega.
• Kasutajainteraktsioonis välditakse olukordi, kus kasutaja ei saa aru, kuidas jätkata.
• Andmete sisestusväljad on tähistatud (st kasutajale on arusaadav, mida tuleb sisestada).
• Kasutajale on arusaadav, kas süsteem aktsepteeris tema tegevuse (hiireklõps, nupuvajutus), sh kasutajale
antakse vastav ja märgatav visuaalne tagasiside (nn mikrointeraktsioon).
• Infosüsteem peab funktsionaalse vea (näiteks kohustuslikkude väljade täitamata jätmisel) korral
kasutajale kuvama kasutajasõbraliku veateate. Veateated peavad olema hallatavad.
• Kasutajaliidese kõik disainiotsused peavad olema kooskõlastatud tellijaga enne nende realiseerimist.
• Rakenduse tausta, menüüde ja teksti värvid peavad olema ilma rakenduse koodi muutmata vahetatavad.
• Teksti taustana mitte kasutada taustamustrit.
• Veebilehitseja aknaid avavaid hüpikaknaid (pop-up) ei tohi kasutada.
• Kasutajaliideses toiminguni (põhi- ehk enamkasutatavad tegevused) navigeerimiseks peab kehtima 3
kliki printsiip, väljalogimiseks 1 kliki printsiip. Kõik rakenduse kasutajaliidesest tehtavad toimingud
tohivad üksteisest olla maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud
saama. Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas.
• Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja massmuutmiste kohta, kui pole kokku
lepitud teisiti.
• Rakenduse kasutajaliides peab teavitama kasutajat ette sessiooni aegumisest. Ette teavitamise aeg peab
olema konfigureeritav.
• Kui vormile sisestatakse mahukaid andmevälju peab kasutajaliides kokku lepitud ajavahemike järel
salvestama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks.
Kui vorm koosneb paljudest väikestest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks ning
salvestatakse vastava etapi lõpus.
• Ebakorrektse sisestuse puhul korrektselt sisestatud vormivälju ei tühjendata.
• Interaktiivsete vormide puhul (näiteks faili üleslaadimine), ei tohiks lehe värskendamisega tegevust
korrata (faili taas üles laadida, andmeid saata, avaldust esitada).
• Kui päring võtab aega kauem kui 3 sekundit, peab kasutaja saama visuaalse teate, et süsteem tegeleb
päringu läbiviimisega. Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut sooritatakse või
muu tellijaga kokkulepitud indikaator.
• Esilehel (sisselogimata) ja ka pärast kasutaja sisselogimist peab olema lihtne võimalus teavitada kasutajat
muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale
45 https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
PwC 77
Tööelu infosüsteemi eelanalüüs Lõpparuanne
märgatav. Näiteks võimalikud teavitused: mingi süsteemi osa on vigane, tuli mingi uus funktsionaalsus,
uuendage isikuandmeid jne.
• Andmeväljade kohustuslikkus peab olema infosüsteemi väljadel märgitud tärniga (*).
• Rakenduse andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses eesti keeles (ilma
kirjavigadeta) ja vajadusel sisaldama selgitavat teksti.
• Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel.
4.4.4 Töökindlus (Reliability)
• Süsteem peab töökindluse tagamiseks järgima Riigi infosüsteemi koosvõime raamistikule kehtivaid
nõudeid 46.
• Rakenduse liidesed peavad olema tõrkekindlad kolmandate osapoolte süsteemide vigade suhtes. Väliste
liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid väljastama mõistliku (võimalikult
lühikese) aja jooksul ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid.
• Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti. Andmebaasi objektide nimetused
peavad olema sisulised ja andma aimu nende otstarbest. Kasutada tuleb vastava andmebaasisüsteemi
nimetamise parimaid praktikaid.
• Tehnilise rikke korral peab süsteem olema taastatav ühe tööpäeva jooksul.
• Süsteemi tuleb varundada iga 24 tunni tagant, maksimaalne andmekadu võib olla seega kuni ühe ööpäeva
jagu andmeid.
• Andmebaas peab toetama nii külm- kui ka kuumvaru (peegeldamist) teise serveriruumi. Ei tohi kasutada
teenuseid, mis välistavad andmebaasi peegeldamist (nt "failstream").
4.4.5 Jõudlus (Performance)
• Failisüsteemi salvestamisel ei tohi ühte kausta tekkida üle 10 000 faili. Failid peab katalogiseerima
kokkulepitud tunnuste alusel (nt aasta, kuu, kuupäev).
• Rakenduse kompileerimine, saidi taaskäivitus, konfiguratsiooni muutmine vms peaks toimuma mõistliku
aja jooksul (maksimaalselt 30 s). Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab
rakendus väljastama selle kohta selge teate.
• Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole
komponendid) ja topoloogia peab olema enne reaalse arenduse algust infrastruktuuri juhiga
kooskõlastatud. Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande
käigus välja toodud jõudlusnäitajatele.
• Süsteemi välised kasutajad paiknevad nii laivõrguühendusega lokaalvõrkudes kui ka avalikes
raadiosideühendusega lokaal- või traadita laivõrgus. Sellest sõltuvalt peab süsteem olema optimeeritud
kasutamiseks ka aeglasema (alla 100kB/s) või katkendliku ühendusega võrkudes, nt maapiirkondades,
kus interneti levi võib olla kesine.
• Süsteemi funktsioneerimine peab olema tagatud töökiiruse languseta vähemalt viiekümne (50)
paralleelse autenditud kasutaja korral (sh avalduse registreerimise ja esitamisega seotud
funktsionaalsused).
4.4.6 Toetatavus (Supportability)
• Lahenduse X-tee teenused peavad vastama RIA nõuetele. 47
• Lahendus peab vastama Sotsiaalministeeriumi haldusala IT-profiilile 48.
• Lahendus peab vastama veebide koosvõime raamistikule. 49
46 https://www.mkm.ee/et/riigi-infosusteemi-koosvoime-raamistik
47 https://www.ria.ee/ee/xtee-juhendid.html
48 https://wiki.sm.ee/display/AV/IT-Profiil
49 https://www.mkm.ee/sites/default/files/veebide_raamistik.pdf
PwC 78
Tööelu infosüsteemi eelanalüüs Lõpparuanne
• Rakenduse, andmebaasi ja kolmanda osapoole komponendid peavad olema sellised, mille eluea lõpp
(EOL) pole teadaolevalt vähem kui 2 aasta pärast. Arendaja loodud lahenduse dokumentatsioonis (nt
detailanalüüs vms) peab olema välja toodud kasutatavate komponentide nimetused ja versioonid.
Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea lõpuks, st versiooni tugi võib aeguda, kui
uus versioon on välja lastud.
• Rakenduse värviskeem ja logo kasutamine peab vastama Tellija ametlikule visuaalsele identiteedile (CVI)
ja disainijuhistele (UIG). Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka vastav SF
sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida
tellijalt.
• Süsteemi seadeid peab saama hallata graafilise kasutajaliidese vahendusel. Kasutajaliidese kõik osad ja
teated peavad olema eestikeelsed. Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud
hankedokumentides.
• Kasutajaliides peab olema ilma rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole
kokkulepitud teisiti. Uue keele lisamine peab olema teostatav konfiguratsiooni failist või
administreerimisliidesest. Toetatud peavad olema järgmised keeled: eesti keel, vene keel ja inglise keel.
• Veebirakenduse kasutajaliides peab vastama vähemalt WCAG 2.0 tasemele AA. 50
• Lahendus peab kasutama 64-bitist arvutiarhitektuuri, kui ei ole kokku lepitud teisiti.
• Infosüsteem peab kasutama serveri kellaaega ja ajatsooni.
• Kõik andmed, andmebaasid, SQL skriptid ja rakendus peavad kasutama UTF-8 kodeeringut.
Alternatiivina on kokkuleppel tellijaga lubatud ka UTF-16.
• Veebipõhine kasutajaliides peab ühilduma täielikult standarditega vähemalt HTML 4.01 ja CSS 2.1,
eelistatult HTML 5 ja CSS 3. Valideerimiseks kasutatakse vastavaid validaatoreid 51. Kui on tegu
olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni.
• Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude,
kui ka kasutajate arvu osas.
• Kui infosüsteem saadab e-kirju, peab see kasutama välist mailiserverit. Kirja saatmisel peab rakendus
veenduma, et e-mailiserver võttis meili vastu. E-kirjade vormindamine peab järgima interneti
standardeid (RFC 5322). Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on
muudetavad konfiguratsioonifaili kaudu. Genereeritud kirjade puhul peab tagama kirjade jälitatavuse
(näiteks lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja
genereeris jms abistav info).
• Veebirakendus ei tohi seada erilisi nõudeid kasutaja tarkvarale ega riistvarale (platvormi valiku või
jõudluse suhtes). Andmete edastus peab välisvõrgu liikluses olema kaitstud kasutades turvalisi ja
üldteada andmeedastusprotokolle.
50 http://www.w3.org/TR/WCAG20/
51 http://validator.w3.org/
PwC 79
Tööelu infosüsteemi eelanalüüs Lõpparuanne
5 Infosüsteemi realiseerimine
Peatükis on kirjeldatud IT arenduse maksumus ja realiseerimise projekti kirjeldus koos vajalike
kompetentsidega.
5.1 IT-arenduse maksumus
Uue tööelu infosüsteemi arendamise kulude väljaselgitamiseks kasutasime sisendit tarkvaraarendusega
tegelevalt ettevõtetelt, kes võivad tulevikus infosüsteemi arendamisel osaleda. PwC edastas tulevaste
äriprotsesside kirjelduse, infosüsteemi lähteülesande ja tööelu infosüsteemi kasutajate vajaduste uuringu käigus
koostatud prototüübid ja küsis hinnangut andmepäringu vormis. Kõik rahalised hinnangud on tehtud neto
väärtuses.
Tabel 2. Infosüsteemi realiseerimine
Arendaja I Arendaja II Arendaja III
Mahuhinnang Mahuhinnang Mahuhinnang
(tunnid) (tunnid) (tunnid)
Anonüümse kasutaja kasutuslood 48 72 144
Töötaja kasutuslood 188 480 192
Töötaja esindaja kasutuslood 24 100 56
TK-spetsialisti kasutuslood 340 924 644
Juhatuse liikme kasutuslood 18 100 48
TI inspektori kasutuslood 450 760 505
TI juhataja kasutuslood 12 120 36
Peakasutaja kasutuslood 210 1340 231
Integratsiooninõuded (13 infosüsteemi) 660 520 150
Detailanalüüsi koostamine 557 320 200
Visuaalne disain 196 460 120
Andmete migreerimine ITI-st 740 - 160
Arenduse ja testkeskkonna seadistamine 40 - 100
Projektijuhtimine 750 - 300
Testimine 421 - 300
Puhveraeg - - 814
Kokku (h) 4654 5196 4000
Tunnihind (eur/h, km-ita) 50 50 50
Maksumus (eur, km-ita) 232 700 259 800 200 000
Hoolimata standardsest andmepäringu vormist, esines antud hinnangutes metoodilisi erinevusi. Arendaja I ja II
hindasid detailanalüüsi, testimist ja projektijuhtimist eraldi, kuid näiteks arendaja II arvestas need tegevused
arenduse sisse.
PwC 80
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Lähteülesanne kirjeldab ärilisi vajadusi, jättes arendajatele piisava vabaduse tehnoloogilise realiseerimise
teostamiseks (nt programmeerimiskeele või andmebaasi keele valik). Seetõttu esineb varieeruvust
kasutuslugude realiseerimise mahtudes. Mõningate hinnangute puhul on puhveraeg eraldi välja toodud, kuid
teiste puhul on see arvestatud tegevuste sisse, ehk piltlikult öeldes on iga kasutusloo realiseerimise maht selle
võrra suurem. Eelanalüüsi kontekstis on suurimat ja väikseimat mahtu hinnanud arendaja erinevus
aktsepteeritavas vahemikus.
Arenduse maksumuse arvutamisel on arvestuslikuks tunnihinnaks 50 eurot tund, mis peaks vastama Eestis
kehtivale üldisele tasemele. On ettevõtteid, kelle arenduse tunnihind on suurem ja on ka neid, kelle tunnihind
on väiksem.
Võttes kolme arendusettevõtte saadetud hinnangute keskmise, saame uue
tööelu infosüsteemi maksumuseks 230 833 eurot +km.
Andmete migreerimine ITI-st uude infosüsteemi moodustab arendaja I hinnangul 16% ja arendaja III
hinnangul 4% infosüsteemi kogumaksumusest. Mõlemad arendajad rõhutasid vajadust enne täpsema hinnangu
andmist tutvuda ITI andmekogu struktuuriga ja andmekvaliteediga (andmete ülekandmisel on ilmselt vaja
andmeid korrastada). On täiesti realistlik eeldada, et andmete migreerimine võib lõpuks moodustada kuni 20%
kogu infosüsteemi maksumusest. PwC hinnangul ei ole ITI-st andmete migreerimine, arvestades selle
maksumust, mõistlik ja soovitus on jätta ITI infosüsteem paralleelselt uue tööelu infosüsteemiga tööle.
5.2 IT Arendusprojekt
Tööelu infosüsteemi arendamisele võib läheneda mitmel erineval viisil. Üks võimalus on viia läbi arendus
agiilsel meetodil ja teine võimalus on kasutada kosemudelit (waterfall). Avalikus sektoris on levinud neist
viimane, sest seda on lihtsam hankida ja arenduse protsessi on võimalik selgeteks etappideks jagada: nõuete
koostamine, disain, realiseerimine ja testimine. TEHIK võib arendusele mõneti paindlikumalt läheneda ja
kasutada agiilset metoodikat.
Projekti läbiviimiseks on vaja Tellijal järgnevaid kompetentse:
• Tellija peab määrama tooteomaniku, kes on vastutav nõuete püstitamise ja kinnitamise eest.
• Tellija projektijuhti (SCRUM master), kes vastavalt agiilsele metoodikale vaatab tooteomaniku nõuded
üle IT tehnilisest vaatenurgast, jälgib projekti kulgemist ja suhtleb arendaja meeskonnaga.
• Tellija poolne IT arhitekt, kes peab silmas kogu tööelu infosüsteemi tulevast arhitektuuri. Rolli võib
kanda ka kompetentsi olemasolul Tellija projektijuht.
Projekti läbiviimiseks soovitame Pakkujalt nõuda järgnevaid kompetentse:
• Projektijuht – töökogemus tarkvaraarenduse ja/või infosüsteemide ärianalüüsi valdkonnas vähemalt
kolm aastat. Peab olema juhtinud vähemalt kahte sarnase mahuga infosüsteemi arendamise projekti.
• Analüütik – tehnoloogiaalase kõrgharidusega, töökogemus infosüsteemide ärianalüüsi valdkonnas
vähemalt viis aastat. Peab olema osalenud vähemalt kahes sarnase mahuga infosüsteemi arendamise
projektis analüütikuna.
• Kasutajaliidese disainer – peab olema osalenud disainerina vähemalt kahes sarnase mahuga
infosüsteemi arendamise projektis.
• Rakenduse programmeerijad (vähemalt 3) – tehnoloogiaalase kõrgharidusega. Peavad omama
vähemalt kaheaastast programmeerimiskogemust vähemalt kahes sarnase mahuga infosüsteemi
arendamise projektis programmeerijana.
• Süsteemi testija – tehnoloogialase kõrgharidusega. Peab olema osalenud testijana vähemalt kahes
sarnase mahuga infosüsteemi arendamise projektis. Ei tohi olla analüütik ega programmeerija.
PwC 81
Tööelu infosüsteemi eelanalüüs Lõpparuanne
Projekti tegevuskava:
• Hanke korraldamine - Esimene tegevus agiilse lähenemise puhul on leida arenduspartner, kellega
sõlmitakse soovitatavalt raamhanke leping, mille kaudu ostetakse töötunde.
• Arendus - Agiilse metoodika kohaselt tuleb lähteülesanne jagada sprindi etappideks (enamasti 1-2
nädalat). Ühe sprindi tegevused koostatakse tooteomaniku, projektijuhi ja arendaja poolse arutelu
tulemusel ning fikseeritakse sprindi plaanis, kus on kirjas ka iga töö ja sprindi realiseerimiseks kasutatav
aeg. Pärast sprindi lõppu vaadatakse tehtud tööd üle ja kinnitatakse. Ülevaatamise puhul on oluline nii
tooteomaniku kui ka projektijuhi poolne kinnitus, et tulemused vastavad kokkulepitule. Tooteomanik
võib kaasata ka teisi infosüsteemi kasutajaid, kuid oluline on operatiivsus. Tasu arveldatakse pärast
sprintide lõppu. Sprintide väliselt, kuid paralleelselt, töötab arendaja poolel ka analüütik, kes aitab
tulevasi sprinte ette valmistada.
Oluline on tagada tooteomanikule ja projektijuhile piisava ajalise ressursi olemasolu, et osaleda sprindi
koosolekutel ja tulemite ülevaatamisel.
• Vastuvõtmised - Täiendavalt võib kaaluda teatud hetkedel väliste osapoolte kaasamist. Näiteks pärast
riskianalüüsi mooduliga sobivale kaugusele jõudmist kaasatakse mõned ettevõtjad ja küsitakse
tagasisidet. Samuti on soovitatav projekti hilisemates faasides viia läbi turvatestimised, kasutades
testimisel välist ja sõltumatut osapoolt.
• Infosüsteemi käivitamine – infosüsteem paigaldatakse toodangukeskkonda ja tehakse avalikuks. Toimub
avalikkusele suunatud kommunikatsiooniplaani realiseerimine, kasutajate tagasiside töötlemine, aktiivne
arendaja poolne tugi ja kiire reageerimine esilekerkivate probleemide lahendamiseks.
Arendajatelt saadud hinnangu põhjal kulub projekti läbiviimiseks pärast hankelepingu sõlmimist 6-9 kuud.
PwC 82
Tööelu infosüsteemi eelanalüüs Lõpparuanne
6 Lisad
6.1 Intervjueeritavad
Tabel 3. Intervjueeritavad
Intervjueeritava nimi Asutus või ettevõte Intervjuu kuupäev
Maret Maripuu Tööinspektsioon 13.02.18
Meeli Miidla-Vanatalu Tööinspektsioon 13.02.18
Apo Oja Tööinspektsioon 13.02.18
Rauno Piirsalu Sotsiaalministeerium 14.02.18
Seili Suder Sotsiaalministeerium 14.02.18
Karin Reinhold TTÜ 14.02.18
Marina Järvis TTÜ 14.02.18
Indrek Avi Tööinspektsioon 19.02.18
Mari-Liis Ivask Tööinspektsioon 19.02.18
Piret Kaljula Tööinspektsioon 19.02.18
Angelica Maasikas Tööinspektsioon 20.02.18
Eneken Hiire Tööinspektsioon 20.02.18
Marika Liiv Tööinspektsioon 20.02.18
Jüri Milov Tööinspektsioon 22.02.18
Aile Salundi Tööinspektsioon 22.02.18
Kalmer Kärblane Tööinspektsioon 22.02.18
Egne Kurvits Rimi Eesti Food AS 14.03.18
Kaie Nellis Tartu Ülikooli Kliinikum SA 14.03.18
Raido Raud Raua Ehitus OÜ 20.03.18
Uku Velbri Estonia Klaverivabrik AS 20.03.18
Mario Käära Maiasmokk OÜ 20.03.18
Siiri Elleste Merchants House Hotel 20.03.18
Mari Tupits Mainor Ülemiste AS 21.03.18
Kenno Pirnpuu GBS Produkter OÜ 21.03.18
Margit Eskel Mentha OÜ 21.03.18
Kristel Marmor Tea Keeleõpetuse AS 21.03.18
PwC 83
Tööelu infosüsteemi eelanalüüs Lõpparuanne
www.pwc.ee
© 2018 AS PricewaterhouseCoopers Advisors. Kõik autoriõigused kaitstud. “PwC” viitab Eesti seaduste alusel asutatud ja tegutsevale
äriühingule AS PricewaterhouseCoopers Advisors või kontekstist lähtuvalt teistele PricewaterhouseCoopers International Limited
rahvusvahelise võrgustiku liikmetele, kellest igaüks on eraldiseisev ja sõltumatu juriidiline isik.
www.pwc.ee Lõpparuanne
Tööelu
infosüsteemi
kasutajate
vajaduste
analüüs
Lõpparuanne
Sotsiaalministeerium
15. mail 2018
Lõpparuanne
Rauno Piirsalu
Sotsiaalministeerium
Gonsiori 29
Tallinn 15027
15. mai 2018
Austatud Rauno Piirsalu
Käesolev aruanne on koostatud AS PricewaterhouseCoopers Advisors (“PwC”) poolt
Sotsiaalministeeriumile vastavalt Sotsiaalministeeriumi ja PwC vahel 26. veebruar 2018 sõlmitud
lepingule (“Leping”).
Aruanne on koostatud Tööelu infosüsteemi kasutajate vajaduste analüüsi eesmärgil.
Aruandes sisalduv info pärineb mitmest allikast ja me ei ole Projekti raames hinnanud nende
infoallikate usaldusväärsust ega testinud sealt pärineva info tõepärasust. Meie töö näol pole tegu
kindlust andva audiitorteenusega ja selles sisalduvat finants- ega muu info õigsuse osas pole läbi
viidud kontrollprotseduure, välja arvatud eraldi sätestatud juhtudel. Seetõttu ei vastuta PwC
aruande täpsuse ega täielikkuse osas.
Käesoleva dokumendi näol on tegu aruande lõpparuandega. Juhul kui järeldused lõppversioonis
erinevad meie poolt esitatu varasemate diskusioonide käigus väljaöeldust või vahearuandes
kirjutatust, tuleks eelistada neid, mis on lõpparuandes.
Käesoleva aruande sisu pole lubatud teha kättesaadavaks teistele isikutele, välja arvatud Lepingus
sätestatud juhtudel ning vastavatel tingimustel. PwC kannab aruandega seoses õiguslikku vastutust
Lepingus sätestatud ulatuses üksnes Sotsiaalministeeriumi ja mitte ühegi teise osapoole ees, kes võib
oma otsustes olla tuginenud selles aruandes sisalduvale teabele või seisukohtadele.
Aruannet puudutavates küsimustes võtke palun ühendust Mihkel Lauk-iga, 614 1800 ja
[email protected] või Teet Tender-iga, 614 1800 ja
[email protected]
Täname Teid ja Teie töötajaid meeldiva koostöö eest.
Lugupidamisega
Teet Tender
AS PricewaterhouseCoopers Advisors
AS PricewaterhouseCoopers Advisors, Pärnu mnt 15, 10141 Tallinn, Registrikood: 10325507
T: 614 1800, F: 614 1900,
[email protected], www.pwc.ee
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Oluline teadaanne isikutele, kes ei ole aruande adressaadid
Isikud, kes ei ole käesoleva aruande adressaadid ja seda aruannet loevad, loetakse ta nõustunuks
alljärgnevate tingimustega:
1) Aruannet lugev isik võtab teadmiseks, et AS PricewaterhouseCoopers Advisors on selle
koostanud vastavalt oma kliendilt saadud juhistele ning üksnes kliendi huvisid ja kasu silmas
pidades.
2) Aruannet lugev isik tunnistab asjaolu, et ta pole selle aruande adressaat ning vastamaks tema
huvidele ja vajadustele oleks võinud aruande koostamiseks osutuda vajalikuks läbi viia
teistsuguseid või täiendavaid töid.
3) Lugejal pole vastuväited asjaolule, et AS PricewaterhouseCoopers Advisors, selle juhtorganid,
töötajad ega esindajad ei vastuta mingil kujul kahju ega saamata jäänud tulu eest, mis
õigusvastaselt aruandega tutvunud isikule sellega seoses kaasneda võivad.
PwC Page 3 of 29
Lõpparuanne
Uuringu autorid
Kaarel Koosapoeg
Jako Ülenõmm
Mihkel Lauk
Anna-Liisa Palatu
Uuringu juhtrühm
Tabel 1. Uuringu juhtrühm
Juhtrühma liige Asutus/organisatsioon/ettevõte
Rauno Piirsalu Sotsiaalministeerium
Seili Suder Sotsiaalministeerium
Meeli Miidla-Vanatalu Tööinspektsioon
Rainer Rohtla Tervise ja Heaolu Infosüsteemide Keskus
Kaido Kütt Tervise ja Heaolu Infosüsteemide Keskus
Mõisted ja lühendid
Nr Mõiste, lühend Selgitus
1 TI Tööinspektsioon
2 RA Riskianalüüs
3 TK Töökeskkond
AS PricewaterhouseCoopers Advisors, Pärnu mnt 15, 10141 Tallinn, Registrikood: 10325507
T: 614 1800, F: 614 1900,
[email protected], www.pwc.ee
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Sisukord
Uuringu autorid ........................................................................................................................... 4
Uuringu juhtrühm ....................................................................................................................... 4
Mõisted ja lühendid ..................................................................................................................... 4
1 Sissejuhatus ............................................................................................................................ 6
2 Ülevaade kasutajavajadustest.................................................................................................. 6
2.1 Kommunikatsioon ja andmevahetus TI ning ettevõtjate vahel .............................................................................7
2.2 Riskianalüüsi läbiviimine ....................................................................................................................................... 8
2.3 TI järelevalve läbiviimine ......................................................................................................................................10
2.4 Tööõnnetuste, tööst põhjustatud haigestumiste ja kutsehaigestumiste uurimine ............................................. 11
3 Kasutatavuse testimine prototüübiga ..................................................................................... 13
3.1 Ülevaade testimisest .............................................................................................................................................. 13
3.2 Testimise eesmärk ja põhimõtted ......................................................................................................................... 13
3.3 Testimise sihtrühm ja stsenaariumid ................................................................................................................... 14
3.4 Testimise tulemused .............................................................................................................................................. 15
3.4.1 Inspektori prototüüp ............................................................................................................................. 15
3.4.2 Ettevõtja prototüüp ............................................................................................................................... 24
4 Lisad ...................................................................................................................................... 26
4.1 Lisa 1: Intervjueeritavate nimekiri ....................................................................................................................... 26
4.2 Lisa 2: Prototüübi testijad .................................................................................................................................... 27
4.3 Lisa 3: Prototüübi stsenaariumid ......................................................................................................................... 27
4.3.1 Inspektori prototüüp ............................................................................................................................ 27
4.3.2 Ettevõtja prototüüp ............................................................................................................................... 28
PwC 5
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
1 Sissejuhatus
Analüüsi eesmärgid on tulevase tööelu infosüsteemi Tööinspektsiooni järelevalve mooduli ja tööandjate
riskianalüüsi mooduli kasutajate vajaduste analüüsimine, mille põhjal töötatakse välja infosüsteemi kasutamise
stsenaariumid. Prototüübi väljatöötamise järgselt testitakse stsenaariumeid kasutajate peal.
Analüüs on oluline täiendus paralleelselt toimuva projekti „Tööelu infosüsteemi eelanalüüsi“ käigus
koostatavale arenduse lähteülesandele.
Projekt viidi läbi kolmes etapis:
I etapp - Kasutajate vajaduste kaardistamine. Etapi käigus intervjueeriti Sotsiaalministeeriumi ja
Tööinspektsiooni spetsialiste ning ettevõtjate esindajaid. Eesmärgiks oli tuvastada erinevatele
osapooltele kehtivad kitsaskohad ja koguda ettepanekuid uue infosüsteemi arendamiseks. Etapi käigus
valideeriti ka uue riskianalüüsi lahenduse kontseptsiooni – Iirimaa Health and Safety Authority loodud
BeSmart lahendust1.
II etapp - Stsenaariumite ja prototüüpide ehitamine. Töötati välja stsenaariumid, mida
visualiseerida ja testida prototüübi töötamise käigus. Etapi teine pool keskendus prototüübi
väljatöötamisele, mis viidi läbi kasutades Axure 2 nimelist tarkvara.
III etapp - Prototüüpide testimine ja täiendamine. Testiti prototüüpe Tööinspektsiooni
spetsialistide ja ettevõtjate esindajate peal eesmärgiga hinnata kasutatavust ja tuvastada kitsaskohti.
Tagasiside põhjal täiendati prototüüpe.
Analüüsi tulemid on järgnevad:
Kohtumiste kokkuvõtted, protokollid;
Eriliigiliste kasutajate vajaduste loetelu;
Infosüsteemi kasutusstsenaariumid;
Riskianalüüsi mooduli prototüüp;
Järelevalve mooduli prototüüp;
Prototüüpide testimise kokkuvõte.
2 Ülevaade kasutajavajadustest
Intervjuude tagajärjel kogutud info põhjal on võimalik jagada kasutajate poolt tõstatatud kitsaskohad ja
vajadused nelja peamisesse kategooriasse:
Kommunikatsioon ja andmevahetus;
Riskianalüüsi läbiviimine (vt ka Tööelu infosüsteemi eelanalüüsi dokumendi ptk 4.3 – Riskianalüüsi
korraldamine);
Järelevalve (vt ka Tööelu infosüsteemi eelanalüüsi dokumendi ptk 4.4 – Järelevalve protsessid);
Tööõnnetuste, tööst põhjustatud haigestumiste ja kutsehaigestumiste uurimine (vt ka Tööelu
infosüsteemi eelanalüüsi dokumendi ptk 4.5, 4.6 ja 4.7).
Lisaks uurisime kasutajatelt, mida nad muudaksid tööohutust puudutavas valdkonnas, kui ressursid ei oleks
nende jaoks piiratud. Allolevas tabelis (vt Tabel 2) on kajastatud soovid, mida käesoleva analüüsi käigus
intervjueeritavad ise välja tõid. Tabelis on esile toodud milliseid muudatusvajadusi toetasid erasektori
1 https://www.besmart.ie/
2 https://www.axure.com/
PwC 6
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
esindajad ja milliseid muudatusvajadusi toetasid avaliku sektori esindajad. Number paremas kahes tulbas
näitab ettepaneku esitanud intervjueeritavate arvu.
Tabel 2. Kasutajavajadused
Muudatuse vajadus Avaliku sektori Erasektori
sooviavaldusi sooviavaldusi
Parem ohutuskultuur, tööandjate teadlikkuse ja motivatsiooni tõstmine. 6 3
Info koondamine tsentraalsesse portaali. Osapoolte vaheline suhtlus 2 5
lihtsamaks läbi portaali. Abistav ja selge info portaalis.
Üldine halduskoormuse vähenemine kõikidele osapooltele, vähem 2 3
paberimajandust ja andmete topelt sisestamist.
Inspektorite mõistev ja professionaalsem suhtumine (lahtisem pilk), 1 4
jõupositsiooni vähenemine ja konsulteeriva rolli suurenemine. Vähem
ametlikkust.
Ühtse tööstandardi loomine inspektoritele, järelevalve kvaliteedi 3 1
suurenemine, kontaktjärelevalve vähenemine ja kontaktivaba järelevalve
suurenemine.
Automaatsed meeldetuletused ja andmevahetus infosüsteemist 2 1
tähtaegade lähenedes (nt tervisekontroll).
Järelevalve statistika analüüs ja oluliste järelduste tegemine (nt 3 -
vähenenud tööõnnetused tänu TI tööle). Mõõdikud.
Ühtse süsteemi järgi loodud lihtne riskianalüüs, mis on ka mõõdetav. - 2
Samas peab säilima paindlikkus.
Tööohutusjuhendite kaasajastamine ja lihtsustamine. Peab olema - 1
arusaadavalt loetav kõigile.
Seadusandluse leevendamine alla 50 töötajaga ettevõtetele. - 1
Tööelu infosüsteemi moodul aeg ajalt enesekontrolli teostamiseks läbi - 1
lihtsatele küsimustele vastamise (nt tuleohutuse kontroll korra kuus).
2.1 Kommunikatsioon ja andmevahetus TI ning ettevõtjate
vahel
TI ja ettevõtja omavahelise suhtluse kvaliteet sõltub olulisel määral sellest, kui palju aega ja ressursse osapooled
selleks kasutama peavad. Kui omavaheline suhtlus on ajamahukas, bürokraatlik ja selle käigus tekib palju vigu,
siis osapooled pigem väldivad üksteisega suhtlemist ja tulemus on negatiivne.
Kui suhtlus on kiire, paberivaba ja osapooltel on teada, mida neilt tegelikult oodatakse, siis on tulemus
positiivne. Oluline eeldus positiivseks tulemiks on see, et osapooltele on antud lihtne töövahend nende ootuste
täitmiseks.
TI ja ettevõtjate omavaheline kommunikatsioon toimub hetkel viiel erineval viisil:
1) E-post;
2) Telefon;
3) Tavapost;
4) TI ja subjekti omavaheline kohtumine (nt järelevalve teostamine subjekti juures või subjekti kutsumine
TI kontorisse);
5) ITI ja ETI infosüsteemid.
PwC 7
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Omavaheline andmete vahetamine toimub valdavalt e-posti ja paberdokumentide vahetamise teel. Puudub
kontaktivaba järelevalve teostamise võimalus. Paberdokumente esitatakse inspektorile üle vaatamiseks
kontaktjärelevalve käigus ettevõttes kohapeal või harvemal juhul saadetakse tavaposti teel. Inspektor saab
nendega järelevalve teostamisel kohapeal tutvuda ja vajadusel hilisemaks analüüsimiseks kaasa võtta.
Paberdokumentidega tutvumine kohapeal ja nendest olulise info leidmine on pealiskaudne, sest osapooltel on
vähe aega ja paberdokumendid valdavalt mahukad.
Elektrooniliste dokumentide ja tõendusmaterjalide vahetamine toimub suures osas peale inspektori teostatud
kontaktjärelevalvet ja ettekirjutuse koostamist, kui ettevõtja peab inspektori välja toodud rikkumiste
kõrvaldamist tõendama. Ettevõtja saadab inspektori e-postile tõendi rikkumise kõrvaldamise kohta nt foto,
täiendkoolituse läbimise tunnistuse või ka vabatekstilise seletuse. Ettevõtjal on võimalus ka osa infot otse eTI
kliendiportaali laadida, kuid selle protsessi keerukuse tõttu eelistatakse e-posti teel lähenemist.
Inspektoril on kohustus elektroonilised dokumendid järelevalve infosüsteemi ITI ülesse laadida ja vastavad
andmed sisestada, et kõik dokumendid oleksid järelevalvejuhtumiga seotud. Kuna ITI infosüsteem on
vananenud, siis tuleb inspektoril mitmel juhul ettevõtja saadetud dokument ja e-kiri välja printida, uuesti
sobivas vormingus sisse skaneerida ja seejärel infosüsteemi uuesti ülesse laadida.
Kokkuvõtvalt saab öelda, et TI ja ettevõtjate omavaheline kommunikatsioon on hetkel aeglane, selles on palju
bürokraatiat ja tarbetut paberdokumentide genereerimist. Osapooled ei tea, mida neilt oodatakse ja millised
töövahendid nende ootuste täitmiseks üldse eksisteerivad.
Kommunikatsiooniprotsessi parendamiseks eksisteerivad selged vajadused:
1) Viia osapoolte vaheline kommunikatsioon ühtsesse tsentraalsesse elektroonilisse tööelu
infosüsteemi. Teadete vahetamine osapoolte vahel peab olema lihtsas sõnumite vahetamise vormis.
Selline lähenemine hoiab osapoolte aega kokku ja vähendab bürokraatiat, sest kõik osapooled teevad
toiminguid ja töötlevad infot ühes infosüsteemis. Alati on näha vestluse ajalugu, tunduvalt väheneb
vigade tekkimise oht, puudub vajadus andmeid topelt sisestada ja infosüsteem saadab ise osapooltele
tähtaegade lähenedes meeldetuletusi.
2) Vähendada mentaliteeti, et töökeskkonnas peab alati eksisteerima mingi rikkumine.
Läbiviidud intervjuude käigus tuli mitmelt tööandjalt välja negatiivne kogemus, et inspektorite poolt on
seatud normiks, et ilma rikkumisteta töökeskkonda ei eksisteeri. Selline suhtumine pärsib tugevalt
osapoolte vahelist kommunikatsiooni ja mõjutab seda negatiivselt.
3) Ühtlustada kontrollimise läbiviimise protseduure inspektorite seas ja tõsta ettevõtjate
teadlikkust. Kui osapooled saavad reaalselt aru, mida neilt tegelikult oodatakse ja millised on
töövahendid nende ootuste täitmiseks, siis mõjutab see osapoolte vahelist kommunikatsiooni positiivselt.
Sisuliselt on soov, et järelevalve osas kehtiksid samad reeglid kõigile ja sõltuvus inspektorite isiklikest
kogemustest ja eelistustest väheneks. See aitab suurendada läbipaistvust.
4) Suurendada inspektori nõustavat rolli ja vähendada jõupositsioonilt lähenemist. Inspektori
ja tööandja vahelisel suhtlemisel peab vähenema range ametlikkus. Osapoolte vaheline ühine eesmärk on
luua ohutu töökeskkond ja töökultuur.
2.2 Riskianalüüsi läbiviimine
(vt ka Tööelu infosüsteemi eelanalüüsi dokumendi 4.3 – Riskianalüüsi korraldamine).
Riskianalüüs (RA) on tegevus, millega ettevõtja selgitab välja ja hindab töökeskkonna ohutegureid, mis võivad
töötajaid kahjustada. Näiteks ebapiisav valgustus, sundasendis töötamine, kokkupuude kemikaalide või pideva
müraga.
Ettevõtjal on oma töökeskkonna RA läbiviimine seadusega kohustuslik, kuid selle koostamise metoodikat ei ole
talle ette antud. Igal ettevõtjal on vaba voli otsustada, milline nende RA välja näeb või kes selle koostanud on.
Paljudel juhtudel kasutatakse veebist leitud RA näiteid ja kohandatakse see endale sobivaks. Sellise
lähenemisega puudub ettevõtjal kindlustunne, et TI seda ka aktsepteerib. Samuti puudub RA-l aegumistähtaeg.
PwC 8
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
TI on küll loonud RA koostamiseks Tööbiku 3 töövahendi, kuid see on koostatud juba teadlikule töökeskkonna
(TK) spetsialistile mitte väiksema ettevõtte kasutajale, kes pole töökeskkonna ohutusega niivõrd kursis ja ei
oma ka ajalisi ressursse töövahendi kasutamiseks. Samuti ei ole ettevõtjad Tööbiku olemasolust teadlikud, selle
kasutatavus on madal ning pigem tellitakse RA koostamine sisse väliselt osapoolelt. Riskianalüüsi nähakse
keerulise dokumendina, mida peab koostama vaid TI nõuete täitmiseks ja linnukese kirja saamiseks. (vt ka
Tööelu infosüsteemi eelanalüüsi dokumendi ptk 3.1.2.3 – Infosüsteemide problemaatika).
Väliselt osapoolelt RA-d tellides puudub ettevõtjal samuti kindlustunne, et TI ka seda RA-d aktsepteerib.
Tööandja ei oska hinnata kolmanda osapoole tehtud riskianalüüsi kvaliteeti. Selle sobivus selgub alles
järelevalve käigus ja sõltub suurel määral inspektori kogemusest ja suhtumisest. Kuna RA-ga tutvumiseks on
inspektoril vähe aega, siis valdavalt loeb inspektor seda pealiskaudselt.
RA-d võib pakkuda ükskõik milline ettevõte, sest nõudeid riskianalüüsi kvaliteedile ja seda pakkuvale
ettevõttele ei ole. Riskianalüüsi puhul puudub metoodiline juhend, seda tehakse vabas vormis, paljude riskide
osas on seadusandlus n-ö ümmargune ja määrused neile ebakonkreetsed. Esineb juhtumeid, kus erinevaid
riskianalüüside dokumente lihtsalt kopeeritakse teistele ettevõtetele ja muudetakse ainult mõningaid andmeid.
Teenusepakkuja oskab riskianalüüsi sisse kirjutada ainult need riskide maandamismeetmed, mida hetkel
ettevõttes rakendatakse, teenusepakkujatel puudub sageli kompetents ettevõtte spetsiifilises valdkonnas
täiendavaid maandamisettepanekuid teha. Mida suurem on ettevõte, seda keerulisemaks riskid lähevad (nt
keemilised ja bioloogilised riskid). Teatud juhtudel nõutakse ettevõtetelt riskianalüüsi käigus mõõtmiste (nt
müra tugevus) teostamist, mis teeb ettevõtjale riskihalduse veelgi keerukamaks. Ettevõtjal puudub arusaam,
kas ta peab tellima sertifitseeritud mõõtja või piisab ka lihtsamate vahenditega mõõtmisest (nt müra ja
valgustugevuse mõõtmine läbi nutitelefoni rakenduse).
Intervjuude käigus demonstreeriti intervjueeritavatele ka BeSmart lahendust ja küsiti tagasisidet ja hinnangut,
kas see on rakendatav ka Eestis. (vt ka Tööelu infosüsteemi eelanalüüsi dokumendi ptk 4.3.1.1.2 – Tööandja
riskianalüüsi vaade). Selle käigus saadi kõikidelt intervjuudes osalenud tööandjate poolt väga positiivne
tagasiside. Kõige rohkem toodi esile portaali kasutusloogika lihtsust ka tavatöötajale. Tööandjate poolt
eksisteerib vajadus oma ettevõtte riskianalüüs ise läbi viia, kui seda saaks teha läbi sarnase portaali lihtsatele
küsimustele vastates. Ise riskianalüüsi läbi viies suureneb märkimisväärselt arusaam oma töökeskkonnas
valitsevate ohtude üle ning tekib võimalus neid ohtusid maandada või eemaldada.
RA läbiviimise protsessi parendamiseks eksisteerivad selged vajadused:
1) Luua ühtne ja selge metoodika ning juhised RA koostamiseks. Ettevõtjad ei saa aru, mida neilt
konkreetselt oodatakse. Töötervishoiu ja tööohutuse seadus sätestab ettevõtjal kohustuse läbi viia
riskianalüüs, kuid selle koostamise soovituslikku metoodikat ei ole ette antud. Tööelu.ee veebilehel on
teoreetiline ülevaade riskianalüüsi tegemiseks, kuid see on tervikuna raskesti hoomatav. Igal ettevõtjal on
vaba voli otsustada, milline nende riskianalüüs välja näeb või kes selle koostanud on. Ettevõtted
kasutavad sageli veebist leitud riskianalüüside näiteid, mis kohandatakse enda vajadustele sobivaks.
Sellise lähenemisega puudub ettevõtjal kindlustunne, et riskianalüüs on adekvaatne ja TI seda
aktsepteerib. Ka nendel juhtudel, kus ettevõte ei kohanda leitud riskianalüüsi oma vajadustele, vaid
töötab selle ise välja, puudub kindlustunne selle adekvaatsuse ja ulatuse osas.
Ettevõtjatele eksisteerivad sõltuvalt tegutsemisvaldkonnast palju erinevaid seaduseid ja erinevaid
määruseid. Nendest arusaamine on väiksematele ja ka suurematele ettevõtetele keeruline ja ajamahukas,
nt ei saada aru milliste töökeskkonna ohtude puhul on nende mõõtmine reaalselt vajalik ja milliste puhul
mitte. Puudub teadmine, kas lihtsamad mõõtmised võib ka ise teostada või peab selleks tellima
spetsialisti.
(vt ka Tööelu infosüsteemi eelanalüüsi dokumendi ptk 3.1.2.1 – Tööandjate problemaatika ja ptk 4.3 –
Riskianalüüsi korraldamine).
2) Luua lihtne tsentraalne töövahend (tööelu infosüsteem) RA läbiviimiseks. Ettevõtja peab
oma töökeskkonna riskide hindamiseks saama ise lihtsa töövahendiga RA läbi viia. Töövahend (nt
tsentraalne tööelu infosüsteem) peab olema lihtsasti kasutatav nii suurema kui väiksema ettevõtte puhul
3 TÖÖBIK - http://toobik.ee/
PwC 9
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
ja RA peab saama läbi viia tavakasutaja (nt ettevõtte personalijuht või tegevjuht) vastates lihtsasti
arusaadavatele küsimustele töökeskkonnas paiknevate riskide kohta. Oluline on, et kergesti on võimalik
(nt isikukoodi sisestades) volitada ka teist isikut RA läbi viima või seda kinnitama.
Ettevõtjal peab tekkima peale RA läbiviimist selge arusaam töökeskkonnas valitsevate riskide kohta ja
genereeruma tegevuskava maandamismeetmete rakendamiseks.
Oluline eeldus uue töövahendi loomisele on see, et ka TI peab sellist RA läbiviimise metoodikat täielikult
aktsepteerima.
3) Koolitada ettevõtjaid RA läbiviimisel. Ettevõtja peab aru saama, et riskianalüüsi läbiviimine on
tema enda huvides ja see ei ole bürokraatlik karistusviis ettevõtjaks olemisel. Ettevõtja peab aru saama,
mida riik ikkagi temalt ootab ja millised töövahendid selleks loodud on. Kasutades standardset ja selget
töövahendit riskianalüüsi läbiviimiseks on otstarbekas koostada lühike tutvustav videopõhine
õppematerjal, mis annab nii metoodikast kui ka töövahendist ülevaate. Õppematerjalist veelgi olulisem
on, et uues riskianalüüsi töövahendis oleksid kontrollküsimused ja meetmed sõnastatud piisavalt selgelt,
et nende osas ei tekiks lisamaterjali järgi vajadust.
4) Turundada ja populariseerida tööelu portaali ettevõtjatele. Ettevõtjatel puudub hetkel
arusaam, millised riigi poolt loodud töövahendid olemas on. Tulevikus peab ettevõtjal olema selge
arusaam, millised on loodud tööelu portaali võimalused ja mis kasu ta portaalist saab. Uude infosüsteemi
kasutajate meelitamiseks peaksid seda tutvustavad sõnumid keskenduma tööandjatele pakutavale
väärtusele – riskianalüüsi protsessi lihtsustumine, selgem kommunikatsioon ja halduskoormuse
vähenemine (säästetakse ettevõtjate aega nii riskianalüüsi kui järelevalve kontekstis).
2.3 TI järelevalve läbiviimine
(vt lisaks ka Tööelu infosüsteemi eelanalüüsi dokumendi ptk 4.4 – Järelevalve protsessid).
TI teostatav järelevalve protsess on nii inspektoritele kui ka ettevõtjale koormav ja eksisteerib vajadus selle
muutmiseks. Puudub kontaktivaba järelevalve teostamise võimalus. TI jõuab järelevalvet teostada ainult
mõnele protsendile kogu ettevõtjatest.
Hetkel kasutusel olev infotehnoloogiline lahendus lähtub peamiselt paberdokumentide loomise loogikast,
järelevalve protsessis tekib palju pabertoimikuid ja teostatakse palju käsitööd (vormide täitmine, info topelt
sisestamine infosüsteemidesse). Tööandja ja TI teevad oma toiminguid ja töötlevad infot eraldi süsteemides.
Tööandja saadab inspektorile enda info (e-mailid, paberdokumendid, elektroonilised dokumendid), kes need
ITI järelevalve infosüsteemi sisestab. Selline tegevus raiskab mõlema osapoole aega ja rahalisi ressursse. Selle
asemel saaksid osapooled tegeleda suuremat väärtust loovate tegevustega.
TI järelevalve teostamise protsessi parendamiseks eksisteerivad selged vajadused:
1) Luua kontaktivaba ja automaatjärelevalve võimekus. Automaatjärelevalve ehk infosüsteemi
poolt teostatav järelevalve võimaldab kõikidel protsessi osapooltel saavutada suurema ressursside
kokkuhoiu. Automaatse järelevalve läbimise eelduseks on riskianalüüsi tegemine uues tööelu
infosüsteemis ja ettevõttes selleks vajalike TK esindajate rollide (nt TK-spetsialisti) määramine, lisaks on
võimalik kehtestada täiendavaid tingimusi.
Kontaktivaba järelevalve peamine eesmärk on sarnaselt automaatjärelevalvele osapoolte
halduskoormuse ja aja kokkuhoid. Järelevalve käigus toimub ettevõttega suhtlus, kuid külastus ei ole
vajalik. Sarnaselt automaatjärelevalve protsessile puudub ka siin inspektoril vajadus järelevalve subjekti
külastada.
Kontaktivaba ja automaatjärelevalve võimekus võimaldab TI-l kontrollida rohkem ettevõtteid ja kontrolli
käigus kõikide osapoolte aega kokku hoida. Kontaktivaba ja automaatjärelevalve tuleb luua läbi
tsentraalse tööelu infosüsteemi, mida kasutavad kõik osapooled. Ettevõtja saab infosüsteemi üles laadida
kõik TI jaoks vajalikud dokumendid ja sisestada vajalikud andmed ning inspektor saab nendega soovi
korral tutvuda ja otsustada, kas esineb rikkumisi ja vajadust kontaktjärelevalve jaoks.
PwC 10
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Automaatse järelevalve korral teostab infosüsteem ise ettevõtja suunal lihtsad kontrollid ja koostab
päringute põhjal tööandjale fooripõhise staatusega profiili:
a. Roheline staatus (automaatjärelevalve läbitud, inspektor ei tunne huvi, inspektori sekkumist ei ole
vaja).
b. Kollane staatus (kontaktivaba või kontaktjärelevalve võimalus, inspektori vähene huvi, inspektor
otsustab sekkumise).
c. Punane (kontaktivaba või kontaktjärelevalve võimalus, inspektori suur huvi, inspektor otsustab
sekkumise).
(vt ka Tööelu infosüsteemi eelanalüüsi dokumendi ptk 4.4.1 ja 4.4.2 – Kontaktivaba ja
automaatjärelevalve läbiviimine).
2) Lihtsustada ja kiirendada kontaktjärelevalve teostamist. Kontaktjärelevalve on kõige vähem
eelistatud järelevalve liik järelevalve menetlemise protsessis, sest inspektor peab järelevalvesubjekti
juurde kohale sõitma. Selline lähenemine on TI-le ressursikulukas ja tööandjale koormav.
Kui ettevõte läheb kontaktjärelevalvesse, siis läbi tööelu infosüsteemi saab ettevõtja juba eelnevalt
inspektori soovitud infot sisestada ja vajalikke dokumente üles laadida. Selline lähenemine hoiaks
mõlema osapoole aega märkimisväärselt kokku. Inspektor saab järelevalve teostamisel keskenduda
ainult olulisele ja seeläbi kontrollida rohkem ettevõtteid ning ettevõtja saab keskenduda oma
põhitegevusele.
(vt ka Tööelu infosüsteemi eelanalüüsi dokumendi ptk 4.4.3 – Kontaktjärelevalve läbiviimine).
3) TI inspektoritele tuleb luua ühtne tööstandard järelevalve läbiviimiseks. Neil peavad olema
selged tööjuhised ja arusaam läbiviidavast järelevalve protsessist. Kogu järelevalve protsess peab
toimuma läbi tööelu infosüsteemi. Ka vähese kogemusega inspektor peab suutma järelevalve protsessi
läbi viia samamoodi nagu kogenud inspektor.
2.4 Tööõnnetuste, tööst põhjustatud haigestumiste ja
kutsehaigestumiste uurimine
(vt ka Tööelu infosüsteemi eelanalüüsi dokumendi ptk 4.5, 4.6 ja 4.7).
Tööõnnetuste, tööst põhjustatud haigestumiste (TPH) ja kutsehaigestumiste (KH) uurimisel võib sõltuvalt
juhtumist olla kokku seitse osapoolt:
1) tööandja;
2) töötaja (kannatanu);
3) politsei;
4) uurimistalituse juhataja;
5) inspektor-uurija;
6) kergete õnnetuste haldaja;
7) arst.
Tööandjal on kohustus kõiki tööõnnetusi uurida. Töötaja peab esimesel võimalusel teatama tööandjale igast
temaga juhtunud tööõnnetusest, samuti selle tagajärjel ajutise töövõimetuse määramisest. Tööandja peab TI-le
esitama uurimisraporti ja TI otsustab, kas tegu on tööõnnetusega ja vajab uurimist.
Kuna protsessis on nii mitmeid osapooli, siis on väga oluline, et osapoolte vaheline kommunikatsioon toimuks
kiiresti ja arusaadavalt. Paraku ei toimu see käesoleval hetkel alati nii. Tihti esineb juhtumeid, kus näiteks arst
ei edasta TI-le teatist tööõnnetuse kohta ja tööandja ootab TI vastust.
Samuti on olukordi, kus tööandjale helistab raske tööõnnetuse toimumisel mitu erinevat inspektorit ja teavitab
neid juhtumist. Osapoolte vaheline kommunikatsioon on puudulik.
PwC 11
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
TI pakub tööandjale erinevates tegutsemisvaldkondades tööohutust käsitlevaid publikatsioone, nt töötamine
saepingiga, kuid need juhendid on koostatud liiga keeruliselt ja tavatöötajale raskesti arusaadava
terminoloogiaga. Seega ei täida need neile seatud eesmärki – hoida ära tööõnnetusi.
Tööõnnetuste, TPH ja KH uurimise protsessis eksisteerivad selged vajadused:
1) Luua uus tsentraalne tööelu portaal ja parandada seeläbi protsessis osalevate osapoolte
kommunikatsiooni ja andmevahetust. Menetlemine ja andmevahetus peab toimuma protsessi
algusest lõpuni tööelu infosüsteemis, kus seotud osapooltele on määratud vajalikud õigused. Samuti
toimub infosüsteemis omavaheline suhtlus ja vajalike dokumentide vahetus. Omavahelisest suhtlusest
tekib osapoolel ülevaatlik struktureeritud vestlus, mida on lihtne jälgida. Inspektoril on vaja järelevalveks
teada palju toimub TPH ja KH ettevõtetes, et seeläbi oma tegevust paremini planeerida. Samas KH annab
tööandjatele väärtuslikku informatsiooni, kuidas töötingimusi parandada. Eesmärkide saavutamiseks on
vajalik teha muudatusi ka teistes infosüsteemides, kus TPH-d ja KH-d kirjeldavad andmed esmalt
registreeritakse.
2) Parandada TI pakutavate juhendmaterjalide kvaliteeti. Tööohutusjuhendid peavad olema lihtsa
terminoloogiaga, konkreetsed, selgesti arusaadavad ja suunatud töötajale, kes töövahendiga tööd teeb.
3) Tekitada TI võimekus kogutud andmeid analüüsida ja selle põhjal otsuseid läbi viia.
Sisuliselt kogub TI hetkel ITI infosüsteemi vahendusel järelevalvet tehes erinevaid andmeid, kuid nende
analüüsimiseks on vaja käsitööd teha (andmed eksportida Excelisse ja seal neid analüüsida). Järelevalve
protokolli vahendusel tekkivad andmed ei ole kõik masintöödeldaval kujul, mistõttu tuleb andmed
eksportida, korrastada ja viia masintöödeldavale kujule. Analüütika piiratus ei võimalda seetõttu TI
tegevuse kohta kaugeleulatuvaid järeldusi teha. Puudub selge ülevaade, kas see, et tööõnnetuste arv
mingil aastal vähenes oli tänu suuremale pingutusele järelevalves või oli seal taga muu põhjuslik seos.
Vaja on aru saada, kas suurem pingutus ettevõtete kontrollimisel ja ohtude maandamine ka reaalselt
vähendab järgmisel aastal potentsiaalsete tööõnnetuste arvu.
4) Seotud infosüsteemide arendamine. Tuleb arendada seoseid erinevate infosüsteemide vahel, kus
vajalik info tekib ja viia see õigete osapoolteni. Lähtuda tuleb loogikast, et kasutaja sisestab andmeid ühe
korra ja infosüsteemid vahendavad seda sisestatud infot.
PwC 12
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
3 Kasutatavuse testimine
prototüübiga
3.1 Ülevaade testimisest
Käesoleva analüüsi käigus loodi ettevõtja ja inspektori prototüüp, mille kasutatavust testiti 15 kasutaja peal. Iga
kasutajaga kestis testimine kuni tund aega. Kuna kasutajate hulk oli suur, siis viidi läbi ka grupitestimise
sessioonid, kuhu kaasati kuni neli kasutajat korraga.
Üldine hinnang mõlemale prototüübile oli positiivne. Infosüsteemi tsentraalsus, osapoolte ühtne vaade ning
lihtne omavaheline suhtlemine olid enim esile toodud positiivsed omadused. Kõhklusi infosüsteemi
rakendatavuse osas esines kasutajate poolt, kes esindasid suuremat ettevõtet (rohkem kui 100 töötajat). Nende
poolt toodi peamise murekohana välja see, et nende ettevõtte struktuur on keeruline (rohkelt osakondi ja
erinevaid juhte), puudus arusaam, kuidas erinevate osakondade ja filiaalide riskianalüüse infosüsteemis
teostada, neile erinevaid vastutajaid lisada ja tegevuskava hallata.
Kasutajate poolsed muudatusettepanekud puudutasid valdavalt erinevates infosüsteemi vaadetes neile vajaliku
info puudumist, nt puudus kasutaja tegevusele järgnev kokkuvõttev vaheleht, ei küsitud kinnitust enne teate
edastamist või ettekirjutuse saatmise lehel puudusid viited rikkumiste tabelile.
3.2 Testimise eesmärk ja põhimõtted
Käesoleva analüüsi käigus loodi ettevõtja ja inspektori prototüüp. Prototüüpide loomisel keskenduti inimeste
käitumisele süsteemis. Fookus oli infosüsteemi funktsioonidel ja nende efektiivsel paigutusel.
Testimise eesmärk oli kasutatavuse probleemide ja loogikavigade tuvastamine ning lahendamine loodud
prototüüpides enne nende lõplikku kinnitamist. Kasutatavuse testimise käigus selgitati välja kasutajate
käitumine loodud prototüübis ja leiti ebaloogilisena tunduvad kohad ning tegevused.
Testimisel jälgiti järgmiseid olukordi:
kas kasutaja sai aru, kuidas ja mida teha saab.
kas kasutaja tegi stsenaariumi läbimisel vigu.
kas stsenaariumi läbimisel tehtavad tegevused olid nende jaoks loogilised.
Valdavalt tuleb 80% ühe prototüübi kitsaskohtadest välja juba pärast nelja kasutajaga testimise läbiviimist 4.
Käesoleva analüüsi käigus kaasati kahe prototüübi testimisse kokku 15 kasutajat, mis võimaldas tuvastada
ligikaudu 95% kitsaskohtadest.
Kasutajad, kes testimisse kaasati, ei olnud seotud stsenaariumite loomise ja prototüüpide väljatöötamisega. Iga
kasutajaga kestis testimine kuni tund aega. Kuna kasutajate hulk oli suur, siis viidi läbi ka grupitestimise
sessioon, kuhu kaasati kuni neli kasutajat korraga.
Testi alguses selgitas testi moderaator testimise põhjuseid, testi läbiviimise korda, stsenaariumeid ja kasutajate
õigusi. Testi jooksul paluti kasutajal teostada testimisülesanded ehk stsenaariumid, mille jooksul jälgiti
prototüüpides leiduvaid ebaloogilisusi ja tekkinud veaolukordi.
4 Nielsen, J., Cost of User testing a Website (1998). http://www.useit.com/alertbox/980503.html
PwC 13
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Lisaks jälgis moderaator kasutajatele kõhklusi tekitavaid kohti prototüüpides ja küsis kasutajalt vajadusel
täpsustavaid küsimusi, et aru saada, mis neid põhjustab. Testimise protsessi käigus märkis moderaator
kirjalikult üles kasutajate poolt antud tagasiside ja veaolukorrad.
Testi lõppedes ei peetud vajalikuks igal kasutajal kirjalikult ja personaalselt tagasiside ankeet täita, vaid
täiendav tagasisidestamine toimus suulisel teel. Kui kasutajaid oli rohkem kui üks, siis viidi läbi grupiarutelu.
3.3 Testimise sihtrühm ja stsenaariumid
Käesoleva analüüsi käigus kaasati kahe prototüübi testimisse kokku 15 kasutajat. Täpne kasutajate nimekiri ja
stsenaariumid on leitavad analüüsi lisadest (vt Lisa 2: Prototüübi testijad ja Lisa 3: Prototüübi stsenaariumid).
Kaasati nii TI poolseid kasutajaid sh inspektorid kui ka ettevõtjate poolseid kasutajaid. Mõlemat liiki kasutajate
peal testiti nii inspektori kui ka ettevõtja prototüüpi.
PwC 14
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
3.4 Testimise tulemused
Järgnevalt on välja toodud prototüüpide testimisel tuvastatud probleemid ja muudatusettepanekud.
Tabel 3. Üldine tagasiside mõlemale prototüübile ja muudatusettepanekud
Tagasiside Muudatusettepanek/kommentaar
Vaadata üle kirjavead nt TK esindajate rollid kirjutatakse kokku. Tekst prototüüpides üle vaadata.
Erinevates vaadetes peaks olema n-ö abinupp, kus saab infot ja juhendeid. Prototüüpidesse juhendeid juurde ei lisa. Need täpsustatakse detailanalüüsi
käigus.
Kui tegu on suurema ettevõttega, siis igale osakonnale peaks saama eraldi Sama loogika nagu filiaalipõhisel riskianalüüsi teostamisel.
riskianalüüsi teostada.
Kuidas lahendada uute ehitusobjektide puhul riskianalüüsi teostamine, Detailanalüüsi teema, kuid juba täidetud riskianalüüsi põhja võiks saada üle
enamikul juhul on töötajad ja objekt sarnane. kanda uuele ehitusobjektile. Seejärel saab erisuste olemasolul nt
ohumooduleid juurde lisada või eemaldada.
Kui töötaja lahkub ettevõttest ja tuleb hiljem tagasi, siis kas temaga seotud Detailanalüüsi teema. Vajalik töötaja nõusolek.
ajalugu ja andmed võiksid uuesti üle tulla.
Kuidas seotakse töötajate e-mailid ja teavitused, sest TÖR-is e-maile pole. Töötaja lisab ise oma profiilis enda e-maili või TK-spetsialist lisab töötaja e-
maili teda konkreetse tegevuse eest vastutajaks määrates.
3.4.1 Inspektori prototüüp
Järgnevalt on toodud välja prototüübi ekraanivaated ja seal on märgitud kasutajate poolt välja toodud probleemid. Tabelis paremal on ettepanekud
prototüübi korrigeerimiseks.
PwC 15
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tabel 4. Tuvastatud probleemid ja muudatusettepanekud, inspektori prototüüp
Tuvastatud probleem Muudatus prototüübis
1) Prototüübis ei tehtud muudatust,
sest eraldi menüü loomine ei ole
otstarbekas.
1. Tööõnnetused peaksid olema eraldi
menüüs, sest ei sobi kokku
töötervishoiuga.
PwC 16
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tuvastatud probleem Muudatus prototüübis
2) Lisati töölaual olevasse tabelisse uus
veerg lähenevate tähtaegadega.
2. Inspektori töölaual peaksid olema
menetluste käigus seatud tähtajad (nt
rikkumised), mis hakkavad aeguma.
PwC 17
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tuvastatud probleem Muudatus prototüübis
3) Otsingutulemusele juurde lisati
töötajate arvu veerg.
4) Ettevõte profiili alla lisati veerud,
kus on näha käimasolevad
menetlused ja menetleja.
3. Ettevõtte otsingutulemustes puudub
töötajate arv. See on vajalik info
menetluse alustamiseks.
4. Otsingutulemustest puudu
käimasolevate menetluste arv.
PwC 18
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tuvastatud probleem Muudatus prototüübis
5) Lisati nimekiri kõige tüüpilisematest
dokumentidest, mida on järelevalve
läbiviimiseks vajalik esitada,
inspektoril on võimalik „+“ märgiga
nupule vajutades lisada ka
täiendavaid dokumente.
6) Nimekirja lisati kontrolli liik ehitise
ülevaatus. Vajadus ehitise eelteate
järele lisati arenduse
lähteülesandesse, kuna see info
edastatakse Ehitusregistri kaudu.
5. Sõltuvalt kontrolli eesmärgist kuvada
täielik nimekiri vajalikest dokumentidest
koos linnukese panemise võimalusega.
6. Puudu on kontrolli liik ehitise eelteade ja
ülevaatus.
PwC 19
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tuvastatud probleem Muudatus prototüübis
7) Igale saadetud sõnumile ja lisatud
manusele lisati kuupäev, kellaeg ja
saatja, mis on kasutajale pidevalt
nähtavad.
8) Lisati võimalus vestluse aknas
teostada sõnumite otsimiseks.
9) Peakasutaja saab vestluste ja logide
väljavõtte teha. Vestluse PDF
7. Ettevõttega suhtlemisel puudub teadetel formaadis väljaprintimise võimalus
ja lisatud manustel kuupäev ja kellaeg. igal kasutajal ei ole otstarbekas.
Samuti puudub inimese nimi, kellega Prototüüpi ei muudetud.
inspektor suhtleb. 10) Lisati võimalus teostada töötajate
8. Puudub varasemate sõnumite nimekirja päring TÖR-ist.
otsingukast. 11) Tegu on järelevalvega ja seega ei teki
9. Vestlust peaks saama PDF formaadis siin uurimiskokkuvõtet. Prototüüpi
välja printida. ei muudetud.
12) Lisati nupp töö või töövahendi
10. Soov on näha ettevõtte töötajate
peatamiseks.
nimekirja siin vaates.
11. Uurimiskokkuvõtte saatmine –nupp
puudu (kui tegemist KH või TÕ-ga).
12. Töö või töövahendi peatamine – nupp
puudu.
PwC 20
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tuvastatud probleem Muudatus prototüübis
13) Lisati läbiviidavate toimingute
kirjeldamiseks tabel.
14) Lisati võimalus täiendavate
dokumentide lisamiseks.
15) Lisati lehele nupp prindi kontrolli
protokoll.
16) Vahetati nuppude „saada
kontrollprotokoll“ ja „täida
13. Puudub tabel läbiviidavate toimingute hinnanguleht“ asukoht, et
hinnangulehe täitmine oleks
lisamiseks.
esimesena.
14. Puudub tabel täiendavate dokumentide
17) Lähteülesandes lisati nõue, et
nõudmiseks ettevõttelt. sõidukijuhtide järelevalvega seotud
15. PDF formaati printimine (kui vaja nt rikkumiste puhul saab rikkumise
tähitud kirjana saata). siduda konkreetse töötajaga.
16. Eksiti nuppudega saada Prototüüpi ei muudetud.
kontrollprotokoll ja täida hinnanguleht. 18) Asendati „salvesta ja logi välja“ nupp
17. Kui kontrollitakse sõidukijuhte, siis võiks uue nupuga „salvesta ja tagasi
tabelis olla rikkumisega seotud töötaja. töölauale“. Muudatus viidi sisse
18. Puudu nupp kuidas saab salvestada ja prototüübis läbivalt.
tagasi töölauale. 19) Ettevõtte lisatud manustele lisati
19. Ettevõtte esitatud tõenditel ei näe juurde üles laadimise aeg.
kuupäeva ja kellaaega.
PwC 21
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tuvastatud probleem Muudatus prototüübis
20) Hinnangulehelt kantakse
kommentaari lahter rikkumiste
juurde üle, kui kasutaja hindab
olukorda halvaks või pigem halvaks.
20. Idee, et kui valitakse hinnangulehel 21) Lähteülesandesse viidi sisse ärinõue,
pigem halb/halb, siis läheb see et hinnangulehe saab edastada
automaatselt kontrollprotokolli liiklusjärelevalve infosüsteemi.
rikkumise reale.
21. Kui kontrollitakse sõidukijuhte, siis
hinnangulehte peab saama saata liikluse
järelevalve infosüsteemi.
PwC 22
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tuvastatud probleem Muudatus prototüübis
22) Ettekirjutuse juurde lisati
rikkumiste tabel, otsus, ettekirjutuse
täitmise aeg ja viide õigusaktile.
23) Lisati vaheleht tehtud ettekirjutuse
kokkuvõttega enne ettevõttele
saatmist
24) Lisati veerg ettekirjutuse täitmise
tähtajaga.
22. Ettekirjutuse koostamisel puudub
kontrollprotokolli rikkumiste tabel, ettevõtte
juba tehtud vastuväited ja rikkumiste
paragrahvide valik, millele viidata või
linnukesed märkida.
23. Puudub kinnituse küsimine enne ettekirjutuse
saatmist ettevõttele.
24. Ettekirjutuses määratud kuupäevad
rikkumiste kõrvaldamiseks ei ole kuvatud
inspektori töölaual.
PwC 23
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
3.4.2 Ettevõtja prototüüp
Järgnevalt on toodud välja prototüübi ekraanivaated ja seal on märgitud kasutajate poolt välja toodud probleemid. Tabelis paremal on ettepanekud
prototüübi korrigeerimiseks.
Tabel 5. Tuvastatud probleemid ja muudatusettepanekud, ettevõtja prototüüp
Tuvastatud probleem Muudatusettepanek
1) Lisati menüüsse volituste kehtimise
kuupäev.
2) Ei lisatud ettevõtte profiili alla vaikimisi
kehtivat volituste pikkust.
3) Lisati veerg tunnistuse/dokumendi
kehtivuse kuupäev, see võimaldab
õigeaegselt tunnistusi uuendada. .
1) Volituste kuupäev puudu.
2) Volituste eelnev defineerimine võiks käia
ettevõtte profiili alt (nt meie ettevõttes on
volinikud valitud vaikimisi kaheks aastaks)
3) Puudu tunnistuse kehtimise kuupäev.
PwC 24
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
Tuvastatud probleem Muudatusettepanek
4) Lisati lähteülesandesse nõue, et ettevõtte
poolt ise lisatud mooduleid saab
kustutada. Prototüüpi ei muudetud.
5) Lisati nupp tagasi töölauale.
6) Moodulite järjekorda ei saa muuta, kuna
see funktsionaalsus ei loo süsteemi
lisaväärtust. Prototüüpi ei muudetud.
7) Kõikidele moodulitele saab vastutajaid
lisada, et lihtsustada riskianalüüsi
läbiviimist meeskonnana. Prototüüpi ei
muudetud.
8) Lähteülesandesse lisati ärireegel, et
4) Moodulite kustutamise võimalus puudu. inspektor saab mooduleid märkida ja
5) Ei saa kuidagi tagasi töölauale. kommentaarid lisada, mis kantakse üle
6) Moodulite järjekorda peaks saama muuta rikkumiste alla. Prototüüpi ei muudetud.
nt sorteerin ise olulisuse järgi.
7) Kõikidele moodulitele ei peaks saama
vastutajat lisada.
8) TI inspektor peaks saama erinevatele
ohumoodulitele kommentaare juurde
lisada.
9) Lisati selge vaade, kes kasutaja on ja
9) Rolli valik selgemaks. Sisselogimisel tahan millises rollis. Lisati sisselogimisel
näha kellena sisse login. vaheleht koos rolli valikuga.
PwC 25
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
4 Lisad
4.1 Lisa 1: Intervjueeritavate nimekiri
Tabel 6. Intervjueeritavad
Intervjueeritava nimi Asutus või ettevõte Intervjuu kuupäev
Maret Maripuu Tööinspektsioon 13.02.18
Meeli Miidla-Vanatalu Tööinspektsioon 13.02.18
Apo Oja Tööinspektsioon 13.02.18
Rauno Piirsalu Sotsiaalministeerium 14.02.18
Seili Suder Sotsiaalministeerium 14.02.18
Karin Reinhold TTÜ 14.02.18
Marina Järvis TTÜ 14.02.18
Indrek Avi Tööinspektsioon 19.02.18
Mari-Liis Ivask Tööinspektsioon 19.02.18
Piret Kaljula Tööinspektsioon 19.02.18
Angelica Maasikas Tööinspektsioon 20.02.18
Eneken Hiire Tööinspektsioon 20.02.18
Marika Liiv Tööinspektsioon 20.02.18
Jüri Milov Tööinspektsioon 22.02.18
Aile Salundi Tööinspektsioon 22.02.18
Kalmer Kärblane Tööinspektsioon 22.02.18
Egne Kurvits Rimi Eesti Food AS 14.03.18
Kaie Nellis Tartu Ülikooli Kliinikum SA 14.03.18
Raido Raud Raua Ehitus OÜ 20.03.18
Uku Velbri Estonia Klaverivabrik AS 20.03.18
Mario Käära Maiasmokk OÜ 20.03.18
Siiri Elleste Merchants House Hotel 20.03.18
Mari Tupits Mainor Ülemiste AS 21.03.18
Kenno Pirnpuu GBS Produkter OÜ 21.03.18
Margit Eskel Mentha OÜ 21.03.18
Kristel Marmor Tea Keeleõpetuse AS 21.03.18
PwC 26
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
4.2 Lisa 2: Prototüübi testijad
Tabel 7. Prototüübi testijad
Testija nimi Asutus või ettevõte Testimise kuupäev
Piret Kaljula Tööinspektsioon 17.04.18
Angelica Maasikas Tööinspektsioon 17.04.18
Marika Liiv Tööinspektsioon 17.04.18
Kairit Ehala Tööinspektsioon 17.04.18
Aile Salundi Tööinspektsioon 17.04.18
Egne Kurvits Rimi Eesti Food AS 17.04.18
Raido Raud Raua Ehitus OÜ 17.04.18
Mario Käära Maiasmokk OÜ 17.04.18
Eneken Hiire Tööinspektsioon 18.04.18
Indrek Avi Tööinspektsioon 18.04.18
Jüri Milov Tööinspektsioon 18.04.18
Kalmer Kärblane Tööinspektsioon 18.04.18
Kaire Saarep Tööinspektsioon 18.04.18
Mariko Vahula Tööinspektsioon 19.04.18
Kaie Nellis Tartu Ülikooli Kliinikum SA 19.04.18
4.3 Lisa 3: Prototüübi stsenaariumid
4.3.1 Inspektori prototüüp
Prototüüp on lisatud eraldi manusena „Lisa 4 Inspektori prototüüp HTML.zip“
4.3.1.1.1 Stsenaarium 1 – järelevalve läbiviimine.
Eesmärk: Järelevalve läbiviimine
1) Inspektor Mari Maasikas logib infosüsteemi sisse kasutades ID kaarti ja talle kuvatakse inspektori
töölaud.
2) Inspektor valib oma tööülesannete vaate, kus on kirjas talle määratud ettevõtted kontrollimiseks.
3) Inspektor lisab uue ettevõtte Parim Ehitus OÜ, keda kontrollida.
4) Inspektor alustab järelevalvet ja saadab välja teavituse, kus märgib ära dokumendid, millega ta soovib
tutvuda.
5) Tööandja laeb üles dokumendid sh riskianalüüsi, millega inspektor saab tutvuda, enne visiiti.
6) Inspektor tutvub ettevõtte profiiliga ja üles laetud riskianalüüsiga enne ettevõtte külastamist.
7) Inspektor külastab ettevõtet ja täidab hinnangulehe koos kontrollprotokolliga, märkides ära rikkumised.
8) Tööandja tutvub rikkumistega ja esitab iga rikkumise juurde tõendid (tekst, fail ja foto), millega tõendab
rikkumise kõrvaldamist.
9) Inspektor tutvub esitatud tõenditega ja hindab, kas need on piisavad kinnitamaks rikkumise
kõrvaldamist.
PwC 27
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
10) Pärast rikkumise kõrvaldamist soovib Inspektor ettevõtte tähelepanu juhtida mõningatele aspektidele ja
küsida täiendavaid küsimusi rikkumise kõrvaldamise tõendite osas.
11) Inspektor saadab ettevõttele sõnumi.
12) Tööandja vastab sõnumile.
13) Suhtlus registreeritakse järelevalve juhtumi juures.
14) Inspektor otsustab, kas juhtum lõpetada või on vaja koostada ettekirjutus.
15) Inspektor otsustab koostada ettekirjutuse.
16) Inspektor täidab ettekirjutuse vormi ja edastab selle ettevõttele.
17) Stsenaarium on läbitud.
4.3.2 Ettevõtja prototüüp
Prototüüp on lisatud eraldi manusena „Lisa 5 Ettevõtja prototüüp HTML.zip“
4.3.2.1.1 Stsenaarium 1 – rollide määramine.
Eesmärk: anda töökeskkonna spetsialisti roll ettevõtte töötajale Mari Maasikale.
18) Ettevõtte Köögivili OÜ juhatuse liige Jaan Juurikas (edaspidi tööandja) logib smart-ID-d kasutades sisse
tööelu infosüsteemi.
19) Tööandja valib töölaualt oma ülesannete alt töökeskkonna esindajate määramise.
20) Tööandjale kuvatakse TK esindajate rollid ja iga rolli taga on rippmenüü töötajate nimekirjaga.
21) Tööandja valib töökeskkonna spetsialistiks personalispetsialisti Mari Maasika, usaldusisikuks Rein
Redise, esmaabiandjaks Valeria Vaarika ja volinikuks Kaarel Kaalika.
22) Pärast valiku kinnitamist viiakse tööandja tagasi oma töölauale.
23) Tööandja logib infosüsteemist välja.
24) Esimene stsenaarium on läbitud.
4.3.2.1.2 Stsenaarium 2 – TK esindajate määramine ja riskianalüüsi läbiviimine.
Eesmärk: vaadata üle TK esindajate rollid ja läbi viia töökeskkonna riskianalüüs.
1) Köögivili OÜ TK-spetsialist logib tööelu infosüsteemi sisse kasutades ID-kaarti või mobiili-ID-d.
2) TK-spetsialistile kuvatakse tema personaalne töölaud koos temale määratud tegevustega.
3) TK-spetsialist vaatab järgmise ülesandena üle TK esindajate volitused ja rollid.
4) Kolmanda ülesandena valib TK-spetsialist ettevõtte riskianalüüsi koostamise.
5) EMTAK koodi põhjal kuvatakse talle vastav tegevusvaldkond, kuid ta saab seda soovi korral korrigeerida.
TK-spetsialist kinnitab talle pakutud tegevusvaldkonna.
6) TK-spetsialistile kuvatakse vastavalt tema ettevõttele standardsed ohumoodulid. TK-spetsialist otsustab
sinna ohumooduleid juurde lisada. Ta lisab juurde kolm uut moodulit: 1) radoon 2) müra ja 3)
vibratsioon.
7) TK-spetsialist alustab ohumoodulite täitmist valides ohumooduli ELEKTER.
8) TK-spetsialist vastab ohumooduli küsimustele.
9) TK-spetsialistile kuvatakse maandamismeetmed, mida ta ei ole rakendanud ja ta otsustab need lisada
tegevuste nimekirja.
10) Seejärel saab töökeskkonna spetsialist määrata tegevuskavva lisatud tegevustele vastutajad. Ta valib
tulekustutite eest vastutajaks Rein Redise ja katkiste juhtmete eest vastutajaks Kaarel Kaalika.
11) TK-spetsialist logib infosüsteemist välja.
12) Teine stsenaarium on läbitud.
PwC 28
Tööelu infosüsteemi kasutajate vajaduste analüüs Lõpparuanne
www.pwc.ee
© 2018 AS PricewaterhouseCoopers Advisors. Kõik autoriõigused kaitstud. “PwC” viitab Eesti seaduste alusel asutatud ja tegutsevale
äriühingule AS PricewaterhouseCoopers Advisors või kontekstist lähtuvalt teistele PricewaterhouseCoopers International Limited
rahvusvahelise võrgustiku liikmetele, kellest igaüks on eraldiseisev ja sõltumatu juriidiline isik.
Tööelu Infosüsteemi arendustööd H ooldustööde osutamise reeglid Hooldustööde osutamise reeglid on koostatud tänase parima teadmise põhjal . S õltuvalt Tellija ko nkreetsest vajadusest ja hooldustööde tellimise ajast võivad hooldustööde teostamise t ingimused tellimuse esitamisel muutuda või täieneda . T e llitavad tööd Tegevused Tulemus 1. Rakenduse ja selle liideste töös probleemide tuvastamine ja lahenduste leidmine; Logide analüüs Plumberi analüüs Andmebaasi andmete analüüs Nende tegevustega seotud arendustööd muudatusettepanek veapilet tagasiside kliendile nt rakendus käitub vastavalt analüüsile või konsultatsioon funktsionaalsuse korrektseks kasutamiseks 2. Vigaste andmete tuvastamine andmebaasis; Logide analüüs Andmebaasi andmete analüüs Nende tegevustega seotud arendustööd muudatusettepanek veapilet tagasiside kliendile nt rakendus käitub vastavalt analüüsile või konsultatsioon funktsionaalsuse korrektseks kasutamiseks 4. Muud rakenduse ja selle liidestega seotud tööd, mis on vajalikud rakenduse ja selle liideste käideldavuse tagamiseks; Majutajalt ja teistelt koostööpartneritelt tulnud tähelepanekute analüüs . Nende tegevustega seotud arendustööd muudatusettepanek tagasiside kliendile 5. Tellijat esindavate töötajate konsulteerimine rakenduse administreerimise ja andmebaasi päringute osas; TeIS funktsionaalsuse analüüs Andmemudeli analüüs Nende tegevustega seotud arendustööd muudatusettepanek tagasiside kliendile andmebaasi päring 6. Tarnete paigalduste toetamist TeIS live , test ning muudes keskkondades ja selle käigus tekkivate veaolukordade lahendamine. Paigalduslogide analüüsimine Majutaja küsimuste analüüs Nende tegevustega seotud arendustööd tagasiside kliendile skript Tööde hulka ei kuulu vigade kõrvaldamine tarkvaras, kui tegemist on garantiiliste vigadega. Garantiilised tarkvaravead kõrvaldatakse garantii korras vastavalt raamlepingu sätestatud tingimustele. Töö korraldus Täitja tagab Tööde osutamise valmisoleku ja omapoolse abi kuni veaolukorra kõrvaldamiseni vastavalt käesolevas dokumendis ja hankelepingu tehnilises kirjelduses toodud tingimustele. Tööd esitatakse JIRA-s TeIS hoolduse projekti kaudu. Kõik Töödega seonduv info dokumenteeritakse JIRA-s (sh tarneteatised, juhendid, spetsifikatsioonid, lähtekood, testiraportid, tuvastatud vead/probleemid ja nende lahendused). Kriitilise tööga seoses tuleb lisaks JIRA kandele töö tekkimisest teada anda ka telefoni teel. Täitja saab sisendi Tööde alustamiseks ja teostamiseks üksnes Tellija kontaktisikult. Tellija kontaktisik määrab JIRA-s raporteeritud probleemi või tööülesande pileti tüübiks "Hooldus". Peale probleemi lahendamist kirjeldab Täitja kõik tegevused, mida ta probleemi lahendamiseks teostas. Samuti paneb ta tööülesande juurde kirja teostatud tunnid. Kui Töö on Täitja poolt teostatud, märgib Täitja Töö olekusse " Resolved " ja suunab töö Tellija poolt määratud kontaktisikule üle vaatamiseks ja testimiseks. Tellija poolne kontaktisik korraldab 5 (viie) tööpäeva jooksul Töö testimise ja vastuvõtmise. Vastuvõetud Töö määratakse staatusesse „ Closed “. Juhul kui Tellijal on pretensioone või vastuväiteid teostatud Tööle, määrab Tellija kontaktisik Töö staatuseks „ waiting for testing “ ja suunab Töö Täitja uuesti täitmiseks. Täitja peab tegema Töös parandused Poolte poolt kokkulepitud aja jooksul. Kui kokkulepet ei saavutata, siis tuleb Täitjal kõrvaldada vead Tellija poolt määratud tähtaja jooksul. Ligipääsud Tellija keskkondadele Täitja peab esitama meeskonnaliikmete nimekirja , kes hakkavad lahendama TeIS töös esinevaid probleeme. Esitatud isikutele luuakse vajadusel vastavad ligipääs ud vajalikesse keskkondadesse . Täitja tagab konfidentsiaalsusnõude täitmise vastavalt raamlepingus toodud tingimustele. Live keskkonna juurdepääsu d kooskõlastatakse eelnevalt Tellija kontaktisikuga. Täitja töötajad saavad TeIS LIVE keskkonna andmebaasidele ainult andmete lugemise õigused jooksvalt , kui selleks tekib vajadus . Andmebaasis teostab muudatused Tellija. Kui hoolduse käigus on vaja andmeid muuta andmebaasis, siis Täitja koostab andmete muutmise skriptid. Valminud skriptide käivitamise korraldavad Tellija kontaktisikud. Reageerimise ajad Probleemi prioriteet Kirjeldus Reageerimise aeg tööpäeviti kell 9:00 – 17:00 Kriitiline viga ( critical ) Tarkvaral põhinev teenus või süsteem ei toimi ega ole kasutatav, näiteks on andmed rikutud; esineb kasutajasessioonide ebanormaalne katkemine; probleem mõjutab süsteemi käideldavust ja andmete terviklikkust; mõjutatud on enamus Tarkvara kasutajatest; vastukaal probleemi vältimiseks praktiliselt puudub; tõsine finantsmõju; Kiireim võimalik aeg, kuid mitte hiljem kui 4 tunni jooksul (kui Pooled ei lepi asjaolude tõttu kokku teisiti) Häiriv viga ( major ) Tarkvaraga seotud probleem ei sega teatavate reservatsioonide järgimisel igapäevast töötamist; mõjutatud ei ole kõik Tarkvara kasutajad; väiksema tähtsusega funktsionaalsused pole käideldavad, kasutatavad või süsteemi jõudlus on madalamal maksimaalsest nõudest; eksisteerib ajutine aktsepteeritav vastukaal probleemi vältimiseks. 3 tööpäeva jooksul (kui Pooled ei lepi kokku teisiti) Pisiviga ( minor ) väikesed puudused minimaalse mõjuga Tööde kasutajatele või klientidele; kosmeetilised probleemid (ekraanikomponendid on nihkes, kuid see ei takista komponendi eesmärgipärast kasutamist); pikaajaline vastukaalu kasutamine kasutajatele vastuvõetav. 10 tööpäeva jooksul või kokkuleppel Tellijaga pikema mõistliku aja jooksul Reageerimise aeg – selle aja jooksul peab Täitja alustama probleemi lahendamist. Kui JIRA-s on probleem registreeritud enne kella 14:00 (tööpäeval), siis kõikide prioriteetide korral algab reageerimise aeg raporteerimise momendist. Peale kella 14:00 registreeritud probleemide korral algab reageerimisaja arvestus järgmise tööpäeva kella 9:00-st. Töö välisel ajal Kriitiliste vigad e lahendamise valmisoleku ajaplaan tuleb Tellija ja Täitja esindajate poolt eelnevalt kokku leppida iga kord vähemalt 3 tööpäeva ette arvates sündmusest, mis võib tekitada Kriitilise vea . Sellistel juhtudel Tellija teavitab Täitjat probleemidest telefoni teel. Tööaeg on tööpäevadel (v.a riiklikud pühad) kell 9:00 kuni kell 17:00.
TEHIK Versioonihalduskeskkond Juhend Anti Urm 4.08.2017 Versioon Kuupäev Muutja Kommentaar 1.0 04.08.2017 Anti Urm Esmaversioon 2.0 02.07.2018 Martin Õunap Dokumendi nime muudatus; lähtekoodihaldus --> versioonihaldus; dokumendist infosüsteemi nime kaotamine Dokumendi eesmärk Kirjeldatakse ära lahenduste arenduse käigus tekkiva lähtekoodi halduse reeglistik . Üldine kirjeldus Versioneerimistarkvara L ähtekoodi hallatakse GIT tarkvaraga. Tsentraalne versio o nihaldustarkvara asub TEHIKus aadressil https://gitlab.sotsiaalministeerium.ee/ Iga tarkvara arendaja võib teha enda versioneerimistarkvarasse koopiaid TEHIKu versioonihalduskeskkonnast . Tarkvara paigalduspakettide kokku ehitamine toimub TEHIKu versioonihalduskeskkonnast . Loodava koodi üleslükkamine ( commit ja push ) Iga koodi kinnitamine ( commit ) ja üleslükkamine ( push ), peab sisaldama endas Jira ülesannete loetelu, mida antud kinn i tami n e/üleslükkamisega lahendatakse või luuakse . Lisaks Jira ülesande numbrile, peab sisaldama ka lühidat ülevaadet teostatud muudatuse kohta. Versioonihalduse harude haldus Peamised harud TEHIKu versio o nihalduskeskkonnas on kohustuslike harudena olemas Master Develop Versioonihalduse harus origin/master hoitakse Live keskkonnas oleva tarkvara lähtekoodi seisu. Versioonihalduse harus origin/develop hoitakse arenduse keskkonnas oleva tarkvara lähtekoodi seisu. Kui lähtekood on saavutanud stabiilse seisu, et paigaldada see Live /Test/... keskkonda, siis kõik D evelop harus olevad muudatused tuleb mestida M aster harusse ning silditada vastava tarkvara versiooni numbriga. Toetavad harud Iga uue arenduse algul loob arendaja ühe alljärgnevatest versioonihalduse harudest Feature Release Hotfix Feature haru Väljavõte tehakse: Develop Mestimine tehakse: Develop Haru nime kuju: [projekti lühinimetus]-*, või Jira taski number Feature haru kasutatakse tarkvara uue funktsionaalsuse arendusteks. Release haru Väljavõte tehakse: Develop Mestimine tehakse: Develop ja Master Haru nime kuju: release-* Release harus kasutatakse tarkvara live mineku ettevalmistamiseks. Selles võib teostada nn viimase minuti tarkvara korrigeerimise tegevusi. Lisaks on veel lubatud pisikesi veaparandusi ning meta-andmete täiendusi. Peale tööde lõppu Release harus, peab Develop harus olema kogu vajalik lähte kood järgmisteks suuremateks arendusteks. Hotfix haru Väljavõte tehakse: Master Mestimine tehakse: Develop ja Master Haru nime kuju: hotfix-* Hotfix harus kasutatakse live keskkonnas oleva tarkvara vigade parandamiseks. Kasutatud materjalid: http://nvie.com/posts/a-successful-git-branching-model/
Tööelu infosüsteemi arendustööd Mittefunktsionaalsed nõuded Versioon: 1.0 Käesolev dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded Tööelu infosüsteemi arendustele ning nende dokumentatsioonile. Käesolevat dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb lähtuda põhidokumendis kirjeldatust. Põhidokumendi s viidatud TEHIK-u poolt koostatud dokumentide ja kolmandate osapoolte poolt koostatud dokumentide erisuste puhul tuleb lähtuda TEHIK-u poolt loodud dokumentides kirjeldatust. Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel. Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus on võimalik. Nõude nr. Nõude sisu Seletused Koostamise eest vastutaja Vastavus üldistele standarditele 1.1 Lahendus peab olema kooskõlas riigi IT koosvõime raamistiku nõuetega. https://www.mkm.ee/sites/default/files/riigi_it_koosvoime_raamistik.pdf Arendaja 1.2 Lahenduse X-tee teenused peavad vastama RIA nõuetele. https://www.ria.ee/ee/xtee-juhendid.html Arendaja 1.3 Lahendus peab vastama TEHIK-u IT profiilile. - Arendaja 1.4 Rakendus peab olema kirjutatud arvestades selle rakenduse poolt töödeldavatele andmetele määratud ISKE turvaklassi nõudeid. Tööelu infosüsteemi ISKE turvaklass on K2T3S2 . https://www.ria.ee/ee/iske-kkk.html Arendaja 1.5 Lahendus peab vastama veebide koosvõime raamistikule. https://www.mkm.ee/sites/default/files/veebide_raamistik.pdf Arendaja 1.6 Veebirakenduse kasutajaliides peab vastama vähemalt WCAG 2.0 tasemele AA. http://www.w3.org/TR/WCAG20/ Eesti Pimedate Liidu poolt soovitatud näidised: http://kaasav.miljonivaade.eu/ http://www.bbc.com/ Arendaja 1.7 Veebipõhine kasutajaliides peab ühilduma täielikult standarditega vähemalt eelistatult HTML 5 ja CSS 3 Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ Kui on tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni. Arendaja 1.8 ID-kaardiga allkirjastam isel on eelistatud veebipõhine DigiD oc-teenuste kasutamine. Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüü s vms) peab olema välja toodud DigiD oc-teekide versioonid ja kasutuskohad Arendaja 1.9 Veebirakendus peab probleemideta läbima OWASP ASVS baasil põhineva testi Kui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS viimase kehtiva versiooni tasemeks 2 ( https://www.owasp.org/index.php/Category: OWASP_Application_Security_Verification_Standard_Project ). Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile. Tellija poolset turvatestimist teostab kolmas sõltumatu pool. Selline esmane kolmanda poole turvatestimine tellitakse tellija finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui tellija vastava nõudmise esitab. Arendaja 1.10 Krüptoalgoritmide ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut, st lahendustes ei tohi kasutada uuringus väljatoodud ebaturvalisi algoritme ja võtmepikkuseid Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh SSL /TLS sertifikaatide kasutuskohad. Värskeima uuringu leiab aadressilt https://www.ria.ee/ee/kruptouuringud.html Arendaja 1.11 Andmete edastus peab välisvõrgu liikluses olema kaitstud kasutades turvalisi ja üldteada andmeedastusprotokolle - Arendaja 1.12 Infosüsteem peab kasutama serveri kellaaega ja ajatsooni - Arendaja 1.13 Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. - Arendaja 1.14 Rakendus peab olema tehniliselt tükeldatud vastavalt loogilisele jaotusele. Saadud osised peavad olema eraldi versioneeritavad ja paigaldatavad Näiteks, kui rakendusel on eraldi turvakontekstidega liidesed ametnikule ja kodanikule, peab rakendus olema jagatav kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiks. Arendaja 1.15 TeIS loomisel peab arvestama valitsusasutusele kehtestatud visuaalse identiteedi stiilijuhisega https://www.valitsus.ee/et/eesmargid-tegevused/valitsusasutuste-visuaalse-identiteedi-stiilijuhis Arendaja 1.16 Avalike e-teenuste loomisel peab arvestama valitsusasutustele kehtestatud iseteeninduskeskkonna raamistikuga https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik_08.07.2015.pdf https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik_-_kokkuvote.pdf https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistiku_kasutatavuse_nouded_dets.pdf Arendaja Nõuded rakenduse arhitektuurile 2.1 Rakenduse, andmebaas i ja kolmanda osapoole komponend id peavad olema sellised, mille eluea lõpp (EO L) pole teadaolevalt vähem kui kahe aasta pärast. Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema välja toodud kasutatavate komponentide nimetused ja versioonid. Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea lõpuks, st versiooni tugi võib aeguda, kui uus versioon on välja lastud. Arendaja 2.2 Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peab olema enne reaalse arend use algust TEHIK-u poolt projekti kaasatud tarkvara arhitektiga kooskõlastatud . Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande käigus välja toodud jõudlusnäitajatele. Arendaja 2.3 Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril. - Arendaja 2.4 Rakendusserver peab olema vajadusel klasterdatav aktiivklastris (kasutajasessioon ei tohi olla klastri node põhine). - Arendaja 2.5 Rakendust peab saama ilma ümberprogrammeerimata liigutada erinevate domeenide ja domeeni saitide vahel Lahendus se ei tohi olla sisse kompileeritud absoluutseid URI-sid Arendaja 2.6 Rakenduse liidesed peavad olema tõrkekindlad kolmandate osapoolte süsteemide vigade suhtes Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid väljastama mõistliku (võimalikult lühikese) aja jooksul ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid. Arendaja 2.7 Rakenduse konfiguratsiooniparameetrid tuleb ühte kohta kokku tuua nii, et nende muutmisel ei peaks rakendust uuesti kokku kompileerima (nt ühte tekstipõhisesse konfiguratsioonifaili, andmebaasi tabelisse). Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (näit Log4net). Samuti on väga soovitatav eraldi konfiguratsioonifailis hoida arendaja ja administraatori vastutusala parameetrid. Infosüsteem peab olema seadistatav konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks konfiguratsioonile ka muud programmikoodi. Parameetrid, mida võib olla vajadus muuta rakenduse töökäigus, võib talletada andmebaasis, kuid see peab olema kokkulepitud TEHIK-u poolt projekti kaasatud tarkvara arhitektiga . Arendaja 2.8 Rakenduse kompileerimine, saidi taaskäivitus, konfiguratsiooni muutmine vms peaks toimuma mõistliku aja jooksul. Maksimaalselt 30 sek. Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus väljastama selle kohta selge teate Arendaja 2.9 Rakendus peab kasutama 64-bitist arvutiarhitektuuri kui ei ole kokku lepitud teisiti. Suund on 64-bitiste rakenduste op süsteemide kasutamise poole. Arendaja 2.10 Kõik andmed, andmebaasid, SQL skriptid ja rakendus peavad kasutama UTF-8 kodeeringut. Alternatiivina on kokkuleppel tellijaga lubatud ka UTF-16. - Arendaja 2.11 Failisüsteemi salvestamisel ei tohi ühte kausta tekkida üle 10000 faili. Failid peab katalogiseerima kokkulepitud tunnuste alusel (nt aasta, kuu, kuupäev). Arendaja 2.12 Rakenduse loomisel tuleb eelistada objektorienteeritud mudelit Eelistuse eiramine tuleb kooskõlastada projektijuhiga enne arendamise alustamist Arendaja 2.13 Ühest andmetabelist teise viitamisel tuleb kasutada väliseid võtmeid ( Foreign key ). - Arendaja 2.14 Kõik välised võtmed ( Foreign Key ) peavad olema indekseeritud. Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded rakenduse jõudlusele oleksid täidetud ka tulevikus. (1, 3, 5 või 10 aasta pärast – vastavalt planeeritud kasutusajale). Arendaja 2.15 Tuleb kasutada päringumuutujaid ( Parameter Binding ). SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama päringumuutujaid, et vältida SQL vahemälu fragmentseerumist ( When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation ) Arendaja 2.16 Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti. Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest. Kasutada vastava andmebaasisüsteemi nimetamise parimaid praktikaid. Arendaja 2.17 Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat: Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Rakenduse piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus. Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis. Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi välja toodud ja tuleb peale installi ära võtta. Ei kehti teiste andmebaasisüsteemide korral, seal võib see tekitada mõttetut keerukust. Kui lahenduse arhitektuur ei võimalda antud punkti täitmist, tuleb see kokku leppida TEHIK-u poolt projekti kaasatud tarkvara a r hitektiga. Arendaja 2.18 Failide hoidmise asukoht lepitakse igakord kokku. Kuid failid ja failide indeks peavad olema replikeeritavad teise serveriruumi. Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud nõudmised ja piirangud andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht. Arendaja 2.19 Peab olema minimiseeritud vajadus, et haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid. Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus. Arendaja 2.20 Rakendus peab olema võimeline kasutama keskkonnamuutujaid (serverinimi, kuu, päev jne). Näiteks logifailides. Arendaja 2.21 Andmebaas peab toetama nii külm- kui ka kuumvaru (peegeldamist) teise serviruumi. Ei tohi kasutada teenuseid, mis välistav ad andmebaasi peegeldamist (nt failstream ). Arendaja 2.22 Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Accent peab olema sisse lülitatud. Näiteks MS SQL puhul Estonian_CI_AS. Arendaja 2.23 Kui infosüsteemid saadavad e-kirju, peavad nad kasutama välist e-mailiserverit. Kirja saatmisel peab rakendus veenduma, et e-mailiserver võttis meili vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322). Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on muudetavad konfiguratsioonifaili kaudu. Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav info). Arendaja 2.24 Konfiguratsiooniparameetrite nimed peavad olema sisulised. Kui see ei ole võimalik, siis peab kõrval olema seletus. Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne Arendaja 2.25 Infosüsteemides on eessüsteemid ( front end ; presentatsiooni kiht) ja tagasüsteemid ( back end ; äriloogika kiht) arhitektuuriliselt selgelt lahutatud. Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on andmete haldamine ja võrguteenuste pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist . Välise süsteemi taastumisel peab süs teem olema suuteline oma tööd jä tkama taaskäivitamata. Arendaja 2.26 Konfiguratsioonifailid peavad olema vastavalt rakendusserveri tüübile vaikimisi kaitstud failid Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Arendaja peab välja tooma konfifailide listi, kui neid on mitu. Arendaja 2.27 Rakenduse failid, mida kasutaja näha ei tohi, peavad olema vaikimisi kaitstud kaustades. Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, App_LocalResources, App_Themes, App_WebReferences Arendaja 2.28 Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama sisuga parameetreid ei tohi konfiguratsioonis eksisteerida. Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, tuleb vältida korduseid ja kasutada muutujaid vajalikes kohtades . Arendaja 2.29 Kõik rakenduse liidesed peavad olema võimelised t öötama kõrgkäidelda valt. Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav lahendus on selline, mida saab samaaegselt käitada erinevates masinates. Arendaja 2.30 Klientrakendus ei tohi pöörduda otse andmebaasi poole. Tuleb kasutada rakendusservereid. Arendaja 2.31 Keskkonnapõhised muutujad peavad olema konfiguratsioonifailist seadistatavad. Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. Arendaja 2.32 Rakenduses peab olema võimalik piirata ebaõnnestunud logimisi ajaühiku kohta (mobiil-ID, ID-kaart, , Smart-ID ) ühelt IP-aadressilt. Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel võib kasutada captchat või konto lukustamist. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama konfiguratsioonifailist muuta. Arendaja 2.33 Rakendus ei tohi kasutada meetodeid, mis välistavad shared hostingu kasutamise. .NET rakenduste puhul on suund shared hostingu kasutamise suunas. Arendaja 2.34 Rakenduse äriloogika tuleb realiseerida andmebaasist eraldi sõltumatus rakenduskihis. Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna kirjutatavaid andmeid, va trigerid, mis tekitavad logi. Arendaja 2.35 Andmebaasis võib kasutada vaid ISO/IEC 9075 standardiga kaetud funktsionaalsusi. Lisaks ei tohi kasutada ka sama standardi osas 13 kirjeldatud funktsionaalsusi. *Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille üleviimine mõnele muule andmebaasiplatvormile ei ole võimalik. *ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis. Arendaja 2.36 Kui rakendus eeldab eraldi kasutajate, rollide ja õiguste registri pidamist, siis peab rakendus kasutama Riigi autentimis teenust TARA ja autoriseerimismoodulit AAM. TARA info: https://www.ria.ee/ee/tara-autentimisteenus.html AAM on keskne autentimis - ja autoriseerimis lahendus. Kui lahenduse loomisel on näha, et AAM-i kasutamine pole mõttekas, tuleb see kokku leppida TEHIK-u poolt projekti kaasatud tarkvara arhitektiga Arendaja 2.37 Uniform resource identifier (URI) pikkus ei tohi ületada ühegi IS poolt toetatava brauseri maksimaalset lubatud väärtust. Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda eraldi järele uurida sõltuvalt IS komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239. Arendaja 2.38 SOAP teenuseid pakkuva rakenduse WSDL peab olema üles ehitatud nii, et see toetaks teenuste versioneerimist. Näiteks: Alajaotis definitions/types/schema: * complexType defineerimisel tuleb sellele lisada any element . Arendaja 2.3 9 Rakendus peab olema võimeline töötama koormusjaoturitega varustatud taristul. Vajadusel võimaldama SSL offload -i . Arendaja 2.40 Sidusinfosüsteemide mitte kättesaadavus ei tohi segada rakenduse töötamist. Sidusinfosüsteemidega andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse. Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem olema suuteline oma tööd j ä tkama taaskäivitamata. Arendaja 2.41 Kui ajastatult käivitatav taustatöö, ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud. - Arendaja 2.42 Ühe tarkvarakomponendi raames ei tohi sama parameetri seadistamine toimuda rohkem kui ühes kohas. Näiteks kui rakenduse komponent pöördub andmebaasi või veebiteenuse poole, siis selle pöördumise parameetrid peavad olema muudetavad vaid ühes kohas. Arendaja 2.43 Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate Tehnoloogiate ja standardite valik tuleb kooskõlastada TEHIK-u poolt projekti kaasatud tarkvara arhitektiga - Arendaja 2.44 Rakenduse ühenduste (s.h. andmebaasi ja sidusinfosüsteemide ühendused) realiseerimisel tuleb kasutada ühenduste puulimist ( connection pooling ). Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang ja päringu aegumise aeg ( request timeout ) . Rakenduse ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Ühenduste taastumisel peab rakendus olema suuteline oma tööd j ä tkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse. Arendaja 2.45 Rakenduse uuendustega kaasnevad andmebaasi muudatused tuleb automatiseerida. Näiteks Liquibase või Flyway . Arendaja Turvalisuse tagamisega seotud nõuded 3.1 Sisemised rakendusliidese autentimised pea vad olema lahendatud TARA-ga ja rolli valikul peab arvestama kasutaja kontoga seotud piirnagutega Active directory -s . Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne. Arendaja 3.2 Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades. - Arendaja 3.3 SSL veebiserver peab kasutama turvalisi ja SSL/TLS versioone ja šifrikomplekte https://www.ssllabs.com/ssltest/ Arendaja 3.4 Rakendus tohib kasutada vaid sessiooni küpsiseid. Muude küpsiste kasutamine on keelatud. - Arendaja 3.5 Kui andmebaasis olevate andmete ISKE tervikluse turvaosaklass on 2 või kõrgem, siis tuleb kõik klass 2 infot sisaldavad andmebaasi kirjed/tabelid versioneerida. St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist informatsiooni: *viide kirjele, mille ta kehtetuks muutis (kui on) *kasutaja, kes kirje lõi *kirje loomise aeg *sessiooni-ID (kui on olemas). Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni: *kasutaja, kes kirje kehtetuks tunnistas *kirje kehtetuks tunnistamise aeg. Arendaja 3.6 Kui rakenduse poolt töödeldavate andmete konfidentsiaalsuse turvaosaklass on 2 või kõrgem, peab rakendusega kaasas olema lahendus, mis suudab toota toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni. Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja omavahelised suhted. Arendaja 3.7 Andmebaasis olevate rakenduse kontod peavad omama ainult minimaalselt rakenduse tööks vajalikke õiguseid. Ei resource, dba, ANY ega muud sellist. Nõude täitmiseks vajalikud vahendid (skriptid) peavad kuuluma rakenduse juurde ja nende sisu peab olema kontrollitav. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse installijuhendis. Arendaja 3.8 Rakendusse ja andmetele tohib olla ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades. St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi. Arendaja 3.9 Rakendus ei tohi teostada X-tee päringut otse kasutajaarvutist. Kasutajaarvutitest otse X -tee päringute tegemine on arvutivõrgu tasemel kinni. Rakendusserverist tehtavate päringute teostamiseks on mõistlik kasutada vahekomponenti rakendusserveri ja X -tee vahel. Arendaja 3.10 Veebipõhised välise veebilehega rakendused, mis on keskmise või kõrgema ISKE turbeastmega, peavad kasutama vahendeid kaitsmaks rakendust lubamatute päringute eest. IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Lubatud päringud on kõik päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele ette nähtud. Kasutama peab whitelisting põhimõtet, mitte blacklisting . Arendaja 3.11 Kui rakenduse mõni ISKE turvaosaklass on 2 või kõrgem, peab rakendus sisenemisel näitama pä rast õnnestunud siss logimist eelmise õnnestunud sisse logimise aega. Kui on toimunud ebaõnnestunud sisse logimise katseid, siis peab kuvama ka, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti. Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud. Riikliku autentim ismooduli TARA kasutamise puhul tuleb talletada info ka ebaõnnestunud autentimise puhul. Arendaja 3.12 Kõigil rakendustel peab olema konfigureeritav kasutajasessiooni aegumise aeg. Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Arendaja 3.13 Krüpteerimise ja/või räside arvutamise korral tuleb kasutada tugevaid algoritme. Järgida tuleb uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut. Lubatud on: AES-256, Blowfish-256, RSA-2048, SHA-2, RIPEMD-160 või tugevamaid. Lahenduses tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. Arendaja 3.14 Autenditud sessiooni tunnust ei tohi ainult lihtsa küpsisega lahendada. Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse kopeerimisega ühest arvutist teise. Arendaja 3.15 Tagada tuleb rollide lahusus. Halduritel ei tohi olla võimalik muuta ega näha rakenduse konfiguratsiooni. Administraatoril, halduril ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja kasutusjuhtudest. Arendaja 3.16 Kui kasutajaid hallatakse ka rakenduses, tuleb sisse logimisel kõigepealt kontrollida kasutaja olemasolu rakenduses ja alles siis pöörduda AD või AAM-i poole. Eesmärk vähendada AD ja AAM-i koormust. Arendaja 3.17 Arendus peab olema orienteeritud toodangukeskkonnas toimimiseks. Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis toodangu keskkonnas on ebavajalikud või segavad (näiteks kasutuseta funktsionaalsus ja komponendid, mõeldud testimiseks testkeskkonnas, arendusabiks arenduskeskkonnas jne). Arendaja 3.18 Rakendus ei tohi lubada ühe kasutajaga mitut samaaegset sessiooni. Juhul kui lähteülesanne spetsiaalselt ei ütle teisiti. Arendaja 3.19 Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud. Milline lahendus valitakse tuleb kokku leppida tellijaga. Täpsustuseks vt ISKE nõue HT.34. Vt ka nõuet 3.28. Arendaja 3.20 Kui lahendus peaks kasutama ajatempli teenust, siis tuleks eelistada Guardtime lahendust. Ajatempli kasutamise vajadus lepitakse eraldi kokku Tellija IT juhiga ja infoturbejuhiga. See sõltub Tellija keskse ajatempli kasutamise võimalustest. Arendaja 3.21 Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed olema krüptoaheldatud, et tagada et tõestusväärtusega andmeid ei saaks märkamatult kustutada. Täpsustuseks vt ISKE nõue HT.10. Krüptoahela kasutamise vajadus lepitakse eraldi kokku Tellija infrastrktuuri juhiga ja infoturbejuhiga. See sõltub Tellija keskse krüptoahela kasutamise võimalustest. Arendaja 3.22 Kui rakenduses on S3 salastuse astmega andmeid, peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult. Täpsustuseks vt ISKE nõue HT.37 . Arendaja 3.23 Veebirakendus ei tohi jätta sulgemisel kasutaja tööjaama maha ajutisi faile. Paksu kliendi korral ei tohi rakendus kasutaja tööjaama jätta maha krüpteerimata kujul ajutisi faile, mis sisaldavad või võivad sisaldada konfidentsiaalse või kõrget terviklust nõudvat informatsiooni. Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline kustutamine tagamaks, et ei koormata liigselt kasutaja arvutit. Nõude eesmärk on tagada, et rakenduse sulgemisel ei jääks kasutaja arvutisse maha informatsiooni, mida sinna jääda ei tohiks, sh pääsuandmeid, isikuandmeid, andmekogu sisulisi andmeid jms Arendaja 3.24 Rakendus ja selle komponendid peavad võimaldama kasutada keskkondade lahusust Arendaja arendab arenduskeskkonnas ja annab tarne üle tellijale paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning seejärel paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas. Kokkuleppel tellijaga võib antud protsess erineda kirjeldatust mille vajadus tuleneb näiteks konteinerlahenduse kasutamisele võtul. Arendaja 3.25 Rakendus peab võimaldama hõlpsalt välja vahetada aegunud ja ebaturvalise krüptoalgoritmi. Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada. Arendaja 3.26 Rakenduse andmebaasi krüpteerimisega seotud andmeväljad peavad olema muudetava pikkusega. Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid olema muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme. Arendaja Logimine, debuggimine , testimine 4.1 Rakendusel peab olema masinloetav testleht (JSON, XML). Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom built rakenduse versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone reeta. Samuti peab testlehel olema infot rakenduse (vajadusel tema erinevate osade) ja tema kõigi väliste liideste staatuse kohta (töötab, ei tööta). Rakenduse, andmebaasi ja liideste töökorda kontrollitakse testpäringute teel, mis tuleb tellijaga kokku leppida eelanalüüsi käigus. Testleht peab oma konfiguratsiooni võtma rakenduse üldisest konfiguratsioonist (baasistring, välised ühendused). Arendaja 4.2 Rakenduse kõik üleantavad versioonid peavad enne tellijale üle andmist olema testitud Testitulemused tuleb edastada tellijale koos rakenduse üleandmisega . Vaata lisaks nõuet 4.23 ja 4. 24 . Arendaja 4.3 Rakendus peab logima kasutaja edukat ja ebaedukat autentimist ja sessiooni lõpetamist, kasutaja IP ja autentimismeetodit (ID-kaart, mobiil-ID vms), eduka autendi puhul tuleks logida ka kasutaja isikukood ja mobiil-ID ning Smart-ID puhul telefoninumber Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale parool, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui võimalik kasutajatunnus (mobiil-ID puhul telefoni number, ID-kaardi puhul isikukood). Kui rakendus kasutab kasutajate autentimiseks AAM-i või TARA , siis leppida projektijuhiga eraldi kokku autentimise detailsus ehk mis kajastatakse AAM-is või TARA-s ja mis rakenduses. Arendaja 4.4 Erinevate logifailide kirjeid peab olema võimalik seotud komponentide logidega loogiliselt kokku viia. Tegevuste sidumiseks peab olema võimalik logikirjeid siduda ühise välja abil. Selleks ei sobi kellaaeg ega IP. Sobib näiteks unikaalne ID, mis ei tohi olla sessiooni ID, sest seda saaks logist välja lugeda ja rünnakuks ära kasutada. Võib olla ka sessiooni ID räsi Arendaja 4.5 Rakendus peab suutma logida kõiki X-tee teenuste kaudu liikuvaid andmeid. Peab olema võimalus logimist sisse-välja lülitada. Vajalik eelkõige silumiseks ja toodangu keskkonna probleemide lahendamiseks. Arendaja 4.6 Kui rakenduse ISKE konfidentsiaalsus turvaosaklass on 2 või kõrgem, peab rakendus logima kõiki konfidentsiaalsus klassiga 2 või kõrgemate andmete loomist, muutmist (sh kustutamist) ja vaatamist. Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga ning sessiooniinfoga. Isikuandmete kaitse seadus §25 lg2 p3: (Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöö tlussüsteemis juurdepääs saadi. Arendaja 4.7 Kui rakenduse ISKE tervikluse turvaosaklass on 2 või kõrgem peab rakendus logima kõiki tervikluse klassiga 2 andmete loomist ja muutmist (sh kustutamist). Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga ning sessiooniinfoga. Isikuandmete kaitse seadus §25 lg2 p3:(Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; Arendaja 4.8 Kui rakenduse andmete konfidentsiaalsuse turvaosaklass on 3, siis ka kõiki administraatorite ja haldurite poolt tehtavaid andmete vaatamised (ka otse baasis) tuleb logida. Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise logimist ise (ka tavakasutajate logimist) deaktiveerida või logisid kustutada/muuta. Võib tellijaga kokku leppel nõudest loobuda kui andmed on krüpteeritud. Arendaja 4.9 Kui rakenduse andmete tervikluse turvaosaklass on 3, siis ka kõiki administraatorite ja haldurite poolt tehtavaid andmete muudatused (ka otse baasis) tuleb logida. Lahendus peab tagama, et administraatorid/haldurid ei saa andmete muutmise logimist ise (ka tavakasutajate logimist) kinni keerata või logisid kustutada/muuta. Tellijaga kokkuleppel võib nõudest loobuda, kui andmed on kaitstud digiallkirja, digitempli või välise osapoole ajatempliga. Arendaja 4.10 Logimiseks tuleb kasutada standardseid komponente kogu logiahela ulatuses. Näiteks java-s log4j/logback ... , transpordiks syslog, logi formaadiks JSON või CSV või tabeldus-eraldus. Failid peavad olema loetavad tekstilisel kujul. Logid peavad olema kujul, et neid saaks töödelda masinloetavalt ja inimloetavalt. Arendaja 4.11 Andmete loomise/vaatamise/muutmise/kustutamise tegevused peavad olema kajastatud logides . Logikirjes peab sisalduma piisavalt informatsiooni, et vastata küsimustele kes, mida, kus, kust, millal, kuidas ja tulemus. Arendaja 4.12 Logid peavad olema jaotatud loogiliselt. Seansilogi - info sisselogimiste, väljalogimiste ja seansi aegumiste kohta. Vigased sisselogimise katsed. Info õiguste suurendamise kohta. Peab olema logitud ka tühja või puuduvate parameetritega logimise katsed. Tegevuslogi - kogu informatsioon kasutajate tegevuste kohta koos tegevuse tüübi, seansi parameetrite (korreleerimaks seansi- ja tegevuslogi) ja kasutaja poolt esitatud sisendparameetritega (sh. väliste ressursside kasutamise kohta). Logida tuleb nii õnnestunud kui ka ebaõnnestunud tegevusi. Tehniline logi - rakendusserveri poolt loodud logi Vealogi - erinevate veaolukordade info Silumislogi - arendajate jaoks vajalik debug info Arendaja 4.13 Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtuse g a . Näiteks NULL Arendaja 4.14 Logis tuleb kõik mitte kuvatavad ( non-printable ) sümbolid kodeerida . N äiteks reavahetused -> \n, non-printable sümbolid - 0x00..0x1f, 0x7f..0xff . Arendaja 4.15 Logides peab olema maksimaalselt üks sündmus ühel real. Mitme realiste sündmuste puhul kasutada kodeerimist või JSON formaati. Mitme realiste sündmused võivad olla tehnilises-, vea- või silumislogis kui rakendusserver ei oska seda kodeerida . Arendaja 4.16 Ühe ja sama sündmuse väljad peavad olema erinevatel logikirjetel samas järjekorras - Arendaja 4.17 Logida tuleb päringud mille vastus on puhverdatud . - Arendaja 4.18 Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida kui ei ole nõutud teisiti. Arendaja 4.19 Rakendusega peab olema kaasas skript jõudlustestide tegemiseks. Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. Arendaja 4.20 Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu. Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust ( stack trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, GET- ja POST-parameetrid ja nende väärtusi. Logimise detailsusrežiimi ( info, warning, errog, debug ) peab saama muuta. Arendaja 4.21 Rakenduse funktsionaalsuse kirjeldusega tuleb luua ka logimise dokumentatsioon ja loginäidised. Koos funktsionaalsuse arendamisega tuleb luua ka loodava funktsionaalsuse logimine ja selle dokumentatsioon Mida logitakse, kuidas sündmused on logifailidesse jagatud, logiridade näited . Arendaja 4.22 Logimisparameetreid peab saama muuta rakendust taaskäivitamata. Näiteks log4j konfiguratsiooni failis " monitoring-interval ". Arendaja 4.23 Arhitektuuriline lahendus peab olema 75% ulatuses kaetud komponenditestidega ( unit test ). - Arendaja 4.24 Arhitektuuriline lahendus peab olema 50% ulatuses kaetud vastuvõtutestidega. - Arendaja Nõuded rakenduse lähtekoodile 5.1 Lähtekoodi kommentaarid peavad kõigis lahenduse kihtides (rakenduse enda kood, andmebaas, jne) olema kirjutatud eelistatult inglise keeles, vähem eelistatud alternatiivina eesti keeles. NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile – nt igasugu erinevad lahtise koodiga koodilõigud jms. Kui on tegu olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt. Arendaja 5.2 Lähtekoodi kommentaarid peavad olema selged, arusaadavad ja sisuliselt kirjeldama vastavat koodi, mille juures nad on ning moodustama vähemalt 20% koodi mahust. Rakenduse kood peab olema piisavalt hästi kommenteeritud, et erialast haridust omav tarkvaraarendaja on võimeline süsteemile jätkuarendusi teostama. Arendaja 5.3 Muutujate, tüüpide ja funktsioonide nimed peavad olema sisulised ja andma aimu nende otstarbest. Parim praktika Arendaja 5.4 Koodis kasutatavad konstandid ja lühendid tuleb kirjutada suurte tähtedega. Parim praktika. Nt Identifikaator --> ID Arendaja 5.5 Koodis kasutatavaid konstante ei tohi selle kasutamise kohta väärtusena hardcodeda – need tuleb defineerida muutujatena ja kasutada läbi nende. - Arendaja 5.6 Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd , jms). N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti. Arendaja 5.7 Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad. Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt kui on tegu tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID Arendaja 5.8 Andmebaasi väljade pikkused tuleb kirjeldada sümbolites, mitte baitides. Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. ( Instead of allocating x bytes of storage for the field, x chars of storage must be allocated ). Arendaja 5.9 Kui kokku pole lepitud teisiti, siis JAVA rakenduse kood peab olema kirjutatud vastavalt "Oracle Java Code convention" dokumendile. Checkstyle ( http://checkstyle.sourceforge.net/ ) ei tohi käivitamisel järgmise konfiguratsioonifailiga väljastada ühtegi viga. Arendaja 5.10 Kui kokku pole lepitud teisiti, siis Python rakenduse kood peab olema kirjutatud vastavalt "Style Guide for Python Code " dokumendile http://www.python.org/dev/peps/pep-0008/ Arendaja 5.11 Kui kokku pole lepitud teisiti, siis .NET rakenduse kood peab olema kirjutatud vastavalt "NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries". http://msdn.microsoft.com/en-us/library/ms229042.aspx Valideerimiseks kasutatakse 'StyleCop' vaikimisi konfiguratsiooni Arendaja 5.12 JAVA koodi valideerimiseks kasutatakse: 1. PMD ( http://pmd.sourceforge.net/ ) reeglistikud „Basic Rules“, „Import Statement Rules“, „Security Code Guidelines“ ja „Unused Code Rules“ ei tohi väljastada ühtegi viga. 2. DocCheck( http://java.sun.com/j2se/javadoc/doccheck/ ) 3. Findbugs ( http://findbugs.sourceforge.net/ ) TEHIK-u poolt kirjeldatud reeglistikus “Java koodi kvaliteedi nõuded.zip” ei tohi väljastada vigu. Arendaja 5.13 .NET koodi valideerimiseks kasutatakse: FxCop ( http://msdn.microsoft.com/en-us/library/bb429476.aspx ) Arendaja 5.14 Pythoni koodi valideerimiseks kasutatakse: Pychecker(http://pychecker.sourceforge.net/) Arendaja 5.15 Automaatne koodivalideerimine TEHIK-us on automaatseks koodivalideerimiseks kasutusel SonarQube ( https://www.sonarqube.org/ ). Ennem üleandmist tuleb veenduda, et koodis puuduvad: Turbedefektid Blokeerivad ja kriitilised vead Mõistlik on koodivalideerimine automatiseerida Gitlabi või Jenkinsi abil. Sõltub milline lahendus on projektis kasutusel. 5.1 6 Kasutuses mitteolev kood tuleb rakenduse lähtekoodist kõrvaldada. - Arendaja 5.1 7 Arendamisel kasutatakse DRY ja SOLID printsiipe http://en.wikipedia.org/wiki/Don%27t_repeat_yourself http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) Arendaja 5.1 8 Üleantavas koodis ei tohi olla paroole, mida on kasutatud arenduse käigus Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb asendada fraasiga “<password>“. Arendaja 5.1 9 Rakenduste lähtekoodi tasemel ei tohi olla ühtegi sisse kodeeritud parameetrit, väljade nimetust, veateadet. Eelpoolmainitu haldamine toimub failis või andmebaasis. Arendaja Andmekvaliteet ja standardid 6.1 Aadressiandmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse määrusest "Aadressiandmete süsteem". Liidestatakse Maa-ameti X-tee teenusega. https://www.riigiteataja.ee/akt/103102017005?leiaKehtiv Arendaja 6.2 Rakendus peab võimalikult palju informatsiooni eeltäitma automaatselt (kirje sisestamise kuupäev, kasutaja nimi jne). Välja arvatud logimisvormi lahtrid autentimisel Arendaja 6.3 Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. Jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. - Arendaja 6.4 Tervishoiuteenuste osutajate andmete kasutamisel peab kontrollima nende andmeid, sh tegevuslubade kehtivust Terviseameti Tegevuslubade registrist Liidestatakse Terviseameti X -tee teenusega Arendaja 6.5 Tervishoiutöötajate andmete kasutamisel peab kontrollima nende andmeid Terviseameti tervishoiutöötajate registrist Liidestatakse Terviseameti X -tee teenusega Arendaja 6.6 Meditsiiniandmete vahetamiseks tuleb kasutada meditsiiniandmete andmevahetuse standardit HL7 www.hl7.org Vajadusel on lubatud ka teiste standardite kasutamine, kuid see tuleb tellijaga eraldi kokku leppida Arendaja 6.7 Tervise valdkonna klassifikaatorid peavad olema kooskõlas Tellija OID-ide ja publitseerimiskeskusega Võimalusel tuleb kasutada olemasolevaid OID-e ja klassifikaatoreid, mida vajadusel täiendatakse või luuakse uued ning publitseeritakse samuti publitseerimiskeskuses http://pub.e-tervis.ee Arendaja/Tellija Kasutajaliides 7.1 Kasut ajaliidese kõik disainiotsused peavad olema kooskõlastatud tellijaga enne nende realiseerimist - Arendaja 7.2 Veebipõhine kasutajaliides peab olema kasutatav enamlevinud veebibrauseritega, sh nutiseadmetel (Android, IOS, Windows Phone) Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel tootja poolt toetatud versioonid. Täpsemad nõuded on välja toodud Tehnilise kirjelduse Lisas 1.3 Front-end arendusreeglid. Arendaja 7.3 Rakenduse värviskeem ja logo kasutamine peab vastama Tellija ametlikule visuaalsele identiteedile (CVI) ja disainijuhistele (UIG). Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka vastav SF sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida tellijalt. Arendaja 7.4 Kasutajaliidese kõik osad ja teated peavad olema eesti-, vene- ja inglisekeelsed. Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud hankedokumentides Arendaja 7.5 Lahenduse esitluskiht peab olema graafiliselt eskaleeruv ja mugavalt kasutatav kõigi enamlevinud seadmete resolutsioonidega. Toetatud peavad olema vähemalt resolutsioonid: 2560x1440, 1920x1200, 1920x1080, 1680x1050, 1600x1200, 1440x900, 1366x768, 1360x768, 1280x1024, 1280x960, 1280x800, 1280x768, 1152x864, 1024x768, 1024x600, 768x1024, 720x1280, 375x667, 360x640, 320x480. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. Arendaja 7.6 Hüpikaknaid (pop-up) ei tohi kasutada. Silmas on peetud uusi veebilehitseja aknaid avavaid hüpikaknaid Arendaja 7.7 Kasutajaliideses toiminguni (põhi- ehk enamkasutatavad tegevused) navigeerimiseks peab kehtima 3 kliki printsiip, väljalogimiseks 1 kliki printsiip. Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas. Arendaja 7.8 Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja massmuutmiste kohta kui pole kokku lepitud teisiti. - Arendaja 7.9 Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale kasutajasõbraliku veateatega, mis sisaldab soovituslikult ka vea koodi. Teade peab olema kasutaja poolt lahendust kasutatavas keeles. Veateated peavad olema sellised, mis võimaldavad IT-abil võimalikult lihtsalt tuvastada vea olemuse ja asukoha. Arendaja 7.10 Kasutajaliides peab olema ilma rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole kokkulepitud teisiti. Uue keele lisamine peab olema teostatav konfiguratsiooni failist või administreerimisliidesest. Arendaja 7.11 Rakenduse tausta, menüüde ja teksti värvid peavad olema ilma rakenduse koodi muutmata vahetatavad. - Arendaja 7.12 Rakenduse kasutajaliides peab teavitama kasutajat ette sessioon aegumisest. Ette teavitamise aeg peab olema konfigureeritav. Arendaja 7.13 Kui vormile sisestatakse mahukaid andmevälju peab kasutajaliides kokku lepitud ajavahemike järel salvestama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks. Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks ning salvestatakse vastava etapi lõpus. Arendaja 7.14 Sisestusvormidel andmete sisestamisel peab saama väljade vahel vastavalt äriloogikale liikuda klaviatuuri abil tabulaatoriga. - Arendaja 7.15 Interaktiivsete vormide puhul (näiteks faili üleslaadimine), ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). - Arendaja 7.16 Kui päring võtab aega kauem kui 3 sekundit, peab kasutaja saama visuaalse teate, et süsteem tegeleb päringu läbiviimisega. Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut sooritatakse või muu tellijaga kokkulepitud indikaator. Arendaja 7.17 Esilehel (sisse logimata) ja ka pärast kasutaja sisse logimist peab olema lihtne võimalus teavitada kasutajat (sisse loginud kasutaja puhul ka vastavalt tema rollile või temaga seotud ettevõtte tegevusalale) muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav. Näiteks võimalikud teavituses: mingi süsteemi osa on vigane, tuli mingi uus funktsionaalsus, vahetage oma parool, uuendage isikuandmeid jne. Arendaja 7.18 Infosüsteem peab funktsionaalse vea (näiteks kohustuslikkude väljade täitamata jätmisel) korral kasutajale kuvama kasutajasõbraliku veateate. Veateated peavad olema hallatavad. - Arendaja 7.19 Päringu vastusena kuvatud tabeli veerge on võimalik andmete/teksti tähestikulises järjekorras sorteerida. - Arendaja 7.20 Andmeväljade kohustuslikkus peab olema infosüsteemi väljadel märgitud tärniga (*). Võib olla mõni muu viis, mis on tellija poolt soovitud. Arendaja 7.21 Rakenduse andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel. - Arendaja 7.22 Kasutajaliides peab vastama ka dokumendis "Front-end arendusreeglid" kirjeldatud reeglitele Täpsemad nõuded on välja toodud Tehnilise kirjelduse Lisas 1.3 Front-end arendusreeglid. Arendaja Dokumentatsioon 8.1 Kogu rakenduse dokumentatsioon peab olema kirjutatud eesti keeles. Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud tellija jaoks) dokumentatsioon. Samuti võib erandiks olla välispooltega seotud projektid. Erandid tuleb kooskõlastada tellijaga enne dokumentatsiooni koostamist Arendaja 8.2 Lahendus kirjeldatakse RIHA määruse nõuete kohaselt. https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6 Arendaja / Projektijuht / Tellija RIHA haldur 8.3 Rakenduse dokumentatsioon peab sisaldama paigaldusjuhiseid, varundatavate komponentide kirjeldust, kasutajate kasutusjuhendeid, peakasutajate ja administraatorite kasutusjuhendeid, andmemudeleid, arhitektuurilisi mudeleid, süsteemitehnilisi kirjeldusi, nõudeid riistavarale, krüpt algoritme ja võtmepikkuseid, SSL /TLS sertifikaatide kasutuskohti jms Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori nimedega, korrektse keelekasutusega, selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et sõltumatu kolmas tehniliste IT baasteadmistega isik suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi). Arendaja 8.4 Rakenduse dokumentatsioon peab sisaldama tabelite-andmete-logide mahu kasvu arvestuslikku hinnangut rakenduse sihipärase kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas). Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel ja detailanalüüsi käigus. Mahuhinnang peab sisaldama ka logide säilitamise, arhiveerimise tähtaegu. Arendaja 8.5 Iga uue versiooniga peab alati välja tooma versiooni muudatuse kirjeldused ( release notes ). Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel. Arendaja 8.6 Rakenduse dokumentatsioon peab vastama ka dokumendis "Nõuded infosüsteemi dokumentatsioonile" kirjeldatud nõuetele Täpsemad nõuded on välja toodud Tehnilise kirjelduse Lisas 1.2.1 Nõuded infosüsteemi dokumentatsioonile . Arendaja Versioonihaldus 9.1 Kõik rakenduse testimiseks, koolituseks või implementeerimiseks üle antavad tarkvarapaketid peavad olema versioneeritud. Kasutama peab Tellija versioonihalduse repositooriumi. Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta peab hoidma oma erinevaid versioone. Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi Arendaja 9.2 Arendaja peab veenduma, et teeb muudatusi aktuaalsesse koodi. Ehk paralleelse arendamise puhul võetakse igal hommikul versioonihalduse repositooriumist viimane seis koodist. - Arendaja 9.3 Paigalduspaketile koostatakse kontrollkood (checksum), mis pannakse eraldi .sum failina tarnele kaasa. Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi koostamiseks: $ sha256sum filename [filename2] ... > kontrollkood.sum Arendaja 9.4 Kõik rakenduste tellijale lepingujärgsete üleantavate versioonide lähtekoodid peavad olema varustatud arendaja esindaja digiallkirjaga. Ka tagant järgi peab olema 100% kindel, et üle anti õige arendaja signeeritud, mitte kolmanda osapoole poolt kompromiteeritud versioon. Mahuka lähtekoodi asemel võib signeerida paigalduspaki kontrollkoodi. Arendaja 9.5 Nii arendamisel kui ka hoolduslepingute korral kasutatakse Tellija veahalduse keskkonda. Arendajale antakse selleks õigused Tellija veahalduse keskkonda. Juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi Arendaja Paigalduspaketi kooste 10.1 Tarnitava lahenduse koosseisus üle antava lähtekoodiga peavad kaasas olema kirjeldused sellest paigalduspaketi koosteks. Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb rida shell-käske või võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid või mis iganes muu moodus paigalduspaketi tekitamiseks. Eelistatud on kasutada GitL abi pipeline või Jenkins skripte/Jenkinsfile, sõltuvat kasutatavast lahendusest. Arendaja 10.2 Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada ainult minimaalse rakenduse käitamiseks vajamineva failikomplekti. Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole vajalik rakenduse käitamiseks. Arendaja 10.3 Kooste kirjelduste alusel valmivat paigalduspaketti peab olema võimalik liigutada erinevate masinate vahel. Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris tuleb see tingimata just sealsamas kokku kompileerida. Arendaja 10.4 Lähtekoodi kompileerimine peab olema teostatav ka võrguühenduse puudumise korral. Kasutada tuleb tellija poolset Artifactorit. Arendaja 10.5 Andmebaasi paigalduse skriptid ei tohi olla kompileeritud. Administraator tahab veenduda skripti sisus. Arendaja
Tööelu Infosüsteemi arendustööd A rhitektuur Sisukord TOC \o "1-3" \h \z \u Sisukord PAGEREF _Toc522274554 \h 1 Sissejuhatus PAGEREF _Toc522274555 \h 1 Komponentdiagramm PAGEREF _Toc522274556 \h 2 Paigaldusvaade PAGEREF _Toc522274557 \h 3 Rajadokument PAGEREF _Toc522274558 \h 4 Lahenduse planeeritav ligipääsuskeem arendajale PAGEREF _Toc522274559 \h 8 Süsteemi arhitektuuris kasutatavad tehnoloogiad PAGEREF _Toc522274560 \h 9 Sissejuhatus Dokumendis kirjelda takse Tööelu Infosüsteemi ( TeIS ) arhitektuurilist visiooni. D okumendis välja toodud komponendid ja nende omavaheline suhtlus ei ole lõplik ja on teostajale suuna ning põhimõtete näitajaks. Täpsem komponentide hulk ja vajadus peab tulema välja detailanalüüsi käigus. Diagrammidel roheliselt on märgitud osad, mi s vajavad loomist. Kollaselt märgitud komponendid on riigi poolt teostatud . Tervise ja Heaolu Infosüsteemide Keskus (TEHIK) peab läbirääkimis i , et neid kasutusse võtta. Kollased komponendid vajavad muuda tusi, et sobida TEHIK-u infrastruktuuri . Siniselt on välja toodud komp onendid, mis vajavad seadistusi ning väiksemaid muudatusi, et neid TeIS-s kasutada . Roosalt on välja toodud komponendid, mille seadistused ja muudatused ei ole TeIS-i osa. Komponentdiagramm Kirjeldamaks TeIS -s paiknevaid tehnilisi ja äriloogilisi komponente . Paigaldusvaade Paigaldusvaade k irjelda b süsteemi komponentide paigaldust ning omavahelist suhtlust. Infosüsteem on laias laastus jagatud kolmeks : konteineri sisesed teen u s ed, sisevõrgus kättesaadavad teenused ja välisvõrgust otse ligipääsetavad teenused . K omponen did peavad suhtlema omavahel üle standardsete protokollide. Loodavad komponendid peavad olema skaleeritavad, koormust juhitakse konteinerlahenduses oleva proxy teenusega. Loodavate komponentide omavaheline suhtlus käib üle JSON REST teenuse väljaarvatud andmebaasi, S3 ja X-tee suhtlused, mille puhul kasutatakse neile vastavaid protokolle. Avalikus võrgus olevad komponendid peavad kasutama SSO põhimõtet, ülejäänud komponentide vaheli n e suhtlus peab olema kaitstud API võtme või sertifikaadi au t entimisega. Täpsem lähenemine selgub detailanalüüsi käigus. Infosüsteem töötab UTF8 kodeeringus. Rajadokument AAM TEHIK-u poolt välja arendatud autentimise ja autoriseerimise moodul Autoriseerimisel kasutatav protokoll: SOAP Turvaserver Standardne RIA poolt loodud X -tee Kasutatakse liidestumiseks X -teega Kasutatav protokoll: SOAP Failihoidla S3 teenus failide talletamiseks Kasutatav protokoll: S3 Digit empel Moodul failide tembeldamiseks asutuse templiga Kasutatav protokoll: JSON ; PKCS11 Redis NoSql andmebaas sessioonide hoiustamiseks Kasutatav protokoll: RESP TeIS API Moodul teenuse pakkumiseks . Antud mooduli eesmärgiks on pakkuda võimalust asutustel, kes kasutavad enda poolt välja töötatud või sisse ostetud lahendust, liides tuda TeIS teenustega. Kasutatav protokoll: JSON TeIS Esitluskiht TeIS loodavate teenuste kasutamiseks mõeldud esitluskiht. Kasutatav protokoll: HTTPS X -tee tarbitavad teenused Moodul X -teega suhtlemis eks tarbitavate teenuste tarbes Kasutatav protokoll: SOAP; JSON X -tee pakutavad teenused Moodul X -teega suhtlemi seks pakutavate teenuste tarbes Kasutatav protokoll: SOAP; JSON Failide lugemis-kirjutamis moodul Mo odul failihoidlaga suhtlemiseks Kasutatav protokoll: S3 Faili allkirjastaja Moodul faili( de ) allkirj astamiseks Kasutatav protokoll: JSON Dokumendi generaator D okumendipõhjade haldamiseks, dokumentide konfigureerimiseks ja nende dünaamiliseks gen ereerimiseks kasutatav komponent Kasutatav protokoll: JSON Rollid Moodul rollide ja nende õigus te haldamiseks ja hoiustamiseks Kasutatav protokoll: JSON Volitused Moodul volius te haldamiseks ja hoiustamiseks Kasutatav protokoll: JSON Järelevalve Järelevalve protsessi de eest vastutav moodul. Täpsem analüüs peab selgitama, kas antud moodul on mõistlik tükeldada väik e semateks mooduliteks. Kasutatav protokoll: JSON Ettevõtted Ettevõttei d ja nende andmeid siduv moodul Kasutatav protokoll: JSON Isikud Isiku s ja nende andmeid siduv moodul Kasutatav protokoll: JSON Parimad praktikad Moodul parimate praktikate haldamiseks ja pakkumiseks Kasutatav protokoll: JSON Üritused Moodul ürituste jaoks Kasutatav protokoll: JSON Aruanded M oodul aruannete kuvamiseks tabloost Kasutatav protokoll: JSON Tableau TEHIK-s kasutatav lahendus aruannete loomiseks ja kuvamiseks andmelao andmete pealt Kasutatav protokoll: HTTPS Laadimis skriptid Andme analüüsi tarvis andmete ülekande skriptid põhi baasist andmelattu Kasutatav tehnoloogia: Pentaho ETL Kasutatav protokoll: JDBC Andmeait Andmela du analüüsi ja raportite tarvis Kasutatav tehnoloogia: Vertica DB Kasutatav protokoll: JDBC Andmebaas PostgreSQL andmebaas andmete hoiustamiseks Kasutatav protokoll: JDBC Teavitused Komponent teavituste genereerimiseks, ettevalmistamiseks ja haldamiseks Kasutatav protokoll: JSON TEAVIS Komponent teavituste saatmiseks Mass teadete jaoks kasutatakse parterit, et väl tida asutuse SMTP serveri musta nimekirja sattumist Kasutatav protokoll: JSON; SOAP; SMTP Sertifikaat Asutuse sertifikaat digitaalseks tembeldamiseks Paigutub HSM seadmel, mis vastab FIPS140-2 standardile Kasutatav protokoll: PKCS11 ... Moodulid, mis selguvad täpsema analüüsi käigus Kasutatav protokoll: JSON; SOAP; HTTPS; JDBC TARA Riiklik autentimis moodul https://www.ria.ee/ee/tara-autentimisteenus.html Hetkel teada olevad v älised liidestused X-tee teenustega Haigekassa infosüsteem andmed tööõnnetuste ja töövõimetuspäevade kohta PPA infosüsteem andmed lähetatud töötajate koht Ehitisregister andmed kavandatava või ehitatava ehitise asukoha, ehitamise ja ehitamisega seotud isikute andmete kohta. Automaatne teade TI-le, kui uue ehituse andmed sisestatakse ehitisregistrisse Äriregister andmed ettevõtte registrikoodi, ärinime, registreerimise aja, õigusliku vormi, juriidilise aadressi, seaduslike ja volitatud esindajate kohta Aadressandmete infosüsteem andmed ettevõtte aadressandmeväljade täitmiseks EMTA Töötamise register (TÖR) andmed töötamise, tööd tegeva isiku, tööd võimaldava isiku, töötamise alustamise aja, töötamise peatumise aja, töötamise lõpetamise aja, töötamise õigusliku aluse, alla 15-aastase töötegija töötingimuste ning eelloetletud kannete tegemise ja muutmise aja kohta Liiklusregister andmed ettevõtte autopargi koosseisu kohta, sõidukijuhtide järelevalve info Liiklusjärelevalve infosüsteem andmed järelevalvemenetluste ning süüteomenetluse käigus määratud karistuste õigusliku aluse kohta Majandustegevuse register andmed ettevõtte tegevusalade, tegevuslubade ning tegevuse maakonna kohta Rahvastikuregister andmed isiku perekonnanime, eesnime, soo, sünniaja, isikukoodi, kodakondsuse, elukoha, sideandmete ning surma kohta E-toimik andmed TI kui kohtuvälise menetleja poolt läbi viidud väärteomenetluste ning TI-ga seotud kohtumenetluste kohta Karistusregister andmed TI kui kohtuvälise menetleja poolt määratud karistuste kohta TARN infosüsteem andmed TI poolt määratud sunnirahade ning väär teokaristuste sundtäitmise kohta Eesti surmaregister (TAI) andmed TI-le surmade kohta mis on toimunud töökohal Kollektiivlepingute andmekogu SKA andmekogu lähetatud töötajate A1 vormide kohta Lahenduse plan eeritav ligipääsuskeem arendajale Tegu planeeritavate ligipääsudega, täpsem lähenemine selgub arenduse algusfaasis. Git on kättesaadav ka väljaspool arendajate VPN-i ja TEHIK-u võrku. Süsteemi arhitektuuris kasu tatavad tehnoloogiad Kubernetes Konteiner la henduste orkestreerimis - ja majutus lahendus Java LTS Komponentide loomisel kasutatav keel. Lahenduse loomisel kasutada viimast Java LTS versiooni, mis on kättesaadav. Postgre SQL TeIS raames kasutav andmebaasi mootor. Lahenduse loomisel tuleb kasutusse võtta viimane kättesaadav versioon. Angular Esitluskihis kasutatav raamistik. Kasutusele tuleb võtta lahenduse loomisel kõige uuem raamistiku versioon. Swagger Komponentide teenuste dokumenteerimis raamistik masin-masin liidestuse tarvis Python/Ruby/... Komponentide loomisel on lubatud kasutada alternatiivseid keeli, kuid see peab olema põhjendatud ja kokkulepitud TEHI K-u poolse arhitektiga. Lisaks on lubatud kasutada tehnoloogilisi lahendusi, mis on välja toodud Tehnilise kirjelduse Lisas 1.5 IT profiil, kuid see peab olema põhjendatud ja kokkulepitud TEHIK-u poolse arhitektiga projektis.
Tööelu infosüsteemi arendustööd Lisa 1. Tehniline kirjeldus Sisukord: TOC \o "1-3" \h \z \u 1. E esmärk PAGEREF _Toc523476563 \h 2 2. Arendus tellitakse raamlepingu alusel ühelt arendajalt PAGEREF _Toc523476564 \h 2 3. Hangitav skoop PAGEREF _Toc523476565 \h 2 3.1. Tellitavad tööd PAGEREF _Toc523476566 \h 2 4. TeIS Tööde teostamise põhimõtted PAGEREF _Toc523476567 \h 3 5. Eeldatav ajaplaan PAGEREF _Toc523476568 \h 4 6. Lisad PAGEREF _Toc523476569 \h 5 Eesmärk Riigihanke tulemusena sõlmitakse raamleping täitjaga , kes hakka b arendama Tööinspektsiooni Tööelu I nfosüsteemi ( TeIS ) . Arenduse eesmärk on, et 2020. aasta lõpus on Tööinspektsiooni (TI) ja tööandja töö tõhustamiseks kasutusel mugav, kiire ja madala tõrgete arvuga infosüsteem. Infosüsteemi kasutuselevõtu tulemusena väheneb kaudselt tööõnnetuste arv, paraneb töökeskkond ning see optimeerib TI ressursside (aeg, töötajate arv, raha) ning tööandjate ressursside kasutust. TeIS arendustööde raames valmib infosüsteem ja selle esitluskiht ning j ärelevalve moodu l. Lisaks selgitatakse raamlepingu täitmise käigus välja infosüsteemi edasised arendusvajadused. Kuigi täna on TI - l kasutusel infosüsteem ITI , kliendiportaal eTI ja tööandjatele suunatud töövahend Tööbik , luuakse käesoleva tellitava töö tulemusena TeIS nö nullist. Arenduse lõppedes ITI ja eTI suletakse , Tööbiku säilitamise või sulgemise otsuse tegemiseks tellitakse eraldi täiendav analüüs , mis ei ole antud tellitavate tööde skoobis . Infosüsteemid on kirjeldatud Tehnilise kirjelduse lisas 1.8 peatükis 2.1.2.3. Arendus tellitakse raamlepingu alusel ühe lt arendaja lt N ii spetsiifilise töö tellimisel tuleb maandada riske nii hästi kui võimalik, et saavutada soovitud eesmärk ning kasutada avalikku raha võimalikult kuluefektiivselt. Arenduse tükeldamine tooks kaasa mitmed riskid, mis realiseerumisel seaksid eesmärgini jõudmise kahtluse alla. Näiteks risk, et arendajate tööd ei pruugi omavahel koos toimima hakata ning keeruline on leida vigade puhul selle põhjustaja, sellest tulenevalt viibiks ka probleemi kõrvalda mine ning tõuseks arenduse kulu. Kuivõrd hangitava TeIS-i näol on tegemist tervikliku tehnilise lahendusega, on majanduslikult otstarbekas tööde teostamine hankida ühelt arendajalt. Hangitav skoop Töö elu infosüsteemi hankimiseks valmis 2018. a eelanalüüs (l isa 1.7 ) ja kasutajate vajaduste analüüs (lisa 1.8 ) , mis mõlemad keskendus id infosüsteemi järelevalve ja riskianalüüsi moodulile. Eelanalüüs ei käsitlenud esitluskihi autentimata vaadet . Analüüsi de vastuvõtmise järel pandi paika arendusvajadus ja järjekord. Esimeses etapis e hk käesoleva raamlepingu täitmise raames arendatakse i nfosüsteem ja selle esitluskiht ning järe levalve moodul . Järgmiste moodulite arenduse vajadus ja tellimine selgitatakse jooksvalt. Infosüsteemi lähteülesanne (lühiülevaade hetkeolukorrast, infosüsteemi loogiline mudel, funktsionaalsed ja mittefunktsionaalsed nõuded) on kirjeldatud eelanalüüsi peatükis 4 (lisa 1.7 ). Infosüsteemi arhitektuur on kirjeldatud ning visualiseeritud Lisas 1.1. Tellitavad tööd: Infosüstee m: IT, UX ja ärianalüüs (sh arhitektuuri analüüs); UI kasutajaliideste disain, sh: Kujunduselemendid; Ekraanivormide näidised; Olemasoleva RIA stiiliraamatu VEERA muutmine ja täiendamine vastavalt äri- ja UX analüüsi tulemitele ; Uute teenuste arendusprotsessis arendaja poolt teostatud HTML prototüüpide üle vaatamine, nõuetele vastavuse kontrollimine ja k innitamine; Liideste arendus komponentide vahel (vt. Lisa 1.7 p 4.2 Infosüsteemi loogiline mudel). NB Kuigi põhilised liidestused on kirjeldatud, ei ole loetelu lõplik. Detailanalüüsi käigus võib ilmneda vajadus lisaliidestuste järele; Uute teenuste arendamin e ja andmemigratsioon ITI-st (sh analüüs, konsultatsioon); TeIS jooksvate muudatusvajaduste realiseerimine; TeIS tarkvara hooldusteenus. Infosüsteemi esitluskiht Esitluskiht hõlmab endas autentimata ja autenditud vaadet. Autentimata vaade hakkab põhinema Tööelu portaalil, mis ehitatakse nö nullist. TeIS valmimise järel Tööelu portaal , senisel kujul, suletakse. Autentimata vaade ehk hanke raames valmiv Tööelu portaal saab olema aken autenditud vaatesse ehk valmivasse Tööelu infosüsteemi iseteenindusse. Esitluskihi täpsemad nõuded kirjeldatakse hankelepingus. J ärelevalve moodul; Järelevalv e moodul on kirjeldatud Lisa 1.7 punktides 3.1, 3.2, 3.4-3 . 9. Eelanalüüsis ei pruugi olla kirjas kõik järelevalve mooduli protsessid ega nende lõplik detailsusaste. TeIS Tööde teostamise põhimõtted Tööde teostamiseks sõlmitakse hankelepingud või esitatakse tööde tellimuskiri. Täitja peab olema valmis: teostama arendustöid funktsionaalsuse põhiselt, kus sisendiks on konkreetse tulemi (skoobi) tellimus, sh tähtaeg ja/või piirsumma; teostama arendustöid arendusmeeskonna töötundide põhiselt, kus arendused realiseeritakse agiilse arendusprotsessi põhimõtetel; andma arendustega seot ud konsultatsioone ja koolitusi. Eeldatav a japlaan Märkused: Arendustööde ajaplaan on indikatiivne ja koostatud tänase parima teadmise põhjal. Tööde täpsem maht ning järelevalve mooduli teenuste arenduste järjestus ja ajaraam täpsustuvad arhitektuuri- ja ärianalüüsi tulemina. Lisad Lisa 1.1. A rhitektuur Lisa 1.2. Mittefunktsionaalsed nõuded Lisa 1.2.1. Nõuded infosüsteemi dokumenteerimisele Lisa 1.3. Front-end arendusreeglid Lisa 1.4. Versioonihalduse kirjeldus Lisa 1.5 . IT-profiil Lisa 1.6 . Hooldustööde osutamise reeglid Lisa 1.7 . Tööelu infosüsteemi eelanalüüs Lisa 1.8. Kasutajate vajaduste analüüs
Tööelu Infosüsteemi arendustööd
Nõuded pakkuja meeskondadele
1. Tööde teostamiseks peab pakkujal olema võimekus teostada järgmisi töid:
- detailanalüüs (sh ärianalüüs, süsteemianalüüs);
- tarkvara arhitektuuri disain;
- esitluskihi disain;
- arendus;
- testimine.
2. Pakkuja peab esitama kaks meeskonda, sh mõlemasse meeskonda peavad kuuluma:
- projektijuht (1);
- analüütik (1);
- arendajad (2);
- arhitekt (1);
- testija (1).
3. Esitluskihi arendamise meeskonda peab kuuluma ka veebidisainer/UX disainer.
4. Mõlemas meeskonnas peab ühel meeskonnaliikmetest olema Scrum Masteri kogemus selle
rakendamisel vähemalt kahes projektis.
5. Meeskondade liikmed ei tohi kattuda, st sama isik ei tohi olla mõlemas meeskonnas. Samuti
ei tohi sama isik olla erinevates rollides. Erandiks on projektijuht ja arhitekt, kes võib olla 2
meeskonna peale ühine, pakkuja peab esitama seega minimaalselt 11 meeskonnaliiget, kes
hakkavad töid teostama.
MEESKOND 1
Taustsüsteemide arendusmeeskond
Projektijuht (nimi, isikukood): Heldi Raudsepp, 48405175216
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1 Omab vähemalt 3-aastast JAH Trinidad Wiseman OÜ, äri- ja süsteemianalüütik ning
töökogemust tarkvara arenduse projekti- ja meeskonnajuht, 09.2013 - tänaseni
projektijuhina.
Olulisemad projektid (mittetäielik loetelu):
• RIKi Delegaatide inforuumi arendus, peatöövõtja
Andmevara AS, 01.2017 – 07.2017, TWNi
meeskonna projektijuht ja analüütik, kontaktisik
Triin Sepp,
[email protected]
• Omniva e-kviitungi infosüsteemi arendus
02.2015 – 09.2016, Heldi oli projektis analüütiku,
projektijuhi ja Scrum Masteri rollides, kontaktisik
Pille Muni,
[email protected], kokku
projekt üle 5000 h
• HTMi Haridusportaali arendus, 02.2018 –
tänaseni, üle 6800 h, Heldi on projektis
analüütiku, Scrum Masteri ja projektijuhi
rollides, kontaktisik Erkki Jakobson,
[email protected]
• „E-notar 3“: iseteenindusportaali loomine,
digitõestuse võimaluse loomine ja e-notari
süsteemi täiendamine, TWNi meeskonna
projektijuht ning äri- ja süsteemianalüütik,
01.2018 – tänaseni, peatöövõtja Andmevara AS,
[email protected]
2 On juhtinud vähemalt ühte JAH • HTMi Haridusportaali arendus, 02.2018 –
tarkvara arendusprojekti viimase 2 tänaseni, üle 6800 h, Heldi on projektis
aasta jooksul, mille projekti maht analüütiku, Scrum Masteri ja projektijuhi
ületab 5000 tundi. rollides, kontaktisik Erkki Jakobson,
[email protected]
3* Scrum Master kogemus vähemalt JAH • Omniva e-kviitungi infosüsteemi arendus
kahes projektis 02.2015 – 09.2016, Heldi oli projektis analüütiku,
projektijuhi ja Scrum Masteri rollides, kontaktisik
Pille Muni,
[email protected], kokku
projekt üle 5000 h
• HTMi Haridusportaali arendus, 02.2018 –
tänaseni, üle 6800 h, Heldi on projektis
analüütiku, Scrum Masteri ja projektijuhi
rollides, kontaktisik Erkki Jakobson,
[email protected]
*Kohustuslik ühel meeskonnaliikmetest.
Analüütik (nimi, isikukood): Andrus Sarv, 36908260320
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab kõrgharidust ja JAH Tallinna Tehnikaülikool, 09.1987 - 05.1993,
Automatiseeritud juhtimissüsteemid, süsteemiinseneri
diplom
Omab vähemalt 3-aastast JAH 08.2010 - tänaseni Trinidad Wiseman OÜ äri- ja
töökogemust tarkvara arenduse süsteemianalüütik, analüüsiprojektide projektijuht
projektides analüütikuna või
tarkvara projekteerijana. 09.2004-07.2010 Editre OÜ äri- ja süsteemianalüütik
1b* Omab vähemalt 5-aastast JAH
töökogemust tarkvara arenduse
projektides analüütikuna või
tarkvara projekteerijana.
2 On osalenud vähemalt ühes IT JAH HTMi Haridusportaali arendus, 02.2018 – tänaseni, üle
projektis viimase kahe aasta 6800 h, Erkki Jakobson,
[email protected]
jooksul, mille arendusmaht on
rohkem kui 5000 tundi.
3 Omab töökogemust:
3.1 Menetlussüsteemide arendamisel JAH PRIA loomaregistri utiliseerimise e-teenus aprill – juuni
ja/või analüüsimisel 2018, tellija Fujitsu, Reeni Kuus,
[email protected]
3.2 äriprotsesside optimeerimisel JAH Elering klienditoe protsesside ärianalüüs juuli – sept
2017, Mikk Välja,
[email protected]
Haigekassa Partnerihalduse infosüsteemi detailanalüüs,
06.2016 – 03.2017, Ruth Türk,
[email protected]
Etendusasutuste ressursiplaneerimise süsteemi analüüs
aug – dets 2016, Kultuuriministeerium, Indrek Reimand,
[email protected]
3.3 Tsentraalsete süsteemidega JAH Omniva e-kviitungi arendus, 02.2015 – 09.2016, Pille
Muni,
[email protected]
Haigekassa Partnerihalduse infosüsteemi detailanalüüs,
06.2016 – 03.2017, Ruth Türk,
[email protected]
3.4 UML-iga (Unified Modeling JAH PPA kodakondsus ja migratsiooni valdkonna infosüsteemi
Language)1 kaardimaksete moodul. Süsteemi tellija SMIT,peatöövõtja
Fujistu, Mait Koppel,
[email protected] okt -
dets 2016
1
Siin ja edaspidi lugeda kogu dokumendis koos märkega "või samaväärne" kui see on objektiivselt võimalik.
Samaväärsuse tõendamise kohustus lasub pakkujal, kes sellele tugineda soovib.
PRIA loomaregistri utiliseerimise e-teenus aprill – juuni
2018, tellija Fujitsu, Reeni Kuus,
[email protected]
3.5 Prototüüpide koostamisel JAH HITSA Koolide veebilehtede ja kasutajakogemuse
ärianalüüs, 11.2016 – 03.2017, Taavi Aasma
[email protected]
Tallinna Ligipääsetavuse infosüsteemi analüüs dets 2017
kuni veebr 2018, Aire Johanson,
[email protected]
3.6 Konteinerlahenduse loomisel JAH HTMi Haridusportaali arendus, 02.2018 – tänaseni, üle
6800 h, Erkki Jakobson,
[email protected]
4** Scrum Master kogemus vähemalt EI
kahes projektis
*Täita tuleb kas väli 1a või 1b.
**Kohustuslik ühel meeskonnaliikmetest.
Arendaja 1 (nimi, isikukood): Jüri Tõnisson, 37803150249
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab kõrgharidust EI
infotehnoloogia, majanduse või
matemaatika – füüsika valdkonnas
ja
Omab vähemalt 3-aastast JAH
töökogemust IT arendajana.
1b* Omab vähemalt 5-aastast JAH 2016 -…TripleDev OÜ, 2012-2016 Rahandusministeeriumi
töökogemust IT arendajana. infotehnoloogiakeskus, 2005-2012 Maksu- ja Tolliamet
2 On osalenud vähemalt ühes IT JAH Tugiteenuste portaali täiendavad JAVA arendustööd
projektis viimase kahe aasta 2017-2018.a. Riigihange nr. 181519, tööde maht üle
jooksul, mille arendusmaht on 5000 tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
rohkem kui 5000 tundi ning (
[email protected], tel. 606 3400
projektis on kasutatud Spring ja
Hibernate raamistikke ning
REST/SOAP protokollil baseeruvaid
veebiteenuseid.
3 Omab vähemalt 2-aastast JAH Tugiteenuste portaali täiendavad JAVA arendustööd
töökogemust relatsiooniliste 2017-2018.a.. Riigihange nr. 181519, tööde maht üle
andmebaaside ja Java’ga. 5000 tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
RKAS elektroonilise dokumendihaldustarkvara
arendustööd, 2016-2017, Riigihange nr. 169800, Riigi
Kinnisvara AS, Taimo Veski (
[email protected], tel. 606
3400)
FIDEK (inffiles) füüsilise isiku tuludeklaratsioon 2005-
2015, Inf failide lisamise tarkvarassüsteemi arendustööd.
Failide valideerimine, parsimine ja salvestamine baasi.
Spetsialist osales projektis Java tarkvaraarendaja
ülesannetes. RMIT, Meelis Riima (
[email protected]
tel. 671 3940)
4 Omab töökogemust järgmiste
töövahendite, raamistike ja
keskkondadega:
4.1 GIT JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle
5000 tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.2 Jenkins JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.3 Intellij IDEA/Eclipse JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.4 Spring raamistik JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.5 Hibernate raamistik JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.6 REST ja SOAP veebiteenused JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.7 Konteinerlahenduse loomisel JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.8 PostgreSQL JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.9** Scrum Master kogemus vähemalt EI
kahes projektis
*Täita tuleb kas väli 1a või 1b.
**Kohustuslik ühel meeskonnaliikmetest.
Arendaja 2 (nimi, isikukood): Jaanus Heinlaid, 37405070026
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab kõrgharidust JAH Tallinna Tehnikaülikool, magister, arvuti- ja
infotehnoloogia, majanduse või süsteemitehnika
matemaatika – füüsika valdkonnas
ja
Omab vähemalt 3-aastast JAH 1999-2011 TietoEnator Eesti AS/Tieto Estonia AS, 2011-…
töökogemust IT arendajana. TripleDev OÜ
1b* Omab vähemalt 5-aastast JAH
töökogemust IT arendajana
2 On osalenud vähemalt ühes IT JAH Tugiteenuste portaali täiendavad JAVA arendustööd
projektis viimase kahe aasta 2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
jooksul, mille arendusmaht on tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
rohkem kui 5000 tundi ning (
[email protected], tel. 606 3400
projekts kasutatud Spring ja
Hibernate raamistikke ning
REST/SOAP protokollil baseeruvaid
veebiteenuseid.
3 Omab vähemalt 2-aastast JAH Tugiteenuste portaali täiendavad JAVA arendustööd
töökogemust relatsiooniliste 2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
andmebaaside ja Java’ga. tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
Reportnet rakenduste arendustööd 2014. aastal,
Hankeleping nr. 3322/B2014.EEA.55656, Lepingu alusel
teostas TripleDev enam kui 5000h mahus tarkvara
arendustöid, jooksvat infosüsteemide hooldustuge ja
dokumenteerimist Euroopa Keskkonnaagentuuri
Reportnet infosüsteemidele, Søren Roug, Head of Group,
OSE2 - IT networking and public systems,
[email protected], (+45) 33 36 71 00.
Spetsialist osales tehnilise projektijuhi ja vanemarendaja
ülesannetes.
Reportnet rakenduste arendustööd 2013. aastal
Hankeleping nr. 3322/B2012.EEA.55282, Lepingu alusel
teostas TripleDev enam kui 5000h mahus tarkvara
arendustöid, jooksvat infosüsteemide hooldustuge ja
dokumenteerimist Euroopa Keskkonnaagentuuri
Reportnet infosüsteemidele, Søren Roug, Head of Group,
OSE2 - IT networking and public systems,
[email protected], (+45) 33 36 71 00 Spetsialist
osales tehnilise projektijuhi ja vanemarendaja
ülesannetes.
4 Omab töökogemust järgmiste
töövahendite, raamistike ja
keskkondadega:
4.1 GIT JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.2 Jenkins JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.3 Intellij IDEA/Eclipse JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.4 Spring raamistik JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.5 Hibernate raamistik JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.6 REST ja SOAP veebiteenused JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.7 Konteinerlahenduse loomisel JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.8 PostgreSQL JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.9** Scrum Master kogemus vähemalt EI
kahes projektis
*Täita tuleb kas väli 1a või 1b.
**Kohustuslik ühel meeskonnaliikmetest.
Arhitekt (nimi, isikukood): Enriko Käsper, 37809150039
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab kõrgharidust JAH Tallinna Tehnikaülikool, bakalaureus, majanduslik
infotehnoloogia valdkonnas ja andmetöötlus
omab vähemalt 5-aastast JAH 1999-2011 Tieto Estonia AS süsteemikonsultant, tarkvara
töökogemust süsteemi- või arendaja, arhitekt, tiimijuht. 2011 - … TripleDev OÜ,
tarkvara arhitektina. arhitekt, tiimijuht, vanemarendaja.
1b* Omab vähemalt 10-aastast
töökogemust süsteemi- või
tarkvara arhitektina.
2 On osalenud vähemalt ühes IT JAH Tugiteenuste portaali täiendavad JAVA arendustööd
projektis viimase 2 aasta jooksul, 2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
mille arendusmaht on rohkem kui tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
5000 tundi. (
[email protected], tel. 606 3400
e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
3 Omab vähemalt 5-aastast JAH Tugiteenuste portaali täiendavad JAVA arendustööd
töökogemust relatsiooniliste 2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
andmebaaside ja Java’ga. tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
RKAS elektroonilise dokumendihaldustarkvara
arendustööd, 2016-2017, Riigihange nr. 169800, tööde
maht üle 5000 töötunni, tellija Riigi Kinnisvara AS, Taimo
Veski (
[email protected], tel. 606 3400) Spetsialist
osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Reportnet rakenduste arendustööd 2014. aastal,
Hankeleping nr. 3322/B2014.EEA.55656. Lepingu alusel
teostas TripleDev enam kui 5000h mahus tarkvara
arendustöid, jooksvat infosüsteemide hooldustuge ja
dokumenteerimist Euroopa Keskkonnaagentuuri
Reportnet infosüsteemidele, Søren Roug, Head of Group,
OSE2 - IT networking and public systems,
[email protected], (+45) 33 36 71 00
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
Reportnet rakenduste arendustööd 2013. aastal
Hankeleping nr. 3322/B2012.EEA.55282. Lepingu alusel
teostas TripleDev enam kui 5000h mahus tarkvara
arendustöid, jooksvat infosüsteemide hooldustuge ja
dokumenteerimist Euroopa Keskkonnaagentuuri
Reportnet infosüsteemidele, Søren Roug, Head of Group,
OSE2 - IT networking and public systems,
[email protected], (+45) 33 36 71 00
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
EMT e-poe arendustööd https://www.emt.ee/pood,
2010. Ülesanded sisaldasid e-poe portleti
väljaarendamist ja selle integreerimist EMT avalikku
veebiportaali. Kasutatud tehnoloogiad:Java EE, Liferay
Portal, Spring Portlet MVC, jQuery. Spetsialist osales
projektis vanemarendaja ülesannetes. Kontakt: tööandja
Tieto Estonia AS poolne projektijuht Indrek Majas tel
5116006.
Tallinna Linnavolikogu infosüsteemi AKTAL arendus
http://aktal.tallinnlv.ee, perioodis 2003-2010.
Infosüsteem haldab õigusaktide eelnõusid,
linnavolikogu istungite pidamist ning personaliinfot.
Kasutatud tehnoloogiad Java, XML, XSL, JSP, PostgreSQL
Spetsialist osales projektis tehnilise projektijuhi,
arhitekti ja vanemarendaja ülesannetes. Kontaktisik:
Mari Roots,
[email protected] tel. 640 4330
4 Omab töökogemust menetlus- ja JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
finantssüsteemide projekteerimisel Riigihange nr. 160618 (https://www.kviitung.ee/)
ja arendamisel. Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5 Omab töökogemust järgmiste
töövahendite, raamistike ja
keskkondadega:
5.1 Liquibase JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.2 Enterprise Architect JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.3 Jenkins JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.4 Linux/Unix JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
operatsioonisüsteemidega Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.5 Virtualiseerimistehnoloogiate ning JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
„continuous integration“ töövõtete Riigihange nr. 160618 (https://www.kviitung.ee/)
ning seadistamisega Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.6 SOA ja Mikroteenustel põhinevate JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
arhitektuurilahenduste Riigihange nr. 160618 (https://www.kviitung.ee/)
projekteerimisel ning Spetsialist osales projektis ScrumMasteri, arhitekti ja
realiseerimisel vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.7 Konteinerlahenduse loomisel JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.8 Spring raamistikuga JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.9 Hibernate raamistikuga JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.10 SOAP JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.11 Angular raamistikuga JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.12 Apache HTTPD ja Apache Tomcat JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
tehnoloogiatega Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.13 PostgreSQL JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
5.14** Scrum Master kogemus vähemalt JAH Tugiteenuste portaali täiendavad JAVA arendustööd
kahes projektis 2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected]) Spetsialist osales
projektis ScrumMasteri, arhitekti ja vanemarendaja
ülesannetes
Reportnet rakenduste arendustööd 2014. aastal,
Hankeleping nr. 3322/B2014.EEA.55656, Reportnet
rakenduste arendustööd 2014. aastal. Lepingu alusel
teostas TripleDev tarkvara arendustöid, jooksvat
infosüsteemide hooldustuge ja dokumenteerimist
Euroopa Keskkonnaagentuuri Reportnet
infosüsteemidele, Søren Roug, Head of Group, OSE2 - IT
networking and public systems,
[email protected], (+45) 33 36 71 00
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
Reportnet rakenduste arendustööd 2013. aastal
Hankeleping nr. 3322/B2012.EEA.55282, Reportnet
rakenduste arendustööd 2013. aastal. Lepingu alusel
teostas TripleDev tarkvara arendustöid, jooksvat
infosüsteemide hooldustuge ja dokumenteerimist
Euroopa Keskkonnaagentuuri Reportnet
infosüsteemidele, Søren Roug, Head of Group, OSE2 - IT
networking and public systems,
[email protected], (+45) 33 36 71 00
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
*Täita tuleb kas väli 1a või 1b.
** Kohustuslik ühel meeskonnaliikmetest.
Testija (nimi, isikukood): Gertrud Ohov, 48312250214
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1 Omab vähemalt 3-aastast JAH 2017 – 2018, vanem kvaliteedispetsialist, 2014-2017 LHV
töökogemust testijana või Pank, vanem kvaliteedispetsialist, 2010-2013, Tieto
programmeerijana. Estonia AS testijuht, 2007-2010 Tarkvara testija
2 On osalenud vähemalt kahes (2) JAH 1) Iute CRM kliendihalduse infosüsteemi
tarkvara arenduse projektis, kus on arendustööd, tellija Iute Credit Europe AS, Allar
teostanud testide Niinepuu, 04.2017 - tänaseni
automatiseerimist.
[email protected]
2) LHV Panga kaardimaksete vastuvõtu süsteemi
arendustööd, Indrek Kaljumäe, 2015-2016,
[email protected], tel. +372 527 6485
3* Scrum Master kogemus vähemalt EI
kahes projektis
*Kohustuslik ühel meeskonnaliikmetest
MEESKOND 2 Esitluskihi arenduse meeskond
Projektijuht (nimi, isikukood): Heldi Raudsepp, 48405175216
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1 Omab vähemalt 3-aastast JAH Trinidad Wiseman OÜ, äri- ja süsteemianalüütik ning
töökogemust tarkvara arenduse projekti- ja meeskonnajuht, 09.2013 - tänaseni
projektijuhina.
Olulisemad projektid (mittetäielik loetelu):
• RIKi Delegaatide inforuumi arendus, peatöövõtja
Andmevara AS, 01.2017 – 07.2017, TWNi
meeskonna projektijuht ja analüütik, kontaktisik
Triin Sepp,
[email protected]
• Omniva e-kviitungi infosüsteemi arendus
02.2015 – 09.2016, Heldi oli projektis analüütiku,
projektijuhi ja Scrum Masteri rollides, kontaktisik
Pille Muni,
[email protected], kokku
projekt üle 5000 h
• HTMi Haridusportaali arendus, 02.2018 –
tänaseni, üle 6800 h, Heldi on projektis
analüütiku, Scrum Masteri ja projektijuhi
rollides, kontaktisik Erkki Jakobson,
[email protected]
• „E-notar 3“: iseteenindusportaali loomine,
digitõestuse võimaluse loomine ja e-notari
süsteemi täiendamine, TWNi meeskonna
projektijuht ning äri- ja süsteemianalüütik,
01.2018 – tänaseni, peatöövõtja Andmevara AS,
[email protected]
2 On juhtinud vähemalt ühte JAH • HTMi Haridusportaali arendus, 02.2018 –
tarkvara arendusprojekti viimase 2 tänaseni, üle 6800 h, Heldi on projektis
aasta jooksul, mille projekti maht analüütiku, Scrum Masteri ja projektijuhi
ületab 5000 tundi. rollides, kontaktisik Erkki Jakobson,
[email protected]
3* Scrum Master kogemus vähemalt JAH • Omniva e-kviitungi infosüsteemi arendus
kahes projektis 02.2015 – 09.2016, Heldi oli projektis analüütiku,
projektijuhi ja Scrum Masteri rollides, kontaktisik
Pille Muni,
[email protected], kokku
projekt üle 5000 h
• HTMi Haridusportaali arendus, 02.2018 –
tänaseni, üle 6800 h, Heldi on projektis
analüütiku, Scrum Masteri ja projektijuhi
rollides, kontaktisik Erkki Jakobson,
[email protected]
* Kohustuslik ühel meeskonnaliikmetest
Analüütik (nimi, isikukood): Alan Altermann, 38002256014
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab kõrgharidust ja JAH • Chalmers University of Technology, Rootsi,
Management of Production magistrikraad,
lõpetamise aasta 2013
• Talinna Tehnikaülikool, informaatika
bakalaureus, lõpetamise aasta 2002
omab vähemalt 3-aastast JAH • Trinidad Wiseman OÜ, äri- ja süsteemianalüütik,
töökogemust tarkvara arenduse 06.2010 – tänaseni
projektides analüütikuna või
tarkvara projekteerijana. • ASA Quality Services OÜ, äri- ja
süsteemianalüütik, 03.2007 – 06.2010
• TietoEnator Eesti AS (hiljem Tieto Eesti AS),
süsteemianalüütik, 02.2003 - 03.2007
1b* Omab vähemalt 5-aastast JAH
töökogemust tarkvara arenduse
projektides analüütikuna või
tarkvara projekteerijana.
2 On osalenud vähemalt ühes IT JAH • SKAIS2 infosüsteemi analüüs ja
projektis viimase 2 aasta jooksul, kasutajakogemuse disain, arendusmaht üle 10
mille arendusmaht on rohkem kui 000 h, Tieto Eesti AS, 2016-2017, Janar Mürkhain
5000 tundi.
[email protected],
• SMITi asutusesisene arendusprojekt, üle 7000 h,
projekti sisu on salastatud, lisainfo saamiseks
pöörduda SMITi poole, kontaktisik Romet
Saaliste,
[email protected], 10.2017 –
tänaseni
3 Omab töökogemust:
3.1 menetlussüsteemide arendamisel JAH • SKAIS2 infosüsteemi analüüs ja
ja/või analüüsimisel kasutajakogemuse disain, arendusmaht üle 10
000 h, Tieto Eesti AS, 2016-2017, Janar Mürkhain
[email protected]
• HTMile Eesti Hariduse Infosüsteemi ärianalüüs
uue tarkvaralise lahenduse loomiseks, 02.2017 –
11.2017, Urmas Jaagusoo,
[email protected]
• KEMIT KOTKAS infosüsteemi analüüs, 06.2017 –
11.2017, Svea Nilsson,
[email protected]
• MKMile avaliku sektori 20 e-teenuse
detailanalüüs ja kontseptsiooni väljatöötamine,
04.2014 – 09.2014, Janek Rozov,
[email protected]
3.2 äriprotsesside optimeerimisel JAH • SKAIS2 infosüsteemi analüüs ja
kasutajakogemuse disain, arendusmaht üle 10
000 h, Tieto Eesti AS, 2016-2017, Janar Mürkhain
[email protected]
• Taimekaitse valdkonna infosüsteemi eelanalüüs,
Põllumajandusministeerium 06.2014 – 12.2014
Sirli Kalbus
[email protected]
• Põllumajandusameti maaparandussüsteemide ja
Maaparandusalal Tegutsevate Ettevõtjate
Registri analüüsi läbiviimine, 06.2013 – 12.2013
Maris Raudsepp,
[email protected]
3.3 tsentraalsete süsteemidega JAH • SKAIS2 infosüsteemi analüüs ja
kasutajakogemuse disain, arendusmaht üle 10
000 h, Tieto Eesti AS, 2016-2017, Janar
Mürkhain
[email protected]
• SIS/SIRENE analüüs ja realisatsioon, 08/2006 –
12/2008 Siseministeerium,
Keskkriminaalpolitsei, Politseiamet, Toomas
Adson (53 444 607)
3.4 UML-iga (Unified Modeling JAH • SKAIS2 infosüsteemi analüüs ja
Language) kasutajakogemuse disain, arendusmaht üle 6000
h, Tieto Eesti AS, 2016-2017, Janar Mürkhain
[email protected]
• SMITi asutusesisene arendusprojekt, projekti
sisu on salastatud, lisainfo saamiseks pöörduda
SMITi poole, kontaktisik Romet Saaliste,
[email protected], üle 7000 h, 10.2017 –
tänaseni
3.5 prototüüpide koostamisel JAH • SKAIS2 infosüsteemi analüüs ja
kasutajakogemuse disain, arendusmaht üle 6000
h, Tieto Eesti AS, 2016-2017, Janar Mürkhain
[email protected]
• SMITi asutusesisene arendusprojekt, üle 7000 h
projekti sisu on salastatud, lisainfo saamiseks
pöörduda SMITi poole, kontaktisik Romet
Saaliste,
[email protected] 10.2017 –
tänaseni
4** Scrum Master kogemus vähemalt EI
kahes projektis
*Täita tuleb kas väli 1a või 1b.
** Kohustuslik ühel meeskonnaliikmetest
Arendaja 1 (nimi, isikukood): Tauri Nikkari, 38603080314
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab kõrgharidust JAH TTÜ Informaatika bakalaureus, lõpetatud 2014
infotehnoloogia, majanduse või
matemaatika – füüsika valdkonnas
ja
omab vähemalt 3-aastast JAH • Trinidad Wiseman OÜ, front-end arendaja,
töökogemust IT arendajana. 10.2017 – tänaseni
• Telia Eesti AS, front-end arendaja, 08.2011 –
09.2017
• Automatweb, webmaster, 09.2010 – 07.2011
1b* Omab vähemalt 5-aastast JAH
töökogemust IT arendajana.
2 On osalenud vähemalt ühes IT JAH • Tugiteenuste portaali täiendavad JAVA
projektis viimase kahe aasta arendustööd 2017-2018.a. Riigihange nr.
jooksul, mille arendusmaht on 181519, tööde maht üle 5000 tunni. Tellija Riigi
rohkem kui 5000 tundi ning Kinnisvara AS, Taimo Veski
projektis on kasutatud Angular (
[email protected], tel. 606 3400
raamistikke ning REST/SOAP
protokollil baseeruvaid • Telia süsteemide arendus, 08.2011 – 09.2017,
veebiteenuseid. projektide kogumaht üle 5000h, kontaktisik Rait
Vagula,
[email protected]
3 Omab vähemalt 2-aastast JAH • Tugiteenuste portaali täiendavad JAVA
töökogemust esitluskihi arendustööd 2017-2018.a. Riigihange nr.
arendamisel. 181519, tööde maht üle 5000 tunni. Tellija Riigi
Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
• Telia veebi ja front-end raamistike loomine,
01.2016 – 06.2017, kontaktisik Rait Vagula,
[email protected]
• Eesti Telekomi veeb 09.2013 – 07.2014,
kontaktisik Rait Vagula,
[email protected]
• Elioni äriklientide iseteenindusportaal 03.2012 –
05.2013, kontaktisik Gunnar Eensalu
[email protected]
4 Omab töökogemust järgmiste
töövahendite, raamistike ja
keskkondadega:
4.1 GIT JAH • Telia erinevad projektid 6a, projektide kogumaht
üle 5000h, kontaktisik Rait Vagula,
[email protected]
• Tugiteenuste portaali täiendavad JAVA
arendustööd 2017-2018.a. Riigihange nr.
181519, tööde maht üle 5000 tunni. Tellija Riigi
Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.2 Jenkins JAH • Web3 arendus, Telia, 08.2011 - 03.2012 ,
kontaktisik Gunnar Eensalu
[email protected]
4.3 Intellij IDEA/Eclipse JAH Eclipse: TTÜ Java ainetes.
Intelij IDEA:
• Web3 arendus, Telia, 08.2011 - 03.2012 ,
kontaktisik Gunnar Eensalu
[email protected]
• Puuetega Inimeste transpordi infosüsteem PIT2,
peatöövõtja Andmevara AS, 01.2018 – tänaseni
[email protected]
Intelij Webstorm:
• Tugiteenuste portaali täiendavad JAVA
arendustööd 2017-2018.a. Riigihange nr.
181519, tööde maht üle 5000 tunni. Tellija Riigi
Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.4 Angular JAH • Tugiteenuste portaali täiendavad JAVA
arendustööd 2017-2018.a. Riigihange nr.
181519, tööde maht üle 5000 tunni. Tellija Riigi
Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.5 REST ja SOAP veebiteenused JAH • Tugiteenuste portaali täiendavad JAVA
arendustööd 2017-2018.a. Riigihange nr.
181519, tööde maht üle 5000 tunni. Tellija Riigi
Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.6 HTML5 ja CSS (SASS) JAH • Telia veeb ja front-end raamistik (HTML5, SASS),
01.2016 – 06.2017. 01.2016 – 06.2017 Projekti
kogumaht üle 1000 tunni, kontaktisik Rait
Vagula,
[email protected]
• Tugiteenuste portaali täiendavad JAVA
arendustööd 2017-2018.a. Riigihange nr.
181519, tööde maht üle 5000 tunni. Tellija Riigi
Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.7 Scrum Master kogemus vähemalt EI
kahes projektis**
*Täita tuleb kas väli 1a või 1b.
** Kohustuslik ühel meeskonnaliikmetest
Arendaja 2 (nimi, isikukood): Henri Kokk, 38809295223
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab kõrgharidust EI
infotehnoloogia, majanduse või
matemaatika–füüsika valdkonnas
ja
omab vähemalt 3-aastast JAH
töökogemust IT arendajana.
1b* Omab vähemalt 5-aastast JAH Trinidad Wiseman OÜ (varem Wiseman Interactive OÜ),
töökogemust IT arendajana front-end arendaja, 2009 – tänaseni
2 On osalenud vähemalt ühes IT JAH HTMi Haridusportaali arendus, 02.2018 – tänaseni, üle
projektis viimase kahe aasta 6800 h, Erkki Jakobson,
[email protected]
jooksul, mille arendusmaht on
rohkem kui 5000 tundi ning
projektis on kasutatud Angular
raamistikke ning REST/SOAP
protokollil baseeruvaid
veebiteenuseid.
3 Omab vähemalt 2-aastast JAH Trinidad Wiseman OÜ (varem Wiseman Interactive OÜ),
töökogemust esitluskihi loomisel. front-end arendaja, erinevad projektid 2009 – tänaseni,
sh
• Tallinna Ettevõtlusametile Visittallinn.ee
veebiplatvormi arendus, 2009 – tänaseni, Evelin
Tsirk,
[email protected]
• Trinidad Wisemani sisemise palgaarvestuse ja
statistika infosüsteemi arenduse projekt,
05.2017 – 10.2017,
[email protected]
• HTMi Haridusportaali arendus, 02.2018 –
tänaseni, üle 6800 h, Erkki Jakobson,
[email protected]
4 Omab töökogemust järgmiste
töövahendite, raamistike ja
keskkondadega:
4.1 GIT JAH Trinidad Wisemani erinevad projektid viimase seitsme
aasta jooksul, sh:
• Tartu Linnavalitsusele Tartu kultuuriakna
arenduse projekt, 03.2017 – 10.2017, Karin Valk
[email protected]
• Max.ee veebiplatvormi arendus, Max123 AS,
04.2017 – 06.2017, Raul Pero,
[email protected]
• Talinna Ettevõtlusametile Visittallinn.ee
veebiplatvormi arendus, 2009 – tänaseni, Evelin
Tsirk,
[email protected]
4.2 Jenkins JAH • Trinidad Wisemani palgaarvestuse ja statistika
infosüsteemi arenduse projekt, 05.2017 –
10.2017,
[email protected]
4.3 Intellij IDEA/Eclipse JAH • Trinidad Wisemani palgaarvestuse ja statistika
infosüsteemi arenduse projekt, 05.2017 –
10.2017,
[email protected]
4.4 Angular JAH • Angular Js – Mascus.com mobiilirakendus,
07.2017 – tänaseni,
[email protected]
• Angular 2+ - HTMi Haridusportaali arendus,
02.2018 – tänaseni, üle 6800 h, Erkki Jakobson,
[email protected]
4.5 REST ja SOAP veebiteenused JAH • HTMi Haridusportaali arendus, 02.2018 –
tänaseni, üle 6800 h, Erkki Jakobson,
[email protected]
• Mascus.com mobiilirakendus, 07.2017 –
tänaseni, Jarmo Tauren (tegu soomlasega)
[email protected]
• Mõisakoolid.ee arendus, 04.2015 – 06.2016,
Anne Lass,
[email protected]
4.6 Scrum Master kogemus vähemalt Ei
kahes projektis**
*Täita tuleb kas väli 1a või 1b.
** Kohustuslik ühel meeskonnaliikmetest.
Arhitekt (nimi, isikukood): Enriko Käsper, 37809150039
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab kõrgharidust JAH Tallinna Tehnikaülikool, bakalaureus, majanduslik
infotehnoloogia valdkonnas ja andmetöötlus
omab vähemalt 5-aastast JAH 1999-2011 Tieto Estonia AS süsteemikonsultant, tarkvara
töökogemust süsteemi- või arendaja, arhitekt, tiimijuht. 2011 - … TripleDev OÜ,
tarkvara arhitektina. arhitekt, tiimijuht, vanemarendaja.
1b* Omab vähemalt 10-aastast JAH
töökogemust süsteemi- või
tarkvara arhitektina.
2 On osalenud vähemalt ühes IT JAH Tugiteenuste portaali täiendavad JAVA arendustööd
projektis viimase 2 aasta jooksul, 2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
mille arendusmaht on rohkem kui tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
5000 tundi. (
[email protected], tel. 606 3400
e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected]) Spetsialist osales
projektis ScrumMasteri, arhitekti ja vanemarendaja
ülesannetes
3 Omab vähemalt 5-aastast JAH Tugiteenuste portaali täiendavad JAVA arendustööd
töökogemust relatsiooniliste 2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
andmebaaside ja Java’ga. tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
RKAS elektroonilise dokumendihaldustarkvara
arendustööd, 2016-2017, Riigihange nr. 169800, tööde
maht üle 5000 töötunni, tellija Riigi Kinnisvara AS, Taimo
Veski (
[email protected], tel. 606 3400) Spetsialist
osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected]) Spetsialist osales
projektis ScrumMasteri, arhitekti ja vanemarendaja
ülesannetes
Reportnet rakenduste arendustööd 2014. aastal,
Hankeleping nr. 3322/B2014.EEA.55656, Reportnet
rakenduste arendustööd 2014. aastal. Lepingu alusel
teostas TripleDev tarkvara arendustöid, jooksvat
infosüsteemide hooldustuge ja dokumenteerimist
Euroopa Keskkonnaagentuuri Reportnet
infosüsteemidele, Søren Roug, Head of Group, OSE2 - IT
networking and public systems,
[email protected], (+45) 33 36 71 00
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
Reportnet rakenduste arendustööd 2013. aastal
Hankeleping nr. 3322/B2012.EEA.55282, Reportnet
rakenduste arendustööd 2013. aastal. Lepingu alusel
teostas TripleDev tarkvara arendustöid, jooksvat
infosüsteemide hooldustuge ja dokumenteerimist
Euroopa Keskkonnaagentuuri Reportnet
infosüsteemidele, Søren Roug, Head of Group, OSE2 - IT
networking and public systems,
[email protected], (+45) 33 36 71 00
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
EMT e-poe arendustööd https://www.emt.ee/pood,
2010. Ülesanded sisaldasid e-poe portleti
väljaarendamist ja selle integreerimist EMT avalikku
veebiportaali. Kasutatud tehnoloogiad:Java EE, Liferay
Portal, Spring Portlet MVC, jQuery. Spetsialist osales
projektis vanemarendaja ülesannetes. Kontakt: tööandja
Tieto Estonia AS poolne projektijuht Indrek Majas tel
5116006.
Tallinna Linnavolikogu infosüsteemi AKTAL arendus
http://aktal.tallinnlv.ee, perioodis 2003-2010.
Infosüsteem haldab õigusaktide eelnõusid,
linnavolikogu istungite pidamist ning personaliinfot.
Kasutatud tehnoloogiad Java, XML, XSL, JSP, PostgreSQL
Spetsialist osales projektis tehnilise projektijuhi,
arhitekti ja vanemarendaja ülesannetes. Kontaktisik:
Mari Roots,
[email protected] tel. 640 4330
4 Omab töökogemust järgmiste
töövahendite, raamistike ja
keskkondadega:
4.1 Liquibase JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.2 Enterprise Architect JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.3 Jenkins JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.4 Linux/Unix JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
operatsioonisüsteemidega Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.5 Virtualiseerimistehnoloogiate ning JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
„continuous integration“ töövõtete Riigihange nr. 160618 (https://www.kviitung.ee/)
ning seadistamisega Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.6 SOA ja Mikroteenustel põhinevate JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
arhitektuurilahenduste Riigihange nr. 160618 (https://www.kviitung.ee/)
projekteerimisel ning Spetsialist osales projektis ScrumMasteri, arhitekti ja
realiseerimisel vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.7 Spring raamistikuga JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.8 Hibernate raamistikuga JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle
5000 tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.9 SOAP JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.10 Angular raamistikuga JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.11 Apache HTTPD ja Apache Tomcat JAH e-kviitungi kesksüsteemi arendustööd 2015-2016,
tehnoloogiatega Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected])
4.12 PostgreSQL JAH Tugiteenuste portaali täiendavad JAVA arendustööd
2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
4.13** Scrum Master kogemus vähemalt JAH Tugiteenuste portaali täiendavad JAVA arendustööd
kahes projektis 2017-2018.a. Riigihange nr. 181519, tööde maht üle 5000
tunni. Tellija Riigi Kinnisvara AS, Taimo Veski
(
[email protected], tel. 606 3400
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
e-kviitungi kesksüsteemi arendustööd 2015-2016,
Riigihange nr. 160618 (https://www.kviitung.ee/)
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes, tellija Eesti Post AS, Tiina
Leinbock, (
[email protected]) Spetsialist osales
projektis ScrumMasteri, arhitekti ja vanemarendaja
ülesannetes
Reportnet rakenduste arendustööd 2014. aastal,
Hankeleping nr. 3322/B2014.EEA.55656, Reportnet
rakenduste arendustööd 2014. aastal. Lepingu alusel
teostas TripleDev tarkvara arendustöid, jooksvat
infosüsteemide hooldustuge ja dokumenteerimist
Euroopa Keskkonnaagentuuri Reportnet
infosüsteemidele, Søren Roug, Head of Group, OSE2 - IT
networking and public systems,
[email protected], (+45) 33 36 71 00
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
Reportnet rakenduste arendustööd 2013. aastal
Hankeleping nr. 3322/B2012.EEA.55282, Reportnet
rakenduste arendustööd 2013. aastal. Lepingu alusel
teostas TripleDev tarkvara arendustöid, jooksvat
infosüsteemide hooldustuge ja dokumenteerimist
Euroopa Keskkonnaagentuuri Reportnet
infosüsteemidele, Søren Roug, Head of Group, OSE2 - IT
networking and public systems,
[email protected], (+45) 33 36 71 00
Spetsialist osales projektis ScrumMasteri, arhitekti ja
vanemarendaja ülesannetes
*Täita tuleb kas väli 1a või 1b.
** Kohustuslik ühel meeskonnaliikmetest.
Veebidisainer/UX disainer (nimi, isikukood): Sander Lastovets, 38709025214
Nõude Nõuded Kas Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood vastab Projektidele viitamisel märkida projekti tellinud asutus,
esitatud tellija kontaktisik ja projekti nimi, arvestades, et hankijal
nõudele on õigus kontrollida esitatud andmeid viidatud
(JAH/ EI) kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1a* Omab vähemalt JAH • Eesti Kunstiakadeemia graafilise disaini
rakenduskõrgharidust graafilise bakalaureus, lõpetamise aasta 2010
disaini, interaktsioonidisaini või
veebitehnoloogiate erialal ja • KASK (Belgia) graafilise disaini magister,
lõpetamise aasta 2011
omab vähemalt 3-aastast JAH Trinidad Wiseman, UX disainer, interaktsioonidisainer,
töökogemust veebidisainerina. front-end arendaja, 11/2012 – tänaseni
1b* Omab vähemalt 5-aastast JAH
töökogemust veebidisainerina.
2 On osalenud veebidisainerina JAH • Telia TV kasutajaliidese väljatöötamine, 10.2014
vähemalt 6 veebilehe – tänaseni, Telia, Alar Lutsar,
[email protected]
kasutajaliidese (e-kommerts,
iseteenindus või samaväärne) • Omniva e-kviitungi arendus, 02.2015 – 09.2016,
disaini projektis viimase 3 aasta Pille Muni,
[email protected]
jooksul. Tõenduseks esitab enda
poolt loodud veebidisaini visuaalse • EKI sõnastiku- ja terminibaasisüsteemide
faili. Tööde esitamiseks võib arendus, riigihange nr. 186015, Eesti Keele
kasutada enim levinuid Instituut, peatöövõtja TripleDev OÜ, 09.2017 –
tänaseni,
[email protected]
failiformaate.
• MKM teenuste kataloog, 05.2017 – 12.2017, Airi
Reidi,
[email protected]
• Qlaara veebisõnastik, 01.2014 – 02.2017, Arvi
Tavast,
[email protected]
• MINU.TV veebileht, 12.2014– 04.2017, Telia,
Alar Lutsar,
[email protected]
• RIA eID teadmusportaali ja
iseteeninduskeskkonna loomise proovitöö,
08.2018.
Esitatud kujundusfailid on ärisaladusega kaitstud töö
ja nende levitamine on keelatud.
3 Omab töökogemust:
3.1 veebilehtede graafilise disaini JAH • Telia e-lahenduste väljatöötamine, sh digi-tv
loomisel projektid, 12.2012 – tänaseni, Alar Lutsar,
[email protected]
3.2 persoonade loomisel JAH • Telia e-lahenduste väljatöötamine, sh digi-tv
projektid, 12.2012 – tänaseni, Alar Lutsar,
[email protected]
3.3 töövoogude kirjeldamisel JAH • Telia e-lahenduste väljatöötamine, sh digi-tv
projektid, 12.2012 – tänaseni, Alar Lutsar,
[email protected]
3.4 Wireframe ja prototüüpide JAH • e-Notar3 arendus, 01.2018 – tänaseni,
loomisel (HTML5; CSS(SASS); peatöövõtja Andmevara AS,
Javascript)
[email protected]
• EKI sõnastiku- ja terminibaasisüsteemide
arendus, riigihange nr. 186015, Eesti Keele
Instituut, peatöövõtja TripleDev OÜ, 09.2017 –
tänaseni,
[email protected]
• MKM e-kataloogi arendus, 05.2017 – 11.2017,
[email protected]
3.5 kasutatavuse (UX) analüüside JAH • Telia e-lahenduste väljatöötamine, sh digi-tv
teostamisel projektid, 12.2012 – tänaseni, Alar Lutsar,
[email protected]
• EKI sõnastiku- ja terminibaasisüsteemide
arendus, riigihange nr. 186015, Eesti Keele
Instituut, peatöövõtja TripleDev OÜ, 09.2017 –
tänaseni,
[email protected]
4 On osalenud vähemalt kahes JAH • e-Notar3 infosüsteemi arendus, 01.2018 –
projektis viimase 2a jooksul, kus tänaseni, peatöövõtja Andmevara AS, Triin Sepp,
järgiti vähemalt WCAG 2.0 AA-taset
[email protected]
ja W3C standardit.
• EKI sõnastiku- ja terminibaasisüsteemide
arendus, riigihange nr. 186015, Eesti Keele
Instituut, peatöövõtja TripleDev OÜ, 09.2017 –
tänaseni,
[email protected]
• MKM teenuste kataloog, 05.2017 – 12.2017, Airi
Reidi,
[email protected]
5** Scrum Master kogemus vähemalt EI
kahes projektis
*Täita tuleb kas väli 1a või 1b ning 5a või 5b
** Kohustuslik ühel meeskonnaliikmetest
Testija (nimi, isikukood): Nadežda Matvejeva, 48304070381
Nõude Nõuded Kas vastab Täpsustus selle kohta kus/millal/kuidas on nõue täidetud.
kood esitatud Projektidele viitamisel märkida projekti tellinud asutus,
nõudele tellija kontaktisik ja projekti nimi, arvestades, et hankijal
(JAH/ EI)
on õigus kontrollida esitatud andmeid viidatud
kontaktisiku vahendusel.
Välja täitmine on kohustuslik.
1 Omab vähemalt 3-aastast JAH 2018 – … TripleDev OÜ, vanem kvaliteedispetsialist
töökogemust testijana või 2014-2018 Kühne+Nagel AS, Senior Agile Quality
programmeerijana. Manager, 2007-2014 Fujitsu Services OÜ, test manager
2 On osalenud vähemalt kahes JAH 1) Iute CRM kliendihalduse infosüsteemi
tarkvara arenduse projektis, kus on arendustööd, 06.2018. – tänaseni, tellija Iute
teostanud testide Credit Europe AS, Allar Niinepuu,
automatiseerimist.
[email protected]
2) Kühne+Nagel AS infosüsteemid eCollaboration
Suite, CLICK. 2014-2017, Kontakttelefon 660
0966, hr. Kai Albowski, Head of IT Centre Tallinn,
Kühne + Nagel.
3* Scrum Master kogemus vähemalt EI
kahes projektis*
* Kohustuslik ühel meeskonnaliikmetest
Hankelepingu projekt
HANKELEPING nr.....
Tervise ja Heaolu Infosüsteemide Keskus (edaspidi nimetatud ka Tellija), registrikood
70009700, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor
Katrin Reinhold ja
...................................., (edaspidi nimetatud ka Täitja), registrikood..............,
aadress........., keda esindab .........................................................................
edaspidi koos või eraldi nimetatud ka Pool või Pooled, sõlmisid Tellija läbiviidud
riigihankes „Tööelu infosüsteemi arendustööd (riigihanke viitenumber ...) poolte vahel
pp.kk.aaaa sõlmitud raamlepingu alusel käesoleva hankelepingu (edaspidi nimetatud ka
Leping) alljärgnevas:
1. LEPINGU ESE
1.1. Lepingu esemeks on Tööelu infosüsteemi ............. tööd (Tellija võib
hankelepinguga tellida arendustöid koos garantiiteenusega, arhitektuuri- ja
analüüsitöid koos garantiiteenusega, hooldustöid jmt töid, mis on vajalikud Tööelu
infosüsteemi arendamiseks – täpne hankelepingu sisu lepitakse kokku lepingu
sõlmimise käigus) (edaspidi nimetatud ka Tööd).
1.2. Tööde loetelu, Tööde teostamise tingimused ja konkreetsed realiseerimistähtajad
on sätestatud Lepingu lisas 1 (tehniline kirjeldus).
1.3. Lepingu Tööde maht on ... (hankelepingu sõlmimisel lepitakse kokku hankelepingu
konkreetne maht kas töötundides, fikseeritud hinnana kogu teostatava töö eest,
hooldustööde puhul vajadusel kuutasuna vmt moel vastavalt Poolte kokkuleppele).
1.4. Vajadusel on Tellijal õigus tellida ja Täitjal kohustus teostada Lepingu esemega
seotud täiendavaid Töid kuni 20% ulatuses kokkulepitud mahust.
1.5. Täiendavate Tööde tellimine ja sellega kaasnevad muudatused Lepingu täitmisel
lepitakse Poolte vahel kokku vähemalt kirjalikku taasesitamist võimaldavas
digitaalselt allkirjastatud vormis.
2. LEPINGU ÜLDTINGIMUSED
2.1. Pooled teevad Lepingu täitmiseks ja Lepingu eesmärkide saavutamiseks koostööd.
Lepingu täitmisel kohustuvad Pooled tegema kõik vajalikud pingutused, et täita
Leping õigeaegselt ja vastavalt kokkulepetele, lähtudes käesolevas Lepingus,
raamlepingus ja õigusaktides sätestatud kohustustest.
2.2. Käesolevas hankelepingus reguleerimata osas juhinduvad Pooled raamlepingus
fikseeritud tingimustest.
3. TÖÖDE ÜLEANDMISE JA VASTUVÕTMISE KORD
3.1. Täitja kohustub Töö üle andma/teostama .... (tähtaeg).
3.2. Täitja annab Töö üle vastavalt lisas 1 kokku lepitud tingimustele, juhindudes lisaks
käesolevas Lepingus sätestatule ka Poolte vahel sõlmitud raamlepingust.
3.3. Töö antakse Tellijale üle koos nõuetekohase dokumentatsiooniga vastavalt
raamlepingu lisale 1.2.1 „Nõuded infosüsteemi dokumenteerimisele“, kui ei ole
kokku lepitud teisti. Vajadusel täpsustab/muudab Tellija dokumenteerimise
nõudeid või nõutud dokumentide nimekirja konkreetse hankelepingu sõlmimisel.
3.4. Töö antakse üle Täitja poolt allkirjastatud üleandmise ja vastuvõtmise aktiga
(edaspidi ka Akt).
3.5. Koos üle antava Tööga annab Täitja Tellijale üle kõik Tööde intellektuaalse omandi
õigused vastavalt raamlepingus sätestatule.
4. TÖÖDE MAKSUMUS JA ARVELDUSTE KORD
4.1. Tellija tasub üksnes Lepingu alusel tellitud, teostatud ja üle antud Tööde eest.
4.2. Ühe töötunni maksumuseks Tööde teostamisel on ..... (maksumus sõnadega)
eurot ilma käibemaksuta (Lepitakse kokku punktis 1.3 sätestatud Tööde mahust
lähtudes. Vajadusel märgitakse Lepingu alusel välja maksmisele kuuluv
kogusumma, nt fikseeritud kuutasu kasutamise korral, ühe töötunni hinda eraldi
välja ei tooda, vaid märgitakse fikseeritud tasu suurus).
4.3. Tellija tasub Lepingu alusel tellitud Tööde eest kokku ..... (maksumus sõnadega)
eurot ilma käibemaksuta (Lepitakse kokku lähtudes punktis 1.3 sätestatud Tööde
mahust lähtudes).
4.4. Täitjal on õigus esitada arve pärast Tööde Tellija poolt vastu võtmist, mis toimub
Tellija poolse Akti allkirjastamisega. Täitja annab Tellijale arve tasumiseks tähtaja
minimaalselt 21 kalendripäeva alates arve esitamisest.
4.5. Täitja esitab Tellijale arve masinloetaval kujul aadressil
[email protected].
5. LEPINGU LÕPETAMINE JA ÜLES ÜTLEMINE
5.1. Leping lõpeb kohustuste täitmisega, Lepingu lõpetamise kokkuleppe sõlmimisega,
muul Lepingus ettenähtud või seadusest tuleneval alusel.
5.2. Tellijal on õigus Leping igal ajal üles öelda, teatades sellest 60 (kuuskümmend)
kalendripäeva ette.
5.3. Poolel on õigus Leping etteteatamistähtaega järgimata igal ajal üles öelda, kui
teine Pool on Lepingut oluliselt rikkunud või esineb raamlepingu punktis 14.4
nimetatud alus Lepingu üles ütlemiseks. Olulise lepingurikkumisena mõistavad
pooled raamlepingu punktis 14.5 sätestatut.
6. KONTAKTISIKUD
6.1. Tellija kontaktisik on: …. …, telefon …., e-post: ….
6.2. Täitja kontaktisik on: …, …., telefon … e-post: ….
7. LÕPPSÄTTED
7.1. Täitjal puudub volitus tegeleda Lepingu raames avalike suhetega ning anda teateid
pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja
arvatud Tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul.
7.2. Leping, Lepingu lisad ja muud selle alusel või selle täitmiseks sõlmitavad
kokkulepped jõustuvad alla kirjutamisel ning kehtivad kuni Poolte kõikide kohustuste
täitmiseni.
7.3. Kõik teated seoses Lepingu täitmisega esitatakse e-posti või kirja teel Lepingus
nimetatud aadressil või mõnel muul aadressil, mille Pool on teisele Poolele
teatavaks teinud. Informatiivset teadet võib edastada ka telefoni teel.
Informatiivseks loetakse teade, millega ei kaasne iseseisvaid õiguslikke tagajärgi.
7.4. Käesolevat Lepingut saab muuta Poolte kirjalikku taasesitamist võimaldavas vormis
sõlmitud kokkuleppel. Kõik Lepingu muudatused tuleb sõlmida Lepinguga samas
vormis ja need jõustuvad Poolte poolt allkirjastamisel.
7.5. Kõik käesoleva Lepingu täitmisest tulenevad vaidlused ja lahkarvamused püütakse
lahendada Poolte vaheliste läbirääkimiste teel. Kokkuleppe mittesaavutamisel
lahendatakse vaidlus Harju Maakohtus. Lepingule kohaldub Eesti õigus.
8. LISAD
8.1. Lisa 1 - Hankelepingu eseme tehniline kirjeldus;
8.2. Lisa 2 – Täitja poolt esitatud pakkumus.
9. Poolte allkirjad
Tellija Täitja
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Raamleping nr 3-9/1660-1 Tööelu infosüsteemi arendustööd Tervise ja Heaolu Infosüsteemide Keskus (edaspidi Tellija ), registrikood 70009700, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja OÜ TripleDev , registrikood 12055727 , aadress Järvevana tee 7b , Tallinn ja Trinidad Wiseman OÜ , registrikood 11244225 , aadress Akadeemia tee 21/4 , Tallinn, keda esindab ühispakkujate volikirja alusel Marek Põldeots (edaspidi Täitja ) edaspidi ka eraldi Pool või koos P ooled, sõlmisid raamlepingu alljärgnevas : Raamlepingu eesmärk Tellija poolt korraldatud riigi hanke „ Tööelu infosüsteemi arendustööd “ ( riigihanke viitenumber 200150 ) alusel sõlmitud raamlepingu eesmärk on sätestada raamlepingu kehtivuse ja raamlepingu alusel tellitud tööde teostamise ajal kehtivad Poolte õigused , kohustused ja vastutus ning määrata kindlaks tööde tellimis e tingimused . Raamlepingus fikseeritakse Tööde tellimise tingimused ning poolte õigused ja kohustused kogu raamlepingu alusel tööde teostamise perioodi ks. Raamlepingu alusel t ellitavate Tööde sisu , maht ja teostamise tähtajad lepitakse kokku han k elepingus või tellimuskirjas. R aamleping ei kohusta Tellijat T äitjalt t öid tellima . Raamlepingu ese Raamlepingu esemeks on Tööelu infosüsteemi ( edaspidi Te IS ) tarkvara arendamise ja kasutusele võtmisega seonduvad tööd ning tarkvara hooldustööd (edaspidi ka tarkvara arendustööd või Tööd ), mida Täitja kohustub teostama lähtudes raamlepingu alusel sõlmitud hankelepingu s või tellimuskirjas kokku lepitud tingimustest. Käesoleva raamlepingu alusel tellitakse vähemalt infosüsteem ja selle esitluskiht , järel e valve moodul ning TeIS tarkvara hooldus eks vajalikud Tööd . Täpsem ülevaade tellitavatest töödest on välja toodud tehnilises kirjelduses. Tellija võib raamlepingu alusel samuti tellida täiendavaid TeIS arendamiseks vajalikke Töid . T ööd e tellimused ja nende sisu lepitakse kokku raamlepingu alusel sõlmitavate hankelepingute või tellimuskirjade esitamise l . Tööde teostamisel lähtutakse lisaks käesolevale raamlepingule hankelepingu või tellimuskirja (edaspidi koos nimetatud ka Leping ) tingimustest ja kehtiva kodukorra regulatsioonist . Tellija võib teha kodukorda muudatusi , teavitades Täitjat kodukorra muutmisest. T ööde teostamise täpsed tingimused lepitakse kokku Tööde tellimisel Lepingus . Kui Lepingus sätestatud tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks Lepingu tingimus. Käesoleva raamlepingu juurde kuuluvateks lahutamatuteks osadeks loetakse riigi hanke alus dokumendid ja T äitja riigi hankes esitatud pakkumus. LEPINGU ÜLDTINGIMUSED Pooled teevad Lepingu täitmiseks ja Lepingu eesmärkide saavutamiseks koostööd. Lepingu täitmisel kohustuvad Pooled tegema kõik vajalikud pingutused, et täita Leping õigeaegselt ja vastavalt kokkulepetele, lähtudes lisaks Lepingule raamlepingus ja Lepingu lisades ning õigusaktides sätestatud kohustustest. Tellija eeldab, et Täitja on Lepingu esemeks olevate Tööde tarkvaraarenduse valdkonna professionaal, kes saab aru ning võtab teadlikult enda kanda Lepingu funktsionaalsete ja mittefunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Sellest tulenevalt laieneb Täitjale ka selliste Tööde tegemise kohustus, mida ei ole Lepingus otsesõnu kokku lepitud, kuid mis oma olemusest lähtuvalt kuuluvad Lepinguga seotud Tööde hulka ja pidid olema Täitjale kui professionaalile ettenähtavad pakkumuse esitamisel ning mis on Lepingu täitmiseks vajalikud. Nimetatud Tööde tegemine ei kuulu teistsuguse kirjaliku kokkuleppe puudumisel eraldi tasustamisele ning Täitja teostab kirjeldatud Tööd Lepingu täitmise raames. Töö käigus tuvastatud vastuolu korral teavitab Täitja vastuolu esinemisest viivitamatult Tellijat. Tööde teostamisel juhindub Täitja Tellija poolsetest suunistest Lepingu eesmärkide saavutamisel , pöördudes juhiste saamiseks või läbirääkimisteks vajadusel Tellija poole. K ui Tööde teostamisel tekivad Täitja ja Tellija vahel erimeelsused, lähtutakse Lepingu eesmärkidest Tellija seisukohalt. Tellijal on õigus jooksvalt Lepingu täitmist kontrollida. Tellijal on õigus anda Täitjale suuniseid Lepingu täitmiseks ning Täitja kohustub neid järgima. POOLTE ÕIGUSED JA KOHUSTUSED Täitja kohustub: teostama Tööd Lepingus kokkulepitud tingimustel ja ulatuses , sh tagama Tööde õigeaegse alustamise, teostamise, valmimise ja Tellijale üleandmise; järgima Tööde teostamisel Poolte jaoks kohustuslikke dokumente ; täitma kõiki Tellija juures kehtivaid ja õigusaktidest tulenevaid andmekaitsealaseid ja andmete turvalisust puudutavaid eeskirju, kui need on Täitjale teatavaks tehtud; pidama kinni kõikidest raamlepingu ja Lepingu tingimustest; tagama Tööde teostajate kõrge professionaalse taseme ning vajalike tehnoloogiate ja metoodika väga hea tundmise vastavuses meeskonnale esitatud nõuetele kogu Lepingu täitmise perioodi jooksul; kasutama Tööde teostamisel meeskonnaliikmeid, kes on riigihanke pakkumuses Tööde teostamiseks nimetatud , kui Pooled ei ole kokku lep pinud teisiti (p 4.2.3) ; saama Tellija poolse kirjaliku nõusoleku Töid teosta va meeskonnaliikme asendamiseks , esita des Tellijale u ue meeskonnaliikme kompetentsi tõendavad dokumendid; asendama Tellija nõudmisel meeskonnaliikme juhul, kui isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine kahjustab pidevalt Lepingu korrektset ja õigeaegset täitmist. Täitja kannab kõik asendusest tulenevad või sellega kaasnevad kulud; teostama Tööd kuni kokku lepitud Tööde üleandmise ja vastuvõtmiseni oma ressursside arvel ning pidama arve esitamisel kinni Poolte vahel kokku lepitud Tööde maksumuse suurusest ja maksetingimustest; kasutama Tööde teostamisel Tellija tööajahalduse ja projektijuhtimiskeskkondi , mis on Täitjale kättesaadavaks tehtud ; pöörduma juhiste saamiseks Tellija poole, kui need o n Tööde teostamiseks vajalikud, samuti teavitama Tellijat koheselt kõikidest asjaoludest, mis mõjutavad Tööde teostamist või Täitja poolsete muude L epinguliste kohustuste täitmist. Täitjal on õigus: saada Tööde teostamise eest Lepingus kokkulepitud ulatuses ja korras tasu; asendada objektiivsel põhjusel ja Tellija eelneval kirjalikul nõusolekul meeskonnaliikmeid tingimusel, et meeskonnaliikmed asendatakse vähemalt samaväärse kompetentsiga isikutega, kes vastavad meeskonnaliikmetele esitatud nõuetele ; Täitja võib Tellija nõusolekul meeskondi täiendada uute liikmetega, kes ei pea vastama meeskonnaliikmetele esitatud nõuetele, kui see võimaldab teostat avaid T öid kvaliteetsemalt ja/või efektiivsemalt ellu viia; kasutada Tööde teostamisel allhankijaid ( pidades silmas, et kasutatavad meeskonnaliikmed peavad vastama esitatud nõuetele ) , kooskõlastades allhankijate kasutamise eelnevalt Tellijaga . A llhankijate tegevuse ja tegevusetuse eest vastutab Tellija ees Täitja . Tellija kohustub: tasuma Täitjale vastu võetud Tööde teostamise eest Lepingus kokkulepitud ulatuses ja korras; tagama Täitjale ligipääsu Tööde teostamiseks vajaliku le informatsiooni le ja keskkondadele ning vastama Täitja küsimustele seoses Lepingu täitmise või Lepingu dokumentide tõlgendamisega 3 (kolme) tööpäeva jooksul ; võtma Tööde üleandmise ja vastuvõtmise aktiga vastu Täitja poolt üle antud puudusteta Tööd mõistliku aja jooksul või vastavalt Lepingus sätestatud tähtajale ; teavitama Täitjat üle antud Töödes esinevatest puudustest ning kohustusest puudused kõrvaldada, andes vajadusel selleks täiendava tähtaja, kui tähtaeg ei tulene muudest kokkulepetest . Tellijal on õigus: kontrollida jooksvalt Tööde teostamise käiku andes vajadusel juhiseid, mis ei välju Lepingus sätestatu raamest ega moonuta Lepingu sisu ning on mõistlikud ja vajalikud Lepingu eesmärgi saavutamiseks; nõuda Täitja meeskonnaliikme asendamist juhul, kui isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine kahjustab pidevalt Lepingu korrektset ja õigeaegset täitmist; keelduda osaliselt või täielikult tasu maksmisest, kui Täitja ei teostanud Töid kokku lepitud tähtajaks või vastavuses Lepingule ja selle juurde kuuluvatele dokumentidele ning Täitja poolne Lepingu rikkumine ei ole objektiivselt põhjendatud (nt on tegemist objektiivse põhjendusega, kui Tööde teostamine on viibinud Tellija või kolmanda osapoole tegevuse tõttu) ; nõuda Täitjalt tekkinud kulutuste ja kogu kahju hüvitamist, kui Täitja poolne Lepingu mittetäitmine või mittekohane täitmine on toonud Tellijale kaasa kulutusi , v.a kui rikkumine oli põhjustatud Tellija või kolmanda osapoole tegevusest ; öelda Täitja poolse olulise L epingu rikkumise korral raamleping ja/ või Leping igal ajal üles ja nõuda lepingu ülesütlemisega kaasnevate kulutuste ja kahju hüvitamist täies ulatuses . NÕUDED DOKUMENTATSIOONILE JA KASUTUSJUHENDITELE Tööde dokumentatsioon ja kasutusjuhend id peavad tagama Tellijale võimaluse tulevikus parandada ja arendada Tööde tulemit, samuti koolitada ja juhendada oma töötajaid Tööde kasutamisel. Tööde dokumentatsioon peab olema laetud üles Tellija määratud keskkonda. Täitja kohustub lähtekoodi dokumenteerimisel juhinduma raamlepingu lisast 1 .4 „Versiooni halduse kirjeldus“ . T ööde käigus loodud lähtekood peab olema kirjutatud ja dokumenteeritud selliselt, et vajadusel oleks Tellija või kolmas isik võimeline aru saama tarkvara loogilisest ülesehitusest ning jätkama lähtekoodi arendusega, juhindudes Riigi Infosüsteemi Arhitektuuri nõuetest. Tööde tulem peab olema dokumenteeritud konkreetsete Tööde iseloomust lähtudes , juhindudes kehtivas kodukorras ning raamlepingu lisades 1 .2 „Mittefunktsionaalsed nõuded“ ja 1 .2.1. „Nõuded infosüsteemi dokumenteerimisele“ sätesta tust , kui Lepingus ei ole kokku lepitud teisiti. Raamlepingu hind Riigih anke hinnapakkumuses pakutud Tööde ühe töötunni maksimaalne maksumus ilma käibemaksuta fikseeritakse kogu raamlepingu keht ivuse ajaks . Tööde teostamise maksimaalne ühe töötunni hind käibemaksuta on 48 ( nelikümmend kaheksa ) eurot. Käesoleva raamlepingu alusel tellitavate Tööde eeldatav mah t on kuni 1 000 000 ( ü k s miljon) eurot ( ilma käibemaksuta) . Täitjal ei ole lubatud raamlepingu keht ivuse ajal punktis 6 . 2 sätestatud ühe töötunni maksimaalset hinda tõsta, kuid Täitja võib pakkuda madalamat hinda. Vajadusel on Tellijal õigus raamlepingu mahtu kuni 20% ulatuses suurendada . Täitja meeskond Täitja tagab riigi hankes pakkumusega esitatud meeskonnaliikmete (Lisa 3 ) osalemise T ööde teostamisel, v . a juhul , kui Täitjast mittesõltuval asjaolul ei ole seda võimalik teha ja meeskonnaliige on asendatud Tellija nõusolekul teise meeskonnaliikmega. Täitja võib lisada täiendavaid meeskonnaliikmeid juhul, kui riigi hanke s pa kkumusega esitatud meeskonnaliikmed on tellitud T ööde täitmisega hõivatud. Täiendavaid meeskonnaliikme peavad vastama kokku lepitud tingimustele (Lisa 4). Tellija võib Lepingu sõlmimisel tellida lisaks kinnitatud meeskonnaliikmete rollidele (Lisa 4) uusi rolle, kui see on tingitud tellitavate Tööde iseloomust ja Tööde efektiivseks teostamiseks on otstarbekas kaasata teistsuguse kompetentsiga meeskonnaliikmeid. TÖÖDE tellimine Tööde teostamiseks sõlmib Tellija T äitjaga hankelepingu(d) , milles määratakse Tööde täpne sisu ja üle antavad tulemid (T ööde loetelu), Tööde maht, konkreetne realiseerimist ähtaeg jm olulised tingimused. Hankelepingu sõlmimiseks esitab Tellija T äitja te le pakkumuskutse ja annab mõistliku aja pakkumuse esitamiseks, arvestades tellitavate T ööde keerukust ja pakkumuse esitamiseks vajalikku aega . Pakkumuse esitamisel tuleb järgida kõiki pakkumuskutses esitatud nõudeid. Tellijal on õigus pidada Täitja ga kirjalikus vormis või protokollituna läbirääkimisi ning küsida täiendavaid kinnitusi ja andmeid T ööde osutamiseks vaj alike eelduste olemasolu kohta. Tellija sõlmib Täitjaga hankelepingu vastavalt pakkumuskutse tingimustele . Täitja kohustub hankelepingu allkirjastama hiljemalt 3 (kolme) tööpäeva jooksul hankelepingu allkirjastamiseks saamisest. Tööde tellimiseks eeldatava mahuga vähem kui 2 0 000 ( kakskümmend tuhat) eurot ilma käibemaksuta , võib Tellija esitada Täitjale tellimuskirja. Täitja esitab Tellijale omapoolse kinnituse tellimuskirja vastu võtmise ja valmisoleku kohta tellimuskirja alusel Tööde teostamisega alustamise osas . Tellimuskirja alusel T öö de teostamisega alustamiseks allkirjastavad Pooled tellimuskirja . TÖÖDE ÜLEANDMINE JA VASTUVÕTMINE Tööde üleandmise ja vastuvõtmise kord, Tööde teostamise etapid ja tähtajad ning Tööde testimiseks esitamise tähtajad ja kord jm Tööde teostamiseks vajalikud kokkulepped lepitakse Poolte vahel kokku Lepingu sõlmimisel , juhindudes muuhulgas kehtivas kodukorras sätestatust . Täitja kohustub Tööd üle andma Lepingus kokkulepitud tähtaegadel ja tingimustel . Tööde lahutamatuks osaks, mis tuleb üle anda koos Töödega , on Tööde juurde kuuluv nõuetekohane dokumentatsioon (sh kasutusjuhendid) ja intellektuaalomandi õigused . Täitja annab Töö üle omalt poolt allkirjastatud üleandmise ja vastuvõtmise aktiga (edaspidi nimetatud ka Akt ) . Tellija võtab Tööd vastu Akti allkirjastamisega pärast edukat v astuvõtutestimist kehtivas kodukorras või Lepingus sätestatud tingimustel . Tellija võib Tööd vastu võtta, kui Töödes esineb üksikuid ja Tellija jaoks väheolulisi pisivigasid , mis fikseeritakse Aktis. Tellija poolne pisivigadega Tööde vastuvõtmine ei vabasta Täitjat kohustusest vead Tellija poolt määratud mõistliku tähtaja jooksul kõrvaldada ning üle anda vigadeta Tööd. Tellija teavitab Täitjat testimise käigus avastatud vigadest , andes Täitjale mõistliku tähtaja vigade parandamiseks enne Tööde teistkordset ül e andmist. Töödes ilmnevates vigades eristatakse järgnevaid kriitilisuse astmeid: k riitiline viga – T arkvaral põhinev teenus või süsteem ei toimi ega ole kasutatav, näiteks on andmed rikutud; esineb kasutajasessioonide ebanormaalne katkemine; probleem mõjutab süsteemi käideldavust ja andmete terviklikkust ; mõjutatud on enamus Tarkvara kasutajatest; vastukaal probleemi vältimiseks praktiliselt puudub; tõsine finantsmõju; h äiriv viga – T arkvaraga seotud probleem ei sega teatavate reservatsioonide järgimisel igapäevast töötamist; mõjutatud ei ole kõik Tarkvara kasutajad; väiksema tähtsusega funktsionaalsused pole käideldavad, kasutatavad või süsteemi jõudlus on madalamal maksimaalsest nõudest; eksisteerib ajutine aktsepteeritav vastukaal probleemi vältimiseks. p isiviga - väikesed puudused minimaalse mõjuga Tööde kasutajatele või klientidele; kosmeetilised probleemid (ekraanikomponendid on nihkes, kuid see ei takista komponendi eesmärgipärast kasutamist); pikaajaline vastukaalu kasutamine kasutajatele vastuvõetav. Tööde testimise käigus avastatud ja Täitjale raporteeritud vead parandab Täitja omal kulul, teavitades vigade parandamisest Tellijat. Kui Täitja annab vigade parandamise järgselt üle Tööd, milles Tellija vastuvõtutestimise käigus esineb jätkuvalt vigu (teistkordne vigadega Tööde üleandmine) , võib Tellijal otsustada, kas anda Täitjale uus tähtaeg vigade parandamiseks , kõrvaldada vead ise või kolmanda isiku kaasabil, vähendades Täitjale makstavat tasu võrdeliselt vigade parandamiseks tehtud kulutustega. Kõigi Lepingu järgsete Tööde vastuvõtmise ajaks loetakse kõigi Lepingu alusel teostatud Tööde osas viimase Akti allkirjastamise aeg. INTELLEKTUAALNE OMAND Täitja kinnitab Lepingu allkirjastamisega, et talle kuuluvad Tööde teostamiseks vajalikud autoriõigused, litsentsid ja muud intellektuaalse om andi õigused, mis on vajalikud L epingu järgsete Tööde teostamiseks ja õiguste loovutamiseks Tellijale ning nende suhtes ei ole õigusi ega nõudeid kolmandatel isikutel. Tasu autoriõiguste loovutamise ning litsentsi andmise eest sisaldub Lepingu hinnas. Täitja loovutab Tellijale Tööde teostamise käigus loodud Tööde kõik autori varalised õigused ning annab lihtlitsentsi autori isiklikele õigustele koos all-litsentsi andmise õigusega kogu autoriõiguste kehtivuse ajaks ilma geograafiliste piiranguteta. Täitja tagab, et isiklikud õigused on ilma Täitja nõusolekuta teostatavad muuhulgas järgnevas ulatuses: Tellijal on õigus Tööd kasutada mis tahes eesmärgil ja viisil; Tellijal või Tellija tellimusel kolmandatel isikutel on õigus teha üle antud Töödes muudatusi ning neid täiendada; Tellijal või Tellija tellimusel kolmandatel isikutel on õigus teostatud Tö id muuta või Tö ödele lisada Tellija või kolmandate isikute poolt loodud Töid ; Tööde üleandmisega Tellijale kinnitab Täitja, et Tööd on üldsusele avaldamiseks valmis. Täitja tagab Tellijale kõik vajalikud õigused Lepingu täitmise käigus loodava Töö kontrollimiseks, testimiseks ning süsteemi paigutamiseks ka ajal, mil Tööd on vastuvõtutestimiseks üle antud, kuid ei ole veel Tellija poolt Aktiga vastu võetud. Käesolevas alapeatükis sätestatud õigused ja litsentsid loetakse Tellijale lõplikult üle läinuks pärast Töö vastuvõtmist. Täitja kohustub lahendama kõikvõimalikud lepingujärgsete Töödega seotud intellektuaalse omandi õigustest tekkivad vaidlused kolmandate isikute või oma töötajate või koostööpartneritega , v.a. juhul, kui tarkvara või tarkvara osa litsentside soetamise kohustus oli Tellijal või kolmandal osapoolel . Juhul, kui eeltoodust tekib Tellijale rahaline või muu kohustus või juhul, kui Tellija on kohustatud lõpetama Lepingu alusel teostatud ja vastuvõetud Tööde kasutamise, on Tellijal õigus nõuda Täitjalt sellega kaasneva rahalise või muu kohustuse täitmist ja/või samaväärse Töö loomist ilma täiendavat tasu nõudmata võimalikult lühikese aja jooksul, hoidudes mistahes viivitustest tarkvara arendamises, kasutuselevõtmises ja kasutamises Tellija poolt. Juhul, kui Täitja ei täida punktis 10.7 nimetatud kohustust mõistliku aja jooksul, on Tellijal õigus nõuda kogu kahju hüvitamist, mis on Tellijale kaasnenud või kaasneb Täitja poolt kohustuse mittenõuetekohase täitmisega. GARANTII Täitja annab Lepingu alusel teostatud Töödele garantii 12 ( kaksteist ) kuud , mis hakkab kulgema kõigi Lepingu alusel teostatud Tööde üleandmisest (viimase lepingujärgsete Tööde Akti allkirjastamisest alates). Juhul , kui Töö teostamine on kokku lepitud etapiviisiliselt , algab garantiiperiood Töö etapi osas selle toodangukeskkonnas kasutuselevõtust alates . Kui T ellija ei võta T öid toodangukeskkonnas kasutusele 3 (kolme) kuu möödumisel alates T ööde vastuvõtmisest, algab garantii nimetatud aja möödumis el. Garantiiga on hõlmatud kõik tarkvaras ilmnevad vead, mis ei ole tekkinud Tellija või kolmandate osapoolte tegevuse tagajärjel. Täitjale peab saama edastada teateid garantiiga hõlmatud vigade ilmnemise kohta vastavalt kehtiva kodukorra regulatsioonile garantiist tulenevate õiguste teostamiseks igal tööpäeval vähemalt ajavahemikul kell 8:00 kuni 17:00. Garantiikohustusega hõlmatud vea ilmnemisel teavitab Tellija Täitjat veast, edastades kogu teabe, mis Tellijal on vea ja selle tekkimise olukorra ning võimalike põhjuste kohta . Tellija määra b võimalusel, milline on vea kriitilisuse aste või kas tegemist on muu garantiikohustusega hõlmatud puudusega ning määrab vea kõrvaldamiseks tähtaja, lähtudes punktis REF _Ref494457058 \r \h \* MERGEFORMAT 9 .7 fikseeritud vigade kriitilisuse astmetest. Kui tegemist on k riitilise veaga ( critical ) , teatab Täitja hiljemalt 24 ( kahekümne nelja ) tunni jooksul alates k riitilise vea kohta teate saamisest oma esialgse hinnangu k riitilise vea võimalike põhjuste kohta ning juhtnöörid, kuidas Tööde tulemit edasi kasutada . Täitja peab kaasama k riitilise vea kõrvaldamisse nii palju spetsialiste, et eelduslikult võiks k riitiline viga saada kõrvaldatud 3 ( kolme ) t ööpäeva jooksul alates vea kohta teate saamisest. Kui tegemist on h äiriva vea ( major ) , pisivea ( minor ) või muu garantiikohustusega hõlmatud puudusega, teatab Täitja hiljemalt 48 ( neljakümne kaheksa ) tunni jooksul alates selle kohta teate s aamisest oma esialgse hinnangu h äiriva vea, pisivea või muu puuduse võimalike põhjuste kohta ning vajadusel juhtnöörid, kuidas Tööde tulemit edasi k asutada . Täitja peab kaasama h äiriva vea, pisivea või muu puuduse kõrvaldamisse nii palju spetsialiste, et eelduslikult võ iks nimetatu saada kõrvaldatud 10 ( kümne ) tööpäeva jooksul alates teate saamisest. Täitja garantiist tuleneva te kohustuste täitmine on arvestatud Lepingus kokkulepitud tasu hulka. Juhul, kui Täitja tõendab, et kõrvaldatud viga või muu puudus ei olnud Lepingu garantiiga hõlmatud, hüvitab Tellija Täitja kantud otsesed kulud seoses nimetatud vea või puuduse kõrvaldamisega. Kulude hüvitamisel võetakse aluseks Lepingus, mille raames teostatud Töödes on viga või puudus ilmnenud, fikseeritud Tööde teostamise ühe töötunni hind . Tellija tagab Täitjale kaasaabi garantiikohustuse alla käivate vigade ja puuduste kõrvaldamisel Tellija võimekuse ja võimaluste piires . Kui Täitja ei suuda vig asid või puuduseid kokkulepitud tähtajaks kõrvaldada, võib Tellija nimetatud ise kõrvaldada või korraldada nende kõrvaldamise kolmanda isiku kaasabil , teavitades sellest Täitja le . Tellijal on õigus Täitja lt nõuda mõistlike kulutuste hüvitamist , mis tekkisid seoses eelkirjeldatud viisil vea või puuduse kõrvaldamisega , kui tegemist oli vea või puudusega, mis oli garantiiga hõlmatud . Garantii kaotab kehtivuse, kui Tellija muudab Täitjaga kooskõlastamata lähtekoodi, välja arvatud Tööde osale , mida ei ole muudetud, kui Tellija suud ab eristada lähtekoodis tehtud muudatusi. Garantiiga ei ole hõlmatud: h ooldus- ja arendustööd, mis ei ole tingitud vajadusest kõrvaldada punkti s 9.7 nimetatud vigasid või kokku lepitud tingimustele mittevastavusest tulenevaid puudusi; ekspluatatsioonihäirete kõrvaldamine, mis on põhjustatud Tellija või kolmanda isiku poolt Tööde juhuslikus t või tahtlikust kahjustamisest. POOLTE VASTUTUS Pooled vastutavad oma lepinguliste kohustuste rikkumise eest, välja arvatud, kui rikkumine on vabandatav. Rikkumine on vabandatav, kui esineb vääramatu jõud. Pool vastutab teise Poole ees muuhulgas Lepingu rikkumise eest, mis tuleneb Poole poolt Lepingu täitmisele kaasatud isikute tegevusest või tegevusetusest (sh allhankijate tegevuse eest, keda Täitja tööde teostamise kasutab) . Pool ei vastuta l epingu liste kohustuste rikkumise eest, mis tulene s teise Poole kohustuste rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest . Nimetatud asjaolu esinemist peab tõendama Pool, kes sellele tugineda soovib. Poole lepingulise kohustuse rikkumise korral on teisel Poolel õigus kasutada kõiki seadusest tulenevaid õiguskaitsevahendeid. Poolte rahaline koguvastutus on piiratud Lepingu kogumaksumusega, kuid see piirang ei kehti tahtliku rikkumise korral , intellektuaalomandiõiguse või andmekaitsealaste kohustuste rikkumise korral . Juhul, kui Tellija satub Täitjale Tööde eest tasu maksmisega viivitusse, on Täitjal õigus esitada viivise nõue , mille suuruseks on 0, 2 % lepingujärgse konkreetse Töö eest maksmisele kuuluvalt tasult iga tasumiseg a viivitatud kalendripäeva eest, kuid mitte rohkem kui 2 5 % konkreetse Töö eest tasumisele kuuluvast kogusummast. Täitja esitab viivise nõude Tellijale allkirjastatult vähemalt kirjalikku taasesitamist võimaldavas vormis. Täitja poolse l epingu liste kohustuste rikkumisena käsitletakse eeskä tt olukorda, kus Tööd ei vasta L epingu tingimustele või esineb muid Täitja poolseid L epingu rikkumisi (nt üle antud Tööd ei ole kvaliteetsed või ei vasta muudele Poolte vahel kokku lepitud tingimustele jmt ). Juh ul, kui Täitja ei anna nõuetekohaselt teostatud Tööd üle Lepingus fikseeritud tähtajal või Poolte poolt kirjalikult kokkulepitud muul tähtajal, on Tellijal õigus nõuda leppetrahvi tasumist, mille suuruseks on 100 eurot iga Töö üleandmisega viivitatud kalendripäeva eest, kuid mitte rohkem kui 2 5 % Lepingu kogumaksumusest . Kui Tööde teostamine on kokku lepitud etappide kaupa, siis mitte rohkem kui 25% etapi kogumaksumusest . Lepingu olulise rikkumise korral on Tellijal õigus esitada Täitjal e leppetrahvi nõue 1 0 000 eurot iga rikkumise eest. Oluliseks lepingurikkumiseks loetakse punktis 14. 5 sätestatut. Leppetrahvi nõude kohustub Tellija esitama mõistliku aja jooksul, kuid mitte hiljem kui 3 kuu jooksul alates päevast, mil Tellija sai teadlikuks leppetrahvi nõude aluseks olevast asjaolust. Leppetrahvi nõude vaidlustamine ei vabasta Täitjat selle maksmise kohustusest enne vastava kohtuotsuse jõustumist. Täitja on kohustatud leppetrahvi tasuma 2 nädala jooksul alates Tellija poolt vastava nõude esitamisest. Tellijal on õigus tasaarvestada leppetrahvi summa Täitjale Töö teostamise eest tasumisele kuuluvate maksetega. Tööde vastuvõtmine Tellija poolt ei vabasta ega vähenda Täitja vastutust L epingu rikkumise eest. Konfidentsiaalsuskohustus Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele isikutele ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud teiselt P oolelt käesole va raamlepingu alusel tellitud T ööde teostamise käigus või muul viisil või juhuslikult. Juhul, kui Lepingu täitmise raames osutub vajalikuks isikuandmete töötlemine, lepivad Pooled isikuandmete töötlemise tingimused kokku Lepingus, juhindudes isikuandmete kaitse üldmääruse artiklis 28 sätes tatust . Konfidentsiaals e informatsiooni all mõistavad P ooled igasugust informatsiooni (s h ärisaladus i , isikuandmeid, Lepingute andmeid , infosüsteeme, turvasüsteemide kirjeldusi, riistvara ja tarkvara kirjeldusi, pakkumuse kirjeldusi, kasutatavaid tehnoloogiaid, spetsifikatsioone jms), mis on saadud seoses T ööde teostamisega ja mille sattumine kolmandate isikute kätte võib P ooltele põhjustada turvariske või majanduslikku kahju või kolmandate isikute (eelkõige Tellija klientide) eraelu puutumatuse rikkumist. Kahtluse korral eeldatakse informatsiooni konfidentsiaalsust. Konfidentsiaalne informatsioon ei hõlma endas informatsiooni, mille avalikustamise k ohustus tuleneb õigusaktidest või mille avalikustamiseks P ooled on andnud nõusoleku . Pooled võivad edastada konfidentsiaalset informatsiooni ainult nendele isikutele, kes on tellitud T ööde täitmisega otseselt seotud. Täitja kohustub tagama, et isikud, keda ta oma kohustuste täitmisel kasutab, oleksid konfidentsiaalsuse kohustusest teadlikud ning nõudma nimetatud isikutelt selle kohustuse tingimusteta ja tähtajatut täitmist. Vastutus konfidentsiaalsuskohustuste täitmise eest lasub Täitjal. Pooled ei kasuta raamlepingu täitmisel neile teatavaks saanud konfidentsiaalset informatsiooni oma huvides e ga muul eesmärgil, kui tellitud T ööde teostamiseks. Konfidentsiaalsuskohustus jääb kehtima tähtajatult, ka raamlepingu ja raamlepingu alusel sõlmitud Lepingute lõpetamise või lõppemise järgselt. Täitja on teadlik, et raamleping ning raamlepingu alusel sõlmitud Lepingud ja kokkulepped on avalikud, v.a osades, mis on avaliku teabe seadusest tulenevatel alustel määratud asutusesiseseks kasutamiseks või märgitud Täitja poolt ärisaladuseks . Konfidentsiaalsuskohustuse r ikkumise korral kohustub Täitja hüvitama kõik kahjud, mis sellise rikkumise tagajärjel Tellijale või kolmandale isikule tekkisid , sõltumata sellest, kas rikkumine pandi toime L epingu kehtivuse ajal või lepinguliste kohustuste lõppemise järgselt . Raamlepingu kehtivus ja ülesütlemine Raamleping jõustub sõlmimise hetkel ja kehtib 26 kuud. Poolte kokkuleppel on võimalik raamlepingu kehtivust pikendada, kuid mitte kauemaks kui 48 kuud. Lepingud tuleb sõlmida raamlepingu kehtivuse ajal, kuid võivad kehtida kauem. Tellija võib raamlepingu igal ajal ühepoolselt üles öelda, teatades T äitjale 60 päeva ette . Raamlepingu ülesütlemine ei muuda automaatselt kehtetuks selle alusel varem sõlmitud Lepingu i d . T äit ja võib raamlepingu igal ajal ühepoolselt üles öelda, teatades Tellijale vähemalt 9 0 päeva ette. Raamlepingu ülesütlemine ei muuda automaatselt kehtetuks selle alusel varem sõlmitud Lepingu i d . Tellijal on õigus raamleping ühepoolselt etteteatamistähtaega järgimata üles öelda, kui T äitja on oluliselt raamlepingut rikkunud või juhul, kui Täitja: suhtes on algatatud pankrotimenetlus; pankrot on välja kuulutatud; Täitja varad arestitakse; Täitja finantsseisund halveneb Tellija põhjendatud hinnangul oluliselt ja see muudab Lepingu nõuetekohase täitmise vähetõenäoliseks . Raamlepingu oluliseks rikkumiseks Täitja poolt loetakse muuhulgas: mõjuva põhjuseta Lepingu sõlmimata jätmine; vale andmete või valeinfo esitamine; Täitjal puuduvad Lepingu täitmiseks vajalikud õigused (sealhulgas load, litsentsid, intellektuaalse omandi õigused ); alapunktis 10 sätestatud intel lektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine ; korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei vasta kokku lepitud nõuetele või meeskonnaliikme asendami ne ilma T ellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta; konf identsiaalsuskohustuse rikkumine ; korduv (vähemalt kahel korral) L epingu jär gsetele tingimustele vast ava kohustuse täitmata jätmine , sh L epingu järgsete T ööde mittekoha ne teostamine ja kohustuste täitmata jätmine garantiiperioodil ; L epin gu järgsete kohustuste üleandmine kolmandale isikule , saamata selleks eelnevalt Tellija poolse t kirj alikku taasesitamist võimaldavat nõusoleku t . Pooltevahelised teated ja kontaktisikud Teadete edastamine toimub üldjuhul e-posti teel. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peab t eade olema edastatud kirjalikku taasesitamist võimaldavas vormis allkirjastatult Poole allkirjaõigusliku isiku poolt . Tellija kontaktisik on: Rainer Rohtla telefon 565 5447 e-post:
[email protected] . Täitja kontaktisik ( ud ) on: Enriko Käsper telefon 515 4190 , e-post:
[email protected] ja Marek Põldeots telefon 501 4930, e-post:
[email protected] . Kontaktisikute pädevuses on anda teisele Poolele vajaliku informatsiooni oma pädevuse piires, kontrollida teostatud Töö kvaliteeti , anda Töö üle ja võtta Töö vastu ning allkirjastada Akt . Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult. Muud tingimused Kogu suhtlus raamlepingu täitmise perioodil toimub Tellija ja Täitja vahel eesti keeles, sh töökoosolekud, arupärimised, tagasiside andmine , tellimuste esitamine, Lepingute sõlmimine jmt. Täitjalt oodatakse raamlepingu perioodi l operatiivset tagasisidet Tellija arupärimistele. Pakkuja peab tagama, et meeskonnaliikmetega oleks võimalik eesti keeles ilma põhjendamatute viivitusteta informatsiooni vahetada . Raamlepingu alusel sõlmitud Lepingutele kohalduvad raamlepingu tingimused, olenemata raamlepingu kehtivusest. Täitjal ei ole õigust ilma T ellija kirjaliku nõusolekuta raamlepingut või sellest tulenevaid kohustusi kolmandatele isikutele üle anda . Kolmas isik on mistahes füüsiline või juriidiline isik, kes ei ole käesoleva raam lepingu pooleks. Raamlepingut muudetakse pooltevahelise kirjaliku kokkuleppega raamlepinguga samas vormis . Täitjal puudub volitus tegeleda raamlepingu osas avalike suhetega ning anda teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arv atud Tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul. Raamlepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada, antakse lahendamiseks Harju Maakohtule. Raamlepingule kohaldub Eesti õigus. Kui raamlepingu mõni säte on vastuolus Eesti Vabariigis kehtivate õigusaktidega, ei mõjuta see ülejäänud sätete kehtivust. Lisad Lisa 1 . Tehniline kirjeldus ja selle lisad ; Lisa 1 .1. TeIS arhitektuur ; Lisa 1 .2. Mittefunktsionaalsed nõuded ; Lisa 1 .2.1. Nõuded infosüsteemi dokumenteerimisele ; Lisa 1 .3. Front-end arendusreeglid ; Lisa 1 .4. Versiooni halduse kirjeldus ; Lisa 1 .5. IT-profiil (tehnilised nõuded e-teenustele) ; L isa 1 .6. Hooldustööde osutamise reeglid ; Lisa 1.7 . Tööelu infosüsteemi eelanalüüs ; Lisa 1.8 . Kasutajate vajaduste analüüs; Lisa 2. Kodukord; Lisa 3. Täitja meeskond; Lisa 4. Nõuded meeskonnale; Lisa 5 . Hankelepingu projekt. Poolte allkirjad Tellija: Täitja: Katrin Reinhold Marek Põldeots ( allkirjastatud digitaalselt ) ( allkirjastatud digitaalselt )