10 Optimize-Phase Change Request Management

Transkript

1 Die während des Betriebs der Lösung erhobenen Kennzahlen und Daten können Sie in der Optimize-Phase dazu verwenden, Kosten zu senken oder die Performance zu steigern. Wichtig ist, dass alle Änderungen nachvollziehbar in der Lösung vorgenommen werden. In diesem Kapitel wird die Funktionsweise des Change Request Managements, der Upgrade- Unterstützung sowie des Konzern-Roll-out erläutert. 10 Optimize-Phase Während der Optimize-Phase im laufenden Betrieb stellen Sie sicher, dass Änderungen geplant und konsistent durchgeführt werden. Der SAP Solution Manager unterstützt Sie dabei durch das Change Request Management. Auch im Fall tiefgreifender Veränderungen, wie beim Upgrade einer Softwarekomponente Ihrer Lösung, enthält der SAP Solution Manager Funktionen, die eine professionelle Realisierung anhand von in der Praxis erprobten Vorgehensweisen ermöglichen. Eine weitere Anforderung in der Optimize-Phase kann aber auch die Verteilung einer in der Unternehmenszentrale definierten Vorlage an Niederlassungen sein. Hier bietet der SAP Solution Manager die Funktion Konzern-Roll-out an Change Request Management Einer der entscheidenden Faktoren, Qualität und Transparenz einer Software-Lösung sicherzustellen und IT-Standards zu erfüllen, ist die Nachvollziehbarkeit von Änderungen. Dies bezieht sich auf Software-Änderungen ebenso wie auf Änderungen der Konfiguration. Dieser Abschnitt wird aufzeigen, wie der SAP Solution Manager Sie dabei unterstützt, diese Anforderungen durch klar geregelte Prozessabläufe und eine lückenlose Dokumentation umzusetzen. Der SAP Solution Manager bietet hierzu einen Genehmigungsworkflow, der individuell angepasst werden kann, und dokumentiert alle Tätigkeiten, die während der Implementierung einer Änderung von der Nachvollziehbarkeit 425

2 10 Optimize-Phase Anforderung bis hin zur technischen Realisierung durchgeführt werden. Dies ermöglicht es dem Kunden, jederzeit nachzuvollziehen, woher eine Anforderung kam, wer sie umsetzte und wann die Änderung in eine produktive Umgebung eingespielt wurde. Ein wesentlicher Aspekt hierbei ist, dass an einer zentralen Stelle alle relevanten Informationen zur Verfügung stehen und jederzeit abgerufen werden können. Innerhalb eines Projekts können alle Änderungen, die innerhalb eines bestimmten Zeitraums realisiert werden sollen, geplant und kontrolliert umgesetzt werden. Auch Änderungen, die außerhalb eines Projektplans auftreten und eine schnelle Lösung erfordern (so genannte Dringende Korrekturen), z. B. wenn ein Fehler auftritt, der eine Produktivumgebung gefährdet, können hier wohldokumentiert und effizient behoben werden. Projektplan Integration von Change Request Management und Transportaufträgen Alle Änderungen, die im Rahmen eines Projekts realisiert werden sollen, können in einem Projektplan in cprojects (siehe Abschnitt 6.3) erfasst und geplant werden. Eine Ressourcenplanung ist ebenso verfügbar wie die Anbindung an das Backend, z. B. CATS (Cross-application Time Sheet) zur Rückmeldung von Tätigkeiten. Änderungsanträge, die das Genehmigungsverfahren durchlaufen haben, können hier eingeplant werden. Dieser Projektplan ist mit dem Projekt, das in einem so genannten Projektzyklus mehrere Projektphasen durchläuft, in den SAP Solution Manager integriert. Die Phasen werden zentral aus dem SAP Solution Manager heraus kontrolliert und geben Rahmenbedingungen vor, die nicht umgangen werden können. Dies wird im Folgenden (siehe hierzu auch Abschnitt ) weiter erläutert. Der SAP Solution Manager schließt hier eine Lücke, die sich in vielen Change-Management-Lösungen ergibt: Wenn Change-Management- Prozesse z. B. über Datenbanken oder Listen abgebildet und hier alle Änderungsanträge und deren Genehmigungen protokolliert werden, ist spätestens dann ein manueller Schritt notwendig, wenn ein Transportauftrag erzeugt oder eingespielt werden muss. Die Nummer des Transportauftrags muss manuell in die Datenbank übertragen werden, was eine potenzielle Fehlerquelle darstellt. Ein Tippfehler oder ein Fehler beim Kopieren entwertet den gesamten Prozess. Im Change Request Management werden Transportaufträge zentral aus dem SAP Solution Manager heraus erzeugt, und bei der Erzeugung wird immer automatisch eine Referenz zum jeweiligen Änderungs- 426

3 Change Request Management 10.1 antrag angelegt (darüber hinaus werden auch dessen ID und Kurztext in die Bezeichnung des Transportauftrags aufgenommen), so dass eine klare Zuordnung jederzeit möglich ist. Das Change Request Management bietet darüber hinaus die Möglichkeit, alle Transporte im Rahmen eines Projekts nachzuverfolgen, zu kontrollieren, in welchen Systemen sie erzeugt und in welche Systeme sie eingespielt wurden. Durch den SAP Solution Manager kann zentral in die Transportprotokolle und die Importqueue, aber auch in das Wartungsprojekt des SAP Solution Manager, den Projektplan (cprojects) und die angeschlossenen Systeme navigiert werden. Auch Änderungen, die keinen Transportanschluss erfordern, können über das Change Request Management erfasst werden. Hier wird, wie bei allen Änderungen, ein Änderungsantrag gestellt, der alle Genehmigungsschritte durchläuft. Im Änderungsantrag selbst werden die Schritte dokumentiert, die zur Realisierung nötig sind. Der SAP Solution Manager stärkt somit SAP in ihrer Vision des Application Managements und der IT-Governance, indem er Funktionen zur Verfügung stellt, die unabdingbar sind, um eine transparente Implementierung und Betriebsführung einer Lösung zu garantieren. Dies bildet eine Grundlage vieler regulatorischer Bestimmungen. Die Fragen, wer was wann getan und wer kontrolliert und die Genehmigung erteilt hat, lassen sich so beantworten. Änderungen ohne Transportanschluss Um den Betrieb einer Systemlandschaft unter sich ständig ändernden Anforderungen garantieren zu können, müssen folgende Gesichtspunkte berücksichtigt werden: Änderungsanträge, ob sie aus Fehlermeldungen resultieren oder im Rahmen eines Ideenmanagements direkt erzeugt werden, müssen von einer zentralen Stelle klassifiziert und genehmigt werden. Ist ein solcher Antrag genehmigt, müssen die Durchführung der Änderung, deren Transport in Folgesysteme (Qualitätssicherung und Produktion) und ihr Test sichergestellt sein. Eine lückenlose Dokumentation beinhaltet darüber hinaus alle für die Änderung relevanten Informationen sowie Daten über alle beteiligten Personen. Darüber hinaus muss der Status eines Änderungsantrags zu jeder Zeit nachvollziehbar sein. 427

