Prioritäten und Ticketstatus

Konkret haben wir 4 Ticket-Prioritäten. Diese sind an den SLA (Service-Level-Agreement) mit dem DVV orientiert, da wir uns für verschiedene Prioritäten an entsprechende Antwort- und Lösungszeiten halten müssen. Diese sind im DVV Rahmenvertrag nachzulesen. Ich habe euch den Teil hier aber auch nochmal eingefügt:

Störungen der Priorität 1 (kritisch)

• Definition: Totalausfall, gravierende Auswirkung auf Endanwender; als gravierende Auswirkung gilt insbesondere eine Störung, bei der die Verfügbarkeit ununterbrochen mindestens 30 Minuten oder wiederholt 15 Minuten nicht gegeben ist. 

• Die Reaktionszeit (beginnend mit dem Eingang bei VIT) für Störungen dieser Priorität darf 2 Stunden nicht überschreiten. Die Entstörzeit darf 2 Std. nach der Reaktion nicht überschreiten und wird im Einzelfall mit dem Nutzer besprochen. 

• Störungsbehebung auch außerhalb der Supportzeiten 

Störungen der Priorität 2 (dringend)

• Definition: hohe Auswirkung auf Endanwender, Fehler in endanwenderrelevanten Anwendungen, die die Arbeit mit der gesamten Anwendung aber nicht wesentlich einschränken. 

• Die Reaktionszeit (beginnend mit dem Eingang bei VIT) für Störungen dieser Priorität darf 4 Stunden nicht überschreiten. Die Entstörzeit darf 24 Std. nach der Reaktion nicht überschreiten und wird im Einzelfall mit dem Nutzer besprochen. 

• Störungsbehebung nur innerhalb der Supportzeiten 

Störungen der Stufe Priorität 3 (normal)

• Definition: geringe Auswirkung auf Endanwender, generelle Probleme, die nicht zeitkritisch sind, Störungen hinsichtlich einzelner Geschäftsvorfälle 

• Die Reaktionszeit (beginnend mit dem Eingang bei VIT) für Störungen dieser Priorität darf 24 Stunden nicht überschreiten. Die Entstörung erfolgt mit dem nächsten Seite 28 Minor-Release. 

• Störungsbehebung nur innerhalb der Supportzeiten 

Störungen der Priorität 4

• Definition: keine nennenswerte Auswirkung auf Endanwender 

• Die Reaktionszeit (beginnend mit dem Eingang bei VIT) für Störungen dieser Priorität darf 2 Tage nicht überschreiten. Die Entstörung erfolgt mit dem nächsten Minor-Release. 

• Störungsbehebung nur innerhalb der Supportzeiten

Das bedeutet also, dass bspw. ein Ausnahmefehler beim Erstellen einer Rechnung kein Prio 1 Ticket sein darf. Natürlich ist es uns klar, dass es unschön ist und schnell behoben werden muss, aber gerade so ein Prio 1 Ticket kann am Wochenende Prozesse auslösen, die dafür sorgen, dass meine Kollegen und ich in Bereitschaft gerufen werden und somit Kosten und Aufwände entstehen.

Des Weiteren möchte ich kurz die Ticketstatus erläutern, die wir in Freshdesk haben:

Offen: Das Ticket ist noch nicht bearbeitet.

Weitere Abstimmung erforderlich: Wir haben Rückfragen zu dem Ticket und müssen noch eine Klärungsschleife drehen.

In Bewertung: Wir müssen ggfs. nochmal eine interne Rücksprache halten.

Ausstehend: Das Entwicklerticket ist angelegt und man muss darauf warten, dass es umgesetzt wird.

Im Testsystem: Der Entwickler hat das Ticket soweit umgesetzt und hat den Stand ins Testsystem released. Das bedeutet, dass wir die Umsetzung des Tickets nochmal testen (außer bei Entwicklungen – dort testet die PowerUser-Gruppe)

Gelöst: Der Fehler ist behoben oder die Frage ist beantwortet.

Geschlossen: Die Frage oder das Ticket hat sich erledigt. Es kann auch sein, dass das Ticket geschlossen wird, weil es ein ähnliches Ticket bereits besteht. Dann werden die Tickets in der Regel zusammengeführt.

Zuletzt noch die Info zu den Notizen an den Tickets:

Wenn Helpdesk-Tickets mit Entwicklertickets verbunden sind, dann werden automatische Notizen generiert, sobald ein Entwicklungsticket zur Entwicklung ausgewählt wurde, das Ticket in Bearbeitung ist, das Ticket auf PR wartet, das Ticket auf Test-Release wartet, es im Testsystem ist und das Ticket auf Done (fertig) geschoben wurde. Da diese Notizen unserer Wahrnehmung nach teilweise missinterpretiert wurde, möchte ich euch hier nur noch einmal dafür sensibilisieren, dass die Notizen hauptsächlich für Transparenz sorgen sollen. Daher möchte ich euch einmal kurz unseren Entwicklungs-/Bugfixing-Prozess erläutern:

Wenn wir ein Entwicklerticket angelegt haben, dann ist es im Eingangskorb. Wenn es sich um ein entsprechend priorisiertes Ticket handelt, schieben wir es weiter zu „zur Entwicklung ausgewählt“. Von dort nimmt es sich ein Entwickler entsprechend und korrigiert den Fehler oder schreibt das neue Feature. Daraufhin stellt der Entwickler einen PR (Pull-Request), sodass sich ein Kollege den angepassten Code nochmal anschaut. Hier geht es hauptsächlich darum zu überprüfen ob die Art und Weise der Codeanpassungen passt. Wenn das passt, wird das Ticket auf „Wartet auf Test-Release“ geschoben. Mit dem nächsten Update unserer Testsysteme ist das Ticket dann im Testsystem. Wenn das Ticket im Testsystem ist, dann schauen wir fachlich nochmal drüber und geben dem Entwickler entsprechend Rückmeldung ob die Anpassung funktioniert oder nicht. Gehen wir von einem positiven Test aus, wird das Ticker auf „Done“ geschoben. Dort bleibt es dann, bis zum nächsten Live-Release. Feature-Entwicklungen würden dann im Major-Release kommen und Bugfixes werden in der Regel im Minor-Release live gebracht.