(pressebox) (Mainz, 10.01.2017) .

1. Überblick

Der SAP Solution Manager 7. 2 bietet zur Vorgängerversion einige Veränderungen und Neuerungen, die es zu beachten gilt. Im Rahmen dieses Artikels soll nicht jede einzelne Neuerung und Veränderung aufgezählt werden. Diese können auf der SAP Website nachvollzogen werden.

Vielmehr werden diejenigen Änderungen und Neuerungen betrachtet, für die sich neue Herausforderungen und Möglichkeiten für die Life Science Branche ergeben.

2.  Grundlagen

Der Solution Manager ist eine Anwendung zur Verwaltung, Überwachung und Wartung der angeschlossenen Systeme. Die Version 7.1 wird ab dem 31.12.2017 von der SAP nicht mehr gewartet und muss ersetzt werden. Die Nachfolgeversion 7.2 steht seit dem 15.08.2016 jedem zur Verfügung. Einzelne Releases folgen und sind über das Jahr verteilt.

3. Neuerungen

Interessante Änderungen betreffen die neue Organisation der Systemlandschaften und die Möglichkeiten zur Dokumentation der Systeme und Prozesse. Beide Bereiche sind eng miteinander verbunden und es sind neue Konzepte zur Anwendung gekommen, die eine Veränderung im Umgang und dem Betrieb des Solution Managers erfordert. Neu hinzugekommen ist ein integriertes Anforderungs-Management (Requirement Management), mit dem sich Anforderungen innerhalb Projekten mittels eines Workflows und schließlich des Change Prozesses transportieren und implementieren lassen.

3.1. Systemlandschaft

Der neue Ansatz des Solution Managers 7.2 ordnet logische Komponenten zu Gruppen zusammen (Logical Component Groups) (LCG). Weiterhin werden s.g. Branches erstellt, wovon mindestens zwei vorhanden sein müssen. Eine Branch kann als der Kontext der Gesamtheit aus System, Prozessen und Anwendungen gesehen werden, die diese Lösung widerspiegelt. Standardmäßig sind mindestens zwei Branches vorgeben.  Zum einen die „productive“ Branch, die das aktuelle Produktivsystem wiederspiegelt und keine direkten Änderungen zulässt, sowie eine „maintenance“ Branch. Für Entwicklungen werden separate „developer“ Branches genutzt, die zukünftige Versionen der Produktiv-

3.2. Dokumentation

Der Dokumentation kommt für die regulierte Life Science Industrie mit ihren speziellen Anforderungen eine besondere Bedeutung zu. Die bekannte Solar-Welt ist nicht mehr vorhanden und die Transaktionen Solar01/ 02 sind nicht mehr vorhanden. Dokumentationen jeder Art, funktionale Spezifikationen, Testfälle, Beschreibung der Geschäftsprozesse werden nach wie vor den Prozessen direkt zugeordnet. Als neue Funktion bietet der Solution Manager 7.2 die Möglichkeit, Dokumente einzelnen Sites zuzuordnen, sowie die Aufhebung der Limitierung auf drei Ebenen.

3.3. Requirement Management

Im regulierten Umfeld kommen dem Management von Anforderungen an Systeme und Prozesse eine besondere Bedeutung zu. Die Anforderungen müssen unterschrieben und aufbewahrt werden, sodass stets der Ursprung der Anforderung ermittelbar ist. Änderungen und Anpassungen ausgehend von diesen initialen Anforderungen werden als Change behandelt. Im Solution Manager 7.2 sind Anforderungen eng mit dem Project Management und dem Change Control Prozess im SAP verzahnt. Das Requirement Management dient dazu, neue Anforderungen desjeweiligen Bereiches zu erfassen, wohingegen der 

umgebung darstellen. Die LCGs und Branches überschneiden sich, wodurch organisatorische Teilbereiche abgebildet werden können.

Dieses neue Konzept erlaubt es, Änderungen innerhalb einer LCG einzuspielen, indem Änderungen nur auf der „maintenance“-Branch getätigt werden. Im Anschluss werden alle Änderungen (Delta) von der „maintenance“-Branch in die „produc-tive“-Branch gespielt.

Dieses Konzept stellt sicher, dass die „productive“-Branch stets das aktuelle Live-System darstellt, mit der Sicherheit, dass Änderungen am Live-System nicht möglich sind. Es ist schreibgeschützt und Änderungen können nur über die „maintenance“-Branch eingespielt wer-den. Die „maintenance“-Branch kann als Sammelbehälter für Releases gesehen werden, um diese in die „productive“-Branch zu transportieren. Die Anzahl an Branches ist nicht beschränkt. Durch weitere Branches lassen sich Ent-wicklungs- und Testumgebungen abbil-den.

Branches sind hierarchisch organisiert. Die „productive“-Branch steht an der Spitze. Eine Branch kann als Version der „productive“-Branch angesehen werden, welches den aktuellen Stand des Live Systems darstellt.

Für die Abbildung großer ERP- und Systemlandschaften, in denen mehrere Produktivsysteme existieren, z.B. bei internationalen Konzernen mit mehr-eren Produktionsstandorten, müssen Prozesse und Dokumente nicht doppelt erstellt werden. Die benötigten logi-schen Komponenten werden zu weiteren logischen Gruppen zusam-mengeschlossen, die die Anforder-ungen der jeweiligen Sites berück-sichtigen. Diese werden ebenfalls in denselben „maintenance“-Branches gepflegt. Die „maintenance“-Branch stellt das Delta dar – quasi eine neue zukünftige Version mit geplanten Releases.

Für die Abbildung großer ERP- und Systemlandschaften, in denen mehrere

Diese Funktionalität ist eng verknüpft mit dem Konzept der Branches. Dokumente werden den jeweiligen Prozessen zugeordnet. Gibt es eine Änderung im D-System innerhalb der Maintenance-Branch, wird dies im Changedokument erfasst und protokolliert. Werden die Änderungen innerhalb der Maintenance Branch in das Q-System transportiert und dort getestet und schließlich in das P-System in die „productiv“-Branch geladen, werden ebenso die zugehörigen Dokumente automatisch in die jeweilige Branch überführt.

Schlussfolgerung: Durch die Verzahnung des Change Prozesses mit der Lösungs-dokumentation kann das System dabei unterstützen, die Dokumentation aktuell und valide zu halten. Durch die zentrale Funktion, die Lösungsdokumentation einzelnen Sites zuzuordnen und damit lokale Anpassungen im System kenntlich zu machen, ist es möglich, gezielte lokale Besonderheiten eindeutig zu identifizieren und entsprechend die Dokumentation konsistent zu halten.

Change Control Prozess zum Ändern bestehender Funktionen und Prozesse dient.

Ziel eines Projektes ist es, die angestrebten Vorteile im Rahmen der vorgegebenen Zeit, Kosten, Budget und Risiken zu erreichen.

Die Verzahnung der Requirements mit dem Projekt erlaubt es, den Überblick über die zu erledigenden Anforderungen zu behalten. Das Testmanagement ist an das Projekt Management angeschlossen, wodurch ein direkter Bezug zwischen Testfall und Requirement hergestellt werden kann.

Schlussfolgerung: Anforderungen an einen Prozess oder an die Funktionalität können nun nicht mehr nur Dokumenten basiert erstellt und geführt werden, sondern direkt im Solution Manager 7.2 in einer Datenbank erstellt, überprüft und abgelegt werden. Die Verbindung einzelner Objekte mit Folgeobjekten wie Entwicklungsspezifikationen, Testfällen, Changes und Incidents, kann das System integriert unterstützen.

Produktivsysteme existieren, z.B. bei internationalen Konzernen mit mehreren Produktionsstandorten, müs-sen Prozesse und Dokumente nicht doppelt erstellt werden. Die benötigten logischen Komponenten werden zu weiteren logischen Gruppen zusam-mengeschlossen, die die Anforde-rungen der jeweiligen Sites berück-sichtigen. Diese werden ebenfalls in denselben„ maintenance“-Branches gepflegt. Hierbei ist zu beachten, dass der Solution Manager 7.2 die Funktion mitbringt, logische Gruppen einzelnen Sites zuzuordnen, wodurch die hinterlegten Änderungen einer Maintenance Branch jeweils nur für eine Site gelten oder aber für die globale Einheit. Diese Unterscheidung gilt auch in der „productive“-Branch. Dadurch ist es möglich, lokale Anpassungen nachvollziehbar zu implementieren und aufzeigen, was die lokalen Unterschiede sind.

Schlussfolgerung: Der saubere Aufbau der zu verwaltenden Landschaft ist die Voraussetzung für die reibungslose Arbeit der darauf aufbauenden Prozesse, mit denen die genannten Stärken des Solution Managers 7.2 genutzt werden können.

4. Auswirkungen

Um die beschriebenen Änderungen erfolgreich nutzen zu können, sind verschiedene Maßnahmen notwendig. Die Anpassung der logischen Komponenten innerhalb der Systemlandschaft ist erforderlich. Die enge Verzahnung zwischen der Systemarchitektur, der Verwaltung der Dokumentationen und des Change Controls benötigt eine solide Infrastruktur, die dem neuen Konzept von logischen Gruppen und die Nutzung der Branches genügt. Dieser Initialaufwand beim Migrieren von 7.1 auf 7.2 und der damit verbundenen Neuausrichtung der Konzepte und der Infrastruktur im Solution Manager zahlen sich später in der operativen Nutzung der Dokumentationsfunktion und dem Change Control aus.

Die Dokumentation von Prozessen bietet nun die Zuordnung zu einzelnen Sites. Dadurch lassen sich lokale Anpassungen genau identifizieren und für Fit-Gap Analysen nutzen. Die mit dem Change Control Prozess verknüpfte Funktion, neben der eigentlichen Änderung im System auch die zugehörige Dokumentation zu transportieren, erlaubt es, Mehraufwand zu reduzieren und gleichzeitig sicherzustellen, dass die Dokumentation valide bleibt.

Das im Solution Manager integrierte Requirement Management bietet eine im SAP Umfeld integrierte Möglichkeit, Anforderungen aufzunehmen, zu sammeln und in einen Change Prozess einfließen zu lassen. Die Anforderungen zu einem Prozess bleiben im System hinterlegt und sind mit diesem verbunden.

5. Zusammenfassung

Der Solution Manager in der Version 7.2 weist einige Neuerungen und Veränderungen auf. Einige ausgesuchte Änderungen betreffen die Verwaltung und Darstellung der Systemlandschaft, die in Branches und logische Gruppen aufgeteilt werden und durch ihre Überschneidung einen Gewinn an Flexibilität versprechen. Die Dokumentation der Prozesse erfolgt nicht mehr in der Solar-Welt, bleibt aber weiterhin den Prozessen zugeordnet. Bei einer Änderung im System wird die Änderung der Dokumentation automatisch berücksichtigt und auch transportiert. Die Erfassung Prozesse kann nun durch das integrierte Requirement Management erfolgen. Die Anforderungen können genehmigt und mit Changes verknüpft werden. Eine Betrachtung der ursprünglichen Anforderung gegenüber der Änderungen ist dadurch innerhalb des Solution Managers möglich.

Eine für die speziellen Anforderungen der Life Science optimierte Lösung stellt auch die Version 7.2 nicht dar. Es fehlt unter anderem an digitalen Signaturen und einer echten Versionierung der Dokumentation. Diese und weitere Gaps bedürfen weiterhin einer externen Lösung durch einen kompetenten Partner mit Erfahrung in den Prozessen der Life Science Industrie und den speziellen Anforderungen im regulierten Umfeld (21 CFR Part 11 und 820, etc.). Die Significon bietet mit ihrem Solution Package für den Solution Manager eine entsprechende Lösung an, die diese Gaps schließt und den Anforderungen des regulierten Umfelds genüge trägt. Sprechen Sie uns gerne an!