Fallstudie: S/4HANA als private Cloud Plattform einführen

Problemstellung

In dieser Fallstudie zeigen wir Ihnen wie man S/4HANA als private Cloud Plattform in globalen Pharma- und Medizintechnikunternehmen einführen kann.

Der Kunde ist ein international tätiges Pharma- und Medizintechnikunternehmen. Im Rahmen der Globalisierung besteht die Herausforderung, dass Prozesse nicht weltweit harmonisiert sind und diese auch nicht systemgestützt gemessen, konsolidiert und berichtet werden können. Es besteht eine fragmentierte IT-Landschaft mit verschiedensten Systemen, die Prozesse auch nur teilweise und mit Medienbrüchen unterstützen. Vor Einsatz von QFINITY beim Kunden wurde durch eine andere Beratungsfirma eine Methode etabliert, die für die Projektmitglieder jedoch nicht klar war, bisher keine belastbaren Ergebnisse erzeugt hat, Termine nicht eingehalten wurden und auch die Umsetzung nicht einheitlich erfolgt ist.

Im Rahmen der Globalisierung sollen daher

  • S/4HANA als Private Cloud Plattform eingeführt werden
  • Eine einheitliche Methode für Projekt und Validierung definiert werden
  • Ein Template Ansatz mit zentralen Prozessverantwortlichen etabliert werden
  • Die Systemlandschaft vereinheitlicht werden
  • Ein Roll-Out Konzept und die Planung der weltweiten Roll-Outs erfolgen
  • Zentrale Prozesse für z.B. Change Management und Benutzer- und Berechtigungsverwaltung durch Einführung von SAP Standardsystem wie SAP Solution Manager und SAP GRC (Governance, Risk, and Compliance) systemtechnisch unterstützt und standardisiert werden
  • SOX (Sarbanes-Oxley-Act) Vorgaben mit als Bestandteil der Standardmethode integriert werden
Q-FINITY GxP Qualitätsmanagement

Projektausführung

Validierung und Methodik

Damit S/4HANA als Private Cloud Plattform eingeführt werden kann wurde zunächst mit dem Validierungsteam basierend auf vorhandenen Dokumenten und der generellen Methode zur Validierung computergestützter Systeme des Kunden ein Vorgehen konform zu diesem definiert und gemeinsam im Detail besprochen. Der geänderte Ansatz war dabei stark optimiert, um zum einem den Ansatz zu einem weltweiten Template zu genügen und die Spezifika von SAP bzw. eines komplexen, globalen Systems zu berücksichtigen. Für zentrale Themen wie Change Management oder Benutzer- und Berechtigungsverwaltung, aber auch die Handhabung von Audit Trail Reviews, die Konfiguration und Entwicklung oder die Datenmigrationsstrategie wurden eigene Anweisungen definiert. Zugleich wurde der Ansatz auch so definiert, dass die spezifischen Aspekte von parallelen Roll-Out Projekten und bereits parallelen Standorten, z.B. im Vorgehen für Projekt Change Requests oder für Regressionstests für Live Sites berücksichtigt wurden.

Bestandteil der Methodik sind neben den Aspekten zur Validierung der Einschluss von Projektmanagement und generellen Anforderungen an das Unternehmen, wie z.B. SOX-Anforderungen, um auch Finanzbehörden zu genügen, ohne neben der Validierungsdokumentation weitere nicht integrierte Dokumentation zu erzeugen. So wurde u.a. auch ein Quality Gate Ansatz und das Vorgehen zum Tracking des Status von allen zu liefernden Projektergebnissen etabliert.

Da auch die bisherigen Templates stark redundant waren und eher für die Einführung einfacher System geeignet, mussten diese vereinfacht und die Redundanzen durch zentrale Dokumente ersetzt werden.

Mit der Definition der Methode wurden die Projektmitglieder dann in der Methode geschult und werden fortlaufend gecoached.

Fokussierung auf dem Business Aspekt bei der Dokumentation

Bei der Definition der Design-Dokumentation wurde besonderen Wert auf die Ausrichtung auf das Business wert gelegt. Dies spiegelt sich v.a. bei der Definition der verschiedenen Konfigurationselemente von SAP wider, da diese nun verstanden werden können und zugleich auch die Rationale für deren Konfiguration verständlich ist. Hierzu wurden die Definitionen des Template klar gegen erlaubte Lokalisierungen abgetrennt, so auch in der Verwendung von entsprechenden Namensräumen zu deren Abtrennung. Der Fokus auf die Anforderungen des Business findet sich auch in der Teststrategie, da der Test der Benutzeranforderungen verbunden mit dem Test potentieller Risiken im Vordergrund steht. Bestandteil sind hier auch Integrationstests, die sicherstellen, dass Geschäftsprozess End-to-End funktionieren und zugleich auch die tagtäglichen Prozesse widerspiegeln. Auch bilden sie wiederum die Basis für die Regressionstests und vereinfachen damit auch die Testung künftiger Releases.

Q-FINITY hat hier v.a. bzgl. des Reviews der Inhalte unterstützt, um so ein Coaching hin zu einer sinnvollen, nicht den Standard von SAP sondern die Spezifika des Kunden definierenden klaren Dokumentation des Designs zu erreichen. Mit diesen definierten Kundenspezifika können dann sinnvolle und relevante Benutzeranforderungen definiert werden und Tests somit auf die konfigurierten Prozesse und nicht auf den SAP Standard fokussiert werden.

Einführung von SAP Tools und Validierung des Basis-Systems

Da das Unternehmen noch stark Dokumenten-orientiert war, wurde auch durch Q-FINITY der Vorteil der Einführung eines elektronischen Change Managements aufgezeigt und somit auch die Einführung des SAP Solution Manager ChaRM Prozesses mit Nutzung von elektronischen Unterschriften in den Projekt Scope mit aufgenommen. Q-FINITY definiert hier mit dem technischen SAP Implementierer den Prozess im SAP Solution Manager, um unter Wahrung der regulatorischen Anforderungen den Prozess trotzdem so schlank und anwenderfreundlich als möglich zu gestalten.

Um auch die Aspekte um SOX zu unterstützen, wird im Projekt das SAP GRC (Governance, Risk, and Compliance) eingeführt, welches die Prüfung von Rollen und Benutzern bzgl. Sensitive Access and Segregation of Duties (SoD) erlaubt. Zudem werden auch entsprechenden technische Kontrollen mit implementiert.

Neben diesen spezifischen Tools müssen auch zusätzlich das SAP PO (Process Orchestration) zum Management von Schnittstellen und SAP BW/4HANA (Business Warehouse zum Reporting) als Bestandteil der S/4HANA Systemlandschaft validiert werden, bevor die eigentlichen Geschäftsprozesse in S/4HANA eingeführt werden können. Um dies einheitlich zu Prozessen in Finanzen, Supply Chain Management, Produktion oder Stammdatenmanagement zu handhaben, wurde eine übergreifende Geschäftsprozessliste (Business Process Master List) definiert, die alle Prozesse der Systemlandschaft berücksichtigt, d.h. auch Prozesse wie das Change Request Management oder die Access Risk Analysis (ARA) in SAP GRC. Sie ist die Basis für eine GxP Bewertung der Prozesse und die Definition der Prozesseignerschaft für die verschiedenen Geschäftsprozesse im Unternehmen.

Ergebnis und Nutzen

Bis zum bisherigen Projektstand konnten die Methode vereinheitlicht und deutlich gegenüber dem bisher geplanten Vorgehen vereinfacht werden. Das Projektteam ist geschult und wird fortlaufend gecoached. Während das Template weiter definiert und mit Unterstützung von Q-FINITY in den nächsten Jahren weltweit ausgerollt wird, erfolgt die Validierung des Basissystems. Die Prozesse in den unterstützenden Tools sind definiert und werden weiter zusammen mit Q-FINITY umgesetzt.

Das Projektteam hat schon den Nutzen der klar definierten und einfachen Dokumentation erkannt und arbeitet gemäß den Vorgaben der Projektmethodik. Durch den definierten Zeitplan kann damit das Basissystem in kurzer Zeit validiert werden.

In der Diskussion unter anderen mit den Validierungsverantwortlichen des noch in EMEA im Einsatz befindlichen SAP Altsystems, wurde der innovative und effiziente Charakter der Validierungsmethodik erkannt und soll voraussichtlich auch für diese noch bis zur Systemablösung genutzt werden. Durch sie werden Ressourcen auf die wesentlichen Punkte fokussiert und unnötige Dokumentation und unnötig komplizierte Prozesse vermieden.

Können wir auch Ihnen helfen S/4HANA als Private Cloud Plattform einzuführen? Oder benötigen Sie Hilfe in einem unserer anderen Gebiete? Dann kontaktieren Sie uns hier!

Q_FINITY KONTAKT


    *Pflichtfelder