Job Management Konzept
Das könnte Sie interessieren:
In jedem Unternehmen mit einem SAP-System gibt es jemanden, der die Verantwortung für die SAP Basis trägt. Diese Person sorgt für den störungsfreien Betrieb des SAP-Systems. Sie begleitet Wartungsarbeiten und greift bei besonderen Situationen, wie zum Beispiel schlechter Performance, ein. Auch für Unternehmen, die den Betrieb der Basis an einen externen Dienstleister übergeben, ergeben sich an dieser Stelle oft noch Aufgaben aus dem Umfeld der Benutzer und des Berechtigungsmanagements.
Das sogenannte Service Level Management (SLM) dient der langfristigen Überwachung und Optimierung. Es wird bereits von vielen IT-Organisationen zum Management der Beziehungen zwischen den einzelnen Service-providern und dem Geschäftsprozessinhaber eingesetzt. Als Service Level Management bezeichnet man eine strukturierte, proaktive Methode, die das Ziel hat, den Benutzern einer IT-Anwendung ein adäquates Serviceniveau zu garantieren – in Übereinstimmung mit den betriebswirtschaftlichen Zielen des Auftraggebers und bei optimalen Kosten. Diese Methode beinhaltet klar definierte, überprüfbare Ziele und eine klare Kommunikation zwischen den Geschäftsprozessinhabern und den Betreibern einer Lösung (dies können für Server, Datenbanken, Netzwerke etc. mehrere interne oder externe Betreiber sein). Das Service Level Management besteht zunächst aus einem Service Level Agreement, in dem die oben zu erreichenden Ziele im Hinblick auf Verfügbarkeit, Performance, Korrektheit und Sicherheit definiert werden und auch festgelegt wird, wie das Erreichen dieser Ziele gemessen und kommuniziert werden soll. Das Service Level Reporting berichtet über die Zielerreichung in einem festgelegten Zeitraum. Primäres Ziel des Service Level Reportings ist es also, festzustellen, ob die festgelegten Betriebsziele erreicht wurden, und mögliches Optimierungspotenzial aufzuzeigen.
SAP Extended Memory und Roll-Puffer
Zur Bewältigung der digitalen Transformation im Allgemeinen, aber auch zur Bewältigung der sich verändernden Anforderungen an die SAP-Basis und deren Aufgabengebiet ist es notwendig, bestehende Rollen zu überarbeiten und neue Rollen zu definieren wie auch zu etablieren. Dies sind bspw die Rollen des Technologiearchitekten, neue Ausprägungen des Subject Matter Expert (SME) oder auch die Rolle des Expert Team Lead zur Führung einer Gruppe von Experten. Fortführende Informationen sind dem Kapitel 7.1 und 9.3 der Masterarbeit zu entnehmen.
Als Eingaben für das Sizing dienen Ihre Angaben über die Anzahl der Benutzer in den verschiedenen SAP-Anwendungen. Anhand detaillierter Erfahrungswerte über den Hardwarebedarf der verschiedenen SAP-Anwendungen werden zunächst der Hardwarebedarf pro Anwendung (als Produkt aus Benutzeranzahl und anwendungsspezifischem Lastfaktor und eventuell einem konstanten Grundbedarf) und anschließend der Gesamthardwarebedarf als Summe aller Einzelbedarfe pro Anwendung berechnet. Das benutzerbasierte Sizing liefert immer dann zuverlässige Angaben, wenn die Hauptlast in einem System durch Dialogbenutzer verursacht wird und der SAP-Standard nicht wesentlich modifiziert wurde. Bei der Interpretation des Ergebnisses ist zu berücksichtigen, dass das benutzerbasierte Sizing im Quick Sizer mit einer Zielauslastung von 100 % in Bezug auf den Hauptspeicher und 33 % in Bezug auf die CPU rechnet. Bereits in Kapitel 2, »Analyse von Hardware, Datenbank und ABAP-Applikationsserver«, haben wir dargestellt, dass man eine CPU nicht zu 100 % auslasten kann, wenn man auf einem Rechner mit Dialogbenutzern eine gute Antwortzeit garantieren möchte. Die relativ niedrig angesetzte Zielauslastung berücksichtigt außerdem noch einen relativ hohen Sicherheitsfaktor, den man beim benutzerbasierten Sizing mit beachten muss.
Basisadministratoren steht mit "Shortcut for SAP Systems" eine PC-Anwendung zur Verfügung, die etliche Tätigkeiten in der SAP Basis vereinfacht bzw. ermöglicht.
Im Beispiel in Abbildung 3.6 fällt auf, dass die Antwortzeiten für die ersten Dialogschritte deutlich unter 1 Sekunde liegen, dass aber der letzte Transaktionsschritt im Dialog-Task (mit dem Funktionscode SICH) eine hohe Antwortzeit von 14,5 Sekunden aufweist.
Während dieser Schritte werden Daten wie Variablen, interne Tabellen und Bildschirmlisten aufgebaut und im Hauptspeicher des Applikationsservers gehalten.