Om osYdelserCasesArtikler
← Tilbage til ydelser

ERP-modernisering og exit fra SAP ECC: arbejdet omkring migreringen, som ingen fik estimeret

Enhver ERP-migrering rummer to projekter. Der er det, der står i planen (det nye system, procesdesignet, systemintegratoren), og så er der det, der dukker op i måned fire, når nogen tæller grænsefladerne.

Det andet projekt er vores. De firs specialbyggede integrationer, rapporterne som økonomi er afhængig af, og som ingen ejer, lagerterminalerne der taler med en databaseview, kundeportalen der læser direkte i de gamle tabeller, og de tyve års data, der skal ind i det nye system i en form, det vil acceptere. Det står sjældent i den oprindelige scope, og det er ofte det, der afgør datoen.

Derfor står det på kalenderen nu

Mainstream-vedligeholdelsen af SAP ECC 6.0 ophører 31. december 2027. Udvidet vedligeholdelse kan bære en virksomhed frem til udgangen af 2030, mod merbetaling og med reduceret omfang. En stor del af installationsbasen er ikke kommet i gang, migreringer tager typisk atten til seksogtredive måneder, og de partnere og den hyperscaler-kapacitet, der skal udføre dem, bliver booket nu.

Det samme pres findes uden for SAP-verdenen. Oracle EBS-kunder har deres egen supporthorisont, Dynamics AX- og NAV-installationer bliver skubbet mod Business Central og Dynamics 365, og en lang hale af virksomheder kører et ERP, der blev kraftigt tilpasset for et årti siden af folk, som for længst er videre.

Uanset destinationen har problemet samme form: ERP'et er ikke en ø, og det, der hænger på det, er som regel udokumenteret.

Det, vi laver

Kortlægning af grænseflader

Før noget kan planlægges, skal nogen fastslå, hvad der faktisk taler med ERP'et. Det gør vi empirisk (ved at læse databaselogs, netværkstrafik, planlagte jobs, konfiguration i integrationsmiddleware og kildekode) frem for at sende et spørgeskema rundt og håbe.

Resultatet er en oversigt over hver eneste grænseflade med retning, protokol, frekvens, datamængde, forretningsejer hvor en kan findes, og en vurdering af, om den skal bygges om, kan udfases eller kan tilpasses. Kunder finder rutinemæssigt to til fem gange så mange grænseflader, som de havde regnet med, og et ikke ubetydeligt antal viser sig slet ikke at tjene noget formål.

Ombygning af integrationslaget

Vi bygger de grænseflader om, der skal overleve, og vi foretrækker at bygge dem mod en abstraktion frem for at pege dem direkte på det nye system. Et integrationslag mellem jeres satellitsystemer og ERP'et betyder, at næste migrering (og der kommer en), ikke skal gentage øvelsen. Det gør det også muligt at flytte applikationer over i bølger i stedet for i én cutover-weekend.

Arbejdet her spænder over IDoc- og BAPI-grænseflader, OData-services, SOAP-endepunkter fra en tidligere epoke, fladfil- og SFTP-udvekslinger der stadig driver halvdelen af europæisk B2B, beskedkøer og moderne REST-API'er på den nye side.

Datamigrering som ingeniørdisciplin

Udtræk, rensning, transformation, indlæsning og (den del, der som regel undervurderes) afstemning. Vi bygger migreringen som kode, der kan køres igen, ikke som et engangsscript, så den kan afvikles snesevis af gange mod stadig renere data med resultaterne sammenlignet automatisk hver gang.

Afstemningen er der, hvor troværdigheden ligger. Økonomi godkender ikke en migrering, fordi indlæsningen lykkedes; de godkender, fordi saldi stemmer, antal stemmer, og de forskelle der er tilbage, er forklaret og accepteret på skrift.

Specialsystemer, der overlever ERP'et

De fleste virksomheder har applikationer bygget rundt om det gamle ERP, som indkapsler noget, ERP'et ikke kunne: en konfigurator, et prissætningsværktøj, en produktionsterminal, en kundeportal, et planlægningsregneark der blev bærende. Nogle bør udfases ind i standardfunktionaliteten i det nye system. Nogle er reel konkurrencefordel og bør bygges ordentligt om som selvstændige applikationer, der ikke længere er svejset fast til et databaseskema, som er ved at blive skiftet ud.

Vi hjælper jer med at skelne de to fra hinanden og bygger derefter dem, der er værd at beholde.

Rapportering og skygge-datalandskabet

Ethvert langtlevende ERP får et lag af rapporter, udtræk og regneark uden om sig. De brækker højlydt ved cutover, og de står næsten aldrig i planen. Vi kortlægger dem, finder dem forretningen reelt kører på, og bygger dem om mod den nye datamodel eller mod et rapporteringslag, der skærmer dem fra den.

Nedlukning og dataopbevaring

Det gamle system indeholder registreringer, I er lovmæssigt forpligtet til at gemme i årevis, efter at det er slukket. At holde ECC kørende i skrivebeskyttet tilstand i et årti er en dyr måde at opfylde en opbevaringsregel på. Vi bygger udtrækket ind i et tilgængeligt arkiv med de søge- og eksportveje, revisorer og skattemyndigheder rent faktisk beder om, så det gamle system kan slukkes.

Hvad det ikke er

Vi er ikke et SAP-funktionshus. Vi konfigurerer ikke FI/CO, vi designer ikke jeres procestemplates, og vi er ikke den partner, der kører S/4HANA-programmet. Det er specialistroller, og dem skal I hyre en specialist til.

Vi er det udviklingsteam, der arbejder ved siden af den partner på alt det, ERP'et rører ved, men som ERP-programmet ikke dækker. I praksis bliver vi engageret enten direkte af kunden for at beskytte deres side af programmet eller som underleverandør til den systemintegrator, der kører det.

Leder I efter nogen til at eje hele S/4HANA-konverteringen, siger vi, at det er vi ikke, og vi siger det hellere i den første samtale end i den tredje.

Hvor vi arbejder

Ved siden af et S/4HANA-program: ombygning af integrationer, datamigrering, arbejde med satellitsystemer og nedlukning af det gamle landskab.

Migreringer helt væk fra SAP: til Odoo, Dynamics 365 Business Central, ERPNext, Netsuite eller en branchespecifik løsning, mest udbredt blandt mellemstore virksomheder, for hvem S/4HANA er ude af proportioner. Her udgør integrations- og dataarbejdet størstedelen af projektet.

Oracle-, Dynamics AX/NAV- og Infor-landskaber, der står med det samme livscykluspres og mindre opmærksomhed på sig.

Virksomheder, der slet ikke migrerer, og som har besluttet at blive stående indtil videre og har brug for at få moderniseret de omkringliggende systemer, gjort grænsefladerne understøttelsesvenlige og reduceret risikoen imens.

Sådan forløber et samarbejde

Afdækning, tre til seks uger. Grænsefladeoversigt, vurdering af datakvalitet, gennemgang af satellitsystemer og en skriftlig rapport om, hvordan det omkringliggende landskab faktisk ser ud. Den kan bevidst købes som en selvstændig opgave: flere kunder har brugt den til at genforhandle omfang og pris på en systemintegrators tilbud, hvilket mere end betalte for den.

Udvikling, parallelt med hovedprogrammet: integrationslag, migreringspipeline, ombygning af applikationer, efter jeres tidsplan og mod jeres cutover-dato.

Cutover-support, inklusive generalprøverne, afstemningskørslerne og den hypercare-periode, hvor de grænseflader, der aldrig rigtig blev afprøvet i test, endelig bliver det.

Nedlukning, når det nye system er stabilt, og arkivet er godkendt.

Teknologi

Java, .NET, Python, Node.js og PHP på applikationssiden; SAP-grænsefladeteknologier, herunder IDoc, BAPI, RFC og OData; middleware som MuleSoft, Apache Camel, Kafka og Azure Integration Services; SQL Server, Oracle, DB2, HANA og PostgreSQL; AWS og Azure. Kører dele af landskabet på noget ældre (Delphi, VB6, PowerBuilder, COBOL op ad ERP'et) er det velkendt grund og ikke en overraskelse.

Ofte stillede spørgsmål

Hvornår ophører supporten for SAP ECC præcis?

Mainstream-vedligeholdelsen af SAP ECC 6.0 ophører 31. december 2027. Udvidet vedligeholdelse kan købes frem til udgangen af 2030 mod merbetaling og med reduceret omfang. Få de konkrete vilkår for jeres enhancement pack og jeres kontrakt bekræftet direkte hos SAP, da de er forskellige.

Vi har allerede valgt en systemintegrator. Hvor passer I ind?

Ved siden af dem. Integratoren ejer ERP-konverteringen; vi ejer landskabet omkring den: grænseflader, dataarbejde, satellitsystemer, rapportering og nedlukning. Den arbejdsdeling er udbredt, den holder integratoren fokuseret på det system, de er specialister i, og den betyder, at nogen er ansvarlig for de dele, der ellers plejer at falde ned mellem kontrakterne.

Er det realistisk at komme helt væk fra SAP?

For nogle virksomheder, ja. Det afhænger af, hvor meget af det, I laver, der er standard, hvor meget der ligger i tilpasninger, og om en mindre platform kan bære jeres volumen og jeres lovkrav. Det er en reel mulighed for mellemstore produktions- og distributionsvirksomheder og en dårlig én for komplekse multinationale koncerner. Afdækningsfasen giver jer beviserne til at beslutte det frem for argumenterne.

Hvor lang tid tager grænsefladeoversigten?

Tre til seks uger for de fleste mellemstore landskaber. Den er i høj grad begrænset af adgang, hvor hurtigt vi kan komme til logs, kildekode, middlewarekonfiguration og de mennesker, der husker, hvorfor noget findes.

Kan I holde det gamle system tilgængeligt til revision, efter vi har slukket det?

Ja. Vi bygger udtrækket ind i et søgbart arkiv med den opbevaringsperiode og den søge- og eksportfunktionalitet, jeres revisorer og skattemyndigheder kræver. Det er som regel langt billigere end at holde et licenseret ERP kørende i skrivebeskyttet tilstand i et årti.

Hvad hvis vi beslutter ikke at migrere endnu?

Det er en legitim beslutning, ikke mindst når udvidet vedligeholdelse er tilgængelig til 2030. Arbejdet består så i at reducere risikoen i mellemtiden: dokumentere og stabilisere grænseflader, udfase det, ingen bruger, og modernisere applikationerne omkring ERP'et, så det omkringliggende landskab ikke er forhindringen, den dag I flytter.

Kom i gang

Fortæl os, hvad I kører, hvor I er i beslutningen, og om der allerede er valgt en integrator. Så siger vi, hvad det omkringliggende landskab sandsynligvis kommer til at koste jer, og hvor vi ville begynde.

Kontakt os for at få afgrænset en afdækning af grænseflader og data.

Relaterede ydelser

Klar til at komme i gang med denne ydelse?

Kontakt os
← Tilbage til alle ydelser