Validierung im Rechenzentrum (Teil 1)

Blog-Featureimage--Outsourcing-20140818-corp

In unseren Rechenzentren betreiben wir etliche Kundensysteme, die aufgrund diverser gesetzlicher Vorgaben qualifiziert oder validiert betrieben werden müssen. Die Validierung eines Systems wird beispielsweise von folgenden Regularien gefordert:

  • SOX (Sarbanes-Oxley Act) oder ISAE No. 3402 (International Standard on Assurance Engagements)
  • IT-Sicherheitsmanagement nach ISO/IEC 27001
  • Good Automated Manufacturing Practice (GAMP, GxP)
  • Payment Card Industry Data Security Standard (PCI DSS)
  • Zahlungsdienstleistungsaufsichtsgesetz (ZAG, BaFin)

Server

Wo liegt der Unterschied zwischen Qualifizierung und Validierung?
Eine Validierung ist notwendig, wenn das zu untersuchende System kritische Daten direkt verarbeiten kann, zum Beispiel bei GxP-relevanten ERP-Systemen. Die weniger aufwändige Qualifizierung kommt zum Einsatz, wenn das zu untersuchende System selbst keinen direkten Zugang zu solchen Daten besitzt – aber ein System steuert oder überwacht, das wiederum über den direkten Datenzugang verfügt. Ein System zu qualifizieren bedeutet, den Nachweis zu erbringen, dass es nach gewissen vorgegebenen Standards und Regeln aufgebaut wurde. Validierung bietet darüber hinaus den Beweis, dass ein System den zuvor definierten Anforderungen genügt.

Wozu ist das notwendig?
Sicherlich haben Sie schon von Rückrufaktionen im Automobilbereich, in der Pharma- oder der Lebensmittelbranche gehört. Wenn verunreinigte Produkte zurückgerufen werden oder Bauteile ersetzt werden müssen, weil sie die Funktion gefährden, ist dies nur mit einer guten Datenpflege machbar. Zugleich muss aber auch gewährleistet sein, dass die Systeme eine solche Datenkonsistenz sicherstellen. Und genau da setzen Qualifizierung und Validierung an. Die ordnungsgemäße Funktion wird anfänglich geprüft und durch ein sauberes Change-Management fortgeschrieben.

Der Betrieb von qualifizierten und validierten Systemen führt zu einem erhöhten Dokumentationsaufwand. Änderungen müssen zwar auch für andere Systeme nachvollziehbar dokumentiert werden, doch sind die Anforderungen hier deutlich höher. Nach einer Änderung muss das System ggf. erneut geprüft, das heißt re-validiert oder erneut qualifiziert werden. Und diese Dokumentation muss externen Auditoren standhalten. Ein hoher Anspruch, den die Kolleginnen und Kollegen in unseren Rechenzentren erfüllen.

Ein Beispiel: Validierung der itelligence Monitoring-Landschaft
Wir können die Systeme unserer Kunden nicht unbeaufsichtigt betreiben. Da es sich um einige hundert Systeme handelt, kommt ein automatisches Monitoring zum Einsatz: SAP-Systeme überwachen wir mit Nagios und mit dem SAP Solution Manager. Mit dem neuen Solution Manager 7.1 hat SAP das Monitoring komplett umgebaut und neben das alte CCMS die neue Monitoring and Alerting Infrastructure (MAI) gesetzt, die wir nun nutzen wollen. Im Rahmen der Umstellung befassen wir uns zurzeit mit der Validierung dieses neuen Monitorings.

Der Validierungsprozess besteht aus mehreren Schritten:

1. Risikobewertung
Anhand einer Checkliste wird ermittelt, ob eine Qualifizierung oder Validierung erforderlich ist.

2. Anforderungsspezifikation
Ein Lastenheft entsteht, aus dem die Funktionen des Tools hervorgehen. Aus diesem Lastenheft werden später Testpläne abgeleitet.

3. Risikoanalyse
Etwaige Schwachstellen müssen beschrieben werden. Falls möglich, werden Maßnahmen ergriffen, um die Schwachstellen zu mindern oder zu eliminieren. Die Risikoanalyse dient auch zur Berechnung möglicher Schäden, die z. B. durch Vertragsstrafen entstehen  können.

4. Validierungsplan
Ein Validierungsplan wird erstellt, der genehmigt werden muss.

5. Installationsplan
Die einzelnen Schritte zum Aufbau des Systems werden beschrieben. Dabei wird auf vorhandene Dokumentationen und Anleitungen verwiesen. Insbesondere der Verweis auf SAP Installation Guides ist hilfreich.

6. Testanleitungen
Aus der Anforderungsspezifikation werden Testpläne abgeleitet, mit denen ein ordnungsgemäßer Betrieb des Tools überprüft wird.

An die Planung der Validierung schließt sich die Umsetzung an, die wiederum in mehreren Schritten erfolgt. Die Umsetzung orientiert sich an der erstellten Planung.

1. Installation
Das Tool wird anhand des erstellten Plans installiert. Hierbei werden ggf. Angaben aus der Anforderungsspezifikation umgesetzt. Abweichungen von der Planung aufgrund von unerwarteten Fehlersituationen oder Neuerungen werden dokumentiert.

2. Testprotokolle
Die geplanten Tests werden durchgeführt und protokolliert. Abweichungen werden dokumentiert und möglichst behoben.

3. Validierungsbericht
Die Testprotokolle werden in einem Validierungsbericht zusammengefasst.

Danach wird das Tool an den Betrieb übergeben. Änderungen unterliegen dem Change-Management, das bei Bedarf Revalidierungen einleitet. Zudem wird im zweijährigen Rhythmus geprüft, ob eine grundlegende Revalidierung notwendig ist. Falls nicht, muss dies begründet werden. Bei der Revalidierung werden die genannten Schritte erneut durchgeführt. Sie baut, wenn möglich, auf den bereits erstellten Validierungsplan und die Testanleitungen auf.

In einem 2. Teil dieser Blogreihe werde ich die beispielhafte Validierung der itelligence Monitoring-Landschaft weiter verfolgen. Für Rückfragen stehe ich gern zur Verfügung.

– Rainer Kunert, itelligence Outsourcing & Services GmbH –

Ähnliche Beiträge

feature-image-people
Lesen Sie mehr
blog-featured-image-auster
Lesen Sie mehr
featured-image-sundown
Lesen Sie mehr
itelligence Conference Center
Lesen Sie mehr
image blog digitale welt
Lesen Sie mehr
SAP S/4HANA Generationswechsel
Lesen Sie mehr

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Folgen Sie uns: