Softwarefehler mit IT Support Teams managen – Teil 1

Keine Kommentare

Welcher IT-Dienstleister kann von sich sagen, eine fehlerfreie Software-Anwendung zu betreiben? Wir alle wissen, dass es trotz intensivster Bemühungen in der Qualitätssicherung unmöglich ist, komplexe Software fehlerfrei zu betreiben. Wir wissen aber auch, dass durch Störungen in Form einer Downtime in unternehmenskritischen Anwendungen in wenigen Minuten mehrere tausend Euro Schaden entstehen können. Umso wichtiger ist es, dass Störungen im laufenden Betrieb in kurzer Zeit kanalisiert, priorisiert und behoben werden.
Doch Kunden erwarten heute noch deutlich mehr.
Ein guter Support gibt Kunden nicht nur eine schnelle und klare Rückmeldung über die eingereichten Störungsmeldungen, sondern informiert sie auch proaktiv, wenn die Probleme gelöst worden sind (Stichwort: Customer Experience).

In diesem ersten Teil der Blogserie werde ich nach einleitender Begriffserklärung über die Notwendigkeit und Aufgaben eines IT Support Teams schreiben. Im zweiten Teil geht es um einen Lösungsansatz für die Schnittstelle des Support Teams zum 3rd-Level Support am Beispiel von Softwareentwicklungs-Teams.

Was ist eine IT Störung?

Hier eine Definition aus Wikipedia:

Unter einer Störung versteht man nach
IT Infrastructure Library (ITIL):
„Ein Ereignis, das nicht zum standardmäßigen Betrieb eines Services
gehört und das tatsächlich oder potenziell eine Unterbrechung dieses
Services oder eine Minderung der vereinbarten Qualität verursacht.“

Störungen in der IT werden in der ITIL-Sprache auch Incidents genannt. Der Begriff “IT-Service” kommt aus der ITIL-Sprache und kann zum Beispiel als Software-Anwendung verstanden werden.

Ein Incident kann an unterschiedlichsten Stellen in der IT auftreten zum Beispiel:

  • bei einem Netzwerkausfall
  • in einem Online Report mit falschen Zahlen
  • durch schlechte Anwendungsperformance

Je umfangreicher, volatiler und komplexer der IT-Service ist, umso höher wird auch die Anzahl der täglich gemeldeten Incidents sein. Der IT-Service hat die Aufgabe, einen Mehrwert für den Kunden zu erbringen. Jede Störung dieses IT-Services bewirkt also erstmal eine Verschlechterung des Mehrwertes.

Zur effizienten Störungsbehebung beschreibt der Best Practice Ansatz von ITIL den Incidentmanagement-Prozess, wie in dem folgenden Aktivitätsdiagramm zu erkennen ist.

Incidentmanagement

Die Organisation eines IT-Supports

Incidents werden mit Hilfe von Trouble Tickets dokumentiert. Für die Entgegennahme und Überwachung der Tickets ist ein Support Team zuständig. Support Teams werden auch oft Help Desk oder Service Desk genannt.

Der IT-Support wird häufig in 1st-Level, 2nd-Level und 3rd-Level Support unterteilt. Der 1st-Level ist der erste Anlaufpunkt für den Kunden zur Erfassung aller Vorfälle. Der 2nd-Level ist in der Regel im IT-Betrieb angesiedelt und beseitigt die Störungen, die durch den 1st-Level nicht behoben werden konnten. Der 2nd-Level ist also für die technisch anspruchsvollen Supportanfragen zuständig. Mit dem 3rd-Level ist der Hersteller der Anwendung gemeint, welcher zum Beispiel der externe Anbieter oder das In-House Software-Entwicklungs-Team sein kann. Der 3rd-Level ist also die letzte “Eskalationsstufe” der Supportanfrage und wird involviert, wenn die vorhergehenden Stufen keine Lösung herbeiführen konnten.

Wer braucht ein Support Team?

Die Hauptgründe für ein Unternehmen ein Support Team einzurichten sind sicherlich die Möglichkeit einer zentralen Anlaufstelle für den Kunden, Effizienz und Kostenoptimierung. Bei einem Volumen von mehreren 100 Tickets in der Woche wird es für ein Software-Entwicklungs- Team nicht mehr wirtschaftlich sein alle Fragen selbst zu beantworten. Es ist kostengünstiger, redundante und einfach zu lösende Anfragen durch den Support bearbeiten zu lassen. Der geschulte Support ist darauf fokussiert, kundenorientiert und zügig zu agieren. Weiterhin lassen störungsbedingte Unterbrechungen die Produktivität der Entwickler rapide sinken. Eine interessante Statistik zu Unterbrechungen am Arbeitsplatz ist hier zu finden.

Es gibt allerdings noch weitere Gründe für ein Support Team, die sich klarer herausstellen lassen. Dazu betrachten wir die Aufgaben eines Support Teams näher.

Aufgaben eines Support Teams

  • Details der Störung herausfinden und schnelle Rückmeldung an den Kunden – innerhalb des Service Level Agreement (SLA)
  • Abgleich mit bekannten Fehlern („known Errors“)
  • Priorisierung und Behebung der Störungen innerhalb des vorgegebenen SLA
  • hohe Erstlösungsquote erzielen im Zweifel durch Workarounds
  • Verkürzung der Mean Time To Repair (MTTR) in enger Zusammenarbeit mit dem 3rd-Level
  • Dokumentation bekannter Lösungswege oder Workarounds

Nicht nur, dass diese vielfältigen Tätigkeiten eine Spezialisierung durch ein Support Team sinnvoll werden lassen. Derartige Aufgaben sind zum Teil sogar gegenläufig zu den Aufgaben eines Entwicklungs-Teams. Während ein Software-Entwickler versucht die Ursache der Störung zu finden und zu beheben, hat der Support zum obersten Ziel die Störung so schnell es geht zu lösen – im Zweifel durch einen Workaround. Über einen längeren Zeitraum würden somit immer mehr Workarounds aufgebaut werden, die den gleichen Effekt wie technische Schulden in Software-Projekten haben.

Es geht auch nicht immer einzig und allein um Geschwindigkeit. Das Support Umfeld ist sehr dynamisch:

  • Prioritäten von Anfragen können sich über den Lebenszyklus ändern.
  • Abhängigkeiten zwischen Störungen entstehen und lösen sich auf.
  • Zuständigkeiten ändern sich.

Insbesondere bei sehr vielen Anfragen gilt es den Überblick zu halten, also keine Anfragen zu übersehen sowie fachlich korrekt und freundlich zu antworten.

Was spricht gegen ein Support Team?

Es gibt neben den genannten Vorteilen für eine Organisationsform mit Support Teams selbstverständlich auch Nachteile.
Jede zusätzliche geschaffene Kommunikationsschnittstelle birgt die Gefahr von Informationsverlust, redundanten Tätigkeiten, Reibungspotential oder Zeitverlust.

Welche detaillierten Herausforderungen die Schnittstelle zwischen Support Teams und Entwicklungs-Teams birgt, welche Lösungsansätze es gibt und inwiefern DevOps die Probleme löst, werde ich im nächsten Teil dieser Blogreihe behandeln.

 

Jörg Spiegelhoff

Jörg Spiegelhoff ist seit 2010 bei der codecentric am Standort Solingen. In seiner 20-jährigen IT-Laufbahn hat er in den Rollen Produkt-/Projektmanager, Agile Coach und IT-Leiter in verschiedenen Branchen und mit unterschiedlichen Technologien Erfahrungen sammeln können. Aktueller Schwerpunkt seiner Arbeit ist es, die Partnerschaft mit Atlassian auszubauen und Unternehmen beim Einsatz des Produktportfolios zu unterstützen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.