Routing-Strategie

Die zweite Strategie innerhalb der While-Schleife ist die Routing-Strategie.

Hier wird festgelegt, welche Routing-Strategie angewendet werden soll, um den Vorgang zur Bearbeitung in die einzelnen Queues zu routen.

Die voreingestellte Routing-Strategie ist das sogenannte Direct Routing. Dies bedeutet, dass Sie konkret festlegen, in welche Warteschlangen und auf welche Infotische der Vorgang gelegt werden soll.

Erfolgt ein Direct Routing in die Warteschlange eines Agenten, bedeutet dies automatisch, dass der Vorgang vom Agenten editierbar ist. Erfolgt ein Direct Routing auf den Infotisch eines Agenten, kann auf die so gerouteten Vorgänge nur lesend zugegriffen werden kann.

WARNUNG: Wenn das Administratorkonto umbenannt wird, werden Workflows unterbrochen!

Für das Direct Routing finden Sie im Eigenschaftsbereich die Eigenschaften WaitingQueue (Warteschlange) und ControlQueue (Infotisch), über die Sie die Auswahldialoge öffnen und somit die Rollen bzw. Agenten auswählen können.

Anmerkung: Wie Sie sehen, sind die Eigenschaften WaitingQueue (Warteschlange) und ControlQueue (Infotisch) durch den roten Punkt als Pflichtfelder markiert. Dennoch können Sie in obigem Dialog auch KEINEN Agenten (also eine leere Liste) auswählen und durch Assign bestätigen.

Anmerkung: Eine leere Auswahl bei der WaitingQueue Eigenschaften bedeutet, dass der Vorgang in keine Warteschlange geroutet wird und somit in der Stage Activity verbleibt und von keinem Agenten zu bearbeiten ist. Diese Variante ist daher nur dann zu verwenden, wenn an anderer Stelle im Workflow der Vorgang verändert wird, um die Break-Condition jemals zu erreichen!

Folgenden Routing-Strategien stehen zur Auswahl.

AgentRouting

Der Vorgang wird auf den Arbeitstisch EINES Agenten geroutet und ist daher dort schon reserviert. Hierfür wird der Parameter Agent als Pflichtfeld im Eigenschaftsbereich verwendet, in dem die eingerichteten Agenten in einer Liste angeboten werden.

AutomaticSkillBasedRouting

Skills können frei definiert werden und Mitarbeitern können diese Skills mit unterschiedlichen Gewichtungen zugewiesen werden (Mitarbeiter XY hat beispielsweise den Skill Hardware mit der Gewichtung 80 %, Mitarbeit Z Software zu 90 %, usw.). Auch in Vorgangsdialogen kann ein Skill-Control eingebaut sein, womit zum Ausdruck gebracht werden kann: Um diesen Vorgang zu bearbeiten, braucht der entsprechende Mitarbeiter die Fähigkeit X zu mindestens Y Prozent.

Ziel dieser Routing-Strategie ist zudem, die Vorgänge bestmöglich zu verteilen, indem nach geeigneten Agenten gesucht wird, die z. Z. keine Vorgänge reserviert haben, also potentiell Arbeit übernehmen können.

Sind keine Skills für die Agenten und Vorgänge eingerichtet, kann diese Strategie nicht verwendet werden.

Für die Strategie AutomaticSkillBasedRouting gibt es drei Propertys:

Possible Workers sind Sie alle potentiellen Bearbeiter des Vorgangs. Potentiell bedeutet in diesem Zusammenhang, dass vor dem Routing zusätzlich geprüft wird, ob der im Vorgang angegebene Skill auch von den Agenten erfüllt ist.

Zudem wird versucht, diesen Vorgang genau EINEM Agenten aus der Possible Workers-Liste auf den Arbeitstisch zu routen. Der Vorgang wird also nur dann zu dem Agenten geroutet, wenn dieser
- angemeldet ist,
- (mindestens) den entsprechend im Vorgang angegebenen Skill hat und
- zur Zeit KEINEN Vorgang im Zustand Offen reserviert, also auf dem Arbeitstisch hat. Offen bezieht sich dabei auf den Status des CASEINFO.INTERNALSTATE, d. h. Vorgänge im Zustand Warte auf oder Zu prüfen werden hier ignoriert.
Hat der Agent mindestens einen Vorgang reserviert, wird der Arbeitstisch des nächsten, übernächsten usw. Agenten aus der Possible Workers-Liste geprüft, bis ein Agent gefunden ist, der keinen Vorgang reserviert hat.
Agent ist ein Agent, auf dessen Arbeitstisch die Vorgänge solange bleiben, bis sie entsprechend der Skills und angemeldeten Agenten geroutet werden können. Der Agent (in obigem Beispiel PoolAgent) ist ein explizit für dieses Routing angelegter Agent. Er sollte NUR als Pool für dieses Routing verwendet werden, also KEINE anderen Vorgänge erhalten und bearbeiten!

Sollte über diesen Mechanismus kein freier Arbeitstisch gefunden werden, wird der Vorgang zu dem unter Agent angegebenen Arbeitstisch geroutet und nach 90 Sekunden wird durch eine Re-Analyse erneut versucht, den Vorgang an einen qualifizierten Agenten zu verteilen.
AgentRestriction
- True sucht nur unter den Agenten aus der Liste der Possible Workers nach potentiellen Bearbeitern.
- False bedeutet, dass die Possible Workers-Liste ignoriert wird und alle im System befindlichen Agenten auf Anwesenheit und Skills untersucht werden, um u. U. den Vorgang auf den Arbeitstisch geroutet zu bekommen.

ConditionalRouting

Beim Conditional Routing werden die Warteschlangen und Infotische anhand von Bedingungen/Conditions auf dem Vorgangsobjekt berechnet. Hierfür werden die beiden Properties WaitingQueueRoutingInfos und ControlQueueRoutingInfos zur Verfügung gestellt.

Eine Bedingung, die Sie über den bekannten Condition-Dialog entweder direkt auswählen oder neu anlegen, wird den Agenten/Rollen (den Principals) zugeordnet.

Wie Sie in obigem Beispiel sehen, soll das Routing abhängig von der Priorität sein. Achten Sie in diesem Fall darauf, dass für JEDEN Prioritätswert auch ein Routing-Ziel (Agent/Rolle) angegeben ist.

Bei Überschneidung der Bedingungen wird der zugehörige Vorgang in alle Warteschlangen bzw. Infotische geroutet, die eine der angegebenen Bedingungen erfüllen (ODER-Verknüpfung der Bedingungen).

Sie können an dieser Stelle einen Vorgang auch in Abhängigkeit von prozentual verstrichener oder verbleibender Reaktions- oder Lösungszeit routen. Natürlich können Sie diese zeitlichen Prozentabfragen auch in anderen Aktivitäten verwenden wie der Evaluate Activity.

Hier zwei Beispiele:

this.CASEINFO.ReactionTime.RemainingPercent <= 20

dient zur Abfrage, ob die verbleibende Reaktionszeit kleiner oder gleich 20 Prozent ist.

this.CASEINFO.PromisedSolutionTime.ElapsedPercent > 50

dient zur Abfrage, ob von der versprochenen Lösungszeit bereits mehr als 50 Prozent verstrichen sind.

DirectRouting

Standard-Routing-Strategie

Die Queues werden durch die Eigenschaften WaitingQueue und ControlQueue festgelegt.

DirectRoutingWithResponsible

In der Service-Level-Management-Komponente können für einen angebotenen Service ein Verantwortlicher (Responsible) und ein stellvertretender Verantwortlicher (Agent oder Rolle) eingetragen werden. Für jedes SLA kann zudem ein weiterer Agent (oder Rolle) eingetragen sein.

Diese Strategie kann nur dann sinnvoll verwendet werden, wenn die Workflowdefinition mit der Option Service Level Management 5.x und Anfrager und Vertrag erforderlich gespeichert wird, und somit auch in einem Service mit Agreements verwendet wird.

Die Queues des DirectRoutingWithResponsible werden können sodann durch mehrere Properties belegt werden.

ControlQueue: Agenten und Rollen werden für das Routing auf Infotisch oder Warteschlange eingetragen.
Waiting Queue: Agenten und Rollen werden für das Routing auf Infotisch oder Warteschlange eingetragen.
RouteToCaseOwner bietet die Möglichkeit, an den Besitzer des Vorgangs zu routen. Gleiche Auswahlen werden auch bei den Service- und SLA-Beteiligten getroffen.
- None: Vorgang wird nicht an den Besitzer geroutet.
- WaitingQueue: Vorgang wird in die Warteschlange des Besitzers geroutet.
- InfoQueue: Vorgang wird auf den Infotisch des Besitzers gelegt.
- Both: Vorgang wird sowohl in die Warteschlange als auch auf den Infotisch des Besitzers geroutet.

RouteToServiceManager

Auswahl der Queue für den Verantwortlichen, der im Service eingetragen ist.

RouteToServiceAssistant

Routing an den Stellvertreter des Services.

RouteToSLAOwner

Routing an den auf dem SLA angegeben Agenten.

DirectWQRouting

Während in der Strategie DirectRouting auch immer die Belegung für den Infotisch eingetragen werden muss, bietet die Strategie DirectWQRouting nun nur die Wartschlange als Property an.

FilterRouting

Die Queues werden anhand der bestehenden Filter (definiert im Administrator) bestimmt.

LastSUOwnerRouting

Der Vorgang wird auf den Arbeitstisch des Owners der letzten ServiceUnit (SU) geroutet; dabei ist er natürlich schon reserviert.

NoRouting

Für den Fall, dass der Vorgang nur intern bearbeitet werden, also in keiner Queue auftauchen soll (Connectivity).

OwnerRouting

Der Vorgang wird auf den Arbeitstisch des Owners geroutet; dabei ist er natürlich schon reserviert.

Beachten Sie, dass mit der Auswahl OwnerRouting schon festgelegt ist, wohin der Vorgang geroutet werden soll, trotzdem aber die Eigenschaften WaitingQueue und ControlQueue eingeblendet werden. Damit soll der Fall abfangen werden, dass der Owner beispielsweise der Workflow selbst ist, und somit nirgendwo hin geroutet wird.

Sie müssen in diesen beiden Propertys ein geeignetes Instruction Set für die Warteschlange und den Infotisch eines Agenten eintragen, da ansonsten später die Kompilierung des Workflows fehlschlägt. Die Instruction Sets selbst können Sie bei Bedarf leer lassen.

Eine weitere Routing-Strategie, das Prozessrollen-Routing, wird im Zusammenhang mit Service Level Management am Ende dieses Handbuchs im Teil Workflow und Service Level Management beschrieben.

TeamRoutingStrategy

Der Vorgang wird an das Team bzw. die Person geroutet, die über die Vorgangszuweisung im Dialog ausgewählt und in der ODE HLCASEASSIGNMENT gespeichert ist.

Beachten Sie, dass die Aktivierung der Funktion Vorgangszuweisung aktivieren im Dialog Vorgangszuweisung konfigurieren für die erfolgreiche Verwendung der Team Routing Strategie zwingend notwendig ist.

Lesen Sie auch: Konfigurieren des Team-Routings, Anwenderhandbuch ClassicDesk und Zugriffsverwaltung.

Entsprechend der gewählten Assoziationsdefinition kann ein Vorgang, der per Team Routing Strategie einem Agenten zugeordnet wird, auch auf den Infotisch der anderen Teammitglieder geroutet werden. Eine Änderung an dieser Assoziation erfordert eine manuelle Reanalyse der Prozess-Instanz. Genauere Informationen hierzu erhalten Sie im Abschnitt Ausnahmen für Reservierung: Administrative Vorgangszuweisung und Reservieren durch den Besitzer.

Für diese Routing-Strategie müssen folgende Eigenschaften angegeben werden:

AddToControlQueueOfProcessManager: True: Vorgänge auf dem Infotisch des Managers, der im Designer im Dialog Vorgangszuweisung konfigurieren im Feld Manager >> Team über die entsprechende Assoziation ausgewählt wurde, werden anzeigt.; False: Die Vorgänge werden nicht angezeigt
AddToControlQueueOfServiceDesk: True: Vorgänge auf dem Infotisch von Agenten des Service Desk, die im Designer im Dialog Vorgangszuweisung konfigurieren im Feld Service Desk über die entsprechende Assoziation ausgewählt wurden, werden angezeigt.; False: Die Vorgänge werden nicht angezeigt.
AddToControlQueueOfTeamMember: True: Vorgänge auf dem Infotisch anderer Teammitglieder, die im Designer im Dialog Vorgangszuweisung konfigurieren im Feld Teammitglied >> Team über die entsprechende Assoziation ausgewählt wurden, werden angezeigt.; False: Die Vorgänge werden nicht angezeigt.
ControlQueue: Wählen Sie hier die Agenten, Gruppen und Rollen aus, auf deren Infotisch der Vorgang geroutet werden sollen.
RouteToOtherTeamMember: Über diese Eigenschaft können Sie definieren, ob der Vorgang in der Warteschlange der anderen Teammitglieder verbleiben soll, auch wenn er bereits einer Person zugewiesen wurde.
True: Der Vorgang bleibt auch bei einer persönlichen Zuweisung in der Warteschlange der anderen Teammitglieder.
False: Der Vorgang verschwindet aus der Warteschlange der anderen Teammitglieder, sobald er einer Person persönlich zugewiesen wurde.
WaitingQueueFallback: Hier können Sie eine Fallback-Warteschlange konfigurieren, in die der Vorgang geroutet wird, falls beispielsweise das Team, dem der Vorgang zugewiesen ist, keine Mitglieder hat oder die Teammitglieder keinen Agenten zugewiesen sind.

Erstellen benutzerdefinierter Routing-Strategien

Wenn Sie an Mitglieder einer bestimmten Organisationseinheit routen möchten, können Sie dies über eine benutzerdefinierte Routing-Strategie tun. Dazu steht Ihnen bei der Erstellung eigener Strategien im Activity Designer die Klasse PrincipalSupport zur Verfügung.

Die in dieser Klasse enthaltene Methode GetPrincipalsOfOrganization(ICodeContext, HLObjectIdentity, Type) liefert eine Liste von Agenten, deren zugewiesene Personen über Assoziation, die durch den Parameter associationType definiert wird, mit der Organisationseinheit, die durch den Paramater orgUnitIdentity definiert wird, assoziiert sind.

Informationen zum Erstellen eigener Strategien finden Sie im Abschnitt Erstellen von Strategien.

Ausnahmen für Reservierung: Administrative Vorgangszuweisung und Reservieren durch den Besitzer

In Workflows wird durch die gewählte Routing-Strategie sehr genau festgelegt, wer den Vorgang in der Warteschlange und dem Infotisch hat. Hierbei gilt: Nur wer einen Vorgang in der Warteschlange hat, darf ihn auch reservieren.

Da dieses Verhalten in einigen Fällen zu restriktiv ist, gibt es zwei Strategien, um hierfür Ausnahmen definieren zu können.

Diese können Sie innerhalb der helpLine Stage Activity innerhalb der Wait Handlers unter Reserve auswählen:

StratrategyStageHandlerOwnerCanReserve: Ist diese Strategie gewählt, kann innerhalb dieser Stage auch der Owner (Besitzer) den Vorgang reservieren und bearbeiten.
StrategyStageHandlerRoleCanReserve: Ist diese Strategie gewählt, können über die zusätzliche Property AdditionalRoles Agenten und Rollen angegeben werden, die den Vorgang reservieren können oder die den Vorgang durch Administrative Vorgangsreservierung per Drag and Drop (im ClassicDesk auf den Agenten in Verwaltung) zugewiesen bekommen können.