Best Practice: Anforderungen an eine Systemmigration

Anforderungen an eine Migration

Bei je­der Sys­tem­mi­gra­tion kom­men spe­zi­fi­sche kon­zep­tio­nelle aber auch recht­li­che An­for­de­run­gen zum Tra­gen. Die recht­li­chen An­for­de­run­gen be­inhal­ten die Grund­prin­zi­pien Si­cher­heit, Vollständig­keit, Rich­tig­keit, Un­veränder­lich­keit, Ord­nung & Nach­voll­zieh­bar­keit so­wie Zeit­ge­recht­heit. Sie ori­en­tie­ren sich an den Vor­ga­ben des Han­dels­ge­setz­bu­ches (HGB) bzw. de­ren In­ter­pre­ta­tion im IDW RS FAIT 1 (IDW Stel­lung­nahme zur Rech­nungs­le­gung: „Grundsätze ord­nungsmäßiger Buchführung bei Ein­satz von In­for­ma­ti­ons­tech­no­lo­gie“ vom 24.09.2002).

© Thinkstock

Auf der kon­zep­tio­nel­len Seite fin­den sich An­for­de­run­gen, wie z. B., dass Da­ten­struk­tu­ren und -for­mate rich­tig und vollständig er­ho­ben, Map­ping-(Um­schlüsse­lungs-)Struk­tu­ren sach­ge­recht um­ge­setzt, Steue­rungs­pa­ra­me­ter und de­ren Um­set­zung aus­rei­chend berück­sich­tigt so­wie Da­ten­bestände im Alt-Sys­tem und die „Eröff­nungs­bestände“ im Neu-Sys­tem für alle de­fi­nier­ten Zeiträume auf der Grund­lage ei­nes Kon­troll- und Ab­stimm­kon­zep­tes ab­ge­stimmt und ar­chi­viert wer­den. Sind Da­ten­berei­ni­gun­gen vor­ge­se­hen, was je nach Zu­stand des ak­tu­el­len Sys­tems un­be­dingt zu emp­feh­len ist, sollte die Be­rei­ni­gung möglichst im Alt­sys­tem er­fol­gen, um keine überflüssi­gen Alt­las­ten in das neue Sys­tem zu überführen. Ein aus­rei­chen­des Test­kon­zept für die Da­ten­mi­gra­tion so­wie Vor­ga­ben für die Do­ku­men­ta­tion wer­den außer­dem vor­aus­ge­setzt.

Risiken bei einer Migration

Bei ei­ner Mi­gra­tion sind stets auch Ri­si­ken zu be­ach­ten. Be­son­ders her­vor­zu­he­ben sind (zu) hohe Aus­fall­zei­ten des ge­sam­ten Sys­tems so­wie das teil­weise oder vollständige Fehl­schla­gen des ei­gent­li­chen Da­ten­trans­fers. Wer­den ein­zelne Fel­der nicht kor­rekt ge­mappt, ent­steht bei der Mi­gra­tion ein un­brauch­ba­res Da­ten­chaos. Ist in einem sol­chen Fall keine Fall­back-Op­tion vor­han­den, kann dies sehr ernste Kon­se­quen­zen ha­ben. Zu­letzt sind die nicht un­er­heb­li­chen Kos­ten so­wie der zeit­li­che Auf­wand, je nach Größe des Sys­tems, zu be­ach­ten. Die Kom­ple­xität ei­nes sol­chen Pro­jek­tes kann schnell dazu führen, dass übermäßig viel Zeit und Geld in­ves­tiert wer­den, ohne kon­kre­ten Out­put zu er­hal­ten. Das Ein­be­zie­hen ei­nes er­fah­re­nen Pro­jekt­teams ist da­her zu emp­feh­len.

Was ist SAP HANA?

Das Akro­nym HANA steht für High Per­for­mance Analytic Appli­ance und be­zeich­net dem­ent­spre­chend eine per­for­mante Da­ten­bank-An­wen­dung von SAP. Diese verfügt über die In-Me­mory-Tech­no­lo­gie, bei der Da­ten nicht länger auf Fest­plat­ten, son­dern auf dem Ar­beits­spei­cher ge­hal­ten wer­den, so­wie spal­ten­ori­en­tierte Spei­cher­tech­no­lo­gie und ermöglicht da­durch schnel­lere Da­ten­zu­griffe und -ver­ar­bei­tun­gen.

Wege zu SAP HANA

Grundsätz­lich gibt es drei ver­schie­dene Möglich­kei­ten zur Einführung von SAP HANA. Wir ge­hen von einem Un­ter­neh­men aus, wel­ches be­reits ein SAP ERP Sys­tem be­treibt, je­doch eine Da­ten­bank ei­nes Dritt­an­bie­ters nutzt. Es sind außer­dem ei­gene Mo­di­fi­ka­tio­nen und Pro­zesse vor­han­den – das SAP ERP wurde an­ge­passt - „cu­st­omi­zed“. Das Ziel ist es, eine Mi­gra­tion der Da­ten nach SAP HANA durch­zuführen.

Op­tion 1 ist es, Up­grade und Mi­gra­tion in einem Schritt durch­zuführen. 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 Up­date Ma­na­gers“ kann außer­dem eine be­lie­bige Da­ten­bank ver­wen­det wer­den. Sys­tem­ak­tua­li­sie­rung, Uni­code Kon­ver­tie­rung so­wie die Da­ten­mi­gra­tion ge­sche­hen in einem Schritt.

Op­tion 2a be­inhal­tet in einem ers­ten Schritt die Ak­tua­li­sie­rung des ERP auf ein Re­lease, wel­ches HANA un­terstützt (so­fern noch nicht vor­han­den). An­schließend folgt die Mi­gra­tion auf herkömm­li­che Weise. Dies funk­tio­niert so­wohl bei der SAP-ei­ge­nen Pro­gram­mier­spra­che „Ad­van­ced Busi­ness Ap­pli­ca­tion Pro­gramming“ (ABAP) als auch Java ba­sier­ten Sys­te­men.

Op­tion 2b ist die vollständige Neu­in­stal­la­tion des HANA-Sys­tems in neuer Um­ge­bung. Dies ist ein­fach um­zu­set­zen, sollte je­doch nur an­ge­wandt wer­den, so­fern nicht be­reits ein SAP ERP-Sys­tem be­trie­ben wird. An­schließend folgt die klas­si­sche Mi­gra­tion von Da­ten in das neu ein­ge­rich­tete Sys­tem.

Wel­che die­ser Me­tho­den gewählt wer­den sollte, hängt stark vom Grad der In­di­vi­dua­li­sie­rung des vor­han­de­nen SAP ERP-Sys­tems ab. Liegt viel Cu­st­omi­zing vor, so ist Op­tion 2a zu wählen. Liegt ein SAP ERP Sys­tem vor, das im Stan­dard be­trie­ben wird, kann der Soft­ware-Up­date-Ma­na­ger von SAP ge­nutzt wer­den.

Migrationsablauf

Der Ab­lauf ei­ner Mi­gra­tion kann in meh­rere Pha­sen un­ter­teilt wer­den. Zu An­fang steht die Pro­jekt­or­ga­ni­sa­tion und das Pro­jekt­ma­nage­ment zur Fest­le­gung des or­ga­ni­sa­to­ri­schen Rah­mens. Es folgt die Pla­nungs­phase so­wie die De­fi­ni­ti­ons-, De­sign- und Cu­st­omi­zing-Phase. Sind in ei­ner ers­ten Test­phase sämt­li­che Abläufe ge­tes­tet wor­den, kann mit ei­ner Test­mi­gra­tion be­gon­nen wer­den. Da­bei wer­den Teil­sys­teme pro­be­weise mi­griert, wo­durch si­cher­ge­stellt wird, ob die Mi­gra­tion ers­tens tech­ni­sch rea­li­sier­bar ist und zwei­tens de­ren Da­ten vollständig sind. Dar­auf­hin be­ginnt die Pro­duk­tiv­set­zungs­phase bzw. der ei­gent­li­che Go-Live, bei dem die pro­duk­ti­ven Da­ten mi­griert wer­den. Schluss­end­lich wer­den die zu­gehöri­gen Do­ku­men­ta­tio­nen ak­tua­li­siert und zur Verfügung ge­stellt.

Grundsätz­lich sind alle Da­ten auf Vollständig­keit nach fol­gen­dem Ver­fah­ren ab­zu­stim­men:

Die Ab­stim­mung er­folgt ent­lang ei­nes Ab­stim­mungs­kon­zep­tes. Darin wird Fol­gen­des ge­re­gelt:

• Wel­che Da­ten sind ab­zu­stim­men?
• Wel­cher Stich­pro­ben­um­fang gewähr­leis­tet hin­rei­chende Si­cher­heit über die Vollständig­keit im Ziel­sys­tem?

Da­nach wird an­hand phy­si­schen Ver­gleichs die Übe­rein­stim­mung der Da­ten aus dem Quell­sys­tem mit dem Ziel­sys­tem überprüft:

• i.d.R. ma­nu­el­ler Sicht­ver­gleich von Lis­ten aus Quel­len- und Ziel­sys­tem
• i.d.R. de­tail­lierte Ab­stim­mung und Re­vi­sion (Vier-Au­gen-Prin­zip)

Fazit

Den we­sent­li­chen Punkt im Rah­men der Mi­gra­tion stel­len do­ku­men­tierte Ab­stim­mungs­hand­lun­gen auf Ba­sis ei­nes Ab­stim­mungs­kon­zep­tes dar, wel­che die Rich­tig­keit und Vollständig­keit der über­tra­ge­nen Da­ten nach­voll­zieh­bar auf­zei­gen.
Ha­ben Sie SAP ERP im Ein­satz und pla­nen auf eine HANA-Da­ten­bank um­zu­stei­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 An­pas­sun­gen vor­ge­nom­men wur­den.

Exkurs: Verfahrensdokumentation?

Be­son­ders zu be­ach­ten bei der Sys­tem­mi­gra­tion ist eine ge­set­zes­kon­forme Ver­fah­rens­do­ku­men­ta­tion. Gemäß GoBD wird ein Haupt­do­ku­ment mit im We­sent­li­chen un­veränder­ten In­hal­ten be­reit­ge­stellt, wel­ches auf die je­wei­li­gen Un­ter­do­ku­mente re­fe­ren­ziert. Dazu gehören un­ter an­de­rem Ver­fah­rens­be­schrei­bun­gen im De­tail in­klu­sive IKS, tech­ni­sche Un­ter­la­gen und Handbücher, Ar­beits­an­wei­sun­gen so­wie Verträge und Pro­to­kolle. Sämt­li­che Be­stand­teile sind lau­fend ak­tu­ell zu hal­ten und über die Dauer der ge­setz­li­chen Auf­be­wah­rungs­frist von zehn Jah­ren auf­zu­be­wah­ren.