4 10 Optimize-Phase Integrierte Teams ITIL Ebenso wichtig ist die Integration von Menschen im Unternehmen, wobei die Prozessorientierung des SAP Solution Manager einen wichtigen Beitrag leistet, die Kommunikation zwischen Fachabteilung und IT-Administratoren sicherzustellen. Alle an einer Änderung beteiligten Personen haben jederzeit Zugriff auf alle relevanten Informationen, wie z. B. Anforderungen, Spezifikationen, Dokumentation, Testfälle, Testergebnisse oder Statusanalysen, die anhand der Strukturen im SAP Solution Manager gegliedert und zentral verfügbar sind. SAP orientiert sich mit diesem Angebot an den Prozessen der IT Infrastructure Library (ITIL, siehe Kapitel 2). Ziel des Change Managements ist, laut ITIL, die wirtschaftliche und termingerechte Durchführung von Änderungen mit minimalem Risiko. Das Szenario Change Request Management umfasst die Prozesse Verwaltung von Änderungsanträgen, Projektmanagement und Änderungslogistik (siehe Abbildung 10.1). SAP Solution Manager Verwaltung von Änderungsanträgen Projektmanagement Änderungslogistik Management aller Änderungsanträge Änderungsantrag kategorisieren Änderung dokumentieren Workflow für Genehmigung Statusberichte Vollständige Änderungshistorie Projektplanung Projekt dokumentieren Customizing und Entwicklung (Spezifikationen) Test Management Customizing und Entwicklung (Realisierung) Testausführung Nahtlose Integration in TMS Transport einplanen Transport nachverfolgen Abbildung 10.1 Prozesse des Change Request Managements im Überblick Verwaltung von Änderungsanträgen Szenario Ein Sachbearbeiter in der Fachabteilung entdeckt einen Änderungsbedarf in einer Transaktion, mit der er arbeitet. Er kann nun direkt aus der Transaktion eine Support-Meldung erfassen, in der er den Sachverhalt beschreibt, und eine Änderung anfordern. Die Meldung 428

5 Change Request Management 10.1 erscheint daraufhin im Arbeitsvorrat eines Service-Desk-Mitarbeiters, der die Meldung bearbeitet und gegebenenfalls einen Änderungsantrag (Change Request) erzeugt (siehe Abschnitt 9.5). Dieser Change Request wird nun vom System zur zentralen Rolle des Szenarios, dem Change Manager, weitergeleitet. Der Change Manager ist dafür verantwortlich, den Antrag zu bewerten, ihn zu kategorisieren und zu genehmigen oder ggf. abzulehnen. Genehmigt er den Antrag, wird automatisch ein Änderungsdokument (Change Document) erzeugt. Das Änderungsdokument bildet in den folgenden Arbeitsschritten die operative Grundlage für Entwickler, Tester und IT- Administratoren. Der Change Manager greift nach erfolgreichem Ablauf der im Folgenden beschriebenen Prozesse wieder ein und schließt den Change Request ab. Das Änderungsdokument erscheint im Arbeitsvorrat eines Entwicklers, der die Änderung implementiert und zum Testen freigibt, womit sie dem Tester übergeben wird. Erst nach erfolgreichem Test kann die Änderung ins Produktivsystem transportiert werden. Im Rahmen des Projektmanagements stellt der SAP Solution Manager seine bewährten Projektverwaltungsfunktionen zur Verfügung. Darüber hinaus beinhaltet das Change Request Management ab Release 3.2 cprojects, die Projektmanagement-Software der SAP. Ein Alleinstellungsmerkmal des Change Request Managements ist es, dass die Änderungen nicht nur verwaltet, sondern auch geprüft und nachvollziehbar durch die Systemlandschaft transportiert werden. Hierbei bietet der SAP Solution Manager Unterstützung beim Planen von Tätigkeiten eines IT-Administrators und ermöglicht z. B. eine automatische Kontrolle von Importreihenfolgen und Tracking von Transporten. Auf diese Weise rundet die Änderungslogistik das Szenario Change Request Management ab. Projektmanagement Änderungslogistik Architektur Um die Architektur des Change Request Managements im SAP Solution Manager zu verstehen, ist es zunächst wichtig, die Zusammenhänge zwischen den verwendeten Entitäten zu klären. Ein optionaler Teil, der für das Change Request Management eingesetzt werden kann, ist cprojects (siehe Abschnitt 6.3). cprojects stellt den Projektplan bereit, fasst alle Phasen, Aufgaben und deren Status cprojects 429

6 10 Optimize-Phase zusammen. Das cprojects-projekt steht in einer 1:1-Beziehung zu einem SAP-Solution-Manager-Projekt. Der zentrale Teil des Change Request Managements ist das SAP-Solution-Manager-Projekt (siehe Abschnitt 6.2) im SAP Solution Manager. Das Projekt enthält folgende Informationen: Logische Komponenten Dies beinhaltet die Systemlandschaft und, damit verbunden, die Transportwege, die vom Change Request Management verwendet werden sollen. IMG-Projekt Das IMG-Projekt wird aus der Projektverwaltung des SAP Solution Manager (Transaktion SOLAR_PROJECT_ADMIN) in Satellitensystemen angelegt, um Einstellungen, die über den SAP-Einführungsleitfaden (IMG) für ein SAP-Solution-Manager-Projekt vorgenommen werden, in einem System zu bündeln. CTS-Projekt Das CTS-Projekt stellt einen Container in einem logischen System (Kombination System und Mandant) dar, der Transportaufträge zusammenfasst, die zu einem IMG-Projekt gehören. Das Change-Request-Management-Szenario unterstützt alle Projektarten des SAP Solution Manager, also Implementierungs-, Upgrade-, Vorlagen- und Wartungsprojekte. SAP Solution Manager Change Request Management Entwicklungssysteme Logische Systeme (Mandanten) Change Document Projektzyklus Transportaufträge Change Request Aufgabenplan IMG- Projekt CTS- Projekt Q P Projektplan SAP-Solution- Manager- Projekt IMG- Projekt CTS- Projekt Q P cprojects Abbildung 10.2 Beziehungen zwischen cprojects, SAP-Solution-Manager-Projekten und Systemen im Change Request Management 430

7 Change Request Management 10.1 Eine Übersicht über alle im Projekt verwendeten Objekte erhalten Sie in der Transaktion Projektlogistik (/TMWFLOW/PROJ). Hier können Sie auf der Registerkarte Projektstruktur die Zusammenhänge auf einen Blick sehen (siehe Abbildung 10.3): Projektlogistik SAP-Solution-Manager-Projekt Projekt- oder Wartungszyklus Aufgabenplan zugeordnetes cprojects-projekt IMG-Projekt CTS-Projekt und die dafür erfassten Transportaufträge Abbildung 10.3 Transaktion Projektlogistik (/TMWFLOW/PROJ) In Abhängigkeit davon, welche Einstellungen der Change Manager im Change Request vor der Genehmigung vornimmt, sind zwei Arten von Change-Request-Management-Zyklen (Projektzyklus und Wartungszyklus) verfügbar, die sich auf Grund der unterschiedlichen Anforderungen im Ablauf unterscheiden und daher im Folgenden näher beleuchtet werden. 431

