Support-Level und Störungsklassen abgrenzen

Montagmorgen, mehrere Mitarbeitende können nicht auf ein zentrales System zugreifen, der Anbieter stuft das Ticket aber als normale Anfrage ein. Dein Fachbereich spricht von einem Produktionsstillstand, der Service Desk von einem Einzelfall. Genau an dieser Stelle zeigt sich, ob ein Supportvertrag belastbar ist. Nicht die Zahl der vereinbarten Supportstunden entscheidet, sondern die klare Verbindung von Support-Level, Störungsklasse, Priorität und verbindlichen Zeiten.

Support-Level und Störungsklassen sind nicht dasselbe

In vielen Verträgen werden diese Begriffe vermischt. Das führt dazu, dass im Ernstfall unterschiedliche Erwartungen aufeinandertreffen.

Der Support-Level beschreibt, wer eine Anfrage oder Störung bearbeitet und welche fachliche Tiefe die Bearbeitung hat. Typischerweise werden drei Ebenen unterschieden:

Support-Level	Typische Aufgabe	Typische Kompetenz
First Level	Annahme, Erfassung, Erstprüfung, Standardlösungen	Service Desk, Anwenderbetreuung
Second Level	Fachliche Analyse, Konfiguration, Fehleranalyse im Betrieb	Systemadministration, Produktspezialisten
Third Level	Fehlerbehebung im Produkt, Quellcodeanalyse, Herstelleranalyse	Entwicklung, Hersteller, Spezialisten

Die Störungsklasse beschreibt dagegen, wie schwerwiegend ein konkreter Fehler für dein Unternehmen ist. Sie bildet die Grundlage für die Priorität und damit für die geschuldeten Reaktions- und Wiederherstellungszeiten.

Ein Vertrag sollte daher nicht einfach festhalten: „Der Auftragnehmer leistet First, Second und Third Level Support.“ Das sagt noch nichts darüber aus, wie schnell bei einem kritischen Ausfall reagiert werden muss. Ebenso wenig reicht die Aussage: „Kritische Störungen werden priorisiert bearbeitet.“ Ohne festgelegte Zeiten bleibt offen, was „priorisiert“ praktisch bedeutet.

Die Aufgaben der drei Support-Level sauber abgrenzen

Die Level-Struktur funktioniert nur, wenn die Zuständigkeiten nicht abstrakt bleiben. Entscheidend ist, welche Tätigkeiten der jeweilige Level tatsächlich übernimmt und wann eine Übergabe erfolgen muss.

First Level: Annahme und strukturierte Erstprüfung

Der First Level ist die erste Anlaufstelle. Er nimmt Störungen entgegen, dokumentiert sie, prüft bekannte Fehlerbilder und versucht, standardisierte Lösungen anzuwenden. Dazu gehören etwa:

• Prüfung, ob die Störung bereits bekannt ist
• Kontrolle von Zugangsberechtigungen und Basisdaten
• Rückfragen zur Reproduzierbarkeit
• Anwendung dokumentierter Workarounds
• Information der betroffenen Nutzerinnen und Nutzer
• Weiterleitung an den Second Level nach definierten Kriterien

Wichtig ist: Der First Level darf nicht zum Wartezimmer werden. Wenn ein Ticket nur entgegengenommen, aber über Stunden nicht fachlich geprüft wird, hilft eine kurze Reaktionszeit wenig. Vereinbare deshalb, wann ein Ticket an den Second Level übergeben werden muss. Das kann etwa bei nicht erfolgreicher Erstprüfung, bei bestimmten Störungsklassen oder bei Überschreitung einer Bearbeitungszeit gelten.

Second Level: Analyse im Betrieb

Der Second Level übernimmt Fälle, die eine vertiefte technische oder fachliche Analyse erfordern. Typische Aufgaben sind:

• Analyse von Logdateien und Schnittstellen
• Prüfung von Systemparametern und Konfigurationen
• Fehleranalyse in Datenbeständen
• Wiederherstellung von Diensten
• Koordination mit Infrastruktur- oder Cloud-Anbietern
• Erarbeitung und Umsetzung eines Workarounds

Im Vertrag sollte erkennbar sein, ob der Second Level Änderungen selbst vornehmen darf. Besonders bei produktiven Systemen sind Freigaben, Dokumentation und Rückfallmöglichkeiten wichtig. Eine schnelle Fehlerbehebung darf nicht zu unkontrollierten Eingriffen führen, die später neue Probleme auslösen.

Third Level: Produktverantwortung und tiefgreifende Fehlerbehebung

Der Third Level kommt ins Spiel, wenn der Fehler im Produkt selbst vermutet wird oder der Second Level keine Lösung erreichen kann. Bei Standardsoftware ist das oft der Hersteller. Bei Individualsoftware kann es das Entwicklungsteam des Dienstleisters sein.

Hier liegt ein häufiger Vertragsfehler: Der Dienstleister verkauft einen umfassenden Support, schließt aber die Verantwortung für Herstellerzeiten faktisch aus. Wenn dein Anbieter für den Third Level auf Dritte angewiesen ist, sollte er trotzdem verantwortlich bleiben, die Bearbeitung zu steuern, nachzuhalten und über den Status zu informieren. Andernfalls musst du im kritischen Fall selbst mehreren Beteiligten hinterhertelefonieren.

Störungsklassen nach Auswirkung und Dringlichkeit definieren

Eine brauchbare Klassifizierung betrachtet mindestens zwei Fragen:

1. Wie stark ist das Unternehmen oder ein wesentlicher Geschäftsprozess beeinträchtigt?
2. Wie dringend muss gehandelt werden, um Schäden zu vermeiden?

Die Zahl der betroffenen Personen allein reicht nicht. Ein Fehler, der nur eine Person betrifft, kann kritisch sein, wenn diese Person einen fristgebundenen Zahlungsverkehr freigeben muss. Umgekehrt kann ein eingeschränktes Komfortmerkmal viele Personen betreffen, ohne den Geschäftsbetrieb wesentlich zu gefährden.

Eine praxistaugliche Einteilung kann so aussehen:

Klasse	Beschreibung	Typisches Beispiel
Kritisch	Zentraler Dienst oder wesentlicher Geschäftsprozess ist vollständig ausgefallen, ein akzeptabler Workaround fehlt	Produktionssteuerung, ERP-Zugriff oder zentrale Anmeldung ist nicht verfügbar
Hoch	Wesentliche Funktion ist erheblich beeinträchtigt, ein Workaround ist nur eingeschränkt oder mit hohem Aufwand möglich	Bestellungen können nur manuell und deutlich verzögert verarbeitet werden
Mittel	Einzelne Funktionen oder Nutzergruppen sind betroffen, der Betrieb kann mit vertretbarem Aufwand fortgeführt werden	Eine Auswertung oder Schnittstelle liefert fehlerhafte Ergebnisse
Gering	Kleine Beeinträchtigung ohne wesentliche Auswirkung auf den Geschäftsbetrieb	Darstellungsfehler, unkritische Fehlermeldung, Funktionswunsch

Diese Beschreibungen müssen zu deinem konkreten System passen. Bei einem Krankenhaus, einem Produktionsbetrieb oder einer Bank ist die Bewertung eines Ausfalls anders als bei einer internen Wissensplattform. Übernimm daher keine Standardmatrix ungeprüft.

Priorität und Zeiten je Klasse verbindlich koppeln

Die Störungsklasse muss eine konkrete Folge haben. Üblich sind mindestens folgende Zeitwerte:

• Reaktionszeit: Zeitraum zwischen ordnungsgemäßem Eingang der Meldung und qualifizierter Bearbeitungsaufnahme.
• Analysezeit: Zeitraum bis zu einer ersten fachlichen Einschätzung, Ursache oder belastbaren nächsten Maßnahme.
• Wiederherstellungszeit: Zeitraum bis zur Wiederherstellung des vereinbarten Betriebs oder bis zu einem akzeptierten Workaround.
• Lösungszeit: Zeitraum bis zur dauerhaften Beseitigung der Ursache, soweit diese geschuldet und technisch möglich ist.
• Informationsintervalle: Rhythmus, in dem der Dienstleister bei kritischen und hohen Störungen Statusmeldungen liefert.

Vermeide die Formulierung „Der Auftragnehmer bearbeitet Störungen unverzüglich“. Sie wirkt eindeutig, ist aber streitanfällig. Besser ist eine Tabelle, die für jede Klasse Supportzeit, Reaktionszeit, Wiederherstellungsziel und Eskalation festlegt.

Dabei ist wichtig, zwischen Wiederherstellung und endgültiger Fehlerbeseitigung zu unterscheiden. Ein Workaround kann den Geschäftsbetrieb sichern, ersetzt aber nicht zwingend die dauerhafte Lösung. Vertraglich solltest du festlegen, wann ein Workaround als ausreichend gilt und welche Restarbeiten danach geschuldet sind.

