Datenbereinigung und Datenübernahme von Altsystem nach mySAP ERP 2005 bei einem internationalen Automobilzulieferer


Diplomarbeit, 2007

55 Seiten, Note: 2,4


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

1. Einleitung
1.1. Ziel der Diplomarbeit
1.2. Vorstellung des Unternehmens
1.3. Vorstellung des Migrationsprojektes von Cooper

2. Einführung in die Thematik
2.1. Begriffsklärung
2.1.1. Datenmigration
2.1.2. Datenqualität
2.2. Methoden zur Datenübernahme
2.2.1. Batch-Input Mappen
2.2.2. Legacy System Migration Workbench

3. Vorbereitungen einer Datenmigration
3.1. Analyse des „Business Blueprint“
3.1.1. Business Blueprints bei Cooper Standard Automotive
3.1.2. Identifikation der Datenquellen (Alt-System)
3.1.3. Identifikation der Daten-Objekte (Soll-System)
3.2. Analyse der geeigneten Übernahmemethoden
3.2.1. Vorüberlegungen
3.2.2. Vorteile von Batch-Input
3.2.3. Grenzen von Batch-Input
3.2.4. IDocs versus Batch-Input
3.2.5. Application Link Enabling (ALE)
3.2.6. Business Application Programming Interface (BAPI)
3.2.7. Methodenübersicht
3.3. Viele Werkzeuge für ein Problem
3.3.1. Datenübernahme Workbench
3.3.2. DX-Workbench vs. LSMW
3.3.3. Was kann „Informatica“?
3.3.4. Kriterien zur Methodenauswahl
3.4. Vorgehensschema einer Datenmigration
3.4.1. Phasen einer Datenmigration Vorgehensschema einer Datenmigration in 5 Phasen
3.4.2. Probleme bei der Datenaufbereitung und Konvertierung
3.5. Verschiedene Umsetzungen des Konzeptes
3.5.1. Voranalyse der Altdaten
3.5.2. Analyse des Zielsystems
3.5.3. Entscheidung für Migrationstechnik
3.5.4. Migrationsplanung
3.5.5. Auswertung der Verfahren

4. Zusammenfassung
4.1. Viele Konzepte, keine Normen
4.2. Schlussbemerkungen

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1 Datenqualität Kriterien (Quelle: Informatica)

Abbildung 2 Datenqualität – Struktur (Quelle: Müller)

Abbildung 3 Screenshot SAP: Transaktionsaufzeichnung (Batch-Input-Mappe)

Abbildung 4 Vorgehensweise Batch-Input nach SAP

Abbildung 5 Vorgehensweise LSMW nach SAP

Abbildung 6 Screenshot SAP: LSMW – Strukturbeziehungen pflegen

Abbildung 7 Aufbau einer IDoc Nachricht (Quelle: SAP)

Abbildung 8 Vorgehensweise Datenübernahme-Workbench nach SAP

Abbildung 9 Beispieldatei für Übernahme (Auszug)

Abbildung 10 Postleitzahlen in Beispieldatei

Abbildung 11 Screenshot SAP: Debitor anlegen

Abbildung 12 Screenshot SAP: LSMW – Anzeige umgesetzter Daten

Abbildung 13 Screenshot SAP: LSMW – Fieldmapping

Abbildung 14 Screenshot SAP: DX-Workbench

1. Einleitung

Migrationsprojekte, die mit einem Wechsel des ERP-Systems verbunden sind, sind meistens aufwendige Großprojekte, welche die Beteiligten über lange Zeit binden.

Neben den wichtigen Elementen einer Migration wie der Umstellung der Hardware, der Softwareimplementation und der Schulung der Mitarbeiter auf das neue System ist auch ein weiteres Teilprojekt von enormer Wichtigkeit: Die Datenübernahme. Ein frisch aufgesetztes SAP-System kann noch so modern und leistungsstark sein – ohne dass es zunächst mit den betriebsrelevanten Daten gefüttert wird, kann man es nicht produktiv einsetzen. Was ist jedoch die geeignete Vorgehensweise, wenn man Daten sicher übertragen will? Wie genau sollte eine Datenübernahme vorbereitet werden? All dies sind Fragen, denen in dieser Arbeit nachgegangen werden soll.

Im Gegensatz zu der Einführung bzw. Entwicklung von Softwaresystemen gibt es für die Übernahme von Altdaten kein einheitliches Vorgehensmodell. Wenn ein System über die Jahre gewachsen ist, fehlt bei den Mitarbeitern zusätzlich eventuell auch das nötige Fachwissen, eine Migration der Daten erfolgreich durchführen zu können. Ohne eigene Erfahrungswerte und einheitliche Modelle kann man aber bei einem derart komplexen Thema leicht den Überblick verlieren.

Dazu kommt noch die Thematik, dass Daten nicht einfach sorglos übernommen werden können. Gerade bei langjährig im Einsatz gewesenen Systemen wird es zwangsläufig viele Daten geben, welche im einen oder anderen Punkt nicht den Kriterien des neuen Systems entsprechen. Daher muss auch das Thema der sogenannten „Datenbereinigung“ im Zuge einer Datenübernahme besonders beachtet werden.

1.1. Ziel der Diplomarbeit

Wenn man einfach die Datenbank des Altsystems kopieren könnte, das neue System diese Datenbank kurz analysieren und vielleicht noch die Daten bereinigen würde und man schließlich mit dem neuen System arbeiten könnte, gäbe es gar kein Problem mit einer Datenübernahme.

Da dem nicht so ist, sondern hingegen es eine Menge zu beachten gibt bei einer Datenmigration, soll es ein Ziel dieser Arbeit sein, in diesen Themenkomplex einzuführen.

Der Fokus liegt hier eindeutig auf SAP und den SAP-eigenen Methoden zur Datenübernahme. SAP ist ein bekanntes Softwareunternehmen und deren ERP-Lösung findet international immer mehr Verbreitung. SAP bietet dabei speziell für das Themengebiet der Datenübernahme eine ganze Anzahl von Möglichkeiten, wie Daten sauber und korrekt übernommen werden können.

An erster Stelle steht somit zunächst eine Einführung in diese Möglichkeiten, Daten aus einem Altsystem nach mySAP zu übertragen. Es sollen zunächst die Grundlagen über Datenmigration und Datenbereinigung aufgezeigt werden und darauf aufbauend dann die bekanntesten und wichtigsten SAP-spezifischen Datenübernahmemöglichkeiten erläutert werden.

Ein weiteres Ziel ist es, diese Verfahren anschließend genauer zu analysieren und deren Vorteile und Nachteile herauszuarbeiten. Darauf aufbauend kann dann bereits eine grobe Einschätzung gegeben werden, für welche Anwendungsfälle sich welche Vorgehensweise am besten eignet. Dies soll anhand einer kurzen Evaluation und grafischer Darstellung dann nochmals verdeutlicht werden.

In dieser Arbeit soll auf diese Erkenntnisse aufbauend dann schließlich ein Vorgehensschema für Datenmigrationen entwickelt werden. Dies ist sinnvoll, da es derzeit keine einheitlichen Vorgehensmodelle für Datenmigrationen gibt und so ein gut verständlicher „Ablaufplan“ vermittelt wird, der auch bei eigenen Datenübernahmeprojekten Anwendung finden kann.

1.2. Vorstellung des Unternehmens

Das Unternehmen Cooper Standard Automotive International Division (CSAID, im Folgenden „Cooper“) ist ein international tätiger Automobilzulieferer. Es stellt sogenannte „Sealing Systems“ und „Fluid Systems“ her. Dies sind Gummidichtungen für die Autotüren und z.B. Bremsleitungen. Weiterhin produziert Cooper Heizungen, Kühlung & Air-Conditioning, Servolenkungen und Abgassysteme.

Cooper hat 19000 Beschäftigte in 78 Zweigstellen in 17 Ländern. Unter anderem produziert Cooper in USA, Brasilien, Indien, Polen, Tschechien, Großbritannien, Frankreich, Spanien und Deutschland. Die IT-Zentrale des Unternehmens für Europa liegt am Standort Schelklingen. Dieser wurde als „Metallwarenfabrik Schelklingen“ gegründet und später von „Siebe Automotive“ aufgekauft. Siebe wiederum wurde von „Cooper Tire & Rubber“ im Jahr 2000 aufgekauft und das Werk wurde in die internationale Unternehmensstruktur integriert.

2005 spaltete sich das Unternehmen in zwei unabhängige Konzerne „Cooper Tire“ und „Cooper Standard“. Erstere konzentriert sich seitdem auf das amerikanische Kerngeschäft und die Produktion von Autoreifen.

Für die Inbetriebnahme des europäischen Rechenzentrums wurde eigens die IT-Zentrale in ein eigenes Gebäude outgesourced. Im Rechenzentrum der IT stehen die Server der in den einzelnen Werken verwendeten ERP-Systeme. Ebenso läuft über dieses Rechenzentrum der europäische Mailverkehr des Unternehmens.

Am Standort Schelklingen fand auch die praktische Ausbildung in den Praxisphasen der Studienzeit statt. Derzeit wurde mit ITT ein weiterer Automobilzulieferer aufgekauft, der Aufkauf von Metzeler Automotive steht kurz bevor.

Somit expandiert das Unternehmen beständig, was insbesondere auch die IT vor große Herausforderungen stellt.

1.3. Vorstellung des Migrationsprojektes von Cooper

Schon im Jahre 2005 war bei Cooper die Erkenntnis gereift, dass die derzeitigen, verschiedenen ERP-Systeme in den einzelnen Werken und Ländern allesamt an ihre Grenzen stoßen würden. Der Support für das in Deutschland verwendete ERP-System FORS sollte in den nächsten Jahren von Atos eingestellt werden und daher war der Wunsch nach einem neuen System verständlich. Erklärtes Ziel war es, am Ende europaweit ein einheitliches ERP-System in allen Werken zu haben.

Bereits zu diesem Zeitpunkt wurden umfangreiche Anforderungsdokumente erstellt und eine Evaluation der auf dem Markt befindlichen Produkte gestartet. Über ein Jahr danach war dann die Wahl auf SAP gefallen.

Als erstes sollten die Werke in Frankreich, danach in Deutschland auf das neue System wechseln.

Gemeinsam mit der AllForOne Systemhaus AG wollte man diese Aufgabe meistern. Es wurde neue Hardware beschafft sowie eine Testinstallation von SAP vorgenommen. Ebenfalls wurde das spätere Design, der Funktionsumfang etc. genau definiert und der Soll-Zustand des künftigen SAP-Systems entwickelt.

Der nächste Schritte war nun, das neue System zu customizen, wofür Berater und Entwickler von AllForOne bei Cooper vorstellig waren.

Sobald das neue System dem Business Blueprint gemäß eingerichtet und konfiguriert ist, wird dann im nächsten, entscheidenden Schritt die Übernahme der Daten aus dem alten ERP-System erfolgen. Gleichzeitig, während das neue System noch vorkonfiguriert wird, kann dabei bereits die Vorbereitung zur späteren Datenmigration erfolgen.

Besonders in dieser Vorphase der Datenmigration liegt das Hauptaugenmerk dieser Diplomarbeit. In dieser Phase entsteht der Hauptaufwand, da hier die Analyse des Altsystems ebenso erfolgen muss wie die Festlegung auf eine Vorgehensweise, eine Übernahmemethode etc.

Wie allgemein ein solches Datenübernahmeprojekt anzugehen ist, auf was man achten sollte und wie die SAP-eigenen Mittel sinnvoll eingesetzt werden können, soll diese Arbeit mit Hilfe eines abschließenden Praxisbeispiels aus dem Projektumfeld bei Cooper veranschaulichen.

2. Einführung in die Thematik

Das Gebiet der Datenmigration und Datenbereinigung mag leicht verständlich und übersichtlich klingen, wenn man diese Begriffe das erste Mal zu hören bekommt. Man migriert Daten, also überträgt sie von einem System zu einem Anderen. Doch so einfach wie es am Anfang klingt, ist es bei weitem nicht.

Denn zunächst ist die Frage zu stellen, wie genau Daten eigentlich übertragen werden.

Welche Methoden gibt es speziell von SAP, um von Altsystemen Daten einspielen zu können? Auf diese Fragen soll das folgende Kapitel eine Antwort geben. Es wird die Begriffe der Datenmigration und vor allem auch der Datenbereinigung in der Theorie vorstellen und wichtige Grundkenntnisse vermitteln. Daran wird sich eine Einführung in die zwei wichtigsten Methoden und Werkzeuge zur Datenübernahme von SAP anschließen.

Danach ist das Rüstzeug für die spätere, genauere Betrachtung der Übernahmemethoden von SAP geschaffen.

2.1. Begriffsklärung

Zunächst soll im Folgenden das Themengebiet der Datenübernahme näher beleuchtet werden. Es wird erläutert, was Datenmigration genau ist und warum dieses Gebiet in jedem Migrationsprojekt einen der wichtigsten Teilprozesse bildet. Auch der Zusammenhang zwischen Datenübernahme und Datenqualität, bzw. Datenbereinigung wird näher beleuchtet. Dieses Grundverständnis ist wichtig, um später verstehen zu können, was die Datenübernahmemethoden von SAP genau machen und um ein Gespür für die Wichtigkeit von konsistenten Datenbeständen zu vermitteln.

2.1.1. Datenmigration

Wenn man von „Migration“ spricht, ist damit in der Informationstechnik natürlich nicht die Wanderbewegung von Völkern, Tieren, Planeten oder ähnlichem gemeint. Der Begriff „Migration“ steht allgemein für „(aus)wandern“[1]. In der EDV bedeutet dies also quasi eine Wanderung von etwas altem hin zu etwas neuem. Alte Technologie wird z.B. in neue Technologie integriert.[2]

Grundsätzlich wird in der Informationstechnik zwischen zwei Arten der Migration unterschieden, der sogenannten „Softwaremigration“ und der „Datenmigration“.

Bei dem dieser Arbeit zugrundeliegenden Projekt handelt es sich sowohl um eine Softwaremigration als auch um eine damit einhergehende Datenmigration, die auszuführen ist. Die Software – in diesem Falle das alte ERP-System – wird gewechselt, wofür daraufhin dann die alten Daten übernommen werden müssen.

Sobald Daten von einem Medium auf ein anderes bzw. von einem System zu einem anderen übertragen werden, kann man von Datenmigration sprechen.[3]

Wenn neue Softwaresysteme in einem Unternehmen eingeführt werden ist es unerlässlich, dass die produktiven Daten sowie wichtige historische Daten, die für das Weiterarbeiten von Nöten sind, in das neue System übertragen werden.

Diese „Fütterung“ des Neusystems mit Daten, ist ein wichtiges Teilprojekt jedes Migrationsprojektes und kann einen Großteil der Projektressourcen binden[4].

Datenmigration und Datenübernahme sind daher also synonym verwendete Begriffe für den ganzen Teilbereich der Auswählung von betriebswirtschaftlichen Daten aus einem Altsystem und deren Übertragung ins neue System, z.B. SAP.

Genauer gesagt ist bei der Übertragung von Altdaten aus ERP-Systemen die Übernahme von sogenannten Stammdaten und Bewegungsdaten gemeint.[5]

Es gibt in der Theorie drei verschiedene Arten, wie ein Migrationsprojekt generell durchgeführt werden kann. Hierbei wird zwischen weicher, integrativer und harter Migration unterschieden.[6]

Weiche Migrationen laufen quasi in mehreren Schritten ab, in welchen Alt – und Neusystem teilweise parallel betrieben werden und der Umstieg ebenfalls Stück für Stück erfolgt.

Noch anspruchsvoller als diese Methode ist die integrative Migration, bei welcher das neue System auf die Datenbestände des Altsystems zugreifen und mit diesen arbeiten kann. Dies erfordert erheblichen Programmieraufwand, was in der Praxis meist dazu führt, dass man sich für andere Optionen entscheidet, wie zum Beispiel die „harte Migration“, den „Big Bang“, bei welchem der Umstieg auf das neue System zu einem gewissen Stichtag erfolgt und die Daten nur einmal „initial“ übernommen werden.[7]

Um eine Datenmigration erfolgreich durchführen zu können, müssen dafür zunächst aus der gesamten Datenmenge des Altsystems die relevanten Daten ermittelt werden. Diese können wie bereits beschrieben in „Stammdaten“ und „Bewegungsdaten“ unterschieden werden.

Stammdaten sind hierbei jene Daten, welche über längere Zeit unverändert bleiben und Informationen enthalten, welche immer wieder benötigt werden.[8]

Bei Bewegungsdaten handelt es sich im Umkehrschluss um veränderliche Daten, welche aktuell sein müssen und für das operative Geschäft wichtig sein können.

Alte Bewegungsdaten sind z.B. Buchungsbelege und damit historische Daten, welche aber immer noch für Auswertungen herangezogen werden können und somit von Wichtigkeit sein können.[9]

Wenn man sich mit der Frage befasst, wie denn Daten generell übertragen werden können, stößt man meistens auf sogenannte Importtechniken.

Dabei werden die Daten aus den alten Quellen in Dateien ausgelesen, welche einem vordefinierten Aufbau genügen müssen. Diese werden dann in das neue System geladen, welches aus den Dateien die Daten extrahiert und in die Datenbank einpflegt.

Ebenfalls besteht die Möglichkeit, dass die Daten direkt über Schnittstellen ins neue System gelangen. Hier werden sie dann meist zwischengespeichert und mit speziellen Tools wird dann eine Anpassung der Altdaten an die Gegebenheiten des neuen Systems vorgenommen.[10]

Wenn Daten von einer Datenbank in eine andere übertragen werden sollen, muss man sich in diesem Zusammenhang auch die Anforderungen eines Datenbankmanagementsystems an die Daten näher betrachten.

Dabei ist eine wichtige Anforderung an Datenbanken, dass deren Daten frei von Redundanzen sind und die Datenintegrität sichergestellt ist[11].

Unter Datenintegrität versteht man dabei, dass die Daten in unveränderter Form (also im Originalzustand) vorliegen.[12]

Unter „Redundanz“ versteht man den Grad für die „Überflüssigkeit“ von Informationen, d.h. im Kontext von Datenspeicherung dass Daten mehrfach gespeichert werden, bzw. die Informationen mehrfach im Datenbestand vertreten sind.[13]

Insbesondere die Redundanzfreiheit wird im Laufe dieser Arbeit noch häufiger von Bedeutung sein, wenn es um das Thema „Duplettenprüfung“ geht.

Mit den Anforderungen, wie die Daten beschaffen sein müssen, um korrekt migriert werden zu können, befasst sich innerhalb der Datenmigration eine ganz eigene Unterkategorie. Die Rede ist hierbei von der „Datenbereinigung“ oder dem „Data-Cleansing“. Was genau darunter zu verstehen ist und welche Anforderungen noch an qualitativ „korrekte“ Daten gestellt werden, wird im Folgenden gezeigt werden.

2.1.2. Datenqualität

Im Zuge einer jeden Datenübernahme ist man vor die Frage gestellt, welche Daten des Altsystems wichtig sind und welche nicht. Damit Daten effektiv verarbeitet und interpretiert werden können müssen diese ausgewählten Daten darüber hinaus auch gewissen Qualitätsanforderungen entsprechen. Um dies zu gewährleisten, sollte bei einem Datenmigrationsprojekt immer auch großer Wert auf die Datenbereinigung und somit auf die Herstellung einer hohen Datenqualität gelegt werden.[14]

Was genau versteht man nun aber unter dem Begriff „Datenbereinigung“?

Datenbereinigung beschäftigt sich mit dem Erkennen und Entfernen von Fehlern und Inkonsistenzen in Daten um deren Qualität zu verbessern.[15]

Darunter versteht man einerseits, dass die Metadateneigenschaften von Quell- und Zielsystem kompatibel sind.[16]

Darüber hinaus bedeutet Datenqualität allerdings nicht nur eine Prüfung der Datenstruktur sondern auch eine semantische, inhaltliche Überprüfung der Daten.

Hierbei werden z.B. Maßnahmen zur Reduktion des Datenvolumens angewandt, um den Datenbestand von unnötigen, veralteten oder falschen Daten zu säubern.

Bei dieser Analyse des Altdatenbestandes sollen somit jene Daten gefunden und entfernt werden, welche im operativen System später keine Verwendung mehr finden.

So kann eine konsistente Datenbasis für das Neusystem generiert werden.[17]

Eine einfache, schablonenhafte Einteilung der Daten in qualitative gute und schlechte Daten kann so leicht allerdings nicht erfolgen. Es müssen vielmehr eine ganze Reihe von Kriterien überprüft werden, welche insgesamt qualitativ „gute“ Daten ausmachen.[18]

Um eine etwas genauere Einteilung der einzelnen Stufen der Datenqualität zu geben, beschreibt z.B. das Unternehmen Informatica folgende 6 Schlüsselkriterien:

Vollständigkeit, Konformität, Konsistenz, Fehlerfreiheit, Duplikatfreiheit und Integrität[19]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Datenqualität Kriterien (Quelle: Informatica)

In der zugrundeliegenden Literatur gibt es weitere Ansätze, in welche Kriterien die Datenqualität zu unterteilen ist und in welche Hierarchie diese Kriterien zu gliedern sind.

So steht bei [Müller] die Fehlerfreiheit (Akkuratheit) an oberster Stelle, unter welcher sich Sub-Kriterien wie Integrität, Konsistenz und Datendichte gruppieren. Diese gliedern sich wieder in weitere Sub-Kriterien.[20]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Datenqualität – Struktur (Quelle: Müller)

Zusammengefasst kann gesagt werden, dass unter dem Stichwort Datenqualität die Aufgaben der Qualitätssicherung des Datenbestandes verstanden werden können.

Gerade bei einem Datenmigrationsprojekt ist es wünschenswert, keine Daten in ein neues System zu übernehmen, welche lückenhaft oder mit Fehlern behaftet sind. Auch doppelte Einträge und Karteileichen sollten vermieden werden. Im weiteren Verlauf der Arbeit werden die einzelnen Kriterien der Datenqualität immer wieder Verwendung finden und abschließend ein Datenbestand auch auf jene Punkte wie Fehlerfreiheit etc. beispielhaft überprüft werden.

2.2. Methoden zur Datenübernahme

Nachdem nun allgemein definiert wurde, was man unter dem Begriff Datenmigration bzw. Datenübernahme zu verstehen hat und worauf hierbei zu achten ist, soll nun der Frage nachgegangen werden, welche Methoden es speziell für den Fall einer Migration nach SAP gibt, die Daten ins neue ERP-System zu übertragen.

Als Interne Methoden innerhalb von SAP stehen hierbei zunächst die Verfahren Batch-Input sowie Direct-Input und sogenannte BAPIs oder IDocs zur Verfügung.[21]

Auf letztere wird im späteren Verlauf noch näher eingegangen. Zunächst werden an dieser Stelle die wichtigsten Verfahren kurz vorgestellt.

Beim Direct-Input Verfahren werden die Daten direkt in das SAP-System übernommen. Die SAP-Datenbank wird dabei direkt mit den übernommenen Daten befüllt.[22]

Direct-Input wird auch als kontrolliertes, direktes Schreiben auf die Datenbank bezeichnet.[23]

Dieses Verfahren ist allerdings nur für sehr große Datenvolumen zu empfehlen, da beim Einlesen nur rudimentäre Prüfungen erfolgen und es wird daher im Folgenden nicht weiter vertieft.[24]

Besonders soll in dieser Einführung zunächst auf die gängigen Wege über Batch-Input Verfahren und die Legacy System Migration Workbench, kurz LSMW eingegangen werden. Im weiteren Verlauf der Diplomarbeit wird auf diese hier vermittelten Grundkenntnisse wieder zurückgegriffen.

Es sei noch erwähnt, dass es eine weitere Möglichkeit gibt, mit SAP Daten zu übernehmen, welche hier allerdings nicht behandelt wird: Das „Computer Aided Test Tool“ (CATT). Es wird in dieser Arbeit außer Acht gelassen, da es die geringste Mächtigkeit der zur Verfügung stehenden Methoden aufweist und vom ursprünglichen Entwurf für Testszenarios und nicht für Datenübernahmen vorgesehen war.[25]

2.2.1. Batch-Input Mappen

„Batch-Input ist eine der wichtigsten Methoden für die Übertragung von Daten in das R/3-System. Batch-Input wird für Massendatenübernahmen und nicht für fast Realtime-Datenübernahmen verwendet.“[26]

Diese Definition der SAP zeigt schon sehr deutlich, wofür Batch-Input konzipiert wurde. Es ist auf die Übertragung von großen Datenmengen bei einer initialen Datenübernahme (vgl. „harte Migration“) ausgelegt.

Beim Batch-Input-Verfahren wird im Grunde ein manueller, vom Nutzer gesteuerter Transaktionsablauf einer beliebigen SAP-Transaktion simuliert und die Daten so übernommen, als würden sie von Hand in die Bildschirmmasken eingegeben werden.

Dadurch ist z.B. bereits das Qualitätskriterium eines konsistenten Datenbestandes gegeben, da durch das Abarbeiten der Transaktion auch alle mit dieser verknüpften Prüfungen durchlaufen werden. Somit können keine fehlerhaften Daten ins System gelangen, die Transaktion würde sonst abbrechen und einen Fehler melden.[27]

Der Ablauf eines Datenimports via Batch-Input ist generell in mehrere Schritte zu unterteilen.[28]

Vorraussetzung für das Durchführen eines Batch-Inputs ist die Erstellung einer sogenannten Batch-Input-Mappe.

Eine Batch-Input Mappe ist dabei eine Stapelverarbeitung bei SAP. Genauer definiert besteht sie aus einer Reihenfolge von Transaktionscodes und Dynpro-Aufrufen mit den dazugehörigen Daten.[29]

Eine einmal erstellte Mappe wird dann vom Anwender „abgespielt“, das heißt, die einzelnen in der Mappe hinterlegten Transaktionen und Bildschirmmasken werden automatisch aufgerufen. Hierbei werden die Eingabefelder der jeweiligen SAP-Transaktion im Hintergrund mit den Daten aus der Batch-Input-Mappe versorgt.

Im Grunde ruft also eine Batch-Input-Mappe automatisch und ohne dass der Nutzer etwas davon bemerkt eine SAP-Transaktion und die dazugehörige Bildschirmmaske auf (z.B. „Material anlegen“) und trägt in die definierten Eingabefelder die Daten aus der Mappe ein. Hierfür ist notwendig, dass in der Mappe jede für die Datenübernahme notwendige Transaktion, jede Bildschirmmaske und jedes Eingabefeld definiert ist.

Es gibt allgemein mehrere Möglichkeiten, eine solche Batch-Input-Mappe zu erzeugen. Eine gängige Methode ist hier die „Batch-Input-Aufzeichnung“. Hierbei ruft der Anwender eine Transaktion auf, welche er für die Dateneinspielung verwenden möchte.

Ähnlich der Makroaufzeichnung in Microsoft Office wird nun bei der Batch-Input-Aufzeichnung jeder Arbeitsschritt des Anwenders im Hintergrund protokolliert und gespeichert. Man legt in diesem Fall exemplarisch einen neuen Datensatz an. Dabei ist darauf zu achten, dass alle benötigten Felder auch mit Daten belegt werden.

Kann-Felder, welche bei der Aufzeichnung unberücksichtigt bleiben, in späteren Datensätzen allerdings vorhanden sind, können zu Problemen führen.

Die später aus der Aufzeichnung erstellte Mappe wird dann diese unberücksichtigten Felder ebenfalls nicht beinhalten. Jene Datensätze der Altdaten, welche dann aber diese Felder belegt haben können dann nicht mithilfe dieser Batch-Input-Mappe migriert werden.[30]

Nachdem eine Batch-Input-Aufzeichnung mithilfe des Transaktionsrecorders abgeschlossen ist, kann daraus z.B. ein ABAP Programm erstellt werden, mit welchem die Daten eingespielt werden können. Dieser Schritt ist notwendig, da der Transaktionsrecorder nur eine einzige Transaktion aufgezeichnet hat. Daraus muss nun eine Mappe erzeugt werden, welche den selben Aufbau wie diese Aufzeichnung hat, jedoch anstelle der alten Daten der Beispieltransaktion jeweils die zu migrierenden Daten aus dem Altsystem enthält.

Weniger Programmieraufwand beim Erstellen einer Mappe aus einer Transaktionsaufzeichnung heraus erfordert die Funktion der Serienbrieferstellung von Microsoft Word. Hierbei wird die Aufzeichnung in Word hineinkopiert und es können dann externe Datenquellen an den Serienbrief angebunden werden.

Diese externe Datenquelle kann z.B. ein extrahierter und vorbereinigter Datenbestand sein, welcher auf den Aufbau der Batch-Input-Mappe angepasst ist.[31]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Screenshot SAP: Transaktionsaufzeichnung (Batch-Input-Mappe)

Eine weitere Möglichkeit, Batch-Input-Mappen zu erzeugen, bietet sich über die

Standard-Batch-Input-Programme. Diese sind vordefinierte Programme, welche speziell für Anwendungsfälle wie die Übernahme von z.B. Kundenstammdaten entwickelt wurden. Da sie allgemein gehalten sind, sind in diese Programme auch viele Standard-Konstellationen integriert, sprich Datenfelder, welche so sehr häufig Verwendung finden. Dies mach ein derartiges Programm und die damit erzeugten Mappen wesentlich komplexer als manuell über eine Aufzeichnung erstellte Mappen.

Da sich SAP-Transaktionen für verschiedene Eingabedaten unterscheiden können, z.B. durch unterschiedliche Folgemasken nach Dateneingabe, ist diese Möglichkeit mit unter einer durch Aufzeichnung erstellten Mappe vorzuziehen. Diese verwendet immer nur einen exemplarischen Fall und überträgt diesen dann auf alle folgenden Datensätze. Ein Standard-Batch-Input-Programm kann allerdings für mehrere Datensätze die passenden Bildschirmmasken so in der Batch-Input-Mappe erzeugen, dass diese korrekt abgespielt werden kann und die Daten fehlerfrei ins System übertragen werden.[32]

Die empfohlene Vorgehensweise beim Datenimport via Batch-Input sieht einen Ablauf wie in der folgenden Grafik dargestellt vor:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Vorgehensweise Batch-Input nach SAP

In der Entscheidungsphase sollte überlegt werden, ob einmalig eine Massendatenübernahme erfolgen soll oder ob das Altsystem parallel weiter genutzt werden soll. In diesem Fall sind periodische Datenübernahmen sinnvoller.

Hat man sich für eine initiale Datenübernahme und Batch-Input als Übernahmemethode entschieden, erfolgt im nächsten Schritt dann die Erzeugung der Batch-Input-Mappen und deren anschließende Verarbeitung.

[...]


[1] [Meyers]

[2] [ITWissen.info]

[3] [Pentadoc.de]

[4] [Willinger 2003]: S. 11

[5] [Willinger 2003]: S. 37, S. 313

[6] [Pentadoc.de]

[7] [Pentadoc.de]

[8] [Willinger 2003]: S. 19

[9] [Willinger 2003]: S. 19

[10] [Willinger 2003]: S. 194

[11] [Kleuker]: S. 6

[12] [Hansen]: S. 175

[13] [Hansen]: S. 1055

[14] [Müller]: S. 8

[15] [Rahm]: S. 1

[16] [Informatica]: S. 4

[17] [Willinger 2003]: S. 20

[18] [Informatica]: S. 5

[19] [Informatica]: S. 5

[20] [Müller]: S. 8

[21] [help.sap.com]: Techniken der Datenübernahme

[22] [help.sap.com]: Techniken der Datenübernahme

[23] [Willinger 2003]: S. 42

[24] [Willinger 2003]: S. 265

[25] [Willinger 2003]: S. 262

[26] [help.sap.com]: Batch-Input: Prozessübersicht

[27] [help.sap.com]: Techniken der Datenübernahme

[28] [help.sap.com]: Batch-Input: Prozessübersicht

[29] [Willinger 2003]: S. 47

[30] [Willinger 2003]: S. 59

[31] [Willinger 2003]: S. 63 ff., S. 81 ff.

[32] [Willinger 2003]: S. 55

Ende der Leseprobe aus 55 Seiten

Details

Titel
Datenbereinigung und Datenübernahme von Altsystem nach mySAP ERP 2005 bei einem internationalen Automobilzulieferer
Hochschule
Duale Hochschule Baden-Württemberg, Ravensburg, früher: Berufsakademie Ravensburg
Note
2,4
Autor
Jahr
2007
Seiten
55
Katalognummer
V85377
ISBN (eBook)
9783638900287
ISBN (Buch)
9783638905725
Dateigröße
555 KB
Sprache
Deutsch
Schlagworte
Datenbereinigung, Datenübernahme, Altsystem, Automobilzulieferer
Arbeit zitieren
Dipl. Wirtschaftsinformatiker (BA) Oliver Jung (Autor:in), 2007, Datenbereinigung und Datenübernahme von Altsystem nach mySAP ERP 2005 bei einem internationalen Automobilzulieferer, München, GRIN Verlag, https://www.grin.com/document/85377

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Datenbereinigung und Datenübernahme von Altsystem nach mySAP ERP 2005 bei einem internationalen Automobilzulieferer



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden