Nädal 11: Tarkvara arendus- ja ärimudeli analüüs konkreetse projekti näitel

 Oma kirju karjääri jooksul olen ma osalenud erinevates ERP tarkvara arenduse projektides, erinevates rollides. On au olnud olla nii lõppkasutaja, äri poolel tellija, arendaja kui ka tellija IT osakonna vastutava rak.adminni rollis. Esimeses kahes rollis olles, ei olnud ma ausalt öeldes arendusmudelitest midagi kuulnud. Esimest korda puutusin nende teemadega kokku Vali-IT koolituse raames ja sealt edasi on see juba olnud projektide loomulik osa. Oma kogemuse pealt võin küll kinnitada, et mudeli valik on väga oluline osa projektist. Samas kui ma olin arendaja, siis mulle pigem tundus, et valiku dikteerisime meie kui arenduspartner. Samas ka tänases rollis tundub mulle, et see ongi midagi, mis tuleb pigem arenduspartneri poolt, kui ei ole just tegu ettevõttega, kus arendusi teostatakse ettevõtte siseselt, mis eeldab väga suurt IT üksust ettevõtte sees.

Lihtne oleks olnud valida seekord näide oma kogemuste pagasist, aga mõeldes hoiatusele, et midagi diskreetset välja ei räägiks, siis otsustasin valida siiski midagi muud. Mugandasin teemat selliselt, et valisin projekti ühest lõputööst.

Tarkvaraporjekt teenindusettevõtte X näitel.

Tarkvaraprojektid ei õnnestu kunagi ainult tehnilise kvaliteedi tõttu. Edu sõltub sellest, kas arendusmudel sobib ettevõtte töökorraldusega ja kas ärimudel toetab tarkvarast loodava väärtuse realiseerimist. Teenindusettevõtte X juhtum on hea näide, kuidas need kaks maailma peavad koos toimima.

Üsna tihti kasutatakse arendusmudeli valikul hübriidset lähenemist. 

Lõputöös kirjeldatud ettevõte X seisab silmitsi probleemidega, mis on tüüpilised kiiresti kasvavatele teenindusettevõtetele: killustunud infosüsteemid, topeltsisestused, puuduv analüütika ja ebatäpne andmekvaliteet. Sellises olukorras ei ole nõuded projekti alguses kunagi täielikult selged. Interjuude põhjal oli otsus soovitada ettevõttele uue tarkvara juurutuse projektiks pigem koskmudelit, kuna kasutajad tõid välja ühe suure puudusena, et ei osata projekti lõpetada. Samas oli välja toodud ka projekti algfaasis puudulik planeerimine. Koskmudeli eeldus on et nõuded on väga selgelt määratletud

Seetõttu mina arvan, et antud juhul ei sobi klassikaline koskmudel, mis eeldab fikseeritud nõudeid ja lineaarset protsessi. Samas ei ole ettevõtte X organisatsioonikultuur piisavalt paindlik, et rakendada puhast agiilset metoodikat – juhtkond vajab selget ajakava, eelarvet ja kontrolli.
Samas kasutades arenduste teostamisel agiilset arendusmudelit, mis võimaldaks kasutajal anda tagasisidet iga iteratsioonide järel ning vähendaks riski, et arendatakse midagi, mida tegelikult ei vajata. 

Senise tarkvaraportfelli moodustavad infosüsteemid, mis on iga osakond ise juurutanud. Infosüsteemid ei olnud integreeritud, andmekvaliteet oli madal, puudus aruandlus ja analüüsi funktsionaalsus.

Uus tarkvaraprojekt lähtub väärtuspõhisest, kus tarkvara ei ole lihtsalt kulu, vaid investeering, mis peab:

• vähendama tööjõukulu,
• parandama andmete kvaliteeti,
• kiirendama teenindusprotsesse,
• toetama ettevõtte kasvustrateegiat.

Kuna töös ei mainita konkreetset tarkvara mida juurutatakse, siis ei ole juttu konkreetsest ärimudelist.

Kokkuvõteks

Võib öelda, et tarkvaraprojekti edu sünnib siis, kui:

• arendusmudel sobib ettevõtte küpsuse ja kultuuriga,
• tarkvara roll selles on defineeritud,
• väärtust tarnitakse järk-järgult ja kasutajate tagasiside põhjal.
• Projekti meeskond töötab ühtse eesmärgi nimel.

Selline koosmõju loob tarkvara, mis ei ole lihtsalt uus süsteem, vaid ettevõtte strateegiline tööriist efektiivsuse ja konkurentsivõime kasvatamiseks. 
Kui ma veel arendaja rollis olin, siis joonistus väga hästi välja see, et kui ettevõte valis suuna, et tarkvara looks ettevõttele väärtust. Eesmärgiks võeti kasutada uut tarkvara võimalikult palju, kõik tegevused mida sai suunati uude tarkvarasse, siis need projektid olid lõpuks edukad. 

Allikad:

Tarkvaraprojekti planeerimine teenindusettevõtte X näitel - TalTech raamatukogu digikogu