Workflows und Service Level Management

Wie Sie Workflows im Service Level Management einsetzen, erfahren Sie im folgenden Abschnitten.

Anmerkung: Lesen Sie auch die Dokumentation zur Portfolio-Administration im Bereich Services.
Anmerkung: Bei der Erstellung eines Workflows müssen Sie entscheiden, ob dieser als Service-Prozess - mit oder ohne Vertrag - definiert ist oder nicht.

  • Die Standard-Einstellung im Workflow Designer ist Kein Vertrag Notwendig. Ändern Sie die Einstellung, wenn Sie mit Verträgen arbeiten.
  • Arbeiten Sie NICHT mit Services und haben weder Default-Service noch Default-SLAs definiert, setzen Sie diese Option auf Vertragsmanagement 4.x zurück.

Parameterübergabe durch SLA-Definition an den Workflow

Verwenden Sie den Workflow im Service Level Management Kontext, können zusätzlich zur Workflowdefinition Parameter definiert werden, die ihre Belegung in der Definition des zugehörigen SLAs erhalten.
Diese Übergabemöglichkeit für Parameter aus der SLA-Definition in den Workflow ist ebenfalls im ClassicDesk Handbuch nachzulesen. Hier nur die Hinweise, an welchen Stellen im Workflow Designer Sie auf diese neuen Parameter zugreifen können.

Neben einfachen Parametern wie Strings können hier auch Processes-Organisationseinheiten und Prozessrollen definiert und aus dem SLA bezogen werden.

Eine so übergebene Organisationseinheit kann dann beispielsweise in der Genehmigungsaktivität verwendet werden.

Prozessrollen-Routing

Zu den Parametern, die aus einem SLA übergeben werden können, gehören auch Prozessrollen. Diese können nicht nur in Genehmigungsaktivitäten sondern auch für das Routing verwendet werden. Sie finden zwei neue Routing-Strategien für Prozessrollen.

ProcessRoleRouting
Routet den Vorgang in die Warteschlange der durch die Prozessrolle angegebenen Agenten.
ProcessRoleRoutingWithControlQueue
Routet den Vorgang in die Warteschlangen bzw. auf die Infotische der durch die Prozessrolle angegebenen Agenten.

Service-relevante Methoden im Instruction Set

Um Service-Parameter auch innerhalb des Workflows verfügbar zu machen, werden nachfolgende Methoden im Instruction Set angeboten.
  • Copy Services
  • Copy Processs Services
  • Add Product to Service
  • Add Product to Affected Service
  • Add Budget to Affected Service
  • Add KBArticle to Affected Service
Copy Services
Ein Produkt kann mehreren Services als Service-Komponente zugeordnet sein. Innerhalb eines Workflows kann es erforderlich sein, ein weiteres Produkt auch an eben diese Services anzubinden.
Die Methode CopyServices findet in einem ersten Schritt die Services heraus, zu welchem das ursprüngliche Produkt (Source Product) als Service-Komponente zugeordnet ist, und ordnet in einem zweiten Schritt das weitere Produkt (Target Product) ebenfalls diesen Services zu.
Anmerkung: Die Zuordnung des weiteren Produkt zum Service wird in einem Instruction Set des Target Products getätigt, wobei das ursprüngliche Produkt als Source hinzugeladen sein muss
Beispiel:
In der Abbildung sehen Sie ein Instruction Set eines NotebookComputers, in welchem als Source ein DesktopComputer hinzugefügt wurde und bei Einfügen der Copy Services Methode als Quelle gewählt wird.
Copy ProcessService
Wird ein ProcessChaining durchgeführt, kann es gewünscht sein, sowohl den via Service Contract selektierten Service des ursprünglichen Vorgangs als auch die weiteren Services in den neuen Prozess zu übernehmen, die über einen ServiceSelector im Dialog gewählt wurden, zu übernehmen.

Innerhalb der Start-Aktivität eines Workflows können Sie bestimmen, welche Daten aus dem Ursprungs-Vorgang übernommen werden sollen. Hierzu verwenden Sie die TryCast-Methode, um zwischen den einzelnen Vorgangs-Typen unterscheiden zu können.

Beispiel:
Die Abbildung zeigt, wie durch Copy Process Services von einem ursprünglichen ChangeRequest (als Related Object) die Services in einen Incident (hlObj, also in dessen CreateObjectInstructions) übernommen werden.
Add Product to Service
Innerhalb eines Workflows, der als Service Contract-Prozess gestartet wurde, kann mit der Add Product to Service Methode ein Produkt dem zugehörigen Business oder Technical Service zugeordnet werden.
Add Product to Affected Services

Zuweisung eines Produkts zu allen viaService Selector gewählten Services innerhalb eines Workflows.

Add Budget to Affected Services
Innerhalb der Financial Management Komponente in der Startkonfiguration ITIL3 wird ein helpLine- internes Objekt Budget angeboten, in dem alle Angaben gespeichert werden, die zur finanziellen Abrechnung von Serviceleistungen benötigt werden.

Durch Add Budget to Affected Services kann dieses Budget-Objekt über ein Instruction Set ebenso allen via Service Selektor betroffenen Services zugeordnet werden.

Add KBArticle to Affected Services

Ein KBArtikel, der in der Startkonfiguration ITIL V3 über ein Produkt abgebildet wurde, kann über ein Instruction Set und Add KBArticle to Affected Services den betroffenen Services zugeordnet werden.

Wechsel von Services und SLAs zulassen

Processes stellt eine Erweiterung des Operationsbereich/Operation Scopes zur Verfügung, um während eines Business-Prozesses den Wechsel von einem einmal ausgewählten Service mit zugehörigem SLA zu einem anderen zu ermöglich. Diese Funktionalität ist dazu gedacht, eine vielleicht falsche Service- oder SLA-Auswahl bei der Vorgangsaufnahme wieder berichtigen zu können.
  1. Fügen Sie einen Operationsbereich ein und erzeugen eine neue Verzweigung.
    Die system-interne Aktion SwitchContractAgreement wird angezeigt.

  2. Korrigieren Sied die fehlenden Properties wie im Instruction Set angezeigt.

    Weisen Sie dem Workflow die Eigenschaft als ServiceProzess zu. Verwenden Sie in der Ribbon Bar den Eintrag ContractRequired.
  3. Setzen Sie die Option GuiAllowed auf true.
  4. Binden Sie die Objekt-Identität.
Solange dieser Business-Prozess sich innerhalb dieses Operationsbereichs befindet, ist im Vorgangsdialog die Option zur Service-Auswahl aktiviert – der gewählte Service oder das SLA kann beliebig geändert werden.
Anmerkung: Informationen über Service-Wechsel finden Sie in der Historie des Workflows auf einer zweiten Registerkarte.

Versionierung von Prozessen und Services mit dem Agreements Updater

Soll ein Workflow- oder Ad Hoc-Prozess in einem Service-Agreement verwendet werden, kann immer nur die aktuell aktivierte Prozess-Version zugeordnet werden. Sobald aber eine neue Version eines Workflows oder Ad Hoc-Vorgangs erstellt und aktiviert wurde, welcher in Agreements eingebunden ist, muss jedes dieser Agreements auf die neue Version aktualisiert werden.
Zu diesem Zweck steht im Workflow-Administrationsbereich des Designer der Agreements Updater zur Verfügung.
Anmerkung: Die Aktualisierung der Agreements kann auch manuell vorgenommen werden, indem eine neue Version des Agreements angelegt und in den Contract-Portfolios den Kunden neu zugeordnet werden.


In der Abbildung sehen Sie zwei Versionen des Workflows MailServiceWF. Die Version 1 wurde bereits als Service Prozess in Agreements eines Business Services verwendet, welcher als Contract Portfolio Kunden zugeordnet wurden. Eine neuere Version MailServiceWF 2 wurde sodann erstellt und aktiviert.
Anmerkung: Diese Version kann noch nicht in den Clients verwendet werden, da sie weder einem Agreement des Default Service noch einem Business-Service zugeordnet ist. Die alte Version ist nicht mehr aktiv.

Updatefähige Agreements

Gehen Sie wie folgt vor, um die Agreements zu aktualisieren, die updatefähig sind.
  1. Wählen Sie in der Workflow-Administration eine aktive Version eines Prozesses aus und wählen Sie den Agreement Updater für diesen Prozess - im Beispiel MailServiceWF Version 2.
  2. Filtern Sie die Ansicht um nur die benötigten Agreements anzuzeigen nach den Eigenschaften aktiv, aktuell, updatefähig.
    Sie sehen im Tabellenbereich des Fensters, in welchen Vereinbarungen die Vorversion verwendet wurde. Im Beispiel wurde die Version 1 des MailServiceWF in einem Agreement des DefaultServices und in zwei unterschiedlichen Agreements (Gold und Silber) des Mail-(Business-)Services verwendet.

  3. Nehmen Sie die Updates innerhalb der ausgewählten Agreements vor. Die gelb markierten Agreements sind updatefähig. Über einen Tooltipp geben die gelben Markierungen weiteren Aufschluss über den Status des Agreements. Updatefähigkeit bedeutet:
    • Die Option Service Level Management 5.x -> Anfrager und Vertrag erforderlich ist weiterhin ausgewählt.
    • Zwischen den Versionen des Prozesse wurden keine Parameter verändert, hinzugefügt oder entfernt.
    • Die Einstellungen bzgl. Priortätsmatrix und Nutzung des Default Services wurden beibehalten.
  4. Wählen Sie die Schaltfläche Vereinbarungen aktualisieren.
    In allen hier ausgewählten Agreements wird die Prozess-Version 1 des MailServiceWF durch die Version 2 ersetzt, und die erfolgreiche Durchführung angezeigt.

    Im ClassicDesk in der Service Level Management Administration sehen Sie für die Agreements direkt die neue Version des Prozesses eingetragen. Auch die Agreements in den Contract Portfolios der einzelnen Kunden wurden in diesem Schritt auf die neue Version 2 des Prozesses aktualisiert.

Nicht updatefähiges Agreement

Neue Versionen sind nicht updatefähig, wenn sich Parameter oder die Einstellungen bzgl. Prioritätenmatix verändert haben. In diesem Fall werden die Agreements als nicht update-fähig gekennzeichnet.

Gehen Sie wie folgt vor, um die Agreements zu aktualisieren, die updatefähig sind.
  1. Erzeugen Sie ein neues Agreement, welches auf die neue Prozess-Version verweist und mit den geänderten Parametern oder Prioritätseinstellungen arbeitet.
  2. Klonen Sie die betroffenen Agreements über die Schaltfläche Vereinbarungen klonen.
    Es wird ein Dupplikat der Agreements erzeugt. Diese Duplikate sind in der Service-Level-Management-Komponente im ClassicDesk sofort sichtbar. Die neue Prozess-Version ist bereits eingetragen.



  3. Bearbeiten Sie die neuen Agreements solange Sie noch im Status In Planung sind.
  4. Setzen Sie die alten Agreements in den Status Archiviert.
  5. Aktivieren Sie die neuen Agreements.
  6. Ersetzen Sie die Agreements in den Vertrags-Portfolios.