deen
Nexia Ebner Stolz

Best Practice: Anforderungen an eine Systemmigration

Ist die Leistungsfähigkeit eines bestehenden Systems nicht mehr gegeben, oder bedeutet der Wechsel zu einem neueren System einen technischen und wirtschaftlichen Quantensprung, dann wird es auf kurze oder lange Sicht Zeit, das System abzulösen.

Anfor­de­run­gen an eine Mig­ra­tion

Bei jeder System­mi­g­ra­tion kom­men spe­zi­fi­sche kon­zep­tio­nelle aber auch recht­li­che Anfor­de­run­gen zum Tra­gen. Die recht­li­chen Anfor­de­run­gen bein­hal­ten die Grund­prin­zi­pien Sicher­heit, Voll­stän­dig­keit, Rich­tig­keit, Unve­r­än­der­lich­keit, Ord­nung & Nach­voll­zieh­bar­keit sowie Zeit­ge­recht­heit. Sie ori­en­tie­ren sich an den Vor­ga­ben des Han­dels­ge­setz­bu­ches (HGB) bzw. deren Inter­pre­ta­tion im IDW RS FAIT 1 (IDW Stel­lung­nahme zur Rech­nungs­le­gung: „Grund­sätze ord­nungs­mä­ß­i­ger Buch­füh­rung bei Ein­satz von Infor­ma­ti­ons­tech­no­lo­gie“ vom 24.09.2002).

Auf der kon­zep­tio­nel­len Seite fin­den sich Anfor­de­run­gen, wie z. B., dass Daten­struk­tu­ren und -for­mate rich­tig und voll­stän­dig erho­ben, Map­ping-(Umschlüs­se­lungs-)Struk­tu­ren sach­ge­recht umge­setzt, Steue­rungs­pa­ra­me­ter und deren Umset­zung aus­rei­chend berück­sich­tigt sowie Daten­be­stände im Alt-Sys­tem und die „Eröff­nungs­be­stän­de“ im Neu-Sys­tem für alle defi­nier­ten Zei­träume auf der Grund­lage eines Kon­troll- und Abstimm­kon­zep­tes abge­stimmt und archi­viert wer­den. Sind Daten­be­r­ei­ni­gun­gen vor­ge­se­hen, was je nach Zustand des aktu­el­len Sys­tems unbe­dingt zu emp­feh­len ist, sollte die Ber­ei­ni­gung mög­lichst im Alt­sys­tem erfol­gen, um keine über­flüs­si­gen Alt­las­ten in das neue Sys­tem zu über­füh­ren. Ein aus­rei­chen­des Test­kon­zept für die Daten­mi­g­ra­tion sowie Vor­ga­ben für die Doku­men­ta­tion wer­den außer­dem vor­aus­ge­setzt.

Risi­ken bei einer Mig­ra­tion

Bei einer Mig­ra­tion sind stets auch Risi­ken zu beach­ten. Beson­ders her­vor­zu­he­ben sind (zu) hohe Aus­fall­zei­ten des gesam­ten Sys­tems sowie das teil­weise oder voll­stän­dige Fehl­schla­gen des eigent­li­chen Daten­trans­fers. Wer­den ein­zelne Fel­der nicht kor­rekt gemappt, ent­steht bei der Mig­ra­tion ein unbrauch­ba­res Daten­chaos. Ist in einem sol­chen Fall keine Fall­back-Option vor­han­den, kann dies sehr ernste Kon­se­qu­en­zen haben. Zuletzt sind die nicht uner­heb­li­chen Kos­ten sowie der zeit­li­che Auf­wand, je nach Größe des Sys­tems, zu beach­ten. Die Kom­ple­xi­tät eines sol­chen Pro­jek­tes kann sch­nell dazu füh­ren, dass über­mä­ßig viel Zeit und Geld inves­tiert wer­den, ohne kon­k­re­ten Out­put zu erhal­ten. Das Ein­be­zie­hen eines erfah­re­nen Pro­jekt­teams ist daher zu emp­feh­len.

Was ist SAP HANA?

Das Akr­o­nym HANA steht für High Per­for­mance Analytic Appli­ance und bezeich­net dem­ent­sp­re­chend eine per­for­mante Daten­bank-Anwen­dung von SAP. Diese ver­fügt über die In-Memory-Tech­no­lo­gie, bei der Daten nicht län­ger auf Fest­plat­ten, son­dern auf dem Arbeits­spei­cher gehal­ten wer­den, sowie spal­ten­o­ri­en­tierte Spei­cher­tech­no­lo­gie und ermög­licht dadurch sch­nel­lere Daten­zu­griffe und -ver­ar­bei­tun­gen.

Wege zu SAP HANA

Grund­sätz­lich gibt es drei ver­schie­dene Mög­lich­kei­ten zur Ein­füh­rung von SAP HANA. Wir gehen von einem Unter­neh­men aus, wel­ches bereits ein SAP ERP Sys­tem bet­reibt, jedoch eine Daten­bank eines Dritt­an­bie­ters nutzt. Es sind außer­dem eigene Modi­fi­ka­tio­nen und Pro­zesse vor­han­den – das SAP ERP wurde ange­passt - „custo­mi­zed“. Das Ziel ist es, eine Mig­ra­tion der Daten nach SAP HANA durch­zu­füh­ren.

Option 1 ist es, Upgrade und Mig­ra­tion in einem Schritt durch­zu­füh­ren. Dies setzt ein vor­han­de­nes SAP-Sys­tem vor­aus. Mit­hilfe des von SAP her­aus­ge­ge­be­nen „Soft­ware Update Mana­gers“ kann außer­dem eine belie­bige Daten­bank ver­wen­det wer­den. Sys­tem­ak­tua­li­sie­rung, Uni­code Kon­ver­tie­rung sowie die Daten­mi­g­ra­tion gesche­hen in einem Schritt.

