Vorgangsmanagement

Grundlagen

Mit dem CURSOR-Vorgangsmanagement-Modul können zahlreiche Prozesse abgebildet werden. Beste Beispiele sind Klärung von kaufmännischen oder technischen Fragen, Beseitigung von Störungen oder Bearbeitung von Beschwerden. Zahlreiche Funktionen zur Delegation, Eskalation und Dokumentation erlauben die zeitnahe Bearbeitung von Serviceanfragen, Anliegen und ermöglichen die einfache Kommunikation mit allen Beteiligten. Die Kommunikation wird über Vorgänge abgebildet, die je nach Prozessablauf beliebig benannt werden können (z.B. "Beschwerde" oder "Anfrage"). Ein Vorgang kann optional mehrere Anliegen umfassen. 

• Anwendungsfall: Ticketbearbeitung

  • Bearbeitung (Anlage, Änderung, Delegation, Eskalation) von Serviceanfragen

  • Integration von Mail- und Portalsystemen

• Anwendungsfall: Beschwerdebearbeitung

  • Bearbeitung (Anlage, Änderung, Delegation, Eskalation) von Beschwerdevorgängen

  • Zuordnung und Verfolgung untergeordneter Beschwerdeanliegen

  • Umfangreiche Auswertungsmöglichkeiten zur Ursachenanalyse

• Vorgänge können vom unterschiedlichen Typ sein. Diese unterscheiden sich durch den hinterlegten Prozess.

• Anliegen bilden die Möglichkeit, mehrere Anliegen in einem Vorgang separat zu bearbeiten.

• Aktivitäten dienen dazu, den Kommunikationsablauf genau festzuhalten und somit auf ein gezieltes Ergebnis hinzuarbeiten.

Technische Voraussetzungen

Die folgenden Absätze beschreiben die Hinweise und Änderungen für Systeme, die vor der Version 23.1 das Kundenservice-Modul im Einsatz hatten.

Änderungen im Standard

Neuer Nummernkreis bei Vorgängen und Anliegen

• Auf dem Vorgang: Vorgangs-Nr. (TicketNo.Ticket)

  • Feldeigenschaft "Doppelte Feldwerte verhindern" wurde im Standard aktiviert

Änderung von Memofeldern

• Auf dem Vorgang: Beschreibung (Description.Ticket)

  • Hier ist eine Umwandlung von EditorPane auf HTML erfolgt

  • In dem Zuge wurde auch das Feld  Description2.Ticket umgestellt

  • Conclusion.Ticket wurde ebenfalls in HTML umwandelt

• Auf dem Anliegen: Beschreibung (Description.TicketRequest)

  • Hier istl eine Umwandlung von EditorPane auf HTML erfolgt

  • In dem Zuge wurde auch das Feld Description2.TicketRequest  umgestellt

  • Conclusion.TicketRequest wurde ebenfalls in HTML umwandelt

• Die Felder Desription2.Ticket und Desription2.TicketRequest wurden von den Masken entfernt

Benachrichtigungen

• Es wird eine Benachrichtigung an den User "Delegiert an" (Delegiert an Gruppe) versendet.

  • Dies erfolgt bei Überschreitung des Datum Erinnerungsdatum (auf dem Vorgang und Anliegen)

  • Dies erfolgt bei Überschreitung des Datum Fälligkeitsdatum (auf dem Vorgang und Anliegen)

    • Wenn beide eingetreten wird nur eine Benachrichtigung (Fälligkeitsdatum) versendet.

    • Die Benachrichtigung wird nur aktualisiert (Nur eine Benachrichtigung für Erinnerung und Fälligkeitsdatum - auch wenn diese gleich sind)

Neuer Timer zum Versand von Benachrichtigungen nach überschrittenem Datum

Es wurde ein neuer Timer "Eskalationsdatum prüfen" im Standard erstellt, welcher jede Minute prüft, ob ein Vorgang oder Anliegen Datum (Fälligkeits- und Erinnerungsdatum) überschritten wurde und versendet anschließend eine Benachrichtigung im Benachrichtigungssystem.

Aufnahme von neuen Datumsfeldern auf dem Vorgang und auf dem Anliegen

• Bei der Neuanlage eines Vorgang werden die Werte vom Erinnerungs- und Fälligkeitsdatum wie folgt vorbelegt:

• Fälligkeitsdatum (standardmäßig +14 Tage vorbelegt)

• Erinnerungsdatum (standardmäßig +7 Tage vorbelegt)

  • Wurden die hinterlegten Daten überschritten erhält die Person, welche in dem Feld "Delegiert an" hinterlegt wurde eine Benachrichtigung

• Bei der Neuanlage eines Anliegens werden die Werte vom Erinnerungs- und Fälligkeitsdatum des übergeordneten Vorgang übernommen

• Zusätzlich dazu gilt: 

  • Das Fälligkeitsdatum des Anliegens darf nicht hinter dem Fälligkeitsdatum des übergeordneten Vorgang liegen

    • Prüfung: Eine Speicherung des Datensatzes darf nicht erfolgen, wenn dies nicht gewährleistet ist 

    • Wenn durch eine manuelle Änderung  durch Speichern  das Fälligkeitsdatum des Vorgang vor dem Fälligkeitsdatum des Anliegen liegt, so wird automatisch das Fälligkeitsdatum des Anliegen mit dem Fälligkeitsdatum des Vorgang gleichgesetzt 

    • Wenn durch eine manuelle Änderung das Fälligkeitsdatum des Anliegen hinter dem Fälligkeitsdatum des Vorgang liegt, so soll die manuelle Änderung und die Abspeicherung verhindert werden. Stattdessen wird der letzte gültige Wert für das Fälligkeitsdatum es Anliegens verwendet → Zurücksetzen auf letzten Wert

Neues Feld Ansprechpartner auf dem Anliegen

Es gibt ein neues Feld Ansprechpartner auf dem Anliegen, welches bei der Neuanlage mit dem Ansprechpartner aus dem übergeordneten Vorgang vorbelegt wird.

Änderungen an der Skriptbibliothek SC0TicketUtils

Folgende Anpassungen sind in der Skriptbibliothek SC0TicketUtils erfolgt:

Optional: Klassifikationen für einzelne Abteilungen individualisieren.

Es besteht die Möglichkeit abhängig vom Tickettyp unterschiedliche Schlüssel in der Klassifikation und Unterklassifikation zu hinterlegen. Dies kann somit in drei Stufen konfiguriert werden: Tickettyp - Klassifikation - Unterklassifikation. Sollen in diesen Schlüsselbereichen allgemeine Schlüssel (für alle Personen) hinterlegt werden, muss diese Konfiguration nicht durchgeführt werden, nur wenn beispielsweise abteilungsindividuelle Schlüssel hinterlegt werden sollen, welche andere Abteilungen nicht sehen oder auswählen sollen.

Feldeigenschaft in dem Feld Unterklassifikation (Classification2.Ticket):
Nachschlagesuche: 

LookupEntityS_KeytabKeyMappings

Vorselektion beim Validieren:

MasterKey.KeyMappings.EQUAL={Classification.Ticket}
MasterKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION
SlaveKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION2
Active.KeyMappings.EQUAL=1

Feldeigenschaft in dem Feld Klassifikation (Classification.Ticket):
Nachschlagesuche:

LookupEntityS_KeytabKeyMappings

Vorselektion beim Validieren:

MasterKey.KeyMappings.EQUAL={TicketType.Ticket}
MasterKeyRange.KeyMappings.EQUAL=C0TICKET_TYPE
SlaveKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION
Active.KeyMappings.EQUAL=1

Migration für Bestandskunden

Bei Kunden, welche das Kundenservice-Modul lizenziert und über Customizing verändert haben, muss innerhalb des Projekts geprüft werden, welche Auswirkungen die Anpassungen im Standard haben. Hier muss eine projektindividuelle Lösung gefunden werden.

Änderung der Sprachvariablen

Die Sprachvariablen wurden von der modulspezifischen Internationalisierung in die Skriptbibliothek (Skript-Klasse SC0TICKETUTILS) Sprachvariablen verschoben. Hierdurch hat sich auf der Skript Aufruf String I18nUtils.i18nModule(String moduleID, String key, Locale language, Object... parameter) in den Skript Aufruf String I18nUtils.i18nCustom(String key, Locale language, Object... parameter) im Standard geändert. Dies muss bei allen übersteuerten Prozessen im Bereich des Vorgangsmanagement nachgezogen werden.

