Allikas: Äri-IT Sügis 2024
Autorid: Margit Roosnurm, BCS Itera CRMi konsultant ja Külli Rebane, BCS Itera ärijuht
Projekti edukus sõltub selgetest rollidest ja vastutustest.
Veidi vanematele võib meenutada multikat „Kolm sõpra Prostokvašinost“, kus perepoeg kirjutas emale ja isale kirja, aga kuhu kass ja koer oma osa lisasid. Sellest tekkis vanematele omajagu segadust ja ehmatust – poja käpad valutasid ja saba nagu polekski, lisaks hakkas pojal pihta ka karvavahetus. Nii võib juhtuda ka siis, kui palju inimesi ilma arhitektita projekti teevad. Siit ka üks oluline võimalik põhjus, miks mõni keeruline projekt sujub probleemideta ja lahendus valmib justkui imelihtsalt, samal ajal kui teises samasuguses projektis ei tundu miski sujuvat nii, nagu on oodatud. Millest projekti edukus oleneb?
Olles aidanud ettevõtetel praeguseks juba üle 20 aasta äritarkvara lahendusi luua, võime julgelt öelda, et edukuse määrab meeskond. Kui projektis on vajalikud meeskonnaliikmed ja nad teavad oma töö eesmärki ning ülesandeid ja vastutust, siis on esimene samm eduka lõpptulemuse suunas tehtud.
Kui projekt on lihtne, võib meeskond olla väike ja hakkama saadakse väheste rollidega. Äritarkvara lahenduste puhul võib nn lihtsa projekti näiteks tuua standardlahenduse juurutuse, kus arendusi küll üldjuhul on, kuid need on pigem olemasoleva lahenduse täiendused, mis ei muuda lahenduse põhiolemust ega struktuuri.
Keerukamate projektide puhul võib ka valmislahendus vajada täielikku ümberstruktureerimist – kriitiliseks muutub roll, kes aitab lahenduse disainida ehk nn arhitekt. Tegelikkuses võib see isik kanda olenevalt ettevõttest erinevat nime, kuid sisu jääb samaks. Keegi, kes vastutab terviku toimimise eest, arvestades üksikute protsessidega.
Kuna müügiprotsessi ja kliendihaldamise tööriist Microsoft Dynamics Sales on suurettevõtetes sageli nn platvormiks ja kohandusi tarkvaras tehakse pigem rohkem, on nendesse projektidesse väga oluline kaasata inimene, kes lahenduse terviku õiges suunas liikumisel kogu aeg silma peal hoiab.
Kes see lahenduse arhitekt on? Millal ja milleks teda vajatakse?
Lahenduse arhitekt vastutab üldise lahenduse eduka kavandamise eest, mis on eduka juurutamise esimene samm. Ta kannab hoolt selle eest, et lahendus vastaks ettevõtte ärivajadustele täna, homme ja ka kaugemas tulevikus. Ta peab oskama mõelda ja ette näha seda, millised võivad olla ettevõtte vajadused 4–5 aasta pärast, ja looma lahenduse, mis käib ajaga kaasas ning on paindlik ja muudetav, sest ka juurutusprotsess võib kesta aasta-kaks või koguni kolm.
Lahenduse arhitektil on oluline osa just ärinõuete ja tehniliste lahenduste kombineerimises. Lõppkasutaja soov võib tunduda lihtne, kuid ei pruugi üldse sobituda teiste kasutajate soovidega või lahenduse üldise loogikaga. Arhitekt ei pea kindlasti ütlema keerukatele soovidele „ei“. Pigem peab ta leidma viisi, kuidas keerukad ärinõuded saaks lahendatud selliselt, et äriprotsessid ei kannataks ning lahendus jääks laitmatult tööle kõikide kasutajate jaoks.
Kuna harilikult on ettevõtetel kasutusel rohkem kui üks rakendus ning kõik need rakendused vahetavad omavahel andmeid automaatselt, siis on arhitekti üks ülesanne tagada andmete sujuv vahetamine ehk liidestus. Kuna andmeid on järjest rohkem, muutub üha olulisemaks pöörata tähelepanu ka jõudluse kindlustamisele.
Kuigi arhitekti roll on väga oluline projekti algusetappides, on ta tavaliselt arendusmeeskonnale toeks kogu juurutuse vältel ning hoiab silma peal, et igapäevaelu lahendust kokkulepitud rajalt kõrvale ei suunaks ning igapäevane arendustöö toimuks tervikut, jõudlust, turbestandardeid ja tehnoloogilisi uuendusi silmas pidades.
Mõned näited, mis aitavad otsustada, kas ja millal on lahenduse arhitekti kaasamine põhjendatud.
- Kindlasti juhul, kui luuakse uut tarkvaralahendust.
- Kui valmislahendusse luuakse täiesti uued moodulid.
- Kui lahendus on keerukas, paljude seoste ja ärireeglitega.
- Kui lahendus on liidestatud paljude väliste rakendustega.
- Kui lahendust kasutavad väga paljud kasutajad või töödeldakse suures mahus andmeid, mis mõlemad võivad tekitada jõudlusprobleeme.
- Kui projekti käigus muudetakse oluliselt äriprotsesse.
- Kui lahenduse loomisel kasutatakse uusi tehnoloogiaid.
Mis juhtub, kui arhitekti projektis pole?
Ebapiisav disain
Esimene tagasilöök on kindlasti läbimõtlemata lahendus, alates ebamugavast kasutajaliidesest kuni optimeerimata töövoogudeni, mis võib viia kasutajate rahulolematuseni ja madala kasutuseni (või ei hakata lahendust üldse kasutama).
Teiseks võivad halvasti struktureeritud protsessid ja funktsionaalsused põhjustada ebaefektiivseid tegevusi ja kaasa tuua põhjendamatuid viivitusi. Kuna hea arhitekt tagab, et lahendus on piisavalt paindlik tulevasteks muudatusteks ja laiendusteks, võib lahendus arhitekti puudumisel osutuda liiga jäigaks ja seda võib olla keeruline kohandada, kui ettevõtte vajadused muutuvad. Igasugu piirangud võivad algul tunduda mõistlikud, kuid hiljem on nende muutmine ebamugav või aeganõudev.
Süsteemi integreerimise probleemid
Liidestustes võib ilma arhitektita puududa selge visioon ja strateegia selle kohta, kuidas erinevad süsteemid omavahel suhtlevad ja andmeid jagavad, mis võib viia andmesünkroonimise jts katkestusteni. Valesti loodud integratsioon võib põhjustada andmete kaotsiminekut või dubleerimist, mis omakorda võib kahjustada äritegevuse järjepidevust ja otsuste tegemise täpsust. Arhitekt tagab ka selle, et kõik süsteemid vastavad ettevõtte turvanõuetele. Ilma võib kergesti tekkida turvaauke ja vastavusprobleeme.
Kulukad ja aeganõudvad probleemid.
Probleeme ei taha keegi ja on hea, kui meeskonnas on liige, kes suudab võimalikke tekkivaid kitsaskohti prognoosida ja ennetada. Arhitekti puudumine võib suurendada projekti riske ja viia kulukate vigadeni.
- Ilma arhitektita võib tekkida olulisi viivitusi, kuna puuduvad selged juhised ja planeeringud, mis suunavad meeskonna tööd.
- Vigade parandamine ja lahenduse ümbertegemine pärast juurutamist võivad olla väga kulukad.
- Kehvasti juurutatud süsteem nõuab sageli ulatuslikumat koolitust ja pidevat tuge, mis omakorda suurendab kulusid ja koormab IT-osakonda.
Kokkuvõtteks võib öelda, et lahenduse arhitekt on suure kogemusega ja tunneb toodet hästi, ta on hea suhtleja ja meeskonnamängija ning omab põhjalikke tehnilisi teadmisi erinevatest tehnoloogiatest. Vaadates ülaltoodud võite ja ka riske, võib julgelt öelda, et isegi kui lahenduse arhitekt võib vahel tunduda liigse lisakuluna, tagab ta kindlasti projektimeeskonnale parema une ja ettevõttele jätkusuutliku lahenduse.
