ERP-modernisering og exit fra SAP ECC: ingeniørarbeidet ingen tok med i omfanget

Hver ERP-migrering har to prosjekter inni seg. Det ene står i planen (det nye systemet, prosessdesignet, systemintegratoren), og det andre dukker opp i måned fire, når noen teller grensesnittene.

Det andre prosjektet er vårt. De åtti egenutviklede integrasjonene, rapportene økonomi er avhengige av og ingen eier, terminalene på lageret som snakker med en databasevisning, kundeportalen som leser rett fra de gamle tabellene, og tjue år med data som skal inn i det nye systemet i en form det godtar. Det er sjelden med i det opprinnelige omfanget, og det er ofte det som avgjør datoen.

Hvorfor dette står på kalenderen nå

Ordinær vedlikeholdsstøtte for SAP ECC 6.0 opphører 31. desember 2027. Utvidet vedlikehold kan ta en virksomhet til utgangen av 2030, til en høyere pris og med redusert omfang. En stor del av installasjonsbasen har ikke begynt, migreringer tar gjerne atten til trettiseks måneder, og kapasiteten hos partnerne og hyperskalererne som skal gjøre dem, bookes nå.

Det samme presset finnes utenfor SAP-verdenen. Oracle EBS-kunder har sin egen støttehorisont, installasjoner av Dynamics AX og NAV skyves mot Business Central og Dynamics 365, og en lang hale av virksomheter kjører et ERP som ble kraftig tilpasset for ti år siden av folk som siden har sluttet.

Uansett hvor ferden går, er problemet formet likt: ERP-et er ingen øy, og det som henger på det er som regel udokumentert.

Hva vi gjør

Kartlegging av grensesnitt

Før noe kan planlegges, må noen slå fast hva som faktisk snakker med ERP-et. Det gjør vi empirisk (ved å lese databaselogger, nettverkstrafikk, planlagte jobber, konfigurasjonen i integrasjonsmellomvaren og kildekoden), ikke ved å sende ut et spørreskjema og håpe.

Resultatet er en oversikt over hvert grensesnitt med retning, protokoll, frekvens, datamengde, forretningseier der en finnes, og en vurdering av om det må bygges om, kan avvikles eller kan tilpasses. Kunder finner jevnlig to til fem ganger så mange grensesnitt som de ventet, og et betydelig antall viser seg å ikke betjene noe som helst.

Ombygging av integrasjonslaget

Vi bygger om de grensesnittene som må overleve, og vi foretrekker å bygge dem mot en abstraksjon i stedet for å peke dem rett på det nye systemet. Et integrasjonslag mellom satellittsystemene og ERP-et betyr at neste migrering (og den kommer), ikke gjentar denne øvelsen. Det gjør det også mulig å flytte applikasjoner over i puljer i stedet for i én cutover-helg.

Arbeidet spenner over IDoc- og BAPI-grensesnitt, OData-tjenester, SOAP-endepunkter fra en tidligere epoke, flatfil- og SFTP-utvekslinger som fortsatt driver halve europeisk B2B, meldingskøer, og moderne REST-API-er på den nye siden.

Ingeniørarbeidet i datamigreringen

Uttrekk, vasking, transformasjon, last og (den delen som vanligvis undervurderes) avstemming. Vi bygger migreringen som repeterbar kode, ikke som et engangsskript, slik at den kan kjøres dusinvis av ganger mot stadig renere data med resultatene sammenlignet automatisk hver gang.

Avstemmingen er der troverdigheten bor. Økonomi godkjenner ikke en migrering fordi lastingen gikk gjennom; de godkjenner fordi saldoene stemmer, antallene stemmer, og differansene som står igjen er forklart og skriftlig akseptert.

Egenutviklede applikasjoner som overlever ERP-et

De fleste virksomheter har applikasjoner bygget rundt det gamle ERP-et som koder noe ERP-et ikke kunne: en konfigurator, et prisverktøy, en terminal i produksjonen, en kundeportal, et regneark som ble bærende konstruksjon. Noen bør pensjoneres inn i standardfunksjonaliteten i det nye systemet. Noen er reelle konkurransefortrinn og bør bygges skikkelig om til applikasjoner i egen rett, ikke lenger sveiset fast til et databaseskjema som er i ferd med å endres.

Vi hjelper deg å skille de to fra hverandre, og bygger deretter dem det er verdt å beholde.

Rapportering og skyggedatalandskapet

Ethvert langlivet ERP får med tiden et lag av rapporter, uttrekk og regneark utenfor seg selv. De brekker høylytt ved cutover, og de står nesten aldri i planen. Vi kartlegger dem, finner ut hvilke virksomheten faktisk drives på, og bygger dem om mot den nye datamodellen eller mot et rapporteringslag som skjermer dem fra den.

Utfasing og oppbevaring av data

Det gamle systemet inneholder poster du er lovpålagt å oppbevare i mange år etter at det er slått av. Å la ECC stå og gå skrivebeskyttet i et tiår er en dyr måte å oppfylle et oppbevaringskrav på. Vi bygger uttrekk til et tilgjengelig arkiv med søke- og eksportveiene revisorer og skattemyndigheter faktisk spør etter, slik at det gamle systemet kan skrus av.

Hva dette ikke er

Vi er ikke et funksjonelt SAP-konsulenthus. Vi konfigurerer ikke FI/CO, vi designer ikke prosessmalene dine, og vi er ikke partneren som kjører S/4HANA-programmet. Det er spesialistroller, og til dem bør du engasjere en spesialist.

Vi er ingeniørteamet som jobber ved siden av den partneren, med alt ERP-et berører og som ERP-programmet ikke dekker. I praksis blir vi engasjert enten direkte av kunden for å beskytte kundens egen side av programmet, eller som underleverandør til systemintegratoren som kjører det.

Leter du etter noen som skal eie hele S/4HANA-konverteringen, sier vi at det er vi ikke, og vi sier det heller i første samtale enn i tredje.

Der vi jobber

Ved siden av et S/4HANA-program: ombygging av integrasjoner, ingeniørarbeid i datamigreringen, arbeid på satellittsystemene og utfasing av det gamle landskapet.

Migreringer bort fra SAP helt: til Odoo, Dynamics 365 Business Central, ERPNext, NetSuite eller et bransjespesifikt system, vanligst hos mellomstore virksomheter der S/4HANA er ute av proporsjon. Her utgjør integrasjons- og dataarbeidet mesteparten av prosjektet.

Oracle-, Dynamics AX/NAV- og Infor-landskap under det samme livssykluspresset, med mindre oppmerksomhet rettet mot seg.

Virksomheter som ikke migrerer i det hele tatt, som har bestemt seg for å bli stående og trenger systemene rundt modernisert, grensesnittene gjort håndterbare og risikoen redusert mens de venter.

Slik kjøres oppdragene

Kartlegging, tre til seks uker. Oversikt over grensesnitt, vurdering av datakvalitet, gjennomgang av satellittsystemer, og en skriftlig rapport om hvordan landskapet rundt faktisk ser ut. Dette tilbyr vi bevisst som et frittstående oppdrag: flere kunder har brukt det til å reforhandle omfang og pris i tilbudet fra en systemintegrator, noe som mer enn betalte for det.

Bygging, parallelt med hovedprogrammet: integrasjonslag, migreringsløype, ombygging av applikasjoner, etter din tidsplan og mot din cutover-dato.

Cutover-støtte, inkludert generalprøvene, avstemmingskjøringene og hypercare-perioden der grensesnittene som aldri ble ordentlig prøvd i test, endelig blir det.

Utfasing, når det nye systemet er stabilt og arkivet er godkjent.

Teknologi

Java, .NET, Python, Node.js og PHP på applikasjonssiden; SAP-grensesnittteknologier som IDoc, BAPI, RFC og OData; mellomvare som MuleSoft, Apache Camel, Kafka og Azure Integration Services; SQL Server, Oracle, DB2, HANA og PostgreSQL; AWS og Azure. Der det eksisterende landskapet kjører på noe eldre (Delphi, VB6, PowerBuilder, COBOL ved siden av ERP-et) er det kjent terreng og ingen overraskelse.

Ofte stilte spørsmål

Når opphører støtten for SAP ECC, nøyaktig?

Ordinær vedlikeholdsstøtte for SAP ECC 6.0 opphører 31. desember 2027. Utvidet vedlikehold er tilgjengelig til utgangen av 2030 mot ekstra kostnad og med redusert omfang. Bekreft detaljene for din enhancement pack og din avtale direkte med SAP, siden vilkårene varierer.

Vi har allerede valgt systemintegrator. Hvor passer dere inn?

Ved siden av dem. Integratoren eier ERP-konverteringen; vi eier landskapet rundt: grensesnitt, dataarbeid, satellittsystemer, rapportering og utfasing. Den arbeidsdelingen er vanlig, den holder integratoren fokusert på systemet de er spesialister på, og den gjør at noen er ansvarlig for delene som ellers faller mellom kontraktene.

Er det realistisk å gå helt bort fra SAP?

For noen virksomheter, ja. Det avhenger av hvor mye av det du gjør som er standard, hvor mye som ligger i tilpasninger, og om en mindre plattform kan bære volumet ditt og de regulatoriske kravene dine. Det er et reelt alternativ for mellomstore produsenter og distributører, og et dårlig et for komplekse multinasjonale konsern. Kartleggingsfasen gir deg grunnlaget til å avgjøre, ikke argumentet.

Hvor lang tid tar kartleggingen av grensesnitt?

Tre til seks uker for de fleste mellomstore landskap. Den er i hovedsak begrenset av tilgang, hvor raskt vi kommer til logger, kildekode, mellomvarekonfigurasjon og folkene som husker hvorfor noe finnes.

Kan dere holde det gamle systemet tilgjengelig for revisjon etter at vi slår det av?

Ja. Vi bygger uttrekk til et søkbart arkiv med den oppbevaringstiden, søkefunksjonen og eksportmuligheten revisorene og skattemyndighetene krever. Det er som regel langt billigere enn å la et lisensiert ERP stå og gå skrivebeskyttet i ti år.

Hva om vi bestemmer oss for å ikke migrere ennå?

Det er en legitim beslutning, særlig med utvidet vedlikehold tilgjengelig til 2030. Jobben blir da å redusere risiko i mellomtiden: dokumentere og stabilisere grensesnitt, avvikle det ingenting bruker, og modernisere applikasjonene rundt ERP-et slik at landskapet rundt ikke er hindringen den dagen du flytter.

Kom i gang

Fortell oss hva du kjører, hvor du er i beslutningen, og om en integrator allerede er valgt. Vi sier hva landskapet rundt sannsynligvis kommer til å koste deg, og hvor vi ville begynt.

Kontakt oss for å avtale en kartlegging av grensesnitt og data.

Relaterte tjenester

• Vedlikehold av eldre systemkode: for systemene som blir stående
• Integrasjon av e-faktura: kravet som ofte lander midt i en migrering
• Bemanningsforsterkning og outsourcing: ingeniører inn i teamet så lenge programmet varer