Inhaltsverzeichnis
Das Wichtigste vorab
Wie prüfen Sie ein ByDesign-Update mit angemessenem Aufwand?
Ordnen Sie jeden relevanten Release-Hinweis Ihrem tatsächlichen Einsatz, den betroffenen Datenwegen und vorhandenen Anforderungen zu. Bewerten Sie Auswirkungen und Unsicherheiten. Daraus wählen Sie geeignete Dokumentenprüfungen und Regressionstests aus. Halten Sie Testbedingungen, Ergebnisse und Abweichungen fest und entscheiden Sie anschließend über die weitere Nutzung. Eine dokumentierte Begründung trägt den Umfang; der Update-Titel allein tut es nicht.
- SAP-Release-Hinweise sind der Ausgangspunkt; die eigene Prozessbewertung bestimmt den Nachweisumfang.
- Preview, bestätigte Änderung und tatsächlicher Systemtermin müssen auseinandergehalten werden.
- Testsystem, Erweiterungen und Schnittstellen müssen den zu prüfenden Ablauf geeignet abbilden.
- Der Abschluss verbindet Ergebnisse, offene Abweichungen und eine verantwortete Betriebsentscheidung.
1. Den Prüfauftrag pro Update klar abgrenzen
Beschreiben Sie zuerst den Gegenstand: Welches ByDesign-System, welcher bekannte Ausgangsstand und welcher Zielstand werden betrachtet? Gehören ein Partnerpaket, ein angebundenes Lager oder eine eigene Auswertung dazu? Nutzen Sie den vorhandenen System- und Prozessbestand. Eine neue ERP-Bewertung bei jedem Release würde die konkrete Änderungsfrage eher verdecken.
Der regulatorische Schwerpunkt dieses Leitfadens liegt auf GMP-Prozessen für Humanarzneimittel. Annex 11 verbindet risikobezogene Nachweise mit kontrollierten Änderungen. Daraus folgt kein festes Testpaket für jedes Cloud-Update. Entscheidend ist, ob die Änderung die vorgesehenen Aufgaben, relevanten Daten oder wirksamen Kontrollen beeinflussen kann. Andere Regelbereiche müssen Sie für Ihren Einsatz gesondert zuordnen.
Benennen Sie einen Verantwortlichen für die Bewertung und die benötigten Beiträge. Technischer Termin und fachliche Bewertung sind unterschiedliche Aufgaben.
2. SAP-Informationen sammeln und ihren Stand festhalten
Der SAP What’s New Viewer unterscheidet unter anderem Required, Recommended und Info only. Diese Angaben beschreiben den von SAP erwarteten Handlungsbedarf zur Nutzung einer Änderung. Sie sind ein hilfreiches Eingangssignal, aber keine GxP-Risikoklassifizierung Ihres Prozesses. Lesen Sie die konkrete Beschreibung samt Voraussetzungen und notwendigen Aktionen.
SAP kennzeichnet vorläufige Hinweise als Preview und weist auf mögliche Änderungen hin. Erfassen Sie deshalb Titel beziehungsweise Kennung, Quelle, Abrufdatum, betroffenen Bereich und den bewerteten Textstand. Prüfen Sie vor Abschluss, ob aus einem vorläufigen Hinweis eine geänderte endgültige Beschreibung geworden ist. Ergänzen Sie relevante Partnerhinweise und bereits bekannte eigene Störungen.
Legen Sie fest, wer die Informationen erhält und Vertretung übernimmt. Ein gefiltertes Abonnement ist praktisch; die Auswahl darf jedoch querschnittliche Änderungen an Zugriff, Ausgabe oder Kommunikation nicht unbeabsichtigt ausblenden. Die eigene Übersicht sollte erkennen lassen, welche Themen geprüft und welche begründet ausgeschlossen wurden.
3. Vom Release-Hinweis zum betroffenen Prozess gelangen
Für jeden potenziell relevanten Hinweis stellen Sie dieselben Fragen: Nutzen wir die Funktion oder eine ihrer Abhängigkeiten? Welche Anforderung, Aufzeichnung oder Kontrolle kann sich ändern? Können wir das mit vorhandenen Unterlagen zuverlässig beurteilen? Ein Funktionsname allein verrät beispielsweise nicht, ob eine nachgelagerte Chargenliste oder ein externes System denselben Datenweg nutzt.
Die folgende Matrix ist ein eigener Arbeitsvorschlag. Ihre Zeilen sind angenommene Änderungstypen, keine behaupteten Änderungen eines bestimmten SAP-Releases. Sie zeigt, wie die Begründung zu einer konkreten Auswahl führt. Bei unklaren Auswirkungen gehört die Klärung mit SAP beziehungsweise dem Partner als offener Punkt in die Bewertung.
| Angenommener Hinweis | Bezug zum eigenen Einsatz | Begründete nächste Maßnahme |
|---|---|---|
| Anzeige eines nicht verwendeten Bereichs wird angepasst | Keine genutzte Funktion und keine festgestellte Abhängigkeit | Ausschluss mit nachvollziehbarer Bestandsreferenz dokumentieren |
| Auswahlkriterium einer relevanten Auswertung verändert sich | Auswertung unterstützt die Rückverfolgung einer Charge | Sollbestand und gespeicherte Auswahl mit geändertem Ergebnis vergleichen |
| Kommunikationsverhalten eines genutzten Datenwegs ändert sich | Ein Partnerprozess benötigt die übertragenen Mengen und Bezüge | Durchgängigen Austausch samt Fehlerbehandlung prüfen |
| Zugriffsregel einer genutzten Tätigkeit ist betroffen | Die Funktion trennt Erfassung und fachliche Entscheidung | Erlaubten und unerlaubten Zugriff mit den vorgesehenen Rollen testen |
| Auswirkung auf eigene Erweiterung ist noch unklar | Partner kann den betroffenen Aufruf noch nicht einordnen | Bewertung offen halten; technische Klärung und passende Nachweise anfordern |
Quellen: [4]
4. Regression anhand der möglichen Folge auswählen
Ein Regressionstest soll zeigen, dass eine benötigte, bisher funktionierende Eigenschaft auch nach der Änderung erhalten bleibt. Wählen Sie daher nicht einfach die zuletzt ausgeführten Tests. Ordnen Sie den möglichen Fehler zunächst einer fachlichen Folge zu: falsche Menge, fehlende Chargenzuordnung, unerlaubte Aktion oder unvollständige Aufzeichnung.
Nutzen Sie vorhandene freigegebene Anforderungen und geeignete Prüffälle weiter. Ergänzen Sie dort, wo ein neuer Fehlerweg entsteht oder die ursprünglichen Nachweise den veränderten Ablauf nicht abdecken. Besonders nützlich sind ein repräsentativer Normalfall, die betroffene Grenze und ein plausibler Fehlerfall. Anzahl und Tiefe ergeben sich aus dem Risiko und der verfügbaren Evidenz.
Eine reine Dokumentenbewertung kann für eine nachvollziehbar nicht betroffene Funktion ausreichen. Sie ist weniger tragfähig, wenn die Auswirkung unbekannt bleibt oder eine relevante Kontrolle verändert wird. Halten Sie auch den Grund fest, warum kein zusätzlicher Funktionstest gewählt wurde; vermeiden Sie bloße Standardformeln wie keine Relevanz ohne Bezug zum Bestand.
Quellen: [4]
5. Das Testsystem rechtzeitig und passend vorbereiten
Die ByDesign Library beschreibt den Wartungsplan im Service Control Center für produktive und nicht produktive Systeme. Nutzen Sie die tatsächlichen Systemtermine für Ihre Planung. Eine allgemeine Veröffentlichung von Release-Informationen belegt weder den bereits installierten Stand Ihres Tests noch den Termin Ihrer Produktion.
Für Systemkopien nennt SAP wichtige Grenzen: Während des Zeitraums zwischen Test- und Produktivupgrade kann keine Kopie des Produktivsystems angefordert werden. Bei einer Kopie sind Anlagen und Änderungsbelege zudem eigene Auswahlpunkte. Eine scheinbar passende Kopie kann deshalb genau die historischen Belege nicht enthalten, die Ihr Test benötigt.
Prüfen Sie vor dem Test konkret Version, relevante Konfiguration, Rollen, Erweiterungen und Testdaten. Dokumentieren Sie Unterschiede zur Produktion und deren Bedeutung. Benötigt der Prüffall eine frühere Aufzeichnung, stellen Sie deren Verfügbarkeit gezielt sicher. Die Eignung einer Testumgebung folgt aus dem Prüfziel, nicht allein aus ihrer Bezeichnung.
6. Eigene Erweiterungen und Schnittstellen ausdrücklich einbeziehen
Erfassen Sie die Abhängigkeiten eines relevanten Ablaufs auch außerhalb des sichtbaren ByDesign-Bildschirms. Dazu können Partnerlogik, zusätzliche Felder, Berichte und angebundene Systeme gehören. Fragen Sie den Partner nach betroffener Version, untersuchtem Änderungsumfang und verfügbaren Ergebnissen. Ein pauschales kompatibel hilft wenig, wenn die Aussage Ihren konkreten Datenweg nicht benennt.
Der SAP Security Guide beschreibt Kommunikationsvereinbarungen als Konfiguration des elektronischen Austauschs mit einem Kommunikationspartner. Er ordnet deren Konfiguration dem Kunden zu. Prüfen Sie deshalb auch Endpunkte, Authentifizierung und die Zuständigkeit für die jeweilige Gegenseite, wenn die Änderung diesen Bereich betrifft. Ein erreichbarer Dienst ist noch kein Nachweis korrekter fachlicher Verarbeitung.
Nach einer Systemkopie kann außerdem Nacharbeit nötig sein. Die Library nennt insbesondere die Aktivierung kundenspezifischer Add-ons im Status In Development im Zielsystem. Lassen Sie den Partner den für den Prüffall benötigten Zustand bestätigen. Andernfalls könnte der Test unbeabsichtigt einen anderen Ablauf ausführen als die spätere Produktion.
7. Beispiel: eine geänderte Übergabe an ein externes Lager prüfen
Das folgende Szenario ist selbst entwickelt. Es beschreibt weder eine reale SAP-Release-Änderung noch einen Kundenfall. Angenommen, Ihr Unternehmen überträgt einen Lieferauftrag mit Chargenbezug an ein externes Lager. Ein bewerteter Hinweis betrifft einen Bestandteil dieses Datenwegs. Ihre fachliche Vorgabe lautet: Nur die vorgesehene Charge und Menge dürfen weiterverarbeitet werden; unvollständige Übergaben müssen erkennbar bleiben.
Fachbereich und Partner bestimmen gemeinsam, wo der Auftrag fachlich verbindlich wird und welches System den Verarbeitungsstand führt. Erst danach legen sie Sollwerte und Belege fest. Die Auswahl unten konzentriert sich auf die betroffene Übergabe. Andere unabhängige ERP-Bereiche werden nicht allein wegen dieses Beispiels erneut geprüft.
Führen Sie die Fälle mit geeigneten Testendpunkten und repräsentativen Rollen aus. Ein bewusst erzeugter Fehler darf keine echte Lieferung anstoßen. Falls eine Gegenseite nur simuliert werden kann, dokumentieren Sie, welcher Teil damit belegt wird und welcher Nachweis am tatsächlichen Zusammenspiel noch fehlt.
| Prüffall | Erwartetes fachliches Verhalten | Ergebnisbelege |
|---|---|---|
| Gültiger Auftrag mit Teilmenge | Charge, Menge und Auftragsbezug kommen unverändert an | Quellbeleg, übertragener Datensatz und Zielbeleg |
| Fehlende erforderliche Chargenzuordnung | Unvollständiger Vorgang wird kontrolliert zurückgewiesen oder angehalten | Fehlermeldung und erkennbarer Bearbeitungszustand |
| Unterbrechung nach dem Versand | Wiederanlauf führt zu einem eindeutig geklärten Vorgang | Sende-/Empfangsbezug und dokumentierte Fortsetzung |
| Erneute Übermittlung desselben Vorgangs | Unbemerkte doppelte Verarbeitung bleibt ausgeschlossen | Vergleich der Geschäftsvorgänge beider Systeme |
| Korrektur eines noch offenen Vorgangs | Nur die fachlich gültige Fassung wird verwendet | Version beziehungsweise Korrekturbezug und finale Zuordnung |
Quellen: [4]
8. Abweichungen in eine begründete Betriebsentscheidung überführen
Wenn ein Test fehlschlägt, unterscheiden Sie zunächst Produktfehler, ungeeignete Testbedingungen und falsche Erwartung. Halten Sie den ursprünglichen Befund fest. Ein erfolgreicher Wiederholungstest erklärt noch nicht, warum der erste Versuch scheiterte. Besonders bei instabilen Datenwegen sollte die Ursache vor dem Abschluss ausreichend geklärt sein.
Ordnen Sie eine verbleibende Abweichung dem betroffenen Prozess und Risiko zu. Benennen Sie gegebenenfalls eine zulässige vorübergehende Maßnahme, Verantwortlichen, Gültigkeitsgrenze und spätere Erledigung. Nicht jedes offene Dokumentationsdetail muss dieselbe Konsequenz haben wie eine unzuverlässige Materialzuordnung.
Wenn der technische Update-Termin nicht in Ihrem Einfluss liegt, bleibt die Entscheidung über die zulässige Nutzung des betroffenen Ablaufs notwendig. Bereiten Sie erforderliche Einschränkungen oder geeignete Ersatzabläufe vor. Dieser Leitfaden unterstellt weder einen beliebig verschiebbaren SAP-Termin noch eine jederzeit mögliche Rückkehr zur alten Version.
Quellen: [4]
9. Den Abschluss mit dem tatsächlichen Systemstand verbinden
Ein brauchbarer Updateabschluss beantwortet wenige konkrete Fragen: Was wurde tatsächlich eingespielt? Welche Auswirkungen wurden bewertet? Welche Anforderungen sind durch welche Nachweise abgedeckt? Welche Abweichungen bleiben und wer hat die weitere Nutzung entschieden? Verknüpfen Sie Release-Unterlagen, Bewertung, Ergebnisse und Entscheidung so, dass der Zusammenhang später ohne Projekterinnerung verständlich bleibt.
Gleichen Sie die im Test verwendete Ausgangslage mit der tatsächlichen Produktion ab. Eine unerwartete zusätzliche Änderung verlangt eine erneute Bewertung ihrer Auswirkungen, nicht automatisch eine Wiederholung aller Tests. Legen Sie außerdem fest, welche ersten regulären Vorgänge nach dem Update besonders beobachtet werden und wie Auffälligkeiten gemeldet werden.
Aktualisieren Sie betroffene Betriebsanweisungen, Schulungsinformationen und den Systembestand. Nutzen Sie wiederkehrende Störungen oder schwer bewertbare Release-Hinweise, um den nächsten Durchlauf zu verbessern.
Quellen: [4]
10. Checkliste für einen planbaren Update-Durchlauf
Den Aufwand bestimmen vor allem die betroffenen Abläufe, Eigenentwicklungen, Datenwege, verfügbaren Nachweise und Testmöglichkeiten. Auch fehlende fachliche Sollwerte können mehr Arbeit verursachen als das technische Update selbst. Planen Sie deshalb die Mitwirkung des Fachbereichs und Partners ein; ein freier Kalenderslot der IT reicht nicht.
Ein Systemverantwortlicher kann den Ablauf koordinieren. Prozessverantwortliche legen die fachlichen Erwartungen fest, der Partner erläutert technische Abhängigkeiten und die Qualitätssicherung wirkt entsprechend Ihren geregelten Zuständigkeiten an Bewertung und Entscheidung mit. Die konkrete Aufgabenverteilung sollte vor dem nächsten Release geklärt sein.
- Betroffene Systeme, Ausgangs- und Zielstände sowie tatsächliche Termine erfassen.
- SAP- und Partnerhinweise mit Quelle und bewertetem Stand sammeln.
- Genutzte Prozesse, relevante Daten und Abhängigkeiten zuordnen.
- Unklarheiten klären und Testauswahl beziehungsweise Ausschlüsse begründen.
- Testsystem, Daten, Rollen, Erweiterungen und Gegensysteme auf Eignung prüfen.
- Ergebnisse und ursprüngliche Abweichungen nachvollziehbar dokumentieren.
- Verbleibende Risiken, vorübergehende Maßnahmen und Nutzungsentscheidung festhalten.
- Tatsächlichen Produktivstand, Betriebsunterlagen und erforderliche Nachbeobachtung abgleichen.
Quellen: [4]
Häufige Fragen zu ByDesign-Updates
Muss nach jedem ByDesign-Update vollständig revalidiert werden?
Nein, ein pauschaler Volltest folgt nicht allein aus einem Cloud-Update. Bewerten Sie die Auswirkungen auf Ihren freigegebenen Einsatz und die vorhandenen Nachweise. Daraus ergeben sich Art und Umfang zusätzlicher Prüfungen. Bei weitreichenden Änderungen kann dieser Umfang erheblich sein. Entscheidend ist eine nachvollziehbare Begründung, nicht das Ziel, grundsätzlich möglichst wenige oder möglichst viele Tests auszuführen.
Quellen: [4]
Bedeutet Info only, dass keine GxP-Bewertung nötig ist?
Nein. Die SAP-Angabe beschreibt den erwarteten Handlungsbedarf aus Produktsicht. Ihr Prozess kann besondere Abhängigkeiten haben, etwa eine relevante Auswertung oder externe Weiterverarbeitung. Ordnen Sie den Hinweis deshalb zumindest Ihrem Bestand zu. Wenn sich daraus begründet keine Auswirkung ergibt, können Sie dies dokumentieren, ohne vorsorglich jeden Funktionsbereich erneut zu testen.
Welche Release-Informationen braucht der Systemverantwortliche?
Benötigt werden die konkrete Änderung, Voraussetzungen, erwartete Aktionen und der bewertete Informationsstand. Ergänzen Sie den Bezug zur eigenen Nutzung, relevante Partnerhinweise und tatsächliche Systemtermine. SAP-Previews können sich noch ändern. Eine früh erstellte Bewertung sollte deshalb gegen die endgültige Information geprüft werden, bevor sie als Grundlage des Updateabschlusses dient.
Wann sollten wir das Testsystem vorbereiten?
So früh, dass benötigte Daten und Komponenten vor dem vorgesehenen Prüfzeitraum verfügbar sind. Die SAP Library schließt die Anforderung einer Produktivkopie während des Upgrade-Zeitraums zwischen Test- und Produktivsystem aus. Klären Sie außerdem benötigte Anlagen und Änderungsbelege. Ein kurzfristig verfügbares Testsystem ist nicht automatisch für historische oder durchgängige Prozessprüfungen geeignet.
Dürfen wir ungenutzte neue Funktionen ausschließen?
Ein Ausschluss kann begründet sein, wenn die Funktion tatsächlich nicht genutzt wird und keine relevante Abhängigkeit beeinflusst. Prüfen Sie auch Vorgaben, die sich automatisch auf bestehende Abläufe auswirken könnten. Halten Sie den Bestandsbezug und Ihre Begründung fest. Das bloße Etikett neue Funktion ist weder ein ausreichender Ausschlussgrund noch ein automatischer Testauftrag.
Quellen: [4]
Genügt die Kompatibilitätsbestätigung unseres Partners?
Sie kann einen wichtigen Beitrag leisten, wenn klar ist, welche Erweiterung, Version und Nutzung sie abdeckt. Prüfen Sie ihre Übertragbarkeit auf Ihren Ablauf. Offene Anforderungen, kundenspezifische Einstellungen und relevante Schnittstellen können zusätzliche Nachweise benötigen. Vermeiden Sie sowohl das ungeprüfte Übernehmen einer allgemeinen Zusage als auch das vollständige Wiederholen geeigneter Partnernachweise ohne fachlichen Grund.
Quellen: [4]
Warum reicht ein erfolgreicher Schnittstellenaufruf nicht?
Er zeigt zunächst nur einen Teil des Datenwegs. Ihr fachlicher Nachweis muss beispielsweise bestätigen, dass Identität, Menge und Bezug im Ziel richtig verarbeitet werden. Prüfen Sie passend zum Risiko auch Unterbrechung, Wiederholung und Korrektur. In ByDesign sind Kommunikationsvereinbarungen kundenspezifisch konfiguriert; deshalb gehören die eigene Einstellung und die tatsächliche Gegenseite in die Betrachtung.
Wann kann eine dokumentierte Bewertung ohne neuen Funktionstest ausreichen?
Wenn Sie mit geeigneten Unterlagen nachvollziehbar zeigen können, dass der freigegebene Einsatz und seine relevanten Kontrollen nicht betroffen sind. Benennen Sie die betrachteten Abhängigkeiten und den Grund für den Ausschluss. Bei ungeklärter Auswirkung ist die Bewertung hingegen noch nicht abgeschlossen. Ein fehlender Test ist dann keine risikobasierte Entscheidung, sondern eine offene Frage.
Quellen: [4]
Was passiert bei einem offenen Fehler kurz vor dem technischen Update?
Bewerten Sie die Auswirkung auf den konkreten Ablauf und eskalieren Sie die erforderliche Entscheidung an die zuständigen Verantwortlichen. Eine Einschränkung der Nutzung oder ein geeigneter Ersatzablauf kann notwendig werden. Deren Zulässigkeit muss begründet sein. Unterstellen Sie keine beliebige Verschiebung oder Rückabwicklung des Cloud-Updates; klären Sie die tatsächlich verfügbaren technischen und betrieblichen Möglichkeiten.
Quellen: [4]
Was gehört zum Abschluss und wer muss dafür mitarbeiten?
Der Abschluss verbindet Systemstand, Auswirkungsbewertung, ausgewählte Nachweise, Abweichungen und die Entscheidung über die weitere Nutzung. Systemverantwortlicher, betroffener Fachbereich, Qualitätssicherung und zuständige Partner liefern ihre vereinbarten Beiträge. Aufwand und Dauer hängen vor allem von Auswirkungen und offenen Nachweisen ab. Eine feste Schätzung allein aus der Bezeichnung ByDesign-Update wäre deshalb nicht belastbar.
Quellen: [4]
Quellen & fachlicher Stand
Quellenstand: 6. Oktober 2026. Herstellerangaben stammen aus SAP-Unterlagen für ByDesign 2608; maßgeblich für Ihren Durchlauf bleiben die tatsächlichen Systemstände und Termine. Vorläufige Release-Hinweise können sich ändern. Die Matrizen und das Lagerbeispiel sind eigene Prüfvorschläge und beschreiben keine konkrete SAP-Release-Änderung. Regulatorischer Schwerpunkt: GMP-Prozesse für Humanarzneimittel.
- SAP Business ByDesign 2608: How to Use the What’s New Viewer
- SAP Business ByDesign Library 2608, 21. August 2026: Wartungsplan und Systemkopien
- SAP Business ByDesign Security Guide 2608, 31. Juli 2026: Kommunikationsvereinbarungen
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems
- Europäische Kommission: EudraLex Volume 4, geltende GMP-Leitlinien
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Den nächsten ByDesign-Updateumfang begründet festlegen
Wir unterstützen Sie dabei, Release-Hinweise mit Ihren Prozessen und bestehenden Nachweisen zu verbinden. Daraus entsteht eine konkrete Auswahl von Prüfungen und offenen Entscheidungen.
- IT-GxP-Consulting →
Auswirkungsbewertung, Regression und nachvollziehbaren Updateabschluss gemeinsam strukturieren.