3rd-Level-Support

Weit mehr als Troubleshooting

Kunden zufriedenstellen. Und das Problem an der Wurzel packen

Ganz oben auf der Eskalationsleiter

Das Incident Management im Rahmen des IT Service Managements sieht drei Eskalationsstufen vor. In der ersten Stufe legt ein Service-Desk ein Ticket an, nimmt eine Kategorisierung und Priorisierung vor und findet in vielen Fällen eine Sofortlösung. Wenn das nicht klappt, wird das Ticket an den 2nd-Level-Support weitergeleitet – an technische Experten, die zwar in die Tiefe gehen können, aber noch keine Hand an den Code legen dürfen. Kommt man auch auf diese Art nicht weiter, wird das Problem an den 3rd-Level-Support eskaliert. Der setzt sich aus Spezialisten zusammen, die entscheiden, ob es für das Problem bereits eine Lösung gibt (z.B. ein anstehendes Update), oder ob und wie eine neue Lösung gefunden werden muss.

Das 3. Level

Nicht alle Firmen sind in der Lage, das für die dritte Supportebene nötige Know-how aufzubauen und zu pflegen. Kundenanfragen des 3rd Levels beinhalten außergewöhnliche oder einzigartige Problemstellungen.

Quelle: http://www.hardwarewartung.com/

Sicherheit ist oberstes Gebot

Der Kunde wartet auf eine Lösung innerhalb der vertraglich vereinbarten Reaktionszeiten (Service Level Agreement). Die erforderlichen Eingriffe dürfen aber auf keinen Fall die Systemstabilität gefährden. Mitunter ist es daher sinnvoll, zweigleisig vorzugehen: Der Kunde bekommt eine Umgehungslösung (Workaround) und bleibt durch diese schnelle, effektive Hilfe arbeitsfähig. Gleichzeitig ermittelt die Entwicklung Möglichkeiten, das Problem an der Wurzel zu beheben. Dabei entstehen häufig Ideen für Verbesserungen und neue Features für die Software münden.

3rd-Level-Support - am Beispiel der ePayBL

Ticket-Erstellung

Priorisierung anhand der Schwere bzw. Dringlichkeit des Problems.
Abfrage von Informationen zum Kontext (Log-Files, Screenshots, Ablauf, Rückfragen).

Analyse des Tickets

Klassifizierung: Fehler oder neue Anforderung.
Anfordern weiterer Informationen.
Bei Fehlern: Finden der Ursachen.
Bei neuen Anforderungen: Verstehen des Problems, Vorschläge zur Umsetzung.
Diskussion und Abstimmung zur Umsetzung einschließlich Aufwandsabschätzung und (Re-Priorisierung).

Umsetzung

Bei Fehlern: Korrektur des Fehlers im Code, ggf. mit temporärem Workaround.
Bei neuen Anforderungen: Umsetzen der Anforderung.
In beiden Fällen: Mehrstufiger Test (Komponenten-Tests, GUI-Tests, Integrationstests), Dokumentation, Abstimmung über die Produkt-Roadmap.

 

Auslieferung

Erstellen eines versionierten und gelabelten Softwarestands.
Ausliefern eines reproduzierbaren Mediums zur Installation auf der Zielanlage über einen Austausch-Server beim Kunden.

Abnahme durch den Kunden

Abnahmetests im Test- und Integrationssystem des Kunden.
Freigabe und Einspielen in das Produktivsystem.
Gegebenenfalls Erstellen neuer Tickets für Folgefehler oder geänderte Anforderungen (zurück zu Schritt 1).

Der kürzeste Weg zur Weißglut

Viele große Organisationen lagern den IT-Support komplett aus. Bei Level 1 und 2 kann das durchaus sinnvoll sein, weil die externen Service-Mitarbeiter 24/7 erreichbar sind und Probleme idealerweise rasch lösen können – was aber oft nicht klappt, nicht zuletzt wegen der hohen Fluktuation auf Dienstleisterseite. Richtig kritisch wird’s, wenn Probleme tiefer liegen und wochen- und monatelang ungelöst bleiben. Im Effekt stellt sich bei vielen Usern das ohnmächtige Gefühl ein, übermäßig viel Zeit für IT zu investieren.

Woher kommt das? Die Sachbearbeiter beim externen Dienstleister haben weder eine Verbindung zur Geschichte noch zur Zukunft des Systems. Daher ist es gut, wenn Konzeption, Entwicklung und 3rd-Level-Support in einer Hand liegen.

Das kontrollierte Vorgehensmodell mit klaren Prozessen und enger Abstimmung mit den Kunden hat sich bewährt. Es gewährleistet ein transparentes, strukturiertes und geordnetes Vorgehen bei der Weiterentwicklung der ePayBL.