Miten valita sopiva järjestelmätoimittaja?

3 touko 2012 • Strategia ja liiketoimintamuotoilu, Ventures ja startupit

Järjestelmätoimittajan valinta on yksi tärkeimmistä päätöksistä organisaatiolle, jonka toiminnalle nettipohjaiset IT-ratkaisut ovat kriittisiä. Se on myös pahuksen vaikeaa.

”On kuin bingoa pelaisi” on yksi kuulemani kommentti. Lue lisää, niin kerron miten voit hiillostaa toimittajiasi ja varmistaa onnistuneen valinnan.

Miksi järjestelmätoimittajan valinta on tärkeää?

Toimivat ja nykyaikaiset IT-ratkaisut ovat kriittisiä organisaation jokapäiväisen toiminnan pyörittämiselle ja toiminnan kehittämiselle riippumatta tyypistä tai toimialasta. Tästä useimmat lienevät yksimielisiä.

Jokainen myös ymmärtää, että kummin kaiman veljenpojan palkkaaminen oman talon suunnittelijaksi ja rakentajaksi on melkoista arpapeliä, vaikka se halvaksi tulisikin. Silti jotkut melko isotkin organisaatiot ovat valmiita hankkimaan toiminnalleen tärkeitä järjestelmiä (näennäisesti) ensisijaisesti hintalapun perusteella tai varsin kevyen toimittajavertailun perusteella.

Ei kukaan tarkoituksella haluaisi tehdä huonoa IT-toimittajavalintaa tai pelkästään halvan hinnan perusteella. Miksi sitten niin moni kokee tehneensä huonon toimittajavalinnan tai saaneensa huonon IT-järjestelmätoimituksen?

Yksinkertaisesti sen takia, että hyvän toimittajan valinta tai sopivan järjestelmän ostaminen on kertakaikkisen vaikeaa, jos ei itse ole syvällisesti alaan perehtynyt ammattilainen.

Erityisen vaikeaa on tunnistaa toimittajajoukousta minkä tasoista ammattitaitoa kukin tarjoaa suhteessa omaan polttavaan tarpeeseen.
Itse koen asian niin, että useimmiten pitäisi keskittyä ensisijaisesti toimittajan valintaan ja toissijaisesti järjestelmän valintaan.

Miksi toimittajan valinta on tärkeämpää kuin teknisen tuotteen?

Teknisen tuotteen (alusta, IT-ratkaisu, tuote jne.) oikeaan osunut valinta on kiistämättä keskeistä onnistuneelle IT-projektille. Yleensä onnistuneen hankinnan lopputulos on lopulta enemmän kiinni toimittajan pätevyydestä kuin teknisestä tuotteesta.

”Mutta onhan selvää, että jos valitsen toimivaksi todistetun tuotteeen kuten Sharepointin/Wordpressin/Magenton/[lisää oma suosikkituotteesi tähän], niin ei toimittajalla ole niin paljon osuutta lopputulokseen, eikö?”

Riski on toki hyväksi tunnetulla tuotteella pienempi, mutta toimittajavalinta ratkaisee. Tässä muutama argumentti perusteluksi:

• Hyvä toimittaja osaa suositella sopivia teknisiä ratkaisuja. Joskus käy niinkin, että asiakas on hankkimassa todella hyvää tuotetta; se vain sattuu olemaan ihan väärä ratkaisu ongelmaan.
• Hyvä toimittaja näkee kauemmas. IT-ratkaisujen odotetaan usein kestävän vuosia, mutta asiakkaalla on harvemmin riittävästi osaamista tehdä tuotevalinta siten, että se on kestävä pitkälle tulevaisuuteen. Toki toimittajallakin pitää olla hyvä käsitys asiakkaan liiketoiminnasta, muuten ratkaistaan helposti vain sen hetkistä ongelmaa.
• Saman ongelman voi teknisesti ratkaista yleensä vähintään 10 järkevällä tavalla. Julkaisujärjestelmät on hyvä esimerkki: maailma on täynnä riittävän hyviä tuotteita, pelin ratkaisee toimittaja joka valitsee asiakastarpeiseen sopivimman.
• IT-projekti on jatkumo. Omat tarpeet muuttuvat jatkuvasti, niin pitäisi myös IT-järjestelmien. Ulkoisesti hyvältä näyttävä tuote saattaakin olla osaavan toimittajan silmissä riskialtis valinta, jos vaikkapa tuotteen kehitysyhteisön aktiivisuus on selvästi hiipunut viime aikoina.
• Standardointi on vain osa ratkaisua. ”Olemme keskittyneet vain Microsoft-teknologioihin”. Kyllä, mutta onko teille sopivin ratkaisu Sharepoint, Sitefinify vai ehkä Open Source-pohjainen Umbraco tai Orchard?

