ERP-hanketta pääsee harvoin suunnittelemaan puhtaalta pöydältä. Useimmiten hankkeissa on kyseessä korvausprojekti, jossa ympäröivien järjestelmien ja toimittajien määrät ovat päässeet kuin varkain vuosien aikana kasvamaan ja eri osien kehittäminen eteenpäin on hankalaa. Tällaisessa tilanteessa toimittajariippumaton neuvonantaja voi olla kullanarvoinen kumppani.
Kaikki yhdestä paikasta?
Asiakkaiden ajatus projektin alussa voi olla vähentää toimittajien ja järjestelmien määrää ja siten helpottaa omaa arkeaan. Uskotaan, että kun ostetaan kaikki tarpeellinen yhdestä paikasta, saadaan toimittajien hallinta ja kehittäminen sujuvammaksi, nopeammaksi ja ehkä jopa edullisemmaksi.
Mutta miksi niin ei aina käy? Asiakkaan toimiala, liiketoiminta ja tarpeet vaikuttavat siihen, millainen arkkitehtuuri kannattaa rakentaa. Yksi mahdollisimman kattava toiminnanohjausjärjestelmä voi kuulostaa hyvältä, mutta sopiiko se yrityksen arkeen ja siellä hoidettaviin prosesseihin parhaalla tavalla? Jos järjestelmää käytetään ensisijaisesti talouden prosessien tai projektitoimitusten hallintaan, yhden ns. ”yleiserpin” perustoiminnallisuudet voivat hyvinkin riittää.
Yksi ERP-järjestelmä ei kuitenkaan ole aina välttämättä paras ratkaisu. Valintaa tulisi tarkastella sitä vasten, missä liiketoiminnan kohdissa on suurimmat kehittämisen tarpeet tai mahdollisuudet. Tavoitteena voi olla saada keskeisimmät tiedot ja toiminnallisuudet keskitettyä ja välttää hankalia järjestelmien välisiä integraatiota. On silti ymmärrettävä, että pakettiin kuuluvien toiminnallisuuksien osalta kehityksen nopeus sidotaan aina valittavan paketin tulevaan kehitykseen.
Käyttäjien näkökulmat huomioon
Joskus käy niin, että kun ERP:iä hankitaan tai vaihdetaan, keskitytään vaihtoehtojen toiminnallisuuksiin, peilaten niitä aikaisemman järjestelmän ongelmiin. Ohjelmiston vaihtaminen edellyttää kuitenkin hyvää käsitystä siitä, mikä on aidosti oleellista liiketoiminnan kehittämisen kannalta.
Pidempään käytössä olleen ratkaisun kohdalla liiketoiminta on jo voinut kehittyä paljonkin eteenpäin. Yrityksessä henkilöt tekevät kuitenkin päivittäin töitä vanhan järjestelmän rajoitteiden ohjaamina. Tällöin heidän voi olla vaikea kuvata uuden järjestelmän vaatimuksia. Tässä tilanteessa keskitytään helposti nykyjärjestelmän puutteisiin, jotka halutaan ehdottomasti ”korjata” uudessa järjestelmässä.
Hankkeen suunnitteluvaiheessa tehtävässä mallinnuksessa ei tavoitteena ole täydelliset kuvaukset, vaan riittää, että kaikki osapuolet liiketoiminnasta toimittajiin pystyvät niiden avulla käymään keskustelua. Hyvä kumppani auttaa löytämään ne paikat, joissa on eniten epäselvyyttä.
Vaatimusten priorisointi on hyvä tehdä niin, että hanketta voidaan myös rajata tai vaiheistaa. Tällöin ei myöskään ole tarpeen laskea vaatimuksissa rimaa turhan alas, jolloin karsitaan vaatimuksista ”väärästä päästä”. Usein kehittämisessä aiemmin mukana olleilla henkilöillä on käsitys, että jokin vaatimus on kallis, vaikka tarvittava toiminnallisuus saattaakin olla uudessa paketissa vakiona. Asiat, jotka aikaisemmin ovat olleet hankalia toteuttaa, voivat olla uusien ERP-ratkaisujen tarjoamilla alustoilla huomattavasti yksinkertaisempia.
On myös syytä miettiä, paljonko eri toiminnoilla on käyttäjiä ja miten usein he näitä toimintoja käyttävät. Jos kolme henkilöä käyttää taloushallinnon toiminnallisuutta ja projekteissa puolestaan 300 henkilöä, minkä ryhmän kriteerit vaikuttavat järjestelmän tai järjestelmien valintaan eniten? Vastaavasti, jos yrityksen taloushallinnon ammattilaiset käyttävät järjestelmää päivittäin, voivat he omaksua monimutkaisemmankin järjestelmän käytön hyvällä koulutuksella. Jos firman muut työntekijät käyttävät järjestelmää kerran tai kaksi kuussa, muodostuu käytöstä helposti iso kynnys näille käyttäjäryhmille.
Entäpä freelancerit, konsultit ja muut ulkopuoliset kumppanit, joita yrityksissä usein työskentelee? Jo määritysvaiheessa pitäisi miettiä, miten he pääsevät näppärästi ja turvallisesti käsiksi tarvitsemaansa tietoon. Millainen on heidän käyttöliittymänsä?
ERP:in valintavaiheessa kannattaa tarkastella, miten se tukee yrityksessä käytössä olevia muita järjestelmiä. ERP:issä voi olla vaikkapa markkinointiautomaation ominaisuuksia, mutta käyttäjien kannalta ne eivät välttämättä ole joustavia, sujuvia ja riittävän nopeasti kehittyviä. Joihinkin tehtäviin voi olla järkevämpää valita niihin kehitetty erikoistyökalu. Näissäkin kohdissa on tärkeää tietää, millä kriteereillä erikoisratkaisuja ostetaan ja kuka niitä hallinnoi: tarvitaan pelisäännöt ja ainakin keskeisimmät yritysarkkitehtuurin kuvaukset ja linjaukset.
Mitä riippumaton arkkitehti tuo määritys- ja valintatilanteeseen?
Osaava arkkitehti katsoo yrityksen toimintojen kokonaisuutta ja auttaa määrittämään keskeisimmät käyttötilanteet ja toiminnallisuudet nyky- ja tavoitetilassa. Hän auttaa yritystä hahmottamaan etenemismahdollisuuksia luomalla etenemissuunnitelman. Neutraali, ulkopuolinen kumppani voi myös helpottaa sisäisiä keskusteluja ja arviointeja.
Riippumaton arkkitehti tuo yritykseen kokonaisarkkitehtuurin näkökulman. Hän näkee myös tulevien toiminnallisuuksien tarpeet. Hän ei tuota vain järjestelmäkuvia, vaan osapuolien välistä keskustelua tukevia kuvauksia. Yrityksen parasta hakeva arkkitehti ei tee, mitä pyydetään, vaan mitä tarvitaan.
Ilkka Lilius
Ilkka on toinen Reflectorin perustajajäsenistä ja laaja-alainen arkkitehti, joka on toiminut eri rooleissa tietojärjestelmien kehityshankkeissa. Ilkka on tiimin rakentaja, tulkki ja koordinaattori, joka pystyy ymmärtämään laajasti eri toimijoiden näkökulmat.
