SCSM 2012 – Incident und Change Management (Teil 3)

Im zweiten Teil dieser Blogserie habe ich Ihnen das Connector Framework vorgestellt. Dieser Beitrag beschäftigt sich mit Incident und Change Management. Dabei soll nicht unbedingt der „best practice“-Ansatz von ITIL oder MOF vorgestellt werden, sondern was der Service Manager in diesem Bereich an technischen Möglichkeiten bietet.

In der Welt des Service Managers sind Change und Incident Requests WorkItems.

Sie sind in einer Baumstruktur im WorkItem Panel aufgelistet. Unterhalb der Bereiche Change Management und Incident Management befinden sogenannte Views, die als Filter zu verstehen sind, abgebildet. Wählt man eine dieser Views aus, werden den Filter Optionen entsprechend die Tickets angezeigt.

Views lassen sich auch selbst erstellen.

An dieser Stelle ein kleiner Tipp: Wenn Ihnen der Informationsumfang der Basis Objekte nicht reicht, wählen Sie für „Search for objects of a specific class“ die „Combination classes“ an Stelle der „Frequently used base classes“.

Incident Request erstellen

Incident Requests können entweder aus der Service Manager Konsole oder dem Self-Service Portal heraus erstellt werden. Wohingegen Change Requests aktuell nur aus der Service Manager Konsole heraus erstellt werden können.

Um einen Incident zu erstellen wählen Sie unter Work Items > Incident Management > Create Incident.
Es öffnet sich ein Formular:

Füllen Sie alle benötigten Felder aus und speichern Sie das Ticket. Anschließend können Sie die üblichen Arbeiten an diesem Ticket durchführen:

• Assignments
• Escalation
• Remote Desktopsitzung starten
• User Feedback anfordern
• …

Einige Tasks müssen allerdings noch mittels SCSM Workflows mit der notwendigen Logik versehen werden, z.B. der Request User Input Task, der anders als man erwarten würde, das Ticket nur in den Zustand Pending versetzt und keine eMail rausschickt.

Unter dem Tab Related Items sehen Sie außerdem ob diesem Ticket andere Tickets (z.B. Child- oder Parent-Tickets) zugeordnet sind. Außerdem können Sie Betroffene Systeme (z.B. der Computer des Antragsstellers) einsehen.

Change Request auf Basis eines Templates erstellen

Der Service Manager lebt von seinen Templates. Nachfolgend erstellen wir gemeinsam ein Template für einen möglichen Standard Change. Um anschließend darauf basierend unsere Change Requests zu erstellen.

Dazu wählen wir unter Library den Eintrag Templates

Per Rechstklick und Create Template, erstellen wir ein neues Template.

Einen Name auswählen: in diesem Beispiel wird eine Office Installation beantragt (da scheiden sich jetzt die Geister ob das ein Change oder Service Request ist…)
Beim Klick auf OK öffnet sich das Template und wir können nun Felder vorbelegen, die im eigentlichen Ticket dann aber wieder überschrieben werden könnten.
Wir tragen als Titel „Bitte Office installieren“ ein und wählen dann in den Tabs den Button Activities.

Eine Zusammensetzung aus Aktivities kann als Workflow verstanden werden. Hier können einzelne Schritte definiert werden, die den Workflow abbilden.
Beispielsweise soll in unserem Fall Zunächst der

• Vorgesetzte zustimmen

und anschließend soll die

• Installation von einem Customer Server Mitarbeiter durchgeführt

werden.

Das leere Activities Fenster muss nun mit den oben genannten Steps vorausgefüllt werden.
Dazu kann über die Toolbar mit dem + Symbol eine Activity hinzugefügt werden.

Wenn wir dies gemacht haben bekommen wir eine Auswahl von Activity Templates.
Unter anderem:

• Manuel Activity (für Vorgänge die Manuell durchgeführt werden müssen)
• Review Activity (für Vorgänge die eine Genehmigung erfordern)

Wir wählen zunächst die Review Activity und füllen Sie wie in der folgenden Abbildung aus.

Anschließend wählen wir über das + Symbol erneut eine Activity, diesmal eine Manual Activity, aus.

Das Ergebnis sollte dann in etwa wie folgt aussehen:

Anschließend mit OK das Template speichern und unter WorkItems ChageManagement einen neuen Change auf Basis dieses Templates erstellen. Sie werden sehen, dass die Activities bereits hinzugefügt wurden und darauf warten bearbeitet zu werden.

Dies war natürlich nur ein Ausschnitt daraus, was mit Changes und Incidents möglich ist. Gerade in Kombination mit dem Orchestrator lassen sich ein paar ganz nette Dinge umsetzen.

Weitere Beiträge dieser Serie:

• SCSM 2012 – System Center Service Manager 2012 – Einführung (Teil 1)
• SCSM 2012 – Connector Framework, Zusammenspiel der System Center Familie (Teil 2)
• SCSM 2012 – Incident und Change Management (Teil 3)
  
• SCSM 2012 – Service und Request Offerings, User Management (Teil 4)
• SCSM 2012 – Service Manager Authoring Tool (Teil 5)
• SCSM 2012 – Erstellen eigener Configuration Items (Teil 6)
• SCSM 2012 – Standard Incidents erweitern (Teil 7)
• SCSM 2012 – Automatisierung mit dem SCOrch (Teil 8)