SAP S/4HANA validieren: GxP-Anforderungen, Migration und Testnachweise

Public Cloud, Private Cloud oder On-Premise: Warum die Edition zählt

Die Bezeichnung S/4HANA reicht für einen Validierungsplan nicht aus. SAP unterscheidet Betriebsmodelle mit unterschiedlichen Möglichkeiten für Konfiguration, Erweiterungen und Änderungen. Ein Plan sollte deshalb die genaue Edition, den Release-Stand und die relevanten Komponenten nennen. Eine zusätzliche Integrationsplattform oder ein externes Lager gehört zur Landschaft, wenn darüber relevante Daten verarbeitet werden.

Die regulatorische Fragestellung bleibt die Eignung für den vorgesehenen Einsatz. Die Arbeitsteilung ändert sich jedoch: Wer betreibt welche Komponente, wer darf Änderungen einspielen und welche Nachweise sind verfügbar? „Cloud“ bedeutet weder, dass alle Aufgaben beim Anbieter liegen, noch dass jede Cloud-Edition denselben Release-Ablauf verwendet.

Quellen: [3] [10] [1]

Neueinführung und Systemkonvertierung getrennt planen

Bei einer Neueinführung werden Zielprozesse und ihre Einrichtung neu aufgebaut. Für die Validierung stehen dann die Anforderungen, die Konfiguration und die Übernahme benötigter Daten im Vordergrund. Vorhandene Nachweise aus einem Altsystem können fachliche Informationen liefern; ihre Übertragbarkeit auf den neuen Ablauf muss bewertet werden.

Bei einer Systemkonvertierung wird ein bestehender Systemstand in die neue technische und funktionale Umgebung überführt. Hier ist die Auswirkungsanalyse besonders wichtig: Welche Abläufe, Datenmodelle, Erweiterungen und angebundenen Anwendungen ändern sich? Der Begriff Brownfield bedeutet nicht, dass das frühere Validierungsergebnis unverändert weitergilt. Die dokumentierte Änderung bestimmt die ergänzenden Arbeiten.

SAP beschreibt unterschiedliche Einführungswege und ihre Rahmenbedingungen. Daraus lässt sich kein pauschaler Wechselpfad für jedes Ausgangssystem ableiten. Legen Sie den technisch vorgesehenen Pfad mit dem Implementierungspartner fest und führen Sie dazu eine Liste relevanter Änderungen. Diese Liste verbindet Projektplanung und Validierung und wird bei späteren Umfangsänderungen fortgeschrieben.

Quellen: [4] [1]

Anforderungen aus Prozessen statt aus einer Transaktionsliste ableiten

Eine Liste eingesetzter Anwendungen oder Transaktionen beschreibt die Bedienoberfläche, aber noch nicht das fachliche Ziel. Eine brauchbare Anforderung erklärt die notwendige Wirkung. Beispiel: Eine nicht freigegebene Materialcharge darf in einem definierten Herstellungsprozess nicht verwendet werden. Welche Funktionen diese Wirkung gemeinsam herstellen, wird anschließend im Lösungsdesign beschrieben.

Für den GMP-Einsatz verlangt Annex 11 eine nachvollziehbare, risikobasierte Begründung des Nachweisumfangs. Als praktische Umsetzung empfiehlt sich die Verbindung von Anforderung, Fehlermöglichkeit, Kontrolle und Nachweis. Ein unbeabsichtigter Statuswechsel oder eine falsche Mengenumrechnung kann eine andere Bedeutung haben als eine fehlerhafte kaufmännische Anzeige.

Berücksichtigen Sie übergreifende Abhängigkeiten: gemeinsam genutzte Stammdaten, Organisationseinheiten, Berechtigungen, Druckausgaben und Schnittstellen. Der fachliche Umfang lässt sich häufig nicht sauber an einer Modulgrenze abschneiden. Die Testauswahl sollte erklären, welche Risiken abgedeckt sind, welche vorhandenen Belege genutzt werden und wo ergänzende Prüfungen nötig bleiben.

Quellen: [1]

Datenmigration nach S/4HANA: Werte, Bedeutung und Altdatenzugriff

Eine Migration ist fachlich erst bewertet, wenn die benötigten Daten im Ziel richtig interpretiert und verwendet werden können. Annex 11 nennt bei einer Datenübertragung den Erhalt von Wert und Bedeutung. Ein Vergleich der Datensatzanzahl allein zeigt deshalb nicht, ob Einheiten, Statuszuordnungen oder Beziehungen zwischen Objekten erhalten geblieben sind.

SAP beschreibt das Migration Cockpit der Public Edition als Werkzeug zur Übernahme des für den Betriebsstart benötigten Datenbestands. Dazu gehören je nach Objekt Stammdaten, offene Vorgänge und Salden; bestimmte historische Kontosalden sind ausdrücklich eingeschlossen. Eine vollständige Historie abgeschlossener Transaktionen wird dadurch nicht pauschal übernommen. Möglichkeiten und Grenzen müssen zur gewählten Edition und zum Migrationspfad passen.

Für qualitätsrelevante Daten empfiehlt sich eine Zuordnung zwischen Quelle, Transformationsregel, Ziel und Prüfmethode. Auffällige oder ausgeschlossene Datensätze werden nachvollziehbar bearbeitet. Parallel wird festgelegt, wie auf aufbewahrungspflichtige Altdaten zugegriffen wird. Ein erfolgreicher Go-live ist für sich genommen keine Begründung, die einzige nutzbare Quelle historischer Nachweise abzuschalten.

Quellen: [5] [6] [1]

Schnittstellen und Erweiterungen im Gesamtprozess bewerten

S/4HANA kann Teil einer Landschaft aus Lagerverwaltung, Produktionssystem, Labor, Qualitätsmanagement und externen Dienstleistern sein. Für die Validierung zählt der relevante Datenfluss durch diese Landschaft. Die Verfügbarkeit einzelner Integrationswege ist editions- und versionsabhängig; für die Public Edition dokumentiert SAP Schnittstellen zu ausgewählten Prozessumfängen und ihre Nutzungsbedingungen.

Eine zweckmäßige Schnittstellenbeschreibung benennt Sender, Empfänger, auslösenden Vorgang, Dateninhalt, Zuordnung und Fehlerbehandlung. Testfälle prüfen zusätzlich zur korrekten Übertragung auch abgewiesene, fehlende oder wiederholt eingehende Nachrichten. Das Zielsystem muss erkennen lassen, welches Ergebnis zur Ausgangsnachricht gehört.

Bei Erweiterungen sind Verantwortung und Änderungsweg besonders wichtig. Wer beschreibt und prüft eigene Logik? Welche Standardfunktionen werden beeinflusst? Welche Belege existieren für die verwendete Version? Ein isoliert erfolgreicher Test einer Erweiterung beantwortet noch nicht, ob der gesamte qualitätsrelevante Prozess mit ihr korrekt abläuft.

Quellen: [7] [1]

Berechtigungen und Nachvollziehbarkeit an kritischen Aktionen prüfen

Ein Rollenname wie „Qualität“ ist kein Nachweis für passende Zugriffsrechte. Für die Prüfung werden konkrete Aufgaben und unerlaubte Aktionen benannt: Stammdaten ändern, einen Status setzen, eine relevante Einstellung anpassen oder Daten exportieren. Repräsentative Benutzer führen diese Aktionen mit ihren tatsächlichen Rollen aus.

Änderungsbelege und weitere Protokollierungsfunktionen sind am benötigten Objekt zu bewerten. Standardobjekte, eigene Felder und Erweiterungen können unterschiedliche Möglichkeiten besitzen. Das dokumentierte SAP-Beispiel für RAP-basierte Änderungsbelege zeigt zudem, dass eine konkrete Protokollierungsfunktion eine Aktivierung erfordern kann. Daraus folgt keine allgemeine Aussage zu allen S/4HANA-Objekten.

Zu einem brauchbaren Prüfergebnis gehören der erfasste Inhalt, die Zuordnung zum Benutzer und Geschäftsobjekt sowie der vorgesehene Zugriff auf die Historie. Aufbewahrung und fachliche Überprüfung werden mitgedacht. Bei Public-Edition-Upgrades sollten auch Änderungen an Business Catalogs, Einschränkungen und Rollenvorlagen in die Auswirkungsbewertung einfließen.

Quellen: [8] [9] [1]

Beispiel für einen Test über mehrere Systemgrenzen

Illustratives Beispiel: Ein Laborergebnis beeinflusst, ob eine Charge in einem festgelegten S/4HANA-Prozess verwendet werden darf. Der Test beginnt mit einem bekannten Ausgangszustand im Laborsystem und endet mit einer fachlichen Aktion in S/4HANA. Die tatsächliche Umsetzung und das erwartete Verhalten werden vorab festgelegt.

Zuerst wird ein gültiges Ergebnis übertragen. Geprüft werden die richtige Chargenzuordnung, der verarbeitete Status und die daraus folgende erlaubte Aktion. Danach folgen ein zurückgewiesenes Ergebnis, eine unterbrochene Übertragung und die erneute Verarbeitung derselben Nachricht. Ein berechtigter Benutzer bearbeitet den Fehler nach dem vorgesehenen Verfahren. Das Testprotokoll verbindet die Systemzustände über eindeutige Kennungen.

Der Ablauf deckt mehr als eine technische Verbindung ab: Datenzuordnung, Statuswirkung, Benutzerrechte und Fehlerbearbeitung werden gemeinsam sichtbar. Ein solcher Test ergänzt die benötigten Einzelprüfungen. Er ersetzt nicht automatisch weitere Nachweise, etwa für andere Chargenarten, Standorte oder abweichende Prozessvarianten.

Quellen: [1]

Nach dem Go-live: Änderungen und Releases kontrolliert weiterführen

Die aktuelle SAP-Dokumentation beschreibt für die Public Edition zwei Hauptupgrades im Jahr, im Februar und August, mit einem früheren Upgrade des Testsystems. Dieser Ablauf darf nicht unverändert auf Private Cloud, On-Premise oder jede angeschlossene Komponente übertragen werden. Für die eigene Landschaft werden die tatsächlich geltenden Termine und Verantwortlichkeiten festgehalten.

Ein praktikables Änderungsverfahren verbindet technische Änderung und fachliche Auswirkung. Der Verantwortliche ordnet betroffene Anforderungen, Prozesse, Rollen, Schnittstellen und Nachweise zu. Daraus ergibt sich die gezielte Testauswahl. Auch Änderungen an Stammdatenregeln oder einer externen Anwendung können relevant sein, obwohl das S/4HANA-Kernsystem selbst kein Upgrade erhält.

Für die Übergabe in den Betrieb empfiehlt sich ein festgelegter Kern von wiederverwendbaren Prüfungen sowie eine Übersicht offener Maßnahmen. Störungen, wichtige Änderungen und deren Ergebnisse fließen in die regelmäßige Bewertung des Systemzustands ein. So kann das Team nachvollziehen, welche Nachweise den heutigen Einsatz noch abdecken und wo neue Arbeit erforderlich ist.

Quellen: [10] [1]

Checkliste: Was vor der Entscheidung zum Produktivstart geklärt sein sollte

Eine hohe Zahl bestandener Tests allein beschreibt den Freigabestatus nicht vollständig. Die verantwortlichen Stellen brauchen eine zusammenhängende Bewertung von Umfang, Ergebnissen, Abweichungen und verbleibenden Risiken. Die folgende Arbeitshilfe unterstützt diese Entscheidung.

• Edition, Zielstand, Standorte und vorgesehene Nutzung sind eindeutig dokumentiert.
• Wichtige Anforderungen sind mit den zugehörigen Prüfungen und Ergebnissen verknüpft.
• Abweichungen und offene Punkte sind fachlich bewertet und haben Verantwortliche.
• Die Datenmigration ist abgeglichen; ausgeschlossene Daten und Altdatenzugriff sind geregelt.
• Berechtigungen und kritische Abläufe wurden mit geeigneten Benutzern geprüft.
• Betriebsaufgaben, Änderungen, Störungen und benötigte Schulungen sind vorbereitet.
• Die Entscheidung über den vorgesehenen Einsatz folgt dem Qualitätsprozess des Unternehmens.

Quellen: [1] [2]