Release-Wechsel (Umstieg auf eine neue ERP-Version)
Kurz gesagt
Ein Release-Wechsel ist der geplante Übergang eines ERP-Systems auf einen neuen Release-Stand, nicht das Einspielen einer Korrektur. Er folgt der Reihe Testsystem, Regressionstest, Änderungsstopp, Umschaltung und Rückfallplan; die einschlägigen Standards (ITIL 4, ISO/IEC 20000-1, BSI IT-Grundschutz) binden in Deutschland, Österreich und der Schweiz nur über Gesetz oder Vertrag. Der Aufwand wächst nach dem redaktionellen Modell dieses Artikels mit dem Grad der Anpassung.
Das Wichtigste
- Release-Wechsel heißt Übergang innerhalb desselben ERP-Produkts auf einen neuen Release-Stand.
- Schrittfolge: Testsystem, Regressionstest, Freigabe, Freeze, Umschaltung, Nachtest, Rückfallplan.
- Der BSI IT-Grundschutz verlangt von Anwendern eine Rückfall-Lösung und eine dokumentierte Freigabe; er bindet nur über Gesetz oder Vertrag.
- ISO/IEC 20000-1:2018 und ITIL 4 Change Enablement sind Standard und Leitfaden, kein Gesetz.
- Je Modifikation im Herstellercode rechnet das Modell 6 Arbeitstage je Release, je Erweiterung 2.
- Ein Test kann einen Fehler im Produktivbetrieb nicht ausschließen; deshalb gehört ein Rückfallplan dazu.
Release-Wechsel ist der geplante Übergang eines ERP-Systems auf einen neuen Release-Stand innerhalb desselben Produkts: Der neue Stand läuft zuerst im Testsystem, ein Regressionstest prüft die alten Abläufe, ein Änderungsstopp friert die Produktion ein, danach folgt die Umschaltung mit bereitliegendem Rückfallplan.
Wozu er dient
Änderungen am ERP kommen in Ständen: Sicherheitskorrekturen und Fehlerbehebungen innerhalb eines Release-Stands, kleinere Releases und Versionswechsel mit geändertem Datenmodell oder geänderten Schnittstellen. Ein Release-Wechsel bündelt einen solchen Stand und trifft dabei Einstellungen, Vorlagen, Schnittstellen und Anpassungen; das unterscheidet ihn vom Einspielen einer einzelnen Korrektur. Wie tief Sie testen, richtet sich nach der Änderung und ihrem Risiko; der IT-Grundschutz verlangt in OPS.1.1.6.A1 Testfälle, die möglichst repräsentativ alle Funktionen abdecken. Testfälle und Abnahme im Einzelnen beschreibt die Anleitung Update im Testsystem prüfen.
Die Schrittfolge
- Testsystem aufsetzen: derselbe Release-Stand, dieselben Einstellungen, Anpassungen und Vorlagen wie in der Produktion, betrieben in einer eigenen, von der Produktivumgebung getrennten Testumgebung (OPS.1.1.6.A13) und repräsentativ für die eingesetzten Geräte und Betriebssystemumgebungen (A1); personenbezogene Testdaten mindestens pseudonymisiert (A11).
- Neuen Stand im Testsystem einspielen.
- Regressionstest fahren: Kernabläufe und die eigenen Anpassungen gegen vorher festgeschriebene Erwartungen, ohne den Produktivbetrieb zu beeinflussen, mit Soll-Ist-Vergleich und dokumentierter Auswertung (OPS.1.1.6.A2, A3 und A12).
- Freigeben: Die fachlich zuständige Stelle gibt die Software nach erfolgreichem Test frei und dokumentiert die Freigabe in einer Freigabeerklärung (OPS.1.1.6.A4).
- Freeze setzen: Ab dem Änderungsstopp keine inhaltlichen Änderungen mehr an Stammdaten, Vorlagen und Anpassungen, damit Test und Produktion vergleichbar bleiben.
- Umschalten (Switch): den neuen Stand zum festgelegten Termin produktiv einspielen.
- Nachtesten: mit geeigneten Referenzsystemen prüfen, ob die Änderung erfolgreich war, und das Ergebnis dokumentieren (OPS.1.1.3.A13, eine Anforderung bei erhöhtem Schutzbedarf).
- Rückfallplan bereithalten: die Bedingungen, unter denen abgebrochen wird, und der Weg zurück auf den alten Stand samt Datenstand. Der IT-Grundschutz verlangt von Anwenderorganisationen eine Rückfall-Lösung (OPS.1.1.3.A1) und hält fest, dass ein umfangreiches Testverfahren einen Fehler im Produktivbetrieb nicht ausschließen kann (OPS.1.1.3, Abschnitt 2.3).
Was der Wechsel kostet
Im redaktionellen Modell dieses Artikels wächst der Aufwand mit dem Grad der Anpassung (Customizing) und mit der Zahl der anzupassenden Schnittstellen. Die folgende Rechnung ist ein solches Modell mit erfundenen Beispielwerten für ein Handels-ERP; sie ist keine Messung. Einen Benutzerfaktor enthält das Modell nicht.
| Position | Beispielwert (Arbeitstage je Release) |
|---|---|
| Grundaufwand: Testsystem, Kernabläufe, Nachtest | 2 |
| je Erweiterung (eigener Programmteil über die Schnittstelle) | 2 |
| je Modifikation (Eingriff in den Programmcode des Herstellers) | 6 |
| je anzupassender Schnittstelle (etwa EDI, Bank, Shop) | 1 |
Beispielrechnung: Ein Betrieb mit zwei Erweiterungen, einer Modifikation und zwei anzupassenden Schnittstellen kommt auf 2 + 2 × 2 + 6 + 2 × 1 = 14 Arbeitstage je Release. Bei vier Releases im Jahr sind das 56 Arbeitstage. Im Modell steht die Modifikation damit bei 6 Arbeitstagen je Release, eine reine Einstellung ohne eigenen Prüfaufwand bei 0.
Standards als Grundlage
Den Rahmen setzen hier Standards und Leitfäden. Der BSI IT-Grundschutz (Edition 2023, veröffentlicht im Februar 2023) verlangt von Anwenderorganisationen in OPS.1.1.3, Änderungen geeignet zu planen, zu genehmigen und zu dokumentieren; der Baustein OPS.1.1.6 regelt Test und Freigabe. ISO/IEC 20000-1:2018 (Edition 3.0, veröffentlicht am 14. September 2018, mit Amendment 1:2024 vom 23. Februar 2024) verlangt ein Service-Management-System, dessen Anforderungen auch den Übergang von Services umfassen. ITIL 4 beschreibt Change Enablement als Praxis, Änderungsrisiken zu bewerten, Änderungen zu autorisieren und Änderungspläne zu steuern. Alle drei binden nur, soweit ein Gesetz, ein Vertrag oder eine Regelung sie in Bezug nimmt. Wann welcher Stand ansteht, legt die Update-Strategie fest (Update-Strategie für das ERP).
Nicht zu verwechseln
- Patch oder Sicherheitsupdate: Korrektur innerhalb eines Release-Stands, kein Wechsel des Standes.
- Datenmigration: Übertrag der Altdaten in ein anderes System (Datenmigration).
- Go-live: Einführung eines neuen Systems; der Release-Wechsel bleibt beim selben Produkt.