Räätälöidyn web-sovelluksen ostaminen – eri mallit ja vinkkejä

Hyvin asiakaskohtaisen verkkopalvelun tai web-sovelluksen ostaminen poikkeaa jonkin verran perinteisen verkkosivuston tai verkkokaupan toteutusprojektista.

Isoimmat erot tulevat yleensä siitä, että hyvin räätälöidyn sovelluksen toteutukseen tyypillisesti liittyy vaativia integraatioita muihin järjestelmiin tai hyvin uniikin käyttökokemuksen toteutusta. Kummatkin ovat asioita, joiden ennustaminen tarkasti on vaikeaa. Siksi kiinteähintainen, projektimainen ostaminen ei sovi yhtä helposti räätälöityihin sovelluksiin kuin vakiintuneempiin projektityyppeihin.

Tässä artikkelissa esitetään kaksi erilaista mallia valita sopiva kumppani hyvin räätälöidyn palvelun toteutukseen. Tässä artikkelissa ei oteta kantaa yksittäisiin teknologioihin tai opasteta yksityiskohtaisesti miten kumppaneita kannattaa arvioida ja pisteyttää. Nyt keskitytään valintaprosessin kokonaismalliin sekä kriittisiin sopimusteknisiin linjauksiin.

Malli 1: Parhaan tiimin valitseminen

Jos kyseessä on hyvin bisneskriittinen palvelu ja vauhtiin pitää päästä nopeasti, niin räätälöidyn sovelluksen ostamiseen kannattaa joskus suhtautua hieman rekrytoinnin kaltaisesti. Teknologiat ja kokonaislähestymistapa eivät ole niin kriittisiä asioita tällöin. Olennaista on löytää todella osaavia tyyppejä, sellaisia todellisia ’softakokkeja’, jotka loihtivat toimivan palvelun pystyyn omatoimisesti ja laadukkaasti.

Esimerkiksi teknologiavalinta ei äärimmäisen räätälöidyssä sovelluksessa ole yleensä kovin merkityksellinen, etenkään lopputuloksen toiminnallisuuksien näkökulmasta. Olennaista on, että valittava tiimi luottaa valitsemaansa teknologiaan tai lähestymistapaan, ja toivottavasti on tehnyt vastaavalla mallilla onnistuneita sovelluksia aiemminkin.

Tämän mallin puolesta puhuvat Suomessa monet toimittajat, esimerkiksi Reaktor, Siili ja monet muut. Asiakkaan näkökulmasta tällaisessa mallissa ei ole kyse niinkään tietojärjestelmän ostamisesta, vaan parhaiten tehtävään sopivien tyyppien löytämisestä ja heidän vuokraamisestaan asiakkaan oman projektijohdon alaisuuteen. Tässä mallissa asiakas vastaa täysin lopputuloksista, koska johtaa itse projektia.

Halpaa tällainen lähestymistapa ei ole, koska relevantteja tuloksia harvoin saadaan aikaiseksi alle kolmessa kuukaudessa, ja parhaat tehot syntyvät yleensä vasta jossain puolen vuoden urakoinnin paikkeilla. Täten helposti puhutaan useista sadoista tuhansista euroista jo ennen kuin ensimmäinen kattava tuotantoversio on kasassa. Jos tämän kokoinen hintalappu ei kuitenkaan hirvitä, niin malli on erityisen toimiva – etenkin jos omasta takaa löytyy tuoteomistaja-osaamista ja näkemystä haluttavasta lopputuloksesta.

Kilpailutuksen ja valintakriteerien näkökulmasta tässä mallissa yleensä korostuvat ehdotetun tiimin (ja tiimin jäsenten) aiemmat toimeksiannot sekä aiempien ostajien asiakastyytyväisyys. On varsin tyypillistä, että valintavaiheessa haastatellaan ehdotetun tiimin aiempien asiakkaiden avainhenkilöitä ja näiden henkilöiden palautteella on varsin merkittävä vaikutus valintaprosessissa.

Hinnoittelun osalta huomiota yleensä kiinnitetään vain tarjottujen henkilöiden päivähintoihin, jos edes niihinkään. Olennaista on löytää tyyppejä, joille edessä oleva haaste ei ole tuntematon, ja takana on sopivaa kokemusta vastaavista projekteista. Malli muistuttaa monella tapaa erilaisten puitesopimusjärjestelyiden kilpailutuksia, ja periaatteessa myös julkishallinto voi soveltaa tätä mallia.

Tällainen pelkästään tiimin osaamiseen keskittyvä arviointi on monien ohjelmistofirmojen vahvasti ajama malli tällä hetkellä. Tätä on helppo ymmärtää, koska ohjelmistofirmojen kannalta tämän kaltainen resurssivuokraus on yksi parhaita ohjelmistoliiketoiminnan muotoja.

Hyvällä sopimuksella malli voi tosin myös asiakkaalle olla siedettävän riskin malli, koska yleensä irtisanominen on helppoa ja laskutus perustuu suoraan tehtyihin tunteihin. Esimerkiksi irtisanomispykälät ovat yleensä hyvin suosiollisia asiakkaalle tässä mallissa, ja usein koko tiimin voi käytännössä vaihtaa jopa parin viikon varoitusajalla, jos yhteistyö ei toimikaan.

Mallin isoimpana haasteena on se, että pelkästään tiimiä arvioimalla ei päästä kiinni eri teknologioiden ja toimintamallien mahdollisiin kustannus- ja laatueroihin. Esimerkiksi osaava Drupal-tiimi voi olla huomattavasti tehokkaampi vaikkapa erittäin räätälöidyn verkkokaupan toteutukseen kuin saman palvelun jonkun karkeamman ohjelmistoframeworkin (esim. Django) avulla toteuttava tiimi. Monet tähän alueeseen keskittyvät toimittajat myös preferoivat täysin räätälöityjä toteutuksia, jotka voivat olla erittäin työläitä, ja arvokkaita.

Lopputuloksen kokonaiskustannuksen ennustaminen on tässä mallissa käytännössä mahdotonta, joten monelle asiakkaalle tämän mallin soveltaminen aivan tällaisenaan on lähes mahdotonta. Toimittajaloukunkaan vaara ei ole mallissa aivan pieni, koska mitä vapaammat kädet toimittajalle annetaan, niin sitä eksoottisempia toteutusratkaisut voivat olla – vaikka oikeudet toimituksen lopputuloksiin jäisivätkin asiakkaalle.

Mainituista haasteista huolimatta tätä mallia voi suositella etenkin isoille asiakkaille tilanteisiin, joissa nopeus on ennustettavaa budjettia ja koeteltua teknologiapohjaa tärkeämpää.

Yleensä tätä mallia käytetään esimerkiksi erittäin kiireellisten liiketoimintasovellusten nopeassa toteutuksessa, esimerkiksi jonkun asiointipalvelun sisälle – tai kokonaan uuden asiointisovelluksen toteutuksessa asiakkaille. Ehkä voisi jopa sanoa, että mitä enemmän on kyse uudesta ja rohkeasta kokeilusta, niin sitä paremmin tämä vain tiimin valintaan keskittyvä ykkösmalli toimii.

Malli 2: Parhaan lähestymistavan ja tiimin valitseminen

Toinen malli ostaa räätälöidyn toteutuksen läpivienti on tehdä hieman enemmän pohjatyötä, ja sitten pyytää valittuja kandidaatteja kertomaan millaisella lähestymistavalla he palvelun toteutuksen tekisivät.

Tyypillisesti tässä mallissa tehdään jonkinlainen prototyyppi palvelun tavoiteltavasta ensimmäisestä versiosta (slangiterminä voidaan puhua vaikka tuotevisiosta). Prototyyppi voi olla a) kasa leiskoja ja ’powerpointtikonsepti’ tai jopa b) selaimellä käytettävä tyylikäs html-prototyyppi sekä sitä täydentävä vaatimusmäärittelydokumentti. Etenkin jos aikataulu ei ole kriittinen, niin jälkimmäinen vaihtoehto on yleensä suositeltava. Tällaisen proton toteutukseen on helppo käyttää jotain freelanceria, digitoimistoa tai design-toimistoa. Isommissa kokonaisuuksissa jopa palvelumuotoilutoimisto voi olla vastuussa prototyyppivaiheesta.

Nykyisin myös monet ohjelmistofirmat tarjoavat suunnittelu- ja prototyyppipalveluita, jolloin saatetaan puhtaan html-toteutuksen lisäksi jo tehdä jonkin verran toiminnallisuuksiakin.

Kun proto on kasassa, niin sopivimmiksi valittuja toimistoja pyydetään tutustumaan protoon ja vaatimusmäärittelyyn, ja esittämään ehdotuksensa heidän mielestään sopivimmasta tiimistä, teknologia-arkkitehtuurista sekä projektimallista.

Tyypillisesti tällöin ollaan ostamassa astetta enemmän avaimet käteen -toteutusta kuin pelkästään resursseja oman projektijohdon alaisuuteen. Siksi myös ensimmäisen vaiheen kustannusarviointi yleensä kuuluu kandidaateilta pyydettävän esityksen sisältöön.

Projektista riippuen arvioinnin kohteena saattavat olla myös testauskäytänteet, laadunvarmistusmenetelmät tai design-osaaminen.

Tässä mallissa hinta-arvioihin päästään myös aivan toisella tapaa kiinni, ja tässä vaiheessa saatetaankin nähdä jopa satojen tuhansien eurojen eroja, vaikka maali olisi kohtuullisen tarkasti asetettu. Räätälöityjen kokonaisuuksien toteutuksessa kun hinta-arvioon vaikuttaa merkittävästi hyvin moni asia, esimerkiksi valitun tiimin kokemus, valitut teknologiat sekä projektimenetelmät. Täten tarjoajien skaala voi olla yllättävänkin iso.

Yleensä tässä mallissa huomio myös kiinnittyy enemmän työmääräarvioihin kuin euromääräisiin arvioihin tai tuntihintoihin. Erityisesti kandidaateilta odotetaan tässä kohtaa realistisuutta. On esimerkiksi melko yleistä, että erittäin selkeästi muita alhaisempi työmääräarvio tiputetaan kokonaan jatkokeskusteluista. Erittäin isoja arvioita antaneet kandidaatit saattavat jopa paremmin päästä jatkokeskusteluihin, koska näiltä halutaan kuulla hyviä perusteluita arvioilleen.

Tyypillisesti paras kandidaatti tällaisessa lähestymisessä valitaan ehdotetun tiimin kokemuksen ja esitetyn lähestymistavan uskottavuuden perusteella. Tässäkään mallissa yrityksen referensseillä ei ole yleensä merkitystä, olennaista on ehdotetun tiimin sopiva kokemus ja heidän referenssit. Näin malli pyrkii löytämään parhaiten sopivan kokonaisratkaisun, ja esimerkiksi kokemusta ei yliarvosteta, vaan nuori ja osaava tiimikin voi pärjätä kisassa.

Hintamallina tyypillisesti käytetään tavoitehintamallia, jossa toimitusvastuu projektista on selkeästi valitulla kumppanilla. Tavoitehintamallia voi kuitenkin säätää jopa sopimusvaiheessa vielä, riippuen siitä miten paljon projektijohdollista kykyä asiakkaalla itsellään on.

Tämä toinen, hieman enemmän pohjatyötä vaativa malli soveltuu parhaiten tilanteisiin, joissa toteutettavalta palvelulta odotetaan melko pitkää elinkaarta ja toteutuksen läpiviennin odotetaan tapahtuvan jokseenkin ennustettavalla budjetilla.

Malli on käynnistysvaiheeltaan selkeästi hitaampi, koska prototyypin ja vaatimusmäärittelyn laatiminen vie helposti parikin kuukautta, ja samoin kilpailutus on työläämpi prosessi. Hyödyt ovat kuitenkin huomattavat, koska mallissa päästään kiinni eri lähestymistapojen kustannuseroihin, voidaan sopia turvallisempi tavoitehintainen toimitussopimus ja läpivientiin saadaan ylipäätään uskottavampi ennuste.

Todella isoihin hankkeisiin POC-vaihe on suositeltava

Todella isoissa hankinnoissa, esimerkiksi selkeästi yli 500 000 euron projektikokonaisuuksissa, kahta parasta tiimiä saatetaan jopa testata muutaman viikon mittaisten Proof-Of-Concept (POC) -vaiheiden kautta, jolloin asiakkaan tiimi pääsee arvioimaan hieman lähempää millaista tiimien kanssa olisi työskennellä. POC-vaiheista maksetaan kandidaateille tyypillisesti joku ennakkoon sovittu, kiinteä kertakustannus – esimerkiksi 10 000 euroa.

