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.
