Monessa yrityksessä liiketoiminnan kehitystarve muuttuu lopulta IT-hankkeeksi: nykyinen ERP ei taivu, muutokset ovat hitaita ja väliaikaisratkaisut kasvavat Excelien, sähköpostien ja erillisjärjestelmien verkostoksi. Silloin pöydälle nousee helposti suuri ERP-uudistus, vaikka lähtökohdan pitäisi olla eri: pitääkö koko järjestelmä todella vaihtaa, vai voisiko yrityksen toimintaa uudistaa yksi prosessi kerrallaan?

ERP-ongelma ei aina ole ERP-ongelma

Vanha ERP on helppo nimetä syylliseksi silloin, kun liiketoiminnan tarpeisiin vastaaminen kestää liian kauan. Uusi prosessi tarvitsisi järjestelmätukea, mutta muutos päätyy kehitysjonoon. Pieni toiminnallisuus vaatii määrittelyn, tarjouksen, projektin ja julkaisuikkunan. Siinä välissä prosessi hoidetaan Excelillä, sähköpostilla tai ihmisten muistilla, tai sitten muutos todetaan niin työlääksi, että prosessi jää pysyvästi manuaaliseksi.

Tästä syntyy helposti johtopäätös, että ERP on tullut tiensä päähän ja aletaan harkita koko järjestelmän uusimista.

Usein ongelma on kuitenkin hienovaraisempi. Järjestelmä voi edelleen hoitaa aivan hyvin sen tehtävän, jota varten se on rakennettu: esimerkiksi talouden, tilausten tai varaston ydintiedon. Pullonkaula syntyy siitä, että samaa järjestelmää yritetään käyttää myös kaikkien uusien liiketoimintatarpeiden toteuttamiseen.

Silloin ERP:stä on tullut paitsi järjestelmä myös muutoksen portinvartija.

Kaikkea ei tarvitse uusia kerralla

Perinteisessä ERP-uudistuksessa on vahva sisäinen logiikka. Kun järjestelmä vaihdetaan, prosessit, integraatiot ja data voidaan suunnitella uudelleen samalla kertaa.

Ongelma on muutoksen mittakaava.

Mitä enemmän toimintoja uudistus koskee, sitä enemmän siinä on keskinäisiä riippuvuuksia. Liiketoiminnan kehitystarpeet eivät kuitenkaan odota monivuotisen hankkeen valmistumista. Siksi organisaatiossa syntyy samaan aikaan kaksi todellisuutta: suuri tavoitetila tulevaisuudessa ja tämän päivän tarpeisiin rakennetut väliaikaisratkaisut.

Vaihtoehtoinen ajattelutapa on pitää nykyinen ERP aluksi paikallaan ja siirtää toiminnallisuuksia sen ympäriltä hallitusti uusiin sovelluksiin.

ERP voi säilyä esimerkiksi tiettyjen ydintietojen järjestelmänä samalla, kun käyttäjän päivittäinen työ tapahtuu yhä useammin sen ulkopuolella. Uusi sovellus lukee tarvittavat tiedot taustajärjestelmästä, hoitaa oman prosessinsa ja palauttaa tarvittavat muutokset takaisin.

Tämä muuttaa ERP-uudistuksen luonnetta. Yhden suuren korvausprojektin sijasta syntyy sarja rajattuja liiketoimintamuutoksia.

Ensimmäinen kysymys on: mitä ERP:n pitää edelleen omistaa?

Asteittainen modernisointi ei tarkoita satunnaisten sovellusten rakentamista vanhan järjestelmän ympärille. Jos arkkitehtuuria ei johdeta, seurauksena voi olla vain uudenlainen järjestelmäviidakko.

Siksi jokaisessa irrotettavassa prosessissa pitäisi ratkaista ainakin kolme asiaa.

• Ensimmäinen on tiedon omistajuus. Jos esimerkiksi tilaus on ERP:ssä yrityksen virallinen tietue, uuden sovelluksen pitää tietää, mikä tieto syntyy siinä ja mikä ERP:ssä.
• Toinen on prosessin omistajuus. Jonkun pitää pystyä määrittelemään, mitä prosessin kuuluu tehdä myös poikkeustilanteissa. Ei riitä, että määritellään ainoastaan miltä uuden käyttöliittymän pitäisi näyttää.
• Kolmas on integraation toimintamalli. Liiketoimintaprosessi ei saa pysähtyä vain siksi, että taustajärjestelmä on hetkellisesti poissa käytöstä, eikä samaa tietoa pitäisi joutua syöttämään käsin useaan paikkaan.

Virnexin VAID-alustassa tämä on ratkaistu niin, että uusi liiketoimintamoduuli voi toimia nykyisen ERP:n rinnalla. ERP voi säilyä esimerkiksi talouden, varaston ja tilausten system of recordina, kun uusi palvelu huolehtii omasta käyttäjäprosessistaan ja tietojen synkronoinnista. Olennaista on, että integraatio ei ole erillinen projekti tai kolmannen osapuolen väliohjelmisto, vaan sisäänrakennettu kyvykkyys VAID-alustassa.

Tästä seuraa viisi käytännön hyötyä:

• Liiketoimintaprosessi toimii myös silloin, kun ERP on hetkellisesti poissa käytöstä, koska VAID-palvelut jatkavat käyttäjien palvelemista itsenäisesti.
• Tieto päivittyy sekunneissa jatkuvana muutosvirtana yön yli ajettavien eräajojen sijaan.
• Käyttäjien ei tarvitse asioida ERP:ssä lainkaan, koska VAID ottaa vastaan kuorman, viiveet ja rajapintojen monimutkaisuuden.
• Yksikään kirjaus ei myöskään katoa, sillä jono uusii viestinvälityksen, kunnes ERP vahvistaa sen, jolloin molemmat päät pysyvät yhtenäisinä.
• Modernisointi ei myöskään edellytä yhtä yhteistä käyttöönottoviikonloppua.

Tekoäly nopeuttaa rakentamista, mutta ei poista arkkitehtuurin tarvetta

Tekoäly tekee tästä kehityksestä erityisen ajankohtaisen.

Sovelluksen käyttöliittymän, liiketoimintalogiikan tai integraation ensimmäinen versio voidaan rakentaa nyt huomattavasti aikaisempaa nopeammin. Se ei kuitenkaan tee satunnaisesta sovelluskehityksestä hyvää arkkitehtuuria.

Päinvastoin. Kun uusien ratkaisujen rakentamisen kynnys laskee, kasvaa tarve päättää, millä periaatteilla niitä tehdään.

Kuka saa muuttaa prosessia? Kuka hyväksyy tuotantoon vietävän version? Miten ratkaisu testataan ja dokumentoidaan? Missä sen data sijaitsee? Miten käyttöoikeudet, lokit ja muutokset jäljitetään?

Näistä tulee olennaisempia kysymyksiä kuin siitä, kuinka nopeasti ensimmäinen demo saadaan ruudulle.

Modernisointia kannattaa ajatella kyvykkyyksinä, ei järjestelminä

IT-johdolle asteittaisen mallin kiinnostavin seuraus voi olla se, että investointien yksikkö muuttuu.

Sen sijaan että päätetään ensin järjestelmästä, voidaan lähteä yhdestä liiketoimintakyvykkyydestä: esimerkiksi tarjousprosessista, huollon varaosien hallinnasta, toimitusajan vahvistamisesta tai jostakin käsityöhön jääneestä sisäisestä prosessista.

Sille voidaan määritellä omistaja, tavoite ja rajapinta nykyisiin järjestelmiin. Vasta sitten päätetään, miten kyvykkyys toteutetaan.

Tällä on myös organisatorinen vaikutus. Prosessin omistajan rooli kasvaa, koska hänen pitää pystyä kuvaamaan mitä liiketoiminta tarvitsee. IT:n rooli puolestaan siirtyy yksittäisten muutospyyntöjen toteuttamisesta enemmän arkkitehtuurin, tietoturvan, integraatioiden ja hallitun muutoksen mahdollistamiseen.

VAIDin toimintamallissa prosessiomistaja kuvaa tarpeen, tekoälyagentit huolehtivat toteutuksesta ja asiantuntija hyväksyy muutoksen ennen tuotantoon vientiä. Ajatus on erottaa toisistaan liiketoiminnan päätös siitä, mitä tarvitaan, ja tekninen vastuu siitä, että ratkaisu rakennetaan oikein ja hallitusti.

Tavoitteena ei ole päästä eroon ERP:stä

Asteittaisen modernisoinnin päämääräksi ei kannata asettaa ERP:n poistamista.

Parempi tavoite on palauttaa ERP sille kuuluvaan rooliin ja rakentaa sen ympärille kyky muuttaa toimintaa ilman, että jokaisesta muutoksesta syntyy uusi ERP-projekti.

Joissakin yrityksissä kehitys voi lopulta johtaa siihen, että vanhan ERP:n yksittäisiä moduuleja voidaan poistaa käytöstä. Toisissa ydinalusta voi jatkaa taustalla vielä pitkään. Olennaista on, ettei koko yrityksen muutosnopeus ole enää sidottu yhden järjestelmän elinkaareen.

Silloin myös ERP-uudistuksen lähtökysymys muuttuu.

Ei enää: Millä järjestelmällä korvaamme nykyisen?

Vaan: Minkä liiketoimintakyvykkyyden haluamme pystyä muuttamaan seuraavaksi?

Kiinnostuitko? Verkkosivuiltamme löydät lisää tietoa VAID-alustasta. Voit myös pyytää meiltä ilmaisen esittelyn.