ERP-projektissa kannattaa katsoa IT:tä kokonaisuutena

Kun yrityksen IT-ydin eli ERP vaihtuu, on vaikea välttyä säteileviltä muutoksilta. Ydin on määritelmällisestikin kiinni lähes kaikessa, ja kunnianhimo ”kaiken korjaamisesta kerralla” vie helposti turmioon. Samalla ERP-uudistus on myös iso mahdollisuus, joka pitää vain osata käyttää oikein.

ERP-hankkeet näyttäytyvät helposti massiivisina, ja mitään välipaloja ne eivät ole kenellekään. Esimerkiksi BearingPointin Suomen ERP-markkinoita koskevassa selvityksessä todettiin, että keskimääräinen ERP-investointi oli luokkaa 15 miljoonaa euroa ja helposti kolmannes IT-budjetista. Mitä tällä uudistuksella siis saadaan?

Devisioonan kokemuksen mukaan valtaosa uudistuksista lähtee liikkeelle kahdesta ajatuksesta: Vanhan ERPin tukeminen käy liian kalliiksi, ja eihän se oikeastaan taivukaan siihen, mitä nykyään haluamme tehdä (BearingPointin selvitys löysi saman trendin: 88 % vastaajista tuskaili elinkaariongelmien kanssa, ja 62 % koki ERPin tukevan liiketoimintamallia liian huonosti). Molemmat ongelmat ovat luonteeltaan sellaisia, että kokonaisuudistus tuntuu luonnolliselta reseptiltä.

Mutta ratkeavatko ongelmat investoimalla miljoona tai 15? Tai peräti 150?

Onnistujat ovat usein hyviä liimaajia

Normaalia sovellusta pidetään pitkäikäisenä jo 5–10 vuoden kohdalla. ERP voi elää helposti tupla- tai peräti triplavuodet. Mutta jos melkein kaksi kolmannesta nyky-ERPeistä ei tue liiketoimintaa tarpeeksi hyvin, niin kuinka todennäköisesti juuri tällä kertaa onnistutaan rakentamaan kaikki sietämään seuraavan 15 vuoden venymistarpeet?

Kunnianhimoisimmissa projekteissa samalle alustalle viedään kaikki, ja onnistuessaan lopputulokset ovat erinomaisia. Toisaalta nämä onnistumiset tulevat usein lompakon kautta; tyypillisempi taitaa olla se tilanne, jossa osa liiketoimintatarpeiden omistajista jää nuolemaan käpäliään, kun jokainen data-alkio tai prosessi ei sopinutkaan ERPin aikatauluun tai budjettiin. Tämä saattaa olla pelastuskin: ERPin sisään naulattua toimintatapaa ei yleensä kovin herkästi muutella, joten myös liiketoiminnan maturiteettia on hyvä tarkastella: Minkä asioiden jäykistäminen ja normalisointi tuottaa eniten arvoa?

Tyypillisempi onnistuminen taitaakin tulla sitä kautta, että ERPiä tehdessä on ollut viisautta hahmottaa, miten varautua liiketoiminnan tuleviin muutoksiin, ja harkita hankelaajuutta siltä pohjalta. Joustoa tarvitsevien ja ei-kriittisten osien jättäminen ERPin ulkopuolelle voi sekä tuoda ketteryyttä tulevaisuuteen että myös vähentää mammuttihankkeen riskejä.

Integraatiot kuuluvat keskusteluun

Vaikka lompakko olisi miten tuhti ja kunnianhimon taso korkealla, kaikkea ei koskaan viedä yhteen järjestelmään. ERP on aina monien tietovirtojen lähde ja kohde, ja siksi integraatioista on puhuttava. Monesti puhe on myös lähellä kiroilua: integraatioihin koetaan liittyvän riskejä ja murheita.

Devisioonan näkökulmasta integraatioiden parjaaminen on turhaa – oikeastaan viestinviejän ampumista. Kyse on lopulta siitä, että integraatiotyö paljastaa ne kohdat, jossa järjestelmien yhteyksiä ei ole suunniteltu oikein. Datan omistajuus voi olla hakoteillä, järjestelmien välisissä siirtymissä katoaa tietoa – tai tiedon oikeita käyttötapoja ei yksinkertaisesti tiedä kukaan. Oikea kysymys onkin se, miksi näiden ongelmien annetaan paljastua vasta niin myöhään? Vastaus kietoutuu usein integraatiosotkun aukomisen turhauttavuuteen.

