Äriprotsesside tuvastamine, tõhustamine ja haldamine

I – Millisel protsessijuhtimise küpsusastmel asub sinu ettevõte?

2. apr. 2024 / / 0 Comments

Vast olete kuulnud ütlust “Igal asjal on oma aeg”? See ütlus kehtib väga hästi ka protsessijuhtimise kohta (NB! mõtlen protsessijuhtimise nime all lühendit BPM (Business Process Mangement)). Ettevõtted, kes ei ole siiani tegelenud enda protsesside paika panemise, dokumenteerimise ja protsessidest teadlikkuse tõstmisega, tahavad äkitselt teada, milline on kõige parem tööriist oma protsesside haldamiseks. Mina ütleks selle peale “Hold your horses!“. Kõigepealt on vaja protsessijuhtimise mõtteviis juurutada ettevõtte kultuuris ja alles seejärel tulevad spetsiaalsed tööriistad, notatsioonid ja repositooriumid.

Käesolevas postituses puudutan protsessijuhtimise küpsusmudelit (BPM Maturity Model) , mille abil saab iga ettevõte enda küpsusastet määrata ning jagan ka mõned soovitused, kuidas järgmisele arengutasemele liikuda.

Joonisel ei ole kajastatud 0-taset, sest selles faasis ei ole ettevõtted endale isegi teadvustanud oma ettevõtte äriprotsesse ega ka seda, millist kasu annab nende kaardistamine. Samuti puuduvad seal inimesed, kes teaks midagi äriprotsesside kaardistamisest ja täiustamisest. Eestis on valdav osa mikro- ja väikeettevõtteid oma protsessijuhtimises alles 0-tasemel!

Soovitus: pange paika oma ettevõtte eesmärgid ja mõelge läbi reaalsed tegevused, kuidas sinna jõuate. Selle mõtteharjutuse tulemusena peaks tekkima arusaam oma ettevõtte põhiprotsessist/-protsessidest. Seejärel proovige seda arusaama, kuidagi kirja panna ja/või visualiseerida. Küsige sellele teiste meeskonnaliikmete arvamust/tagasisidet!

Tase 1 – Algeline

1.taset iseloomustab hästi kaootiline ja eesmärgipäratu tegutsemine. Sellel tasemel on ettevõttes teadvustatud vajadus saada paremini aru oma äriprotsessidest aga mingit juhitud süsteemi veel paigas ei ole. Ettevõttes on üksikud äriprotsesside entusiastid, kes modelleerivad näiteks enda töölõike ning selle tulemusena tekkivad protsessimudelid asuvad sellesama isiku arvutis. Tihti puuduvad isegi sama meeskonna üleselt kokkulepped, kuidas tööd tehakse, rääkimata siis kogu meeskonna tööd kajastavatest protsessimudelitest.

Mõned tunnusmärgid, et ettevõtte asub 1.tasemel:

  • Üksikud meeskonnaliikmed on kuulnud protsessijuhtimisest ja on seda teemat iseseisvalt uurinud (teadmiseks, et ka mina alustasin sellest punktist 🙂 );
  • Tekib vaikselt arusaam, et vaja oleks ühtset protsessijuhtimise metoodikat;
  • Protsesse “juhivad” need isikud, kes protsessimudelid lõid – nö isikupõhine juhtimine;
  • Mõned protsessid on juhuslikult dokumenteeritud;
  • Protsessijuhi mõiste puudub;
  • Protsesside kaardistamise ja täiustamise/standardiseerimise metoodika puudub;
  • Üldiselt ei kasutada protsessimudeli loomiseks mingit kindlat notatsiooni;
  • Protsessi muudatuste juhtimist ei toimu, muudatusi viiakse sisse ad-hoc printsiibil;
  • Protsessimudelite kvaliteedikontroll puudub;
  • Protsessimudelite hoidmiseks ei kasutata ühtseid tööriistu ega repositooriumi.

Soovitus: Ärge võtke ette liiga suurt ampsu! Näiteks võtke fookusesse mõni oma ettevõtte peamise toote või teenusega seotud protsess. Mõni selline, kus kõige rohkem king pitsitab 😉. Pange eesmärgiks läbi viia selle teenuse osutamise või toote loomisega seotud protsessi kaardistamine sellisel tasandil, et kõigil protsessis osalejatel tekiks arusaam oma rollist. Panustage inimeste koolitamisse, leidke üles enda ettevõtte äriprotsesside entusiastid ja võimestage neid. Kui selliseid inimesi ei ole, siis “kasvatage” need või värvake. Esimese “ampsu” edukal läbimisel, tutvustage seda algatust ettevõttes laiemalt, jagage õnnestumisi ja õppetunde.

Tase 2 – Juhitud

2.taset iseloomustab juba juhitum lähenemine, milles meeskonna/tiimi tasandil pannakse projektipõhiselt paika ühised protsessid. Seda selleks, et sama töölõiku tegevad töötajad oskaksid üksteisega arvestada ja projekt jõuaks eduka lõpuni. Protsesside täiustamine on endiselt jäetud äriprotsesside entusiastide pärusmaaks ja kui seda tehakse, siis sellest dokumentatsiooni näol mingit märki maha ei jää. Protsessijuhtimise teemal on mõnda üksikut inimest koolitatud aga ettevõttes läbivat ja süsteemset koolituskava ei eksisteeri.

