ITSPEA nr 11: Arendus- ja ärimudel projekti X näitel.

Arendus- ja ärimudelite nädala ülesandeks oli analüüsida üht arendus- ning üht ärimudelit konkreetse näite baasil. Olen kokku puutunud agiilse arendusmeetodi rakendamisega projekti läbiviimisel ning kuigi projekt sisaldas konfidentsiaalseid osapooli, saan siiski kirjeldada protsessi osapoolte nimesid täpsustamata, mis annab piisava ülevaate agiilse mudeli rakendamisest, kuna üldjoontes see ei erinenud tavapärasest praktikast.

Projekt X: Välise teenusepakkuja (vendor'i) vahetamine.

Osapooled: Ettevõte A, vendor B, vendor C.

Eesmärk: Lihtsustada ettevõttesiseseid protsesse, suurendada kuluefektiivsust ning parandada üldist kliendikogemust läbi välise teenusepakkuja vahetamise, mis sobitub ettevõtte A pakutava teenusega paremini.

Arendusmudel: Agiilne.

Ärimudel: SaaS (tarkvara kui teenus).

Kuna tegemist on spetsiifilise valdkonnaga ning ettevõtte A pakutava teenuse haldamine käis läbi vendori B platvormi, mida omakorda haldavad ettevõtte A osakonnad, mis jaotuvad erinevate riikide vahel (maatriksorganisatsioon), oli tegemist teatava kõrgema keerukusastmega projektiga. Protsesse, mida see projekt mõjutas, oli kümneid ning detaile tõenäoliselt tuhandeid, mis oli üks argumente kasutamaks agiilset lähenemist.

Projekti algfaasis kaardistati olemasolev töömudel ning projekteeriti ka tulevane mudel, mille baasil sai kirjeldada ärikriitilised, keskmise olulisusega ning vähemolulised projekti mõjutavad tegurid. Selle põhjal loodi esmane ülesannete (sprintide) baas. Kuigi mina olin äripoolel ega oma detailset ülevaadet arenduse protsessidest, tean niipalju, et kasutati sprinte, millede pikkus olenevalt sprindi keerukusest varieerus 1-3 nädala ringis. Sprintidega paralleelselt toimusid regulaarsed koosolekud, kus arenduspool kogus lisadetaile äripoolelt ning äri sai omakorda anda tagasisidet nendepoolt läbiviidud testimistele.

Tol hetkel ma arendusmudelite teeoriaga erilist kokkupuudet ei omanud, kuid kui üldiselt nimetati töö koordineerijat projektijuhiks, siis tagantjärgi vaadates oli tema ametinimetus Scrum Master, justnagu agiilsele Scrum-meetodile kohane. Agiilse meetodi üldtuntud riskikohtadele kohaselt erines eeldatav suur pilt mõningal määral tegelikkusest, mis tähendas ka ootamatusi projekti eri faasides. Teisalt, kuna vahetu suhtlus arenduse ja äripoole vahel käis pidevalt, oli nende lahendamine efektiivne ega tekitanud pikaajalisi katkestusi.

Kuna tegemist on lähiturgudel küllaltki levinud teenusega, mille turg Eestis on pigem väike, pakutakse teenust kasutades nearshoring'ut. Ärimudeli mõistes on tegemist SaaS-mudelil baseeruva teenusega, mida ettevõte A ostab vendor'ilt selleks, et oma klientidele pakutavat teenust hallata. Peamine kasutegur ostetavalt teenuselt ettevõtte A jaoks on siseste protsessidega kaasnevate tegevuste automatiseerimine läbi klientidele pakutava teenuse koondumise ühisele platvormile, mida pakub vendor ning kasutab ettevõte A. Kogu projekti vältel oli mõju välistele klientidele minimaalne, eelkõige väljendus see erinevate raportite disaini muutuses.