Mis on ärianalüüs ja miks seda vaja on?

Kui eesti keeles öelda sõna ärianalüüs, siis erinevatel inimestel tulevad seda kuuldes pähe erinevad teemad. Kui nüüd inglise keel appi võtta, siis on olemas ärianalüüs ehk siis „Business analysis“, mis tegeleb protsesside kaardistamisega ja ärivajaduste väljaselgitamisega. Lisaks on ka olemas ärianalüüs ehk siis „Business intelligence“, mis tegeleb analüütikaga, numbrite analüüsimisega ja sellest järelduste tegemisega. Siin artiklis ja ka üldiselt sellel lehel räägime me ennekõike sellest esimesest.

Just see segadus analüüsi ja analüütika vahel ongi üks põhjustest, miks mul tekkis tahtmine sellest teemast kirjutada. Teine põhjus on see, et tegelikult olen ma oma karjääri jooksul väga vähe kokku puutunud korraliku ärianalüüsiga. Midagi küll tehakse, aga tavaliselt ilma täpsema arusaamata, mida tegelikult on vaja kaardistada ning ennekõike on eesmärgiks kirjeldada infosüsteemi. Ärianalüüs aga ei tähenda üldse seda, et lõpptulemuseks peab olema infosüsteem. Otse vastupidi, tulemuseks võib olla arusaam, et muuta saab protsesse ja ei ole vaja lisa tarkvara juurde hankida.

Mis on ärianalüüs?

Mis siis aga see ärianalüüs e. „Business analysis“ ikka on? Lühida kirjelduse leiab ka siitsamast ITBAC enda lehelt artiklist Mis on IT- ja ärianalüüs? ja sealt kokkuvõtet tehes on ärianalüüs organisatsiooni muudatuste teostamiseks vajaduste uurimine ja kaardistamine. Seal artiklis on ka ära toodud kaks eri rolli: Ärikonsultant ja Ärianalüütik, kellest esimene kaardistab organisatsiooni üldised vajadused ja muudatuskohad ning teine kaardistab siis juba täpsemalt muudatusega seotud protsesse. Mõlemad need rollid teevad ärianalüüsi, ärikonsultant teeb seda lihtsalt natuke kõrgemal ja üldisemal tasemel kui ärianalüütik.

Ärikonsultandi tehtavat ärianalüüsi me väga põhjalikult ei kirjelda. Kui väga kokkuvõtlikult sellest rääkida, siis nad istuvad koos organisatsiooni juhtidega maha ja aitavad paika panna üldise visiooni ja eesmärgi. Nad kaardistavad erinevaid siseseid ja väliseid mõjutajaid ja leiavad valupunkte ning riskikohti. Selle töö tulemusena pannakse paika edasised eesmärgid ja mõõdikud (inglise keeles KPI – Key Performance Indicators) ning need omakorda võivad olla algatajaks muudatustele.

ITBAC-i põhiline fookus on just ärianalüütiku poolt tehtaval ärianalüüsil. See saab alguse siis kui on teada muudatuse vajadus ja on vaja hakata uurima sellega seotud protsesse ning kuidas seda muudatust realiseerida. Näiteks muudatusvajadused võivad olla järgmised:

• Meie veebipoe müüginumbrid on väga madalad, meil on vaja tõsta veebipoe kaudu tehtavate müükide numbrit.
• Kliendid ei ole rahul, et tagasiside saamise protsess on väga aeglane ja nad pöörduvad konkurentide poole. Tagasiside andmise protsessi peab parendama.
• Seadused muutusid ja firma praegused protsessid ei kata neid muudatusi ära. Protsessid ja tarkvarad tuleb üle vaadata ja kirjeldada ära kohad, mis vajavad muutmist.

Ärianalüütik võtab talle antud probleemi kirjelduse, hakkab seda süstemaatiliselt lahkama ning peale leidude dokumenteerimist saab ka pakkuda välja lahendusvariante.

Ärianalüüsi ei saa alati teha kindlate sammudega, mõne probleemi puhul on vaja teha asju, mida teiste probleemide puhul ei ole vaja teha, aga on mõned üldised tegevused, mis on vajalikud suuremal osal juhtudest:

• Osapoolte kaardistamine (firma sisesed, firma välised jne.)
• Hetke olukorra kirjeldamine (protsessidiagrammid, nõuded jm.)
• Välja pakutud lahendus ja oodatud tulemused (protsessidiagrammid, nõuded jm.)
• Muudatuse väärtuse mõõtmine

Oluline on ära mainida, et välja pakutud lahendus ei saa olla põhjalik IT süsteemi kirjeldus. Ärianalüütiku töö tulemuseks võib olla kirjeldus, et on vaja veebipoodi ja veebipoes peab olema võimalik tooteid ostukorvi panna, aga täpsemalt see IT süsteemi kirjeldada ei tohi. Näiteks järgnev tekst ei ole väga hea ärianalüüsi tulemus:

“Kui kasutaja avab meie veebipoe, siis näidatakse seal toodete nimekirja piltidega. Kui toote pildi peale klikkida, siis avaneb toote leht ja seal saab kasutaja vajutada nuppu toote ostukorvi panemiseks.” 

Miks on selline kirjeldus halb (kui jätta kõrvale sõnastus, pealiskaudus jne.)? Sest see on täpne lahenduse kirjeldus inimese poolt, kes ei oma põhjalikke teadmisi kasutatavatest tehnoloogiatest ja nende võimalustest. Näiteks kui juba eelnevat näidet vaadata, siis ei ole tegelikult mingit vajadust avada toote lehte selleks, et toodet ostukorvi lisada, aga kui keegi on harjunud just nii poodlema, siis see on esimene lahendus, mis talle pähe tuleb.

Kui nüüd eelnev jutt kokku võtta, siis ärianalüütik alustab oma tööd muutmisvajadusest ja kirjeldab ära sellega seotud osapooled, protsessid ning muu vajaliku. Kui hetke olukord on piisava täpsusega ära kirjeldatud, siis on võimalik selle põhjal kirjeldada nõudmised lahendusele, kuidas see lahendus võiks toimida ning mis on selle lahenduse tulemusel ettevõtte jaoks lisanduv väärtus. Nende teadmiste pealt on võimalik IT analüütikul hakata disainima IT lahendust, muidugi kui see osutub vajalikuks.

Miks on ärianalüüsi vaja?

Miks on ärianalüüsi vaja? Lihtne viis sellele küsimusele vastust leida on küsida endalt, kas sa tahaksid kasutada süsteemi, või olla osaline tarkvara arenduse protsessis, kus kõiki osapooli pole kaasatud ja vajadused pole selged? Kui enne pole ärianalüüsi tehtud (mõistlikus koguses siiski, ma ei räägi siin pikast Waterfall metoodika ärianalüüsi protsessist) ja hakatakse ehitama IT lahendust, siis kõige tõenäolisem tulemus on see, et uute osapoolte ja vajaduste selgumisel projekti skoop muutub ning sellega koos ka projekti maksumus ja valmimise aeg. Halvimal juhul jääb projekt üldse pooleli ning suure hulga töö ja rahakulu peale ei ole tulemuseks midagi näidata.

Teine oluline põhjus, miks ärianalüüsi on vaja, on selleks et teada saada mis on soovitud muudatuse väärtus. Kas see mõjutab oluliselt ettevõtte protsesse säästes aega ja raha või kas see tõstab märgatavalt klientide rahulolu? Kui neid asju ei tea, siis võib juhtuda, et tehakse tarkvara, mida ei ole vaja ning peale aja ja raha kulutamist ei võeta valminud lahendust kasutusele. Põhjuseid võib olla küll erinevaid, kuid eelnev ärianalüüs ja muudatuse väärtuse kindlakstegemine aitab selliseid olukordi vältida.

Elu on näidanud, et kõikide projektide puhul selgub tegemise käigus ootamatuid asjaolusid, olenemata sellest kui hästi on eeltööd tehtud. Oluline on see kui palju neid ootamatusi tekib. Ükskõik mis arendusmeetodeid kasutatakse, iga töö käigus leitud ja juurde lisatav funktsionaalsus maksab, kas ajas ja rahas või teiste funktsionaalsuste arvelt. Kui enne süsteemi arendust teha korralik ärianalüüs, on võimalik vähendada juurde lisanduvaid asju ja seega ka projektile kuluvat aega ning raha. Ja muidugi on tulemuseks ka parem IT süsteem.