Datenmigration Erfahrungsberichte aus Oracle E-Business Suite Release 11i- und 12-Projekten

Transkript

1 Datenmigration Erfahrungsberichte aus Oracle E-Business Suite Release 11i- und 12-Projekten Michael Weiler, PROMATIS software GmbH Ettlingen, 19. März

2 Gliederung Migrationsprojekte Teil eines Ganzen Funktionsumfang Beispiel einer Projektstruktur Migrationsobjekte Stammdaten Bewegungsdaten Abhängigkeiten Migrationstechnologien MS-Excel und WebADI (EBS) Schnittstellentabellen und Hintergrundprogramme (EBS) Datenbereinigung (Data Cleansing) Projektteam und abwicklung Projektteam Projektabwicklung Different Mentalities Q & A 2

3 Migrationsprojekte Teil eines Ganzen ERP-Migrationsprojekte sind oft nicht weniger aufwändig als ERP- Einführungsprojekte Komplexe Anforderungen an das Migrations-Projektteam Abhängigkeiten zwischen einzelnen Migrationsobjekten Mapping von Datenstrukturen bestehender Anwendungen zur neuen ERP- Anwendung Entsorgung und Wiederaufbereitung von veralteten Daten (Data Cleansing) Berücksichtigung von kulturellen Rahmenbedingungen (bezogen auf Kunde und Projektteam) 3

4 Migrationsprojekte Funktionsumfang Welche Stammdaten (Artikel, Kunden, Lieferanten, etc.) sollen übernommen werden? Welche Bewegungsdaten (Rechnungen, Gutschriften, Artikelbestände, Aufträge etc.) sollen übernommen werden? Welche Abhängigkeiten existieren zwischen den zu migrierenden Daten? Können bestimmte Daten manuell übernommen werden? 4

5 Migrationsprojekte Funktionsumfang Welche Daten können schwer oder gar nicht (im Standard) übernommen werden? Welche Mitarbeiter (interne und externe) stehen zur Verfügung? Welche Fähigkeiten haben sie? Welche Aufgaben können von internen Mitarbeitern übernommen und was muss extern vergeben werden? Empfehlung: Separates Migrationsprojekt sollte - parallel zum eigentlichen Einführungsprojekt - aufgesetzt werden. 5

6 Migrationsprojekte Beispiel einer Projektstruktur Projektsteuerungs- und Organisationsaufgaben Phase I Phase II Phase III Phase IV Phasenorientierte Einführung der Oracle Applikationen Projektdefinition Architektur Financials Processes Procurement& Logistics Execution Partner Self-Service Analytics Processes Provisionsabrechnung Datenmigration Systemmanagement 6

7 Migrationsobjekte Stammdaten Mitarbeiter (inkl. EBS Benutzer und Zuständigkeiten) Lagerorganisationen (inkl. Standorte, Läger, Lagerplätze und Liefernetze) Artikel (inkl. Hauptartikelstamm, Zuordnung zu Lagerorganisationen und Artikelkategorien, Artikelquerverweise) Preislisten und Rabatte Stücklisten Lieferanten (inkl. Adressen und Bankverbindungen) Liste der genehmigten Lieferanten (Welchen Artikel darf ich über welchen Lieferanten beziehen?) Kunden (inkl. Adressen und Bankverbindungen) Banken 8

8 Migrationsobjekte Bewegungsdaten Artikelbestände (pro Lagerorganisation) Bestellungen Aufträge Artikelbestände Offene Posten Kunden (Rechnungen, Gutschriften und Zahlungen) Offene Posten Lieferanten (Rechnungen und Anzahlungen) Anlagevermögen Summen- und Saldenlisten 9

9 Migrationsobjekte Stamm- und Bewegungsdaten Anzahl der Migrationsobjekte oft > 20 Müssen alle Migrationsobjekte automatisiert übernommen werden? Gefahr: Migrationsaufwände > Einführungsaufwände Keep it simple and keep it focused ist hier eine sehr gute Strategie, um die Projektlaufzeiten im Rahmen zu halten. 10

10 Migrationsobjekte Stamm- und Bewegungsdaten Empfehlung 1: Bewegungsdaten werden i.d.r. zu einem Stichtag übernommen. Eine Ausnahme stellen die Summen- und Saldenlisten dar. Hier sollten mindestens die Kontenbewegungen der letzten zwölf Monate übernommen werden. Empfehlung 2: Es werden nur Bestellpositionen übernommen, bei welchen noch der Wareneingang fehlt. Noch nicht mit Lieferantenrechnungen abgeglichene Bestellpositionen (mit schon gebuchtem Wareneingang) sind bereits in den Artikelbeständen berücksichtigt. 11

11 Migrationsobjekte Stamm- und Bewegungsdaten Empfehlung 3: Ebenso sollten nur Auftragspositionen übernommen werden, die noch nicht versendet und somit auch noch nicht fakturiert sind. Schon zum Stichtag versendete Auftragspositionen sind als Abgänge in den Artikelbeständen berücksichtigt worden. Empfehlung 4: Geschlossene Bestellungen, Aufträge, Kunden- und Lieferantenrechnungen sollten nicht übernommen werden. 12

12 Migrationsobjekte Abhängigkeiten Migrationsobjekte können nicht in beliebiger Reihenfolge geladen werden, da kausale Abhängigkeiten bestehen. Empfehlung 5: Um die Komplexität zu reduzieren wird empfohlen, die Migration in mehrere Teilprojekte (Phasen) zu unterteilen. Nachfolgende Abbildung zeigt eine mögliche Unterteilung in vier Teilprojekte. 13

13 Migrationsobjekte Abhängigkeiten 14

14 Migrationsobjekte Abhängigkeiten Migrationsobjekt Artikelstamm 15

15 Migrationsobjekte Abhängigkeiten Fazit: Wie bei der Einführung der EBS sollte auch bei der Datenmigration in Prozessen gedacht werden. 16

16 Migrationstechnologien (EBS) Migrationsobjekte werden durch den Einsatz unterschiedlicher Technologien in die EBS geladen. Die wichtigsten sind: Import über MS-Excel und WebADI (Application Desktop Integrator) Beispiele: Summen- und Saldenlisten, Anlagevermögen Schnittstellentabellen und Hintergrundprogramme Beispiele: Artikelstamm und offene Posten API s (Application Program Interfaces, z.b. ein PL/SQL Prozeduraufruf) Beispiele: Banken und Rabatte 17

17 Migrationstechnologien (EBS) MS-Excel und WebADI 18

31 Migrationstechnologien (EBS) Schnittstellentabellen und Hintergrundprogramme Ablaufbeispiel einer Artikelmigration: Die Migration erfolgt in zwei Schritten: 1. Eine spezifische PLSQL-Prozedur ermittelt über einen Datenbanklink alle Artikel, die migriert werden sollen. Diese werden dann in die Standard- Interfacetabelle geschrieben, aufgeteilt in Sets zu je Artikel. 2. Über Funktionen werden IDs gemappt: Standardeinkäufer im Altsystem -> Standardeinkäufer im Neusystem. Fehler werden in eine Fehlertabelle geschrieben und die entsprechenden Artikel in der Interfacetabelle gesperrt. 32

32 Migrationstechnologien (EBS) Technologien haben sich beim Übergang von R11i nach R12 in einigen Bereichen geändert. So sind in R12 z.b. Banken und Lieferanten in die TCA (Trading Community Architecture) integriert (d.h. Kunden, Banken und Lieferanten sind physisch in denselben Tabellen abgelegt). 33

33 Datenbereinigung Problemfelder Inaktive Kunden sollen nicht migriert werden: Es existieren jedoch Offene Posten für einen Teil dieser Kunden Pflichtfelder im neuen System existieren im bestehenden System nicht! Der Kundenstamm ist auf mehrere Systeme verteilt. Wie gelingt eine Zusammenführung! Es existieren Fehler im bestehenden System: Angebliche Pflichtfelder sind für einen Teil der Daten nicht gesetzt. Es existieren negative Lagerbestände für einige Artikel. Und vieles mehr Die Kunden- und Anlagennummern sind Mandanten übergreifend eindeutig. Im bestehenden System ist dies nicht der Fall! Einführung eines globalen (Haupt-) Artikelstamm mit eindeutiger Artikelnummer. Im bestehenden System ist dies nicht der Fall! 34

34 Datenaufbereitung Lösungsmöglichkeiten Aktivierung der Kunden mit Offenen Posten. Ableitungsregeln: Aus bestehenden Feldern werden die neuen Felder abgeleitet (z.b. Männlich, Weiblich Anrede: Herr bzw. Frau) Vormigration von mehreren Systeme: Duplikate eliminieren, Regelwerk erstellen etc. Fehlerbeseitigung durch automatische oder manuelle Bereinigung im bestehenden System. Vergabe von neuen Nummern: ACHTUNG Es muss für nachfolgende Migrationsobjekte das Mapping Alte Nummer Neue Nummer gespeichert werden. 35

35 Datenbereinigung Durchführung Für jedes Migrationsobjekt muss geklärt werden, wo das Data Cleansing durchgeführt wird. Hier sind mehrere Möglichkeiten denkbar: in den existierenden Legacy-Systemen in Zwischentabellen / (MS-Excel-) Dateien in den Schnittstellen-Tabellen Anforderungen für diese Aufgaben an das Projektteam: Sehr gute Kenntnisse in den Vorsystemen und im Zielsystem Technisches Know-How (Oracle Entwicklungswerkzeuge, Datenmodell) 36

36 Projektteam- und abwicklung Projektteam Bei der Zusammensetzung des Projektteams ist darauf zu achten, dass nicht nur Entwickler sondern auch erfahrene Mitarbeiter mit sehr guten EBS- Kenntnissen zum Einsatz kommen. Die Entwickler sollten mit den gängigen Oracle Werkzeugen vertraut sein und mit den Endanwendern auf Augenhöhe Anforderungen diskutieren können. Um die Projektlaufzeiten im Rahmen zu halten, muss das Migrationsprojekt eine entsprechende Priorität erhalten. Eine Try and Error -Methode bei der Entwicklung der Schnittstellen führt zum Scheitern des Projekts. Mix von Entwicklern und funktionalen Beratern muss stimmen 37

37 Projektteam- und abwicklung Projektabwicklung Bevor das Projekt startet, sollte eine ausführliche Analyse erfolgen. Abläufe sind zu dokumentieren, Teilprojekte mit Meilensteinen müssen realistisch geplant werden. Die Dauer zwischen zwei Meilensteinen sollte weniger als vier Wochen betragen. Mehrere Testmigrationsläufe sind einzuplanen. Die Tests sollten mit möglichst aktuellen Daten durchgeführt werden. Mit der Datenbereinigung ist frühzeitig zu starten. Nur so kann die Migrationsquote an die 100% herangeführt werden. 38

38 Projektteam- und abwicklung Projektabwicklung Die Endanwender sind frühzeitig in das Migrationsprojekt einzubinden. Es müssen ausreichend Trainings durchgeführt werden bei internationalen Projekten möglichst in der jeweiligen Landessprache. Ebenfalls sollten die Endanwender in Entwicklungsentscheidungen eingebunden werden, damit sie sich als Teammitglieder verstehen, die gefällten Entscheidungen mittragen und bei Problemen das Migrationsteam unterstützen. Bei internationalen Projekten auch in Europa auf landesübliche Gepflogenheiten achten. Es sollte berücksichtigt werden, wie wir Deutsche im Ausland gesehen werden. 39

39 Projektteam- und abwicklung Different Mentalities 40

45 Questions & Answers Kontakt Michael Weiler Dipl.-Wirtschaftsing. Principal Senior Consultant PROMATIS software GmbH Pforzheimer Str Ettlingen Tel Fax Web: michael.weiler@promatis.de 46