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.
