SLA-Bewertung bei Ticket-Reklassifizierung – Bitte um Einschätzung

[Jörg Schulte Osthorst]

Hallo Zusammen,

wir möchten euch um eure Meinung und Stellungnahme zu folgendem Sachverhalt bitten, den wir in KIX18 beobachtet haben. Die Darstellung wurde mit KI-Unterstützung erstellt.


1. Sachverhalt: Der Ticketverlauf

Folgender Ticketverlauf wurde im System KIX18 beobachtet und soll hinsichtlich seiner SLA-Bewertung diskutiert werden:
1.      Ein Ticket wird vom Kunden als Incident erstellt. Auf dem Incident ist eine SLA für die First Response hinterlegt.
2.      Das Ticket wird für den Kunden sichtbar und zeitnah bearbeitet. Die First Response SLA wird eingehalten.
3.      Im Rahmen von ein bis drei weiteren öffentlichen Bearbeitungsschritten stellt sich heraus, dass es sich um einen Service Request handelt. Ticket-Typ und Service werden entsprechend umgestellt. Mit dem neuen Service ist keine SLA verknüpft.
4.      Es folgen mehrere weitere Bearbeitungsschritte.
5.      Im weiteren Verlauf stellt sich heraus, dass es sich doch um eine Störung (Incident) handelt. Ticket-Typ und Service werden erneut umgestellt. Mit dem nun wieder aktiven Incident-Service ist eine SLA verknüpft.
Befund des Systems KIX18: Das System bewertet diesen Ticketverlauf als SLA-Verletzung.


2. Bewertung aus Kundenperspektive


Aus Sicht des Kunden ist der beschriebene Ticketverlauf nicht als SLA-Verletzung zu werten. Die Begründung:
·         Der Kunde hat ein Problem gemeldet und eine zeitgerechte Reaktion erhalten – die First Response SLA wurde eingehalten.
·         Die Bearbeitung war für den Kunden sichtbar und kontinuierlich im Gange.
·         Die interne Reklassifizierung des Ticket-Typs (Incident → Service Request → Incident) ist ein interner Vorgang des Dienstleisters und für das Kundenerlebnis nicht relevant.
·         Der Kunde erlebt: ,,Mein Anliegen wurde aufgenommen, man hat reagiert und die Bearbeitung läuft." – Dies entspricht einer vertragskonformen Leistungserbringung.
Eine SLA-Verletzung aus Kundenperspektive wäre dann gegeben, wenn die First Response nicht innerhalb der vereinbarten Zeit erfolgt wäre – was hier ausdrücklich nicht der Fall ist.


3. Bewertung aus ITIL-/ITSM-Sicht

Auch aus der Perspektive etablierter ITSM-Frameworks (insbesondere ITIL) lässt sich das beschriebene Verhalten nicht als SLA-Verletzung klassifizieren:
·         SLA-Messung bezieht sich auf konkrete Zielzeiten (z. B. First Response, Resolution Time), nicht auf den internen Bearbeitungsprozess. Maßgeblich ist, ob die vertraglich vereinbarten Zeitziele eingehalten wurden – und das war hier der Fall.
·         Reklassifizierungen sind ein regulärer ITSM-Prozess. ITIL sieht explizit vor, dass Tickets im Verlauf der Bearbeitung neu bewertet und umklassifiziert werden können, wenn sich der tatsächliche Sachverhalt klarer darstellt. Dies ist ein Zeichen von Sorgfalt und Prozessqualität, kein Fehler.
·         Die Kontinuität der Bearbeitung war gegeben. Es gab keine Unterbrechung, kein Liegenlassen des Tickets – der Dienstleister hat aktiv und nachvollziehbar gehandelt.
·         Ein SLA-Verstoß im ITIL-Sinne setzt voraus, dass eine vertraglich definierte Zeitvorgabe überschritten wurde. Dies ist anhand des geschilderten Verlaufs nicht erkennbar.


4. Kernfragen an den Hersteller KIX

Schritt 1: Konsens prüfen
Zunächst bitten wir um eine Bewertung unserer Einschätzung aus Kundenperspektive und aus ITIL-/ITSM-Sicht:
·         Teilt der Hersteller unsere Auffassung, dass der beschriebene Ticketverlauf keine SLA-Verletzung darstellt?

Schritt 2a: Falls KIX als Hersteller unsere Einschätzung nicht teilt
·         Auf welcher Grundlage bewertet ihr diesen Verlauf als SLA-Verletzung?
·         Welchem ITSM- oder Produktprinzip folgt das System dabei - und wie lässt sich dieses Prinzip mit einer kundenorientierten SLA-Philosophie vereinbaren?

Schritt 2b: Falls KIX als Hersteller unsere Einschätzung teilt
·         Wie kann diese Einschätzung im KIX18 abgebildet werden?
·         Handelt es sich um eine Konfigurationsanpassung, die im Rahmen des bestehenden Systems umsetzbar ist?
·         Oder ist das beschriebene Systemverhalten als Fehlverhalten einzustufen, das einer Korrektur durch den Hersteller bedarf?

Wir teilen die Einschätzung des Systems - dass in diesem Fall eine SLA-Verletzung vorliegt - ausdrücklich nicht und sehen hier Klärungsbedarf auf konzeptioneller als auch auf technischer Ebene.

Viele Grüße
Jörg

[Torsten Thau]

(auch diese Antwort wurde mit Hilfe von KI erstellt)

Hallo zusammen,

vielen Dank für die Schilderung dieses spannenden Use-Cases! Die KI-Zusammenfassung liefert bereits einen guten Überblick, auch wenn für eine tiefgehende Analyse noch ein paar Details zur konkreten Systemkonfiguration und zum exakten Trigger der SLA-Verletzung fehlen.Wir gehen davon aus, dass das System in eurer aktuellen Konfiguration bei einem solchen ,,Zickzackkurs" die wechselnden SLA-Kriterien noch nicht dynamisch abfängt. Um dieses Szenario in KIX sauber und zukunftssicher abzubilden, empfehlen wir drei pragmatische Lösungswege:

Möglichkeit 1: Saubere Trennung (Best Practice) Die Reklassifizierung im selben Ticket wird unterbunden. Stattdessen wird der ursprüngliche Vorgang abgeschlossen und ein korrekt klassifizierter Folgevorgang erstellt. Das ist die unkomplizierteste Lösung, da sie die ITIL-Practices methodisch sauber voneinander trennt und die Systematik der Standard-Workflows nutzt.

Möglichkeit 2: Dynamische SLA-Berechnung über definierte Startzeitpunkte Die Reklassifizierung im Ticket wird zugelassen, jedoch wird der Startzeitpunkt der neuen SLA-Frist (manuell oder automatisch) neu gesetzt. KIX bietet architektonisch die Flexibilität, den Startzeitpunkt für SLAs abweichend zu definieren. Es kann jedes beliebige Date-Time-Feld am Ticket als neuer Ausgangspunkt für die SLA-Berechnung genutzt werden. Zur Konfiguration: KIX Pro Dokumentation – Service Level Agreements (https://docs.kixdesk.com/pro/de/administration/services-und-sla/service-level-agreements--sla-.html#UUID-f2fe3ea8-9405-5f20-62a1-343c4bfe934f_UUID-5959d740-c345-8ace-4fbd-94d8fa704088). Diese korrekt, gewünscht zu initialisieren ist Administrationsaufgabe.

Möglichkeit 3: Event-gesteuerte SLA-Erfüllung (Automatisierung) Als dritten, sehr eleganten Weg könnt ihr das SLA-Kriterium exakt zum Zeitpunkt der Reklassifizierung systemisch als "erfüllt" deklarieren. Dadurch wird die bisher erbrachte Leistung eingefroren und gewertet, bevor der Ticket-Typ wechselt. Dies lässt sich hervorragend über die Automatisierungs-MacroAction "Erfüllungszeit Setzen" konfigurieren. Eine gute Orientierung, wie so ein Job aufgebaut wird, bietet der im System bereits enthaltene Vorgabejob ,,SLA Solution Time Fulfillment". Details zur MacroAction: KIX Pro Dokumentation – Übersicht der Macro-Actions (https://docs.kixdesk.com/pro/de/administration/anhang/macro-actions/uebersicht-der-macro-actions.html). Auch dieser Weg steht dem Admin zur Konfiguration zur Verfügung. 

Wie diese drei Ansätze verdeutlichen, ist KIX architektonisch bewusst so flexibel gestaltet, dass es Unternehmen nicht in starre Software-Vorgaben zwingt. Selbst wenn diese bei der Klassifizierung aus einer strengen ITIL-Perspektive als nicht ganz optimale Abläufe gelten mögen, offeriert das System vollumfängliche Möglichkeiten, diese Praxisrealitäten abzubilden. Administratoren erhalten alle nötigen Werkzeuge, um auch komplexe oder abweichende Workflows präzise und kundenorientiert im System zu verankern, ohne die Integrität der SLA-Messung zu gefährden.