Kuinka verkkopalveluja tulee ostaa?

Kaupunginvaltuutettu ja ohjelmistokonsultti Otso Kivekäs kirjoitti hiljattain ansiokkaan kirjoituksen ”Kuinka ohjelmistoja tulee ostaa?”. Kirjoitus kiteyttää etenkin julkishallinnon näkökulmasta erittäin hyvin eri vaihtoehtoja. Otson kirjoituksessa ei ole käytetty juurikaan esimerkkeinä verkkopalveluiden ostamista, mutta kirjoituksen pääviesti on sovellettavissa täysin verkkopalveluiden ostamiseen – ja pätee erittäin hyvin niin julkiseen sektoriin kuin yksityiseen.

Etenkin jos olet töissä verkkopalveluja ostavassa organisaatiossa, niin Otson alkuperäinen kirjoitus kannattaa ehdottomasti lukea. Näkökulma on toki ohjelmistokeskeinen, mutta etenkin isompien verkkopalveluprojektien suhteen tämä näkökulma on erittäin toimiva.

Seuraavaksi sovellan Otson esittämää kolmijakoa verkkopalveluiden ostamiseen.

Vaihtoehto 1: Osta palveluna (pilvestä)

”Pilvipalvelut eli valmiit online-ratkaisut eivät yleensä ole täsmälleen sitä, mitä sinulla oli mielessä. Mutta vaiva ja kustannus on ehkä tuhannesosa täsmälleen oikeanlaisen järjestelmän hankkimisesta. Kannattaa selvittää, onko sopivia online-tuotteita tarjolla, ja vakavasti miettiä, voitaisiinko toiminta sovittaa toimimaan niillä.”

Palveluna ostettavat ratkaisut sopivat tilanteisiin, joissa verkkopalvelu ei ole toiminnan kannalta kriittinen eikä siihen kohdistu ehdottomia erityisvaatimuksia. Esimerkiksi Kela tuskin sähköisiä palveluitaan koskaan voi ostaa valmiina pilviratkaisuna.

Sitä vastoin pk-yritykset, yhdistykset ja monet julkishallinnon hankkeet pärjäävät mainiosti Kotisivukoneen kaltaisilla täysin palveluna tarjottavilla valmistuotteilla. Tuhansia henkilökohtaisia blogeja ja jopa yrityksien sivustoja pyöritetään myös esimerkiksi WordPress.com -palvelulla. Tässäkin blogissa on näistä kirjoitettu aiemmin tarkemmin edullisina ja helppoina ratkaisuina tehdä nettisivustoja.

Pilvipalveluiden yleistyessä kannattaisikin myös julkisella puolella useammin miettiä, että kannattaisiko tapahtuman, seminaarin tai markkinointikampanjan sivusto tehdä jonkun Kotisivukoneen kaltaisen pilvipalvelun päälle? Edelleen tässä maassa törmää hämmentävän usein jonkun hankkeen tai projektin tai yhdistyksen sivustoon, joka on tehty 10 000 – 30 000 euroa maksaneena projektina vaikka samaan tulokseen olisi päässyt muutamalla satasella ja valmisteemalla.

Vaihtoehto 2: Osta standardituote

”Jos jotain ratkaisua ei saa palveluna netistä, sen saattaa silti saada valmiina tuotteena. Tai jos lainsäädäntö ei mahdollista nettipalvelun käyttöä, niin tietojärjestelmän voisi ehkä kuitenkin hankkia valmiina omiin tiloihin.”

Verkkopalveluiden saralla WordPress on melko täydellinen esimerkki standardituotteesta, joka vastaa useimpien asiakkaiden vaatimuksiin aivan sellaisenaan. Isompien konsernien näkökulmasta myös esimerkiksi EPiServer edustaa tällaista standardituoteratkaisua joskus.

Periaatteessa tässä standardituote-sarjassa kilpailee Suomessakin lukuisia kotimaisia julkaisujärjestelmätuotteita (esim. Poutapilvi, Koodiviidakko, Crasman). Kotimaisten toimijoiden kohdalla kuitenkin rajoittavana tekijänä on Otsonkin mainitsema riski toimittajaloukusta. Myöskään standardista vaihtoehdosta tuskin voi puhua, jos ko. tuotteella tekee verkkopalveluita vain kourallinen ihmisiä maailmassa.

