Ohjelmistokehityksen hankkiminen palveluna on kriisissä. Se on ollut kriisissä jo vuosia. Luemme säännöllisesti uutisia isoista projekteista, jotka epäonnistuvat.
Jos hankittu ohjelmisto ei vastaa tarpeita, koko investointi menee hukkaan.
Mikä ohjelmistokehityksen hankinnassa sitten menee pieleen?
1. Ei saada sitä mitä tarvittiin
Isoin epäonnistuminen on se, ettei saada sellaista ohjelmistoa, joka olisi tarvittu. Silloin koko investointi menee hukkaan.
2. Myöhästytään markkinoilta
Melkein yhtä suuri synti on se, että hankinnan tekeminen vie liikaa aikaa. Hankinnan harkinnasta ohjelmiston toimitukseen kuluu niin paljon aikaa, että liiketoiminnallinen hyötymomentti menetettetään. Useimmilla organisaatioilla menee kolmesta kuukaudesta puoleen vuoteen jo hankintaprosessin vetämisessä alusta loppuun. Vasta tämän jälkeen toimittaja voi aloittaa oman osuutensa.
3. Tehdään turhaa työtä
Yksittäisten toimijoiden kannalta pienempi, mutta kokonaisuuden kannalta edellä mainittuja pahempi ongelma on se, että hankintojen valmistelu ja kilpailutus vaativat paljon työtä sekä asiakkailta että toimittajilta. Tämä työ on sellaista, joka ei tuota mitään muuta, kuin päätöksiä siitä, minkä toimittajan asiakkaat valitsevat. Tämä työ ei ole turhaa vain niissä tapauksissa, joissa hankinta epäonnistuu. Päinvastoin: tämä oire on nähtävissä useimmissa ohjelmistohankinnan tapauksissa.
Jos ohjelmiston hankinnassa ja toimituksessa menee kauan, liiketoiminnallinen mahdollisuus voi olla jo mennyt.
Kärjistetty esimerkki tästä on 100 henkilötyöpäivän projekti, jonka kilpailutukseen eri tahot käyttivät yhteensä lähes 100 henkilötyöpäivää (htp) työtä:
- Asiakas teki teki tarjouspyynnön ja alustavan konseptikuvauksen, 20 htp
- 4 toimittajaa tekevät tarjouksen ja siihen liittyvän ratkaisukonseptikuvauksen, 5-15 htp kukin eli yhteensä n. 30 htp
- 4 toimittajaa esittelevät tarjouksensa asiakkaalle: 2 htp / toimittaja, yhteensä 8 htp
- Asiakkaan edustajat ovat tietysti mukana tarjouksen esittelytilaisuuksissa, 8 htp
- Asiakkaan edustajat vertailevat tarjouksia neljän viikon ajan, 20 htp
- Asiakas ja valittu toimittaja neuvottelevat sopimuksesta, 5 htp kummaltakin taholta
Yhteensä työtä hankintaan jo ennen kehityksen alkua on siis asiakas tehnyt lähes 50 henkilötyöpäivää ja kukin toimittaja yli 10 henkilötyöpäivää. Toimittajien kilpailuttamisesta saatavat edut saavat olla suuret, että niillä voidaan perustella 50 henkilötyöpäivän investointia 100 henkilötyöpäivän projektin valmisteluun.
Tämä on toki äärimmäinen esimerkki, mutta todellisuus on se, että harvoin hankinnan tarjouskilpailuvaihetta ajatellaan niinkään sen kannalta, että miten suuri investointi kannattaa tehdä kuin pakettina, jossa kaikki aktiviteetit ovat pakollisia.
Jos edes osa tästä työmäärästä saadaan eliminoitua, niin valtava määrä lisäkapasiteettia vapautuu lisäarvoa tuottavaan työhön. Ajatelkaa, jos asiakkaat ja toimittajat käyttäisivät tuon ajan siihen, että pyrkisivät luomaan loppuasiakkaiden elämää helpottavia ja ilostuttavia palveluita!
Miten voisit välttää nämä sudenkuopat?
Lyhyesti: Ohjelmistohankintojen sudenkuopat voidaan välttää, jos
- toimittajalle annetaan suurempi vastuu ja vapaus ratkaisujen suunnittelusta,
- pilkotaan hankinnat pienempiin kokonaisuuksiin sekä
- sidotaan tarjouspyynnöt ja sopimukset ensisijaisesti haluttuihin liiketoimintavaikutuksiin haluttujen järjestelmien sijaan.
Tämä vaatii uusien ohjelmistohankinnan toimintamallien kehittämistä ja käyttöönottoa.
Tässä artikkelissa käsittelen näistä keinoista kahta ensimmäistä.
1. Anna toimittajan keskittyä ongelmanratkaisuun
Perinteisesti ostaja rakentaa kuvan viiteryhmien tarpeet täyttävästä ohjelmistoratkaisusta.
Perinteisessä ohjelmistohankinnassa asiakas pyrkii määrittämään mahdollisimman tarkasti, millaisen järjestelmän haluaa ostaa. Tälläinen määrittelytyö sisältää pakostakin useita suunnittelulinjanvetoja ja päätöksiä, myös käyttäjäkokemuksen ja tekniikan alueilta.
Tälläinen suunnittelutyö on osa ohjelmistotoimittajien erikoisosaamista. Olisi tehokkaampaa antaa ammattilaisten tehdä itse työnsä kuin sitoa heidän kätensä. Samalla toimittajalle tulisi parempi kokonaiskuva ratkaistavasta ongelmakentästä, mikä mahdollistaisi sen, että toimittaja voi ehdottaa entistä parempia ratkaisuja.
Ratkaisu pähkinänkuoressa
Tämä edellyttää sitä, että toimeksiannossa määritellään ongelma, johon halutaan ratkaisu, eikä itse ratkaisua.
Näin toimimalla varmistetaan myös se, että asiakkaan eri viiteryhmät ovat yksimielisiä siitä, miksi ohjelmistohankinta tehdään. Usein tämä keskustelu sivuutetaan, kun on kiire lähteä määrittelemään ratkaisua.
Tällä tavoin toimimalla säästetään myös työtä ja aikaa toteutusvaiheessa. Kun asiakas on itse määritellyt ratkaisun, tulee toteutusvaiheen aluksi siirtää asiakkaan määrittelijöille kertynyt tieto ohjelmistosta siirtää toimittajalle. Tämä vie paljon työtä ja aikaa. Voisi puhua jopa siitä, että ratkaisun määrittely tehdään kahteen kertaan: ensin asiakkaan toimesta tarjouspyyntöä varten ja sen jälkeen toimittajan toimesta toteutuksen lomassa.
Toimittaja käyttää usein paljon aikaa siihen, että pyrkii ymmärtämään asiakkaan tarpeita ja ajatuksia. Samalla vaivalla, itse asiassa huomattavasti pienemmällä, toimittaja ja asiakas voisivat luoda ja tarkentaa yhteistä kuvaa ratkaisusta koko toteutuksen ajan.
2. Teetä pienempiä kokonaisuuksia
Laajoissa ohjelmistoalan tutkimuksissa on todettu, että isot projektit epäonnistuvat paljon useammin kuin pienet. Tämä johtuu siitä, että isoissa projekteissa palautesykli on usein huomattavasti pidempi. Kun palautesykli on liian pitkä, ongelmia ei huomata ajoissa.
Laajan Chaos Manifesto -tutkimuksen tulosten perusteella isot hankkeet epäonnistuvat useammin kuin pienet.
Tämän takia isokin hanke kannattaa pilkkoa pienemmiksi kokonaisuuksiksi, joiden onnistumista voi arvioida asiakkaan näkökulmasta toisista irrallaan. Ja sitten toteuttaa näitä pieniä kokonaisuuksia peräkkäin.
Näin asiakas pitää myös kaikki avaimet käsissään. Jos yhteistyö toimittajan kanssa ei suju, voidaan toimittajaa vaihtaa kokonaisuuksien välissä. Jos tuleva tiekartta vanhentuu, on suuntaa helpompi muuttaa, kun sitä ei ole lyöty lukkoon pitkillä toimittajan kanssa tehdyillä projektisopimuksilla.
Yhteenveto
Tässä kaksi periaatetta ohjelmistokehityksen hankkimisen sudenkuoppien välttämiseen. Periaatteina ne ovat yksinkertaisia. Miksi sitten näin ei toimita kaikkialla? Yllä kuvatut periaatteet vaativat muutosta nykyisiin toimintatapoihin sekä asiakkaalta ja toimittajalta. Juuri tämän takia näihin asioihin panostaminen on huomattava kilpailuetu sekä toimittajille että ohjelmistojen ostajille.
Antti Kirjavainen on kokenut valmentaja. Hän auttaa yrityksiä kehittymään liiketoimintalähtöisiksi, asiakkaita ymmärtäviksi ja jatkuvasti toimintaansa kehittäviksi.
Antin tehtävänä on auttaa uusia yrityksiä omaksumaan näitä uusia työn organisoimisen ajatusmalleja ja käytäntöjä ja näin viedä vaikutuksensa aivan uudelle tasolle.
- Kirjoittaja
- @anttiki
- Haastattelu