Forbered HANA-migration korrekt

Hvis jeres SAP-Business-One-database er vokset gennem årene, viser det sig ret hurtigt før en migration: gamle rapporter, uklare egenudviklinger, dubletter, åbne gamle forpligtelser i regnskabet, og ingen ved præcis, hvilken grænseflade der egentlig skriver hvad om natten. Det er præcis her, det afgøres, om I forbereder en HANA-migration korrekt, eller om projektet senere vil koste tid, nerver og penge.

En HANA-migration er ikke et stort projekt, hvis den er planlagt ordentligt. Den bliver dog unødvendigt kompliceret, så snart virksomheder forsøger at improvisere både teknisk omlægning og procesrensning samtidig. For mellemstore virksomheder, start-ups og voksende virksomheder gælder derfor: skab klarhed først, migrer derefter. Ikke omvendt.

Hvorfor forberedelsen afgør projektets succes

Mange virksomheder undervurderer ikke selve migrationen, men tilstanden af deres nuværende system. På papiret kører SAP Business One. I hverdagen er der så Excel-sideverdener, manuelle korrektioner, historiske særtilfælde og add-ons, der godt nok bruges, men ikke er dokumenteret. HANA gør ikke sådanne emner større - men mere synlige.

Det er den gode nyhed og samtidig knudepunktet. Hvis man vil forberede HANA-migrationen korrekt, behøver man ikke opfinde alt på ny. Det handler om ærligt at vurdere den nuværende tilstand og sikre de dele, der virkelig bærer i dagligdagen. Resten skal undersøges.

Forbered HANA-migration korrekt: først fastlægge omfanget

Den mest almindelige fejl er et for løst projektomfang. Så starter migrationen med ideen om “først at skifte teknisk”, og to uger senere handler det pludselig også om nye arbejdsprocesser, nye rapporter, ny dokumentlogik og et oprydningsprojekt for hele artikelstammen. Det er præcis sådan, forsinkelser opstår.

Det er bedre med et klart omfang på tre niveauer. For det første: Hvad skal nødvendigvis med i HANA-miljøet, så I kan fortsætte arbejdet? For det andet: Hvad skal undersøges og målrettet optimeres? For det tredje: Hvad holdes bevidst udenfor, fordi det er historisk vokset, men i dag ikke længere er forretningskritisk?

Denne opdeling er pragmatisk og sparer diskussioner. Den hjælper også internt, fordi ledelse, fagområde og IT ikke behøver at beslutte alt på samme tid.

Fuldstændig registrering af systemer, add-ons og grænseflader

Før der fastlægges datoer, har I brug for et pålideligt billede af jeres systemlandskab. Dette inkluderer SAP-Business-One-versionen, databasestand, anvendte add-ons, individuelle tilpasninger, tilknyttede tredjepartssystemer og alle import- og eksportprocesser. Især kritiske er stille afhængigheder - for eksempel et gammelt forsendelsesværktøj, en egenbygget SQL-rapport eller en finansgrænseflade, som kun én person i virksomheden virkelig kender.

Især i mindre virksomheder er denne viden ofte ikke ordentligt dokumenteret. Det er normalt, men risikabelt. En god forberedelse betyder derfor ikke kun at inventarisere teknikken, men også at udpege ansvar. Hvem kontrollerer hvad, hvem beslutter i tilfælde af konflikter, hvem frigiver tests?

Datakvalitet før hastighed

Når man migrerer til HANA, bør man ikke automatisk tage al databalast med. Det handler ikke om at slette fortiden. Det handler om tidligt at identificere dårlige stamdata, inaktive datasæt, dobbelte forretningspartnere eller uklare kontotildelinger. Ellers migrerer I bare problemer hurtigere.

Især relevante er artikelstammer, forretningspartnerdata, lagerinformationer og finansdata. Hvis der er inkonsistenser der, vil I bemærke det senere i rapporter, evalueringer og efterfølgende processer. En grundig datakontrol koster tid, men sparer betydeligt mere tid i efterarbejdet.

Uden testplan bliver enhver migration dyr

Et testsystem alene er ikke nok. I har brug for en testplan, der passer til jeres virksomheds hverdag. Mange teams tester for teknisk og for lidt procesorienteret. Så kontrolleres det, om dokumenter kan oprettes, men ikke, om hele processen fra tilbud til ordre, levering, faktura og betaling virkelig fungerer som i dagligdagen.

En god testplan orienterer sig mod reelle forretningsbegivenheder. Hvilke processer kører dagligt? Hvilke er kritiske for månedsafslutning, forsendelse, indkøb eller produktion? Hvilke særtilfælde må ikke gå i stykker? Det er præcis disse scenarier, der skal gennemspilles fuldstændigt før Go-live.

Det gælder også for tilladelser, udskriftslayouts, godkendelser og evalueringer. I mange projekter er det ikke de store showstoppere, men de punkter, hvor fagområder mister tillid. Hvis et salgsteam ikke kan udskrive rene dokumenter på den første dag, er stemningen hurtigt væk - selvom databasen teknisk set er perfekt migreret.

Involver nøglebrugere tidligt

Migrationer fejler sjældent på grund af manglende software. De fejler snarere, fordi fagområder inddrages for sent. Hvis nøglebrugere først kommer i spil kort før Go-live, ser de problemer, når der næsten ikke er tid til korrektioner.

Derfor bør de relevante personer fra finans, drift, salg, indkøb eller lager tidligt med til bordet. Ikke til lange workshops uden resultat, men til klare beslutninger. Hvilke rapporter er uundværlige? Hvilke skærmbilleder eller felter bruges dagligt? Hvilke gamle løsninger skal bevidst forsvinde?

Det har også en anden fordel: Den interne accept stiger. De, der har været involveret i forberedelsen, er mere tilbøjelige til at støtte omlægningen senere.

Planlæg timing realistisk i stedet for at forskønne

Mange virksomheder placerer migrationstidspunktet der, hvor det ser godt ud i kalenderen. Mellem kvartalsafslutning, lageroptælling, ferietid og årsafslutning virker næsten hver uge på en eller anden måde mulig. I praksis er det sjældent sådan.

Realistisk timing betyder at tage jeres operationelle rytme alvorligt. Hvis månedsafslutningen er stram, hvis der er sæsonmæssige toppe, eller hvis et lagerprojekt starter parallelt, bør migrationen ikke presses ind i netop denne periode. En tilsyneladende hurtig dato er dyr, hvis ingen internt har tid til tests, godkendelser eller spørgsmål.

Selve cutover kræver også en klar planlægning. Hvornår overføres de sidste data? Hvem stopper grænseflader? Hvem kontrollerer dokumentnummerkredse, brugerrettigheder og udskriftsformularer? Hvem beslutter, hvis der stadig er et kritisk punkt åbent om morgenen på Go-live? Den, der besvarer disse spørgsmål på forhånd, reducerer hektik betydeligt.

Teknisk forberedelse er vigtig - men ikke alt

Naturligvis hører den tekniske basis også til migrationen. Infrastruktur, versioner, kompatibilitet af add-ons, backup-strategi og ydelseskrav skal kontrolleres grundigt. Især når virksomheder kommer fra et voksende miljø, er det fornuftigt ikke kun at satse på “det kører på en eller anden måde”, men bevidst at opbygge målarkitekturen.

Alligevel er teknikken kun en del af sandheden. En HANA-database giver jer ingen fordel, hvis processer fortsat kører med skygge-lister og manuelle korrektioner. Den egentlige løftestang ligger ofte i at bruge migrationen som en anledning til at fjerne overflødige omveje. Ikke som et kæmpeprojekt, men med sund pragmatisme.

Det er præcis her, god forberedelse adskiller sig fra overengineering. I har ikke brug for et transformationsprogram med ti delprojekter. I har brug for klarhed, prioriteter og en partner, der SAP Business One virkelig kender og ikke først i projektet begynder at forstå jeres virkelighed.

Hvad der virkelig skal være på plads før Go-live

Kort før omlægningen bliver det ofte hektisk. Derfor hjælper en simpel regel: Alt, der er forretningskritisk for den første arbejdsdag, skal være bindende kontrolleret og godkendt. Dette inkluderer stamdata, åbne dokumenter, kerneprocesser, grænseflader, brugerroller og standardevalueringer. Nice-to-haves kan vente. Forretningskritiske emner kan ikke.

Lige så vigtigt er en klar supportramme for de første dage efter Go-live. Hvem er tilgængelig? Hvordan prioriteres fejl? Hvad er en reel blokering, og hvad er kun et træningsemne? Virksomheder, der undervurderer denne fase, oplever unødvendig uro - selv når migrationen er kørt fagligt korrekt.

De, der arbejder med fast pris, klart omfang og klare ansvar, har en reel fordel her. Det er præcis derfor, specialiserede projekter ikke satser på konsulentsprog, men på pålidelige processer uden overraskelser. Det er også grunden til, at mange virksomheder foretrækker at arbejde med en specialiseret partner som RConsult ved en HANA-migration frem for en generalist, der kun ved siden af beskæftiger sig med SAP Business One.

Hvornår mere forberedelse er fornuftig - og hvornår ikke

Ikke alle virksomheder har brug for den samme dybde før en HANA-migration. Hvis jeres systemlandskab er overskueligt, der næsten ikke findes egenudviklinger, og datakvaliteten er i orden, kan forberedelsen være kompakt og hurtig. Hvis der derimod er mange add-ons, internationale krav, flere klienter eller historisk voksede særprocesser i spil, har I brug for mere forberedelse.

Pointen er ikke at sælge så meget analyse som muligt. Pointen er at vælge den passende forberedelse. For lidt forberedelse fører til overraskelser. For meget forberedelse bremser jer uden merværdi. Begge dele er unødvendige.

Hvis I vil forberede jeres HANA-migration korrekt, så tænk ikke først på tekniske slides eller projektplaner. Tænk på jeres reelle drift mandag morgen efter Go-live. Kan jeres teams arbejde? Passer tallene? Kører processerne? Hvis disse spørgsmål er besvaret klart, er migrationen ikke kun gennemført, men også fornuftigt implementeret.

Den bedste forberedelse kendes ikke på store præsentationer, men på, at overgangen til sidst virker uspektakulær - præcis sådan skal det være.