Datamigrering till SAP S/4HANA och avveckling av äldre system

Utforska hur datamängd, systemkomplexitet och beslut om avveckling påverkar resultatet av SAP S/4HANA-migreringen och den långsiktiga dataarkitekturen.

Omställningen till SAP S/4HANA beskrivs ofta som en systemuppgradering. I praktiken är det betydligt mer än så.

Det handlar om en genomgripande förändring av hur data struktureras, lagras och används i hela verksamheten. Även efter att det nya systemet har tagits i drift återstår ofta en central fråga:

Vad händer med allt som blir kvar i de äldre systemen?

I många projekt är SAP S/4HANA i produktion, relevant data har migrerats och affärsprocesserna fungerar som planerat. Samtidigt fortsätter äldre system att köras parallellt – inte för att de har glömts bort, utan för att verksamheten fortfarande är beroende av dem. Det kan handla om historisk rapportering, åtkomst för revision och regelefterlevnad, kvarvarande integrationer eller andra affärskritiska beroenden.

Det är i detta skede som migreringen går in i en ny fas: från teknisk driftsättning till strukturerad avveckling, arkitekturförenkling och långsiktig förvaltning av data och systemlandskap.

Den dolda komplexiteten i äldre systemlandskap

Innan en migrering inleds behöver företag ofta hantera en verklighet som lätt underskattas: systemlandskapet består sällan av ett enda system. I stället handlar det om ett komplext ekosystem med flera instanser, integrationer och beroenden.

Typiska kännetecken för äldre systemmiljöer är bland annat:

• Flera ERP-instanser för olika regioner eller affärsenheter
• Parallella rapporteringslösningar och datalager
• Inkonsekventa masterdatamodeller
• Bristfälligt dokumenterade integrationer med system utanför SAP-miljön
• Överlappande ansvar mellan olika funktioner och avdelningar

I praktiken kan den här komplexiteten skapa flera flaskhalsar och öka både riskerna och arbetsinsatsen i samband med migreringen.

Det här är i grunden ett problem med företagsarkitekturen som har formen av en migreringsuppgift, snarare än ett problem som främst handlar om datavolym.

Migreringsstrategi och dess påverkan på datastrategin

Migreringsstrategin reduceras ofta till ett val mellan Brownfield, Greenfield eller selektiv dataövergång (Bluefield). I praktiken är den uppdelningen bara en del av bilden. Det avgörande är hur den valda strategin påverkar tre centrala beslut:

• Vilka data ska migreras?
• Hur ska dessa data struktureras i det nya systemet?
• Var ska historiska data lagras och göras tillgängliga?

Svaren på dessa tre frågor formar den framtida datamiljön i större utsträckning än den tekniska migreringsvägen i sig.

Beroende på vald strategi kan flera områden påverkas.

Som tabellen visar avgör migreringsstrategin hur mycket av den befintliga miljön som följer med till SAP S/4HANA och hur mycket komplexitet som blir kvar.

 För en mer detaljerad genomgång av migreringsplaneringen, se vår förberedelseguide för övergången från SAP ECC till SAP S/4HANA. 

Att fastställa dataomfattningen

Det är när man beslutar vad som ska migreras och vad som ska lämnas kvar som omfattningen av migreringen blir konkret. I detta skede behöver teamen avgöra vilka datamängder som är nödvändiga för verksamheten och vilka som kan ligga kvar i befintliga system eller arkiv. Att behandla olika datatyper på samma sätt skapar ofta problem längre fram, eftersom varje kategori har olika krav och beroenden.

Utmaningar med masterdata

Masterdata är sällan helt konsekventa. Samma leverantör eller kund kan ha olika ID:n eller attribut i olika äldre system. Dessa skillnader behöver harmoniseras innan migreringen påbörjas. Det innebär bland annat att anpassa affärspartnerstrukturer och identifiera dubbletter. Om detta arbete genomförs för snabbt riskerar inkonsekvenserna att följa med in i SAP S/4HANA och visa sig som felaktiga rapporteringsdimensioner eller dubbla poster för samma affärspartner.

Hantering av öppna transaktioner

Öppna poster som kundfordringar, leverantörsskulder och försäljningsorder måste migreras utan att den finansiella integriteten påverkas. Utmaningen ligger ofta i ofullständiga dokumentkedjor, till exempel en order där tillhörande leveransdokument saknas. Eftersom dessa data är direkt kopplade till den dagliga verksamheten blir även mindre fel snabbt synliga efter driftsättningen, när användarna börjar arbeta i det nya systemet.

