Dienstleistung

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.

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.