Miksi järjestelmätoimittajan valinta on vaikeaa?

Kuvitellaan, että et ymmärrä talonrakentamisesta mitään ja haluat uuden omakotitalon. Tiedät montako huonetta, millaisia pintaamateriaaleja jne. haluat. Sinulla on siis melko hyvä käsitys lopputuloksesta.

Sitten pitäisi vielä päättää kuka talon rakentaa ja miten se rakennetaan. Otatko kaiken samalta vai monelta eri toimittajalta? Vai käytätkö osaan käteviä tuttujasi kustannusten leikkaamiseksi? Entä kuka ottaa vastuun, jos jotain menee pieleen?

IT-toimittajavalinnan problematiikka on pitkälti samanlaista – paitsi, että se on todennäköisesti vieläkin vaikeampaa, koska suurin osa ei osaa tutkia ohjelmiston lähdekoodia tai integraatiorajapintoja, jotta voisi vakuuttuaa perustuksien olevan kunnossa. Pitää voida täysin luottaa toimittajan ammattitaitoon.

Oi ihme, jos valinta koetaan bingon pelaamiseksi.

Mihin kiinnittää huomio järjestelmätoimittajan valinnassa?

Seuraava kuva havainnollistaa miksi järjestelmähankinta menee helposti pieleen.

Kuva pätee erityisesti internet-ratkaisuihin. Valinnassa käytetään usein paljon aikaa käyttöliittymän läpikäyntiin, vaikka integraatiorajapintojen ja järjestelmän skaalautuvuuden tutkiminen saattaisivat olla paljon tärkeämpi edellytys sille, että järjestelmä tukisi liiketoimintaa vielä vuosienkin päästä. Tämä on tietysti luonnollista, koska kuka tahansa pystyy kommentoimaan ruudulla näkemäänsä, mutta teknisten rajapintakuvausten tutkiminen onkin ihan toinen juttu.

On kuitenkin muutamia kysymyksiä, joilla voit parantaa toimittajavalintaasi.

Olen jakanut kysymykset neljään eri osa-alueeseen: yritykseen, palveluihin, toimintatapoihin ja tuotanto-osaamiseen.

Järjestelmätoimittaja yrityksenä

Koska valitaan toimittajaa, niin taustat ovat luonnollisesti tärkeitä. Niitä osataankin aika hyvin penätä, mutta on muutamia juttuja, joita asiakkaat eivät välttämättä keksi selvittää.

Luokittele järjestelmätoimittaja

Järjestelmätoimittajan luokitus on mielestäni erittäin tärkeä, mutta varsin usein unohdettu valintakriteeri. Tarkoitan tällä sitä, että olisi hyvä ymmärtää minkätyyppisiä yrityksiä kentällä palveluita tarjoaa ja suhteuttaa tätä omaan tarpeeseesi.

Esimerkiksi verkkoratkaisujen puolella toimii ainakin seuraavan tyyppisiä toimijoita: verkkokonsultit, mainostoimistot, uusmediatoimistot, digitoimistot, ohjelmistotalot, integraattorit, sosiaalisen median toimijat, analytiikkatoimijat ja sähköisiin liiketoimintasovelluksiin keskittyneet tahot.

Jos haluat hakukoneoptimointia, niin parhaat osaajat löytynevät analyytikkaan ja inbound-markkinointiin keskittyneiltä tahoilta. Jos taas haluat hienon visuaalisen ilmeen, niin mainostoimisto on aika ilmeinen valinta. Jos haluat rakentaa sähköisen kauppapaikan, portaalin tai räätälöidyn verkkosovelluksen, niin sähköisiin liiketoimintasovelluksiin erikoistuneet tahot ovat luonteva valinta.

Selvitä millaisia pelureita kentällä on ja valitse sektorilta, joka istuu tarpeeseesi.

Järjestelmätoimittajan kokemus

Tämä on ilmeinen, mutta relevantti. Lähes jokainen asiakas kyselee referenssejä, mutta saatko vastaukseksi pelkkiä firmojen nimiä. Entä saatko pyydettäessä asiakkaita, joille voit soittaa ja kysellä miten toimittaja on suoriutunut tehtävistään.

Järjestelmätoimittajan ja liiketoiminnan jatkuvuus

Varsinkin isommat asiakkaat osaavat kiitettävästi kysellä tämän perään. Mutta mieti kumpi on sinulle relevantimpaa: 100 liukuhihnaverkkosivustoa 3 vuodessa vai 100 vaativaa toteutusta 10 vuodessa?

Paljon näkee sitä, että tuoreemmat toimittajat esittävät pelkkiä referenssimääriä. Kannattaa kysellä mistä määrät muodostuvat. Esimerkiksi toimittaja, jolla on suosittu SaaS-tuote saattaa kertoa omaavansa satoja referenssejä, mutta vain muutama kymmenen niistä on sovellusprojekteista, loput SaaS-asiakkaita. Huomionarvoinen asia, jos olet hankkimassa vaikkapa tarpeisiisi räätälöityä sovellusta.

Yrityksen kokoluokka on oleellinen asia, mutta usein unohdetaan sen suhteellisuus. Kumman arvelet saavan parempaa palvelua: ison toimittajan pienin asiakas vai pienen toimittajan isoin asiakas?

Määrä ei takaa laatua. Vaadi enemmän tietoa.

Järjestelmätoimittaja ja sen palvelut

Olen tarkoituksella jättänyt pois tästä listasta teknisten tuotteiden valintaan liittyvät kysymykset. Ei sen takia, että ne eivät olisi relevantteja, vaan sen takia, että keskustelu keskittyy niihin yleensä muutenkin. Sen vuoksi käsittelenkin tässä palveluita.

Koulutus

Isommille asiakkaille tämä on yleensä pakollinen oston kriteeri, mutta saattaa joskus unohtua pienemmiltä. Minusta yksi hyvä keino arvioida tätä on se tajuaako toimittaja tarjota koulutuspalveluita järjestelmäprojektiinsa kysymättä. Jos osaa, niin todennäköisesti niitä on joskus aiemminkin toimitettu.

Ylläpito

Ylläpitopalveluiden tarjoaminen osana toimitusta kuulostaa itsestäänselvältä, mutta on kaikkea muuta. Omien kokemuksieni mukaan toimivien ylläpitopalveluiden järjestäminen vaatii harjoittelua, investointeja ja ylläpitokulttuurin rakentamisen yritykseen.

Kannattaa huomata, että toimivan ylläpitokulttuurin muodostuminen ottaa helposti vuosia. Sen vuoksi esimerkiksi tuoreemmissa yrityksissä saatetaan keskittyä kyllä toteutukseen kiitettävästi, mutta ylläpitoon ei niinkään.

Saako tukea sähkopostin lisäksi myös puhelimitse? Kenelle tukea tarjotaan? jne.

Konsultointi

Konsultointia tarjoaa useimmat IT-firmoista, mutta onko se vain keino laskuttaa korkeampaa tuntitaksaa vai onko taustalla uskottavaa näyttöä onnistuneista konsultoinneista? Myös uskottava kuvaus ja näkemys konsultointiprosessista ja asiakkaan tarpeeseen liittyvästä konsultoinnista antaa käsitystä siitä minkätasoista konsultointi on.

Kuka konsultointia tarjoaa on toki oleellinen kysymys. Isolla toimittajalla saattaa olla tapana marssittaa neuvotteluihin kaikkien kokenein seniorikonsultti, mutta varsinaisen työn saattaa tehdä täysi juniori.

Järjestelmätoimittaja ja sen toimintatavat

Toimintatavat ovat tietoisesi valittuja, mutta liittyvät kiinteästi yrityksen kulttuuriin ja historiaan. Muutamaa asiaa tarkastelemalla pääsee kiinni siihen millä tavalla toimittaja tekee työnsä.

Toimintamalli

Ketterästä kehitys on vakiintunut de facto tavaksi ohjelmistoprojektien toimittamisessa vesiputousmallin sijasta. Mutta miten voi arvottaa toimittajia asian perusteella, jota kaikki kertovat tekevänsä? Aihe on niin laaja, että jätän käsittelyn ja kerron vain pari kysymystä, joilla voit arvioida toimintamallia:

