In einem der letzten Artikel hatte ich über den Mythos des nicht validierbaren SharePoints gesprochen und im Zuge dessen versprochen, noch einmal im Detail darauf zurückzukommen.
SharePoint als Tool kenne ich bereits seit 2002, habe also schon einiges damit gemacht und muss zugeben, dass ich ein „Fan“ des Tools bin und deswegen unter Umständen nicht ganz neutral sein werde 🙂 Was SharePoint in meinen Augen ausmacht, ist nicht, dass es dort keine Probleme gibt. Vielmehr gefällt mir, dass es ein sehr flexibles Toolset ist, um Unternehmen bei ihren Validierungsbestrebungen zu unterstützen. Inzwischen weiß ich genau, wo ich es wie einsetzen kann und wo es nicht geeignet ist.
Der Ansatz, den ich im Folgenden beschreiben werde, wurde bereits in mittelständischen sowie DAX-Unternehmen, bei Lohnherstellern und Biotech-Unternehmen implementiert und vielfach von Kunden, RP und FDA auditiert. Der Kern einer erfolgreichen Validierung ist, wie bei jeder anderen Software, das Verständnis des Tools.
Einer der wichtigsten Punkte, die es bei SharePoint (SP) grundlegend zu verstehen gilt, ist, dass SP keine „ready to use“ Software ist. Zum einen gibt es viele Teilkomponenten, die auf den Bedarf angepasst ausgewählt werden müssen. Zum anderen bietet SP nach der Installation zunächst erst einmal eine Basis, auf der wir dann unsere Prozesse implementieren können.
Aus diesem Grund ist der Basisansatz bei SharePoint derselbe, wie bei einem großen ERP, zum Beispiel SAP. Wir qualifizieren unseren SP als Plattform. Dann stellen einen qualifizierten Betriebsprozess zur Verfügung, indem wir unsere GxP-Prozesse abbilden und sauber validieren können.
Im Folgenden werde ich nur auf die Kernkomponente, die Web- / Portal-Lösung eingehen. Der Ansatz kann direkt auf andere Komponenten, wie den Business Data Connector (BDC), die Suchdienste oder die Workflowdienste übertragen werden.
Die Installation von SharePoint – Installation Qualification
Fangen wir bei den Basics an: der Installation. SP basiert auf einem Windows-Server und MS SQL als Datenbank. Während die qualifizierte Inbetriebnahme von Windows Servern inzwischen schon gut etablierter Standard in den Unternehmen ist, sind sich viele nicht bewusst, dass bei der SQL-Installation eine Installationsdatei erzeugt werden kann. Diese können Sie im Zuge der IQ als Beweis verwenden. Alternativ können Sie die Installationsdatei auf dem DEV erzeugen und diese mit den Parametern auf VAL und PROD verwenden. Ich bevorzuge diese Variante, da ich so sicher sein, dass alle Umgebungen gleich konfiguriert sind.
Jetzt geht es an die Installation von SP selbst und auch hier gibt es gute Nachrichten: Diese Installation kann ebenfalls vollständig gescriptet ausgeführt werden! Dies trifft auch auf die Konfiguration zu. Kern der Dokumentation bei meinen Installationen ist deshalb immer eine „einseitige IQ“ im Sinne von „Führe das Script aus der Anlage aus“. In der Anlage habe ich dann eine vollständig gescriptete Installation und Konfiguration der SP-Instanz. Haben Sie jemals eine einfachere IQ erlebt?
Der qualifizierte Betrieb – Key to survive
Nachdem wir jetzt eine qualifizierte Infrastruktur haben, müssen wir diese nur noch qualifiziert betreiben. Hier setze ich auf zwei Kernkomponenten:
- Risikoabhängige Trennung von Inhalten / Prozessen
- Skriptbasierte Administration
1. Trennung von Inhalten und Prozessen nach Risiken
SP bietet uns unterschiedliche Möglichkeiten, um Inhalte voneinander zu trennen. Meine Empfehlung ist hier: Kategorisieren Sie Ihre Inhalte und legen Sie für die jeweiligen Kategorien Regeln fest. Die Ebenen der Abgrenzung sind (von der geringsten zur größten Abgrenzung)
- Teamseite: In unterschiedlichen Teamsites können Sie zum Beispiel unterscheiden, ob Farben und Anzeigen (so genannte Webparts) bearbeitet werden können.
- Webseitensammlung: Teamsites werden in Sammlungen gruppiert. Dort sind auch Gruppen aufgehängt, was bedeutet, dass Sie eine sicherheitstechnische Abgrenzung von Gruppen ab hier durchführen können.
- Web-Anwendung: Web-Anwendungen können separat gestartet und gesichert werden.
- Separater SP-Server: Sie können Server mit unterschiedlichen Versionen in Ihrer Farm haben und diese dem Anwender trotzdem in einer Oberfläche präsentieren.
Was bedeutet das jetzt in der Praxis?
Mein Startpunkt für eine Separierung sieht in 90% der Fälle wie folgt aus: Ich erstelle separate Webseitensammlungen für Gxp- und für non-Gxp-Themen. Dann erhält jeder Bereich Teamsites basierend auf seinen Anforderungen. So können Sie super einfach einen sehr dynamischen und flexiblen Bereich für, zum Beispiel, Projektteams schaffen. Gleichzeitig haben Sie einen kontrollierten Bereich vorliegen, in dem beispielsweise die Rechteanforderung über die IT laufen.
Erstellen Sie sich jetzt noch ein einfaches Formular (gerne auch in SharePoint) mit dem Sie prüfen können, in welchem Bereich neue Anträge einzusortieren sind. Damit haben Sie sich dann eine qualifizierte Basis für validierte SP-basierte Prozesse geschaffen.
2. Skript basierte Administration
Wie bereits erwähnt, ist SP ein sehr komplexes Tool und es gibt oft mehrere Wege dasselbe Ziel zu erreichen. Aus diesem Grund verwende ich für die Administration von SP sehr gerne Powershell Skripte. Dies hat den Vorteil, dass wir direkt unsere Doku mit automatisieren können und so eine Basis aufbauen, um Aufgaben weiter zu delegieren oder gar zu automatisieren.
Beim Einsatz von Skripten sollte immer beachtet werden, dass die Versionen kontrolliert sind und immer klar ist, welche Version zu verwenden ist. Im Optimalfall sollte auch noch jede Ausführung mit ihren Parametern dokumentiert werden.
Hier gibt es unterschiedliche Tools auf dem Markt, die das unterstützen. Aber auch die Versionierung in SharePoint kann schon helfen. In neuen Prozessen ist es oft schwer zu überschauen, welche Arbeiten wie oft vorkommen. Daher scripte ich vorab die wichtigsten Standardthemen, wie „Neuer Benutzer“, „Neue Site“ und ähnliches. Alle anderen Themen werden dann gescriptet, wenn sie auftreten. Das heißt, dass die erste Ausführung einer Task deutlich länger dauert, da hier das Skript erstellt werden muss. Alle Folgeausführungen haben dann einen reduzierten Aufwand.
Nach der Qualifizierung die Validierung
Nachdem wir jetzt auf einer vollständigen, qualifizierten Umgebung arbeiten, ist die Validierung von neuen Prozessen sehr unkompliziert. Sie müssen es nur schaffen, sich auf die Benutzeranforderungen zu fokussieren und keine technischen Themen in die URS mit aufnehmen.
In einfachen Fällen (zum Beispiel eine Dokumenten-Bibliothek für GxP-Dokumente) führen Sie dann lediglich eine kleine IQ durch (Dokumentation über Skript). Im Anschluss folgt eine PQ-Phase, in der der Anwender die Lieferung überprüft. Bei komplexeren Themen kommt klassisch eine FS- und OQ-Phase hinzu.
Fazit: SharePoint-Validierung – easy as eating cake
Sie sehen, der Aufwand für einen qualifizierten Betrieb und Validierung von SharePoint ist überschaubar. Wir müssen lediglich unser System qualifiziert aufsetzen und betreiben und es schaffen, bei den Benutzeranforderungen auch wirklich auf Benutzerebene zu bleiben.
Welche Herausforderungen hatten Sie bereits mit SharePoint?
Mit chaotischen Grüßen,
Christof Layher
