Es kommt stark darauf an welche Fragen gestellt werden damit die nachfolgende Bearbeitung auch erfolgreich wird. Einerseits kann man sich an ITIL halten, aber alleine das Schema ist nur das Konstrukt für einen guten Support.
Es wird nie perfekt sein können
Erst einmal muss man wissen, dass es nie perfekt sein kann und auch nie perfekt sein wird. Wie alles im Leben ist auch der Support ein konstantes Streben nach Glück. In vielen Firmen wird man das auch spüren und dann entweder daran verzweifeln, oder weiter streben. Hier möchte ich mal meine ganz persönliche Sicht auf die Dinge rund um ITIL und Prozessmanagement schildern.
Auch kleine Positionen haben große Wirkung
Erst einmal geht es um die wirtschaftliche Priorisierung einzelner Prozess-Schritte, natürlich sind die bearbeitenden Personen, die eine Störung endgültig beheben, die wirtschaftlich erfolgreichsten. Deshalb ist man geneigt sein Hauptaugenmerk genau auf diese zu legen und deren Arbeitsstruktur so gut es geht zu verbessern.
Der fatale Fehler dabei: Der ganze ITIL-Prozess, oder nennen wir ihn ab jetzt einfach Geschäftsprozess, hängt an mehreren Elementen.
Funktioniert die Aufnahme nicht, kann die Nachbearbeitung nicht funktionieren und überlastet die Nachbearbeitung die Aufnahme entstehen Flüchtigkeitsfehler und ein Trend zur Vereinfachung entsteht – sprich: Eine äußerst schädliche Bevorzugung von Quantität. Welches dann wiederum für die Nachbearbeitung ungenaue oder unpassende Fälle bedeutet.
Ein Fallbeispiel
Prinzipiell sehe ich die Grundstruktur für „Tickets“ eher in einigen Fragen:
- Was wollten Sie gerade tun?
- Warum können Sie dies gerade nicht ausführen?
- Falls Sie eine Fehlermeldung sehen, in welchem genauen Wortlaut ist diese?
- Was haben Sie kurz vor der Fehlermeldung getan? Oder was taten Sie, um Ihr Ziel zu erreichen?
Ganz wichtig dabei ist es dem Kunden zu erklären, dass auch der banalste Zusammenhang zählt. Das Verständnis von Zusammenhang zwischen Ursache und Fehler ist in jedem Menschen anders und jeder hält etwas anderes als Selbstverständlich. Es mag auch für den Kunden sicherlich ungewöhnlich sein zu schildern, dass er gerade auf einen Button nicht klicken kann, aber genau das ist etwas, was er als Selbstverständlichkeit ansah und deshalb sonst verschwiegen hätte.
Das Ganze würde ich gerne noch einmal an einem Beispiel veranschaulichen:
- Was wollten Sie gerade tun?
„Ich wollte eine Auftragsbestätigung an unseren Lieferanten senden.“ - Warum können Sie dies gerade nicht ausführen?
„Ich habe unseren Lieferanten angerufen, bei ihm sei nichts angekommen“. - Falls Sie eine Fehlermeldung, in welchem Wortlaut ist diese?
„Es gab keine Fehlermeldung.“ - Was haben Sie kurz vor der Fehlermeldung getan? Oder was taten Sie, um Ihr Ziel zu erreichen?
„Ich habe Outlook geöffnet, eine E-Mail an die Adresse lieferant@firma.de geschrieben und abgesendet. Nach einigen Stunden rief ich an und fragte nach dem Eingang der Mail.“
Hier ist schon eine Falle eingebaut. Es wird vermutlich sehr wohl eine Fehlermeldung gegeben haben, die der Anwender allerdings nicht als zusammengehörig ansah.
Wir gehen jetzt davon aus, dass der Lieferant wegen kompromittiertem Netzwerk beim E-Mail-Provider gesperrt wurde und deshalb keine Mails empfangen oder senden kann bis er seinem Provider die von ihm vorgeschlagenen Maßnahmen bestätigt.
Meistens ist es der Empfängerfirma entweder nicht bekannt, oder relativ spät bekannt – immerhin ist es ein „erstaunlich ruhiger Tag“ der nun mal eben auch so auftreten könnte.
Prinzipiell ist das einzige, was nach der Störungsaufnahme getan werden muss, nachzusehen was mit dieser E-Mail geschah. Entweder filtert man im Ablaufprotokoll vom Exchange nach der MessageID und findet darüber die delivery-failed Nachricht des Empfängerproviders, oder man forstet per Fernwartung im Outlook nach entsprechenden Rückmeldungen.
Ist man dann nicht an große wirtschaftliche Prozesse gebunden, kann man der Empfängerfirma natürlich anbieten gegen Bezahlung beim Provider-Problem zu helfen, ansonsten ist man mit dem Ticket durch.
Die Lösung ist also zu empfehlen den Auftrag an den Lieferanten per Fax oder anderen Möglichkeiten zu geben.
Wichtig hierbei ist nicht die Rückmeldung „wir können nichts tun“ – welche auch stimmen würde – sondern eher der Vorschlag und die Erklärung was genau los ist und warum nicht direkt behoben werden kann.
Die Lösung sieht also so aus:
„Ihr Lieferant ist leider gesperrt worden, da dieser Probleme mit eventuellen Schädlingen in seinem Netzwerk hat oder haben könnte. Wir empfehlen Ihnen die Bestellung, falls möglich, per Fax oder Telefon aufzugeben.“
Das bezweckt im Idealfall einen Kunden der beim Lieferanten anruft und diesen auf die Probleme aufmerksam macht, sofern es nicht bereits während der Behebung des Tickets passiert ist.
Ohne Fragen beginnt Wildwuchs
Was der obere Vorgang beschreibt sind die richtigen Fragen die zu stellen sind. Wird dem Kunden ein freier Lauf gegeben, wäre die Meldung „E-Mails funktionieren nicht, wir haben das mit mehreren Mails getestet“ – wobei dann meist verschluckt wird, dass man ja seinem Hauptlieferanten auf mehreren seiner Adressen hat versucht zu erreichen. Was auch erklärbar ist, weil der Unterschied zwischen Domain und E-Mail-Adresse nicht bekannt sein muss und sich geschäftliche Beziehungen oftmals genau so wie gute Freunde auf erstaunlich wenige Beziehungen beschränken.
Letztendlich habe ich relativ gute Erfahrung mit dem simplen Fragenkatalog gemacht. Natürlich darf man sich auf diesen nicht festbeißen und darf nicht gleich alles verteufeln das nicht genau dem Muster entspricht, aber diese Fragen geben auch denjenigen, die Hilfe suchen den richtigen Anstoß auch diese Fragen zu beantworten, so wird auch die Behebung danach einfacher, auch wenn diese in der operativen Störungsbehebung mal länger dauert. Zum Beispiel, wenn sich komplexere Fehlerursachen herausstellen, die schon im ursprünglichen Service Design aufgetreten sind.
In a nutshell:
Um eine Störung zu beheben, solltest du nicht versuchen die Störung zu erkennen, sondern verstehen, warum es der Kunde gerade nicht tun kann und was das für Auswirkungen auf den Betrieb deines Kunden hat. Dein Helfer-Instinkt wird dich sowieso zur Fehlersuche bewegen.