Onko miljoona webbisivuista paljon vai vähän?
Jääkiekon SM-liigan jumittaneet sivustot saivat Ilta-Sanomat tutkimaan aihetta ja haastattelemaan toimitusjohtajaa sekä arvioituttamaan sivuston laatua Petteri Järvisellä.
Esimerkiksi LinkedInissä on aiheesta käyty keskustelua suuntaan jos toiseen. Toisille miljoona on pöyristyttävän paljon, toisille ihan normaali raha tietojärjestelmähankkeesta.
SM-liigan uudistuksesta ei ole ulospäin kovin paljon kerrottu, mutta todennäköisesti projektiin liittyy myös taustajärjestelmiin liittyvää työtä sekä integraatioita, joten ”tavallisista webbisivuista” ei ole kyse. Toisaalta, ei SM-liigan sivusto ole mitenkään sellainen toiminnallisesti, jonka tarvitsisi ehdottomasti maksaa miljoona euroa.
Ulkopuolelta ei kuitenkaan voi kovin hyvää analyysiä tehdä, joten jätettäköön SM-liigan tapaus omaan arvoonsa. Tässä jutussa käsitellään lähinnä yleisellä tasolla sitä, miten kohtuullisen tavallinen it-projekti voi maksaa huomattavasti enemmän kuin mikä olisi markkinan ”tiukka hinta”.
Petteri Järvisenkin analyysi SM-liigan tapauksesta keskittyy asioihin, jotka eivät liity kovin suoraan saitin hintalappuun tai siihen miksi sivusto ei ole kestänyt isoa kuormaa – selvää on lähinnä se, että monia asioita on tehty sivuston toteutuksessa ammattitaidottomasti, mutta juurisyyt ongelmiin lienevät pääosin ostajan puolella, yleensä tällaiset tapaukset kertovat lähinnä huonoista päätöksistä jossain hankkeen alkuvaiheissa.
Miljoonaluokan kustannuksethan harvoin syntyvät mistään yksittäisistä asioista. Samanlaisia asioita voi tällä alalla tehdä hyvin erilaisilla hintalapuilla. Usein kyse on ympäristöstä, valitusta tiimistä ja valitusta työskentelymallista. Se, mitä tehdään, toki vaikuttaa, mutta isoin asia on aina, miten tehdään.
1) Monimutkaisuus maksaa
Se järkevin syy isoihin kustannuksiin on kokonaisuuden monimutkaisuus. Jos on kyse kokonaisuudesta, johon esimerkiksi liittyy useita erilaisia tietojärjestelmiä, ja näiden välisiä integraatioita ja muutostöitä, eikä vastaavaa kokonaisuutta ole aiemmin tehty, ainakaan samalla tiimillä, tulee työ vaatimaan todella paljon koordinaatiota, suunnittelua ja testaamista. Toteutus on yleensä yksinkertaista, sitten kun on keksitty mitä pitää tehdä ja on varmistettu, että näin todellakin voidaan tehdä.
Monimutkaisuuden kustannuksia voidaan toki laskea aina hyvällä ennakkosuunnittelulla ja valmistelulla, koska mitä enemmän joudutaan toteutusvaiheessa asioita suunnittelemaan, testaamaan ja uudelleensuunnittelemaan, sitä nopeammin joudutaan yllättävien kustannuksien alueelle. Isot muutokset keskellä toteutusvaihetta ovat aina arvokkaimpia.
Ketterät menetelmät ovat toki tehneet näistä yllätyksistä hyväksyttävämpiä prosessimielessä, mutta ei isojen muutosten toteutuksesta ole tullut yhtään halvempaa.
Varsin usein kun jonkun tietojärjestelmän kustannukset ovat karanneet ennakoidusta, on kyse juuri ”yllätyksistä” toteutusvaiheessa. Joskus kyse on aidoista yllätyksistä, usein enemmänkin heikosta valmistelusta ja ennakkosuunnittelun puutteista.
2) Kokemattomuus maksaa
Mitä kokemattomampi tiimi on tekemässä, niin ostajalla kuin toteuttajalla, sitä kalliimmaksi asiat yleensä myös tulevat. Yllätyksiä kun tulee sitä enemmän, mitä kokemattomampi tiimi on kyseessä – ja mitä monimutkaisempi kokonaisuus, sitä isompia voivat olla tämän kustannusvaikutukset.
SM-liigan kumppaninakin on ollut iso it-talo, joka ei ole tunnettu verkkopalveluiden tekijä, joten amatöörimäiset toteutustavat eivät ole tästä johtuen ainakaan alan ammattilaisille mitään kovin suuria yllätyksiä. Jos haluaa hyvää laatua, kannattaa ostaa asioita niihin erikoistuneilta tahoilta, ei sekatavarakaupoilta.
Moni iso it-talo on toki hyvä hoitamaan isoja kokonaisuuksia, mutta nämä osaavat myös siitä taidosta laskuttaa – tai pikemminkin asioita ratkotaan vain laittamalla asiakkuuteen niin paljon ihmisiä, että kädet eivät lopu kesken. Tämä on toki joskus juuri sitä, mistä asiakkaat haluavatkin maksaa. Korkea laatuhan ei välttämättä ole aina prioriteetti, varsin usein esimerkiksi nopeus on paljon tärkeämpää liiketoiminnan näkökulmasta.
3) (Nopea) prosessi maksaa
Mitä nopeammin, sitä nopeammin, sanottiin ainakin armeijassa usein. Tietojärjestelmien kohdalla tuo sanonta ei toimi sen paremmin kuin armeijassakaan. Oikeampi versio olisi jotain ”mitä nopeammin, sitä kalliimpaa, sitä riskialttiimpaa, ja ei aina lopulta edes kovin nopeaa”.
Tietojärjestelmäihmiset eivät yleensä pidä vertailusta rakennusalaan, mutta oikeasti näissä on paljon samaa. Rakennusalallakin kova vauhti tarkoittaa yleensä erittäin suuria kustannuksia ja mahdollisia rakennusvirheitä ja ongelmia käyttövaiheen aikana. Sama pätee tietojärjestelmähankkeisiin, nopeus alkuvaiheessa johtaa usein pettymyksiin ja riitelyyn loppuvaiheessa.
Erityisesti jos on kyse monimutkaisista kokonaisuuksista, tällöin nopeutettu prosessi voi nostaa kustannuksia erittäin paljon.
It-alan firmat ovat myös vuosien varrella oppineet, miten nopeutta vaativien asiakkaiden kanssa toimitaan, eli kukaan ei suostu käytännössä sitoutumaan mihinkään kiinteään tai edes tavoitehintaiseen urakkaan, ellei asiakas ole tehnyt pohjatöitä poikkeuksellisen hyvin. Ja kiirettä vaativat asiakkaat eivät yleensä ole valmisteluhommiaan tehneet.
Tällöin ei ole ihmekään, että kustannukset paisuvat, jos asioita vaaditaan tapahtuvan nopeasti, mutta suunnitelmat ja tavoitteetkin ovat levällään. Tämä on kuitenkin hyvin yleinen todellisuus it-alalla tänä päivänä.
Ovatko it-hankkeiden isot kustannukset lopulta edes yllättäviä?
Ja jos hankkeessa sattuu olemaan useampi näistä asioista, eli monimutkaisuutta ja laajuutta, kokematon tiimi, kevyet pohjatyöt ja suurpiirteinen sopimus toteuttajan kanssa – niin onko se oikeastaan edes mikään yllätys, että lopullinen hintalappu on moninkertainen ja lopputulokset silti laadullisesti heikot?
Isot hankkeet maksavat aina, joko niistä maksetaan omalla työllä ja hyvällä valmistautumisella, tai sitten paksuilla setelinipuilla toteuttajan suuntaan. Ja riippuen omasta tilanteesta, miljoona toteuttajalle voi todellakin olla aivan hölmöläisen hommaa tai aivan sopiva raha vauhdikkaasta suorituksesta hankalassa tilanteessa.
Aiemmin kirjoitettua digihankkeiden valmistelusta ja budjetoinnista:
- Web-palveluiden aiheuttamaa hiilijalanjälkeä tulisi vähentää
- ”Agile-markkina synnytti lihakaupan”
- Iso osa kotimaisesta ohjelmistoalasta on henkilöstövuokrausta
- Valtion yhteisen YJA-julkaisualustan diili vihdoin virallisesti Ambientialle
- Kunnat keskittävät WordPressiin ja Drupaliin
- Moni toimisto vaatii todella paljon osallistumista asiakkaalta
- Julkishallinnon tietojärjestelmähankinnat usein isompia kuin miltä näyttävät
- Vesiputous vai ketterät menetelmät? Väitöskirja käsittelee valinnan tekemistä
- HSL näyttää esimerkkiä web-kehityksen budjetoinnissa
- Yle Uutiset näyttää esimerkkiä web-kehityksen budjetoinnissa
Perttu Tolvanen
Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.
Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!
1 kommentti “Onko miljoona webbisivuista paljon vai vähän?”
Kommentointi on suljettu.
Matti Uusitalo
Loistava kirjoitus. Omalla 15v. kokemuksella voin sanoa että en muista yhtään yllätystä projekteissa joissa olen ollut mukana joka olisi johtunut mistään muusta kuin valmistelun puutteesta. Yllätykset tulevat kun lähdetään soitellen sotaa eikä tutkita ensin. On yllättävän yleistä että suunnitellaan vain pintapuolisesti että päästään nopeasti tekemään. Tämä vaikka suunnitteleminen on halpaa ja tekeminen on kallista. Kun teet ja suunnittelet samaan niin se sitten vasta kallista onkin. Tämä viimeinen on se mitä tehdään kun yllätys iskaa.