Den lieben langen Tag beschäftige ich mich mit dem Thema Anwendungsmanagement, und träume dabei oft von einer effektiveren, ticketfreien Anwendungsbetreuung. Lässt sich die Bearbeitungszeit von Tickets nicht einfach mithilfe von Automatisierung reduzieren? Eine schöne und inzwischen auch recht gängige Lösung ist, beim Auftreten eines Anwendungsfehlers einen automatisch erstellten Snapshot des Systemstatus gemeinsam mit einer Fehlerbeschreibung an den Support zu schicken. Das spart viel Rede und Antwort über den Hintergrund der Problemmeldung. Dennoch lindert dieser Weg lediglich ein paar der lästigen Symptome anstatt das Problem bei der Wurzel zu packen. Brauchen wir die Tickets denn unbedingt? Ihr Sterben würde allen Beteiligten viel Zeit und Geld sparen – der Fachabteilung, der IT und nicht zuletzt dem User.

FAQ-Datenbanken eignen sich nur für einfache Probleme

Der Ausbau von Self-Service-Angeboten beispielsweise ist in diesem Zusammenhang eine gute Idee. Allerdings sollten sich Unternehmen überlegen, welche Fragen sie unter der Rubrik FAQs beantworten. Denn wird es mal kompliziert und erfordert die Lösung des Problems beispielsweise viel IT-Know-how, muss der Anwender Zeit mitbringen. Damit sinken seine Produktivität und Effizienz und unterm Strich verlagern sich die Kosten lediglich von IT zu Fachabteilungen. Versucht ein Kunde IT-Probleme mit Hilfe der FAQs zu lösen und kommt nicht weiter, endet die Geschichte in der Regel wieder beim Telefonsupport – was die FAQs ja ursprünglich vermeiden sollten. Greift der Kunde letztlich zum Hörer ist er unter Garantie bereits verärgert, denn die auf FAQs verschwendete Zeit gibt ihm keiner zurück.

Einzelne Schritte des Support-Prozesses zu automatisieren ist in vielen Fällen durchaus sinnvoll, allerdings nur, wenn der Prozess von Anfang bis Ende durchdacht ist. Ein Beispiel: Vor einiger Zeit verlor ich mein Handy. Und meine Bank unterstützt die Registrierung einer neuen Mobilfunknummer mit einem Standard-Prozess. Das Ergebnis: Die mTAN zur Bestätigung der neuen ging automatisch an die alte Rufnummer, auf dem zwar authentifizierten aber mir nicht mehr verfügbaren Gerät. Die Folge: ein langwieriger Prozess inkl. vieler Telefonate mit Bankmitarbeitern. Kostenpunkt, Zeit und Nerven. Ein anderes Beispiel: Ich bestellte meine neue Küche online. Der erste Händler teilte mir AM ENDE meines Bestellvorgangs mit, zwei Schrankfronten seien erst in sechs Monaten lieferbar. Die Zeit, die ich bis dahin in die Möbelauswahl und Dateneingabe investierte, schlug eins zu eins in Verärgerung um und ich bestellte woanders.

Endanwender vernachlässigt

Inzwischen hat das Möbelhaus der Küchenauswahl eine automatische Abfrage des Lagerbestandes vorgeschaltet. Jetzt werden nur noch Konstellationen angezeigt, die auch komplett lieferbar sind. Auch meine Bank hat einen Prozess aufgesetzt. Er ermöglicht, neue Endgeräte mittels Super-PIN zu registrieren, die ich bei der Eröffnung meines Kontos per Post erhalten habe. Eine gute Lösung für bedeutend weniger Anrufe im Contact Center, und damit letztlich auch weniger Tickets. Würden solche Prozesse allerdings gleich von vornherein aus Sicht der Endanwender getestet, wäre keiner dieser Aufwände überhaupt erst entstanden.

Ähnlich verhält es sich mit Tickets wegen langsam arbeitender oder abstürzender Systeme. Derzeit überwacht die IT meistens nur die Leistung und Verfügbarkeit der Anwendungen, nicht aber die Konsistenz der Daten. Diesen Vorgang können Unternehmen automatisieren, so dass der Support proaktiv Datenbanken bereinigen kann, bevor ihre Antwortzeiten steigen und sich die Tickets stapeln.

Die Kehrseite der Automatisierung

All diese Beispiele zeigen: Bleiben die Ursachen für Support-Anfragen weiter bestehen, hilft auch jede noch so gute Automatisierungslösung nicht weiter. Dieses Dilemma passiert, wenn IT und Anwender nicht miteinander sprechen und keiner weiß was den jeweils anderen umtreibt. So kommen munter weiter Prozesse, Workarounds und Solutions ins Spiel, um Symptome zu mildern. Am Ende ist es so kompliziert, dass niemand mehr durchblickt, aber Hauptsache, es läuft alles automatisch. Dennoch, von automatischen Service-Prozessen, die zu nichts führen, kann sich letztlich kein Anwender oder Kunde was kaufen. Sie wollen zuallererst gar kein Problem haben, das ein Ticket erforderlich macht. Warum ist genau das häufig so schwer? In vielen Fällen verhindern Interessenskonflikte beziehungsweise Zielkonflikte die Lösung. Die Support-Abteilung beispielsweise würde sich ungern daran messen lassen, wie wenig Tickets aufgemacht werden, denn erstens kann sie ein derartiges Ziel allein nicht erreichen und zweitens würde sie sich damit selbst überflüssig machen.

KPIs sind nicht immer aussagefähig

Ich habe selbst schon erlebt, dass eine Endkunden-Hotline hervorragend kurze Bearbeitungszeiten und dabei enorm hohe Erstlösungsraten hatte. Trotzdem hagelte es in User-Foren harsche Kritik. Können Anwender so ungerecht sein? Nein, denn es stellte sich heraus, dass die Hotline jedes Ticket beim Erstkontakt schloss. Dabei teilte sie dem Kunden mit, dass sie ihn erneut kontaktieren wird, um das Problem zu lösen. Für diesen Vorgang öffnete sie ein neues Ticket. Wie viel Zeit zwischen Antwort A und Kontakt B verging, war auf diese Art nicht messbar. Das Ergebnis ließ sich allerdings sehen: übererfüllte KPIs, genervte Anwender und ein ratloses Management.

Wäre diese Hotline nicht an den üblichen Qualitätsparametern Erstlösungsrate und Service Level gemessen worden und hätten sich alle Prozessbeteiligten stattdessen zusammengesetzt, um die Ursachen für User-Anfragen abzustellen, wäre es möglicherweise gar nicht erst so weit gekommen. Deshalb plädiere ich immer dafür, Business-KPIs zu definieren. Sie sollten den gesamten Prozess abdecken und für alle Beteiligten lohnenswert sein. Letzteres ist zwar kompliziert, meiner Meinung nach aber machbar. Dann kämen wir auch dem (fast) Ticket-freien Arbeitsalltag näher. Oder sind Sie immer noch der Meinung, dass es nur ein schöner Traum ist?

Liebe Anwender, hört auf Euch über die Ticketabarbeitung bei der IT zu beschweren. Geht stattdessen mit dem CIO in einen Dialog über Business KPIs und fordert störungsfreie Geschäftsprozesse aus Anwendersicht.