Option 2a bein­hal­tet in einem ers­ten Schritt die Aktua­li­sie­rung des ERP auf ein Release, wel­ches HANA unter­stützt (sofern noch nicht vor­han­den). Ansch­lie­ßend folgt die Mig­ra­tion auf her­kömm­li­che Weise. Dies funk­tio­niert sowohl bei der SAP-eige­nen Pro­gram­mier­spra­che „Advan­ced Busi­ness App­li­ca­tion Pro­gram­ming“ (ABAP) als auch Java basier­ten Sys­te­men.

Option 2b ist die voll­stän­dige Neu­in­stal­la­tion des HANA-Sys­tems in neuer Umge­bung. Dies ist ein­fach umzu­set­zen, sollte jedoch nur ange­wandt wer­den, sofern nicht bereits ein SAP ERP-Sys­tem betrie­ben wird. Ansch­lie­ßend folgt die klas­si­sche Mig­ra­tion von Daten in das neu ein­ge­rich­tete Sys­tem.

Wel­che die­ser Metho­den gewählt wer­den sollte, hängt stark vom Grad der Indi­vi­dua­li­sie­rung des vor­han­de­nen SAP ERP-Sys­tems ab. Liegt viel Custo­mi­zing vor, so ist Option 2a zu wäh­len. Liegt ein SAP ERP Sys­tem vor, das im Stan­dard betrie­ben wird, kann der Soft­ware-Update-Mana­ger von SAP genutzt wer­den.

Mig­ra­ti­ons­ablauf

Der Ablauf einer Mig­ra­tion kann in meh­rere Pha­sen unter­teilt wer­den. Zu Anfang steht die Pro­jek­t­or­ga­ni­sa­tion und das Pro­jekt­ma­na­ge­ment zur Fest­le­gung des orga­ni­sa­to­ri­schen Rah­mens. Es folgt die Pla­nungs­phase sowie die Defini­ti­ons-, Design- und Custo­mi­zing-Phase. Sind in einer ers­ten Test­phase sämt­li­che Abläufe getes­tet wor­den, kann mit einer Test­mi­g­ra­tion begon­nen wer­den. Dabei wer­den Teil­sys­teme pro­be­weise migriert, wodurch sicher­ge­s­tellt wird, ob die Mig­ra­tion ers­tens tech­nisch rea­li­sier­bar ist und zwei­tens deren Daten voll­stän­dig sind. Dar­auf­hin beginnt die Pro­duk­tiv­set­zungs­phase bzw. der eigent­li­che Go-Live, bei dem die pro­duk­ti­ven Daten migriert wer­den. Schluss­end­lich wer­den die zuge­hö­ri­gen Doku­men­ta­tio­nen aktua­li­siert und zur Ver­fü­gung ges­tellt.

Grund­sätz­lich sind alle Daten auf Voll­stän­dig­keit nach fol­gen­dem Ver­fah­ren abzu­stim­men:

Die Abstim­mung erfolgt ent­lang eines Abstim­mungs­kon­zep­tes. Darin wird Fol­gen­des gere­gelt:

  • Wel­che Daten sind abzu­stim­men?
  • Wel­cher Stich­pro­ben­um­fang gewähr­leis­tet hin­rei­chende Sicher­heit über die Voll­stän­dig­keit im Ziel­sys­tem?

Danach wird anhand phy­si­schen Ver­g­leichs die Übe­r­ein­stim­mung der Daten aus dem Quell­sys­tem mit dem Ziel­sys­tem über­prüft:

  • i.d.R. manu­el­ler Sicht­ver­g­leich von Lis­ten aus Quel­len- und Ziel­sys­tem
  • i.d.R. detail­lierte Abstim­mung und Revi­sion (Vier-Augen-Prin­zip)

Fazit

Den wesent­li­chen Punkt im Rah­men der Mig­ra­tion stel­len doku­men­tierte Abstim­mungs­hand­lun­gen auf Basis eines Abstim­mungs­kon­zep­tes dar, wel­che die Rich­tig­keit und Voll­stän­dig­keit der über­tra­ge­nen Daten nach­voll­zieh­bar auf­zei­gen.
Haben Sie SAP ERP im Ein­satz und pla­nen auf eine HANA-Daten­bank umzu­s­tei­gen, so ist in einem ers­ten Schritt zu ana­ly­sie­ren, ob die ein­ge­setzte Ver­sion nah am Stan­dard ist oder Anpas­sun­gen vor­ge­nom­men wur­den.

Exkurs: Ver­fah­rens­do­ku­men­ta­tion?

Beson­ders zu beach­ten bei der System­mi­g­ra­tion ist eine geset­zes­kon­forme Ver­fah­rens­do­ku­men­ta­tion. Gemäß GoBD wird ein Haupt­do­ku­ment mit im Wesent­li­chen unve­r­än­der­ten Inhal­ten bereit­ge­s­tellt, wel­ches auf die jewei­li­gen Unter­do­ku­mente refe­ren­ziert. Dazu gehö­ren unter ande­rem Ver­fah­rens­be­sch­rei­bun­gen im Detail ink­lu­sive IKS, tech­ni­sche Unter­la­gen und Hand­bücher, Arbeits­an­wei­sun­gen sowie Ver­träge und Pro­to­kolle. Sämt­li­che Bestand­teile sind lau­fend aktu­ell zu hal­ten und über die Dauer der gesetz­li­chen Auf­be­wah­rungs­frist von zehn Jah­ren auf­zu­be­wah­ren.




nach oben