Anhand eines anschaulichen Praxisbeispiels verdeutlichen wir 3 konkrete Use Cases, die für die ALM Transformation hin zu integrierten IT Prozessen und einer integrierten Tool Chain zielführend sind.
Viele SAP-Fachabteilungen haben Bedenken vor automatisierten Tests und meinen, dass das Testen nur etwas für Programmierer ist. Aber das stimmt nicht! Jeder kann Tests durchführen und davon profitieren!
In unserem gemeinsamen Webinar mit Basis Technologies schaffen wir Vorurteile und Mythen zum Thema Testen aus der Welt und geben Klarheit darüber, wann und wo Tests erforderlich sind und wie man Tests effektiv durchführt.
Effektives Testen ist dabei immer mehr als nur technische Lösungen, sondern auch großteils die organisatorische Einbindung in Ihrem Unternehmen.
Auszüge der Folieninhalte des Webinars:
Schauen Sie sich dieses Webinar an und erfahren Sie mehr über:
In Teil 2 unserer Beitragsserie haben wir bereits die Synaworks Customer Journey und ihre drei Anknüpfungspunkte angesprochen. Lass uns hier nochmal einsteigen und das konkrete Leistungsportfolio beleuchten: Was machen wir als Synaworks eigentlich im Bereich ALM? Und was machen wir dabei anders als andere?
Wir konnten während eines SAP S/4HANA-Einführungsprojekts ein Chemiekonzern aus Köln mit einem Umsatz von 7,2 Mrd. € (2018) grundlegend zu den Teststufen beraten. Unser Beraterteam begleitete dabei das globale SAP S/4HANA Projektteam vom Integrationstest bis zum Abnahmetest. Als zentrale Test Management Plattform wurde der SAP Solution Manager 7.2 in Kombination mit dem standardisierten SAP Add-on Focused Build eingesetzt.
Durch den SAP Solution Manager konnte der komplette SAP Testprozess von der Testplanung über die Erstellung der Testfälle bis hin zu den abschließenden, prüfungsrelevanten Reports auf einer zentralen und integrativen Plattform abgedeckt werden.
Durch intuitive und rollenbasierte FIORI Applikationen wurde die Benutzerfreundlichkeit und Akzeptanz bei den Anwendern maßgeblich gefördert. Für positives Feedback sorgte insbesondere die gute technische Anbindung des SAP S/4HANA Entwicklungs- und Testsystems an den SAP Solution Manager. Die positiven Effekte bezüglich der Zusammenarbeit zwischen Entwicklern und Testern lösten dabei eine hohe Zufriedenheit im Projektteam aus.
Die von Entwicklern benötigten Transportaufträge konnten dadurch direkt auf Basis der von den Testern gemeldeten Fehlern erstellt und verwaltet werden. Zudem hatten die Verantwortlichen durch das im Rahmen von SAP Focused Build standardisierte Test Suite Dashboard zu jedem Zeitpunkt einen Gesamtüberblick über den aktuellen Teststatus sowie den Testfortschritts. Diese hohe Integration hat auch die Test Manager befähigt, eine verlässliche Rückverfolgbarkeit zwischen Fehlermeldung und Fehlerbehebung zu etablieren. Somit konnten auf Seiten der Tester, Testkoordinatoren und Entwickler Aufwände eingespart und die gesamte Testphase effizient durchgeführt werden.
Gerne beraten wir auch Sie, wie Sie durch ein standardisiertes SAP Test Management die Effizienz und Qualität in Ihrem S/4HANA Projekt und im Betrieb erhöhen können.
WWZ hat es zum Jahresstart 2021 geschafft: Mit dem neuen Jahr startete das Zuger Versorgungsunternehmen mit über 470 Mitarbeitenden in ihr erstes Jahr auf SAP S/4HANA. Synaworks durfte das Schweizer Unternehmen im SAP S/4HANA Projekt im Bereich Test Management begleiten und unterstützte bei einem risikominimierten Go-Live. Geknallt haben daher zum Glück nur noch die Silvesterböller. Mehr zum Projektverlauf und welche Erkenntnisse sich auch auf andere Branchen übertragen lassen, lesen Sie im Folgenden:
Testen ist ein wichtiger Teil jedes SAP Implementierungs- und Migrationsprojekts. WWZ hat sich bei ihrem SAP S/4HANA Transformationsprojekt für einen standardisierten und tool-gestützten Ansatz entschieden. Das Synaworks Team begleitete das Projekt vom Testkonzept und dessen Implementierung im SAP Solution Manager bis zur Befähigung und Begleitung der Projektorganisation, die für das Test Management verantwortlich ist. Der eingeführte Standard definiert, wie die erarbeiteten Inhalte und Testfälle auch zukünftig in wiederverwendbarer und strukturierter Form zur Verfügung stehen – denn nach dem Projekt ist immer vor dem (nächsten) Projekt.
Mit Synaworks die digitale Transformation erfolgreich gestalten.
Der SAP Solution Manager als Test Management Tool ist bei WWZ nicht neu. Infolge eines Releasewechsels auf die Version 7.2 mussten Einzelfunktionstestfälle jedoch zwischenzeitlich in Excel gesammelt werden. Die Testfälle wiesen starke Unterschiede in Qualität, Beschreibungstiefe und Aktualität auf. Daraufhin kam es bei der Testdurchführung stark auf die Verfügbarkeit, Erfahrung und Gewissenhaftigkeit einzelner Tester an. Zudem ergab eine Verwendungsanalyse der regelmäßig genutzten Transaktionen im SAP ERP System, dass viele der Top 100 Transaktionen nicht durch die Excel-Testfälle abgedeckt waren. Die geringe Testabdeckung führte zu zusätzlichen Herausforderungen. Ein standardisiertes und damit qualitativ hochwertiges SAP Test Management war unter diesen Umständen nicht möglich.
Für die SAP S/4HANA Einführung bestand daher Handlungsbedarf: „Ein Projekt dieser Größe verlangt nicht nur nach einer klaren Teststrategie, sondern auch nach qualitativ hochwertigen Fällen, die unabhängig und realistisch getestet werden. Für uns war ein klares und umfassendes Test Management absolut essentiell.“, erläutert Andreas Affeltranger, Test Manager des Projekts und IT-Mitarbeiter von WWZ. In den angesetzten 10 Testphasen im Rahmen des gesamten SAP S/4HANA Transformationsprojektes sollten außerdem erstmalig integrative Prozesse bis hin zu ganzen End-to-End-Szenarien getestet werden – ein ambitionierter Anspruch.
Pragmatisch und schnell ans Ziel kommen und dabei den Zeit- und Ressourcenaufwand für die beteiligten Teams so gering wie möglich halten – unter dieser Maßgabe starteten die Experten von WWZ und Synaworks in das gemeinsame Projekt.
Im ersten Schritt galt es, die Business-Prozessstruktur bei WWZ transparent zu machen. Dies geschah Bottom-Up über eine Verwendungsanalyse der genutzten SAP ERP Transaktionen aus den letzten 10 Monaten. In kurzen iterativen Schleifen mit den Fachbereichen wurden die miteinander in Verbindung stehenden Transaktionen erst zu Prozessen und dann Schritt für Schritt zu bereichsübergreifenden Prozessszenarien verknüpft. Das Projektteam identifizierte in kurzer Zeit mehr als 250 Prozesse für 16 Fachbereiche und dokumentierte sie in einer umfassenden Prozessstruktur.
Parallel dazu wurden grundlegende Rahmenbedingungen zum Testvorgehen in einem Testkonzept gesetzt und festgehalten. Daraufhin folgte die Implementierung der Test Suite mit den funktionalen Erweiterungen von SAP Focused Build im SAP Solution Manager.
An anderer Stelle arbeiteten die Experten von WWZ und Synaworks am Thema SAP ERP Schnittstellen: Alle Schnittstellen sollten klar den zugehörigen Prozessen zugeordnet sein und durch eigene Testfälle abgedeckt werden. Mittels halbautomatisierter Generierung von Testfällen auf Basis der Prozessstruktur konnte bereits ein Grundstock an essenziellen Testfällen geschaffen werden, die dann durch die Teams nur noch angereichert und priorisiert werden mussten – ein wichtiger Schritt, um risikooptimiertes Testen zu ermöglichen.
Vor Beginn der ersten integrativen Testphase wurden alle beteiligten Teams gemäß ihrer Rolle im Testprozess geschult. Im weiteren Prozess begleitete das Synaworks Team WWZ in der Rolle des Tool- und Methoden-Coachs durch das Projekt. Bereits während der folgenden Testphasen wurden außerdem End-to-End-Testszenarien aufgebaut und von cross-funktionalen Teams grafisch modelliert und im SAP Solution Manager dokumentiert.
Einem professionellen, tool-gestützten Test Management sowie der erstmaligen strukturierten Testdurchführung ganzer integrativer Prozesse und End-to-End-Szenarien folgte im Januar 2021 der erfolgreiche Go-Live von SAP S/4HANA bei WWZ. Die signifikant höhere Testabdeckung minimierte potenzielle Risiken für das Transformationsprojekt und ein Echtzeit-Reporting erleichterte die aktive Steuerung der Testphasen und die Nachverfolgung von Fehlern.
Juan Janse von der Innflow AG, Projektleiter des SAP S/4HANA Transformationsprojektes bei WWZ, ist zufrieden: „Synaworks für das SAP Test Management ins Boot zu holen war die richtige Entscheidung. Ihre fachliche Expertise kombiniert mit der methodischen Vorgehensweise und dem richtigen Blick für pragmatische Lösungsansätze war für uns sehr wertvoll. So konnten wir uns auf das Wesentliche konzentrieren – nämlich die SAP S/4HANA Transformation selbst.“
Das Projekt zeigt auch die großen Möglichkeiten, die sich über ein innovatives und ganzheitliches Application Lifecycle Management (ALM) erschließen können: Der Einführung von Change Impact Analysen (BPCA), SAP Testautomatisierung und einer weiteren Integration der ALM Prozesse Change- und Release Management stehen nun alle Türen offen. Nicht zuletzt ergab sich dadurch eine bessere Transparenz und eine Optimierung der Zusammenarbeit, indem die Unternehmens-IT und Business-Anwender den SAP Solution Manager als zentrale ALM Plattform gemeinsam nutzen.
1. Fachbereiche müssen die Hintergründe des Testprozesses verstehen.
Die Gründe für eine hohe Anzahl an Testphasen sowie der notwendige Ressourcen-Einsatz für den Aufbau der Prozessstruktur muss transparent kommuniziert und überzeugend erklärt werden, da es sich hierbei vielfach um zusätzliche Aufwände für alle Beteiligten handelt. Ein frühes Einbinden, eine Kommunikation in der „Sprache des Fachbereiches“, ein pragmatischer und zeitschonender Ansatz sowie viel Teamwork führten zu einer durchgehend hohen Akzeptanz.
2. Wiederverwendbarkeit der Testfälle ist ein Muss.
In Zeiten von immer schneller aufeinander folgenden SAP Releases und immer kürzerer Zeit zum Testen können Testfälle nicht mehr für jedes Projekt angepasst oder gar neu erstellt werden. Ein Konzept für die Wiederverwendbarkeit von Testfällen, das bestenfalls das Prozess- und Dokumentationsmanagement mit dem SAP Change- und Release Management verbindet, ist essenziell. So gehört die Aktualisierung der Dokumentation und der Testfälle zum kontinuierlichen ALM Prozess.
3. Usability und Transparenz lebe hoch!
Für das Projekt bei WWZ nutzte Synaworks den SAP Solution Manager und das Add-On SAP Focused Build. Die Akzeptanz und Usability des Test Step Designers in SAP Focused Build, welcher Excel-basierte Testfälle überflüssig macht, war durchgehend hoch. Der hohe Standardisierungsgrad der Lösung ermöglicht außerdem eine schnelle Einführung. Durch das Echtzeit Reporting mit dem SAP Test Suite Dashboard ist eine unkomplizierte Steuerung der Testphase und eine aktive Fehlerverfolgung umsetzbar.
4. End-to-End wird zur Normalität.
Testen in End-to-End Szenarien ab dem ersten Test fördert die Qualität der Testphase signifikant. Prozessübergänge und Schnittstellen sind besonders fehleranfällig, wohingegen die wertschöpfenden Prozesse eines Unternehmens häufig bereichsübergreifend organisiert sind. Wenn integratives End-to-End Testen von Beginn an Bestandteil der Teststrategie ist, kann hier viel Zeit und Geld gespart werden.
Seit dem Solution Manager 7.2 gibt es innerhalb der Lösungsdokumentation nicht mehr nur die eine „Version“ der Prozessstruktur und der dazugehörigen Objekte und Dokumente, sondern mehrere. Im Zuge dessen ist es möglich das Design der Prozesse, Dokumente etc. in einer separaten Umgebung durchzuführen, während die aktuelle produktive Version der Prozesse und Dokumentation jedoch geschützt bleibt.
Ähnlich zu Entwicklungen in einer SAP Systemlandschaft stellt sich dann die Frage, wie die Änderungen aus der Design in die Produktive Umgebung gelangen, im besten Fall synchronisiert zu der technischen Implementierung. Hier kann die „Change Control“ Option das Bindeglied zwischen der Lösungsdokumentation und Ihrem Change Control Management Prozess sein.
Bei den verschiedenen „Versionen“ der Lösungsdokumenten spricht man von sogenannten Branches. Mit der Analogie zu einer SAP Systemlandschaft lässt sich das Prinzip der Branches gut erklären. Hier werden verschiedene Tätigkeiten in den dafür vorgesehenen Branches durchgeführt – ähnlich wie in einem Entwicklungs- und Produktivsystem. Im Entwicklungssystem führt man die Anpassungen an Objekten durch. Sind sie final angepasst, werden die Änderungen in das produktive System überführt. Solange die neue Version noch nicht komplett abgeschlossen ist, ist im produktiven System die „alte“ Version noch immer aktiv.
Dieses Prinzip lässt sich über die Branches auch auf die Inhalte der Lösungsdokumentation übertragen. Hier spricht man dann beispielsweise von der sogenannten Maintenance Branch (entspricht dem „Entwicklungssystem“) und der Production Branch (entspricht dem „Produktivsystem“), in welcher sich keine Änderungen durchführen lassen. Verglichen mit der alten Business Blueprint aus den vorherigen Solution Manager Versionen ergibt sich folgender Vorteil: es lassen sich alle Inhalte in der Maintenance Branch anpassen, ohne dass die Änderungen direkt in der Production Branch sichtbar sind. In der Production Branch findet der Support beispielsweise immer die aktuell gültige Dokumentation zu den produktiv genutzten Prozessen.
Damit eine solche Umgebung funktioniert und die Stände aktuell gehalten werden, muss man sich – analog zum SAP Transportwesen – eine Vorgehensweise erarbeiten, wie die fertiggestellten Anpassungen am Ende in die Production Branch gelangen. Um Änderungen in die nächste Branch zu überführen, müssen sie manuell innerhalb der Lösungsdokumentation freigegeben werden.
In diesem manuellen Verfahren verliert man, insbesondere bei großen Organisationen und vielen Änderungen leicht den Überblick. Die Aktivierung der sogenannten Change Control Option schafft hier eine Erweiterung. Hiermit kann die Lösungsdokumentation in das Change Request Management eingebunden werden.
Wird die Change Control Option für eine Branch über die Lösungsverwaltung aktiviert, können innerhalb dieser Branch nur noch Änderungen im Rahmen der Lösungsdokumentation vorgenommen werden, nachdem ein entsprechendes Änderungsdokument (z.B. Normal, Urgent Change etc.) ausgewählt wurde. Das Änderungsdokument dient in diesen Fall als „Transportauftrag“, um die Änderungen kontrolliert in die Production Branch zu überführen.
Die Zuordnung zu einem Änderungsdokument lässt sich dann entweder direkt aus der Lösungsdokumentation oder im Änderungsdokument (im Reiter Lösungsdokumentation) durchführen. Im Änderungsdokument sind später entsprechende Aktionen und Prüfungen integriert, welche die Änderungen beim Live-setzen automatisch in die Production Branch „transportieren“.
So lassen sich neben den technischen Anpassungen – sprich Transporte, die im Änderungsdokument enthalten sind – auch die Dokumentenänderungen und strukturellen Änderungen in der Lösungsdokumentation gemeinsam transferieren. Auf diese Weise wird sichergestellt, dass sowohl die Anpassung eines Objektes, als auch die zugehörige Dokumentation sauber in der jeweiligen produktiven Umgebung ankommen.
Auch in kundeneigenen ChaRM-Vorgangsarten können die Aktivitäten mit aufgenommen werden, wenn sie nicht ohnehin bereits aus dem SAP Standard Vorgangsarten überführt wurden. An dieser Stelle ist es im Übrigen auch möglich den Zeitpunkt anzupassen, beispielsweise wann ein Dokument in die Production Branch überführt werden soll.
Man muss sich bewusst sein, dass nach der Aktivierung der Change Control für jede Änderung, in der spezifischen Branch, ein Änderungsdokument notwendig ist. Beispielsweise auch für die Freigabe von Dokumenten – das entspricht einer Statusänderung oder der Anpassung von Testfällen. Die Change Control ist nicht auf verschiedene Objekttypen einzuschränken, sondern ist für alle Elemente gültig. Falls reine Änderungen an der Lösungsdokumentation übertragen werden sollen, macht es im folgenden Schritt Sinn eine Vorgangsart im ChaRM ohne Transportanbindung einzurichten – wie etwa den General oder Admin Change.
Darüber hinaus ist eine Rollenzuweisung (Partnerfunktion) im zugehörigen Änderungsdokument zwingend notwendig. Nur so steht das Änderungsdokument in der Branch auch zur Verfügung. Hier lässt sich wieder die Analogie zum Transportauftrag herstellen: nur wer dort als Mitarbeiter hinterlegt ist, kann auch dem Transport bzw. der Aufgabe Änderungen zuordnen.
Zuletzt sollte nicht unerwähnt bleiben, dass die Aktivierung bzw. Deaktivierung der Change Control nur möglich ist, wenn alle Änderungen aus dieser spezifischen Branch in die Production Branch überführt wurden. Das bedeutet, dass beispielsweise die Maintenance und Production Branch den gleichen Stand benötigen.
Mit der Change Control Option bietet die SAP eine sinnvolle Integration für die Änderungskontrolle innerhalb der Lösungsdokumentation in das Change Request Management. Hierdurch kann sichergestellt werden, dass sowohl technische Änderungen als auch die dazugehörige Dokumentation gemeinsam live gesetzt werden und so auch keine Inhalte in der Maintenance Branch „vergessen“ werden.
Speziell in großen Organisationen ist es kaum möglich ohne Change Control die Aktualität der Dokumente zu gewährleisten. Ohne die Funktion ist hier mit alten, inkonsistenten Ständen von Prozessen und Dokumentationen zu kämpfen, welche nie dem produktiven Stand entsprechen – oder sich nur schwer eindeutig identifizieren lassen. Genau hier setzt die Change Control an, um die sonst aufwändige, manuelle Organisation, durch einen Automatismus zu unterstützen.
Wenn Sie bereits mit dem Change Request Management arbeiten und die Dokumentation mit in diesen Prozess aufnehmen wollen, empfehlen wir Ihnen einen Blick auf die Funktion zu werfen. Die zuvor genannten Konsequenzen ergeben sich aus dem dann strengeren Prozess, durch welchen Sie jedoch im Endeffekt mehr Sicherheit und Konsistenz über Ihre Dokumentation erlangen.
Wir beraten und begleiten Sie bei der Konzeption, Implementierung und Umsetzung einer ALM Plattform – auf prozessualer, technischer und organisationaler Ebene und erarbeiten mit Ihnen gemeinsam die beste Strategie, wie die Funktionen in Ihrer aktuellen Situation bestmöglich eingesetzt werden können.
Wenn Sie sich einen ersten Überblick verschaffen wollen, dann empfehlen wir Ihnen unsere Synaworks Academy Trainings „Application Lifecycle Management mit SAP Solution Manager 7.2 für SAP S/4HANA“ .
Natürlich stehen wir Ihnen als Beratung jederzeit zur Verfügung. Wir sind gespannt und freuen uns sehr auf Ihre Kontaktaufnahme!