Bei uns vermitteln wir, wie solche Service-Level-Vereinbarungen mit dem übrigen IT-Vertrag zusammenspielen und wie du Klauseln in Verhandlungen belastbar prüfst. Passende Seminare und Termine findest du bei uns auf cmt.de.

Messbeginn, Messende und Servicezeiten festlegen

Selbst gut gewählte Zeiten helfen nicht, wenn ihr unterschiedliche Messpunkte annehmt. Der Vertrag sollte deshalb ausdrücklich beantworten:

• Wann gilt eine Störung als wirksam gemeldet?
• Über welche Kanäle darf oder muss sie gemeldet werden?
• Welche Mindestinformationen muss ein Ticket enthalten?
• Wann beginnt die Reaktionszeit?
• Wann endet die Wiederherstellungszeit?
• Welche Zeiten gelten außerhalb der vereinbarten Servicezeit?
• Wann darf die Uhr angehalten werden?

Die Reaktionszeit sollte mit dem Eingang einer ordnungsgemäßen Meldung im vereinbarten Ticketsystem beginnen. Bei kritischen Störungen kann zusätzlich eine telefonische Meldung sinnvoll sein. Dann muss aber klar sein, ob der Anruf allein genügt oder ob zusätzlich ein Ticket erforderlich ist.

Eine Unterbrechung der Messzeit ist nur sinnvoll, wenn sie nachvollziehbar dokumentiert wird. Typische Fälle sind fehlende Mitwirkung des Kunden, fehlender Systemzugang oder eine ausstehende Freigabe. Der Dienstleister sollte den Unterbrechungsgrund anzeigen und belegen. Eine pauschale Klausel, wonach Zeiten bei „Mitwirkungsproblemen“ nicht laufen, ist zu unbestimmt.

Eskalation verhindert, dass Tickets liegen bleiben

Eine Eskalationsregel ergänzt die normalen Bearbeitungswege. Sie legt fest, wer informiert wird und wer Entscheidungen treffen darf, wenn eine Störung nicht innerhalb der vorgesehenen Zeit behoben ist.

Für kritische Störungen sollte die Eskalation nicht erst nach Ablauf der Wiederherstellungszeit beginnen. Sinnvoll ist eine mehrstufige Regelung:

1. Der Service Desk informiert unverzüglich den verantwortlichen Second Level.
2. Der Dienstleister benennt eine koordinierende Person mit Entscheidungsbefugnis.
3. Bei absehbarer Zielverfehlung wird das Management auf beiden Seiten eingebunden.
4. Der Dienstleister informiert in festen Intervallen über Status, Maßnahmen, Risiken und nächste Schritte.
5. Nach Abschluss erfolgt eine Ursachenanalyse, wenn die Störung eine festgelegte Schwere erreicht.

Achte darauf, dass Eskalation nicht nur „Information“ bedeutet. Sie muss zu zusätzlichen Ressourcen, Priorisierung oder Entscheidungen führen können.

Checkliste für deine Vertragsprüfung

Prüfe vor Vertragsabschluss insbesondere diese Punkte:

• Sind First, Second und Third Level nach Aufgaben und Verantwortlichkeiten beschrieben?
• Ist klar, wer bei Hersteller- oder Unterauftragnehmerleistungen die Koordination übernimmt?
• Sind Störungsklassen anhand konkreter Auswirkungen auf dein Unternehmen definiert?
• Sind Reaktionszeit, Wiederherstellungszeit und dauerhafte Lösung voneinander getrennt?
• Gibt es je Störungsklasse eindeutige Zeitwerte und Servicezeiten?
• Ist geregelt, wann die Zeitmessung beginnt, endet oder ausnahmsweise pausiert?
• Sind Workarounds nur dann ausreichend, wenn sie den vereinbarten Betrieb tatsächlich ermöglichen?
• Gibt es verbindliche Statusmeldungen und Eskalationsstufen?
• Werden Tickets, Prioritätsänderungen und Zeitunterbrechungen nachvollziehbar dokumentiert?
• Ist festgelegt, wie wiederkehrende oder besonders schwere Störungen analysiert und dauerhaft abgestellt werden?

Je präziser diese Punkte geregelt sind, desto weniger hängt die Bearbeitung im Ernstfall von einzelnen Personen, Kulanz oder unterschiedlichen Erwartungen ab. Ein guter Supportvertrag beschreibt nicht nur, dass Hilfe geleistet wird. Er legt fest, wer wann welche Verantwortung übernimmt und welches Ergebnis dein Unternehmen bei welcher Störung erwarten darf.