8 10 Optimize-Phase Projektzyklus für Entwicklungsprojekte Zur Unterstützung von Implementierungs-, Upgrade- und Vorlagenprojekten über das Change Request Management bietet der SAP Solution Manager den Projektzyklus an. Der Projektzyklus ist ein vorkonfigurierter Servicevorgang (Vorgangsart SDDV, siehe Abbildung 10.4), mit dem Sie über die Projektlaufzeit folgende Tätigkeiten steuern: Änderungsanträge und die daraus resultierenden Änderungen in den Systemen, die in Ihrem Projekt verwendet werden die Transportaufträge, die benötigt werden, um die Änderungen in die Folgesysteme zu transportieren die komplette Änderungslogistik, d.h., wann welche Transporte in die Folgesysteme importiert werden können cprojects SAP-Solution-Manager-Projekt (Imp./Upgrade/Vorlage) Projektbeginn Projektzyklus Entwicklung Test Vorbereitung für Go-live Go-live Projektende Harmonisierung Normale Korrekturen Harmonisierung Harmonisierung Testmeldungen (während Intergrationstest) Abbildung 10.4 Rolle des Projektzyklus für Implementierungs-, Upgrade- und Vorlagenprojekte Phasen des Projektzyklus Der Projektzyklus bietet durch seine Phasenstruktur eine operative Ergänzung zum Projektplan. Ein einzelner Projektzyklus umfasst folgende Phasen: Entwicklung ohne Freigabe Entwicklung mit Freigabe Test Vorbereitung für Go-live (Notkorrektur) Go-live 432

9 Change Request Management 10.1 Nach der Go-live-Phase schließen Sie den Projektzyklus ab. Ein Sonderfall des Projektzyklus ist der Wartungszyklus, bei dem ein mehrmaliges Durchlaufen der Phasen möglich ist (siehe Abschnitt ). In der Phase Entwicklung ohne Freigabe kann ein Transportauftrag zwar erzeugt, aber nicht freigegeben werden. Die Freigabe kann erst erfolgen, nachdem die Phase Entwicklung mit Freigabe erreicht ist. Sie wird von einem zentralen Gremium (Change Advisory Board oder Change Manager) eingeleitet und erlaubt, Transporte freizugeben und in die Testumgebung zu importieren. Nachdem die Änderungen des Projekts in die Testumgebung eingespielt wurden, kann die Test- Phase eröffnet werden, um den Integrationstest zu ermöglichen. Nun können keine neuen Änderungsanträge für dieses Projekt angelegt werden, es werden nur noch Fehler beseitigt, die im Test aufgetreten sind. Die Phase Vorbereitung für Go-live erlaubt es Benutzern mit entsprechender Berechtigung, weitere notwendige Änderungen durchzuführen, bevor die Änderungen in der Go-live-Phase in die produktive Umgebung importiert werden. Es können jedoch keine Änderungen importiert werden, die nicht vorher in der Test-Phase erfolgreich getestet wurden Änderungsantrag (Change Request) Dem Zyklus können nun beliebig viele Änderungsanträge zugeordnet werden. Der Änderungsantrag (Vorgangsart SDCR) ist, ähnlich wie die Support-Meldung, ein vorkonfigurierter Servicevorgang, der alle Daten enthält, die für die Änderung relevant sind. Unter anderem sind dies Auftraggeber Anforderer Change Manager Change Advisory Board von der Änderung betroffenes System (Installation/Komponente) Priorität Änderungsart (Sachverhalt) Texte, die die Kommunikation sicherstellen Beschreibung der Änderung Grund der Änderung 433

10 10 Optimize-Phase Auswirkungen auf Geschäftspartner Auswirkungen auf Systeme Änderungsantrag intern Änderungsantrag Antwort Änderungsarten Je nach der im Feld Sachverhalt ausgewählten Änderungsart legt das System beim Genehmigen des Änderungsantrags automatisch einen Folgevorgang an. Ein Projektzyklus unterstützt vier Änderungsarten, anhand derer der Change Manager Änderungsanträge klassifizieren kann: Normale Korrektur Als Normale Korrekturen werden Anträge wie z. B. das Einspielen von Support Packages oder von Hinweisen klassifiziert, also Tätigkeiten, die im Rahmen der regulären Systemwartung anfallen. Projektantrag Ein Projektantrag betrifft eine größere Änderung an einer Systemlandschaft, wie z. B. die Implementierung einer neuen Lösung oder das Upgrade einer bestehenden Lösung. Testmeldung Eine Testmeldung dient dazu, Fehler, die während der Testphase auftreten, an die Entwicklung zu melden. Administrationsmeldung Eine Administrationsmeldung betrifft Änderungen, die keinen Transportanschluss erfordern, also z. B. Änderungen an Nummernkreisen. Das Change Request Management bildet also vom Einholen der Anforderungen über die Implementierung, das Testen, die Betriebsführung und kontinuierliche Verbesserung einer Lösung den kompletten Lebenszyklus ab. Das Szenario ist in die umfassenden Funktionen des SAP Solution Manager, wie Service Desk, E-Learning Management oder Upgrade-Support, integriert. Transportsteuerung Zur Transportsteuerung verwendet das Change Request Management die Transportmethode IMPORT_PROJECT_ALL, d.h., in der Konfiguration des Change Request Managements muss die Transportmethode IMPORT_ALL durch IMPORT_SINGLE ersetzt werden. Dies hat den Vorteil, dass Sie projektbezogen arbeiten können und die Transportaufträge am Ende der Zyklusphasen harmonisiert und 434

11 Change Request Management 10.1 konsolidiert in der Reihenfolge ihrer Freigabe in die Folgesysteme eingespielt werden. Diese Vorgehensweise minimiert das Risiko von so genannten Überholern im Transportwesen. Am Ende des Projekts können Sie die gesammelten Änderungen in die produktiven Systeme importieren und das Projekt abschließen Aufgabenplan Der Aufgabenplan im Change Request Management stellt das technische Rückgrat aller Änderungsprozesse dar. Alle Systeme und die notwendigen Aufgaben sind hier zusammengefasst und werden in der korrekten Abfolge angezeigt. Alle Aufgaben, die Sie über die Benutzeroberfläche der Korrekturen oder des Projektzyklus im SAP Solution Manager über Aktionen ausführen (Systemanmeldung, Transportauftrag anlegen, Transportauftrag importieren etc.), sind hier hinterlegt. Technischer Ablaufplan Jedem Projektzyklus ist ein Aufgabenplan zugeordnet, der für Systemadministratoren ein wertvolles Werkzeug zur Transportsteuerung und -einplanung darstellt, da Aufgaben einfach per Drag & Drop in der Tagesübersicht eingeplant werden können (siehe Abbildung 10.5). Abbildung 10.5 Aufgabenplan des Change Request Managements 435

12 10 Optimize-Phase Statusschema Angelegt Änderungsarten in Entwicklungsprojekten Normale Korrektur Die Normale Korrektur (Vorgangsart SDMJ) bildet die Korrekturmaßnahmen eines Projekts ab und folgt dem Statusschema In Entwicklung Entwicklung abgeschlossen Erfolgreich getestet Produktiv Zurückgezogen Im Folgenden wird der Prozess, den eine Normale Korrektur durchläuft, im Detail erläutert. Prozessbeschreibung Ein Anwender entdeckt beim Arbeiten in einem System fehlende Funktionen. Er kann diese Störung direkt aus der Transaktion, in der er sich befindet, über eine Support-Meldung an den SAP Solution Manager melden. Die Support-Meldung beinhaltet alle relevanten Systemdaten und die Beschreibung der Anforderung. Der Service-Desk-Mitarbeiter, der die Support-Meldung bearbeitet, stellt fest, dass die Anforderung nur über einen Change Request realisiert werden kann, und legt im Service Desk über die Aktion Änderungsantrag erstellen einen entsprechenden Change Request an. Der Änderungsantrag erscheint im Arbeitsvorrat des Change Manager (Transaktion CRM_DNO_MONITOR), der eine Klassifizierung des Change Request durchführt, festlegt, wie die Änderung durchgeführt werden soll (Normale Korrektur), und sie genehmigt oder ablehnt. Bei der Bewertung spielt die Priorität des Änderungsantrags eine wichtige Rolle. Wird der Änderungsantrag als Normale Korrektur genehmigt, erzeugt der SAP Solution Manager automatisch einen Änderungsvorgang vom Typ Normale Korrektur. Der Änderungsantrag und die Korrektur sind über den Dokumentenfluss verbunden, und die Zuordnung ist jederzeit transparent. Der Änderungsvorgang bildet die operative Grundlage für Entwickler, Tester und Systemadministratoren ab. Zunächst wird der Ent- 436

13 Change Request Management 10.1 wickler benachrichtigt, dass eine neue Korrektur zur Bearbeitung vorliegt. Er übernimmt die Korrektur und setzt den Status über eine Aktion auf In Entwicklung. Der Entwickler legt im Entwicklungssystem einen Transportauftrag an, meldet sich direkt am Entwicklungssystem an und gibt nach erfolgter Korrektur die Transportaufgaben im Entwicklungssystem (Transaktion SE09) frei. Die Freigabe des Transports ist im Change Request Management nur aus einer Korrektur oder dem Aufgabenplan möglich. Wenn der Änderungsvorgang erfolgreich abgeschlossen ist und alle entsprechenden Transportaufträge freigegeben wurden, setzt der Entwickler den Status auf Korrektur abgeschlossen. Alle beschriebenen Tätigkeiten können direkt aus dem Änderungsvorgang über Aktionen ausgeführt werden. Die neu entwickelte Funktion wird während eines regulären Imports des Projektpuffers über den Aufgabenplan in ein Testsystem importiert und dort entweder zunächst einem Unit Test oder direkt in den Integrationstest übergeben. Ein Tester prüft die Änderung. Hierzu stehen ihm alle benötigten Funktionen, wie z. B. Systemanmeldung, aber auch alle Informationen zum Änderungsvorgang, also die komplette Änderungshistorie, zentral zur Verfügung. Das Change Request Management bietet ein Vier-Augen-Prinzip an, d.h., Sie können einstellen, dass der Entwickler und der Tester nicht dieselbe Person sein dürfen. Ein Tester setzt nach erfolgreichem Test den Status des Änderungsvorgangs auf Test erfolgreich abgeschlossen, um anzugeben, dass die neue Funktion getestet wurde und in das Produktivsystem importiert werden kann. Zum Einspielen der Änderungen in die produktiven Systeme sind folgende Voraussetzungen zu beachten: Einspielen der Änderungen Der Systemadministrator kann die Änderung nur in das Produktivsystem importieren, wenn sich der entsprechende Projektzyklus in der Go-live-Phase befindet. Der Status kann nur auf Produktiv gesetzt werden, wenn alle Normalen Korrekturen des Projekts erfolgreich in die produktiven Systeme importiert wurden. Sie können diesen Status für alle importierten Normalen Korrekturen am Ende eines Projektzyklus setzen, indem Sie den Job CRM_SOCM_SERVICE_REPORT einplanen. 437

14 10 Optimize-Phase Normale Korrekturen, deren Status noch In Entwicklung lautet, lösen im betreffenden Projektzyklus eine Warnmeldung aus, wenn der Status während der Testphase gesetzt wird. Change Request SDCR Normale Korrektur SDMJ Projektzyklus SDDV Testmeldung SDTM Testmeldung Testmeldungen (Vorgangsart SDTM) können Sie nur während der Testphase des Projektzyklus anlegen. Da die Testmeldung während des Integrationstests genutzt wird und sich dieser Test auf das gesamte Projekt (also alle Korrekturen) bezieht, hat sie keinen Bezug zu einer einzelnen Korrektur oder einem Änderungsantrag. Sie dient dazu, einen während des Tests identifizierten Fehler an die Entwicklung zu melden, und erlaubt dem verantwortlichen Entwickler, den Fehler über einen Transportauftrag zu korrigieren. Da der Umfang des Projekts über die Änderungsanträge genehmigt wurde, beinhaltet die Testmeldung keine Genehmigungsschritte. Sie folgt dem Statusschema Statusschema Angelegt SAP-Solution-Manager- Projekttyp: Implementierungsprojekt Administrationsmeldung SDAD Upgrade-Projekt Vorlagenprojekt Abbildung 10.6 Änderungsarten in Entwicklungsprojekten In Bearbeitung Nachzutesten Bestätigt Zurückgezogen 438

15 Change Request Management 10.1 Die Testmeldung ist notwendig, da in der Testphase keine neuen Korrekturen angelegt werden können, denn dies würde den definierten Umfang des Projekts verzerren. Ein Tester legt eine Testmeldung an und beschreibt die aufgetretenen Symptome. Ein Entwickler bearbeitet die Meldung, kann einen oder mehrere Transportaufträge anlegen und den Fehler im Entwicklungssystem korrigieren. Um die Änderung zum erneuten Test vorzulegen, setzt der Entwickler den Status Testmeldung erneut prüfen. Nach erneutem Import des Transportpuffers in das Testsystem überprüft der Tester die Funktionen, bestätigt den Testerfolg mit dem Status Bestätigt und setzt den Status der Normalen Korrektur auf Erfolgreich getestet. Administrationsmeldung Eine Administrationsmeldung (Vorgangsart SDAD) dient dazu, Änderungen, die keine Transporte erfordern, wie z. B. Änderungen an Nummernkreisen oder Benutzerdaten, abzubilden, aber dennoch die komplette Änderungshistorie zu bewahren. Die Administrationsmeldung bietet Zugang zum Aufgabenplan und zu Aktivitäten, wie z. B. einer Systemanmeldung, und hat folgendes Statusschema: Angelegt In Bearbeitung Erledigt (Entwicklung abgeschlossen) Erfolgreich getestet Produktiv Bestätigt Abgeschlossen Zurückgezogen Statusschema Arbeiten mit Projektzyklen Der Projektleiter legt ein Projekt im SAP Solution Manager an (Implementierungs-, Upgrade- oder Vorlagenprojekt) und generiert zu diesem Projekt die IMG- und CTS-Projekte sowie einen Projektzyklus. Der Systemadministrator aktiviert den entsprechenden Aufgabenplan. Zu diesem Zeitpunkt können Sie bereits Änderungsanträge Projektvorbereitung 439

