Sie sind auf Seite 1von 85

Marc O. Schäfer, Matthias Melich

SAP Solution Manager

®

Marc O. Schäfer, Matthias Melich SAP Solution Manager ® Bonn Boston
Marc O. Schäfer, Matthias Melich SAP Solution Manager ® Bonn Boston

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

19

Geleitwort 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

33

1.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 38

1.4.3 Offenheit: SAP Solution Manager für

Nicht-SAP-Software

39

1.5 Höhere Benutzerfreundlichkeit

45

1.5.1 Den Überblick behalten mit Management Dashboards

45

1.5.2 End-to-End-Monitoring und Alerting

48

1.5.3 CRM-Benutzeroberfläche SAP Web Client und Work Center

49

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

63

2.2.1 Requirements-Phase

63

2.2.2 Design-Phase

66

2.2.3 Build-Phase

67

2.2.4 Test-Phase

69

Inhalt

 

2.2.5

Deploy-Phase

74

 

2.3

Realisierung von Anforderungen über

 

die Wartung (Minor Release)

75

3

Effektiver und effizienter Betrieb

79

 

3.1 Operations Control Center

80

3.2 Proaktives Monitoring und das Arbeiten mit dem Alert-Eingang

82

3.3 Technische Administration

86

3.4 Betrieb von Geschäftsprozessen am Beispiel »Überwachen des Tagesabschlusses«

87

3.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

97

 

4.1.1 Landschaftsdaten, Werkzeuge zur

 

Verwaltung und Prozesse zur Nutzung

99

 

4.1.2 Handhabung von Landschaftsdaten

104

4.1.3 Topologie der Werkzeuge zur Verwaltung von Landschaftsdaten

117

 

4.2 Assistent zur Lösungsdokumentation

118

 

4.2.1 Dokumentation der Systemlandschaft

119

4.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

127

4.4 Initialer Aufbau einer Business-Blueprint-Struktur mit der Excel-Upload-Schnittstelle

129

4.5 Dokumentation der Lösung

131

4.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

144

5.1.1 Aufbau

144

5.1.2 Inhalte

146

5.1.3 Produktabhängigkeit

148

5.1.4 Ausblick

148

5.2 ASAP-Implementierungsmethode

149

5.2.1 Umfang und Nutzen

149

5.2.2 Roadmap-Phasen

150

5.2.3 Struktur der ASAP-Methode

152

5.2.4 Business Add-ons zur ASAP-Methode

153

5.2.5 Arbeiten mit der Run-SAP- und der

ASAP-Implementierungs-Roadmap

153

5.3 Projektverwaltung als Eckpfeiler der Projektvorbereitung

156

5.3.1 Projektverwaltung

156

5.3.2 Anlegen eines Einführungsprojekts

157

5.3.3 Festlegen des Projektumfangs und der Vorgehensweise

157

5.3.4 Verwalten von Projektmitarbeitern

158

5.3.5 Festlegen der Systemlandschaft

160

5.3.6 Festlegen der projektspezifischen Meilensteine

161

5.3.7 Hinterlegen von Organisationseinheiten

161

5.3.8 Festlegen der Projektstandards

162

5.4 Business Blueprint – Soll-Konzept für Ihre Lösung

164

5.4.1 Aufbau des Business Blueprint

164

5.4.2 Dokumentation des Soll-Konzepts

170

5.4.3 Verantwortliche definieren

172

5.4.4 Abschluss des Business Blueprint

173

5.5 Konfiguration der Lösung

174

5.5.1 Voraussetzungen der Konfiguration

175

5.5.2 Grundsätze der Konfiguration

176

5.5.3 Realisierung von Eigenentwicklungen

179

5.5.4 Arbeiten mit Servicemeldungen

180

5.6 Testmanagement

182

5.7 E-Learning-Management – effizienter Wissenstransfer im Projekt

182

9

Inhalt

5.7.1 Erstellung von Lernmaterialien

183

5.7.2 SAP Productivity Pak by ANCILE Adapter for SAP Solution Manager

184

5.7.3 Organisieren und Verteilen von Lerninhalten

185

5.8 Reporting für Ihr Einführungsprojekt

188

5.8.1 Reporting Roadmap

188

5.8.2 Reporting – Business Blueprint

188

5.8.3 Reporting – Konfiguration

191

5.8.4 Reporting – Lernmaterialien

194

5.8.5 Reporting – Test

196

5.8.6 Reporting – Systemlandschaft

196

5.8.7 Reporting – Historie

196

5.9 SAP Solution Manager bei der HARTMANN GRUPPE

197

6 Vorlagenmanagement

203

6.1 Anwendungsbereiche für Vorlagen

203

6.1.1 Die unternehmensweite Prozessbibliothek

204

6.1.2 Konzern-Roll-out

204

6.2 Vorlagenmanagement im Detail

207

6.2.1 Vorlagenmanagement im Kontext des Application Lifecycle Management

207

6.2.2 Methodische Unterstützung durch die Global ASAP Template Roadmap

209

6.2.3 Anlegen von Vorlagen

210

6.2.4 Business-Blueprint-Definition und Konfigurationsstruktur

212

6.2.5 Freigabe und Implementierung von

Vorlagen

213

6.2.6 Tipps & Tricks für die Arbeit mit Vorlagen

214

6.3 Vorlagenverwaltung und Lebenszyklus

217

6.3.1 Vergleich und Abgleich von Änderungen

217

6.3.2 Übernahme von Vorlagenänderungen

(Roll-out)

221

6.3.3 Rückführung lokaler Änderungen in

die Vorlage (Roll-in)

223

6.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

234

7.2.1 Testoption 1

235

7.2.2 Testoption 2

235

7.2.3 Testoption 3

236

7.2.4 Ergänzende Produkte

236

7.3 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 für SAP Support Packages oder SAP Enhancement Packages

241

7.3.5 Vorbereitende Schritte

245

7.3.6 Vorteile für den Kunden

250

7.4 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

7.5 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 Testplänen

273

7.5.4 Testfälle mit SAP Test Acceleration and Optimization erstellen

275

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

282

7.6.1 Ein automatisierter, integrierter, standardisierter Ansatz

283

7.6.2 Anlegen von Business Blueprints und Anforderungsmanagement

283

7.6.3 Änderungseinfluss-Analyse

284

7.6.4 Testplanung

284

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

296

8.1.1 Work Center »Change Management«

297

8.1.2 Zentrale Transportverwaltung mit

Quality Gate Management

303

8.1.3 SAP Best Practices im Bereich Transport

307

8.2 Change Request Management

308

8.2.1 Change Request Management im Detail

310

8.2.2 Architektur

316

8.2.3 Projektzyklus und Wartungszyklus

317

8.2.4 Änderungsantrag (Request for Change)

321

8.2.5 Änderungstypen im Change Request Management im Detail

326

8.2.6 Änderungsverwaltung mit dem Change Request Management

332

8.2.7 Zentrale Änderungskontrolle

334

8.2.8 Transparenz über Änderungsprozesse

340

8.2.9 Integration des Change Request Manage-ment mit den anderen Application-Lifecycle-Management-Funktionen

344

12

Inhalt

8.3 Transportverwaltung

348

8.3.1 SAP-Änderungs- und

Transportsystem (CTS)

348

8.3.2 Synchronisation von Entwicklungssystemen

360

8.3.3 SAP Transport Execution Analysis Service

363

8.4 Änderungsdiagnose

365

8.4.1 Änderungen verfolgen

365

8.4.2 Änderungsauswertungen

366

8.4.3 Durchgängige Änderungsanalyse

367

8.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

381

9.1.1 IT-Servicemanagement nach ITIL

382

9.1.2 SAP-IT-Servicemanagement (SAP ITSM)

384

9.1.3 Integrationskonzept

385

9.1.4 Anwendungsszenarien

388

9.1.5 Der zentrale Incident- und Problem-Management-Prozess

398

9.1.6 Stammdaten

405

9.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

416

9.4 Incident Management für Softwarepartner

423

