Miks on hea, kui keegi kirjeldab Sinu eest ärinõuded?

Kas olete tundnud, et tarkvaras oleks vaja ühte suurt punast nuppu, mida vajutades saavad kõik maailma mured lahendatud? Tegemist on täiesti normaalse olukorraga, kuid kahjuks päriselu nii lihtne ei ole. Infosüsteemide maailmas tuleb kõigepealt kirjeldada, mis on selle punase nupu taga. See tingib omakorda töökorralduse ehk äriprotsesside ja ärinõuete kirjeldamise. Loodud kirjeldus on ettevõttele või teenusepakkujast arendajale sisendiks, mida temalt esimese hooga tahetakse, kirjutab Columbus Eesti digitaliseerimise ekspert Marko Seier.

Kuid kes peaks seda tegema?

Tavaliselt on keskmisega suurusega ettevõttes, kus on üks peamiselt IT-abiga tegelev töötaja, keeruline leida aega protsesside kirjeldamiseks. Loomulikult leitakse soovi korral keegi hakkaja töötaja, kes kirjutab vajadused kokku ja saadab need infosüsteemide arendajale. Kuid keeruliseks läheb siis, kui arendaja vaatab nõudeid ja 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 poolt 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.

Lugu on ilmunud ka tööstusuudised.ee digitaliseerimise teemaveebis.