S/4HANA-hankkeeseen valmistautuminen vaiheittain

SAP S/4HANA -siirtymähankkeessa on kyse liiketoiminnan transformaatiosta. Kuinka siihen kannattaisi valmistautua, ja kuinka kauan varata aikaa suunnittelulle ja toteutukselle, kun SAP:n asettama takaraja on vuonna 2025?

Kirjoitimme äskettäin S/4HANA-siirtymähankkeeseen liittyvän oppaan, jossa keskityimme S/4HANA-transformaation hyötyihin ja vaihtoehtoisiin toteuttamistapoihin, ja analysoimme eri ajureita, jotka ohjaavat hankkeelle valittavaa lähestymistapaa. Mutta miten SAP-käyttäjäorganisaation pitäisi toteuttaa itse hankkeen valmistelu – eli miten varmistaa SAP S/4HANA -hankkeen onnistunut käynnistäminen organisaationne tavoitteiden mukaisesti?

S/4HANA:an siirtyminen on liiketoiminnan transformaatio. Suunnitteluun ja valmisteluun on realistista varata 1–2 vuotta, riippuen hankkeen ja investoinnin kokoluokasta ja vaikutuksista liiketoimintaan. Sen jälkeen itse S/4HANA-toteutusprojekti kestää tyypillisesti toiset 1–2 vuotta, isoissa ja monimutkaisissa organisaatiossa mahdollisesti jopa merkittävästi pidempään. Koska SAP on asettanut siirtymälle takarajan vuoteen 2025, hankkeen valmistelu on syytä käynnistää välittömästi.

Kun S/4HANA-transformaatiohanke ja siihen liittyvä suunnittelu ja valmistelu vaiheistetaan, päätöksiä voidaan tehdä hallitusti ja tarkentaa lähestymistapaa ja tavoitteita jatkuvasti uuden ja tarkemman tiedon pohjalta. Koko hankkeen taustalla on oltava ensisijaisesti liiketoiminnalle tuotettavat hyödyt.

Lähde liikkeelle IT:stä ja liiketoiminnan tavoitteista

IT:n kannalta ERP-alustan tulevaisuuden tavoitetilan ajureina ovat kokonaisarkkitehtuurin viiden vuoden tavoitetila, IT:ltä vaadittavat kyvykkyydet ja muut strategiset ohjaavat periaatteet, esimerkiksi pilvipalvelujen käytön suhteen. Toisaalta IT:ltä odotetaan jatkuvasti nopeampia versiopäivitys- ja julkaisusyklejä, joten erityistä huomiota jo suunnitteluvaiheessa pitää kiinnittää myös tulevan järjestelmän kehitysmalleihin. Siinä auttaa ketterien mallien ja esimerkiksi DevOpsin omaksuminen osaksi työtapoja.

Usein S/4HANA-hanke lähtee liikkeelle tietohallinnon puolelta, mutta liiketoiminnan mukaan saaminen on kriittistä. Valmistelun ensimmäisessä vaiheessa kannattaakin keskittyä vastaamaan kysymykseen ”Miksi?”

Liiketoiminnan kannalta oleellista on analysoida yrityksen strategiasta ja toimintamallista johdettuja kyvykkyysvaatimuksia, ja toisaalta tunnistaa mahdollisimman laajasti modernin teknologian mahdollisuudet ja hyödyt liiketoiminnalle.

Toimivaksi ja Capgeminin suosittelemaksi toimintamalliksi on osoittautunut hankkeen jaottelu karkeasti seuraaviin vaiheisiin:

1. Esiselvitys
2. Proof of Concept
3. Määrittelyprojekti
4. Toteutusprojekti
5. Jatkuva kehittäminen

Vaiheet eivät ole täysin erillisiä, vaan limittyvät. Seuraavaksi esittelemme siirtymävaiheiden mallin vaihe vaiheelta.

1. Esiselvitysvaihe – liiketoiminnan tavoitteet ja hyödyt

Esiselvitysvaiheessa keskitytään liiketoiminnan ja IT:n strategisiin tavoitteisiin sekä S/4HANA:n tuomiin hyötyihin, sen vaatimiin muutoksiin liiketoiminnan prosesseissa ja IT-arkkitehtuurissa, sekä määritetään määrittely- ja toteutusprojektien raamit.

Joissakin tapauksissa päätös S/4HANA:an siirtymisestä voidaan tehdä ilman konkreettista business casea, mutta useimmiten on kuitenkin syytä tarkastella tavoitteita ja vaikutuksia järjestelmällisesti. Business casen ydin ei käytännössä koskaan S/4HANAN:n tapauksessa muodostu kustannussäästöistä, vaan uuden alustan luomista mahdollisuuksista. Niiden kvantifioimiseen pitää varata riittävästi aikaa ja varmistaa liiketoiminnan tiivis mukanaolo.