Otsokin käyttää esimerkkinä standardituotteesta Microsoftin SharePointtia ja Adoben Photoshoppia. Näin standardituote voi olla suljettukin ohjelmisto, kunhan se on tarpeeksi yleinen ja sille löytyy kumppaniverkostoa riittävästi.

Standardituotteen voi siis hankkia avoimena tai suljettuna, mutta yksinkertaisesti turvallisempaa on ostaa avoin tuote. Tällainen täysin avoin julkaisujärjestelmätuote on esimerkiksi WordPress.

Julkishallinnon suosima Liferay voi myös joissain tilanteissa olla tällainen standardituote, jolla verkkopalvelu voi syntyä ilman toimittajaloukkuun johtavaa räätälöintiä – tai kuten Otso asiaa kutsuu: mokailua. Liferayta voidaan pitää myös avoimempana kuin esimerkiksi EPiServeriä, mutta Liferaynkin kohdalla lähdekoodi on saatavilla vain pyydettäessä (kun käytetään yleisimmin käytössä olevaa EE:tä).

Julkaisujärjestelmien kohdalla voidaan toisaalta myös kysyä, että onko edes WordPress oikeastaan standardituote siinä mielessä mitä Otso alkuperäisessä kirjoituksessaan tarkoittaa. Valmisteeman avulla käyttöönotettuna WordPress ehkä tämän määritelmän täyttää, mutta EPiServer ja Liferay eivät enää olekaan yhtä selkeitä tapauksia – kotimaisista tuotteista puhumattakaan – ja myyntimiesten väitteistä huolimatta.

Verkkopalveluiden kohdalla rajanvetoa voisi ehkä tehdä myös budjetin kautta. Jos olet tekemässä WordPressillä verkkopalvelua ja toimittajat arvioivat toteutuksen maksavan yli 15 000 euroa, niin et välttämättä enää ole ottamassa WordPressiäkään käyttöön aivan standardituotteena. EPiServerin, Drupalin ja Liferayn kohdalla standardituotteen raja menee korkeammalla, mutta viimeistään yli 100 000 euron toteutustarjousten kohdalla ei pitäisi enää puhua standardituotteen käyttöönotosta.

Vaihtoehto 3: Teetä avointa

”Jos markkinoilta ei kerta kaikkiaan löydy sellaista järjestelmää jota tarvitset, on se sitten jonkun pakko koodata. Tähän liittyy aina suurin toimittajaloukun riski.”

Parhaana toimittajaloukun välttämisen tapana Otso pitää koodin avoimuutta.

”Toimittajaloukku vältetään sillä, että kaikki koodi on avointa. Tämä on perusperiaate, josta on hyvin harvoin syytä poiketa. Ja yleensä poikettaessa tehdään virhe. Kun koodi on avointa, toimittajaa voidaan vaihtaa tarvittaessa, eikä toimittajaloukkua synny, tai ainakin siitä pääsee pois helpommin.”

Täysin räätälinä koodaamista Otsokaan ei pidä ainoana vaihtoehtona, koska hyviä osaratkaisuja löytyy moneen tilanteeseen. Esimerkiksi verkkopalveluiden kohdallahan on nimenomaan kyse usein siitä, että hankitaan valmis julkaisujärjestelmätuote, jonka päälle sitten kehitetään jonkin verran oman liiketoiminnan kannalta keskeisiä erityistoimintoja.

Tällöin olennaista on hankkia ensin perusjärjestelmä, ja sitten erikseen kilpailuttaa laajennuksien kehittäminen perusjärjestelmän päälle tai rinnalle. Näin toimivatkin jo esimerkiksi monet mediatalot, jotka työskentelevät useiden eri kumppaneiden kanssa – esimerkiksi laajoissa Drupal-ympäristöissä.

”Jos halutaan ostaa valmis järjestelmä ja kehittää sen päälle, siihen on syytä suhtautua kahtena eri hankintana: 1) hankitaan perusjärjestelmä, 2) kilpailutetaan erikseen sen päälle uuden laajennoksen kehitys. Perusjärjestelmän pitää siis tarjota riittävät avoimet rajapinnat, että muutkin kuin sen perusjärjestelmän tekijä tai kumppanit voivat aidosti kilpailla kehitysprojektista. Itse asiassa perusjärjestelmän tekijätaho olisi syytä sulkea ulos toisen projektin tarjoajien joukosta. Samaan tapaan ylläpito ja käyttötuki pitää pystyä kilpailuttamaan erikseen.”

Käytännössä aivan näin ryhdikkäästi asioita tekee hyvin harva, eikä se julkaisujärjestelmien kohdalla edes ole välttämättä järkevää aina. Perusperiaate on kuitenkin erittäin hyvä. Verkkopalvelun ydinosat ja sisältökokonaisuudet kannattaa tehdä julkaisujärjestelmän päälle. Erikoiset sovellukset ja erilliskokonaisuudet kannattaa tehdä jotenkin muuten, räätälinä tai julkaisujärjestelmän laajennuksina (plugareina, moduuleina, jne).

Asiakkaiden kannalta iso osa hyödyistä saavutetaan yleensä jo tekemällä asioita järkevästi nojaten rajapintoihin ja eriyttäen räätälöidyt osat julkaisujärjestelmän ”perusrungosta”. Tämän toteutumisen varmistamiseksi kaksi eri kumppania on tietysti varmin malli, mutta tekniset ratkaisut huomioivalla konseptoinnilla pääsee myös pitkälle.

Järkevään malliin voi siis päästä myös suljetun tuotteen kanssa. Esimerkiksi Ruotsissa julkishallinto käyttää EPiServeriä erittäin laajalti ja teetättää erityiset laajennuksensa lisäosina. Osan näistä lisäosista julkishallinto vielä julkaisee avoimesti verkossa.

Todella isoissa ”työmaissa” Otson kuvaamaa mallia ainakin yksityisellä puolella on myös käytetty. Kun yksi kumppani vastaa perusjärjestelmästä, ja toiset laajennuksista, niin osapuolten välille syntyy järkevä yhteistyösuhde (ja terveellä tavalla kilpailuhenkinen) ja kokonaislaatu paranee. Jos sama osapuoli toteuttaa sekä perusjärjestelmän että räätälöinnit, niin houkutus tehdä järjestelmästä tiukasti yhteen sidottu, erikoinen kokonaisuus, saattaa olla suurempi.

Esimerkiksi EPiServer- ja Drupal-asiakkaiden keskuudessa ei ole ollenkaan tavatonta, että verkkosivuston toteuttaa yksi kumppani ja esimerkiksi extranetin toinen kumppani. Joillakin voi olla jopa kolmaskin kumppani, joka sitten toteuttaa räätälöityjä sovelluksia näiden sisälle tai rinnalle.

Kenties se tärkein johtopäätös, joka Otson kirjoituksesta kannattaisi asiakkaan edustajien tehdä on, että toimittajaloukun voi luoda itselleen hyvin monella tapaa.

Julkaisujärjestelmienkin maailmassa yleisesti käytetty ja täysin avoin järjestelmä, kuten Drupal, voi myös johtaa toimittajaloukun syntymiseen. Mutta kuten Otso toteaa, niin avoimissa järjestelmissä se on silti asteen suljetumpia järjestelmiä vaikeampaa. Käytännössä esimerkiksi EPiServerin ja Liferayn kohdalla kumppaneita ja yhteisiä toimintatapoja on paljon, joten mokailua tosiaan pitää harrastaa, jos toimittajaloukkuun päätyy. Mitenkään mahdotonta se ei kuitenkaan ole – ja varmasti jopa WordPressin kanssa saa itsensä koodattua toimittajaloukkuun.

Otson kirjoitus kannattaakin lukea kokonaisuudessaan. Julkishallinnon kannalta tämä asia on myös erityisen tärkeä, koska linjavalinta pitää hankintalaista johtuen tehdä aikaisessa vaiheessa. Yksityisellä puolella ”mokattu prosessi” voidaan vielä oikaista joissain tapauksissa huonosti käyttäytyvää toimittajaa uhkailemalla. Julkishallinnossa paras tapa välttää ongelmat on laittaa askelmerkit oikein jo hankinnan valmisteluvaiheessa.

Lue lisää: Verkkopalvelun uudistus – kaikki artikkelit Vierityspalkissa