Mõned tunnusmärgid, et ettevõtte asub 2.tasemel:

  • Teatud hulk inimesi on läbinud protsessijuhtimise teemalisi koolitusi;
  • Projektipõhiselt jõuvad protsessijuhtimise tegevused ka töötajate ametijuhenditesse;
  • Koolituse läbinud meeskonnaliikmed kasutavad sama BPM tööriista;
  • Protsessi muudatuste juhtimine toimub (projekti)meeskonna siseselt;
  • Protsesse dokumenteeritakse samast standardist lähtuvalt (tavapäraselt BPMN);
  • On tekkinud nö mitteametlikud protsessijuhid;
  • Protsesside kaardistamise ja täiustamise/standardiseerimise metoodika on juhuslik – igaüks teeb nii nagu heaks arvab;
  • Valikuliselt kontrollitakse protsessimudelite kvaliteeti;

Soovitus: Panustage inimeste koolitamisse, leidke üles enda ettevõtte äriprotsesside entusiastid ja võimestage neid. Andke äriprotsesside entusiastidele vastutusrikkamaid ülesandeid – nt ettevõtte protsesside kaardistamise ja täiustamise metoodika paika panemine. Laske neil analüüsida ettevõtte vajadusest ja ressurssidest lähtuvaid erinevaid BPM tööriistu ja valige välja enda ettevõttele sobiv. Kujundage äriprotsesside entusiastidest enda ettevõtte protsessijuhid. Tehke tööd juhtkonnaga – selgitage neile laiapindsema protsesside kaardistamiseks ja täiustamise vajalikkust. Planeerige rahastus – ühelt poolt laiemalt enda inimeste koolitamiseks ning teisalt protsesside kaardistamisse ja täiustamisse konsultantide näol lisaressursi kaasamiseks.

Kõige suurem arenguhüpe on 2.tasemelt 3.tasemele liikumine, sest 3.tasemel peaksid senini läbiviidud tegevused hõlmama juba laiemalt kogu ettevõtet. Selle arenguhüppe õnnestumisel on võtmetähtsusega juhtkonna tugi – kas juhtkond on pardal ja on nõus ettevõttes laiemalt protsesse kaardistama ja liikuma protsessipõhise juhtimise poole? Kui vastus on jah, siis klaaslage ees ei ole ja suure tõenäosusega arenguhüpe õnnestub läbi viia. Kui vastus on ei, siis tuleb veel juhtkonnaga tööd teha niikaua, kuni see arusaam tekib ja klaaslagi saab purustatud.

Kui soovid ise rohkem teada saada protsessipõhisest juhtimisest, siis tule kuula minu 9.aprillil toimuvat veebiseminari! Registreeruda saad siin – https://kreetsolnask.podia.com/milles-seisneb-protsessipohine-juhtimine .

Oma ettevõtte äriprotsesside entusiastide koolitamiseks ja võimestamiseks on sobilik minu äriprotsesside kirjaoskuse koolitus –   https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

3.-5. küpsustasemest kirjutan juba järgmises blogipostituses! 😉

Mida annab meile teadlikkus oma äriprotsessidest?

15. märts 2024 / / 0 Comments

Käesoleva blogi kõige esimeses postituses kajastasin seda, miks on äriprotsesse vaja ja mida annab nende kaardistamine. Hetkel on tunne, et vahepeal möödunud 2 aasta jooksul on minu kogemustepagas mõnevõrra täienenud ning antud teemat oleks vaja värskete mõtetega uuesti käsitleda. Seega on antud blogipostituse fookuses taaskord seesama küsimus, et mida ikkagi annab meile teadlikkus oma äriprotsessidest?

Kindlasti olete erinevates valdkondades kohanud jäämäe analoogiat, milles jäämäe tipp visualiseerib seda kõige nähtavamat osa. Samal analoogial põhineva visualiseeringu tegin ka protsessipõhise juhtimise kohta. Tihti arvatakse, et protsessipõhine juhtimine võrdubki protsesside kaardistamisega.

Kuna protsessimudelid on selle tegevuse kõige tajutavam tulem, siis on isegi mõistetav, miks nii arvatakse. Samas ei ole mõistlik protsesse kunagi kaardistada lihtsalt selle tegevuse enda pärast! Peaks olema sügavam põhjus, miks seda tehakse. Ja needsamad sügavamad põhjused asuvadki nö “veepinna” all. Mida sügavamal need asuvad, seda vähem neid teadvustatakse.

Strateegiate elluviimine

Arusaam oma äriprotsessidest on tegelikult üks olulisemaid strateegiate ja eesmärkide elluviimise eeldusi! Minu silmis on äriprotsessid eesmärgist lähtuvalt disainitud teekonnad, mis aitavad jõuda punktist A punkti B. Need aitavad lahti mõtestada, KUIDAS oma eesmärkideni jõuda! Ja hästi disainitud protsessid teevad seda vägagi edukalt.

Näiteks võib mul olla isiklik eesmärk kasvatada käesoleva aasta lõpuks oma igakuist passiivset sissetulekut 500 eurole. Selleks panen paika strateegia, et teen seda enda veebikoolituste müümise kaudu. Selle eesmärgini jõudmiseks, panen enda jaoks paika ajaraami, mille jooksul seatud eesmärgi poole rühin. Ja ka tegevused, mis ma selle eesmärgi saavutamiseks tegema pean. Teisisõnu disainin endale äriprotsessi, mida sihikindlalt jälgima hakkan.

Tundub ju loogiline, eks? Aga mida ikkagi annavad siin protsessimudelid? Oletame, et pandud eesmärgi saavutamine läheb väga libedalt ja on näha, et turul on nõudlust minu veebikoolituste järele. Järgmine samm on veelgi suurema eesmärgi seadmine, mille ellu viimiseks ei piisa enam ühest inimesest. Olen jõudnud punkti, kus ma pean oma koolitusäri kasvatamiseks, võtma tööle täiendavaid inimesi. Ja vot sel hetkel, kui pead hakkama oma ülesandeid kellelegi delegeerima, on protsessimudel üks tänuväärne töövahend. Sa oled protsessimudeli näol dokumenteerinud kogu kvaliteetse teenuse loomise ja pakkumise protsessi ning see on väga hea materjal, mille abil uus inimene kiiresti “pardale” tuua.