2. Proof of Concept – varmuutta ja konkretiaa toteutustapaan

Proof of Concept (PoC) eli soveltuvuusselvitys on valinnainen vaihe, mutta monesti hyödyllinen. Jos siirtymä toteutetaan konversiona, PoC:lla saadaan ensikäden tietoa konversion monimutkaisuudesta, ja ennen kaikkea sen vaatimasta tuotantoympäristön seisokeista.

Jos siirtymä taas toteutetaan uusimplementointina, PoC monesti jakautuu niin, että erillisen vaiheen sijaan esiselvityksessä erilaisilla havainnollistuksilla (esimerkiksi esikonfiguroiduilla demo-ympäristöillä) hyötyjä ja teknologian mahdollisuuksia konkretisoidaan. Liiketoimintaa sitoutetaan ja innostetaan, ja toisaalta seuraavan vaiheen eli määrittelyprojektin yhteydessä rakennetaan hiekkalaatikkoympäristö tukemaan määrittelyä.

3. Määrittelyprojekti –uusimplementoinnin tarkentaja

Määrittelyprojekti on mielekäs toteuttaa erillisenä projektina osana uusimplementointia, sillä silloin tulevan järjestelmän toiminnallinen ja tekninen laajuus ja lopullinen käyttöönoton suunnittelu tulee tehdyksi huolellisesti. Siten itse toteutusprojektin investointipäätös voidaan tehdä mahdollisimman tarkan aikataulun ja budjetin perusteella.

Tällainen vesiputousmallista johdettu rakenne saattaa nykypäivänä tuntua kömpelöltä. Usein on kuitenkin epärealistista hakea miljoonaluokan investoinnille hyväksyntää, ellei lopputuloksesta ole riittävän tarkkaa ymmärrystä. Ehkä jo lähitulevaisuudessa myös isoja ERP-hankkeita voidaan käynnistää puhtaasti ketterien menetelmien pohjalta – nykypäivänä käytännössä aina nojaudutaan hybridimalleihin.

Suoraviivaisessa teknisessä konversiototeutuksessa määrittelyprojektia ei tyypillisesti eriytetä omaksi vaiheekseen, mutta mahdolliseen PoC-vaiheeseen voidaan silloin sisällyttää määrittelyprojektin elementtejä.

4. Toteutusprojekti – kun transformaatio tapahtuu

Toteutusprojekti nimensä mukaisesti toteuttaa S/4HANA-transformaation.

Vaikka luonnollisesti suurin osa kustannuksista ja ajasta kuluu tässä vaiheessa, on tärkeää huomata, että strategiset linjaukset ja päätökset tehdään pääosin jo edeltävissä vaiheissa. Niitä ei siis pidä aliarvioida tai aliresursoida! Yhtälailla huolellinen työ edeltävissä vaiheissa mahdollistaa onnistuneen toteutusprojektin ja nopean siirtymisen jatkuvan kehittämisen vaiheeseen.

Jos toteutusprojekti uhkaa paisua liian suureksi, on se syytä pilkkoa osiin. Käytäntö ja kokemus ovat osoittaneet, että nykymaailmassa liiketoiminnan tarpeet ja myös ERP:n ulkopuolinen IT-ympäristö muuttuvat niin nopeasti, että liian suureksi kasvava ja hitaasti etenevä ERP-projekti ei välttämättä valmistu koskaan. Valitsemalla oikeat arkkitehtuurikäytännöt ja kehittämismenetelmät ja panostamalla testiautomaatioon voidaan isojakin toistuvia käyttöönottoja tehdä luottavaisin mielin, ilman pelkoa häiriöistä jo tuotantokäytössä oleville osuuksille.

5. Jatkuva kehittäminen – tranformaatio ei lopu kuin seinään

Jatkuva kehittäminen mahdollistaa responsiivisen alustan ja järjestelmän, joka tukee liiketoimintaa joustavasti ja ketterästi. Sen edellytyksenä on oikeanlainen arkkitehtuuri ja alusta asti uusiutuvaksi suunniteltu ja rakennettu järjestelmä, sekä organisaation kyvykkyydet järjestelmän jatkuvaan päivittämiseen ja ylläpitoon.

Onnistuminen tässä vaiheessa on kaikkea muuta kuin itsestäänselvää. Kestävästi ylläpidettävä ja jatkuvasti kehitettävä järjestelmä täytyykin huomioida S/4HANA-hankkeen alusta asti yhtenä tärkeimmistä, ellei tärkeimpänä, tavoitteista.

Tukea S/4HANA-siirtymän vaiheistamiseen