Tarkvara kui (valmis) teenuse hankimine erineb oluliselt tarkvaraarenduse hankimisest tunnihinna alusel. Viimasel juhul on pakkujateks ennekõike tarkvaraarendusega tegelevad ettevõtted, kes üldjuhul ei ole spetsialiseerunud kindlale valdkonnale.
Tarkvara kui teenuse ostmisel on teatud tüüpi küsimused, mis vajavad enne hankeotsuse tegemist vastust. Esiteks on oluline aru saada, kas soovitud teenust üldse on võimalik osta valmislahendusena ja kui on, siis mis on sellise lahenduse eelised. Teiseks tuleks analüüsida teenuse valiku tingimusi ning kolmandaks tuleks aru saada, kas teenusepakkujate kvalifitseerimisel tuleb ette näha täiendavaid või teistsuguseid tingimusi.
1. Teenusepõhise tarkvara üldised eelised
Teenusepõhiselt on mõtet tarkvara hankida juhul, kui tegemist on funktsiooniga, mis lihtsustab oluliselt tellija tööd, kuid ei ole iseenesest kliendi enese poolt osutatava kriitilise teenuse osa. Nii aitab teenusepõhine tarkvara teha lihtsamaks näiteks üksikute funktsioonide haldamist või katab tervikuna teatud tugiprotsesse nagu Upsteem.com personaliarenduses.
Teenusepõhisel tarkvaral on mitmed eelised:
1.1. Haldamiskoormuse puudumine
Teenusepõhise tarkvara haldamise eest hoolitseb teenuse osutaja. Üldjuhul paikneb teenus valmis keskkonnas „pilves“ ning riistvara küsimusi ei ole vaja koos teenuse osutajaga lahendada. Seega on tavaliselt kogu teenuse haldus teenuseosutaja kohustus. Sobivate pilveserverite leidmiseks võib korraldada eraldi sertifitseerimisi.
1.2. Professionaalsus ja valdkonda tundev meeskond
Spetsialiseerunud teenuse osutajal on tavaliselt meeskond, kes on tegelenud vastava valdkonnaga juba aastaid. See tagab asjatundlikkuse mitte ainult tehnilistes, vaid ka sisulistes küsimustes.
1.3. Kasutajatoe pakkumine
Teenuse osutaja pakub üldjuhul oma tootele ka pidevat kasutajatuge, mis vähendab oluliselt tellija koormust. Lisaks kasutajatoele võidakse osutada esmaseid kasutajakoolitusi või panna kokku ka terveid koolitusprogramme.
1.4. Pidev teenuse edasiarendamine
Laia valdkonnaga tarkvaraarendaja ei ole kursis konkreetse teenuse puhul turul toimuvaga ning ka vastavate parimate praktikatega. Spetsialiseeritud teenuse osutaja tunneb oma teemat väga professionaalselt. See loob teenuseosutajale võimaluse oma toodet pidevalt vastavalt valdkonna parimatele praktikatele täiendada ja edasi arendada. Edasiarendused ei ole tavaliselt eraldi hinnastatud juhul, kui neid ei tehta kliendi tellimusel.
1.5. Kulude kokkuhoid
Teenusepakkujate võimekus oma toodet toetada ja edasi arendada on lõppkokkuvõttes teenuse tellijale odavam kui sama teenuse ise väljaarendamine.
2. Teenuse valiku tingimused
Teenuse valiku tingimustest oleme varem kirjutanud ühe eraldiseisva postituse. Alljärgnevalt keskendume aga üldistele valiku kriteeriumitele.
2.1. Teenuse spetsialiseeritud funktsionaalsus
Kas tarkvara teeb seda, mida te tahate, et ta teeks? Loomulikult tuleb kaaluda, milline funktsionaalsus on kõige olulisem teenuse valimisel. Ehk mida konkreetselt peab tarkvara tegema ja mis ei ole nii oluline.
2.2. Sobiv teenuseprotsess
Kuidas teeb tarkvara seda, mida ta teeb? Teenuse protsessi sobivus on kõige olulisem teenuse valiku kriteerium. Teenuse protsess on seotud küsimusega, kas tarkvara poolt pakutavad funktsioonid on korraldatud viisil, mis võimaldavad tarkvara kliendi soovitud viisil kasutada. Oluline on aru saada, kui paindlik teenuse protsess on ja mis ulatuses saab seda seadistada.
2.3. Turvalisus – terviklikkus ja kättesaadavus ning ligipääsuõigused
Pakutav lahendus peab olema kooskõlas hankija poolt soovitud ligipääsuõiguste süsteemiga. Lisaks teenuse tööprotsessile on väga oluline hankija jaoks määrata soovitav ligipääsuõiguste korraldus – see ei pea tingimata olema hankedokumentides kirjas – piisav on, kui hankijal on selle kohta ettekujutus.
2.4. Arhiveerimine
Arhiveerimine võimaldab osa andmestikust aktiivsest kasutusest eemaldada, aga samas on vajadusel võimalik see hiljem taas kättesaadavaks teha.
2.5. Andmete allalaadimise võimalus pakutavast süsteemist
Funktsiooni eesmärk on vajadusel nii enda kui ka kliendi andmed teenusest kätte saada ning jätkata nende andmetega mõnes muus süsteemis või paberil. Juhul kui valdkonnas on olemas kindlad andmestandardid, peaks rakendus neid ekspordi ja impordi lihtsustamiseks toetama.
2.6. Ümberlülitamine teise teenuse peale
Küsimus sellest, kas ja kuidas toetab teenus hilisemat võimalust valida selle asemele midagi muud.
2.7. Teenuse hind
Hinnastamises võib olla mitu mudelit sõltuvalt sellest, mida hinnastatakse. Asudes teenust valima, on mõistlik aru saada, millistel alustel antud valdkonnas teenuseid hinnastakse - sellisel juhul on võimalik kujundada endale ka võrdlemise metoodika. Mõned variandid on näiteks: kasutajate arv, tehtud operatsioonid, kasutatud andmemaht jne.
Lisaks hinnale tuleks võrrelda ka lisanduvaid kulusid - näiteks mil viisil ja mis hinnaga osutatakse kasutajatuge või koolitusteenuseid. Sellisel juhul võib hankes ka eraldi ette näha, kas koolitus on tehtava pakkumise komponent või mitte (tasub arvestada ka võimalusega, et teenusepakkuja tarkvara kasutuskoolituse korraldab kolmas osapool).
3. Kuidas kvalifitseerida teenusepakkujaid?
Teenuse valiku puhul ei ole võimalik lähtuda samadest kriteeriumitest, mis tarkvara arenduse teenuse ostmisel. Kvalifitseerumise tingimused ei saa seega olla sarnased.
Teenuse osutaja võimekust näitavad alljärgnevad tingimused:
3.1. Klientide arv ja suurus, käive teenuse osutamisest
Kui palju ja millise suurusega kliente teenusepakkujal antud valdkonnas on? Kui suur on käive valdkonna teenuse osutamisest? Samas ei maksa seda liiga tähtsaks hinnata, sest olenevalt ärimudelist võib olla igakuine käive suhteliselt väike. Küll aga tasuks pöörata tähelepanu sellele, kas teenusepakkujal on hankijaga võrreldavaid kliente (kas siis teenuse spetsifikatsiooni või mahu poolest), sest see võimaldab hankijal uurida ka teiste kogemusi.
3.2. Tootearendusse tehtud investeeringud
Teenuste pakkujalt ei ole võimalik küsida tarkvaraarenduse mahtusid või kogemusi rätsepalahenduste loomise projektidest. Teenuse arendaja on aga investeerinud teenuse loomisesse ja seega saab hindamisel arvestada ka toote arendusse tehtud investeeringuid. Investeeringute suurus ei pruugi aga alati olla seotud loodud toote kvaliteedi või vajalike funktsioonidega.
3.3. Meeskonna suurus ja kvalifikatsioon, valdkonna kompetentside olemasolu
Teenusepõhise tarkvara pakkujad on professionaalid oma tegevusalal ja seejärel profid tarkvaralahenduste loomisel. Programmeerimisteenuse pakkujad on profid tarkvara arendamises ning nende ülesanne on omandada konkreetse valdkonna pädevus kliendi poolt projekti teostamiseks antud aja jooksul. Selge, et tarkvara arendajale antud aeg ei võimalda tal saada valdkonna profiks. Teenusepõhise lahenduse pakkujate meeskonnas on tavaliselt ka sisulise valdkonna professionaale, kes tootearendust nõustavad. Kvalifitseerimisel võib vastavat pädevust ka küsida.
3.4. Tugiteenused ja haldamise võimekus
Tarkvara osutamine teenusena tähendab üldjuhul ka lahenduse toetamist nii sisulise abi osutamise kaudu kui ka tarkvara tehnilist haldamist. Ehk võib küsida kasutajatoe olemasolu ning seda, millistel tingimustel kasutajatuge osutatakse. Oma osa on siin ka mittefunktsionaalsetel nõuetel nagu teenuse kättesaadavus.
3.5. Rakendustugi
Teenuse osutajad oskavad üldjuhul nõustada ka teenuse kasutuselevõtuga seotud küsimustes, nendel on koostöölepingud vajalike koolitajate või konsultantidega. Milliseid rakendusprojekte ja millise ajaga on varem tehtud ning kas selleks on ka eraldiseisev meeskond? Lisaks, kas rakendus on eraldi hinnastatav?
Kokkuvõttes loodame, et esitatud punktidest on hangete ettevalmistamisel abi. Jõudu tööle!
Karl Laas
Upsteem.com
Asutaja ja CEO
+ 372 53 468 213
karl.laas@upsteem.com
