Vältä epäonnistunut järjestelmähanke – näin varmistat, että projekti hyödyttää koko liiketoimintaa

Järjestelmähanke epäonnistuu harvoin siksi, että itse teknologia olisi täysin väärä. Useammin ongelmat syntyvät jo ennen järjestelmän valintaa: yrityksen tarpeita ei ole määritelty riittävän tarkasti, nykyisiä prosesseja ei tunneta tai hanketta tarkastellaan liian kapeasti IT-projektina.

Uuden ERP-, CRM- tai muun liiketoimintajärjestelmän pitäisi aina ratkaista liiketoiminnan todellisia ongelmia ja helpottaa ihmisten arkea. Siksi onnistunut järjestelmähanke alkaa yrityksen toiminnan ymmärtämisestä, ei vain järjestelmätoimittajien demoista.

Järjestelmähankkeissa samat ongelmat toistuvat yllättävän usein:

• tarve on määritelty hatarasti
• järjestelmää ei valittu liiketoiminnan pohjalta
• henkilöstöä ei osallistettu
• projektista tuli IT-projekti, ei kehityshanke

Nämä ongelmat voidaan välttää, kun järjestelmähanke rakennetaan alusta lähtien liiketoiminnan tavoitteiden, nykytilan ja todellisten tarpeiden ympärille.

Onnistunut järjestelmähanke etenee tavoitteesta jatkuvaan kehittämiseen

Onnistunut järjestelmähanke ei ala järjestelmän tai toimittajan valinnasta, vaan liiketoiminnan tavoitteesta. Ensin pitää ymmärtää, mitä yrityksessä halutaan muuttaa ja miksi. Sen jälkeen muodostetaan kuva nykytilasta, tunnistetaan ja priorisoidaan tarpeet, valitaan tarkoitukseen sopiva ratkaisu ja viedään se hallitusti osaksi ihmisten arkea. Käyttöönotto ei kuitenkaan ole hankkeen päätepiste, vaan sitä seuraavat ylläpito ja jatkuva kehittäminen.

Koko prosessin ajan mukana kulkevat henkilöstö ja avainkäyttäjät sekä hankkeelle asetetut onnistumisen mittarit. Näin järjestelmän valintaa ja kehittämistä ohjaavat alusta loppuun todelliset liiketoiminnan tarpeet ja tavoiteltavat hyödyt.

1. Tavoite – mitä haluamme muuttaa ja mitä hyötyä tavoittelemme?

Ensimmäiseksi määritellään, miksi järjestelmähanke ylipäätään käynnistetään. Tavoitteena voi olla esimerkiksi manuaalisen työn vähentäminen, myyntiprosessin nopeuttaminen, toimitusvarmuuden parantaminen, tiedon laadun kehittäminen tai johdon paremman tilannekuvan rakentaminen.

Tässä vaiheessa ei vielä ratkaista, mikä järjestelmä hankitaan. Olennaisempaa on määrittää mitä liiketoiminnassa pitäisi hankkeen seurauksena muuttua paremmaksi.

Samalla kannattaa määritellä ensimmäiset onnistumisen mittarit. Jos tavoiteltavaa muutosta ei pystytä kuvaamaan, myöhemmin on vaikea arvioida, onnistuiko hanke.

2. Nykytila – miten prosessit, järjestelmät ja tiedonkulku toimivat nyt?

Kun tavoite on selvillä, muodostetaan riittävän tarkka kuva nykyisestä toiminnasta. Nykytilakartoituksessa tarkastellaan järjestelmien lisäksi liiketoimintaprosesseja, käyttäjärooleja, tiedonkulkua, integraatioita, manuaalisia työvaiheita, kustannuksia ja tunnistettuja ongelmakohtia.

Tärkeää on ymmärtää myös se, mikä nykyisessä toimintamallissa toimii hyvin. Kaikkea ei tarvitse muuttaa vain siksi, että järjestelmää ollaan uudistamassa.

Henkilöstön ja avainkäyttäjien rooli on tässä vaiheessa erityisen tärkeä. He tuntevat usein parhaiten työn todellisen arjen, käytössä olevat kiertotiet ja ongelmat, jotka eivät näy johdon raporteissa tai prosessikuvauksissa.