16 10 Optimize-Phase anlegen, klassifizieren und genehmigen. Damit legen Sie in dieser Phase bereits den Umfang an Änderungen fest, der in diesem Projekt umgesetzt werden soll. Bei der Genehmigung ordnet der SAP Solution Manager die daraus resultierenden Korrekturmaßnahmen dem Projektzyklus zu. Falls mehrere Projekte gleichzeitig bearbeitet werden, existiert mehr als ein Projektzyklus. In diesem Fall wird bei der Genehmigung erfragt, welchem Zyklus Sie die Korrektur zuordnen möchten. Entwicklung ohne Freigabe Entwicklung mit Freigabe Der Change Manager setzt den Status des Projektzyklus auf Entwicklung ohne Freigabe. Wenn dieser Status gesetzt ist, können Korrekturen von den Entwicklern bearbeitet und im System entwickelt werden. Die Entwickler können Transportaufträge und Transportaufgaben anlegen, können diese jedoch nicht freigeben und auch nicht exportieren. Wenn der Change Manager den Status des Projektzyklus von Entwicklung ohne Freigabe in Entwicklung mit Freigabe ändert, können die Entwickler ihre Transportaufträge aus einer Korrektur heraus freigeben. Der Systemadministrator verwendet den Aufgabenplan zum Import aller freigegebenen Korrekturen in die Testsysteme. In vielen Fällen existieren in den Entwicklungssystemen keine Stamm- oder Bewegungsdaten, die den Entwicklern erlauben, die von ihnen entwickelten Korrekturen zu testen. Diese benötigten Daten sind oft nur im Testsystem verfügbar. Daher besteht in dieser Phase des Projektzyklus die Möglichkeit, vor dem Integrationstest Zeit für Entwicklertests (Unit Tests) einzuplanen, d.h. einen Zeitraum, in dem die Entwickler die Korrekturen nach dem Import in die Testsysteme selbst prüfen können, um anschließend den Status ihrer Korrekturen auf Entwicklung abgeschlossen zu setzen. Test Voraussetzung für die Testphase ist es, dass alle Korrekturen im Status Entwicklung abgeschlossen vorliegen. Ist dies nicht der Fall, meldet das System beim Phasenwechsel einen Fehler und setzt den Status zurück auf Entwicklung mit Freigabe. In dieser Phase können keine neuen Korrekturen angelegt werden, da dies eine Erweiterung des Projektumfangs im laufenden Projekt bedeuten würde. Ist eine neue Korrektur notwendig, ist es daher nötig, die Phase des Projektzyklus zurück auf Entwicklung mit Freigabe zu setzen. 440

17 Change Request Management 10.1 In der Testphase können Tester die Korrekturen auf funktionale und fachliche Richtigkeit überprüfen. Findet ein Tester einen Fehler, kann er diesen über eine Testmeldung dokumentieren und den betreffenden Entwickler auf den Fehler aufmerksam machen. Über die Testmeldung kann ein Entwickler im Entwicklungssystem einen neuen Transportauftrag anlegen und den Fehler bereinigen. Die Testphase gilt als abgeschlossen, wenn alle Korrekturen und Testmeldungen im Status Erfolgreich getestet vorliegen, Änderungen können nicht vom Test ausgenommen werden, d.h., sie müssen entweder erfolgreich getestet oder zurückgenommen werden. Wenn nach Abschluss der Testphase weitere Änderungen vorgenommen werden müssen, können Transportaufträge und -aufgaben im Rahmen der Notkorrekturphase zwar angelegt, freigegeben und transportiert werden, jedoch nur über den Aufgabenplan des Projektzyklus und mit entsprechenden Berechtigungen. In der Go-live-Phase wird der gesamte Transportpuffer des CTS-Projekts in der Reihenfolge der Freigabe in die Produktivsysteme importiert. Während dieser Phase können keine Transportaufträge angelegt oder freigegeben werden. Nach dem Import in die produktive Systemumgebung existieren keine offenen Transportaufträge mehr, und der Transportpuffer ist leer. Sie können nun den Projektzyklus abschließen, indem Sie den Status auf Bestätigt setzen. Damit ist das Projekt beendet. Notkorrektur (Vorbereitung für Go-live) Go-live Unterschiede zwischen Wartungszyklus und Projektzyklus Der Wartungszyklus ist ein Projektzyklus, der auf die speziellen Anforderungen von Wartungsprojekten hin erweitert wurde. Im Gegensatz zu einem Entwicklungsprojekt hat ein Wartungsprojekt zwar einen definierten Beginn, die Wartung ist aber ein kontinuierlicher Prozess, der stets fortgeführt wird. Dem Lebenszyklusmodell folgend, verwenden Sie zur Einführung einer Lösung ein Einführungsprojekt des SAP Solution Manager. Das Einführungsprojekt wird erfolgreich abgeschlossen und in den Betrieb überführt. Dazu übernehmen Sie die Daten des Projekts in eine Lösung (siehe Abschnitt 8.1). Um diese Lösung aktuell zu halten, ordnen Sie ihr ein Wartungsprojekt mit einem Wartungszyklus zu. 441

18 10 Optimize-Phase cprojects SAP-Solution-Manager-Projekt (Wartungsprojekt) Wartungszyklus Entwicklung Test Vorbereitung für Go-live Go-live Harmonisierung Wartungsmaßnahmen Harmonisierung Harmonisierung Testmeldungen (während Intergrationstest) Dringende Korrekturen (unabh. vom Wartungszyklus) Abbildung 10.7 Rolle des Wartungszyklus in Wartungsprojekten Phasenmodell Der Wartungszyklus folgt demselben Phasenmodell wie der Projektzyklus, verfügt jedoch über einige Besonderheiten. Zum einen existiert für den Wartungszyklus eine zusätzliche Korrekturart (Dringende Korrektur), die es ermöglicht, schnelle Korrekturen flexibel durchzuführen (siehe Abschnitt ). Zum anderen empfehlen wir für das Arbeiten mit Wartungszyklen eine andere Herangehensweise, um den Anforderungen, die die Wartung einer Lösung stellt, gerecht zu werden: Wir empfehlen, einer Lösung ein Wartungsprojekt zuzuordnen, das so lange läuft, wie die Lösung betrieben wird. Innerhalb des Wartungsprojekts werden alle notwendigen Korrekturen über Wartungszyklen abgedeckt. Die Dauer eines Wartungszyklus wird vom Change Manager festgelegt, z. B. ein Monat. Während dieser Zeit durchläuft der Zyklus alle Projektphasen von Entwicklung ohne Freigabe bis Go-live. Am Ende der Go-live-Phase schließen Sie den Zyklus nicht ab, sondern setzen seinen Status zurück auf Entwicklung ohne Freigabe, um einen erneuten Zyklus zu beginnen. Es han- 442

