Hyppää sisältöön

SAP-konkari neuvoo: Näin varmistat, että S/4 HANA -konversiohanke rullaa sujuvasti maaliin

Häämöttääko S/4 HANA-päivitys lähitulevaisuudessa? SAP-arkkitehtitiimin vetäjä Timo Salo kertoo kuusi askelta, jotka auttavat välttämään tyypilliset sudenkuopat.

Mistä syntyvät onnistuneet SAP-projektit, Timo Salo?

”Jokainen SAP ja asiakas on erilainen, ja ratkaistavia haasteita tulee väistämättä vastaan. Haasteita ei pidä kuitenkaan pelätä, vaan niihin tulee varautua! Niistä päästään sujuvasti yli, kun projekti on suunniteltu huolellisesti ja osapuolet – eli liiketoiminta, IT ja kumppanit – jakavat yhteisen päämäärän.”

Mikä SAP S/4HANA? Tutustu toiminnanohjausjärjestelmien suosikkiin täällä 

Nämä askeleet auttavat sekä asiakasta että toimittajaa suunnittelemaan tuloksellisen SAP-hankkeen:

1. Huolehdi siitä, että toimittaja saa jo tarjousvaiheessa nähtäväkseen järjestelmäarkkitehtuurikartan.

On tärkeää, että toimittaja hahmottaa jo tarjousvaiheessa, miten muutoksen kohteena oleva järjestelmä liittyy muihin järjestelmiin.

S/4HANA-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. Kaiken kaikkiaan integraatiot täytyy tunnistaa tarkalla tasolla yllätysten välttämiseksi.

Tässä vaiheessa 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 S/4HANA-projektissa SAP:n tuen saamiseen.

2. Varmista, että kommunikaatio pelaa puolin ja toisin.

Luottamuksen on oltava vahvaa ja kielen yhteistä. Kun viestintä on rehellistä ja suoraa alusta alkaen, ongelmiin pystytään puuttumaan varhaisessa vaiheessa ja voidaan keskittyä projektin eteenpäin viemiseen.

Sofigaten toimitusmalliin kuuluu, että etsimme avainrooleihin parhaat tekijät, ja aina he eivät ole lähimmän nurkan takana. Toimintatapamme perustuu kumppanuudelle ja molemminpuoliselle luottamukselle. Tästä etuna on suora kommunikointi ja työn tehokkuus. Globaalin verkoston ansiosta saamme paikalliset osaajat ympäri maailman työskentelemään asiakkaan kanssa.

Erään 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.

3. Kun varsinainen projektitoimitus alkaa, on tärkeää, että asiakkaalla on hyvä ymmärrys omista prosesseistaan.

Jos ajantasaisia prosessikuvauksia ei ole olemassa, tehdään kyvykkyyskartoitus, joka toimii testaussuunnitelman pohjana. Sofigate on tehnyt kyvykkyyskartoituksesta palvelukonseptin, jonka käytön voi räätälöidä jokaiselle asiakkaalle sopivaksi.

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. Testaus on myös aikataulutettava realistisesti.

4. Testaussuunnitelma koeponnistetaan migraatiovaiheessa.

Ensimmäinen testausrupeama kannattaa tehdä laajana. Siinä suunnitelmaa voidaan vielä tarkentaa ja hioa. Tässä vaiheessa muodostetaan seuraavia testejä varten referenssipiste, johon tulevaa S/4HANA-testausta verrataan. Samalla testaajat palauttelevat mieleen harvemmin käytettyjä toimintoja.

Migraatiotestauksessa havaitaan myös mahdolliset vanhassa järjestelmässä olevat erityistapaukset, joihin ei päivittäin 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 S/4HANA-testauksissa pysähdytä ihmettelemään, että mitenkäs tämä nyt 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 ovat 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. S/4HANA-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 aloittaa S/4HANA-hiekkalaatikon rakentaminen.

Lähtökohdaksi voidaan esimerkiksi ottaa projektin alkuajalta tuotantokopio, josta testijärjestelmä on tuoreistettu.

Ensimmäisen konversion tekeminen kaikkine temppuineen ottaa aikaa. Jokainen SAP-järjestelmä on omanlaisensa eikä konversiota voi tehdä liukuhihnalta. Esimerkkinä eräässä projektissa Sandbox-järjestelmän konversio vei 26 päivää. Tuotantojärjestelmää konvertoidessa taas asiakkaan käyttökatko alkoi perjantaina klo 12 ja S/4HANA 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.

Muista! S/4HANA -migraatio on muutosprojekti – ja tekninen käyttöönotto vain ensimmäinen vaihe muutoksen polkua

Vaikka yllä kirjoitinkin vinkkejä konversiohankkeeseen, haluan kuitenkin alleviivata yhden perustavanlaatuisen asian onnistumisessa. Tekninen käyttöönotto on vain ensimmäinen vaihe S/4HANA -muutoksessa.

Jos lopetat hankkeen käyttöönottoon, jää suuri osa kokonaishyödystä saavuttamatta. SAP S/4HANA – sekä perinteinen On Premise että Cloud-versio – on moderni, reaaliaikainen, käyttäjää tukeva sekä jatkuvasti kehittyvä järjestelmä. SAP kehittää järjestelmää jatkuvasti tuoden sinne uusia tehokkuutta lisääviä innovaatioita. Eniten hyötyvät ne, jotka pystyvät käyttämään järjestelmää sellaisena kuin se on tarjolla.

S/4HANAa ei tule muokata perinteisellä ”puukotuksella” ja Z-ohjelmilla kuin viimeisenä keinona. On olemassa keinot, jotka pienentävät kehityskustannusta, elinkaarikustannusta ja auttaa pitämään järjestelmän vakiona. Ole yhteydessä, kun haluat keskustella tästä lisää!

 

Timo SaloTimo Salo on liiketoiminta-arkkitehti, jolla on pitkä tausta erilaisista tehtävistä IT-projekteissa ja arkkitehtuurissa. SAP S/4HANAan erikoistunut Salo vetää Sofigatella SAP-arkkitehtitiimiä.

Etsi