Wiedereröffnungsaktivitäten

Einführung in Wiedereröffnungsaktivitäten

Sobald ein Ticket technisch geschlossen ist, d. h. einen Endknoten im Workflow erreicht hat, kann es weder bearbeitet werden noch gibt es Aktivitäten für das Ticket. In einem Geschäftsprozess kann es aber erforderlich sein, solche Tickets wieder zu öffnen. Dies kann durch eine Wiedereröffnungsaktivität abgebildet werden.

Beispielhafte Anwendungsfälle für Wiedereröffnungsaktivitäten sind:

• Das System erhält eine E-Mail zu einem geschlossenen Ticket. Statt ein neues Ticket mit einer Relation vom geschlossenen Ticket zu erstellen, soll das geschlossene Ticket wieder geöffnet werden.
• Der Kunde ist mit der Lösung im Ticket nicht zufrieden. Er möchte das Ticket in CM/Track wieder öffnen.

Wenn eine Wiedereröffnungsaktivität verwendet wird, kehrt das Ticket nicht zum Startknoten zurück, sondern tritt an der Stelle in den Prozess wieder ein, die durch die ausgehenden Verbindungen der Aktivität definiert sind. Wiedereröffnungsaktivitäten haben keine eingehenden Verbindungen. Sie sind im Bereich, in dem sie sich befinden, und in allen Unterbereichen dieses Bereichs sichtbar.

Eigenschaften einer Wiedereröffnungsaktivität

Wiedereröffnungsaktivitäten haben die folgenden Eigenschaften:

Abbildung 53: ConSol CM Process Designer - Eigenschaftseditor für eine Wiedereröffnungsaktivität

• Name

  Pflichtangabe. Dies ist der technische Name der Wiedereröffnungsaktivität. Wenn eine neue Wiedereröffnungsaktivität erstellt wird, können Sie ihre Bezeichnung editieren und der Aktivitätsname wird automatisch aus der Bezeichnung erstellt (Sonderzeichen werden ausgelassen). Danach wird der Name der Aktivität nicht mehr automatisch geändert, kann aber noch manuell editiert werden. Zulässige Zeichen für Namen sind:

  • Buchstaben (Klein- und Großbuchstaben), aber keine Sonderzeichen
  • Unterstriche
  • Zahlen

• Bezeichnung

  Der lokalisierte Name der Wiedereröffnungsaktivität. Alle Sprachen, die für das System konfiguriert wurden, sind verfügbar und können ausgefüllt werden. Im Web Client wird die Bezeichnung in der Sprache angezeigt, die im Webbrowser eingestellt ist. Wenn keine Bezeichnung in dieser Sprache verfügbar ist, wird die Bezeichnung in der Standardsprache angezeigt.

  

  Abbildung 54: ConSol CM Process Designer - Lokalisierung für Bezeichnungen

• Beschreibung

  Optional. Eine lokalisierte Beschreibung, die als Mouseover im Web Client angezeigt wird. Diese kann dem Bearbeiter Informationen dazu liefern, was passiert, wenn er die betreffende Wiedereröffnungsaktivität ausführt.

  

  Abbildung 55: ConSol CM Process Designer - Lokalisierte Beschreibung einer Wiedereröffnungsaktivität

  

  Abbildung 56: ConSol CM Web Client - Lokalisierte Beschreibung einer Wiedereröffnungsaktivität eines geschlossenen Tickets

• Sortier-Index

  Definiert die Reihenfolge der Aktivitäten in der Liste der Workflow-Aktivitäten im Web Client. Die Aktivitäten mit niedrigen Zahlen werden oben in der Liste angezeigt.

• Bedingung

  Optional. Es kann ein Skript im Skripteditor (siehe Abschnitt Editieren von Skripten) eingegeben werden. Das Skript muss true oder false zurückgeben. Es wird ausgeführt, wenn die vorherige Aktivität ausgeführt wurde, d. h., sobald es möglich wird, die Aktivität mit der Bedingung anzuzeigen. Wenn true zurückgegeben wird, wird die Aktivität angezeigt; wenn false zurückgegeben wird, wird die Aktivität nicht angezeigt. Eine Aktivität, die eine Bedingung hat, ist mit dem Icon Ausrufezeichen gekennzeichnet.

  • Der Rückgabewert ist true.
    Die Aktivität wird angezeigt. Wenn es sich um eine manuelle Aktivität handelt, kann diese im Web Client vom Bearbeiter durchgeführt werden.
  • Der Rückgabewert ist false.
    Die Aktivität wird nicht im Web Client angezeigt.

• Skript

  Optional. Im Skripteditor kann ein Skript eingegeben werden (siehe Abschnitt Wiedereröffnungsaktivitäten), das ausgeführt wird, wenn das Ticket die Aktivität durchläuft.

• Overlay

  Optional. Klicken Sie in das orangene Feld, um ein Standard-Overlay von ConSol CM oder ein bereits hochgeladenes Overlay auszuwählen. Klicken Sie auf den Button mit den drei Punkten an der rechten Seite, um den Dateiexplorer des Betriebssystems zu öffnen und ein neues Icon hochzuladen. Wenn das Ticket die Aktivität durchläuft, wird das Overlay im Web Client zum Ticket-Icon hinzugefügt. Maximal kann das Ticket-Icon drei Overlays haben. Dieser Mechanismus kann für mehrere Zwecke verwendet werden. Einige Beispiele sind:

  • Eine Eskalation:
    Das Ticket wurde erstellt und es hat sich noch kein Bearbeiter darum gekümmert.
  • Eine E-Mail:
    Das Ticket hat eine E-Mail erhalten.
  • Eine Nachricht an den Bearbeiter:
    Ein anderer Bearbeiter hat zum Beispiel einen Kommentar zu meinem Ticket hinzugefügt.

  

  Abbildung 57: ConSol CM Process Designer - Eigenschaftseditor: Standard-Overlays und ein kundenspezifisches Overlay

  

  Abbildung 58: ConSol CM Web Client - Ticket-Icons mit Overlays

• Overlay-Gültigkeit

  Wird nur angezeigt, wenn ein Overlay ausgewählt wurde.

  • Aktivität
    Das Overlay hängt so lange am Ticket-Icon, wie das Ticket hinter der Aktivität steht, bzw., sofern vorhanden, hinter der letzten automatischen Aktivität steht, die ohne manuelle Interaktion durchlaufen werden kann. Sobald die nächste manuelle Aktivität ausgeführt wird, wird das Overlay vom Ticket-Icon entfernt.
  • Bereich
    Das Overlay wird entfernt, wenn das Ticket den Bereich verlässt.
  • Prozess
    Das einmal zum Ticket-Icon hinzugefügte Overlay hängt für den Rest des Prozesses am Ticket-Icon.
  • Nächstes Overlay
    Das Overlay hängt so lange am Ticket-Icon, bis ein neues Overlay hinzugefügt wird. Wenn ein neues Overlay hinzugefügt wird, wird das alte Overlay entfernt.

  Wenn es für einen Anwendungsfall nicht ausreicht, ein Overlay mithilfe der Overlay-Gültigkeit zu setzen oder zu entfernen, können Sie ein Workflow-Skript verwenden. Details dazu finden Sie im Abschnitt Arbeiten mit Overlays.

• Sichtbarkeit im Ticketprotokoll

  Pflichtangabe. Diese Eigenschaft definiert, auf welchem Sichtbarkeitslevel die Durchführung der Aktivität im Ticketprotokoll im Web Client angezeigt wird. Die möglichen Werte sind:

  • 2nd level and 3rd level
  • only 3rd level
  • on every level
  • default (Standardwert)
    

    Die Aktivität wird auf dem Sichtbarkeitslevel angezeigt, das im Admin Tool, Navigationsgruppe Tickets, Navigationselement Protokoll, konfiguriert ist. Je nach Aktivitätstyp wird eine der folgenden Einstellungen verwendet:

    • Manuelle Aktivität oder Aktivität mit Overlay ausgeführt
    • Aktivität nach Eskalation ausgeführt
    • Automatische Aktivität ausgeführt
  • hidden on all levels
    Wenn dieser Wert ausgewählt ist, wird die Ausführung der Aktivität nie im Ticketprotokoll im Web Client angezeigt.

  

  Abbildung 59: ConSol CM Web Client - Sichtbarkeitslevel im Ticketprotokoll

• Autom. Aktualisierung deaktivieren

  Legt das Verhalten des Tickets fest, wenn ein Ereignis gefeuert oder ausgeführt wurde. Normalerweise wird nach einem Ereignis automatisch eine Ticket-Update-Operation durchgeführt. Bei mehreren direkt aufeinanderfolgenden Ereignissen, sollten Sie es vermeiden, nach jedem einzelnen Ereignis eine Ticket-Update-Operation anzustoßen. Setzen Sie dazu für alle Ereignisse außer dem letzten Ereignis der Kette das Feld Autom. Aktualisierung deaktivieren auf true. So wird das Ticket erst nach dem letzten Ereignis aktualisiert.

• Für Kunden freigeben

  Boolean. Wenn ausgewählt, wird die Aktivität als Workflow-Aktivität im ConSol CM-Portal CM/Track angezeigt. Die Aktivität wird in CM/Track nur angezeigt, wenn keine Bedingung vorhanden ist oder das Bedingungsskript true zurückgibt. Wenn ein ACF (Aktivitätsformular) für die Aktivität gesetzt ist, wird es geöffnet, wenn der Kunde auf die Aktivität klickt. Ein Beispiel für ein ACF in CM/Track finden Sie im Abschnitt ACFs in CM/Track.

• Für Benutzer freigeben

  Boolean. Wenn ausgewählt, wird die Aktivität als Workflow-Aktivität im Web Client angezeigt. Die Aktivität wird nur angezeigt, wenn keine Bedingung vorhanden ist oder das Bedingungsskript true zurückgibt. Wenn ein ACF (Aktivitätsformular) für die Aktivität gesetzt ist, wird es geöffnet, wenn der Benutzer auf die Aktivität klickt.

Prozesslogik von Wiedereröffnungsaktivitäten

Das Ticket wird wieder geöffnet, sobald die Wiedereröffnungsaktivität ausgeführt wurde. Die weitere Verarbeitung hängt von den ausgehenden Verbindungen der Wiedereröffnungsaktivität ab. Die Prozesslogik von Wiedereröffnungsaktivitäten ist dieselbe wie für normale Aktivitäten (siehe Prozesslogik von Aktivitäten).

Berücksichtigen Sie, welche Auswirkungen das Wiedereröffnen von geschlossenen Tickets auf den Workflow als Ganzes hat. Die folgende Liste zeigt einige Beispielbereiche, in denen Anpassungen nötig sein könnten, wenn Wiedereröffnungsaktivitäten eingeführt werden.

• Automatische Aktionen beim Schließen von Tickets

  Falls der Workflow automatische Aktionen enthält, die beim Schließen eines Tickets ausgeführt werden, kann es sein, dass Sie diese für ein wieder geöffnetes Ticket anpassen müssen, um zu verhindern, dass sie mehr als einmal ausgeführt werden. Es kann sogar sein, dass Sie einige dieser Aktionen rückgängig machen müssen, wenn ein Ticket wieder geöffnet wird.

  Beispiel: Es wird automatisch ein FAQ-Ticket erzeugt, wenn ein Ticket mit einer Lösung geschlossen wird. Nun wird das ursprüngliche Ticket wieder geöffnet, weil die Lösung nicht wie erwartet funktioniert, und das FAQ-Ticket muss entsprechend aktualisiert werden.

• Ticketrelationen

  Wenn im Workflow ein bestimmtes Verhalten bezüglich Parent-Child- oder Master-Slave-Relationen implementiert ist, kann das Wiedereröffnen eines Tickets auch Änderungen an anderen Tickets erforderlich machen.

  Beispiel: Ein Parent-Ticket kann nur geschlossen werden, wenn alle seine Child-Tickets geschlossen sind. Nun wird ein Child-Ticket wieder geöffnet und das Parent-Ticket muss auf diese Änderung reagieren.

• Reports/Dashboards

  Wenn die Anzahl geschlossener Tickets in Reports oder Dashboards analysiert wird, müssen Sie entscheiden, wie Sie mit wieder geöffneten Tickets umgehen. Ansonsten können die Reportdaten für wieder geöffnete Tickets ungenau sein, z. B. weil dasselbe Ticket mehr als einmal gezählt wird.

Verwenden Sie ein Skript in der Wiedereröffnungsaktivität oder platzieren Sie eine automatische Aktivität mit einem Skript hinter der Wiedereröffnungsaktivität, um die erforderliche Logik hinzuzufügen.

Beispiel für die Verwendung von Wiedereröffnungsaktivitäten

Beispiel 1: Wiedereröffnen eines geschlossenen Tickets bei Eintreffen einer E-Mail

Wenn eine E-Mail zu einem geschlossenen Ticket eintrifft, wird standardmäßig ein neues Ticket und eine Relation zwischen dem neuen Ticket und dem ursprünglichen Ticket, zu dem die E-Mail eingetroffen ist, erzeugt. Falls Sie stattdessen lieber das ursprüngliche Ticket wieder öffnen möchten, können Sie in den Bereich, in dem sich der Endknoten befindet, eine Wiedereröffnungsaktivität einfügen und diese Aktivität im Verarbeitungsskript für eingehende E-Mails ausführen.

Gehen Sie folgendermaßen vor:

1. Fügen Sie eine Wiedereröffnungsaktivität in den Bereich bzw. die Bereiche mit Endknoten ein.
2. Erzeugen Sie eine Verbindung von der Wiedereröffnungsaktivität zu der Aktivität, bei der die Ticketverarbeitung fortgesetzt werden soll.
3. Bearbeiten Sie das Skript NimhIncomingMailRouting.groovy im Admin Tool, um die Logik für das Wiedereröffnen des Tickets hinzuzufügen.
4. Installieren Sie den Workflow und testen Sie ihn.

Die folgende Abbildung zeigt den Teil des Workflows, in dem sich der Endbereich und die Wiedereröffnungsaktivität befinden.

Abbildung 60: ConSol CM Process Designer - Workflow mit einer Wiedereröffnungsaktivität

Das folgende Beispiel zeigt das Skript NimhIncomingMailRouting.groovy aus dem Admin Tool. Die rot hervorgehobenen Zeilen wurden hinzugefügt, um das Ticket wieder zu öffnen, wenn eine Wiedereröffnungsaktivität vorhanden ist.

Code-Beispiel 6: NimhIncomingMailRouting.groovy - angepasst für das Wiedereröffnen eines Tickets bei Eintreffen einer E-Mail