Kennzahlen um den Erfolg eines TIcketsystems zu messen

[DerHarte]

Hallo

Bin mir nicht sicher ob das Thema hier richtig aufgehoben ist, aber ich poste es mal hier.

Bei meiner neuen Arbeitsstelle ist mein erstes größeres Projekt ein Ticketsystem zu installieren. Jedoch erstmal nur zu internen Dokumentation für die IT-Abteilung und daher sind die "Kunden" nur die Mitarbeiter.
Ich habe jetzt schon ein Ticketsystem ausgewählt und fast alles entsprechend eingerichtet und könnte eigentlich schon damit produktiv arbeiten. 

Da es vorher kein Ticketsystem gab, ist das grundsätzliche Ziel das Tagesgeschäft der IT zu entlasten.

Jetzt zu meiner Frage:
Wie kann ich messen ob das Ticketsystem diesem Ziel gerecht wird?
Da es vorher kein Ticketsystem gab, gibt es keine Vergleichswerte. Sonst könnte ich natürlich schauen, wie viele Tickets erstellt wurden und wie lange die durchschnittliche Arbeitszeit an einem Ticket ist.

Habt ihr hier Ideen, wie ich hier weiterkomme?

 

Vielen Dank im Voraus!

[tkreutz2]

Suche mal nach S.M.A.R.T Kriterien und überlege, welche Kriterien dabei helfen könnten.

[TooMuchCoffeeMan]

Welche Prozesse bzw. Tickets werden denn mit dem Ticketsystem überhaupt abgebildet? Service Requests? Incidents? Problems? Change Requests?

Zunächst mal solltest du abgrenzen welcher Prozess hier abgebildet wird und in welchen Grenzen er verläuft. Im Prozess gibt es Stakeholder, deren Rollen sollten definiert werden. Welche Arten von Tickets kann es geben. Wie unterscheiden sich diese Tickets voneinander. Wie ist der Regelprozess bzw. der "goldene Pfad" eines Tickets? Gibt es Genehmigungsprozesse? Wenn ja, wird die Aufgabentrennung (Segregation of Duties) beachtet? Gibt es Dispatcher die Tickets zuteilen? Gibt es eine Knowledge Base die genutzt wird? Gibt es regelmäßige Ergebnis- und Performance Evaluationen?

Damit hast du erstmal genügend Stoff für deine gute Dokumentaiton.

Wenn es dir rein um Kennzahlen geht, solltest du vorsichtig sein welche Kennzahlen du einführst und dir immer der Wechselwirkung bewusst sein. Wenn z.B. getracked wird wie hoch die Durchlaufzeiten von ServiceRequest-Tickets ist, dann kann ein Nebeneffekt davon sein, dass Bearbeiter die Tickets gerne schnell schließen wollen. Das läuft einer erfolgreichen Bearbeitung des Tickets unter Umständen zuwider, sofern es sich nicht um ein Standardproblem handelt.

Lange Rede, kurzer Sinn: Du solltest zunächst die Ziele definieren, die dein Unternehmen mit dem Ticketsystem erreichen will. Erst dann kannst du sinnvolle Kennzahlen definieren.

 

 

Bearbeitet 21. September 2020 von TooMuchCoffeeMan

[Rabber]

Da es bis dato gar kein Ticketsystem gab, vermute ich, dass auch die zugrunde liegenden Prozesse nicht übermäßig detailliert ausformuliert und standardisiert sind. Von daher ist es schwierig, hier einen A/B-Vergleich anzustellen, da mit der Einführung des Ticketsystems höchstwahrscheinlich auch Prozessänderungen einhergehen.

Ich würde deshalb mit dem kleinen 1x1 anfangen:

• Welche Prozesse sind von dem neuen Ticketsystem betroffen?
  Musstet Ihr diese anpassen, wenn ja wie und was versprecht Ihr Euch davon?
• Grundlegende Kennzahlen: Anzahl aktiver Nutzer im Ticketsystem, Anzahl erstellter Tickets, usw.
  Diese dann im Monatsvergleich z. B.

Natürlich kannst Du die dollsten Burndowns bringen, andere Charts und Metriken auftischen. Das wird die Entscheider aber vermutlich mehr verwirren, als dass es ihnen nützt. Du musst die Empfänger des Reports zuerst an das Thema heranführen und darlegen, welche Vorteile dies bringt.

Und ganz wichtig: Wenn Du weißt, wer den Report erhalten soll, kläre mit demjenigen, was seine Ziele sind und was sich der Empfänger davon verspricht. Es bringt Dir wenig, wenn wir Dir darlegen, dass bei Firma X oder Y Kennzahl K1 oder K2 im Vordergrund stehen, wenn bei Euch etwas ganz anderes gefordert wird.

[DerHarte]

Schon mal danke für die vielen Antworten.

 

vor 10 Stunden schrieb TooMuchCoffeeMan:

Welche Prozesse bzw. Tickets werden denn mit dem Ticketsystem überhaupt abgebildet? Service Requests? Incidents? Problems? Change Requests?

Zunächst mal solltest du abgrenzen welcher Prozess hier abgebildet wird und in welchen Grenzen er verläuft. Im Prozess gibt es Stakeholder, deren Rollen sollten definiert werden. Welche Arten von Tickets kann es geben. Wie unterscheiden sich diese Tickets voneinander. Wie ist der Regelprozess bzw. der "goldene Pfad" eines Tickets? Gibt es Genehmigungsprozesse? Wenn ja, wird die Aufgabentrennung (Segregation of Duties) beachtet? Gibt es Dispatcher die Tickets zuteilen? Gibt es eine Knowledge Base die genutzt wird? Gibt es regelmäßige Ergebnis- und Performance Evaluationen?

Damit hast du erstmal genügend Stoff für deine gute Dokumentaiton.

Wenn es dir rein um Kennzahlen geht, solltest du vorsichtig sein welche Kennzahlen du einführst und dir immer der Wechselwirkung bewusst sein. Wenn z.B. getracked wird wie hoch die Durchlaufzeiten von ServiceRequest-Tickets ist, dann kann ein Nebeneffekt davon sein, dass Bearbeiter die Tickets gerne schnell schließen wollen. Das läuft einer erfolgreichen Bearbeitung des Tickets unter Umständen zuwider, sofern es sich nicht um ein Standardproblem handelt.

Lange Rede, kurzer Sinn: Du solltest zunächst die Ziele definieren, die dein Unternehmen mit dem Ticketsystem erreichen will. Erst dann kannst du sinnvolle Kennzahlen definieren.

 

 

Also grundsätzlich lässt sich sagen, dass erstmal alle Prozesse bzw. Tickets abgebildet werden sollen, die vorher via Telefon, Mail, Flurfunk oder durch "in der Tür stehen" erstellt wurden.

Es soll einfach alles ausgelagert werden und das grundsätzliche Ziel ist es das Tagesgeschäft zu entlasten, dringliche und wichtige Tickets priorisiert zu bearbeiten und daraus im besten Fall eine Knowledgebase erstellen.

Du hast natürlich Recht, dass man mit den Kennzahlen aufpassen muss. Da ich schon selbst als Supporter bzw. "Agent" gearbeitet hab, weiß ich dass man versucht die Ziele zu erreichen und dann evtl. schneller aber nicht qualitativer antwortet etc.
Das spielt aber in diesem Fall keine Rolle, da wir eigentlich nur 2-4 Mitarbeiter in der IT-Abteilung sind und um uns ca. 70 Mitarbeiter kümmern müssen.

 

vor 9 Stunden schrieb Errraddicator:

Da es bis dato gar kein Ticketsystem gab, vermute ich, dass auch die zugrunde liegenden Prozesse nicht übermäßig detailliert ausformuliert und standardisiert sind. Von daher ist es schwierig, hier einen A/B-Vergleich anzustellen, da mit der Einführung des Ticketsystems höchstwahrscheinlich auch Prozessänderungen einhergehen.

Ich würde deshalb mit dem kleinen 1x1 anfangen:

• Welche Prozesse sind von dem neuen Ticketsystem betroffen?
  Musstet Ihr diese anpassen, wenn ja wie und was versprecht Ihr Euch davon?
• Grundlegende Kennzahlen: Anzahl aktiver Nutzer im Ticketsystem, Anzahl erstellter Tickets, usw.
  Diese dann im Monatsvergleich z. B.

Natürlich kannst Du die dollsten Burndowns bringen, andere Charts und Metriken auftischen. Das wird die Entscheider aber vermutlich mehr verwirren, als dass es ihnen nützt. Du musst die Empfänger des Reports zuerst an das Thema heranführen und darlegen, welche Vorteile dies bringt.

Und ganz wichtig: Wenn Du weißt, wer den Report erhalten soll, kläre mit demjenigen, was seine Ziele sind und was sich der Empfänger davon verspricht. Es bringt Dir wenig, wenn wir Dir darlegen, dass bei Firma X oder Y Kennzahl K1 oder K2 im Vordergrund stehen, wenn bei Euch etwas ganz anderes gefordert wird.

Da hast du Recht. Die Prozesse nicht ausformuliert und teilweise noch veränderbar, da die disziplinarische IT-Abteilung erst noch ensteht. 

Bezüglich des Reports bzw. der Kennzahlen für wen diese sind. Das ist ganz einfach. Diese sind erstmal nur für mich.
Nur als Hintergrund: Ich musste bei meinen 4 Projekten jeweils Ziele definieren und diese sollen dann beim nächsten Gespräch behandelt werden. Natürlich wird vorher überprüft, ob die Ziele sinnvoll sind, aber bei diesem Projekt tu ich mir ein wenig schwer.

Wie oben geschrieben, soll grundsätzlich nur das Tagesgeschäft entlastet bzw. digitalisiert werden, damit man sich um wichtigere Dinge kümmern kann.

vor 9 Stunden schrieb Errraddicator:

 

• Welche Prozesse sind von dem neuen Ticketsystem betroffen?
  Musstet Ihr diese anpassen, wenn ja wie und was versprecht Ihr Euch davon?
• Grundlegende Kennzahlen: Anzahl aktiver Nutzer im Ticketsystem, Anzahl erstellter Tickets, usw.
  Diese dann im Monatsvergleich z. B.

 

Der Vorschlag ist schon mal ein guter Anfang. ich werde dies aber auch so ansprechen, dass das Ziel schwer messbar ist und evtl. gibt es einen Alternativvorschlag.

 

[tkreutz2]

vor 49 Minuten schrieb DerHarte:

Also grundsätzlich lässt sich sagen, dass erstmal alle Prozesse bzw. Tickets abgebildet werden sollen, die vorher via Telefon, Mail, Flurfunk oder durch "in der Tür stehen" erstellt wurden.....

Es soll einfach alles ausgelagert werden und das grundsätzliche Ziel ist es das Tagesgeschäft zu entlasten, dringliche und wichtige Tickets priorisiert zu bearbeiten....

...... da wir eigentlich nur 2-4 Mitarbeiter in der IT-Abteilung sind und um uns ca. 70 Mitarbeiter kümmern müssen....

Die Prozesse nicht ausformuliert und teilweise noch veränderbar, da die disziplinarische IT-Abteilung erst noch ensteht. 

Wie oben geschrieben, soll grundsätzlich nur das Tagesgeschäft entlastet bzw. digitalisiert werden, damit man sich um wichtigere Dinge 

Die Konstellation halte ich dahingehend für problematisch, da hierdurch auch neue Problemkreise auftreten können.

Durch die Kanalisierung ist davon auszugehen, dass eine hohe Last auf den Schultern des Dispatchers liegt, also den Personen, welche die Klassifizierung vornehmen.

