15. veebruar 2018

Tähelepanu! Artikkel on enam kui 5 aastat vana ning kuulub väljaande digitaalsesse arhiivi. Väljaanne ei uuenda ega kaasajasta arhiveeritud sisu, mistõttu võib olla vajalik kaasaegsete allikatega tutvumine.

Infosüsteemide maailmas tuleb kõigepealt kirjeldada, mis on selle punase nupu taga. Selleks tuleb kirjeldada töökorraldust ehk äriprotsesse ja -nõudeid. Loodud kirjeldus on ettevõttele või teenusepakkujast arendajale sisendiks, mida temalt esimese hooga tahetakse.

Kes peaks seda tegema?

Tavaliselt on keskmise suurusega ettevõttes, kus on üks peamiselt IT-abiga tegelev töötaja, keeruline leida aega protsesside kirjeldamiseks. Loomulikult leitakse soovi korral keegi hakkaja, kes kirjutab vajadused kokku ja saadab need infosüsteemide arendajale. Keeruliseks läheb siis, kui arendaja ei saa kirjapandust aru. Heal juhul hakatakse täpsustama, aga halvemal juhul loobutakse pakkumise tegemisest. Veel halvemal juhul luuakse vale lahendus, millele kulutatakse raha, aga mis tulu ei too. Ja see omakorda jätab mulje, et IT ongi kasutu kuluartikkel.

Kuidas sellist olukorda vältida?

Üks lahendus on lasta teha nii ärianalüüs kui ka nõuete kirjeldus kogenud välisel osapoolel. Mis on selle lahenduse head küljed:

Teadmised – äriprotsesside kirjeldaja teab, kuidas kasutada tunnustatud protsesside kirjeldamise keeli nagu BPMN ja UML. Tunnustatud keelte kasutamine aitab arendajatel nõuetest ühtmoodi aru saada;Kogemus – väline osapool võib küsida esmapilgul rumalaid küsimusi, mis hiljem võivad osutuda õigeteks küsimusteks;Väline pilk – haakub mõneti eelmisega. Väline pilk võib märgata mitmeid ebaefektiivseid aspekte, millega ise juba harjutud ollakse, ja luua sisendeid mitmetele parandusettepanekutele;Ärikasu hindamine – väline hindaja oskab kogemuse pealt tuua välja võimalikku ärikasu erinevate ärinõuete osas

Loomulikult on väljast tellitud kirjeldamisel ka omad puudused:

Ei pruugi lõpuni äri tunda – selle vastu aitab kirjeldamise kogemus. Samuti saab võtta aluseks tunnustatud protsessiraamistikke nagu SCOR ja ITIL;Erinevad arendajad loevad erinevat infot välja – seda riski aitab leevendada üldtunnustatud kirjelduskeelte kasutamine;Tehakse liiga palju või liiga vähe – kirjeldatakse kas liiga agaralt ülima detailsuseni või siis liiga vähe. Esimene variant on mõnevõrra parem, kuid selle võrra on töö kallim ja ajamahukam, sest minnakse juba detailsete tarkvaranõuete kirjeldamise faasi. Teisel juhul ei pruugi hiljem tööga midagi peale hakata.

Korrektse analüüsi ja õigete ärinõuete baasil juurutatud tarkvara teenib ettevõtte huve. Kui protsesse ei kaardista, siis ka kindlasti kuhugile jõutakse, kuid kas just soovitud kohta?

Igal juhul on soovitav enne it-lahenduste juurutamist protsessid kaardistada ja nõuded kirjeldada.

Lisaks on veel omaette arutelu koht, kas kirjeldada protsesside hetkeseis (as-is) või keskenduda kohe tulevase protsessikirjelduse loomiseks (to-be). Aga sellest juba tulevikus.

Autor: Marko Seier, Columbus Eesti digitaliseerimise ekspert