Hyvin valmisteltu järjestelmähanke helpottaa myös toimittajien vertailua ja päätöksentekoa.

3. Tarpeet – mitä pitää ratkaista ensin?

Nykytilan perusteella tunnistetaan ne tarpeet, joihin järjestelmähankkeella pitää vastata. Kaikki havaitut ongelmat eivät kuitenkaan ole yhtä tärkeitä eikä kaikkea tarvitse ratkaista ensimmäisessä vaiheessa.

Tarpeita kannattaa priorisoida esimerkiksi liiketoimintahyödyn, kiireellisyyden, riskien ja toteutettavuuden perusteella. Samalla erotetaan toisistaan todelliset vaatimukset ja ominaisuudet, jotka olisivat vain mukavia lisäyksiä.

Tässä vaiheessa voidaan myös havaita, ettei kaikkia ongelmia tarvitse ratkaista uudella järjestelmällä. Joskus prosessin muuttaminen, nykyisen järjestelmän parempi hyödyntäminen, integraatio tai automaatio voi olla tarkoituksenmukaisempi ratkaisu.

4. Valinta – mikä ratkaisu vastaa parhaiten liiketoiminnan tarpeisiin?

Vasta kun tavoitteet, nykytila ja priorisoidut tarpeet tunnetaan, voidaan tehdä perusteltu järjestelmävalinta.

Tarpeet muutetaan vaatimusmäärittelyksi, jonka avulla eri järjestelmiä ja toimittajia voidaan vertailla samoilla perusteilla. Vertailussa pitäisi tarkastella ominaisuuksien lisäksi esimerkiksi järjestelmän soveltuvuutta yrityksen prosesseihin, integraatioita, kustannuksia, käytettävyyttä, toimittajan kyvykkyyttä sekä ratkaisun mahdollisuuksia kehittyä yrityksen mukana.

Tässä riippumattomasta näkökulmasta on usein hyötyä. Tavoitteena ei ole löytää ominaisuuksiltaan suurinta järjestelmää, vaan yrityksen tarpeisiin tarkoituksenmukaisin kokonaisuus.

5. Käyttöönotto – miten järjestelmä, prosessit ja ihmiset saadaan toimimaan yhdessä?

Järjestelmän käyttöönotto ei ole pelkkä tekninen asennusprojekti. Samalla muuttuvat usein prosessit, vastuut, tiedonkulku ja ihmisten tapa tehdä työtä.

Siksi henkilöstön ja avainkäyttäjien osallistuminen jatkuu myös käyttöönotossa. Heitä tarvitaan esimerkiksi ratkaisujen tarkentamiseen, testaamiseen, koulutukseen ja sen varmistamiseen, että uusi toimintamalli toimii käytännössä.

Tekninen go-live ei vielä kerro hankkeen onnistumisesta. Olennaista on seurata, alkaako järjestelmä tuottaa niitä hyötyjä, joiden vuoksi hanke käynnistettiin.

6. Ylläpito ja jatkuva kehittäminen – järjestelmähanke ei pääty käyttöönottoon

Liiketoiminta, asiakkaiden tarpeet, toimintatavat ja teknologia muuttuvat jatkuvasti. Siksi järjestelmäkään ei voi jäädä käyttöönoton jälkeen pysyvästi samanlaiseksi.

Käyttökokemusten perusteella voidaan tunnistaa uusia kehitystarpeita, poistaa tarpeettomia työvaiheita, rakentaa integraatioita ja automaatioita sekä ottaa käyttöön järjestelmän uusia ominaisuuksia. Samalla seurataan hankkeelle asetettuja onnistumisen mittareita ja arvioidaan, ovatko tavoitellut liiketoimintahyödyt toteutuneet.

Jatkuva kehittäminen ei tarkoita jatkuvaa järjestelmän muuttamista. Olennaista on seurata, miten ratkaisu palvelee liiketoimintaa, tunnistaa uudet tarpeet ja arvioida muutokset niiden tuottaman hyödyn perusteella. Näin järjestelmäympäristö kehittyy hallitusti yrityksen mukana eikä vuosien kuluessa muodostu uudelleen vaikeasti hallittavaksi kokonaisuudeksi.

