ServiceNow im GxP-Umfeld validieren: vom genehmigten Change zum nachgewiesenen Systemstand

1. Den konkreten ServiceNow-Prozess statt einer ganzen Plattform bewerten

Hier geht es um ServiceNow Change Management im ITSM-Kontext, seine Beziehungen zur Configuration Management Database und die benötigten Plattformaufzeichnungen. Das ist kein pauschaler Leitfaden für alle ServiceNow-Produkte. Erfassen Sie Ihre Anwendungen, Lizenzrechte, aktivierten Erweiterungen, Integrationen und angepassten Workflows. Ein Sicherheitszertifikat des Anbieters kann relevante Lieferantenevidenz sein, bestätigt aber nicht automatisch Ihren konkreten Freigabeprozess.

Die verlinkte Dokumentation zeigt den Releasebezug Brazil. Einzelne Neuerungen stehen ausdrücklich unter Early Availability. Daraus folgt nicht, dass diese Funktionen in Ihrer Instanz allgemein verfügbar oder aktiviert sind. Dieser Artikel setzt insbesondere neue Lockdown-, KI- oder Compliance-Funktionen nicht als vorhandene Kontrolle voraus. Prüfen Sie Ihren tatsächlichen Release- und Konfigurationsstand, bevor Sie eine Herstellerbeschreibung in eine Anforderung oder einen Test übernehmen.

Der regulatorische Bezug ist ein Einsatz innerhalb der GMP-Herstellung von Humanarzneimitteln. Entscheidend ist, ob ServiceNow relevante Prozesse oder Aufzeichnungen beeinflusst. Ein Ticket für eine Bürotastatur hat einen anderen Einfluss als die Genehmigung einer LIMS-Schnittstellenänderung. Annex 11 liefert dafür den risikobezogenen Lebenszyklusrahmen; eine universell „validierte SaaS“ lässt sich aus dem Produktnamen nicht ableiten.

Quellen: [7] [1] [8] [9]

2. Standard, Normal und Emergency fachlich begrenzen

ServiceNow unterscheidet unter anderem Standard-, Normal- und Notfalländerungen. Standardänderungen beruhen auf einem vorab genehmigten wiederholbaren Ablauf. Normaländerungen durchlaufen Bewertung und Genehmigung; Notfalländerungen haben einen beschleunigten Weg. Das beschreibt die Prozessmechanik, nicht bereits die Angemessenheit für Ihr GMP-Umfeld.

Für eine Standardvorlage sollten Sie den erlaubten Umfang konkret benennen: betroffene Systemtypen, freigegebene Parameter, notwendige Voraussetzungen und Abbruchbedingungen. Ein Austausch außerhalb dieser Grenzen darf nicht allein aufgrund einer ähnlich klingenden Vorlage den vorab genehmigten Weg nutzen. Prüfen Sie daher einen passenden und einen absichtlich unpassenden Auftrag. Legen Sie auch fest, wer die Vorlage selbst ändern darf und welche Bewertung dadurch erneut erforderlich wird.

Für Notfälle sind Befugnis, Sofortentscheidung und nachfolgende Vervollständigung der Nachweise festzulegen. Dringlichkeit ist keine Bestätigung der fachlichen Sicherheit. Ein CAB kann Teil Ihres Verfahrens sein; dieser Artikel unterstellt kein universell vorgeschriebenes Gremium. Wichtig ist, dass die zuständigen Entscheider die betroffene Qualitäts- und Datenwirkung erkennen und der tatsächlich gewählte Ablauf nachvollziehbar bleibt.

Quellen: [2] [9]

3. CMDB-Beziehungen mit dem Änderungsumfang abgleichen

Ein Configuration Item beschreibt ein verwaltetes Objekt. ServiceNow kann mehrere CIs einem Change zuordnen und zwischen betroffenen CIs und beeinflussten Services unterscheiden. Ein vorhandener Link beweist allerdings weder die Vollständigkeit Ihrer Abhängigkeiten noch den tatsächlichen Zustand eines Servers oder einer Anwendung. Dafür brauchen Sie einen geeigneten Abgleich außerhalb der bloßen Ticketverknüpfung.

Beginnen Sie mit der betroffenen Funktion: Welcher Datenweg soll sich ändern, und welche Anwendung verarbeitet das Ergebnis? Vergleichen Sie anschließend die CI-Liste mit Architektur, Verantwortlichen und tatsächlicher Verbindung. Die folgende Arbeitshilfe zeigt den benötigten Zusammenhang. Sie schreibt weder getrennte Dokumente noch ein bestimmtes ServiceNow-Datenmodell vor; entscheidend ist die nachvollziehbare Verbindung.

Quellen: [3] [1] [9]

4. Proposed Changes nicht mit einer Umsetzungssperre verwechseln

Bei Proposed Changes können vorgesehene CI-Werte zunächst vorgemerkt und später angewandt werden. Die ServiceNow-Dokumentation erklärt ausdrücklich, dass das Anwenden auch ohne Verifikation oder trotz fehlgeschlagener Verifikation möglich ist. Wer für seinen Prozess eine Sperre benötigt, darf sie daher nicht allein aus dem Vorhandensein dieses Prüfschritts ableiten.

Eine weitere Grenze betrifft die Erkennung geplanter Änderungen. Die dokumentierte Standardlogik kann den zeitlichen Zusammenhang mit einem Change berücksichtigen. ServiceNow weist darauf hin, dass dadurch eine manuelle, inhaltlich unzulässige Änderung innerhalb des Fensters als geplant erscheinen kann. Ein passender Zeitstempel ist folglich kein Ersatz für den Vergleich mit dem genehmigten Zielwert.

Definieren Sie die benötigte Kontrolle konkret und prüfen Sie ihre tatsächliche Wirkung. Das kann ein wirksam konfigurierter technischer Übergangsschutz sein oder eine begründete andere Kontrolle im Gesamtprozess. Halten Sie außerdem auseinander, ob gerade ein CMDB-Datensatz geändert wird oder die reale Zielanwendung. Ein Apply-Vorgang an der CMDB ist nicht automatisch ein Deployment auf dem betroffenen System.

Quellen: [4] [9]

5. Illustratives Beispiel: ein genehmigter Schnittstellenwechsel

Das folgende Beispiel ist frei konstruiert, kein Kundenfall und kein ausgeführter ServiceNow-Test. Change C-17 betrifft Gateway G1 sowie die beiden Anwendungen A1 und A2. Genehmigt ist der Wechsel eines Anschlussports von 8443 auf 9443 in allen drei betroffenen Konfigurationen. Eine definierte Nachricht mit Charge L17 und Ergebnis 7,25 mg muss danach bei beiden Empfängern inhaltlich unverändert ankommen.

Das eigene Soll verlangt vor Umsetzung eine berechtigte Genehmigung, eine passende CI-Liste und eine erfolgreiche technische Vorprüfung. Für die CMDB-Anwendung wird hier ausdrücklich eine technische Sperre bei fehlgeschlagener Verifikation als Anforderung gewählt; sie ist keine behauptete ServiceNow-Standardeigenschaft. Negative Zweige werden getrennt vom positiven Ablauf aufgebaut und anschließend kontrolliert zurückgesetzt.

Das Fenster 20:00 bis 21:30 umfasst 90 Minuten. Geplant sind 15 Minuten Sicherung, 20 Minuten Umsetzung und 25 Minuten Prüfung, insgesamt 60 Minuten. Hinzu kommen 20 Minuten Rückfallreserve; damit bleiben zehn Minuten Puffer. Die Rechnung zeigt nur die Planungskonsistenz. Ob diese Zeiten und das Rückfallverfahren geeignet sind, müsste ein tatsächliches Projekt separat belegen.

Quellen: [4] [1]

6. Tatsächliche Umsetzung und Testbelege zusammenführen

Legen Sie fest, welcher Beleg den tatsächlichen Zielstand zeigt. Das kann beispielsweise ein kontrollierter Konfigurationsexport, ein geeignetes Deploymentprotokoll oder ein überprüfter Systembefund sein. Die Wahl hängt vom Zielsystem ab. Ein ausführlicher Freitext im Change ersetzt diesen Nachweis nicht, wenn er nur die beabsichtigte Handlung beschreibt.

Verbinden Sie den Beleg mit dem genehmigten Stand. Wurde unterwegs ein Parameter geändert, eine Anwendung ausgelassen oder eine zusätzliche Komponente angefasst, braucht diese Abweichung eine Bewertung. Das bedeutet nicht automatisch ein vollständiges neues Projekt. Es muss aber erkennbar bleiben, welche Teile des ursprünglichen Nachweises weiterhin passen und wo eine neue Entscheidung oder Prüfung erforderlich wird.

Der Abschluss sollte die tatsächlich relevanten Ergebnisse zusammenfassen: Was wurde umgesetzt, welche Tests waren erfolgreich, welche Befunde bleiben und wer entscheidet über die Nutzung? Eine Fehlermeldung ist nicht bereits durch das Schließen einer Aufgabe erledigt. Ebenso beweist ein einzelner grüner Test nur seine eigene Fragestellung. Bestimmen Sie im Verfahren, wie aus den Einzelbelegen eine tragfähige Gesamtentscheidung entsteht.

Quellen: [1] [10] [9]

7. Rollen, Genehmigungen und alternative Schreibwege prüfen

Prüfen Sie, wer einen Change anlegt, fachlich bewertet, genehmigt, umsetzt und abschließt. Berücksichtigen Sie zusätzlich Administratoren, Schnittstellen und automatisierte Abläufe. Die in der Dokumentation beschriebene Feldeditierbarkeit hängt vom Zustand und konfigurierten Workflow ab. Eine schreibgeschützte Formularansicht beweist daher nicht allein, dass jeder andere relevante Schreibweg ausreichend kontrolliert ist.

Als gezielter Negativtest eignet sich eine Änderung des genehmigten Zielwerts durch einen Benutzer mit unzureichender Befugnis. Prüfen Sie außerdem, ob ein automatischer Import oder technischer Dienst denselben Sachverhalt verändern kann. Der Testumfang sollte den tatsächlich genutzten und risikorelevanten Wegen folgen. Es ist nicht sinnvoll, hypothetische Integrationen zu testen, die Ihre Instanz gar nicht besitzt.

Eine Genehmigung benötigt einen klaren Gegenstand und eine befugte Person. Ob zusätzlich Anforderungen an elektronische Signaturen greifen, ergibt sich aus dem vorgesehenen Prozess und Regelbereich, nicht aus der Bezeichnung des Buttons. Legen Sie fest, wie Identität, Entscheidungsbedeutung und zugehöriger Stand zusammenbleiben. Eine gemeinsame Gruppenidentität darf dabei nicht unbemerkt die erforderliche Zuordnung zur entscheidenden Person ersetzen.

Quellen: [1] [9]

8. Auditdaten, History Sets und aufbewahrte Nachweise unterscheiden

ServiceNow dokumentiert Auditing für aktivierte Tabellen und Felder. Einstellungen werden nicht automatisch von einer übergeordneten auf eine untergeordnete Tabelle übertragen. Die Dokumentation nennt zudem Ausnahmen, unter anderem bestimmte Upgrade- und Importwege. Prüfen Sie deshalb die tatsächlich relevanten Felder und Änderungskanäle Ihrer Instanz, statt aus einer aktivierten Auditfunktion auf vollständige Abdeckung zu schließen.

History Sets dienen einer bei Bedarf erzeugten Darstellung aus Auditdaten. ServiceNow rät davon ab, sie als Grundlage für Reports zu verwenden. Ein verständlicher Verlauf in der Oberfläche beantwortet daher noch nicht, ob ein langfristig benötigter Nachweis vollständig exportiert, wiedergefunden und gelesen werden kann. Wählen Sie den vorgesehenen Berichts- oder Aufbewahrungsweg anhand der benötigten Belegfunktion.

Für eine relevante Zielwertänderung sollte ein Prüfer den vorherigen und neuen Sachverhalt, den Verantwortlichen und den Zusammenhang zur Entscheidung nachvollziehen können. Definieren Sie außerdem benötigte Anhänge und externe Belege. Die Aufbewahrung richtet sich nach deren Zweck und einschlägigen Anforderungen. Dieser Artikel setzt weder unbegrenzte Speicherung aller Plattformereignisse noch eine einheitliche Frist für sämtliche Tickets voraus.

Quellen: [5] [6] [10]

9. Auch das Change-System kontrolliert weiterentwickeln

Wenn ein Workflow neue Genehmiger bekommt, eine Schnittstelle anders schreibt oder ein Plugin aktualisiert wird, kann sich die Verlässlichkeit des Nachweiswegs ändern. Bewerten Sie daher nicht nur Updates der gesteuerten GMP-Anwendungen, sondern auch relevante Änderungen am ServiceNow-Prozess selbst. Lieferantenunterlagen und Release Notes helfen, den betroffenen Umfang einzugrenzen; sie ersetzen den Abgleich mit Ihrer Konfiguration nicht.

Für Regression bieten sich gezielt die kritischen Übergänge an: fehlende Genehmigung, geänderter Umfang, negative Verifikation, unerlaubte Feldänderung und fehlender Abschlussbeleg. Auch zuvor unveränderte Schritte können von einer neuen Regel beeinflusst werden. Bestehende Nachweise dürfen dagegen weiter genutzt werden, wenn ihre Eignung für den neuen Stand nachvollziehbar begründet bleibt.

Prüfen Sie außerdem den Betrieb bei Ausfall oder eingeschränktem Zugriff. Wie wird ein dringender Change kontrolliert entschieden, wenn der normale Workflow nicht erreichbar ist? Wie kommen nach Wiederherstellung die zusammengehörigen Belege zurück in den vorgesehenen Nachweisweg? Ein solches Verfahren sollte Ihrem Risiko entsprechen. Es ist weder ein pauschaler Freibrief zur Umsetzung noch zwingend eine zweite vollständige Plattform.

Quellen: [7] [9] [10]

10. Vorbereitung und Checkliste für QA und IT

Für ein kleineres Unternehmen ist ein eng abgegrenzter Pilotprozess oft hilfreicher als eine pauschale Plattformliste. Wählen Sie einen wiederkehrenden Change mit echter GMP-Wirkung und einem bekannten Datenweg. Der Process Owner erklärt Entscheidungen und Ausnahmen; IT liefert Instanz-, CI- und Integrationswissen; QA bewertet Qualitätswirkung und Nachweisanforderungen. Der Implementierungspartner sollte die tatsächlich wirksamen Regeln erläutern können.

Aufwand entsteht besonders durch unklare CMDB-Verantwortung, viele abweichende Workflows, nicht nachvollziehbare Anpassungen, externe Belegablagen und fehlende repräsentative Testdaten. Eine belastbare Planung braucht daher zunächst einen aktuellen Ablauf und dessen offene Nachweislücken. Die folgende Checkliste unterstützt diese Vorbereitung; sie ist keine universelle Zertifizierungscheckliste.

• Anwendungen, Lizenzumfang, Release und relevante Anpassungen erfasst.
• GMP-relevante Change-Arten und begründete Ausnahmen abgegrenzt.
• Genehmigter Inhalt mit betroffenen CIs und Datenwegen verbunden.
• Verifikation und tatsächliche Durchsetzung erforderlicher Kontrollen unterschieden.
• CMDB-Stand mit realer Konfiguration und Umsetzungsbelegen verglichen.
• Rollen, technische Konten und alternative Schreibwege berücksichtigt.
• Fachliche Prüfergebnisse und offene Befunde im Abschluss bewertet.
• Auditabdeckung und langfristige Lesbarkeit benötigter Nachweise geprüft.
• Update-, Notfall- und Ausfallverfahren mit Verantwortlichen festgelegt.

Quellen: [1] [3] [9]