Beispielszenario: Verwalten von Änderungen und Aktivitäten

 

Veröffentlicht: Juli 2016

Gilt für: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

Dieses Beispielszenario für System Center 2012 – Service Manager unterstützt Sie bei der Erreichung Ihres Ziels, Änderungen und Aktivitäten mithilfe mehrerer Szenarien durchgängig zu verwalten. Betrachten Sie dieses Beispielszenario als eine Fallstudie, die einen Kontext für einzelne Szenarien und Verfahren liefert.

Szenarien für das Verwalten von Änderungen und Aktivitäten

Szenario	Beschreibung
Initiieren und Klassifizieren einer Änderungsanforderung	Hier wird beschrieben, wie Anforderungen gestartet und klassifiziert werden. Außerdem wird beschrieben, wie Elemente und Aktivitäten Änderungsanforderungen hinzugefügt werden.
Genehmigen und Modifizieren von Änderungsanforderungen	Hier wird beschrieben, wie Änderungsanforderungen durch das Hinzufügen von Änderungsdetails und Änderungsprüfern modifiziert werden. Außerdem wird beschrieben, wie eine Prüfaktivität genehmigt wird.
Anhalten und Fortsetzen einer Änderungsanforderung	Hier wird beschrieben, wie eine Änderungsanforderung angehalten und fortgesetzt wird.
Implementieren und Schließen einer Änderungsanforderung	Hier wird beschrieben, wie manuelle Aktivitäten ausgeführt werden, um Aufgaben zu verfolgen. Weiterhin wird beschrieben, wie eine Änderungsanforderung nach dem Ausführen der Änderungen geschlossen wird, und wie Benutzer benachrichtigt werden.

Initiieren und Klassifizieren von Änderungsanforderungen

In diesem Szenario, welches das Initialisieren und Klassifizieren einer Änderungsanforderung umfasst, möchte Julia, die Messagingunterstützungsanalytikerin, ein Änderung vorschlagen und verfolgen. Dazu erstellt sie eine Änderungsanforderung, um Informationen zu erfassen, die sie und andere für das Auswerten, Planen, Entwickeln, Testen, Bereitstellen und Beurteilen von Änderungen verwenden werden. Julia initialisiert zunächst die Änderungsanforderung und legt anschließend deren Priorität und Kategorie fest.

In Incident Management-Szenarien hat Phil einen Incident erstellt, bei dem ein Benutzer ein Messagingproblem hatte; hierbei hat Phil eine Erstuntersuchung des Problems durchgeführt. In diesem Szenario setzt Julia die Untersuchung desselben Incident fort. Sie vergewissert sich, dass die Ursache ein bekanntes Problem ist und dass es von Microsoft Exchange Server 2010 SP1 behoben wird. Außerdem stellt sie fest, dass alle Exchange-Server das Service Pack benötigen, also nicht nur ein einzelner Server. Als Nächstes sichtet Julia die Dienstzuordnung für das Exchange-Dienst-Konfigurationselement, welches das Service Pack erfordert, und öffnet im Konfigurationselemementeformular des Diensts einen Change Request. Als Letztes hängt Julia ein gespeichertes Bildschirmfoto an die Änderungsanforderung, das sich bei der späteren Prüfung der Änderungsanforderungen als nützlich erweisen kann.

Nach dem Erstellen der Änderungsanforderung müssen die Änderungsprüfer bei der Woodgrove Bank die Änderungsanforderung genehmigen; außerdem müssen die Änderungsimplementierer alle Aktionen abschließen, die für die Änderung erforderlich sind. Diese Prüfungs- und Implementierungsschritte sind in der Änderungsanforderung als Satz von Prüfaktivitäten und manuellen Aktivitäten definiert.

Genehmigen von Änderungsanforderungen

In dem Szenario, welches das Genehmigen einer Änderungsanforderung umfasst, möchte Garret den Woodgrove Bank-Geschäftsprozess, also die Genehmigung aller IT-Infrastrukturänderungen, durchsetzen, bevor die Änderungen bereitgestellt werden. Er möchte diesen Geschäftsprozess durchsetzen, indem er Service Manager verwendet, um Prüfaktivitäten für eine Änderungsanforderung zu verknüpfen. Da eine Genehmigung erforderlich ist, wird die Änderungsanforderung erst implementiert, nachdem die Entscheidungsträger bei der Woodgrove Bank zugestimmt haben, dass die Änderung notwendig ist. Garret kann verschiedene Prüfverfahren einrichten, beispielsweise einstimmige Abstimmung, Prozentsatz der „Ja“-Stimmen oder automatische Genehmigung.

Die Verfahren zu diesen Szenarien stehen in Zusammenhang mit einer IT-Infrastruktur-Änderung bei der Woodgrove Bank, die vor Bereitstellung der Änderung genehmigt wird.

Anhalten und Fortsetzen von Änderungsanforderungen

Im Verlauf des Bereitschaftsprüfung für eine Änderungsanforderung möchte Garret eine Änderungsanforderung gelegentlich anhalten und diese Änderungsanforderung zu einem späteren Zeitpunkt wieder fortsetzen. Beispiel: Julia hat zuvor eine Änderungsanforderung erstellt. Diese Änderungsanforderung ist von zusätzlichen Maßnahmen eines externen Teams abhängig. Garret möchte diese Änderungsanforderung so lange anhalten, bis das externe Team seine Arbeit abgeschlossen hat. Garret wird die Änderungsanforderung fortsetzen, sobald das externe Team seine Arbeit abgeschlossen hat. Garret möchte außerdem gelegentlich die Blockierung für fehlgeschlagene Änderungsanforderungen aufheben.

Implementieren und Schließen von Änderungsanforderungen

Sobald die Change Requests an Garrets IT-Infrastruktur getestet und zur Bereitstellung freigegeben worden sind, besteht sein letzter Schritt darin, alle ausstehenden manuellen Aktivitäten für den Change Request abzuschließen. Eine manuelle Aktivität muss als abgeschlossen oder fehlgeschlagen gekennzeichnet sein. Wenn alle manuellen Aktivitäten abgeschlossen sind, wird der Change Request automatisch als abgeschlossen eingestuft und erscheint in der Ansicht Change Requests: Abgeschlossen . Wenn eine manuelle Aktivität fehlschlägt, wird der Change Request automatisch als fehlgeschlagen eingestuft und erscheint in der Ansicht Change Requests: Mit Fehlern . Sobald die Änderungsanforderung in einer der beiden Ansichten erscheint, kann Garret die Änderungsanforderung schließen. Nach dem Schließen eines Change Requests kann diese nicht wieder geöffnet werden.

In dem Szenario, welches das Implementieren und Schließen von Änderungsanforderungen umfasst, schließt Aaron eine manuelle Garantieprüfungsaktivität ab. Als Nächstes setzt Garret die verbleibenden manuellen Aktivitäten des Change Requests auf Abgeschlossenund schließt den Change Request. Garret öffnet einen zweiten vorhandenen Change Request, setzt die manuelle Nachimplementierungsaktivität auf Fehlgeschlagenund schließt dann den Change Request.

Siehe auch

Verwalten von Änderungen und Aktivitäten in System Center 2012 – Service Manager