• Kuinka usein saan uuden demon ohjelmasta katselmoitavakseni? Vesiputousmallissa saattoi mennä kuukausia, ketterästi tehden yleensä 1-3 viikkoa.
• Kuinka vapaasti voin muuttaa sovittuja määrittelyjä projektin aikana? Vesiputousmallissa ei juuri, ketterässä kehityksessä jopa hyvinkin vapaasti sprinttien välillä. Muutokset ovat projektien kuluessa väistämättömiä, kun näkemys lopputuloksesta realisoituu ja tarkentuu.

Kannattaa tietysti huomata, että ketterä kehitys on kahden kauppa, joten ostajankin on hyvä ymmärtää että hänen oma panoksensa on kriittinen lopputuloksen suhteen. Mutta sama koskee mielestäni mitä tahansa toimintamallia.

Myös kehityksen ja toimittajan läpinäkyvyys luo luottamusta siihen, että ongelmat nostetaan esille kun niitä tulee.

Dokumentointikulttuuri

Dokumentointikulttuuri

Ohjelmiston dokumentaatio on erityisen tärkeä osa-alue ja kokemuksieni mukaan yksi kaikkein eniten laiminlyödyistä. Se on siinä mielessä ymmärrettävää, että jos asiakas ei osaa pyytää, niin toimittaja ei välttämättä miellä pakolliseksi.

Mikä on minimivaatimus dokumentaatiolle?

Minusta absoluuttinen minimi on asianmukaisesti kommentoitu ja versionhallintaan sijoitettu lähdekoodi. Ilman lähdekoodin dokumentointia ohjelmiston jatkokehitys muuttuu tuskalliseksi. Se on hiukan sama kuin yrittäisi lukea 5000-sivuisen kirjaa, jonka sivut on sekoitettu ja jossa ei ole sivunumerointia.

Erityisen kriittiseksi lähdekoodin puuttumisen tekee se, että ongelmat tällä saralla valkenevat asiakkaalle yleensä vasta sitten, kun toimittajan ohjelmistosta vastannut koodari lähtee talosta tai toimittaja vaihtuu kokonaan.

Jonkinlainen käyttöohje on yleensä paikallaan, mutta sen asiakkaat yleensä osaavat pyytääkin. Sen sijaan ylläpitäjän käyttöohje on dokumentti, jota ei usein pyydetä, mutta voi olla lähes pakollinen. Erityisesti isommassa organisaatiossa, jossa toimittajan tuottama sovellus asennetaan asiakkaan IT:n hoiviin, on syytä löytyä ko. dokumentti tai hankaluuksia seuraa.

Dokumentteja on lukuisa joukko muitakin (vaatimusmäärittelyt, arkkitehtuuri- ja tietokantakuvaukset jne.) ja niiden tarpeellisuus on tapauskohtaista. Suositeltavaa on luetella sopimuksentekovaiheessa dokumentit, jotka sisältyvät toimitukseen.

Testauskulttuuri ja järjestelmätoimittaja

Ohjelmiston laatuun liittyy oleellisesti testauskäytännöt. Tämäkin aihe on liian laaja tyhjentävästi käsiteltäväksi, joten pureudun vain muutamaan mielestäni oleelliseen asiaan.

Ensiksi tärkein: testaus on lähtökohtaisesti juuri niin hyvää kuin siihen on käytetty työaikaa.

Toisinsanoen jos haluat mahdollisimman hyvin testatun sovelluksen, valmistaudu maksamaan siitä. On epärealistista olettaa, että saat virheetöntä koodia, jos et ole valmis maksamaan siitä.

Esimerkiksi terveydenhuoltoprojekteissa testaamiseen verifiointeineen ja validaatioineen saatetaan käyttää kuukausia, mikä on pakollista, jos ohjelmisto siirtää esimerkiksi veriarvotietoa mittalaitteesta taustajärjestelmiin.

Sen sijaan jos mobiiliportaali jättää lähettämättä tilatun soittoäänen, niin tappio on mielipaha ja 50 sentin menetys. On luonnollista, että edellä mainittujen ohjelmistojen testaukseen käytetään eri määrä aikaa.

Yksi hyvä tapa on tehdä etukäteen riskianalyysi toteutettavasta järjestelmästä ja keskittyä eniten niiden ongelmien minimoimiseen, jotka voivat aiheuttaaa suurimmat vahingot.

Testausasia on niin monisyinen juttu, että ehkä palaan siihen joskus myöhemmin oman blogiartikkelin muodossa.

Pyydä toimittajaasi kertomaan millä tavalla ohjelmisto testataan. Muista kuitenkin, että mitä paremmin testattu, sitä kalliimpi.

Kuinka järjestelmätoimittaja vie järjestelmäsi tuotantoon?

Tämä on yksi asia, jota ei juuri koskaan kysytä, mutta jolla on suuri merkitys palvelun toimivuuteen tuotannossa.
Tuotantoonvientiprosessi voi olla pitempikin, mutta yleensä seuraava on hyväksyttävä minimiprosessi: kehitys –> pilotti –> tuotanto.

Kehitystyö tapahtuu yleensä kehittäjien koneilla, joista ohjelmakoodi kerätään versiohallintaan mistä muodostetaan uusi versio koko ohjelmasta. Sitten ohjelma siirretään pilottiympäristöön, jossa tulee tarkistettua päivityksen toimivuus testauksella ja koekäytöllä. Vasta kun kaikki on todettu toimivaksi, uusi ohjelmistoversio päivitetään tuotantoon.

Ohjelmiston voi toki siirtää suoraan kehityskoneelta tuotantoon, mutta tällöin on paljon isompi riski, että jotain menee vikaan. Huomaa, että 3-vaiheinen prosessi on kalliimpi, mutta varmempi (ja ammattimaisempi).

Jossain tapauksissa muutoksia voidaan tehdä jopa suoraan tuotantoversioon (esim. SaaS-sovellusalustan mahdollistamat muutokset), mutta harvemmin.

Muista helppo kaava: kehitys –> pilotti –> tuotanto.

Järjestelmätoimittajan tekninen kyvykkyys

Asiakkaalle päin toimittajien tekninen kyvykkyys voi näyttää identtiseltä, mutta todellisuudessa niillä voi olla eroa kuin yöllä ja päivällä. Ihminen kun luonnostaan tarkastelee vain pintaa (=käyttöliittymää/ulkoasua).

Palkkaisitko sinä automekaanikoksi ihmisen, joka osaa vaihtaa autosta vain palaneen polttimon?

Kömpelö esimerkkini pyrkii havainnollistamaan, että on toimijoita, jotka osaavat jonkin verran tuunata valmiita teknisiä tuotteita, alustoja tai käyttöliittymää, mutta jotka eivät kuunaan päivänä osaisi ohjelmoida alusta asti monimutkaista enterprise-sovellusta.

Kannattaakin kysellä toimittajalta vaikka prosenttilukuina, kuinka iso osa työstä on omaa ja kuinka iso muiden koodia. Oman koodin tekemisen maksimointi ei ole oletusarvoisesti tavoiteltavaa, mutta voi antaa käsityksen siitä onko kyseessä automekaanikko vai harrastelijaremontteeraaja.

Montako prosenttia toimittaja on itse tehnyt projektiensa toteutuksista?

Tekninen järjestelmätoimittaja vai kumppani?

Suhde toimittajaan voi olla hyvin eri tasoinen tarpeesta riippuen. On kuitenkin hyvä ymmärtää mitä hakee. Jos haluaa peruskoodausta mahdollisimman halvalla jokin pieni suomalainen toimija tai offshore talo voi ajaa asian.

Jos haluaa oman liiketoiminnan kehittämistä tukevan ideoivan kumppanin, niin tuntihintaa ei kannata tuijottaa yhtä paljon ja yhteistyömuodotkin voivat olla erilaisia.
Jotkut toimittajat tekevät liukuhinnatoimituksia: mahdollisimman paljon, kustannustehokkaasti ja muutokset minimoiden. Toiset taas (kuten me) keskittyvät mieluummin

pienempään määrään asiakkaita, mahdollisimman pitkäkestoisiin asiakasuhteisiin ja panostavat IT:n kehittämisessä sen viemistä liiketoimintatasolle.
Kummallekin löytyy paikkansa, kaikki riippuu tarpeistasi.

Järjestelmätoimittajan tuotanto-osaaminen

Verkkopalvelun toimittaminen vaatii nykyään paljon enemmän osaamista kuin monet luulevat. Kannattaa selvittää mitä kaikki osa-alueita toimittaja uskottavasti tekee ja millä alueilla käytetään kumppaneita. Esimerkkinä, että meidän toimituksissamme liiketoimintalähtöisen suunnittelun ja teknisen toteutuksen teemme itse. Mobiili ja virtuaalitodellisuuden ratkaisuissa käytämme ulkopuolisia toimittajia hyödyksi.