Arbeiten auf Treibsand

In der IT werden seit etwa 20 Jahren Organisationsformen ausprobiert. Einige haben sich bewährt, viele sind jedoch gescheitert. Aber sie werden meistens nur als Methoden der Softwareentwicklung gesehen. In anderen Bereichen haben sich Trends wie NEW WORK in die gleiche Lücke geschoben. Aber allen ist gemein, dass sie versuchen, ein Problem zu lösen, das unlösbar scheint.

Spätestens im letzten Jahr hat sich für viele Menschen die Arbeitswelt deutlich geändert. Während einige Arbeitsbereiche sich nicht ändern können (LKW-Fahrer und Feuerwehr können nicht im Homeoffice arbeiten) ist in den Verwaltungen des Unternehmens ein jahrzentelanger Mythos gebrochen worden. Viele Chefs waren davon überzeugt, dass die Mitarbeiter nur auf der Couch schlafen würden, wenn sie nicht im Büro sitzen würden. Sie hatten Angst vor Kontrollverlust. Durch die SARS-Covid-Pandemie blieb vielen Chefs nichts anderes übrig, als sich darauf einzulassen.

Aber die Welt hat sich geändert. Stand man früher noch auf festen Boden und konnte agieren, weiß man heute nicht, wann sich als ewig geglaubte Grundsätze als alt erweisen. Es ist so, als würde sich der stabile Fels von gestern in Treibsand verwandelt haben. Nichts ist mehr sicher.

Die meisten Verwaltungen funktionieren weiter. Es gab (und gibt) noch Reibungsverluste, liebgewonnene Gewohnheiten und Arbeitsweisen funktionieren so nicht mehr und man muss neue Wege finden. Aber es finden sich Wege. Die Situation hat eines gezeigt: die oft beschworene „Business Resilienz“ greift zu kurz. Das haben wir in der IT schon die letzten Jahre vor allem durch das Aufkommen der Cloud lernen müssen und viele Firmen haben diese Umstellung noch nicht abgeschlossen. Aber gehen wir ein paar Schritte zurück. Früher hatten IT-Abteilungen oft eine Zahl, an der sie gemessen wurden: die MTBF („Mean Time Between Failure“, auf Deutsch: „durchschnittliche Zeit zwischen Fehlern“). Die musste so hoch wie möglich sein. Fehler sollten immer ausgeschlossen sein. Ich muss sagen, in vielen (vor allem Manager-Köpfen) ist dies auch heute noch die wichtigste Kennzahl: „Die IT muss funktionieren, wir können uns keine Fehler erlauben.“

Dabei wird eines total vergessen: wir haben nicht alles unter Kontrolle – und in einer Cloud-Welt noch viel weniger als früher. Und selbst wenn wir es unter Kontrolle hätten: Fehler passieren. Jemand ist auf dem falschen Server angemeldet und fährt ihn herunter, eine Sicherung im Rechenzentrum brennt durch, der inzwischen sprichwörtliche Bagger trennt das Daten- oder Stromkabel. Es ist eine Tatsache, dass niemand vollständig ausschließen kann, dass ein Fehler passiert. Soll man verzweifeln? Eher mal schauen, was man sonst machen kann. Zusammen mit der Cloud kam in der IT eine weitere (schon alte) Kennzahl mehr ins Zentrum: MTTR („Mean Time To Repair“, auf Deutsch: „durchschnittlicher Fehlerbehebungszeitraum“). Man akzeptiert also, dass Fehler und Störungen auftreten werden. Wichtig ist, die Technik und Organisation so aufzubauen, dass sie Fehler schnell korrigiert und damit die Störungen beheben kann. Je kleiner diese Zahl ist, desto besser ist die Organisation. Da man Störungen niemals ausschließen kann, muss man mit ihnen leben und sie schnell ausschalten. Wer darin so gut ist, greift sogar zu Methoden wie Chaos-Engineering oder Monkey-Testing. Dabei wird in der Produktion wild von einem unbeteiligten Techniker irgendeine Technikkomponente (oder mehrere) deaktiviert oder gestört und damit das System für die „natürlich“ auftretenden Fehler optimiert – denn ohne diese Fehler weiß man nicht, worauf man sich vorbereiten muss.

Wenn wir aus der IT ausbrechen und uns in die Firmenorganisation begeben, wäre das so als würde der Chef einfach mal ins Büro einer wichtigen Mitarbeiterin gehen und sie für 4 Wochen in den Urlaub schicken. Am besten die Projektleiterin eines Projektes, dass in 3 Wochen geliefert werden muss. Ein Unternehmen, dass damit umgehen kann, wird auch den Autounfall einer Schlüsselperson überstehen.

Viele belassen es dann dabei. Aber damit ist nur der halbe Weg beschritten. Hier wird nur mit Fehlern umgegangen. Aber wenn man es weiterbetrachtet, sollte man hier nicht stehen bleiben, sondern die Organisation so gestalten, dass sie mit dem Treibsand von oben umgehen können. Damit kann man meist unerkannte Potentiale heben. Denn der Treibsand fordert Vernetzung. Konnte auf dem Stabilen Grund jeder vor sich hinarbeiten und man kam dann doch am Ziel an, versinkt man im Treibsand, wenn man sich kein Netz geschaffen hat. Dieses Netz hilft einem, nicht im Treibsand zu versinken. Je mehr „Seilschaften“ in verschiedenste Bereiche einer Organisation man sich geschaffen hat, desto sicherer ist man, nicht im Sand zu versinken. Was früher einen faden Beigeschmack hatte und nach Vetternwirtschaft klang, ist heute notwendig und dient der Organisation. Jeder muss auf Informationen reagieren und immer mitdenken, sonst bemerkt man nicht einmal, dass die Organisation schon fast im Sand versunken ist. Aber wenn jeder wie eine Spinne im Netz sitzt und das Zittern spürt, kann man reagieren und schnell genug die Kollegen aus dem Sand ziehen, bevor alle feststecken.

Aber bevor ich jetzt zu weit abdrifte, belasse ich es heute dabei. Der nächste Gedankensplitter kommt bestimmt …