19 Change Request Management 10.1 delt sich hierbei technisch immer um denselben Wartungszyklus, der mehrfach durchlaufen wird. Die Vorteile dieser Vorgehensweise zeigen sich an einem Beispiel: Sie haben den Umfang Ihres Wartungszyklus definiert, indem Sie die vorliegenden Änderungsanträge bewertet und genehmigt haben. Zehn Normale Korrekturen sind für den laufenden Wartungszyklus (z. B. Oktober 2006) genehmigt worden. In der Entwicklungsphase stellt sich heraus, dass eine der Normalen Korrekturen, Korrektur Nummer neun, nicht in der für die Phase anberaumten Zeit realisiert werden kann. Beispiel Als Projektleiter stehen Ihnen zwei Möglichkeiten offen, mit dieser Verzögerung umzugehen: Zum einen können Sie das Zeitfenster für diese Korrektur vergrößern, um sie im laufenden Wartungszyklus zu realisieren. Wenn Sie jedoch feststellen, dass die Änderung nicht kritisch ist, und keine Abhängigkeiten zu den anderen Korrekturen bestehen, können Sie entscheiden, diese Änderung im nächsten Wartungszyklus November 2006 fertig zu stellen. Hierfür verbleibt die Korrektur im Status In Entwicklung. Die neun anderen Korrekturen durchlaufen die Test- und Go-live-Phasen, werden also in die produktiven Systeme eingespielt. Nun setzen Sie den Status des Wartungszyklus auf Entwicklung ohne Freigabe, und der Zyklus November 2006 beginnt. Sie können den Wartungszyklus bei diesem Vorgehen nicht abschließen, da noch offene Korrekturen existieren. Im nächsten Durchlauf des Wartungszyklus im November wird die Korrektur Nummer neun zusammen mit den neuen Korrekturen konsolidiert eingespielt. Dies stellt einen Unterschied zum Projektzyklus dar. Wenn Normale Korrekturen vorhanden sind, deren Status bei Änderung der Wartungszyklusphase von Entwicklung mit Freigabe in der Testphase noch nicht Entwicklung abgeschlossen lautet, gibt das System nur eine Warnmeldung aus. Diese Korrekturen werden daraufhin vom Integrationstest ausgeschlossen und können nicht freigegeben werden. Diese Vorgehensweise hat noch einen anderen Vorteil. Schon während der Testphase des Zyklus Oktober 2006 können Sie Korrekturen für den Zyklus November 2006 genehmigen, und die zuständigen Entwickler können die Korrekturen bereits bearbeiten und Transporte erstellen. Diese Transportaufträge können im Zyklus Oktober 443

20 10 Optimize-Phase 2006 allerdings noch nicht freigegeben werden. So können Sie Engpässe bei der Ressourcenplanung umgehen, da freie Kapazitäten in der Entwicklung schon in der Testphase wieder genutzt werden können. Dringende Korrektur Im Wartungsbetrieb können jederzeit Störungsmeldungen auftreten, die eine schnelle Umsetzung erfordern, z. B. wenn ein Ausfall der produktiven Systeme droht. In diesem Fall können Sie mit einer Normalen Korrektur nicht zeitnah reagieren, da diese von der Phase des Wartungszyklus abhängt, d.h., wenn sich der Wartungszyklus in der Testphase befindet, können Sie keine neuen Korrekturen für diesen Zyklus erfassen. Aus diesem Grund bietet das Change Request Management die Dringende Korrektur an. Change Request SDCR Dringende Korrektur SDHF Normale Korrektur SDMJ Wartungszyklus SDMN Testmeldung SDTM Transportsteuerung SAP-Solution-Manager- Projekttyp: Wartungsprojekt Administrationsmeldung SDAD Abbildung 10.8 Änderungsarten in Wartungsprojekten Dringende Korrektur Dringende Korrekturen verfügen über einen eigenen Aufgabenplan, d.h., sie können unabhängig vom Wartungszyklus transportiert werden. So ist es möglich, Änderungen über eine Dringende Korrektur in die produktiven Systeme zu importieren, bevor die Normalen Korrekturen in der Go-live-Phase des Wartungszyklus eingespielt werden. Hierzu wird die Transportmethode IMPORT_SUBSET verwendet, d.h., die Transportaufträge, die aus einer Dringenden Korrektur generiert worden sind, werden in den Transportpuffer geschrieben 444

21 Change Request Management 10.1 und in die Folgesysteme importiert. Nach dem Import verbleiben sie jedoch im Puffer. Beim regulären Import über den Aufgabenplan des Wartungszyklus wird der gesamte Transportpuffer des Projekts über die Methode IMPORT_PROJECT_ALL konsolidiert importiert, d.h., die Dringenden Korrekturen werden nochmals eingespielt (siehe Abschnitt ). So wird die Konsistenz der Daten sichergestellt. Die Dringende Korrektur folgt dem Statusschema Statusschema Angelegt In Entwicklung Zu testen Erfolgreich getestet Genehmigt für Import Produktiv Bestätigt Abgeschlossen Zurückgezogen In der ausgelieferten Version importiert der SAP Solution Manager die Transportaufträge einer Dringenden Korrektur automatisch in das Testsystem, wenn Sie den Status Zu testen setzen. Diese Einstellung wurde vorgenommen, um den Prozess weiter zu beschleunigen, Sie können diese Einstellung jedoch über Customizing ändern Wartungsprozesse Um die Wartung effizienter zu gestalten, bietet der SAP Solution Manager mit Release 4.0 vordefinierte Wartungsprozesse an, die eine wesentliche Erleichterung für Systemadministratoren bringen. Das System zeigt Ihnen in der Transaktion SOLUTION_MANAGER im Bereich Operations auf der Registerkarte Change Management Support Packages/Stacks eine Liste der Support-Package-Stände der Systeme Ihrer Lösung an. Sie können aus dieser Oberfläche die Support-Package-Stände Ihrer Systeme mit dem Angebot der SAP auf dem SAP Service Marketplace vergleichen, Change Requests für Support Packages anlegen, die Sie einspielen möchten, und diese kontrolliert implementieren. Dies erleichtert es zum einen, für Sie Support Packages/Support Package Stacks 445