Historik och rapporteringsbehov

Frågan om hur många års historik som ska migreras diskuteras ofta, men det avgörande är hur informationen ska användas. Organisationen behöver fastställa om historisk rapportering ska ske direkt i det nya systemet eller om ett externt arkiv är tillräckligt. Många företag migrerar endast de senaste åren och arkiverar äldre data. Det gör migreringen mer hanterbar, men förutsätter att ekonomi-, revisions- och rapporteringsfunktionerna enas om upplägget i ett tidigt skede.

Avstämning av avslutade räkenskapsår

Avslutade räkenskapsår är i första hand en fråga om avstämning snarare än operativ drift. Organisationen behöver avgöra om tidigare bokslut ska kunna återskapas direkt i SAP S/4HANA. Om så är fallet ökar arbetsinsatsen avsevärt. Projekt kan annars försenas när ekonomiavdelningen förväntar sig fullständig historisk rapportering i det nya systemet samtidigt som IT utgår från att ett arkiv är tillräckligt. Om denna skillnad i förväntningar upptäcks sent kan det bli både kostsamt och svårt att ändra inriktning.

Konfigurationsbeslut

Konfiguration handlar inte enbart om tekniska inställningar. Den speglar också tidigare affärsbeslut. Att återanvända all befintlig konfiguration kan förenkla migreringen på kort sikt, men riskerar samtidigt att föra med sig onödig komplexitet och äldre speciallösningar. Att utforma konfigurationen från grunden ger större möjligheter att förenkla systemlandskapet, men kräver mer tid och engagemang från verksamheten. Därför behövs en avvägning mellan genomförandetakt och en mer ändamålsenlig målarkitektur.

Avvägningen mellan omfattning och komplexitet

En större dataomfattning kan upplevas som enklare på kort sikt eftersom färre beslut behöver fattas om vad som ska lämnas kvar. Samtidigt ökar både datamängden och behovet av avstämning. En mer begränsad omfattning kräver mer analys och samordning i förväg, men kan ge en mer kontrollerad målmiljö. Målet är därför inte enbart att migrera data, utan att anpassa omfattningen efter verksamhetens faktiska behov.

Datakvalitet som begränsande faktor, inte en separat saneringsaktivitet

Datakvalitet hanteras ofta som ett parallellt arbetsområde under förberedelserna inför migreringen. I praktiken är den i stället ofta avgörande för hur långt projektet kan gå i varje fas.

Vissa problem återkommer som tydliga hinder. Det gäller bland annat inkonsekvenser i masterdata mellan system, olösta frågor kring Customer-Vendor Integration (CVI) och differenser mellan reskontra och huvudbok. Sådana problem är vanliga i miljöer med flera källsystem.

Utmaningen är ofta när problemen upptäcks. De blir vanligtvis synliga först under integrations- eller avstämningstester, när data redan har transformerats och laddats. Att åtgärda dem i det skedet innebär ofta att tidigare steg måste göras om, vilket ökar både arbetsinsatsen och projektrisken.

Så undviker ni datasilor som gradvis hämmar verksamheten

Insikter från LeverX och SAP PLM baserade på praktisk erfarenhet

Läs mer

Verkligheten bakom avvecklingen av äldre system

Äldre system försvinner inte automatiskt när ett nytt system tas i drift. De finns ofta kvar som viktiga referenspunkter för revision, historisk rapportering och operativa kontroller. Att avveckla dem är sällan en engångsåtgärd, utan kräver vanligtvis en stegvis process.

Läsbehörighet som säkerhetsnät

Att behålla det äldre systemet i skrivskyddat läge är ett vanligt första steg. Det gör det möjligt för användarna att söka fram den information de behöver utan risk för att nya data läggs till eller befintliga poster ändras av misstag. Det skapar en stabil grund för regelefterlevnad samtidigt som teamet fokuserar på den nya plattformen.

Separera data tidigt

Att tidigt i projektet skilja aktiva data från historiska data gör den slutliga övergången betydligt smidigare. Om beslutet om vad som ska migreras respektive arkiveras skjuts upp till slutet av projektet kan själva migreringen bli en betydande flaskhals. Att göra denna uppdelning tidigt kan minska behovet av omfattande datarensning senare.

Användning av dedikerade plattformar för datalagring