Ettevõtte igapäevane juhtimine

Öeldakse, et head spetsialistid ei pruugi olla head juhid. Ometi ootame oma juhilt, et ta saaks aru meie igapäevastest tegevustest ja oskaks vajadusel nõu anda. Mina näen, et spetsialistist juhi tegemine ei olegi alati see kõige õigem lahendus. Vaja on vaid juhile piisavalt hästi selgeks teha, millega tema inimesed igapäevaselt tegelevad. Ja sellist arusaama aitavad jällegi väga hästi luua protsessimudelid. Need on justkui visuaalsed teekaardid, mis aitavad igapäevastes tegevustes orienteeruda ja annavad otsustamisel vajalikku taustainfot.

Ettevõtetes on tavapäraselt ikka sadu erinevaid äriprotsesse, mille kaasabil mingeid tooteid või teenuseid luuakse ja müüakse. Kogu selle “masinavärgi” hoomamine võib ühe korraliku kaardita olla paras väljakutse. Protsessimudelid tulevad siingi abiks. Oma protsesside visualiseerimine mudelina ning erinevate mudelite omavaheline linkimine annab sulle suunataju, sisuliselt GPSi, millega protsessiderägastikus õigesse kohta navigeerida.

Digitaalse transformatsiooni läbiviimine

Kui keegi mainib sõnapaari “digitaalne transformatsioon”, siis tavaliselt mõtleb ta selle all vajadust panna oma ettevõtte tehnoloogia (IT süsteemid, robotid, AI jne) kaasabil efektiivsemalt toimima. Minu eelnevalt toodud veebikoolituste näites võib digitaalne transformatsioon tähendada näiteks seda, et AI või spetsiaalsed IT lahendused aitavad mul veebikoolitusi kiiremini koostada.

Mida aga tihti ei tajuta on see, et enne tehnoloogia rakendamist on vaja väga hästi aru saada, kuhu ja mille hüvanguks seda rakendada on vaja. Siin tulevad taaskord mängu äriprotsessid, mille AS-IS (ehk olemasoleva) olukorra kaardistus annab ette pildi, kus on üldse mõttekas tehnoloogiat efektiivistamisel kasutada. Veebikoolituse näite puhul võiks AI kaasa aidata koolitusvideo automaatsel töötlemisel või koolituskava koostamisel. Ehk siis panen väga täpselt paika, millistes äriprotsessi sammudes ootan tehnoloogia tuge.

Seega kui mõne digitaalse transformatsiooni raames on plaanis äriprotsesse automatiseerida, siis see on esimene indikatsioon selle kohta, et kõigepealt on vaja AS-IS äriprotsesse kaardistada. Ja kindlasti on oluline määrata see fookus, kuhu tehnoloogiat rakendada plaanitakse.

Meeldiva töötajakogemuse kujundamine ja inimeste võimestamine

Oleme palju kuulnud kliendikogemusest aga mis on töötajakogemus?

“Töötaja vaatest on töötajakogemus lihtsalt reaalsus, mida nad kogevad organisatsioonis töötades. Töötajakogemuse moodustavad kõik kokkupuuted tööandjaga alates kandideerimise protsessist, kõigest, mis töökohal juhtub, kuni organisatsioonist lahkumiseni. Igal töötajal on individuaalne töötajakogemus.” (allikas – Brightera veebileht).

Kui kliendikogemuse vaatest on võtmetähtsusega kliendi teekond ehk protsess, mida ta teatud toote või teenuse tarbimiseks läbima peab, siis sama võiks kehtida ju ka töötajakogemuse puhul? Kindlasti on hea töötajakogemuse kujunemisel palju erinevaid tegureid aga mina näen, et üks võtmeteguritest on teadlikkus ja selgus ettevõtte äriprotsessides. Ilmselt meist kellelegi ei meeldiks töötada ettevõttes, kus eesmärgid ei saa täidetud, sest puudub kokkulepe, KUIDAS neid täita? Või sa pead igapäevaselt tegelema ainult ad-hoc “tulekahjude” kustutamisega?

Loen hetkel raamatut nimega “Äriilma mässulised”, mis kajastab väga mitmetes organisatsioonides läbiviidud vaatlusi ja nende pealt on näha, et tavapärased juhtimismudelid enam ei tööta! Ettevõtted peavad töötajate tööle meelitamiseks ja seal hoidmiseks üha enam panustama töötajakogemuse tõstmisele.

John Maxwell on kunagi öelnud “Juhid saavutavad suurepärasuse mitte lähtuvalt oma võimust, vaid võimekusest võimestada teisi“. Palju räägitakse sellest, et inimesi saab võimestada neid usaldades ja neile vastutust andes. Nagu juba eespool mainitud, siis võivad protsessimudelid olla väga head tööriistad vastutuse delegeerimisel. Samuti saab inimesi võimestada hästi disainitud nö inimkesksete protsesside kaudu. Näiteks võiksidki juhid delegeerida ainult eesmärke ning iga töötaja paneb sellest lähtuvalt paika enda töövoo, kuidas ta eesmärgid saavutab. Nii jõuame lõppkokkuvõttes inimkesksete protsessideni, mis oma olemuselt juba võimestavadki inimesi.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele käigus õpetan, kuidas häid äriprotsesse disainida –  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Minu õppetunnid äriprotsesside kaardistamise projektidest

