Nädal 11 - Tarkvara arendus-ja ärimudelid

Olen lähemalt kokku puutunud haridusvaldkonna infosüsteemide arendusega. Võtan antud teemakäsitluses jutuks ühe väiksema infosüsteemi, milleks kutseõppeasutuste müügisüsteem

Mõni aeg tagasi läks riigisektor oma majandusarvestuse pidamisega üle SAP’le. Samas aga ei võetud Rahandusministeeriumi otsusega üle täielikku SAP funktsionaalsust, vaid enimkasutatud moodulid sellest. Haridus-ja Teadusministeeriumi puhul otsustati SAPi riigi raamatupidamise konsolideerimise raamistikus laiendada ka ministeeriumi hallatavatele kutseõppeasutustele.  Kutseõppeasutusi eristab enamus valitsusasutustest see, et need teenivad ühel või teisel moel tulu – nt majutus, kutseõppurite teenused (juuksur, mehaanikatööd, majutusteenus jne), täienduskursused. Tekkis vajadus just sellist müügitulu samuti korrektselt ja süsteemselt majandusarvestuses ära siduda. SAP seda ei toetanud ja oli vaja leida lahendus. Lahendusena tuvastati SAAS põhine lähenemine, mida täiendada siis kliendivajadustest tuleneva lisaarendusega. Hanke tulemusena sai lepingupartneriks ERPLY, mille kasutamise eest ministeerium tasub + täiendav ressurss, mille raames ERPLY lisaarendusi teeb. Tundus ainuõige plaan olevat, et riik ei hakka eraturul olemas olevatele teenustele alternatiivi ise arendama. Lisaks litsentsitasule, on  lepingu raames kohaldatud juba aastaid agiilset funktsioonipõhist arendusmudelit, mille käigus lisatakse järk-järgult kliendi vajadustest lähtuvaid funktsionaalsusi.

Selle arendus suurim valu on aga ärimudel. Kui loogiliselt võttes selline tarkvara iga-aastane litsentsitasu pluss kliendivajadustest lähtuv arendustegevuse eest tasumine näib väga mõistlik ärimudel olevat, siis on selle süsteemi arenduses on hoopis teised probleemid. 

Esmalt on tegemist mitme kliendi huvidest lähtuva arendustegevusega ja vajadused/soovid/unistused on kohati väga erinevad. Ministeeriumipoolne tooteomanik peab tegema valikuid lähtudes mõistlikkusest, ressursi piiratusest ja süsteemile omistatud ootustel põhinevatest vajadustest. Teenuse eest tasuja ja teenuse kasutaja on seega erinevad isikud – ministeerium tuvastab koolidega koostöös vajadused, ERPLY teeb arendused, ministeerium maksab arenduste ja teenuskulu eest, koolid kasutavad. Suurim väljakutse on sõeluda välja ebamõistliku arendussoovid koolide poolt, sest arvete tasumise valu koolideni ei jõua ning nn maitseküsimusi on palju.

Teisalt on tuleb silmitsi seist ka süsteemiväliste teguritega. Avalike teenuste arendamisel on selge ootus infosüsteemide omavahelisele koosvõimele. Arendatava süsteemi vaatest ei tundu see üldse probleem olevat, et näiteks müügisüsteem peab olema liidestatud erinevate asjakohaste süsteemidega, näiteks täienduskoolituse infosüsteemiga, õppeinfosüsteemiga jne. Kui käsiloleva infosüsteemi jõudlus ja valmisolek liidestuste loomiseks on ka olemas, on tihtipeale probleeme liidestatava süsteemiga, sest teisel süsteemil on arendsplaanides omad prioriteedid, oma juhtrühmad jne.  Teema on valus isegi siis, kui mõlemal tooteomanikul on sama sihtgrupp.

Kuigi me ei ole selliste tekkinud riiklike IT majade usku, millist teed minnes oleks näiteks meile vajalik müügisüsteem tõenäoliselt siiski ise arendatud, on päris hirmus mõelda, et ühel hetkel see teenusleping ERPLY’ga lõpeb, ja kuna uus partner tuleb leida riigihankega, kas ring algab uuesti otsast peale. Ja tsiteerides laulu sõnu, kas „jällegi on ainult tühjad pihud….“.