In allen Wirtschaftszweigen sind heute SAP-Systeme mehr oder weniger Standard. Für deren Administration gibt es den SAP Solution Manager. Und dennoch oder gerade deswegen ist das Anwendungsmanagement nicht trivial. Ein Grund, warum es noch viel zu oft vernachlässigt wird. Was vereint den Solution Manager mit der Dampfmaschine? Früher wurden viele Aktivitäten in der Systemverwaltung und im Support manuell durchgeführt. Die technische Entwicklung macht es nun möglich, diese automatisiert abzuwickeln. Dabei schwingt auch leichte Kritik mit. Denn SAP hat das Werkzeug spät an die Anwender herangetragen – im Rahmen der Produktlebenszyklen von SAP R/3 oder der SAP Business Suite. Ein weiterer Aspekt: Ähnlich wie in den Anfängen des Dampfmaschinenzeitalters werden die Anwender mit Werkzeugen unterschiedlicher „Erprobungsgrade“ und technologischer Qualität konfrontiert. Deshalb ist es für die Anwender eine Herausforderung, die Werkzeuge koordiniert und effektiv einzusetzen. Ihren Anfang nahm die Entwicklung des Solution Managers mit der Notwendigkeit, mehrere SAP-Systeme durch ein zentrales Anwendungsmanagement zu verbinden. So sollten sowohl die Anwender in ihren Customer Competence Centern als auch SAP über den Active Global Support die Möglichkeit haben, die Leistungen zu zentralisieren. Die gleiche Anforderung galt auch für alle Werkzeuge zur Leistungsverbesserung des SAP-Systems. Allerdings verfolgte SAP hier das Ziel, möglichst viele ihrer Support-Werkzeuge direkt in die Hände der Kunden zu legen. Erst später kamen Tools hinzu, die im operativen Betrieb das Änderungsmanagement sowie die Fehler- und Problemlösung organisieren. Auch für die Projektsteuerung bietet SAP mit dem Solution Manager eine „eingebundene“ Lösung, die eine stringente Durchführung unterschiedlichster Projekte begünstigt. Die anspruchsvollste Projektform ist der Solution Upgrade, inklusive der Integration von cProjects als virtuelle Projektplattform.

Zentrales Anwendungsmanagement über Workcenter

Für ein zentrales Anwendungsmangement der SAP-Systemlandschaft sind im Solution Manager so genannte Workcenter verantwortlich (siehe Schaubild). Jeder einzelne Workcenter bildet dabei bestimmte Rollen ab oder unterstützt spezielle Aufgaben. Sie decken den gesamten Kreislauf des Anwendungsmanagements ab. Von der Implementierung bis zum Test einer neuen Lösung reichen die Phasen „Design“ und „Build & Test“. Die Phase „Deploy“, die Änderungen aktiviert, wird durch den Workcenter Change Management unterstützt. Der Schwerpunkt des Modells liegt in der „Operate“-Phase. Dort werden die klassischen Aufgaben eines Administrators in den Workcentern zur Fehleranalyse, zum Solution Monitoring und für die Bearbeitung von internen Fehlermeldungen (Incident Management) unterstützt. Die so genannte „Optimize“-Phase wird durch die SAP Services Delivery abgebildet. Schließlich helfen noch Workcenter beim Upgrade und der Dokumentation der Lösung.

Hoher Nutzen für Administratoren großer Systemlandschaften

Müssen mehrere Systeme miteinander verbunden werden, verdeutlicht die Workcenter-Struktur, warum der Einsatz des Solution Managers besonders vorteilhaft ist. Denn gerade in großen Systemlandschaften stiftet die zentrale Übersicht über Ausfallzeiten oder eine Domänen übergreifende Transportverwaltung großen Nutzen. Hier arbeitet der Solution Manager wie eine Spinne im Netz, koordiniert und verbindet die verschiedenen Systeme miteinander. Gleiches gilt für den Workcenter Systemverwaltung. Dieser bietet einen zentralen Zugriff auf Routineaufgaben und auf die Werkzeuge der Systemadministration. Im Workcenter für Systemmonitoring befindet sich eine ganze Reihe von Werkzeugen, die ein zentrales, standardisiertes Monitoring erlauben. Insgesamt ermöglichen diese Systemchecks eine proaktive Problemerkennung, sofern die dafür notwenigen Werkzeuge in den Satellitensystemen aktiviert sind. Der Business Process Operation Workcenter überwacht dabei Schnittstellen und stellt die Datenkonsistenz sicher. Auf der Basis von Überwachungsfunktionen werden hier Alarmmeldungen oder Aufgaben generiert. Über vordefinierte Schwellwerte und Reaktionen kann der Support dadurch schnell auf Problemstellungen reagieren. Auch eine klassische Aufgabe, wie die Jobverwaltung, kann in komplexen Systemlandschaften zu einem Problem werden. SAP ermöglicht aus diesem Grund eine prozessorientierte und dokumentierte Jobsteuerung, die systemübergreifend erfolgt. So erlaubt der Workcenter zur so genannten Root Cause Analyse die Ursachenanalyse und Problemlösung für ABAP und Java-basierte Anwendungen. Das Zwischenresümee lautet: Sämtliche Workcenter, die administrative Aufgaben erledigen, sind empfehlenswerte und nützliche Werkzeuge. Sie begünstigen alle ein zentrales Anwendungsmanagement. In welcher Stufe dieses ausgebaut werden sollten, ist von der Komplexität der Systemlandschaft abhängig.

ITIL-konforme Prozesse im Anwendungsmanagement

Damit eine Support- oder eine Entwicklungsabteilung ITIL-konforme und Workflow-gesteuerte Änderungen durchführen kann, nutzen diese den erweiterten Change Management Workcenter. Er stellt insbesondere die zentrale Verwaltung von Wartungs- und Änderungsanträgen sicher. Das Incident Management erlaubt die einfachere Abwicklung von Fehlermeldungen innerhalb einer Supportorganisation beim Kunden. Dabei arbeitet die interne Erfassung von Fehlermeldungen eng mit dem SAP Service Marktplatz und dem SAP Support zusammen. Im Grunde werden hier also CRM-Funktionalitäten innerhalb des Solution Managers verfügbar gemacht: So können auf diesem Wege neben einer Serviceanfrage auch Lösungen gepflegt werden, wie sie ein Service-Desk üblicherweise in seinen Standardvorgängen durchführen muss. In einem engen Zusammenspiel ist auch der SAP-Support im Rahmen des Service Delivery Workcenters zu sehen. Dort erlaubt die SAP den Zugriff auf die gesamte Palette des SAP Supports – von bereitgestellten Diagnosen, die der Kunde selbst durchführen kann, bis hin zur Nutzung von kostenpflichtigen SAP Services und Experten. Für den reibungslosen Betrieb des Workcenters im Solution Manager ist eine gepflegte Geschäftsprozessstruktur notwendig, die auf Basis des mitgelieferten Business Process Repositorys (BPR) zusammengestellt werden kann. Diese Struktur kann manuell aufgebaut werden. Es gibt allerdings auch Services, beispielsweise RBE Plus, die eine notwendige Evaluierung und individuelle Ausprägung vereinfachen und beschleunigen. Beurteilung: Die hier beschriebenen Prozesse müssen berücksichtigt werden, um ein reibungsloses Zusammenspiel mit dem SAP Support sicherzustellen. Allerdings bestehen hier Abgrenzungsprobleme zu bereits vorhandenen Verfahren, Tools und übergreifenden ITIL-Prozessen. Denn SAP ist eben nur eines von vielen im Einsatz befindlichen IT-Systemen.

Solution Manager im Projekteinsatz

