pekka1500x500

Onnistunut ohjelmistoprojekti - Minimoi riskit

Ohjelmistoviidakko on täynnä sudenkuoppia aina toimittajaloukusta venyneisiin aikatauluihin ja ylipursuavaan budjettiin. Mistä on onnistunut ohjelmistoprojekti tehty? Tälle sivulle olemme keränneet vinkkejä siihen, miten vältät ohjelmistohankintojen suurimmat epäonnistumisen riskit.

 

Haluatko lukea tekstin paremmalla ajalla? Lähetä teksti sähköpostiisi + 3 casea aiheeseen liittyen. 

1 Riski: Ohjelmisto ei ratkaise oikeaa ongelmaa

Usein tietojärjestelmiä hankittaessa huomataan pian käyttöönoton jälkeen, että hartaasti odotettu ja paljon maksanut ohjelmisto ei ratkaisekaan kaikkia ongelmia, mitä varten se hankittiin.

Tämä on kaikkein fataalein virhe ohjelmistohankinnoissa. Yritys on investoinut paljon aikaa ja rahaa, mutta ongelma ovat edelleen olemassa ja vaikuttavat työhön. Joudutaan punnitsemaan, onko aikaa ja rahaa korjata vai tuleeko halvemmaksi aloittaa alusta.

Ennen jokaista investointia on kaikkein tärkeintä määrittää, mitkä ongelmat halutaan ratkaista. Jos perimmäistä ongelmaa ei ymmärretä oikein, hankinta epäonnistuu takuuvarmasti.

Onnistuneen ohjelmistohankinnan salaisuus on ottaa kaikki sidosryhmät alusta asti mukaan hankkeen suunnitteluun. Näitä sidosryhmiä ovat liiketoiminnan edustajat (eli ohjelmiston hankkiva taho), loppukäyttäjät (hankkivan tahon työntekijät ja/tai asiakkaat) sekä toteutustiimi (joko oma tai toimittajan). Jos jokin edellä mainituista sidosryhmistä jätetään syystä tai toisesta pois keskusteluista, syntyy ongelmia.

 


JOS LIIKETOIMINTA JA TOTEUTUSTIIMI KÄYVÄT KESKUSTELUJA ILMAN LOPPUKÄYTTÄJÄÄ,
SYNTYY OHJELMISTO, JOTA EI HALUTA KÄYTTÄÄ.
TÄLLÖIN SILTÄ ON TURHA ODOTTAA MYÖSKÄÄN TUOTTOA TAI SÄÄSTÖJÄ.
-
JOS TOTEUTUSTIIMI JA LOPPUKÄYTTÄJÄT KÄYVÄT KESKUSTELUJA ILMAN LIIKETOIMINTAA, SYNTYY OHJELMISTO,
JOTA HALUTAAN KYLLÄ KÄYTTÄÄ, MUTTA JOKA EI TUO BISNESHYÖTYÄ.
-
JOS LIIKETOIMINTA JA LOPPUKÄYTTÄJÄT KESKUSTELEVAT KESKENÄÄN JA JÄTTÄVÄT TOTEUTUSTIIMIN ULKOPUOLELLE,
OHJELMISTOSTA EI TULE SELLAINEN KUIN OLI TARKOITUS.

Screen Shot 2018-06-27 at 15.57.09

1 Ratkaisu: Kirkasta ongelma, validoi olettamukset ja testaa ohjelmistoa

ONGELMAN KIRKASTAMINEN

Ennen kuin ratkaisua lähdetään rakentamaan, tulee ongelmasta olla selkeä visio. Se onnistuu ainoastaan ottamalla kaikki sidosryhmät mukaan keskusteluun.

Ongelmien kirkastamisen apuna voi käyttää esimerkiksi Lean Canvasia, joka on muokattu versio Business Model Canvasista. Lean Canvas keskittyy nimenomaan ongelmaan ja sen ratkaisemiseen.

OLETUSTEN VALIDOINTI

Koko ongelmaa ei kannata lähteä ratkaisemaan yhdellä kertaa – etenkään rakentamalla siihen ohjelmistoa. Monesti ongelman ja sen ratkaisujen hahmottamisessa tehdään paljon oletuksia, joihin ratkaisut perustuvat. Oikea tapa edetä on pyrkiä validoimaan jokainen oletus kriittisyysjärjestyksessä, mahdollisimman keveästi ja halvalla. Kun tärkein oletus on testaamalla todettu paikkansa pitäväksi, voidaan siirtyä seuraavaksi tärkeimmän oletuksen pariin.

Ratkaisu liiketoimintaongelmaan voi olla esimerkiksi uuden kuluttajille suunnatun verkkopalvelun rakentaminen. Tässä tärkein oletus lienee, että kuluttajat ovat valmiita käyttämään kyseistä palvelua.

Verkkopalvelun toteuttamisen sijaan oletusta voidaan testata esimerkiksi haastattelemalla kuluttajia ja kysymällä mielipiteitä palvelun tarpeellisuudesta. Mikäli palaute on pääosin negatiivista, ongelmaa ja sen ratkaisua lienee syytä pohtia uudelleen. Jos taas vastaanotto on innostunutta, voidaan siirtyä testaamaan seuraavaa oletusta.

 


