11. August 2024

Stilllegung der Altsysteme

Cite this article:

Espeter, F. (2024): Stilllegung der Altsysteme. DPI Verlag, In ERP Information 3/2024, S. 37–40

https://doi.org/10.58678/erp-information_24-3_37-40

Es gibt sicherlich Ausnahmen wie zum Beispiel bei der Gründung eines Joint Ventures oder bei einem Buy-out, doch in der Regel beinhaltet ein ERP-Implementierungsprojekt nicht nur das Ablösen eines oder mehrerer Altsysteme durch ein Neusystem, sondern auch die damit verbundene Stilllegung des vorhandenen und genutzten Altsystems. 

In den wenigsten Fällen steht diese Teilaufgabe im betroffenen Unternehmen im Fokus des Projektes und wird selten vom Lieferanten des Neusystems mitangeboten. Es verbleibt also in der Verantwortung der lokalen IT, alle notwendigen Maßnahmen zu planen und durchzuführen. Der nachfolgende Artikel soll hierzu eine Hilfestellung geben. 

Implementierungen von Business-Systemen, sei es ein neues vollständiges ERP-System oder nur Teile davon (z. B. Personalmanagementsysteme), beinhalten fast immer ein Ablösen von Altsystemen. Darunter sind alle IT-Systeme zu verstehen, die mit der Einführung eines neuen Systems abgelöst, nicht mehr operativ genutzt werden und kontrolliert aus dem Betrieb genommen werden sollen, sodass in den Systemen keine Erfassung und Verarbeitung von Daten mehr möglich ist.

Hierbei handelt es sich nicht um ein einfaches Abschalten, sondern die Systeme werden entsprechend definierter Anforderungen kontrolliert „aus dem Betrieb genommen“. Diese Anforderungen sind sowohl gesetzlichen als auch betrieblichen Ursprungs. Regeln für die Verfügbarkeit und den Zugang sind zu definieren, die Systeme sind Bestandteil des Betriebskonzeptes und sie verbleiben teilweise in der IT-Landschaft. Wir sprechen hier von einer „Stilllegung“.

Die Altsysteme mit ihren Funktionen und Daten stellen in der Regel die Referenz für die Neuimplementierung dar und führen zu Anforderungen an die Funktionen des Neusystems und an die dazugehörige Datenmigration. Dabei reduziert sich der Einfluss der Altsysteme auf das Implementierungsprojekt nicht nur auf die Rolle des funktionalen Referenzsystems oder Datenlieferanten. In den meisten ERP-Implementierungsprojekten werden nicht alle Daten migriert, woraufhin sich die Frage stellt, was mit den Daten geschieht, die nicht migriert werden.

Da sich sowohl die funktionalen Anforderungen als auch die Strategie der Datenübernahme während des Projektverlaufes ändern können, ist es notwendig, das Teilprojekt der Stilllegung des Altsystems als Bestandteil des Implementierungsprojektes zu sehen. Es muss hier eingebettet werden, da die Möglichkeiten eines stillgelegten Systems eingeschränkt sind und somit auch Anforderungen an das Neusystem und deren Datenmigration zurückgespiegelt werden. Deshalb folgt ein kurzer, sehr vereinfachter Einblick in die Grundstruktur eines ERP-Projektes:

Die Terminologie in den Implementierungsmethoden der verschiedenen ERP-Anbieter unterscheidet sich zwar, aber bei den meisten hat sich eine 6-Phasen-Struktur etabliert.  

1. Initialisierung des Projektes: Zunächst werden die administrativen Grundlagen geschaffen. 

2. Erkundungsphase: Es erfolgt die Annäherung des Unternehmens an die neue Software auf der einen Seite und die Annäherung der Beratenden an die Abläufe des Unternehmens, die zu einem ersten rudimentären Prototyp führt. 

3. Ausarbeitungsphase:  Der Prototyp wird vervollständigt, alle Prozesse des Unternehmens werden abgebildet und getestet. 

4. Erstellungsphase: Auf Basis der gewonnenen und ausgetesteten Erkenntnisse wird nun das neue System erstellt.

5. Übergangsphase: Das neue System wird mit Daten versehen und „Live“ geschaltet.

6. Nutzungsphase: Das System wird final optimiert.

Die ERP-Implementierung lässt sich in verschiedene Themenbereiche gliedern wie z. B. die Abbildung der Geschäftsprozesse, das Systemdesign, die Realisierung von Anpassungen, die Datenübernahme etc. Diese Bereiche beinhalten jene Tätigkeiten und Arbeitsergebnisse, die immer durchgeführt bzw. erbracht werden und solche, die nur unter bestimmten Randbedingungen durchgeführt werden sollten. Für all diese Themen empfiehlt es sich, als erstes jeweils passende Strategien zu erarbeiten, in denen die Arbeitspakete definiert werden.

Mit diesen Strategien sollten insbesondere folgende Fragen für jeden Themenbereich beantwortet werden:

  • Was wollen wir erreichen? 
  • Wie wollen wir es tun?
  • Wie ist unsere Vorgehensweise, welche Arbeitspakete werden benötigt? 
  • Welche Standards wollen wir nutzen?
  • Welche Tools wollen wir nutzen? 

Der Themenbereich Datenübernahme ist hierfür ein gutes Beispiel, da einer gründlichen Erarbeitung der Übernahmestrategie eine entscheidende Bedeutung zufällt. Wird dies vernachlässigt, kann es zu erheblichen Planungsabweichungen kommen. Auf Basis der definierten, zukünftigen Prozessabläufe werden die Datenobjekte festgelegt, die in das neue System übernommen werden sollen. Mit der Analyse der Qualität und Menge der Altdaten kann festgelegt werden, welche Daten migriert werden sollen und welche nicht. Auch wird festgelegt, wie eine notwendige Datenbereinigung durchgeführt wird.

Es wird die Form der Übernahme definiert, also im Wesentlichen, ob per Programm oder manuell migriert werden soll. Die dabei festgelegte Strategie hat einen direkten Einfluss auf die Anforderung an die Stilllegung der Altsysteme.

Der Themenbereich Datenübernahme ist hierfür ein gutes Beispiel, da einer gründlichen Erarbeitung der Übernahmestrategie eine entscheidende Bedeutung zufällt. Wird dies vernachlässigt, kann es zu erheblichen Planungsabweichungen kommen. Auf Basis der definierten, zukünftigen Prozessabläufe werden die Datenobjekte festgelegt, die in das neue System übernommen werden sollen. Mit der Analyse der Qualität und Menge der Altdaten kann festgelegt werden, welche Daten migriert werden sollen und welche nicht. Auch wird festgelegt, wie eine notwendige Datenbereinigung durchgeführt wird. Es wird die Form der Übernahme definiert, also im Wesentlichen, ob per Programm oder manuell migriert werden soll. Die dabei festgelegte Strategie hat einen direkten Einfluss auf die Anforderung an die Stilllegung der Altsysteme.

Der Themenbereich Stilllegung der Altsysteme beginnt im Gegensatz zu den anderen Themenbereichen nicht mit der Festlegung einer Strategie, sondern mit der Analyse der Anforderungen und der Ist-Situation. Erst wenn klar ist, was erreicht werden muss und welche Ausgangslage herrscht, können eine Strategie bzw. ein Konzept entworfen und entsprechende Maßnahmen geplant werden. Klassische Maßnahmen sind die Auslagerung der nicht in das neue ERP-System geladenen Daten in eine Archiv-DB, Erstellung von neuen Schnittstellen zu den External-Schnittstellen etc. 

Wie schon beschrieben sind die Themenbereiche in Arbeitspakete zu strukturieren. Es empfiehlt sich, eine einheitliche Nomenklatur zu etablieren, wie beispielsweise die nachfolgend gewählte Art : . DAV.010.

Folgende Arbeitspakete sind für eine strukturierte Stilllegung von Altsystemen im Rahmen einer ERP-Implementierung empfehlenswert:

DAV.010 Aufnahme der Anforderungen

Die Anforderungen an eine Systemstilllegung haben zwei Quellen: Die gesetzlichen Anforderungen und die unternehmerischen, funktionalen.

  • Der Gesetzgeber hat in den letzten Jahren die Anforderungen an die Datenaufbewahrungsfristen, den Zugang der Behörden zu diesen Daten und den Datenschutz erheblich erweitert. Darüber hinaus unterliegen die Gesetze und Verordnungen einer kontinuierlichen Veränderung und es empfiehlt sich, den Wirtschaftsprüfer einzubinden.
  • Nicht erst seit der Datensammelwut von Facebook, Google etc. ist klargeworden, dass historische Daten wertvoll sind. So werden Altdaten benötigt, um z. B. Marktprognosen durchzuführen oder sie werden für das tägliche Arbeiten im Service/Wartungsgeschäft gebraucht.

Die unternehmerischen Anforderungen müssen im Rahmen der Erkundungsphase ausgearbeitet werden. Das Ergebnis sollte ein vom Steeringboard abzunehmendes Dokument sein.

DAV.020 Deltaanalyse 

Als nächsten Schritt wird in der Ausarbeitungsphase analysiert, welche der Anforderungen nicht vom neuen System abgedeckt werden können. Dies wird sich in erster Linie auf die historischen Daten und Transaktionsdaten beziehen, denn diese sind in der Regel sehr schwer zu migrieren. Welche Daten übernommen werden können, wird in der Datenübernahmestrategie festgelegt.

Aber auch die Integration des Altsystems in die existierende IT-Landschaft ist zu berücksichtigen. Im Rahmen des Themenbereichs Systemdesign wird in der Regel immer eine Ist-Aufnahme der bestehenden IT-Landschaft durchgeführt. Hier sollten auch die bestehenden Schnittstellen gründlich inventarisiert werden. Die Erfahrung zeigt, dass insbesondere bei Systemen, die schon viele Jahre in Betrieb sind, nicht alle Schnittstellen präsent sind, insbesondere die passiven Datenbereitstellungsschnittstellen. 

Als Beispiel sei hier der Zugriff der Zeiterfassung auf ein im Altsystem vorhandenes Schichtmodell genannt, das im neuen System nicht bzw. ganz anders abgebildet wird. Das Ergebnis dieser Aktivität ist ein von der Projektleitung abzunehmendes Dokument.

DAV.030 Erarbeitung des Stilllegungskonzeptes

Lassen sich die technischen Schnittstellen in der Regel vom neuen ERP-System durch Anpassungen noch vollständig abbilden, so gelingt das bei den historischen Daten selten. Um diese Anforderungen zu erfüllen, gibt es mehrere Optionen:

Weiterführung des Altsystems im Read-Only-Modus

Dies ist sicherlich für das ERP-Implementierungsprojekt die einfachste Lösungsoption, doch sprechen ggf. die Betriebskosten und das fehlende bzw. reduzierte Betriebsführungs-Know-how dagegen. Zu berücksichtigen ist zudem, dass zum Altsystem auch Peripheriegeräte wie Bildschirme und Drucker gehören. Diese müssen hinsichtlich ihrer Kosten und Verfügbarkeit betrachtet werden. 

Übernahme der Daten in ein Standard-Archiv-System 

Es gibt am Markt Standardlösungen zum Archivieren von ERP-Daten. Diese haben Load-Programme für die am Markt gängigen ERP-Systeme und darüber hinaus Werkzeuge, um Load-Programme für andere ERP-Systeme herzustellen. Der Vorteil solcher Systeme ist die Abdeckung von gesetzlichen Anforderungen. Der Nachteil ist, dass sich das Datenmodell dieser Systeme in der Regel auf die Finanzdaten beschränkt und z. B. die Daten für das Support- und Servicegeschäft im Modell nur eingeschränkt abgedeckt werden, da sie häufig branchenspezifisch ausgeprägt sind. 

Migration der Altdaten-DB auf eine neue Plattform 

Um sich von den ggf. vorhandenen Betriebsführungsthemen eines Altsystems zu lösen, kann es sinnvoll sein, die Altdatenbank mit am Markt verfügbaren Konvertierungsprogrammen in eine Datenbank der neuesten Generation 1:1 zu konvertieren. Eine solche Lösung hat den Vorteil, dass man sich mit wenig Aufwand von den „alten Zöpfen“ löst und die Daten auch in Zukunft im Zugriff hat. Es ist dabei zu berücksichtigen, dass auch in Zukunft neue Berichte und Zugriffe für die Altdaten realisiert werden müssen. Das dafür notwendige Datenmodell-Know-how muss langfristig verfügbar sein, um die Aussagekraft der Berichte gewährleisten zu können.

Migration in ein individuelles Archivsystem

Diese Lösungsvariante hat nicht nur den Vorteil, dass sie sich vollständig von den Lasten des Altsystems befreit und auf neueste Technologien setzen kann, sondern sie reduziert auch die Betrachtung auf die zu archivierenden Daten. Es werden also nur die notwendigen Datenobjekte archiviert. Doch bedarf dies 

  • der gründlichen Analyse des bestehenden DB-Modells,
  • eines durchdachten Designs des Archivs,
  • der Erstellung des Archivs und
  • der Erstellung, eines Tests sowie der Installation von Load-, Zugriffs- und Berichtsprogrammen.

Diese Tätigkeiten stellen ein eigenständiges Entwicklungsprojekt dar, das geplant, budgetiert und parallel zur Implementierung des ERP-Systems umgesetzt werden muss. 

Das während der Ausarbeitungsphase zu erstellende Konzept kann auch eine Mischung aus verschiedenen Optionen sein, zum Beispiel Finanzdaten in ein Standard-Archiv, Auftrags- und Artikeldaten in ein individuelles Archiv laden und klärt des Weiteren das Betriebskonzept der Altsysteme (Abbau, Stand-by, Weiterbetrieb etc.). 

Das Ergebnis dieser Aktivität sollte ein vom Steeringboard abzunehmendes Dokument sein.

DAV.040 Bereitstellung des notwendigen Archivsystems

Ist die Option Weiterführung des Altsystems im Read-Only-Modus nicht möglich, nicht gewünscht oder nicht ausreichend, so müssen entsprechend dem erstellten Konzept das neue Archivsystem und die für das Tagesgeschäft notwendigen Berichte in der Erstellungsphase bereitgestellt werden. Dies kann bzw. sollte wie schon erwähnt in einem Parallelprojekt durchgeführt werden. Das Ergebnis dieser Aktivität ist das bereitgestellte System.

DAV.050 Archivieren der Altdaten

Ist das Archivsystem verfügbar, so können in der Übergangs- oder Nutzungsphase, nachdem die Transaktionen im Altsystem gesperrt wurden, die Daten in das Archivsystem geladen werden. Die Altsysteme können abgeschaltet werden. Das Ergebnis dieser Aktivität ist ein für das Unternehmen nutzbares Archivsystem und eine von Altsystemen bereinigte IT-Landschaft.

Fazit 

Altsysteme sind in der Konzeption einer neuen IT-Landschaft, die im Rahmen einer ERP-Implementierung entsteht, mit zu berücksichtigen. Altsysteme beinhalten Funktionen und Daten. Deren Stilllegungen gehören in der Regel zu einem ERP-Implementierungsprojekt. Diese Aktivität wird selten vom ERP-Implementierungslieferanten angeboten, verbleibt also in der Verantwortung der eigenen IT. Um die Stilllegung erfolgreich durchzuführen, ist eine strukturierte Vorgehensweise nötig.

Weiterführende Literatur

Espeter F. ERP-Systeme erfolgreich implementieren: Das Praxishandbuch für agiles Prozessmanagement (mitp Business). 2022.

Friedrich Wilhelm (genannt Friedhelm) Espeter, Projektmanager (PMP/PMI) und Scrum Master (PSM I), arbeitet seit mehr als 30 Jahren als Projektmanager im Bereich der Implementierung von Standardsoftware. Er war Manager bei namhaften amerikanischen und europäischen Softwarehäusern und arbeitet heute als Berater von Project Management Service speziell im ERP-Umfeld.

Friedhelm Espeter
Am Bruche 41, 31515 Wunstdorf
E-Mail: friedhelm.espeter@espeter.com
https://espeter.com/