22 10 Optimize-Phase relevante Information aus dem breiten Angebot der SAP zu filtern, zum anderen sind über die Wartungsprozesse alle Änderungen stets nachvollziehbar. SAP HotNews SAP HotNews sind SAP-Hinweise mit Priorität 1 (sehr hoch). Diese SAP-Hinweise erklären, wie Sie Probleme vermeiden oder lösen, die zu Datenverlust oder einem Absturz des SAP-Systems führen können. Die für Systeme Ihrer Lösung relevanten SAP HotNews werden proaktiv in der Transaktion SOLUTION_MANAGER im Bereich Operations unter Change Management HotNews angezeigt. Sie können Informationen zu den SAP HotNews im SAP Service Marketplace einsehen eine Entscheidung zu den SAP HotNews zurückstellen, falls eine Abstimmung länger dauert SAP HotNews als nicht relevant kennzeichnen einen Änderungsantrag anlegen, mit dem die SAP HotNews eingespielt werden können SAP Solution Manager beim Ministerium der Finanzen des Landes Brandenburg»Durch den Einsatz des Change Request Managements ist eine signifikante Verringerung der Fehlerquote bei der Beantragung, Umsetzung und Dokumentation von Systemveränderungen nachweisbar.«andreas Altenburg, Ministerium der Finanzen des Landes Brandenburg Ministerium der Finanzen des Landes Brandenburg Die Landesverwaltung Brandenburg stellt eine Flächenverwaltung im Sinne der grundgesetzlich verankerten Strukturen dar. Oberstes Entscheidungsgremium ist das Kabinett, in dem die Fachminister die Umsetzung der zu Beginn der Legislaturperiode vereinbarten Regierungsziele koordinieren und entsprechend an die parlamentarische Ebene berichten. Das gesamte SAP-Projekt Brandenburg beruht auf einer Kabinettsentscheidung aus den Jahren 2002 und Die Landesverwaltung Brandenburg besteht aus zehn Fachministerien, 1 1 Finanzen; Inneres; Justiz; Infrastruktur und Raumordnung; Landwirtschaft, Umweltschutz und Verbraucherschutz; Bildung, Jugend und Sport; Arbeit, Soziales, Gesundheit und Familie; Wissenschaft, Forschung, Kultur; Wirtschaft; Staatskanzlei. 446

23 Change Request Management 10.1 die als oberste Landesbehörden fungieren, und deren nachgeordneten Ressortbereichen, in denen eine Vielzahl oberer, Landesobersowie Landesmittelbehörden organisiert sind. In der Landesverwaltung sind derzeit ca Bedienstete in den verschiedenen Behörden und Einrichtungen tätig. Das Ministerium der Finanzen Brandenburgs befasst sich seit Januar 2002 im Rahmen der Modernisierung des Landesrechnungswesens mit der Einführung betriebswirtschaftlicher Steuerungsinstrumente in den Behörden und Einrichtungen des Landes Brandenburg. Hierzu werden Elemente des externen Rechnungswesens (Doppik, erweiterte Kameralistik), des internen Rechnungswesens (KLR, Controlling) sowie der Logistik, des Instandhaltungsmanagements und des Immobilienmanagements auf Basis von SAP R/3 implementiert. Gleichzeitig verantwortet das Ministerium der Finanzen den Betrieb und die Weiterentwicklung des Systems für alle Nutzer der Landesverwaltung im Rahmen der Funktionen eines Customer Competence Center (CCC). Derzeit betreut das Ministerium der Finanzen ca produktive SAP-Anwender und wird bis zum Jahr 2008 flächendeckend SAP R/3 für die Landesverwaltung einführen und für ca Nutzer betreiben. Die Einführung des SAP Solution Manager stellt eines von ca. 30 Teilprojekten im Rahmen der landesweiten SAP-Einführung im Bundesland Brandenburg dar. Auf Grund der Gesamtsteuerungsfunktion des Leitstandes Rechnungswesen des Finanzministeriums für Einführung und Betrieb des Systems R/3 ergaben sich mit der ersten Produktivsetzungswelle eine Vielzahl von Kommunikations- und Entscheidungsschnittstellen zwischen den anwendenden Bereichen des Systems, dem als CCC fungierenden Leitstand und den betreibenden Rechenzentren des Landes. Der Leitstand initiierte zunächst im November 2004 die Einführung des SAP Solution Manager 3.2 zur Systemüberwachung und Koordinierung des Korrektur- und Transportwesens zwischen Einführungsprojekten und operativem Betrieb. Auf Grund der sehr positiven Erfahrungen entschied der verantwortliche Projektleiter im Oktober 2005, den SAP Solution Manager als führendes Instrument für das gesamte Change Request Management des Anwendungsbetriebs zu implementieren. Gleichzeitig wurde verfügt, am Ramp-Up-Programm der SAP zur Einführung des SAP Solution Manager 4.0 teilzunehmen und bis Juni 2006 Projektübersicht 447

24 10 Optimize-Phase den SAP Solution Manager für alle Prozesse des Betriebs und der Einführungsprojekte (Change Request Management, Service Desk, Service Management) flächendeckend zum Einsatz zu bringen. Besonderheiten im Umfeld öffentlicher Verwaltungen Ausgangssituation Im Gegensatz zu rein privatwirtschaftlich organisierten Unternehmen, in denen die Motivation zur Einführung und Optimierung integrierter Software-Systeme sicher in der Optimierung bestehender Prozesse, der Effizienzsteigerung und der damit verbundenen Realisierung von echten Ressourceneinsparungen zu vermuten sind, hat die Einführung moderner Software-Systeme in der Verwaltung zunächst andere Auslöser. Diskutiert wird hier seit Anfang der 90er Jahre sehr intensiv die Frage nach der Transparenz von Verwaltungshandeln und insbesondere die Frage der effizienteren Mittelverwendung bei Verwaltungstätigkeiten. Die großen Einführungsprojekte betriebswirtschaftlicher Software Ende der 90er Jahre waren daher kaum davon bestimmt, Einführung und Betrieb derartiger Systeme möglichst effizient zu gestalten, sondern von der grundsätzlichen Herausforderung, extrem zergliederte Verwaltungseinheiten und vor allem Fachministerien, die es gewohnt sind, nach dem Prinzip der Ressortzuständigkeit zu handeln, 2 dazu zu bewegen, standardisierte Verfahren und Anwendungen zuzulassen und zu nutzen. Das Land Brandenburg begann relativ spät mit der Einführung von SAP R/3 und ist mit einem jährlichen Haushaltsvolumen von ca. 10 Mrd. Euro eines der kleineren Flächenländer in Deutschland. Allerdings wurde versucht, aus den Einführungserfahrungen anderer Länder zu lernen, um mit möglichst geringem Mitteleinsatz ein flächendeckend anwendbares Ressourcensteuerungssystem zum Einsatz zu bringen. Dies wurde zunächst dadurch sichergestellt, dass das Ministerium der Finanzen als für das Rechnungswesen zuständiges Ressort sowohl die Einführung als auch den daran anschließenden Betrieb des SAP-Systems für alle Behörden und Einrichtungen des Landes an einer zentralen Stelle konzentrierte. Weiterhin wurde im Land entschieden, ein zentral finanziertes Einführungs- und Betriebsmodell für das System auszuwählen. Dies sicherte zunächst eine standardisierte Einführung des Systems in den über 290 Behörden und Einrichtungen des Landes, brachte aber auch nachteilige Aspekte mit 2 Jedes Fachministerium einer Verwaltung entscheidet zu großen Teilen eigenständig darüber, welches Verfahren innerhalb seines Zuständigkeitsbereichs wie eingeführt wird. 448