Die meisten Solution Manager Projekte sind in der Regel Upgrades. Daneben stellen der Roll-Out einer Lösung und die Nachdokumentation der Systemnutzung die wichtigsten Projektformen dar. Klassische Neueinführungsprojekte spielen hingegen keine wichtige Rolle. So ist es nicht verwunderlich, dass das zentrale Testen im Vordergrund steht. Denn eine effiziente Testabwicklung ist bei einem System-Upgrade einer der größten Kostenfaktoren. Neben den Tests müssen in solchen Projekten relevante Upgradeaktivitäten und der Bedarf an Endanwenderschulungen ermittelt werden. Die meisten Projekte beschränken sich dabei auf technische Upgrades. Funktionale Upgrades, über die neue Funktionen aktiviert werden oder Modifikationen durch Standardfunktionen ersetzt werden, bilden leider eher die Ausnahme. Noch seltener sind strategische Upgrades, die völlig neue Geschäftsszenarien und Prozesse etablieren oder Prozessabläufe durch zusätzliche SAP-Anwendungen und Funktionen verbessern sollen. Da im Solution Manager selten Einführungsprojekte vorliegen, muss der Blueprint initial aufgebaut werden. Dabei kann es vorkommen, dass sämtliche Konfigurationsinhalte und Dokumentationen eingebunden oder gar neu entwickelt werden müssen. Auch Testfälle sind nicht unbedingt immer vorhanden. Um den Blueprint aufzubauen, müssen demnach zwei Ziele verfolgt werden. Auf der einen Seite ist es notwendig, die Originalelemente des Business Process Repository zu aktivieren, da sie Verweise auf Upgradeinformationen beinhalten. Die Prozesse und Prozessschritte sind dazu von SAP mit Dokumentation und Konfigurationsinformation erweitert worden. Auf der anderen Seite will ein SAP-Anwenderunternehmen in der Regel sein Prozessmodell möglichst weitgehend individuell gestalten. Daher ist es erforderlich, alle genutzten Transaktionen, insbesondere die kundenspezifischen, prozessgerecht zuzuordnen. So wird sichergestellt, dass auch deren Nutzung nachvollziehbar bleibt. Dieses objektive Bild der Ist-Situation beschleunigt ein Upgrade-Projekt massiv, da nur relevante Aspekte, Prozesse, Belegarten und Positionstypen getestet werden müssen. Beurteilung: Mit der Abwicklung von ganzen Projekten „verlässt“ der Solution Manager allerdings auch die IT-Abteilung, wo nur wenige „Basis“-Experten mit ihm umgehen.

Neue Solution Manager Funktionen im Feldtest

Für den technischen Upgrade und das Testthema bietet SAP in der neuesten Version zwei Erstentwicklungen an. Einerseits das Custom Development Management Cockpit, in dem Eigenentwicklungen untersucht und mit den vom Upgrade betroffenen Elementen eines zweiten Systems abgeglichen werden können. Andererseits ermöglicht der Business Process Change Analyzer den Abgleich zwischen den geänderten Objekten eines Transportes (Change oder Support Package) und der technischen Stückliste zu bestimmten Objekten (Transaktion, Report). Wenn sich durch eine Neuentwicklung ein bestimmtes technisches Objekt, eine Tabelle oder ein Funktionsbaustein ändert, kann der Experte so erkennen, in welchen Transaktionen sich dies auf das Zielsystem auswirkt. Leider ist diese Funktionalität mit einer sehr aufwändigen Vorbereitung im Zielsystem verbunden, da für jede Transaktion in der Prozessstruktur die technische Stückliste einzeln erstellt werden muss. Beurteilung: Beide Werkzeuge sind aus diesen Gründen nur für „Basis“-Experten verwendbar und sind damit isoliert zu betrachten. Eine Konsolidierung mit anderen, ähnlichen Tools und bessere analytische und inhaltliche Vorgaben wären hier hilfreich. Daher empfiehlt es sich, beide Werkzeuge vor ihrem Einsatz im Produktivsystem, einer Prüfung an einigen, bekannten Objekten zu unterziehen. Ein Massenabgleich erscheint nicht praktikabel, da die Reports zu sehr umfangreichen Ergebnissen führen, deren Aussagegehalt gegen Null geht. Auch ist es fraglich, ob ein Unternehmen dadurch wirklich Testaufwand sparen kann.

Solution Manager und BPM-Tools

Üblicherweise sind in Business-Process-Management-Projekten Modellierungswerkzeuge wie ARIS beteiligt. Sie bilden die Grundlage für das Re-Design oder die Verwaltung von Konzernvorgaben für bestimmte Geschäftsprozesse. Dem Werkzeug liegt ein Prozessmodell zugrunde, das SAP-Transaktionen als Attribute pflegt und ansonsten viele weitere organisatorische Design-Aspekte beinhaltet, die allerdings wenig mit dem Solution Manager zu tun haben. Das Hauptproblem in diesen Projekten liegt darin, dass zunächst einmal festgelegt werden muss, von wo aus bestimmte Informationen gepflegt werden sollen. Sinnvollerweise sollten Prozessänderungen nur im BPM-Tool vorgenommen und zur SAP-Umsetzung an den Solution Manager übergeben werden. Dies setzt voraus, dass das BPM-Tool integrationsfähig ist. Es macht allerdings wenig Sinn, alle Details eines neu definierten Geschäftsprozesses an den Solution Manager zu übergeben. Nicht empfehlenswert ist es, beispielsweise im Solution Manager alle Prozessvarianten für verschiedene Geschäftsvorfälle oder Standorte abzubilden. Vielmehr ist es anzuraten, eine generelle Prozessstruktur abzubilden und die einzelnen Prozessvarianten per Dokumentation als Erklärungskomponente einzuklinken. Beurteilung: Der Solution Manager ist keine BPM-Umgebung. Letztlich muss er die Prozessstruktur in der Perspektive einer Supportabteilung abbilden, die nicht in Prozessvarianten denkt, sondern in der Dimension technischer Objekte der SAP-Applikation.

Randbedingungen und Wirtschaftlichkeit

Einsparungen mit dem Solution Manager zu erzielen ist eine Frage der Opportunitätskosten, d.h. was sind die Alternativen? Dem Aufwand einen zentralen Solution Manager aufzubauen und zu warten, stehen die Vorteile der Zentralisierung der Aufgaben bei mehreren SAP-Systemen gegenüber. Auch können (müssen aber nicht)  verfügbare Werkzeuge mehr oder weniger viele Verwendungsmöglichkeiten bieten. So sind der Ressourcenbedarf und der Nutzen stark von der Kundenlandschaft und der Projektsituation geprägt. Umgekehrt versucht die SAP, ihren „höherwertigen“ Enterprise Support durch neuere Tools wie das Custom Development Management Cockpit aufzuwerten. Hierzu muss sich noch zeigen, ob diese „Premium“-Strategie der richtige Weg ist.

Fazit: Tools, die Support unterstützen, in den Fokus nehmen

Der Solution Manager kann sehr minimalistisch als Werkzeug für eine zentrale Systemadministration verwendet werden. Darüber hinaus empfiehlt sich sein Einsatz auch für das Anwendungsmanagement auf Kundenseite. Und zwar in jenen Bereichen, die ausgereift sind. Letztlich stellt der Solution Manager das Bindeglied zwischen der SAP-Support-Organisation und dem Kundensystem dar. Aus diesem Grund sollten Anwenderunternehmen jene Funktionen, die diese Verfahren unterstützen, in den Vordergrund rücken. Dazu gehört auch der Aufbau der Prozessstruktur auf Basis des Business Process Repository. SAP wagt mit dem Solution Manager den Versuch, seinen Kunden den Zugang zu vielen neuen Funktionen zu bieten. Die etwas „jüngeren“ Werkzeuge machen jedoch noch den Eindruck von „Laboranwendungen“. Da die Nutzung dieser Funktionen mit Einführungs- und Pflegekosten verbunden ist, sollten sich SAP-Anwenderunternehmen bei deren Einführung noch Zeit lassen, bis erste positive Erfahrungsberichte vorliegen. Der Projekteinsatz des Solution Managers kann aus dem operativen Betrieb heraus als „kleines“ Dokumentationsprojekt erfolgen oder mag als Projektaufgabe in das nächste Upgrade- oder Erweiterungsprojekt einbezogen sein. Der Projekteinsatz sollte in keinem Fall „überdehnt“ werden. Denn der Solution Manager ist und bleibt die Dampfmaschine des Anwendungsmanagements. Und eine solche entwickelt nur dann einen optimalen Wirkungsgrad, wenn die einzelnen Arbeitsphasen genau gesteuert und im Blick behalten werden. Wir wollen doch keine Kohle verschwenden!