Miks on vaja protsesse modelleerida?

Kumb juhend on arusaadavam, kas A või B?

A. Kui sul kõht tühjaks läheb siis tuleb minna poodi (või jahile, aga poest saab kiiremini). Kui oled poodi kohale jõudnud, siis pead meeles pidama, et Selveris tuleb see skännerijubin võtta enne poodi sisenemist, sest kaubad tuleb kohe peale riiulilt võtmist skannerida. Rimis jällegi on vastupidi, saad kohe kaubad võtta ja skanneerid pärast iseteeninduskassas. Samal ajal on mõned olulised ja väga kasulikud reeglid, mida ei tohi unustada. Üks on see, et ära osta kõige odavamat vorsti, sest see koosneb jahust ja kondipurust. Teine, veel olulisem reegel on, et kui ostad omale õlut, siis osta ka naisele mingi meeldiv asi. Nüüd, kui hakkad poest lahkuma, siis ära unusta kauba eest maksta! Kui oled sattnud Rimisse, pead kõik kaubad ükshaaval skanneerima. Selveris on vaja ainult maksta, kuna eelnevalt oled loodetavasti kõik juba skannerinud. Kõik, võid minna koju mugima.

B. 

Selleks ongi vaja protsesse modelleerida. Sest 1 pilt on selgem kui 1000 sõna.

Teeme 1000 protsessi korraga!

Eelmine nädal korraldasime ISO Klubiga seminari EMTA-s, so siis kõigi eestimaalaste poolt palavalt armastatud Maksu- ja Tolliamet. Teemaks oli protsessijuhtimise arendamine EMTA-s. Kahjuks peab tõdema, et maksuamet on oma protsessijuhtimise väga edukalt käima pannud ja maksude maksmisest ilmselt pääsu pole ;)

Mida õpetlikku kõrva taha panin?

* Ära kirjuta kokku sadu protsesse. Sa ei jõua neid iialgi hallata. Tee parem umbes 4-5 peamist, kogu ettevõtet läbivat põhiprotsessi ja nende alla max 35 alamprotsessi. Vajadusel koosta alamprotsesse täpsustavad juhendid.
* Kaasa protsessjuhtimise juurutamise projekti kohe alguses tippjuhtkond. Kui tippjuhte asi ei huvita, ei huvita see lõppkokkuvõttes mitte kedagi. Protsessijuhtimise juurutamine on aga nii karm muudatus funktsionaalsete juhtide jaoks, et sõda tuleb nagunii.
* Kasuta mugavaid ja tasuta töövahendeid. Näiteks Wiki (dokumentide haldamiseks) või BizAgi (protsesside kaardistamiseks). Tasuta asjad ja töötavad.

Ühesõnaga, oli palju äratundmisrõõmu samadest "ämbritest" :) Isegi neisse astutud.
Muuseas, EMTA sai s2010.a  Eesti Kvaliteediühingult protsessijuhtimise arendamise eest "Aasta Kvaliteedi Teo" auhinna! See auhind antakse organisatsioonile, kes on teinud kõige vägevama arenduse kvaliteedijuhtimise vallas. Kuna ma ise olin ka juhusulikult žüriis, siis sain nüüd kinnituse, et EMTA esikohale asetaimine läks igati asja ette.

Kes on veel väledam kui jänes?!

Gepard? Bolt?
Tegelikult tuleb välja, et tänapäeval on isegi Boltist väledam hoopis tarkvara arenduse metoodika. Täna korraldasime ISO Klubis seminari, kus Alek Kozlov Skypest tegi huvilistele vahva ülevaate agiilsete praktikate rakendamisest tarkvara arendamisel.

Kokkuvõttes oli sõnum see, et kiiresti muutuvas keskkonnas tuleb oma toodet või tarkvara arendada sarnaselt, nagu juhitakse roolijaga suurt sõudepaati. Kahksamehelise paadi sõit käib nii, et 8 sõudjat uhavad ja samal ajal 1 roolija annab sõudjatele regulaarselt infot vajaliku tõmebsageduse ja tempo kohta. Ning pidevalt korrigeerib paadi suunda. Kui roolija seda ei teeks, uhaks paat kaldasse või kaotaks vajaliku tempo. Pildil on küll ainult 4 sõudjat, aga mõte jääb samaks :)

Täpselt sama moodi käib agiilne arendusprotsess.Muutuvas keskkonnas ei tööta enam vana hea, kõigile pähe taotud, deterministlik protsessijuhtimise mudel: sisend sisse-->protsess sulla-mulla-->ja väljund välja.

Sellele mudelile on vaja juurde kahte asja:
a) mingit tööriista, mis regulaarselt jälgib, kas protsess läheb õigesti (paadi suuna jälgimine ja korrigeerimine)
b) ning pidevat tagasisidet ehk seiret (roolija juhised sõudjatele).

Paatkond peab suutma olukorda kogu aeg kontrollida ja vajadusel muutuva olukorraga kohanduda. Muidu pole head nahka loota. Ehk siis: kui tegutsete kiiresti muutuvas keskkonnas, unustage deterministlik, staatiline mudel ja kasutage empiirilist protsesside juhtimise mudelit (roolija on ka paadis).

Päris elus on asjad tihti paraku keerulisemad. Pidevalt tuleb teha arendavas tootes vajadusel (väikeseid) muudatusi, ITIL keeles peab hästi töötama change mgm. Skype näide oli see, et kui vanasti tehti tootes keskmiselt 1 muudatus aastas, siis peale agiilse praktika/metoodika rakendamist tehakse seda 7 korda aastas. Kohandumine!

Väga tihti ei saa tellija arendajalt seda, mida ta ootas. "See pole ju üldse see, mida ma soovisin!" Mille peale tarkvara arendaja vastab: "Ise oled süüdi, lähteülesanne oligi selline, /loll/!" Ja siis edasi suheldakse advokaatide vahendusel :) Väga tuttav stsenaarium ilmselt paljudele. Nali on selles, et tegelikult ei olegi tarkvara tellijal kohe võimalik teha ideaalset lähteülesannet. Välistatud. Midagi läheb ikka metsa. Tuleb koos arendajaga edasi minna step-by step, alguses ehitada süsteemi kontuurid, siis kest ja lõpuks värv. Nii on lihtsam (ja odavam!) käigu pealt asju korrigeerida. Lihtne.

Mulle tekkis endal paralleel, kuidas me ise püüame arendada Soovitusindeksi teenust. Teeme jupi kaupa, uurime klientidelt tagasisidet ja vastavalt sellele siis liigume edasi. Ja see töötab. Vale oleks olnud kohe püüda ehitada super-hüper monstrum valmis ja siis turule minna. Tundub, et oleme olnud poolkogemata agiilse metoodika kasutajad. Ei,siiski väledad, see on lahedam sõna :)