Onnistuneen järjestelmähankkeen lopputulos ei siis ole vain käyttöön otettu järjestelmä, vaan yrityksen mukana kehittyvä toimintamalli, joka helpottaa ihmisten työtä ja tukee liiketoiminnan tavoitteita.

Henkilöstö mukaan jo alussa – ei vasta testausvaiheessa

Pk-yrityksessä etenkin avainkäyttäjät on tärkeää ottaa mukaan aikaisessa vaiheessa, esimerkiksi työpajoihin.
Avainkäyttäjien osallistamisessa ei ole kyse vain muutoksen hyväksyttämisestä henkilöstölle. Heillä on usein paras käytännön ymmärrys siitä, missä nykyiset järjestelmät ja prosessit aiheuttavat ylimääräistä työtä, mitä kiertoteitä arjessa käytetään ja mitkä tarpeet eivät näy johdon tai IT:n näkökulmasta.

Hyvin fasilitoiduissa työpajoissa tätä tietoa voidaan hyödyntää vaatimusten määrittelyssä ilman, että järjestelmävalinnasta tulee eri käyttäjäryhmien toivelista. Liiketoiminnan tavoitteet muodostavat edelleen kehyksen, mutta henkilöstön kokemuksesta saadaan tärkeä osa päätöksenteon pohjaa.

Vain näin saadaan kattava kuva:

• mistä arjen haasteet syntyvät
• mitkä toiminnot ovat kriittisiä
• mitä ei saa muuttaa
• miten uusi järjestelmä voisi helpottaa työtä

Tämä myös vähentää muutosvastarintaa, joka on yksi yleisimmistä hankkeiden kompastuskivistä.

Järjestelmähankkeen onnistuminen pitää määritellä liiketoiminnan mittareilla

Järjestelmähankkeen onnistumista ei pitäisi mitata vain sillä, valmistuiko projekti aikataulussa ja budjetissa. Tärkeämpää on seurata, toteutuivatko ne hyödyt, joiden vuoksi hanke käynnistettiin: vähenikö manuaalinen työ, nopeutuiko prosessi, paraniko tiedon laatu, saiko johto paremman tilannekuvan tai paraniko asiakaskokemus.

Riippumaton asiantuntija tuo objektiivisuuden

Järjestelmätoimittajat ovat hyviä omissa tuotteissaan – mutta pk-yritys tarvitsee jonkun, joka katsoo kokonaisuutta yrityksen edun näkökulmasta.

Järjestelmätoimittajan tehtävänä on luonnollisesti osoittaa, miksi juuri heidän ratkaisunsa sopii asiakkaalle. Ostajan tehtäväksi jää arvioida, onko ratkaisu oikeasti sopiva suhteessa yrityksen tavoitteisiin, prosesseihin, muihin järjestelmiin, kustannuksiin ja tulevaisuuden tarpeisiin.

Riippumattoman asiantuntijan arvo korostuu juuri tässä välissä. Hänen tehtävänsä ei ole myydä tiettyä järjestelmää, vaan auttaa yritystä muodostamaan riittävä vaatimusmäärittely, vertailemaan vaihtoehtoja samoilla perusteilla ja haastamaan sekä toimittajia että tarvittaessa myös asiakkaan omia oletuksia.

Ulkopuolinen asiantuntija:

• kilpailuttaa ja vertaa toimittajia objektiivisesti
• arvioi ratkaisut liiketoiminnan, ei vain teknologian kautta
• tunnistaa riskit ennen kuin ne realisoituvat
• varmistaa, että dokumentaatio ja sopimukset ovat kunnossa

Tätä kautta yritys saa turvaa ja luottamusta siihen, että valittu ratkaisu on yrityksen tarpeisiin tarkoituksenmukaisin.

Joskus hyvä lopputulos voi olla myös se, ettei järjestelmää vielä vaihdeta. Nykyisen ratkaisun parempi hyödyntäminen, prosessin muuttaminen tai integraation rakentaminen voi tuottaa tavoitellun hyödyn huomattavasti pienemmällä investoinnilla.