In unserer Blogserie „How to ALM “ (HTALM) geht es diesmal um die Möglichkeiten, die ALM-Prozesse direkt in SAP Cloud ALM (CALM) zu modellieren und damit zu dokumentieren. Wir zeigen, wie man die vordefinierten ALM-Best Practice Flows in SAP Cloud ALM “aktivieren” und anschliessend anpassen kann.
❓ Warum ALM-Prozesse in SAP Cloud ALM dokumentieren?
Die vordefinierten Best Practices in SAP Cloud ALM geben bereits eine klare Struktur für Onboarding, Projekt-Setup, Build, Test und Deployment. Dennoch hat jede Organisation individuelle Anforderungen an die IT-Prozesse, die es notwendig machen, die Prozesse anzupassen. Und jetzt kommt das Beste: Man kann die Best Practice Prozesse direkt in SAP Cloud ALM BPMN-Modeler anpassen und dokumentieren.
⚽️ ALM Kick-start Modelling
SAP Cloud ALM kommt mit detaillierten BPMN-Prozessdiagrammen für die folgenden Bereiche:
Onboarding
Projektsetup
Fit-to-Standard
Build
Test
Deployment
Fix & Enhance
Wie können wir diese nun aktivieren und anpassen? Ich mache ein Beispiel für den Fix & Enhance Prozess. Dieser Prozess zeigt, wie Lösungen iterativ – meistens in der sogenannten Wartung/Maintenance-Phase, die nach der Projektphase kommt – verbessert und erweitert werden können. Vielleicht will man in diesem Fix & Enhance-Prozess die Integration von Incidents und Changes als Ausgangspunkt von einem anderen Tool in SAP Cloud ALM mit einem Feature integrieren und nicht mit einem Requirement, wie im Best Practice-Flow vorgesehen.
Wichtig: Ich spreche hier bewusst nicht von einer Operations/Betrieb-“Phase”, sondern von einer Wartung/Maintenance-“Phase”, denn die Funktionen für die Operations/Betrieb sind in SAP Cloud ALM für die Überwachungsbereich belegt.
Schritt 1: Neuen Scope für das Lösungsszenarios “Tools und Technologie” innerhalb eines Projektes anlegen
Schritt 2: Lösungsprozesse des Lösungsszenarios in den Scope aufnehmen (via Toggle Switch)
Das Ergebnis lässt sich anschliessend direkt schon ansehen, da der Lösungswertefluss sowie die Lösungsprozessdiagramme ersichtlich sind
Schritt 3: Eine Kopie des Lösungsprozesss erstellen
Schritt 5: Die kopierten Diagramme können nun an die Gegebenheiten des Unternehmens angepasst werden, gespeichert und “published” werden
💎Warum das Ganze?
Dank der visualisierten Rollen und Aktivitäten verstehen alle Beteiligten den Ablauf. Wir schaffen Transparenz und sind effizient, da wir kein weiteres Tool brauchen und auf den Best Pratices aufbauen können.
Letztendlich hilft dies extrem, um auch komplexeren Prozessen folgen zu können und das nichts vergessen geht.
Neben der Sicherstellung eines gemeinsamen Verständnis, sind die Prozessflows natürlich eine super Ausgangslage um die Testfälle zu erstellen. Und: Bessere Testfälle sollten zu mehr Effizienz für das Testing, bessere Qualität und somit zu einem stabileren Produktivsystem führen.
➡️ Und ein letzter Tipp
Nutzt die ersten Erfahrungen mit BPMN für die ALM Prozesse, um auch die Geschäftsprozesse in der gleichen Form zu dokumentieren. So werden einheitliche Standards geschaffen, die Transparenz erzeugen und die Zusammenarbeit zwischen IT und Fachbereichen fördert.
Mit den integrierten Tools und Best Practices in SAP Cloud ALM wird ALM-Prozessmanagement nicht nur effizient, sondern auch intuitiv.
Viele von uns erfreuen sich wohl an einem frisch gebackenen Donut. Dabei denken wir nicht nur an den köstlichen Geschmack, sondern auch an die Form – einen Ring. Und obwohl man reflexartig nun denken könnte, dass sich der vorliegende Artikel mit der Analogie der äusseren Form eines Donuts und dem Application Lifecycle Management-Ring befasst, gehe ich nicht darauf ein, sondern auf den Unterschied von Plan- und Value-Driven Development und deren Problematik.
Besonders spannend ist dabei die Frage, warum in SAP Cloud ALM bestimmte Features immer noch fehlen. Viele Kunden stellen genau diese Frage: Warum ist das oder jenes Feature noch immer nicht verfügbar? Ich möchte SAP dabei nicht in Schutz nehmen, denn man könnte sicher argumentieren, dass mit mehr oder schnelleren Entwicklerressourcen manches schneller umgesetzt werden könnte. Aber vielmehr geht es mir darum, ein Verständnis für die Herausforderungen zu schaffen: Wie balanciert man den Druck der Kundenerwartungen mit der langfristigen Vision und der Qualitätssicherung? Genau hier zeigt sich die Schwierigkeit, in einem plangetriebenen Ansatz sowohl Stabilität als auch Flexibilität zu vereinen, um Werte zu liefern, die nachhaltig Bestand haben.
Von SAP SolMan zu SAP Cloud ALM
Der SAP Solution Manager (oder von der Community auch liebevoll SolMan genannt) wird Ende 2027 aus der Mainstream Wartung fallen. Zwar ist SAP Cloud ALM kein direkter Nachfolger des SAP Solution Managers, da es keine Featureparität geben wird, aber es ist zumindest der logische Nachfolger.
Und genau hier, an diesem Punkt, entsteht der Zusammenhang von einem Donut zu SAP Cloud ALM. Das fast jeder weiss, dass der Donut ringförmig ist, haben wir bereits geklärt. Viele von Ihnen wissen auch, wie ein guter Donut schmecken sollte. Und die SAP-Kunden wissen, wie der SAP Solution Manager aussieht und was er für ALM-Funktionen bietet. Es liegt also auf der Hand, dass man genau diese Funktionen auch für dem «Nachfolgprodukt» erwartet.
Der Solution Manager, kann also mit einem altbekannten Donut-Rezept verglichen werden. Ein Rezept und eine Zubereitung, bei dem wir genau wissen, welche Zutaten hineingehören und welches Endergebnis wir erwarten können. Es ist gar ein bewährtes Rezept, das von vielen geliebt wird.
Die Entwicklung SAP Cloud ALM hingegen stellt nun ein ganz neues Rezept und Vorgehensweise dar. Dieses wird nicht mehr schlicht nach Plan (plan-driven) entwickelt, bei dem das Endprodukt- und dessen Features von Anfang an feststehen. Vielmehr handelt es sich um eine value-driven Herangehensweise, bei der der Wert und Nutzen für den Kunden im Vordergrund stehen.
Value-Driven vs. Plan-Driven Development: Ein Rezeptduell
Das Verständnis der Unterschiede zwischen Value-Driven und Plan-Driven Development ist wichtig, um die Vorzüge und Herausforderungen zu erkennen. Hier ein Vergleich:
Plan-Driven Development (PDD)
PDD basiert auf einem systematischen und sequenziellen Ansatz, bei dem jede Phase (Anforderungen, Design, Implementation, Validierung) der Softwareentwicklung streng geplant wird, bevor sie tatsächlich beginnt. Der Leistungsumfang ist fix, die Kosten und die Termine «variabel» bzw. die Stellschrauben, an denen gedreht werden kann.
Planung: Das Hauptaugenmerk liegt auf der Vorabplanung. Es wird erwartet, dass alle Anforderungen zu Beginn des Projekts festgelegt werden und sich im Verlauf des Projekts nur wenig oder gar nicht ändern.
Dokumentation: PDD betont die Wichtigkeit umfassender Dokumentationen. Jeder Schritt wird ausführlich dokumentiert, um sicherzustellen, dass alle Beteiligten den Ablauf und die Anforderungen genau verstehen.
Flexibilität: PDD ist in der Regel weniger flexibel in Bezug auf Änderungen, da Änderungen oft kostspielig und zeitaufwendig sind, besonders wenn sie spät im Prozess vorgenommen werden.
Risikomanagement: PDD versucht, Risiken frühzeitig zu minimieren, indem alles vorab geplant wird.
Beispiele für Methoden: Wasserfallmodell, V-Modell.
Value-Driven Development (VDD)
VDD fokussiert sich darauf, kontinuierlichen Wert für den Kunden oder den Endbenutzer zu schaffen, indem auf Feedback und iterative Entwicklung gesetzt wird. Bei diesem Vorgehen sind die Kosten und Termine «fix» und der Leistungsumfang variabel. Ein gutes, agiles Requirementsengineerung ist für VDD ein Muss.
Planung: Anstatt sich streng an einen festgelegten Plan zu halten, passt VDD sich flexibel an neue Informationen oder geänderte Kundenbedürfnisse an.
Dokumentation: Während Dokumentation immer noch wichtig ist, kann sie in VDD weniger umfangreich sein als in PDD. Der Schwerpunkt liegt auf funktionsfähiger Software und Kundenfeedback.
Flexibilität: VDD ist in Bezug auf Änderungen sehr flexibel, da der Ansatz erwartet, dass Anforderungen sich im Laufe der Zeit ändern können.
Risikomanagement: VDD akzeptiert, dass Risiken bestehen, setzt aber darauf, sie durch regelmäßige Feedbackschleifen und Anpassungen zu minimieren.
Beispiele für Methoden: Agile Entwicklungsmethoden wie Scrum und Kanban
Plan-driven Development: So vertraut wie ein Zuckerguss-Donut oder ein SAP Solution Manager
Vor einigen Jahren wurde der SAP Solution Manager entwickelt. Eine Plattform, für die Implementierung und dem Betrieb von SAP-Lösungen (vor allem für on-Premise Produkte). Das Rezept ist fest, die Zutaten sind bekannt, und das Ergebnis ist vorhersehbar, d.h. das Prinzip bei der Entwicklung des SolMan war weitestgehend der systematische Ansatz des «Plan-Driven Development». Ähnlich einem Architekten, der jedes Detail plant, bevor der eigentliche Bau beginnt.
Die Herausforderung des Wandels: SAP Cloud ALM
Stellen Sie sich also vor, Sie stehen in einer modernen Donut-Bäckerei. Anstatt nur einen festgelegten Donut zu backen, experimentiert der Bäcker mit verschiedenen Zutaten. Er bringt Ihnen zuerst den nackten Donutring, das Grundgerüst – sozusagen ein Minimum Viable Product (MVP). Für manche ist dies bereits ausreichend, andere warten auf die Glasur, wieder andere auf die Streusel und aufgrund des Feedbacks kann der Bäcker nach und nach (in mehreren Iterationen) den Donut verfeinern. Wieder andere geben Feedback und verlangen nach einer bestimmten Füllung. Welcher Weg ist nun der richtige?
Die Entwicklung von SAP Cloud ALM erinnert an den Trend von experimentellen Donut-Geschmacksrichtungen. Zwar wurde SAP Cloud ALM auch für Implementierung und dem Betrieb von SAP-Lösungen entwickelt, aber mit einem deutlicheren Fokus: Für SAP Cloud Produkte.
Die agile Entwicklung bei SAP Cloud ALM ist nun, als würde der Bäcker alle zwei Wochen vorbeischauen und sagen: «Testen Sie das mal!». Aber statt eines vollständigen Donuts gibt es vielleicht nur einen Bissen. Einige Kunden sind begeistert von der schnellen Lieferung und der Möglichkeit, Feedback zu geben. Andere sind vielleicht enttäuscht, dass der Donut noch nicht «fertig» ist.
Eine Geschmackswelt, die sich ständig verändert
So wie die Welt der Donuts sich ständig weiterentwickelt – denken Sie nur an Trends wie Cronuts oder Donut-Burger – so verändert sich auch die unsere Welt der Informationssysteme und der allgemeinen Rahmenbedingungen. Das Wichtigste ist, dass wir bereit sind, uns anzupassen, Feedback zu geben und offen für die unzähligen Möglichkeiten zu sein, die vor uns liegen.
Das value-driven Development erfordert Flexibilität und Offenheit für Veränderungen. Und während einige Kunden die Chance schätzen, ihre eigenen «Donuts» zu gestalten, finden es andere herausfordernd, sich ständig an neue Geschmacksrichtungen anzupassen.
Es braucht einen «Shift in Mindset» auf zumindest dreierlei Weise:
Entwicklerteams müssen sich so anpassen, damit sie in die in der Lage sind, ein Produkt tatsächlich agil zu entwickeln
Kunden müssen die Bereitschaft und Akzeptanz entwickeln, dass nicht jede Funktion bereits 100% Mehrwert bringt, dafür aber Teilfunktionen schneller nutzbar sind und zumindest einen Teil-Mehrwert bringen
Kunden müssen sich auf eine Reise begeben und Funktionen nicht nur fordern, weil sie es «halt schon immer so gemacht haben», sondern hinterfragen, ob alternative Herangehensweisen einen noch grösseren Nutzen bringen könnten
In einer sich ständig verändernden (digitalen) Welt sollten wir vielleicht alle ein wenig mehr die Werte von Donut-Liebhabern übernehmen: Neugierde, Flexibilität, Geduld und die Offenheit für einen potenziell nächst besseren und süssen Bissen der Donutinnovation – auch wenn einem der ein oder andere Versuch mal nicht so gut schmeckt 🍩
Willkommen zur neuesten Ausgabe unserer zweiwöchentlichen SAP Cloud ALM Update-Serie! Alle zwei Wochen stellen wir Ihnen die neuesten Innovationen, Leistungsverbesserungen und Schnittstellenerweiterungen vor, die Ihr Cloud ALM-Erlebnis verbessern. In dieser Ausgabe befassen wir uns mit den spannenden Updates, die in Woche 48 eingeführt wurden. Bleiben Sie dran, um einen genaueren Blick auf die Neuerungen zu werfen!
Services
Im «Problem- und Aktionsmanagement» werden Probleme und eigenständige Aktionen jetzt auf der Grundlage der SAP-Kategorie und nicht mehr nach dem Problemtyp kategorisiert. Jetzt ist es möglich, die Issues und Standalone-Aktionen nach SAP-Kategorie zu filtern.
Implementation
Unter «Prozesse» ist es jetzt möglich, dasselbe Dokument mehrfach unterschiedlichen Entitäten eines Lösungsprozesses innerhalb des Kontexts eines Projekts und Umfangs zuzuordnen. Zum Beispiel ist es möglich, dasselbe Dokument einer Lane und einer Lösungsaktivität innerhalb desselben Lösungsprozessablaufs zuzuordnen.
Beachten Sie, dass ein Dokument immer nur einmal einer bestimmten Entität zugeordnet werden kann (z. B. kann dasselbe Dokument nicht zweimal derselben Lösungsaktivität im Kontext eines Projekts, Umfangs, Lösungsszenarios, Lösungsprozesses, Lösungsprozessablaufs oder Lösungsprozessablaufdiagramms zugeordnet werden).
Bei der Auswahl des gesamten Diagramms (durch Klicken ausserhalb seiner Grenzen) werden nur die Dokumente angezeigt, die dem Diagramm direkt zugeordnet sind nicht denen innerhalb der enthaltenen Entitäten. Das Gleiche gilt für Anforderungen, User Stories oder Aufgaben. Eine Übersicht über solche Zuordnungen finden Sie in der App «Solution Process Traceability».
Die Übersichts-App bietet nun die Möglichkeit, nach Release zu filtern. Durch die Verwendung des Filters werden die Daten für die Aufgaben, Anforderungen, Merkmale und Defect-Verteilung aktualisiert.
In der projektübergreifenden Übersicht gibt es in der App «Prozesshierarchiezuordnung» jetzt eine neue Spalte für die Defects.
«Analytics» hat einen neuen Filter Testplan in der App «Defect Reporting» eingeführt. Jetzt werden alle Registerkarten entsprechend gefiltert, wobei die Registerkarte Defekt-Verteilung auch eine Auswahl nach Testplan für Defects bietet.
Operations
Synthetic User Monitoring hat jetzt den Verfügbarkeitsstatus verbessert.
Falls Ausführungen aufgrund von Überwachungsproblemen (z. B. Infrastrukturprobleme, schlecht geformte Skripte oder interne Fehler) fehlschlagen, wird die Verfügbarkeit für diese Ausführungen nun nicht mehr bewertet.
In der Benutzeroberfläche werden sie nicht wie folgt behandelt:
Auf der Startseite werden sie nicht für die angezeigten Status in den Übersichtskacheln gezählt. Wenn die letzte Ausführung aufgrund eines Überwachungsproblems fehlgeschlagen ist, wird das Symbol für die letzte Verfügbarkeit in Blau angezeigt.
In den Ausführungen werden sie in blau mit der Information Verfügbarkeit nicht bewertet angezeigt.
Es wird kein Ereignis erzeugt, wenn die Ausführung aufgrund von Überwachungsproblemen fehlschlägt.
Integration & Exception Monitoring hat 2 neue Funktionen zur Verfügung.
Es wird ein neuer Ereignistyp, «Probleme entdeckt», eingeführt. Dieser Ereignistyp ermöglicht die Konfiguration von Ereignissen auf der Grundlage von status group, Status direction oder einem anderen für die Nachrichtenkategorie verfügbaren Filterparameter.
So ist es beispielsweise möglich, Ereignisse für Warnmeldungen von einer bestimmten Schnittstelle einzurichten, indem die Parameter Status und Senderschnittstelle angegeben werden.
Die Ereignisbedingungen werden im Abschnitt Filter der Ereigniseinstellungen definiert. Standardmässig sind ERROR und WARNING für den Parameter Status Group ausgewählt.
Eine neue Version der Raw Data Outbound Logs API ist jetzt für Integration & Exception Monitoring verfügbar. Diese Version verwendet eine neue Nutzdatenstruktur, die die Nachrichtenverarbeitung für offene Telemetrie vereinfacht.
Administration
Das Landscape Management hatte Verbesserungen bei der Zugangskontrolle.
Auf der Detailseite eines Business Service werden die zugeordneten Services und Systeme angezeigt. Diese Namen verweisen nun nur noch auf die entsprechende Detailseite, wenn der Benutzer über die Zugriffskontrolle Zugriff auf die Komponente hat.
Auf der Detailseite einer verwalteten Komponente werden die Business Services dieser Komponente angezeigt. Dort werden nur die Business-Services aufgelistet, auf die Benutzer aufgrund der Zugriffskontrolle Zugriff haben.
Landscape Management hat auch eine neue Funktion eingeführt, die Business Units.
Es ist nun möglich, Geschäftseinheiten als zusätzliches Gruppierungskriterium für verwaltete Komponenten zu verwenden, um einen besseren Überblick über Systeme und Dienste zu erhalten. Es ist möglich, einem System oder Service eine oder mehrere Business Units zuzuordnen. Benutzer mit der Rolle Landschaftssicherheitsadministrator können Geschäftseinheiten im Konfigurationsabschnitt Kundengeschäftseinheiten erstellen, bearbeiten und löschen.
Diese Funktion ist besonders nützlich für einen besseren Überblick, wenn eine grosse Anzahl von Systemen und Diensten unter derselben Kundennummer läuft. Je nachdem, welches Gruppierungskriterium für die Gruppierung der verwalteten Komponenten am hilfreichsten ist, ist es auch möglich, beliebige andere Werte wie Abteilungen, Marken oder Standorte anzugeben.
Nach der Erstellung kann die Liste der Dienste und Systeme nach jeder Geschäftseinheit gefiltert werden; ausserdem werden die einer Dienstleistung oder einem System zugeordneten Geschäftseinheiten in den entsprechenden Details angezeigt.
In der heutigen digitalen Landschaft ist das Verständnis, wie Benutzer mit Anwendungen interagieren, von entscheidender Bedeutung, um die Leistung zu verbessern und die Benutzererfahrung zu steigern. Für Unternehmen, die SAP-Systeme nutzen, bietet Real User Monitoring innerhalb von SAP Cloud ALM for Operations aussagekräftige Einblicke in das Verhalten, die Leistung und die Nutzungsmuster von Endanwendern, unabhängig davon, ob diese auf Anwendungen in der Cloud oder vor Ort zugreifen.
Dieses Tool ist besonders wertvoll für IT- und Geschäftsanwender, die die Anwendungsleistung optimieren und die Benutzerzufriedenheit steigern wollen.
Es ermöglicht Unternehmen die Verfolgung und Analyse von Benutzeranfragen innerhalb verwalteter SAP-Umgebungen, wo es Benutzerinteraktionen überwacht und aufzeichnet und Daten über Leistung, Antwortzeiten und die allgemeine Anwendungsnutzung erfasst. Durch das Sammeln dieser Informationen bietet Real User Monitoring einen Einblick in die Benutzererfahrung und zeigt, wie häufig auf Anwendungen zugegriffen wird und wie reaktionsschnell sie während der Nutzung sind.
Betrachten wir die Anwendung genauer und untersuchen die angebotenen Funktionen.
Übersicht
Im Übersichtsbereich von Real User Monitoring sehen Sie eine klare Darstellung der ausgewählten Dienste, die zu dem festgelegten Bereich gehören. Diese sind nach ihrer Wichtigkeit geordnet, wobei die kritischsten zuerst angezeigt werden. Die angezeigten Daten sind auf den gewählten Zeitrahmen abgestimmt und bieten eine gezielte Momentaufnahme der Leistungstrends.
Jede Kachel zeigt, wie sich der Application Performance Index (Apdex) über die Zeit für die drei wichtigsten Anfragetypen eines Dienstes entwickelt. Hierbei wird der Name und der Typ des Dienstes in der Kopfzeile der Kachel deutlich angezeigt.
Die Balken in den einzelnen Anfragetypen liefern zusätzliche Informationen: Ihre Grösse zeigt, wie oft sie ausgeführt wurden, und ihre Farbe gibt die Apdex-Bewertung an. Wenn Sie den Mauszeiger über einen Balken bewegen, wird eine QuickInfo mit detaillierten Informationen angezeigt, darunter die Startzeit, der Apdex-Wert und die Anzahl der Ausführungen.
Links auf der Kachel zeigt ein visueller Indikator die durchschnittliche Servicebewertung basierend auf den dargestellten Anfragetypen. So kann die Gesamtleistung des Dienstes auf einen Blick eingeschätzt werden.
Requests
Für jeden Requests können Sie mühelos die wichtigsten Informationen einsehen, darunter Name und Typ, Status (Kritisch, Warnung oder OK), Ausführungsfrequenz, durchschnittliche Antwortzeit und die Anzahl der betroffenen Benutzer. Standardmässig ist die Liste nach der Anzahl der kritischen Ausführungen (rot markiert) sortiert, um sicherzustellen, dass die dringendsten Probleme priorisiert werden.
Wenn Sie auf das Symbol «Details» neben einer Anfrage klicken, erhalten Sie drei tiefere Einblicke:
Request Actions: Aktionen werden auf der Grundlage des Anforderungstyps kategorisiert, z. B. HTTP(S)-Methoden wie GET oder POST, SAPUI5-Aktionen, die durch UI-Elemente, Web-Dynpro-Ereignisse, Web-GUI-Interaktionen oder RFC-Funktionsgruppen ausgelöst werden.
Ausführungsanalyse: Zeigen Sie Ausführungsmuster während des ausgewählten Zeitraums an. Eine niedrige Nettozeit für kritische Zeilen weist darauf hin, dass das Problem möglicherweise ausserhalb des aktuellen Dienstes liegt und weitere Untersuchungen erforderlich sind.
Ausführungsdetails: Diese Ebene bietet einen detaillierten Einblick in eine einzelne Ausführung, einschliesslich zusammenhängender Anfragen von anderen Komponenten. Sie können auch aus verschiedenen Visualisierungen wählen, um die Analyse an Ihre Bedürfnisse anzupassen.
Die Farbe des Anfragestatus ist an die Antwortzeiten gebunden:
Kritisch (rot): Die Reaktionszeit übersteigt den Medianwert um mindestens das Doppelte der Standardabweichung.
Warnung (Gelb): Die Reaktionszeit überschreitet den Medianwert um mindestens eine Standardabweichung.
Diese detaillierten Einblicke helfen bei der Identifizierung von Leistungsengpässen und bei der gezielten Fehlersuche.
Analyse
Die Analyseseite bietet leistungsstarke Tools zur Aufschlüsselung von Anfragemetriken nach verschiedenen Dimensionen und bietet eine breite Palette anpassbarer Analyseoptionen. Sie können die Anzeigeeinstellungen mit dem Filter-Popover feinabstimmen, um sich auf die Daten zu konzentrieren, die für Ihre Bedürfnisse am wichtigsten sind.
Die Seite Analyse unterstützt zwei primäre Anzeigeformate:
Table View
Verwenden Sie das Drilldown-Steuerelement, um die als Spalten angezeigten Dimensionen auszuwählen, sie per Drag-and-Drop neu anzuordnen und mit der Option «»Sortieren» zu sortieren.
Wählen Sie eine einzelne Kennzahl – Summe, Durchschnitt oder Anzahl – um Ihre Analyse gezielt auszurichten.
Ideal für detaillierte, tabellarische Vergleiche über Dimensionen hinweg.
Chart View
Am besten geeignet für die Visualisierung von Trends im Zeitverlauf.
Wählen Sie eine Auflösung und einen Zeitrahmen, um Liniendiagramme zu erstellen, die die Entwicklung der Metrik zeigen.
Für nicht-zeitliche Analysen setzen Sie die Auflösung auf «Keine Zeitabschnitte», um horizontale Balkendiagramme zu erstellen.
Mit dem Drilldown-Steuerelement können Sie Dimensionen aktivieren und anordnen, die Tabellenspalten oder Diagrammkategorien definieren. Die Berechnungen der Metriken umfassen:
Summe: Die Summe aller Abfragewerte.
Durchschnittlich: Die Summe geteilt durch die Anzahl.
Anzahl: Die Gesamtzahl der Anfragen.
Für zeitbezogene Aufschlüsselungen wählen Sie unter Auflösung eine Zeitauflösung.
Die Analyseseite bietet eine flexible, dimensionenbasierte Ansicht der Anfragemetriken, die es einfach macht, Trends und umsetzbare Erkenntnisse zu erkennen, die auf Ihre betrieblichen Anforderungen zugeschnitten sind.
Frontend
Die Seite Frontend bietet wichtige Nutzungs- und Leistungsmetriken für Frontend-Anfragetypen wie SAPUI5, Web Dynpro und Web GUI. Dieser Abschnitt bietet einen detaillierten Überblick über die Leistung von Anwendungen aus der Sicht des Endbenutzers und hilft Ihnen, potenzielle Engpässe zu erkennen und zu beheben.
Der Abschnitt «Frontend» enthält die folgenden Metriken:
Ausführungen: Gesamtzahl der im ausgewählten Zeitraum ausgeführten Anfragen.
Endbenutzer-Zeit: Reaktionszeit für den Benutzer.
Netzwerkzeit: Zeit, die für Netzwerkumläufe zwischen dem Frontend und dem Server benötigt wird.
Backend-Zeit: Verarbeitungszeit auf dem Server.
Sie können diese Metriken als Diagramm oder Tabelle darstellen und die Anzeige mithilfe der Filteroption anpassen, um bestimmte Anfragen, Zeitrahmen und Auflösungsstufen auszuwählen.
Standardmässig werden die Metriken für die aktuelle Woche mit einer stündlichen Auflösung angezeigt, unabhängig von den globalen Zeitrahmeneinstellungen. Um diese Seite an die globalen Einstellungen anzupassen, wählen Sie im Filter-Popover die Option Vererben.
Der Abschnitt Betriebssysteme und Browser bietet einen Überblick über die von den Endnutzern verwendeten Betriebssysteme, Browser und Geräte sowie die jeweiligen Nutzerzahlen. Abhängig von der Einstellung der Anzeigeversion im Filter:
Die Nutzerzahlen werden nach Browser- und Betriebssystemtypen (z. B. Windows, Chrome) angezeigt.
Alternativ können sie auch nach bestimmten Versionen (z. B. Windows 10) aufgeschlüsselt werden.
Wenn Sie auf ein Segment in den Kreisdiagrammen klicken, werden einzelne Nutzer für ein ausgewähltes Betriebssystem oder einen Browser angezeigt. Die Nutzerdaten werden anonymisiert, wenn der Betrachter nicht die Rolle «Real User Analyst Sensitive» hat, damit sensible Informationen geschützt bleiben.
Die Frontend-Seite liefert verwertbare Erkenntnisse über das Nutzerverhalten und die Leistung und ermöglicht proaktive Massnahmen zur Verbesserung des Gesamterlebnisses.
Backend
Die Seite «Backend» bietet einen wichtigen Überblick über die Leistungs- und Nutzungsmetriken für Backend-Anfragen und hilft Ihnen, die Systemleistung zu überwachen und zu optimieren.
Standardmässig zeigt die Seite Antwortzeiten und Ausführungszahlen für diese Backend-Anfragetypen an:
HTTP
HTTPS
RFC
RFCS
Dialog
Die Metriken können als Diagramm oder Tabelle angezeigt werden, und mit der Filteroption können Sie die Ansicht durch Auswahl bestimmter Anfragen, Zeiträume und Auflösungen verfeinern. Wenn Sie die Rolle «Real User Analyst Sensitive» haben, können Sie die Daten auch nach bestimmten Benutzern filtern, um tiefere Einblicke zu erhalten.
Standardmässig werden die Metriken der aktuellen Woche mit einer stündlichen Auflösung angezeigt. Diese Einstellung ist unabhängig vom globalen Zeitrahmen. Um sich an die globalen Einstellungen anzupassen, wählen Sie im Popup-Filter die Option Vererben.
Services/Systems
Die Seite Services/Systems bietet einen Überblick über die Leistung der Anfragen, gruppiert nach Diensten und Systemen, so dass es einfach ist, Einheiten mit schlechter Leistung oder hohem Anfragevolumen zu identifizieren.
Hauptmerkmale:
Sehen Sie sich die Bewertungen für jede Dienstleistung/jedes System und jede Art von Anfrage an.
Ermitteln Sie, wie viele Anfragen für einen bestimmten Anfragetyp ausgeführt werden, und bestimmen Sie, welcher Dienst das grösste Volumen bearbeitet.
Wenn eine Entität dominiert, können Sie die Werte als Prozentsätze anzeigen, indem Sie die Symbolleiste erweitern und Diagrammeinstellungen wählen.
Die Statusfarbe der Anfragen spiegelt ihre Antwortzeiten wider:
Kritisch (rot): Die Reaktionszeit übersteigt den Medianwert um mindestens das Doppelte der Standardabweichung.
Warnung (gelb): Die Reaktionszeit überschreitet den Medianwert um mindestens eine Standardabweichung.
Die Seite Services/Systeme hilft Ihnen dabei, Leistungsprobleme zu erkennen und besser zu verstehen, wie die Dienste mit Anfragen umgehen, was gezielte Verbesserungen ermöglicht.
Clients
Die Seite Clients bietet detaillierte Informationen zu den Betriebssystemen, Browsern und Gerätetypen, die von den Benutzern für die folgenden Frontend-Anfragetypen verwendet werden:
SAPUI5
Web Dynpro
Web GUI
Hauptmerkmale
Einblicke in die Technologien, auf die sich Benutzer verlassen, aufgeschlüsselt nach Betriebssystem, Browser und Gerätetyp.
Einen Überblick über die Benutzerzahlen finden Sie im Abschnitt Betriebssysteme und Browser auf der Seite Frontend.
Wenn Sie nicht die Rolle Real User Analyst Sensitive haben, werden die Benutzernamen anonymisiert, um den Datenschutz zu gewährleisten.
Filterungsoptionen
Verwenden Sie den allgemeinen Filter, um die Daten nach Betriebssystem, Browser und Gerätetyp (z. B. Windows oder Chrome) zu filtern.
Für eine versionsspezifische Filterung (z. B. Windows 10) verwenden Sie die Filteroption in der entsprechenden Tabellenspalte.
Die Seite «Clients» bietet wertvolle Einblicke in Benutzerumgebungen, die Ihnen helfen, Nutzungsmuster zu verstehen und für eine Vielzahl von Geräten und Plattformen zu optimieren.
Ausführungsablauf
Die Seite Ausführungsablauf bietet eine chronologische Ansicht der Benutzeraktionen und der entsprechenden Systemreaktionen, so dass Sie Nutzungsmuster analysieren und potenzielle Systemprobleme erkennen können.
Standardmässig werden keine Daten angezeigt. Um zu beginnen, geben Sie einen gültigen Benutzernamen oder eine Stammkontext-ID in den Filter ein:
Die Root Context ID identifiziert eine Sitzung und bleibt auch dann konsistent, wenn Anfragen an verschiedene Server gesendet werden, z.B. beim Starten einer App über das SAP Fiori Launchpad.
Wenn Sie nicht die Rolle Real User Analyst Sensitive haben, kann nur die Root Context ID verwendet werden, und die Benutzernamen sind nicht sichtbar.
Sobald die Ergebnisse ausgefüllt sind, werden Aktivitäten mit Backend-Antworten, die 200 ms überschreiten, detailliert aufgeführt. Die wichtigsten Spalten sind:
App/UI-Komponente: Front-End-Anwendung verwendet.
Interaktion mit dem Benutzer: Technische Bezeichnung der Aktion des Benutzers.
UI-Reaktionszeit [ms]: Zeit, die die Benutzeroberfläche benötigt, um zu reagieren.
Name der Anfrage/Backend-Komponente: Server-Anfrage ausgelöst.
Backend-Aktion: Auf dem Server durchgeführte Operation.
Reaktionszeit [ms]: Server-Verarbeitungszeit.
Nettozeit [ms]: Die Gesamtverarbeitungszeit der Komponente, ohne ausgehende Anfragen.
Zeit (basierend auf dem Server): Zeitstempel der Aktion.
Sie können auf eine beliebige Komponente oder Aktion klicken, um direkt zur Anforderungsseite zu navigieren und die entsprechenden Filtereinstellungen für eine gezielte Aufschlüsselung anzuwenden.
Die Seite Execution Flow bietet einen umfassenden Überblick über die Benutzeraktivitäten und Backend-Prozesse und hilft Ihnen, Aktionen zu verfolgen, die Leistung zu bewerten und Probleme in Echtzeit zu untersuchen.
Aufwändige Anfragen
Die Seite «Expensive Requests« hebt die ressourcenintensivsten und kritischsten Anfragen in Ihren Diensten und Systemen hervor. Dadurch können potenzielle Engpässe identifiziert und die Leistung optimiert werden.
Hauptmerkmale
Zeigt standardmässig bis zu 200 Anforderungsnamen an, geordnet nach Ressourcenverbrauch oder Wichtigkeit. Sie können dieses Limit in den Filtern unter dem Feld Top anpassen.
Die Ergebnisse erscheinen als Baumdiagramm mit Quadraten, die die Namen der Anfragen darstellen, gruppiert nach Anfragetypen.
Tree Map Details
Quadratgrösse: Hängt vom gewählten Anzeigemodus ab.
Quadratfarbe: Gibt den Prozentsatz der «roten» (kritischen) Ausführungen wieder. Eine Anfrage ist «rot», wenn ihre Antwortzeit mindestens das 12-fache der mittleren Antwortzeit für ihren Typ beträgt. Die Farbschwellenwerte sind in der Legende angegeben.
Im Anzeigemodus können Sie zwischen drei Ansichten wählen:
Leistung (Standard): Hebt die Anforderungsnamen mit den meisten roten Ausführungen hervor.
Arbeitsbelastung: Konzentriert sich auf Anfragen mit der höchsten Gesamtbeantwortungszeit, berechnet als Produkt aus Ausführungsanzahl und durchschnittlicher Antwortzeit.
Verwendung: Zeigt die Namen der Anfragen mit der höchsten Anzahl an eindeutigen Aufrufen an, was die Breite der Nutzeraktivität darstellt.
Klicken Sie auf ein beliebiges Quadrat, um den entsprechenden Anforderungsnamen in der Anforderungsübersicht anzuzeigen. Sie können auch auf Ausblenden klicken, um einzelne dominierende Anforderungsnamen auszublenden und einen besseren Überblick über die anderen Anforderungsnamen zu erhalten. Ausgeblendete Anforderungsnamen werden in den Filtern mit einem Ausrufezeichen (!) als Präfix angezeigt.
Die Seite «Expensive Requests» bietet eine übersichtliche visuelle Darstellung von ressourcenintensiven Anfragen, die Ihnen hilft, Optimierungen zu priorisieren und die Gesamteffizienz des Systems zu verbessern.
HTTP-Fehler
Die Seite HTTP-Fehler bietet Einblicke in HTTP(S)-Anfragefehler über Systeme und Dienste hinweg und ermöglicht eine schnelle Identifizierung von Leistungsproblemen.
Für jedes System oder jeden Dienst innerhalb des ausgewählten Zeitrahmens wird die Seite angezeigt:
Anzahl der Ausführungen: Insgesamt ausgeführte HTTP(S)-Anfragen.
Erfolgsquote (%): Prozentsatz der erfolgreichen Anrufe.
Client-Fehler (4xx): Prozentsatz der Anrufe mit 4xx-Statuscodes.
Server-Fehler (5xx): Prozentsatz der Anrufe mit Statuscodes 5xx.
Der Abschnitt «Historie» veranschaulicht die Entwicklung der HTTP(S)-Aufrufe und -Fehler im Laufe der Zeit. Ein erweiterter Zeitraum vor dem ausgewählten Zeitrahmen ist in den Diagrammen als Kontext enthalten, wobei der ausgewählte Zeitrahmen lila hervorgehoben ist.
Klicken Sie auf ein System oder einen Dienst in der Tabelle, um detaillierte Daten für die entsprechenden Anforderungsnamen innerhalb des ausgewählten Systems oder Dienstes anzuzeigen.
Die Seite HTTP-Fehler bietet Ihnen verwertbare Erkenntnisse zur Überwachung von Fehlertrends, zur Behebung von Problemen und zur Gewährleistung einer hohen Systemzuverlässigkeit.
Geolokalisierung
Auf der Seite «Geolocation» können Sie analysieren, woher HTTP(S)-Anfragen stammen, und erhalten so einen Einblick in die geografische Verteilung des Datenverkehrs für die untersuchten Systeme und Dienste.
Hauptmerkmale
Bei öffentlichen Cloud-Diensten wird die IP-Adresse des Anrufers über X-Forwarded-For an die Anwendung weitergeleitet, so dass die IP-Adresse einem Standort zugeordnet werden kann. Beachten Sie, dass Benutzer diese Informationen mit VPN-Tools ändern können.
Private Cloud-Dienste und On-Premise-Systeme hängen von der Konfiguration der Netzinfrastruktur ab, um Standortdaten bereitzustellen.
Die Standortübersicht zeigt die Anzahl der Anfragen gruppiert nach Land/Region und IP-Adresstyp, einschliesslich:
PUBLIC: IP-Adressen, die durchgereicht und einem Standort zugewiesen wurden.
PRIVATE: Für diese IP-Bereiche sind keine Standortdaten verfügbar.
UNKNOWN: IP-Adressen, die nicht in einen Standort aufgelöst werden können.
Suchen Sie nach bestimmten Standortdaten, indem Sie ein Land/eine Region aus der Übersicht auswählen oder den Filter verwenden, um eine Kennzahl zu definieren. Sie können die folgenden Kriterien für eine tiefere Analyse untersuchen:
Stadt
Request Name
Aktion (HTTP-Methode)
User Name
HTTP-Status (Statuscode)
Die Seite «Geolocation» hilft Ihnen, die globale Verteilung der Nutzeraktivitäten zu visualisieren, regionale Leistungsprobleme zu erkennen und Verkehrsmuster an verschiedenen Standorten zu verstehen.
Alerting
Die Seite «Alerting» bietet einen Überblick über alle aktivierten Alarme und hilft Ihnen, kritische Systemereignisse zu überwachen und notwendige Massnahmen zu ergreifen.
Hauptmerkmale
Warntypen: Derzeit werden hauptsächlich HTTP-Fehler angezeigt.
Konfiguration: Alarme werden im Abschnitt Konfiguration der entsprechenden verwalteten Komponente aktiviert und konfiguriert.
Schritte, die Sie unternehmen können
Warnungen sortieren: Sortieren Sie Alarme nach Alarmname, Meldung, Status, Bearbeiter und Objektdetails.
Prozessoren zuweisen/entfernen: Verwalten Sie, wer für die Bearbeitung von Alarmen zuständig ist.
Bestätigen Sie die Warnungen: Quittieren und bestätigen Sie offene Alarme.
Aktionsprotokolle anzeigen: Überprüfen Sie die Protokolle, die mit jedem Alarm verbunden sind, um einen detaillierten Verlauf zu erhalten.
Exportieren: Exportieren Sie die Liste der Warnmeldungen zur weiteren Analyse in ein Arbeitsblatt.
Die Seite «Alerting» stellt sicher, dass Sie bei kritischen Problemen den Überblick behalten, diese effizient lösen und die Systemzuverlässigkeit durch proaktives Alarmmanagement aufrechterhalten können.
Tipp: So erstellen Sie aussagekräftige Favoriten zur Übersicht
Um zum Beispiel nur bestimmte Anfragen auf der Übersichtsseite anzuzeigen, können Sie eine Anfrage öffnen und als Favorit speichern.
Wenn wir nun zur Startseite gehen, können wir den neu erstellten Favoriten sehen:
Fazit
Mit Real User Monitoring erhalten Organisationen Transparenz über Benutzerinteraktionen, Reaktionszeiten und Systemleistung. Dieses Tool verbessert nicht nur die Fähigkeit der IT-Teams, Probleme effizient zu lösen, sondern liefert auch den Business-Teams wertvolle Einblicke in das Nutzerverhalten. Infolgedessen hilft Real User Monitoring Organisationen dabei, ein nahtloses und optimiertes Benutzererlebnis zu bieten, was sowohl die operative Effizienz als auch die Zufriedenheit der Endnutzer steigert.
Ist es die Dämmerung des SAP Solution Managers oder ist es die Morgenröte von SAP Cloud ALM, in der dieses einsame gefiederte Feature in Richtung Produktion segelt? Es ist beides.
Jeder SAP-Admin kennt es: Der Auditor steht vor der Tür und will wissen, wer wann was im System geändert hat und ob alle Schritte nachvollziehbar sind. Mit der Transportanalyse in SAP Cloud ALM kann das Nachweisen und Prüfen von Änderungen schnell und sicher erledigt werden – und zwar von «vorne» (anhand einer Änderungsnummer) oder von «hinten» (anhand einer Transportnummer). In diesem Artikel zeige ich dir, wie du von «hinten» die Transportanalyse in SAP Cloud ALM einsetzen kannst, um Audit-Anforderungen zu erfüllen, und wie du ITIL-konforme Change Enablement-Prinzipien integrierst, indem du mit Tags für die Risikoabschätzung und Requirements für die Kundenzentrierung und Wertschöpfung arbeitest.
🆕 Der moderne Ansatz: Change Enablement nach ITIL 4
Die IT-Welt hat sich verändert: Cloud Computing, agile Methoden und immer schnellere Anpassungen an Kundenbedürfnisse haben die Anforderungen an das Change-Management neu definiert. Der ITIL 4-Ansatz von Change Enablement geht weg von starren Prozessen hin zu einem flexiblen Framework, das kontrollierte und schnelle Veränderungen ermöglicht. Es hilft, Risiken zu minimieren, ohne die Geschwindigkeit und Agilität moderner IT-Umgebungen zu beeinträchtigen.
Im Kontext von SAP Cloud ALM bedeutet das: Transparente Nachweise, zügige Umsetzung und die richtige Balance zwischen Kontrolle und Flexibilität. Genau das brauchen wir im Audit – und SAP Cloud ALM liefert uns dafür die passenden Werkzeuge.
🚨 Was für den Audit wirklich wichtig ist
Um den Anforderungen eines Audits gerecht zu werden, verlangt ITIL 4 Change Enablement eine transparente und nachvollziehbare Dokumentation aller Änderungen. Besonders wichtig sind die Nachweise dafür, dass:
1. Die Änderung im DEV-System veranlasst und implementiert wurde.
2. Die Änderung im Testsystem geprüft wurde.
3. Die Freigabe für den Import ins Produktivsystem von der berechtigten Person erteilt wurde.
Die Transportanalyse in SAP Cloud ALM hilft dir, all diese Nachweise lückenlos und audit-sicher zu dokumentieren – schnell und ohne großen Aufwand.
Schritt-für-Schritt zur Audit-sicheren Transportanalyse in SAP Cloud ALM
Schritt 1: Projektübergreifende Übersicht öffnen
Gehe in SAP Cloud ALM zur Projektübergreifenden Übersicht. Hier erhältst du einen Überblick über alle Projekte und Aktivitäten und kannst direkt die gewünschten Transporte finden. Diese Übersicht ist dein Ausgangspunkt für gezielte Analysen und eine schnelle Navigation zu den Transporten, die du prüfen willst.
Schritt 2: Die App «Transportanalys» starten
Öffne die Transportanalyse-App. Diese zeigt dir alle Transporte, ihre Ziele, Status und Zuordnungen zu bestimmten Features oder User Stories. Die App deckt den gesamten Lebenszyklus eines Transports ab und liefert dir den Einstiegspunkt aus Transportsicht für alle Informationen, die du für eine auditfeste Dokumentation benötigst.
Schritt 3: Den gesuchten Transport filtern
Verwende den Filter, um nach der Transportnummer zu suchen, die du analysieren möchtest. In der Liste kannst du bereits anhand des Status sehen, ob der Transport erfolgreich in die Produktion übernommen wurde (Status = «Importiert» im Ziel-Tenant=Produktivsystem) , ob er noch aussteht oder eventuell fehlgeschlagen ist. Diese Informationen sind essenziell, um im Audit die genauen Schritte des Transports darzustellen.
Schritt 4: Zum zugehörigen Feature springen
Klicke auf das Feature, das dem Transport zugeordnet ist. Im Feature findest du eine Beschreibung sowie den Auditlog (Historie), der alle Aktivitäten dokumentiert. Hier kannst du nachverfolgen:
Wer war für die Implementierung und Durchführung der Änderung im DEV-System zuständig?
Wer hat die Tests durchgeführt?
Wer hat die Freigabe für den Produktivimport erteilt?
💡 Tipp: Nutze die Transportanalyse regelmässig, um sicherzustellen, dass alle Schritte des Change-Prozesses ordnungsgemäss dokumentiert sind bzw. ob sich auch alle an den Change-Prozess mit SAP Cloud ALM halten und keine Hintertürtransporte durchführt. So bist du auch ohne Hektik auf das Audit vorbereitet und hast alle Nachweise stets zur Hand.
Schritt 5: Zu User Stories oder Requirements springen
Falls dein Team zusätzlich mit User Stories oder Requirements arbeitet, kannst du direkt im Feature zur zugehörigen User Story oder Requirement springen. Gerade die Ebene der Requirements kann besonders hilfreich sein, um den Mehrwert für den Kunden zu dokumentieren.
⚠️ Risikoabschätzung und Kundenzentrierung mit Tags und Requirements
Für eine ITIL-konforme Umsetzung der Risikoabschätzung und Kundenzentrierung kannst du Tags und Requirements nutzen:
Risikoabschätzung mit Tags
Tags sind eine einfache und effektive Möglichkeit, Risiken zu klassifizieren und sichtbar zu machen:
Risiko-Level-Tags wie «High Risk», «Medium Ris» und «Low Risk» zeigen sofort den Risikograd einer Änderung. So kann das Team gezielt entscheiden, welche Genehmigungsstufen notwendig sind.
Compliance-Tags wie «Security-Compliance» oder «Business-Critical» markieren Transporte mit besonderen Anforderungen an Sicherheit und Stabilität.
Impact-Tags wie «Multi-System Impact» oder «Single-System Change» zeigen auf, ob der Transport Auswirkungen auf andere Systeme hat und damit eine genauere Risikoanalyse erforderlich ist.
Vorteil: Tags schaffen eine schnelle Übersicht über Risiken und helfen, die richtigen Kontrollen und Prioritäten für jede Änderung zu setzen.
Kundenzentrierung und Wertschöpfung durch Requirements
Requirements eignen sich hervorragend, um den Mehrwert und die Ziele der Änderung aus Kundensicht festzuhalten:
Customer-Value-Requirements beschreiben den erwarteten Nutzen einer Änderung für den Kunden, z. B. «Verbesserte Benutzerfreundlichkeit im Fiori App». So sehen alle Beteiligten direkt, welchen Mehrwert die Änderung bringt.
Value-Tracking und Feedback: Ergänze das Requirement um Feedback-Notizen oder Tags, die erfassen, wie gut die Änderung die Kundenerwartungen erfüllt hat.
Vorteil: Requirements helfen dabei, die Kundenzentrierung in den Fokus zu rücken und zeigen im Audit, dass jede Änderung auf den Kundenwert und -nutzen ausgerichtet ist.
🛫 Take away message
Mit SAP Cloud ALM und den modernen ITIL 4-Prinzipien für Change Enablement gelingt es dir, Änderungen audit-sicher und flexibel zu dokumentieren. Die Transportanalyse hilft, alle Schritte eines Changes klar nachzuvollziehen und die notwendigen Nachweise für den Audit zu liefern. Tags und Requirements sorgen zusätzlich für eine strukturierte Risikoabschätzung und eine klare Dokumentation des Kundennutzens. So wird Change Enablement in SAP Cloud ALM nicht nur auditfest, sondern auch zu einem echten Mehrwert für das Unternehmen und den Kunden.
We use cookies and similar technologies to improve your experience on our website.
