<< Click to Display Table of Contents >> Navigation:  Release Informationen > Version 2.1

Funktionen für Automatisierungen zur Zeitersparnis

Automatischer Start Bearbeitung von Tickets

Use Case:

Eindeutige Tickets sollen nicht mehr durch einen IT Mitarbeiter klassifiziert werden müssen, sondern direkt bearbeitet werden können, um manuelle Tätigkeiten bei diesen Tickets zu reduzieren

 

Umsetzung:

▪Option, dass Tickets, die aus dem Self-Service Portal (SSP) erstellt werden, automatisch in den Ticketzustand „Bearbeitung“ versetzt werden

▪Dies bezieht sich auf folgende Ticketoptionen:

•Alle Service Requests vom Typ „Bestellung“ aus dem SSP Webshop

•Tickets, die auf Basis definierter Ticket-Vorlagen erstellt werden (auch durch internen Mitarbeiter)

 

▪Sollte ein Genehmigungsprozess für das Ticket vorliegen, wird dieser automatisch gestartet

▪Sollten individuelle Pflichtfelder für den Ticket-Typ definiert worden sein, müssen diese nach wie zuvor durch den Ticketbearbeiter im Zustand „Neu“ bzw. „Klassifikation“ befüllt werden

▪Für Bestellungen können zusätzliche Standard-Kategorien vordefiniert werden (Pflichtfeld)

 

Aufgaben Workflow Pakete für Shop Artikel

Use Case:

Wenn ein Web Shop Artikel bestellt wird, sind damit ggf. bestimmte umzusetzende Aufgaben verbunden, die automatisch im Service Request erscheinen sollen und nicht manuell nachträglich angelegt werden müssen.

 

Umsetzung:

▪Erweiterung des Artikel-Verwaltungs-Formulars um eine Referenz auf Aufgaben Workflow Pakete

▪Wenn mehrere Artikel in einer Bestellung sind werden ggf. enthaltene Aufgaben Workflows in den Ticket Aufgaben nacheinander ergänzt

 

Direktes Erstellen einer Person aus dem Posteingang

Use Case:

Wenn ein unbekannter Absender eine Email gegen das Ticketsystem sendet, soll dieser einfacher direkt aus dem Emailobjekt heraus angelegt werden können, um die das Ticket direkt anlegen zu können.

 

Umsetzung:

▪Ergänzung einer entsprechenden Aktion direkt im Email Formular mit automatischer Übernahme der Absenderinformationen (Emailadresse)

 

Import für Personen: neue automatische Importoptionen

Use Case:

Bestimmte Attribute bei Personenobjekte können derzeit nicht über den Import gesetzt werden. Dieser soll um weitere sinnvolle Optionen erweitert werden, damit diese nicht nachträglich manuell gesetzt werden müssen.

 

Umsetzung:

▪Erweiterung des CSV Personen Imports und bMS AD Personen Import um folgende weitere Attribute:

•VIP (true/false)

•Zusätzliche E-mail Adressen

•Bevorzugte Kontaktart (mandatory)

•Benötigt nie eine Genehmigung (true/false)

•SSP Zugang erteilt (true/false; mandatory)

•Authentifizierungs-Option

▪Windows Domäne (muss importiert werden, wenn Authentifizierungsoption = Windows)

▪Wichtig: bei Pflichtfeldern MUSS die Importvorlage bei CSV Importen gefüllt sein (Neues CSV Template)

 

Erweiterung Nachrichten

Individuelle Nachrichten-Einstellungen je Ticket

Use Case:

Zusätzlich zu den globalen automatischen E-Mails im Ticketprozess, soll es möglich sein, diese bei einzelnen Tickets individuell zu deaktivieren. Dies ist bei z.B. bei langläufigen-Tickets hilfreich, um unnötige Emails zu vermeiden.

 

Umsetzung:

▪Optionales Einblenden eines Ticket-Tabs „Nachrichten-Optionen“ (Bearbeitungsformular und Erfassungsformular)

▪Diese bieten die Möglichkeit alle Standard-Nachrichten des Tickets zu deaktivieren, inkl. Deaktivierung aller Nachrichten, die automatisch durch den Ticketprozess versendet werden

 

Option zur Einschränkung von automatischen Nachrichten je Ticket-Typ

Use Case:

Aktuell kann eine automatische Nachrichtenvorlage für Tickets generell nur aktiviert oder deaktiviert werden. Es soll eine Möglichkeit geben diese Ticketnachricht auch nur bezogen auf einzelne Ticket-Typen aktivieren zu können.

 

Umsetzung:

▪Jede Nachrichtenvorlage erhält zusätzlich eine Liste der Ticket-Typen

▪Die Nachricht wird ausschließlich bei den angegebenen Ticket-Typen versendet

▪Wenn kein Ticket-Typ angegeben ist, wird die Nachricht bei allen Ticket-Typen versendet

 

 
Genehmigungen: Erweiterung Informationen und flexiblere Nachrichtenoptionen

 

Use Case:

Bestimmte Genehmigungen müssen an Top-Management gesendet werden. Dort werden spezifischere oder anders aufbereitete Informationen in den Genehmigungs-Emails erwartet.

Wenn mehrere Genehmiger involviert sind, wird für die eigenen Entscheidungsfindung auch die Information erwartet wer bereits genehmigt hat.

 

Umsetzung:

▪Erweiterung der Standard-Nachrichten um weitere spezifische Genehmigungsprozess-Emails:

•Je für neue, erteilte, und abgelehnte Genehmigungen

•Zuordnungsmöglichkeit Nachrichten je Genehmigungsmodell

•Darstellung auf der Nachrichtenvorlage, für welche Genehmigungsmodelle diese verwendet werden

▪Erweiterung der Nachrichtenvorlagen für Genehmigungen um dynamische Platzhalter zu den zum Zeitpunkt der Nachricht bereits getätigten Genehmigungen/ Ablehnungen und durch wen diese getroffen wurden

▪Erweiterung des Genehmigungs-Objektes um diese Informationen, auch für mehrstufige Genehmigungsprozesse

 

Emailoption für Admins, falls bMS Import Jobs fehlschlagen

 

Use Case:

Admins können bMS Import Jobs auf Basis von automatischen Zeitintervallen planen. Falls einer dieser Jobs fehlschlägt soll der Admin eine automatische Email erhalten, um diese Jobs nicht regelmäßig im System überprüfen zu müssen.

 

Umsetzung:

▪Erweiterung auf der Admin-Kachel „bMS Integration“ um eine Benachrichtigungsoption bei den bMS Import Jobs

▪Wenn aktiviert erhalten alle Benutzer mit „Administration-Voll“ Berechtigung eine automatische Systememail, wenn ein bMS Import Job fehlschlägt, mit den Informationen aus dem Job

 

Zweite Standardemail für Passwortversand

Use Case:

Wenn ein Account Passwort geändert wurde, wird dies über eine Standard Emailvorlage dem betreffenden User zugesandt. Um die Sicherheit zu erhöhen soll eine Möglichkeit geschaffen werden Username, Link auf das System und Passwort in getrennten Emails zu versenden.

 

Umsetzung:

▪Ergänzen einer zweiten identischen Nachrichtenvorlage für Passwortänderungen in der Kategorie „Personen“

▪Ein Admin hat nun die Möglichkeit selbst zu definieren, ob 2 Emails versendet werden sollen und welche Informationen in der jeweiligen Email enthalten sind

 

Automatische Übernahme des Ticket-Titels in manuelle Email-Nachrichten aus dem Ticket heraus

Use Case:

Ein Ticketbearbeiter nutzt die manuellen Nachrichtenoptionen, um an Kunden oder andere Empfänger aus dem Ticket heraus Emails zu senden. Neben der Ticketnummer soll bei jeder Nachrichtenoption im Email Betreff auch automatisch der Ticket-Titel enthalten sein, um diesen nicht selbst erfassen zu müssen.

 

Umsetzung:

▪Zusätzlich zur Ticketnummer wird automatisch auch der aktuelle Ticket-Titel in jede manuelle Nachrichtenoption aufgenommen

 

 

Erweiterungen Fragebögen

Fragebögen: Option zum Versenden desselben Fragebogens an mehrere Empfänger nacheinander

Use Case:

Bestimmte Fragebögen müssen ggf. durch mehrere Empfänger nacheinander ausgefüllt oder nochmals durch einen weiteren Empfänger überprüft, ergänzt und ggf. Antworten korrigiert werden (z.B. ein Fragebogen für Onboarding muss durch HR und Fachabteilung ausgefüllt werden).

 

Umsetzung:

▪Im Ticket-Tab „Fragebögen“ gibt es die Möglichkeit bereits beantwortete Fragebögen per Buttons nochmals selbst auszufüllen oder zu versenden

▪Sämtliche Antworten werden mit Zeitstempel in der Liste gespeichert, auch wenn die Frage mehrfach beantwortet wurde

▪Im Ticket-Tab „Fragebögen“ wird die Antworten-Liste für die bessere Zuordnung um die Spalten „Fragebogen-Titel“ erweitert

▪Der CSV Export der Antworten wird um weitere Spalten erweitert (Fragebogen-Titel; Ticket-Nr; Zeitstempel Antwort; Ersteller der Antwort)

 

Fragebögen: Nutzung von Fragebögen aus Ticket-Vorlagen auch während der Ticketbearbeitung

Use Case:

Aktuell sind Fragebögen aus einer Ticket-Vorlage nur bei Erfassung eines Tickets nutzbar. Der Vorlagen-Fragebogen soll während der gesamten Bearbeitungsdauer eines Tickets auswählbar und durch den Ticketbearbeiter oder den Empfängern ausfüllbar sein.

 

Umsetzung:

▪Im Ticket-Tab „Fragebögen“ wird der Fragebogen aus der Vorlage dargestellt, inkl. der direkten Ausfüll- oder Versende-Option

▪Wenn ein Fragebogen in der Vorlage enthalten ist, wird der Tab Fragebögen immer eingeblendet sein, auch wenn noch keine Antworten aus Fragebögen enthalten sind

 

 

Fragebögen: Erweiterung weiterer Optionen bei Fragebögen

Use Case:

Die Fragebögen werden für eine Vielzahl von Use-Cases genutzt und benötigen mehr Flexibilität und Optionen

 

Umsetzung:

▪Erweiterung der maximalen Anzahl der Fragen von 20 auf 30 bei Fragebogen Typ „Liste“

▪Einführung von möglichen Pflicht-Antworten bei Fragebogen Typ „Liste“

▪Kopierfunktion für gesamte Fragebögen, um schnell Varianten zu produzieren (beide Fragebogen-Typen)

 

Erweiterungen Optionen für Ticket-Verantwortliche Gruppen

Standardverantwortlicher für Tickets auf Basis von Standorten und Org-Units

Use Case:

Unternehmens-Einheiten haben lokale IT Mitarbeiter, die abhängig vom Standort und/oder Org.-Einheit Tickets bearbeiten sollen. Bsp.: Ein von einem Anwender eines bestimmten Standorts erstelltes Ticket soll direkt der Standortverantwortlichen Gruppe zugewiesen werden.

 

Umsetzung:

▪Ergänzung von definierbaren Standardverantwortlichen Gruppen für Standorte und Org.-Einheiten zusätzlich zu Ticket-Typ und Kategorie

▪Ergänzung einer neuen Admin-Kachel „Standard-Verantwortlichkeiten“ in dem alle bestehenden und neuen Verantwortlichkeits-Regeln zentral mittels einer Matrix gepflegt werden können

▪Einführung von Schnellauswahl Buttons an dem Ticketfeld „Verantwortliche Gruppe“, um mit einem Klick die hinterlegte Standard-Gruppe je Regel (falls vorhanden) zusätzlich manuell auswählen zu können oder immer automatisch die jeweils letzte eingetragene Gruppe zu setzen (falls Ticket zwischen 2 verantwortlichen Gruppen hin und her zugewiesen werden muss)

▪Erweiterung der Gruppenliste in der Stammdatenverwaltung um eine Baumansicht, um bei komplexen Gruppenstrukturen eine bessere Übersicht zu erhalten

 

Einschränkung für Ticketweiterleitungen

Use Case:

Es dürfen bestimmte Verantwortliche Gruppen für Tickets diese nur an bestimmte andere verantwortliche Gruppen weitergeben. Damit soll sichergestellt werden, dass bestimmte Vorgaben für die Weitergabe bzw. Eskalation von Tickets in der Organisation eingehalten werden

 

Umsetzung:

▪Einführung einer Liste auf der Verantwortlichen Gruppe, um die Einschränkungen für Ticketweiterleitungen explizit pflegen zu können

▪Wenn in einer Gruppe hier bestimmte Gruppen gepflegt sind, können in Tickets, die auf dieser Verantwortlichen Gruppe stehen, ausschließlich diese Gruppen ausgewählt werden

▪Wenn keine Gruppe in der Liste gepflegt ist können immer alle Gruppen ausgewählt werden (unveränderter Stand wie bisher)

 

Sonstige Erweiterungen

Ausblenden der Benutzername/ PW Login Option für SSP Login Maske

Use Case:

Für Kunden, die für bTS keine eigene Passwörter pflegen wollen und ausschließlich Single-Sign-On über AD Integration nutzen, soll die Benutzername/ PW Option vollständig ausgeblendet werden. Dies soll auch Missverständnisse bei den Anwendern vorbeugen, die z.B. versuchen in bTS das Windows Passwort einzugeben.

 

Umsetzung:

•Einführung einer Checkbox in der Admin-Kachel „AD-Integration“: „Passwort Login für SSP deaktivieren“

•Nur möglich wenn „AD-Login“ aktiviert ist

•Es ist nur möglich dies für SSP Login zu deaktivieren, damit für normale Benutzer immer ein mögliches Fallback vorhanden ist, falls der AD Login einmal technisch nicht verfügbar ist

 

SSP: Darstellungsoptionen für Standard Buttons „Ticket anlegen“ und „Meine Tickets“

Use Case:

Die beiden Standard Buttons „Ticket anlegen“ und „Meine Tickets“ im Header-Bereich des SSP, sollen flexiblere Darstellungsoptionen bzgl. Farbgebung und Anzeige erhalten, um das SSP an der Stelle individueller gestalten zu können.

 

Umsetzung:

▪In der Admin-Kachel „Self-Service-Portal“ wurde der Header-Bereich umgestaltet und einzelne Optionen für Farbgebung für die beiden Standard-Buttons ergänzt

▪Weiterhin können die Buttons optional ausgeblendet werden, falls diese nicht erscheinen sollen