H3K.md

Tere!

Saadan kokkuvõtte ja tagasiside Harjutusülesandele III "Äriprotsessi parendamine IT abil".

Lugesin teie tööd läbi.

Nüüd vajaks iga töö juures mõtlemist: 1) mis on kirjelduses, analüüsis ja ettepanekutes kõige olulisemad õpetlikud momendid? 2) kas ja kuidas teavet saaks üle kanda ja kasutada teistes situatsioonides (teistes protsessides)? 3) kas ja millised otsesed praktilised sammud võiksid analüüsi ja ettepanekute pinnalt teie ettevõtetes järgmisena toimuda?

Lisaks sellele oleks kasulik liigitada tööd analüüsitud protsessid ulatuse (kitsas või lai, keeruline või lihtne) ja ettepanekute konkreetsuse järgi.

Siinkohal tahan teha aga ühe metoodilise märkuse. Protsesside kirjapanek, modelleerimine ja visuaalne esitamine on küll tähtis, kuid kirjelduste ja mudelite hindamine on tunnetuslik protsess. Ei ole võimalik lugeda protsessi kirjeldust ja pelgalt selle alusel midagi sügavamat arvata. Kirjeldusi lugedes ma kõigepealt ütleks ehk "mhmh". Seejärel ääri-veeri küsiks midagi - ja vestlusest võiks midagi areneda. Praktika näitab, et koostatud kirjeldused tuleb rahulikult koos läbi arutada. Dialoogis tuleb välja uusi asju. Mitme ringiga on võimalik jõuda ühisele arusaamisele - mis tihti erineb kõvasti esimesena kirjapandust. Lisaks peab olema kasvõi mingigi kokkupuude protsessiga. Protsesse ei saa analüüsida ja juhtida ilma ise neis osalemata. Seetõttu pean protsessianalüüsis oluliseks järgida agiilarenduse põhimõtteid "Individuals and interactions over processes and tools" ja "Working software over comprehensive documentation".

Meie kursuse formaat kahjuks ei võimalda puhtajaliselt kõiki töid läbi arutada. (See on tänapäeva kõrghariduse üldine, negatiivne tendents - õppevormide liikumine dokumentide vahetamise suunas). Pakun, et laupäeval eraldame kuni 90 minutit teie tööde arutamisele, võttes kõneks igast tööst 1-2 kõige õpetlikumat momenti (ja kõiki töid isegi mitte läbi käies). Allpool markeerin mulle tähtsatena tunduvad küsimused. Laupäeval saame kiiresti need läbi käia ja otsustada, millised väärivad ühisarutelu ja millised mitte.

**Helena, Renna, Triinu - Rõiva konstrueerimisteenus FOOKUSKÜSIMUS: Kas tellimuse esitamist saab teha täisdigitaalseks?

1. Kahtlane, kas telefonisuhtlust kliendiga õnnestub vältida. Oma soovi seletamine ainult e-kirja ja joonise abil võib olla ebapiisav.
2. Kui kliendi asukohaks võib olla kogu maailm, siis väljatrükkide postiga saatmise asemel võiks kiirem, odavam ja lihtsam olla kasutada kliendile lähemal olevat väljatrükiteenust?

• Formaadinimetus on TIFF.

3. Mõned sõnastused on väga üldised:

• "keskkond peaks olema kasutajasõbralik"
• "aitab organiseerida ja hallata protsesse"
• "süsteemne infohaldus" Tuleks minna konkreetseks, analüüsida ja kavandada, milles need omadused konkreetselt väljenduvad.
• WordPress teostuskeskkonnana kahtlemata on võimalik, aga kas parim? WordPress ei ole ostukeskkonna ja klienditeenindusprotsesside tarkvara.
• Läbitöötamist vajavaks kohaks protsessis tundub olevat tellimuse esitamine. Mõõdutabel, tootenäidis, soovid ja juhised - kas neid saab nõutava kvaliteediga digitaalselt esitada?

**Kristo, Janno - Looduskaitseliste väärtuste protsessi parendamine IT abil FOOKUSKÜSIMUS: Kas peamised takistused ettepaneku teostamisel on ärilist või tehnilist laadi?

1. Analüüs on veenev, niipalju, kui oskan hinnata.
2. Meeldiv on see, et uuritud on ka ärilist teostatavust (mis riist- ja tarkvara oleks vaja ja kas see ka ära tasuks)
3. Protsessijooniseid saaks ehk teha veel selgemaks, kuid ka praegused on OK.

**Tauri - Võimalused IT abil tööd lihtsustada apteegiketis FOOKUSKÜSIMUS: Kas ettepanek on andmekaitseliselt teostatav?

1. Olemasoleva protsessi kirjeldus on hästi kirjutatud, huvitav ja veenev.
2. Parendamisidee on loogiline, kuid vajaks kindlasti sügavat andmekaitselist analüüsi. Kuidas kaitsta ravimiostjat tema andmete võimaliku väärkasutamise eest? Andmekaitse põhimõtteks (ja isikuandmete kaitse seadusega kehtestatud nõudeks) on isikuandmete töötlemise minimaalsus. Sellest lähtudes on ebaselge, mida annaks ravimi välja kirjutanud arsti nime näitamine. Teave selle kohta, kust varasemad retseptid on välja ostetud, oleks kahtlemata kasutatav konkurentsianalüüsiks. Ebaselge on, kuidas apteekidel tekkiv võimekus kliendi täielikku retseptiravimite ostuajalugu näha, mõjutaks teenuse kvaliteeti. Klientide ülemeelitamine jms. Ohte saaks leevendada kliendi selgesõnalise nõusolekuga (mida peab saama tagasi võtta) isikuandmete töötlemiseks. Probleem on aga selles, et inimene, eriti vana ja haige, ei tarvitse olla võimeline aru saama, millele ta nõusoleku annab.
3. Lühikese infolehe väljatrükkimise võimalus on suurepärane idee. Tihti on infolehed lugematult väikeses kirjas. Infolehed on aga vist reguleeritud (vaja Ravimiameti kooskõlastust). Päris lihtne see seetõttu ei ole.
4. Programmi NOOM kuvad ei ole väga kasutajasõbralikud? Müügiprotsessis oleks suur tekst müüja tööd rohkem toetav?

**Margus, Pamela, Ivo - Hanke/tellimuse täitmise protsess FOOKUSKÜSIMUS: Kas ettepanek on piisavalt konkreetne, et selle teostus saaks õnnestuda?

1. Universaalset hankesüsteemi on vist võimatu teha. Avalike hangete infosüsteemis (e-riigihankesüsteemis) on hankeprotsesse toetatud ja mõnedes üksikutes lõikudes ka automatiseeritud (nt võrdlustabelis punktide kokkuarvutamine). Sellise süsteemi tegemine on aega ja oskusi nõudev ning kallis. (Uue e-riigihangete süsteemi tegemise eeldatav maksumus on 2 milj €). Seetõttu teie analüüsis ja ideedes ei ole midagi, millele saaks vastu vaielda. Kuid ei ole piisavad konkreetsust, et tekiks usk, uue süsteemi tegemist ette võtta.
2. Märgite, et hankekeskkondi on loodud mitmeid, kuid need ei ole võitnud suurt kasutajaskonda. Võib-olla tuleks põhjalikult mõelda ja uurida, mis on selle põhjus.
3. Laiemalt mõeldes - nõudluse ja pakkumise kokkuviimine on majandussüsteemi üks alusprotsesse. Ost-müük on fundamentaalne muster (ingl pattern). Kõik majandussüsteemi subjektid osalevad selles. Miks siis ei ole ühtainust, standardset ostu-müügi tarkvara või IT-taristut?

*Priit, Kätlin - IT abiga protsessiparenduse võimalused ehituskonstruktsioonide tootmise ettevõttes FOOKUSKÜSIMUSED: Ehitusalal on ISO 9000 protsessikirjelduste terviklik süsteem tegutsemise eeldus. Kas terviklik protsessikirjelduste süsteem on võimalik ka ettevõttes, kus sellist sundi pole? Millised tehnilised barjäärid takistavad tahvelarvutite kasutuselevõttu objektil?

