Eksisteerib mitmeid näiteid edukatest organisatsioonidest, mis on suutnud panna enda äriprotsessid ühte jalga astuma oma baastehnoloogiatega. Näiteks ei kujutaks ilmselt keegi ette Amazoni logistikat, ilma selle toeks oleva infosüsteemita, mis kindlustab kaupade jõudmise õigeks ajaks õigesse punkti. Tänases arutelus võtan fookusesse organisatsioonis kasutusel olevate arendusmudelite sobitamisega erinevate ärimudeli tüüpidega. Ehk siis küsimus selles, et kas õnnestub leida mingile konkreetsele ärimudeli tüübile sobiv arendusmudeli tüüp või mitte.
Tegemist on 11. nädala postitusega õppeaines ITSPEA, mille teemaks on “Arendus- ja ärimudelid“. Õppejõud on küsinud:
Analüüsi ajaveebiartiklis üht tarkvara arendus- ja üht ärimudelit mõne konkreetse projekti näitel..
– Kaido Kikkas
Arendusmudelite tüüpidest
Võtame alustuseks ette pisut ABC-d ja kirjeldame olulisemaid tarkvara arendusmetoodikate aluseks olevaid mudeleid:
- Koskmudel ja V-kujuline koskmudel on lineaarne ja etapiviisiline lähenemine, mille käigus koostatakse tarkvara nõuded, seejärel disain, siis arendus, siis testimine, siis paigaldus ja liigutakse erinevate etappide vahel selge põhimõtte alusel – kui üks asi tehtud, siis võtame ette järgmise kuni võiduka lõpuni. V-mudeli puhul jaguneb protsess lihtsalt arendamise ja testimse tsüklite vahel erineva abstraktsioonitaseme kaupa.
- Inkrementaalne mudel moodustab miniatuurseid koskesid, kus arendus on jagatud väikesteks mooduliteks ja iga konkreetse väikese arenduse tegemiseks toimub eraldi analüüs, disain, koodikirjutamine ja testimine.
- Iteratiivne mudel alustab lihtsa esialgse plaani koostamisega ja peale selle käivitab tsükli, mille raames moodustuvad selged planeerimise, nõuete kirjeldamise, analüüsi, disaini, rakenduse, testimise ja hindamise etapid, mis omakorda viivad uue kavandamise etapini kuni lõpuks rakendatakse piisavalt valmis timmitud süsteem praktikasse.
- RAD-mudel (rapid application development – kiire arendusmudel) asetab fookusesse lõppkasutaja-keskse lihvimise, prototüüpimise ja testimise, mille tulemusena esiaglset prototüüpi või selle mock-upi timmitakse niikaua kui kasutajale paistab see piisavalt hästi sobivat, et on õige aeg selle valmis tegemiseks.
- Agiilne mudel on katustermin, mida kasutatakse väga erinevate metoodikate kirjeldamiseks (Scrum, Kanban, Lean, XP jms), mille käigus on eesmärgiks pigem olemasolevate oskuste baasil eksperimenteerimine ja improviseerimine, et sobivas kontekstis võimalikult paindlikumal moel sobivat rakendusmeetodit leida. Aga enamasti peetakse ka agiilse meetodi puhul silmas pidevat kasutaja-keskset disaini, arendust ja testiminst.
Alltoodud galeriisse olen viidanud veebilehelt Visual Paradigm leitud mõned visuaalsed kirjeldused ülaltoodud meetoditest: https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/
Ärimudelite tüüpidest
Ärimudeli tüüpide struktureerimisel olen aluseks võtnud Gassmann, Frankenberger ja Csiki poolt koostatud raamatu The Business Model Navigator, mille sisus kirjeldatakse detailselt 55 ärimudeli erinevat tüüpi. Seejuures on autorid Šveitsi päritolu põhjalikkusega kirjeldanud, et mil viisil kõik nimetatud ärimudeli tüübid aitavad parimal võimalikul moel neljale küsimusele:
- Kes on konkreetse ärimudeli puhul klient?
- Mis on kliendile pakutav väärtuspakkumine?
- Kuidas ärimudeli puhul luuakse väärtust?
- Miks on ärimudel oma sisus kasumlik?
Seeläbi on antud raamistik kasutaja jaoks lihtsamini ja selgemini mõistetav kui tihti ärimudelite modelleerimises kasutatav kõige populaarseim tööriist, milleks on Alex Osterwalderi poolt väljatöötatud ärimudeli lõuend, kus tuleb ka kõige lihtsama ärimudeli kirjeldamiseks täita 9 väljast koosnev raamistik, milles tuleb lisaks ülaltoodud neljale küsimusele vastata ka kanalite, kliendisuhtluse, partnerite, ressursside, võtmetegevuste, kulustruktuuri ja tuluallikate kohta.
Et kuidagi nimetatud 55 kategooriaga lihtsamini toime tulla, on Šveitsi autorid välja mõelnud 55 mängukaarti, kus need erinevad tüübid on karikatuuridega illustreeritud, toodud mõningad tüüpfirmad, mis nimetatud ärimudeli varianti kasutavad ja ühtlasi kirjeldatud, et milliseid ärimudeli aspekte nimetud tüübi haldamiseks tuleb rõhutada.
Mõtlesin teatud valiku nimetautd 55-osalisest raamistikust antud juhul välja pakkuda ja kirjeldada mõne tarkvarafirma näitel, et nende kasutamise sisu.
- “Add-on” – ärimudel, mille põhjal peamine kliendi jaoks vajalik asi müüakse suhteliselt soodsa hinnaga, aga seejärel pakutakse sellele mitmeid lisasid, mis lõpphinna viivad suhteliselt kõrgeks. Tüüpiline mudeli kasutaja on näiteks SAP või SAS, mille ärianalüütika baasmoodulite litsentside eest makstakse mõõdukat hinda. Seejärel kui neid kohandada on tarvis, siis iga täiendav liigutus hakkab maksma märkimisväärselt suuremat hinda.
- “Auction” – ärimudel, mille puhul tehing tehakse kõrgeima hinnapakkumise teinud kliendiga. Google on oma AdWords programmi integreerinud mikro-oksjonite süsteemi. Juhul kui soovid enda reklaami kuvada, siis valid endale eelarve, paned paika oksjoni piirmäärad ja sõltuvalt otsingute sisust jõuab lõpuks kõige kõrgemat reklaamihinda pakkunud firma reklaam esikohale.
- “Cash machine” – ärimudel, mille põhjal klient maksab teenuse eest enne selle kättesaamist. Tegemist on suhteliselt universaalse mudeliga, mida ilmselt päris mitmed suuremad tarkvaraarendusteenust pakkuvad firmad pakuvad, leppides projekti puhul etapiviisilise tasustamisega – nt klient teeb esimese 10% maksest esialgu kokku lepitud projekti eelarvest kohe alguses, ja seejärel vastavalt etappide läbimisel kuni lõpuni.
- “Crowdfunding” – ärimudel, mille puhul tarbekauba kliendid maksavad enne toote kättesaamist oma väikese osa, et rahastada arendustegevust ja lõpuks oma toote kättesaamist. Tarkvara arenduses ilmselt vähe kasutatud, aga mitmetel juhtudel on mingi riistvaraga integeeritud tarkvaralise arenduse puhul seda kasutatud.
- “Crowdsourcing” või “Open Source” – ärimudel, kus toode ise on tasuta kättesaadav ja rahvas panustab ise arendustegevusse. Väga populaarne mistahes vabavaraliste rakenduste puhul alates Wikipediast ja Linuxi rakendustest kuni mistahes Javascript teekideni. Raha teenimise mudelid on enamasti nendel puhkudel “Add-on” teenuste müügi kaudu.
- “Flatrate” ja sellega sarnanev “Subscription” – ärimudel, kus fikseeritud regulaarsest tasust sõltumata võib klient tarbida mingit teenust nii palju kui ise soovib. Näiteks erinevad striimimisteenused, mille klient võib oma fikseeritud kuutasu eest vaadata oma seadmetest piiramatul hulgal meelelahutust.
- “Freemium” – ärimudel, mille baasteenus on päris tasuta, aga lisade eest makstakse. Sellest tulenevalt on ta mõnevõrra sarnane “Add-on” tüübiga. Tarkvaramaailmas väga levinud – enamik teenusepakkujaid tegutsevad selle mudeli põhjal, kus kasvõi prooviperioodil on teenus ilma tasuta kättesaadav.
- “Hidden revenue” või siis “advertising” mudel – lõppkasutaja saab mingit teenust kasutada tasuta, aga sellele kasutajale näidatakse suunatud reklaami. Siia kuulub tehnoloogiafirmadest nii Google, kogu sotsiaalmeedia.
- “License” mudel – arendusfirma loob enda intellektuaalset omandit, mida müüb seejärel kasutamiseks. Valdav mudel suurte tarkvarafirmade puhul, kes arendavad ja müüvad nn universaalseid “karbitooteid”, mis viimaste aastate vältel on küll karbist välja roninud ja klientidele kättesaadavaks tehtud veebi kaudu: Adobe, IBM, Microsoft, Oracle.
- “Orchestrator” või sellega sarnane “Solution provider” mudel – tarkvaraarendusfirma kombineerib erinevatest saadaolevatest moodulitest kokku lahenduse, mis on kliendile võimalikult sobivamal moel kohandatud. Sisuliselt on see kombinatsioon “karbitoodetest” ja oma teenuse pakkumisest.
- “Pay per use” mudel – tarkvararendusfirma loob teenuse, mille eest pole mingit regulaarset tasu tarvis maksta. Küll aga iga kord, kui seda kasutada, siis tuleb selle eest teostada kas suuremaid tasusid või mõningatel juhtudel teostada mikromakseid. Siia kategooriasse kuulub taas Google – juhul kui mitte keegi kliendi poolt tellitud reklaamile ei kliki, siis ei lähe see talle ka maksma.
- “Pay what you want” – või annetuste-põhine mudel, mille alusel on igaühel võimalik otsustada, et kui palju ta saadud teenust hindab ja soovib selle eest tasuda.
- “Performance-based-contracting” – on mudel, mille alusel tarkvarafirma sõlmib kliendiga lepingu, et sõltuvalt rakenduse poolt teenitud edasisest tulust saab ka tarkvarafirma tulu. Tihti toimub selline tehing startup-firmadega, kellel pole võimalik oma arendatava teenuse eest maksta ja selle asemel pakub ta arendajale kas osalust või optsiooni saada osa tuleviku tulust.
- “Revenue sharing” on mudel, mille põhjal üks osapool jagab osa tulust teisega. Selle põhimõtte aluselt toimivad App Store ja Google Play. Suure osa rakenduse müügitulust võtab Apple ja Google omale. Teise maksab ta rakenduse autorile.
- “Virtualisation” on mudel, mille põhjal digitaalse teenuse pakkuja teeb füüsilise kauba tarnimisele selge alternatiivi. Näiteks toimivad nii enamik virtuaalse reaalsuse tarkvaraarenduse teenuse pakkujaid.
Kuigi mõningaid piiripealseid juhtumeid otsustasin sedapuhku kõrvale jätta, siis nimekiri tuli päris soliidselt pikk.
Ärimudeli ja arendusmudeli kombo?
Tarkvaraäris kasutatakse üpris erinevaid ärimudelite tüüpe. Tüüpide valik sõltub ennekõike alltoodud muutujast:
- Kas tarkvarafirma pakub tarkvaraarenduse teenust või lõpptoodet ja
- Väärtusahelast. Esiteks – kus tarkvarafirma paikneb oma teenuse või toote pakkumise väärtusahelas – kas pigem lõppkliendi lähedal või temast kaugel. Samuti – kas tarkvarafirma haldab kogu tarkvaraarenduse protsessi enda katuse all või teeb mingit osa sellest väliste partnerite abiga.
- Eelarve suurusest ja loodava süsteemi komplekssusest. Kui tegemist on suure ja keerulise projektiga, siis on eeldatavasti olulisem põhjalik läbimõtlemine võrreldes mõne väikese toote valmistamisega.
- Konkreetse organisatsiooni kultuur ja kogemused. Ajalugu on samuti oluline – kui organisatsioonis on seni kasutatud teatud tüüpi lähenemist arendamiseks, siis see tuleb ilmselt sealsetel töötajatel ka hästi välja.
Üldistades järeldaks eeltoodust alltoodut ja kirjeldaks kolme võimalikku tüüpjuhtumit:
- Kui tegemist on pigem stabiilses äris tegutsejaga, kes teeb valmis algusest lõpuni kalleid süsteeme, mille kohandamine lõpptarbija jaoks pole kuigi oluline, siis võib kasutada lineaarset laadi arendusmudeleid ja ärimudelina sõltuvalt sellest, et kui suured on lõppkliendi poolt laekuvad maksed kas “flatrate” või “add-on” tüüpi ärimudelit.
- Kui tegemist on vastupidi – väga volatiilses valdkonnas tegutseja, kelle lahendused peavad kliendi vajadusega selgelt kohanema, siis on tarvis inkrementaalseid arendusmudeleid ja ärimudelina kas “freemium” või “subscription” ärimudeli tüüpi, mis aitab kohandada kliendi vajadusele vastavalt ka maksete suurust.
- Kui tegu on tarkvaraarenduse teenuse pakkujaga või agentuuriga, siis dikteerib valitava arendusmetoodika tüübi konkreetse kliendi vajadus ja ärimudeli tüüp on tihti kas “solution provider”, “orchestrator” või “revenue sharing”.
Ilmselt võiks seda loetelu veel jätkata ja veel täiendavaid dimensioone luua, aga esialgseks mõttearenduseks vast piisab … 🙂