Third Level Support: Aufgaben, Eskalation und Organisation bei Individualsoftware
Was macht der Third Level Support?
Der Third Level Support übernimmt Vorgänge, die sich weder mit dokumentierten Lösungswegen noch mit Konfigurationsänderungen beheben lassen.
Third Level Support bezeichnet die höchste Eskalationsstufe im IT-Support. Sie ist bei den Personen angesiedelt, die eine Anwendung entwickelt haben oder deren Quellcode pflegen. Bearbeitet werden Fehler, die eine Änderung am Programm selbst erfordern, sowie Störungen, deren Ursache mit den Mitteln der vorgelagerten Stufen nicht zu ermitteln ist.
Damit unterscheidet sich diese Stufe grundlegend von den beiden anderen. Sie behebt nicht Symptome, sondern Ursachen, und ihr Ergebnis ist in der Regel eine Codeänderung, kein Konfigurationseingriff. Der weit überwiegende Teil aller Anfragen wird bereits auf der ersten Stufe abschließend bearbeitet. Was am Ende die dritte Stufe erreicht, ist ein kleiner, aber teurer Rest, weil hier die knappste und höchstbezahlte Kapazität gebunden wird. Den Rahmen dazu beschreibt der Leitfaden zum IT Service Management.
Aufgaben jenseits der reinen Störungsbehebung
Der Zuschnitt reicht über die einzelne Störung hinaus, weil auf dieser Stufe das Wissen über die Architektur liegt.
- Ursachenanalyse bis auf Code- und Datenbankebene
- Entwicklung und Test von Korrekturen
- Bewertung, ob ein Fehler oder eine fehlende Funktion vorliegt
- Einschätzung von Auswirkungen geplanter Änderungen
- Rückfluss von Erkenntnissen in die Wissensbasis der unteren Stufen
- Beratung bei Fragen zur Weiterentwicklung
- Bewertung von Sicherheitsmeldungen zu eingesetzten Bibliotheken
Abgrenzung zum Herstellersupport
Bei Standardsoftware liegt die dritte Stufe beim Hersteller und ist über dessen Wartungsvertrag abgedeckt. Der eigene Betrieb hat dort keinen Zugriff auf den Quellcode und ist auf Reaktionszeiten angewiesen, die er nicht beeinflusst. Bei eigens entwickelter Software fällt diese Grenze weg, was Handlungsspielraum schafft und zugleich Verantwortung verlagert.
Wann wird an die dritte Stufe eskaliert?
Eskalation folgt festgelegten Kriterien, nicht dem Empfinden der bearbeitenden Person. Ohne solche Kriterien schwankt der Zeitpunkt erheblich.
Kriterien für die Eskalation
Vier Auslöser haben sich in der Praxis bewährt und lassen sich in jedem Ticketsystem abbilden.
- Die Ursache liegt nachweislich im Programmverhalten, nicht in Konfiguration oder Bedienung
- Ein Datenbestand ist betroffen und eine Korrektur greift in Daten ein
- Eine definierte Analysezeit auf der zweiten Stufe ist ausgeschöpft
- Die Störung betrifft eine Fehlerklasse mit vertraglich zugesagter Reaktionszeit
Die vierte Bedingung wird häufig übersehen. Wo ein Service Level Agreement enge Fristen für schwerwiegende Fehler vorsieht, muss die Eskalation früher erfolgen, als es die reine Analyselogik nahelegen würde.
Was die Übergabe enthalten muss
Eine Übergabe ohne Kontext erzeugt Rückfragen und verdoppelt die Bearbeitungszeit. Der Mindestumfang lässt sich verbindlich festlegen.
Dazu gehören eine reproduzierbare Beschreibung, der Zeitpunkt des ersten Auftretens, betroffene Nutzergruppen, bereits ausgeschlossene Ursachen und die Frage, ob eine Änderung am System vorausging. Der letzte Punkt verkürzt die Suche am stärksten, weil die meisten neu auftretenden Fehler auf eine vorangegangene Änderung zurückgehen.
Warum verfrühte Eskalation teuer ist
Wird zu früh weitergegeben, bindet der Vorgang Entwicklungskapazität für eine Analyse, die auf der zweiten Stufe hätte stattfinden können. Das verzögert zugleich die Arbeit an Fehlern, die tatsächlich Codeänderungen brauchen. Der Preis einer verfrühten Eskalation ist nicht der Aufwand des einzelnen Vorgangs, sondern die Verdrängung anderer Arbeit. Solche Verschiebungen sichtbar zu machen, ist Aufgabe des IT-Kostenmanagements.
Zusammenspiel mit dem Second Level Support
Die Schnittstelle zum Second Level Support entscheidet über die Wirtschaftlichkeit des gesamten Modells. Beide Stufen brauchen eine gemeinsame Sicht auf den Vorgang.
Der Second Level Support trägt die Diagnose so weit, wie sie ohne Codekenntnis möglich ist. Er prüft Protokolle, grenzt ein und schließt Ursachen aus. Was er nicht leisten kann, ist die Bewertung, ob ein beobachtetes Verhalten so beabsichtigt war. Genau diese Frage gehört auf die dritte Stufe und lässt sich nicht delegieren.
Wie Individualsoftware die Arbeitsteilung verändert
Bei Individualsoftware verschwimmt die Grenze, weil dieselben Personen entwickeln und Störungen beheben. Das beschleunigt die Bearbeitung und birgt zugleich ein Risiko.
Ohne klare Trennung wandern Vorgänge direkt an das Entwicklungsteam, die unteren Stufen bauen kein Wissen auf, und die Abhängigkeit von einzelnen Personen wächst. Eine formale Eskalationsregel bleibt deshalb auch dann nötig, wenn organisatorisch alles in einer Hand liegt. Ergänzend liefert der Eintrag zum First Level Support die Sicht auf die Einstiegsstufe.
Der stille Konflikt mit der Weiterentwicklung
Dieselben Personen bearbeiten Störungen und bauen neue Funktionen. Beide Aufgaben konkurrieren um dieselbe Zeit, und Störungen gewinnen fast immer, weil sie sichtbar drängen. Ohne feste Kapazitätsreservierung verschiebt sich die Roadmap unbemerkt Woche für Woche. Eine getrennte Planung von Wartungs- und Entwicklungskapazität ist deshalb keine Formalie, sondern die Voraussetzung dafür, dass beides verlässlich stattfindet.
Kennzahlen für die dritte Stufe
Die Kennzahlen der unteren Stufen greifen hier nicht. Eine Erstlösungsquote ergibt keinen Sinn, wo definitionsgemäß nur schwierige Fälle ankommen. Aussagekräftig sind stattdessen Werte, die etwas über Ursachen und Systemzustand aussagen.
- Anteil der Vorgänge, die auf eine vorangegangene Änderung zurückgehen
- Zeit von der Übergabe bis zur bestätigten Ursache
- Anteil der Fälle, die ohne Codeänderung gelöst werden konnten
- Wiederholungsrate desselben Fehlerbildes nach einer Korrektur
- Anteil der Vorgänge, deren Erkenntnis in die Wissensbasis zurückfloss
Die Wiederholungsrate ist der ehrlichste Wert. Steigt sie, wurden Symptome behandelt statt Ursachen. Der Anteil der Fälle ohne Codeänderung wiederum zeigt, ob zu früh eskaliert wird, und gehört deshalb regelmäßig gemeinsam mit dem Second Level Support ausgewertet.
Third Level Support für Individualsoftware aufstellen
Der Aufbau folgt anderen Regeln als bei Standardprodukten, weil weder Herstellerfristen noch fremde Wissensdatenbanken zur Verfügung stehen.
Wer übernimmt den Third Level Support bei Individualsoftware?
In der Regel das Team, das die Anwendung entwickelt hat, oder ein Dienstleister, der den Quellcode übernommen hat. Eine dritte Möglichkeit besteht nicht, weil ohne Codezugriff keine Ursachenbehebung möglich ist.
Wechselt der Dienstleister, entscheidet die Qualität der Übergabe über die Reaktionsfähigkeit der folgenden Monate. Ein strukturierter Blick auf den Bestand vor der Übernahme gehört deshalb zum Standardvorgehen. Ohne Kenntnis der Codebasis ist jede Zusage zu Reaktionszeiten unseriös.
Individualsoftware ohne Herstellersupport absichern
Drei Festlegungen tragen den Betrieb, wenn niemand sonst einspringen kann.
- Benannte Vertretung, damit die Stufe nicht an einer Person hängt
- Dokumentierte Architektur- und Betriebsentscheidungen
- Vereinbarte Fehlerklassen mit unterschiedlichen Reaktionszeiten
Die Vertretungsregelung ist der am häufigsten vernachlässigte Punkt. Solange eine einzige Person die Anwendung wirklich kennt, existiert die dritte Stufe nur auf dem Papier.
Absichern lässt sich das mit einfachen Mitteln. Ein regelmäßiger Wechsel bei der Bearbeitung eskalierter Vorgänge verteilt Wissen, ohne zusätzliche Termine zu erzeugen. Wer Vertretung nur im Urlaubsplan regelt und nicht im Tagesgeschäft, stellt im Ernstfall fest, dass die benannte Person die Anwendung nie berührt hat. Ergänzend hilft eine knappe, gepflegte Übersicht der Architekturentscheidungen mehr als eine umfangreiche Dokumentation, die niemand aktuell hält.
TenMedia betreut Individualsoftware über den gesamten Lebenszyklus und übernimmt dabei auch Anwendungen, die andere entwickelt haben. Wie sich Betrieb, Wartung und Eskalationsstufen zu einem belastbaren Modell verbinden lassen, zeigt die Seite zu Softwarebetrieb und Wartung.
