Blogi

Tunnista ERP-projektien inhimilliset ja tekniset haasteet

Joonas Pajunen Bisnes Teknologia

Koodaajat työskentelevät koneella Koodaajia istuu sohvalla

"ERP-projekti ei ole ERP-projekti, ellei joku saa sen päätyttyä kenkää."
– vanha viidakon sanonta

Toiminnanohjausjärjestelmien uudistusprojektit ovat haastavia. Ei siksi, että niiden tarvitsema teknologia, integraatiot tai prosessit olisivat ylitsepääsemättömän vaikeita. Hankaluudet syntyvät usein ihmisten keskuudessa järjestelmän tuomien muutosten mukana. Jos järjestelmän mukana muuttuvat myös työntekijöiden työnkuvat ja tekemisen mallit, miten ihmiset saadaan omaksumaan ja hyväksymään muutokset? Entä millaisia muita onnistumisen edellytyksiä ERP-projekteissa usein kannattaa ottaa huomioon? Oman kokemukseni mukaan onnistumiseen vaikuttavat niin teknologiavalinnat, muutoksen läpivieminen kuin ihmisnäkökulma.

ERP-uudistuksen taustalla toiminnan tehostaminen

Toiminnanohjausjärjestelmiä otetaan käyttöön tai uudistetaan yleensä toiminnan tehostamisen parantamiseksi. Tämä voi tarkoittaa työnkuvien muuttumista tai jopa katoamista. Oman työminän muutos voi johtaa suoraan tai alitajuisesti henkisen vastarinnan syntymiseen.

Pahimmassa tapauksessa muutosvastarinta voi aiheuttaa sen, että uuden järjestelmän määritystyötä tehdään vääristä lähtökohdista. Sen sijaan, että määritystä tehtäisiin parhaan mahdollisen tiedon pohjalta, voidaan erehtyä raiteille, jossa ihmiset eri puolilla organisaatiota suojelevat omaa rooliaan tai totuttuja tapoja. Tällöin päätöksiä ei välttämättä tehdä organisaation parhaaksi, vaan omien pelkojen sanelemana.

ERP-projektin investointi on yritykselle yleensä todella merkittävä. BearingPointin tutkimuksen mukaan budjetti voi olla jopa 90 % IT-budjetista tai 50 % yrityksen koko budjetista. Tällaisen projektin onnistuminen on vastuussa oleville henkilöille hyvin tärkeä osa omassa työssään onnistumista. Koska ERP-hanke kestää usein vuosia, sen psykologiset vaikutukset korostuvat.

Ihmisten kuunteleminen muutoksessa vähentää jännitteitä

Ulkopuolelta saneltu muutos, joka vaikuttaa ihmisen työnkuvaan voi aiheuttaa vastareaktion tai säikäyttää. Jos vastuista siirretään muualle (ihmiselle, järjestelmälle tai työ poistuu kokonaan), voi työntekijä kokea, että omaa työtä ei ole arvostettu. Mikäli taas vastuut kasvaa ilman keskustelua kompensaatiomuutoksista, voi muutokset tuntua epäreilulta. Autonomian vähenemisestä voi kummuta kapinahenkinen vastareaktio muutoksia kohtaan.

Monesti, etenkin uuden järjestelmän käyttöönotossa, jotkin asiat saattavat olla erilaisuudestaan johtuen epäselviä. Epäselvyys voi johtaa tunteeseen, ettei osaa kyseistä asiaa. Tämä johtaa epävarmuuteen työssä onnistumisesta ja jopa pelkoon oman työn menettämisestä.

Kaikesta tästä syntyy jännitteitä järjestelmää kehittävien tai järjestelmän käyttöönotosta vastaavien ja prosessiin osallistumattomien ihmisten kesken. Jännite tulee pystyä käsitellä, sanoittaa ja purkaa mahdollisimman pian, ettei jännite itsessään aiheuta negatiivisia lieveilmiöitä muualla työpaikalla.

Kun ihmisten huolet ovat käsitelty tai vähintään huomioitu, on teknologiavalintojen aika. Nousseet huomiot vaikuttavat ihmisten odotuksiin järjestelmän käytettävyydestä ja siihen miten liiketoiminnallisia asioita käsitellään järjestelmässä. Vastaako valitun teknologian mukanaan tuomat konseptit henkilöstön tapaa ymmärtää yrityksen bisnes? Jopa sanoilla ja termeillä on merkitystä.

Teknologia valitaan tavoitteiden, tarpeiden ja tulevaisuuden pohjalta

ERP-projektin teknologiavalintojen tulee vastata toki tulevien käyttäjien tarpeita, mutta erityisesti liiketoiminnan laaja-alaisia vaatimuksia. Onko teknologia jokin olemassaoleva ERP-järjestelmä vai kannattaako järjestelmä rakentaa tyhjästä juuri oman bisneksen tarpeeseen?

1. Olemassa oleva järjestelmä

Olemassa olevan järjestelmän valitseminen on etupainotteisesti halvempaa. Näitä järjestelmiä yleensä räätälöidään vastaamaan omaa tarvetta, ja räätälöinti on todennäköisesti halvempaa kuin järjestelmän rakentaminen itse. Riippumatta räätälöinnin määrästä, lopputulos on kuitenkin se, että käyttöön tuleva tuote on pääperiaatteiltaan ja käytettävyydeltään valitun tuotteen mukainen. Olemassa olevan järjestelmän mukana tulee luonnollisesti hintalappu, joka nykypäivänä tarkoittaa jatkuvaa kustannusta ja joka todennäköisesti perustuu käyttäjien määrään. Mitä isompi on organisaatio, sitä kalliimmaksi tämä valinta tulee.

Riippumatta räätälöinnin määrästä, on valmiissa järjestelmässä jokin ennalta määrätty tapa hoitaa toiminnanohjausta. Kyseistä järjestelmää kehittäessä ja käyttäessä on joku tai jotkin tahot miettineet ja iteroineet prosesseja, käytettävyyttä, sääntöjä, terminologiaa, ynnä muita spesifiä osaamista vaativia konsepteja. Valmiin järjestelmän hankkiessa saa siis myös tätä tietotaitoa ja yleensä myös relevanttia koulutusta järjestelmän käyttöön.

2. Oma itse rakennettu järjestelmä

Oman ERP:n rakentaminen on kallista. Itse sovelluskehitys ja -suunnittelu maksaa todennäköisesti satoja tuhansia, ja itse järjestelmän määrittelytyö vie aikaa itse ostajalta. Lopputuloksena on käyttäjilleen juuri sopiva järjestelmä, jota voi myös jatkokehittää haluamaansa suuntaan. Omistamaansa palvelua voi mahdollisesti jopa lisensoida ja myydä eteenpäin. Jatkuvilta kustannuksilta ei tulla silti säästymään, sillä kaikki järjestelmät vaativat jonkinlaista jatkokehitystä tai ylläpitoa, vaikkei näkyviä muutoksia tehtäisikään. Mitä suurempi organisaatio, sitä kriittisempää on oma ja valitun kumppanien osaaminen järjestelmien rakentamisessa ja niiden käyttöönotossa.

Itse rakennetussa järjestelmässä kaikki määrittely ja liiketoiminnan tarpeet täytyy ensin ymmärtää itse. Ymmärrys täytyy osata määrittää sääntöinä, prosesseina, rooleina, datamalleina, yms. Nämä asiat voi tehdä huonosti tai pahimmillaan väärin – ongelma, jota valmiissa järjestelmässä ei ole.

3. Olemassa olevan järjestelmän päälle rakennettu kerros

