S/4HANA-projektin läpileikkaus: Mitkä ovat onnistumisen avaimet?
Onpas tyhjä olo. Kuten aina projektin päätyttyä.
Olen juuri saanut onnistuneesti päätökseen S/4HANA-konversioprojektin. Nyt on hyvä hetki katsoa taaksepäin, mitkä olivat onnistumisen avaimia projektin eri vaiheissa.
Jokainen SAP ja asiakas on erilainen, ja ratkaistavia haasteita tulee väistämättä vastaan. Niistä kuitenkin päästään sujuvasti yli, kun projekti on suunniteltu huolellisesti ja osapuolet jakavat yhteisen päämäärän. Oman kokemukseni perusteella kehotan kiinnittämään huomiota erityisesti seuraaviin asioihin:
1. Huolehdi siitä, että toimittaja saa jo tarjousvaiheessa nähtäväkseen järjestelmäarkkitehtuurikartan.
On tärkeää, että toimittaja hahmottaa jo tässä vaiheessa, miten muutoksen kohteena oleva järjestelmä liittyy muihin järjestelmiin.
S4-konversiossa ja mahdollisessa hosting-kumppanin vaihdossa tullaan välttämättä koskemaan myös muihin liittyviin järjestelmiin, verkkoarkkitehtuuriin, levypalvelimiin ja liittymiin. Saatetaan siirtyä yrityksen domainin ulkopuolelle, ja yllättäen tarvitaan sertifikaatteja ja verkkoavaimia jaettavaksi. Kun tarjousvaiheessa saadaan kokonaisuudesta kattava kuva, osataan ennakoida oikeat henkilöt projektille. FICO-konsultti ei availe VPN-tunneleita tai portteja, kun data ei liiku.
Tässä vaiheessa on toimittajan on myös tärkeä tietää, kuinka SAP:n tuotetuki on asiakkaalla järjestetty. Ollaanko SAP:n tuen piirissä vai kumppanin kautta toimitetussa VAR-mallissa? Tämä vaikuttaa S4-projektissa SAP:n tuen saamiseen.
2. Yhteistyön alkuvaiheessa kannattaa varmistaa, että henkilökemia pelaa puolin ja toisin.
Luottamuksen on oltava vahvaa ja kaikkien projektin osallistujien motivoituneita. Kun viestintä on rehellistä ja suoraa alusta alkaen, ongelmiin pystytään puuttumaan varhaisessa vaiheessa ja voidaan keskittyä projektin eteenpäin viemiseen.
Hyvä luottamuksellinen suhde kantaa yli maantieteellisten rajojen. Päättyneessä projektissani työskentelin itse pääkaupunkiseudulta, asiakas Tampereelta, ja projektitiimi jakautui maantieteellisesti varsin laajalle. Meidän toimitusmalliin kuuluu, että etsimme avainrooleihin parhaat tekijät, ja aina he eivät ole lähimmän nurkan takana. Tiimi jakautui Espoon, Oulun, Milton Keynesin (UK), Sofian (Bulgaria) ja Delawaren (USA) välille. Onneksi on Skype.
3. Kun varsinainen projektitoimitus alkaa, on tärkeää, että asiakkaalla on hyvä ymmärrys omista prosesseistaan.
Jos ajantasaisia prosessikuvauksia ei ole olemassa, hyvä lähestymistapa saattaa asia kuntoon on tehdä kattava testaussuunnitelma sillä välin, kun toimittaja valmistelee migraatiota.
Testaussuunnitelma on joka tapauksessa oltava, ja sen tulee kuvastaa yrityksen toimintaa laajasti. Mieluiten se kattaa kaiken relevantin tekemisen SAP:ssa. Testauksessa tulee olla omat kohtansa vuoden vaihteelle, kauden vaihteelle, sisään ja ulos lähtevälle liikenteelle, mahdollisille yritysostoille (jos tarpeellista) sekä harvemmin tehtäville toiminnoille. Testausjärjestelmään kannattaa panostaa ja testaus vastuuttaa nimetylle henkilölle.
4. Migraatiovaiheessa testaussuunnitelma koeponnistetaan.
Ensimmäisellä testausrupeamalla, joka kannattaa tehdä laajana, voidaan suunnitelmaa vielä tarkentaa ja hioa.Tässä vaiheessa muodostetaan seuraavia testejä varten referenssipiste, johon tulevaa S4-testausta verrataan. Samalla testaajat palauttelevat mieleen harvemmin tehtyjä toimintoja.
Migraatiotestauksessa havaitaan myös mahdolliset vanhassa järjestelmässä olevat erityisyydet, joihin ei normaalissa käytössä tuotannollisella datalla törmätä. Esimerkiksi joidenkin aineistojen ajo järjestelmään ei ole toistuvasti mahdollista, vaan järjestelmä käyttäytyy odottamattomasti. Kun testaussuunnitelmassa on maininta tästä, ei S4-testauksissa pysähdytä ihmettelemään, että mites tämä nyt tälläin rikki on.
5. Jos projektissa joudutaan tekemään alustaan muutoksia, kannattaa ne ajoittaa osaksi migraatiota.
Kun järjestelmät siirretään uusille palvelimille klooneina, on alustaan tehtyjen muutosten havaitseminen helpompaa, koska kaiken tulisi toimia kuten ennenkin.
Tällaisia muutoksia on esimerkiksi siirtyminen Windows-palvelimista LINUX-palvelimiin, Kernel-tason nostot, tietokannan vaihdot ja niin edelleen. Näin muutokset saadaan hajautettua kahteen vaiheeseen ja vaikutukset suppiloitua paremmin. S4-konversiossa voidaan keskittyä olennaiseen ja esimerkiksi käyttöjärjestelmäpäivityksestä johtuvia erikoisuuksia on poissuljettuja korjattu jo migraatiovaiheessa.
6. Kun migraatiovaihe on käynnissä, kannattaa S4-hiekkalaatikon rakentaminen aloittaa.
Lähtökohdaksi voidaan esimerkiksi ottaa projektin alkuajalta tuotantokopio, josta testijärjestelmä on tuoreistettu.
Ensimmäisen konversion tekeminen kaikkine temppuineen ottaa aikaa. Kuten aiemmin jo totesin, jokainen SAP-järjestelmä on omanlaisensa eikä konversiota voi tehdä liukuhihnalta. Esimerkkinä juuri päättyneessä projektissa Sandbox-järjestelmän konversio vei päivää. Tuotantojärjestelmää konvertoidessamme taas asiakkaan käyttökatko alkoi perjantaina klo 12 ja S4 hyrräsi maanantaina klo 9 aamulla. Teimme tosin noin 10 päivää valmistelevia toimenpiteitä taustalla ja varsinainen konversio alkoi ”uptime”-vaiheella edellisenä viikonloppuna.
Hiekkalaatikko tarjoaa asiakkaalle tuotantoympäristöä vastaavan leikkikentän, jossa voi tutustua järjestelmään. Kun asiakas testaa järjestelmää jo tässä vaiheessa, valtaosa ongelmista ja virheistä saadaan korjattua, parhaimmillaan ”lennossa”. Tavoitteena on, että kun testijärjestelmä nostetaan pystyyn, selkeät ongelmat on jo ratkaistu ja asiakasräätälöidyt ohjelmat toimivat.
Ennen projektin alkua asiakkaani CIO totesi, että asiakkaan näkökulmasta on tärkeää, että valitsee itselleen sopivankokoisen kumppanin. Allekirjoitan tämän täysin: molempien osapuolien tulee kokea projekti yhtäläisesti tärkeäksi.
Tiesitkö? S/4HANA-päivityksen voi aloittaa mistä tahansa ERP 6.0 -tasosta.
S/4HANA-projektien määrä kasvaa, mitä lähemmäs vuotta 2025 ja nykyjärjestelmän tuen päättymistä siirrytään. Fiksu hoitaa päivityksen jo hyvissä ajoin eikä jää sumaan. Osaavista konsulteista tulee varmasti ennen pitkää pulaa, kuten kollegani Tom Sandell kirjoittaa.
SAP on tehnyt töitä sen eteen, että siirtymä S/4HANAan olisi helpompi. Taannoisessa aamiaistilaisuudessamme huomasin, että monella on vieläkin mielikuva, että ennen HANA-konversiota pitää tehdä EHP-päivitys vähintäänkin tasolle 7. Näin ei kuitenkaan enää ole, vaan nyt päivityksen voi tehdä mistä tahansa ERP 6.0 -tasosta.
Kannattaa kuitenkin huomioida, että mitä alhaisempi taso, sitä enemmän töitä ja irrallisten noottien asentamista konversio vaatii. Jos et ole päivittänyt SAPia kertaakaan käyttöönoton jälkeen, kannattaa tehdä esiselvitys tilanteesta.
Julkisten palvelujen digitalisoinnin tulee palvella ihmisten arkea
Johtaja, tiedätkö missä kunnossa datasi on?
