SAP Solution Manager: Eine Monitoring-Plattform überwacht SAP-Systeme

Mit dem Business Process Repository des SAP Solution Manager etabliert SAP seit 2001 eine neue Referenzstruktur für das Anwendungsmanagement unabhängig von Anwendungskomponenten und Entwicklungspaketen. Diese Referenzstruktur wird in der Software verankert, um die Implementierung und den Betrieb der Systeme besser zu strukturieren. Die alte Hierarchie der Anwendungskomponenten von SAP R/3 erwies sich im Rahmen der bestehenden technischen Elemente als zu einseitig funktional festgelegt. Deshalb hat sich SAP bewusst für einen alternativen Ansatz entschieden, der auch betriebswirtschaftliche Fragestellungen berücksichtigt.

Die Grundlage und damit die erste Ebene für die Struktur des SAP Solution Manager bildet das Business Process Repository. Dieses gliedert sich nach Modulen wie SAP ERP oder SAP CRM. Die zweite Ebene des Business Process Repository stellen sogenannte Geschäftsszenarien dar. Dabei handelt es sich um Prozessgruppierungen, die sich aus dem Kontext der Lösung und ihrer Einsatzszenarien ergeben. Ein Beispiel dafür sind die Finanzbuchhaltung oder der Einkauf in SAP ERP. Den einzelnen Geschäftsszenarien wiederum sind drei Sichten untergeordnet: Organisationselemente, Stammdatenobjekte und Prozesse. Im Bereich Stammdaten differenziert sich das Finanzwesen beispielsweise in 79 Objekte. Vom Kontenplan über die Kostenstelle bis hin zum Investitionsauftrag finden sich hier alle wichtigen Elemente der Buchhaltung und des Controlling wieder. Auch hier stellt sich für die SAP-Anwender die Frage, welche Elemente sie wie intensiv pflegen. Schließlich differenziert sich der Bereich Prozesse im Finanzwesen in 68 Einzelprozesse, die wiederum – ungefähr im Verhältnis eins zu zehn – mit 633 Prozessschritten ausgestattet sind. Diesen Prozessschritten wiederum sind über 3000 Transaktionen zugeordnet. Typische Geschäftsabläufe sind beispielsweise die Kreditoren- und Debitorenbuchhaltung, aber auch der Einzelabschluss sowie Planungs- oder analytische Prozesse.

Am häufigsten kommt der SAP Solution Manager bei Upgrades und Roll-Out-Projekten zum Einsatz. Der erste Schritt besteht dabei stets im Aufbau einer Blueprint-Struktur, um die Geschäftsabläufe zu dokumentieren und zu entscheiden, welche Prozesse im SAP-System abgebildet werden sollen. Hierbei werden Konfigurationsinhalte und Dokumentationen eingebunden oder gegebenenfalls neu entwickelt. Nicht immer kann dabei auf Testfälle zurückgegriffen werden. Der Aufbau des Blueprints verfolgt zwei Ziele: Auf der einen Seite werden die Originalelemente des Business Process Repository aktiviert, da sie Verweise auf Upgradeinformationen beinhalten. Diese Prozessschritte hat SAP mit Informationen zur Konfiguration und entsprechenden Dokumentationen erweitert. Das zweite Ziel vieler Anwender ist eine möglichst weitgehende Individualisierung ihres Prozessmodells. Dazu müssen alle genutzten Transaktionen, insbesondere die kundenspezifischen, prozessgerecht zugeordnet werden, um deren Nutzung zu verfolgen. Je objektiver das Bild der Ist-Situation ausfällt, desto schneller läuft das Upgrade. Es müssen ja ausschließlich die relevanten Aspekte, Prozesse, Prozessschritte, Belegarten und Positionstypen getestet werden.

Das richtige Individualisieren der Referenzstruktur stellt aus Sicht der Anwender die größte Hürde beim Einsatz des SAP Solution Manager dar. SAP hat hier eine Grenze gesetzt, so dass sich die Strukturtiefe nicht beliebig variieren lässt. Die Prozessschritte stellen die letzte Ebene dar, die sich allein durch Ausprägung von Parallelstrukturen erweitert lässt. In der aktuellen Version des SAP Solution Manager ist erstmals eine semantische Erweiterung verfügbar. Dadurch lassen sich auch Szenarien für Schnittstellen definieren, die Übergänge zwischen SAP-Anwendungen und Fremdsystemen eigenständig darstellen.

Die Einführung eigener Modellelemente ist nur bedingt sinnvoll, da sie von nachgelagerten Werkzeugen nicht über ihre Business Process Repository Identität identifiziert werden können. Den größten Teil der Individualisierung können die Anwender im SAP Solution Manager auf den zugeordneten Tabellen-Reitern durchführen. Dort lassen sich eigene Dokumentationen, Transaktionen oder Testfälle zuordnen. So können Anwender diverse Attribute pflegen, die für das Applikationsmanagement hilfreich sind. Dabei empfiehlt es sich, die Struktur des SAP Solution Manager auf die vorgesehenen Anwendungsfälle hin auszulegen. Nicht empfehlenswert ist es hingegen, die Struktur im Rahmen eines Re-Design-Projektes als Business-Process-Management-Vorlage für eine freie Prozessmodellierung zu missbrauchen.

In Business-Process-Management(BPM)-Projekten kommen fast immer Modellierungswerkzeuge zum Einsatz, um Geschäftsabläufe zu gestalten und konzernweit zu verwalten. Es liegt hier ein Prozessmodell vor, das SAP-Transaktionen als Attribute pflegt und weitere organisatorische Design-Aspekte beinhaltet, die nur wenig mit dem SAP Solution Manager zu tun haben. Ein elementares Problem solcher Projekte ist die Festlegung, an welcher Stelle bestimmte Informationen gepflegt werden. Prozessänderungen beispielsweise sollten nur im BPM-Tool vorgenommen werden und erst bei der SAP-Umsetzung an den SAP Solution Manager übergeben werden. Diese Methode setzt ein integrationsfähiges BPM-Tool voraus. Es ist nicht ratsam, sämtliche Details eines neu gestalteten Geschäftsprozesses an den SAP Solution Manager zu übergeben. Ebenso wenig sollten darin alle Varianten für verschiedene Geschäftsvorfälle oder Standorte abgebildet werden. Stattdessen empfiehlt sich die Abbildung einer generellen Prozessstruktur, in welche die einzelnen Varianten per Dokumentation eingeklinkt werden. Diese Struktur sollte immer aus der Perspektive einer Supportabteilung abgebildet sein. Der Support denkt nämlich nicht in Prozessvarianten, sondern stets in den technischen Objekten der SAP-Anwendungen.

Die Lösung dieses Problems setzt eine übergreifende Content Governance zwischen Fachabteilung und IT voraus. Generell kann es für beide Sichten kein einheitliches Gesamtmodell geben. Auf den ersten drei Ebenen der Struktur sollten allerdings Anwender und IT-Abteilung ein gemeinsames Strukturmodell definieren. Es empfiehlt sich, hierbei sämtliche Terminologien zu vereinheitlichen, damit keine unterschiedlichen Sachverhalte vermischt werden. Das stellt eine gleichbleibende Granularität und Semantik sicher. Der Lösungsansatz für die ersten drei Strukturebenen kann durchaus Business-getrieben sein. Ab der vierten Ebene muss allerdings die Software-nahe Strukturierung der Prozesse auf der Grundlage des Business Process Repository dominieren.

Die Realisierung von BPM-Projekten erfordert, dass die Blueprint-Struktur möglichst realitätsnah auf Grundlage des Business Process Repository individualisiert wird. Eine methodisch und inhaltlich ausgereifte Lösung hierfür liefert beispielsweise IBIS RBE Plus für SAP Solution Manager. Sie unterstützt neben der Individualisierung des Business Process Repository auch die Integration zu BPM-Tools sowie den Aufbau einer eigenen Content Governance. So entsteht eine tragfähige Basis für den effizienten Einsatz des SAP Solution Manager. Der Projekteinsatz dieser Management-Plattform erfolgt dann entweder aus dem operativen Betrieb heraus als kleines Dokumentationsprojekt oder wird als Projektaufgabe in das nächste Upgrade- oder Erweiterungsprojekt einbezogen. Grundsätzlich sollte der Projekteinsatz aber nicht überdehnt werden. Der SAP Solution Manager ist und bleibt ein Instrument des IT-Anwendungsmanagements