9. veebr. 2024 / / 0 Comments

Eksimine on inimlik!Keegi meist ei ole täiuslik ja me kõik teeme vigu!

Sattusin hiljaaegu lugema ühte raamatut, milles tutvustati Jaapani kultuuriruumist tulenevat Hansei mõistet. Hansei tähendabki protsessi, mille käigus õpitakse oma vigadest, selleks et järgmisel korral parem olla. Hansei protsessi üheks võtmekomponendiks on tagasivaate koosolekud (hansei-kai), mille käigus analüüsitakse, mis läks hästi ja mis halvasti. Sellest raamatust inspireerituna mõtlesin kirjutada postituse vigadest, mida mina olen erinevates protsessikaardistuse projektides teinud. Ning muidugi ka sellest, mida ma nendest vigadest õppisin 🙂

Õppetunnid äriprotsesside kaardistamisest

1. õppetund

Kui sa õigel hetkel õigeid inimesi (seotud osapooli) ei kaasa, siis võib kõige halvemal juhul olla “rong juba läinud”. Iga äriprotsesside kaardistamise projekt on oma olemuselt ka muudatuste juhtimine ning õigel ajal õigete inimeste kaasamine on edu saavutamisel võtmetähtsusega!

Iga äriprotsesside kaardistamise ja optimeerimise projekt on samaaegselt ka muudatuste juhtimise projekt. Seega on oluline siin arvestada muudatuste juhtimise põhitõdedega. Üks kõige olulisem põhimõte on see, et muudatus peab kõigepealt toimuma isiklikul tasandil (loe täpsemalt siit) . Ehk siis protsessiga seotud inimesed peavad olema valmis ise muutuma ja neil peab olema valmisolek muudatusega kaasa minna.

Esimese asjana on sul vaja välja selgitada, keda ja millisel hetkel on vaja kaasata. Seega on vaja läbi viia seotud osapoolte ja nende huvide analüüs. Kel kohe huvi, siis saab siit inglise keeles selle kohta lugeda. Plaanin lähitulevikus selle kohta eraldi postituse ka teha. Nüüd selleks, et saada inimesed endaga “samasse paati”, on vaja nendega inimlikult suhelda, vajadusel neid toetada ja nõustada. Võimaluse korral praktiseeri näost näkku suhtlust!

Seotud osapoolte vähene kaasamine on probleemiks just suuremate/ keerulisemate äriprotsesside puhul. Mainitud protsessidel võib seotud osapooli olla nii palju, et silme eest läheb kirjuks. Sellistel puhkudel on alati kiusatus mõni vähemtähtis osapool välja jätta aga seda ei tasuks teha, sest just nemad võivad saada komistuskiviks hilisemas protsessi juurutamise etapis.

2. õppetund

Dokumentatsioon (juhendid, süsteemi kirjeldus, analüüsid, lepingud, seadusandlus vms) peegeldab teatud hetke seisu ning võib olla lugemise hetkeks vähemal või suuremal määral aegunud. Samuti on see alati kirjutatud teatud eesmärki või vaadet silmas pidades, mis ei pruugi kattuda sinule vajaliku vaatega. Seega on mõistlik alati selle sisusse kriitiliselt suhtuda ja see õigete inimestega üle valideerida.

Minu äriprotsesside kaardistamise töövoos on tavaliselt esimeseks sammuks olemasoleva dokumentatsiooniga tutvumine. Seda teen ma selleks, et saada paremat ülevaadet konkreetse ettevõtte ärispetsiifikast ning, et ennast paremini kaardistamise töötubadeks ette valmistada. Tegelikult on minul mainitud esimese sammuga seoses isegi mitu õppetundi:

  • Esimene on see, et tuleb alati silmas pidada, et lepingud on ikkagi eelkõige juriidilised konstruktsioonid ning päriselu ei pruugi alati lepingu järgi toimida. Mul oli kunagi üks kaardistuse projekt, milles kliendi töötajad ütlesid, et teevad oma tööd nii nagu lepingus on kirjas. Sai siis selle järgi ka esimesed protsessimudelid tehtud, kuni selgus, et tegelikkus oli natuke teistsugune.
  • Teine õppetund on see, et erinevaid analüüse/süsteemide kirjeldusi aluseks võttes, tuleb alati arvestada, et need ei ole peaagu kunagi ajakohased! Need on üldjuhul ajakohased ainult sel hetkel kui need valmivad.

Nimetatud õppetundidest võtsin kaasa selle, et ei tohiks eeldada, et lepingud kajastavad päriselu või et erinevatest dokumenditest saan kätte kõige ajakohasema info . Alati tuleb kõik kahtluse alla seada ja protsessiga seotud inimestega tekkinud küsimused üle täpsustada.

3. õppetund

Intervjuudel/töötubades jälgi põhimõtet, et küsitled eri valdkondade ja eri hierarhiatasemel olevaid inimesi eraldi.

See on teadmine, mida igale analüütikule koolipingis õpetatakse, aga seda ei taha keegi usukuda enne kui on ise kõrvetada saanud. Minul on olnud kogemus ühe rangelt hierarhiatasemeid jälgiva organisatsiooniga, kus proovisin pingelise ajagraafiku tõttu intervjuusid kombineerida. See päädis sellega, et intervjuudel kõik inimesed oma arvamust avaldada ei julgenud ning lõpuks pidin vajaliku info kättesaamiseks ikkagi veel täiendavaid intervjuusid tegema. Ehk siis vahel võib aja kokkuhoid olla lihtsalt näiline ja ei tasu minna lihtsama vastupanu teed!

Nimetatud õppetundi olen mina kogenud pigem hierarhiliste organisatsioonide juures. Samas võib see esineda vabalt ka vähem hierarhilises organisatsioonis. Määravaks saab see kui mugavalt ettevõtte inimesed end üksteise seltskonnas tunnevad.

4.õppetund

Ära eelda, et sinu protsessimudeleid ja/või kirjeldusi oskavad kõik lugeda! Mina olen õppinud, et iga äriprotsesside kaardistamise projekt on ühtlasi ka protsessidega seotud inimeste koolitamise projekt. Kui sa tahad, et keegi oskaks hiljem ka mudelisse modelleeritud tarkust kasutada, siis on vaja panustada inimeste koolitamisse.

Jällegi oleks lihtsam ja kiirem protsessimudelid valmis joonistada ning kliendile lihtsalt üle anda. Antud stsenaariumi lõpeb tavapäraselt sellega, et need mudelid leiavad oma koha kusagil “sahtlipõhjas” ja keegi neid aktiivselt kasutama ei hakka. Võibolla olete kuulnud Pareto prinsiibist, mis ütleb, et 20% panust toob 80% tulemusi? Vot siin ongi selle 20% panuse koht – protsessidega seotud inimeste koolitamine, annab tulemuseks selle, et nad oskavad hiljem mudelisse modelleeritud tarkust ka kasutada.

Mina vaatan igat äriprotsesside kaardistamise projekti teekonnana, mille käigus tekib teekonnale kaasatud inimestel arusaam oma rollist ja kuuluvusest ettevõtte ökosüsteemis. Nagu misiganes teekonnal, tuleb ka sellel ette komistuskivisid, millest midagi õppida. Ja seda ikka selleks, et järgmisest komistuskivist juba teadlikumalt mööduda.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele käigus jagan enda õppetunde erinevatest projektidest –  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Hetkel on samuti välja töötamisel koolitus targale tellijale, mille käigus mõtestatakse lahti vajalikud eelteadmised ja oskused IT projektide juhtimiseks ning õpetatakse, millisel tasemel ja detailsusega analüüsi võiks üks tark tellija ise osata teha. Kui tahad selle koolituse kohta rohkem infot, siis võta minuga julgelt ühendust!

Iga analüüsiprotsess on oma olemuselt agiilne

15. jaan. 2024 / / 0 Comments

Seekordset postitust tundub paslik alustada ühe väga tabava tsitaadiga:

“Analysis sounds like something that just kind of happens through staring at requirements long enough“

“Software Requirements Essentials” Karl wiegers, candase hokanson

See tsitaat on väga tabav ja kirjeldab minu arust üsna täpselt seda, kuidas analüüsi tegevust laiemalt mõistetakse. Teine väärarusaam on see, et analüüs koosnebki ainult intervjuude läbiviimisest ja nende põhjal memode kirjutamisest. Käesolevas postituses avan natuke analüüsi läbiviimise tööprotsessi ehk seda, millistest etappidest see koosneb ning millised on iga etapi tavapärased tegevused. Natuke teise nurga alt olen analüütiku tööprotsessist kirjutanud ka ühes oma varasemas blogipostituses.

Analüüsi läbiviimise tööprotsess

Tuvastamise etapp

Inglise keeles on sellel etapil palju kõnekam nimetus kui eestikeelne tuvastamine. Elicitation tähendab otsetõlkes esile tooma või välja meelitama ning tegelikult annavadki need tegusõnad väga hästi edasi seda mõtet, mida analüütik antud etapis tegema peab.

Seotud osapoolte peades on väga palju erinevate nõuete fragmente – näiteks mingi kindel visioon konkreetsest kasutajaliidese kuvast või konkreetsete andmete kirjeldused, mida neil vaja on või hoopis rahulolematus/probleemid oma praeguse süsteemi/tööprotsessiga. Sellised fragmendid ei ole tihtilugu ei struktureeritud ega ka terviklikud, mis tähendab, et nõuete formuleerimiseks peab analüütik nendega veel vaeva nägema.

Seega võiks öelda, et nõuete kogumine on ainult üks tegevus nõuete tuvastamise etapist. Lisaks kuuluvad sinna sellised tegevused nagu uurimine, avastamine ja leiutamine. Analüütik peab suutma väga erinevate töövõtete abil endale selgeks teha, millist probleemi lahendatakse ja milline võiks olla tellija jaoks rahuldustpakkuv lahendus. Lisan ka mõned enimkasutatavate meetodite märksõnad – dokumentide analüüs, protsesside kaardistamine ja analüüs, andmekaevandamine, kasutajaliideste analüüs, intervjuud ja fookusgrupid, kasutajate vaatlus, ajurünnak. Konkreetse meetodi valik sõltub sinu sihtrühmast, projekti ajakavast ja eelarvest, projekti arendusmeetoodikast jne.

Analüüsimise etapp

Nõuete tuvastamise etapis kogutud, avastatud ja välja uuritud info vajab nüüd süsteemset ja parimatest praktikatest lähtuvat korrastamist. Mida siis analüüsimise tegevus ikkagi endast kujutab? Analüüsimine on sisuliselt kogutud info klassifitseerimine, filtreerimine, sorteerimine, visualiseerimine ning info omavaheline võrdlemine. See annab analüütikule võimaluse kontrollida, et kogutud info on omavahel kooskõlas ja et tal ei ole midagi kahe silma vahele jäänud.