Kolmas edellisten vaihtoehtojen yhdistelmä on ottaa valmis järjestelmä ja rakentaa sen päälle oma käyttöliittymä sekä tietyt omat lainalaisuudet. Tällä valinnalla saavutetaan pienemmät kehityskustannukset ja itselle sopivampi käyttökokemus, mutta jatkoa ajatellen huolehdittavaksi jää sekä lisenssikulut että oman järjestelmän jatkokehityskulut, vaikka kevyempiä ovatkin. Prosessit ja ns. pellin alla olevat yksityiskohtaiset toiminnallisuudet ovat valmiiksi mietitty, ja itse voi keskittyä omien tärkeimpien prosessien parantamiseen ja oman kilpailuedun korostamiseen.

Toiminnanohjausjärjestelmän uudistuksen ei tule lähteä pelkästään teknologisesta tarpeesta, ellei olemassaoleva teknologia hajoa käsiin tai aiheuta jotain muuta suurta riskiä esimerkiksi tietoturvaan liittyen. Vaikka tarve olisikin alun perin teknologialähtöinen, tulee muutos koskemaan ihmisiä. Onnistuakseen tulee muutoksessa osallistaa ne ihmiset, joihin järjestelmän uudistus vaikuttaa. Ihmisten osallistaminen tulee olla johdonmukaista ja sillä tulee olla selvä vaikutus lopputulokseen. ERP-hankkeiden koon takia muutoksessa tarvitaan järjestelmällisyyttä. 

Järjestelmällisyys vaatii selkeyttä rooleissa ja vastuissa

Suuren hankkeen onnistumisessa tärkeintä on suunnitelmallisuus ja järjestelmällisyys. Suunnitelmat muuttuvat ja järjestelmällisyys pitää huolen, että suunnitelmien muutosta voidaan johtaa oikeaan suuntaan.

Omien kokemuksieni mukaan toistuvin ongelma IT-hankkeiden onnistumisessa on siihen tarvittavaan jatkuvaan määrittelytyöhön varattavan ajan aliarviointi. Tuoteomistajalla on liian usein liian monta hattua, ja ilman selkeää visiota ja siitä kumpuavia päätöksiä, käytetty aika ja raha kohdistuu vääriin asioihin.

ERP-projektissa on lähes aina kyse monesta sidosryhmästä, integraatioista toisiin järjestelmiin ja jonkin olemassa olevan liiketoimintakriittisen asian parantamisesta. Tällaisessa ympäristössä ei kannata larpata startupia eikä sokeasti soveltaa yliketterää asioiden viime hetkellä määrittelyä. Usein monivuotiselle hankkeelle tarvitaan kunnon suunnitelma, mutta suunnitelmaa tulee toteuttaa ketterästi ja muutoskyvykkäästi.

Useiden sidosryhmien takia asioiden määrittely ja kunnollinen dokumentointi on elintärkeää. Tehdyt päätökset ja niiden myöhempi käsittely eri sidosryhmien näkökulmasta tulevat vaatimaan joko näitä dokumentaatioita tai rajattomasti keskustelua sekä palavereja. Dokumentointia ei tule ajatella teknisenä toimenpiteenä, vaan ihmisten välisenä kommunikaationa. Dokumentaatiot ovat muistiinpanojen kaltaisesti myös kommunikaatiota tulevaisuuden itsesi kanssa.

Valmistaudu siihen, että jotain menee kuitenkin pieleen

Palatakseni takaisin alkuun – onko järjestelmänne kehityksessä huomioitu prosessien, talousasioiden ja teknologisten valintojen lisäksi ihmisten psykologiset tarpeet?

Etupainotteinen osallistaminen sekä aktiivinen jännitteiden käsittely mahdollistavat onnistuneen käyttöönoton. Silti jotain menee todennäköisesti pieleen. Ihmiset ovat kiireisiä tai muuten keskittyneet omaan työhönsä. Heidän näkökulmastaan toiminnanohjausjärjestelmän kehittäminen on sivuseikka, kunnes tulee testaamisen tai käyttöönoton aika.

Kaikesta valmistelusta huolimatta, tulee käyttöönoton ja kehittämisen yhteydessä projektin läpiviejillä olla valmius sekä kärsivällisyys toistaa viestejään monella eri tasolla; yksilön huolista organisaatiotason muutosten sanoittamiseen.