Anpassungen updatefähig halten: Dokumentation und Regeln

Eine Anpassung ist jede Einstellung, jedes Druckformular, jede Auswertung und jede Erweiterung, die nicht zum Herstellerstand gehört. Ob Ihr Wartungsvertrag sie erfasst, hängt von seinem Umfang ab — klären Sie das je Anpassung mit Ihrem Hersteller. Sie muss auch nach dem nächsten Update weiter tragen. Ob sie das tut, entscheidet sich daran, ob Sie sie kennen, einer Person zuordnen und wiederholt testen können. Dieses Vorgehen baut dafür ein Anpassungsregister auf und hält es über die Updates hinweg aktuell.

Grundlage der Regeln ist der BSI IT-Grundschutz, Edition 2023 (Stand Februar 2023). Er ist eine Methode des Bundesamts für Sicherheit in der Informationstechnik und bindet nicht durch Gesetz; verpflichtend wird er nur, wo ein Vertrag, eine Weisung oder eine Regelung ihn festschreibt. Seine Bausteine OPS.1.1.3 Patch- und Änderungsmanagement und OPS.1.1.6 Software-Tests und Freigaben sind als technische Richtschnur auch für Betriebe in Österreich und der Schweiz lesbar.

Was Sie vorab brauchen

• eine Liste aller Änderungen am System seit dem Go-live: Anpassungsanforderungen, Einstellungen, Druckformulare, Auswertungen, Schnittstellen, Erweiterungen
• je Anpassung eine fachlich verantwortliche Person aus dem Fachbereich, nicht nur eine Person aus der IT
• einen Testzugang, der keine echten Buchungen und keine Nachrichten an Schnittstellen auslöst; BSI OPS.1.1.6.A2 verlangt, dass funktionale Software-Tests den Produktivbetrieb nicht beeinflussen
• einen festen Ablageort, an dem Register und Testergebnisse für die nächste Version auffindbar sind
• die Release- und Änderungsinformationen Ihres Herstellers, damit Sie wissen, welche Bausteine ein Update berührt
• eine Person, die die Freigabe erteilt und sie dokumentiert

Schritt für Schritt: Anpassungen erfassen und pflegen

Schritt 1: Anpassung erfassen

Geben Sie jeder Anpassung eine Kennung und beschreiben Sie in einem Satz ihren Zweck. BSI OPS.1.1.3.A5 empfiehlt, Änderungsanforderungen (Request for Changes) zu erfassen und zu dokumentieren. Erfasst wird die Programmierung ebenso wie eine Einstellung, die ein Update auf den Auslieferungsstand zurücksetzt. Ende: Die Anpassung steht mit Kennung und Zweck im Register.

Schritt 2: Verantwortliche Person festlegen

Tragen Sie die fachlich zuständige Person ein. BSI OPS.1.1.3.A2 verlangt, für alle Organisationsbereiche Zuständige für das Patch- und Änderungsmanagement festzulegen. Diese Person kann den Zweck beurteilen und später entscheiden, ob die Anpassung noch gebraucht wird. Ende: In jeder Zeile steht ein Name, nicht eine Abteilung.

Schritt 3: Testfall formulieren

Beschreiben Sie in einem Testfall, welche Eingabe welches Ergebnis erzeugen muss. BSI OPS.1.1.6.A1 verlangt, Testfälle so auszuwählen, dass sie möglichst repräsentativ alle Funktionen überprüfen; Negativ-Tests, die ungewollte Funktionen aufdecken, sollten Sie zusätzlich berücksichtigen (dieselbe Anforderung). Der Testfall muss wiederholbar sein, weil Sie ihn bei jedem Update erneut ausführen; wie Sie Fälle aus Ihren Abläufen ableiten, zeigt der Artikel zu Testfällen aus Geschäftsprozessen. Ende: Eine zweite Person kann den Testfall ohne weitere Erklärung ausführen.

Schritt 4: Update-Prüfung eintragen

Notieren Sie je Anpassung, woran Sie nach einem Update erkennen, dass sie noch trägt: welcher Menüpunkt, welcher Bericht, welche Schnittstelle. BSI OPS.1.1.3.A1 verlangt eine Rückfall-Lösung für jede durchgeführte Änderung und empfiehlt, Änderungen vorab geeignet zu testen (siehe OPS.1.1.6 Software-Tests und Freigaben). Die Update-Prüfung ist die Vorbereitung darauf, weil Sie so wissen, wo Sie nach dem Einspielen zuerst nachsehen. Ende: Die Spalte nennt mindestens einen sichtbaren Anhaltspunkt.

Schritt 5: Register nachführen

BSI OPS.1.1.3.A11 empfiehlt, Änderungen in allen Phasen zu dokumentieren. Führen Sie das Register deshalb bei jeder Anpassung nach und nicht erst vor dem Jahresabschluss. Wird eine Anpassung stillgelegt, bleibt die Zeile mit dem Datum der Stilllegung erhalten. Ende: Register und System stimmen überein.

Das Anpassungsregister

Das Register ist eine Tabelle; eine Tabellenkalkulation oder ein eigenes Feld in Ihrem System genügt. Entscheidend sind vier Angaben je Zeile, weil Sie genau sie beim nächsten Update brauchen: der Zweck, die verantwortliche Person, der Testfall und die Update-Prüfung.

Kennung	Anpassung und Zweck	Verantwortlich	Testfall	Update-Prüfung	Stand
A-014	Druckformular für die Sammelrechnung	Buchhaltung	Sammelrechnung über drei Aufträge erzeugen und drucken	Menüpunkt „Sammelrechnung” öffnet ohne Fehlermeldung	2026-05-02
K-007	Rollenrecht „Bestellung freigeben”	Einkauf	Bestellung als Sachbearbeitung anlegen, dann freigeben	Freigabe erscheint nur mit der Rolle „Einkaufsleitung”	2026-07-19
S-003	Schnittstelle zum Online-Shop für Bestandsabgleich	Vertrieb	Bestand in einem Testartikel ändern und den Abgleich auslösen	Testartikel zeigt im Shop den geänderten Bestand	2026-08-11

Die Beispiele sind erfundene Einträge (Beispiel, kein Datenbestand). Tragen Sie eine Anpassung erst dann als erledigt ein, wenn der Testfall mindestens einmal bestanden ist.

Regeln für Ihr Anpassungsregister

Die folgenden Regeln sind eine redaktionelle Empfehlung; wo eine BSI-Anforderung dahintersteht, ist sie genannt.

1. Keine Anpassung ohne Eintrag: erst eintragen, dann produktiv schalten.
2. Genau eine verantwortliche Person je Anpassung (BSI OPS.1.1.3.A2: Zuständige MÜSSEN festgelegt werden).
3. Ohne wiederholbaren Testfall keine Freigabe; die Freigabe wird dokumentiert (BSI OPS.1.1.6.A4: Freigabeerklärung).
4. Notieren Sie, an welcher Stufe die Anpassung ansetzt — Einstellung, Formular, Auswertung, Schnittstelle oder Erweiterung —, weil davon abhängt, ob ein Update sie berührt. Welche Stufen es gibt und wie sie sich unterscheiden, beschreibt der Artikel Stufen der ERP-Anpassung.
5. Legen Sie zu jeder Änderung vorher fest, wie Sie sie zurücknehmen (BSI OPS.1.1.3.A1: Rückfall-Lösungen MÜSSEN vorhanden sein).
6. Prüfen Sie vor jedem Update die Regressionsliste und testen Sie nach dem Einspielen nach (BSI OPS.1.1.6.A12 empfiehlt Regressionstests nach Änderungen, BSI OPS.1.1.3.A13 Nachtests mit dokumentiertem Ergebnis).

Die Regressionsliste vor dem Update

Ein Regressionstest prüft die Wirkung einer Änderung auf andere Funktionen. BSI OPS.1.1.6.A12 empfiehlt Regressionstests nach jeder Software-Änderung und nennt dabei ausdrücklich die Sicherheitsmechanismen und -einstellungen; die Einleitung des Bausteins begründet das damit, dass sich selbst eine kleine Änderung auf ganz andere Funktionen auswirken kann. Für ein Update heißt das: Neben der geänderten Stelle des Herstellers prüfen Sie Ihre eigenen Anpassungen mit. Eine Zeile je Prüfung, mit Beleg und Ergebnis:

Prüfung	Beleg	Bestanden, wenn
jede Anpassung aus dem Register	Kennung und Testfall	der beschriebene Ablauf liefert dasselbe Ergebnis wie vorher
Schnittstellen (Shop, Bank, Kasse, Buchhaltung)	eine Testbuchung je Schnittstelle	Daten kommen an und zurück, ohne Fehlermeldung
Druckformulare und Auswertungen	Druck oder Export	die Ausgabe öffnet sich und enthält die erwarteten Werte
Rollen und Berechtigungen	Anmeldung je Rolle	jede Rolle erreicht ihre Startmaske, die Rechte stimmen
Nachtests nach dem Einspielen	Wiederholung der Zeilen darüber	jede Prüfung ist mit Ist-Wert und Datum dokumentiert

So prüfen Sie das Ergebnis

Das Register ist vollständig, wenn jede Anpassung eine Kennung, einen Zweck, eine verantwortliche Person, einen Testfall und eine Update-Prüfung trägt. Die Regressionsliste ist abgeschlossen, wenn jede Zeile ein Ergebnis mit Datum hat und offene Punkte eine Frist und eine zuständige Person nennen. Prüfen Sie außerdem, ob eine Anpassung nur noch in der Liste steht, aber im System fehlt, oder umgekehrt — beide Fälle sind vor dem nächsten Update zu klären.

Wenn etwas nicht klappt

Symptom	Mögliche Ursache	Umgang
Anpassung fehlt nach dem Update	das Update hat die Änderung auf den Herstellerstand zurückgesetzt	Eintrag und Rückfall-Lösung nutzen, Anpassung neu einspielen und den Testfall wiederholen
Ein anderer Ablauf bricht nach dem Update	Regressionseffekt außerhalb der eigenen Anpassung	den betroffenen Ablauf als Testfall ergänzen; BSI OPS.1.1.6 nennt genau diese Wirkung
Niemand kennt den Zweck einer Anpassung	Zweck und verantwortliche Person fehlen im Register	Zweck mit dem Fachbereich klären oder die Anpassung stilllegen und die Zeile nachführen
Update lässt sich nicht einspielen	eine Anpassung steht dem Herstellerstand im Weg	Anpassung mit dem Hersteller klären, Rückfall-Lösung bereithalten, Update erneut versuchen

Wann Sie Hilfe holen sollten

Holen Sie Ihren Anbieter oder Hersteller hinzu, wenn eine Anpassung im Kern geändert wurde oder vom Herstellerstandard abweicht; wie Sie eine solche Erweiterung beauftragen und abnehmen, steht im Artikel zur individuellen Erweiterung. Fällt das Update in ein Umstellungs- oder Wiederherstellungsszenario, gehört der Restore-Test dazu. Ein geführtes Register ist Teil der Betriebsdokumentation; wo sie abgelegt wird, beschreibt das Betriebshandbuch fürs ERP.