Autor: KreetSolnask (Page 2 of 4)

Andmete ja andmekvaliteedi roll tööprotsessides

Mõnda aega tagasi kirjutasin Ravimiameti apteegistatistika väljaandesse “20 aastat apteegistatistikat Eestis” ühe artikli andmekvaliteedist ning andmete kogumise ja töötlemise tööprotsessidest. Sellest on ajendatud ka minu järgmine blogipostitus, milles toon välja enda tähelepanekud andmekvaliteediga seoses.

Kõikide tööprotsesside käigus tekib teatud hulk andmeid. Näiteks võivad meie igapäevase poeskäigu kohta tekkida poe andmebaasi kliendikaardi kasutamisega seotud andmed (arve summa ja arveridade arv, ostetud tootegrupid, rakendunud soodustused jne). Nimetatud andmed on eelkõige vajalikud poe turundusega seotud tööprotsessides (nt. kliendilojaalsusprogrammi loomise ja uuendamise protsessis) aga võivad olla heaks sisendiks ka eraisiku eelarve ja rahaasajade planeerimise tööprotsessis.

Mis on andmekvaliteet?

Kvaliteet on vastavus kokkulepitule ning kui me räägime andmekvaliteedist, siis kajastab see seda, kas andmed on kogutud, loodud, talletatud, töödeldud vastavalt kokkuleppele. Kui kokkuleppe kohaselt peab andmeid kirjeldama klassifikaatorite kaudu ning seda ei ole andmete kogumisel niimoodi rakendatud, siis ei teki ka kvaliteetseid andmed.

Näiteks poeskäigu raames tekkivate andmete puhul on väga oluline läbi mõelda, millisel kujul salvestatakse kliendi ostu info. Ütleme, et näiteks kliendi poolt ostetud tootegruppide info on vaja salvestada klassifikaatorite kaudu. Selline andmetalletus võimaldaks hiljem neid andmeid hõlpsalt analüüsida ja selle pinnalt otsuseid teha. Oletame, et poe iseteeninduse kassasüsteem salvestab millegipärast kokkulepitud andmetalletuse asemel kogu info ühte suurde vabateksti välja. Sellisel juhul on tegemist halva andmekvaliteediga, kuna need andmeid ei ole hiljem lihtsasti ja eesmärgipäraselt kasutatavad.

Kuidas tagada kvaliteetsed andmed?

Kvaliteetsed andmed tekivad läbimõeldud andmete kogumise ja töötlemise tööprotsessidest, mille toetamiseks on loodud kas infosüsteemid või struktureeritud andmete kogumise mallid. Selleks et andmeid koguda, peab kõigepealt tuvastama, kust ja kelle käest neid kõige mõistlikum oleks koguda.

Alati ei ole vaja täiesti uusi andmeid koguda, vaid tuleks analüüsida, kas kusagil on juba sarnaseid andmeid kogutud. Ressursi säästliku kasutuse vaatest on juba ükskord kogutud andmete taaskasutus väga oluline! Seega peaks kindlasti proovima taaskasutada võimalikult palju juba kogutud andmeid. Selle mõttega haakub väga hästi ka reaalajamajanduse kontseptsioon.

Järgmine võtmeküsimus on, millisel kujul andmeid oleks mõistlik koguda. Andmete kogumist toetavate infosüsteemide või mallide puhul on väga oluline, et andmeid kogutakse justnimelt sellisel kujul ja sellistele reeglitele vastavalt, nagu lõppeesmärgi jaoks vaja on. See tähendab tihipeale seda, et infosüsteemides ja andmete kogumise mallides on andmete sisestajale ette määratud, mis kujul ta saab andmeid sisestada, ning sisestades kontrollitakse ka seda, et andmed vastaksid etteantud ärireeglitele.

Kvaliteetsed andmed saavad tekkida ainult siis, kui on lahti mõtestatud andmete kogumise ja töötlemise tööprotsessid ning pandud paika, millises etapis andmetega midagi tehakse. Kui andmete kogumise etapis suudetakse koguda väga kvaliteetsed andmed, siis see tähendab vähem tööd andmetöötluse etapis. Ja vastupidi, kui andmete kogumisel ei ole andmekvaliteet fookuses, siis see tähendab väga palju tööd andmetöötluse etapis. Siinkohal peaks eraldi rõhutama, et tihti ei olegi kogutud „prügi” võimalik andmetöötlusega korda teha ja seega ei pruugi kõikidest kogutud andmetest üldse kasu olla.

Mida jälgida andmete kogumisel ja haldamisel?

Kõige hullem variant on see, kui kogu andmestik on talletatud ühte vabateksti välja. Selliselt kogutud andmed sisaldavad tavapäraselt palju sisestusvigu ning neid on ühtsetel alustel väga keeruline (tihti isegi võimatu) analüüsida. Samuti on selliselt talletatud andmetest keeruline midagi üles leida. Seega oleks esimene soovitus koguda andmeid standardiseeritult ehk klassifikaatorite kaudu.

Andmete kogumisel peab määrama, mis eesmärgil neid kogutakse ja mida soovitakse hiljem andmetega peale hakata. Kui on soov andmeid teatud lõigetes otsida, analüüsida, filtreerida, grupeerida vms, siis on oluline, et selliste toimingute jaoks vajalikud tunnused oleksid andmetes esindatud.

Kui kogutavaid andmeid on vaja analüüsida koos mingite teiste andmekogude andmetega, siis on oluline, et andmetes talletatakse ka kogumise või töötlemise käigus kõik vajalikud seosed teiste andmete/andmekogudega.

Tänapäeval peaks uute süsteemide arendamisel olema kõige olulisem nõue see, et kogutud andmeid peab olema võimalik hõlpsalt süsteemist kätte saada. Mina olen erinevate projektide raames väga palju põrkunud probeemi otsa, et teatud süsteemist ei olegi võimalik andmeid kätte saada ning see pärsib andmete taaskasutamist.

Andmete haldamisel tuleks paika panna andmete halduse tööprotsessid ja läbi mõelda järgmised küsimused:

  • Kas ja kui tihti andmeid uuendatakse? Kuidas toimub andmete uuendamise töövoog?
  • Kas ja kui tihti klassifikaatoreid uuendatakse? Kuidas toimub klassifikaatorite haldamine? Kas eri hetkedel laekunud andmetes on vaja arvestada klassifikaatorite erinevaid versioone?
  • Milline on andmekvaliteet ja kuidas seda tagatakse?
  • Kas andmeid kustutatakse? Kellel on õigus andmeid vaadata, lisada, muuta, kustutada?
  • Kuidas on võimalik andmeid jagada? Mõtestada lahti erinevad andmeid tarbivad sihtrühmad ja neile vajalikud andmete tarbimise kanalid!

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele käigus puudutame samuti tööprotsesside ja andmete/andmevoogude vahelist seost – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Äriprotsessi tõhustamise tööprotsess

Antud postitus on jätk minu eelmisele blogipostitusele, milles selgitasin protsessimudeli abil, kuidas äriprotsesse kaardistatakse. Käesolevas postituses näitlikustan protsessimudeli abil erinevaid samme, mida on vaja läbida ühe tööprotsessi optimeerimiseks. NB! Protsesside optimeerimise eeltingimuseks on AS-IS protsessimudel või muul viisil väljendatud väga hea arusaam olemasolevast protsessist!

Millest alustada protsesside optimeerimist?

Ekslikult arvatakse, et äriprotsesside optimeerimine on lihtsalt olemasoleva tööprotsessi automatiseerimine (nt. mõne IT lahenduse arendamine). Oma äriprotsesside kirjaoskuse koolitusel alustan protsesside optimeerimisest rääkimist alati oma lemmik Bill Gatesi tsitaadiga – “The first principle for any technology you contemplate introducing into a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will just magnify inefficiency” . Seega tuleks alati enne automatiseerimist olemasolev tööprotsess disainida võimalikult mõistlikuks. Järgnevalt kirjeldatud sammud annavadki juhise, kuidas seda teha.

1.samm – probleemide tuvastamine ja juurpõhjuse analüüs

Tihti nimetavad seotud osapooled juba AS-IS protsessi kaardistamise käigus erinevaid probleemkohti, mis olemasolevas protsessis esinevad. Nende nimetatud probleemide puhul peab kindlasti läbi viima ka juurpõhjuse analüüsi ehk aru saama, millest probleem on tekkinud. Juurpõhjuse analüüsist olen täpsemalt kirjutanud ühes eelnevas blogipostituses. Kui te juurpõhjuse analüüsi läbi ei vii, siis võib juhtuda, et hakkate valele asjale lahendust otsima!

Miks mulle meeldib, et AS-IS protsessid ka üles joonistataks on sellepärast, et visuaalne protsessiskeem annab väga hea kiire ülevaate, kust võiks hakata optimeerimiskohti otsima. Potentsiaalsed kohad on protsessimudelis sellised, kus esineb väga palju tööde üleandmisi või “põrgatamisi” erinevate osapoolte vahel. Samuti tulevad visuaalselt protsessimudelil väga hästi välja nt dubleerivad tegevused.

2.samm – bürokraatia eemaldamine

Bürokraatia võib meist igaühe jaoks olla natuke erineva tähendusega. Tavaliselt on bürokraatia seotud vajadusega omada teatud tegevuste üle kontrolli, vigade tegemise hirmuga või igaks juhuks teatud tegevuste tegemisega. Erinevaid bürokraatlike samme võib leida protsessijoonistelt seal, kus esineb näiteks läbi mitme hierarhiataseme erinevaid kinnituste andmisi või kus on näha, et kontrollitakse pidevalt mõne teise rolli igat liigutust.

Bürokraatia võib esineda ka sellisel juhul, kui ettevõtte äriprotsesse ei ole pikka aega uuendatud. Sellisel juhul võib protsess sisaldada nö ajast maha jäänud tegevusi, mida pole enam antud protsessi läbimiseks vaja või mille tulemit ükski teine protsessi osapool enam ei tarbi.

Tundub uskumatu aga ka tänapäeval mängivad väga paljudes äriprotsessides tähtsat rolli ikka veel paberdokumendid, mida keegi näiteks arhiveerimise eesmärgil välja prindib või millelt keegi mõnda süsteemi infot sisestab. Sellised kohad on protsessides kindlasti esimesed, mis vajavad optimeerimist, sest dokumendipõhine andmete hoidmine ja haldamine on väga ressursimahukas.

3.samm – väärtuspõhine analüüs

Väärtuspõhise analüüsi kohta olen kirjutanud ühes eelnevas blogipostituses . Põhjalikumalt saate lugeda viidatud postitusest aga lühidalt selgitan selle metoodika põhimõtteid ka siin – sisuliselt on vaja aru saada, kes on antud äriprotsessi klient ning tuvastada, millised on kliendi jaoks väärtusetud tegevused.

  • Kui äriprotsessi tegevused ei ole kliendi jaoks väärtuslikud ning nad ei loo ka ettevõttele väärtust, siis võib need tegevused äriprotsessist eemaldada.
  • Kui äriprotsessi tegevused ei ole kliendi jaoks väärtuslikud aga loovad ettevõttele väärtust, siis neid tegevusi äriprotsessist eemaldada ei saa, vaid tuleb leida viisid nende optimeerimiseks.

4.samm – duplikaatide eemaldamine

Duplikaadid võivad äriprotsessides esineda mitmes kontekstis – näiteks dubleerivate tegevustena, dubleeriva andmekorje, -edastuse või -sisestusena. Dubleeriminine tekib tavapäraselt siis, kui mitmed protsessiga seotud grupid ei ole omavahel integreeritud – see tähendab, et ei suhtle omavahel, ei vaheta omavahel andmeid, koguvad ja haldavad andmeid ainult enda eesmärkidest lähtuvalt. Inglise keeles on selle nähtuse kohta väga tabav mõiste silos.

Silodest lahti saamiseks tuleks:

  • minimeerida dokumentide põhist lähenemist – dokumentidelt andmete leidmine ja pärimine on väga ressursimahukas;
  • elimineerida kohad, kus toimub dubleeriv andmesisestus ja/või andmete haldus – tuleks võimalikult palju taaskasutada juba teiste osapoolte poolt kogutud andmeid;
  • elimineerida mitme töötaja poolt sama töö tegemine kui see ei ole põhjendatud äriprotsessi jõudluse tõstmisega;
  • luua äriprotsessi tegevuste tarbeks ühtne andmeallikas (single source of data) – eduka andmehalduse üks põhitõdesid on, et kõik seotud osapooled tarbivad andmeid samast allikast. Ühtse andmeallika headeks näideteks on andmebaasid, millega on erinevad osapooled liidestatud või saavad APIde kaudu sealt andmeid pärida või ettevõtte/asutuse sees näiteks andmeladu, mille pealt saab erinevatele osapooltele genereerida vajaliku andmestiku/aruandeid vms.

5. samm – protsessi lihtsustamine

Kuidas saab teada, kas äriprotsess on liiga keeruline? Kui protsessis osalejaid teevad protsessi tegevuste raames väga palju vigu ja nad ei oska tegevusi teha kasutusjuhendita. Väga keerulisi protsesse võib ära tunda ka keeruliste protsessimudelite järgi – sellistel mudelitel on väga palju erinevat tüüpi otsustuskohti ning sõltuvalt protsessi sisendist palju erisusi. Samuti on keeruliste protsessidega tavapäraselt seotud väga palju erinevaid osapooli.

Protsessi lihtsustamisel võiks meeles pidada järgnevat akronüümi – KISS (Keep is simple, stupid!). Lihtsustamiseks proovi:

  • vähendada protsessis esinevaid tööde üleandmisi;
  • grupeerida samalaadsed tegevused kokku;
  • analüüsida, kas kõik otsustuskohad on õige koha peal;
  • lihtsustada mõnda andmesisestuse vormi.

6.samm – protsessi kogukestuse vähendamine

Protsessi kogukestust nimetatakse ka tsükli ajaks. Tegelikult aitavad kõik eelnevalt läbitud sammud protsessi tsükli aega vähendada.

  • Kui sa vähendad protsessis tööde üleandmisi, siis vähenevad ooteajad ning väheneb ka protsessi tsükli aeg;
  • Kui eemaldada väärtusetud tegevused või bürokraatlikud sammud, siis väheneb samuti protsessi tsükli aeg;
  • Kui sa grupeerid või kombineerid samalaadseid tegevusi, siis saab sama töötsükliga need tegevused efektiivsemalt läbitud ning väheneb samuti tsükli aeg.

Kõik kõik nimetatud sammud on läbitud, siis oled eemaldanud protsessist ebaefektiivsused ning on aeg asuda automatiseerima. Siinkohal võiks enne uue infosüsteemi arendamist kaaluda juba ettevõttes/asutuses kasutusel olevate tarkvarade ja infosüsteemide taaskasutamise võimalust. Päris paljud tööprotsessid on oma olemuselt sarnased ning võibolla õnnestub väikeste modifikatsioonidega mõni olemasolev tarkvara kasutusele võtta.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele raames rakendame ka siin postituses kirjeldatud äriprotsessi optimeerimise metoodikaid – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Äriprotsesside kaardistamise tööprotsess

Kuna pilt ütleb rohkem kui tuhat sõna, siis olen viimasel ajal hakanud ka erinevaid enda tegevusi äriprotsesside vahendusel visualiseerima. Antud postituses tutvustan enda AS-IS äriprotsesside kaardistamise tööprotsessi. Modelleerin enda töövoo BPMN notatsioonis ning selgitan lahti, milliseid tegevusi millises järjekorras tavapäraselt teen.

Tavapäraselt algab äriprotsesside kaardistus vajadusest paremini aru saada, kuidas teatud töövood hetkel käivad ning millised osapooled sellega seotud on. Selline vajadus võib näiteks tekkida teenuse kvaliteedi parendamise raames, ettevõtte digitaliseerimise algatustest või infosüsteemide arendamisega seoses.

Mida modelleerida?

Kõigepealt on vaja endale tekitada arusaam ettevõtte/asutuse erinevatest äriprotsessidest ning sellest, millist äriprotsessi kaardistama on vaja hakata. Kui sellist arusaama ei ole, tuleb kõigepealt luua ettevõtte äriprotsesside arhitektuur. Väga uhke mõiste aga sisuliselt tähendab see kõikide ettevõtte äriprotsesside organiseeritud kogumit. Organiseerimise all mõtlen seda, et üldisema taseme protsessid on eristatud madalama taseme protsessidest ning seatud omavahelisi hierarhiaid kujutavasse nimekirja või on seda hierarhiat mingil kujul visualiseeritud.

Kui äriprotsesside arhitektuur on olemas, siis oleks vaja loodud organiseeritud nimekirjast valida see kõige olulisem äriprotsess, mida kaardistama minnakse. Seda saab teha äriprotsesside prioriseerimise kaudu ning sellest olen kirjutanud eraldi blogipostituses – https://kreetsolnask.com/kust-ma-tean-milliseid-ariprotsesse-koigepealt-kaardistada/ .

Edasi jätkub töö selle ühe kõige olulisema äriprotsessiga. Enne modelleerimist on vaja tellijaga/äriprotsessiga seotud osapooltega kokku leppida, mis on äriprotsessi kaardistamise eesmärk ning milline peaks sellest eesmärgist tulenevalt olema protsessimudeli detailsus. Kui tarkvaraarendajale on vaja väga detailset ja tehniliselt nüanssirohkem protsessimudelit, siis näiteks teenusejuhile sobib tase üldisem protsessimudel. Väga oluline on, et modelleerimise eesmärgi ja detailsuse kokkulepe oleks olemas enne mudeli joonistamist!

Kust saada äriprotsessi kohta infot?

Igasugust äriprotsessi on palju lihtsam modelleerida siis, kui sul on olemas taustateadmine selle protsessi kohta – sisuliselt on vaja aru saada, mida modelleeritav äriprotsess üldse sisaldab, millised osapooled on sellega seotud ning kuidas see konkreetne äriprotsess ettevõte/asutuse teiste äriprotsessidega seostub (nö suur pilt). Sellise taustateadmise saab tekitada erinevate äriprotsessiga seotud materjalide läbitöötamisega või kui selliseid materjale ei ole, siis äriprotsessiga seotud osapoolte intervjueerimise kaudu. Arvestama peab seda, et kui äriprotsessiga seotud alusmaterjalid puuduvad, siis peab selle võrra rohkem intervjuude voore läbima.

Aga mida teha siis kui äriprotsessiga seotud osapooled ei ole valmis intervjuude käigus rääkima? Vahel ikka juhtub, et mõni inimene ei suuda ennast selgelt väljendada või on tema igapäevased tegevused tema jaoks nii iseenesest mõistetavad, et ta ei oskagi neid kirjeldada. Sellisel juhul on väga heaks metoodikaks vaatlus – sisuliselt lähed protsessiga seotud osapoolte juurde kohale ja jälgid, kuidas nad enda tööd teevad.

Juhul kui olemasoleva äriprotsessi toetamiseks on loodud mingi infosüsteem, siis võib väga head infot saada ka infosüsteemide logidest. Sõltuvalt infosüsteemi logide granulaarusest, võib sealt olla võimalik välja lugeda, milliseid infosüsteemi mooduleid või funktsionaalsusi, millises järjekorras läbitakse. Sellise lähenemise inglise keelne koondmõiste on Process Mining – kel huvi võib internetist lähemalt uurida.

Kuidas modelleerida?

Nüüd peaksid olema äriprotsesside kaardistamisel juba sellises punktis, et on aeg hakata BPMN-is mudelit modelleerima. Aga enne veel võiksid paika panna oma äriprotsessi skoobi – see annab kindluse, et oled koostöös seotud osapooltega läbi mõelnud, milline on minu äriprotsessi ulatus. Äriprotsesside skoobist ehk raamistikust olen kirjutanud eraldi blogipostituse – https://kreetsolnask.com/kuidas-alustada-ariprotsessi-modelleerimist/ Võtmetähtsusega on äriprotsessiga seotud osapooltega koos paika panna äriprotsessi algus- ja lõppsündmus!

Lõpuks tuleb äriprotsess BPMN notatsioonis (võib muidugi kasutada ka mõnda muud notatsiooni, minu isiklik lemmik on lihtsalt BPMN :)) ära modelleerida. Ära ei tohi unustada, et seda modelleeritud protsessi tuleb kindlasti vähemalt korra protsessiga seotud osapooltega valideerida! Oluline on, et protsessimudelist saaksid lisaks modelleerijale aru ka kõik protsessiga seotud osapooled ning siin tuleb võtta niipalju aega kui vaja, et mudel nendega läbi käia ja nende heakskiit saada.

Mis saab edasi?

Kui läheb hästi ja protsessiga seotud osapoolte heakskiit saabub kiirelt, siis palju õnne, oled edukalt jõudnud ühe äriprotsessi kaardistatud. Tavapäraselt nii hästi lähe ning sõltuvalt protsessiga seotud osapoolte tagasisidest võib olla vajadus ümber mõtestada protsessi skoop (kirjeldada uuesti äriprotsessi raamistik) või teha täiendusi AS-IS protsessimudelisse.

Varem või hiljem jõuavad kõik protsesside kaardistused sellisesse seisu, et on tekkinud protsessiga seotud osapoolte poolt heakskiidu saanud AS-IS protsessimudel. Võin teid lohutada, et sellega töö ei lõppe – järgmise sammuna on vaja AS-IS protsessi analüüsida, tuvastada selles probleemkohad ning neile lahendusi leides disainida TO-BE tööprotsesse. Aga sellest kirjutan juba eraldi postituses, milles tutvustan taaskord äriprotsessi kaudu enda lähemist.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele raames rakendame siin postituses kirjeldatud äriprotsessi kaardistamise tööprotsessi – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Kuidas saab äriprotsessidest kasu ärianalüütik?

Lähtuvalt igapäevasest vajadusest selgitada, millised on ärianalüütiku ülesanded ja mida võiks üks heal tasemel ärianalüütik osata, võtsin taas ette IIBA The Global Standard for Business Analysis | IIBA® poolt välja töötatud BABOKi (Business Analysis Body of Knowledge). BABOK tutvustab, millised kompetentsid peaksid ühel ärianalüütikul olema, millistest tegevustest ärianalüüs tavapäraselt koosneb ning tutvustab ka erinevaid enimkasutatavaid ärianalüüsi tehnikaid. BABOKist inspireerituna mõtlesin seekordses blogipostituses kirjutada äriprotsesside kaardistuse ja analüüsi rollist ärianalüütiku tööriistakohvris.

Analüütik peab planeerima ka enda tööprotsessi!

Kogemused erinevate töövõtjatega näitavad, et tihtipeale suhtutakse analüüsi kui millesegi triviaalsesse, mis ei nõua mingit tõsist metoodikat, mille tegevusi ei pea ette planeerima ning selleks, et tellija vajadusi mõista piisab mõnest koosolekust ning memost. Kahjuks lõppeb kirjeldatud stsenaarium tihti sellega, et töövõtja ei loo oma tegevusega tellijale väärtust, mille tulemus päädib lõputute vaidlustega ning õnnetud on nii töövõtja kui ka tellija.

Kuidas mina sellist olukorda väldin? Mul on iga analüüsiprojekti jaoks paika pandud üldine tööprotsess, mida läbides saan mitmeid olulisi riske maandada:

  • analüüsi planeerimise etapp,
  • nõuete kogumise ja haldamise etapp,
  • nõuete analüüsimise, disainimise ja kinnitamise etapp,
  • lahenduste disainimise etapp.

Analüüsi planeerimise tööprotsess

  • Enne iga projekti algust mõtestan ma enda jaoks läbi, mis on antud projekti eesmärk ja millist kliendi vajadust/probleemi sellega lahendatatakse. Kui mulle on arusaamatu eesmärk või kliendi vajadus, siis see on esimene asi, mida kliendiga täpsustan;
  • Kui kliendi vajadus on teada, mõtlen läbi, millised tulemid kõige paremini seda vajadust rahuldavad. Analüüsiprojektides tähendab see seda, et panen paika, millise detailsusega spetsifikatsioon peab tekkima. Kui mul endal on olemas ettekujutus tulemitest, siis tutvustan seda ka kliendile, et koos temaga valideerida, kas olen asjast õigesti aru saanud;
  • Kui tulemid on teada ja kliendiga kooskõlastatud, siis panen paika, millist tüüpi tegevusi pean läbima, et neid tulemeid saavutada;
  • Kui tegevused on paigas, siis mõtestan läbi, milliseid osapooli on vaja milliste tegevuste puhul kaasata. Selleks, et osapoolte kaasamine oleks tulemuslik, on oluline enne täpsustada iga osapoole ootused.

Lisaks nimetatud üldisele analüüsi planeerimise protsessile on vaja kliendiga kokku leppida ka see, kuhu analüüsi käigus kogutud info talletatakse, kes, kuidas, millal ja milliste tegevustega analüüsiprotsessi panustavad.

Nõuete kogumise ja haldamise tööprotsess

Selles protsessis on kõige olulisem enda jaoks läbi mõtestada:

  • Mis info on juba olemas ning mis vajab täiendavalt kogumist?
  • Kes annab täiendavat infot ning kuidas on seda seotud osapoolelt kõige otstarbekam kätte saada. Analüütik peab oskama väärtustada ka teiste osapoolte ajalist ressurssi ning leidma võimalikult efektiivsed info kogumise viisid!
  • Kellega ja kuidas valideeritakse, kas kogutud info on aja- ja asjakohane?
  • Kuidas tagada erineva taseme (ärinõuded vs tehnilised taskid/nõuded) nõuete jälgitavus (traceability)?
  • Kuidas käsitleda nõuete muudatusi?

Nõuete analüüsimise, disainimise ja kinnitamise tööprotsess

Kui nüüd tellijaga on peetud mitmeid intervjuusid, töötubasid või töötatud läbi kuhjade viisi dokumentatsiooni, siis on analüütiku ülesanne kogutud informatsioon enda jaoks loogiliseks tervikuks seostada. Ega ilmaasjata rõhutata, et analüütiku üks võtmekompetentse on suure pildi nägemise võimekus :). Suur pilt saab tekkida läbi kogutud nõuete sünteesimise või analüüsimise.

Sünteesi tulemusena disainitakse koostöös tellijaga nõue, mis vajab kindlasti enne realiseerimist ka kliendi kinnitust. Siin on jällegi väga lihtne viis “visata” kliendile ette spetsifikatsioon ja paluda kinnitust, kuid paraku ei vii selline tegevus alati soovitud tulemini. Mina olen täheldanud, et vahel tasub nõuete kinnitamisse rohkem panustada ning selgitada kliendile näiteks koosoleku käigus lahti see loogika, kuidas ja mida on kirja pandud ning mida klient täpsemalt kinnitama peab.

Äriprotsessid on üks paljudest metoodikatest, mis aitavad kliendi nõudeid teatud nurga alt visualiseerida. Mina kasutan äriprotsesside mudeleid väga tihti selleks, et enda arusaama tagasi peegeldada. Sisuliselt valideerin läbi äriprotsesside AS-IS mudelite, kas ma olen õigesti aru saanud kliendi tööst ning selle raames tekkivatest probleemidest. See annab kindluse, et kliendi juurprobleemid on tuvastatud ning minnakse õiget asja lahendama.

Lahenduste disainimise tööprotsess

Lahenduste disainimise üks eeldusi on see, et ärianalüütikul on tekkinud väga hea arusaam, kliendi vajadustest ning ootustest. Jällegi olen kogenud, et ettevõtte/asutuse olemasolevate äriprotsesside kaardistuse (AS-IS olukorra) analüüsimine annab ärianalüütikule väärtusliku teadmise kliendi vajaduste kohta ning suuna, mida oleks vaja kliendi tööprotsessides tulevikus parandada ning kuidas neid võimalikult optimaalseks disainida.

Samuti võimaldavad hetke- ja tulevikuolukorra äriprotsesside mudelid hinnata, kui suur võit on loodaval lahendusel. Näiteks on võimalik läbi protsesside simulatsiooni hinnata, kui palju on tulevikuprotsess hinnanguliselt efektiivsem (st. kui palju kiirem ta on, kui palju ressurssi säästetakse jne). See teadmine on omakorda oluline sisend loodava lahenduse tasuvusanalüüsi, mille käigus võiks tekkida arusaam, kas loodava lahenduse näol tehtav investeering on tasuv.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele on oodatud osalema kõik ärianalüütikud, kes tahavad saada oma tööriistakohvrisse juurde ühe olulise metoodika rakendamise oskust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Ettevõtte väärtusahel – mis see on ja miks see oluline on?