Analüüsimise etapi tulemina võivad tekkida nõuete kirjeldused, mis on kujutatud, kas tekstiliselt või mudeli kujul või hoopis prototüübina. Siinkohal tahan igaks juhuks üle rõhutada, et ei ole olemas ühte notatsiooni, mis kataks kõikide erinevate info esitamise viiside vajadused. Väga kummaline on vahel analüüsi tellinud osapoole nõuetest lugeda, et kõik mudelid peavad olema koostatud UML (Unified Modelling Language) notatsioonis. Samas kui äriprotsesside modelleerimiseks on soovituslik kasutada üldse BPMN-i (Business Process Management Notation) või andmevoogude visualiseerimiseks DFD-d (Data Flow Diagram).

Kogutud info analüüsimise abil kontrollib analüütik, kas kõikide seotud osapoolte vajadustega on arvestatud ning kas on olemas kokkulepe kõiki nõudeid rahuldava lahenduse osas. Eelmises lauses on üks olulisemaid sõnu “kokkulepe” – see eeldab, et misiganes esitlusviisil kirja pandud nõuded on ka tellijaga valideeritud ning saadud tema kinnitus.

Määratlemise etapp

Antud etapi vajalikkust annab edasi järgnev tsitaat:

“However, the cost of recording knowledge is small compared to the cost of acquiring that knowledge or reacquiring it in the future.”

“Software Requirements Essentials” Karl wiegers, candase hokanson

Väga levinud väärarusaam on see, et agiilses arenduses dokumenteeritakse võimalikult vähe ning dokumentatsiooni nõudmine on justkui vananenud praktika. Mina olen seisukohal, et dokumentatsioon on oluline kommunikatsioonivahend ning see kajastab mingi hetke seisu tellija ja arendaja vahelisest kokkuleppest. Ausalt öeldes ei ole minu pea küll prügikast, et suudan sinna kõik kokkulepped ja nüanssid salvestada ning hiljem neid väikse vaevaga meenutada. Mul on oma mälumahuga parematki teha, kui seda sellel eesmärgil kasutada.

Mõned soovitused spetsifikatsiooni kirjutamisel:

  • Lähtu nõuete kirjeldamisel samast stiilist ja detailsusastmest ning mõtle läbi, milline esitlusviis annab kõige paremini edasi nõude/nõuete olemust;
  • Organiseeri nõuded struktuurselt ja lugeja jaoks loogiliselt – loo endale nõuete kirjeldmise mallid, mida saad erinevates projektides taaskasutada;
  • Ära unusta välja selgitada ja kirjeldada ärireegleid (business rules);
  • Loo nõuete arusaadavuse suurendamiseks sõnastik.

Kinnitamise etapp

Nõuete kinnitamise etapis hinnatakse, kas kirjapandud nõuded tegelikult ka rahuldavad tellija vajadusi ning kas need aitavad kaasa äriliste eesmärkide saavutamisele. Selle etapi olulisust tihti alahinnatakse ning pingelises projektiplaanis on selle etapi ärajätmise ahvatlus suur. Mida ei mõisteta on see, et selles etapis vigade avastamine ja nende parandamine on mitmeid kordi odavam, kui mõnes hilisemas etapis.

Arendusmeeskonna liikmed saavad kontrollida nõudeid (verification) – st hinnata, kas midagi realiseeriti õigesti. Tellija meeskonna liikmed saavad kinnitada nõudeid (validation) – st hinnata, kas tehti üldse õiget asja. Mõlemad sammud on vajalikud ja nende läbiviimiseks on erinevaid võimalusi. Kontrollimiseks on väga efektiivne töövorm teise sama rolli kandva isiku poolt tehtud töö üle vaatamine (nn. peer-review, code-review jne). Kinnituse saamiseks on minu arust kõige sobivam meetod koos tellijaga kinnitamist vajavate nõuete läbikäimine ning selle raames tellija kinnituse küsimine. Kirja teel kinnituse küsimine võib päädida sellega, et sinu kirja ignoreeritakse või ei saada täpselt aru, millele kinnitust on vaja.

Kosemudeli stiilis analüüsi protsessi ei ole olemas!

Nagu postitusele lisatud protsessiskeemilt näha, siis saab analüüsi protsessis peaagu igast etapis liikuda tagasi eelmisesse etappi ning see on igasuguse analüüsi puhul täiesti normaalne töövoog. Räägitakse küll arendusprojektidest, mis järgivad kosemudelit (waterfall) aga isegi sellistes projektides ei ole võimalik kõiki detaile ette analüüsida. Kuna tellija teadlikkus ajas kasvab ja tema nõuded muutuvad, siis tuleb isegi väga detailselt ette defineeritud analüüsis kindlasti ette muutmisvajadusi.

Muutmisvajadused võivad selguda:

  • Kui analüütik on hakanud nõudeid analüüsima (st grupeerima, korrastama, võrdlema), siis võib tulla välja, et mingid nõuded on üldse kogumata ning peab minema tagasi nõuete tuvastamise etappi;
  • Kui nõuded on spetsifikatsioonina kirja pandud, võib selguda, et mingid nõuded on analüüsimata või kogumata ning peab minema tagasi, kas nõuete analüüsimise või tuvastamise etappi;
  • Kui toimub nõuete kontrollimine ja kinnitamine, võivad selguda asjaolud, mistõttu võib olla vajadus minna tagasi, kas nõuete tuvastamise, analüüsimise või määratlemise etappi.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele käigus õpetan täpsemalt, kuidas tööprotsesse kaardistada ja optimeerida –  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Hetkel on välja töötamisel ka koolitus targale tellijale, mille käigus mõtestatakse lahti vajalikud eelteadmised ja oskused IT projektide juhtimiseks ning õpetatakse, millisel tasemel ja detailsusega analüüsi võiks üks tark tellija ise osata teha. Kui tahad selle koolituse kohta rohkem kuulda, siis võta minuga julgelt ühendust!

