sap® solution manager - cloud object storage | store ... initialer aufbau einer business-blueprint-...
TRANSCRIPT
Marc O. Schäfer, Matthias Melich
SAP Solution Manager®
Bonn � Boston
Auf einen Blick
1 Konzept des SAP Solution Manager 7.1 ................ 29
2 Application Lifecycle Management (ALM) ............. 57
3 Effektiver und effizienter Betrieb ........................... 79
4 Lösungsdokumentation im SAP Solution Manager ............................................ 95
5 Implementierung von Lösungen ............................. 143
6 Vorlagenmanagement ............................................. 203
7 Testmanagement .................................................... 231
8 Verwaltung der Änderungskontrolle ...................... 295
9 Application Incident Management ........................ 381
10 Technischer Betrieb ................................................ 443
11 Betrieb von Geschäftsprozessen ............................ 565
12 Wartung einer SAP-Lösungslandschaft .......................................... 615
13 Unterstützung von Upgrade-Projekten .................. 633
14 SAP Landscape Transformation .............................. 655
15 Custom Code Management: effiziente Verwaltung kundeneigener Entwicklungen ........... 697
A Die Autoren ............................................................. 739
B Autoren der Kundenerfahrungsberichte ................. 759
Inhalt
Geleitwort des Chief Operating Officer der SAP AG .................. 19Geleitwort des DSAG-Vorstands für Operations/Service & Support .................................................. 21Über dieses Buch ..................................................................... 23
1 Konzept des SAP Solution Manager 7.1 ................. 29
1.1 Effektive Implementierung von Änderungen – Projekte im SAP Solution Manager ......................... 31
1.2 Effizienter Betrieb – Lösungen im SAP Solution Manager ............................................ 32
1.3 Prozesse im SAP Solution Manager ......................... 331.4 Vom SAP-zentrierten zum lösungsweiten Einsatz .... 36
1.4.1 Einfache Nutzung für die Gesamtkundenlösung ................................ 36
1.4.2 Offenheit: Integration von Partnerprodukten 381.4.3 Offenheit: SAP Solution Manager für
Nicht-SAP-Software ................................... 391.5 Höhere Benutzerfreundlichkeit ............................... 45
1.5.1 Den Überblick behalten mit Management Dashboards .......................... 45
1.5.2 End-to-End-Monitoring und Alerting ......... 481.5.3 CRM-Benutzeroberfläche
SAP Web Client und Work Center ............. 491.6 Erweiterung der Nutzungsrechte
bringt Kostenvorteile .............................................. 52
2 Application Lifecycle Management (ALM) .............. 57
2.1 Phasen und Themenblöcke des Application Lifecycle Management ......................... 57
2.2 Realisierung von Anforderungen mittels Releases (Major Release) ......................................... 632.2.1 Requirements-Phase .................................. 632.2.2 Design-Phase ............................................ 662.2.3 Build-Phase ............................................... 672.2.4 Test-Phase ................................................. 69
7
Inhalt
2.2.5 Deploy-Phase ............................................. 742.3 Realisierung von Anforderungen über
die Wartung (Minor Release) ................................... 75
3 Effektiver und effizienter Betrieb ............................ 79
3.1 Operations Control Center ...................................... 803.2 Proaktives Monitoring und das
Arbeiten mit dem Alert-Eingang .............................. 823.3 Technische Administration ...................................... 863.4 Betrieb von Geschäftsprozessen am Beispiel
»Überwachen des Tagesabschlusses« ....................... 873.5 Betrieb von Geschäftsprozessen am Beispiel
»Automatisiertes Business-Exception-Management« ......................................................... 90
3.6 Technischer Betrieb am Beispiel »Analyse komplexer technischer Probleme« ........................... 92
4 Lösungsdokumentation im SAP Solution Manager 95
4.1 Technische Landschaftsdokumentation .................... 974.1.1 Landschaftsdaten, Werkzeuge zur
Verwaltung und Prozesse zur Nutzung ....... 994.1.2 Handhabung von Landschaftsdaten ............ 1044.1.3 Topologie der Werkzeuge zur Verwaltung
von Landschaftsdaten ................................. 1174.2 Assistent zur Lösungsdokumentation ....................... 118
4.2.1 Dokumentation der Systemlandschaft ........ 1194.2.2 Automatische Zuordnung der
Analyseergebnisse zu einer Geschäftsprozessstruktur ............................ 120
4.2.3 Analyseergebnisse in einem Projekt aktualisieren oder in eine Lösung überführen ................................................. 127
4.3 Reverse Business Process Documentation ............... 1274.4 Initialer Aufbau einer Business-Blueprint-
Struktur mit der Excel-Upload-Schnittstelle ............. 1294.5 Dokumentation der Lösung ..................................... 1314.6 SAP Solution Manager bei Sanofi-Aventis
Deutschland GmbH ................................................. 137
8
Inhalt
5 Implementierung von Lösungen ............................. 143
5.1 Beschleunigte und prozessorientierte Implemen-tierung durch den SAP-Standard-Content ............... 1445.1.1 Aufbau ...................................................... 1445.1.2 Inhalte ....................................................... 1465.1.3 Produktabhängigkeit ................................ 1485.1.4 Ausblick .................................................... 148
5.2 ASAP-Implementierungsmethode ........................... 1495.2.1 Umfang und Nutzen .................................. 1495.2.2 Roadmap-Phasen ...................................... 1505.2.3 Struktur der ASAP-Methode ...................... 1525.2.4 Business Add-ons zur ASAP-Methode ........ 1535.2.5 Arbeiten mit der Run-SAP- und der
ASAP-Implementierungs-Roadmap ............ 1535.3 Projektverwaltung als Eckpfeiler der
Projektvorbereitung ................................................ 1565.3.1 Projektverwaltung ..................................... 1565.3.2 Anlegen eines Einführungsprojekts ............ 1575.3.3 Festlegen des Projektumfangs und der
Vorgehensweise ........................................ 1575.3.4 Verwalten von Projektmitarbeitern ............ 1585.3.5 Festlegen der Systemlandschaft ................. 1605.3.6 Festlegen der projektspezifischen
Meilensteine ............................................. 1615.3.7 Hinterlegen von Organisationseinheiten .... 1615.3.8 Festlegen der Projektstandards .................. 162
5.4 Business Blueprint – Soll-Konzept für Ihre Lösung ... 1645.4.1 Aufbau des Business Blueprint ................... 1645.4.2 Dokumentation des Soll-Konzepts ............. 1705.4.3 Verantwortliche definieren ........................ 1725.4.4 Abschluss des Business Blueprint .............. 173
5.5 Konfiguration der Lösung ........................................ 1745.5.1 Voraussetzungen der Konfiguration ........... 1755.5.2 Grundsätze der Konfiguration .................... 1765.5.3 Realisierung von Eigenentwicklungen ........ 1795.5.4 Arbeiten mit Servicemeldungen ................. 180
5.6 Testmanagement .................................................... 1825.7 E-Learning-Management – effizienter
Wissenstransfer im Projekt ...................................... 182
9
Inhalt
5.7.1 Erstellung von Lernmaterialien ................... 1835.7.2 SAP Productivity Pak by ANCILE Adapter
for SAP Solution Manager .......................... 1845.7.3 Organisieren und Verteilen von
Lerninhalten ............................................... 1855.8 Reporting für Ihr Einführungsprojekt ....................... 188
5.8.1 Reporting Roadmap ................................... 1885.8.2 Reporting – Business Blueprint ................... 1885.8.3 Reporting – Konfiguration .......................... 1915.8.4 Reporting – Lernmaterialien ....................... 1945.8.5 Reporting – Test ......................................... 1965.8.6 Reporting – Systemlandschaft ..................... 1965.8.7 Reporting – Historie ................................... 196
5.9 SAP Solution Manager bei der HARTMANN GRUPPE ............................................. 197
6 Vorlagenmanagement ............................................. 203
6.1 Anwendungsbereiche für Vorlagen .......................... 2036.1.1 Die unternehmensweite
Prozessbibliothek ....................................... 2046.1.2 Konzern-Roll-out ....................................... 204
6.2 Vorlagenmanagement im Detail .............................. 2076.2.1 Vorlagenmanagement im Kontext des
Application Lifecycle Management ............. 2076.2.2 Methodische Unterstützung durch die
Global ASAP Template Roadmap ................ 2096.2.3 Anlegen von Vorlagen ................................ 2106.2.4 Business-Blueprint-Definition und
Konfigurationsstruktur ............................... 2126.2.5 Freigabe und Implementierung von
Vorlagen .................................................... 2136.2.6 Tipps & Tricks für die Arbeit mit
Vorlagen .................................................... 2146.3 Vorlagenverwaltung und Lebenszyklus .................... 217
6.3.1 Vergleich und Abgleich von Änderungen .... 2176.3.2 Übernahme von Vorlagenänderungen
(Roll-out) ................................................... 2216.3.3 Rückführung lokaler Änderungen in
die Vorlage (Roll-in) ................................... 2236.4 Vorlagenmanagement bei Procter & Gamble ........... 223
10
Inhalt
7 Testmanagement ..................................................... 231
7.1 Ablauf von der Testplanung bis zur Testdurchführung ................................................... 232
7.2 Optionen für Testwerkzeuge ................................... 2347.2.1 Testoption 1 .............................................. 2357.2.2 Testoption 2 .............................................. 2357.2.3 Testoption 3 .............................................. 2367.2.4 Ergänzende Produkte ................................ 236
7.3 Business Process Change Analyzer ........................... 2367.3.1 Anwendungsfall 1: Customizing-
Änderungen .............................................. 2377.3.2 Anwendungsfall 2: Änderungen von
kundeneigenem Code ................................ 2387.3.3 Anwendungsfall 3: Enhancement Package –
Business-Function-Analyse ........................ 2397.3.4 Anwendungsfall 4: Optimierung des
Testumfangs für SAP Support Packages oder SAP Enhancement Packages .............. 241
7.3.5 Vorbereitende Schritte .............................. 2457.3.6 Vorteile für den Kunden ............................ 250
7.4 Testoption 1 ........................................................... 2517.4.1 Überblick über Testfunktionen und
Werkzeuge der Testoption 1 ...................... 2517.4.2 Work Center »Testmanagement« .............. 2537.4.3 Manuelles Testen ...................................... 2557.4.4 Testautomatisierung .................................. 2597.4.5 Test-Reporting .......................................... 265
7.5 Testoption 2 – Testen mit dem SAP Quality Center by HP ....................................... 2687.5.1 Überblick über Testfunktionen und
Werkzeuge der Testoption 2 ...................... 2697.5.2 Übertragung in den Business Blueprint ...... 2727.5.3 Erstellen von Testplänen ............................ 2737.5.4 Testfälle mit SAP Test Acceleration and
Optimization erstellen ............................... 2757.5.5 Ausführen der Testfälle unter
Verwendung von SAP Test Acceleration and Optimization und SAP Quality Center by HP ............................................. 276
11
Inhalt
7.5.6 Austausch von Fehlermeldungen zwischen SAP Quality Center by HP und SAP Solution Manager ............................... 278
7.5.7 Reporting in SAP Solution Manager und SAP Quality Center by HP .......................... 279
7.5.8 Wartung von Testfällen mithilfe von SAP Test Acceleration and Optimization .... 280
7.6 Testoption 3 – Integration mit IBM-Rational-Werkzeugen ...................................... 2827.6.1 Ein automatisierter, integrierter,
standardisierter Ansatz ............................... 2837.6.2 Anlegen von Business Blueprints und
Anforderungsmanagement ......................... 2837.6.3 Änderungseinfluss-Analyse ........................ 2847.6.4 Testplanung ............................................... 2847.6.5 Vorteile für den Kunden ............................. 286
7.7 SAP Solution Manager bei Colgate-Palmolive .......... 287
8 Verwaltung der Änderungskontrolle ....................... 295
8.1 Quality Gate Management ...................................... 2968.1.1 Work Center »Change Management« ......... 2978.1.2 Zentrale Transportverwaltung mit
Quality Gate Management ......................... 3038.1.3 SAP Best Practices im Bereich Transport .... 307
8.2 Change Request Management ................................. 3088.2.1 Change Request Management im Detail ..... 3108.2.2 Architektur ................................................. 3168.2.3 Projektzyklus und Wartungszyklus .............. 3178.2.4 Änderungsantrag (Request for Change) ...... 3218.2.5 Änderungstypen im Change Request
Management im Detail .............................. 3268.2.6 Änderungsverwaltung mit dem
Change Request Management .................... 3328.2.7 Zentrale Änderungskontrolle ...................... 3348.2.8 Transparenz über Änderungsprozesse ......... 3408.2.9 Integration des Change Request Manage-
ment mit den anderen Application-Lifecycle-Management-Funktionen ............ 344
12
Inhalt
8.3 Transportverwaltung ............................................... 3488.3.1 SAP-Änderungs- und
Transportsystem (CTS) ............................... 3488.3.2 Synchronisation von
Entwicklungssystemen .............................. 3608.3.3 SAP Transport Execution
Analysis Service ........................................ 3638.4 Änderungsdiagnose ............................................... 365
8.4.1 Änderungen verfolgen ............................... 3658.4.2 Änderungsauswertungen ........................... 3668.4.3 Durchgängige Änderungsanalyse ............... 3678.4.4 Konfigurationsvalidierung .......................... 369
8.5 SAP Solution Manager bei Ferrero Deutschland MSC GmbH & Co. KG ......................... 373
9 Application Incident Management ........................ 381
9.1 Incident und Problem Management ........................ 3819.1.1 IT-Servicemanagement nach ITIL ............... 3829.1.2 SAP-IT-Servicemanagement (SAP ITSM) .... 3849.1.3 Integrationskonzept ................................... 3859.1.4 Anwendungsszenarien ............................... 3889.1.5 Der zentrale Incident- und
Problem-Management-Prozess .................. 3989.1.6 Stammdaten ............................................. 4059.1.7 Best-Practice-Funktionen ........................... 408
9.2 Incident Management mit Help-Desk-Systemen anderer Anbieter .................................................... 414
9.3 Incident Management für IT-Dienstleister ............... 4169.4 Incident Management für Softwarepartner .............. 4239.5 SAP Solution Manager bei Ferrero
Deutschland MSC GmbH & Co. KG ......................... 4289.6 SAP Solution Manager bei der itelligence AG .......... 436
10 Technischer Betrieb ................................................. 443
10.1 Technisches Monitoring .......................................... 44710.1.1 Alert-Eingang ............................................ 44810.1.2 System-Monitoring .................................... 45310.1.3 Verbindungs-Monitoring ........................... 456
13
Inhalt
10.2 Zentrale Überwachung von SAP NetWeaver Process Integration .................................................. 45810.2.1 Einstieg und Navigation ............................. 46110.2.2 Overview Monitor ...................................... 46210.2.3 Component Monitor .................................. 46410.2.4 Channel Monitor ........................................ 46510.2.5 Message Monitor ....................................... 46610.2.6 Zentrale inhaltsbasierte
Nachrichtensuche ..................................... 47110.2.7 Anbindung an die Alert-Infrastruktur .......... 47310.2.8 Anbindung an den Service Desk ................. 473
10.3 End-User-Experience-Monitoring ............................ 47410.4 End-to-End-Root-Cause-Analysis ............................. 481
10.4.1 Vorgehensweise zur Root Cause Analysis ... 48310.4.2 Architektur ................................................. 48510.4.3 Werkzeuge in der Root Cause Analysis ....... 48710.4.4 Root Cause Analysis im Detail .................... 48910.4.5 Qualitätssicherung mit Werkzeugen der
Root Cause Analysis ................................... 49910.5 Technische Administration ...................................... 501
10.5.1 Work Mode Management .......................... 50210.5.2 IT-Kalender ................................................ 51110.5.3 Benachrichtigungsverwaltung ..................... 51210.5.4 Zentrale Systemadministration ................... 513
10.6 Technische Analyse ................................................. 52410.6.1 Technische Auswertungen .......................... 52410.6.2 Management-Auswertungen ...................... 539
10.7 Datenvolumenmanagement .................................... 54310.7.1 Positionsbestimmung ................................. 54310.7.2 Analyse der Datenverteilung ...................... 54410.7.3 Priorisieren von Objekten ........................... 54910.7.4 Priorisieren nach Speicherverbrauch ........... 55010.7.5 Priorisieren nach Altersstruktur der
Daten ......................................................... 55210.7.6 Priorisieren nach Nutzungshäufigkeit .......... 55310.7.7 Auswertung der Daten ............................... 55610.7.8 Diskussionen mit den Fachbereichen .......... 55810.7.9 Projekt-Reporting ...................................... 561
14
Inhalt
11 Betrieb von Geschäftsprozessen ............................ 565
11.1 Geschäftsprozess- und Schnittstellenüberwachung .. 56611.1.1 Werkzeuge, die den Betrieb der
Geschäftsprozesse unterstützen ................. 56611.1.2 Geschäftprozessüberwachung im
SAP Solution Manager ............................... 56911.1.3 Handhabung der Geschäftsprozessüber-
wachung im SAP Solution Manager ........... 57111.1.4 Geschäftsprozesse mit der Anwendung
Geschäftsprozess-Analyse (Business Process Analytics) verbessern ..................... 573
11.2 Jobverwaltung ........................................................ 57611.2.1 Herausforderungen in der Jobverwaltung ... 57711.2.2 Fallbeispiel eines Jobverwaltungsprozesses
im Sinne des SAP-Standards ...................... 58011.2.3 Automatische Umleitung eines
Endanwenders vom Backend-Systemin das Antragsformular des SAP Solution Manager ............................... 588
11.2.4 Job Scheduling Management Health Check 58911.3 Datenkonsistenzverwaltung .................................... 591
11.3.1 Einführung in die Daten-konsistenzverwaltung ................................ 591
11.3.2 Überblick über die Werkzeuge zur Datenkonsistenzverwaltung ....................... 593
11.4 Performance von Geschäftsprozessen ...................... 59911.4.1 Performanceoptimierung von
Geschäftsprozessen ................................... 60011.4.2 Performanceoptimierung mit
Self-Services der SAP ................................. 60511.5 SAP Solution Manager bei der Bayer
MaterialScience ...................................................... 609
12 Wartung einer SAP-Lösungslandschaft .................. 615
12.1 Der Maintenance Optimizer ................................... 61612.1.1 Der Maintenance Optimizer im Detail ....... 61812.1.2 Maintenance Optimizer für SAP ERP ......... 62312.1.3 Unterstützung komplexer Landschaften ..... 625
15
Inhalt
12.1.4 Country Legal Changes Packages für SAP ERP HCM – Lösungen und HR Support Packages in den Wartungs-vorgang einbinden ..................................... 626
12.1.5 Berechtigungen und Auswertungen im Maintenance Optimizer ............................. 627
12.1.6 Wartungszertifikat und Lizenzmanagement 62812.2 Systemempfehlungen .............................................. 630
12.2.1 Empfehlungen für Ihre Systeme erhalten .... 63112.2.2 Integration mit anderen Werkzeugen im
SAP Solution Manager ............................... 63212.2.3 Einrichtung der Funktion
»Systemempfehlungen« .............................. 632
13 Unterstützung von Upgrade-Projekten .................. 633
13.1 Upgrade Dependency Analyzer ............................... 63513.1.1 Mögliche Abhängigkeitsaussagen ............... 63713.1.2 Abgrenzung des UDA zum Maintenance
Optimizer und den Szenarien- und Prozess-komponentenlisten (PCL/SCL) .................... 640
13.1.3 Datenqualität und Haftungsausschluss ........ 64113.1.4 Beispiele für die Nutzung des UDA ............. 641
13.2 Projektplanung und Projektmanagement mit der Upgrade Roadmap ...................................... 649
13.3 Custom Development Management Cockpit ........... 65013.4 Maintenance Optimizer ........................................... 65113.5 Testmanagement ..................................................... 65213.6 Endanwenderschulungen ......................................... 65313.7 SAP Upgrade Assessment ....................................... 65313.8 SAP GoingLive Functional Upgrade Check ............... 65313.9 Methode Near Zero Downtime ............................... 654
14 SAP Landscape Transformation .............................. 655
14.1 Der Greenfield-Ansatz ............................................. 65914.2 Das Vorgehen bei SAP-Transformationen ................ 65914.3 Phasen der Durchführung eines
Transformationsprojekts .......................................... 660
16
Inhalt
14.3.1 Identifikation des Transformationsansatzes ............................ 661
14.3.2 Analyse der Systemlandschaft und Planung des Projekts ................................. 661
14.3.3 Evaluierung und Vorbereitung eines Transformationsprojekts ............................ 662
14.3.4 Realisierung eines Transformationsprojekts ............................ 662
14.3.5 Typische Vorgehensweise bei der Durchführung eines Mandantentransfers ... 663
14.4 Transformationsszenarien ........................................ 66414.4.1 Transformationslösungen für Verkaufs-,
Kauf- und Umstrukturierungsvorhaben ...... 66414.4.2 Vereinheitlichung und Transformation
von Daten ................................................. 66914.4.3 Konsolidierung von Systemen und
Reduzierung der IT-Kosten ........................ 67514.5 Nutzung von SAP Landscape Transformation .......... 677
14.5.1 Arbeiten mit SAP Landscape Transformation .......................................... 678
14.5.2 Aufbau des Work Centers der SAP-LT-Software ...................................... 679
14.5.3 Projekte anlegen ....................................... 68214.5.4 Kombinieren von
Transformationslösungen ........................... 68314.5.5 Projekte durchführen ................................. 68414.5.6 Analysen ausführen ................................... 68514.5.7 Transformationsapplikationen ausführen .... 68614.5.8 Wichtige Hinweise und Empfehlungen
zur technischen Durchführung ................... 68714.6 Ergänzende Services zu
SAP Landscape Transformation ............................... 68814.7 SAP Solution Manager bei SKW
Stahl-Metallurgie Holding AG ................................. 692
15 Custom Code Management: effiziente Verwaltung kundeneigener Entwicklungen ................................ 697
15.1 Einführung in Custom Code Management .............. 69715.1.1 Das Stadt-Modell ...................................... 698
17
Inhalt
15.1.2 Der Prozess des Custom Code Management .............................................. 700
15.2 Custom Code Lifecycle Management – Verwaltung kundeneigener Entwicklungen .............. 70215.2.1 Prozess und Architektur ............................. 70315.2.2 Die Anwendung CCLM im Detail ................ 70715.2.3 Einstellungen ............................................. 70915.2.4 Bibliotheksdefinition .................................. 71115.2.5 Objekte in der Bibliothek ........................... 71215.2.6 Reporting ................................................... 714
15.3 Custom Development Management Cockpit ............ 71615.4 Analysen für kundeneigene Entwicklungen .............. 726
15.4.1 SAP-Originalobjekte von Klonen unterscheiden ............................................ 726
15.4.2 Verwendungsbereiche der Klone identifizieren .............................................. 729
15.4.3 Überwachung und Auswertung der Modifikationen .......................................... 730
15.4.4 Versionen Ihrer Programme unterscheiden ............................................ 731
15.4.5 Zeit für Verbesserung ................................. 73315.5 Custom Code Lifecycle Management bei
Procter & Gamble .................................................... 734
Anhang ............................................................................ 739
A Die Autoren ....................................................................... 739B Autoren der Kundenerfahrungsberichte ............................. 759
Index ........................................................................................ 765
18
Die während des Betriebs der Lösung erhobenen Kennzahlen und Daten können Sie 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 werden der Prozess Verwaltung der Änderungskontrolle erläutert und die Funktionsweisen des Change Request Management, des Quality Gate Manage-ment, des Retrofit sowie der unterstützenden Services und Analysen im Detail erklärt.
8 Verwaltung der Änderungskontrolle
Der Prozess Verwaltung der Änderungskontrolle (Change Control Management) stellt sicher, dass Änderungen geplant und konsistent durchgeführt werden. Wichtig ist, dass alle Änderungen nachvoll-ziehbar in der Lösung vorgenommen werden und ihr Risiko in Bezug auf Stabilität und Sicherheit jederzeit kontrollierbar ist.
Funktionen des SAP Solution Manager
Der SAP Solution Manager unterstützt Sie dabei durch eine Vielzahl von Funktionen. Das ITIL-zertifizierte Change Request Managementermöglicht Ihnen die höchste Integration in Ihren Change-Manage-ment-Prozess. Darüber hinaus stellt das Quality Gate Managementeine zusätzliche Qualitätskontrolle für Projekte bereit und sichert den korrekten Transport von Änderungen in die Produktivsysteme. Im Umfeld von Upgrade, globalen Roll-outs von Vorlagen oder funk-tionalen Weiterentwicklungen ergeben sich Risiken und Aufwände in der Synchronisation von Entwicklungssystemen. Mit der Retrofit-Funktion synchronisieren Sie duale Landschaften vollständig und mit minimalem manuellen Aufwand. Um über alle Änderungen in der Landschaft einen Überblick zu behalten, bietet Ihnen die Change-Analyse Informationen zum aktuellen Stand und zur Historie der Änderungen an. Aufgezeichnet werden Änderungen von Konfigura-tionen eines Systems von Betriebssystem, Datenbank und Applikati-onsserver-Parametern über Transportaufträge und Hinweise bis hin zu Support Packages. Mit der Configuration Validation können Sie Konfigurationseinstellungen vergleichen und damit z. B. die Homo-genität der Konfiguration innerhalb der Lösungslandschaft sicherstel-
295
Verwaltung der Änderungskontrolle8
len. Basierend auf den Erfahrungen des SAP-Supports, bietet Ihnen der Guided Self-Service Transport Execution Analysis eine auf Ihre Transportlandschaft abgestimmte Best-Practice-Empfehlung der SAP. Daraus können Sie für sich einen entsprechenden Aktionsplan ablei-ten, der organisatorische, prozess- oder auch werkzeugbezogene Aspekte enthalten kann.
8.1 Quality Gate Management
Das Quality Gate Management stellt in Bezug auf eine durchgängige Lösungslandschaft sicher, dass die Bereiche Design und Entwicklung sowie die Implementierung eines neuen Service effizient und effektiv in Projekte eingebettet sind. Ziel ist es, einen integrierten und kon-sistenten Qualitätsprozess im Unternehmen zu etablieren und alle beteiligten Abteilungen darin zu integrieren.
Zusammenarbeit mit dem Release
Management
Das Quality Gate Management unterstützt das Release Managementbei Implementierungs- und Wartungsprojekten bei Kunden. In der Regel wird dabei zwischen zwei Arten von Releases unterschieden:
1. Major ReleaseDas Major Release ist gekennzeichnet durch eine drei- bis sechsmo-natige Laufzeit. Kunden entwickeln innerhalb eines Jahres zwei bis vier Releases. Ein solches Release beinhaltet alle Arten von Änderungen, auch solche, die Kerngeschäftsprozesse nachhaltig beeinflussen, daher erfordert ein Major Release einen kompletten Regressionstest.
2. Minor ReleaseDas Minor Release ist durch eine wesentlich kürzere Laufzeit zwi-schen einer und vier Wochen definiert. Ziel eines solchen Releases ist es, Fehlerkorrekturen und kleinere funktionale Erweiterungen zu bündeln und zur Verfügung zu stellen. Hierbei kann der Test-umfang auf die Kerngeschäftsprozesse und die bereitgestellten Erweiterungen eingeschränkt werden.
Diese Vorgehensweise bietet Ihnen die folgenden Vorteile:
� Die Häufigkeit der Änderungen im produktiven System wird reduziert.
� Änderungen finden zu klar definierten Zeitpunkten statt.
� Die Zufriedenheit der Endanwender steigt durch frühzeitige Kom-munikation und Trainings.
296
Quality Gate Management 8.1
� Für jede Änderung steht die angemessene Testmethode zur Verfü-gung.
� Tägliche Änderungen werden auf Notfallkorrekturen reduziert.
� Das Risiko von Inkonsistenzen durch fehlende oder in der falschen Reihenfolge eingespielte Transporte verringert sich.
� Der Arbeitsaufwand für Transportverwaltung durch Bündelung sinkt.
Abbildung 8.1 zeigt das Release Management (Minor und Major Release) und Transport Management, also das Einspielen in Folgesys-teme, im Überblick.
Abbildung 8.1 Release und Deployment Management
8.1.1 Work Center »Change Management«
Das Work Center Change Management im SAP Solution Manager stellt den zentralen Einstiegspunkt dar, um Projekte für das Quality Gate Management anzulegen bzw. zu verwalten. Die Darstellung ermöglicht dem Benutzer, sich einen schnellen Überblick über die verschiedenen Softwareentwicklungsprojekte und deren Status zu verschaffen. Dabei unterstützt das Quality Gate Management sowohl Implementierungs- als auch Wartungsprojekte.
SAP Solution Manager
QG QG
QG QG QG QG QG ...
QG QG QGScope Build
Build
Transportzyklus
Alle Arten von Änderungen inklusiveinvasiver Eingriffe
Fehlerkorrekturen und kleinere Änderungen (inkl. Reimport von Notfallkorrekturen)
Priorität Normal
3-6 Monate 1-4 Wochen
Major Release Minor Release
Normal
Testumfang Kompletter Testumfang Zentrale Prozesse und neue Funktionen
Änderungskategorien
Test Deploy Scope Build
Test Deploy
Implementierungsprojekt (Major Release)
Wartungsprojekt in Zyklen (Minor Release)
...
297
Verwaltung der Änderungskontrolle8
Sichten In der Sicht Überblick sehen Sie, welche Aufgaben zu erledigen sind bzw. an welchen Projekten Sie mitarbeiten oder beteiligt sind und wel-cher Rolle Sie zugewiesen sind. Die zu erledigenden Aufgaben können von Ihnen direkt bearbeitet werden. Die automatische Aktualisierung sorgt dafür, dass Sie immer auf dem aktuellen Datenbestand arbeiten. Mithilfe von Favoriten können mehrere Projekte benutzerspezifisch zusammengefasst und dargestellt werden. Über die Sicht Projekte kön-nen Sie eine Vielzahl von Informationen visualisieren. Hierfür stehen verschiedene Registerkarten innerhalb der Sicht Projekte zur Verfü-gung (siehe Abbildung 8.2).
Abbildung 8.2 Projektübersicht im Quality-Gate-Kalender
Mithilfe der Registerkarte Kalendersicht können Sie sich anhand des Quality-Gate-Kalenders den Status aller aktuell angelegten bzw. laufen-den Projekte sowie deren aktive Phase anzeigen lassen. Zusätzlich wer-den sowohl die Quality Gates als auch die Meilensteine in der Übersicht visualisiert. Mithilfe der Mehrfachselektion von Projekten ermöglicht die Kalendersicht, die Projektlaufzeiten und deren aktuellen Status zu visualisieren. Diese Ansicht erlaubt es, eventuelle zeitliche Konflikte frühzeitig zu erkennen und entsprechende Aktionen zu initiieren.
Vorgehensweise Um ein Projekt innerhalb des Quality Gate Management zu nutzen, müssen bestimmte Voraussetzungen erfüllt sein. Sie müssen ein SAP-Solution-Manager-Projekt anlegen (Transaktion SOLAR_PROJECT_ADMIN) und die Systemlandschaft in der Transaktion SMSY pflegen (siehe Abschnitt 5.3.1). Dabei kann es sich um ein Wartungs- oder ein Implementierungsprojekt handeln. Erst danach ist das Projekt in der Auswahlbox sichtbar. Nach Auswahl des gewünschten Projekts können
298
Quality Gate Management 8.1
Sie über den Menüpunkt Einrichten � Quality Gate Management die noch ausstehenden Konfigurationen vornehmen. Nach dem Klick auf den Menüpunkt öffnet sich ein Assistent, in dessen erstem Schritt Sie die Startzeitpunkte der einzelnen Phasen festlegen können. Folgende vier Phasen mit den entsprechenden Quality Gates sind im Standard definiert:
� Scope
� Build
� Test
� Deploy
Quality GateEin Quality Gate (Q-Gate) ist ein spezieller Meilenstein in einem Pro-jekt. Q-Gates befinden sich zwischen denjenigen Phasen im Projekt, die in besonderer Weise von den Ergebnissen der Vorphase abhängig sind oder in denen besonderes Augenmerk auf technische Abhängig-keiten gelegt werden muss. Ein Q-Gate beinhaltet eine Prüfung der Ergebnisse der Vorphase. Die geforderten Ergebnistypen und Anforde-rungen an diese Phasen können Sie z. B. in Form von Checklisten für ein Q-Gate hochladen. Die Prüfung wird von Projektverantwortlichen und Experten der entsprechenden Phasen innerhalb einer Sitzung vor-genommen. Je nach Ausgang kann das Projekt wie geplant weiterlau-fen, kann aber auch abgebrochen oder verzögert werden. Bei Einsatz des Quality Gate Management können keine Transporte in die Folge-systeme eingespielt werden, ohne dass ein Q-Gate erfolgreich durch-laufen wurde. Diese Importsperre erlaubt Ihnen ein hohes Maß an Kon-trolle über Ihre Projekte und das Transportwesen. Erst nach erfolgreich durchlaufener Q-Gate-Prüfung wird die Importsperre für das nachfol-gende System aufgehoben.
In Abbildung 8.3 ist der Ablauf des Quality Gate Management exem-plarisch dargestellt.
MeilensteineZusätzlich zu den bestehenden Q-Gates können Sie sogenannte Mei-lensteine anlegen, die einen bestimmten Zeitpunkt in Ihrem Projekt darstellen. Ein Meilenstein ist ein Ereignis mit besonderer Bedeu-tung. Im Projektmanagement sind diese Ereignisse meist Unter- bzw. Zwischenziele eines Projekts. Diese Ziele sind an die Fertigstellung eines bedeutenden Projektergebnisses gebunden. Um die Wichtig-keit eines Meilensteins hervorzuheben, können Sie ihn zusätzlich mit einer Q-Gate-Prüfung versehen.
299
Verwaltung der Änderungskontrolle8
Abbildung 8.3 Ablauf des Quality Gate Management
Qualitätsmanagerund Qualitäts-
ausschuss
Im zweiten Schritt legen Sie den Qualitätsmanager sowie den Quali-tätsausschuss fest. Dadurch wird ein Vier-Augen-Prinzip innerhalb des Projekts und des Prozesses etabliert (Segregation of Duties). Nur wenn beide Personen oder Gruppen das Q-Gate als erfolgreich durchlaufen bestätigen, wird die Importsperre für das dem Q-Gate zugewiesene System aufgehoben und ein Import in das System ermöglicht. Die Transporte mit den unterschiedlichen Entwicklun-gen können Sie mithilfe des Transportmanagements in das System importieren.
Im dritten Schritt wird die logische Komponente, die Sie zuvor in der Systemlandschaftspflege (Transaktion SMSY) angelegt haben, mit den darin definierten Systemen dargestellt und gegen die Transport-wegekonfiguration verifiziert.
In einem weiteren Schritt erfolgt die Zuordnung der einzelnen Q-Gates zu den Phasen und Systemrollen. Durch die flexible Zuord-nung der Q-Gates ist es z. B. auch möglich, zwischen dem Entwick-lungssystem und dem Qualitätssicherungssystem kein Q-Gate zu set-zen, somit ein iteratives Testen zu ermöglichen und trotzdem sein Produktivsystem zu schützen.
Build
Solution-Manager-Projekt mitQuality Gate Management
Test
Entwickler
Tester
Administrator
Quality-Gate geschlossenQuality-Gate offen
Quality-Gate
Quality-Gate-Dokument
Qualitäts-manager
Resultatedokumentieren
•
Dokumentationhochladen
•
Q-Gatebewerten
•
QualitySteeringBoard
Empfehlungendes Qualitäts-Managersbestätigen oderzurückweisen
300
Quality Gate Management 8.1
Nach Abschluss der Konfiguration zeigt der Assistent Ihnen die Pro-jektlandschaft mit den einzelnen Phasen, Systemen, Q-Gates und Meilensteinen (siehe Abbildung 8.4).
Abbildung 8.4 Projektlandschaft nach Abschluss der Konfiguration
Q-Gate-KalenderNach dem Sichern der Konfiguration werden die unterschiedlichen Meilensteine und Q-Gates in einem Q-Gate-Kalender angezeigt. Mit unterschiedlichen Filteroptionen kann die Sicht auf die Projekte benutzerspezifisch angepasst werden. Ein Klick auf das durchlaufene Q-Gate zeigt Ihnen die Ergebnisse und Anforderungen, die in Form von Checklisten und Dokumenten fixiert sind (siehe Abbildung 8.5).
Abbildung 8.5 Q-Gate-Dokumentation
301
Verwaltung der Änderungskontrolle8
Der Qualitätsmanager ist für den Übergang der einzelnen Projekt-phasen verantwortlich (Scope, Build, Test und Deploy). Die Prüfung hierfür wird durch Projektverantwortliche und Experten für die ent-sprechenden Phasen innerhalb einer Sitzung vorgenommen. Zusätz-lich stehen Ihnen verschiedene Informationen und Sichten für Ihre Softwareentwicklungsprojekte zur Verfügung. Über die angebotenen Registerkarten des Work Centers behalten Sie immer den Überblick (siehe Abbildung 8.6).
Abbildung 8.6 Informationen zu Q-Gates
Mit einem Klick auf das jeweilige Projekt stehen dem Qualitätsmana-ger über verschiedene Registerkarten sowohl allgemeine als auch detaillierte Informationen, wie z. B. definierte Projektphasen, Anzahl der zum Projekt gehörenden Änderungen und Transportaufträge sowie Informationen zu den Verantwortlichen des Projekts, zur Ver-fügung (siehe Abbildung 8.7).
Log Für die entsprechende Revisionssicherheit sorgt ein Aktions-Log bzw. Applikations-Log, das alle Aktivitäten mit Zeitstempel und Benutzer mitprotokolliert.
302
Quality Gate Management 8.1
Abbildung 8.7 Projekt mit den Änderungen und den dazugehörigen Transporten
8.1.2 Zentrale Transportverwaltung mit Quality Gate Management
In heutigen heterogenen, verteilten Kundenlösungen ist es notwen-dig, im Bezug auf eine durchgängige Lösungslandschaft sicherzustel-len, dass die Implementierung eines neuen Service effizient und effektiv durchgeführt werden kann. Während früher das Hauptau-genmerk auf den Abhängigkeiten von Objekten in einer Systemland-schaft lag, liegt es heute auf den Abhängigkeiten von Objekten in einer Lösungslandschaft. Das heißt, Systeme, die technisch vollkom-men unabhängig voneinander sind, stehen mehr und mehr in einer funktionalen Abhängigkeit. Ziel muss es sein, eine zentrale Trans-portverwaltung für die gesamte Lösungslandschaft zu etablieren.
Mit dem Quality Gate Management stellt der SAP Solution Manager im Work Center Change Management eine Administrationsoberfläche für die zentrale Transportverwaltung (siehe Abbildung 8.8) zur Verfügung.
Transport-konfiguration und -risiken
Mit einem Klick auf die Registerkarte Systemlandschaftsgrafik
kann sich der Transportverantwortliche nach vorheriger Auswahl des Projekts die definierte Lösungslandschaft grafisch im Detail an-sehen (siehe Abbildung 8.9).
303
Verwaltung der Änderungskontrolle8
Abbildung 8.8 Zentrale Transportverwaltung
Abbildung 8.9 Systemlandschaftsgrafik
Die Lösungslandschaft spiegelt die kundenspezifische Transportkon-figuration und deren Transportwege wider. Die Lösungslandschaft eines Projekts wird mithilfe eines Assistenten schnell und einfach eingerichtet und basiert auf SAP-Solution-Manager-Projekten (siehe Abschnitt 8.1.1). Die farbliche Visualisierung zeigt die derzeit aktive
SAP Solution ManagerChange ControlManagement
SAP-Solution-Manager-Projekt
Änderung 1
Änderung 2
Änderung 3
SAP NetWeaver Portal SAP ECC
Transport-auftrag
Transport-auftrag
Transport-auftrag
Transport-auftrag
Transport-auftrag
Transport-auftrag
304
Quality Gate Management 8.1
Phase des Projekts sowie die durchlaufenen und noch anstehenden Q-Gates an. Zusätzlich werden eventuelle Transportrisiken in der Systemgrafik farblich gekennzeichnet.
Die Transportrisiken der entsprechenden Systeme werden darüber hinaus auf der Registerkarte Risiken in tabellarischer Form zur Ver-fügung gestellt (siehe Abbildung 8.10). Die Risiken werden vom Sys-tem automatisch gesammelt. Der Qualitätsmanager kann auf diese Art vor jeder Phase bzw. vor jedem Phasenabschluss beurteilen, wel-che Transporte freigegeben wurden bzw. noch auf eine Freigabe war-ten. Darüber hinaus ist zu erkennen, ob alle Transporte korrekt in das System importiert wurden. Basierend auf diesen Informationen kann er entscheiden, welche Maßnahmen notwendig sind.
Abbildung 8.10 Transportrisiken in Lösungslandschaften
Beispiele für Risiken sind:
� Transportfehler (Return-Code 8)
� fehlende Transportaufträge in den Systemen
� Transporte, die eine logische Abhängigkeit zueinander haben und nicht vollständig importiert wurden
305
Verwaltung der Änderungskontrolle8
� offene Transportaufträge, die im Entwicklungssystem auf die Frei-gabe warten
Auf diese Weise kann der Qualitätsmanager mit entsprechenden Aktivitäten kritischen Situationen effektiv entgegenwirken und eine Risikoeinschätzung des Projekts vornehmen.
Änderungen am Projekt
Basierend auf der Auswahl eines Projekts stellt die Registerkarte Änderungen die projektspezifischen Änderungen sowie die darin befindliche Anzahl von Transportaufträgen dar. Dabei können belie-big viele Änderungen für ein Projekt angelegt werden. Die einzelnen Änderungen können Sie über die Registerkarte Änderungen für das jeweilige Projekt anlegen. Nach dem Anlegen einer Änderung kön-nen Sie dieser eine beliebige Anzahl von Transportaufträgen (Work-bench/Customizing) zuordnen. Das Anlegen von Transportaufträgen kann über die Registerkarte Änderungen, über die Schaltfläche Transporte verwalten oder über die Registerkarte Transporte mit der Schaltfläche anlegen erfolgen. Die Änderungen bilden die Klam-mer für die verschiedenen Transportaufträge, die ihnen zugeordnet sind. Die Basis hierfür bilden CTS-Projekte.
Die in Abschnitt 8.1.1 angesprochenen Änderungen und Transport-aufträge für ein Projekt können auch über das Change Request Management angelegt und im Quality Gate Management (siehe Abbildung 8.11) dargestellt werden (siehe Abschnitt 8.2.9).
Abbildung 8.11 Übersicht der zu einem Projekt gehörenden Transportaufträge
306
Quality Gate Management 8.1
Transportaufträge logisch bündeln
Durch dieses Konzept ist es möglich, logisch zusammengehörige bzw. voneinander abhängige Transportaufträge system- und/oder lösungsspezifisch zu bündeln. Abhängig von der aktuellen Phase können Sie ganze Projekte oder einzelne Änderungen mit einem oder mehreren Transportaufträgen in die nachfolgenden Systeme importieren. In der Test-Phase kann der Administrator in Absprache mit dem Qualitätsmanager und weiteren Experten Transportauf-träge anderen Projekten und deren Änderungen zuordnen. In dieser Phase des Softwareentwicklungsprojekts kann der Qualitätsmana-ger eine Konsolidierung des Projekts vornehmen, bevor er die letzte Phase des Projekts aktiviert. In der Deploy-Phase kann das komplette Projekt mit all seinen Transportaufträgen entsprechend den in der Praxis bewährten Vorgehensweisen von SAP (SAP Best Practices) importiert werden. Damit wird sichergestellt, dass alle Transport-aufträge eines Projekts komplett und in der richtigen Reihenfolge sowie zu einem bestimmten Zeitpunkt in die produktiven Systeme importiert werden. Kann ein Projekt-Import (Import all) nicht durchgeführt werden, steht auch für die Deploy-Phase der Import einzelner Änderungen zur Verfügung. Mithilfe dieser Funktionalität können Geschäftsprozesse in ABAP- und Nicht-ABAP-Systemen über Lösungslandschaften hinweg synchron geändert werden.
8.1.3 SAP Best Practices im Bereich Transport
Um Sie bei Ihren Änderungen bestmöglich zu unterstützen, wurde das Quality Gate Management unter Berücksichtigung der SAP Best Practices im Bereich Transport entwickelt. Diese basieren auf der Erfahrung einer Vielzahl von Kundenprojekten:
� Transport von KopienDiese Funktion bietet die Möglichkeit, einen originalen Transpor-tauftrag und die darin befindlichen Objekte so lange im Entwick-lungssystem zu sperren, bis die entwickelte Funktionalität erfolg-reich im Qualitätssicherungssystem getestet wurde. Erst danach findet die finale Freigabe des originalen Transportauftrags statt. Folglich arbeitet der Entwickler so lange wie möglich mit dem Transport von Kopien.
Dieses Vorgehen bringt im Wesentlichen zwei Vorteile. Zum einen wird die Anzahl der Transportaufträge, die in das Produktiv-system importiert werden, reduziert. Da der originale Transport
307
Verwaltung der Änderungskontrolle8
nur die finale Version des geänderten Objekts enthält und nicht die zuvor entwickelten Versionen, reduziert sich sowohl die Anzahl der Objektversionen im Produktivsystem als auch die Importzeit der Transportaufträge.
Überholer-problematik
Der zweite Vorteil liegt darin, dass mit dem Transport von Kopien die Gefahr der Überholerproblematik entscheidend reduziert wer-den kann, weil die entwickelten Objekte so lange wie möglich im Entwicklungssystem gesperrt bleiben und somit Versionskonflikte verhindert werden können.
� Systemübergreifende ObjektsperreMithilfe der systemübergreifenden Objektsperre ist es möglich, mehrere Implementierungsprojekte bzw. Wartungsprojekte auf ein und derselben Systemlandschaft zu betreiben. Ändert ein Ent-wickler in einem Projekt ein Objekt, ist dieses Objekt für alle ande-ren Entwickler sowohl im gleichen als auch in den anderen Projek-ten auf dieser Systemlandschaft mithilfe der systemübergreifen-den Objektsperre nicht mehr änderbar. Abhängig von der Einstellung der Sperre kann eine Änderung frühestens nach der finalen Freigabe des Transportauftrags erfolgen. Dadurch werden Versionskonflikte frühzeitig unterbunden. Diese Funktion steht sowohl für ABAP-Workbench-Objekte als auch für Customizing-Einstellungen zur Verfügung.
� Dringende KorrekturenEine dringende Korrektur ermöglicht die schnellstmögliche Imple-mentierung einer Korrektur im Produktivsystem mithilfe eines Vorabtransports. Durch die Zuordnung zu einem Projekt bleiben die Transportreihenfolge und die Konsistenz des Produktivsys-tems erhalten.
Weiterführende Details zu den SAP Best Practices im Bereich Trans-port finden Sie in Abschnitt 8.3.
8.2 Change Request Management
Die Möglichkeit, Änderungen nachzuvollziehen, ist einer der wich-tigsten Faktoren, um Qualität und Transparenz in einer Softwarelö-sung zu garantieren und dabei sicherzustellen, IT-Standards zu erfül-len. Das gilt besonders für Änderungen an Softwarekomponenten selbst oder Änderungen an der Konfiguration. Dieser Abschnitt zeigt,
308
Change Request Management 8.2
wie der SAP Solution Manager Sie dabei unterstützt, Änderungen an Softwarekomponenten oder deren Konfiguration durch klar gere-gelte Prozessabläufe und eine lückenlose Dokumentation umzuset-zen, und Ihnen damit die Möglichkeit gibt, Ihre Änderungen und Transporte zentral zu verwalten.
Änderungen in einem Unternehmen finden ihren Ursprung meist in der Fachabteilung. Entweder dadurch, dass Innovation angefordert wird, um das Wachstum und die Weiterentwicklung des Unterneh-mens in einer sich ständig ändernden Marktsituation zu sichern, oder dadurch, dass während des täglichen Betriebs Störungen oder technische Probleme auftreten, die nur durch eine Änderung am Sys-tem oder den Austausch einer IT-Komponente behoben werden kön-nen.
ÄnderungsanträgeIm Change Request Management münden all diese Änderungsanforde-rungen in sogenannten Änderungsanträgen. Dabei bietet das Change Request Management Funktionen, um all diese Änderungen, Anfor-derungen und Änderungsanträge zu verwalten, auszuführen und zu dokumentieren – nicht nur durch Nachverfolgen eines Status, son-dern auch durch eine verbesserte Integration zwischen der Fachab-teilung und der IT bei diesem Prozess. Die Anwendung unterstützt Änderungen von der ersten Anforderung bis zum finalen Deploy-ment im System. Dies setzt eine enge Integration zwischen dem SAP Solution Manager und den verwalteten Systemen sowie eine enge Integration des Change Request Management mit dem Transportwe-sen von SAP selbst voraus. Diese Integration beginnt auf der Geschäfts- und Änderungsprozessebene und geht bis auf die techni-sche Ebene von Transporten und Entwicklungsobjekten.
Major und Minor Releases
Generell unterscheidet SAP zwischen verschiedenen Arten von Änderungen. Basierend auf der Zeit, die benötigt wird, um die Ände-rung durchzuführen und einzusetzen, werden diese in verschiedene Arten von Releases unterteilt. Die größte Kategorie bilden dabei die Major Releases, die eine Laufzeit von drei bis sechs Monaten haben und durch Änderungen die Kerngeschäftsprozesse nachhaltig beein-flussen. Daneben gibt es Minor Releases, die eine wesentlich kürzere Laufzeit haben und in erster Linie genutzt werden, um Fehlerkorrek-turen bereitzustellen und kleinere Anforderungen zu realisieren.
Implemen-tierungs- oder Wartungsprojekt
Innerhalb der IT-Organisation werden diese Änderungen oder Releases entweder durch ein Implementierungsprojekt oder durch
309
Verwaltung der Änderungskontrolle8
ein Wartungsprojekt realisiert, das fortlaufend Änderungen am Sys-tem ermöglicht. Die Projekte sind dabei immer in Phasen unterteilt, um das Projektmanagement sowie die Release-Kontrolle zu unter-stützen. Eine detaillierte Darstellung der Phasen, die im Change Request Management verwendet werden, finden Sie in Abschnitt 8.2.3.
Change Request Management kann außerdem auch in Kombination mit dem Quality Gate Management des SAP Solution Manager ver-wendet werden, um die verschiedenen Phasen und Abschnitte eines Implementierungsprojekts zu kontrollieren. Diese Integration erlaubtes Ihnen, sicherzustellen, dass Qualitätskriterien und Projektstan-dards eingehalten werden, bevor eine Phase eines Projekts abge-schlossen werden kann. Mehr über die Integration von Change Request Management und Quality Gate Management erfahren Sie am Ende dieses Kapitels im Abschnitt 8.2.9.
Wie bereits erwähnt, sind beide Anwendungen eng in die Transpor-tinfrastruktur der SAP integriert. Dies ermöglicht Ihnen, Änderungen von der Anforderung in der Fachabteilung bis zur Umsetzung in der IT zu verfolgen. Die Verwaltung der Transporte wird hierbei zentral vom Change Request Management übernommen, und manuelle Aktivitäten werden auf ein Minimum reduziert.
8.2.1 Change Request Management im Detail
Change Request Management ist ein flexibles Werkzeug, das Sie dabei unterstützt, Entwicklungen und Änderungen an Ihrer gesam-ten Systemlandschaft zentral im SAP Solution Manager zu kontrollie-ren. Für diesen Zweck bietet das Change Request Management eine Reihe von Funktionen.
Das Konzept, auf dem die Prozesse beruhen, besteht dabei im Wesentlichen aus zwei Arten von Dokumenten: dem Änderungsan-trag und dem Änderungsvorgang.
Änderungsantrag Der Änderungsantrag ist das initiale Dokument, in dem die Anforde-rung oder die durchzuführende Änderung erstmals dokumentiert und beschrieben wird und in dem auch die Genehmigung bzw. das Geneh-migungsverfahren des Antrags abläuft und dokumentiert wird.
Änderungsvorgang Sobald Sie einen Änderungsantrag genehmigt haben, werden ein oder mehrere Änderungsvorgänge als Folgedokumente mit direktem
310
Change Request Management 8.2
Bezug zum ursprünglichen Antrag erstellt. Bei den Änderungsvor-gängen wird dabei zwischen verschiedenen Arten von Änderungen unterschieden, je nachdem, ob es sich bei der Änderung um eine Änderung an einem System oder an einer IT-Komponente handelt und von welcher Dringlichkeit die Änderung ist. Im Änderungsvor-gang haben Sie die Möglichkeit, alle Aktivitäten zu dokumentieren und auszuführen, die benötigt werden, um diese Änderung vorzu-nehmen.
So können Sie jederzeit nachzuvollziehen, wo eine konkrete Ände-rung ihren Ursprung hatte, wer sie genehmigt, wer sie umgesetzt und wer sie letztlich in das Produktivsystem eingespielt hat. Ein wesent-licher Vorteil dieser Transparenz ist, dass all diese Informationen jederzeit an einer zentralen Stelle, dem SAP Solution Manager, zur Verfügung stehen und aufgerufen werden können.
Abbildung 8.12 Übersicht über den Standardprozess des Change Request Management
BeispielszenarioEin kurzes Beispiel (siehe Abbildung 8.12) für einen typischen Ände-rungsvorgang mit Change Request Management soll die Vorgehens-weise verdeutlichen: Ein Sachbearbeiter in der Fachabteilung entdeckt einen Änderungsbedarf in einer Transaktion, mit der er arbeitet. Er kann nun direkt aus der Transaktion eine Service-Desk-Meldung erfas-sen, in der er den Sachverhalt beschreibt, und eine Änderung anfor-dern. Die Meldung erscheint daraufhin im Arbeitsvorrat eines Service-
Serv
ice
Des
kC
hang
e R
eque
st M
anag
emen
t
SAP Solution Manager
Service-Desk-
Mitarbeiter
ChangeManager
Tester
Entwickler
IT Operator
AnfordererIncident(Problem)
Änderungs-antrag
Änderungs-vorgang
Kontrollierbare Transporte
Kontrollierbare Transporte
DEV
QAS
PRD
Feedback
311
Verwaltung der Änderungskontrolle8
Desk-Mitarbeiters, der die Meldung bearbeitet und gegebenenfalls einen Änderungsantrag (Request for Change) erzeugt (siehe Abschnitt 8.2.4). Dieser Änderungsantrag 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 gegebenenfalls abzulehnen. Genehmigt er den Antrag, wird ein Änderungsvorgang (Change Trans-action) erzeugt. Der Änderungsvorgang 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 Änderungsantrag ab.
Der Änderungsvorgang 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.
Release Manage-ment mit dem
Change Request Management
Mit den Funktionen des Change Request Management können Sie Releases und Projekte in verschiedener Art und Weise verwalten. 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 (sogenannte dringende Änderungen), z. B. wenn ein Fehler auftritt, der eine Produktivumgebung gefährdet, können hier wohldokumentiert und effizient behoben werden.
Projektplan Eine andere Möglichkeit, Releases mit dem Change Request Manage-ment zu verwalten, ist die Integration mit cProjects, dem Projektpla-nungswerkzeug der SAP. Alle Änderungen, die im Rahmen eines Pro-jekts realisiert werden sollen, können in einem Projektplan in cProjects 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 Aufgaben. Ände-rungsanträge, die das Genehmigungsverfahren durchlaufen haben, können hier eingeplant werden. Dieser Projektplan ist mit dem SAP-Solution-Manager-Projekt, das in einem sogenannten Projektzyklusmehrere 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.
312
Change Request Management 8.2
Integration des Change Request Management mit dem Transport-wesen
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 Trans-portauftrag 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 Änderungsantrag angelegt (darüber hinaus werden auch dessen ID und Kurztext in die Bezeich-nung des Transportauftrags aufgenommen), sodass eine klare Zuord-nung jederzeit möglich ist. Das Change Request Management bietet darüber hinaus die Möglichkeit, alle Transporte im Rahmen eines Pro-jekts nachzuverfolgen und zu kontrollieren, in welchen Systemen sie erzeugt und in welche Systeme sie eingespielt wurden. Über den SAP Solution Manager können Sie zentral in die Transportprotokolle und die Importqueue, aber auch in das Wartungsprojekt des SAP Solution Manager, den Projektplan und die angeschlossenen Systeme navigie-ren. Jeder Änderungsvorgang bietet eine Übersicht aller Transporte und Transportaufgaben, die darüber erstellt wurden. Von dort kann jederzeit der Status der Transporte überwacht werden und ein direkter Absprung in die Log-Datei erfolgen.
Änderungen mit und ohne Transportanschluss
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 wer-den die Schritte dokumentiert, die zur Realisierung nötig sind. Der SAP Solution Manager stärkt somit SAP in ihrer Vision des Applica-tion Management und der IT-Governance, indem er Funktionen zur Verfügung stellt, die unabdingbar sind, um eine transparente Imple-mentierung und Betriebsführung einer Lösung zu garantieren. Dies bildet die Grundlage vieler regulatorischer Bestimmungen; z. B. die Fragen, wer was wann getan und wer kontrolliert und die Genehmi-gung erteilt hat, lassen sich so beantworten.
Um den Betrieb einer Systemlandschaft unter sich ständig ändernden Anforderungen garantieren zu können, müssen folgende Gesichts-punkte berücksichtigt werden:
313
Verwaltung der Änderungskontrolle8
� Änderungsanträge, ob sie aus Fehlermeldungen resultieren oder im Rahmen eines Ideenmanagements direkt erzeugt werden, müs-sen 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 Perso-nen.
� Darüber hinaus muss der Status eines Änderungsantrags zu jeder Zeit nachvollziehbar sein.
Integrierte Teams Ebenso wichtig ist die Integration von Menschen im Unternehmen, wobei die Prozessorientierung des SAP Solution Manager einen wichtigen Beitrag leistet, um die Kommunikation zwischen Fachab-teilung und IT-Administratoren sicherzustellen. Alle an einer Ände-rung beteiligten Personen haben jederzeit Zugriff auf alle relevanten Informationen, wie z. B. Anforderungen, Spezifikationen, Dokumen-tation, Testfälle, Testergebnisse oder Statusanalysen, die anhand der Geschäftsprozesshierarchie im SAP Solution Manager gegliedert und zentral verfügbar sind.
Konformität mit IT-Standards
SAP orientiert sich mit diesem Angebot an den Prozessen der IT Infrastructure Library (ITIL). Ziel des Change Management ist, laut ITIL, die wirtschaftliche und termingerechte Durchführung von Änderungen mit minimalem Risiko. Das Change Request Manage-ment umfasst die Prozesse Verwaltung von Änderungsanträgen, Pro-jektmanagement und Änderungslogistik.
Darüber hinaus ermöglicht das Change Request Management Ihrem Unternehmen, diese Prozesse auf einfache Art und Weise einzuset-zen, indem es vordefinierte Prozesse bietet. Zusätzlich unterstützt es Sie dabei, den Ansprüchen von Audit-Anforderungen wie z. B. von SOX (Sarbanes-Oxley Act) zu genügen, indem alle Nutzer gezwungen werden, Softwareänderungen über die definierten Change-Management-Prozesse zentral über den SAP Solution Mana-ger durchzuführen.
Einsatzbereit out of the Box
Ein großer Vorteil des Change Request Management sind, wie bereits erwähnt, die Standardprozesse und Funktionen, die mit ausgeliefert werden und so schnell eingesetzt werden können.
314
Change Request Management 8.2
Der SAP Solution Manager wird mit vorkonfigurierten Arbeitsabläu-fen für den Änderungsantrag und die Änderungsausführung (Ände-rungsvorgänge) ausgeliefert. Diese Arbeitsabläufe basieren auf den Erfahrungen, die SAP auf dem Gebiet des Change Management und der Transportverwaltung gewonnen hat und die durch viele Kunden-projekte mit beeinflusst wurden. Die folgenden Änderungstypen sind vorausgeprägt:
� Normale ÄnderungAls normale Änderungen werden Anträge wie z. B. das Einspielenvon Support Packages oder von Hinweisen klassifiziert, also Tätig-keiten, die im Rahmen der regulären Systemwartung anfallen.
� FehlerkorrekturEine Fehlerkorrektur dient dazu, Fehler, die während der Testphase auftreten, an die Entwicklung zu melden. Über dieses Dokument kann der Entwickler dann später auch den Fehler beheben, obwohl er in der Testphase keine neuen normalen Änderungen anlegen kann.
� Dringende ÄnderungEine dringende Änderung ermöglicht Ihnen, schnell und flexibel zu reagieren, wenn eine Störung den Betrieb Ihrer Lösung gefährdet. Hier ist es möglich, Änderungen über eine dringende Änderung in die produktiven Systeme zu importieren, bevor die normalen Änderungen in der Produktivstart-Phase des Wartungszyklus ein-gespielt werden.
� Administrative ÄnderungEine administrative Änderung betrifft Änderungen, die keinen Transportanschluss erfordern, also z. B. Änderungen an Num-mernkreisen.
� Allgemeine ÄnderungEine allgemeine Änderung betrifft Änderungen, die keinen Trans-portanschluss erfordern und darüber hinaus nichts mit einem SAP- oder IT-System zu tun haben, also z. B. Änderungen an IT-Komponenten wie Druckern oder mobilen Geräten.
Rollen und Geneh-migungsprofile
Um einen schnellen und reibungslosen Start mit dem Change Request Management zu ermöglichen, liefert SAP ebenfalls eine Reihe vordefinierter Rollen und Genehmigungsprofile aus. Diese Rollen und Prozesse können initial genutzt werden, um einen Mach-
315
Verwaltung der Änderungskontrolle8
barkeitsnachweis mit dem Change Request Management zu erstellen, und später als Grundlage dazu dienen, das Change Request Manage-ment an die individuellen Bedürfnisse oder Change-Management-Prozesse Ihres Unternehmens anzupassen.
8.2.2 Architektur
Um die Architektur des Change Request Management im SAP Solu-tion Manager zu verstehen, ist es zunächst wichtig, die Zusammen-hänge zwischen den verwendeten Entitäten zu klären.
SAP-Solution-Manager-Projekt
Die Grundlage des Change Request Management ist das SAP-Solu-tion-Manager-Projekt (siehe Abschnitt 8.1.1). Das Projekt enthält fol-gende Informationen:
� Logische KomponentenEine logische Komponente beinhaltet alle Systeme, die ein Pro-duktivsystem (bzw. einen produktiven Mandanten) versorgen. Die zugeordneten Systeme sind in der Regel über Transportwege miteinander verbunden.
� IMG-ProjektDas IMG-Projekt wird aus der Projektverwaltung des SAP Solution Manager (Transaktion SOLAR_PROJECT_ADMIN) in verwalteten Systemen angelegt, um Einstellungen, die über den SAP-Einfüh-rungsleitfaden (IMG) für ein SAP-Solution-Manager-Projekt vorge-nommen werden, in einem System zu bündeln.
� CTS-ProjektDas 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 unterstützt die Projektarten Imp-lementierungs-, Upgrade-, Vorlagen- und Wartungsprojekt.
In Abhängigkeit davon, welchen Typ von Änderungsvorgang der Change Manager im Änderungsantrag vor der Genehmigung zuweist, können Sie dem Änderungsantrag zwei Arten von Projekten bzw. Change-Request-Management-Zyklen (Projektzyklus und Wartungszy-klus) zuweisen, die sich aufgrund der unterschiedlichen Anforderun-gen im Ablauf unterscheiden und daher in Abschnitt 8.2.3 näher beleuchtet werden.
316
Change Request Management 8.2
AufgabenplanDer Aufgabenplan (Task List) im Change Request Management stellt Systemadministratoren eine Übersicht über erfolgte und eingeplante Aktionen zur Verfügung. Alle Systeme und die notwendigen Aufga-ben 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 ebenfalls hier hinterlegt. Mehr Informationen zum Aufgabenplan finden Sie in Abschnitt 8.3.1, Unterabschnitt »Zentrales Transportmanagement«.
8.2.3 Projektzyklus und Wartungszyklus
Mehrfach wurde bereits von Implementierungs- und Wartungspro-jekten gesprochen. Dieser Abschnitt soll die Konzepte und Unter-schiede zwischen den beiden Projekttypen näher erläutern.
ProjektzyklusZur Unterstützung von Implementierungs-, Upgrade- und Vorlagen-projekten über das Change Request Management bietet der SAP Solu-tion Manager den Projektzyklus an.
Abbildung 8.13 Wartungsprojekt mit Zyklus und möglichen Änderungsvorgängen
Entwicklungmit Freigabe
Test
Wartungszyklus
Vorbereitungfür Go-Live
Entwicklungohne Freigabe
Go-Live
SAP-Solution-Manager-Projekt (Wartungsprojekt)
Fehler-korrektur
NormaleÄnderung
DringendeÄnderung
AdministrativeÄnderung
317
Verwaltung der Änderungskontrolle8
Der Projektzyklus (dargestellt in Abbildung 8.13) ist ein vorkonfigu-rierter Servicevorgang (Vorgangsart SMDV), 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
Phasen des Projektzyklus
Der Projektzyklus bietet anhand seiner Phasenstruktur eine opera-tive Ergänzung zum Projektplan. Ein einzelner Projektzyklus umfasst folgende Phasen:
� Entwicklung ohne Freigabe
� Entwicklung mit Freigabe
� Test
� Vorbereitung für Produktivstart
� Produktivstart
Nach dem Produktivstart schließen Sie den Projektzyklus ab. Ein Sonderfall des Projektzyklus ist der Wartungszyklus, bei dem ein mehrmaliges Durchlaufen der Phasen möglich ist (siehe unten).
In der Phase Entwicklung ohne Freigabe kann ein Transportauftrag zwar erzeugt, aber nicht freigegeben werden. Diese Phase kann daher auch als initiale Spezifikationsphase oder Planungsphase gese-hen werden. Bei Einsatz der normalen Änderung (Vorgangsart SMMJ) ist die Verwendung dieser Phase für die Entwicklung nicht empfeh-lenswert, da die Erzeugung von Testtransporten in dieser Phase nicht möglich ist. Die Freigabe von Transportaufträgen 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 es, Transporte freizugeben und für Funktionstests 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
318
Change Request Management 8.2
Test aufgetreten sind. Die Phase Vorbereitung für Produktivstarterlaubt es Benutzern mit entsprechender Berechtigung, weitere not-wendige Änderungen durchzuführen, bevor die Änderungen in der Produktivstart-Phase in die produktive Umgebung importiert wer-den. Es können jedoch keine Änderungen importiert werden, die nicht den Status Erfolgreich getestet erreicht haben.
Unterschiede zwischen Wartungszyklus und Projektzyklus
Dem Lebenszyklusmodell folgend, verwenden Sie zur Einführung einer Lösung ein Einführungsprojekt im 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.1). Um diese Lösung aktuell zu halten, ordnen Sie ihr ein Wartungsprojekt mit einem Wartungszyklus zu.
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 kontinuier-licher Prozess – die einzelnen Phasen des Wartungszyklus werden fortlaufend immer wieder durchlaufen.
Phasenmodell des Wartungszyklus
Der Wartungszyklus folgt demselben Phasenmodell wie der Pro-jektzyklus, verfügt jedoch über einige Besonderheiten. Zum einen existiert für den Wartungszyklus eine zusätzliche Art von Ände-rungsvorgang (dringende Änderungen), die es ermöglicht, drin-gende Änderungen flexibel durchzuführen (siehe Abschnitt 8.2.5). 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 War-tungsprojekts werden alle notwendigen Korrekturen über Wartungs-zyklen 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 Pro-duktivstart. Am Ende der Produktivstart-Phase schließen Sie den Zyklus ab, der dabei auf offene und nicht abgeschlossene Geschäfts-transaktionen und Transportaufträge überprüft wird. Nicht abge-schlossene Belege werden so beim Anlegen eines neuen Wartungs-zyklus übernommen.
319
Verwaltung der Änderungskontrolle8
Aus technischer Sicht ist es möglich, den Wartungszyklus nicht abzu-schließen, sondern seine Phase auf Entwicklung ohne Freigabe zurück-zustellen und denselben Zyklus somit erneut zu durchlaufen. Durch Abschließen und Neuanlegen des Wartungszyklus wird jedoch ein nachvollziehbareres und übersichtlicheres Reporting ermöglicht und gewährleistet, weshalb wir Ihnen das Abschließen und Neuanlegen von Wartungszyklen empfehlen.
Beispiel 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 Änderungen sind für den laufenden Wartungszyklus (z. B. Oktober) genehmigt worden. In der Entwicklungsphase stellt sich heraus, dass eine der normalen Änderungen, Änderung Num-mer 9, nicht in der für die Phase anberaumten Zeit realisiert werden kann.
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 kri-tisch ist und keine Abhängigkeiten zu den anderen Änderungen bestehen, können Sie entscheiden, diese Änderung erst im nächsten Wartungszyklus – November – fertigzustellen. Hierfür verbleibt die Änderung im Status In Entwicklung. Die neun anderen Änderun-gen durchlaufen die Test- und Produktivstart-Phasen, werden also in die produktiven Systeme eingespielt. Nun schließen Sie den Zyklus Oktober ab, und die offene Änderung steht zur Übernahme in den neuen Zyklus bereit. Beim Anlegen des Zyklus November wird die Änderung automatisch in diesen Zyklus übernommen und damit zusammen mit den neuen Änderungen des Zyklus konsolidiert bear-beitet.
Dies stellt einen Unterschied zum Projektzyklus dar. Wenn normale Änderungen vorhanden sind, deren Status bei Änderung der War-tungszyklusphase von Entwicklung mit Freigabe in der Testphase noch nicht Erfolgreich Getestet lautet, gibt das System nur eine Warn-meldung aus. Diese Korrekturen werden daraufhin vom Integra-tionstest ausgeschlossen und können nicht freigegeben werden.
Im Wartungsbetrieb können jederzeit Störungsmeldungen auftreten, die eine schnelle Umsetzung erfordern, z. B. wenn ein Ausfall der
320
Change Request Management 8.2
produktiven Systeme droht. In diesem Fall können Sie mit einer nor-malen Änderung 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 Änderungen für diesen Zyklus erfassen. Aus diesem Grund bietet das Change Request Management die dringende Änderung an, die in Abschnitt 8.2.5näher erläutert wird.
8.2.4 Änderungsantrag (Request for Change)
Einem Projekt- oder Wartungszyklus können generell beliebig viele Änderungsanträge zugeordnet werden. Der Änderungsantrag (Re-quest for Change, Vorgangsart SMCR, siehe Abbildung 8.14) ist, ähn-lich wie die Service-Desk-Meldung, ein vorkonfigurierter Servicevor-gang, der alle Daten enthält, die für die Änderung relevant sind. Unter anderem sind dies:
� beteiligte Personen (Auftraggeber, Anforderer, Change Manager, Change Advisory Board)
� von der Änderung betroffenes System (Installation/Komponente)
� das zugehörige SAP-Solution-Manager-Projekt
� Priorität
� Auswirkung
� Dringlichkeit
� Risiko
� Änderungsumfang
� Texte, die die Kommunikation sicherstellen (z. B. Beschreibung der Änderung, Grund der Änderung, Auswirkungen auf Geschäfts-partner, Auswirkungen auf Systeme etc.)
Das Change Request Management bildet somit vom Einholen der Anforderungen über die Implementierung und das Testen bis zur Betriebsführung und kontinuierlichen Verbesserung einer Lösung den kompletten Lebenszyklus ab. Das Szenario ist in die umfassen-den Funktionen des SAP Solution Manager wie etwa Incident Management, E-Learning-Management oder Upgrade-Support inte-griert.
321
Verwaltung der Änderungskontrolle8
Abbildung 8.14 Der Änderungsantrag (Request for Change) in der neuen Web-Client-Oberfläche
Änderungsumfang Im Zuordnungsblock Umfang des Änderungsantrags (siehe Abbil-dung 8.15) können Sie festlegen, welche Art von Änderung vorliegt und in welchem System bzw. welcher Komponente diese Änderung durchgeführt werden soll.
Abbildung 8.15 Zuordnungsblock »Umfang des Änderungsantrags«
Änderungsarten Abhängig davon, welche Änderungskategorie Sie auswählen, legt das System bei der Freigabe der Änderung zur Entwicklung andere Fol-gevorgänge an. Ein Projektzyklus unterstützt vier Änderungsarten,
322
Change Request Management 8.2
anhand derer der Change Manager Änderungsanträge klassifizieren kann:
� normale Änderung
� Fehlerkorrektur
� administrative Änderung
� allgemeine Änderung
Im Gegensatz zur vorangegangenen Version des Change Request Management ist es nun möglich, verschiedene Änderungsarten innerhalb eines Änderungsantrags zu kombinieren. Der Change Manager kann hierfür für jeden neuen Änderungsvorgang einen wei-teren Eintrag in der Tabelle des Zuordnungsblocks Umfang des
Änderungsantrags anlegen. Es ist dabei grundsätzlich möglich, jede Art von Änderung miteinander zu kombinieren. Die zur Verfügung stehenden Systeme oder Komponenten haben außerdem eine Bezie-hung zum SAP-Solution-Manager-Projekt, das dem Dokument im Zuordnungsblock Details zugewiesen wurde. Nur Komponenten, die Teil der Systemlandschaft dieses Projekts sind, können ausge-wählt werden. Eine Ausnahme stellt dabei die allgemeine Änderung dar. Da dieser Änderungstyp unabhängig von einem SAP- oder IT-System zu betrachten ist, gibt es keine Abhängigkeit zur auswähl-baren Komponente.
Genehmigungs-vorgänge
Dem Änderungsantrag kann ein Genehmigungsvorgang zugewiesen werden, der durchlaufen werden muss, bevor der Antrag den Status Genehmigt erreicht.
Abbildung 8.16 Zuordnungsblock »Genehmigung«
Bei einem Genehmigungsvorgang handelt es sich um einen Geneh-migungsprozess, der aus einer festgelegten Reihe von Genehmi-gungsschritten besteht (siehe Abbildung 8.16). Für jeden Genehmi-gungsvorgang kann im Customizing definiert werden, welche Genehmigungsschritte durchgeführt werden müssen. Dabei kann
323
Verwaltung der Änderungskontrolle8
ausgewählt werden, welche Schritte parallel ablaufen dürfen und welche Schritte voneinander abhängig sind.
Geschäftspartner zuweisen
Für jeden Genehmigungsschritt können Sie definieren, welche Geschäftspartnerrolle für die Durchführung verantwortlich ist. Wenn Sie später den Genehmigungsvorgang im Änderungsantrag auswählen, müssen Sie jedem Schritt einen konkreten Geschäftspart-ner zuweisen. Jeder Geschäftspartner kann dann über SAP Business Workflow mit einem Workflow-Item oder einer E-Mail benachrich-tigt werden, wenn eine Entscheidung von ihm benötigt wird.
Zur Durchführung der Genehmigung können Sie zwischen drei ver-schiedenen Möglichkeiten auswählen: Genehmigt, Abgelehnt oder Nicht Relevant. Zusätzlich kann zu jedem Genehmigungsschritt bei der Durchführung ein Kommentar durch den Genehmiger hinterlegt werden. All diese Informationen werden auch im Protokoll des Änderungsantrags mitprotokolliert und lassen sich jederzeit nach-vollziehen.
Sie können beliebig viele Genehmigungsvorgänge im Customizing definieren, die Sie, je nach Änderungsart, einem Antrag zuweisen können. Daneben ist es auch möglich, mithilfe eines Regelwerks eigene Regeln zu definieren, die z. B. basierend auf Feldwerten auto-matisch einen bestimmten Genehmigungsvorgang zuweisen (sind z. B. Dringlichkeit und Priorität der Änderung sehr hoch, soll ein anderer Genehmigungsvorgang verwendet werden als bei einer nor-malen Änderung).
Im Standard liefert SAP einen einfachen Genehmigungsvorgang aus, der nur aus einem Genehmigungsschritt für den Change Manager besteht – diesen können Sie an Ihre Anforderungen anpassen und erweitern.
Prozess des Änderungsantrags
Der Prozess des Änderungsantrags beginnt mit dem Anlegen des Antrags durch den Anforderer, dieser ist dabei entweder ein Mitar-beiter des Service Desk oder, im Fall einer neuen Anforderung, ein Mitarbeiter der Fachabteilung. Er beschreibt die notwendige Ände-rung und fügt alle weiteren nötigen Informationen hinzu, z. B. Spezi-fikationen oder Screenshots. Danach übernimmt der Change Mana-ger das Dokument und ändert den Status des Dokuments von Angelegt in Überprüfung. In diesem Überprüfungsschritt vervoll-ständigt der Change Manager den Änderungsantrag mit weiteren
324
Change Request Management 8.2
relevanten Informationen und beantwortet dabei unter anderem die folgenden Fragen:
� Welches System und welcher Änderungstyp werden benötigt (Definition des Änderungsumfangs)?
� Welches SAP-Solution-Manager-Projekt soll verwendet werden?
� Welche Lösung und welcher Geschäftsprozess sind betroffen?
� Welcher Genehmigungsvorgang soll verwendet werden?
� Wie groß ist das Risiko für diese Änderung?
� Welche Auswirkungen und Dringlichkeit hat die Änderung, und wie ist sie zu priorisieren?
In Abbildung 8.17 ist der Prozess eines Änderungsantrags schema-tisch dargestellt.
Abbildung 8.17 Übersicht über den Prozess eines Änderungsantrags
Genehmigungs-vorgang
Wenn alle diese Fragen beantwortet und die Informationen gesam-melt und in den Antrag eingetragen wurden, übergibt der Change Manager den Antrag zur Genehmigung. Nun startet der zugewiesene Genehmigungsvorgang. Darüber hinaus hat der Change Manager die Möglichkeit, den Änderungsantrag abzulehnen, falls der Antrag nicht realisiert werden soll oder ein ähnlicher Antrag bereits vorliegt.
Wenn alle Genehmigungsschritte erfolgreich durchlaufen wurden und das Ergebnis des Genehmigungsvorgangs positiv ist, wird der Status des Antrags auf Genehmigt gesetzt, und der Change Manager kann nun den Antrag zur Entwicklung oder Umsetzung freigeben. Mit dieser Freigabe werden auch die im Änderungsumfang definier-ten Änderungsvorgänge angelegt, und der Status des Antrags wird auf Laufende Implementierung geändert.
Änderungsantraganlegen
Anforderer Change Manager Change Manager1 – n Genehmiger
Änderungsantraggenehmigen
Übergabe zurEntwicklung
Umfangs-erweiterung
Antragvalidieren
Systemdetailsetc. hinzufügen
Benach-richtigung
viaWorkflow
NeuesÄnderungs-dokument
325
Verwaltung der Änderungskontrolle8
Wenn alle zugewiesenen Änderungsvorgänge ihren Endstatus erreicht haben, ändert sich automatisch der Status des Antrags auf Realisiert. Der Change Manager kann nun als letzten Schritt den Antrag und die Realisierung nochmals überprüfen, bevor er den Sta-tus nach Rücksprache mit dem Anforderer auf Bestätigt setzt.
Umfangs-erweiterung
Eine weitere Neuerung im Prozess des Änderungsantrags mit dem neuen SAP Solution Manager ist die Möglichkeit, den Umfang der Änderung während der Implementierung zu erweitern. Mit der Aktion Umfang erweitern ist es möglich, den definierten Umfang eines Änderungsantrags zu erweitern und weitere Änderungsvor-gänge hinzuzufügen. Somit verlieren Sie auch dann nicht den Über-blick über alle zusammenhängenden Änderungen, wenn diese erst nachträglich hinzugefügt wurden.
8.2.5 Änderungstypen im Change Request Management im Detail
Im Change Request Management unterscheidet man eine Reihe von Änderungstypen, die im vorangegangenen Abschnitt bereits kurz vor-gestellt wurden. Dieser Abschnitt befasst sich näher mit den einzelnen Änderungstypen und beschreibt den Anwendungsfall, den Prozess sowie Besonderheiten der verschiedenen Änderungstypen näher.
Normale Änderung
Statusschema Die normale Änderung (Vorgangsart SMMJ) bildet die Korrektur- oder Änderungsmaßnahmen eines Projekts ab und folgt dem Status-schema:
� Angelegt
� In Entwicklung
� Zu testen
� Erfolgreich getestet
� Importiert in Produktion
� Zurückgezogen
Im Folgenden wird der Prozess, den eine normale Änderung durch-läuft, im Detail erläutert.
Prozess-beschreibung
Ein Anwender entdeckt beim Arbeiten in einem System fehlende Funktionen. Er kann diese Störung direkt aus der Transaktion, in der
326
Change Request Management 8.2
er sich befindet, über eine Service-Desk-Meldung an den SAP Solu-tion Manager melden. Die Service-Desk-Meldung beinhaltet alle relevanten Systemdaten und die Beschreibung der Anforderung.
Der Service-Desk-Mitarbeiter, der die Meldung bearbeitet, stellt fest, dass die Anforderung nur über einen Änderungsantrag realisiert wer-den kann, und legt im Incident Management über die Aktion Folge-
vorgang anlegen einen entsprechenden Änderungsantrag an.
Der Änderungsantrag erscheint im Arbeitsvorrat des Change Mana-gers, der eine Klassifizierung des Änderungsantrags durchführt, festlegt, wie die Änderung durchgeführt werden soll (normale Änderung), und sie genehmigt oder ablehnt. Bei der Bewertung spielt die Priorität des Änderungsantrags eine wichtige Rolle. Details zum Ablauf des Prozesses für den Änderungsantrag finden Sie in Abschnitt 8.2.4.
Wird der Änderungsantrag als normale Änderung genehmigt, erzeugt der SAP Solution Manager automatisch einen Änderungsvorgang vom Typ normale Änderung, sobald der Antrag zur Entwicklung freigege-ben wird. Der Änderungsantrag und der Änderungsvorgang sind über den Dokumentenfluss verbunden, und die Zuordnung ist somit jeder-zeit transparent.
Der Änderungsvorgang bildet die operative Grundlage für Entwick-ler, Tester und Systemadministratoren ab. Zunächst wird der Ent-wickler benachrichtigt, dass eine neue Änderung zur Bearbeitung vorliegt. Er übernimmt diese Änderung und setzt den Status über eine Aktion auf In Entwicklung.
Der Entwickler legt im Entwicklungssystem direkt über den SAP Solution Manager einen Transportauftrag an, meldet sich direkt am Entwicklungssystem an und gibt nach erfolgter Änderung die Trans-portaufgaben im Entwicklungssystem (Transaktion SE09) frei. Nach Abschluss der Entwicklung erzeugt der Entwickler über eine Aktion im Änderungsvorgang einen Testtransport, der in das Testsystem importiert wird. Anschließend erfolgt der Test der Neuentwicklung durch den Entwickler. Verläuft dieser Test erfolgreich, setzt der Ent-wickler den Status Zu testen – hierdurch wird, falls nicht zuvor vom Entwickler veranlasst, ein Transport von Kopien erstellt, der in das Testsystem importiert werden kann. Die neu entwickelte Funktion wird während eines regulären Imports des Projektpuffers durch
327
Verwaltung der Änderungskontrolle8
einen (im verwalteten System) eingeplanten Job in ein Testsystem importiert und dort zunächst einem erneuten Funktionstest unterzo-gen. Dem Tester stehen alle benötigten Funktionen, wie z. B. System-anmeldung, 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 die-selbe Person sein dürfen.
Wenn dieser Test erfolgreich war, setzt der Tester über eine Aktion den Status der Änderung auf Erfolgreich getestet. Der Auftrag aus dem Entwicklungssystem wird nun in das Testsystem exportiert. Alle beschriebenen Tätigkeiten können direkt aus dem Änderungsvor-gang über Aktionen ausgeführt werden.
Mit diesem Schritt endet die normale Änderung, sie enthält ab diesem Zeitpunkt nur noch beschreibende Statuswerte, wird aber aus tech-nischer Sicht an den Projektzyklus übergeben und von diesem voran-getrieben.
Einspielen der Änderungen
Zum Einspielen der Änderungen in die produktiven Systeme müssen Sie folgende Voraussetzungen beachten:
� Der Systemadministrator kann die Änderung nur in das Produktiv-system importieren, wenn sich der entsprechende Projektzyklus in der Phase Produktivstart befindet.
� Der Status kann nur auf Importiert in Produktion gesetzt wer-den, wenn alle normalen Änderungen des Projekts erfolgreich in die produktiven Systeme importiert wurden. Sie können diesen Status für alle importierten normalen Änderungen am Ende eines Projektzyklus setzen, indem Sie den Job CRM_SOCM_SERVICE_
REPORT einplanen.
Normale Änderungen, deren Status noch In Entwicklung lautet, lösen im betreffenden Projektzyklus eine Warnmeldung aus, wenn der Status während der Testphase gesetzt wird.
Dringende Änderung
Dringende Änderungen (Vorgangsart SMHF) verfügen über einen eigenen Aufgabenplan, d. h., sie können unabhängig von der Phase des zugeordneten Wartungszyklus transportiert werden. So ist es
328
Change Request Management 8.2
möglich, Änderungen über eine dringende Änderung in die produk-tiven Systeme zu importieren, bevor die normalen Änderungen in der Produktivstart-Phase des Wartungszyklus eingespielt werden. Dringende Änderungen können auch nur im Zusammenhang mit einem Wartungsprojekt angelegt werden und stehen für Implemen-tierungsprojekte nicht zur Verfügung.
Transport-steuerung
Hierzu wird die Transportmethode IMPORT_SUBSET verwendet, d. h., die Transportaufträge, die aus einer dringenden Änderung generiert worden sind, werden in den Transportpuffer geschrieben und in die Folgesysteme importiert. Nach dem Import verbleiben sie jedoch im Puffer. Beim regulären Import über den Aufgabenplan des Wartungs-zyklus wird der gesamte Transportpuffer des Projekts über die Methode Import_Project_All konsolidiert importiert, d. h., die dringenden Änderungen werden nochmals eingespielt. So wird die Konsistenz der Daten sichergestellt.
StatusschemaDie dringende Änderung hat folgendes Statusschema:
� Angelegt
� In Entwicklung
� Zu testen
� Erfolgreich getestet
� Freigegeben für Produktion
� Importiert in Produktion
� Bestätigt
� Abgeschlossen
� Zurückgezogen
In der ausgelieferten Version importiert der SAP Solution Manager die Transportaufträge einer dringenden Änderung automatisch in das Testsystem, wenn Sie den Status Zu testen setzen. Diese Einstel-lung wurde vorgenommen, um den Prozess weiter zu beschleunigen, Sie können diese Einstellung jedoch über das Customizing ändern.
Administrative Änderung
Eine administrative Änderung (Vorgangsart SMAD) dient dazu, Ände-rungen an Systemen abzubilden, die keine Transporte erfordern, wie
329
Verwaltung der Änderungskontrolle8
z. B. Änderungen an Nummernkreisen oder Benutzerdaten, hierbei aber dennoch die komplette Änderungshistorie zu bewahren. Die administrative Änderung bietet Zugang zum Aufgabenplan und zu Aktivitäten, wie z. B. einer Systemanmeldung, und hat folgendes Sta-tusschema:
Statusschema � Angelegt
� In Bearbeitung
� Abgeschlossen
� Bestätigt
� Zurückgezogen
Allgemeine Änderung
Eine allgemeine Änderung (Vorgangsart SMCG) dient dazu, Änderun-gen an nicht-systemrelevanten Objekten abzubilden, die keine Trans-porte erfordern und unabhängig von Projekten im SAP Solution Manager sein können, wie z. B. Änderungen an einem mobilen Gerät oder einem Drucker.
Statusschema Die allgemeine Änderung bietet hierfür ein abstraktes Statusschema, das jederzeit an Ihre individuellen Bedürfnisse angepasst werden kann:
� Angelegt
� In Bearbeitung
� Zu testen
� Änderungsdokumentation
� Änderungsauswertung
� Fehlgeschlagen
� Ursprung wiederherstellen
� Bestätigt
� Abgebrochen
� Zurückgezogen
Die Bearbeitung einer allgemeinen Änderung beginnt, wie die ande-ren Änderungen, durch Setzen des entsprechenden Status durch die Person, die die Änderung durchführt. Nach einem erfolgreichen Test
330
Change Request Management 8.2
muss die Änderung gegebenenfalls nochmals gesondert dokumen-tiert und ausgewertet werden. Falls diese Auswertung erfolgreich ist, kann die Änderung bestätigt werden. Es kann aber auch nötig sein, die Änderung wieder rückgängig zu machen, falls die aktuelle Umset-zung eine Verschlechterung der Situation bedeutet.
Fehlerkorrektur
Nur in TestphaseFehlerkorrekturen (Vorgangsart SMTM) können Sie nur während der Testphase des Projekt- oder Wartungszyklus anlegen. Da die Fehler-korrektur während des Integrationstests genutzt wird und sich dieser Test auf das gesamte Projekt (also alle Änderungen) bezieht, hat sie keinen Bezug zu einer einzelnen Änderung oder einem Änderungs-antrag. 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 Fehlerkorrektur keine Genehmigungsschritte. Sie folgt dem Statusschema:
Statusschema� Angelegt
� In Korrektur
� Zum Nachtesten
� Bestätigt
� Zurückgezogen
Die Fehlerkorrektur ist notwendig, da in der Testphase keine neuen normalen Änderungen angelegt werden können, denn dies würde den festgelegten und genehmigten Umfang des Projekts verzerren.
Ein Tester legt eine Fehlerkorrektur an und beschreibt die aufgetre-tenen 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 Zum Nachtesten. Nach erneutem Import des Transportpuffers in das Testsystem über-prüft der Tester die Funktionen und bestätigt den Testerfolg mit dem Status Bestätigt. Beim Projektimport in der Produktivstart-Phase werden dann alle Änderungen und Fehlerkorrekturen gemeinsam in das Produktivsystem eingespielt.
331
Verwaltung der Änderungskontrolle8
8.2.6 Änderungsverwaltung mit dem Change Request Management
Alle Funktionen des Change Request Management, die bisher beschrieben wurden, sind sehr flexibel und können an die individu-ellen Anforderungen eines Unternehmens angepasst werden. Dies beginnt bei der Unterstützung verschiedener Technologien und Sys-temlandschaften und endet beim Design und der Modellierung kom-plexer Arbeitsabläufe und individueller Prozesse.
Unterstützte Systemland-schaften und Technologien
Das Change Request Management ist so flexibel wie Ihr Geschäft und unterstützt viele verschiedene Systemlandschaften. Neben einer Drei-System-Landschaft können auch weitaus komplexere Land-schaften mit dem Change Request Management verwaltet werden.
Neben den verschiedenen sequenziellen Typen von Systemland-schaften ist das Change Request Management aber auch fähig, andere Arten von Landschaften zu verwalten, z. B. duale Landschaften, d. h., die Belieferung paralleler Testsysteme oder die Synchronisation par-alleler Entwicklungs- und Wartungslandschaften ist möglich (siehe Abschnitt 8.3.2). Auch selbstständige Sandbox-Systeme können in den Prozess eingebunden und adäquat mit Transporten versorgt wer-den. Generell unterstützt das Change Request Management alle Landschaften, die mit dem Transport Management System der SAP abgebildet werden können.
Offenheit Das Change Request Management kann aber nicht nur genutzt wer-den, um Änderungen an SAP-Landschaften zu verwalten. Durch die Integration mit dem erweiterten Änderungs- und Transportsystem(CTS+) ist es Ihnen möglich, auch Nicht-ABAP- und sogar Nicht-SAP-Technologien wie Java, C++ oder Microsoft .NET mit den Ände-rungsvorgängen des Change Request Management zu verwalten.
Die System-landschaft im
Änderungsvorgang
Innerhalb eines Änderungsvorgangs können Sie sich jederzeit die komplette Systemlandschaft bzw. den vom Change Request Manage-ment generierten Transportpfad inklusive der Systemrollen anzeigen lassen.
Der Zuordnungsblock Systemlandschaft zeigt dabei eine tabellari-sche Übersicht der einzelnen Systeme, die dem aktuellen Projekt über logische Komponenten zugeordnet wurden. In der Spalte Akti-
onen können Sie sich am System direkt anmelden, um z. B. dort eine Änderung durchzuführen oder eine geänderte Funktionalität zu tes-
332
Change Request Management 8.2
ten. Der Zuordnungsblock zeigt daher im Standard immer nur das momentan relevante System an. Dieses wird über den aktuellen Sta-tus des Änderungsvorgangs bestimmt, z. B. wenn sich der Ände-rungsvorgang im Status In Entwicklung befindet, ist das relevante System das Entwicklungssystem.
Flexible Arbeits-abläufe und Workflows
Wie bereits beschrieben, folgt jede Art von Änderungsvorgang einem eigenen und vordefinierten Arbeitsablauf, was es einfach macht, diese Funktionen sofort einzusetzen.
Viele Unternehmen haben jedoch bereits heute einen Change-Management-Prozess etabliert und wollen diesen nicht wegen der Einführung einer neuen Anwendung anpassen. Deshalb sind alle Prozesse des Change Request Management sehr flexibel und können an Ihre individuellen Anforderungen angepasst werden.
Dies beginnt bei der Definition der Genehmigungsvorgänge und geht bis zur Definition und Modellierung der verschiedenen Prozess-schritte im Detail. Außerdem können die existierenden Änderungs-vorgänge auch kopiert werden, um existierende Aktionen und deren Konditionen zu bearbeiten oder komplett neue Aktionen und Kondi-tionen zu definieren.
Mehrstufige Kategorisierung
Die mehrstufige Kategorisierung erlaubt Ihnen, jedes Dokument im Change Request Management und im SAP-IT-Servicemanagement detailliert zu kategorisieren, wobei im Standard vier Kategorieebe-nen zur Verfügung stehen, die in einer Baumstruktur aufgebaut und voneinander abhängig sind.
Mehr Informationen zu dieser Funktion finden Sie auch in Abschnitt 9.1.7, Unterabschnitt »Mehrstufige Kategorisierung«.
Transport-verwaltung im Change Request Management
Die Integration von Change Request Management und Transportwe-sen stellt sich vor allem im Zuordnungsblock Transport Manage-
ment eines Änderungsvorgangs dar (siehe Abbildung 8.18). Der Zuordnungsblock ist den Dokumenttypen normale Änderung, drin-gende Änderung sowie Fehlerkorrektur zugeordnet.
Neben einer Übersicht über alle relevanten Transportaufträge und Transportaufgaben eines Änderungsantrags bietet der Zuordnungs-block einen zentralen Zugriffspunkt zu allen transportrelevanten Aktionen und Funktionen.
333
Verwaltung der Änderungskontrolle8
Abbildung 8.18 Zuordnungsblock »Transport Management«
Über Drucktasten können neue Transportaufträge oder Transport-aufgaben angelegt werden, Aufträge freigegeben oder kritische Ob-jekte genehmigt werden. In einer Tabelle werden alle Transporte ge-listet und weitere Detailinformationen, wie der Besitzer des Transports, der Typ des Auftrags, der Status sowie die Anzahl der Transportaufgaben, angezeigt. Mit einem Klick können Sie direkt in die Transportprotokolle oder die Stückliste des Transportauftrags ab-springen.
Wenn von einem Transport bereits Transporte von Kopien angelegt wurden, wird dies ebenfalls dargestellt. In einem Pop-up können Sie nachvollziehen, wie oft ein Kopietransport erstellt wurde und wel-cher Kopietransport der aktuelle ist. Daneben zeigen weitere Spalten in der Tabelle, ob der Transport kritische Objekte beinhaltet oder Konflikte mit anderen Transporten entdeckt wurden.
8.2.7 Zentrale Änderungskontrolle
Eines der Ziele des Change Request Management ist, einen Kontroll-mechanismus bereitzustellen, um einen sicheren und reibungslosen Software-Deployment-Prozess zu gewährleisten. Um dies zu errei-chen, nutzt das Change Request Management eine Reihe von Funkti-onen, die Ihnen in verschiedenen Situationen helfen können, Ihre Änderungen konsistent zu halten und die Anzahl der Störungen und Probleme entlang der Prozessausführung zu minimieren.
Eingebaute Transport-Best-
Practices
Vielleicht der wichtigste Punkt des Change Management ist, einen Überblick darüber zu behalten, welche Änderungen in die produk-
334
Change Request Management 8.2
tive Umgebung eingespielt werden und welche Transporte über-haupt vom Entwicklungssystem über das Testsystem in das Produk-tivsystem gelangen dürfen. Dabei soll die Integrität der einzelnen Systeme natürlich zu keiner Zeit gefährdet werden.
Das Change Request Management hat eingebaute Transport-Best-Practices von SAP, die die Arbeit mit Änderungen erleichtern und Ihnen helfen, Fehler zu vermeiden. Ein Beispiel hierfür ist die Nut-zung von Transporten von Kopien.
Weitere Informationen finden Sie darüber hinaus in Abschnitt 8.3,der sich speziell mit dem Thema Transportverwaltung beschäftigt.
Konsistente Transporte
Das Tagesgeschäft wird es nötig machen, normale und dringende Änderungen auf derselben Systemlandschaft zu kombinieren, auch wenn die reguläre Wartung noch immer andauert. Falls hierbei ein Objekt geändert wurde, das gleichzeitig auch von einer Neuentwick-lung betroffen ist, kann dies zu Problemen führen, wenn man die Transporte nicht in der richtigen Reihenfolge importiert. Das Change Request Management hat eine eingebaute Sicherheitsfunktion, um die sichere Bearbeitung von normalen und dringenden Änderungen zu gewährleisten und diese immer in der korrekten Reihenfolge zu importieren.
Zur Transportsteuerung verwendet das Change Request Manage-ment die Transportmethode IMPORT_PROJECT_ALL. Dies hat den Vor-teil, dass Sie projektbezogen arbeiten können und die Transportauf-träge am Ende der Zyklusphasen harmonisiert und konsolidiert in der Reihenfolge ihrer Freigabe in die Folgesysteme eingespielt wer-den. Diese Vorgehensweise minimiert das Risiko sogenannter Über-holer im Transportwesen. Am Ende des Projekts können Sie die gesammelten Änderungen in die produktiven Systeme importieren und das Projekt abschließen. Das bedeutet, beim Projektimport wer-den alle dringenden Änderungen beachtet und nochmals in der rich-tigen Reihenfolge importiert, um Inkonsistenzen auszuschließen.
System-übergreifende Objektsperre
Stellen Sie sich verschiedene Implementierungs- und Wartungspro-jekte, die gleichzeitig in Ihrer Lösungslandschaft durchgeführt werden, vor – einige dieser Projekte arbeiten sogar in derselben Systemland-schaft aus Entwicklungs-, Qualitätssicherungs- und Produktivsystem. Wenn ein Entwickler ein Objekt ändert, das später von einem anderen Entwickler geändert wird, sind alle Änderungen des ersten Entwicklers
335
Verwaltung der Änderungskontrolle8
verloren. Dieses Problem kann durch die Verwendung der systemüber-greifenden Objektsperre verhindert werden.
Die systemübergreifende Objektsperre sorgt dafür, dass beim Ändern eines Objekts in einem verwalteten System ein Sperreintrag im zentralen SAP-Solution-Manager-System erstellt wird. Dieser Ein-trag verhindert dann, je nach Konfiguration der Objektsperre, dass eine weitere Änderung am selben Objekt in irgendeinem anderen Transportauftrag gemacht werden kann. Die systemübergreifende Objektsperre kann hierbei nicht nur ABAP-, sondern auch Customi-zing-Objekte schützen. Der Einsatz minimiert das Risiko eines Down-grades durch unterschiedliche Produktivstart-Zeitpunkte von Ände-rungen in parallel laufenden Projekten. Weitere Details finden Sie in Abschnitt 8.3.1.
Kritische Objekte Für sogenannte sensitive oder kritische Objekte – also Objekte, die direkten Einfluss auf Kerngeschäftsprozesse haben – kann eine Prü-fung aktiviert werden, die vor dem Export eines Transportauftrags ausgeführt wird. Transportaufträge, die kritische Objekte enthalten, müssen separat genehmigt werden.
Die Prüfung kann sowohl auf systemspezifischer als auch mandan-tenspezifischer Ebene aktiviert werden. Während ein Transportauf-trag exportiert wird, berechnet das System den Zielmandanten sowie das Zielsystem. Wenn die Prüfung auf kritische Objekte für den jeweiligen Zielmandanten oder das Zielsystem aktiviert wurde, prüft das System, ob der Auftrag kritische Objekte oder Subobjekte ent-hält. Wenn dies der Fall ist, wird der Export nicht durchgeführt.
Um den Transport dennoch durchzuführen, muss das Objekt von einer zuständigen Person genehmigt und damit zum Export freigege-ben werden. Dadurch lässt sich leicht ein zusätzlicher Schutz für Ihre Anwendungen realisieren.
Projektphasenverwaltung
Durch die eingebaute Phasenkontrolle im Change Request Manage-ment ist sichergestellt, dass immer nur die richtigen und erlaubten Transportaktionen ausgeführt werden können. Bei der Verwaltung und der Kontrolle der Phasen der Wartungs- und Implementierungs-projekte können Sie z. B. sicherstellen, dass der Stand Ihres Testsys-tems während der Testphase immer konstant bleibt und keine neuen
336
Change Request Management 8.2
Änderungen eingespielt werden können, die dann gegebenenfalls ungetestet in die Produktion gelangen würden (siehe Abbildung 8.19).
Abbildung 8.19 Der Wartungszyklus in der neuen Web-Client-Oberfläche
Die Phasenkontrolle ist mit den verschiedenen Änderungstypen inte-griert, um sicherzustellen, dass nur die korrekten Änderungsvor-gänge in bestimmten Phasen eingesetzt werden, z. B. Fehlerkorrektu-ren in der Projektphase Test. Dadurch können Sie zentral im SAP Solution Manager alle Ihre Wartungs- und Implementierungspro-jekte kontrollieren.
Arbeiten mit Projektzyklen
Ein kurzes Beispiel soll das Konzept des Projektzyklus verdeutlichen: Der Projektleiter legt ein Projekt im SAP Solution Manager an (Im-plementierungs-, Upgrade- oder Vorlagenprojekt) und generiert zu diesem Projekt die IMG- und CTS-Projekte sowie einen Projektzyk-
337
Verwaltung der Änderungskontrolle8
lus. Der Systemadministrator aktiviert den Zyklus im Beleg des Pro-jektzyklus (Vorgangsart SMMN) über die entsprechende Aktion. Zu diesem Zeitpunkt können Sie bereits Änderungsanträge anlegen, klassifizieren und genehmigen. Damit legen Sie in dieser Phase be-reits den Projektumfang fest.
Bei der Genehmigung ordnet der SAP Solution Manager die resultie-renden Änderungsvorgänge dem Projektzyklus zu. Falls mehrere Projekte gleichzeitig bearbeitet werden, kann mehr als ein Projektzy-klus existieren. In jedem Fall legen Sie bereits im Vorfeld durch die Zuweisung eines Projekts zum Änderungsantrag fest, welcher Zyklus verwendet wird.
Entwicklung ohne Freigabe
Der Change Manager setzt den Status des Projektzyklus auf Entwicklungohne Freigabe. Wenn dieser Status gesetzt ist, können Änderungen von den Entwicklern bearbeitet und im System entwickelt werden. Die Entwickler können Transportaufträge und Transportaufgaben anle-gen, können diese jedoch nicht freigeben und auch nicht exportie-ren. Diese Phase kann daher auch als initiale Spezifikationsphase oder Planungsphase gesehen werden. Bei Einsatz der normalen Änderung (Vorgangsart SMMJ) ist die Verwendung dieser Phase für die Entwicklung nicht empfehlenswert, da die Erzeugung von Test-transporten in dieser Phase nicht möglich ist.
Entwicklung mit Freigabe
Wenn der Change Manager den Status des Projektzyklus von Ent-wicklung ohne Freigabe in Entwicklung mit Freigabe ändert, können die Entwickler Transporte von Kopien ihrer vorgenommenen Änderun-gen erzeugen, die zu Testzwecken ins Testsystem importiert werden. Dieser Import erfolgt idealerweise durch eingeplante Jobs oder aber manuell durch den Systemadministrator im Aufgabenplan.
In vielen Fällen existieren in den Entwicklungssystemen keine Stamm- oder Bewegungsdaten, die den Entwicklern erlauben, die von ihnen entwickelten Änderungen zu testen. Diese Daten sind oft nur im Testsystem verfügbar. Daher besteht in dieser Phase des Pro-jektzyklus die Möglichkeit, vor dem Integrationstest Zeit für funktio-nale Tests einzuplanen, d. h. einen Zeitraum, in dem die Entwickler die Änderungen nach dem Import in die Testsysteme selbst prüfen können, um anschließend den Status ihrer Änderungen auf Zu tes-
ten zu setzen. Anschließend erfolgt ein erneuter Transport von Kopien ins Testsystem. Der Tester sieht die zu testende Änderung in
338
Change Request Management 8.2
seinem Arbeitsvorrat im Work Center oder SAP Web Client und kann den Test durchführen. War der Test erfolgreich, setzt der Tester den Status der Änderung auf Erfolgreich getestet und stößt damit im Hintergrund den Export der Änderung aus dem Entwicklungssystem an.
TestNach dem Wechsel in die Testphase können Transportaufträge aller Änderungen, die den Status Zu testen noch nicht erreicht haben, nicht mehr exportiert werden. Dazu erhält der Anwender eine ent-sprechende Warnung, wenn er den Phasenwechsel wie von SAP empfohlen im Beleg (Vorgangsart SMMN) vornimmt. Durch dieses Verhalten wird ein Einfrieren des Codings (Code Freeze) ab Beginn der Testphase herbeigeführt. Dringende Änderungen sind von die-sem Verhalten nicht betroffen und können weiterhin verwendet werden.
In der Testphase können Tester die Änderungen auf funktionale und fachliche Richtigkeit überprüfen. Findet ein Tester einen Fehler, kann er diesen über einen Beleg vom Typ Fehlerkorrektur (Vorgangs-art SMTM) dokumentieren und den betreffenden Entwickler auf den Fehler aufmerksam machen. Über diese Fehlerkorrektur kann ein Entwickler im Entwicklungssystem einen neuen Transportauftrag anlegen und den Fehler bereinigen. Die Testphase gilt als abgeschlos-sen, wenn alle Änderungen und Fehlerkorrekturen im Status Erfolg-
reich getestet vorliegen. Änderungen, die diesen Status noch nicht erreicht haben, können nicht vom Test ausgenommen werden, d. h., sie müssen entweder erfolgreich getestet oder zurückgenommen werden.
Vorbereitung für den Go-Live (Notkorrektur)
Wenn nach Abschluss der Testphase weitere Änderungen vorgenom-men werden müssen, können Transportaufträge und -aufgaben im Rahmen der Go-Live-Vorbereitungen bzw. der Notkorrekturphase zwar angelegt, freigegeben und transportiert werden, jedoch nur über den Aufgabenplan (Task List) des Projektzyklus und mit ent-sprechenden Berechtigungen. Dringende Änderungen sind davon nicht beeinflusst und können weiterhin verwendet werden.
Go-LiveIn der Go-Live-Phase wird der gesamte Transportpuffer des CTS-Pro-jekts in der Reihenfolge der Freigabe in die Produktivsysteme impor-tiert. Während dieser Phase können keine Transportaufträge ange-legt oder freigegeben werden, auch die Verwendung dringender Änderungen ist nicht mehr möglich. Nach dem Import in die produk-
339
Verwaltung der Änderungskontrolle8
tive Systemumgebung existieren keine offenen Transportaufträge mehr, und der Transportpuffer ist leer. Sie können nun den Projekt-zyklus abschließen, indem Sie den Status auf Bestätigt setzen. Damit ist das Projekt beendet.
Das Weiterschalten der Projektphase sollte grundsätzlich über die entsprechende Aktion im Beleg (Vorgangsart SMMN) erfolgen. In einer Drei-System-Landschaft befinden sich z. B. alle Transportauf-träge von dringenden Änderungen, die im Status Zu testen sind, im Importpuffer des Produktivsystems. Erfolgt das Umschalten der Phase nicht über den Beleg, sondern über den Aufgabenplan, erhält der Anwender keine Warnungen über diesen Zustand – die dringen-den Änderungen würden somit ungetestet importiert werden. Beim Weiterschalten der Phase über den SMMN-Beleg erfolgen entspre-chende Prüfungen, sodass der Anwender gewarnt ist und entspre-chend reagieren kann.
8.2.8 Transparenz über Änderungsprozesse
Das Change Request Management ist nicht nur ein Werkzeug zur Kontrolle und Verwaltung Ihrer Änderungen, sondern gibt Ihnen auch jederzeit die Möglichkeit, detaillierte Informationen über den Status des gesamten Change-Management-Prozesses zu erhalten. Im Folgenden erhalten Sie einen kurzen Überblick über die verschiede-nen Monitoring- und Reporting-Funktionalitäten.
Monitoring- und Überwachungsfunktionen
Die neue Benutzeroberfläche des Change Request Management bie-tet viele Möglichkeiten, die Abarbeitung und den Status der einzel-nen Änderungsanträge und Änderungsvorgänge zu überwachen und einen Überblick über den Gesamtstatus des Change Management zu bekommen.
Im Bereich Verwaltung von Änderungsanträgen in der SAP-IT-Servicemanagement-Benutzerrolle haben Sie die Möglichkeit, eine Reihe von vorkonfigurierten Suchmasken zur Suche nach Ände-rungsvorgängen zu verwenden. Die Suchmasken teilen sich dabei in die Bereiche Änderungsantrag, Änderungsvorgang sowie Pro-
jektzyklus auf (siehe Abbildung 8.20).
340
Change Request Management 8.2
Abbildung 8.20 Suche nach Änderungsanträgen in der neuen Web-Client-Oberfläche
Gespeicherte Suche
Jede Seite bietet eine Reihe von Suchkriterien, die sich völlig frei mit-einander kombinieren lassen. Damit haben Sie die Möglichkeit, indi-viduelle Suchanfragen zu erstellen, und jeder Benutzer kann sich damit einen personalisierten Arbeitsvorrat erzeugen, da sich jede Zusammenstellung als sogenannte gespeicherte Suche sichern lässt.
Die gespeicherten Suchen können Sie zentral im oberen Bereich der Benutzeroberfläche auswählen und jederzeit, unabhängig von der aktuellen Position in der Anwendung, aufrufen.
Die Ergebnisse der Suche werden in einer Tabelle übersichtlich dar-gestellt, wobei jede Tabellenspalte beliebig sortiert und gefiltert wer-den kann. Über die Personalisierungsfunktionen kann jeder Anwen-der für sich selbst bestimmen, welche Tabellenspalten relevant sind,
341
Verwaltung der Änderungskontrolle8
in welcher Reihenfolge diese angezeigt werden sollen und welche Information ausgeblendet werden soll.
Neben der tabellarischen Darstellung kann das Suchergebnis auch grafisch als interaktives Torten- oder Säulendiagramm angezeigt wer-den. Durch Klick auf ein bestimmtes Segment filtert das System die Suchergebnisse automatisch. Zur weiteren Bearbeitung können die Suchergebnisse auch in ein Tabellenverarbeitungsprogramm expor-tiert werden.
Change-Request-Management-
Reporting
Die Reporting-Funktionalitäten des Change Request Managementkönnen ohne großen Einrichtungsaufwand verwendet werden und sind somit ebenfalls »out of the box« verfügbar. Alle Abfragemöglich-keiten und Ergebnislisten sind bereits vordefiniert und können direkt verwendet werden, zusätzlich gibt es eine Reihe von Filter- und Einstellungsmöglichkeiten.
Change-Request-Management-Ereignisse, wie z. B. das Ändern eines DDIC-Objekts in einem Entwicklungssystem oder die Implementie-rung eines SAP-Hinweises, werden immer im Kontext von SAP-Solu-tion-Manager-Projekten oder -Lösungen durchgeführt. Die Ereig-nisse, die beim Bearbeiten eines Änderungsvorgangs ausgeführt werden, sind über die komplette Systemlandschaft verteilt, benöti-gen Genehmigungen und eine klare Zuweisung von Aufgaben.
Die Reporting-Funktion des Change Request Management analysiert diese Transaktionen und die zugehörigen Ereignisse, konsolidiert sie und zeigt sie in einer Übersicht an. Dabei ist es nicht nötig, ein sepa-rates SAP NetWeaver Business Warehouse (BW) bereitzustellen, da Sie das im SAP Solution Manager integrierte BW-System verwenden können. Ein Reporting-Service, der im Hintergrund läuft, sammelt die Daten automatisch, sowohl vom SAP Solution Manager als auch von den verwalteten Systemen.
Erfasste Entitäten Die Reporting-Transaktion (Transaktionscode /N/TMWFLOW/REPOR-TINGN) erlaubt eine Anzeige und Auswahl über folgende Entitäten:
� Änderungsvorgänge und Änderungsanträge
� SAP-Solution-Manager-Lösungen und -Projekte
� Change-Request-Management-Aufgabenpläne (Task Lists)
� Systeme
� Support Packages
342
Change Request Management 8.2
� SAP-Hinweise
� Transportaufträge
� Transportobjekte
Der Nutzer kann frei entscheiden, welche Daten er benötigt, und kann zusätzliche Filterkriterien festlegen. Das Ergebnis wird in einer Übersicht dargestellt, die viele zusätzliche Funktionen und Absprünge (z. B. in den Änderungsvorgang, die Task List etc.) bietet.
Wie auch bei den Monitoring- und Überwachungsfunktionen kön-nen all diese Daten in ein Tabellenverarbeitungsprogramm zur Nach-bearbeitung exportiert werden.
Änderungs-nachverfolgung
Neben dem Reporting bietet das Change Request Management auch Funktionen zur Nachverfolgung (Transaktion /TMWFLOW/TRMO) an. Eine besondere Übersichtsdarstellung enthält dabei viele ver-schiedene Informationen und erlaubt eine eingehende Analyse.
Zum Beispiel sind folgende Informationen nachvollziehbar:
� das Quellsystem, in dem ein bestimmter Transportauftrag erstellt wurde
� das Zielsystem, in das ein bestimmter Transportauftrag importiert wurde
� die Anzahl der Transportaufträge, die aus dem Zielsystem exportiert wurden
� die Anzahl der Transportaufträge, die angelegt wurden, aber noch nicht freigegeben sind
� die Anzahl der Transportaufträge, die einen Importfehler erzeugt haben
Darüber hinaus ist es z. B. auch möglich, festzustellen, ob Änderun-gen in der korrekten Reihenfolge in das Zielsystem importiert wur-den oder ob es zu Inkonsistenzen zwischen dem Quell- und Ziel-system hinsichtlich des Exports und Imports von Änderungen gekommen ist.
Systeme vergleichen
Eine weitere Funktion des Change-Request-Management-Trackings ist der Vergleich von zwei Systemen, um herauszufinden, ob alle Transportaufträge korrekt exportiert und importiert wurden oder ob es Differenzen gibt. Dabei können zunächst alle Objekte pro System in einem geteilten Bildschirm angezeigt werden. Wenn Sie z. B. fest-
343
Verwaltung der Änderungskontrolle8
stellen wollen, welche Unterschiede existieren, können Sie mit einem Klick einen Filter aktivieren, der Ihnen das Ergebnis übersicht-lich darstellt.
8.2.9 Integration des Change Request Management mit den anderen Application-Lifecycle-Management-Funktionen
Neben dem Transportwesen ist das Change Request Management in viele weitere Prozesse und Anwendungen des SAP Solution Manager integriert (siehe Abbildung 8.21) und kann gemeinsam mit diesen verwendet werden. Dieser Abschnitt gibt Ihnen einen Überblick über die verschiedenen Integrationsaspekte des Change Request Management, die neben der Integration in die technische Infrastruk-tur heute existieren.
Abbildung 8.21 Übersicht über die Integrationen des Change Request Management
Integration mit dem Quality Gate
Management
Durch die Verwendung der gleichen Basistechnologien ist es mög-lich, das Quality Gate Management und das Change Request Manage-ment integriert und in der gleichen Landschaft für unterschiedliche Projekttypen parallel zu betreiben.
ALM-Funktionen
Technische Infrastruktur
IT-Service-management
Quality Gate Management
Transport Management System Erweitertes Change & Transport System
System-empfehlungen
Projekt- undLösungsver-zeichnisse
Test-management
Job SchedulingManagement
Change RequestManagement
344
Change Request Management 8.2
So kann das Change Request Management für ein Wartungsprojekt und das Quality Gate Management für ein Implementierungsprojekt verwendet werden. Typischerweise basiert ein Wartungsprojekt auf einzelnen Änderungen, die genehmigt und dokumentiert werden müssen, während ein Implementierungs- oder Release-Projekt einen definierten Umfang abdeckt, der zu Beginn genehmigt und danach realisiert wird. Durch die konsequente Umsetzung der SAP Best Practices für den Transport werden beide Projekte vor Inkonsisten-zen und Überholern geschützt (siehe Abschnitt 8.1.3).
Auch die Integration der beiden Werkzeuge ist möglich. Durch die Definition von Quality Gates (Q-Gates) auf einem für das Change Request Management konfigurierten SAP-Solution-Manager-Projekt kann diese Integration einfach aktiviert werden. Folglich kann der Benutzer das Quality Gate Management integrativ mit dem Change Request Management betreiben.
Bei diesem Szenario steuert das Change Request Management den gesamten Änderungsprozess, der sowohl das Anlegen, Genehmigen und Dokumentieren aller Änderungen beinhaltet als auch das Anlegen, Freigeben und Importieren der zum Projekt gehörigen Transportauf-träge. Das Quality Gate Management übernimmt dabei die Steuerung der Phasen und visualisiert die Inhalte des Change-Request-Manage-ment-Projekts. Damit stellt das Quality Gate Management den Q-Gate-Kalender, die Änderungsvorgänge, die Transportaufträge und die Risi-ken des Change-Request-Management-Projekts dar. Es agiert in dieser Rolle als eine Art Change Management Dashboard, das es dem Projekt-management-Team erlaubt, hilfreiche Informationen zur Verfügung zu stellen, um etwaige auftretende Risiken frühzeitig zu erkennen und zu beseitigen. Weitere Informationen zu den Funktionen des Quality Gate Management finden Sie in Abschnitt 8.1.
Integration mit dem IT-Service-management
Wie bereits erwähnt, ist das Change Request Management stark an die Vorgaben der IT Infrastructure Library (ITIL) angelehnt. Damit geht eine Integration in die anderen IT-Servicemanagement-Bereiche des SAP Solution Manager einher: Wenn Sie eine Störung (Incident) oder ein Problem in Ihrem Service Desk haben, können Sie direkt einen Änderungsantrag als Folgedokument erstellen. Dabei werden wichtige Informationen wie Texte und die zugewiesene Komponente automa-tisch an den Änderungsantrag übertragen, und es wird eine Beziehung zwischen beiden Dokumenten hergestellt, sodass jederzeit verfolgt werden kann, wo der Ursprung des Änderungsantrags lag.
345
Verwaltung der Änderungskontrolle8
Das Change Request Management kann dabei so konfiguriert wer-den, dass nach Abschluss des Änderungsantrags – also sobald die Änderung erfolgreich durchgeführt und bestätigt wurde – auch der zugehörige Incident oder das zugehörige Problem automatisch geschlossen wird.
Integration mit Dokumentation
Alle Änderungen, die Sie mit dem Change Request Management vor-nehmen, basieren immer auf einem SAP-Solution-Manager-Projekt. Die Informationen, die sich in diesen Projekten befinden, können ebenfalls im Change Request Management genutzt und Änderungs-vorgängen zugewiesen werden. Dadurch haben Sie die Möglichkeit, Ihre Änderungsvorgänge und Änderungsanträge zu klassifizieren und zu kategorisieren.
In den Zuordnungsblöcken Lösung und Projekt können Sie Infor-mationen wie Geschäftsprozessszenarien, Geschäftsprozesse oder Geschäftsprozessschritte zuweisen. Das Change Request Manage-ment Reporting unterstützt diese Zuweisung, sodass Sie im Repor-ting auch die Möglichkeit haben, nur Änderungsvorgänge anzuzei-gen, die eine Beziehung zu einem bestimmten Geschäftsprozess besitzen.
Die zugrunde liegenden Dokumente des Projekts oder der Lösung wie Testfallbeschreibungen oder Spezifikationen können im Zuord-nungsblock Dokumente referenziert werden.
Check-in/Check-out-Funktion
Wenn Sie eine Lösung zu einem Änderungsvorgang zuweisen und diese Lösung eine Verbindung zum verwendeten Wartungsprojekt besitzt, können Sie darüber auch die sogenannte Check-in/Check-out-Funktion benutzen. Sobald Sie diese Funktion aktiviert haben, kön-nen der Inhalt und die Struktur der Lösung nicht mehr direkt bear-beitet werden, vielmehr können die Teile der Lösung, die geändert werden müssen, mithilfe des Änderungsvorgangs in das Wartungs-projekt ausgecheckt werden. Dort können die Dokumente und Pro-zesse aktualisiert werden, entsprechend der dazugehörigen Soft-ware- oder Konfigurationsänderung, die zeitgleich über den Änderungsvorgang durchgeführt wird. Danach kann die Struktur wieder eingecheckt werden, sobald die Änderung abgeschlossen wurde.
Das Ergebnis ist nicht nur eine geänderte Konfiguration auf techni-scher Ebene, sondern auch eine geänderte bzw. aktualisierte Doku-
346
Change Request Management 8.2
mentation Ihres Geschäftsprozesses. Dies ist besonders wichtig, wenn Sie andere Funktionen des SAP Solution Manager verwenden möchten, die eine korrekte Lösungsdokumentation voraussetzen (z. B. Business Process Monitoring).
Integration mit Testmanagement
Ein Thema, das immer eng verwandt mit Änderungen und Change Management betrachtet wird, ist das Thema Testmanagement. Im SAP Solution Manager gibt es eine große Anzahl von Funktionen und Anwendungen, um Testvorgänge und Testprozesse in der Kunden-landschaft zu kontrollieren und zu verwalten. Diese Funktionalitäten sind auch mit dem Change Request Management integriert, sodass Sie bei Änderungsanträgen oder Änderungsvorgängen eine Bezie-hung zwischen diesen und Entitäten aus dem Testmanagement her-stellen können (siehe Kapitel 7).
Der Zuordnungsblock Testmanagement erlaubt es, Testpläne oder Testpakete aus dem SAP Solution Manager zu einem Change-Request-Management-Dokument zuzuweisen. Dadurch kann ein Change Manager oder Testkoordinator z. B. bereits im Vorfeld einer Änderung einen Testplan zuweisen, der Testfälle enthält, die zum Testen der geplanten Änderung verwendet werden sollen.
In einem weiteren Schritt können Sie das Change Request Manage-ment durch die Implementierung einer eigenen Kondition auch so konfigurieren, dass die Prozesskontrolle abhängig vom erfolgreichen Ausführen der zugewiesenen Testpakete oder Testpläne ist. Damit ist es möglich, eine Prüfung zu implementieren, die z. B. das Ändern des Status von Zu testen auf Erfolgreich getestet nur dann möglich macht, wenn die zugewiesenen Testfälle positiv getestet wurden. Dies bringt weitere Stabilität in Ihre Software und minimiert das Risiko von Fehlern im Produktivsystem.
Integration mit Maintenance Management
Die Wartung einer SAP-Landschaft ist ebenfalls eng verknüpft mit dem Thema Change Management. Teil des Prozesses Maintenance Management ist die Funktion Systemempfehlungen. Hier werden Ihnen SAP-Hinweise für Ihre Systemlandschaft zur Implementierung vorgeschlagen (z. B. sicherheitsrelevante oder performancerelevante Hinweise, etc.).
Wenn Sie sich für die Implementierung eines solchen SAP-Hinweises entscheiden oder in Ihrem Unternehmen den Prozess des Change Request Management verwenden und eine Implementierung über
347
Verwaltung der Änderungskontrolle8
einen Änderungsantrag anstoßen wollen, können Sie direkt aus der Anwendung Systemempfehlungen einen Änderungsantrag erstellen, der alle nötigen Informationen über den zu implementierenden SAP-Hinweis bereits enthält.
Weitere Informationen zur Funktion Systemempfehlungen finden Sie in Kapitel 12.
Integration mit Job Scheduling
Management
Der Bereich Job Scheduling Management (Jobverwaltung)
beschäftigt sich mit den zahlreichen Hintergrundanwendungen und Stapelverarbeitungsprogrammen, die in einem SAP-System einge-plant sind. Wenn die Systemlandschaft komplexer wird und die Zahl dieser Jobs massiv ansteigt, ist es schwierig, hier den Überblick zu behalten. Mithilfe des Job Scheduling Management können Sie die Einplanung und Ausführung solcher Anwendungen zentral verwal-ten.
Durch eine Integration mit dem Change Request Management ist es möglich, auch das Einplanen einer solchen Hintergrundanwendung über einen Change-Management-Prozess abzubilden. Hierfür wird im Change Request Management ein spezieller Zuordnungsblock zur Verfügung gestellt.
Mehr zum Thema Jobverwaltung erfahren Sie in Kapitel 11.
8.3 Transportverwaltung
In integrierten Systemlandschaften ist es wichtig, alle Änderungen in einem zentralen System zu verwalten. Nur so ist es möglich, Ände-rungen, die mehr als ein Produktivsystem betreffen, synchron durch-zuführen, z. B. gleichzeitige Änderungen im SAP NetWeaver Portal und im SAP-ERP-Backend-System. Darüber hinaus werden im SAP Solution Manager zentrale Transportfunktionen für die gesamte Sys-temlandschaft zur Verfügung gestellt, wie das Synchronisieren von Entwicklungssystemen oder die systemübergreifende Objektsperre.
8.3.1 SAP-Änderungs- und Transportsystem (CTS)
Zentrales Werkzeug
Das SAP-Änderungs- und Transportsystem (Change and Transport Sys-tem, CTS) ist das zentrale Werkzeug zur Verwaltung von Änderungen an Customizing- und Repository-Daten, die im Implementation Guide
348
Index
A
ABAPAusnahmen (Fehler) 534Auswertungen 534
ABAP Coverage Analyzer 707ABAP Database Connectivity (ADBC)
41ABAP Workbench 349Abgleichsfunktion 209Abhängigkeitsaussagen 637Action List 521Adaptive Computing Controller (ACC)
99, 507Ad-hoc-Reporting, CCLM 714Administrationsreporting 189, 522administrative Änderung 315, 323,
329Agenten 485Agile Softwareentwicklung 153Alert 401Alert-Details 83Alert-Detailsicht 453Alert-Eingang 44, 80, 82, 447, 448,
479, 572Alert-Gruppen 452Alerting 48, 445Alert-Management, Auswertungen
532Alerts 79, 448, 572, 594
zurückstellen 451Alert-Tabelle 450allgemeine Änderung 315, 323, 330Altersanalyse 575Altersstruktur der Daten 552Analyse 446
technische 524Analyseprojekt 120Analysestruktur 124Analysesystem 720, 722, 723, 724Änderungsanalyse 94
durchgängige 367Änderungsanforderung 62Änderungsantrag 64, 309, 310, 313,
320, 321, 387Prozess 324Umfangserweiterung 326
Änderungsauswertung 366Änderungsdiagnose 365Änderungsdokument 310Änderungseinfluss-Analyse 71, 233,
237, 242, 284HARTMANN GRUPPE 201
Änderungskontrollezentrale 334
Änderungstypen 326Änderungsumfang 322Anlagenklassen umstellen 672Anpassungen, kundenspezifische 167Anpassungskosten 724Antwortzeiten 534, 535Antwortzeitverteilung 534Antwortzeitzusammensetzung 534Anwendungsanalyse 608Application Incident Management
381Application Lifecycle Management
(ALM) 57HARTMANN GRUPPE 201
Application Management 29, 57Arbeitsmodi 502
langfristig planen 504Monitoring-Einstellungen 509Status 505
Arbeitsvorrat 189Arbeitsvorrat für beschädigte Test-
fälle 264Archiv-Analyse 685Archivierung, Komplexität 550ARIS 38ASAP-Methode 31, 149ASAP-Roadmap 149, 153, 165
Add-ons 153Roadmap-Phasen 152Rollen 155Themenbereiche 155Variante 155
Assistent zur Lösungsdokumentation 64, 96, 118, 165, 169Analyse 122Analyseergebnis 126Analyseprojekt 122Analysestruktur 124
765
Index
Content-Schnittstelle 122HARTMANN GRUPPE 199Prüfregel 123Prüfreihe 123Prüfschritt 123Regeldatenbank 122, 124Work Center 121
Aufgabenplan 317, 358Ausfallzeitauswertungen 510Ausfallzeiten 502Ausnahmen (Fehler) 534außerhalb der Geschäftszeiten 504Auswertung 180, 182Auswertungstypen 529Autoimport 361automatische Testskripte 248automatischer Abgleich mit der SAP-
Korrektur-Workbench 362automatisierte Testfälle 262
Reporting 263Availability Status 463
B
Backlog Monitor 469BAdI 700Basic Settings (Content) 148Batch-Input-Mappe 570Bayer MaterialScience AG 609Benachrichtigungen 445, 573
Ausfallzeiten 508Verwaltung 508, 512
Benchmarking 574Benutzerakzeptanztest 69Benutzertest 233Benutzerverwaltung 159Berechtigungen
Maintenance Optimizer 627Projekt 159Vorlagen- und Roll-out-Projekte 215
Berechtigungskonzept 163, 659beschädigte Testfälle 255, 264Beschleuniger 158, 649Beschleuniger, Run SAP 154Bestandsprozesse integrieren 164Betrieb von Geschäftsprozessen 34,
87, 444, 565Bibliotheksdefinition, CCLM 711BI-Diagnose-Center 531
BI-Monitoring 44, 448Blueprint-Sign-Off 174BMC Appsight for SAP Client Diag-
nostics 486Buchungskreise umbenennen 670Buchungskreise zusammenführen
665Buchungskreiskonsolidierung 668Build & Test-Phase 30, 58Build to Test 68Build-Phase 67Business Blueprint 67, 132, 150, 164,
252Abschluss 173allgemeine Dokumentation 170Grafik 172Reporting 188Sign-Off 174Struktur aufbauen 129Transaktionen 168, 170
Business Configuration Sets (BC Sets) 216, 362
Business Document (BDoc) 570Business Exceptions 91Business Function Prediction 63Business Functions 240
Aktivierung 69, 175Business Process Analysis & Monito-
ring 575Business Process Analytics 566, 568,
573Bayer MaterialScience 610
Business Process Change Analyzer (BPCA) 71, 119, 194, 235, 236, 252, 271, 280HARTMANN GRUPPE 201Testoption 3 284
Business Process Completeness Check 91
Business Process Documentation Con-tent 96
Business Process Monitoring 395, 566
Business Process Procedures (BPPs) 179
Business Process Repository (BPR) 120, 144, 164, 167, 176, 204, 214
Business Process Testing (BPT) 269Business Requirements 252, 255Business System 462
766
Index
Business User 86Business Workflow 570Business-Automation-Enabler-Schnitt-
stelle 588Business-Blueprint-Definition 212Business-Blueprint-Dokument 172Business-Rolle 413BW-Reporting
CCLM 716Testen 265
Bytecode-Instrumentierungstechnolo-gie (BCI) 486
C
CA Wily Introscope 43, 94, 485, 488Capability Maturity Model Integration
(CMMI) 227Carve-Out 664CCLM 703, 707CCMS-Monitoring 509CDC 597
Vergleichsinstanz 597Vergleichslauf 597Vergleichsobjekt 597
CDMC-Kollektor 706Change Advisory Board 64, 318
itelligence AG 440Change Analyzer 280Change and Transport System (CTS)
348Change Control Management 295Change Diagnosis 365Change Impact Analysis 651Change Management 384, 387Change Management Dashboard 345Change Manager 312, 318Change Request Management 62,
180, 295, 306, 308, 310Administrationsmeldung 329, 330administrative Änderung 315, 323Aktion 317allgemeine Änderung 315, 323Änderungsantrag 313, 314, 321Änderungsverwaltung 332Architektur 316Aufgabenplan 317Change Advisory Board (Rolle) 318Change Document 312
Change Manager (Rolle) 312, 316, 318, 319, 323
dringende Änderung 315, 328dringende Korrektur 312, 319, 321,
329Entwickler (Rolle) 312Fehlerkorrektur 315, 323Ferrero 374Genehmigungsvorgang 323HARTMANN GRUPPE 200Integrationen 344Integrationstest 318, 320Monitoring 340normale Änderung 315, 323, 329Projektmanagement 314, 316Projektzyklus 312, 316, 317, 318,
319, 338Reporting 342Tester (Rolle) 312Transportsteuerung 314, 315, 328,
329, 335Transportverwaltung 333Verwaltung von Änderungsanträgen
314Wartungszyklus 316, 319
Change-Analyse 43, 295, 487, 494Change-Reporting-Werkzeug 488Channel Monitor 465Channel Short Log 465Check Points 275Check-in/Check-out-Funktion 346CIM-Modell 109
sanofi-aventis 141Clearing-Analyse 651, 718
Phasen 720Clearing-Analyse-Projekt 719Clearing-Prozess 718, 720ClearQuest 38Clonefinder 701, 727, 728Clown 727Code Freeze 339, 499Coding Scan 685Colgate-Palmolive 287Common Information Model (CIM)
105Component Monitor 464Configuration Management 384Configuration Status 463Configuration Validation 295, 369,
632
767
Index
Continuous Quality Check BPPO (SAP CQC BPPO) 605
Country Legal Changes Packages für SAP ERP HCM 626
cProjects 312CPU-Auslastung 534, 535Cross Database Comparison 597Cross-Application-Objekte 547Cross-System Comparison 732CTS Deployment Log 40CTS Script Caller 40CTS+ 39, 40, 65, 332, 349CTS+ Deploy Web Service 40CTS, erweitert � CTS+CTS-Analyse 718
Phasen 724CTS-Analyse-Projekt 724CTS-Projekt 316, 337, 351Custom Code Analysis 726, 733Custom Code Lifecycle Management
702Procter & Gamble 734Prozessübersicht 704Transparenz 701
Custom Code Management 35, 697Prozess 700
Custom Development Management Cockpit 650
Custom Development Management Cockpit (CDMC) 702, 716, 717CA (Clearing Analysis) 718CTS-Analyse 724Phasen 718UCIA (Upgrade/Change Impact Analy-
sis) 718Upgrade/Change Impact Analysis
721, 722Customer Center of Expertise (CCoE)
210, 388Customer Task Area 521Customizing-Änderungen 237Cutover 74
D
Dashboard Apps 46Dashboard Framework 46dashboard-basierte Auswertungen
541
Dashboards 84, 541, 568Data Consistency Management 591Data Supplier 98, 105Data Volume Management 543Dateisystem 534, 535Dateitransfer 40Datenanalyse 557Datenbankanalyse 487, 489Datenbank-Auslastung 534Datenbank-Performance 534, 535Datenbanksperren 606datenbankübergreifender Vergleich �
CDCDatenbank-Verfügbarkeit 534, 535Datenerhebung, Landschaft 104Datenflussnutzung 97Datenkonsistenz 662Datenkonsistenzmanagement 565Datenkonsistenzverwaltung 591Datenverteilung 544Datenvolumenmanagement 543
Reporting 561Datenzentralisierung 657DCToolbox 595Debugging-Analyse 604Decentral Adapter Engine 462Defect Management 235Deliverables 152Deploy 31Deploy-Controller 350Deployment Management 387Deploy-Phase 30, 58, 74Design-Phase 30, 58, 66Detailvergleich 221, 222Diagnosedatenbank 485Diagnostics Agent 109Diagnostics Framework 109digitale Signatur 135, 257DMAIC-Zyklus, Bayer Material-
Science 611Dokumentation 95, 171, 346
der Systemlandschaft 119initiale 95Konsistenzprüfung 121Lösung 131Re- 96System 133technische 97Vorlage 132
Dokumentationsarten 162, 163, 164
768
Index
dokumentenbasierte Service Level Reports 539
Dokumentenverwaltung, Ferrero 374Download-Basket 619, 621Drei-System-Landschaft 615dringende Änderung 315, 328dringende Korrektur 308, 312duale Systemlandschaft 360DVM-KPI-Detailsicht 561dynamische Interface Analysis 729
E
E2E-Exception-Analyse 73E2E-Trace-Analyse 73E2E-Workload-Analyse 73EA-Governance- und Strategie-Frame-
works 153eCATT 70, 235, 259, 261eCATT-Testskript 260ECC-Business-Application-Analyse
685Editor technisches System 112EEM-Robots 475Eigenentwicklungen 179, 606, 697
Kritikalität und Einfluss auf Kernge-schäftsprozesse 700
Qualität 700Quantität 699technische Umsetzung 700Testaufwand 698
Einführungsprojekt 157, 207Einzelsystem-Update 622E-Learning-Management 182E-Mail-Benachrichtigung, Testen 257Endanwenderschulung 653Endanwender-Test 231Endbenutzerrollen 195End-to-End-Analyse 487End-to-End-Change-Analyse 494End-to-End-Exception-Analyse 489End-to-End-Monitoring und Alerting
37, 48End-to-End-Root-Cause-Analysis 481End-to-End-Trace-Analyse 496, 603,
607End-to-End-Workload-Analyse 492
End-User-Experience-Monitoring 44, 82, 92, 445, 447, 474Auswertungen 532
Enhancement Package 232, 234, 239, 615, 623, 633Installation 624Testumfang 241Wartung 624
Enqueues 606Entwicklung mit Freigabe 318Entwicklung ohne Freigabe 318Entwicklungsstrukturen aufbauen
180Error Monitor 467erweitertes Änderungs- und Transport-
system 39, 40, 332erweitertes Transportmanagement 65Erweiterungen 232Erweiterungsspot 700Eskalation 84, 411Events 455Excel-Upload-Schnittstelle 129Exception Management Cockpit 91Exception Status 463Exception-Analyse 43, 487, 489Expert Analysis Transactions 80Extended Computer Aided Test Tool
260External Batch Processing 579Extraktor-Framework 366
F
Feedback-Funktion 187fehlerhafte Änderungen 364Fehlerkorrektur 59, 315, 323, 331Fehlermeldungen, Testen 259Ferrero Deutschland MSC GmbH & Co.
KG 373, 428File-System-Browser 488Filter, CCLM 715Financial Management 384First Level Support 406, 419Flat File 570Fortschritts-Reporting 267
Testen 263Fourth Level Support 407führendes System 710
769
Index
Full-Sync-Phase 110funktionale Spezifikation 163funktionales Testen 231
Option 1 251
G
Garbage Collection 535geänderte geplante Ausfallzeiten 503Genehmigungsverfahren 312
Ferrero 377Genehmigungsvorgang 323, 325Genehmigungsworkflow 180geplante Ausfallzeiten 503Geschäftprozessüberwachung 569Geschäftsabläufe 144Geschäftsjahr umstellen 671Geschäftspartner 405Geschäftsprozess 145
Dokumentation 131Lebenszyklus 166optimieren 657Performance 599Statusmonitor 85Test 231
Geschäftsprozess-Analyse 568, 573Bayer MaterialScience 610
Geschäftsprozessbeschreibung 163Geschäftsprozessgrafik 600Geschäftsprozess-Monitoring 87, 119Geschäftsprozessschritt
Test 231Geschäftsprozesssicht 134Geschäftsprozessstabilisierung 567Geschäftsprozessstruktur 120Geschäftsprozessüberwachung 166,
565, 566Reporting 573und Datenkonsistenzmanagement
594Geschäftsprozessverbesserung 568Geschäftsszenario 145gespeicherte Suche 341Global ASAP Rollout Roadmap 210Global ASAP Template Roadmap 209,
214Global Blueprint and Global Realiza-
tion 210Global Maintenance and Support 210
Global Program Setup, 210globale Attribute 212, 214globale Vorlagen 657globaler Empfänger-Pool 512globales Attribut 206Global-Roll-out-Funktionalität 212Governance-Modell 543Greenfield-Ansatz 659
H
halbautomatischer Abgleich mit BC Sets 362
HARTMANN GRUPPE 197Hauptgeschäftszeit 503Hauptspeicher 534, 535Historie 189
Reporting 196Homogenität 505Host-Analyse 487, 488Host-Verfügbarkeit 534, 535Hot-Backup-SLD-System 118HP QuickTest Professional 235, 260,
269HR Support Packages 626HTTP-/RFC-ST12-Trace 603HTTP-Sessions 535Hub 102, 625
I
iBase (Installed Base) 407IBM Rational 38, 236, 282IBM Rational Functional Tester 260Identifizierung von Kerngeschäftspro-
zessen 119IMG-Auswertung 193IMG-Projekt 176, 316, 337Implementierung der Lösung 60Implementierungsprojekt 309
generieren 213Importsperre 299Incident 64, 76, 84, 381, 383
Folgeaktivitäten 404Incident Management 35, 55, 321,
381, 582Auswertungen 532Ferrero 428
770
Index
für IT-Dienstleister 416für Softwarepartner 423itelligence AG 440Kategorisierung 412mit 3rd-Party-Help-Desk 414Prozess 398Stammdaten 405
Incremental-Sync-Phase 110Infrastructure Management 57initiale Dokumentation 95Installed Base Management 384Instanzverfügbarkeit 534, 535Integration Server 462Integration Validation 73Integration von Partnerprodukten 38Integrationstest 69, 231, 318Integrationsvalidierung 500Interactive Reporting 480interaktive Auswertungen 448, 529
Typen 536interaktives Reporting 446Issue List 521Issue, Nachvollziehbarkeit 181IT Analytics 384IT Infrastructure Library � ITILIT Service Desk 384itelligence AG 436ITIL 29, 57, 314, 345, 375, 381, 384
im SAP Solution Manager 383IT-Kalender 86, 511IT-Objekt 408IT-Performance-Reporting 85IT-Servicemanagement 62, 345, 382
Implementierung 392und ALM 386
J
Java Support Package Manager (JSPM) 617
Java, Auswertungen 535Job anlegen 586Job Scheduling Management 38, 87,
348, 395, 576Job Scheduling Management Health
Check 589Jobantrag 580
zuordnen 584Jobdokument 583
Jobdokumentation 583Jobeinplanung 89Job-Monitoring 586Jobüberwachung 579Jobverwaltung 565, 576
Incident Management 582
K
Kategorisierung, mehrstufig 411Kennzahlen 568Kerngeschäftsprozess 82, 131Key Performance Indicator 46Klon 726Knowledge Article 408Knowledge Management 384, 408Kollektoren, CCLM 711Kommunikationskanäle 465Komponentensicht 146Konfiguration 132
Baseline-Konfiguration 177Detailkonfiguration 177Dokumentation 178Phasen 177Reporting 191szenariospezifisch 177Voraussetzungen 175
Konfiguration der Lösung 174Konfigurationsbeschreibung 163Konfigurationsdatei 624, 651Konfigurationsleitfaden 179Konfigurations-Repository 366Konfigurationsspeicher 372Konfigurationsstruktur 212Konfigurationsvalidierung 369, 632Konsistenzprüfung 175
Dokumentation 121Konsistenzzyklus 592Konsolidierungssystem 720, 724Kontenpläne umstellen 670Kontrollsystem 720, 722, 724Konzern-Roll-out 204
Procter & Gamble 225Kopien, Transport 307, 352Kostenrechnungskreise zusammenfüh-
ren 668Kostenrechnungskreise, umbenen-
nen 670Kostentreiber, Upgrade 633
771
Index
kritische Objekte 336kritisches System 131kundeneigene Entwicklungen 616kundeneigener Code 238kundenspezifische Erweiterungen
699
L
Landscape Fetch 108Landscape Management Database
(LMDB) 39, 108, 109sanofi-aventis 141
Landscape Tranformation Manage-ment 35
Landscape Verification 1.0 for SAP Solution Manager 138
Landscape Verification Tool 108, 109, 114, 115, 616sanofi-aventis 139
Landschaftsdaten 99Handhabung 104Topologie 117
Landschaftsmanagement 39Landschaftsmuster 99, 102
Hub 102Sidecar 102
Landschaftswachstum 551Lasterzeugung, automatisch 476Lasttest 231, 233Lastverteilung 606Laufzeitschätzung 685Learning Map 195
erstellen 185Feedback 187Kapitelstruktur 186
Learning Map Builder 653Lebenszyklus 31, 321Lerninhalte organisieren 185Lernmaterial 195Lernmaterialien 179
erstellen 183Reporting 194
Lights-out-Test 263Lizenz 52Lizenzmanagement 628Lizenzschlüssel 629Lizenzverwaltung 628LMDB 108
Logical Information Object (LOIO) 178
logische Komponente 316Lösung 208
SAP Solution Manager 32Lösungsdesign 208Lösungsdokumentation 33, 68, 95
HARTMANN GRUPPE 198Kernelemente 96
Lösungsdokumentation, Assistent 118
Lösungsimplementierung 33Lösungslandschaft 133, 304LTS 679LUW-Konzept 592
M
Maintenance Management 347Maintenance Optimizer 103, 115,
175, 615, 616, 640, 651für SAP ERP 623Konzept 618und SAP Global Support Backbone
618Vorteile 617
Major Release 59, 63, 207, 296, 309Management Dashboards 45Management-Auswertungen 539Mandantentransfer 663, 675manueller Abgleich 362manueller Testzyklus 250manuelles Testen 255Mappengruppe 215Master Component Repository 105Mehrfachänderung, Ferrero 377mehrstufige Kategorisierung 333, 411Meilensteine 299
projektspezifisch 161Meldung 180
an SAP weiterleiten 421Eingangskanal 399Nachvollziehbarkeit 181verknüpfen 420zum Projekt zuordnen 181
Meldungsbearbeitung 401itelligence AG 438
Meldungsreport 267Mergers and Acquisitions 657
772
Index
Message Flow Monitor 469Message Monitor 466Metamodell für Geschäftsabläufe 145Metriken 455Metrik-Monitoring 456, 531Minor Release 59, 75, 208, 296, 309Mission Critical Support 80Modification Browser 730Modification Justification Check 733Modification Overview 730Modifikation 717Modifikationsabgleich 731Monitor
anwendungsspezifisch 569technisch 570
Monitoring 444Aufgaben 572proaktiv 82
Monitoring- und Alerting-Infrastruk-tur 44, 48, 447
Monitoring-Objekt, BPM 569
N
N+1-Landschaft 360Nachrichtensuche, zentrale 471Nachvollziehbarkeit 180, 196Near-Zero-Downtime-Methode 654normale Änderung 315, 318, 323,
326, 354normale Geschäftszeit 504Notfall-Änderungen 364Notkorrektur 339Nutzungshäufigkeit 553Nutzungsrechte 52
O
Object Management 384Objektattribute 162Objekte, CCLM 712Objektsperre 308, 335, 355
Optionen 355Offene Aufgabenliste 516Offenheit 38, 39Office of Government Commerce
(OGC) 383
Old Space Usage 535Operate-Phase 30, 58Operations Control Center 79, 80, 92Optimierung 446Optimize-Phase 30, 58Organisationseinheit 405Organisationseinheiten 169
hinterlegen 161Organisationsmodell 406Organisationsstrukturen 659OS-Analyse 488OS-Command-Konsole 489Overview-Monitor 462
P
Paging-Rate 534, 535Parallel Processing Framework 87parallele Verarbeitung 606Partner-Hinweis 425Partnerunternehmen 160Patches 615Performance 534, 535
von Geschäftsprozessen 565, 599Performance Status 463Performancetest 69, 231, 233Phantom-Alerts 509Phasenlandschaft 360Physical Information Objects (PHIO)
178PI Integration Builder 351PI-Monitoring 44, 448, 458
Alerts 473Metriken 463Support-Tickets 473
Pink Elephant 384PMBOK 149Portal Content Administrator 351Portalrolle 148Portfolio- und Projektmanagement 60Positionsbestimmung 544Positive Call Closure 410Post Processing Office (PPO) 89PPOMA_CRM 406Priorisieren
nach Altersstruktur der Daten 552nach Nutzungshäufigkeit 553nach Speicherverbrauch 550von Objekten 549
773
Index
Proaktives Monitoring 82Problem 382, 383
Folgeaktivitäten 404itelligence AG 440
Problem Management 55, 381, 384, 521Prozess 398
Process Flow Analyzer 275Procter & Gamble 223, 734Products and Production Management
System (PPMS) 105Produktionsvorbereitung 151Produktivstart und Support 151, 152Produktivsystem 719, 724Produktsystem 99, 101
Landscape Verification Tool 116Profit-Center reorganisieren 667Project Management Institute Project
Management Body Of Knowledge (PMI PMBOK) 149
Projekt- und Lösungsdesign 208Projekt, SAP Solution Manager 31Projektbesetzung 159Projektdokumentation 215Projektkonfiguration, Dokumenta-
tion 184Projektmitarbeiter verwalten 158Projekt-Monitoring, Procter & Gamble
228Projektphasenverwaltung 336Projektplanung, Upgrade Roadmap
649Projektstandards 212
Dokumentationsarten 162festlegen 162Statuswerte 162Stichwörter 162
Projektstruktur bearbeiten 136Projekttemplate 164Projektumfang 157Projektverwaltung 31, 66, 156, 171,
174Projektmitarbeiter 158
Projektvorbereitung 150Projektzyklus 312, 317, 318, 319, 337Prozess, SAP Solution Manager 33Prozessbibliothek 204Prozessdefinition 204Prozess-Design 659
Prozessekundenspezifische 168Wiederverwendung 168
Prozessfluss 172Prozessharmonisierung 204Prozessketten 580Prozesskomponentenliste 637, 640Prozessschritt 132, 145Prozessstruktur 165
Geschäftsprozess 165Geschäftsszenario 165Organisationseinheiten 165Stammdaten 165, 169Strukturelement 165
Prozessüberblicksmonitor 87Prüfregel 123Prüfreihe 123Prüfschritt 123Pull-Mechanismus 42Push-Mechanismus 42
Q
Q-Gate � Quality GateQ-Gate-Kalender 301Qualitätsausschuss 300Qualitätsmanager 300Quality Gate 65, 161, 298, 299
Dokumentation 301Quality Gate Management 61, 65,
295, 296, 344, 359zentrale Transportverwaltung 303
Quality Gates 345Quality-Gate-Kalender 66, 298, 301queued Remote Function Call (qRFC)
570
R
RBPD-Content 127Realisierung 151Realtime Monitoring UI 476rechtliche Anpassungen 615Re-Dokumentation 96Referenz-Prozessstruktur 212Referenzsystem 722, 723Regeldatenbank 124
774
Index
Regressionstest 69Release Management 296, 312Release-Prozess 64Releases, Arten von 296, 309Remote-Support 422, 427Reorganisationsprojekt 657Reporting 446
Administration 189Business Blueprint 188CCLM 714Change Request Management 342Einführungsprojekt 188Historie 196Konfiguration 191Lernmaterialien 194Roadmap 188Systemlandschaft 196Test 196
Reportvariante 190ReqPro 38, 236Request for Change 62, 312, 321Requirements-Modul 235, 236, 273Requirements-Phase 30, 58, 63Requisite Pro 38, 236Retrofit 62, 295, 359, 360
HARTMANN GRUPPE 200Kategorien 361
Reverse Business Process Documenta-tion (RBPD) 127
RFC-Destinationen 534RFC-Provider 535Roadmap-Auswahl 158Roadmaps 66Robots 475Roll-in 223Roll-out 204Roll-out-Projekt 205Root Cause Analysis 37, 42, 71, 80,
446, 481Änderungsanalyse 94Architektur 485CA Wily Introscope 94Elemente 482komponentenspezifisch 483komponentenübergreifend 483Qualitätssicherung 499Trace-Analyse 93Vorgehen 483Werkzeuge 487Workload-Analyse 93
Run SAP like a Factory 79, 81Run-SAP-Roadmap 153
S
SA_PROJECT_UPGRADE 217, 219SA38 589sanofi-aventis Deutschland GmbH
137SAP Add-On Installation Tool (SAINT)
617SAP Best Practices, Transport 307SAP Business Process Performance
Optimization (SAP BPPO) 605SAP Business Suite 149SAP BusinessObjects 351SAP BusinessObjects Dashboards 46SAP Central Process Scheduling by
Redwood 38, 89, 577, 580, 585SAP Code Inspector 701, 703SAP cProjects 60, 65SAP Data Volume Management – Best
Practice Session 556SAP Download Manager 621SAP EarlyWatch Alert 75, 446, 524,
602SAP EarlyWatch Alert Service 711SAP EarlyWatch Check 75SAP Enhancement Package Installer
617, 625SAP Enhancement Package � Enhan-
cement PackageSAP Enterprise Modeling Applications
by IDS Scheer 38SAP Enterprise Support 36, 52, 55SAP Exception Management Cockpit
80SAP Extended Diagnostic 43SAP Global Support Backbone 618,
628SAP GoingLive Functional Upgrade
Check 653SAP HP Quality Center 249SAP Landscape Transformation 655
Anlagenklassen umstellen 672Buchungskreise umbenennen 670Buchungskreise zusammenführen
665
775
Index
Carve-Out 664ergänzende Services 688Geschäftsjahr umstellen 671Installation 677Kontenpläne umstellen 670Kostenrechnungskreise umbenennen
670Kostenrechnungskreise zusammenfüh-
ren 668Mandantentransfer 663Nutzung 677Profit-Center reorganisieren 667Projekt anlegen 682Projekt durchführen 684Roadmaps 658SKW Stahl-Metallurgie 692vs. Greenfield-Ansatz 660
SAP LoadRunner by HP 38SAP NetWeaver Business Warehouse
(BW) 41, 46CCLM 705
SAP NetWeaver BW 41, 46SAP NetWeaver Master Data Manage-
ment 673SAP NetWeaver Process Integration
Metriken 463Monitoring 458
SAP Passport 478SAP Product Support for Large Enter-
prises (SAP PSLE) 36, 385SAP Productivity Pak by Ancile 38,
184SAP Quality Center by HP 38, 235,
268Fehlermeldungen 278Reporting 279
SAP Quality Manager 236SAP Service Delivery 395SAP Solution Manager für Nicht-SAP-
Software 39SAP Standard Support 54SAP Support Package 234
Testumfang 241SAP TAO 249, 269, 271, 275
Wartung von Testfällen 280SAP Task Structure 520SAP TDMS 269SAP Test Acceleration and Optimiza-
tion 235, 249, 269, 271, 275Wartung von Testfällen 280
SAP Test Data Migration Server (TDMS) 252, 269
SAP Transport Execution Analysis 363
SAP Upgrade Assessment 653SAP Web Client 49
Ferrero 376SAP-Änderungs- und Transportsystem
(CTS) 348SAPConnect 508SAP-Einführungsleitfaden (IMG) 316SAP-Hinweise 616
Systemempfehlungen 630SAP-Importwerkzeug für Add-ons
(SAINT) 624SAP-IT-Servicemanagement (SAP
ITSM) 384SAP-Partner 483SAP-Quality-Center-Testbericht 278SAP-SLO-Evaluation-Service 691SAP-SLO-Execution-Support-Service
691SAP-Solution-Manager-Adapter für
SAP Quality Center 270SAP-Solution-Manager-Systemland-
schaft 96SAP-TAO-Testbericht 277Schnittstellen
hinterlegen 169neue 659
Schnittstellentest 231Schnittstellenüberwachung 565, 566SCI 703Scope to Build 67SCOV 707SDCCN 706SE09 327SE95 730Second Level Support 407Secure Area 410Segregation of Duties 300sensitive Objekte 336Service Data Control Center (SDCCN)
706Service Delivery 57Service Desk 37, 51, 81, 181, 235,
391Ferrero 432für Partner 419HARTMANN GRUPPE 200
776
Index
itelligence AG 438Meldung 311Support-Meldung 327
Service Level Management 384Service Level Reports 539Service Request Management 384Service Support 57Servicemeldungen 180
in Learning Maap einbinden 186Service-Request 62, 64Shared Resources 607SID 100Sidecar 102, 625Single Source of Truth 62, 119, 393Single Transaction Analysis 604, 607Sizing 606Skriptverfügbarkeit 538SKW Stahl-Metallurgie Holding AG
692SLA-Eskalation 411SLD-Registrierung
automatisch 99SLG1 510SM36 578, 586, 589SM37 578, 589SMCR 582SMIN 582SMSY 108, 114, 115, 119, 134, 298,
408sanofi-aventis 138
SNP AG 197Software Lifecycle Manager (SLM)
617, 621Softwarekatalog 105Softwarekomponenten 100Softwarelebenszyklus 58SOLAR_EVAL 180, 188, 228SOLAR_LEARNING_MAP 183, 185,
195SOLAR_PROJECT_ADMIN 130, 156,
171, 174, 210, 298SOLAR01 96, 132, 136, 147, 164,
165, 212SOLAR02 96, 132, 147, 176, 183,
185, 212, 273, 717Soll-Konzept 164, 170
Anforderungen 170SOLMAN_SETUP 110, 396SOLMAN_WORKCENTER 645Solution Directory 706
Solution Manager Diagnostics 607Solution-Manager-Projekt 31, 32SOST 508SPAU 731Speicherverbrauch 535, 550SQL-Anweisungen, teure 606SQL-Trace 604ST/A-PI 01N 607ST03N 706ST12 604, 607ST14 608ST-A/PI 604STAD 603Stadt-Modell 698Stammdaten 169
neue 659Stammdaten harmonisieren 657Standard Batch Script 40Standard Shell Script 40statischer Verwendungsnachweis 729Statistiksystem 719, 722Statusanalyse 266Status-Infosystem 266Statusmonitor für Business User 86Statusmonitor für Geschäftsprozesse
85Statusmonitor für technische Kompo-
nenten 86Statusreport 267Status-Reporting, Testen 263Statuswerte 162Stichwörter 162ST-ICO 148Strukturelemente 169Strukturelemente löschen 215SU01 159Sub-Deliverables 152Support Package 615, 616, 618
Auswahl 619, 620, 621Download 619, 621einspielen 619, 622Verteilung 622
Support Package Manager (SPAM) 617
Support Package Stack 620Support-Meldung 408Switch Framework 175Synchronisation von Entwicklungssys-
temen 360
777
Index
Systemkritisches 131technisches 99, 101, 113
System Landscape Directory (SLD) 98, 133sanofi-aventis 138
Systemadministration, zentrale 513Systemadministrationssitzung, zen-
trale 515Systemanalyse 487, 488Systemauswertungen 532Systemdatencontainer 262Systemdokumentation 133Systeme vergleichen 343Systemempfehlungen 630
einrichten 632Integration 632
Systemhierarchie 454Systemkennung (SID) 100Systemkonsolidierung 657, 675Systemlandschaft 189
Analyse 661duale 360festlegen 160pflegen 160Reporting 196
Systemlandschaft (SMSY) 115, 119Systemlandschaft Solution Manager
133Systemlandschaftsgrafik 303Systemlandschaftspflege 706Systemlandschaftssicht 135Systemlastmonitor 706System-Monitoring 44, 447, 453
Hierarchie 455Systemsicht 134systemübergreifende Objektsperre
336Systemverfügbarkeit 534, 535Szenariokomponentenliste 637, 640Szenariotest 69szenarioübergreifend 176
T
Tabellenanalyse 237Task Log Book 518Task Log Book History 522
Task Management 515Task Session Report 524TBOM-Arbeitsvorrat 254TBOM-Aufgaben 249Technical Alerting 395Technical System Editor 39Technical Usage 624technische Administration 82, 86,
501technische Analyse 524technische Komponenten, Statusmoni-
tor 86technische Landschaftsdokumenta-
tion 97technische Spezifikation 163technische Stückliste (TBOM) 246technischer Aufgabenplan 358technischer Betrieb 34, 92, 443
Analyse 446Anwendung 444Benachrichtigung 445Monitoring 444Optimierung 446Reporting 446
technisches Monitoring 43, 447technisches System 99, 101
anlegen 113technisches Szenario 456Test Automation Framework 235,
260Colgate-Palmolive 289Funktionsumfang 261
Test Data Migration Server (TDMS) 236
Test to Deploy 73Test Workbench 235, 253
Auswertungen 532Ferrero 429Reporting 265
Testaufwandsreport 267Testausführung 233
manuelle 257Testauswertung 255Testautomatisierung 61, 71, 259, 260Testautomatisierungs-Framework
249Testbericht 277, 279Testdatencontainer 262Testdokumentation 259Testdurchführung 232
778
Index
TestenIBM Rational 285manuelles 255
Tester-Arbeitsvorrat 255, 258Testfall 34, 216, 394Testfallabdeckung 265Testfallbeschreibung 163, 258Testfälle 258
beschädigte 255Katalogisierung 256manuelle 256
Testkonfiguration erstellen 261Testmanagement 34, 61, 75, 182,
196, 231, 347, 394, 652HARTMANN GRUPPE 201Prozess 70, 232
Testoption 1 235, 249, 251Testoption 2 235, 249, 268Testoption 3 236, 282Testoptionen 234Testpaket 70, 256, 258Test-Phase 69Testplan 70, 233, 256, 394
erstellen 273inkonsistenter 266
Testplanung 232, 233Testoption 3 284
Testplanverwaltung 254Test-Reporting 265Testsequenz 257Testskripte 61, 262
automatische 248Testsystem, Aufbau 233Testumfang 61, 232, 233
Optimierung 72, 242Testvorbereitung 254Testwerkzeug, Optionen 234Testzyklus 233
manueller 250Third Level Support 407Thread-Dump-Analyse 488Threads 535Top-20-Analyse 732Traceability 135Trace-Analyse 43, 93, 94, 487, 496Training Management 38Transformation von Daten 669Transformationsansatz 661Transformationskonzept 663Transformationslösung 655
Transformationsprojekt 655, 656Phasen 660realisieren 662
Transformationsszenarien 664Transparenz 313, 327, 340, 617Transport 349Transport Execution Analysis 296Transport Management 297Transport Management System (TMS)
349Transport Organizer 349Transport von Kopien 307, 352Transportanschluss 313Transportauftrag 306Transportauswertung 372Transport-Backlog 364Transporthäufigkeit 363Transportkonfiguration 304Transportmanagement, zentrales 358Transportrisiken 305, 360Transportsteuerung 329, 335, 619Transportverwaltung 348
zentrale 304Transportweg 304Trendanalyse 575
U
Überholer 308, 335Überwachung von Geschäftsprozes-
sen 41Umstellung
Anlagenklassen 672Kontenfindung 672
Umstellung des Geschäftsjahres 671ungenutzte Daten 555Unit-Test 68Upgrade 35, 232, 625, 717Upgrade Dependency Analyzer (UDA)
633, 635Abhängigkeitsaussagen 637Beispiele 641
Upgrade Roadmap 633, 649Personalisierung 650
Upgrade-/Änderungseinfluss-Analyse 718Phasen 722
Upgrade/Change-Impact-Analysis-Pro-jekt 721
779
Index
Upgrade-Projekt 157, 208, 633Ursachenanalyse 42, 446Usage Procedure Logging 124, 707,
711User Exit Framework 41User-Defined Search (UDS) 471User-Exit 700
V
Verantwortliche definieren 172Verantwortlichkeit 173Verbindungs-Monitoring 44, 445,
448, 456Verbindungstest 457Verfügbarkeit 534, 535Vergleichsfunktion 209Vergleichswerkzeug 206, 217verwaltetes System 501Verwaltung der Änderungskontrolle
34, 295Verwaltung von Dokumenten 135Verwaltung von kundeneigenen Ent-
wicklungenProcter & Gamble 228
Verwendungsnachweis 729Vier-Augen-Prinzip 328View-Trend-Funktion 471Vorgänger/Nachfolger-Beziehung 208Vorlage 203
anpassen 206, 217ausrollen 205definieren 205erstellen 130freigeben 213implementieren 206Lebenszyklus 217Roll-in 223Sichtbarkeit 211, 213transportieren 206, 217
Vorlage für Benutzerschulung 163Vorlagen
anlegen 210mehrstufige 216
Vorlagenänderungen 204übernehmen 221
Vorlagenmanagement 34, 158, 203, 441im ALM-Kontext 207
Vorlagenprojekt 157, 205, 207, 210, 217Vorlagendefinition 211
Vorlagensammler 213Vorlagenstände, verschiedene 216Vorlagenverwaltung 217
W
Wartung 75Arbeitsmodus 503Planung 619, 620
Wartungsaktivität 618Wartungsmanagement 35Wartungsprojekt 157, 208, 309Wartungsprozess 617Wartungsvorgang 618, 620
abschließen 619, 623Wartungszertifikat 616, 628
automatische Verteilung 628Wartungszyklus 317, 319Webformular, Jobantrag 580Webservice 41, 42Webservice-Consumer 534Webservice-Provider 535Wissensartikel 408Wissenstransfer 182Work Breakdown Structure (WBS) 66Work Center 49
Assistent zur Lösungsdokumentation 121
Betrieb von Geschäftsprozessen 89, 571, 593
Change Management 297, 303, 359, 583, 620, 631
Data Volume Management 544Einführung/Upgrade 132, 164, 175,
210, 636, 645, 651Implementierung/Upgrade 718Incident Management 413, 435, 583Jobverwaltung 578Root Cause Analysis 447, 486SAP-Engagement und Serviceliefe-
rung 364, 607Self-Service 389Technische Administration 447, 451,
454, 501, 503, 513Technisches Monitoring 447, 448,
459, 461, 475
780
Index
Testmanagement 253Ursachenanalyse 366Verwaltung der Systemlandschaft
134Verwaltung des SAP Solution Mana-
ger 525, 540Work Mode Management 502, 513
Reporting 510Workload-Analyse 43, 93, 487, 492Worksoft Certify 260
X
X Search 389XBP-Schnittstelle 579
Z
Zeitprofil 492Zeitzonen 511zentrale Änderungskontrolle 334Zentrale Nachrichtensuche 471Zentrale Systemadministration 513Zentrale Systemadministrationssitzung
515, 517zentrale Transportverwaltung 304zentraler Aufgabenplan 358zentrales Transportmanagement 358Zuordnungsvergleich 220
781