Võibolla olete kuulnud, et majandusteadlane Michael Porter https://en.wikipedia.org/wiki/Michael_Porter jagas oma väärtusahela (value chain) mudeli järgi ettevõtte äriprotsessid põhi- ja tugiprotsessideks. Enne kui postitusega jätkan, oleks ilmselt mõistlik defineerida väärtusahela mõiste. Väärtusahel on rida selliseid tegevusi, mida ettevõtted teevad selleks, et luua toodet või pakkuda teenust. Väärtusahelasse kuuluvate tegevuste läbimisel peab tekkima kliendile väärtus (allikas – https://digitalleadership.com/unite-articles/porters-value-chain/).

Joonis 1. Porteri väärtusahela mudel

Joonisel 1 on toodud Porteri poolt välja pakutud väärtusahela mudel, mille järgi saab ettevõtte erinevad protsessid jagada põhi- (primary activities) ja tugitegevusteks (support activities). Põhitegevused on siis sellised, mille läbimine tekitabki lõppkliendile väärtust ning tugitegevused on vajalikud selleks, et põhitegevusi saaks edukalt ja võimalikult optimaalselt läbida.

Porteri väärtusahela põhitegevused

Porteri väärtusahela mudeli järgi on põhitegevused järgnevad:

  • sissetulev logistika (inbound logistics) – kõik tegevused/protsessid, mis on seotud toormaterjali hankimise, ladustamise ja haldamisega;
  • tootmine/operatiivsed tegevused (operations) – kõik tegevused/protsessid, mis on seotud toormaterjalist toodete loomisega;
  • väljaminev logistika (outbound logistics) – kõik tegevused/protsessid, mis on seotud valmistoodete ladustamise ja kliendini jõudmisega;
  • turundus ja müük (marketing and sales) – kõik tegevused/protsessid, mis on seotud toodete turunduse, müügi ja hinnastamisega;
  • klienditeenindus (service) – kõik tegevused/protsessid, mis on seotud kliendi toetamisega toote kasutamisel (nt. klienditeenindus või tugi toote kasutamisel, toote hooldusega seotud tegevused jne).

Porteri väärtusahela tugitegevused

Joonisel 1 välja toodud tugiprotsessid tagavad nö raamistiku, mille najal ettevõttel on võimalik oma põhiprotsesse mugavalt läbida. Nt inimressurssidega seotud protsessid (human resource management) tagavad, et põhiprotsessi sammude jaoks oleksid vajalikul hetkel olemas vajaliku kompetentsiga inimesed. Hankimise protsessid (procurement) tagavad, et toote valmistamiseks oleks vajalikul hetkel olemas vajalik toormaterjal. Tehnoloogia arendamisega (technology development) seotud protsessid tagavad toote innovatsiooni ning selle, et toote põhiprotsess oleks võimalikult efektiivne ja õigetes kohtades automatiseeritud. Muud operatiivsed portsessid (firm infrastructure) tagavad, et ettevõttes oleks nõutekohane raamatupidamine, õiguslik asjaajamine ning muud administratiivsed tegevused.

Porteri väärtusahela mudel on väga hea ülevaatlik mudel, mis grupeerib väärtusloomest lähtuvalt ettevõtte äriprotsessid põhi- ja tugiprotsessideks. Mainitud mudeliga on ainult üks pisike probleem – nimelt on see mudel pigem tootmisettevõtte spetsiifiline ning ei kajasta minu hinnangul hästi IT teenuseid pakkuvate ettevõtet põhiprotsesse. IT teenuste puhul ei esine sissetuleva ja väljamineva logistika põhiprotsesse, kuna füüsiliselt mingid materjalid ja tooted ei liigu ning tooteid ei ole vaja ladustada. IT teenuste puhul on tegemist pigem nõudlusele vastava teenuse õigeaegse pakkumisega ja seega on väga olulisel kohal võimalikult varajases etapis nõudluse tuvastamine.

IT teenuste väärtusahela põhitegevused

Joonis 2. IT teenuste väärtusahel ( allikas – https://pubs.opengroup.org/it4it/refarch20/chap03.html)

OpenGroup https://pubs.opengroup.org/it4it/refarch20/chap03.html on välja pakkunud Porteri väärtusahela analoogial oma tõlgenduse IT teenuste väärtusahelast. Selle järgi on väärtusahela põhitegevused:

  • strateegiast portfoolioni (strategy to portfolio) – kõik tegevused/protsessid, mis on aitavad defineerida ettevõtte starteegia, siduda selle ärilise vajadusega ning planeerida see arendatavate teenuste portfooliosse. Hõlmab endas ka teenuse nõudluse tuvastamisega seotud tegevusi!
  • nõuetest tarnimiseni (requirement to deploy) – kõik tegevused/protsessid, mis on seotud teenuse planeerimise, arendamise, testimise ja tarnimisega. Hõlmab klassikalise tarkvaraarenduse elutsükliga seotud tegevusi.
  • päringust täitmiseni (request to fulfill) – kõik tegevused/protsessid, mis on seotud teenuse hinnastamise ja SLA tingimuste kokkuleppimisega, teenuse tellimise, pakkumise ja teenuse mõõtmisega.
  • tuvastamisest parandamiseni (detect to correct) – kõik tegevused/protessid, mis on seotud teenuse pakkumise käigus tekkivate probleemide/muudatusvajaduste tuvastamise, analüüsimise ja lahendamisega.

Kuidas on ettevõtte protsessid seotud selle väärtusahelaga?

Nagu eelnevatest väärtusahela mudelitest nägime, siis on väärtusahel oma olemuselt ettevõtte äriprotsesside grupeeritud kogum. Mainitud grupeering on tehtud lähtuvalt sellest, milline on ettevõtte strateegia ning millist väärtust ta loodab oma teenuse/tootega pakkuda. Seega võiks öelda, et väärtusahel on justkui korrastatud suur pilt kõikidest erinevatest ettevõtte äriprotsessidest, milles on läbi põhiprotsesside defineerimise rõhutatud ettevõttele eriti olulised äriprotsesside grupid.

Samuti saime teada, et põhiprotsessid on ettevõtte äriprotsessid, mis loovad sellist väärtust, mille eest klient on nõus maksma ning millest tuleb ka suur osa ettevõtte käibest. Seega on igale ettevõttele väga oluline teada täpselt, kuidas tema põhiprotsessid toimivad ning kuidas neid veelgi paremaks/ efektiivsemaks/ kiiremaks saada. Siin tulevadki mängu äriprotsesside kaardistamine ja optimeerimine! Kui põhiprotsessid on kaardistatud ning piisaval määral optimeeritud, siis on kindlasti oluline tähelepanu pöörata ka ettevõtte tugiprotsessidele, sest on ju nende ülesanne omakorda aidata kaasa põhiprotsesside efektiivsele läbiviimisele. Kindlasti tekib siin paljudel kiusatus äriprotsesside kaardistus pooleli jätta, kuna tegemist on ju ainult tugiprotsessidega. Siinkohal väike meeldetuletus, et ebaefektiivsed tugiprotsessid takistavad omakorda põhiprotsesside efektiivset läbimist!

Kokkuvõttev tegevuskava võiks olla järgnev – kui olete oma ettevõtte väärtusahela paika pannud, siis esimese asjana oleks vaja kaardistada kõik ettevõtte põhiprotsessid ning proovida neid optimeerida. Seejärel kaardistada kõik ettevõtte tugiprotsessid ning proovida ka neid optimeerida. Ja nagu äriprotsesside halduses tavaks, siis ükski kaardistus ega optimeerimine ei ole ühekordne tegevus – teatud aja tagant on mõistlik kasutuses olevad tööprotsessid taas üle vaadata ning otsida uusi optimeerimisvõimalusi!

Kui sind kõnetavad teemad, mida oma blogis kajastan või vajad abi oma ettevõtte äriprotsesside kaardistamisel, siis võta minuga julgelt ühendust!

Juurpõhjuse analüüs II – miks klient ei saa seda, mida tal vaja on?

Lubasin eraldi blogipostituses jätktata enda koostatud Ishikawa diagrammi lahti kirjutamist. Seekord käsitlen siis metoodika ja meeskonnaga seotud juurpõhjuseid.

Metoodika

Vikipeedia definitsiooni järgi on metoodika (inglise keeles methodology) korrastatud lähenemine suuremale tegevusele. Metoodika jaotab protsessi väikemateks osadeks, püstitab osadele eesmärgid ning võib näidata ära meetodid nende eesmärkide saavutamiseks https://et.wikipedia.org/wiki/Metoodika.

Minu jaoks tähendab metoodika arusaama, kuidas ma konkreetseid metoodeid/töövõtteid rakendades konkreetse eesmärgini jõuan. Ehk siis ühelt poolt peab olema väga selge arusaam, mis on eesmärk. Teiselt poolt peab olema teadmine, milliseid konkreetseid tegevusi/meetodeid, millises järjekorras selle eesmärgini jõudmiseks rakendatatakse. Tundub ju lihtne ja loogiline? Tegelikkuses on kahjuks misiganes metoodilised märksõnad tarkvara arendusprojektides tihti ainult sõnakõlksud. Puudub tegelik arusaam, mis on nende sõnade taga.

Projektijuhtimise metoodika

Projektijuhtimise meetoodikaid on väga palju erinevaid ning neid ma siin kõiki ükshaaval tutvustama ei hakka. Minu tähelepanek on seotud sellega, et väga palju viidatakse tarkvara arendusprojektides mingile metoodikale ilma lahti mõtestamata, mida see tähendab, kuidas seda rakendada ja kas seda antud kontekstis üldse rakendada on võimalik.

Lõpuks ei ole vahet, millist metoodikat kasutatakse, oluline on projekt etteantud piirangute raames võimalikult edukalt ära teha. Kui projekti realiseerimiseks on väga pingeline ajaperiood, kindel skoop ja eelarve, siis peab olema nagu kellavärk selge, kes mida ja millal teeb. Sellisel juhul ei saa lubada endale agiilsuse sildi all planeerimatust ja metoodika ning vajalike oskuste puudumist.

Millest siis kliendi vaatest vajaka jääb? Suurel osal juhtudest jääb vajaka planeerimise oskusest. Ehk siis mõtteviisist, milliseid tegevusi millises vahemikus on vaja teha selleks, et me mingi etapi lõpuks vajalikud eesmärgid täidetud saaks. Sellise plaani olemasolu on vajalik ka kliendi ootuste juhtimiseks – et oleks arusaam, millal peab olema klient valmis midagi üle vaatama või testima.

Teine oluline tegevus, mis tihti tegemata jäetakse on arendustiimi sees rollide vastutuste ja koostöö korralduse kokku leppimine. Kui seda paika ei panda, siis töö tegijad ei tea, mis nendelt oodatakse ja kuhu “maani” peavad nemad panustama. Rollide paikapanemine ja läbirääkimine peab toimuma koostöös kliendiga! Siis on ka tema ootused rollide tööülesannetele juhitud.

Projektis vajaliku kommunikatsiooni tagamine on samuti üks osa projektijuhtimise metoodikast. Eeldatatakse, et meeskonna sees teineteisega suhtlemine ja info vahetamine on elementaarne ning iga meeskonna liige saab sellega edukalt hakkama. Kuna inimtüübid on erinevad, siis paraku see kõigile nii elementaarne ei ole. Siin on jällegi projektijuhi vastutus aidata sellised juhtusid lahendada! Ja kommunikatsiooni all ei mõtle ma ainult silmast-silma suhtlemist, vaid misiganes infovahetuse viisi.

Analüüsi metoodika

Ma ise olen valdavalt olnud erinevatest analüütiku rollides, seega on analüüsi metoodika mulle väga südamelähedane teema. Nagu nimetuski viitab on analüütiku töö olemus mingi info läbi analüüsimine ning selle läbi kliendi vajaduste parem mõistmine. Tihti on läbitöötamist vajavat infot palju ja seda on vaja veel täiendavalt juurde koguda, et tekiks arusaam, mida kliendil päriselt vajab. Selleks, et mingi infokild ei jääks kahe silma vahele, on vaja väga konkreetset ja süsteemset plaani. Vaja on läbi mõelda, millist infot on vaja koguda, kuidas seda võimalikult optimaalselt teha ning milliste meetoditega seda analüüsida. 

Kurvaks teeb see, et väga sageli tarkvaraarendusprojektides analüütikutel selline plaan/metoodika puudub ning rööpräheldakse ühel ja teisel rindel. Pole ime, et midagi jääb kahe silma vahele ja analüütikul on enda kaitseks vaid öelda “Aga ma ei saanud aru, et teil selline vajadus on!”. Analüütiku peamine ülesanne on aru saada, mis on kliendi vajadus! Kui seda arusaama ei teki, siis tuleks peeglisse vaadata ja endalt küsida:

  • kas ma mõistan üldse probleemi, mida lahendatakse?
  • kas ma sain kliendilt kinnituse, et olen tema probleemist õigesti aru saanud?
  • kas mul oli plaan/tegevuskava, kuidas kellelt ja mis infot ma vajan?
  • kas minu tegevuskava mahub projekti etteantud raamidesse?
  • kas ma analüüsisin lahendatavat probleemi erinevatest aspektidest?
  • kas ma saan aru, kuidas pakutav lahendus probleemi lahendab? nö suure pildi mõistmine
  • kas ma palusin kliendil keerulisemaid asju mitmeid kordi selgitada?
  • kas ma peegeldasin kliendile oma arusaama?

Teine tähelepanek, mida olen märganud on see, et kogutakse küll seotud osapooltelt vajalik info ära, mis vormistatakse memodeks ning sellega justkui analüüs lõppeb. Kallid analüütikud, tahaksin teile meelde tuletada, et analüütiku rolli nimetus on meelega analüütik ja hoopis mitte referent! Info kogumine on alles esimene osa analüüsist. Kõige olulisem osa on kogutud info analüüsimine/sünteesimine ning selle pinnalt koostöös meeskonnaga kliendile vajaliku lahenduse välja pakkumine.

Analüütik peab suutma mõista kliendi probleemi ja tööprotsesse. Kogutud info pealt suurt pilt näha ning koostöös tehnilise meeskonnaga välja pakkuda lahendusi kliendi probleemi lahendamiseks. Kui ta seda ei suuda, siis puudub analüütikul antud projektis/teenuses väärtuspakkumine!

Meeskond

Meeskonna puhul on võtmetähtsusega kolm faktorit – oskused, kogemused ja tahe ehk motivatsioon. Ideaalses tarkvaraarenduse meeskonnas on kõikidel rollidel need kolm faktorit esindatud. Ehk rollil on olemas oskused vajalikke metoodikaid rakendada, ta on seda saanud varasemalt praktiseerida ning tal on tahe klienti aidata.

Nagu me juba teame, siis kahjuks ei ela me ideaalses maailmas ning teenust pakkuva meeskonna puhul jääb tihti vajaka üks kolmest faktorist. Ilmselt oleme kõik omal nahal tunda saanud seda, et riigihangetes võib paberile väga ilusad CV-d kokku kirjutada. Aga kui tegelik töö pihta hakkab, siis jääb justkui midagi vajaka.

Kui vajaka jääb oskustest konkreetseid metoodikaid, töövõtteid rakendada, siis tehakse tööd väga ebaefektiivselt. Suure tõenäosusega tekivad raskused projekti etteantud ressursside raames ära teha.

Kui vajaka jääb eelnevast kogemusest, siis suure tõenäosusega ei osata mõelda lahenduse suure pildi peale, mistõttu ei osata ka teatud riske/ohukohti ette näha. See seab samuti ohtu projekti realiseerimise võimalikkuse etteantud ressursside raames.

Kui vajaka jääb tahtest klienti mõista, siis tekib lahendus, mida kliendile tegelikult vaja ei olnud. Sellisel juhul tehakse lihtsalt midagi ära ning pärast vaidluste käigus tuuakse välja argument “Aga te ei öelnud, et teil selline vajadus on”.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Juurpõhjuse analüüs I – miks klient ei saa seda, mida tal vaja on?

Ma olen tänaseks 10 aastat aktiivsemalt olnud seotud tarkvara arendusprotsessidega nii teenuse tellija kui ka pakkuja poolel, seega mõtlesin vahelduseks sellest kirjutada. Täpsemalt oli mõte peegeldada minu tähelepanekuid selle kohta, miks klient tihti ikkagi ei saa tarkavaraarenduse projektidest seda, mida ta vajab. Oma tähelepanekuid plaanin teile tutvustada läbi Ishikawa või põhjus-tagajärg diagrammi.

Mis on Ishikawa diagramm?

“Kalasaba diagrammi (inglise k fishbone diagramm) tuntakse ka põhjus-tagajärg diagrammi nime all või siis selle looja Kaoru Ishikawa järgi Ishikawa diagrammi nime all. Antud diagrammi kasutatakse probleemi algpõhjuse väljaselgitamiseks. Algpõhjuseni jõudmiseks peab diagrammi joonistamise käigus läbi mõtlema kõik tegurid, mis selle probleemi esile võisid kutsuda.” https://tsenter.ee/kalasaba-diagrammide-kasutamine-probleemide-lahendamisel/

Minu poolt koostatud Ishikawa diagrammi (Joonis 1) probleemiks on küsimus “Miks klient ei saa seda, mis tal vaja on?” ning selle probleemi algpõhjuseid analüüsides olen tuginenud enda tähelepanekutele tarkavaraarenduse projektidest. Minu joonise algpõhjuste grupid on kohandatud vastavalt minu tähelepanekutele. Tavapäraselt võite internetist leida Ishikawa diagramme, milles on algpõhjused grupeeritud 6 suuremasse gruppi.

Joonis 1. Ishikawa diagrammil visualiseeritud algpõhjused

Joonisel viidatud algpõhjuste gruppe kirjutan lahti mitmes järjestikusest blogipostituses. Plaanisin küll seda teha ühe postitusega aga te poleks viitsinud seda siis lõpuni lugeda 🙂 Antud postituses tuleb siis juttu tehnoloogiast ja andmetest.

Tehnoloogia

Tehnoloogia on väga võimas vahend, misiganes tööprotsesside efektiivistamiseks või automatiseerimiseks. Aga seda peab oskama rakendada õigel kujul õigetes kohtades! Mida ma selle all mõtlen? Tehnoloogiat ei ole vaja rakendada lihtsalt sellepärast, et see on uus kuum trend või et keegi teine kusagil seda teeb. See toob kliendile kasu ikkagi siis ja ainult siis kui see haakub antud kliendi tööprotsessidega. Tehnoloogia rakendamise/juurutamisega seoses on minu algpõhjuste tähelepanekud olnud järgnevad:

  • Tarkvaraarenduse projektides pööratakse tihti liiga vähe tähelepanu arhitektuuri läbimõtlemisele ja paika panemisele. Ja siin on oluline arhitektuur mitte abstraksel tasandil, vaid juba seoses äriarhitektuuriga ja tööprotsessidega.
  • Tihti on arhitektuur planeeritud nii, et see ei haaku kliendi tööprotsessidega. See viitab sellele, et tehnoloogiline vaade ei ole kooskõlas äriliste vajadustega ning seda on planeeritud ärilistest vajadustest isoleerituna.
  • Üks peamine ootus arhitektidele on see, et nad on kursis erinevate tehnoloogiliste võimalustega ning oskavad neid sobitada ärilistest vajadustest lähtuvalt ka arhitektuuri. Selle tegemine eeldab arhitektilt oskust ja tahet mõista ärilisi vajadusi. Tundub elementaarne aga sellist oskust kohtab kahjuks vähe! Ma olen mainitud 10 aastase perioodi jooksul kohanud ainult kahte sellist arhitekti, kes seda on suutnud hästi teha.

Andmed

Väga hea viis tööprotsesside efektiivistamiseks on elimineerida tööprotsessidest kasutaja sellised manuaalsed tegevused, millega saab väga edukalt hakkama masin/tehnoloogia. Andmete liigutamine ühest allikast teise, andmete kokku kombineerimine ja omavaheline rikastamine on näited sellistest tegevustest, mida saab misiganes tööprotsessides teha väga edukalt tehnoloogia kaasabil. Andmetega seoses on minu algpõhjuste tähelepanekud olnud järgnevad:

  • Tarkvaraarenduse projektides pööratakse üldiselt väga vähe tähelepanu andmetele ja justnimelt sellele poolele, kuidas kusagil kogutavad andmed saavad säästa mõnes teises tööprotsessis osalevate inimeste tööaega ning millist kasu/väärtust andmed konkreetsele tööprotsessile annavad.
  • Kuna ei tajuta andmete väärtus tööprotsesside efektiivistamisel, siis tihti ei planeerita ka tarkvaraarenduse projektidesse andmete analüüsimisega seotud tegevusi. Uute IT süsteemide arendamisel jääb vajaka andmete analüüsi vaade – ei analüüsita, mis andmeid mingi tööprotsess vajab, mis kujul ta neid andmeid vajab, millistest allikatest need andmed saadakse jne.
  • Väga tavapärane on see, et arendustele eelnevates äri- või eelanalüüsides reastatakse terve hulk erinevaid liidetusi teiste süsteemidega, mida on vaja projektis realiseerida, ilma endale selgeks tegemata, kas antud allikad sisaldavad ikkagi neid andmeid, mida tööprotsessides on vaja.

Minu joonistatud Ishikawa diagrammilt saate juba märksõnade näol vihjeid, millistele algpõhjustele oma järgmistes blogipostitustes keskendun. Senikaua aga proovige ise ka mõne probleemi kohta koostada Ishikawa diagrammi 🙂

NB! Ishikawa diagramm on väga hea töövahend misiganes muudes tööprotsessides esinevate probleemide algpõhjuste väljaselgitamiseks!

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Miks on oluline kaasata kõiki seotud osapooli äriprotsesside kaardistamisse?

People change management is a core essential of successful BPM, and an area that must be focused upon throughout the entire BPM activity

John Jeston, Business Process Management

Väga tihti puutun kokku sellega, et äriprotsesse kaardistatakse isolatsioonis st. ei kaasata kõiki antud äriprotsessiga seotud osapooli ning teatud tegevuste modelleerimiseks eeldatakse, et midagi toimib just nii. Analüütikute seas on väga levinud järgnev ütlus – “Eeldamine on kõigi arusaamatuste ema”. See ütlus kehtib väga hästi ka äriprotsesside kaardistamise kohta. Antud postituses toon välja põhilised argumendid selle kohta, miks on oluline äriprotsesside kaardistamisel kaasata seotud osapooli.

Kaasamine on vajalik selleks, et inimesi “pardale” saada

Äriprotsesside kaardistamise algatused/projektid võivad tuua ettevõttes/asutuses kaasa väga suurt vastuseisu. Ja seda sellepärast, et töötajad ei saa aru, miks seda kaardistust vaja on ja kuidas see hakkab nende tuleviku tööülesandeid mõjutama. Teadmatus omakorda tekitab inimestes alateadlikke hirme ning selle pinnalt tekibki vastuseis.

Siin on esimeseks soovituseks see, et tuleb oma asutuse/ettevõtte töötajatele selgelt ja ausalt kommunikeerida, mis eesmärgil äriprotsesse kaardistatakse ning kas ja kuidas see hakkab tulevikus nende tööd mõjutama. Tavaliselt võib selline kaardistus ja tuleviku äriprotsesside disainimine kaasa tuua muudatusi töötajate tööülesannetest või vajadust uusi oskusi omandada. Kõik sellised nüanssid tuleks töötajatele kindlasti kommunikeerida, siis nad teavad, mida oodata. Lõppude lõpuks on igal töötajal vaja aru saada, mida ta võidab või kaotab antud äriprotsesside kaardistusega.

Äriprotsesside kaardistamise projekti alguses on kommunikatsioon oluline ka selleks, et meelestada töötajaid koostööle. Oluline on siin see, et nimetatud kommunikatsioon tuleks ettevõtte/asutuse juhi poolt. See annab töötajatele signaali, et antud kaardistus on ka juhi jaoks oluline ning nad saavad aru, et kui aitavad projektil õnnestuda, toob see mingit kasu ka ettevõtte/asutuse jaoks.

Kaasamine on üks viis sõlmida kokkuleppeid

Kõige suurem viga, mida tehakse äriprotsesside kaardistamisel on see, et antud äriprotsessiga seotud osapooltelt ei küsita sisendit. Millegipärast arvatakse end teadvat, kuidas teised inimesed tööd teevad ja millised probleemid neil hetke äriprotsessis esinevad. Seda tehakse ilmselt aja säästmiseks või selleks, et saaks kiiresti kaardistamise projektiga edasi liikuda. Sest kui tegemist on suurte ja keeruliste äriprotsessidega, siis võib neid kaasamist vajavaid osapooli olla päris palju.

Selline mitte-kaasamine tekitab töötajates kõrvalejäetuse tunde ning see on jällegi üks põhjustest, miks võib tekkida vastuseis kaardistamise projektile. Töötajatele jääb mulje, et tegelikult ei hoolita sellest, kuidas nemad antud protsessis toimetavad ning millised on nende probleemid/mured.

Võib üsna kindel olla, et need osapooled, keda ei kaasata protsessi kaardistamise faasis, ei ole valmis ka antud protsessile omapoolset kinnitust andma (isegi kui see kajastab nende tegevusi ja vastutusi üpris asjakohaselt). Nad leiavad küll ja veel põhjendusi, miks ei saa antud protsessi kinnitada. Selline trots tekibki mitte-kaasamise tagajärjel.

Seega oleks nimetatud vastuseisu vältimiseks mõistlik võtta see aeg ja kaasta kõiki äriprotsessiga seotud osapooli. See võib toimuda nii, et antud äriprotsess on ära modelleeritud ja siis valideeritakse see seotud osapooltega läbi. Kindlasti ärge valideerimist korraldage nii, et saadate seotud osapooltele protsessimudelid ja palute neil need iseseisvalt läbi töötada. Kõige efektiivsem on valideerimist läbi viia koosoleku/töötoa vormis, mille raames saate anda omaltpoolt protsessi kohta täiendavaid selgitusi.

Kaasamine on üks muudatuste juhtimise tööriistadest

Iga äriprotsessi kaardistus ja selle pinnalt tuleviku äriprotsesside disainimine toob endaga kaasa mingit laadi muudatusi. Need võivad olla muudatused ettevõtte/asutuse töökorralduses või siis hoopiski töömetoodikas (ehk selles, kuidas tööd tehakse).

Misiganes muudatuste juhtimise raamatu te lahti lööte, siis näete, et igal pool rõhutatakse töötajate kaasamise ning neile võimalikult selge ja asjakohase info jagamise olulisust. Täpselt sama kehtib igas äriprotsesside kaardistamise projektis – inimesi on vaja hoida informeerituna, neile on vaja selgitada, mis eesmärgil midagi tehakse, mis selle tegevuse tõttu paremaks muutub ning kuidas see neid puudutab.

Muudatuste juurutamisel on oluline oma töötajatega aktiivselt suhelda, et aru saada, millised mured neil konkreetse muudatusega seoses tekivad. Sellest infost lähtuvalt on vaja mõelda, kuidas oma töötajaid toetada. Vahel võib see toetus seisneda lihtsalt töötaja julgustamises, vahel võib ta kõrvale vajada mentorit vms. Igaljuhul ärge jätke oma töötajaid oma muredega üksi ning proovige aktiivselt neile muudatuste juurutamise käigus tuge pakkuda!

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus. Koolituse teisel päeval puudutame ka äriprotsesside juurutamise, sh muudatuste juhtimise teemasid.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Kõik teed viivad äriprotsesside kaardistusteni

Kui kõnekeeles on ütlus “Kõik teed viivad Rooma”, siis  ärimaastikul võiks olla ütlus “Kõik teed viivad äriprotsesside kaardistuseni”. Käesolevas blogipostituses annan ülevaate äriprotsesside olulisusest ettevõtte/asutuse vaatevinklist. Antud postituse jaoks sain inspiratsiooni Michael Foxi vastavasisulisest LinkedIn-i postitusest. Olen äriprotsesside kaardistuseni jõudmise teekonna kohta koostanud otsustuspuu, mis visualiseerib seda, et lõpuks on ettevõttel/asutusel mingis kontekstis ikkagi oluline aru saada ja kaardistada oma äriprotsesse. Olgugi, et ta seda alguses ei pruugi tajuda ega oska seda vajadust kuidagi äriprotsessidega seostada.

Loe edasi…
« Older posts Newer posts »