IT-Projektmanagement im SAP Solution Manager

2.2 Change Request Management im Software-Lebenszyklus

Das Change Management als solches ist kein Prozess, der in nur einer Phase des Software-Lebenszyklus stattfindet.

Abbildung 2.1: Software-Lebenszyklus

Alle Phasen, die in Abbildung 2.1 dargestellt sind, werden unterstützt, weshalb es wichtig ist, eine ganzheitliche Betrachtung vorzunehmen. Daher möchte ich Ihnen nachfolgend die Aktivitäten in der jeweiligen Phase im Einzelnen vorstellen.

2.2.1 Planungsphase

Die Planungsphase unterteilt sich üblicherweise in die Unterphasen

• Anforderungen und
• Design.

In der Anforderungsphase werden alle Bedarfe bezüglich einer Anwendung gesammelt. Dies können Anpassungen an einer existierenden oder die vollständige Neuentwicklung einer Anwendung sein. Im ChaRM steht für die Dokumentation einer solchen Anforderung der Beleg Änderungsantrag zur Verfügung. Dieses Dokument wird im weiteren Verlauf der Designphase erweitert, z.B. um eine technische Spezifikation, neben der weitere Details im Änderungsantrag gepflegt werden können, wie etwa die Priorität, erwartete Auswirkungen auf existierende Prozesse oder das gewünschte Realisierungsdatum.

Am Ende der Planungsphase muss dann eine Entscheidung getroffen werden, welche der Änderungsanträge angenommen und in die Entwicklungsphase übernommen werden. Diese Entscheidung ist ebenfalls Teil des Änderungsantrags. Abhängig von definierten Genehmigungsprozeduren eines Unternehmens, können ein oder mehrere Entscheider in deren Annahme oder Ablehnung involviert sein. Nach der Annahme eines Antrags erfolgt die Übergabe in ein Änderungsdokument, welches automatisch verlinkt wird. Dies sorgt für einen konsistenten Belegfluss und sichert eine spätere Nachvollziehbarkeit von Änderungen.

2.2.2 Umsetzungsphase

Die Umsetzungsphase ist ebenfalls in zwei Teilphasen untergliedert:

• Entwicklung und
• Test.

Die Entwicklungsphase schließt sich unmittelbar an die Planungsphase an. Alle Informationen, die bereits im Änderungsantrag gepflegt worden sind, sollten auch im Änderungsdokument per Kopiersteuerung enthalten sein. Das Änderungsdokument ist ein generischer Begriff, der den Änderungsprozess definiert, welcher zuvor im Änderungsantrag bestimmt wurde. Im Change Request Management unterscheiden wir die folgenden vier Änderungsprozesse:

1. Normale Änderung
   Als normale Änderung werden alle Modifikationen klassifiziert, in denen Änderungs- oder Neuentwicklungen vorgenommen werden, die bei einem späteren Go-Live mit anderen normalen Änderungen zeitgleich und konsolidiert als Release produktiv gesetzt werden. Mit dieser Änderungsart sollte der Großteil der Änderungen durchgeführt werden.
2. Dringende Änderung
   Die dringende Änderung ermöglicht eine zeitnahe Produktivsetzung einer Änderung, unabhängig von einem existierenden Release und dem dazugehörigen Kalender. Sie sollte nur in Ausnahmefällen genutzt werden, da eine Änderung des produktiven Systems immer mit einem Risiko verbunden ist.
3. Admin-Änderung
   Eine Admin-Änderung beinhaltet die Änderung von Systemeinstellungen, die nicht transportierbar sind und daher in jedem System separat ausgeführt werden müssen.
4. Allgemeine Änderung
   Die allgemeine Änderung umfasst Änderungsvorgänge, die nicht oder nur unmittelbar mit einem System zusammenhängen. Dies können Änderungen an IT-Objekten wie Handys (z.B. ein Firmware-Update) oder Druckern (z.B. Tonertausch) sein. Die allgemeine Änderung im Change Request Management schließt damit die Lücke aus dem Solution Manager 7.0, in dem nur Änderungen an SAP-Systemen durchgeführt und dokumentiert werden konnten. Im Solution Manager 7.1 wird so eine vollständige Dokumentation aller durchgeführten Veränderungen erreicht.

Während der Durchführung normaler und dringender Änderungen erlaubt das Change Request Management das direkte Anlegen von Transportaufträgen im Entwicklungssystem. Transportaufträge dienen als Container für die durchgeführten Änderungen, um sie zu gegebener Zeit in die Folgesysteme, z.B. Test- und Produktivsystem, zu importieren.

Nachdem der Entwickler seine Tätigkeiten abgeschlossen hat, wird die Änderung in der Testphase geprüft. Je nach Landschaft und Anzahl der Teststufen erfolgt diese Verifizierung im Entwicklungs- und/oder Testsystem.

Bei erfolgreicher Testdurchführung wird die Änderung in die nächste Phase übergeben.

2.2.3 Einführungsphase

Die Einführungsphase ist unterteilt in die

• Produktivsetzung und den
• Betrieb.

Die Produktivsetzung ist die Aktivierung der Änderung im produktiven System. Je nach Art der Änderung erfolgt sie konsolidiert (normale Änderung), d.h., mehrere Änderungen werden gleichzeitig im Rahmen eines Release-Go-Lives aktiviert, oder einzeln (dringende Änderung), d.h., nur eine Funktion wird zur Fehlerbehebung aktiviert.

Die anschließende Wartung ist Teil des Betriebes der Anwendung. Hier sind üblicherweise verschiedene IT-Services definiert, die sicherstellen sollen, dass der operative Betrieb nicht beeinträchtigt wird bzw. dass die Auswirkungen minimal sind, falls es zu einer Anpassung kommen muss.

Änderungen an produktiven Anwendungen müssen wiederum beantragt werden, der entsprechende Prozess wurde bereits in Abschnitt 2.2.1 erläutert.

2.2.4 Optimierungsphase

In der Optimierungsphase wird überprüft, ob die in der Planungsphase gestellten Erwartungen erfüllt werden und es möglicherweise Verbesserungspotenziale gibt. Werden Potenziale identifiziert, so können diese wiederum als Änderungsanträge erfasst werden, um sie anschließend in der Planungsphase zu verifizieren.

Das Change Request Management bietet hier verschiedene Funktionen wie z.B. die Transport-Analyse an, um die Konsistenz einer Landschaft zu überprüfen.