Minu lõppeva aasta tähelepanekud tarkvaraarenduse projektidest

29. dets. 2023 / / 2 kommentaari

Seekordse postituse fookuses ei ole kitsalt äriprotsessid, vaid see kajastab laiemalt minu lõppeva aasta õppetunde ja tähelepankuid tarkvaraarenduse projektidest.

Käesoleva aasta lõpp tähistab minu jaoks mitme suure ja pikaajalise projekti lõppu ning tunnen, et on aeg tagasi vaadata ja panna kirja oma tähelepanekud. Etteruttavalt pean kurvastusega tõdema, et mõned tähelepanekud on täpselt samad, mis enam kui 10 aastat tagasi oma esimest tarkvaraarenduse projekti läbi viies.

Tähelepanek nr 1- Agiilsus ei tähenda planeerimatust ja lohakat tegutsemist

Agiilsus on tarkvaraarenduse projektides endiselt üks väga oluline mõiste. Iga tellija tahab oma tarkvara lasta arendada agiilselt, enamjaolt võrdsustatakse agiilsust paindlikkusega. Ometi ei mõisteta tihti, mis on selle mõiste taga ja seda kiputakse väärkasutama. Paljude arendusfirmade jaoks on see lihtsalt sõnakõlks, mida lisada oma pakkumusse lihtsalt sellepärast, et tellija tahab seda seal näha. Ja kui projekt pihta hakkab, siis ei ole agiilsest mõtteviisist ega arendusmetoodikast halli haisugi. Agiilsuse sildi taha peidetakse planeerimatust, lohakat ja läbimõtlematut tegutsemist ja kompetentsi puudumist. Väga hästi võtab minu tähelepanekuid kokku Merle Randleppa blogipostitus agiilsest mõtteviisist ja müütidest. Oma viimaste projektide kogemuste põhjal võin kinnitada, et müüdid nr 1, 4, 5 ja 6 on arendusprojektides väga visalt kanda kinnitanud.

Tähelepanek nr 2- Riigihankes kannatab paber kõike

Kui ma ise mõnda aega tagasi erasektoris töötasin ja erinevatele hangetele pakkumusi koostasin, siis ringlesid kuulujutud, et osad firmad “kirjutavad” oma pakutavale meeskonnale kompetentse, mida neil tegelikult ei ole. Tookord ei võtnud ma seda kuigi tõsiselt ja mõtlesin, et see on lihtsalt kuulujutt või liialdus…kuni tänaseni. Olles ise olnud taas tellija poolel, olen kahjuks pidanud korduvalt tõdema, et seda siiski tehakse ja isegi väga nahhaalselt. Olen korduvalt näinud, et arendusfirma meeskonna rollidel ei ole olnud küsitud rollile kohaseid elementaarseid baasoskuseid ja/või kogemusi. Ometi on tellija justnimelt selle ettevõte kasuks otsustanud heas usu, et tal on vajalik kompetents olemas. Pakkumustesse kirjutatakse tõepoolest kokku igasugust mulli – peaasi, et klient uskuma jääb.

Tähelepanek nr 3- Testimine on osa korralikust arendusmetoodikast

Siinkohal on paslik tuua näide viimasest “agiilsest” arendusprojektist. Arendusfirma väitis, et spetsifikatsiooni loomine enne arendust ei ole agiilse arendusmetoodika osa ja nemad seda ei tee. See oli minu jaoks väga kummaline väide, kuna esiteks on nõuete fikseerimine spetsifikatsiooni kujul kokkulepe tellijaga, mille põhjal toimub hiljem ka testimine ning tööde vastuvõtmine. Samuti meenus mulle ülikoolist õpitud V-mudel, mille järgi on spetsifikatsioon üks-ühele seotud erinevate testimise liikidega.

Ma üritasin pihta saada loogikale, kuidas toimub testimine kui spetsifikatsiooni ei looda. Ja ma ei pidanud kaua pead murdma kui selgus, et meeskonda pakutud testijal ei olnud õrna aimugi minu viidatud seosest. Muuhulgas laekusid esimeste etappide tarned meieni täiesti testimata. Hoolimata sellest, et testimine võiks olla iga endast lugupidava arendusfirma kvaliteedi tagamise protsessi osa, pidime seda edaspidi neile pidevalt meelde tuletama.

Tähelepanek nr 4 – Äriprotsessidest arusaamine on suure pildi mõistmisel väga oluline

Selleks, et arendada kliendile head lahendust, peab kõigepealt mõistma, kuidas ta toimetab (AS-IS tööprotsessid) ning millised on tema praegustes töövoogudes valupunktid (selle info pinnalt disainitakse TO-BE tööprotsessid). Sellise infota ei ole võimalik mõista suurt pilti ning luua lahendust, mida klient päriselt vajab. Jällegi oli minu hämmastus suur kui arendusfirma pakkus meeskonda analüütikut, kes ei suuda aru saada äriprotsessidest (rääkimata oskusest neid kaardistada ja optimeerida) ning mõista kasutuslugude olulisusest tellija ärireeglite ja nõuete talletamisel.

Teine suur komistuskivi, millest ma ei väsi rääkimast ja mida korduvalt tehakse, on AS-IS tööprotsesside kohene automatiseerimine. See on kõige suurem karuteene, mida võib ühe infosüsteemi arendamisel teha. Enne tööprotsessi automatiseerimist tuleb AS-IS tööprotsess disainida võimalikult mõistlikuks. Sellest olen pikemalt kirjutanud eraldi blogipostituses.

