Modernisere ABAP for S/4HANA | Viidre AS

Hvorfor er Z-kode den største risikoen?
Mange S/4HANA-prosjekter undervurderer det de tror er et lite problem: "Vi har litt tilpasset kode, men det er sikkert ikke så mye." I virkeligheten finner de fleste norske SAP-installasjoner 2 000–10 000 tilpassede ABAP-objekter. Noe av dette er kritiske forretningsprosesser. Noe er ubrukt kode ingen tørr slette. Og noe er direkte ukompatibelt med S/4HANA.
Uten en systematisk gjennomgang av Z-koden kan du oppleve at systemet krasjer ved S/4HANA-oppgradering, at integrasjoner som virket slutter å virke, og at brukere møter feil i hverdagen like etter go-live.
## Steg 1: Kartlegg omfanget med Custom Code Migration-verktøyet
SAP Custom Code Migration Workbench (transaksjon CCMW eller via SAP Fiori) er ditt første stopp. Verktøyet analyserer automatisk eksisterende ABAP-kode og identifiserer:
Bruk av avviklete tabeller og felt (Shadow Structure Issues)

Kall til funksjonsmoduler og klasser som ikke eksisterer i S/4HANA

Bruk av avviklete SELECT-optioner

Direkte SQL mot byttet interne tabeller

Kjør dette mot ditt nåværende system og lag en liste over alle påvirkede objekter. Dette gir deg baseline.

Steg 2: Klassifiser funnene
Ikke alle funn er like alvorlige. Klassifiser dem i fire kategorier:
Kritisk (må fikses): Kode som feiler direkte i S/4HANA – bruk av tabeller som er fjernet eller sterkt endret. Disse blokkerer go-live.
Høy prioritet (bør fikses): Kode som fungerer men bruker avviklede API-er som vil fjernes i fremtidige SAP-oppgraderinger. Disse skaper teknisk gjeld.
Lav prioritet (kan planlegges): Kode som fortsatt fungerer men kunne vært modernisert til bedre praksiser. Gode kandidater for fremtidig forbedring.
Ubrukt kode (kan slettes): En overraskende stor andel tilpasset kode er aldri i bruk i produksjon. Bruk SUSG (Program Usage Statistics) for å identifisere dette.
## Steg 3: Prioriter basert på forretningsverdi og risiko
Ikke moderniser ABAP-koden i den rekkefølgen den dukker opp i verktøyet – prioriter basert på faktisk forretningsverdi. Spør deg selv:
- Hvilken forretningsprosess bruker denne koden?

Hva er konsekvensen hvis den feiler etter go-live?

Finnes det standard S/4HANA-funksjonalitet som kan erstatte den?

For mange organisasjoner viser analysen at 20–30% av Z-koden er ubrukt og kan slettes, 40–50% kan moderniseres relativt enkelt med søk-og-erstatning av avviklede tabeller, og 20–30% krever en gjennomgang av forretningslogikken for å finne riktig S/4HANA-tilnærming.

Steg 4: Velg moderniseringstilnærming per objekt
For hvert kritisk ABAP-objekt har du tre valg:
Adapter og migrere: Juster den eksisterende koden til å bruke S/4HANA-kompatible API-er. Raskest, men beholder gammel kodestruktur.
Erstatt med standard: Sjekk om S/4HANA har standard funksjonalitet som dekker behovet. Ofte den beste løsningen forretningsverdi-sett, selv om det kan kreve forretningsendringer.
Skriv om med ABAP Cloud/RAP: For kritisk forretningslogikk som trenger lang levetid, kan det lønne seg å skrive om løsningen fra bunnen med moderne ABAP-mønstre.
## Steg 5: Test systematisk i et S/4HANA-tilnærmet miljø
Ikke vent til et felles testmiljø er tilgjengelig. Sett opp et dedikert teknisk testmiljø der modernisert ABAP-kode kan testes uavhengig av den store prosjektorganisasjonen. Automatiserte regresjonstester (ABAP Unit Tests) er gull verdt i denne fasen.
## Praktisk anbefaling
Start ABAP-moderniseringen tidlig – minimum 6-12 måneder før planlagt go-live for S/4HANA. Jo tidligere du starter, jo mer tid har du til å håndtere overraskende kompleksitet. Og husk: de fleste ABAP-moderniseringsprosjektene finner mer kode og mer kompleksitet enn forventet. Det er ikke unntak – det er regelen.

Slik moderniserer du ABAP-koden før S/4HANA-migreringen