Att flytta äldre data till särskilda plattformar för datalagring, såsom SAP Information Lifecycle Management, kan minska belastningen på IT-miljön och kostnaderna för att underhålla äldre system, samtidigt som informationen förblir tillgänglig för juridiska krav och revision. SAP Information Lifecycle Management kan även stödja GDPR-krav, exempelvis rätten till radering, och ligger i linje med SAP Clean Core-strategin genom att hålla inaktiva data utanför det operativa systemet utan att förlora kontrollen över regelefterlevnaden.

Varje alternativ innebär en avvägning. Att hålla ett komplett äldre system i drift förenklar åtkomsten men innebär fortsatt höga underhållskostnader. Att flytta data till en extern plattform minskar dessa kostnader men kräver en robust plan för åtkomst och återställning. Framgång mäts därför inte i hur snabbt ett system kan stängas ned, utan i om verksamheten fortfarande kan hitta och använda den information som behövs flera år senare.

Projekt som hanterar detta väl börjar vanligtvis med en grundlig analys och profilering av data. Att identifiera och åtgärda inkonsekvenser tidigt minskar risken för att de utvecklas till större problem när migreringscyklerna inleds.

Verktyg och automatisering: var de faktiskt passar in

I de flesta projekt introduceras verktygen tidigt, men deras roll blir ofta tydligare först när konkreta dataproblem börjar visa sig. Då blir det också tydligt om tidigare beslut fungerar med de faktiska data som ska migreras.

SAP Migration Cockpit: strikt struktur, begränsad tolerans

SAP Migration Cockpit är vanligtvis den punkt där förberedda data slutligen förs in i SAP S/4HANA. Verktyget bygger på fördefinierade objektstrukturer och förutsätter att data följer dem.

Det fungerar förutsägbart när:

• Affärspartnerdata redan uppfyller CVI-kraven
• Material- och ekonomistrukturerna är anpassade till SAP S/4HANA-standarder
• Relationerna mellan objekten är konsekventa

Problem uppstår när data kommer från flera system med överlappande eller motstridiga definitioner. Verktyget identifierar eller avvisar sådana konflikter snarare än att lösa dem.

I praktiken behöver team därför ofta omforma data utanför verktyget innan de kan läsas in. SAP Migration Cockpit fungerar därmed främst som en kontrollpunkt snarare än som ett transformationslager.

SAP Data Services: där avvikelser blir synliga

SAP Data Services hjälper till att sammanföra data från olika system och omvandla dem till en gemensam struktur. Verktyget är effektivt för att kombinera data från flera källor, tillämpa enhetlig transformationslogik i stor skala och identifiera tydliga dataproblem under bearbetningen.

Det kan däremot inte lösa skillnader i betydelse. Om två system använder olika nycklar, hierarkier eller definitioner för samma objekt kan verktyget harmonisera formaten, men inte avgöra vilken definition som är den rätta.

Det är ofta här teamen får en tydligare bild av omfattningen av inkonsekvenserna mellan systemen. Verktyget synliggör problemet, men löser det inte på egen hand.

Transformationsmallar: användbara så länge strukturen är stabil

Mallar hjälper till att standardisera mappningslogiken mellan migreringscykler och är särskilt användbara vid återkommande testladdningar. De fungerar bäst när källsystemen har liknande strukturer och mappningarna förblir stabila över tid.

De blir svårare att underhålla när datastrukturerna skiljer sig mellan systemen och antalet undantag ökar. I sådana fall byggs mallarna successivt ut med villkorslogik, och underhållet kan till slut kräva lika mycket arbete som att utveckla transformationerna från grunden.

Automatiserad avstämning: snabb identifiering, tidskrävande analys

Avstämningsverktyg jämför käll- och måldata för att identifiera avvikelser. De är särskilt viktiga vid migrering av finansiella data, där även mindre differenser behöver kunna förklaras.

De hjälper till att besvara frågor som:

• Stämmer totalerna mellan systemen?
• Saknas poster eller förekommer dubbletter?
• Var uppstår avvikelserna?

De förklarar däremot inte varför skillnaderna finns. När en avvikelse har identifierats behöver orsaken fortfarande spåras, ofta genom flera system och transformationssteg. I större program kan denna fas ta längre tid än planerat, särskilt om inkonsekvenser inte har hanterats tidigare.

I moderna implementationer, särskilt de som följer Clean Core-principer, kan verktygskedjan struktureras i följande steg:

• Objektdefinition i SAP MOM: I SAP Migration Object Modeler definieras eller utökas målobjekten, inklusive eventuella anpassade fält. Detta fastställer strukturen för de data som ska migreras.
• Konfiguration av stagingmiljön: SAP Migration Cockpit genererar därefter stagingmiljön utifrån de definierade migreringsobjekten.
• Extrahering och transformation: SAP Data Services hämtar data från äldre system, transformerar och rensar dem samt hanterar dubbletter innan de överförs till stagingområdet.
• Validering: Avstämning och validering genomförs när data har nått stagingområdet, så att teamet kan kontrollera datakonsistensen innan den slutliga migreringen.

Varje steg bygger på det föregående. Problem som inte hanteras tidigt följer med vidare i processen och blir vanligtvis mer resurskrävande att åtgärda senare.

Riskområden

De flesta migreringsrisker börjar som outtalade antaganden under designfasen. De blir ofta synliga först under testning eller driftsättning. Problemen har vanligtvis sitt ursprung i hur data har hanterats långt innan själva migreringen påbörjas.

Historiska avvikelser i balansräkningen

I komplexa systemmiljöer är finansiella data sällan helt harmoniserade mellan alla system. Periodiseringsskillnader, lokala justeringar eller bristande avstämning kan skapa mindre differenser som förblir dolda under lång tid. De upptäcks ofta först när data ska konsolideras och valideras i SAP S/4HANA. Det kan visa sig som:

• Avvikelser i ingående saldon
• Skillnader mellan reskontra och huvudbok
• Luckor i historisk rapportering

För att åtgärda dessa problem krävs ofta en grundlig genomgång av källsystemen för att identifiera var avvikelsen uppstod. Om differenserna inte upptäcks tidigt kan de kräva betydande tid och resurser under den slutliga övergången.

Dolda beroenden i äldre strukturer

Äldre gränssnitt bygger ofta på systemspecifik logik eller anpassade tabellstrukturer som inte längre är dokumenterade. Problemen blir ibland synliga först när integrationer söker efter fält som inte längre finns eller när dataformat inte motsvarar vad nedströmsystemen förväntar sig.

Även om själva dataöverföringen fungerar kan sådana integrationsproblem påverka affärskritiska processer som fakturering och orderhantering efter driftsättningen.

Dataavvikelser vid parallell drift

När det gamla och det nya systemet körs parallellt kan det vara svårt att säkerställa att data förblir synkroniserade. Avvikelser uppstår lätt om reglerna för synkronisering och systemansvar inte är tydligt definierade. Det kan exempelvis handla om:

• Transaktioner som registreras i ett system men inte i det andra
• Fördröjd datareplikering som leder till motstridiga rapporter
• Masterdata som uppdateras i ett system men inte i det andra

Sådana avvikelser påverkar både den operativa verksamheten och rapporteringen, särskilt när användare behöver arbeta i båda systemen samtidigt.

Verkligheten bakom avstämningsarbetet

Avstämning betraktas ibland som ett sista steg, men är i praktiken en kontinuerlig process genom hela migreringen. Utmaningen ligger i att validera stora datamängder över flera dimensioner.

Teamet behöver kunna stämma av både på dokument- och balansnivå och samtidigt identifiera vilket transformationssteg som har orsakat en viss avvikelse. Om arbetsinsatsen underskattas kan det få direkt påverkan på projektets tidsplan.

Dessa risker är sällan kopplade till migreringsverktygen i sig. De uppstår oftare på grund av brister i hur datarelationer och regler har definierats från början.

LeverX Data Migration för SAP S/4HANA

Storskaliga SAP S/4HANA-program innebär ofta flera utmaningar samtidigt. Det kan handla om att konsolidera system, begränsa datamängden och hantera beroenden till äldre system, samtidigt som krav på revision och regelefterlevnad måste uppfyllas. I sådana miljöer påverkar beslut inom ett område ofta flera andra delar av migreringen.

Konsolidering av flera system

Konsolidering är ofta en av de första stora utmaningarna. Olika ERP-instanser kan innehålla överlappande masterdata och strukturer som inte är harmoniserade.

Målet är därför mer än att bara flytta data. Teamen behöver fastställa vilka poster och strukturer som ska utgöra framtida referens och harmonisera dem i en gemensam modell.

Selektiv dataflytt

En fullständig migrering är inte alltid den mest lämpliga vägen. I vissa fall migreras endast utvalda datamängder till det nya systemet, medan andra delar av systemlandskapet förblir aktiva under en övergångsperiod.

Det innebär att systemen behöver samexistera. För att hålla data konsekventa krävs tydliga synkroniseringsregler som förhindrar att informationen i de två miljöerna successivt börjar skilja sig åt.

Stegvis avveckling av system

Äldre ERP-system försvinner sällan samma dag som ett nytt system tas i drift. Krav på revision, rapportering och regelefterlevnad kan innebära att historiska data behöver vara tillgängliga under flera år.

Många organisationer hanterar detta genom att behålla äldre system i skrivskyddat läge eller flytta historiska data till arkiveringsplattformar. Det kan minska IT-miljöns komplexitet och kostnader samtidigt som historiska poster förblir tillgängliga för exempelvis skatte- eller juridiska revisioner.

Gränsöverskridande harmonisering

Globala program medför ytterligare komplexitet. Finansiella strukturer och skattedata behöver harmoniseras mellan olika länder samtidigt som lokala regelverk måste följas.

Det kan kräva ytterligare transformationssteg för att säkerställa att globala standarder kan tillämpas utan att komma i konflikt med lokala krav på regelefterlevnad.

Strukturerad styrning och avstämning

Avstämning bör hanteras som en kontinuerlig process snarare än en avslutande aktivitet. Ett tydligt ramverk för datastyrning definierar vem som ansvarar för data, vad som ska valideras och hur avvikelser ska hanteras när de uppstår.

Genom att följa samma styrnings- och avstämningsprinciper i varje migreringscykel blir det lättare att säkerställa att de slutliga resultaten är korrekta och spårbara.

Stabilisering efter driftsättning

Arbetet avslutas inte vid driftsättningen. Brister i rapportering eller integrationer blir ibland synliga först när systemet används i den dagliga verksamheten och belastas med verkliga transaktionsvolymer.

För att hantera sådana problem behöver tekniska team och verksamheten samarbeta nära under den första tiden efter driftsättningen.

LeverX betraktar dessa steg som delar av en sammanhängande system- och datastrategi. Konsolidering, transformation och avveckling hanteras som delar av samma helhet snarare än som separata IT-aktiviteter.

Den verkliga effekten av valen vid datamigrering

Effekterna av en datamigreringsstrategi blir ofta fullt synliga först efter driftsättningen. Det är när den dagliga verksamheten är i gång och månadsrapporteringen börjar produceras som kvaliteten på de tidiga besluten blir tydlig.

Löpande underhåll och systemprestanda

Hur datamängden hanteras före migreringen kan påverka både systemets prestanda och användarupplevelsen. Genom att minska beroenden till äldre system minskar också risken för att den nya miljön belastas med överlappande poster eller föråldrade objekt.

Det kan förenkla den löpande hanteringen av masterdata och minska antalet undantag som annars kräver manuella lösningar.

Tillförlitlig rapportering

Det är ofta inom rapporteringen som värdet av en väl genomförd migrering blir tydligast. Om data harmoniseras före migreringen minskar behovet av manuell avstämning i finansiell och operativ rapportering.

Avvikelser kan fortfarande förekomma, men de blir enklare att spåra när data följer en konsekvent struktur och har tydligt definierade källor. Det skapar bättre spårbarhet och större tillit till rapporteringen.

Tydligare dataansvar

En strukturerad migrering innebär ofta att organisationen behöver tydliggöra vem som ansvarar för olika typer av data. När roller och ansvar definieras redan under migreringen blir det enklare att upprätthålla datakvaliteten efter driftsättningen.

Det kan också förkorta tiden för att åtgärda fel i exempelvis masterdata eller finansiella justeringar, eftersom det är tydligt vem som ansvarar för respektive område.

Att framtidssäkra systemet

Hur väl systemet kan utvecklas över tid beror också på vilken komplexitet som lämnas kvar. Genom att avveckla föråldrade konfigurationer och data som inte längre används minskar den tekniska skulden.

Det ger organisationen större flexibilitet när nya rapporteringskrav, processförändringar eller andra verksamhetsbehov uppstår.

Strategi framför teknik

Dessa fördelar uppstår inte automatiskt genom att implementera SAP S/4HANA. De beror i hög grad på hur data hanteras, harmoniseras och styrs under övergången.

Om dessa beslut är ofullständiga eller inkonsekventa finns risken att befintliga problem följer med in i den nya miljön. En framgångsrik migrering avgörs därför lika mycket av förberedelser, datastyrning och arkitekturbeslut som av den tekniska plattformen.

Verkligheten bakom avveckling av SAP-data