Tähelepanek nr 5 – Spetsifikatsioon on kommunikatsioonivahend, mitte tüütu kohustus

Minu kui analüütiku jaoks, on olnud tarkvaraarenduse projektides üks tulemuslikumaid tööriistu hästi arusaadav spetsifikatsioon. Sellele küsin alati tellija kinnitust, et ta tõesti soovib sellist lahendust nagu spetsifikatsioonis kirjas. Selline töökorraldus maandab analüütiku jaoks nii mõnegi riski – näiteks selle, et tellija väidab, et ta ei ole olnud teadlik meie kokkuleppest. Või selle, et arendaja hakkab ise leiutama, mida kliendil võiks vaja minna (või veel hullem kuidas võimalikult lihtsalt antud arendusülesanne kaelast ära saada).

Viimaste projektide käigus olen märganud, et tihti analüütikud sellist töövõtet ei kasuta ja selle läbi projekti riske ei enneta. See päädib alati sellega, et arendamisel tehakse teatud eelduseid, millest klient ei tea midagi ning mille üle hakatakse hiljem vaidlema. Sellistes olukordades olen tihti tabanud ennast mõttelt, et palju aja- ja ressursisäästlikum on kohe alguses teha natuke rohkem ja korralikumalt tööd kui hiljem hakata vaidlema ning asju ringi tegema. Analüütiku tegevustest ja tööprotsessides olen samuti kirjutanud eraldi blogipostituse.

Tähelepanek nr 6 – Tuleb mõista ja austada projekti raame ja piiranguid

Olen korduvalt näinud, kuidas riigihangete projektides (kus teatavasti on alati fikseeritud eelarve ja ajaraam ning tihti ka fikseeritud skoop) hakatakse arendama “agiilselt”. See tähendab ilma igasuguse plaanita, kuidas oleks võimalik jõuda projekti oodatava tulemini. Sellise lähenemise lõpplahendus on, et arendusfirma kulutab ära tunnid ja raha ning klient ei saa sellist tulemit, mida ta vajab.

Siinkohal peaks tuhka pähe raputama nii kliendile kui ka arendusfirmale. Klient ei saa küsida arendusfirmalt ebamõistlikku skoopi. Klient peaks suutma ise ära teha ärianalüüsi, et mõista väga täpselt, mida ta hankima läheb ja mis on reaalne ettenähtud eelarve raames ära teha. Teiselt poolt hämmastab mind alati arendusfirmade naiivsus fikseeritud eelarve, ajaraami ja skoobiga projekti arendada agiilselt. See ei ole ju kuidagi võimalik! Seda sellepärast, et kliendil on peaagu alati rahastusallikaga seotud kohustus projekt teatud ajaraamis, teatud eelarve ning lubatud skoobiga ära teha. Ja kuna kõikidest piiravatest faktoritest on kõik fiskeeritud, siis ei ole ju millegi arvelt võimalik agiilselt arendada.

Tähelepanek nr 7 – Rolliselgus on oluline

Rolliselgus ei ole oluline kitsalt tarkvara arenduses vaid igas ettevõttes/asutuses, mille eesmärk on võimalikult efektiivselt toimetada ning tagada oma töötajatele arusaam nende ülesannetest. Kuna tarkvaraarenduse projektid on tavaliselt väga ajakriitilised, siis on ükskõik millise arendusmetoodika eeldus, et täpselt oleks kokku lepitud rollid ning nende vastutused. Mida ma sellega mõtlen? Ikka seda, et arendusmeeskonnas teaks näiteks projektijuht, millised on tema ülesanded selleks, et projektis suhtlus toimiks (nii meeskonna sees kui ka kliendiga), tööd saaks nõuetekohaselt ja õigeaegselt tehtud, projekti riskid oleksid ennetatud ja maandatud ning meeskond oleks juhitud. Kui millegipärast ei ole arendusmeeskonnas ette nähtud projektijuhi rolli, siis peab olema selge, milline muu roll katab neid tavapäraseid projektijuhtimise ülesanded. See oli üks näide projektijuhi vastutusest aga sama loogika kehtib iga misiganes arendusmeeskonna rolli kohta.

Rolliselguseta ei ole võimalik üles ehitada toimivat koostööd nii arendusmeeskonna sees kui ka kliendiga ning tekivad “hallid vastutused”, mis on projekti/töö õnnestumiseks olulised aga mille osas keegi vastutust ei võta.

Minu soov uueks aastaks oleks see, et arendusfirmad päriselt ka läbi mõtestaks, kas ja kuidas nad oma tegevusega kliendile väärtust pakkuvad. Siinkohal on märksõnad – soov klienti mõista ning leida talle kontekstist lähtuvalt parim lahendus, läbitöötatud ja toimivate metoodikate kasutamine, rolliselgus arendusmeeskonnas.

Selleks, et tellijad oskaksid paremini oma vajadusi kirja panna ning osata seista oma õiguste eest, olen välja töötamas uut targale tellijale suunatud koolitust. Täpsemalt aga sellest juba uuel aastal 🙂 !

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

Andmete ja andmekvaliteedi roll tööprotsessides

21. dets. 2023 / / 0 Comments

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

11. dets. 2023 / / 1 Comment

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!

Äriprotsesside optimeerimise tööprotsess
Äriprotsessi tõhustamise tööprotsess

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

12. nov. 2023 / / 1 Comment

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.

AS-IS äriprotsessi kaardistamise tööprotsess

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?

5. sept. 2023 / / 1 Comment

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?

7. aug. 2023 / / 0 Comments

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!

« Older posts

© 2024 Äriprotsesside tuvastamine, tõhustamine ja haldamine

Theme by Anders Noren — Up ↑