Das Problem im IT-Service

Egal was du in der IT tust, es wird neue Probleme indizieren. Keine Lösung ist perfekt – und auch wenn du es versuchst, kannst du nur gegen die Gegebenheiten testen, die du aktuell hast. Gegebenheiten ändern sich. Auch in Zukunft noch.
Eine aktuell perfekte Lösung ist eine die in kürzerer oder längerer Zeit zu Problemen führt. Diese Relation sollte einem bewusst sein.

Es ist also unverweigerlich dass du dich immer und immer wieder mit gleichen Themen auseinandersetzt – auch mit Themen dessen Lösung schon mal vor X Monaten oder Jahren gefunden wurde. Problemstellungen klingen gleich, die Lösung dazu muss sich aber aktuellen Gegebenheiten anpassen und deshalb gibt es keine perfekte Lösung.

Mag man ITIL-Lebenszyklus nennen, mag man auch nicht nach irgendwelchen Frameworks angehen. Schlussendlich endet ein Prozess nie – es kommen nur immer mehr dazu.
Wer das nicht versteht oder akzeptieren kann wird irgendwann entweder Interesse oder Willenskraft verlieren. Das bezieht sich nicht nur auf Personen, sondern auch auf Firmen und deren Tätigkeitsgebiete als Ganzes.

Weil die Anforderung nicht statisch sein kann, kann man deren Lösung nicht als Perfekt bezeichnen.

Incident Reports

Das Problem bei Incident Reports ist häufig nicht dass ein Ticket wirklich gut und zufriedenstellend gelöst wird – es ist oftmals das Problem dass selbst der Serviceprovider nicht genau weiß warum und wieso das jetzt geholfen hat.

Der gängigste Weg in der IT ist oftmals ein ausprobieren – eine Art „ausprobieren mit System“. Man hat gewisse Ansätze und testet sie so lange durch bis man „out of ideas“ ist. Wenn irgendwas arg fehlschlägt spielt man den VM-Snapshot von davor eben kurz zurück. Hat man ein Produktivsystem hat man sich den letzten Snapshot eben geklont und experimentiert dort.
Inmitten dieser ganzen Ansätze funktioniert es dann halt irgendwann und man weiß zu dem Zeitpunkt wirklich noch nicht genau warum und wieso das jetzt damit funktioniert hat.

Man schreibt sich also in seine KB, dass es damit funktioniert hat – damit es eben alle wissen und die künftig berechnete Zeit unternehmensweit effizienter verwendet wird, aber benötigt für die Nacharbeit gehörig viel Zeit die kaum Umsatz einfährt.

Das ist die Krux bei Incident Reports. Ein Mitarbeiter der sie schreibt fährt keinen Umsatz, ist also unprofitabel. Im Gegensatz dazu kann der Serviceprovider selbst nicht so richtig erklären warum und wieso irgendwas geklappt hat und warum es vorher oder urplötzlich ein Problem wurde.

Dazu gibt es auch ein passendes Wallpaper. Nur dass man selbst oftmals nur beschreiben kann welchen Ansatz man gefahren ist bis es zur Lösung kam.

Die richtigen Starter-Fragen im IT-Support

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:

  1. Was wollten Sie gerade tun?
  2. Warum können Sie dies gerade nicht ausführen?
  3. Falls Sie eine Fehlermeldung sehen, in welchem genauen Wortlaut ist diese?
  4. 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:

  1. Was wollten Sie gerade tun?
    „Ich wollte eine Auftragsbestätigung an unseren Lieferanten senden.“
  2. Warum können Sie dies gerade nicht ausführen?
    „Ich habe unseren Lieferanten angerufen, bei ihm sei nichts angekommen“.
  3. Falls Sie eine Fehlermeldung, in welchem Wortlaut ist diese?
    „Es gab keine Fehlermeldung.“
  4. 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.