Joskus tässä vaiheessa myös vaatimusmäärittelyä tarkennetaan, jotta finaalivaiheeseen valittujen kandidaattien antamat kustannusarviot saadaan tarkemmiksi.

POC-vaihetta voikin käyttää myös astetta tiukemman hankintasopimuksen saamiseksi, koska POC-vaiheen jälkeen valittu kandidaatti varmasti ymmärtää paremmin sen mitä ollaan tekemässä.

Isoimmat hyödyt POC-vaiheesta saa kuitenkin jos keskittyy siinä täysin yhteistyön toimivuuden arviointiin. Huomio kannattaa kohdistaa ensisijaisesti työskentelymenetelmiin, tiimin kompetensseihin ja vuorovaikutuksen laatuun. Lyhyessä POC-vaiheessa ei kannata yrittää pisteyttää sitä kuka saa eniten aikaan toimivaa koodia, koska tällöin mitataan käytännössä vain kandidaattien kiinnostusta casea kohtaan, ei tiimin todellista kykyä.

Prototyyppi ja vaatimusmäärittely kannattaa tehdä useimmissa tapauksissa

Hyvin räätälöityjen kokonaisuuksien toteutukseen täysin kiinteähintainen ostaminen sopii huonosti. Silti asiakkaiden kannalta tärkeätä on saada luotettavaa hintatietoa budjetoinnin tueksi. Prototyyppi ja vaatimusmäärittely ovat yleensä parhaat keinot saada kustannusarvioihin riittävää tarkkuutta. Tavoitehintainen toimitussopimus on myös hyvä kompromissi joustavan työskentelymallin ja ennustettavan budjetin välillä.

Perusteellisemmassa arvioinnissa myös usein paljastuvat eri teknologioiden ja toimintamallien erot. Laajojen, räätälöityjen palvelujen hinta-arvioinnissa kun ei ole lainkaan epätyypillistä nähdä jopa satojen tuhansien eurojen eroja kustannusarvioissa.

Erot voivat toki johtua myös kokemattomuudesta, väärinymmärryksistä tai saalistushinnoittelusta. Joka tapauksessa budjetti- ja laatutietoinen asiakas yleensä arvioi tiimien osaamisen lisäksi myös näiden ehdottamia teknologiavalintoja, projektimalleja ja työmenetelmiä.

Aina perusteellisempi arviointiprosessi ei edes johda tiukempaan hankintasopimukseen, vaan fiksut ostajat käyttävät perusteellista prosessia myös oman ymmärryksensä lisäämiseen hankinnan kohteesta ja kriittisistä menestystekijöistä.

Tässä artikkelissa kuvattu malli 2 tuottaakin tyypillisesti parempia projekteja, koska tällöin sekä valittava toimittaja että asiakkaan tiimi on paremmin valmistautunut edessä olevaan prosessiin. Malli 1 soveltuu parhaiten tilanteisiin, joissa projektin käynnistämisellä on jostain syystä äärimmäinen kiire (”kuukaudessa liikkeelle, jotain ulos kahdessa”) tai edessä on vuosia kestävä kehitysurakka, jonka yksityiskohdista ei ole vielä tietoa (esim. lakisääteiset julkishallinnon järjestelmät).

Toimittajien kannalta perusteellisemmat arviointiprosessit ovat aina työläämpiä, ja siksi eivät kovin mieluisia. On myös syytä huomioida, että moni alan firmoista työskentelee hyvin vahvasti resurssivuokrauksen mallilla, jolloin kokonaisvaltaisempi arviointi ei ole heille ylipäätään kovin suosiollinen lähestymismalli.

Asiakkaiden on toimittajienkin näkökulma syytä tiedostaa, ja siksi usein kannattaa rajata kandidaattien määrää jo aivan alkuvaiheessa, tai käyttää porrastettua valintaprosessia. Tarkempaan tarkasteluun harvoin on järkevää ottaa kolmea (3) kandidaattia useampaa. Karsintavaiheen tapaamiskierroksessa voi toki olla jopa kymmeniä kandidaatteja mukana, mutta yleensä laajemmassakin kierroksessa 6-9 kandidaattia riittää aivan hyvin. Kandidaattien suuntaan kannattaa myös olla avoin omasta prosessistaan, koska kohtuullisen kevytkin prosessi voi olla toimittajalle kymmenien työpäivien investointi.