1. "Hetkel on protsessid kirjeldatud ettevõtte tegevuskäsiraamatus sadadel lehekülgedel .doc formaadis teksti vormis, mida on tülikas ja raske jälgida ning uuendada". - Protsessikirjelduste koostamine ja kättesaadavaks tegemine on paljudele ettevõtetele lausa ületamatu väljakutse.
2. Tahvelarvuti objektijuhtidele on huvitav probleem. Suhtluse iseloom on objektil teine kui kontoris. Üks Soome magistrand (samuti ehitusettevõte) rääkis oma töös positiivsest kogemusest tahvelarvuti rakendamisest objektil. Neil oli tehtud tarkvara lihtsustatud versioon. See oli kohandatud objektil töötaja konkreetsete toimingute tegemiseks, ega üritanud pakkuda kontoris kasutava tarkvaraga samaväärseid, laiu võimalusi.
3. Digitaalne allkirjastamine - digitaalallkirja seaduse (https://www.riigiteataja.ee/akt/694375) kohaselt on digitaalallkiri Eestis samaväärne omakäelise, paberil antud allkirjaga. Siiski on teatud tehnilised barjäärid - allkirja andmine nõuab ID-kaardi lugejat arvutis, sertifikaadi kehtivuskinnituse päringut Sertifitseerimiskeskuse (SK) andmebaasi, viimaseks on vaja internetiühendust, lepingut SK-ga.

**Marianne - Komplekteerimisvigade vähendamise võimalused FOOKUSKÜSIMUS: Kas probleem on olemuselt korralduslik, juhtimuslik, oskustega seotud või infotehnoloogiline?

1. "Kliendid esitavad pärast tellimuste kättesaamist palju kaebusi seoses puuduoleva kaubaga. Tellimustelt on tooteid puudu eelkõige seetõttu, et laos tekivad kauba komplekteerimisel vead. Kauba komplekteerimisel tekivad vead, sest kauba komplekteerija võtab riiulist vale toote, vale koguse või ei võta üldse toodet." - See on väga õpetlik.
2. "Ettevõttes töötab väga palju kahe- kuni kolmekümnendates eluaastates inimesi" - Kas demograafiline profiil võib olla komplekteerimisvigadega seotud?
3. Kuidas on tooted identifitseeritud?

• Kas toodetel on nimetused, numbrid, koodid? Kas nimemustrid on otstarbekalt valitud? Nimetused ja koodid peavad olema nii inimloetavad kui ka masintöödeldavad.
• Kuidas on tooted paigutatud? Kas paigutus on loogiline ja soodustab vigadeta komplekteerimist?

3. "Ribakoodi skänneri abil komplekteerib laotöötaja tellimuse" - see protsess vääriks detailset lahtikirjutamist. Mida on vaja?

• ribakoodide süsteemi ettevõtte kogu toodangule.
• ribakoodikleepsude väljatrükkimist
• kleepsude kinnitamist toodetele (Seda teeb inimene? Kuidas tagada, et ta ei tee vigu?)
• tellimuses koodide täpset andmist (Kas kliendid saavad sellega hakkama? Tarkvara, mis tellimuse andmisel seda toetab ja kontrollib?)
• skännerit ja skännitud koodide edastamist süsteemi (see ei ole eriti keeruline)
• skännitud koodide kokkuviimist tellimusega
• varuskeemi (ingl fallback) juhuks, kui elektrooniline lahendus tõrgub
• tasuvusarvestust

**Raul - Ostu-müügi arveprotsess FOOKUSKÜSIMUS: (sama, mis Margus-Pamela-Ivo) Kas ja kui universaalne või spetsiifiline peaks IT-lahendus olema?

1. "Olemasolev olukord oli selline, kus tehnik valis erinevate ladude veebipõhisest keskkonnast välja tooted, tellis need, printis ostuarve ning edastas ostuarve järgmisele inimesele, kes selle järgi tegi müügiarve ning seejärel liikusid ostu- ja müügiarve raamatupidajani, kes sisestas arved uuesti nn “oma programmi” ning märkis peale pangast käsitsi tasumised ja laekumised". - Siit ei saa kahjuks aru, kas tegu on toodete liigutamisega ettevõttesiseselt ühest laost teise või ostu-müügitehinguga kahe erineva ettevõtte vahel. Esimesel puhul pole ostu-müüki. Teisel juhul on ostjal ja müüjal eraldi raamatupidajad.
2. "Ostuarve" ja "müügiarve" on ikka üks ja sama arve, ainult ühe või teise tehinguosapoole vaatepunktist?

**Indrek - Mõõtmistulemiste raportite käsitlemise protsess FOOKUSKÜSIMUS: Probleem on selgelt infotehnoloogiline. Mida oleks vaja, et arvutid-seadmed üksteisega andmeid vahetama panna? Miks tänane tehnoloogia ei võimalda lihtsalt ja odavalt integratsioone teha? Kas peame ootama asjade internetti (Internet of Things)?

**Annika, Julia - Hambakliiniku äriprotsess FOOKUSKÜSIMUS: Töös jõutakse järeldusele, et tehniliselt isegi võiks, kuid vastuvõtule registreerimine vajab siiski inimesepoolset nõustamist. Verifitseerime koos selle järelduse üle.

1. See on hea analüüs. Ettepanekud on sisukad ja neid on veenvalt hinnatud.

**Hanna - Kliendi tellimuse täitmise protsess raamatukirjastuses OK FOOKUSKÜSIMUS: Vaja on päris väikest tehnilist muudatust. Käime selle üle.

**Tanel - Tugijaama valimise ja käivitamise protsess FOOKUSKÜSIMUS: Kirjutate, et planeerimise ja teostamise kvaliteediga ei olda päris rahul. See on väga üldine määratlus. Kust otsast probleemil sabast kinni saada? Kuidas ja millal IT-ga sisse tuua?

1. See, mida olete kirjeldanud, on suur tegevuste kompleks, millel on nii protsessi kui ka projekti omadusi. Püstitate väga olulise, kuid raske küsimuse: kuidas teha nii suur protsess optimaalseks?

**Marion - Koolitusprogramm startup-ettevõttes FOOKUSKÜSIMUS: Väga hea e-õppe süsteemi tegemine võib olla väga kulukas ja aeganõudev. Kui head süsteemi on tegelikult vaja?

1. OK Kirjapandu on mahult piisav, isegi ületab seda - ja käsitleb - niipalju, kui oskan hinnata - kõiki olulisi aspekte. Kiirustamise märgid (õigekirjavead), aga kui teete reaalset startup-i, siis ongi loomulik, et on kiire.
2. Iseõppimise koolitusprogrammidega on mitmeid riske. Head veebipõhist iseõppimisprogrammi ei olegi nii kerge teha. Võib-olla õpimaterjalide kvaliteet polegi nii oluline, kui tegutsemise litsentsinõue ei ole adekvaatne? S.t kas alal tegutsemiseks ikka on vaja kaheaastast kutseharidust?

**Jaanus - Laevaoperaatori suhtlusprotsess teiste osapooltega FOOKUSKÜSIMUS: Kuidas arendada süsteemi, kui praktiliselt kogu töö käib e-kirjadega?

1. Teil on huviga loetav, põhjalik kirjeldus. Küsite mitmeid küsimusi, mida tavaliselt peetakse teisejärgulisteks, kuid mille mõju igapäevase tööprotsessi osana organisatsiooni koguefektiivsusele on suur.
2. e-kirjade suur osakaal ilmselt näitab, et alternatiivset teabevahetus- ja -töötlussüsteemi ei ole lihtne kujundada. Võib ette kujutada kanban-süsteemi, mis koondaks teabe tellimuste kaupa. Sissetuleva e-kirjavoo jaotamiseks on kindlasti võimalusi. Kahjuks nõuab see nii tehnilist arendustööd kui ka organisatsioonilisi ümberkorraldusi.

**Taavi - Kaubaveo tellimuse täitmine FOOKUSKÜSIMUS: Kuidas jõuda IT-arenduse konkreetse lähteülesandeni? Rohkem konkreetsust.

**Kristo, Katrin - Praamipileti muutmise protsessi automatiseerimine virtuaalagendi abil FOOKUSKÜSIMUS: Kuidas loodud klassifikatsiooni kasutada

1. See on hea kirjeldus, mis demonstreerib klassifitseerimise kui meetodi võimsust. Masinõppe algoritmid põhinevad suuresti klassifitseerimisel.
2. Vastuste andmebaas võiks olla vajalik ka inimteenindaja puhul.

**Siiri - FOOKUSKÜSIMUSED: Kuidas korraldada kiire andmehõive kaevanduse tööprotsessis? Kuidas vähendada saatelehe koostamisele kuluvat aega?

1. Töökäsu väljastamine suuliselt - see on võib-olla liiga kauge analoogia, kuid agiilses tarkvaraarenduses on jõutud tõdemuseni, et töökorralduse, kokkulepped või ka plaanid ei pea tingimata olema kirja pandud (dokumenteeritud). See võib tunduda paradoksaalne ja kehtida ainult väikestes, tihedalt koos töötavates tiimides. Kui see väärib tähelepanu. Ma olen oma organisatsiooni (tegeleme tarkvaraarendusega, infosüsteemide halduse ja IT-teenuste osutamisega) mitmesuguste juhtidega sellel teemal rääkinud. Miks ülesannete dokumenteerimist peetakse oluliseks? Näen kolme põhjust: 1) juhi (alateadlik) hirm, et kui ülesanded ei ole kirjalikult fikseeritud, siis ta on liiga vähe "juhtinud"; kogemuse põhjal või väita, et see ei pea alati paika; töö kulgeb kõige paremini, kui ülesanded on inimestel pidevalt "peas" s.t neid ei olegi vaja üles kirjutada; dünaamilises keskkonnas võib ülesannete üleskirjutamine võib olla counterproductive - ülesandeid fikseeritakse nädala, kvartali või tsükli perioodiga; asjaolud aga muutuvad oluliselt kiiremini; tulemuseks on takerdumine ülesannetesse, mis on asjaolude muutumise tõttu adekvaatsuse kaotanud; 2) organisatsiooni tahtmine end kaitsta, tarkvaraarenduses tähendab see seda, et kõik koosolekud ja üldse kogu suhtlus arenduspartneriga tuleb dokumenteerida; selleks kulub meeletu ressurss; milleks on protokollimine vajalik? töö edenemiseks? ei. Tõendusmaterjali olemasoluks, kui feilinud või altvedanud arendaja vastu minnakse kohtusse? Riik ei lähe tarkvaraarendaja vastu kohtusse. Protokolle aga sellest hoolimata vorbitakse; 3) organisatsiooni juhtkonna soov kaitsta end töötajate lahkumise või rivist väljalangemise vastu. "Priit, küsid, miks peab dokumenteerima? Mõtle, kuid ühel päeval sind enam siin pole, kas teine inimene saab sinu töö üle võtta?" Teadmustöö (ingl knowledge work) vallas on selline poliitika kahe teraga mõõk. Töötajatest tahetakse teha vahetatavaid mutrikesi. Kui juhtub olevat tõesti andekas IT-spetsialist (nn "10X more productive than you"-tüüp), siis selles nähakse ohtu. Martin on unikaalne programmeerija - talle ei olegi võimalik varumeest kõrvale tekitada - järelikult tuleb Martinist vabaneda! Võib-olla see ongi üks põhjus, miks Eestis on tohutu puudus kõrge kvalifikatsiooniga IT-spetsialistidest, samas aga parimad IT-spetsialistid otsivad tööd. See, et laadurijuht märgib töökäsu oma märkmikku võib olla täiesti OK. Saateleht seevastu - kuna see jõuab kliendini, kindlasti peaks olema väga korrektselt vormistatud. Probleemide loetelus märgite, et teave jõuab ettevõtte infosüsteemi olulise viivitusega ja tööde planeerimine on ebaefektiivne. Neid aspekte tasuks lähemalt uurida. Laadurijuhil ei ole praegu häid ja mugavaid vahendeid teabe koheseks infosüsteemi hõivamiseks. Tal peaks olema mingi hästi lihtne teabe registreerimise vahend. Teda ei saa ka töö juurest liigselt kõrvale tõmmata. Infotöötluse vana tõde on, et andmehõive (andmete sisestamine infosüsteemi) ei tohi olla omaette tegevus, vaid peab olema lõimitud tööprotsessi. Laoseisu hinnangute andmekvaliteedi tõstmiseks ei saa laadurijuht ilma täiendavate mõõtmisvahenditeta midagi teha. Kui teabe varem infosüsteemi hõivatakse, kas siis keegi kasutaks seda ja milleks? Kas praegu teenuse osutamisega on probleeme (hilinemine)? Kui hilinemisi pole, siis ei saa väita, et planeerimissüsteem on ebaefektiivne? Selge on aga ka see, et 1,5-nädalane "lõtk" müügitehingute ja teabe raamatupidamisse jõudmise vahel ei ole mingil juhul aktsepteeritav. Mida siis tuleks teha? Tahvelarvutite kasutamise idee on mitmes töös. Vastava süsteemi tegemine ei tohiks olla liiga keeruline.