Luulin ostaneeni valmissoftan

Luulin ostaneeni valmissoftan


pertila_timo_croppedOhjelmistokehitys on muuttunut työurani aikana valtavasti. Kehittäjille on nykyään tarjolla erinomaiset työvälineet. Lähes kaikkeen löytyy valmiita kirjastoja tai kehityskehikkoja joita hyödyntämällä pääsee työssään nopeasti eteenpäin. Lisäksi useimpiin liiketoiminnan tarpeisiin löytyy täysin valmiita ratkaisuja. Osa näistä on jopa ilmaisia.

Ohjelmistokehittäjän työn tuottavuus on noussut merkittävästi. Mistä sitten johtuvat uutisiinkin asti päässeet murheelliset tarinat pieleen menneistä ohjelmistoprojekteista? Kaikenhan pitäisi nykyään sujua kuin tanssi. Kasataan vain valmiista palikoista asiakkaalle mieleinen ratkaisu ja siirrytään seuraavaan projektiin.

It-toimittajan vinkkelistä asiat lähtevät usein sivuraiteille jo ostovaiheessa eli tarjouspyynnössä. Esimerkiksi nämä ongelmat korostuvat julkisissa hankinnoissa, joissa tarjouspyynnön sisältö ei ole tarjousvaiheessa neuvoteltavissa:

  1. Ostetaan räätäliratkaisua, vaikka valmisratkaisu olisi käyttökelpoisempi. Tarjouspyyntö on muotoiltu räätäliratkaisulle, ja asiakas ei ehkä tiedä, että tarjolla olisi myös valmisratkaisuja. Toimittajaa pyydetään kuvaamaan, miten erilaiset vaatimukset aiotaan toteuttaa. Isossa kuvassa vaatimukset voi toteuttaa valmisratkaisulla, mutta vaatimusten yksityiskohdat eivät vastaa valmisratkaisua. Yksityiskohdilla taas ei ole lopputuloksen kannalta välttämättä merkitystä mutta eroavaisuudet vaatimusten kuvauksista voivat johtaa tarjouksen hylkäämiseen. Vaihtoehtoisesti toimittaja voi lähteä muokkaamaan valmisratkaisua tarjouspyynnön suuntaan, jolloin päästäänkin luontevasti seuraavaan kohtaan.
  2. Ostetaan valmisratkaisua mutta pakotetaan toimittaja räätäliratkaisuun. Tarjouspyynnön vaatimuksista parhaimmillaan 95 prosenttia täyttyy valmisratkaisun ominaisuuksilla. Viimeiset viisi prosenttia aiheuttaa räätälöintiä. Tämä rampauttaa valmisratkaisun idean. Ratkaisua ei välttämättä voi jatkossa helposti päivittää uuteen versioon. Vaikka pohjana onkin tunnettu valmisratkaisu, toimittajan vaihtaminen jatkossa voi olla yllättävän kallista.
  3. Ostetaan kerralla usean valmisratkaisun parhaat ominaisuudet. Tarjouspyynnöstä on nähtävissä että asiakas on kokeillut monia valmisratkaisuja ja poiminut niistä tarjouspyyntöön mieluisimmat ominaisuudet. Lopputuloksena kaikki tarjoavat räätälöityä valmisratkaisua, vaikka kullakin valmisratkaisulla voitaisiin kattaa 50‒75 prosenttia asiakkaan vaatimuksista.
  4. Lähetetään tarjouspyynnöt toimittajille kesäksi. Myös it-toimittajan henkilöstö pitää kesälomia. Parhaat tarjoukset asiakas saa silloin, kun toimittajalla on kyseisen alueen parhaat asiantuntijat niitä tekemässä. Tämä on molempien osapuolten etu. Juuri ennen kesälomia lähetettyihin tarjouspyyntöihin kannattaa laittaa niin pitkä vastausaika, että toimittajat ehtivät työstää tarjoukset kesälomien jälkeen.

Listasta voi tulkita, että olen valmisratkaisujen ystävä. Valmisratkaisu voi olla kaupan hyllystä saatava, kuten Office 365 ja SalesForce, OpenSource, kuten WordPress ja PrestaShop tai yksittäisen toimittajan ratkaisu Fujitsun CaseM ja NetCommunity. Pääasia että ratkaisu on valmis käyttöönotettavaksi ja se vastaa asiakkaan tarpeeseen riittävän kattavasti.

Mutta valmisratkaisun ostaminen on edelleen monille vaikeaa, koska silloin joutuu tinkimään vaatimuksistaan. Se on valmisratkaisun hinta. Mutta kaupan päälle saa huomattavasti edullisemman hintalapun, mahdollisuuden päivittää ratkaisu helposti uuteen versioon, uusia ominaisuuksia ajan myötä jne. Tämä kaikki yleensä menetetään kun valmistuotetta lähdetään isosti räätälöimään. Voikin sanoa että puhkiräätälöity valmisratkaisu on sekä asiakkaalle että toimittajalle aina se huonoin vaihtoehto.

Miten sitten pitäisi ostaa?

Kun tarve on selvillä, kannattaa tutkia mitä valmiita ratkaisuja markkinoilla on tarjolla ja valita niistä sopivin. Sellaisenaan. Jos riittävän hyvää tuotetta ei löydy (sellaisenaan), kyseessä on aina räätälitoteutus. Vaikka pohjana käytettäisiin valmisratkaisua.

Tiedän, helpommin sanottu kuin tehty. Uskon vahvistamiseksi siteeraan loppuun Dan Holmea joka sanoi kerran SharePoint-esityksessään suurin piirtein näin: ”Kaikkia näkemiäni projekteja yhdistää jälkikäteen katsoen seuraavat asiat: Räätälöintien merkitys liiketoiminnalle on merkittävästi yliarvioitu. Samaan aikaan räätälöinneistä aiheutuneet koko elinkaareen kohdistuvat kustannukset on räikeästi aliarvioitu.”

2 Comments

Add yours
  1. 1
    Antti Kaipainen

    Erinomainen kirjoitus ja olen täysin samaa mieltä. Sen verran lisäisin, että ohjelmisto-hankinnassa on tärkeää, että substanssin ja tekniikan (toimittajan) välissä olisi aina ns. ”adapteri-ihminen”, jolla on substanssin tuntemus sekä toimittajien tarjoamien teknologioiden ja mahdollisesti myös jo ko. ohjelmiston tuntemus. Substanssin osalta ongelma on siinä, että toiveiden tynnyrin sisältö kaadetaan pöydälle jo määrittelyvaiheessa ja kerralla halutaan kaikki eikä omaan toimintaan saisi tulla mitään muutoksia. Valmisohjelmistoa kuitenkin vaaditaan esim. aikataulu- tai kustannussyistä, johon harva toimittaja sitten edes pystyy. Adapteri-ihminen on sitten välissä se joka kertoo substanssille mikä muuttuu ja mitä on muutettava sekä toimittajalle mitkä ovat toleranssit, jonka sisällä pitäisi räätälöintiä voida tehdä.

  2. 2
    Tero Karttunen

    Ymmärtääkseen, miksi esimerkin julkishallinto toimii näin, kannattaa tutustua vaikkapa JHS179-suosituksen viitoslukuun. http://docs.jhs-suositukset.fi/jhs-suositukset/JHS179/JHS179.html#H7 Vaikka kyseessä ei ole (ei kuuluisi olla) vesiputousmalli, niin kuitenkin tarvittavat kyvykkyydet (capability) ja käytettävä liiketoimintamalli pyritään tunnistamaan ennen tietojärjestelmähankintojen kilpailutuksia. Käytetystä menelmästä erillinen ongelma on julkishallintoa sitovat lukuisat lait, normit ja ”hyväksi havaitut käytännöt”, joiden uudelleen neuvottelu yksittäisen järjestelmätoimittajan ehdotuksesta on kivikkoinen tie. Tällöin ei ole mahdollista tyytyä siihen varsinaista arvoa tuottavaan 80 prosenttiin.

Comments are closed.