25 Change Request Management 10.1 sich. Zu nennen wären hier, dass das Einführungsprojekt keinerlei Einflussmöglichkeiten auf etwaige organisatorische oder prozessbedingte Veränderungsbedarfe innerhalb der nutzenden Behörden hatte, da diese in die Zuständigkeit der jeweiligen Ressorts fallen. Weiterhin wirkte sich nachteilig aus, dass das normale Steuerungsinstrument für Systemveränderungen, nämlich die fachliche Begründung eines Bedarfs und die Bereitstellung entsprechender Ressourcen, in Brandenburg so nicht angewandt werden konnte, da die Systemnutzer keinerlei Verantwortung für die Bereitstellung von Ressourcen für die Systemfinanzierung tragen. Außerdem ist gerade im öffentlichen Sektor zu beachten, dass die Vielfalt von Anforderungen an die täglichen Arbeitsroutinen von Verwaltungsbehörden sehr stark von externen Faktoren bestimmt wird und sich daher ein permanenter Anpassungs- und Weiterentwicklungsbedarf an ein softwarebasiertes Ressourcensteuerungssystem ergibt. Großeinsatzlagen der Polizei, Elbehochwasser oder Vogelgrippefälle sind hierbei nur einige Themen, die selbstverständlich eigenständig von Verwaltungen (Laboren, Katastrophenschutz, Sondereinsatzeinheiten etc.) zu bewältigen sind und für die eine entsprechende Ressourcenplanung möglich sein muss. Der Leitstand Rechnungswesen im Finanzministerium sah sich nach der ersten Produktivsetzung des SAP-Systems im Juni 2004 damit konfrontiert, dass täglich eine Fülle von Änderungsanträgen aus den verschiedenen Behörden des Landes eingingen, diese aber größtenteils weder fachlich noch in der Einschätzung der Dringlichkeit ihrer Umsetzung bewertbar waren. Auf Grund seiner Schnittstellenfunktion zwischen Anwendern (Funktion des First und Second Level Supports) und das System betreibenden Rechenzentren (der Leitstand nimmt hier die zentrale Auftraggeberfunktion gegenüber den Rechenzentren wahr) entstand ein akutes Problem, den Überblick über die Anforderungen, die notwendigen Systemveränderungen und vor allem die gleichzeitig weiter voranschreitenden Einführungsprojekte zu behalten. Motivation Bis zum November des Jahres 2004 wurde über die Definition von Service Levels, die Modellierung ITIL-basierter Betriebsstrukturen sowie durch massive Schulungen der Anwenderbereiche versucht, die dargestellte Problematik zu lösen. Obwohl hier durchaus Erfolge verzeichnet wurden, gelang es jedoch nicht, die Betriebsstrukturen 449

26 10 Optimize-Phase so aufzubauen, dass die auftretenden Probleme 3 beherrschbar geworden wären. Nach einer umfassenden Analyse der bestehenden Lage wurden folgende Anforderungen aufgestellt: Anforderungen Auf Grund der sehr unterschiedlich geprägten Systemnutzer (Anwender mit geringem Systemwissen und fachlichen Anforderungen, Leitstand mit hohem Systemwissen, aber wenig Kenntnis der fachlichen Anforderungen, Rechenzentren mit rein technischem Fachwissen) wird ein einheitliches Kommunikations- und Bearbeitungsmedium benötigt, das zunächst Transparenz und Verständnis bei allen Beteiligten zu den bei Systemveränderungen im System ablaufenden Prozessen schafft. Wegen der erheblichen Änderungsanforderungen aus dem Betrieb, die in monatlichen Wartungszyklen bearbeitet werden, und der Systemänderungen durch die parallel laufenden Einführungsprojekte wird akut ein Steuerungsinstrument benötigt, das Transporte und die Reihenfolge von Systemveränderungen transparenter koordiniert. Das für diese Aufgabenstellung einzuführende Unterstützungssystem muss so robust und einfach wie möglich aufgebaut sein, damit es Akzeptanz bei den Beteiligten findet. Vor diesem Hintergrund begann die Suche nach einem geeigneten Instrument zur Erfüllung dieser Anforderungen. Nach Prüfung verschiedener Varianten (Trouble-Ticket-Systeme, datenbankgestützte Anwendungen) wurde entschieden, mit der Pilotierung ausgewählter Elemente des SAP Solution Manager zu beginnen. Projektinhalte und Einführungszeitraum Folgende Projektplanung wurde definiert: 11/ /2005: Einführung des Change Request Managements auf Basis des SAP Solution Manager 3.2 für die Kommunikation zwischen Leitstand MdF und Rechenzentren für alle Themen des Systembetriebs 07/ /2005: Evaluierung der Anwendung und Beschluss über die Einführung weiterer Szenarien 3 Überholerproblematiken im Transportsystem, völlig unterschiedliche Ausbildungsniveaus bei den Nutzern, Beantragung von erheblichen Systemveränderungen ohne jede Rückkopplung zu gleichzeitig laufenden Einführungsprojekten etc. 450

27 Change Request Management / /2006: Teilnahme am Ramp-Up-Programm für SAP Solution Manager 4.0 und Einführung des Service-Desk-Szenarios sowie der gesamten Systemüberwachung. Erweiterung der Anwendung für alle Systemnutzer sowie Nutzung des SAP Solution Manager für Betrieb und Einführungsprojekte 07/ /2006: Evaluation der Einführungs- und Anwendungsergebnisse und Entscheidung über die Einführung weiterer Szenarien wie z. B. E-Learning Management Derzeit, im Mai 2006, befindet sich das Teilprojekt SAP Solution Manager in der letzten Test- und Schulungsphase, bevor eine Freigabe der Anwendung für die gesamte Landesverwaltung Brandenburg erfolgt. Zunächst ist festzuhalten, dass im Change Request Management durch den Einsatz des SAP Solution Manager eine signifikante Verringerung der Fehlerquote bei der Beantragung, Umsetzung und Dokumentation von Systemveränderungen nachweisbar ist. Vor allem dieser Umstand trug dazu bei, dass zumindest bei den Systemverantwortlichen der Behörden und Einrichtungen ein hohes Verständnis für die Einsatzentscheidung des SAP Solution Manager durch den Leitstand im Finanzministerium und eine hohe Akzeptanz zu verzeichnen sind. Vorteile durch den Einsatz des SAP Solution Manager und Erfahrungen Da im SAP Solution Manager ITIL-basierte Prozesse implementiert wurden, besteht bei den Verantwortlichen und Bediensteten der Rechenzentren sowie bei allen technisch orientierten Systemnutzern (IT-Administratoren, IT-Referenten etc.) eine sehr hohe Anwenderakzeptanz und massiver Bedarf, möglichst schnell weitere Funktionen des SAP Solution Manager produktiv zu setzen. Allerdings gilt es aus Sicht des Gesamtverantwortlichen, durchaus kritisch zu untersuchen, ob und inwieweit eine weitere Ausprägung des Systems ohne vorherige genaue Evaluation der Anwendung wirklich zielführend ist. Es ist derzeit durchaus bewusst eine Einstellung im SAP Solution Manager vorgenommen worden, die jedem Endanwender jederzeit ermöglicht, eigene Störungsmeldungen und Änderungsanträge genau mitzuverfolgen. Dies führt dazu, dass auf die an den Änderungen arbeitenden Bediensteten u.u. ein sehr hoher mentaler Druck ausgeübt wird, da in der derzeitigen Einsatzphase noch nicht alle Behörden des Landes das System nutzen und Umgang mit Transparenz 451