Tyypillisiä oletuksia, jotka tulee validoida:

RATKAISU TUOTTAA TAI SÄÄSTÄÄ RAHAA
-
RATKAISULLA SAAVUTETAAN KILPAILUETUA
-
RATKAISUSTA EI OLE OLEMASSA VALMISTUOTETTA
-
RATKAISU ON TEKNISESTI MAHDOLLISTA TOTEUTTAA
-
ELINKAAREN KOKONAISKUSTANNUKSET PYSTYTÄÄN LASKEMAAN
-
IHMISET OVAT KIINNOSTUNEITA JA VALMIITA MAKSAMAAN RATKAISUSTA

MVP, ELI MINIMUM VIABLE PRODUCT-MENETTELY

MVP-mallissa ohjelmisto tai ohjelmiston ominaisuus otetaan mahdollisimman varhaisessa vaiheessa oikeaan käyttöön. Aluksi käyttäjäryhmä voi olla rajatumpi, jotta ei synnytetä myrskyä vesilasiin.

MVP-menettelyn ensimmäisessä vaiheessa ohjelmistoa tai ohjelmiston osaa testataan minimimäärällä ominaisuuksia. Tällöin ohjelmistoa voidaan jatkokehittää käytössä kertyneen datan perusteella.

MVP-menettelyn avulla saadaan selville, kannattaako projektia jatkaa. Jos huomaat, ettei jollekin ominaisuudelle ole tarvetta, sen kehitykseen ei kannata laittaa enempää rahaa likoon. Samalla voit kartoittaa käyttäjien kiinnostusta tuotetta kohtaan ja päättää, kannattaako tuotekehitystä ylipäätään jatkaa.

Lue lisää: 
Minimum Viable Product – testaa ennen kuin investoit
Minimum Viable Product – uhka vai mahdollisuus?

SUUNNITELMIEN JATKUVA PÄIVITTÄMINEN (TAVOITTEET, AIKATAULU, BUDJETTI)

Paljon epävarmuutta sisältäviä ongelmia ei ratkaista luotettavasti pelkällä ennakkosuunnittelulla. Siksi suunnitelmia on päivitettävä jatkuvasti.

Mikä on seuraava asia, jota lähdemme olemassa olevan tiedon valossa tekemään?

Näin hankkeen hallittavuus paranee ja projektia voidaan ohjata matkan varrella oikeaan suuntaan sitä mukaan, kun tietoa tulee lisää. Tällä tavoin riskit hajautuvat pienemmiksi – samoin kuin mahdolliset oppirahat.

Lue lisää: 
Moderni ohjelmistokehitys - vesiputousmalli vs. ketterät menetelmät 

2 Riski: Väärän teknologian valinta

Liiketoiminnan siirtyessä entistä vahvemmin verkkoon, teknologiavalintojen painoarvo kasvaa.

Kun aiemmin vanheneva teknologia oli suurimmaksi osaksi työntekijöiden murhe, nyt siitä kärsivät myös asiakkaat. Pahimmillaan huono käyttäjäkokemus ajaa heidät kilpailijan leiriin.

Vanhenevan teknologian ylläpitäminen ja jatkokehitys on kallista, eikä sopivia osaajia välttämättä löydy. Case Cobol on vain yksi esimerkki siitä, mihin osaajapula voi pahimmillaan johtaa.

Vaarana on myös, ettei vanha teknologia integroidu muihin yrityksen käytössä oleviin järjestelmiin. Tällöin päädytään helposti ottamaan exceleitä ulos yhdestä järjestelmästä ja syöttämään niitä toisiin, mikä on virhealtista ja kuormittaa turhaan työntekijöitä.

Aina ei tietenkään voi ennustaa, milloin tietty teknologia tulee tiensä päähän, kuten CASE Tikonissa tapahtui. Pitkälle pääsee, kun pysyy perillä vallitsevista teknologian trendeistä. 

2 Ratkaisu: Hajauta riski myös ohjelmistohankinnoissa

Tulevaisuutta ei pysty ennustamaan, mutta olennaista on hallita teknologimuutoksista koituvaa riskiä. Tämä toteutuu parhaiten, kun ohjelmistot koostuvat pienistä hallittavista kokonaisuuksista sekä hyvistä rajapinnoista.

Jos yksittäisen teknologian korvaaminen tulee ajankohtaiseksi, koko järjestelmän sijaan voidaan vaihtaa vain tarvittavat osat.

Kuten sijoittamisessa, myös järjestelmähankinnoissa riski kannattaa hajauttaa. On parempi panostaa useampaan keskenään pelaavaan palikkaan kuin yhteen isoon. Tällöin muutostarve ei aiheuta katastrofia, vaan ohjelmistoa on tarvittaessa helpompi korjata ja uusia vain yhdestä nurkasta.

 


Liiketoiminnan kannalta tärkeissä järjestelmähankinnoissa mahdollisiin ongelmiin on varauduttava huolellisesti etukäteen, vaikka se vaatisi lisäinvestointeja.

1. VÄLTÄ SUURIA, KERRALLA VALMIIKSI RAKENNETTAVIA MONOLIITTIRATKAISUJA.
SUOSI PIENISTÄ ITSENÄISISTÄ OSISTA KOOSTUVIA MODULAARISIA JÄRJESTELMIÄ.
-
2. PANOSTA TOIMIVIIN RAJAPINTOIHIN.
-
3. JOS HALUAT PELATA VARMAN PÄÄLLE, HYÖDYNNÄ VALTAVIRRAN MUKAISTA VAKIINTUNUTTA TEKNOLOGIAA.
KÄRJISTETTYNÄ: JOS ON OLTAVA JOSTAKIN RIIPPUVAINEN, KANNATTAA OLLA RIIPPUVAINEN SELLAISESTA
TEKNOLOGIASTA, JONKA JATKOKEHITYKSEEN JA YLLÄPITOON LÖYTYY TODENNÄKÖISIMMIN OSAAJIA.
-
4. SELVITÄ, ONKO HALUAMAASI RATKAISUA TARJOLLA VALMIINA PALVELUNA.

Modernisointi vai uusi järjestelmä

3 Riski: Toimittajaloukku

Toimittajaloukun aiheuttaa useimmiten asiakkaan kannalta epäedullinen sopimusmalli. Asiakkuus saatetaan hankkia halvalla aloitusvaiheen hinnalla.

Myöhemmin asiakkuuden vakiintuessa hintoja voidaan korottaa sitä reippaammin, mitä vähemmän asiakkaalla on todellisia vaihtoehtoja. Jatkokehitys sekä ylläpito saatetaan myös myydä erillisinä jälkeenpäin – mahdollisimman kalliilla.

Jos järjestelmän toimittaja omistaa asiakkaan ohjelmiston oikeudet (IPR:t), asiakkaan neuvotteluasema on erittäin heikko. Ongelmissa ollaan myös, jos järjestelmä on toteutettu teknologialla, jota vain harva osaa käyttää. Edellä mainittu Cobol on hyvä esimerkki tästä.

Pahimmassa tapauksessa toimittajaloukku on kuin ikuisuusjäsenyys kuntosaliin. Huolimatta siitä, että muualta löytyisi paremmat kuntoiluvälineet ja toisen ketjun sali olisi aivan kodin vieressä, kiveen hakattu sopimus tekee vaihtamisen niin kalliiksi, ettei se kannata.

Lue lisää: 
Miten välttää toimittajaloukku ohjelmistohankinnoissa? 

 

3 Ratkaisu: Suosi sopimuksia, jotka voit irtisanoa koska tahansa

Ohjelmistot ovat kriittinen osa liiketoimintaa. Sen takia sopimukset kannattaa tehdä niin, että pääset tarvittaessa irtautumaan niistä.

 

1. VARMISTA, ETTÄ OIKEUDET OHJELMISTOON JÄÄVÄT ITSELLE.
-
2. SUOSI SOPIMUKSIA, JOTKA VOIT IRTISANOA KOSKA TAHANSA.
-
3. VAMISTA, ETTÄ JÄRJESTELMÄLLÄ ON USEITA TOIMITTAJAVAIHTOEHTOJA.
-
4. SUOSI VALMIITA PILVIRATKAISUJA SEKÄ AVOINTA LÄHDEKOODIA. 
-
5. VARMISTA TEKNOLOGIAN ELINKELPOISUUS JA OSAAMISEN SAATAVUUS.
-
6. VARMISTA OIKEUS DATAAN MYÖS SOPIMUKSEN PÄÄTTYMISEN JÄLKEEN.

 

Screen Shot 2018-06-27 at 17.07.10

Muista: Paikallaan pysyminen ei tuo kilpailuetua - uskalla ottaa riskejä!

Ohjelmistohankintoihin liittyy riskejä, mutta liiketoiminnan kannalta suurin riski on jättää teknologia hyödyntämättä. Siksi kehityksessä on syytä pysyä mukana. Muuten seuraavan innovaation edut ohjautuvat kilpailijan laariin.

Uusia järjestelmiä ei kuitenkaan kannata hankkia ilman perusteellista pohjatyötä. Kartoita ongelma, älä sitoudu liian tiukasti yhteen ainoaan toimittajaan tai teknologiaan, ja muista tehdä pieniä ja nopeita kokeiluja pitkin matkaa.

Kaikkeen ei ole valmiita vastauksia, eikä kukaan pysty ennustamaan aukottomasti tulevaa. Riskejä pystyy kuitenkin hallitsemaan tutkimalla, testaamalla ja päivittämällä suunnitelmia jatkuvasti.

 

Varmista, että valitset oikean kumppanin ohjelmistohankkeeseesi!

LATAA MAKSUTON CHECKLIST AVUKSESI KUMPPANIN VALINTAAN.

Ohjelmiston ostajan checklist

 

Heräsikö mielenkiintosi ja haluaisit keskustella teidän ohjelmistohankkeestanne? 

Täytä alla oleva lomake, niin olemme yhteydessä asap!