Change Request Management mit dem SAP Solution Manager · 2018-03-26 · der Change-Request-Management-Funktionalität zu verstehen, ist es daher erforderlich, die verschiedenen Bestandteile

Bonn � Boston

Matthias Friedrich, Torsten Sternberg

Change Request Management mit dem SAP Solution Manager®

1226.book Seite 3 Montag, 2. März 2009 3:48 15

5

Inhalt

Vorwort .................................................................................................. 11

15

1 Einführung ........................................................................... 15

1.1 IT Change Management und Information Technology Infrastructure Library .......................................... 151.1.1 Einordnung des IT Change Managements .................. 161.1.2 Begriffsdefinitionen ................................................... 181.1.3 Aufgaben des IT Change Managements ..................... 201.1.4 Erfolgsfaktoren für IT Change Management ............... 20

1.2 SAP Solution Manager und Information Technology Infrastructure Library ............................................................. 211.2.1 Funktionalitäten des SAP Solution Managers ............ 211.2.2 Unterstützung der ITIL Practices durch den

SAP Solution Manager .............................................. 251.3 Change Request Management mit dem

SAP Solution Manager ........................................................... 291.3.1 Change (Request) Workflows .................................... 291.3.2 Projektverwaltung ..................................................... 301.3.3 Monitoring und Reporting ........................................ 31

1.4 Zusammenfassung ................................................................. 31

33

2 Architektur des Change Request Managements ................ 33

2.1 Bestandteile des Change Request Managements .................... 332.2 Projektverwaltung im SAP Solution Manager ......................... 35

2.2.1 Solution-Manager-Projekte ....................................... 352.2.2 Solution-Manager-Projekte im Change Request

Management ............................................................ 392.2.3 IMG-Projekte und CTS-Projekte ................................ 412.2.4 Projektzyklus und Aufgabenplan ............................... 452.2.5 cProjects ................................................................... 49

2.3 Vorgangsarten/Workflows ..................................................... 512.3.1 Service-Desk-Meldung .............................................. 522.3.2 Änderungsantrag (Change Request) .......................... 542.3.3 Änderungsdokument (Change Document) ................. 582.3.4 Normale Korrektur/Entwicklungstätigkeit .................. 592.3.5 Dringende Korrektur ................................................. 63


Inhalt

6

2.3.6 Administrationsmeldung ........................................... 642.3.7 Testmeldung ............................................................. 652.3.8 Jobantrag/Job Request .............................................. 662.3.9 Änderungsvorgänge für Projekte ............................... 67


69

3 Konfiguration des Change Request Managements ............ 69

3.1 Vorbereitung ......................................................................... 693.1.1 Organisatorische Fragestellungen .............................. 693.1.2 Technische Fragestellungen ....................................... 703.1.3 Voraussetzungen ....................................................... 703.1.4 Verfügbare Dokumentation/Hilfestellung .................. 72

3.2 Konfiguration des Change Request Managements .................. 723.2.1 Standardkonfiguration ............................................... 743.2.2 Erweiterte Konfiguration ........................................... 84

3.3 Definition von Projekten und Systemen im Change Request Management ......................................................................... 1023.3.1 Definition von logischen Komponenten .................... 1023.3.2 Erstellung eines Solution-Manager-Projektes ............. 1073.3.3 Finale Überprüfung der Einstellungen ....................... 109


111

4 Einsatz des Change Request Managements ....................... 111

4.1 Rollen und Aktivitäten ........................................................... 1114.1.1 Anforderer ................................................................ 1124.1.2 Service-Desk-Mitarbeiter .......................................... 1134.1.3 Change Manager ....................................................... 1134.1.4 Change Advisory Board ............................................. 1144.1.5 Entwickler ................................................................. 1144.1.6 Tester ....................................................................... 1154.1.7 IT-Operator .............................................................. 1154.1.8 Zusätzliche Benutzerinformationen ........................... 116

4.2 Prozesse und Integrationsbeispiele ........................................ 1164.2.1 Beispiel der dringenden Korrektur ............................. 1174.2.2 Retrofit-Prozess ........................................................ 1334.2.3 Hot News ................................................................. 1394.2.4 Strukturelemente zu Änderungsvorgängen ................ 141

4.3 Administration ....................................................................... 1474.3.1 Aufgabenplan ........................................................... 147


Inhalt

7

4.3.2 Erweiterte Konfiguration ........................................... 1614.3.3 Änderungsverfolgung ................................................ 1624.3.4 Einplanung ................................................................ 1644.3.5 Projektlogistik ........................................................... 166

4.4 Reporting/Monitoring ........................................................... 1684.4.1 Solution-Manager-Reporting ..................................... 1684.4.2 Vorgangsmonitor ...................................................... 170

4.5 Work Center .......................................................................... 1744.5.1 Work Center Change Management ........................... 1744.5.2 Konfiguration von Work Centern .............................. 1784.5.3 Konfiguration SAP GUI for HTML .............................. 179


181

5 Sicherheit im Change Request Management ...................... 181

5.1 Berechtigungen im SAP-System ............................................. 1815.1.1 Berechtigungen im Solution-Manager-System............ 1815.1.2 Berechtigungen auf Satellitensystemen ..................... 1825.1.3 Work Center ............................................................. 1835.1.4 Erweiterte Berechtigungsprüfungen .......................... 184

5.2 Systemübergreifende Objektsperre ........................................ 1845.2.1 Funktionalität ........................................................... 1855.2.2 Notwendige Einstellungen ........................................ 187

5.3 Kritische Transportobjekte ..................................................... 1905.3.1 Funktionalität ........................................................... 1905.3.2 Notwendige Einstellungen ........................................ 1915.3.3 Modifikationen ......................................................... 192

5.4 Projektüberschneidungen ...................................................... 1935.4.1 Praxisbeispiel ............................................................ 1945.4.2 Notwendige Einstellungen ........................................ 196


6 Erweiterungen des Change-Request-Management-Szenarios ............................................................................. 197

6.1 Erweiterte Transportlandschaften .......................................... 1976.1.1 Drei-System-Landschaft ............................................ 1986.1.2 Vier-System-Landschaft ............................................. 2006.1.3 Parallele Phasenlandschaft ........................................ 2016.1.4 Landschaften für globale Entwicklungen .................... 2036.1.5 Fazit .......................................................................... 205


Inhalt

8

6.2 Erweitertes Transportmanagement ........................................ 2056.2.1 Komponenten ........................................................... 2076.2.2 TMS-Konfiguration ................................................... 2096.2.3 Integration in Anwendungen .................................... 2136.2.4 Landschaftsszenarien ................................................. 2166.2.5 Integration von CTS+ und Change Request

Management ............................................................ 2246.2.6 Fazit .......................................................................... 225

6.3 Erweiterungsentwicklungen/Entwicklungspaket ..................... 2256.4 Kundeneigener Karteireiter .................................................... 226

6.4.1 Definition der notwendigen Datenstrukturen ............ 2276.4.2 Definition des Layouts und Ablauf des Dynpros ......... 2306.4.3 Einbindung des neuen Karteireiters

via Bildschirmsteuerung ............................................ 2346.4.4 Karteireiter im Änderungsantrag ............................... 2356.4.5 Berechnungslogik einfügen ....................................... 236

6.5 Erweiterung des Vorgangsmonitors ........................................ 2386.6 Erweiterte Aktionen und Konditionen ................................... 240

6.6.1 Erweiterte Prüfung auf Text-IDs ................................ 2416.6.2 Erweiterte Prüfung auf Partnerfunktionen ................. 2466.6.3 Transportaufträge anzeigen ....................................... 250


255

7 Change Management in SAP-Landschaften ....................... 255

7.1 Change-Management-Konzept .............................................. 2557.1.1 Wartung – Maintenance Optimizer ........................... 2567.1.2 Technische Integration .............................................. 2587.1.3 Testen ....................................................................... 2587.1.4 Analyse ..................................................................... 259

7.2 Quality Management im SAP Solution Manager .................... 2607.2.1 Funktionsumfang ...................................................... 2607.2.2 Voraussetzungen für das Quality Gate

Management ............................................................ 2627.3 Zusammenfassung ................................................................. 264

265

8 Technische Hinweise zur Nutzung und Fehlerbehebung .... 265

8.1 Neue Systeme hinzufügen ...................................................... 2658.2 System- und Mandantenkopie ............................................... 2678.3 Aufbau einer Projektlandschaft .............................................. 269


Inhalt

9

8.4 Reparatur-Flag beim Import .................................................. 2728.5 Dringende Korrekturen in parallelen Systeme ........................ 2738.6 Transporte und SAP NetWeaver Business Warehouse ............ 274

8.6.1 Dringende Korrektur ................................................. 2748.6.2 Import All ................................................................. 275

8.7 Import Subset/Import Project ................................................ 2758.8 Fehleranalyse ......................................................................... 276

8.8.1 Application Log ........................................................ 2788.8.2 Reports für das Abschließen von Projektzyklen........... 2798.8.3 Berechtigungsprobleme ............................................ 281

8.9 SAP-Hinweise ........................................................................ 283

Die Autoren ............................................................................................ 285

Index........................................................................................................ 287


33

2 Architektur des Change Request Managements

Das Change Request Management im SAP Solution Manager ist aus verschie-denen Einzelbestandteilen zusammengesetzt. Um die gesamte Bandbreiteder Change-Request-Management-Funktionalität zu verstehen, ist es dahererforderlich, die verschiedenen Bestandteile und ihre Wirkungsweise zukennen. Dieses Kapitel wird die verschiedenen Bereiche des Change RequestManagements erläutern und Ihnen einen ersten Einblick in das ChangeRequest Management im SAP Solution Manager ermöglichen.

2.1 Bestandteile des Change Request Managements

Das Change Request Management ist eine Kernfunktionalität im SAP SolutionManager. Der SAP Solution Manager stellt über den gesamten Lebenszykluseiner Applikation hinweg verschiedene Funktionen, Informationen oder Ser-vices zur Unterstützung dieser Lebenszyklen zur Verfügung. In Abbildung 2.1finden Sie eine Darstellung der verschiedenen Lebenszyklen sowie entsprechendzugeordnet die hierzu verfügbaren Funktionen im SAP Solution Manager.

Abbildung 2.1 Change Request Management im SAP Solution Manager

� SAP

Kern-geschäfts-prozesse

Impl

emen

tierung

Optimierung

Durchführung

Change RequestManagement� folgt ITIL-Standards� Wartungsprozesse

Service Desk� Best Practices

für Incident Management� Integration von

Help Desks anderer Hersteller

Solution Monitoring� Systemüberwachung� Business Process Monitoring� zentrale Systemverwaltung� EarlyWatch Alert � Service Level Reporting� Solution Reporting

Upgrade vonSAP-Lösungen� SAP-Methoden

und -Werkzeuge� E-Learning-

Management� Testmanagement

Implementierung vonSAP-Lösungen� SAP-Methoden und -Werkzeuge� Konzern-Roll-out� Customizing-Synchronisation� E-Learning-Management� Testmanagement

Lieferung vonSAP-Services� vor Ort/remote� SAP-Safeguarding

Solution Manager Diagnostics� Sicherer Remote-Zugang� Performance-Messungen� Logs und Dumps � Traces � Technische Konfiguration


Architektur des Change Request Managements2

34

Das Change Request Management ist dem Zyklus der Optimierung zugeord-net. In diesem Zyklus werden Änderungsanforderungen, die im operativenBetrieb entstanden sind, beispielsweise durch entdeckte Programmfehleroder geplante Verbesserungen, dokumentiert und kontrolliert durchgeführt.Die verschiedenen Bausteine des Change Request Managements sind inAbbildung 2.2 dargestellt.

Abbildung 2.2 Bestandteile des Change Request Managements

� Die Projektverwaltung (Project Administration) ermöglicht die Strukturie-rung und Gruppierung der Änderungsaktivitäten sowie der damit verbun-denen technischen Änderungen. Diese technischen Änderungen führenzu Transportaufträgen, die mithilfe des Transportwesens (TransportManagement System) innerhalb der Systemlandschaft verteilt werden. Inder Projektverwaltung werden darüber hinaus Informationen hinsichtlichder zu betreuenden Systeme bzw. Systemgruppen gepflegt.

� Die Systemlandschaftspflege (System Landscape Maintenance) stellt Infor-mationen der zu betreuenden Systeme zur Verfügung. In der Systemland-schaftspflege werden die Systeme definiert, Verbindungen konfiguriertund mehrere Systeme zu logischen Komponenten gruppiert (sieheAbschnitt 3.3.1, »Definition von logischen Komponenten«).

� Der Kasten SAP Change Manager in Abbildung 2.2 stellt die spezifischenChange-Request-Management-Funktionen dar. Dazu zählen zum Beispiel

Projektadministration Business Blueprint Konfiguration Testing

SystemlandschaftspflegeSAP Change Manager

Service Desk Change Request Management

Transport Management System

SN

cProjects

CR CD

Solution-Manager-Projekt

cProject

DEVIMG-Projekt

CTS-Projekt

Task List System- und Transport-

Konfiguration

TransportTracking

PRD

CTS-Projekt

QAS

CTS-Projekt

Systemlandschaft

TesfälleDokumentation

Training

SAP Solution Manager


Projektverwaltung im SAP Solution Manager 2.2

35

der Aufgabenplan (Task List) sowie die verschiedenen Möglichkeiten zurNachverfolgung von Transporten (Transport Tracking).

� Der Kasten Change Request Management stellt die zwei grundlegendenTeilprozesse im Change Request Management dar. Der Änderungsantrag(Change Request) und das Änderungsdokument (Change Document)beschreiben dabei jeweils einen organisatorischen sowie technischen Teil-bereich der Änderung. Zusammen bilden sie den gesamten Change-Request-Prozess ab.

Im Folgenden finden Sie eine detaillierte Beschreibung der verschiedenenBereiche sowie eine Erläuterung ihrer Wirkungsweise.

2.2 Projektverwaltung im SAP Solution Manager

Mit dem SAP Solution Manager werden verschiedene Projektarten ausgelie-fert. Diese dienen in unterschiedlichen Szenarien bzw. zu unterschiedlichenProjektzwecken wie Implementierung, Upgrade oder Change RequestManagement der Organisation, Dokumentation und Steuerung von Projekten.

2.2.1 Solution-Manager-Projekte

Die im SAP Solution Manager verfügbaren Projektarten sind im Einzelnen:

� Implementierungsprojekt/EinführungsprojektDiese Projektart dient zur Einführung von neuen Geschäftsprozessen ineiner SAP-Landschaft mithilfe des SAP Solution Managers. In Form einerProjektstruktur können darin detaillierte Informationen zu einem Prozessabgebildet werden. Dazu zählen Prozessschritte, Dokumentation, Testfälleoder Konfigurationen/Customizing.

� WartungsprojektDiese Projektart dient zur Wartung von Lösungen, die bereits produktivsind, und wird vorwiegend im Change Request Management verwendet.Wartungsaktivitäten für eine Lösung werden in diesen Projekten zusam-mengefasst. Ist im Solution Directory, in dem alle produktiven Prozessedokumentiert sind, die Nutzung der Check-In/Check-Out-Funktionalitätvorgesehen, so werden Wartungsprojekte auch dort genutzt.

� Template-/VorlagenprojektIn einem Template- bzw. Vorlagenprojekt können Strukturen eines Pro-jektes definiert und anschließend anderen Projekten als Vorlage zur Ver-



36

fügung gestellt werden. Es besteht somit die Möglichkeit, Prozesse, Pro-zessschritte, Dokumentationen oder Testfälle zu definieren und als Vor-lage für einen unternehmensweiten Roll-out zu nutzen. Dabei könnenausgewählte Bereiche als nicht änderbar konfiguriert werden.

� Upgrade-ProjektIm Rahmen eines Upgrade-Projektes werden Konfigurationen währenddes Upgrades durchgeführt.

� Safeguarding-ProjektSafeguarding-Projekte dienen der Ursachenanalyse von kritischen Zustän-den sowie deren anschließender Behebung.

� OptimierungsprojektEin Optimierungsprojekt dient der Verbesserung von Geschäftsprozessenoder des allgemeinen Betriebes einer Lösung. Ein möglicher Anwen-dungsbereich besteht im Rahmen von SAP Services.

Einen schnellen Weg zur Erstellung eines Projektes bietet ein webbasierterAssistent, der über die Transaktion AI_SPS aufgerufen werden kann. Abbil-dung 2.3 zeigt einen Bildausschnitt dieses Assistenten. Versierte Anwenderkönnen auch direkt die Projektadministration aufrufen, die im Folgendenkurz beschrieben wird.

Abbildung 2.3 Schnelleinstieg zur Erstellung eines Projektes

Check-In/Check-Out-Funktionalität

Die Check-In/Check-Out-Funktionalität ermöglicht die Überführung eines produkti-ven Geschäftsprozesses aus dem Solution Directory in ein Wartungsprojekt, ohne denaktiven Prozess zu beeinflussen. Nach diesem Check-Out können im Wartungsprojektanschließend Änderungen am Geschäftsprozess, wie zum Beispiel die Definitionneuer Prozessschritte, durchgeführt werden. Abschließend kann mittels Check-In dergeänderte Geschäftsprozess wieder in das Solution Directory überführt werden.



37

Der Aufruf der zentralen Projektadministration erfolgt mit der TransaktionSOLAR_PROJECT_ADMIN.

1. Im Einstiegsbild, wie in Abbildung 2.4 zu sehen ist, werden alle existieren-den Projekte im SAP Solution Manager angezeigt. Darüber hinaus könnendort direkt über die Schaltfläche Projekt anlegen neue Projekte erstelltoder in die Projektauswertung navigiert werden.

Abbildung 2.4 Projektverwaltung im SAP Solution Manager

2. Nach Auswahl eines Projektes per Doppelklick gelangen Sie in die Detail-ansicht der Projekte. Dort besteht nun die Möglichkeit, verschiedene fürdas Projekt relevante Informationen zu pflegen. Hierzu stehen verschie-dene Karteireiter zur Verfügung, von denen der Karteireiter Allgemeine

Daten an erster Stelle zu finden ist. Zunächst sind hier Pflichtangaben wiedie Projektsprache und die Projektbezeichnung einzupflegen. WeitereInformationen wie Statuswerte und Zeitwerte sind hier optional.

3. Die weiteren Karteireiter Umfang, Projektmitarbeiter, Systemland-

schaft und Projektstandards enthalten ebenfalls verschiedene Informa-tionen, die an dieser Stelle jedoch nicht weiter vertieft werden sollen, dasie bis auf den Karteireiter Systemlandschaft für das Change RequestManagement nicht notwendig sind (siehe Abbildung 2.5).

Der Karteireiter Systemlandschaft dient zur Definition der Systeme fürein Projekt. Hier können durch die Auswahl einer logischen Komponentezusammengehörige Systeme eines SAP-Produktes ausgewählt und somitdem Projekt zugeordnet werden.

4. Die Definition einer logischen Komponente erfolgt in der Systemland-schaftspflege (Transaktion SMSY), in der die logischen Systeme zu logi-schen Komponenten zusammengeführt werden, um anschließend in ver-schiedenen Szenarien wie der Implementierung, des Testens oder desChange Request Managements genutzt zu werden (siehe Abschnitt 3.3.1,»Definition von logischen Komponenten«).



38

Abbildung 2.5 Detailinformationen des Solution-Manager-Projektes

Das Beispiel in Abbildung 2.6 zeigt die logische Komponente ZCHARM_LANDSCAPE mit den darin zugeordneten logischen Systemen ST4:200,ST4:300 und ST4:400. Die Bezeichnung der logischen Systeme setzt sich ausder System-ID und dem Mandanten des Systems zusammen. Es handelt sichsomit um drei Mandanten eines Solution-Manager-Systems, die eine Drei-System-Landschaft beispielhaft darstellen. Diese Konfiguration wird oftmalsbeim ersten Setup des Change Request Managements genutzt, um lokal einkorrektes Setup zu überprüfen. Alle Funktionen des Change Request Manage-ments, einschließlich des Transports von Änderungen, können somit getestetwerden. Lediglich der Transport von Workbench-Objekten ist aufgrund dermandantenübergreifenden Gültigkeit dieser Objekte nicht simulierbar.

Bevor nun die weiteren Konfigurationen und Informationen auf dem Kartei-reiter Systemlandschaft erklärt werden, soll der folgende Abschnitt einekurze grundlegende Erläuterung zur Architektur des Change Request Manage-ments bieten. Hier werden neben den Solution-Manager-Projekten weitereTypen von Projekten beschrieben. Die darauffolgenden Abschnitte kehrendann wieder zur Projektadministration zurück.



39

Abbildung 2.6 Systemlandschaft – Projektadministration

2.2.2 Solution-Manager-Projekte im Change Request Management

Wie bereits erwähnt, bilden die Solution-Manager-Projekte die Basis für ver-schiedene Szenarien im SAP Solution Manager. Im Szenario des ChangeRequest Managements können vier der in Abschnitt 2.2.1, »Solution-Mana-ger-Projekte«, dargestellten Projektarten genutzt werden: Wartungspro-

jekt, Einführungsprojekt, Vorlagenprojekt und Upgrade-Projekt.

Aus Sicht des Change Request Managements gibt es jedoch noch weitereBesonderheiten. So werden die vier Projektarten danach unterschieden, obsie zyklisch oder einmalig durchgeführt werden. Abbildung 2.7 zeigt, dassein Wartungsprojekt als zyklisch definiert wird, da es nach erfolgreichemAbschluss immer wieder neu gestartet wird. Einführungs-, Vorlagen- undUpgrade-Projekte haben hingegen einen einmaligen Charakter. Für dieseProjekte gibt es in der Regel nur einen Projektstart und ein Projektende.

Abbildung 2.7 Zyklische und einmalige Projekte

Hintergrund dieser Unterscheidung ist die damit verbundene Anforderungan Funktionen im Change Request Management. In einem Wartungsprojektwerden Prozesse bzw. Funktionalitäten gewartet, die bereits produktiv sind.

zyklisch

Einführungs-projekt

Vorlagen-projekt

Upgrade-Projekt

Wartungs-projekt

einmalig



40

In Projekten, die einen einmaligen Charakter haben, wie zum Beispiel dasEinführungsprojekt, ist die Situation eine andere: Hier wird ein Prozess odereine Funktionalität neu eingeführt und ist erst nach erfolgreichem Abschlussdes Projektes produktiv. Diese grundsätzliche Unterscheidung resultiert inunterschiedlich notwendigen Funktionen, auf die in Abschnitt 2.2.4, »Pro-jektzyklus und Aufgabenplan«, detailliert eingegangen wird.

Solution-Manager-Projekte sind die grundlegende Voraussetzung, um mitdem Change Request Management arbeiten zu können. Diese Projekte wer-den im SAP Solution Manager angelegt und verwaltet. Um jedoch eine Kon-trolle von Änderungen in verwalteten Systemen zu erreichen, werden in die-sen Systemen weitere Projektfunktionen genutzt und mit dem Solution-Manager-Projekt verknüpft. Die dabei verwendeten Projektfunktionen sinddas IMG-Projekt (Implementation Guide) und das CTS-Projekt (Change andTransport System), die in Abschnitt 2.2.3, »IMG-Projekte und CTS-Projekte«,näher erläutert werden. Beide Projektfunktionen sind Basisfunktionen undsomit in SAP NetWeaver bzw. in der SAP-Basis verfügbar.

Wird das Change Request Management für ein Solution-Manager-Projektaktiviert (siehe Abschnitt 3.3.2, »Erstellung eines Solution-Manager-Projek-tes«), wird automatisch im Entwicklungssystem (der logischen Komponente)ein IMG-Projekt generiert, und die Informationen im Solution-Manager-Pro-jekt werden gespeichert. Sind einem Solution-Manager-Projekt mehrerelogische Komponenten zugeordnet, wird in jedem dort definierten Entwick-lungssystem ein IMG-Projekt angelegt.

IMG-Projekte ihrerseits besitzen eine Option, die es ermöglicht, CTS-Pro-jekte direkt mit dem IMG-Projekt zu verknüpfen. Dies bietet wiederum dieMöglichkeit, alle Änderungen und somit Transportaufträge von CTS-Projek-ten auch dem IMG-Projekt zuzuordnen. Abbildung 2.8 stellt diese Konstella-tion der verschiedenen Projekte sowie die damit verbundenen Systeme dar.Neben den beschriebenen Projekten sind in Abbildung 2.8 auch weitereFunktionen im SAP Solution Manager dargestellt. Dabei handelt es sich umden Projektzyklus und den Aufgabenplan sowie die optionale Verbindung zucProjects, einer Projektmanagement-Lösung.

Im Folgenden finden Sie eine ausführlichere Erläuterung zu den IMG- undCTS-Projekten, und im Anschluss daran erfahren Sie, welche Funktionen derProjektzyklus und der Aufgabenplan erfüllen. Abschließend wird die mögli-che Integration von cProjects in das Change Request Management vorgestellt.



41

Abbildung 2.8 Architektur des Change Request Managements

2.2.3 IMG-Projekte und CTS-Projekte

Wie bereits erläutert, sind IMG- und CTS-Projekte Basisfunktionalitäten undsomit in jedem SAP NetWeaver-System verfügbar:

� Mithilfe von IMG-Projekten (Implementation Guide) können Aktivitätendes Customizings koordiniert und daraus resultierende Änderungen untereinem Projekt gespeichert werden.

� CTS-Projekte (Change and Transport System) sind Parameter, mit denenTransportaufträge gruppiert werden können. In IMG-Projekten kann dieCTS-Projektfunktionalität für das entsprechende Projekt aktiviert werden.

Im SAP Solution Manager können Solution-Manager-Projekte mit IMG-Pro-jekten verknüpft werden, und somit kann auf die Systeme der IMG-Projektezugegriffen werden. Durch die Möglichkeit, ein CTS-Projekt einem IMG-Pro-jekt zuzuordnen, können die damit verbundenen Informationen hinsichtlichder zugehörigen Transportaufträge ebenfalls im IMG-Projekt und schließlichauch im Solution-Manager-Projekt genutzt werden.

In Abbildung 2.9 ist das Solution-Manager-Projekt vom Typ Wartungspro-

jekt zu sehen. Auf dem Karteireiter Systemlandschaft finden sich mehrereUnterkategorien; die Kategorie bzw. der Karteireiter Systeme ist Ihnen ausAbbildung 2.6 bekannt.

Projekt (in cProjects

erstellt)

SAP Solution Manager

ProjektzyklusÄnderungs-

vorgang

cProjects

ProjektzyklusAufgabenplan

IMG-Projekt

IMG-Projekt

Entwicklungs-system

CTS-Projekt

Logisches System (System und

Mandant)

CTS-Projekt

Transport-aufträge

Q

Q P

P

D

D

Solution-Manager-Projekt



42

Abbildung 2.9 Wartungsprojekt und zugeordnetes IMG-Projekt

1. Wird nun der Karteireiter IMG-Projekte ausgewählt, ist dort das zugeord-nete IMG-Projekt (CHARM01) zu erkennen. Darüber hinaus ist zu sehen,dass dem IMG-Projekt das logische System ST4:200 zugewiesen ist. Diesentspricht dem Entwicklungssystem der Demolandschaft, die sich aus denlogischen Systemen ST4:200 (Development), ST4:300 (Qualitätssicherung)und ST4:400 (Produktion) zusammensetzt.

2. Wenn Sie nun das IMG-Projekt markieren und auf die Schaltfläche Anzei-

gen klicken, so gelangen Sie automatisch in das jeweilige Entwicklungs-system und in die Ansicht des IMG-Projektes im System. Abbildung 2.10zeigt die Detailansicht des IMG-Projektes im Entwicklungssystem.

Abbildung 2.10 IMG-Projekt im Entwicklungssystem

Der Aufbau und die Darstellung des IMG-Projektes ähneln stark dem desSolution-Manager-Projektes. Lediglich die Typenbezeichnung Customi-



43

zing-Projekt im oberen Bildbereich wie auch die Anzahl der Karteireiterdeuten auf eine andere Projektart hin.

3. Wählen Sie nun den Karteireiter Transportaufträge, wie in Abbildung2.11 zu sehen ist.

Abbildung 2.11 Auswahl des Karteireiters »Transportaufträge« im IMG-Projekt

Auf dem Karteireiter Transportaufträge finden Sie Informationen zurCTS-Funktionalität. Wie Abbildung 2.12. zeigt, können dort die Projekt-daten des CTS-Projektes wie auch die Information, welche Transportauf-träge dem CTS-Projekt zugeordnet sind, abgerufen werden.

Abbildung 2.12 Karteireiter »Transportaufträge« im IMG-Projekt

4. Das Anklicken der Schaltfläche CTS-Projektdaten anzeigen führt zu einerDarstellung, wie sie Abbildung 2.13 zeigt. Sie sehen hier das IMG-Projekt



44

CHARM01 sowie das zugehörige CTS-Projekt ST4_P00001. Die weiterenSchaltflächen Zugeordnete CTS-Aufträge und CTS-Projektstückliste

(siehe Abbildung 2.12) zeigen anschließend auch die betreffenden Trans-portinformationen.

Abbildung 2.13 CTS-Projektdaten

5. Abschließend zum CTS-Projekt ist noch der Projektstatusschalter zubeschreiben. Die Projektstatusschalter für CTS-Projekte ermöglichen dieAktivierung bzw. Deaktivierung verschiedener Eigenschaften für das CTS-Projekt und somit auch für die zugehörigen Transportaufträge. Abbildung2.14 zeigt die Projektstatusschalter für ein CTS-Projekt. Besonders relevantsind hier die Schalter für das Anlegen, Freigeben und Importieren vonTransportaufträgen.

Abbildung 2.14 Projektstatusschalter eines CTS-Projektes

6. Ist das Change Request Management aktiv, übernimmt es die Kontrolleund Steuerung dieser Schalter. Somit kann Änderungsaktivitäten, dieaußerhalb des Change Request Managements stattfinden, die Möglichkeit



45

genommen werden, Transportaufträge auf den betreuten Systemen anzu-legen.

Details zur Konfiguration, insbesondere im Zusammenhang mit derPflichtzuordnung zu Projekten, finden Sie im Abschnitt »Projektzuord-nung von Anträgen als obligatorisch definieren« in Kapitel 3.2.1.

Nach dieser Vorstellung der verschiedenen Projektarten und deren Zusam-menarbeit im Change Request Management werden nun der Projektzyklus,der Aufgabenplan sowie die Integration von cProjects vorgestellt.

2.2.4 Projektzyklus und Aufgabenplan

Bisher wurden Funktionalitäten beschrieben, die das Change RequestManagement nutzt, um Informationen über Änderungen auf verwaltetenSystemen zu sammeln. Um diese Informationen nun im Rahmen verschie-denster operativer Tätigkeiten, wie zum Beispiel die Verteilung von Trans-porten, zu nutzen, bedarf es einer funktionalen Grundlage zur Ausführungdieser Tätigkeiten.

Im Change Request Management ist dies durch das Einplanungswerkzeuggegeben. Dieses Werkzeug basiert auf dem bekannten Schedule Manager,einer Funktionalität zur Durchführung und Kontrolle wiederkehrenderArbeiten. Im Change Request Management ermöglicht der Schedule Mana-ger die Durchführung verschiedenster operativer Tätigkeiten, wie zum Bei-spiel den Import von Transporten in Folgesysteme oder die Erstellung undFreigabe neuer Transportaufträge. Das Einplanungswerkzeug dient zudemder Steuerung eines Solution-Manager-Projektes hinsichtlich des Lebenszyk-lus.

Projekte unterliegen einem Lebenszyklus, der als Projektzyklus bezeichnetwird. Zwischen Projekt und Projektzyklus besteht immer eine 1:1-Bezie-hung, der Projektzyklus wiederum wird in Phasen unterteilt. Diese Phasenspiegeln die unterschiedlichen Teilschritte eines Projektes wider, wie zumBeispiel die Entwicklungsphase oder die Testphase. Die Abbildung dieserPhasen sowie die hierzu erforderlichen Funktionen ermöglicht das Einpla-nungswerkzeug.

Die Phasenwerte für einen Zyklus sind für alle Projekte gleich und untertei-len sich in: Angelegt, Entwicklung ohne Freigabe, Entwicklung mit Freigabe,Test, Notkorrektur, Go-Live, Im Abschluss und Abgeschlossen.



46

Die für den täglichen Betrieb relevanten Phasenwerte sind: Entwicklungohne Freigabe, Entwicklung mit Freigabe, Test, Notkorrektur und Go-Live.Innerhalb dieser Phasen werden verschiedene Aktivitäten während einesProjektes durchgeführt. Abbildung 2.15 zeigt das Zusammenspiel von Pro-jekt, Projektzyklus sowie der Phasen mit den zugehörigen Änderungen.

Abbildung 2.15 Einführungsprojekt, Projektzyklus und Änderungen

Aus technischer Sicht wird der Projektzyklus, wie in Abbildung 2.16 zusehen ist, durch einen generierten Aufgabenplan (Schedule Manager) undeinen Änderungsvorgang (CRM-Dokument) dargestellt. Der Aufgabenplanenthält eine Liste verschiedener Aktivitäten, eine Darstellung der im Projekt-zyklus betreuten Systeme sowie eine Anzeige der aktuellen Phase des Pro-jektzyklus. Der Aufgabenplan ist ein Arbeitsumfeld des IT-Operators. DerÄnderungsvorgang ermöglicht das Schalten einer Projektphase und bietetdarüber hinaus Informationen über zum Projekt gehörige Transportaufträge.Detaillierte Informationen zum Aufgabenplan finden Sie in Abschnitt 4.3,»Administration«. Ein Beispiel für den Aufgabenplan zeigt Abbildung 2.17.

Abbildung 2.16 Projektzyklus eines Solution-Manager-Projektes

Entwicklungs-tätigkeit

Synchronisation

Projektzyklus

Synchronisation Synchronisation

Test Go-LiveNotkorrektur

cProjects

Solution-Manager-Projekt (zum Beispiel Einführungsprojekt)

Entwicklung(ohne und

mit Freigabe)

Projektzyklus

Änderungsvorgang Aufgabenplan



47

Abbildung 2.17 Aufgabenplan im Change Request Management

Abbildung 2.16 ist eine Darstellung, die für die Projektarten Einführungs-projekt, Vorlagenprojekt und Upgrade-Projekt gültig ist. An dieser Stelle istwieder eine Differenzierung (siehe Abbildung 2.7) des Wartungsprojektesvorzunehmen.

Wartungsprojekte besitzen ebenfalls einen Projektzyklus, der hier aber War-tungszyklus genannt wird. Zum Beispiel kann ein dauerhaftes Wartungspro-jekt für eine produktive Lösung in Wartungszyklen von jeweils drei Monatenunterteilt sein. Innerhalb dieser Wartungszyklen werden alle notwendigenTätigkeiten für den Support und die Wartung durchgeführt. Dazu zählen inerster Linie die Entwicklung und der Test von Korrekturmaßnahmen.

Innerhalb dieses dreimonatigen Wartungszyklus werden die Tätigkeitendurch Phasen voneinander getrennt. Zum Beispiel gibt es eine Entwicklungs-phase und eine Testphase. Am Ende der drei Monate hat der Wartungszyklusdie letzte Phase erreicht, und alle Änderungen des gesamten Zyklus werdenin das Produktivsystem importiert. Nach erfolgreichem Import in das Pro-duktivsystem kann der Wartungszyklus abgeschlossen werden. Anschlie-



48

ßend kann ein neuer Wartungszyklus generiert werden, um alle Änderungender kommenden drei Monate zu verwalten. Abbildung 2.18 macht diesenKreislauf deutlich.

Abbildung 2.18 Wartungsprojekt und Wartungszyklus

Das Wartungsprojekt weist im Gegensatz zu den anderen Projektartenjedoch eine Besonderheit auf. Innerhalb des Wartungszyklus kann es not-wendig sein, eine wichtige Änderung/Korrektur so schnell wie möglich indas Produktivsystem zu importieren. In diesem Fall würde sich der dreimo-natige Zyklus als zu lang erweisen. Für dieses durchaus typische Szenariogibt es einen speziellen Änderungsvorgang mit dem Namen Dringende Kor-rektur. Dieser Änderungsvorgang ist nur in Wartungsprojekten verfügbarund ermöglicht einen umgehenden Transport von Änderungen in das Pro-duktivsystem, unabhängig von den Phasen des Wartungszyklus. Dies stellteine Besonderheit dar und unterscheidet das Wartungsprojekt von anderenProjektarten. Eine detaillierte Beschreibung dringender Korrekturen erfolgtin Abschnitt 2.3.5, »Dringende Korrektur«.

Zur Verdeutlichung der verschiedenen Änderungsarten in einem Wartungs-projekt dient Abbildung 2.19. Hier ist noch einmal das Zusammenspiel vonWartungsprojekt und Wartungszyklus sowie der zugehörigen Phasen zusehen. Darüber hinaus zeigt die Abbildung, in welchen Phasen normale Kor-rekturänderungen und dringende Korrekturen angelegt und innerhalb desWartungszyklus durchgeführt werden können.

Es ist zu sehen, dass normale Korrekturen für einen Wartungszyklus nur inden Entwicklungsphasen (Entwicklung mit und ohne Freigabe) möglichsind. In den folgenden Phasen werden normale Korrekturen ausschließlichweiter in das Qualitätssicherungssystem und anschließend in das Produkti-onssystem transportiert. Dringende Korrekturen hingegen können bis kurz

Wartungsprojekt

Änderungsvorgang Aufgabenplan

Wartungszyklusmit Phasen



49

vor dem Go-Live angelegt werden, um noch in denselben Wartungszyklusintegriert zu werden.

Abbildung 2.19 Wartungsprojekt, Wartungszyklus und Vorgänge

Wie Sie den näheren Erläuterungen zu normalen Korrekturen (Abschnitt2.3.4, »Normale Korrektur/Entwicklungstätigkeit«) noch entnehmen wer-den, ist es auch nach den Entwicklungsphasen noch möglich, eine normaleKorrektur anzulegen. Diese wird allerdings nicht im aktuellen Wartungszyk-lus Verwendung finden, sondern im darauffolgenden Zyklus.

2.2.5 cProjects

Die Integration der Projektmanagement-Lösung Collaboration Projects(cProjects) in das Change Request Management ist eine optionale Erweite-rung. Durch eine 1:1-Verknüpfung eines cProjects-Projektes mit einem Solu-tion-Manager-Projekt kann der Change-Request-Management-Prozess vonden erweiterten Projektmanagement-Funktionen im cProjects-Projekt profi-tieren. Dazu zählen eine Vielzahl von Funktionen (wie ein ebenfalls phasen-basiertes Projektmanagement), die Definition von Meilensteinen, Rollenund zu liefernden Ergebnissen sowie die grafische Darstellung des Projektesin Form von Gantt-Diagrammen.

DringendeKorrektur(unabhängig vom Wartungszyklus)

Normale Korrektur

Synchronisation

Wartungszyklus

Synchronisation Synchronisation

Entwicklung(ohne und mit Freigabe) Test Go-LiveNotkorrektur

cProjects

Solution-Manager-Projekt (Wartungsprojekt)



50

Zudem ist hervorzuheben, in welcher Art und Weise die Zusammenarbeitvon cProjects und Change Request Management erfolgt: Ist einem Solution-Manager-Projekt ein cProjects-Projekt zugeordnet, so hat das cProjects-Pro-jekt die gleichen Phasenwerte wie das zugehörige Solution-Manager-Projekt.Die folgenden Phasenwerte finden dabei Anwendung: Entwicklung ohneFreigabe, Entwicklung mit Freigabe, Test, Notkorrektur, Go-Live und ImAbschluss.

Wird nun im weiteren Verlauf des Solution-Manager-Projektzyklus eineneue Phase gewählt, zum Beispiel von Entwicklung mit Freigabe zu Test, soerfolgt eine Konsistenzprüfung gegen das cProjects-Projekt, in der überprüftwird, ob das entsprechende cProjects-Projekt ebenfalls den Phasenwert Testaufweist. Ist dies nicht der Fall, erscheint eine Warnmeldung im Aufgaben-plan und weist auf eine Inkonsistenz mit dem cProjects-Projekt hin. Im cPro-jects-Projekt muss dann zunächst der passende Phasenwert eingestellt wer-den, bevor im Aufgabenplan oder Änderungsvorgang der Phasenwertgewählt wird. Dies ermöglicht cProjects eine führende Rolle hinsichtlich derProjektorganisation und stellt somit ein gutes Arbeitsumfeld für Projektleiterdar (siehe Abbildung 2.20).

Voraussetzung für eine Integration von cProjects ist ein Solution-Manager-Projekt mit aktiviertem Change Request Management. Zudem muss bereitsein Aufgabenplan für das Projekt generiert worden sein.

Abbildung 2.20 cProjects mit Wartungsprojekt


Vorgangsarten/Workflows 2.3

51

2.3 Vorgangsarten/Workflows

Im Change Request Management werden verschiedene Workflows, die nichtmit der Funktionalität des SAP Business Workflows zu verwechseln sind, zurVerfügung gestellt, um den unterschiedlichen Prozessanforderungen gerechtzu werden. In Abschnitt 1.3.1, »Change (Request) Workflows«, wurden dieseWorkflows bereits angesprochen. Im Folgenden finden Sie nun eine Erläute-rung unterschiedlicher Workflows, die entweder direkt oder indirekt mitdem Change Request Management genutzt werden.

Aus technischer Sicht handelt es sich bei all diesen Workflows um ver-schiedene Vorgangsarten der CRM-Service-Vorgangstransaktion (CRMD_ORDER). Vorgangsarten sind Belege der CRM-Service-Vorgangstransaktionund können durch entsprechendes Customizing einen definierten Prozessab-lauf darstellen. Innerhalb der Service-Vorgangstransaktion können die Vor-gänge geöffnet und bearbeitet werden.

Unterschiedliche Vorgangsarten (zum Beispiel Service-Desk-Meldung, Ände-rungsantrag bzw. Change Request) können miteinander verknüpft werdenund so verschiedene Prozesse verbinden. Zu sehen ist diese Verknüpfungzum Beispiel in Transaktion CRMD_ORDER anhand des Belegflusses. EineVerknüpfung von Vorgangsarten kann fest vorgegeben oder anhand einesSelektionsfeldes flexibel gestaltet sein. Basierend auf den Werten des Selek-tionsfeldes im Ursprungsdokument, können so unterschiedliche Folgedoku-mente/-prozesse verknüpft werden. Abbildung 2.21 verdeutlicht die mögli-chen Verknüpfungen noch einmal.

Abbildung 2.21 Vorgänge im Change Request Management

Die Service-Desk-Meldung gehört nicht zum Change Request Management,ist jedoch oftmals Initiator für Aktionen in diesem. Der Service Desk ist eine

Change-Prozess

Service-Desk-

Meldung

ChangeRequest

DringendeKorrektur

NormaleKorrektur

Administration

Testmeldung



52

Funktion, die ebenfalls im SAP Solution Manager verfügbar ist und im Rah-men des Incident Managements verwendet wird. Innerhalb einer Service-Desk-Meldung besteht die Möglichkeit, einen verknüpften Änderungsantrag(Change Request) zu erstellen. Dies stellt zugleich den Übergang zum ChangeRequest Management dar, denn der Änderungsantrag ist das Ausgangsdoku-ment für alle weiteren Aktivitäten im Change Request Management.

Aus dem Änderungsantrag können sich verschiedene Folgevorgänge erge-ben. Diese Vorgänge werden im Standard durch die dringende Korrektur,die normale Korrektur und die Administrationsmeldung dargestellt. DieTestmeldung nimmt eine Sonderstellung ein, da sie ohne Änderungsantragauskommt.

Innerhalb jedes Vorgangs werden Informationen über die beteiligten Perso-nen und Systeme gespeichert. Bei diesen Informationen handelt es sich umsogenannte Stammdaten, die im SAP Solution Manager gepflegt sein müs-sen. Für die beteiligten Personen sind somit entsprechend Geschäftspartnerund für die betreuten Systeme Informationen in der Installed Base (IBase) zupflegen. Detaillierte Informationen zur Konfiguration des Change RequestManagements erhalten Sie in Abschnitt 4.1.3, »Change Manager«.

2.3.1 Service-Desk-Meldung

Die von SAP ausgelieferte Vorgangsart für die Service-Desk-Meldung, derentechnische Bezeichnung SLFN lautet, stellt eine eigene Funktionalität im SAPSolution Manager ab. Mithilfe der Service-Desk-Funktionalität können Pro-blemmeldungen entweder direkt im SAP Solution Manager oder in einemangeschlossenen Satellitensystem erstellt werden. Endanwender habensomit die Möglichkeit, Fehler oder Probleme zu melden und diese Informa-tionen zentral im SAP Solution Manager abzulegen, wo diese Informationendann von der Service-Organisation bearbeitet werden.

Endanwender können dabei über eine webbasierte Oberfläche (Work Cen-ter) jederzeit den aktuellen Status ihrer Service-Desk-Meldung einsehen undgegebenenfalls darauf reagieren. Ein Beispiel des Work Centers zeigt Abbil-dung 2.22.

Zu den Funktionen im Service Desk gehören die Möglichkeit, Meldungenzwischen verschiedenen Organisationseinheiten auszutauschen, der Zugriffauf eine eigene Lösungsdatenbank oder die Hinweissuche bei SAP sowie derdirekte Austausch mit der SAP-Support-Organisation. Ein Vorteil des ServiceDesks besteht darin, aus dem eigenen Service Desk heraus eine SAP-Kunden-meldung bei SAP zu erzeugen. Die Antwort von SAP wird ebenfalls direkt in



53

den Service Desk des SAP Solution Managers repliziert und kann dort sofortweiterverarbeitet werden.

Abbildung 2.22 Work Center für Incident Management

Ergibt die Analyse innerhalb des Service Desks, dass eine Korrekturmaß-nahme durchgeführt werden muss, kann der Mitarbeiter des Service Desksaus der Service-Desk-Meldung heraus einen Änderungsantrag erstellen.Abbildung 2.23 zeigt, wie aus einer Service-Desk-Meldung heraus in der Ser-vice-Vorgangstransaktion CRMD_ORDER ein Änderungsantrag erstellt wird.

In der sogenannten Aktionsliste können verschiedene Funktionen aufgeru-fen werden. Mittels der Aktion Änderungsdokument erstellen kann nundirekt ein Änderungsantrag erzeugt werden.

Hinweis

Die Bezeichnung der Aktion mit dem Wort Änderungsdokument ist an dieserStelle etwas irreführend, da hier ein Änderungsantrag erstellt wird. An diesenÄnderungsantrag wird sich, wie später noch zu sehen sein wird, ein Änderungsdo-kument anschließen.



54

Abbildung 2.23 Änderungsantrag aus einer Service-Desk-Meldung

2.3.2 Änderungsantrag (Change Request)

Der Änderungsantrag, dessen technische Bezeichnung im Customizing SDCRlautet, stellt den ersten Teilprozess des eigentlichen Change Request Manage-ments dar. Hauptaufgabe des Änderungsantrages ist die Dokumentation desAntrages sowie aller damit verbundenen Informationen. Diese können inPflichtinformationen und freiwillige Informationen unterteilt werden.

Um eine fehlerfreie Weiterverarbeitung im Change Request Management zugewährleisten, sind verschiedene Informationen unabdingbar. Dazu zähleneine Beschreibung des Antrages im entsprechenden Textfeld, Informationenzu den betroffenen Systemen, der Anwender, wie zum Beispiel der ChangeManager, sowie die Auswahl der Änderungsart. Die Änderungsart spezifi-ziert, mit welchem Vorgang die eigentliche Änderung durchgeführt wird.Zur Auswahl stehen hier die Normale Korrektur und die Administrations-

meldung. Für Wartungsprojekte gibt es zudem die Option, auch eine Drin-

gende Korrektur durchzuführen.

Freiwillige Informationen im Änderungsantrag sind Datumsangaben, zusätz-liche Benutzerinformationen, Kategorisierungen sowie zusätzliche Textinfor-mationen, wie zum Beispiel die Auswirkung auf Geschäftsprozesse oder Sys-teme. Des Weiteren können Dokumente als Attachment dem Antrag zugefügtwerden.

Ziel des Änderungsantrages ist die Genehmigung oder Ablehnung einesAntrages. Um die verschiedenen Schritte von der Erstellung eines Antrages



55

bis hin zur finalen Entscheidung kenntlich zu machen, steht ein Statusprofilzur Verfügung. Dieses Statusprofil enthält verschiedene Statuswerte, die imÄnderungsantrag als sogenannter Anwenderstatus angezeigt werden. Abbil-dung 2.24 zeigt anhand eines Ausschnitts aus der Service-Vorgangstransak-tion (CRMD_ORDER), wo der Anwenderstatus vorzufinden ist.

Abbildung 2.24 Anwenderstatus im Änderungsantrag

Der von SAP ausgelieferte Standardprozess enthält folgende Statuswerte: ZuGenehmigen, Zurückgewiesen, Genehmigt, Realisiert und Bestätigt.

Sollten diese Statuswerte nicht ausreichen, um den Prozess eines Änderungs-antrages abzubilden, kann das entsprechende Statusprofil leicht erweitertbzw. angepasst werden. Jeder Kunde hat in der Regel einen spezifischen Pro-zess für den Änderungsantrag. Oftmals gilt es, verschiedene Abteilungenoder Partner in diesen Prozess mit einzubeziehen, um am Ende des Ände-rungsantrages eine gesicherte Entscheidung über die Durchführung bzw.Ablehnung treffen zu können.

Tipp: Änderung des Statusprofils

Ändern Sie nicht das von SAP ausgelieferte Statusprofil! Kopieren Sie stattdessendas Statusprofil (SDCRHEAD) in den Kundennamensraum. Führen Sie die Ände-rungen im kopierten Profil durch, und weisen Sie anschließend das neue Sta-tusprofil, zum Beispiel ZDCRHEAD, der Vorgangsart SDCR zu.

In der IMG-Aktivität SOLMAN_CM_GENERAL finden Sie zudem noch einmal den Hin-weis, bei Verwendung eines eigenen Profils immer ein SAP-Profil als Kopiervorlagezu nutzen.



56

Zum Schluss wird noch einmal auf die im Änderungsantrag zu spezifizie-rende Änderungsart zurückzukommen sein. Wie bereits beschrieben, gehörtdie Auswahl einer Änderungsart zu den Pflichtangaben in einem Änderungs-antrag. Fehlen Pflichtinformationen oder sind Informationen falsch eingetra-gen, erscheint im rechten oberen Bereich der Service-Vorgangstransaktioneine rote Ampel. Nach einem Klick auf dieses Ampelfeld erhalten Sie eineBeschreibung des Fehlers. Abbildung 2.25 zeigt beispielhaft die Fehlermel-dung bei fehlender Änderungsart im Änderungsantrag.

Abbildung 2.25 Fehlermeldung im Änderungsantrag

Die Änderungsart wird im Feld Sachverhalt ausgewählt und bietet alle zurVerfügung stehenden Änderungsarten an. Änderungsarten wurden bereits zuBeginn des Abschnitts 2.3, »Vorgangsarten/Workflows«, vorgestellt, denn diezur Auswahl stehenden Änderungsarten sind die Vorgangsarten Normale

Korrektur, Dringende Korrektur und Administration. Für Einführungs-projekte, Vorlagenprojekte und Upgrade-Projekte wird statt der Formulie-rung Normale Korrektur der Begriff Entwicklung bzw. Entwicklungstä-

tigkeit verwendet. Dies erfolgt lediglich zu einem besseren Verständnis, dadiese Projekte keine Korrekturen, sondern neue Entwicklungen etablieren.Technisch handelt es sich um die Vorgangsart der normalen Korrektur (sieheAbschnitt 2.3.4, »Normale Korrektur/Entwicklungstätigkeit«).

Zusammenfassend stehen folgende Änderungsarten zur Verfügung:

� Einführungs-/Implementierungsprojekt, Vorlagenprojekt, Upgrade-Projekt

� Entwicklung/Entwicklungstätigkeit

� Administration

� Wartungsprojekt

� Normale Korrektur

� Dringende Korrektur

� Administration



57

Abbildung 2.26 zeigt das Auswahlmenü für die Änderungsarten.

Abbildung 2.26 Sachverhalt im Änderungsantrag

Nach Eingabe aller Pflichtinformationen kann im Änderungsantrag eineAktion zum Ablehnen oder Genehmigen des Antrages ausgeführt werden.Diese Aktionen werden in der Aktionsliste des Änderungsantrages darge-stellt und führen nach der Auswahl zu einem entsprechenden Statuswert.Abbildung 2.27 zeigt die Aktionsliste zur Genehmigung oder Ablehnung desÄnderungsantrages.

Abbildung 2.27 Genehmigung des Änderungsantrages

Wird der Änderungsantrag abgelehnt, wird automatisch der AnwenderstatusZurückgewiesen gesetzt und das Dokument damit geschlossen. Es sind nunkeine weiteren Änderungen am Dokument mehr möglich. Bei Genehmigungdes Änderungsantrages wird der Anwenderstatus Genehmigt gesetzt.

Im Hintergrund werden in diesem Fall weitere Aktivitäten durchgeführt.Zunächst wird ein Folgevorgang zum Änderungsantrag angelegt, analog zurAktivität zwischen der Service-Desk-Meldung und dem Änderungsantrag.Welcher Vorgang angelegt wird, wurde zuvor durch die Auswahl des Sach-verhaltes spezifiziert, zum Beispiel eine dringende Korrektur. Anschließend



58

sucht das Change Request Management nach einem Projekt- oder Wartungs-zyklus für das im Änderungsantrag angegebene System. Existiert nur ein Pro-jekt- bzw. Wartungszyklus für das System, wird dies automatisch dem Folge-dokument zugewiesen. Sollten jedoch mehrere Projekt- oder Wartungszyklenfür ein System existieren, fordert das System per Auswahlmenü zur Auswahleines Projekt- bzw. Wartungszyklus auf.

Sind all diese Aktionen erfolgreich durchgeführt worden, befindet sich derÄnderungsantrag anschließend im Status Genehmigt. In diesem Status sindkeine weiteren Aktivitäten im Änderungsantrag möglich. Der Change-Request-Management-Prozess wird nun im Folgevorgang, dem Änderungs-dokument, weitergeführt.

2.3.3 Änderungsdokument (Change Document)

Das Änderungsdokument ist eine begriffliche Klammer für die Vorgangsar-ten der dringenden Korrektur, der normalen Korrektur, Administration undTestmeldung. Wie in Abbildung 2.28 dargestellt, fallen darunter alle Vor-gangsarten, die mit der technischen Umsetzung eines Änderungsantragesbetraut sind.

Abbildung 2.28 Änderungsdokumente

Dies macht noch einmal die generelle Unterteilung des Change-Request-Management-Prozesses deutlich. Der Änderungsantrag ist für die Dokumen-tation und Organisation von Anträgen verantwortlich. Der Fokus liegt hierauf der Informationssammlung und Dokumentation mit abschließenderGenehmigung oder Ablehnung. Die Änderungsdokumente sind anschlie-ßend für die Umsetzung eines genehmigten Änderungsantrages verantwort-

Change-Prozess

Service-Desk-

Meldung

ChangeRequest

DringendeKorrektur

NormaleKorrektur

Administration

Testmeldung

Änd

erun

gsdo

kum

ente



59

lich. Da es verschiedene Prozesse für die Implementierung einer Änderunggibt, existieren die bekannten Vorgangsarten der normalen Korrektur, derdringenden Korrektur und der Administrationsmeldung.

2.3.4 Normale Korrektur/Entwicklungstätigkeit

Die normale Korrektur, die im Rahmen von Einführungs-, Vorlagen- undUpgrade-Projekten auch als Entwicklungstätigkeit bezeichnet wird, stellt dentypischen Prozess einer Änderungs- oder Neuimplementierung dar. Der Haupt-teil aller Änderungen sollte mit dieser Vorgangsart durchgeführt werden.

Der technische Name für diese Vorgangsart lautet SDMJ. Unter der Bezeich-nung SDMI ist im SAP Solution Manager eine weitere Vorgangsart mit demNamen Normale Korrektur zu finden. Dabei handelt es sich um die erste Ver-sion dieses Vorgangs, die auch jetzt noch genutzt werden kann. Verbesserun-gen hinsichtlich des Prozesses und der Funktionalität haben in der Zwischen-zeit zu der neuen Version SDMJ geführt, die heute als der von SAPempfohlene und gewartete Standard gilt.

Unterschiede zwischen SDMI und SDMJ

Der Hauptunterschied zwischen den beiden Vorgangsarten besteht in der Übergabeder Korrektur von der Entwicklung zum Test. In der Version SDMI wird nachAbschluss der Entwicklungstätigkeit der entsprechende Transportauftrag freigege-ben und kann anschließend in das Qualitätssicherungssystem importiert werden. Istder Test im Qualitätssicherungssystem fehlerhaft, muss der Entwickler einen neuenTransportauftrag im Entwicklungssystem erstellen und das Prozedere wiederholen.

Neben der Vielzahl von Transportaufträgen, die so entstehen können, kommt esaufgrund der Methodik im Transportmanagement-System zu der Situation, dassalle Testtransporte in das Qualitätssicherungssystem anschließend auch im Import-puffer des Produktionssystems stehen. Sollte die Korrektur bis zum Ende des Pro-jekt- bzw. Wartungszyklus nicht fehlerfrei getestet werden, so könnte der Entwick-ler gezwungen sein, die noch fehlerhaften Entwicklungen am Ende des Zyklus indas Produktionssystem zu importieren.

Die Version SDMJ umgeht diese Problematik, indem zwischen dem Entwicklungs-system und dem Qualitätssicherungssystem zunächst nur ein Transport von Kopiendurchgeführt wird. Kopien der Änderungen werden somit in einem neuen Trans-portauftrag transportiert. Dieser Transportauftrag wird nur in das Folgesystemimportiert, aber nicht in das Produktionssystem weitergeleitet. Das bedeutetzugleich, dass der originale Transportauftrag im Entwicklungssystem bestehenbleibt, solange die Korrektur nicht erfolgreich getestet wird. Erst nach erfolgrei-chem Test wird der originale Transportauftrag freigegeben und kann anschließendnoch einmal in das Qualitätssicherungssystem importiert werden. Dort kann zueinem späteren Zeitpunkt, während der Testphase des gesamten Projektes, einIntegrationstest erfolgen.



60

Innerhalb der normalen Korrektur können verschiedene Anwender desChange-Request-Management-Prozesses aktiv werden. In der Regel sind diesder Change Manager, der Entwickler, Tester und IT-Operator. Detailinfor-mationen zu den Rollen im Change Request Management finden Sie inAbschnitt 4.1, »Rollen und Aktivitäten«.

Innerhalb der normalen Korrektur können die genannten Anwender, zumBeispiel der Entwickler, die Korrektur in Entwicklung nehmen (siehe Abbil-dung 2.29) und anschließend Transportaufträge im Entwicklungssystemgenerieren, die später die Änderung aufnehmen.

Abbildung 2.29 Normale Korrektur

Aus dem Dokument der normalen Korrektur heraus kann direkt in das Ent-wicklungssystem gesprungen werden, um dort die Korrektur oder Entwick-lungsmaßnahmen durchzuführen. Änderungen können anschließend direktin die bereits existierenden Transportaufträge gespeichert werden.

Nach Abschluss der Entwicklungstätigkeiten kann die normale Korrekturzum Test übergeben werden. Die Änderung wird dabei automatisch im Ent-wicklungssystem freigegeben und kann anschließend in das Qualitätssiche-rungssystem importiert werden. Steht die Korrektur oder Entwicklung zumTest bereit, kann aus dem Dokument der normalen Korrektur heraus direktin das Qualitätssicherungssystem gesprungen und der Test durchgeführtwerden. Anschließend kann in der normalen Korrektur der Test als erfolg-reich bzw. nicht erfolgreich gewertet werden.



61

Ein nicht erfolgreicher Test führt zu einem Zurücksetzen in den Entwick-lungsstatus, während ein erfolgreicher Test das Änderungsdokument in denStatus Konsolidiert versetzt. Dieser Zustand kennzeichnet einen erfolgrei-chen Test und ermöglicht den Import der Änderung in das Produktivsystem.Dies geschieht in der Regel am Ende des Projekt- bzw. Wartungszykluszusammen mit allen anderen Änderungsdokumenten und sollte durch einenIT-Operator durchgeführt werden.

Nach erfolgreichem Import aller Änderungen in das Produktivsystem kön-nen die einzelnen Änderungsdokumente abgeschlossen werden, indem derAnwenderstatus von Konsolidiert auf Produktiv gesetzt wird. Dies kannentweder manuell oder automatisiert mit einem Report erfolgen.

Die verschiedenen Anwenderstatus einer normalen Korrektur zur Darstel-lung der unterschiedlichen Teilschritte sind: Angelegt, In Entwicklung, ZuTesten, Konsolidiert, Produktiv und Zurückgezogen. Mithilfe dieser Status-werte werden die einzelnen Schritte innerhalb der normalen Korrektur abge-bildet und ermöglichen somit eine allgemeine Übersicht sowie eine schnelleOrientierung für die Anwender.

In Abbildung 2.30 und Abbildung 2.31 finden Sie eine Übersicht, welcheAktivitäten im Dokument einer normalen Korrektur während der verschie-denen Phasen eines Projekt- bzw. Wartungszyklus möglich sind.

� Abbildung 2.30 demonstriert, dass in einem Projekt (Einführungs-, Vorla-gen- bzw. Upgrade-Projekt) die normale Korrektur nur in den Entwick-lungsphasen erstellt und transportiert werden kann. Ist die Phase Testerreicht, so können notwendige Nachbesserungen/Korrekturen durch dieTestmeldung (siehe Abschnitt 2.3.7, »Testmeldung«) durchgeführt werden.Beim Übergang in die Phase Test müssen alle Korrekturen entweder imEntwicklungssystem freigegeben oder zurückgezogen worden sein. Even-tuell notwendige Korrekturmaßnahmen können in den Phasen Test undNotkorrektur noch ausgeführt werden, jedoch ist die Erstellung von Trans-portaufträgen nur zentral im Aufgabenplan des Projektes möglich. Darü-ber hinaus zeigt die Abbildung, dass nur in der Phase Go-Live ein Import indas Produktionssystem erfolgen kann.

Hinweis

Detaillierte technische Informationen zur Administration und Anwendung desChange Request Managements finden Sie in Kapitel 5, »Sicherheit im ChangeRequest Management«, sowie in Kapitel 8, »Technische Hinweise zur Nutzung undFehlerbehebung«.



62

Abbildung 2.30 Projektphasen und die normale Korrektur

� Abbildung 2.31 zeigt die normale Korrektur in einem Wartungsprojekt.Dort ist die Erstellung und Bearbeitung einer normalen Korrektur jeder-zeit möglich. Hat der Wartungszyklus jedoch die Phase Test erreicht, wer-den normale Korrekturen, die in dieser Phase und den folgenden erstelltwerden, nicht mehr im aktuellen Wartungszyklus verwendet. Diese Kor-rekturen werden in den nächsten Zyklus integriert und können innerhalbdieses Zyklus in das Produktionssystem transportiert werden.

Abbildung 2.31 Phasen des Wartungsprojektes und die normale Korrektur

Der Export einer normalen Korrektur ist innerhalb eines Dokumentes nurin der Phase Entwicklung mit Freigabe möglich. Sobald die Phase Test

NormaleKorrektur

Phase

Antrag Geneh-migung

In Entwicklung

Freigabe Entwicklung abschließen

An Test geben

Produktions-import

Angelegt O X X X X X XEntwicklung ohne Freigabe O O O X X X XEntwicklung mit Freigabe O O O O O O XTest X X X X X X XNotkorrektur X X X X X X XGo-Live X X X X X X OIm Abschluss X X X X X X XAbgeschlossen X X X X X X X

Projekte (Einführungs-, Vorlagen- und Upgrade-Projekt)

Projekte (Wartungsprojekt)NormaleKorrektur

Phase

AntragGeneh-migung

In Entwicklung

FreigabeEntwicklung abschließen

An Test geben

Produktions-import

Angelegt O X X X X X XEntwicklung ohne Freigabe O O O X X X XEntwicklung mit Freigabe O O O O O O XTest O O O X X X XNotkorrektur O O O X X X XGo-Live O O O X X X OIm Abschluss X X X X X X XAbgeschlossen X X X X X X X



63

erreicht ist, können normale Korrekturen des Wartungszyklus aus einemDokument heraus nicht mehr freigegeben werden. Dies stellt sicher, dassin der Phase Test und somit während des Integrationstests keine Änderun-gen in das Qualitätssicherungssystem transportiert werden.

Das hier beschriebene Verhalten der normalen Korrektur stellt die mögli-chen Aktionen innerhalb eines Dokumentes der normalen Korrektur dar.

Der zentrale Aufgabenplan des Wartungszyklus bietet dem IT-Operator oderProjektleiter die Möglichkeit zu Korrekturmaßnahmen. So ist es in den Pha-sen Test und Notkorrektur auch noch möglich, mithilfe des AufgabenplansTransportaufträge anzulegen und in das Testsystem zu transportieren. Diesstellt eine Ausnahmesituation dar, bietet jedoch zugleich die Flexibilität, inder sprichwörtlich letzten Minute noch notwendige Maßnahmen durchzu-führen. Zudem sollte nur der IT-Operator oder Projektleiter dazu berechtigtsein, diese Maßnahmen auszuführen.

2.3.5 Dringende Korrektur

Die nur im Wartungsprojekt verfügbare dringende Korrektur stellt einenVorgang dar, bei dem eine Änderung umgehend in das Zielsystem transpor-tiert werden muss. Sie bietet somit eine Möglichkeit, innerhalb eines War-tungszyklus eine Änderung vor Ende des Zyklus in das Produktivsystem zutransportieren. Dass dieses Verfahren zu keinen Problemen insbesonderehinsichtlich der Datenkonsistenz führt, wird später noch näher erläutert.

Die dringende Korrektur, deren technische Bezeichnung SDHF lautet, ist einteilweise automatisierter Vorgang. Während in der normalen Korrektur zahl-reiche Aktivitäten durch die spezifische Auswahl der Anwender erfolgt, fin-den in der dringenden Korrektur viele Aktivitäten automatisch statt. ZumBeispiel werden in einer dringenden Korrektur sofort Transportaufträgegeneriert, nachdem die Korrektur in Entwicklung genommen wurde. Zudemkann eine einzelne dringende Korrektur innerhalb des Dokumentes bis indas Produktivsystem transportiert werden. Bei einer normalen Korrekturwird dieser letzte Schritt zentral für alle normalen Korrekturen von einemIT-Operator am Ende eines Projekt- bzw. Wartungszyklus ausgeführt.

Die Gründe für diese Flexibilität bestehen im individuellen Aufgabenplaneiner dringenden Korrektur. Wie bereits in Abschnitt 2.2.4, »Projektzyklusund Aufgabenplan«, beschrieben, haben in der Regel nur die Projekt- bzw.Wartungszyklen einen Aufgabenplan. Werden Änderungen vom Typ einernormalen Korrektur, einer Testmeldung oder Administration in einem Pro-



64

jekt- oder Wartungszyklus ausgeführt, bestimmt die aktuelle Phase desZyklus darüber, ob es zum Beispiel möglich ist, eine normale Korrektur frei-zugeben oder eine Testmeldung anzulegen. Phasen von Zyklen bestimmensomit den Rahmen von möglichen Aktivitäten. Um unabhängig von diesenRestriktionen zu agieren, besitzt die dringende Korrektur einen eigenen Auf-gabenplan.

Die möglichen Anwenderstatus der dringenden Korrektur sind: Angelegt, InEntwicklung, Zu Testen, Erfolgreich getestet, Genehmigt für Import, Produk-tiv, Bestätigt, Abgeschlossen und Zurückgezogen. Abbildung 2.32 verdeut-licht, dass eine dringende Korrektur jederzeit erstellt und bearbeitet werdenkann. Dies gilt bis zur Phase Notkorrektur. In der Phase Go-Live kann einedringende Korrektur zwar erstellt werden, jedoch ist ein Export der dringen-den Korrektur nicht möglich.

Abbildung 2.32 Phasen der Wartungsprojekte und dringende Korrektur

2.3.6 Administrationsmeldung

Die Administrationsmeldung mit der technischen Bezeichnung SDAD dientder Dokumentation von Aktivitäten, die nicht zu Transportaufträgen führen.Dies ist zum Beispiel die Änderung von Nummernkreisen oder die Pflegevon Stammdaten. Eine Administrationsmeldung betrifft daher auch immernur ein ausgewähltes System und nicht wie bei den normalen oder dringen-den Korrekturen den Systemverbund aus Entwicklungs-, Qualitätssiche-rungs- und Produktionssystem. Ziel der Administrationsmeldung ist dieDokumentation dieser spezifischen Änderungen. Somit ist jederzeit nach-vollziehbar, wer welche Änderungen auf den Systemen durchgeführt hat.

Dringende Korrektur

Phase

Antrag Geneh-migung

In Entwicklung

Freigabe Zum Test geben

Import in Produktion freigeben

Produktions-import

Angelegt O X X X X X XEntwicklung ohne Freigabe O O O O O O OEntwicklung mit Freigabe O O O O O O OTest O O O O O O ONotkorrektur O O O O O O OGo-Live O O O X O O OIm Abschluss X X X X X X XAbgeschlossen X X X X X X X

Projekte (Wartungsprojekt)



65

Die Statuswerte einer Administrationsmeldung sind: Angelegt, In Bearbei-tung, Erledigt, Bestätigt und Zurückgezogen. Prinzipiell verfügt eine Admi-nistrationsmeldung über die gleiche Funktionalität wie eine normale oderdringende Korrektur. Es ist möglich, direkt aus einer Administrationsmel-dung heraus in das entsprechende System zu springen und in verschiedenenTextarten adäquate Dokumentationen zu erfassen. Lediglich Funktionalitä-ten mit Bezug zum Transportmanagement-System sind in der Administrati-onsmeldung nicht vorzufinden.

Abbildung 2.33 zeigt mögliche Aktivitäten einer Administrationsmeldung inAbhängigkeit von der jeweiligen Phase des Projektzyklus.

Abbildung 2.33 Projektphasen und die Administrationsmeldung

2.3.7 Testmeldung

Wie bereits in Abschnitt 2.3, »Vorgangsarten/Workflows«, beschrieben,nimmt die Testmeldung eine Sonderstellung ein. Die Vorgangsart der Test-meldung, deren technische Bezeichnung SDTM lautet, wird ohne Bezug zueinem Änderungsantrag erstellt. Die Testmeldung dient der Fehlerbehebungin einem Integrationstest und ist somit nur in der Phase Test eines Projekt-bzw. Wartungszyklus möglich.

Da es sich bei der Testmeldung um die Korrektur einer schon genehmigtenÄnderung handelt, wird hier auf einen Änderungsantrag vollends verzichtet.Akteure in einer Testmeldung sind der Entwickler und der Tester. Währendeines Integrationstests kann ein Tester mit der Transaktion TEST_CREATEeine Testmeldung erstellen. Anschließend kann ein Entwickler eine entspre-

Administration

PhaseAntrag

Geneh-migung

In Entwicklung Freigabe

Zum Test geben


Produktions-import

Angelegt O X X X X XEntwicklung ohne Freigabe O O O OEntwicklung mit Freigabe O O O OTest O O O ONotkorrektur O O OGo-Live O O O OIm Abschluss X X X X X X XAbgeschlossen X X X X X X X

Alle Projektarten



66

chende Korrektur im Entwicklungssystem erzeugen und zum erneuten Testan den Tester überstellen. Nach dem Import der Korrektur in das Qualitäts-sicherungssystem kann der Tester einen erneuten Test, nun inklusive derNachkorrektur, durchführen. Ist der Test erfolgreich, so ist damit auch dieTestmeldung abgeschlossen.

Die folgenden Anwenderstatus sind für die Testmeldung möglich: Angelegt,In Bearbeitung, Nachzutesten, Bestätigt und Zurückgezogen. Abbildung 2.34zeigt abschließend, dass nur in der Phase Test eines Projektzyklus die Erstel-lung und Bearbeitung einer Testmeldung möglich ist.

Abbildung 2.34 Projektphasen und Testmeldung

2.3.8 Jobantrag/Job Request

Sofern Sie die Erweiterung Job Scheduling Management mit SAP Central Pro-cess Scheduling by Redwood im Einsatz haben, kann diese ebenfalls in Verbin-dung mit dem Change Request Management genutzt werden. Sie habendann die Möglichkeit, mithilfe der Service-Desk-Meldung einen Jobantragzu dokumentieren und Änderungen an einer Jobdokumentation im ChangeRequest Management zu bearbeiten. Im Rahmen des Änderungsantrageskann ein Jobantrag bearbeitet und genehmigt werden. Eine entsprechendeJobdokumentation wird anschließend in einem Änderungsdokument bear-beitet und dokumentiert.

Testmeldung

PhaseAntrag

Geneh-migung

In Entwicklung Freigabe

Zum Test geben


Produktions-import

Angelegt O X X XEntwicklung ohne Freigabe O X X XEntwicklung mit Freigabe O X X XTest O O O O ONotkorrektur O X X XGo-Live O X X XIm Abschluss X X X X X X XAbgeschlossen X X X X X X X

Alle Projektarten


Zusammenfassung 2.4

67

2.3.9 Änderungsvorgänge für Projekte

Die Änderungsvorgänge für Projektzyklen und Wartungszyklen werdendurch die Vorgangsarten SDDV und SDMN abgebildet. Entsprechend denErläuterungen in Abschnitt 2.2.4 bestehen Projektzyklen, gleich welchenProjekttyps, aus einem generierten Aufgabenplan und einem Änderungsvor-gang.

Der Änderungsvorgang eines Projektes sollte für das Wechseln von einerPhase in die nächste genutzt werden und folgt dabei den schon bekanntenPhasenwerten: Angelegt, In Entwicklung ohne Freigabe, In Entwicklung mitFreigabe, Test, Notkorrektur, Go-Life, Im Abschluss, Abgeschlossen undZurückgezogen. Eine Darstellung, welche Aktivitäten während der unter-schiedlichen Projektphasen möglich sind, können Sie den vorangegangenenAusführungen entnehmen.

2.4 Zusammenfassung

In diesem Kapitel haben Sie die verschiedenen Bestandteile der Change-Request-Management-Funktionalität kennengelernt. Neben der Einordnungin den SAP Solution Manager wurden die Projektverwaltung und der Pro-jektzyklus vorgestellt. Anschließend erfolgte eine Beschreibung der verschie-denen Vorgänge im Change Request Management. Im weiteren Verlauf desBuches werden diese Bestandteile immer wieder aufgegriffen und detailliertbeschrieben.


287

Index

A

ABAP-Dictionary-ObjektRetrofit 139

AbfrageWork Center 176

Ablauflogik 232Abschlussaufgabe

Aufgabenplan 148, 158Administration 63

Change Request Management 147Administrationsmeldung 56

Change Request Management 52, 54Vorgangsart 59, 64

AdministratorBerechtigung 81

Aktion 98, 99, 127, 240Aufgabenplan 159Definition 96Liste 53, 57, 120, 152Profil 96Vorrat 96

AktivierungLog 136Protokoll 76, 144systemübergreifende Objektsperre 89

Änderungsantrag 19, 35, 52, 54, 55, 57, 58, 66, 113, 120Anlage 117Genehmigung 121Hot News 140Request for Change 18Verwaltung 74, 98Work Center 175, 176, 177

Änderungsdokument 58, 61, 124, 177Change Request Management 35Vorgangsart 58Work Center 175, 177

Änderungsverfolgung 162Änderungsvorgang 46, 67, 118

Art 90, 97Aufgabenplan 158Partnerfunktion 111Projektzyklus 153

Anforderer 112, 119, 130

Beispielprozess 133Partnerfunktion 112

AnwendergruppePartnerfunktion 111, 116

Anwenderstatus 61, 64, 122, 127, 128abgeschlossener 131bestätigter 130, 132Statusprofil 55Statusschema 94Testmeldung 66

AnzeigelisteVorgangsmonitor 174

Application Log 165, 190, 278Application Management 21Architektur 33, 38Attachment 126Aufgabe

Freigabe 126Aufgabenplan 50, 63, 85, 139, 147, 150,

152, 266Change Request Management 35dringende Korrektur 149Erstellung 108kundenspezifischer 85Nummernkreis 83Schedule Manager 46, 85Sperre 151

Auftrageigener 125

Auftraggeber 116, 119Partnerfunktion 112

AuftragsanalyseÄnderungsverfolgung 164

Auftragsattribut 82Ausführungsoption

BC-Set 136Ausführungszeit

Aktion 99Ausgangssystem 138Auswertung

Kriterium 168Work Center 176

Availability ManagementITIL 26


288

Index

B

BAdICRM_CUSTOMER_H_BADI 227CRM_DNO_MONITOR 238CRM_ORDER_AUTH_CHECK 184SOCM_CHECK_CONDITION 244SOCM_PROCESS_ACTION 251

BAdI-ErweiterungAktion 99Konsistenzprüfung 100

BCOS_CUST 188BC-Set 75, 101, 134, 136, 144

Retrofit 139Bearbeiter

aktueller 116, 127Partnerfunktion 112

Bedingung 98Aktionsprofil 96Definition 242Konsistenzprüfung 100Statuswert 100

BedingungseditorAktionsprofil 97

Beispielprozess 132Belegfluss 51, 121, 132, 159Berechtigung 181

erweiterte 184Objekt 105Reporting 170Rolle 181

BetriebLebenszyklus 23

Bildschirmsteuerung 234Browser 180Build-Phase 261Business Add-in � BAdIBusiness Configuration Set � BC-SetBusiness Process and Interface

MonitoringWork Center 174

Business Process Change Analyzer 259Business Process Monitoring 23, 141

C

Capacity ManagementITIL 26

Change Advisory Board 19, 114Partnerfunktion 112

Change Analysis 259Change Management 113, 255

ITIL 28Work Center 174

Change Manager 19, 29, 60, 113, 119, 121, 130, 191, 193Beispielprozess 133Partnerfunktion 112Retrofit 134

Change Request 29Prozess 35

Change Request Management 18, 25, 29, 33, 44, 54, 69, 73, 224Konfiguration 128logische Komponente 103Projektverwaltung 30Prozess 58, 60Reporting 169Vorgangsart 97

Check-In 145, 146Geschäftsprozess 36

Check-Out 145, 146Geschäftsprozess 36

Check-Report 109Close Coupling 214Code 91

Gruppe 91Gruppenprofil 91

Configuration ManagementITIL 17, 28

cProjects 40, 45, 49, 89, 90, 153CRM_CUSTOMER_H_BADI 227CRM_DNO_MONITOR 238CRM_ORDER_AUTH_CHECK 184CRMC_MAP 227, 230CRMC_MSGC 243, 247CRMC_MSGS 243, 247CTS+ 205, 212, 216, 222, 224

Double-Stack-Landschaft 218verteilte Systemlandschaft 219

CTSDEPLOY 207CTS-Projekt 40, 41, 43, 44, 82, 126, 158,

159, 160, 162Projektzuordnung 82

CTS-StatuswechselProjektlogistik 167


289

Index

CustomizingAuftrag 126globales 205regionales 205Transportauftrag 124

Customizing-Verteilunglogisches System 102

Cutover 134, 203, 204

D

Datenkollektor 169, 170Datenkonsistenz 63Dauerart 94Deploy Web Service 207, 209, 216, 220Deploy-Phase 261Deploy-Service 206Diagnostics

Root Cause Analysis 174Dictionary-Objekt 134Dokumentenmanagement

cProjects 90Domain Controller 71, 77, 79, 80

ABAP 207Domänen-Link 79, 216

Transportdomäne 80Double-Stack 205

Landschaft 218System 209Zielsystem 212

Downgrade 134, 194dreistufige Systemlandschaft 133, 193,

198, 201

E

EarlyWatch Alert 23, 26Einführungsprojekt 35, 39, 40, 47, 61Einplanbedingung

Aktionsprofil 96Einplanung 164

Analyse 164Aufgabe 152Projektlogistik 166

EinsatzChange Request Management 111

Einstellungszenariospezifische 73szenarioübergreifende 73

EinzeltransportTransportstrategie 78

E-Learning 23, 141Material 142

Enhancement Package 25, 256Enterprise Edition

SAP Solution Manager 142Entwickler 60, 114, 134

Beispielprozess 133Partnerfunktion 112Testmeldung 65

EntwicklungAnwenderstatus 128Change Request Management 56Nummernkreis 83Paket 225Phase 48, 61Projektzyklus 47Status 129System 59, 66, 122, 133Transportmanagement-System 77

ErgebnislisteReporting 169

Event Management 26ITIL 17

Exportprüfung 191kritisches Transportobjekt 87

F

Fehleranalyse 276Folgedokument 133Folgesystem 138, 148funktionaler Tester 115

G

GanttcProjects 49

Genehmigung 190, 192Anwenderstatus 129, 130kritischer Transport 155

Geschäftspartner 93Vorgangsmonitor 170


290

Index

Geschäftsprozess 23, 141, 145Solution Directory 143

Geschäftsprozessüberwachunglogische Komponente 102

Geschäftsszenario 23, 145globaler Namensraum 205globales Customizing 205globales Template 204Grundeinstellung

Aktion 99Konsistenzprüfung 100

Grundkonfiguration 71, 73

H

HinweisEinbau 156Reporting 170

Hot News 117, 139, 140, 178Work Center 175

HP Quality Center 259HTMLB 179

I

IBase 52, 71Komponente 71

ICF 178, 179IMG-Aktivität 41, 55, 72, 73

Nummernkreis 84IMG-Projekt 108Implementation and Upgrades

Work Center 174Implementation Guide � IMGImplementierung

Anwenderstatus 130Dokumentation 142Lebenszyklus 22

Implementierungsprojekt 30, 35, 40, 41, 42, 56

ImportBerechtigung 81Fehler 272fehlerhafter 153IT-Operator 115Projekt 275Subset 275

inaktives System 268

Incident Management 17, 26, 27, 52, 113Event Management 26Work Center 174

InformationVorgänger/Nachfolger 194

Information Technology Infrastructure Library � ITIL

Installed Base � IBaseInstanzprofil 179Integrationstest 65, 115, 200, 203, 267Internet Communication Framework �

ICFInternet-Service 180

Konfiguration 179Intervall

Nummernkreis 83Issue Management 27, 71IT Change Management 15, 17, 20

Monitoring 21IT Service Continuity Management 26IT Service Management � ITSMITIL 15, 21, 90

Änderungsantrag 18Change Advisory Board 19Change Manager 19Incident Management 17ITIL V3 16, 17, 25Request for Change 18, 20

IT-Operator 60, 63, 115, 129, 130, 147Beispielprozess 133Partnerfunktion 112

ITSM 16

J

Java-StackSystem 205

Job Scheduling Management 66Work Center 174

Jobantrag 66Jobdokumentation 66

K

Karteireiterkundeneigener 226

Katalog 91, 92


291

Index

Kategorie 172Kategorisierung 113Knowledge Warehouse 107, 142Komponente

Konfiguration 71logische 37, 102, 103, 105, 107, 138,

265, 270Kondition 240Konfiguration 69, 72

erweiterte 84, 161Projekt 153Transportmanagement-System 76Work Center 178

KonfigurationsknotenIMG 72

Konfliktanalyse 185Konfliktszenario

systemübergreifende Objektsperre 88Konsistenzprüfung 99, 109

Retrofit 135Kontext 144Kontrollfunktion

Change Manager 114Kopiersteuerung 98, 100, 101, 250Korrektur

Änderungsvorgang 48Bearbeitung 122Change Request Management 52, 54dringende 48, 56, 120, 124, 131, 149Maßnahme 61, 63normale 49, 56, 61, 63Prozess 117Synchronisierung 157Testübergabe 126Vorgangsart 59, 63Workbench 134, 135, 139

kritisches Transportobjekt 86kundeneigener Karteireiter 226Kundenmeldung 52Kundennamensraum

Vorgangsart 178

L

Landschaftglobale Entwicklung 203Komponente 104

LayoutVorgangsmonitor 172, 174

Lebenszyklus 16, 21, 27Projektzyklus 45SAP Solution Manager 33

Lizenzverwaltung 177Work Center 176

logische Komponente 265, 270logisches System 38, 42, 102, 103, 106Loose Coupling 213Lösung

Datenbank 27Reporting 169

M

Maintenance Optimizer 256, 257Work Center 175

Mandantlogisches System 103RFC-Verbindung 105

Mandanteneinstellung 161Mandantenkopie 267Modifikation 192

kritisches Transportobjekt 87Modul 233Monitoring 21, 168

Change Request Management 31

N

NachbearbeitungRetrofit 137System 138, 139Zuordnung 155

Nachfolgebeleg 121Nachverfolgung

Projektlogistik 167Namensraum

globaler 205regionaler 205

NavigationsbereichWork Center 177

Nicht-ABAP-Objekt 206, 208Nummernkreis 83, 91

Objekt 83


292

Index

O

OberflächeneinstellungPartnerschema 93

Objekterweiterte Konfiguration 161kritisches 162Reporting 31, 170

ObjektauswertungReporting-Service 87

Objektliste 189, 190, 191, 194, 195Objektsperre

Aktualisierung 189Information 189systemübergreifende 86, 88, 89, 162,

184, 186Szenario 185

Objektversion 134Optimierung

Lebenszyklus 25Optimierungsprojekt 36Organisationsdaten

Reporting 169Organisationseinheit 171

Vorgangsmonitor 172Organisationsmanagement 171Organisationsstruktur 69

P

PAI 231Modul 233

Paket 225parallele Phasenlandschaft 201parallele Systemlandschaft 129paralleles Projekt 200, 201paralleles System 273Parametertransaktion 172Partnerfunktion 93, 111, 116Partnerschema 93PBO 231, 237

Ablauflogik 232Modul 233

PersonalisierungsfilterWork Center 174

PhaseController 158, 271Projektzyklus 64, 67, 108, 150, 159

Steuerung 149Wartungszyklus 158Wechsel 150

Phasenlandschaftparallele 201

PhasenwertcProjects 50Projektzyklus 45, 67

PlanungProjektlogistik 167

PortCTSDEPLOY 207

Priorität 112, 177Vorgangsmonitor 172

Problem Management 18, 26, 27, 113Process After Input � PAIProcess Before Output � PBOProduktion

Anwenderstatus 129Produktionsleiter 116

Partnerfunktion 112Produktionssystem 133, 134, 138Produktivsystem 48, 61, 63

Transportmanagement-System 77Profilgenerator 137Profilparameter 179Projekt

Change Request Management 102paralleles 200, 201Work Center 175

Projektadministration 147, 153Projektverwaltung 34SAP Solution Manager 37

Projektanalyse 162, 164Projektart 35, 39Projektkopf

Reporting 169Projektlandschaft 202

Aufbau 269zweistufige 133

Projektleiter 63, 146Projektlogistik 166Projektmonitor

Logistik 167Projektphase

Projektzyklus 67Projektplanung

cProjects 90


293

Index

ProjektstatusschalterCTS-Projekt 44

ProjektstrukturLogistik 167

ProjekttypEinplanung 164

Projektüberschneidung 193Projektverwaltung 29, 30, 34, 107, 161Projektzuordnung 82, 162Projektzyklus 31, 40, 45, 50, 58, 61, 66,

108, 147, 151, 271Abschließen 279Abschluss 158Administrationsmeldung 65

Prozess 116Prozessdokumentation 142Prozessschritt 23Prüfbericht 101Prüfung 101

Aufgabenplan 159Reporting 31

Q

Qualitätssicherungssystem 48, 59, 63, 128, 133

Quality Gate 261Quality Gate Management 177, 256, 260

Phasen 261Quality Management 260Quality Manager 261

R

RealisierungAnwenderstatus 132

regionaler Namensraum 205regionales Customizing 205Regressionstest 198Reihenfolgeverletzung

Überholer 164Release 137Release Management 18, 28, 256Release Manager 114Release Package 28Release-Landschaft 200Reparatur-Flag 272

Report on Side-Effects 258Reporting 168

Change Request Management 31lösungsübergreifendes 176SAP Solution Manager 29Service 86, 87

Request for Change 20Änderungsantrag 18

Retrofit 129, 133, 136, 155, 202Funktionalität 130Objekt 137Prozess 133, 134, 138System 134, 135, 137, 138

RFC-Destination 81, 104Konfiguration 75

RFC-Verbindung 80, 81, 88, 104, 105, 139, 156Konfiguration 75

Rolle 173Change Request Management 111systemübergreifende Objektsperre 88Typ 154Work Center 178

RollenpflegeWork Center 76

Root Cause Analysis 23, 24, 174

S

Sachverhalt 56, 120, 172Profil 91

Safeguarding-Projekt 36Sandbox-System 199SAP Business Workflow 51SAP Download Manager 258SAP GUI 177, 178

Einstellung 178for HTML 177, 178, 179, 180

SAP NetWeaver 40SAP NetWeaver Application Server 71SAP NetWeaver Business Warehouse

Transport 274SAP NetWeaver Development Infrastruc-

ture 214SAP NetWeaver Portal 214SAP NetWeaver Process Integration 214,

215, 222SAP Service Marketplace 72


294

Index

SAP Solution Manager 22, 26, 28, 29, 31, 37, 40, 52, 59, 107, 174Änderungsdokument 35Application Management 21Applikation 117Aufgabenplan 35Betrieb 23Diagnostics 259Einplanung 165Enterprise Edition 142Implementierung 22ITIL 21Konfiguration 178Lebenszyklus 21Optimierung 25Reporting 168Solution Monitoring 23Ursachenanalyse 24Workflow 29

SAP Tutor 72, 117SAP-Basis 40SAP-Hinweis 283SAP-Infrastruktur 21SAP-Produkt

Systemlandschaftspflege 104SAP-Support-Organisation 52SAPSYS 281SAP-Transportmanagement 205SAP-Variante

Aufgabenplan 166Satellitensystem

Transportmanagement-System 76Schedule Manager 45, 85, 86

Aufgabenplan 46Schnellerfassung

Text Administration 95Scope-Phase 261Security Guide 181Seiteneffekt 258Selektionskriterium 170

Vorgangsmonitor 170Service Delivery

Work Center 174Service Desk 23, 24, 30, 71

Änderungsantrag 117Beispielprozess 133Meldung 52, 57, 66Mitarbeiter 113Partnerfunktion 112

SAP Solution Manager 52Vorgangsart 51

Service Level 24Service Level Management 25Service Level Reporting 24Service-Lebenszyklus 25Service-Vorgang

Monitor 170, 172Service-Vorgangstransaktion 51, 53, 55,

56, 140CRM 117, 119

SMSY_SETUP 270SOCM_CHECK_CONDITION 244SOCM_PROCESS_ACTION 251Software Lifecycle Manager 258Softwarelebenszyklus 141Softwarestatus

Änderungsverfolgung 164Solution Directory 35, 141, 142, 144,

145, 146, 255Solution Landscape and Operations Setup

Work Center 174Solution Monitoring 23Solution Reporting 24, 169

Service Level 24Sperreintrag

systemübergreifende Objektsperre 88Sperrinformation 188Splitscreen-Editor 136SPPFCADM 252Stakeholder 18Standardkonfiguration 74Standardprofil

Konfiguration 91Startbedingung

Aktionsprofil 96Status

Vorgangsmonitor 171Statusanzeige

Retrofit 134Statuseigenschaft 98

Schema 94Statusprofil 55Statusschalter 149Statusschema 94Statusverwaltung 93Statuswert

Administrationsmeldung 65Aufgabenplan 149


295

Index

Statusprofil 55Vorgangsmonitor 171

Steering CommiteeChange Advisory Board 114

StörungsbeseitigungITIL 26

Strukturelement 141, 144Stückliste 195Support Desk

logische Komponente 103Support Package 25, 256

Einspielen 157System

Hinzufügen 265inaktives 268logisches 38, 42, 102, 103, 106paralleles 273virtuelles 267, 270

SystemadministrationWork Center 174

Systemanalyse 162Änderungsverfolgung 164

Systemänderbarkeit 89, 161erweiterte Konfiguration 161Projektlogistik 167

Systemänderungsoption 162Systemanmeldung 154

Aufgabenplan 155Systemdaten

Reporting 169System-ID 102Systemkopie 267Systemlandschaft 138

Change Request Management 41dreistufige 133, 193, 198, 201Konfiguration 70Pflege 34, 37Projektadministration 37Retrofit 133SMSY 138vierstufige 200

SystemlandschaftspflegeIBase 71

Systemmonitoring 23Work Center 174

Systemrolle 138logische Komponente 106

Systemvergleich 268Systemverwaltung 23

T

TabelleBCOS_CUST 188

TagesübersichtAufgabenplan 151

Template 203Aufgabenplan 149globales 204

Template-Projekt 30Terminart 94Terminprofil 94Terminregel 94Test

Anwenderstatus 128Management 258Person 127Phase 261Planverwaltung 153Projektzyklus 47Testanleitung 126Testfall 141, 142Transport 267

Test Data Migration Server 267Test Workbench 259Tester 60, 115

Beispielprozess 133funktionaler 115Partnerfunktion 112

Testmeldung 63, 65Change Request Management 52Vorgangsart 65

TextAdministration 95Customizing 96Historie 124Objekt 95Schema 95Textart 95

TMSADM 183TMWFLOW/CHARMCHK 277TMWFLOW/CMSCONF 188, 191TMWFLOW/LOCKMON 187Track

Aufgabenplan 147, 155Transaktion

CRMC_MAP 227, 230CRMC_MSGC 243, 247CRMC_MSGS 243, 247


296

Index

SMSY_SETUP 270SPPFCADM 252TMWFLOW/CHARMCHK 277TMWFLOW/CMSCONF 188, 191TMWFLOW/LOCKMON 187

TransportAufgabe 154Aufgabenplan 159Historie 269Kopie 59, 157Protokoll 273Route 212, 221Überprüfung 157Verzeichnis 208

Transport Organizer Web UI 207, 209, 219

Transportauftrag 123, 131Anlage 155Freigabe 157Import 157Projektzuordnung 82Registrierung 154Reporting 170

Transportdomäne 71, 79, 80Konfiguration 70

Transportlandschafterweiterte 197

Transportmanagementerweitertes 205

Transportmanagement-System 59, 65, 76, 80Alert Monitor 154Berechtigung 81Importmonitor 154Konfiguration 209

Transportobjektkritisches 86, 190Reporting 170

Transportsteuerung 77Konfiguration 70

Transportstrategie 78Transportmanagement-System 78

TransportwegeTransportmanagement-System 77

Trusted RFC 124Berechtigung 282Verbindung 183

Trusted Service 79, 282

U

Überholer 164Übersicht

Work Center 175Unit-Test 201Upgrade-Projekt 30, 36, 39, 47, 56, 203Ursachenanalyse

Root Cause Analysis 24User

SAPSYS 281

V

Validating and Testing 27Variante

Aufgabenplan 85SAP0 276SAP1 276

Versionierung 273Vieraugenprinzip 20, 115, 128vierstufige Systemlandschaft 200virtuelles System 267, 270Visual Administrator 214Vorbereitung

Konfiguration 69Vorgangsart 51, 58, 59, 90, 144

Terminprofil 94Vorgangsdaten

Reporting 169Vorgangskopf

Text Administration 95Vorgangsmonitor 119, 122, 170

Erweiterung 238mein Team 171meine Abteilung 171

VorlagenberichtAufgabenplan 86

Vorlagenprojekt 30, 35, 39, 47, 56Vorproduktionssystem 200

W

Wartungsaktivität 256Wartungsdokumentation 256Wartungslandschaft 199, 202, 203Wartungsplanung 256


297

Index

Wartungsprojekt 30, 35, 39, 47, 48, 56, 62, 108, 139Nummernkreis 83

WartungsvorgangMaintenance Optimizier 176

Wartungszyklus 47, 48, 58, 61, 62, 63, 158Abschluss 158dringende Korrektur 117Einplanung 165Retrofit 137

Work Center 52, 76, 117, 118, 122, 174, 178

WorkbenchAuftrag 126Objekt 136Transportauftrag 124

Workflow 51Change Request Management 29

Z

ZyklusAbschluss 159


Documents

Change Request Management mit dem SAP Solution Manager · 2018-03-26 · der Change-Request-Management-Funktionalität zu verstehen, ist es daher erforderlich, die verschiedenen Bestandteile