Artikkeli liittyy Älykäs toiminnanohjaus -trendioppaaseemme, joka esittelee uusia suuntia, joita olemme tunnistaneet toimiessamme asiakkaidemme apuna toiminnanohjauksen kehityshankkeissa ja ERP-alustojen uudistusprojekteissa. Oppaan tarkoituksena on auttaa vastaavia hankkeita harkitsevia yrityspäättäjiä huomioimaan hankkeen onnistumisen kannalta oleelliset näkökulmat.
Tässä Ennakoiva valmistautuminen toiminnanohjaushankkeeseen -artikkelisarjan toisessa osassa pohdimme oman organisaation omaa resurssointia, datan laadun ja migraatioiden merkitystä toiminnanohjaushankkeeseen.
Oman organisaation resurssitarvetta toiminnanohjausjärjestelmähankkeessa ei pidä aliarvioida. Siksi pitää yhdessä ratkaisun toimittajan/toimittajakandidaattien kanssa käydä perusteellinen keskustelu järjestelmän vaihtoprojektin resurssien roolituksista. Käytännössä tämä suoritetaan esim. RACI-matriisiin kuvattujen vastuunjakojen avulla.
Nykyisissä tarjouspyynnöissä pyydetään monesti toimittajan työmäärien lisäksi arvioimaan asiakkaalta odotettava työmäärä. Nämä arviot joutuvat toimittajaehdokkaan monesti tekemään kokemusperäisesti ja siksi nuo yhteiset keskustelut on hyvä käydä todellisen tarpeen arvioimiseksi ja ymmärtämiseksi. Hyvin ennalta suunniteltu vastuunjako myös selkiyttää merkittävästi asioita siinä vaiheessa, kun itse projektiin ryhdytään.
Joskus esitetään sellaisia hieman perusteettomia toiveita, että toiminnanohjausjärjestelmän vaihto tulisi saada suoritettua pääosin toimittajan voimin vähien asiakasresurssien minimaalisella hyödyntämisellä. Mikäli kyseessä on tekninen järjestelmänvaihto yhdestä ratkaisusta toiseen samanlaiseen/samankaltaiseen, on tällä toiveella perusteita. Mikäli hankkeeseen sisältyy alussa mainittua toiminnallista muutosta, muodostaa tämä toive merkittävän riskin hankkeen onnistuneelle läpiviennille.
Kannattaa palauttaa mieleen aiemmin mainittu liiketoiminta- ja palvelumuotoilun hyödyntäminen. Mikäli näitä menetelmiä on käytetty, on samalla jo osa tulevasta käyttäjäkunnasta sitoutettu uusiin toimintamalleihin. Tavoitteena onkin, että nämä jo sitoutetut toimivat käyttöönottoprojektissa muutosagentteina, jotka levittävät tietoa toimintatavoista muuhun käyttäjäkuntaan.
Toiminnanohjausjärjestelmän vaihto on hanke, joka vaatii merkittävää panostusta asiakkaan resurssien osalta. Tähän pitää olla varautunut. Tätä varautumista on osaltaan yhteinen resurssien suunnittelu, missä pyritään pilkkomaan projekti paloiksi ja asemoimaan eri palaset kalenteriin asiakasresurssien saatavuus mahdollisimman tarkoin huomioiden.
Eräs vanhan kansan paikkansapitävistä sanonnoista on: ”kannettu vesi ei pysy kaivossa”. Tätä kannattaa resurssisuunnittelussa miettiä. Se, että toimittajaosapuoli tekee asiakkaalle kuuluvia töitä hankkeessa ei johda hyvään lopputulokseen. Tällaisessa tapauksessa käy helposti niin, että projektin läpiviennin jälkeen toimittava organisaatio siirtyy muihin hankkeisiin ja asiakasorganisaatio jää ihmettelemään järjestelmää, jota eivät oikeasti osaa hyödyntää. Tällöin tuskin alussa asetetut tavoitteet pystyvät täyttymään.
Jossain tilanteissa asiakkaan resurssitarvetta pyritään paikkaamaan palkkaamalla/vuokraamalla asiakasorganisaatioon resursseja projektin ajaksi. Tässä lähestymistavassa on ilmeinen sama vaara, mitä edellä kuvattiin pelkästään toimittajavetoisessa lähestymisessä. Joka tapauksessa pitää suunnitella jatkuvuus. Miten projektin aikana tehty työ osataan täysimääräisenä hyödyntää varsinaisen käyttöönottovaiheen jälkeen.
Tyypillinen hyötytavoite järjestelmähankkeelle on parantaa tiedolla johtamista ja sen reaaliaikaisuutta. Tämän rinnalla tulee muistaa, että tiedolla johtaminen toimi kunnolla vasta silloin kun käytettävissä oleva data on laadukasta.
Uusien järjestelmien käyttöönotossa panostetaan siihen, että uuden ratkaisun tuoma data kertyy jatkossa laadukkaasti. Tavoitteet saavuttaneissa järjestelmähankkeissa tässä on onnistuttukin. Sen sijaan korvattavissa nykyjärjestelmissä oleva aiemmin kertynyt data ei välttämättä olekaan riittävän laadukasta.
Korvattavien järjestelmien tietoja tarvitaan tyypillisesti joko perustiedoiksi tai avoimiksi tapahtumatiedoiksi uuteen järjestelmäratkaisuun. Suljettujen, loppuun käsiteltyjen tapahtumatietojen vastaanottamiseen ei nykyisissä valmisjärjestelmäratkaisuissa juurikaan ole käyttökelpoisia menetelmiä. Siksi nämä suljetut tapahtumat on pyrittävä hoitamaan muulla tavoin. Tästä lisää seuraavassa kappaleessa.
Olemassa olevan datan laatua arvioitaessa on erotettava kaksi eri tilannetta. Nykyjärjestelmässä oleva data voi olla liian puutteellista uuteen järjestelmäratkaisuun siirrettäväksi tai nykyjärjestelmän data voi olla suorastaan virheellistä.
Datan laatuun liittyviä välttämättömiä korjauksia voidaan aivan hyvin suunnitella ja useimmissa tapauksissa suorittaakin nykyjärjestelmän käytön aikana ennen tietojen siirtoa uuteen ratkaisuun.
Käsitellään esimerkkinä organisaation tuotetietoja. Nykyisin käytössä oleville korvattaville järjestelmille on hyvin tyypillistä, että niissä ei suoriteta tietojen elinkaaren hallintaa. Järjestelmään on kertynyt tietoja ”aikojen alusta” ja oleviin tietoihin perustuen ei kyetä automaattisesti valikoimaan, mitkä tiedoista ovat ajankohtaisia uuteen ratkaisuun siirrettäviksi. Tällöin voidaan jo nykyratkaisussa ”perata” tietoja ja luokitella niitä siirrettäviin/ei-siirrettäviin. Tämä sujuvoittaa tietojen transformaatiota uuden ratkaisun käyttöönotossa.
Toinen tilanne on sellainen, että tiedetään uuden ratkaisun tarvitsevan sellaisia tuotetietoja, jota vanha ratkaisu ei kata. Tässäkin pitää ennakkoon suunnitella, miten ja milloin puuttuvat tiedot rikastetaan.
Aiemmassa datan laatua koskevassa kappaleessa mainittiin, että uudet pakettitoiminnanohjausratkaisut eivät mielellä ota vastaan päätettyjä tapahtumia. Näiden automaattisiirtoa ei suositella tehtäväksi työläyden ja todennäköisesti huonon lopputuloksen vuoksi. Kuitenkin liiketoiminnan johtaminen perustuu katkeamattomaan analytiikkaan, myös ylitse järjestelmän vaihtojen.
Tässä vaiheessa on hyvä muistaa, että useat nykyisin käyttöön otettavat toiminnanohjausratkaisut ovat alustaratkaisuja. Nämä ovat osa kokonaisuutta, johon sisältyvät rinnakkaisina mm. integraatio- ja analytiikkapalvelut.
Nuo rinnakkaiset analytiikkapalvelut ovat keino säilyttää liiketoiminnan jatkuvuus analytiikan kautta. Vanhojen ratkaisujen tiedon voidaan projektissa viedä samaan data-alustaan, jonne uuden ratkaisun tiedot alkavat käytön myötä kertyä. Tämän ratkaisuvaihtoehdon onnistuminen edellyttää datan laatu kappaleessa kuvailtuja tiedon laatuun panostuksia.
Tämä menetelmä myös vaatii miettimään järjestelmähankkeiden vaiheistusta. Perinteinen, ei niin hyvä, toiminnanohjausratkaisun uudistus metodi on ollut tehdä operatiivinen ratkaisuosuus ensin ja kehittää tarvittava analytiikka ”joskus myöhemmin”. Tällaisessa perinteisessä mallissa on monesti käynyt niin, että analytiikkavaihetta ei ole jaksettu kehittää kunnolla ja koko ratkaisun hyötyä tästä syystä on jäänyt kyseenalaiseksi.
Mikäli on aiemmin jaksettu tehdä tietojärjestelmäarkkitehtuuri, on siinä voitu kuvata, että toiminnanohjausratkaisuksi valitaan jokin soveltuva palvelu ja analytiikkaratkaisuksi jokin siihen soveltuvat palvelu. Usein nämä palvelut löytyvät samasta alustaratkaisusta ja saman alustan eri palvelujen käytöllä on yleensä synergiaetuja erillisiin ratkaisuihin verrattuna.
Kun tämän jälkeen lähdetään toiminnanohjausjärjestelmähankkeeseen, ehkä tunnistetaan, että rinnalla tarvitaan myös analytiikkaratkaisu. Tämän jälkeen voidaan näitä hankkeita edistää sopivasti ajoitettuna niin, että vaadittu lopputulos saavutetaan. Nämä voidaan tehdä yhden taikka useamman toimittajan toimesta asiakkaan oman ohjauskyvykkyyden mukaan.
Lue myös ennakoiva valmistautuminen toiminnanohjaushankkeeseen -artikkelisarjan muut sisällöt:
Osa 1: Tavoitteiden asetanta antaa raamit toiminnanohjaushankkeen toteutukselle
Osa 3: Oikealla toimittajavalinnalla merkitystä toiminnanohjausprojektin onnistumiseen