Folgende Prozesse haben in C0 ihr I18n vom Modul in die Sprachvariablen verschoben. Dies ist in höheren Schichten nachzuholen, sofern einer davon übersteuert wurde:

• C0TicketAddActivity

• C0TicketCompletion

• C0TicketCompletionSub

• C0TicketCreation

• C0TicketMailSending

• C0TicketReopen

• C0TicketRequestCompletion

• C0TicketRequestCreation

Folgende Prozesse haben in C0 kein i18n enthalten, müssten aber im Falle einer Übersteuerung trotzdem geprüft werden ob dort etwas eingebaut wurde.

• C0TicketCreateActivityFromNotesField

• C0TicketLinkActivity

• C0TicketRequestCreateActivityFromNotesField

• C0TicketDelegateToGroup

• C0TicketLinkComment

• C0IB_CreateRequestTicket

Ersetzt werden muss jeder Aufruf wie

I18nUtils.i18nModule("TICKET", "<key>", SessionConstants.LOCALE);

durch

I18nUtils.i18nCustom("<key>", SessionConstants.LOCALE);

b.better

b.better ist nun ein eigenes Modul. Bei dem Update auf die Version 23.1. wird geprüft, ob es b.better spezifische Datensätze gibt. Dies erfolgt wie folgt:

• Sind in den Entitäten Ticket-Begründung (TicketReason) und Ticket-Klassifizierung (TicketClassify) Datensätze vorhanden, dann wird das Beschwerdemanagement Modul (b.better) NICHT entfernt

  • Das löschende Update wird NICHT ausgeführt, wenn in Ticket-Klassifizierung / Begründung Datensätze vorhanden sind

• Sind in den Entitäten Ticket-Begründung (TicketReason) und Ticket-Klassifizierung (TicketClassify) KEINE Datensätze vorhanden, dann wird das Beschwerdemanagement Modul (b.better) entfernt

  • Das löschende Update wird ausgeführt, wenn in Ticket-Klassifizierung / Begründung KEINE Datensätze vorhanden sind

Wichtig: Die Standardmasken TicketBbetter  und  TicketRequestBbetter  wurden gelöscht. Sollen diese nach dem Update auf die Version 23.1. noch verwendet werden, müssen diese VOR dem Update übersteuert werden.

• Umbenennung Kundenservicemodul in Beschwerdemanagement

• Entitäten Ticket und Ticket-Anliegen wurden in Vorgang und Anliegen umbenannt und aus dem Modul heraus gelöst

• Standard Vorgangsmanagement-Logiken wurden ebenfalls aus den Modul heraus gelöst und funktionieren nun ohne eingespieltes Modul

• Einzelne Felder und Infoboards von Vorgang und Anliegen, welche speziell für das Beschwerdemanagement b.better verwendet werden, bleiben im Modul bestehen

• Ein neuer Schlüssel BB - bbetter steuert die neue Maskenlogik und blendet nach der Auswahl die b.better spezifischen Karten (und somit Felder) ein

  • Es ist somit ggf. eine Umstellung des Maskenskript oder der Maske notwendig

• Die Masken TicketBbetter und TicketRequestBbetter wurden gelöscht

  • Hat ein Kunde eine der Masken ausgewählt, aber nicht übersteuert, wird er automatisch auf die neue Maske umgestellt. Dort werden die b.better Felder (bzw. Karten) über die neue Logik ein und ausgeblendet

  • Hat ein Kunde die Masken übersteuert und angepasst, so werden nur die C0 Masken gelöscht. Die C2 Varianten bleiben bestehen, sodass für den Kunden kein Unterschied entsteht

Achtung

Wenn der Kunde vor dem Update das Anpassen der Masken auf das neue Design NICHT wünscht, so müssen die alten Masken in der Kundenschicht (C2-Schicht) übersteuert werden.

Beschreibung des Vorgangs-Prozesses

Prozessstart

Der Kundenservice-Prozess kann über verschiedene Bereiche gestartet werden:

• Geschäftspartner (mittels Aktionsbox)

• Ansprechpartner (mittels Aktionsbox)

• Aktivitäten (mittels Aktionsbox)

• Vorgänge (direkte Neuanlage)

Alternativ können die Vorgänge, Anliegen und andere verknüpfte Daten über vorkonfigurierte Standard- oder Vertiebs-Boards (mit der Kachel "Scores") eingesehen werden. Hierzu sollen die Boards auf dem Cockpit platziert werden. 

Einstieg über Geschäftspartner oder Ansprechpartner

Über Geschäftspartner oder Ansprechpartner kann der Kundenservice-Prozess mittels Aktionsbox (Vorgangsmanagement → Ticket anlegen) gestartet werden. Nach der Neuanlage des Tickets wird der Geschäftspartner und/ oder Ansprechpartner mit vorbelegt und somit eine direkte Verknüpfung hergestellt.

Neuanlage von Vorgängen und Felder-Vorbelegung

Die Neuanlage wird über Einstiegspunkte gestartet. Die Darstellung des Vorgang-Status und das Aktivitäten-Protokoll sind über Infokacheln abgebildet.

Pflichtfelder:

• Betreff

• Typ

  • Allgemein

  • bbetter (nur bei b.better Kunden auswählbar, dieser Schlüssel steuert die Sichtbarkeit der b.better Felder)

  • Ticket

• Ansprechpartner

• Geschäftspartner (wird nach der Auswahl des Ansprechpartner automatisch vorbefüllt)

Weitere Felder:

• Status, Priorität und Beschreibung sind selbsterklärend

• Initiator = Anlageuser

• Delegiert an - der Vorgang kann an eine bestimmte Person delegiert werden

• Delegiert an Gruppe - der Vorgang kann an eine Gruppe (z.B. Abteilung) delegiert werden.

• Fälligkeitsdatum (standardmäßig +14 Tage vorbefüllt)

• Erinnerungsdatum (standardmäßig +7 Tage vorbefüllt)
  Beide Werte können angepasst werden. Die Logiken sorgen dafür, dass das Erinnerungsdatum nicht nach dem Fälligkeitsdatum gesetzt wird. Zu den definierten Terminen wird dann immer die Person per Benachrichtigung informiert, die im Feld "Delegiert an" hinterlegt wurde. 

• Felder Eingang und Eingangsart sind selbsterklärend

• Klassifikation und Unterklassifikation
  Zweisstufige Abhängigkeit, die eine Schlüsselauswahl in der Unterklassifikation erlaubt.
  Die erste Abhängigkeit wird vom Vorgangs-Typ vorbestimmt, welche Schlüssel in der Klassifikation wählbar sind.  In der zweiten Stufe hängen die Schlüssel der Unterklassifikation von den Schlüsseln der Klassifikation ab.

Beim Speichern wird vom System die Vorgangsnummer generiert. Diese setzt sich aus dem Typ und einer hochgezählten siebenstelligen Zahl zusammen. Zusätzlich werden in der Aktionsbox dazugehörige Aktionen angeboten.

Nicht aktive Aktionen werden ausgegraut. 

Delegation von Vorgängen (Weiterleitung)

Es gibt die Möglichkeit, Vorgänge über einen Hinweistext auf der Bearbeitungskachel an einen anderen Mitarbeiter zu delegieren. Das geschieht wie folgt:

• Delegiert an = <Kürzel des betreffenden Kollegen>

• Neuen Kommentar erstellen

Beim Speichern schlägt das Ticket in der ToDo-Liste des delegierten Kollegen auf:

• Schnellstartleiste unter "Offene Aktionen“

Der Ablauf wird im Aktivitäten-Protokoll festgehalten.

Gruppendelegation

Hier ist eine Logik derart hinterlegt, dass entweder das Feld Delegiert an oder Delegiert an Gruppe gefüllt sein kann. Beide Felder können nicht gleichzeitig gefüllt sein, so dass beim Befüllen eines Feldes das andere geleert wird. 

An eine Gruppe delegiertes Ticket reagiert auf Prozesse 

Wenn ein Ticket an eine Gruppe delegiert wurde und man einen Prozess startet, erwartet man, dass das Ticket an denjenigen delegiert, der den Prozess gestartet hat. Die Gruppendelegation wird somit entfernt und das Ticket ist an einen Mitarbeiter delegiert.

Typen von Vorgängen

Ein Vorgang kann drei verschiedene Typen haben:

• Allgemein

• bbetter (nur bei b.better Kunden auswählbar, dieser Schlüssel steuert die Sichtbarkeit der b.better Felder)

• Ticket

Durch den Vorgangs-Typ können Masken für Vorgänge unterschiedlich konfiguriert werden. Sowohl Felder als auch ganze Kacheln können z.B. je nach Abteilung unterschiedlich belegt werden.

Des Weiteren können auch untergeordnete Anliegen unterschiedlich aussehen, dies wird ebenfalls über den Schlüssel Typ auf dem Vorgang gesteuert.

Nach dem initialen Speichern wird der Vorgangs-Typ schreibgeschützt und kann nicht mehr verändert werden.

Einstieg über Aktivitäten

Über Aktivitäten kann der Vorgangs-Prozess ebenfalls mittels Aktionsbox (Vorgangsmanagement → Ticket oder Vorgang anlegen ) gestartet werden, hier wird der Vorgang entweder mit dem Schlüssel TICKET oder ALLGEMEIN vorbelegt. Nach der Neuanlage des Tickets können diverse Felder wie folgt mit vorbelegt werden:

Bearbeitung von Vorgängen

Eine Abbildung von mehreren Anliegen zu einem Vorgang ist über die Aktionsbox möglich. Eine Fortschrittsanzeige und das Aktivitäten-Protokoll geben jederzeit eine Übersicht zum aktuellen Status des Vorgangs.

In der Aktionsbox sind folgende Prozesse implementiert:

• Aktivität anlegen (Erzeugt eine Aktivität zum aktuellen Ticket)

• Anliegen abschließen (Erzeugt eine Abschlussaktivität, in der das Ergebnis sowohl im Ticket, als auch auf der Aktivität festgehalten wird)

• Vorgang abschließen (Erzeugt eine Abschlussaktivität, in der das Ergebnis sowohl im Ticket, als auch auf der Aktivität festgehalten wird)

• Rückfrage an Kunde (Erzeugt eine Aktivität mit vorgefertigten Werten)

• Vorgang wieder eröffnen (Eröffnet einen bereits geschlossenen Vorgang)

Zuordnung mehrerer Anliegen zu einem Vorgang

Anliegen sind funktionale Erweiterungen der Vorgänge, um noch detailliertere Informationen zu hinterlegen, bzw. um mehrere Anliegen einzeln zu behandeln und trotzdem unter einem Vorgang (Sammler) laufen zu lassen. Der Abschluss von Vorgängen und Anliegen wird für den Anwender geführt abgearbeitet.

Zu einem Vorgang können mehrere Anliegen erfasst werden. Folgende Felder werden automatisch aus dem übergeordneten Vorgang übernommen:

• Ansprechpartner

• Geschäftspartner

• Initiator

• Priorität

• Fälligkeitsdatum (bezieht sich auf Termine des übergeordneten Vorgangs und darf diese nicht übersteigen)

• Erinnerungsdatum (bezieht sich auf Termine des übergeordneten Vorgangs und darf diese nicht übersteigen)

Bei der Neuanlage von Anliegen werden die Ticket-Anliegen-Nummern über ein Skript generiert. Dies ist immer im Kontext zu dem übergeordneten Ticket zu sehen und beginnt mit 001.
Ein Anpassen des Pattern-Wert sollte daher über die Skript-Klassen-Methode erfolgen: SC0TicketUtils.applyTicketRequestNumber

• Delegiert an = Anlageuser

• Das Pflichtfeld Betreff muss manuell gefüllt werden.

• Anliegennummer wird automatisch generiert

• Status wird auf Offen gesetzt

Aktivitäten

Aktivitäten dienen dazu, alles, was in dem Prozess gemacht wurde, zu protokollieren. Die Inhalte werden dann auf den Infoboards auf dem Tab Kommentare dargestellt.

Vorgangbezogene Kundenrückfragen und weitere Aktivitäten

Liegt ein gespeicherter Vorgang vor, kann die Kommunikation mit dem Kunden stattfinden. Außerdem können weitere Informationen über Aktivitäten in der Aktionsbox Aktivität anlegen hinzugefügt werden. Es öffnet sich eine Aktivität mit vorbelegten Werten bzw. Text.

Automatische Zuordnung von Aktivitäten

Eine Rückfrage an den Kunden kann über die Aktionsbox Rückfrage an Kunde direkt aufgerufen werden.

Es besteht auch die Möglichkeit, ins System importierte Aktivitäten (z.B. manuell oder über den BCC-Importer) direkt mit einem Vorgang und dem Anliegen zu verknüpfen.

Wird auf dem Vorgang (oder Anliegen) über die Aktionsbox der Prozess Rückfrage an Kunde gestartet, wird im Betreff-Feld eine 7-stellige Nummer mit einem # davor vergeben. Diese Nummer dient der eindeutigen Zuordnung zum Vorgang. Auf der Anliegen-Ebene wird hinter der Ticket-Nummer noch eine dreistellige Ticket-Anliegennummer generiert. Aus dem Feld Ansprechpartner im Vorgang (Anliegen) wird die E-Mail-Adresse als Antwortadresse übernommen.

Wenn diese Aktivität also per Mail versendet wird und anschließend eine Antwort zurückkommt, so wird beim Import in das System die 7-stellige Nummer mit dem # davor überprüft und entsprechend zugeordnet.

Es besteht die Möglichkeit, auch eine individuelle Namenskonvention zu vergeben. Diese kann in der Skript-Klasse SC0TicketUtils und der Skript-Methode generateTicketNoFromActivity angepasst werden.

Abschließen von Prozessen

Prozess "Anliegen abschließen"

Der Prozess kann unter folgenden Bedingungen abgeschlossen werden:

• bei Abschluss eines noch offenen Anliegens kann der der Anwender in diese offenen Anliegen über das Kanban-Tab springen

• zunächst werden alle Anliegen und dann der Vorgang abgeschlossen

• nach dem letzten Anliegen wird auch der Vorgang direkt abgeschlossen

• beim Abschließen des letzten Ticket-Anliegens wird auch das Ticket mit einer Rückfrage geschlossen

Prozess "Vorgang abschließen"

Der Prozess kann unter folgenden Bedingungen abgeschlossen werden:

• Ein Vorgang kann erst beendet werden, wenn alle zugehörigen Anliegen ebenfalls beendet wurden

• (1. Möglichkeit) Über das Tab Anliegen kann man noch offene Anliegen in der Kachel suchen, anzeigen und einzeln abschließen.
  Wird das letzte Anliegen geschlossen, kommt eine Abfrage, ob der Vorgang ebenfalls abgeschlossen werden soll 

• (2. Möglichkeit) Bei der Änderung des Vorgangs-Status oder über den Klick in der Aktionsbox (Vorgang  abschließen) Beim Abschließen eines Vorgangs kommt eine Abfrage, ob auch alle Ticket-Anliegen abgeschlossen werden sollen. (Nach Bestätigung werden die Ticket-Anliegen dann auch abgeschlossen).
  Hier springt man direkt die noch nicht erledigten Anliegen an, um sie zu schließen. Seqventiell werden dann Anliegen und Vorgang im Feld Ergebnis dokumentiert und abgeschlossen. 
  In Kommentaren wird die Person erfasst, die das jeweilige Anliegen oder den Vorgang geschlossen hat. 

• Das Ergebnis des Vorgangs kann durch einen individuellen Text erfasst werden.

Wiedereröffnen von Vorgängen

Öffnen von bereits geschlossenen Vorgängen ist über den Aktionsboxeintrag Vorgang wiedereröffnen möglich. Danach wird der Vorgangs-Status wieder auf Offen gesetzt. Nun können weitere Anliegen angelegt und abgearbeitet werden.

Wiedereröffnen von Anliegen

Öffnen von bereits geschlossenen Anliegen ist über den Aktionsboxeintrag Anliegen wiedereröffnen möglich. Danach wird der Anliegen-Status wieder auf Offen gesetzt. Der übergeordnete Vorgang wird ebenfalls wieder eröffnet.