Im IT Service Geschäft geht es nicht nur um technische Architekturen und Interfaces, sondern zu ganz großen Anteilen um soziale Konstellationen und Schnittstellen. Technische Arbeit gibt es immer und es findet sich eigentlich immer ein Kollege oder Nachbarabteilung, die eigentlich das Problem haben und es bitteschön lösen müssen.
Vor Jahren hatte ich es mit einem Mitarbeiter der Nachbarabteilung zu tun, der irgendwie Kooperationswillig schien, dennoch für reichlich Ärger sorgte. Seine Art war es zu Unzeiten sehr viel über den Zaun zu werfen. Dabei erklärte er wortreich, warum das über den Zaun geworfene nun genau nicht mehr sein Problem sei. Nennen wir diesen ungenannten Mitarbeiter mal Tom. Tom ist akademisch gebildet und bei seinen direkten Kollegen als Fachkraft sehr anerkannt.
Meine eigene Abteilung tickte da doch etwas anders. Ich selbst habe in drei Phasen meines Arbeitslebens für mich selbst Zeitmanagment eingeführt und es in drei großen Änderungen sehr effizient ausgebaut. Das Ganze habe ich dann mit viel Mühe und Schweiß nach und nach in meine Abteilung umgesetzt. Mit dem Ergebnis, dass auch das unstrukturierteste Teammitgleid ein gewisses Zeitmanagment hatte und dies im höheren Management positiv aufgefallen war.
Nun lag wieder so Aktion von Tom vor. Tom hatte zu Ende der Woche allerlei seiner Aufgaben über diverse Zäune geworfen und sorgte mit seiner Tat für eine Krisensitzung. Die anwesenden Team- und Abteilungsleiter fanden einen Kompromiss zur Verteilung der Arbeitslast und mein Chef gab mir die Aufgabe Tom zu coachen.
Na super, einen Mitarbeiter einer anderen Abteilung in strukturierteres Arbeiten lenken, was für eine Aufgabe. Wir verabredeten zusammen mit seinem Chef, dass Tom und ich uns zweimal die Woche morgens 30 Minuten zusammensetzen, um den Tag zu strukturieren.
Für den ersten Termin bat ich Tom seine ToDo-Liste mitzubringen, egal wie die aussehen würde: Papier, Elektronik, Whiteboard. Darauf reagierte Tom recht aggressiv, was eher nicht seinem Naturell entsprach. Tom verschwendete die 30 Minuten mir zu erklären wie sehr er unter Arbeitsbelastung stehe.
Um die Sache abzukürzen: Er hatte keinerlei ToDo-Liste und auch keinerlei planmäßige Idee den Tag anzugehen. Also mussten wir seinen Tag vermessen. Ich bat ihn bis zum nächsten Treffen eine grobe Zeiterfassung anzufertigen und bekam als Antwort ein Arbeitsüberlastungs-Stöhnen. Zu den nächsten Treffen bekam ich sehr künstliche Listen, die vermutlich kurz vor dem Treffen entstanden waren.
Also den langen Weg: Ich sprach Tom wann immer möglich alle 2 Stunden an, bat ihn mir zu sagen was er gerade getan hat und dies aufzuschreiben. So kamen wir langsam, sehr langsam zusammen und konnten fachlich über die Aufgaben reden. In diesen Wochen entstanden aus den Ex-Post-Listen langsam Planungen, die Falls Not am Mann war vollständig über den Haufen geworfen wurden. Not am Mann war sehr oft, eigentlich immer.
Als langsam klar wurde, dass Tom ein Zeitmanagment nicht mehr ignorieren konnte prägte er den sehr schönen Satz „Zeitmanagement nützt nicht, ich kann ja nicht delegieren“. Der war natürlich eine Spitze gegen mich, als Abteilungsleiter kann man ja anscheinend die Aufgaben, die man von seinem Chef bekommt, weg-delegieren 🙂
Was mich zu den Fehlern im IT Selbst-Managment von Tom bringt. Am Ende der Reise hatte Tom ein einfaches Zeitmanagment, dass zwei sehr wichtige Erfolge brachte:
- Tom ging Abends nach Hause mit einer klaren Vorstellung was noch ansteht. Zuvor war der Tag nie lang genug und man hatte noch so unermesslich viel zu tun. Diesen Zuwachs an Lebensqualität behält er meines Wissens nach heute noch.
- Wir haben viel unsinnige Zeitfresser aus seinem Alltag herausgefiltert. Diese möchte ich hier mal darstellen, um eine Vorstellung davon zu geben was neben dem Mittel einer Priorisierung möglich ist.
Tom ist als Administrator zusammen mit zwei Kollegen für eine Geschäftsanwendung verantwortlich (Datenbank, J2EE, Applikation). Die Arbeit des Teams wird von seinem Chef nicht besonders gelenkt, Anforderungen laufen recht ungefiltert in das Team.
Fachlich delegieren
Tom lies Störungs-Tickets (Incidents) im ITSM System gerne bis Freitag Nachmittag liegen. Montags wurde die Supportschicht an einen direkten Kollegen übergeben, diesem wollte er die liegen-gelassenen Störungen nicht zumuten. Also verteilte er großzügig seine Störungen an Nachbarabteilungen. Man muss dazu wissen, diese waren zu dem Zeitpunkt meist schon Dunkelrot, also aus der Lösungszeit hinausgelaufen. Abgelaufene Tickets tauchten in der IT Statistik auf und niemand wollte diese heißen Kartoffeln fangen.
Nun erklärte mir Tom lang und breit warum dieses Ticket von der Nachbarabteilung gelöst werden müsse. Lieber Tom, es ist zu spät. Ja fachlich eher deren Problem, durch den Zeitverzug nun aber deines. Schau doch bitte Morgens, Mittags und Abends ins Tool: Prüfe ob alle Informationen da sind, löse Dinge unter 2 min sofort, prüfe ob Du der richtige Ansprechpartner bist, ansonsten leite das Ticket sofort an die Nachbarabteilung weiter. Die eingesparte Arbeitszeit war immens und die Menge der zufriedenen Menschen auch.
Rechtzeitig Nein sagen
Tom war Meister in losen Absprachen. Am Kaffeeautomat schnell mal Ja gesagt. Wenn der Termin dann kam oder überfällig war, erinnerte er sich meist an die Absprache diskutierte dann aber wortreich, dies sei nicht der abgesprochene Umfang. Das übliche Resultat war eine Hau-Ruck-Aktion bei der er beteiligt war und in deren Nachwehen einige andere seiner Terminzusagen platzen.
Eine kurze schriftliche Zusammenfassung während der Kaffee in der Tasse noch heiß ist, löst heutzutage dieses Dilemma. Was ist angefragt, was nicht und ein Zeitpunkt mit Termin und allen Teilnehmern. Hier liegt der Vorteil in Struktur, wie viel Arbeit eingespart wurde lässt sich nur schätzen.
Releasemanagement und Regeln
Tom (und seine Kollegen) patchten die Systeme sobald auch nur irgendein Patch da war. Morgens checkte ein Skript ob ein neuer Patch da war, der wurde sofort eingespielt, basta. Dies hatte einige negative Konsequenzen. Updates oder Patches werden manchmal zurückgezogen oder in kurzer Abfolge ergänzt. Tom machte also alle Versionen aller Patches mit. Im positiven Fall bedeutet das nur dreimal so viel Arbeit, ist ja nicht massenhaft, geht immer gut. Halt: Das geht nicht immer gut. Nach Toms und meiner Analyse sogar eher des Öfteren mal nicht gut.
Gerade bei Updates, die nach einigen Tagen zurückgezogen werden ist man ganz vorn dabei. Das Update wird eingespielt, System läuft auf Fehler und Google bzw. die Communities haben noch keine Antworten. Hektik entsteht, es wird repariert, Backups eingespielt, dadurch ein unklarer Systemzustand hergestellt.
Man sollte auch die Notwendigkeit dieser Patches nicht überbewerten. Bei einem System in einer abgeschotteten IT Landschaft ist das patchen öfter fraglich, als man denkt. Zugriffe über Clients, die das Unternehmen gar nicht einsetzt, ausweiten von User-Rechten bei Systemen die nur einen Systemuser haben, etc. all das muss nie eingespielt werden.
Leute nutzt Release Management, wenn drei-vier Patche zu einem Termin zusammengefasst werden hat man nur einen neuen Systemzustand, statt über die Zeit vier verschiedene Zustände. Das dämmt die Fehlersuche sehr stark ein. Auch ist allen Beteiligten eher bewusst, dass gestern der Unternehmensinterne Patch-Day war und der Fehler heute vermutlich mit dem neuen Systemzustand zu tun hat.
Nun kam noch dazu, dass Toms Team auch gerne Server und Datenbank patchte, obwohl dies als Managed Service von der Nachbarabteilung geliefert wurde. Was immer wieder zu Streit führte, auch verweigerten die Kollegen zu Recht die Mitarbeit bei der Fehlersuche und mussten mit Mettbrötchen überredet werden. Toms Antwort auf die Frage warum er dort eingreift war: Die Kollegen seien so langsam und es gehe schließlich um Security.
Diese Arbeitsweise abzustellen war ein etwas längerer Weg. Change und Release Management wurden noch einmal von den alten Hasen im Unternehmen in Frage gestellt, bei vielen operativen Abteilungen fehlen ganz konkrete Anweisungen für deren Systeme aber letztendlich wird der Patch-Day nun einigermaßen befolgt. Die Reduktion der Arbeitszeit von Tom ist auch hier immens.
Rumdameln auf IT Art
Was bei IT Servern „Housekeeping“ also Ordung und Sauberkeit sein soll, weiß irgendwie keiner. Statt die Logbücher ordentlicher zu führen, Ist- mit Soll-Zustand abzugleichen, leerte Tom Temp-Verzeichnisse, entfernte nicht mehr benötigte Bibliotheken, lösche alte Systemkerne und sogar alte Log-Files. Hie und da führte sein treiben zu einem Systemstillstand der mehr oder weniger schnell behoben wurde.
Warum man bei einem Unix-System nicht benötigte Bibliotheken löschen muss, wo doch auf der Systempartition reichlich Platz ist, wurde mit „Housekeeping“ beantwortet. Die eigentliche Antwort auf die Frage nach dem warum ist simpel und liegt irgendwo bei rumdameln, rumspielen.
Nun gibt es eine Checkliste „Housekeeping“ und einen Zeitabstand von 3 Monaten. Wir leeren nicht mehr die Mülleimer, denn das macht das System selber, sondern schauen durch das Inventar und dokumentieren Lücken nach.
Fazit
Der Artikel endet mit der Frage: War ich erfolgreich? Na ja, so halb. Tom ist immer noch nicht der strukturierteste Mensch in seiner Umgebung. Aber er ist tatsächlich glücklicher und hat nachweislich weniger Überstunden.
Wir haben ungefähr 12 Monate zusammen gearbeitet, dass das so lange dauert habe ich nicht vermutet. Nach ca. 8 Monaten sah man Tom öfter entspannt und fröhlich mit Kollegen quatschen. Das er als Ergebnis der Maßnahme glücklicher sein könnte, hat er zu diesem Zeitpunkt nicht geglaubt. Strukturiertes Arbeiten ist eher etwas für Beamtenköpfe als für richtige IT-ler.