Wenn das die selben Personen sind, die auch lösen und bearbeiten sollen,  entsteht eigentlich das Gegenteil von Entlastung, da zusätzliche Dokumentationsaufgaben wahrgenommen werden sollen.

Wie soll das in der Praxis denn so laufen und wie ist dies organisiert ?

Bearbeitet 21. September 2020 von tkreutz2

[DerHarte]

vor 3 Minuten schrieb tkreutz2:

Die Konstellation halte ich dahingehend für problematisch, da hierdurch auch neue Problemkreise auftreten können.

Durch die Kanalisierung ist davon auszugehen, dass eine hohe Last auf den Schultern des Dispatchers liegt, also den Personen, welche die Klassifizierung vornehmen.

Wenn das die selben Personen sind, die auch lösen und bearbeiten sollen,  entsteht eigentlich das Gegenteil von Entlastung, da zusätzliche Dokumentationsaufgaben wahrgenommen werden sollen.

Wie soll das in der Praxis denn so laufen ? 

Ich bin ja noch nicht lange in der Firma und kann daher nur die letzten Wochen beurteilen was die Anzahl an Tickets angeht.
Aber das sind so ca. 5-10 am Tag. Ob das mit einem Ticketsystem mehr wird, kann ich nicht beurteilen.
Von diesen maximal 10 Tickets sind 1/3 von einer bestimmten Software was ein bestimmter Kollege macht (macht er auch im Moment, nur gehen die "Tickets" im Moment per E-Mail-Verteiler an ihn).
Die restlichen Tickets sind dann andere Probleme mit den IT-Systemen bzw. der Software oder Hardwaretausch etc.

Letztendlich werden wir zu zweit Dispatchen bzw. den FLS erledigen und teilweise natürlich auch selbst die Tickets bearbeiten.

Im Moment ist es einfach so, dass man immer wieder neue Tickets durch die Tür oder den Flur bekommt, dann sitzt man wieder in Meetings, muss sich um die Infrastruktur kümmern und hat noch seine eigenen Projekte.

Dennoch ist es alles andere als "Stress" oder zu viel bis jetzt. Daher würde ich behaupten, dass mit einem Ticketsystem nicht das Gegenteil entstehen könnte.

 

[tkreutz2]

vor 10 Minuten schrieb DerHarte:

Ich bin ja noch nicht lange in der Firma und kann daher nur die letzten Wochen......
Dennoch ist es alles andere als "Stress" oder zu viel bis jetzt. Daher würde ich behaupten, dass mit einem Ticketsystem nicht das Gegenteil entstehen könnte.
 

Gibt es denn eine Modell-  oder Testphase, vor einem Go-Live ? Also ein Zeitraum, in dem man noch steuernd in Abläufe eingreifen kann, wenn etwas in der Praxis anders laufen sollte, als in der Theorie geplant ? (Sogar Hamburgerküchen durchlaufen gewisse Prozesstrainings- und Simulationen, bevor etwas im echten Ablauf gesetzt wird). Das wäre die Frage nach einer Qualitätssicherung in den Prozessabläufen.

[DerHarte]

vor 7 Minuten schrieb tkreutz2:

Gibt es denn eine Modell-  oder Testphase, vor einem Go-Live ? Also ein Zeitraum, in dem man noch steuernd in Abläufe eingreifen kann, wenn etwas in der Praxis anders laufen sollte, als in der Theorie geplant ? (Sogar Hamburgerküchen durchlaufen gewisse Prozesstrainings- und Simulationen, bevor etwas im echten Ablauf gesetzt wird). Das wäre die Frage nach einer Qualitätssicherung in den Prozessabläufen.

Das hab ich vielleicht vergessen zu erwähnen, aber das ganze wird natürlich eine Testphase haben.
Aber wie oben schon erwähnt oder auch erahnt, weiß ich natürlich noch gar nicht genau, inwieweit wir bestimmte Arbeitsprozesse oder Anforderungen im Ticketsystem abbilden können.

Daher hab ich mich auch erstmal für ein kostenloses Ticketsystem entschieden, um zu sehen was auf uns zukommt.
Wenn das Ticketsystem für die ersten Anforderungen reichen sollte, lässt man dies erstmal laufen.
Falls wir mehr Anforderungen haben, könnte man sich sonst für ein anderes Tool wie z. B. von Jira entscheiden.

Also eine produktive Testphase so gesehen. Ich werde wahrscheinlich auch erst zunächst nur eine Abteilung dies produktiv testen lassen und schauen wie das funktioniert und dann die anderen Abteilungen dazuholen.

[tkreutz2]

vor 13 Stunden schrieb DerHarte:

Das hab ich vielleicht vergessen zu erwähnen, aber das ganze wird natürlich eine Testphase haben.
Aber wie oben schon erwähnt oder auch erahnt, weiß ich natürlich noch gar nicht genau, inwieweit wir bestimmte Arbeitsprozesse oder Anforderungen im Ticketsystem abbilden können.

Na so ein System lebt ja von und mit den Daten, die im laufe der Zeit eingepflegt werden. Von daher stelle ich mir gerade die Frage, wie Daten aus dem Bereich "Flurfunk" eingepflegt werden sollen.

Normalerweise gibt es ja auch so etwas wie Anforderungsmanagement- und Changemanagement.

In der Software  OCS-NG / GLPI kann man eine Erfassung von Geräten mit kaufmännischen Daten und Software durchführen. (Inventarisierung mit Ticketsystem)

Wenn z.B. zu einem späterem Zeitpunkt Probleme mit einem Gerät auftreten, hat man alle Daten zur Hand z.B. ob das Gerät noch in der Garantie ist oder ob es weitere Geräte ähnlicher Bauart gibt, die ähnliche Probleme zu erwarten lassen. Ob es kaufmännisch abgeschrieben ist oder ob es einen Wartungsvertrag gibt oder nicht usw.

Dass wäre dann eine sinnvolle Kombination aus Anforderungsmanagement und Ticketsystem. Allerdings erstellen die Tickets die User auch selbst und die IT nutzt die so aufgebaute Datenbank dann zur Problemlösung- und Recherche.

Im Standard dieser Software sind auch schon einige Statistiken- und Reports mit dabei. Diese kann man dann bei Bedarf weiter verfeinern und ausbauen.

Allerdings muss man sich zunächst die Arbeit machen über eine Ist-Aufnahme den Datenbestand einzupflegen.

Danach erst erfüllt das Ticketsystem wirklich einen Sinn.

Beispielsweise kann mann per Report feststellen, ob alle Clients die gleiche Version z.B. vom Acrobat Reader installiert haben oder die Anzahl von "Monitoren" prüfen, die nicht mehr ergonomischen Richtlinien entsprechen. Wenn man die kaufmännische Information dann hinzu zieht, kann man damit eine Planung für zukünftige Investitionen verwalten.

Oder auch eine Inventaraufnahme der installierten Software und daraus resultierend einen Plan für ein geeigneteres Lizenzmodell entwickeln usw.

Wenn jetzt Probleme mit bestimmten Gerätemodellen auftreten und diese im Ticketsystem eingepflegt sind, erleichtert dies die Fehlerbehebung im vergleich zur händischen Suche. Weil eine Inventarisierung mittels Agent sehr detaillierte Informationen liefert und man nach diesen Informationen filtern kann.

In diesem Fall erübrigt es sich auch neue Kennzahlen zu erstellen, denn ein Fehlerreport kann aus bestehenden Daten erstellt werden, die auch vom Kaufmann nachvollzogen werden können. (z.B. Arbeitszeitausfall wegen technischer Störungen verursacht von Mängeln in bestimmten Hardware- / Treiberkombinationen).

 

Bearbeitet 22. September 2020 von tkreutz2