9.5 SAP Solution Manager bei Ferrero Deutschland MSC GmbH & Co. KG

428

9.6 SAP Solution Manager bei der itelligence AG

436

10 Technischer Betrieb

443

10.1

Technisches Monitoring

447

10.1.1 Alert-Eingang

448

10.1.2 System-Monitoring

453

10.1.3 Verbindungs-Monitoring

456

13

Inhalt

10.2 Zentrale Überwachung von SAP NetWeaver Process Integration

458

10.2.1 Einstieg und Navigation

461

10.2.2 Overview Monitor

462

10.2.3 Component Monitor

464

10.2.4 Channel Monitor

465

10.2.5 Message Monitor

466

10.2.6 Zentrale inhaltsbasierte Nachrichtensuche

471

10.2.7 Anbindung an die Alert-Infrastruktur

473

10.2.8 Anbindung an den Service Desk

473

10.3 End-User-Experience-Monitoring

474

10.4 End-to-End-Root-Cause-Analysis

481

10.4.1 Vorgehensweise zur Root Cause Analysis

483

10.4.2 Architektur

485

10.4.3 Werkzeuge in der Root Cause Analysis

487

10.4.4 Root Cause Analysis im Detail

489

10.4.5 Qualitätssicherung mit Werkzeugen der Root Cause Analysis

499

10.5 Technische Administration

501

10.5.1 Work Mode Management

502

10.5.2 IT-Kalender

511

10.5.3 Benachrichtigungsverwaltung

512

10.5.4 Zentrale Systemadministration

513

10.6 Technische Analyse

524

10.6.1 Technische Auswertungen

524

10.6.2 Management-Auswertungen

539

10.7 Datenvolumenmanagement

543

10.7.1 Positionsbestimmung

543

10.7.2 Analyse der Datenverteilung

544

10.7.3 Priorisieren von Objekten

549

10.7.4 Priorisieren nach Speicherverbrauch

550

10.7.5 Priorisieren nach Altersstruktur der Daten

552

10.7.6 Priorisieren nach Nutzungshäufigkeit

553

10.7.7 Auswertung der Daten

556

10.7.8 Diskussionen mit den Fachbereichen

558

10.7.9 Projekt-Reporting

561

14

Inhalt

11 Betrieb von Geschäftsprozessen

565

11.1 Geschäftsprozess- und Schnittstellenüberwachung

566

11.1.1 Werkzeuge, die den Betrieb der Geschäftsprozesse unterstützen

566

11.1.2 Geschäftprozessüberwachung im SAP Solution Manager

569

11.1.3 Handhabung der Geschäftsprozessüber-wachung im SAP Solution Manager

571

11.1.4 Geschäftsprozesse mit der Anwendung Geschäftsprozess-Analyse (Business Process Analytics) verbessern

573

11.2 Jobverwaltung

576

11.2.1 Herausforderungen in der Jobverwaltung

577

11.2.2 Fallbeispiel eines Jobverwaltungsprozesses im Sinne des SAP-Standards

580

11.2.3 Automatische Umleitung eines Endanwenders vom Backend-Systemin das Antragsformular des SAP Solution Manager

588

11.2.4 Job Scheduling Management Health Check 589

11.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

599

11.4.1 Performanceoptimierung von Geschäftsprozessen

600

11.4.2 Performanceoptimierung mit

Self-Services der SAP

605

11.5 SAP Solution Manager bei der Bayer MaterialScience

609

12 Wartung einer SAP-Lösungslandschaft

615

12.1

Der Maintenance Optimizer

616

12.1.1 Der Maintenance Optimizer im Detail

618

12.1.2 Maintenance Optimizer für SAP ERP

623

12.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 628

12.2

Systemempfehlungen

630

12.2.1 Empfehlungen für Ihre Systeme erhalten

631

12.2.2 Integration mit anderen Werkzeugen im

SAP Solution Manager

632

12.2.3 Einrichtung der Funktion »Systemempfehlungen«

632

13 Unterstützung von Upgrade-Projekten

633

13.1 Upgrade Dependency Analyzer

635

13.1.1 Mögliche Abhängigkeitsaussagen

637

13.1.2 Abgrenzung des UDA zum Maintenance

Optimizer und den Szenarien- und Prozess-komponentenlisten (PCL/SCL)

640

13.1.3 Datenqualität und Haftungsausschluss

641

13.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

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

655

14.1 Der Greenfield-Ansatz

659

14.2 Das Vorgehen bei SAP-Transformationen

659

14.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

664

 

14.4.1 Transformationslösungen für Verkaufs-, Kauf- und Umstrukturierungsvorhaben

664

14.4.2 Vereinheitlichung und Transformation von Daten

669

14.4.3 Konsolidierung von Systemen und Reduzierung der IT-Kosten

675

14.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

682

14.5.4 Kombinieren von Transformationslösungen

683

14.5.5 Projekte durchführen

684

14.5.6 Analysen ausführen

685

14.5.7 Transformationsapplikationen ausführen

686

14.5.8 Wichtige Hinweise und Empfehlungen zur technischen Durchführung

687

14.6 Ergänzende Services zu SAP Landscape Transformation

688

14.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

697

15.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

702

15.2.1 Prozess und Architektur

703

15.2.2 Die Anwendung CCLM im Detail

707

15.2.3 Einstellungen

709

15.2.4 Bibliotheksdefinition

711

15.2.5 Objekte in der Bibliothek

712

15.2.6 Reporting

714

15.3 Custom Development Management Cockpit

716

15.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

733

15.5

Custom Code Lifecycle Management bei Procter & Gamble

734

Anhang

739

A Die Autoren

739

B 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.

Der SAP Solution Manager unterstützt Sie dabei durch eine Vielzahl von Funktionen. Das ITIL-zertifizierte Change Request Management ermöglicht Ihnen die höchste Integration in Ihren Change-Manage- ment-Prozess. Darüber hinaus stellt das Quality Gate Management eine 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

Funktionen des

SAP Solution

Manager

8

Verwaltung der Änderungskontrolle

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.

Zusammenarbeit mit dem Release Management

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.

Das Quality Gate Management unterstützt das Release Management bei 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
Abbildung 8.1 zeigt das Release Management (Minor und Major
Release) und Transport Management, also das Einspielen in Folgesys-
teme, im Überblick.
SAP Solution Manager
Implementierungsprojekt (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

Minor Release

Transportzyklus

3-6 Monate

1-4 Wochen

Änderungskategorien

Alle Arten von Änderungen inklusive invasiver Eingriffe

Fehlerkorrekturen und kleinere Änderungen (inkl. Reimport von Notfallkorrekturen)

Priorität

Normal

Normal

Testumfang

Kompletter Testumfang

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

297

8

Verwaltung der Änderungskontrolle

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

der Sicht Projekte zur Verfü- gung (siehe Abbildung 8.2). Abbildung 8.2 Projektübersicht im Quality-Gate-Kalender

Abbildung 8.2 Projektübersicht im Quality-Gate-Kalender

Vorgehensweise

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.

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

Ein Quality Gate (Q-Gate) ist ein spezieller Meilenstein in einem Pro- Quality Gate 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.

Zusätzlich zu den bestehenden Q-Gates können Sie sogenannte Mei- Meilensteine 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

8

Verwaltung der Änderungskontrolle

Quality-Gate offen

Quality-Gate geschlossen

Build Entwickler
Build
Entwickler
Quality-Gate
Quality-Gate

Quality-Gate-Dokument

Qualitäts-

Quality

manager

Steering

Board

• Resultate

dokumentieren

Empfehlungen

• Dokumentation

des Qualitäts-

hochladen

Managers

• Q-Gate

bestätigen oder

zurückweisen

bewerten

Test Tester
Test
Tester

Administrator

Solution-Manager-Projekt mit Quality Gate Management

Abbildung 8.3 Ablauf des Quality Gate Management

Qualitätsmanager

und 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.

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

Systemen, Q-Gates und Meilensteinen (siehe Abbildung 8.4). Abbildung 8.4 Projektlandschaft nach Abschluss der

Abbildung 8.4 Projektlandschaft nach Abschluss der Konfiguration

Nach dem Sichern der Konfiguration werden die unterschiedlichen Q-Gate-Kalender 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).

die in Form von Checklisten und Dokumenten fixiert sind (siehe Abbildung 8.5). Abbildung 8.5 Q-Gate-Dokumentation 301

Abbildung 8.5 Q-Gate-Dokumentation

301

8

Verwaltung der Änderungskontrolle

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

behalten Sie immer den Überblick (siehe Abbildung 8.6). Log Abbildung 8.6 Informationen zu Q-Gates Mit einem

Log

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

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

Quality Gate Management 8.1 Abbildung 8.7 Projekt mit den Änderungen und den dazugehörigen Transporten 8.1.2 Zentrale

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.

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

Transport-

konfiguration

und -risiken

8

Verwaltung der Änderungskontrolle SAP Solution Manager Change Control Management SAP NetWeaver Portal SAP ECC
Verwaltung der Änderungskontrolle
SAP Solution Manager
Change Control
Management
SAP NetWeaver Portal
SAP ECC
SAP-Solution-
Manager-Projekt
Änderung 1
Transport-
auftrag
Transport-
auftrag
Änderung 2
Transport-
auftrag
Transport-
auftrag
Änderung 3
Transport-
auftrag
Transport-
auftrag
Änderung 3 Transport- auftrag Transport- auftrag Abbildung 8.8 Zentrale Transportverwaltung Abbildung 8.9

Abbildung 8.8 Zentrale Transportverwaltung

auftrag Abbildung 8.8 Zentrale Transportverwaltung Abbildung 8.9 Systemlandschaftsgrafik Die

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

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.

kann er entscheiden, welche Maßnahmen notwendig sind. Abbildung 8.10 Transportrisiken in Lösungslandschaften

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

8

Verwaltung der Änderungskontrolle

offene Transportaufträge, die im Entwicklungssystem auf die Frei- gabe warten

Änderungen

am Projekt

Auf diese Weise kann der Qualitätsmanager mit entsprechenden Aktivitäten kritischen Situationen effektiv entgegenwirken und eine Risikoeinschätzung des Projekts vornehmen.

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) dargestellt werden (siehe Abschnitt 8.2.9). Abbildung 8.11 Übersicht der zu einem Projekt gehörenden

Abbildung 8.11 Übersicht der zu einem Projekt gehörenden Transportaufträge

306

Quality Gate Management

8.1

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.

Transportaufträge

logisch bündeln

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

8

Verwaltung der Änderungskontrolle

Überholer-

problematik

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.

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.

Im 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.

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.

Innerhalb der IT-Organisation werden diese Änderungen oder Releases entweder durch ein Implementierungsprojekt oder durch

309

Änderungsanträge

Major und Minor Releases

Implemen-

tierungs- oder

Wartungsprojekt

8

Verwaltung der Änderungskontrolle

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 erlaubt es 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.

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

Änderungsantrag

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.

Service DeskChange

Request Management

SAP Solution Manager

Feedback Service- Incident Desk- Mitarbeiter
Feedback
Service-
Incident
Desk-
Mitarbeiter
Anforderer (Problem) Änderungs- Change PRD antrag Manager Kontrollierbare Transporte Änderungs- vorgang QAS
Anforderer
(Problem)
Änderungs-
Change
PRD
antrag
Manager
Kontrollierbare Transporte
Änderungs-
vorgang
QAS
Kontrollierbare Transporte
DEV
Änderungs- vorgang QAS Kontrollierbare Transporte DEV   Entwickler   Tester IT Operator
 
 

Entwickler

 
Tester

Tester

IT Operator

IT Operator

Abbildung 8.12 Übersicht über den Standardprozess des Change Request Management

Ein kurzes Beispiel (siehe Abbildung 8.12) für einen typischen Ände- Beispielszenario 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-

311

8

Verwaltung der Änderungskontrolle

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.

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 Projektzyklus mehrere Projektphasen durchläuft, in den SAP Solution Manager integriert. Die Phasen werden zentral aus dem SAP Solution Manager heraus kontrolliert und geben Rahmenbedingungen vor, die nicht umgangen werden können.

Release Manage- ment mit dem Change Request Management

312

Change Request Management

8.2

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.

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.

Integration des

Change Request

Management mit

dem Transport-

wesen

Änderungen mit und ohne Transportanschluss

Um den Betrieb einer Systemlandschaft unter sich ständig ändernden Anforderungen garantieren zu können, müssen folgende Gesichts- punkte berücksichtigt werden:

313

8

Verwaltung der Änderungskontrolle

Ä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.

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.

Konformität mit

IT-Standards

Einsatzbereit out of the Box

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.

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 Einspielen von 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.

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

Rollen und Geneh- migungsprofile

8

Verwaltung der Änderungskontrolle

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.

SAP-Solution-

Manager-Projekt

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.

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

Der 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«.

Aufgabenplan

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.

 

Zur Unterstützung von Implementierungs-, Upgrade- und Vorlagen- projekten über das Change Request Management bietet der SAP Solu- tion Manager den Projektzyklus an.

Projektzyklus

Solu- tion Manager den Projektzyklus an. Projektzyklus SAP-Solution-Manager-Projekt (Wartungsprojekt) Entwicklung
SAP-Solution-Manager-Projekt (Wartungsprojekt) Entwicklung Entwicklung Vorbereitung Test Go-Live ohne Freigabe mit
SAP-Solution-Manager-Projekt (Wartungsprojekt)
Entwicklung
Entwicklung
Vorbereitung
Test
Go-Live
ohne Freigabe
mit Freigabe
für Go-Live
Wartungszyklus
Normale
Änderung
Fehler-
korrektur
Dringende
Änderung
Administrative
Änderung
Abbildung 8.13 Wartungsprojekt mit Zyklus und möglichen Änderungsvorgängen

317

8

Verwaltung der Änderungskontrolle

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 Produktivstart erlaubt 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.

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.

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:

Unterschiede

zwischen

Wartungszyklus

und Projektzyklus

Phasenmodell des

Wartungszyklus

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

8

Verwaltung der Änderungskontrolle

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.5 nä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

8

Verwaltung der Änderungskontrolle

8 Verwaltung der Änderungskontrolle Abbildung 8.14 Der Änderungsantrag (Request for Change) in der neuen Web-

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.

Komponente diese Änderung durchgeführt werden soll. Abbildung 8.15 Zuordnungsblock »Umfang des

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.

Dem Änderungsantrag kann ein Genehmigungsvorgang zugewiesen werden, der durchlaufen werden muss, bevor der Antrag den Status Genehmigt erreicht.

Genehmigungs-

vorgänge

den Status Genehmigt erreicht. Genehmigungs- vorgänge Abbildung 8.16 Zuordnungsblock »Genehmigung« Bei einem

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

8

Verwaltung der Änderungskontrolle

Geschäftspartner

zuweisen

ausgewählt werden, welche Schritte parallel ablaufen dürfen und welche Schritte voneinander abhängig sind.

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

Prozess des

Änderungsantrags

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.

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.

Anforderer Change Manager Änderungsantrag Antrag Systemdetails anlegen validieren etc. hinzufügen
Anforderer
Change Manager
Änderungsantrag
Antrag
Systemdetails
anlegen
validieren
etc. hinzufügen

1 – n GenehmigerAntrag Systemdetails anlegen validieren etc. hinzufügen Änderungsantrag genehmigen Change Manager Übergabe zur

Änderungsantrag genehmigen
Änderungsantrag
genehmigen
Change Manager

Change Manager

Change Manager
Change Manager
Change Manager
Change Manager
Übergabe zur Umfangs- Entwicklung erweiterung
Übergabe zur
Umfangs-
Entwicklung
erweiterung
Benach- richtigung via Workflow
Benach-
richtigung
via
Workflow
Neues Änderungs- dokument
Neues
Änderungs-
dokument

Abbildung 8.17 Übersicht über den Prozess eines Änderungsantrags

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.

Genehmigungs-

vorgang

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.

325

8

Verwaltung der Änderungskontrolle

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-

Eine weitere Neuerung im Prozess des Änderungsantrags mit dem

erweiterung

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-

Ein Anwender entdeckt beim Arbeiten in einem System fehlende

beschreibung

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

8

Verwaltung der Änderungskontrolle

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.

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.

Die dringende Änderung hat folgendes Statusschema:

Angelegt

In Entwicklung

Zu testen

Erfolgreich getestet

Freigegeben für Produktion

Importiert in Produktion

Bestätigt

Abgeschlossen

Zurückgezogen

Transport-

steuerung

Statusschema

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

8

Verwaltung der Änderungskontrolle

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

Fehlerkorrekturen (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:

Nur in Testphase

Angelegt

Statusschema

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

8

Verwaltung der Änderungskontrolle

Unterstützte

Systemland-

schaften und

Technologien

Offenheit

Die System-

landschaft im

Änderungsvorgang

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.

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.

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.

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.

Wie bereits beschrieben, folgt jede Art von Änderungsvorgang einem eigenen und vordefinierten Arbeitsablauf, was es einfach macht, diese Funktionen sofort einzusetzen.

Flexible Arbeits-

abläufe und

Workflows

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.

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«.

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.

Mehrstufige

Kategorisierung

Transport-

verwaltung im

Change Request

Management

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

8

Verwaltung der Änderungskontrolle

8 Verwaltung der Änderungskontrolle Abbildung 8.18 Zuordnungsblock »Transport Management« Über Drucktasten können

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.

Eingebaute

Transport-Best-

Practices

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.

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.

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.

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

Konsistente

Transporte

System-

übergreifende

Objektsperre

8

Verwaltung der Änderungskontrolle

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

in die Produktion gelangen würden (siehe Abbildung 8.19). Abbildung 8.19 Der Wartungszyklus in der neuen

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.

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

Arbeiten mit

Projektzyklen

8

Verwaltung der Änderungskontrolle

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.

Entwicklung

ohne Freigabe

Entwicklung

mit Freigabe

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.

Der Change Manager setzt den Status des Projektzyklus auf Entwicklung ohne 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.

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.

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

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.

In 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

Test

Vorbereitung für

den Go-Live

(Notkorrektur)

Go-Live

8

Verwaltung der Änderungskontrolle

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

Change Request Management 8.2 Abbildung 8.20 Suche nach Änderungsanträgen in der neuen Web-Client- Oberfläche Jede

Abbildung 8.20 Suche nach Änderungsanträgen in der neuen Web-Client- Oberfläche

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.

Gespeicherte

Suche

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

8

Verwaltung der Änderungskontrolle

in welcher Reihenfolge diese angezeigt werden sollen und welche Information ausgeblendet werden soll.

Change-Request-

Management-

Reporting

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.

Die Reporting-Funktionalitäten des Change Request Management kö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.

Erfasste Entitäten

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.

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

SAP-Hinweise

Transportaufträge

Transportobjekte

Change Request Management

8.2

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.

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.

Änderungs-

nachverfolgung

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.

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

Systeme

vergleichen

8

Verwaltung der Änderungskontrolle

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.

ALM-Funktionen IT-Service- Quality Gate System- Projekt- und Test- Job Scheduling management Management
ALM-Funktionen
IT-Service-
Quality Gate
System-
Projekt- und
Test-
Job Scheduling
management
Management
empfehlungen
Lösungsver-
management
Management
zeichnisse
Change Request
Management
Technische Infrastruktur
Transport Management System
Erweitertes Change & Transport System

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.

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.

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

Integration mit

dem IT-Service-

management

8

Verwaltung der Änderungskontrolle

Integration mit

Dokumentation

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.

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.

Check-in/Check-

out-Funktion

Die zugrunde liegenden Dokumente des Projekts oder der Lösung wie Testfallbeschreibungen oder Spezifikationen können im Zuord- nungsblock Dokumente referenziert werden.

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