Pienemmillä toimittajilla ei myöskään ole erillisiä myyntiyksiköitä, joten ellei halua erityisesti suosia isoja taloja, niin etenkin karsintavaiheesta kannattaa tehdä kandidaateille mahdollisimman kevyt.

Sopimusvaiheen perusasiat

Lopuksi muutama perusasia räätälöityjen ohjelmistojen ostamisesta.

Minkä tahansa lähestymistavan valitseekin hankintaan, niin sopimusneuvotteluissa valitun toimittajan kanssa on syytä olla tarkkana etenkin kahdessa kohdassa: a) käyttöoikeudet ohjelmistoon ja b) irtisanomisperusteet.

Räätälöityjä ohjelmistoja ei kannata teetättää sopimusmalleilla, jotka sallivat laajojen oikeuksien jäämisen ohjelmiston toteuttavalle taholle. Useimmille alan toimittajille tämä ei ole ollut kynnyskysymys enää pitkään aikaan, mutta poikkeuksiin törmää silti säännöllisesti.

Asiakkaan tulee yksinkertaisesti vaatia itselleen vapaat käyttöoikeudet kaikkeen ohjelmistokoodiin, joka toteutukseen sisältyy – tai mikäli kokonaisuuden osana käytetään kolmannen osapuolen tuotteita, näiden lisenssit tai tukisopimukset tulee ostaa suoraan asiakasorganisaatiolle.

Asiakkaan harvoin kannattaa vaatia itselleen omistusoikeuksia, tai minkäänlaisia yksinoikeuksia käytettävään koodiin, koska tämä rajoittaisi turhaan toimittajien mahdollisuuksia käyttää olemassa olevia palikoita ja menetelmiä. Vapaa käyttöoikeus asiakaskohtaiseen koodiin ja rajoittamattomat oikeudet käyttää ohjelmiston jatkokehityksessä kolmansia osapuolia riittävät useimpiin tarkoituksiin.

Joillakin toimittajilla on taipumusta puskea räätälöityihinkin toteutuksiin mukaan itse kehittämiään frameworkkeja/sovelluskokoelmia, ja näiden järkevyyttä kannattaa arvioida tapauskohtaisesti, mutta näihinkin tulee vaatia vapaat käyttöoikeudet tilanteesta riippumatta.

Tietysti jos aikoo jälleenmyydä kohteena olevaa ohjelmistoa eteenpäin, niin sopimusasia tulee neuvotella toisin – mutta useimmiten tähän ei ole tarvetta.

Toinen tärkeä asia on irtisanomispykälät. Vaikka olisi sovittu tiukkakin tavoitehintainen malli, niin asiakkaalla tulee olla vahvat oikeudet keskeyttää projektin toimitus korkeintaan kuukauden varoitusajalla. Jos taas maksetaan kehittäjistä toteuman mukaan kuukausittain, niin jopa parin viikon irtisanomisaika voi olla perusteltu vaatimus. Tämäkin on asia, joka on etenkin pienillä ja ketterillä taloilla yleensä jo oletuksena kunnossa, mutta isommat talot saattavat edelleen pyrkiä melko sitoviin kokonaissopimuksiin.

Nämä perusasiat huomioiden, räätälöityjen ohjelmistojen ostaminen on yleisesti ottaen kohtuullisen riskitöntä ja suoraviivaista. Nyrkkisääntönä voi sanoa, että perusteellinen pohjatyö kannattaa mitä pidemmän elinkaaren palvelua on tekemässä, tai mitä tiukemmalla budjettiraamilla palvelu pitää saada pystyyn.

Jos taas haasteena on ensisijaisesti nopea julkaisu, niin huomion voi kiinnittää enemmän yksittäisten tyyppien kokemukseen ja edellisten asiakkaiden tyytyväisyyteen.

Lue lisää: Räätälöidyt web-sovellukset – kaikki julkaisut Vierityspalkissa

—

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee Drupalin, WordPressin sekä räätälöityjen ratkaisujen teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja verkkopalveluiden jatkokehityksen suunnittelussa.