Moniin tilanteisiin voisi suositella hyvää ennakkoharkintaa. Jos ERP-projekti starttaa vuonna 2025, mitä jos alettaisiin katsoa integraatioita kuntoon jo vuonna 2024? Että jos ERP-projektiin mentäisiinkin niin, että integraatioiden nykytila on kaikilla selvästi mielessä, tuleva integraatioarkkitehtuuri tuotannossa ja heikoimmat kohdat valmiiksi korjattuna? Voisiko osan sovelluksista jopa eristää siten, ettei ERP-projektin muutostarve säteilisi niiden rajapintoihin enää ollenkaan?

”Mutta silloinhan käytetään rahaa vanhoihin integraatioihin, jotka korvataan kohta kuitenkin!” – tyypillinen vasta-argumentti, eikä ihan huono. Toisaalta: Aina voi harkita, paljonko kannattaa korjata. Pääasia on se harkinta: että ydinjärjestelmien omistajat ja muut päätöksentekijät tuntisivat integraatioihin liittyvät käsitteet ja riskit jo ennen ERP-projektia, vaikka jotkut riskit hyväksyttäisiinkin osaksi itse hanketta. Väitän, että alkuvaiheen pienet yli-investoinnit kompensoituvat usein sillä, että se kallis megaprojekti pysyy paremmin hanskassa.

Sektorisovelluksilla on arvonsa

ERP-hankkeen rajauksessa rannalle jääneitä liiketoiminnan omistajia ei kannata unohtaa. Ehkä tuotteiden markkinointitietorakenne on liian monimutkainen ERPiin vietäväksi? Ehkä kustannuslaskennan hallintaliittymien tekeminen ERPin sisälle maksaa liikaa hyötyyn nähden? Voi hyvin olla.

Vaikka nämä elementit pudotettaisiin pois itse ydinjärjestelmästä, investointi laadukkaisiin yksittäistä sektoria palveleviin sovelluksiin puoltaa silti usein paikkaansa. Näissä tilanteissa kannattaa myös olla teknologisesti avarakatseinen: Sillä rahalla, jolla ERPiin saadaan nihkeä Excel-klooni jonkin harvinaisemman tiedon ylläpitoon, voi hyvin onnistua tekemään laadukkaan räätälöidyn web-liittymän tai hyvinkin joustavan low code -toteutuksen.

ERP-projekti on usein erinomainen tilaisuus uudistaa myös sektorisovelluksia, kun liiketoimintaprosessit avataan joka tapauksessa. Projektin hallinnan kannalta nämä rönsyt kuitenkin pelottavat, mikä onkin hyvä syy palata taas edelliseen kohtaan: kun integraatioalusta- ja rajapintanäkökulmia on mietitty etukäteen, ERP-hankkeen rinnalle voidaan pystyttää rinnakkaisprojekteja, jotka vähentävät päähankkeen kuormitusta, eivätkä silti muodosta siihen kovia riippuvuuksia.

Datan pitää aina olla yhteistä

2020-luvulla useimmat uudet ERPit ovat pilvessä, mikä on jo iso askel mm. datan saatavuuden kannalta. Toisaalta se, että periaatteessa kuka tahansa voisi päästä helposti ERPin rajapintoihin, ei tarkoita sitä, että kaikkien kannattaisi päästä sinne suoraan. Ehkä tilanne vaatii integraatiokerroksen, ehkä osa datasta virtaa keskitetyn tietovaraston (vaikkapa uuden Microsoft Fabricin) kautta. Mahdolliset integraatiokerrosratkaisutkin on suunniteltava nimenomaan tästä näkökulmasta: kaikki niiden kautta kulkeva data on saatava yhteiseen jakoon, jos sitä joku vain tarvitsee.

Joka tapauksessa olennainen suunnitteluperiaate jokaisessa ERP-uudistuksessa tulisi olla se, että datan pitäisi aina olla kaikille sovelluksille, käyttäjille ja muille työkuormille yhteisesti käytettävissä, sijaitsee sen master-varasto sitten ERPissä tai jossain muualla. Koneoppimismallit, tekoälysovellukset ja monet muut ratkaisut elävät datan avoimuudesta.

Kun BearingPoint kysyi selvityksessään syitä ERP-uudistuksiin, datapohjaiset syyt (rajapintojen ja datan puutteet jne.) olivat vasta syylistan pohjalla. Tämä johtunee osin myös vielä kypsymässä olevasta analytiikkakulttuurista, ja viiden vuoden päästä nämä puutteet olisi huomattu paljon terävämmin. Tämän päivän ERP-uudistuksissa kannattaa varautua jo seuraavaan aaltoon: kaikki data kaikille, mutta hyvin hallittuna niin laadun, pääsyoikeuksien kuin dokumentaationkin osalta.

Haluatko keskustella IT-palettisi tulevaisuudesta? Miettiä integraatioratkaisuja? Kehitellä sektorisovelluksia tai sovitella AI:ta kokonaispalettiin? Ota yhteyttä!

Lisää aiheesta