Implementierungshandbuch › Beispiele für Fallstudien › Beispiele für die Datenmodellierung › Fallstudie 8: Helpdesk-Leistung

Fallstudie 8: Helpdesk-Leistung

Dies ist eine typische Fallstudie zur Helpdesk-Leistung.

Die nachfolgend gezeigte Datenquelle ist vorgegeben:

Die nachfolgend gezeigte Datenquelle enthält Details für die Helpdesk-Tickets, die für jeden Kunden an zahlreichen von den Kunden betreuten Standorten bearbeitet werden. Ein einzelner Standort kann auch von mehreren Kunden gemeinsam genutzt werden.

Die folgenden drei Anforderungen werden dafür benötigt, zu berichten, wann diese Datenquelle verwendet wird:

• % der Tickets der Priorität 1, die innerhalb von vier Stunden für den Kunden CM3 gelöst werden.
• % der Tickets der Priorität 1, die innerhalb von vier Stunden für den Kunden CM3 an jedem Standort gelöst werden.
• % der Tickets der Priorität 1, die innerhalb eines Tages für den Kunden CM3 an jedem Standort gelöst werden.

Die obigen Anforderungen zeigen an, dass die Events folgendermaßen gefiltert werden sollten:

• Priorität
• Kunde
• Standort

Sie müssen angeben, welche dieser Filterkriterien als Event-Typ übersetzt wird und welches die dazugehörige Ressource sein soll.

Wie wähle ich einen Event-Typ aus?

Von den drei benötigten Filterkriterien ist die Ticketpriorität aus folgenden Gründen am besten geeignet, um in ein Event-Typ übersetzt zu werden:

• Sie beschreibt die Art des Events, das bearbeitet wird (Tickets der Priorität 1).
• Die Anzahl verschiedener Prioritäten, die vorhanden sind, ist relativ klein (Priorität 1, 2, 3).
• Der Event-Typ selbst ist relativ konstant (der Helpdesk verändert selten die Prioritäten, mit der er Tickets verarbeitet).

Wie wird eine Ressource ausgewählt?

Die zwei anderen erforderlichen Filterkriterien sind "Kunde" und "Standort". Daher ist die Kombination aus Kunde und Standort die Ressource.

Kunde und Standort sind relativ feste Entitäten und haben einen bestimmten Lebenszyklus, wobei neue Kunden oder neue Standorte hinzugefügt werden können. Darüber hinaus kann sich die Beziehung zwischen einem Standort und einem Kunden ändern.

Für Übersetzungszwecke ist es möglich, mehr als ein Feld von der Datenquelle zu verwenden. Während das Serverfeld in der vorherigen Fallstudie in eine CA Business Service Insight-Ressource übersetzt wurde, wird die Ressource in diesem Fall hingegen durch die Kombination von zwei Feldern gebildet. Jede Permutation erzeugt daher eine neue Ressource.

Die Ressourcen-Liste wird unten angezeigt:

Die Ausgabe-Ressource ist eine Kombination aus Kunden- und Standortfeld und das Symbol "+" wird verwenden, um diese beiden Felder zu verbinden. Es ist wichtig, den Namen der Ressource zu kennen, da er aus der Datenquelle extrahiert und später in den Berichten angezeigt wird. Die Berichterstellungsfähigkeiten müssen den Erwartungen entsprechen.

Hinweis: Einer der häufigsten Fehler beim Modellieren eines Helpdesk-, Ticket- oder Incident-Systems ist, einen einzelnen Incident als Ressource zu definieren.

Die folgenden falschen Annahmen führen häufig zu Fehlern:

1. Der einzelne Incident ist derjenige, der im Bericht angezeigt wird. Legen Sie nicht die Entität, die für die Berichterstellung verwendet wird, als die Entität fest, für die die Berechnungen erstellt werden, d. h. der einzelne Incident sollte nicht die Grundlage für die Berechnungen des Kundenstandorts bilden. Im Allgemeinen basiert der SLA auf der Gesamtleistung und nicht auf der Bearbeitungsleistung einzelner Tickets.
2. Die Garantie erfolgt nach Ticketlevel. Dies ist ein Fehler, weil die Garantien periodisch sind. Es wird eine Aggregation über die Zeit berechnet.

Einstellen von Zuordnungen für die Ressourcen

Für die erste Berechnungsanforderung:

1. % der Tickets der Priorität 1, die innerhalb von vier Stunden für den Kunden CM3 gelöst werden.
   • Ticket-Events, die einem bestimmten Kunden zuzuschreiben sind, müssen empfangen werden. Der Kunde ist Teil dieser Ressource, die auch den Kundenstandort anzeigt. Es gibt daher zwei Optionen, um alle Events, die sich auf die Ressourcen beziehen und diesem Kunden zuzuschreiben sind, zu erfassen:
   • In Fällen, in denen der Kunde in der Datenquelle eine Vertragspartei repräsentiert, können die Ressourcen der zugehörigen Vertragspartei angehängt werden. Dies erlaubt eine Registrierung über die Vertragspartei. Dies ist immer, wo es möglich ist, vorzuziehen.
   • Erstellen Sie eine Ressourcengruppe für jeden der Kunden in der Datenquelle und gruppieren Sie alle zugehörigen Ressourcen innerhalb dieser Gruppe. Bei der Verwendung dieser Methode erfolgt die Registrierung über die Ressourcengruppe.

   Für die nächsten beiden Berechnungsanforderungen:

2. % der Tickets der Priorität 1, die innerhalb von vier Stunden für den Kunden CM3 an jedem Standort gelöst werden.
3. % der Tickets der Priorität 1, die innerhalb eines Tages für den Kunden CM3 an jedem Standort gelöst werden.

Sammeln Sie die Ressourcen für diese Anforderungen in Ressourcengruppen, da die Metriken geclustert werden müssen - vorausgesetzt, dass die Berechnung für jeden Standort individuell ausgeführt werden muss.

Hinweis: Auch wenn die Zuordnungen der Ressourcen für das aktuelle Modell und die aktuellen Anforderungen nicht notwendig sind, ist es wichtig, sie zu erstellen, um künftige Anforderungen zu berücksichtigen. Dies verhindert einen Overhead bei der zukünftigen Systementwicklung.

Auswählen des Zeitstempelfelds

Wie zuvor erwähnt ist der Zeitstempel sehr wichtig für die Art und Weise, wie die Korrelations-Engine die Events verarbeitet. Metriken berechnen das Service Level immer für einen Zeitraum, und die Events, die in diesem Zeitraum verarbeitet werden, sind diejenigen, deren Zeitstempel in diesen Zeitraum fallen.

In der ersten Fallstudie hat die Datenquelle nur ein Zeitfeld. In diesem Fall jedoch gibt es drei mögliche Felder, die als Zeitstempel festgelegt werden können. Prüfen Sie die beiden ersten Datensätze:

Um die Lösungszeit berechnen zu können, ist sowohl die Zeit in "Erzeugt am" als auch die Zeit in "Gelöst am" erforderlich. Für Event-Zwecke ist es möglich, nur einen Zeitstempel anzuhängen. Dann kann der andere als ein Wert innerhalb der Wertfelder verwendet werden.

Wenn der Wert in "Erzeugt am" als Zeitstempel verwendet wird, dann wird das Ticket in die Dezember-Ergebnisse aufgenommen. Wenn der Wert in "Gelöst am" als Zeitstempel verwendet wird, dann wird das Ticket in die Januar-Ergebnisse aufgenommen. Beide Optionen können verwendet werden. Die Auswahl muss nur den Erwartungen bezüglich des Zeitpunkts, wann die Tickets in Berichten angezeigt werden sollen, entsprechen.

Dies ist ein sehr wichtiger Punkt, der während der Implementierung zu berücksichtigen ist, da er bestimmt, wann die Events für Berechnungen verwendet werden. Wenn ein Ticket beispielsweise im November erstellt und bis Dezember noch nicht geschlossen wurde, wann sollte es in das SLA-Ergebnis aufgenommen werden? Wird es in den November-Daten oder doch in den Dezember-Daten erfasst?

In diesem Fall können die Daten nur erfasst werden, nachdem das Ticket geschlossen ist, da das Ticket erst an die Datenquelle übermittelt wird, wenn es geschlossen ist. Normalerweise liegt das "Geschlossen"-Datum nach dem "Erzeugt"- und "Gelöst"-Datum. Wenn das Datum in "Erzeugt" als Zeitstempel gewählt wurde, dann sollte es als Teil der Dezember-Ergebnisse verarbeitet werden. Das "Geschlossen"-Datum war im Januar, d. h., dass der Dezember bereits vorbei ist, als dieses Ticket übermittelt wurde. Demzufolge waren die Ergebnisse für Dezember bereits veröffentlicht worden. Die Korrelations-Engine erfasst das Event als ein in der Vergangenheit liegendes Event, das entsprechend dem Zeitstempel in den Dezember gehört, und löst eine Neuberechnung aus. Daher ändern sich die Dezember-Ergebnisse rückwirkend.

Diese Konsequenzen müssen vollkommen verstanden werden, um festlegen zu können, welches Zeitfeld als Zeitstempel gewählt werden muss. Normalerweise wird das "Geschlossen"-Datum gewählt, um Berichte zu haben, die sich nicht rückwirkend verändern.

Auf der anderen Seite verzögert die Verwendung des "Geschlossen"-Datums als Zeitstempel, dass die Tickets in die Berechnungen einbezogen werden. Ein Ticket, das gelöst wurde, kann möglicherweise nur eine beträchtliche Zeit später geschlossen werden.

Beachten Sie allerdings, dass durch die Verwendung des "Geschlossen"-Datums ein Prozess in der Organisation ausgelöst werden könnte, durch den die Zeit bis zum Schließen der Tickets verringert wird.

Der letzte Vorschlag: