SAP

Implementoinnista inhimillisempää SAP Activaten avulla

Järjestelmämuutos on suuri haaste mille tahansa organisaatiolle. SAP-implementointien kohdalla vaikeuskerrointa lisäävät niin muuttuvat läpivientimallit kuin jo alkanut HANA & S/4HANA-kehityskin.

Vesiputousmallista SAP Activateen

SAPin implementointia tehtiin vuosikymmeniä niin sanotulla vesiputousmallilla. Vuosituhannen alussa siirryttiin ASAP-metodiin, joka sinänsä ei juuri poikennut aikaisemmasta, vaikka projektimalliin lisättiin ketterän kehityksen käytäntöjä eli sprinttejä.

ASAP-metodiin liittyi erittäin haastavia piirteitä. Käytännössä määrittelyt eli speksit (blueprintit) saatettiin lyödä lukkoon jopa vuosi ennen käyttöönottoa ja samalla jäädytettiin muu kehitys. Tänä nopeatempoisen kehityksen aikana tuntuu käsittämättömältä ajatus, että liiketoiminnassa tai organisaatiossa ei tapahtuisi – tai oikeammin tapahtuu ­– muutoksia tuona jäädytysaikana. Kehityksen huomiota jättäminen oli omiaan vieraannuttamaan liiketoiminnassa olevia SAPista eikä syyttä.

Pilviratkaisujen myötä SAP työsti projektin hallintaan liittyviä metodejaan. Ensin kehitettiin Launch, ja sen pohjalta SAP Activate. Tavoitteena oli luonnollisesti tehostaa implementointiprojekteja.

Activatea on mahdollista työstää sekä vesiputous- että ketterän kehityksen mallina. Kaikkein olennaisin ero on se, että määrittelyosa on korvattu edellisessä blogisarjan osassa kirjoittamallani fit-gab -vaiheella.

Activate mahdollistanee 40 prosentin kustannussäästöt

SAPin tutkimusorganisaation (SAP Activate Methodology Overview June 2018) mukaan Activate mahdollistanee 40 prosentin kustannus- ja työpanossäästöt, kun toimintatapaa verrataan ASAP-metodiin. Muita etuja ovat puolet nopeampi implementointi ja pienemmät riskit muun muassa valmispakettien käytön myötä. Laajempia S/4HANA -implementointeja on toteutettu globaalistikin vielä sangen vähän, joten käytäntö todentaa myöhemmin edellä mainitut tulokset.

Activate-malli sisältää SAPin omat työkalut ja menetelmät

Activate-malli sisältää seuraavat kuusi vaihetta, jotka eivät poikkea juurikaan mistään muusta sovellusimplementoinnin mallista. Merkittävin ero syntyy siitä, että SAP on kytkenyt omat työkalunsa ja menetelmänsä tähän malliin. Ilman niitä implementointia ei voida tehdä.

  1. Esiselvitys: Ratkaisuvaihtoehtojen kartoitus, ja tuloksena esimerkiksi uusi implementointi tai vanhan päivitys.
  2. Valmistelu: Organisoinnin suunnitteleminen ja malliyrityksen hyödyntäminen
  3. Fit-gap analyysi: Valitaan muun muassa käytettävät standardit ja otetaan huomioon niiden vaatimat muutokset.
  4. Toteutus: Sprinttien läpivienti iteraatioineen (Scrum), integraation suunnittelu, käyttöönoton valmistelu ja testausvaiheet.
  5. Käyttöönotto koulutuksineen
  6. Ylläpidon järjestelyt tukitoimineen

Case: Investointipäätös on yksinkertainen ja samalla hyvin monitahoinen

Vetämässäni HANA & S/4HANA -esiselvitysprojektissa asiakkaalla oli käytössään noin 10 vuotta vanha SAP/ECC ja ajan myötä laajaksi kasvanut integraatio eri järjestelmiin ja yhteistyökumppaneihin. He, kuten usein muutkin SAP-käyttäjäyhteisöt, olivat mukauttaneet eli räätälöineet Z-koodituksella järjestelmäänsä sangen paljon. Projekti käynnistettiin nykytila- ja tavoitetila-analyysillä. Yhtä aikaa toteutettiin järjestelmäkartoitus kolmannen osapuolen tuotteella.

Kolmannen osapuolen tuote valittiin, koska vastaava SAPin Readiness Check-työkalu tarjosi vähemmän vertailudataa analysoitavaksi. Molemmat hyödyntävät samaa SAPin agenttia, joka kerää datan eri tietokannoista. Värikkäiden projektivaiheiden jälkeen kykenimme vastaamaan asetettuihin miksi ja kuinka -kysymyksiin, mutta rehellisyyden nimissä yrityksen CIO ei uskonut tulosten riittävän investointipäätökseen vielä siinä vaiheessa.

Syy oli yksinkertainen ja silti niin monitahoinen. Asiakas tiesi, mihin nykyinen järjestelmä kykenee ja tunnisti lukuisia kehityskohteita prosesseissaan, mutta hyppy HANA-alustalle ja edelleen S/4HANAan oli liian suuri ja sisälsi liikaa kysymysmerkkejä. Räätälöintien tarve ja tulevaisuus jäi epäselväksi. Ei riitä, että tiedetään rivimäärät ja sijainnit, vaan ne olisi käytävä läpi transaktiotasolle asti vaihtoehtoineen. Myöskään tulosteita, liittymiä ja muita prosessiin vaikuttavia tekijöitä ei voi jättää huomiotta.

Harmaita hiuksia lisäsivät  SAPin kiharaiset tiekartat muun muassa HR/HCM-kehityksen suhteen. Ne eivät kuuluneet viime vuonna S/4HANAn kehitykseen, mutta kuluvana vuonna ne on otettu osaksi kehitettävien kohteiden listaa.

Asiakas jatkanee esiselvityksestä niin sanottuun hiekkalaatikko-testaukseen, jossa toteutetaan varsinainen migraatioharjoitus lukuisine testauskierroksineen. Tässä vaiheessa tukeudutaan SAPin työkaluihin ja menettelyihin.

Jokainen SAPin implementointi on oma tarinansa eikä ole kahta samanlaista toimintaympäristöä. Tärkeintä muutoksessa kohti HANA-maailmaa on tunnistaa yrityksen tarpeet, tavoitteet ja valita oikeat kumppanit viemään läpi hallittu siirtymä.

 

Tarvitsetko lisätietoa S/4 HANAn esiselvitysvaiheesta? Haluatko keskustella käyttöönotosta? Autamme mielellämme!

Ota yhteyttä blogipostauksen kirjoittaneeseen projektipäällikköömme Jari Laihoon joko puhelimitse 040 575 9088 tai sähköpostitse jari.laiho@project-it.fi

Jaa artikkeli: