Sappress Sap Solution Manager

Marc O. Schfer, Matthias Melich

SAP Solution Manager

Bonn

Boston

Auf einen Blick1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 A B Konzept des SAP Solution Manager 7.1 ................ Application Lifecycle Management (ALM) ............. Effektiver und effizienter Betrieb ........................... Lsungsdokumentation im SAP Solution Manager ............................................ 29 57 79 95

Implementierung von Lsungen ............................. 143 Vorlagenmanagement ............................................. 203 Testmanagement .................................................... 231 Verwaltung der nderungskontrolle ...................... 295 Application Incident Management ........................ 381 Technischer Betrieb ................................................ 443 Betrieb von Geschftsprozessen ............................ 565 Wartung einer SAP-Lsungslandschaft .......................................... 615 Untersttzung von Upgrade-Projekten .................. 633 SAP Landscape Transformation .............................. 655 Custom Code Management: effiziente Verwaltung kundeneigener Entwicklungen ........... 697 Die Autoren ............................................................. 739 Autoren der Kundenerfahrungsberichte ................. 759

InhaltGeleitwort des Chief Operating Officer der SAP AG .................. Geleitwort des DSAG-Vorstands fr Operations/Service & Support .................................................. ber dieses Buch ..................................................................... 19 21 23

1

Konzept des SAP Solution Manager 7.1 ................. 291.1 1.2 1.3 1.4 Effektive Implementierung von nderungen Projekte im SAP Solution Manager ......................... Effizienter Betrieb Lsungen im SAP Solution Manager ............................................ Prozesse im SAP Solution Manager ......................... Vom SAP-zentrierten zum lsungsweiten Einsatz .... 1.4.1 Einfache Nutzung fr die Gesamtkundenlsung ................................ 1.4.2 Offenheit: Integration von Partnerprodukten 1.4.3 Offenheit: SAP Solution Manager fr Nicht-SAP-Software ................................... Hhere Benutzerfreundlichkeit ............................... 1.5.1 Den berblick behalten mit Management Dashboards .......................... 1.5.2 End-to-End-Monitoring und Alerting ......... 1.5.3 CRM-Benutzeroberflche SAP Web Client und Work Center ............. Erweiterung der Nutzungsrechte bringt Kostenvorteile ..............................................

31 32 33 36 36 38 39 45 45 48 49 52

1.5

1.6

2

Application Lifecycle Management (ALM) .............. 572.1 2.2 Phasen und Themenblcke des Application Lifecycle Management ......................... Realisierung von Anforderungen mittels Releases (Major Release) ......................................... 2.2.1 Requirements-Phase .................................. 2.2.2 Design-Phase ............................................ 2.2.3 Build-Phase ............................................... 2.2.4 Test-Phase .................................................

57 63 63 66 67 69

7

Inhalt

2.3

2.2.5 Deploy-Phase ............................................. 74 Realisierung von Anforderungen ber die Wartung (Minor Release) ................................... 75

3

Effektiver und effizienter Betrieb ............................ 793.1 3.2 3.3 3.4 3.5 Operations Control Center ...................................... Proaktives Monitoring und das Arbeiten mit dem Alert-Eingang .............................. Technische Administration ...................................... Betrieb von Geschftsprozessen am Beispiel berwachen des Tagesabschlusses ....................... Betrieb von Geschftsprozessen am Beispiel Automatisiertes Business-Exception- Management ......................................................... Technischer Betrieb am Beispiel Analyse komplexer technischer Probleme ........................... 80 82 86 87

90 92

3.6

4

Lsungsdokumentation im SAP Solution Manager4.1 Technische Landschaftsdokumentation .................... 4.1.1 Landschaftsdaten, Werkzeuge zur Verwaltung und Prozesse zur Nutzung ....... 4.1.2 Handhabung von Landschaftsdaten ............ 4.1.3 Topologie der Werkzeuge zur Verwaltung von Landschaftsdaten ................................. Assistent zur Lsungsdokumentation ....................... 4.2.1 Dokumentation der Systemlandschaft ........ 4.2.2 Automatische Zuordnung der Analyseergebnisse zu einer Geschftsprozessstruktur ............................ 4.2.3 Analyseergebnisse in einem Projekt aktualisieren oder in eine Lsung berfhren ................................................. Reverse Business Process Documentation ............... Initialer Aufbau einer Business-Blueprint- Struktur mit der Excel-Upload-Schnittstelle ............. Dokumentation der Lsung ..................................... SAP Solution Manager bei Sanofi-Aventis Deutschland GmbH .................................................

9597 99 104 117 118 119

4.2

120

4.3 4.4 4.5 4.6

127 127 129 131 137

8

Inhalt

5

Implementierung von Lsungen ............................. 1435.1 Beschleunigte und prozessorientierte Implemen- tierung durch den SAP-Standard-Content ............... 5.1.1 Aufbau ...................................................... 5.1.2 Inhalte ....................................................... 5.1.3 Produktabhngigkeit ................................ 5.1.4 Ausblick .................................................... ASAP-Implementierungsmethode ........................... 5.2.1 Umfang und Nutzen .................................. 5.2.2 Roadmap-Phasen ...................................... 5.2.3 Struktur der ASAP-Methode ...................... 5.2.4 Business Add-ons zur ASAP-Methode ........ 5.2.5 Arbeiten mit der Run-SAP- und der ASAP-Implementierungs-Roadmap ............ Projektverwaltung als Eckpfeiler der Projektvorbereitung ................................................ 5.3.1 Projektverwaltung ..................................... 5.3.2 Anlegen eines Einfhrungsprojekts ............ 5.3.3 Festlegen des Projektumfangs und der Vorgehensweise ........................................ 5.3.4 Verwalten von Projektmitarbeitern ............ 5.3.5 Festlegen der Systemlandschaft ................. 5.3.6 Festlegen der projektspezifischen Meilensteine ............................................. 5.3.7 Hinterlegen von Organisationseinheiten .... 5.3.8 Festlegen der Projektstandards .................. Business Blueprint Soll-Konzept fr Ihre Lsung ... 5.4.1 Aufbau des Business Blueprint ................... 5.4.2 Dokumentation des Soll-Konzepts ............. 5.4.3 Verantwortliche definieren ........................ 5.4.4 Abschluss des Business Blueprint .............. Konfiguration der Lsung ........................................ 5.5.1 Voraussetzungen der Konfiguration ........... 5.5.2 Grundstze der Konfiguration .................... 5.5.3 Realisierung von Eigenentwicklungen ........ 5.5.4 Arbeiten mit Servicemeldungen ................. Testmanagement .................................................... E-Learning-Management effizienter Wissenstransfer im Projekt ......................................

5.2

144 144 146 148 148 149 149 150 152 153 153 156 156 157 157 158 160 161 161 162 164 164 170 172 173 174 175 176 179 180 182 182

5.3

5.4

5.5

5.6 5.7

9

Inhalt

5.8

5.9

Erstellung von Lernmaterialien ................... SAP Productivity Pak by ANCILE Adapter for SAP Solution Manager .......................... 5.7.3 Organisieren und Verteilen von Lerninhalten ............................................... Reporting fr Ihr Einfhrungsprojekt ....................... 5.8.1 Reporting Roadmap ................................... 5.8.2 Reporting Business Blueprint ................... 5.8.3 Reporting Konfiguration .......................... 5.8.4 Reporting Lernmaterialien ....................... 5.8.5 Reporting Test ......................................... 5.8.6 Reporting Systemlandschaft ..................... 5.8.7 Reporting Historie ................................... SAP Solution Manager bei der HARTMANN GRUPPE .............................................

5.7.1 5.7.2

183 184 185 188 188 188 191 194 196 196 196 197

6

Vorlagenmanagement ............................................. 2036.1 Anwendungsbereiche fr Vorlagen .......................... 6.1.1 Die unternehmensweite Prozessbibliothek ....................................... 6.1.2 Konzern-Roll-out ....................................... Vorlagenmanagement im Detail .............................. 6.2.1 Vorlagenmanagement im Kontext des Application Lifecycle Management ............. 6.2.2 Methodische Untersttzung durch die Global ASAP Template Roadmap ................ 6.2.3 Anlegen von Vorlagen ................................ 6.2.4 Business-Blueprint-Definition und Konfigurationsstruktur ............................... 6.2.5 Freigabe und Implementierung von Vorlagen .................................................... 6.2.6 Tipps & Tricks fr die Arbeit mit Vorlagen .................................................... Vorlagenverwaltung und Lebenszyklus .................... 6.3.1 Vergleich und Abgleich von nderungen .... 6.3.2 bernahme von Vorlagennderungen (Roll-out) ................................................... 6.3.3 Rckfhrung lokaler nderungen in die Vorlage (Roll-in) ................................... Vorlagenmanagement bei Procter & Gamble ........... 203 204 204 207 207 209 210 212 213 214 217 217 221 223 223

6.2

6.3

6.4

10

Inhalt

7

Testmanagement ..................................................... 2317.1 7.2 Ablauf von der Testplanung bis zur Testdurchfhrung ................................................... 232 Optionen fr Testwerkzeuge ................................... 234 7.2.1 Testoption 1 .............................................. 235 7.2.2 Testoption 2 .............................................. 235 7.2.3 Testoption 3 .............................................. 236 7.2.4 Ergnzende Produkte ................................ 236 Business Process Change Analyzer ........................... 236 7.3.1 Anwendungsfall 1: Customizing- nderungen .............................................. 237 7.3.2 Anwendungsfall 2: nderungen von kundeneigenem Code ................................ 238 7.3.3 Anwendungsfall 3: Enhancement Package Business-Function-Analyse ........................ 239 7.3.4 Anwendungsfall 4: Optimierung des Testumfangs fr SAP Support Packages oder SAP Enhancement Packages .............. 241 7.3.5 Vorbereitende Schritte .............................. 245 7.3.6 Vorteile fr den Kunden ............................ 250 Testoption 1 ........................................................... 251 7.4.1 berblick ber Testfunktionen und Werkzeuge der Testoption 1 ...................... 251 7.4.2 Work Center Testmanagement .............. 253 7.4.3 Manuelles Testen ...................................... 255 7.4.4 Testautomatisierung .................................. 259 7.4.5 Test-Reporting .......................................... 265 Testoption 2 Testen mit dem SAP Quality Center by HP ....................................... 268 7.5.1 berblick ber Testfunktionen und Werkzeuge der Testoption 2 ...................... 269 7.5.2 bertragung in den Business Blueprint ...... 272 7.5.3 Erstellen von Testplnen ............................ 273 7.5.4 Testflle mit SAP Test Acceleration and Optimization erstellen ............................... 275 7.5.5 Ausfhren der Testflle unter Verwendung von SAP Test Acceleration and Optimization und SAP Quality Center by HP ............................................. 276

7.3

7.4

7.5

11

Inhalt

7.6

7.7

Austausch von Fehlermeldungen zwischen SAP Quality Center by HP und SAP Solution Manager ............................... 7.5.7 Reporting in SAP Solution Manager und SAP Quality Center by HP .......................... 7.5.8 Wartung von Testfllen mithilfe von SAP Test Acceleration and Optimization .... Testoption 3 Integration mit IBM-Rational-Werkzeugen ...................................... 7.6.1 Ein automatisierter, integrierter, standardisierter Ansatz ............................... 7.6.2 Anlegen von Business Blueprints und Anforderungsmanagement ......................... 7.6.3 nderungseinfluss-Analyse ........................ 7.6.4 Testplanung ............................................... 7.6.5 Vorteile fr den Kunden ............................. SAP Solution Manager bei Colgate-Palmolive .......... 7.5.6

278 279 280 282 283 283 284 284 286 287

8

Verwaltung der nderungskontrolle ....................... 2958.1 Quality Gate Management ...................................... 8.1.1 Work Center Change Management ......... 8.1.2 Zentrale Transportverwaltung mit Quality Gate Management ......................... 8.1.3 SAP Best Practices im Bereich Transport .... Change Request Management ................................. 8.2.1 Change Request Management im Detail ..... 8.2.2 Architektur ................................................. 8.2.3 Projektzyklus und Wartungszyklus .............. 8.2.4 nderungsantrag (Request for Change) ...... 8.2.5 nderungstypen im Change Request Management im Detail .............................. 8.2.6 nderungsverwaltung mit dem Change Request Management .................... 8.2.7 Zentrale nderungskontrolle ...................... 8.2.8 Transparenz ber nderungsprozesse ......... 8.2.9 Integration des Change Request Manage- ment mit den anderen Application- Lifecycle-Management-Funktionen ............ 296 297 303 307 308 310 316 317 321 326 332 334 340

8.2

344

12

Inhalt

8.3

8.4

8.5

Transportverwaltung ............................................... 8.3.1 SAP-nderungs- und Transportsystem (CTS) ............................... 8.3.2 Synchronisation von Entwicklungssystemen .............................. 8.3.3 SAP Transport Execution Analysis Service ........................................ nderungsdiagnose ............................................... 8.4.1 nderungen verfolgen ............................... 8.4.2 nderungsauswertungen ........................... 8.4.3 Durchgngige nderungsanalyse ............... 8.4.4 Konfigurationsvalidierung .......................... SAP Solution Manager bei Ferrero Deutschland MSC GmbH & Co. KG .........................

348 348 360 363 365 365 366 367 369 373

9

Application Incident Management ........................ 3819.1 Incident und Problem Management ........................ 9.1.1 IT-Servicemanagement nach ITIL ............... 9.1.2 SAP-IT-Servicemanagement (SAP ITSM) .... 9.1.3 Integrationskonzept ................................... 9.1.4 Anwendungsszenarien ............................... 9.1.5 Der zentrale Incident- und Problem-Management-Prozess .................. 9.1.6 Stammdaten ............................................. 9.1.7 Best-Practice-Funktionen ........................... Incident Management mit Help-Desk-Systemen anderer Anbieter .................................................... Incident Management fr IT-Dienstleister ............... Incident Management fr Softwarepartner .............. SAP Solution Manager bei Ferrero Deutschland MSC GmbH & Co. KG ......................... SAP Solution Manager bei der itelligence AG .......... 381 382 384 385 388 398 405 408 414 416 423 428 436

9.2 9.3 9.4 9.5 9.6

10 Technischer Betrieb ................................................. 44310.1 Technisches Monitoring .......................................... 10.1.1 Alert-Eingang ............................................ 10.1.2 System-Monitoring .................................... 10.1.3 Verbindungs-Monitoring ........................... 447 448 453 456

13

Inhalt

10.2 Zentrale berwachung von SAP NetWeaver Process Integration .................................................. 10.2.1 Einstieg und Navigation ............................. 10.2.2 Overview Monitor ...................................... 10.2.3 Component Monitor .................................. 10.2.4 Channel Monitor ........................................ 10.2.5 Message Monitor ....................................... 10.2.6 Zentrale inhaltsbasierte Nachrichtensuche ..................................... 10.2.7 Anbindung an die Alert-Infrastruktur .......... 10.2.8 Anbindung an den Service Desk ................. 10.3 End-User-Experience-Monitoring ............................ 10.4 End-to-End-Root-Cause-Analysis ............................. 10.4.1 Vorgehensweise zur Root Cause Analysis ... 10.4.2 Architektur ................................................. 10.4.3 Werkzeuge in der Root Cause Analysis ....... 10.4.4 Root Cause Analysis im Detail .................... 10.4.5 Qualittssicherung mit Werkzeugen der Root Cause Analysis ................................... 10.5 Technische Administration ...................................... 10.5.1 Work Mode Management .......................... 10.5.2 IT-Kalender ................................................ 10.5.3 Benachrichtigungsverwaltung ..................... 10.5.4 Zentrale Systemadministration ................... 10.6 Technische Analyse ................................................. 10.6.1 Technische Auswertungen .......................... 10.6.2 Management-Auswertungen ...................... 10.7 Datenvolumenmanagement .................................... 10.7.1 Positionsbestimmung ................................. 10.7.2 Analyse der Datenverteilung ...................... 10.7.3 Priorisieren von Objekten ........................... 10.7.4 Priorisieren nach Speicherverbrauch ........... 10.7.5 Priorisieren nach Altersstruktur der Daten ......................................................... 10.7.6 Priorisieren nach Nutzungshufigkeit .......... 10.7.7 Auswertung der Daten ............................... 10.7.8 Diskussionen mit den Fachbereichen .......... 10.7.9 Projekt-Reporting ......................................

458 461 462 464 465 466 471 473 473 474 481 483 485 487 489 499 501 502 511 512 513 524 524 539 543 543 544 549 550 552 553 556 558 561

14

Inhalt

11 Betrieb von Geschftsprozessen ............................ 56511.1 Geschftsprozess- und Schnittstellenberwachung .. 11.1.1 Werkzeuge, die den Betrieb der Geschftsprozesse untersttzen ................. 11.1.2 Geschftprozessberwachung im SAP Solution Manager ............................... 11.1.3 Handhabung der Geschftsprozessber- wachung im SAP Solution Manager ........... 11.1.4 Geschftsprozesse mit der Anwendung Geschftsprozess-Analyse (Business Process Analytics) verbessern ..................... 11.2 Jobverwaltung ........................................................ 11.2.1 Herausforderungen in der Jobverwaltung ... 11.2.2 Fallbeispiel eines Jobverwaltungsprozesses im Sinne des SAP-Standards ...................... 11.2.3 Automatische Umleitung eines Endanwenders vom Backend-System in das Antragsformular des SAP Solution Manager ............................... 11.2.4 Job Scheduling Management Health Check 11.3 Datenkonsistenzverwaltung .................................... 11.3.1 Einfhrung in die Daten- konsistenzverwaltung ................................ 11.3.2 berblick ber die Werkzeuge zur Datenkonsistenzverwaltung ....................... 11.4 Performance von Geschftsprozessen ...................... 11.4.1 Performanceoptimierung von Geschftsprozessen ................................... 11.4.2 Performanceoptimierung mit Self-Services der SAP ................................. 11.5 SAP Solution Manager bei der Bayer MaterialScience ...................................................... 566 566 569 571

573 576 577 580

588 589 591 591 593 599 600 605 609

12 Wartung einer SAP-Lsungslandschaft .................. 61512.1 Der Maintenance Optimizer ................................... 12.1.1 Der Maintenance Optimizer im Detail ....... 12.1.2 Maintenance Optimizer fr SAP ERP ......... 12.1.3 Untersttzung komplexer Landschaften ..... 616 618 623 625

15

Inhalt

12.1.4 Country Legal Changes Packages fr SAP ERP HCM Lsungen und HR Support Packages in den Wartungs- vorgang einbinden ..................................... 12.1.5 Berechtigungen und Auswertungen im Maintenance Optimizer ............................. 12.1.6 Wartungszertifikat und Lizenzmanagement 12.2 Systemempfehlungen .............................................. 12.2.1 Empfehlungen fr Ihre Systeme erhalten .... 12.2.2 Integration mit anderen Werkzeugen im SAP Solution Manager ............................... 12.2.3 Einrichtung der Funktion Systemempfehlungen ..............................

626 627 628 630 631 632 632

13 Untersttzung von Upgrade-Projekten .................. 63313.1 Upgrade Dependency Analyzer ............................... 635 13.1.1 Mgliche Abhngigkeitsaussagen ............... 637 13.1.2 Abgrenzung des UDA zum Maintenance Optimizer und den Szenarien- und Prozess- komponentenlisten (PCL/SCL) .................... 640 13.1.3 Datenqualitt und Haftungsausschluss ........ 641 13.1.4 Beispiele fr die Nutzung des UDA ............. 641 13.2 Projektplanung und Projektmanagement mit der Upgrade Roadmap ...................................... 649 13.3 Custom Development Management Cockpit ........... 650 13.4 Maintenance Optimizer ........................................... 651 13.5 Testmanagement ..................................................... 652 13.6 Endanwenderschulungen ......................................... 653 13.7 SAP Upgrade Assessment ....................................... 653 13.8 SAP GoingLive Functional Upgrade Check ............... 653 13.9 Methode Near Zero Downtime ............................... 654

14 SAP Landscape Transformation .............................. 65514.1 Der Greenfield-Ansatz ............................................. 659 14.2 Das Vorgehen bei SAP-Transformationen ................ 659 14.3 Phasen der Durchfhrung eines Transformationsprojekts .......................................... 660

16

Inhalt

14.4

14.5

14.6 14.7

14.3.1 Identifikation des Transformationsansatzes ............................ 14.3.2 Analyse der Systemlandschaft und Planung des Projekts ................................. 14.3.3 Evaluierung und Vorbereitung eines Transformationsprojekts ............................ 14.3.4 Realisierung eines Transformationsprojekts ............................ 14.3.5 Typische Vorgehensweise bei der Durchfhrung eines Mandantentransfers ... Transformationsszenarien ........................................ 14.4.1 Transformationslsungen fr Verkaufs-, Kauf- und Umstrukturierungsvorhaben ...... 14.4.2 Vereinheitlichung und Transformation von Daten ................................................. 14.4.3 Konsolidierung von Systemen und Reduzierung der IT-Kosten ........................ Nutzung von SAP Landscape Transformation .......... 14.5.1 Arbeiten mit SAP Landscape Transformation .......................................... 14.5.2 Aufbau des Work Centers der SAP-LT-Software ...................................... 14.5.3 Projekte anlegen ....................................... 14.5.4 Kombinieren von Transformationslsungen ........................... 14.5.5 Projekte durchfhren ................................. 14.5.6 Analysen ausfhren ................................... 14.5.7 Transformationsapplikationen ausfhren .... 14.5.8 Wichtige Hinweise und Empfehlungen zur technischen Durchfhrung ................... Ergnzende Services zu SAP Landscape Transformation ............................... SAP Solution Manager bei SKW Stahl-Metallurgie Holding AG .................................

661 661 662 662 663 664 664 669 675 677 678 679 682 683 684 685 686 687 688 692

15 Custom Code Management: effiziente Verwaltung kundeneigener Entwicklungen ................................ 69715.1 Einfhrung in Custom Code Management .............. 697 15.1.1 Das Stadt-Modell ...................................... 698

17

Inhalt

15.2

15.3 15.4

15.5

15.1.2 Der Prozess des Custom Code Management .............................................. Custom Code Lifecycle Management Verwaltung kundeneigener Entwicklungen .............. 15.2.1 Prozess und Architektur ............................. 15.2.2 Die Anwendung CCLM im Detail ................ 15.2.3 Einstellungen ............................................. 15.2.4 Bibliotheksdefinition .................................. 15.2.5 Objekte in der Bibliothek ........................... 15.2.6 Reporting ................................................... Custom Development Management Cockpit ............ Analysen fr kundeneigene Entwicklungen .............. 15.4.1 SAP-Originalobjekte von Klonen unterscheiden ............................................ 15.4.2 Verwendungsbereiche der Klone identifizieren .............................................. 15.4.3 berwachung und Auswertung der Modifikationen .......................................... 15.4.4 Versionen Ihrer Programme unterscheiden ............................................ 15.4.5 Zeit fr Verbesserung ................................. Custom Code Lifecycle Management bei Procter & Gamble ....................................................

700 702 703 707 709 711 712 714 716 726 726 729 730 731 733 734

Anhang ............................................................................ 739A B Die Autoren ....................................................................... 739 Autoren der Kundenerfahrungsberichte ............................. 759

Index ........................................................................................ 765

18

Die whrend des Betriebs der Lsung erhobenen Kennzahlen und Daten knnen Sie dazu verwenden, Kosten zu senken oder die Performance zu steigern. Wichtig ist, dass alle nderungen nachvollziehbar in der Lsung vorgenommen werden. In diesem Kapitel werden der Prozess Verwaltung der nderungskontrolle erlutert und die Funktionsweisen des Change Request Management, des Quality Gate Management, des Retrofit sowie der untersttzenden Services und Analysen im Detail erklrt.

8

Verwaltung der nderungskontrolle

Der Prozess Verwaltung der nderungskontrolle (Change Control Management) stellt sicher, dass nderungen geplant und konsistent durchgefhrt werden. Wichtig ist, dass alle nderungen nachvollziehbar in der Lsung vorgenommen werden und ihr Risiko in Bezug auf Stabilitt und Sicherheit jederzeit kontrollierbar ist. Der SAP Solution Manager untersttzt Sie dabei durch eine Vielzahl von Funktionen. Das ITIL-zertifizierte Change Request Management ermglicht Ihnen die hchste Integration in Ihren Change-Management-Prozess. Darber hinaus stellt das Quality Gate Management eine zustzliche Qualittskontrolle fr Projekte bereit und sichert den korrekten Transport von nderungen in die Produktivsysteme. Im Umfeld von Upgrade, globalen Roll-outs von Vorlagen oder funktionalen Weiterentwicklungen ergeben sich Risiken und Aufwnde in der Synchronisation von Entwicklungssystemen. Mit der RetrofitFunktion synchronisieren Sie duale Landschaften vollstndig und mit minimalem manuellen Aufwand. Um ber alle nderungen in der Landschaft einen berblick zu behalten, bietet Ihnen die ChangeAnalyse Informationen zum aktuellen Stand und zur Historie der nderungen an. Aufgezeichnet werden nderungen von Konfigurationen eines Systems von Betriebssystem, Datenbank und Applikationsserver-Parametern ber Transportauftrge und Hinweise bis hin zu Support Packages. Mit der Configuration Validation knnen Sie Konfigurationseinstellungen vergleichen und damit z. B. die Homogenitt der Konfiguration innerhalb der Lsungslandschaft sicherstelFunktionen des SAP Solution Manager

295

8


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 knnen Sie fr sich einen entsprechenden Aktionsplan ableiten, der organisatorische, prozess- oder auch werkzeugbezogene Aspekte enthalten kann.

8.1

Quality Gate Management

Das Quality Gate Management stellt in Bezug auf eine durchgngige Lsungslandschaft 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 konsistenten Qualittsprozess im Unternehmen zu etablieren und alle beteiligten Abteilungen darin zu integrieren.Zusammenarbeit mit dem Release Management

Das Quality Gate Management untersttzt das Release Management bei Implementierungs- und Wartungsprojekten bei Kunden. In der Regel wird dabei zwischen zwei Arten von Releases unterschieden: 1. Major Release Das Major Release ist gekennzeichnet durch eine drei- bis sechsmonatige Laufzeit. Kunden entwickeln innerhalb eines Jahres zwei bis vier Releases. Ein solches Release beinhaltet alle Arten von nderungen, auch solche, die Kerngeschftsprozesse nachhaltig beeinflussen, daher erfordert ein Major Release einen kompletten Regressionstest. 2. Minor Release Das Minor Release ist durch eine wesentlich krzere Laufzeit zwischen einer und vier Wochen definiert. Ziel eines solchen Releases ist es, Fehlerkorrekturen und kleinere funktionale Erweiterungen zu bndeln und zur Verfgung zu stellen. Hierbei kann der Testumfang auf die Kerngeschftsprozesse und die bereitgestellten Erweiterungen eingeschrnkt werden. Diese Vorgehensweise bietet Ihnen die folgenden Vorteile: Die Hufigkeit der nderungen im produktiven System wird reduziert. nderungen finden zu klar definierten Zeitpunkten statt. Die Zufriedenheit der Endanwender steigt durch frhzeitige Kommunikation und Trainings.296


8.1

Fr jede nderung steht die angemessene Testmethode zur Verfgung. Tgliche nderungen werden auf Notfallkorrekturen reduziert. Das Risiko von Inkonsistenzen durch fehlende oder in der falschen Reihenfolge eingespielte Transporte verringert sich. Der Arbeitsaufwand fr Transportverwaltung durch Bndelung sinkt. Abbildung 8.1 zeigt das Release Management (Minor und Major Release) und Transport Management, also das Einspielen in Folgesysteme, im berblick.

SAP Solution ManagerImplementierungsprojekt (Major Release)

QG

Scope

QG

Build

QG

Test

QG

Deploy

QG

Wartungsprojekt in Zyklen (Minor Release)

...

Build

QG

Test

QG

Deploy

QG

Scope

QG

Build

QG

...

Major Release Transportzyklus nderungskategorien Prioritt Testumfang 3-6 Monate Alle Arten von nderungen inklusive invasiver Eingriffe Normal Kompletter Testumfang

Minor Release 1-4 Wochen Fehlerkorrekturen und kleinere nderungen (inkl. Reimport von Notfallkorrekturen) Normal Zentrale Prozesse und neue Funktionen

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 fr das Quality Gate Management anzulegen bzw. zu verwalten. Die Darstellung ermglicht dem Benutzer, sich einen schnellen berblick ber die verschiedenen Softwareentwicklungsprojekte und deren Status zu verschaffen. Dabei untersttzt das Quality Gate Management sowohl Implementierungs- als auch Wartungsprojekte.

297

8


Sichten

In der Sicht berblick sehen Sie, welche Aufgaben zu erledigen sind bzw. an welchen Projekten Sie mitarbeiten oder beteiligt sind und welcher Rolle Sie zugewiesen sind. Die zu erledigenden Aufgaben knnen von Ihnen direkt bearbeitet werden. Die automatische Aktualisierung sorgt dafr, dass Sie immer auf dem aktuellen Datenbestand arbeiten. Mithilfe von Favoriten knnen mehrere Projekte benutzerspezifisch zusammengefasst und dargestellt werden. ber die Sicht Projekte knnen Sie eine Vielzahl von Informationen visualisieren. Hierfr stehen verschiedene Registerkarten innerhalb der Sicht Projekte zur Verfgung (siehe Abbildung 8.2).

Abbildung 8.2 Projektbersicht im Quality-Gate-Kalender

Mithilfe der Registerkarte Kalendersicht knnen Sie sich anhand des Quality-Gate-Kalenders den Status aller aktuell angelegten bzw. laufenden Projekte sowie deren aktive Phase anzeigen lassen. Zustzlich werden sowohl die Quality Gates als auch die Meilensteine in der bersicht visualisiert. Mithilfe der Mehrfachselektion von Projekten ermglicht die Kalendersicht, die Projektlaufzeiten und deren aktuellen Status zu visualisieren. Diese Ansicht erlaubt es, eventuelle zeitliche Konflikte frhzeitig zu erkennen und entsprechende Aktionen zu initiieren.Vorgehensweise

Um ein Projekt innerhalb des Quality Gate Management zu nutzen, mssen bestimmte Voraussetzungen erfllt sein. Sie mssen ein SAPSolution-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 gewnschten Projekts knnen

298


8.1

Sie ber den Menpunkt Einrichten Quality Gate Management die noch ausstehenden Konfigurationen vornehmen. Nach dem Klick auf den Menpunkt ffnet sich ein Assistent, in dessen erstem Schritt Sie die Startzeitpunkte der einzelnen Phasen festlegen knnen. Folgende vier Phasen mit den entsprechenden Quality Gates sind im Standard definiert: Scope Build Test Deploy Ein Quality Gate (Q-Gate) ist ein spezieller Meilenstein in einem Projekt. Q-Gates befinden sich zwischen denjenigen Phasen im Projekt, die in besonderer Weise von den Ergebnissen der Vorphase abhngig sind oder in denen besonderes Augenmerk auf technische Abhngigkeiten gelegt werden muss. Ein Q-Gate beinhaltet eine Prfung der Ergebnisse der Vorphase. Die geforderten Ergebnistypen und Anforderungen an diese Phasen knnen Sie z. B. in Form von Checklisten fr ein Q-Gate hochladen. Die Prfung wird von Projektverantwortlichen und Experten der entsprechenden Phasen innerhalb einer Sitzung vorgenommen. Je nach Ausgang kann das Projekt wie geplant weiterlaufen, kann aber auch abgebrochen oder verzgert werden. Bei Einsatz des Quality Gate Management knnen keine Transporte in die Folgesysteme eingespielt werden, ohne dass ein Q-Gate erfolgreich durchlaufen wurde. Diese Importsperre erlaubt Ihnen ein hohes Ma an Kontrolle ber Ihre Projekte und das Transportwesen. Erst nach erfolgreich durchlaufener Q-Gate-Prfung wird die Importsperre fr das nachfolgende System aufgehoben. In Abbildung 8.3 ist der Ablauf des Quality Gate Management exemplarisch dargestellt. Zustzlich zu den bestehenden Q-Gates knnen Sie sogenannte Meilensteine anlegen, die einen bestimmten Zeitpunkt in Ihrem Projekt darstellen. Ein Meilenstein ist ein Ereignis mit besonderer Bedeutung. Im Projektmanagement sind diese Ereignisse meist Unter- bzw. Zwischenziele eines Projekts. Diese Ziele sind an die Fertigstellung eines bedeutenden Projektergebnisses gebunden. Um die Wichtigkeit eines Meilensteins hervorzuheben, knnen Sie ihn zustzlich mit einer Q-Gate-Prfung versehen.Meilensteine Quality Gate

299

8


Quality-Gate offen

Quality-Gate geschlossen

Build

Quality-Gate

Test

Quality-Gate-DokumentEntwicklerQualittsmanager Resultate dokumentieren Dokumentation hochladen Q-Gate bewerten

Tester Administrator

Quality Steering BoardEmpfehlungen des QualittsManagers besttigen oder zurckweisen

Solution-Manager-Projekt mit Quality Gate ManagementAbbildung 8.3 Ablauf des Quality Gate Management Qualittsmanager und Qualittsausschuss

Im zweiten Schritt legen Sie den Qualittsmanager sowie den Qualittsausschuss 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 besttigen, wird die Importsperre fr das dem Q-Gate zugewiesene System aufgehoben und ein Import in das System ermglicht. Die Transporte mit den unterschiedlichen Entwicklungen knnen 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 Transportwegekonfiguration verifiziert. In einem weiteren Schritt erfolgt die Zuordnung der einzelnen QGates zu den Phasen und Systemrollen. Durch die flexible Zuordnung der Q-Gates ist es z. B. auch mglich, zwischen dem Entwicklungssystem und dem Qualittssicherungssystem kein Q-Gate zu setzen, somit ein iteratives Testen zu ermglichen und trotzdem sein Produktivsystem zu schtzen.

300


8.1

Nach Abschluss der Konfiguration zeigt der Assistent Ihnen die Projektlandschaft mit den einzelnen Phasen, Systemen, Q-Gates und Meilensteinen (siehe Abbildung 8.4).

Abbildung 8.4 Projektlandschaft nach Abschluss der Konfiguration

Nach 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).

Q-Gate-Kalender

Abbildung 8.5 Q-Gate-Dokumentation

301

8


Der Qualittsmanager ist fr den bergang der einzelnen Projektphasen verantwortlich (Scope, Build, Test und Deploy). Die Prfung hierfr wird durch Projektverantwortliche und Experten fr die entsprechenden Phasen innerhalb einer Sitzung vorgenommen. Zustzlich stehen Ihnen verschiedene Informationen und Sichten fr Ihre Softwareentwicklungsprojekte zur Verfgung. 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 Qualittsmanager ber verschiedene Registerkarten sowohl allgemeine als auch detaillierte Informationen, wie z. B. definierte Projektphasen, Anzahl der zum Projekt gehrenden nderungen und Transportauftrge sowie Informationen zu den Verantwortlichen des Projekts, zur Verfgung (siehe Abbildung 8.7).Log

Fr die entsprechende Revisionssicherheit sorgt ein Aktions-Log bzw. Applikations-Log, das alle Aktivitten mit Zeitstempel und Benutzer mitprotokolliert.

302


8.1

Abbildung 8.7 Projekt mit den nderungen und den dazugehrigen Transporten

8.1.2

Zentrale Transportverwaltung mit Quality Gate Management

In heutigen heterogenen, verteilten Kundenlsungen ist es notwendig, im Bezug auf eine durchgngige Lsungslandschaft sicherzustellen, dass die Implementierung eines neuen Service effizient und effektiv durchgefhrt werden kann. Whrend frher das Hauptaugenmerk auf den Abhngigkeiten von Objekten in einer Systemlandschaft lag, liegt es heute auf den Abhngigkeiten von Objekten in einer Lsungslandschaft. Das heit, Systeme, die technisch vollkommen unabhngig voneinander sind, stehen mehr und mehr in einer funktionalen Abhngigkeit. Ziel muss es sein, eine zentrale Transportverwaltung fr die gesamte Lsungslandschaft zu etablieren. Mit dem Quality Gate Management stellt der SAP Solution Manager im Work Center Change Management eine Administrationsoberflche fr die zentrale Transportverwaltung (siehe Abbildung 8.8) zur Verfgung. Mit einem Klick auf die Registerkarte Systemlandschaftsgrafik kann sich der Transportverantwortliche nach vorheriger Auswahl des Projekts die definierte Lsungslandschaft grafisch im Detail ansehen (siehe Abbildung 8.9).Transportkonfiguration und -risiken

303

8


SAP Solution Manager Change Control ManagementSAP-SolutionManager-Projekt nderung 1

SAP NetWeaver Portal

SAP ECC

Transportauftrag Transportauftrag

nderung 2


nderung 3


Abbildung 8.8 Zentrale Transportverwaltung

Abbildung 8.9 Systemlandschaftsgrafik

Die Lsungslandschaft spiegelt die kundenspezifische Transportkonfiguration und deren Transportwege wider. Die Lsungslandschaft 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

304


8.1

Phase des Projekts sowie die durchlaufenen und noch anstehenden Q-Gates an. Zustzlich werden eventuelle Transportrisiken in der Systemgrafik farblich gekennzeichnet. Die Transportrisiken der entsprechenden Systeme werden darber hinaus auf der Registerkarte Risiken in tabellarischer Form zur Verfgung gestellt (siehe Abbildung 8.10). Die Risiken werden vom System automatisch gesammelt. Der Qualittsmanager kann auf diese Art vor jeder Phase bzw. vor jedem Phasenabschluss beurteilen, welche Transporte freigegeben wurden bzw. noch auf eine Freigabe warten. Darber hinaus ist zu erkennen, ob alle Transporte korrekt in das System importiert wurden. Basierend auf diesen Informationen kann er entscheiden, welche Manahmen notwendig sind.

Abbildung 8.10 Transportrisiken in Lsungslandschaften

Beispiele fr Risiken sind: Transportfehler (Return-Code 8) fehlende Transportauftrge in den Systemen Transporte, die eine logische Abhngigkeit zueinander haben und nicht vollstndig importiert wurden

305

8


offene Transportauftrge, die im Entwicklungssystem auf die Freigabe warten Auf diese Weise kann der Qualittsmanager mit entsprechenden Aktivitten kritischen Situationen effektiv entgegenwirken und eine Risikoeinschtzung 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 Transportauftrgen dar. Dabei knnen beliebig viele nderungen fr ein Projekt angelegt werden. Die einzelnen nderungen knnen Sie ber die Registerkarte nderungen fr das jeweilige Projekt anlegen. Nach dem Anlegen einer nderung knnen Sie dieser eine beliebige Anzahl von Transportauftrgen (Workbench/Customizing) zuordnen. Das Anlegen von Transportauftrgen kann ber die Registerkarte nderungen, ber die Schaltflche Transporte verwalten oder ber die Registerkarte Transporte mit der Schaltflche anlegen erfolgen. Die nderungen bilden die Klammer fr die verschiedenen Transportauftrge, die ihnen zugeordnet sind. Die Basis hierfr bilden CTS-Projekte. Die in Abschnitt 8.1.1 angesprochenen nderungen und Transportauftrge fr ein Projekt knnen 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 gehrenden Transportauftrge

306


8.1

Durch dieses Konzept ist es mglich, logisch zusammengehrige bzw. voneinander abhngige Transportauftrge system- und/oder lsungsspezifisch zu bndeln. Abhngig von der aktuellen Phase knnen Sie ganze Projekte oder einzelne nderungen mit einem oder mehreren Transportauftrgen in die nachfolgenden Systeme importieren. In der Test-Phase kann der Administrator in Absprache mit dem Qualittsmanager und weiteren Experten Transportauftrge anderen Projekten und deren nderungen zuordnen. In dieser Phase des Softwareentwicklungsprojekts kann der Qualittsmanager eine Konsolidierung des Projekts vornehmen, bevor er die letzte Phase des Projekts aktiviert. In der Deploy-Phase kann das komplette Projekt mit all seinen Transportauftrgen entsprechend den in der Praxis bewhrten Vorgehensweisen von SAP (SAP Best Practices) importiert werden. Damit wird sichergestellt, dass alle Transportauftrge 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 durchgefhrt werden, steht auch fr die Deploy-Phase der Import einzelner nderungen zur Verfgung. Mithilfe dieser Funktionalitt knnen Geschftsprozesse in ABAP- und Nicht-ABAP-Systemen ber Lsungslandschaften hinweg synchron gendert werden.

Transportauftrge logisch bndeln

8.1.3

SAP Best Practices im Bereich Transport

Um Sie bei Ihren nderungen bestmglich zu untersttzen, wurde das Quality Gate Management unter Bercksichtigung der SAP Best Practices im Bereich Transport entwickelt. Diese basieren auf der Erfahrung einer Vielzahl von Kundenprojekten: Transport von Kopien Diese Funktion bietet die Mglichkeit, einen originalen Transportauftrag und die darin befindlichen Objekte so lange im Entwicklungssystem zu sperren, bis die entwickelte Funktionalitt erfolgreich im Qualittssicherungssystem getestet wurde. Erst danach findet die finale Freigabe des originalen Transportauftrags statt. Folglich arbeitet der Entwickler so lange wie mglich mit dem Transport von Kopien. Dieses Vorgehen bringt im Wesentlichen zwei Vorteile. Zum einen wird die Anzahl der Transportauftrge, die in das Produktivsystem importiert werden, reduziert. Da der originale Transport

307

8


nur die finale Version des genderten Objekts enthlt und nicht die zuvor entwickelten Versionen, reduziert sich sowohl die Anzahl der Objektversionen im Produktivsystem als auch die Importzeit der Transportauftrge.berholerproblematik

Der zweite Vorteil liegt darin, dass mit dem Transport von Kopien die Gefahr der berholerproblematik entscheidend reduziert werden kann, weil die entwickelten Objekte so lange wie mglich im Entwicklungssystem gesperrt bleiben und somit Versionskonflikte verhindert werden knnen. Systembergreifende Objektsperre Mithilfe der systembergreifenden Objektsperre ist es mglich, mehrere Implementierungsprojekte bzw. Wartungsprojekte auf ein und derselben Systemlandschaft zu betreiben. ndert ein Entwickler in einem Projekt ein Objekt, ist dieses Objekt fr alle anderen Entwickler sowohl im gleichen als auch in den anderen Projekten auf dieser Systemlandschaft mithilfe der systembergreifenden Objektsperre nicht mehr nderbar. Abhngig von der Einstellung der Sperre kann eine nderung frhestens nach der finalen Freigabe des Transportauftrags erfolgen. Dadurch werden Versionskonflikte frhzeitig unterbunden. Diese Funktion steht sowohl fr ABAP-Workbench-Objekte als auch fr CustomizingEinstellungen zur Verfgung. Dringende Korrekturen Eine dringende Korrektur ermglicht die schnellstmgliche Implementierung einer Korrektur im Produktivsystem mithilfe eines Vorabtransports. Durch die Zuordnung zu einem Projekt bleiben die Transportreihenfolge und die Konsistenz des Produktivsystems erhalten. Weiterfhrende Details zu den SAP Best Practices im Bereich Transport finden Sie in Abschnitt 8.3.

8.2

Change Request Management

Die Mglichkeit, nderungen nachzuvollziehen, ist einer der wichtigsten Faktoren, um Qualitt und Transparenz in einer Softwarelsung zu garantieren und dabei sicherzustellen, IT-Standards zu erfllen. Das gilt besonders fr nderungen an Softwarekomponenten selbst oder nderungen an der Konfiguration. Dieser Abschnitt zeigt,

308


8.2

wie der SAP Solution Manager Sie dabei untersttzt, nderungen an Softwarekomponenten oder deren Konfiguration durch klar geregelte Prozessablufe und eine lckenlose Dokumentation umzusetzen, und Ihnen damit die Mglichkeit 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 Unternehmens in einer sich stndig ndernden Marktsituation zu sichern, oder dadurch, dass whrend des tglichen Betriebs Strungen oder technische Probleme auftreten, die nur durch eine nderung am System oder den Austausch einer IT-Komponente behoben werden knnen. Im Change Request Management mnden all diese nderungsanforderungen in sogenannten nderungsantrgen. Dabei bietet das Change Request Management Funktionen, um all diese nderungen, Anforderungen und nderungsantrge zu verwalten, auszufhren und zu dokumentieren nicht nur durch Nachverfolgen eines Status, sondern auch durch eine verbesserte Integration zwischen der Fachabteilung und der IT bei diesem Prozess. Die Anwendung untersttzt nderungen von der ersten Anforderung bis zum finalen Deployment 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 Transportwesen von SAP selbst voraus. Diese Integration beginnt auf der Geschfts- und nderungsprozessebene und geht bis auf die technische Ebene von Transporten und Entwicklungsobjekten. Generell unterscheidet SAP zwischen verschiedenen Arten von nderungen. Basierend auf der Zeit, die bentigt wird, um die nderung durchzufhren und einzusetzen, werden diese in verschiedene Arten von Releases unterteilt. Die grte Kategorie bilden dabei die Major Releases, die eine Laufzeit von drei bis sechs Monaten haben und durch nderungen die Kerngeschftsprozesse nachhaltig beeinflussen. Daneben gibt es Minor Releases, die eine wesentlich krzere Laufzeit haben und in erster Linie genutzt werden, um Fehlerkorrekturen bereitzustellen und kleinere Anforderungen zu realisieren. Innerhalb der IT-Organisation werden diese nderungen oder Releases entweder durch ein Implementierungsprojekt oder durchnderungsantrge

Major und Minor Releases

Implementierungs- oder Wartungsprojekt

309

8


ein Wartungsprojekt realisiert, das fortlaufend nderungen am System ermglicht. Die Projekte sind dabei immer in Phasen unterteilt, um das Projektmanagement sowie die Release-Kontrolle zu untersttzen. Eine detaillierte Darstellung der Phasen, die im Change Request Management verwendet werden, finden Sie in Abschnitt 8.2.3. Change Request Management kann auerdem auch in Kombination mit dem Quality Gate Management des SAP Solution Manager verwendet werden, um die verschiedenen Phasen und Abschnitte eines Implementierungsprojekts zu kontrollieren. Diese Integration erlaubt es Ihnen, sicherzustellen, dass Qualittskriterien und Projektstandards eingehalten werden, bevor eine Phase eines Projekts abgeschlossen 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 erwhnt, sind beide Anwendungen eng in die Transportinfrastruktur der SAP integriert. Dies ermglicht 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 Aktivitten werden auf ein Minimum reduziert.

8.2.1

Change Request Management im Detail

Change Request Management ist ein flexibles Werkzeug, das Sie dabei untersttzt, Entwicklungen und nderungen an Ihrer gesamten Systemlandschaft zentral im SAP Solution Manager zu kontrollieren. Fr 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 nderungsantrag und dem nderungsvorgang.nderungsantrag

Der nderungsantrag ist das initiale Dokument, in dem die Anforderung oder die durchzufhrende nderung erstmals dokumentiert und beschrieben wird und in dem auch die Genehmigung bzw. das Genehmigungsverfahren des Antrags abluft und dokumentiert wird. Sobald Sie einen nderungsantrag genehmigt haben, werden ein oder mehrere nderungsvorgnge als Folgedokumente mit direktem

nderungsvorgang

310


8.2

Bezug zum ursprnglichen Antrag erstellt. Bei den nderungsvorgngen 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 nderungsvorgang haben Sie die Mglichkeit, alle Aktivitten zu dokumentieren und auszufhren, die bentigt werden, um diese nderung vorzunehmen. So knnen Sie jederzeit nachzuvollziehen, wo eine konkrete nderung ihren Ursprung hatte, wer sie genehmigt, wer sie umgesetzt und wer sie letztlich in das Produktivsystem eingespielt hat. Ein wesentlicher Vorteil dieser Transparenz ist, dass all diese Informationen jederzeit an einer zentralen Stelle, dem SAP Solution Manager, zur Verfgung stehen und aufgerufen werden knnen.SAP Solution ManagerService DeskServiceDeskMitarbeiter Feedback Incident (Problem) Anforderer


Entwickler

nderungsantrag nderungsvorgang

Change Manager

PRDKontrollierbare Transporte

Tester

QASKontrollierbare Transporte

IT Operator

DEV

Abbildung 8.12 bersicht ber den Standardprozess des Change Request Management

Ein kurzes Beispiel (siehe Abbildung 8.12) fr einen typischen nderungsvorgang mit Change Request Management soll die Vorgehensweise 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 erfassen, in der er den Sachverhalt beschreibt, und eine nderung anfordern. Die Meldung erscheint daraufhin im Arbeitsvorrat eines Service-

Beispielszenario

311

8


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 dafr verantwortlich, den Antrag zu bewerten, ihn zu kategorisieren und zu genehmigen oder gegebenenfalls abzulehnen. Genehmigt er den Antrag, wird ein nderungsvorgang (Change Transaction) erzeugt. Der nderungsvorgang bildet in den folgenden Arbeitsschritten die operative Grundlage fr Entwickler, Tester und ITAdministratoren. Der Change Manager greift nach erfolgreichem Ablauf der im Folgenden beschriebenen Prozesse wieder ein und schliet 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 Management mit dem Change Request Management

Mit den Funktionen des Change Request Management knnen Sie Releases und Projekte in verschiedener Art und Weise verwalten. Innerhalb eines Projekts knnen alle nderungen, die innerhalb eines bestimmten Zeitraums realisiert werden sollen, geplant und kontrolliert umgesetzt werden. Auch nderungen, die auerhalb eines Projektplans auftreten und eine schnelle Lsung erfordern (sogenannte dringende nderungen), z. B. wenn ein Fehler auftritt, der eine Produktivumgebung gefhrdet, knnen hier wohldokumentiert und effizient behoben werden. Eine andere Mglichkeit, Releases mit dem Change Request Management zu verwalten, ist die Integration mit cProjects, dem Projektplanungswerkzeug der SAP. Alle nderungen, die im Rahmen eines Projekts realisiert werden sollen, knnen in einem Projektplan in cProjects erfasst und geplant werden. Eine Ressourcenplanung ist ebenso verfgbar wie die Anbindung an das Backend, z. B. CATS (Cross-Application Time Sheet) zur Rckmeldung von Aufgaben. nderungsantrge, die das Genehmigungsverfahren durchlaufen haben, knnen hier eingeplant werden. Dieser Projektplan ist mit dem SAPSolution-Manager-Projekt, das in einem sogenannten Projektzyklus mehrere Projektphasen durchluft, 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 knnen.

Projektplan

312


8.2

Der SAP Solution Manager schliet hier eine Lcke, die sich in vielen Change-Management-Lsungen ergibt: Wenn Change-ManagementProzesse z. B. ber Datenbanken oder Listen abgebildet und hier alle nderungsantrge und deren Genehmigungen protokolliert werden, ist sptestens dann ein manueller Schritt notwendig, wenn ein Transportauftrag erzeugt oder eingespielt werden muss. Die Nummer des Transportauftrags muss manuell in die Datenbank bertragen werden, was eine potenzielle Fehlerquelle darstellt. Ein Tippfehler oder ein Fehler beim Kopieren entwertet den gesamten Prozess. Im Change Request Management werden Transportauftrge zentral aus dem SAP Solution Manager heraus erzeugt, und bei der Erzeugung wird immer automatisch eine Referenz zum jeweiligen nderungsantrag angelegt (darber hinaus werden auch dessen ID und Kurztext in die Bezeichnung des Transportauftrags aufgenommen), sodass eine klare Zuordnung jederzeit mglich ist. Das Change Request Management bietet darber hinaus die Mglichkeit, alle Transporte im Rahmen eines Projekts nachzuverfolgen und zu kontrollieren, in welchen Systemen sie erzeugt und in welche Systeme sie eingespielt wurden. ber den SAP Solution Manager knnen Sie zentral in die Transportprotokolle und die Importqueue, aber auch in das Wartungsprojekt des SAP Solution Manager, den Projektplan und die angeschlossenen Systeme navigieren. Jeder nderungsvorgang bietet eine bersicht aller Transporte und Transportaufgaben, die darber erstellt wurden. Von dort kann jederzeit der Status der Transporte berwacht werden und ein direkter Absprung in die Log-Datei erfolgen. Auch nderungen, die keinen Transportanschluss erfordern, knnen ber das Change Request Management erfasst werden. Hier wird, wie bei allen nderungen, ein nderungsantrag gestellt, der alle Genehmigungsschritte durchluft. Im nderungsantrag selbst werden die Schritte dokumentiert, die zur Realisierung ntig sind. Der SAP Solution Manager strkt somit SAP in ihrer Vision des Application Management und der IT-Governance, indem er Funktionen zur Verfgung stellt, die unabdingbar sind, um eine transparente Implementierung und Betriebsfhrung einer Lsung zu garantieren. Dies bildet die Grundlage vieler regulatorischer Bestimmungen; z. B. die Fragen, wer was wann getan und wer kontrolliert und die Genehmigung erteilt hat, lassen sich so beantworten. Um den Betrieb einer Systemlandschaft unter sich stndig ndernden Anforderungen garantieren zu knnen, mssen folgende Gesichtspunkte bercksichtigt werden:

Integration des Change Request Management mit dem Transportwesen

nderungen mit und ohne Transportanschluss

313

8


nderungsantrge, ob sie aus Fehlermeldungen resultieren oder im Rahmen eines Ideenmanagements direkt erzeugt werden, mssen von einer zentralen Stelle klassifiziert und genehmigt werden. Ist ein solcher Antrag genehmigt, mssen die Durchfhrung der nderung, deren Transport in Folgesysteme (Qualittssicherung und Produktion) und ihr Test sichergestellt sein. Eine lckenlose Dokumentation beinhaltet darber hinaus alle fr die nderung relevanten Informationen sowie Daten ber alle beteiligten Personen. Darber 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 Fachabteilung und IT-Administratoren sicherzustellen. Alle an einer nderung beteiligten Personen haben jederzeit Zugriff auf alle relevanten Informationen, wie z. B. Anforderungen, Spezifikationen, Dokumentation, Testflle, Testergebnisse oder Statusanalysen, die anhand der Geschftsprozesshierarchie im SAP Solution Manager gegliedert und zentral verfgbar sind. 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 Durchfhrung von nderungen mit minimalem Risiko. Das Change Request Management umfasst die Prozesse Verwaltung von nderungsantrgen, Projektmanagement und nderungslogistik. Darber hinaus ermglicht das Change Request Management Ihrem Unternehmen, diese Prozesse auf einfache Art und Weise einzusetzen, indem es vordefinierte Prozesse bietet. Zustzlich untersttzt es Sie dabei, den Ansprchen von Audit-Anforderungen wie z. B. von SOX (Sarbanes-Oxley Act) zu gengen, indem alle Nutzer gezwungen werden, Softwarenderungen ber die definierten Change-Management-Prozesse zentral ber den SAP Solution Manager durchzufhren.

Konformitt mit IT-Standards

Einsatzbereit out of the Box

Ein groer Vorteil des Change Request Management sind, wie bereits erwhnt, die Standardprozesse und Funktionen, die mit ausgeliefert werden und so schnell eingesetzt werden knnen.

314


8.2

Der SAP Solution Manager wird mit vorkonfigurierten Arbeitsablufen fr den nderungsantrag und die nderungsausfhrung (nderungsvorgnge) ausgeliefert. Diese Arbeitsablufe basieren auf den Erfahrungen, die SAP auf dem Gebiet des Change Management und der Transportverwaltung gewonnen hat und die durch viele Kundenprojekte mit beeinflusst wurden. Die folgenden nderungstypen sind vorausgeprgt: Normale nderung Als normale nderungen werden Antrge wie z. B. das Einspielen von Support Packages oder von Hinweisen klassifiziert, also Ttigkeiten, die im Rahmen der regulren Systemwartung anfallen. Fehlerkorrektur Eine Fehlerkorrektur dient dazu, Fehler, die whrend der Testphase auftreten, an die Entwicklung zu melden. ber dieses Dokument kann der Entwickler dann spter auch den Fehler beheben, obwohl er in der Testphase keine neuen normalen nderungen anlegen kann. Dringende nderung Eine dringende nderung ermglicht Ihnen, schnell und flexibel zu reagieren, wenn eine Strung den Betrieb Ihrer Lsung gefhrdet. Hier ist es mglich, nderungen ber eine dringende nderung in die produktiven Systeme zu importieren, bevor die normalen nderungen in der Produktivstart-Phase des Wartungszyklus eingespielt werden. Administrative nderung Eine administrative nderung betrifft nderungen, die keinen Transportanschluss erfordern, also z. B. nderungen an Nummernkreisen. Allgemeine nderung Eine allgemeine nderung betrifft nderungen, die keinen Transportanschluss erfordern und darber hinaus nichts mit einem SAP- oder IT-System zu tun haben, also z. B. nderungen an ITKomponenten wie Druckern oder mobilen Gerten. Um einen schnellen und reibungslosen Start mit dem Change Request Management zu ermglichen, liefert SAP ebenfalls eine Reihe vordefinierter Rollen und Genehmigungsprofile aus. Diese Rollen und Prozesse knnen initial genutzt werden, um einen MachRollen und Genehmigungsprofile

315

8


barkeitsnachweis mit dem Change Request Management zu erstellen, und spter als Grundlage dazu dienen, das Change Request Management an die individuellen Bedrfnisse oder Change-ManagementProzesse Ihres Unternehmens anzupassen.

8.2.2

Architektur

Um die Architektur des Change Request Management im SAP Solution Manager zu verstehen, ist es zunchst wichtig, die Zusammenhnge zwischen den verwendeten Entitten zu klren.SAP-SolutionManager-Projekt

Die Grundlage des Change Request Management ist das SAP-Solution-Manager-Projekt (siehe Abschnitt 8.1.1). Das Projekt enthlt folgende Informationen: Logische Komponenten Eine logische Komponente beinhaltet alle Systeme, die ein Produktivsystem (bzw. einen produktiven Mandanten) versorgen. Die zugeordneten Systeme sind in der Regel ber Transportwege miteinander verbunden. IMG-Projekt Das IMG-Projekt wird aus der Projektverwaltung des SAP Solution Manager (Transaktion SOLAR_PROJECT_ADMIN) in verwalteten Systemen angelegt, um Einstellungen, die ber den SAP-Einfhrungsleitfaden (IMG) fr ein SAP-Solution-Manager-Projekt vorgenommen werden, in einem System zu bndeln. CTS-Projekt Das CTS-Projekt stellt einen Container in einem logischen System (Kombination System und Mandant) dar, der Transportauftrge zusammenfasst, die zu einem IMG-Projekt gehren. Das Change Request Management untersttzt die Projektarten Implementierungs-, Upgrade-, Vorlagen- und Wartungsprojekt. In Abhngigkeit davon, welchen Typ von nderungsvorgang der Change Manager im nderungsantrag vor der Genehmigung zuweist, knnen Sie dem nderungsantrag zwei Arten von Projekten bzw. Change-Request-Management-Zyklen (Projektzyklus und Wartungszyklus) zuweisen, die sich aufgrund der unterschiedlichen Anforderungen im Ablauf unterscheiden und daher in Abschnitt 8.2.3 nher beleuchtet werden.

316


8.2

Der Aufgabenplan (Task List) im Change Request Management stellt Systemadministratoren eine bersicht ber erfolgte und eingeplante Aktionen zur Verfgung. Alle Systeme und die notwendigen Aufgaben sind hier zusammengefasst und werden in der korrekten Abfolge angezeigt. Alle Aufgaben, die Sie ber die Benutzeroberflche der Korrekturen oder des Projektzyklus im SAP Solution Manager ber Aktionen ausfhren (Systemanmeldung, Transportauftrag anlegen, Transportauftrag importieren etc.), sind ebenfalls hier hinterlegt. Mehr Informationen zum Aufgabenplan finden Sie in Abschnitt 8.3.1, Unterabschnitt Zentrales Transportmanagement.

Aufgabenplan

8.2.3

Projektzyklus und Wartungszyklus

Mehrfach wurde bereits von Implementierungs- und Wartungsprojekten gesprochen. Dieser Abschnitt soll die Konzepte und Unterschiede zwischen den beiden Projekttypen nher erlutern. Zur Untersttzung von Implementierungs-, Upgrade- und Vorlagenprojekten ber das Change Request Management bietet der SAP Solution Manager den Projektzyklus an.Projektzyklus

SAP-Solution-Manager-Projekt (Wartungsprojekt)

Entwicklung ohne Freigabe

Entwicklung mit Freigabe

TestWartungszyklus

Vorbereitung fr Go-Live

Go-Live

Normale nderung Fehlerkorrektur Dringende nderung Administrative nderung

Abbildung 8.13 Wartungsprojekt mit Zyklus und mglichen nderungsvorgngen

317

8


Der Projektzyklus (dargestellt in Abbildung 8.13) ist ein vorkonfigurierter Servicevorgang (Vorgangsart SMDV), mit dem Sie ber die Projektlaufzeit folgende Ttigkeiten steuern: nderungsantrge und die daraus resultierenden nderungen in den Systemen, die in Ihrem Projekt verwendet werden die Transportauftrge, die bentigt werden, um die nderungen in die Folgesysteme zu transportieren die komplette nderungslogistik, d. h., wann welche Transporte in die Folgesysteme importiert werden knnenPhasen des Projektzyklus

Der Projektzyklus bietet anhand seiner Phasenstruktur eine operative Ergnzung zum Projektplan. Ein einzelner Projektzyklus umfasst folgende Phasen: Entwicklung ohne Freigabe Entwicklung mit Freigabe Test Vorbereitung fr Produktivstart Produktivstart Nach dem Produktivstart schlieen Sie den Projektzyklus ab. Ein Sonderfall des Projektzyklus ist der Wartungszyklus, bei dem ein mehrmaliges Durchlaufen der Phasen mglich 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 gesehen werden. Bei Einsatz der normalen nderung (Vorgangsart SMMJ) ist die Verwendung dieser Phase fr die Entwicklung nicht empfehlenswert, da die Erzeugung von Testtransporten in dieser Phase nicht mglich ist. Die Freigabe von Transportauftrgen 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 fr Funktionstests in die Testumgebung zu importieren. Nachdem die nderungen des Projekts in die Testumgebung eingespielt wurden, kann die Test-Phase erffnet werden, um den Integrationstest zu ermglichen. Nun knnen keine neuen nderungsantrge fr dieses Projekt angelegt werden, es werden nur noch Fehler beseitigt, die im

318


8.2

Test aufgetreten sind. Die Phase Vorbereitung fr Produktivstart erlaubt es Benutzern mit entsprechender Berechtigung, weitere notwendige nderungen durchzufhren, bevor die nderungen in der Produktivstart-Phase in die produktive Umgebung importiert werden. Es knnen jedoch keine nderungen importiert werden, die nicht den Status Erfolgreich getestet erreicht haben. Dem Lebenszyklusmodell folgend, verwenden Sie zur Einfhrung einer Lsung ein Einfhrungsprojekt im SAP Solution Manager. Das Einfhrungsprojekt wird erfolgreich abgeschlossen und in den Betrieb berfhrt. Dazu bernehmen Sie die Daten des Projekts in eine Lsung (siehe Abschnitt 8.1.1). Um diese Lsung 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 kontinuierlicher Prozess die einzelnen Phasen des Wartungszyklus werden fortlaufend immer wieder durchlaufen. Der Wartungszyklus folgt demselben Phasenmodell wie der Projektzyklus, verfgt jedoch ber einige Besonderheiten. Zum einen existiert fr den Wartungszyklus eine zustzliche Art von nderungsvorgang (dringende nderungen), die es ermglicht, dringende nderungen flexibel durchzufhren (siehe Abschnitt 8.2.5). Zum anderen empfehlen wir fr das Arbeiten mit Wartungszyklen eine andere Herangehensweise, um den Anforderungen, die die Wartung einer Lsung stellt, gerecht zu werden: Wir empfehlen, einer Lsung ein Wartungsprojekt zuzuordnen, das so lange luft, wie die Lsung betrieben wird. Innerhalb des Wartungsprojekts werden alle notwendigen Korrekturen ber Wartungszyklen abgedeckt. Die Dauer eines Wartungszyklus wird vom Change Manager festgelegt, z. B. ein Monat. Whrend dieser Zeit durchluft der Zyklus alle Projektphasen von Entwicklung ohne Freigabe bis Produktivstart. Am Ende der Produktivstart-Phase schlieen Sie den Zyklus ab, der dabei auf offene und nicht abgeschlossene Geschftstransaktionen und Transportauftrge berprft wird. Nicht abgeschlossene Belege werden so beim Anlegen eines neuen Wartungszyklus bernommen.Phasenmodell des Wartungszyklus Unterschiede zwischen Wartungszyklus und Projektzyklus

319

8


Aus technischer Sicht ist es mglich, den Wartungszyklus nicht abzuschlieen, sondern seine Phase auf Entwicklung ohne Freigabe zurckzustellen und denselben Zyklus somit erneut zu durchlaufen. Durch Abschlieen und Neuanlegen des Wartungszyklus wird jedoch ein nachvollziehbareres und bersichtlicheres Reporting ermglicht und gewhrleistet, weshalb wir Ihnen das Abschlieen 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 nderungsantrge bewertet und genehmigt haben. Zehn normale nderungen sind fr den laufenden Wartungszyklus (z. B. Oktober) genehmigt worden. In der Entwicklungsphase stellt sich heraus, dass eine der normalen nderungen, nderung Nummer 9, nicht in der fr die Phase anberaumten Zeit realisiert werden kann. Als Projektleiter stehen Ihnen zwei Mglichkeiten offen, mit dieser Verzgerung umzugehen: Zum einen knnen Sie das Zeitfenster fr diese Korrektur vergrern, um sie im laufenden Wartungszyklus zu realisieren. Wenn Sie jedoch feststellen, dass die nderung nicht kritisch ist und keine Abhngigkeiten zu den anderen nderungen bestehen, knnen Sie entscheiden, diese nderung erst im nchsten Wartungszyklus November fertigzustellen. Hierfr verbleibt die nderung im Status In Entwicklung. Die neun anderen nderungen durchlaufen die Test- und Produktivstart-Phasen, werden also in die produktiven Systeme eingespielt. Nun schlieen 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 bearbeitet. Dies stellt einen Unterschied zum Projektzyklus dar. Wenn normale nderungen vorhanden sind, deren Status bei nderung der Wartungszyklusphase von Entwicklung mit Freigabe in der Testphase noch nicht Erfolgreich Getestet lautet, gibt das System nur eine Warnmeldung aus. Diese Korrekturen werden daraufhin vom Integrationstest ausgeschlossen und knnen nicht freigegeben werden. Im Wartungsbetrieb knnen jederzeit Strungsmeldungen auftreten, die eine schnelle Umsetzung erfordern, z. B. wenn ein Ausfall der

320


8.2

produktiven Systeme droht. In diesem Fall knnen Sie mit einer normalen nderung nicht zeitnah reagieren, da diese von der Phase des Wartungszyklus abhngt, d. h., wenn sich der Wartungszyklus in der Testphase befindet, knnen Sie keine neuen nderungen fr diesen Zyklus erfassen. Aus diesem Grund bietet das Change Request Management die dringende nderung an, die in Abschnitt 8.2.5 nher erlutert wird.

8.2.4

nderungsantrag (Request for Change)

Einem Projekt- oder Wartungszyklus knnen generell beliebig viele nderungsantrge zugeordnet werden. Der nderungsantrag (Request for Change, Vorgangsart SMCR, siehe Abbildung 8.14) ist, hnlich wie die Service-Desk-Meldung, ein vorkonfigurierter Servicevorgang, der alle Daten enthlt, die fr 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 zugehrige SAP-Solution-Manager-Projekt Prioritt Auswirkung Dringlichkeit Risiko nderungsumfang Texte, die die Kommunikation sicherstellen (z. B. Beschreibung der nderung, Grund der nderung, Auswirkungen auf Geschftspartner, Auswirkungen auf Systeme etc.) Das Change Request Management bildet somit vom Einholen der Anforderungen ber die Implementierung und das Testen bis zur Betriebsfhrung und kontinuierlichen Verbesserung einer Lsung den kompletten Lebenszyklus ab. Das Szenario ist in die umfassenden Funktionen des SAP Solution Manager wie etwa Incident Management, E-Learning-Management oder Upgrade-Support integriert.

321

8


Abbildung 8.14 Der nderungsantrag (Request for Change) in der neuen WebClient-Oberflche nderungsumfang

Im Zuordnungsblock Umfang des nderungsantrags (siehe Abbildung 8.15) knnen Sie festlegen, welche Art von nderung vorliegt und in welchem System bzw. welcher Komponente diese nderung durchgefhrt werden soll.

Abbildung 8.15 Zuordnungsblock Umfang des nderungsantrags nderungsarten

Abhngig davon, welche nderungskategorie Sie auswhlen, legt das System bei der Freigabe der nderung zur Entwicklung andere Folgevorgnge an. Ein Projektzyklus untersttzt vier nderungsarten,

322


8.2

anhand derer der Change Manager nderungsantrge klassifizieren kann: normale nderung Fehlerkorrektur administrative nderung allgemeine nderung Im Gegensatz zur vorangegangenen Version des Change Request Management ist es nun mglich, verschiedene nderungsarten innerhalb eines nderungsantrags zu kombinieren. Der Change Manager kann hierfr fr jeden neuen nderungsvorgang einen weiteren Eintrag in der Tabelle des Zuordnungsblocks Umfang des nderungsantrags anlegen. Es ist dabei grundstzlich mglich, jede Art von nderung miteinander zu kombinieren. Die zur Verfgung stehenden Systeme oder Komponenten haben auerdem eine Beziehung zum SAP-Solution-Manager-Projekt, das dem Dokument im Zuordnungsblock Details zugewiesen wurde. Nur Komponenten, die Teil der Systemlandschaft dieses Projekts sind, knnen ausgewhlt werden. Eine Ausnahme stellt dabei die allgemeine nderung dar. Da dieser nderungstyp unabhngig von einem SAP- oder ITSystem zu betrachten ist, gibt es keine Abhngigkeit zur auswhlbaren Komponente. Dem nderungsantrag kann ein Genehmigungsvorgang zugewiesen werden, der durchlaufen werden muss, bevor der Antrag den Status Genehmigt erreicht.Genehmigungsvorgnge

Abbildung 8.16 Zuordnungsblock Genehmigung

Bei einem Genehmigungsvorgang handelt es sich um einen Genehmigungsprozess, der aus einer festgelegten Reihe von Genehmigungsschritten besteht (siehe Abbildung 8.16). Fr jeden Genehmigungsvorgang kann im Customizing definiert werden, welche Genehmigungsschritte durchgefhrt werden mssen. Dabei kann

323

8


ausgewhlt werden, welche Schritte parallel ablaufen drfen und welche Schritte voneinander abhngig sind.Geschftspartner zuweisen

Fr jeden Genehmigungsschritt knnen Sie definieren, welche Geschftspartnerrolle fr die Durchfhrung verantwortlich ist. Wenn Sie spter den Genehmigungsvorgang im nderungsantrag auswhlen, mssen Sie jedem Schritt einen konkreten Geschftspartner zuweisen. Jeder Geschftspartner kann dann ber SAP Business Workflow mit einem Workflow-Item oder einer E-Mail benachrichtigt werden, wenn eine Entscheidung von ihm bentigt wird. Zur Durchfhrung der Genehmigung knnen Sie zwischen drei verschiedenen Mglichkeiten auswhlen: Genehmigt, Abgelehnt oder Nicht Relevant. Zustzlich kann zu jedem Genehmigungsschritt bei der Durchfhrung ein Kommentar durch den Genehmiger hinterlegt werden. All diese Informationen werden auch im Protokoll des nderungsantrags mitprotokolliert und lassen sich jederzeit nachvollziehen. Sie knnen beliebig viele Genehmigungsvorgnge im Customizing definieren, die Sie, je nach nderungsart, einem Antrag zuweisen knnen. Daneben ist es auch mglich, mithilfe eines Regelwerks eigene Regeln zu definieren, die z. B. basierend auf Feldwerten automatisch einen bestimmten Genehmigungsvorgang zuweisen (sind z. B. Dringlichkeit und Prioritt der nderung sehr hoch, soll ein anderer Genehmigungsvorgang verwendet werden als bei einer normalen nderung). Im Standard liefert SAP einen einfachen Genehmigungsvorgang aus, der nur aus einem Genehmigungsschritt fr den Change Manager besteht diesen knnen 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 Mitarbeiter des Service Desk oder, im Fall einer neuen Anforderung, ein Mitarbeiter der Fachabteilung. Er beschreibt die notwendige nderung und fgt alle weiteren ntigen Informationen hinzu, z. B. Spezifikationen oder Screenshots. Danach bernimmt der Change Manager das Dokument und ndert den Status des Dokuments von Angelegt in berprfung. In diesem berprfungsschritt vervollstndigt der Change Manager den nderungsantrag mit weiteren

324


8.2

relevanten Informationen und beantwortet dabei unter anderem die folgenden Fragen: Welches System und welcher nderungstyp werden bentigt (Definition des nderungsumfangs)? Welches SAP-Solution-Manager-Projekt soll verwendet werden? Welche Lsung und welcher Geschftsprozess sind betroffen? Welcher Genehmigungsvorgang soll verwendet werden? Wie gro ist das Risiko fr diese nderung? Welche Auswirkungen und Dringlichkeit hat die nderung, und wie ist sie zu priorisieren? In Abbildung 8.17 ist der Prozess eines nderungsantrags schematisch dargestellt.Anforderer nderungsantrag anlegen Change Manager Antrag validieren Systemdetails etc. hinzufgen 1 n Genehmiger nderungsantrag genehmigen Change Manager bergabe zur Entwicklung Umfangserweiterung

Benachrichtigung via Workflow

Neues nderungsdokument

Abbildung 8.17 bersicht ber den Prozess eines nderungsantrags

Wenn alle diese Fragen beantwortet und die Informationen gesammelt und in den Antrag eingetragen wurden, bergibt der Change Manager den Antrag zur Genehmigung. Nun startet der zugewiesene Genehmigungsvorgang. Darber hinaus hat der Change Manager die Mglichkeit, 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 definierten nderungsvorgnge angelegt, und der Status des Antrags wird auf Laufende Implementierung gendert.

Genehmigungsvorgang

325

8


Wenn alle zugewiesenen nderungsvorgnge 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 berprfen, bevor er den Status nach Rcksprache mit dem Anforderer auf Besttigt setzt.Umfangserweiterung

Eine weitere Neuerung im Prozess des nderungsantrags mit dem neuen SAP Solution Manager ist die Mglichkeit, den Umfang der nderung whrend der Implementierung zu erweitern. Mit der Aktion Umfang erweitern ist es mglich, den definierten Umfang eines nderungsantrags zu erweitern und weitere nderungsvorgnge hinzuzufgen. Somit verlieren Sie auch dann nicht den berblick ber alle zusammenhngenden nderungen, wenn diese erst nachtrglich hinzugefgt 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 vorgestellt wurden. Dieser Abschnitt befasst sich nher mit den einzelnen nderungstypen und beschreibt den Anwendungsfall, den Prozess sowie Besonderheiten der verschiedenen nderungstypen nher. Normale nderungStatusschema

Die normale nderung (Vorgangsart SMMJ) bildet die Korrekturoder nderungsmanahmen eines Projekts ab und folgt dem Statusschema: Angelegt In Entwicklung Zu testen Erfolgreich getestet Importiert in Produktion Zurckgezogen Im Folgenden wird der Prozess, den eine normale nderung durchluft, im Detail erlutert.

Prozessbeschreibung

Ein Anwender entdeckt beim Arbeiten in einem System fehlende Funktionen. Er kann diese Strung direkt aus der Transaktion, in der

326


8.2

er sich befindet, ber eine Service-Desk-Meldung an den SAP Solution 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 werden kann, und legt im Incident Management ber die Aktion Folgevorgang anlegen einen entsprechenden nderungsantrag an. Der nderungsantrag erscheint im Arbeitsvorrat des Change Managers, der eine Klassifizierung des nderungsantrags durchfhrt, festlegt, wie die nderung durchgefhrt werden soll (normale nderung), und sie genehmigt oder ablehnt. Bei der Bewertung spielt die Prioritt des nderungsantrags eine wichtige Rolle. Details zum Ablauf des Prozesses fr 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 freigegeben wird. Der nderungsantrag und der nderungsvorgang sind ber den Dokumentenfluss verbunden, und die Zuordnung ist somit jederzeit transparent. Der nderungsvorgang bildet die operative Grundlage fr Entwickler, Tester und Systemadministratoren ab. Zunchst wird der Entwickler 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 Transportaufgaben 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. Anschlieend erfolgt der Test der Neuentwicklung durch den Entwickler. Verluft dieser Test erfolgreich, setzt der Entwickler 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 whrend eines regulren Imports des Projektpuffers durch

327

8


einen (im verwalteten System) eingeplanten Job in ein Testsystem importiert und dort zunchst einem erneuten Funktionstest unterzogen. Dem Tester stehen alle bentigten Funktionen, wie z. B. Systemanmeldung, aber auch alle Informationen zum nderungsvorgang, also die komplette nderungshistorie, zentral zur Verfgung. Das Change Request Management bietet ein Vier-Augen-Prinzip an, d. h., Sie knnen einstellen, dass der Entwickler und der Tester nicht dieselbe Person sein drfen. 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 Ttigkeiten knnen direkt aus dem nderungsvorgang ber Aktionen ausgefhrt werden. Mit diesem Schritt endet die normale nderung, sie enthlt ab diesem Zeitpunkt nur noch beschreibende Statuswerte, wird aber aus technischer Sicht an den Projektzyklus bergeben und von diesem vorangetrieben.Einspielen der nderungen

Zum Einspielen der nderungen in die produktiven Systeme mssen Sie folgende Voraussetzungen beachten: Der Systemadministrator kann die nderung nur in das Produktivsystem importieren, wenn sich der entsprechende Projektzyklus in der Phase Produktivstart befindet. Der Status kann nur auf Importiert in Produktion gesetzt werden, wenn alle normalen nderungen des Projekts erfolgreich in die produktiven Systeme importiert wurden. Sie knnen diesen Status fr 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, lsen im betreffenden Projektzyklus eine Warnmeldung aus, wenn der Status whrend der Testphase gesetzt wird.

Dringende nderung Dringende nderungen (Vorgangsart SMHF) verfgen ber einen eigenen Aufgabenplan, d. h., sie knnen unabhngig von der Phase des zugeordneten Wartungszyklus transportiert werden. So ist es

328


8.2

mglich, nderungen ber eine dringende nderung in die produktiven Systeme zu importieren, bevor die normalen nderungen in der Produktivstart-Phase des Wartungszyklus eingespielt werden. Dringende nderungen knnen auch nur im Zusammenhang mit einem Wartungsprojekt angelegt werden und stehen fr Implementierungsprojekte nicht zur Verfgung. Hierzu wird die Transportmethode IMPORT_SUBSET verwendet, d. h., die Transportauftrge, 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 regulren Import ber den Aufgabenplan des Wartungszyklus 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. Die dringende nderung hat folgendes Statusschema: Angelegt In Entwicklung Zu testen Erfolgreich getestet Freigegeben fr Produktion Importiert in Produktion Besttigt Abgeschlossen Zurckgezogen In der ausgelieferten Version importiert der SAP Solution Manager die Transportauftrge einer dringenden nderung automatisch in das Testsystem, wenn Sie den Status Zu testen setzen. Diese Einstellung wurde vorgenommen, um den Prozess weiter zu beschleunigen, Sie knnen diese Einstellung jedoch ber das Customizing ndern.Transportsteuerung

Statusschema

Administrative nderung Eine administrative nderung (Vorgangsart SMAD) dient dazu, nderungen an Systemen abzubilden, die keine Transporte erfordern, wie

329

8


z. B. nderungen an Nummernkreisen oder Benutzerdaten, hierbei aber dennoch die komplette nderungshistorie zu bewahren. Die administrative nd

Documents

Sappress Sap Solution Manager