Tunnelblick

24. Januar 2009

Mir ist vorhin beim Aufräumen eine alte Ausgabe von Brand Eins ( 03 / 2008 ) in die Hände gefallen: „Leben in Echtzeit“. Das war eine der Ausgaben, die mich als Multitasker natürlich schon damals sehr interessiert hat. Ich bin aber wohl nicht durch alle Artikel gekommen – „Augenblicke der Freiheit“ (S.117) hatte ich nicht mehr in Erinnerung.

Es geht in diesem Artikel um die Frage wann es richtig oder falsch ist, zu zögern – oder rein intuitiv zu entscheiden. Vor allem in Krisensituationen und in komplexen Zusammenhängen.

Ein Absatz hat mich dann nochmals gepackt. Es geht dabei um den Tunnelblick, und ein Experte für Unfallforschung wird zitiert: „… Und je komplexer eine Handlung, desto größer die Wahrscheinlichkeit, sich auf das falsche Thema zu fokussieren.“ (S. 121)

Hier machte dann mein Hirn einen assoziativen Rittberger – kommt schonmal vor – und ich habe diesen Gedanken auf ein Unternehmen als Ganzen angewendet. Und ich habe meine persönlichen Erfahrungen Revue passieren lassen, wie Projekte oder ganze IT-Abteilungen auf von aussen induzierten Stress reagiert haben – z.B. der Entscheidung des obersten Managements, die IT zu großen Teilen auszulagern.

Da hab ich mir gedacht: auch soziale Organisationen – Firmen, Abteilungen, Projekte, Teams – können als Ganzes einen Tunnelblick entwickeln. Und je komplexer die vom Stress betroffenen Strukturen sind, umso wahrscheinlicher ist es, dass man in die falsche Richtung läuft. Wichtige Dinge übersieht. Vernunft in die Ablage packt und im Tunnel dem hellen Licht entgegenläuft, egal obs nun ein entgegenkommender Zug ist oder tatsächlich der Ausgang.

Ich finde hier ein paar spannende gedankliche Ansätze… wie kann man erkennen, dass eine Organisation im Modus „Tunnelblick“ ist – und wie kann man der Organisation diese Erkenntnis erkenntlich machen? … welche Instanzen braucht es in einer Organisation um Tunnelblick zu verhindern – oder zumindest in die richtige Richtung zu lenken? Inwieweit reflektiert sich dieser gedankliche Ansatz im digitalen Teil des Gesamtsystems Unternehmen? Gibt es einen „IT-Tunnelblick“… Was passiert wenn der Umwelt-Stress beim menschlich/organisatorischen Teil des Unternehmens einen Tunnelblick verursacht – und im „Subsystem“ der IT der gleiche Stress einen anderen?

Weiter unten im Artikel wird das Phänomen „Tunnelblick“ auch auf andere Verursacher bezogen – „… könnten emotionale Konflikte, Überforderung, und zu große Komplexität auslösen.“

Eine gewagte Analogie: eine überkomplexe IT- und Anwendungslandschaft versetzt das Unternehmen (wahlweise die IT-Abteilung) in einen permanenten Tunnelblick!

Obwohl… das könnte ich mit persönlichen Erfahrungen durchaus korrellieren…

Na das gibt noch so einiges an gedanklichem Futter für die nächsten Blog-Einträge und Forschungsabende…


Der Workflow führt die Führung vor…

17. Januar 2009

Im Rahmen meiner Architekturtätigkeit beschäftige ich mich intensiver mit „BPM“ – Business Process Management. Die technischen Details erspare ich euch jetzt mal… Im Kern geht es darum das sämtliche Aktivitäten im Unternehmen über Workflow-Systeme abgebildet werden.

Als die Tage vor dem obligatorischen Espresso saß und über die (systemische) Wirkung von BPM sinnierte ist mir ein interessanter Gedanke gekommen: mal angenommen alle wesentlichen Aktivitäten der Firma, der Abteilungen, der Gruppen und Teams sind über ein BPM-System/Workflows realisiert: wer hat dann eigentlich die Führung? Ich meine „Führung“ im Sinne von „ich als Leiter dieses Team entscheide darüber wer im Prinzip wann was macht. Ich delegiere, ich steuere, ich behandle Eskalationen“. Damit inbegriffen: die innere Sicht des Managers, sein Selbstverständis von sich und dem Begriff „Führung“.

All das, was man als Chef früher tun musste, werden bei einer vollwertigen Workflow-Unterstützung durch das BPM gesteuert. Das BPM entscheidet wann ein Vorgang eskaliert wird. Das BPM entscheidet wer wann welche Tätigkeiten zugeordnet bekommt. Nur das BPM hat einen vollständigen Überblick über alle Aktivitäten – die Mitarbeiter reden nicht mehr mit ihrem Chef darüber den Vorgang X erstmal beseite zu legen um auf ein Feedback zu warten. Das wird direkt im BPM – System hinterlegt.

Der Chef hat natürlich einen eigenen Zugang zum BPM-System – er kann (oder darf?) Parameter einstellen, die zur Steuerung der Mitarbeiter dienen, er kann in jeden Vorgang Einsicht nehmen, Statistiken abrufen, Vorgänge zuweisen und er muss natürlich auch die Vorgänge abarbeiten, die die Mitarbeiter eskalieren lassen. Klingt fast wie ein einfacher Mitarbeiter mit einer speziellen Rolle und daraus abgeleiteten Rechten…  Und für das BPM-System ist das genau so…

Der (systemische) Punkt für mich ist: wieviel „Chef“ bleibt vom Chef übrig? Ist die Einführung einer übergeordneten, steuernden Instanz nicht auch implizit eine Degradierung von der herkömmlichen Rolle eines „Chefs“?

Aus der Perspektive der IT-Abteilung ist dieser Gesichtspunkt ggf. relevant: je nach Unternehmenskultur und dem damit verbundenen Führungsverständnis des Managements kann die Einführung eines BPM-Systems als Angriff auf die Selbstbehauptung des Managements sein. Es kann gewisse Widerstände im Unternehmen gegen Workflows & Co erklären, oder auch erklären warum die erwarteten Benefits eine Workflow-Systems sich nicht heben lassen… weil die Mitarbeiter (oder das Management) das System aufgezwungen bekommen und es nun – ggf. unterbewusst – torpedieren…

Es gibt noch einen zweiten Aspekt: wer beherrscht das BPM-System im Sinne von Anpassungen an geänderte Rahmenbedingungen? Die IT – wer sonst? Sollte sich ein Abteilungsleiter dazu entscheiden seine Mitarbeiter-/Teamorganisation anders aufzusetzen, und er braucht dafür neue Regeln (weil sonst das BPM nicht entsprechend angepasst werden kann) dann muss er zur IT-Abteilung gehen.

Ein Gang nach Canossa weil man vergessen hat im letzten Projekt die anstehende Reorganisation mit einzuplanen?

Früher hat man die IT nur benötigt wenns um Funktionalitäten geht. Heute muss man selbst dann die IT belästigen (oder bitten) wenn man die Art und Weise, wie die Mannschaften aufgestellten werden, verändern will. Ist das nicht das letzte große freie Betätigungsfeld des Managements, dort wo es sich „beweisen“ kann: Teams und Gruppen optimal an geänderte Geschäftsbedingungen anzupassen? Ist es nicht ein massiver Eingriff ins Selbstverständnis eines echten Managers wenn er selbst das nicht mehr ohne IT-Anpassungen vornehmen kann?

Wer führt eigentlich – das Workflowsystem oder das Management?


Risiko und Wahrnehmung III (Die geprägten Schatten)

14. Januar 2009

Im letzten Blogeintrag habe ich die Risikostruktur als Ausdruck der Schattenseite einer Organisation beschrieben, vergleichbar mit den Untiefen des Unterbewusstseins einer Person.

Ein – auf den ersten Blick – gewagter Vergleich, insbesondere wenn man die IT-Brille aufsetzt und sich vorstellt, dass die Erzeugung von Software irgendwas mit Unterbewusstsein zu tun haben soll… Aber wer von uns IT’lern kennt das nicht: man kommt in ein Projekt, und man bekommt schon über die Diskussionskultur (was wird wirklich diskutiert, welche Themen sind nicht diskussionsfähig, was wird ignoriert) mit „wie der Hase läuft“. Und ob das Projekt eine Chance auf Erfolg hat. Und dieser „Projektstil“ bleibt meistens erhalten, auch wenn Leute kommen oder gehen. Es ist wie eine Art Mantra – „so verhalten wir uns, und nicht anders“ – dass von der Organisation als Ganzes geprägt und aufrecht erhalten wird.

Dieses Verhalten hat natürlich überhaupt nichts mit Gruppendynamik oder Organisationspsychologie zu tun 😉

So, zurück zum Thema: Risiken sind Ausdruck der Schatten einer Organisation…

Einer meiner ersten Gedanken nach dieser Assoziation war: „hoho, und IT-Projekte giessen diese Schatten in digitale Form…“. Diesem Gedanken will ich heute nachgehen…

Ist das so?

Der übliche Verlauf ist: die Fachseite möchte ein System anpassen oder ein neues System gebaut bekommen. Die IT-Seite wird involviert, es werden Anforderungen formuliert und in Diskussion verfeinert. Es werden verschiedene Aufwandsschätzungen durchgeführt und Budgets organisiert. Es werden technische Konzepte geschrieben und in Software umgesetzt. Die Qualitätssicherung startet (Tests werden formuliert und durchgeführt), es wird eine Produktionsumgebung geschaffen, auf die die Endanwender zugreifen werden. Letztlich wird die Software final abgenommen und in Produktion genommen.

Soweit, so einfach. Nur funktioniert das leider in der Praxis nicht ganz so einfach. Die Anforderungen ändern sich, unerwartete technische Probleme verursachen Mehraufwand, die Qualitätssicherung findet immer wieder neue Fehler in der Software, der Produktionstermin wird immer wieder verschoben…

Wenn ich so darüber nachdenke sehe ich tatsächlich zwei Risikostrukturen: die Risikostruktur der Fachseite, und die Risikostruktur des IT-Projekts.

Die Risikostruktur der Fachseite umfasst alle fachlichen Risiken – das sind alle fachlichen „Risiken“, die in der einen oder anderen Form in der zu erstellenden Software zu berücksichtigen sind. Anders formuliert: es sind mindestens alle Anforderungen, die die Fachseite vergessen hat zu formulieren, plus sich aus dem Business heraus ergebende Risiken (Geschäftspolitik wird kurzfristig geändert).

Die Fachseite hat somit eine eigene, für sie spezifische „Schattenseite“. Und alles was die Fachseite vergisst, verdrängt, nicht beachtet wird über die (nicht) formulierten Anforderungen auch schön brav von der IT in digitales Material „gegossen“. Eine fertige Software hat also zumindesten zu einem gewissen Grad einen „Imprint“ des Unterbewusstseins der Fachseite…

Die IT-Risikostruktur und die Schatten werden zum gewissen Teil ebenfalls in digitales Material verewigt – über nicht richtig oder vollständig realisierte Funktionalitäten, technisch wackelige Lösungen oder ignorierte Tests.

Was mir gerade in diesem Moment auffällt – und jetzt spreche ich als Entwickler: als (motivierter) Entwickler hat man fast immer zwangsläufig ein schlechtes Gewissen. Man hätte hier und dort immer noch besser sein können, die Funktion X ist nicht generisch genug, die Tabelle Y ist eigentlich eine Krücke, und die Fehlerbehandlung an Stelle Z wird in die Hose gehen weil sie nicht ganz zum Rest passt.

Anders ausgedrückt: jede Software digitalisiert das schlechte Gewissen der beteiligten Entwickler – für die „Ewigkeit“. *ein tragisch-komischer Gedanke*. Ich stelle mir vor wie die Softwarepakete dieser Welt, in den Banken, Versicherungen, Telco-Unternehmen alle im millisekundentakt im schlechten Gewissen schwingen… „hätten wir doch… wir sollten das noch ändern… keine Zeit… die Lösung ist aber gar nicht gut… wenn das die Fachseite wüsste… wir haben gesagt das das nicht funktioniert…“

Ja, auch die Schatten der (Projekt)Organisation werden im Endergebnis verewigt. Sie vermischen sich mit den Schatten der Fachseite, und das Endergebnis ist ein Stück Software: ein digitales Mahnmal von Licht („Hoffnung“: unsere IT baut uns eine neue Software die unser Leben leichter/besser macht) und Schatten (wieso haben die/wir nicht daran gedacht das…)…

*schmunzel*


Risiko und Wahrnehmung II (Die Schattenseite)

12. Januar 2009

Im vorangegangenen Blogeintrag habe ich über die Wahrnehmung von Risiken im Zusammenspiel mit dem Risikomanagement philosophiert. Das will ich jetzt fortsetzen…

Mich beschäftigt weiterhin der Aspekt der (Risiko-)Wahrnehmung im Zusammenspiel mit dem Verhalten der Organisation.

Zunächst einmal gilt es festzuhalten das es zwei Arten von Risiken gibt: diejenigen Risiken welche wahrgenommen werden, und diejenigen die verdrängt bzw. ignoriert werden.

Nebengedanke: nach Murphys Gesetz sind diejenigen Risiken, die nicht wahrgenommen werden, diejenigen die einem im unpassensten Moment in den „A…“ beissen. Wenn man also als Projektleiter Risikomanagement ernst meint, dann sollte man mit Sorgenfalten auf die leeren Stellen auf der Risikoliste starren… 😉

Spannend ist es mich Sicherheit heraus zu finden, warum eine Organisation mal die eine Risikoklasse, mal die andere Risikoklasse ignoriert. Diese Auswahl dürfte eine Mischung von schlechten Erfahrungen (das passiert uns nicht wieder), guten Erfahrungen (unsere Kunden könnten uns zwar hier ärgern, das passiert aber aus guten Gründen nie) sowie dem grundsätzlichen Unternehmenskontext (Datenschutz hat bei uns höchste Priorität) sein.

Der Unternehmenskontext wirkt hier umso stärker, umso enger die Risiken mit den Zielvereinbarungen der jeweiligen Management-Ebene verknüpft sind.

Das Risikomanagement als einen Einstieg in eine systemische Analyse zu verwenden dürfte einiges an Erkenntnis über die IT-Organisation als Ganzes liefern, über dem Umgang mit Erfolg und Misserfolg etc.

Der Umgang mit Risiken zeigt in meinen Augen den Reifegrad der Organisation. Risiken sind schlecht, „böse“, unangenehm, lästig. Für das Nennen und Verwalten von Risiken gibt es keine Bonuspunkte – im Gegenteil. Der Projektleiter wird sich „bedanken“ das er ein neues Problem benannt bekommt, denn das Verhindern von Risiken oder die Minimierung von Schäden kostet Zeit, Nerven, Aufwand, bringt einem in der Sache oberflächlich gesehen nicht voran.

Wenn ich so darüber nachdenke: Risiken kann man sich als die „Schattenseite“ der (Projekt)Organisation vorstellen, wobei wahrgenommene Risiken die bewusst eingestandenen Schwächen, und die nicht wahrgenommenen Risiken die dunklen tiefen Schatten des Projekts darstellen. Ähnlich wie in der Psyche eines Menschen: die dunklen Stellen, das Verdrängte, das Vergessene, das Übersehene. In den IT-Sprachgebrauch übersetzt: es sind die nur mit Annahmen „gelösten“ Probleme, die wegdefinierten Anforderungen, die ignorierten Erwartungshaltungen, die wegdiskutierten technischen Risiken, die vergessenen ToDos, die schlecht umgesetzten Softwareroutinen…

Wobei die sich in der Wahrnehmung befindlichen Probleme und Risiken schon aus Selbstschutz berücksichtigt werden. Naja: auch nicht immer – man hat im Projektverlauf nicht immer die Kapazität/Resourcen – noch nicht mal für die benannten Risiken…

Für mich ist eine Organisation „erwachsen“, wenn sie verantwortlich mit Risiken umgehen kann. Das bedeutet nicht, dass alle Risiken immer benannt/behandelt werden müssen – es bedeutet, dass die Organisation sich über den Umgang mit Risiken bewusst ist, und bewusst handelt. Risikoklassen zu ignorieren kann je nach Kontext schlichtweg sinnvoll sein – wenn es bewusst geschieht.

Genug philosophiert für heute… da ist aber mit Sicherheit noch mehr…


Risiko und Wahrnehmung I (Die blinden Flecken)

10. Januar 2009

Beim Abarbeiten meiner alten Arbeitsmails aus den vergangenen Jahren ist mir eine meiner „typischen“ Mails in die Hände gefallen. Es ging um die Vorbereitung eines Angebotsdokuments, und ich habe auf gewisse kommerzielle Risiken hingewiesen die sich aus Formulierungen ergeben könnten – Formulierungen, die nicht in meinem Arbeitsgebiet lagen.

Ich kann mich noch gut erinnern wie meine „Warnung das ist ein Risiko“-Mails etwas verwundert zur Kenntnis genommen wurde. Ich war der einzige der sich über derartige Risiken Gedanken gemacht hat, was wohl vor allem auch daran lag das ich ein „neuer Externer“ war. Als ein solcher war ich noch nicht an die organisationsüblichen „Filter“ angepasst.

Die Projektleitung hat meiner Risiko-Einschätzung nicht widersprochen – das Risiko war echt. Es war einfach nur so, dass derartige Risiken einfach nicht beachtet wurden – es war ein bisschen so „ich sehe das Risiko nicht, also existiert es auch nicht“.

Das Paradoxe daran war: innerhalb dieses Projekts gab es offiziell einen Risikomanagement-Prozess. Man hat mein Risiko aufgenommen, aber dann im Rahmen des Prozesses „verhungern“ lassen. Keine Absicherungmaßnahmen, keine Risikominderungsmaßnahmen… Es war als hätte man die fachliche Richtigkeit (und das damit verbundene kommerzielle Risiko) zur Kenntnis genommen, aber dennoch… es war als hätte sich die (soziale) Organisation dazu entschieden derartige Risiken einfach zu ignorieren.

In diesem Verhalten sind – systemisch gesehen – einige Erkenntnisperlen versteckt.

Zunächst einmal kann man das Verhalten des Systems als Schutz verstehen. Die Projektorganisation hat sich (unbewusst) entschlossen eine bestimmte Risikoklasse zu ignorieren – vielleicht weil man nicht wusste, wie man derartige Risiken richtig handelt, vielleicht weil man mit der Nennung derartiger Risiken ggf. politische Konflikte versachen könnte, vielleicht weil man einfach nicht genügen Kapazität hat sich „auch noch um sowas kümmern zu können“.

Das war mein Hinweis auf das entdeckte Risiko natürlich auch ein Hinweis darauf, dass eine komplette Klasse von Risiken nicht beachtet werden. Die Organisation hat an dieser Stelle nur die Wahl die Tore zu öffnen und alle relevanten Risiken zu benennen (mit unabsehbaren Folgen), oder mein Risiko zu einem „Einzelgänger“ zu machen. Sprich: da man’s nicht verschweigen kann, lässt man den Einzelgänger „verhungern“ in dem sich keiner drum kümmert. Für mich hatte das – zum Glück – keine negativen Folgen, d.h. ich wurde für diesen „Frevel“ weder auf der sozialen Ebene noch formal „bestraft“.

Die (Projekt-)Organisation hat damit aber eine Art Wahrnehmungslücke „produziert“, einen blinden Fleck. Da derartige – oder ähnlich wahrgenommene – Risiken fast schon reflexartig ignoriert werden, tut sich im Risikomanagement natürlich ein grosses Loch auf.

Mein „Intervention“ – die Nennung eines derartigen Risiko – und der Umgang damit (Ignorieren) hat diesen blinden Fleck noch verstärkt. Einem Beobachter im Projekt wird damit deutlich: aha, derartige Risiken werden höchstens in die Liste aufgenommen, aber sonst kümmert sich keiner. Der Aufwand lohnt also nicht… Was wie eine Belohnung für die Handlungsoption „ignorieren“ wirkt.

Wenn man etwas über derartige blinden Flecken eines Projekts wissen will, so müsste man nur folgendes machen: eine Liste aller potentiell möglichen Risikoklassen erstellen (= die üblichen Verdächtigen), und mit der Liste der realen Risiken im Risikomanagement abgleichen. Man kann statistisch davon ausgehen, dass es von jeder Risikoklasse wenigstens ein paar (ggf. auch nur kleine) Risiken gibt. Fehlt im Risikomanagement eine Risikoklasse komplett, dann hat man einen guten Anhaltspunkt für einen blinden Fleck in der Organisationswahrnehmung.

Als Sicht des Risikomanagements müsste der erste Eintrag immer lauten: „Das Risiko, dass Risiken übersehen werden“ 🙂

Im nächsten Blog-Eintrag werde ich das Thema nochmal aufgreifen – da ist noch mehr zu finden…


Gefühle, Motivation und IT

8. Juni 2008

Heute morgen hatte mich meine IT mal wieder gefühlstechnisch im Griff. Ich wollte eine Datei mit OpenOffice öffnen, und dabei dann das Verzeichnis wechseln.

Durch irgendeinen Konfigurationsfehler in meinem Windows-LAN kommt es aber dabei zu unerklärlichen Wartezeiten (durchsucht er das WWW? Fragt er Google ob ich auf meine Dateien zugreifen darf?), d.h. die entsprechende Combobox braucht mehr als 30s um sich zu öffnen.

Je nach Tageslaune kann mich das zur Weißglut treiben. Haaaarg, mach endlich den Verzeichnisbaum auf Du dämliche Kiste. Ich hatte auch schonmal einen 3/4 Tag in die Fehleranalyse gesteckt ohne wirklich weiter zu kommen. Hat was mit der lokalen Vernetzung, Windows-Netzwerk und was-weiß-ich zu tun. Und im Sinne von Aufwand und Ertrag macht’s keinen Sinn sich einen Techniker kommen zu lassen oder noch 1 Woche Arbeitszeit zu investieren.

Ich ärgere mich nur. Und ich nehm’s persönlich. Weil, wenn ich grad im Schwung bin, dann bremst mich sowas aus, frustriert mich, nimmt mir die Motivation.

Natürlich passiert es uns allen, die wir täglich mit der kleinen und großen IT zu tun haben. Wir werden gebremst, frustiert, demotiviert. Sei’s das das Netzwerk so langsam ist, sei’s das die Workflow-Lösung bestimmte Ausnahmen nicht auf die Reihe kriegt.

Mal angenommen der Chef sagt: lass uns ein Movitationsseminar machen. Alle fahren übers Wochenende – von mir aus Outdoor in der Eiffel – zum Motivieren, haben Spaß, lernen sich kennen, machen Teamwork, und kommen hochmotiviert am Montag wieder auf die Arbeit.

Und laufen gegen die Frustrationswand „IT“. Nicht genug Platz auf den Serververzeichnissen, das Intranet ist elendig langsam, die Software teils fehlerhaft.

Erste Frage: Wie lange wird das Movitationstraining wohl wirken?

Zweite Frage: Steigert oder senkt ein vorheriges Motivationstraining den Frust auf die IT?

Merke: will man motivieren, sollte man auch die Arbeitsumgebung betrachten, und insbesondere, falls die IT wesentlicher Bestandteil der Umgebung ist, natürlich auch den PC mit der Software. Schlechte Arbeitsumgebungen können jede Motivationsarbeit zunichte machen.

Merke: die IT hat als Dienstleister mittelfristig starken Einfluß auf die Motivation der IT-abhängigen Mitarbeiter. Die mögliche Wirkung im negativen Spektrum ist dabei höher als im positiven Spektrum.

Man denke einfach nur an den – selbst schon mehrmals erlebten Fall – daran, daß der eMail-Server aus irgendeinem Grund in die Knie geht. Da kocht es ganz schnell in zig Abteilungen, da rufen Abteilungsleiter beim Chef an etc. etc…

Wieviel ist Motivation wert? Wieviel ist das Gefühl flott, schnell und zügig arbeiten zu können, wert? Ich glaube ich muss mit mir als meinem eigenen IT-Dienstleister doch noch einmal ein Gespräch führen…

Alleine dieser Aspekt hat noch eine Reihe weiterer, systemischer Bezüge und Wirkungen. Da gehts dann auch darum das die IT zur Projektionsfläche für grundsätzliche Frustrationen wird. Das die IT-Abteilung den Frust natürlich auf ihre Weise abwehrt und spiegelt. Und natürlich auch innerhalb der IT-Abteilung wirkt es: die Angst vorm IT-GAU führt verständlicherweise zu sehr konservativen Geisteshaltungen (never change a running system). Da wird vielleicht an Technologien nur deswegen festgehalten, um dem massiven Frust und den massiven Vorwürfen bei Technologie-Umstellungen aus dem Weg zu gehen. Etc. Etc.

Aber dazu ein anderes Mal, ich hab zu tun, inzwischen hat sich meine Combobox endlich geöffnet, heissa ich kann weiterarbeiten…

Andrew Smart


Postheroisches Management & IT

22. Januar 2008

Über den Blog von Fritz B. Simon bin ich auf die Revue für postheroisches Management aufmerksam geworden. Das Buch von Dirk Baeker zu diesem Thema fand ich schon spannend – jetzt gibt’s dazu auch noch eine neue Revue.

Als Systemiker unterschreibe ich die Idee des postheroischen Managements sofort. Wenngleich ich selbst mit genau dem umgekehrten Vorbild aufgewachsen bin – ich hatte schon immer ein Faible für Heldenromane und Heldenfiguren, und habe mich in Projekten dementsprechend oft heldenhaft-heroisch gegen die scheinbar unüberwindliche Arbeitswand geworfen – so wie es quasi „Standard“ ist in IT-Projekten. Ich glaube wenigen Nicht-IT’lern ist wirklich bewusst wieviel Blut, Schweiss, Koffein-Überdosen und Schlafentzug in den meisten Softwareprodukten steckt. Ich kann die Anzahl durchgemachter Projekt-Nächte jedenfalls nicht mehr zählen…

Das heldenhaft-heroische in der IT hat übrigens eine interessante Ambivalenz. Da sitzt die IT-Abteilung bis spät in die Puppen vor dem PC, lässt sich Nachts Pizza’s liefern, verzichtet auf Privatleben, programmiert sich die Finger wund – und keiner bekommts mit. Ich meine: wenn man sich schon opfert, dann sollte man das doch wenigstens halbwegs öffentlich tun, oder? Insbesondere sollten es diejenigen mitbekommen für die man sich opfert: die späteren Anwender, oder von mir aus das Management, oder gleich das ganze Unternehmen.

Da der IT’ler per se aber ein sehr schlechter Vermarkter ist, passiert das aber nicht. Man klopft sich gegenseitig müde auf die Schultern – die Welt, äh, nein das Unternehmen gerettet, der Chef ist vielleicht zufrieden, aber das wars schon an Lobeshymnen.

Kein Wunder das man sich ziemlich ärgert wenn die Fachabteilung dann an einzelnen Fehlern in der Software rummeckert… Wissen die denn nicht, wieviel Kraft das gekostet hat, bis zu diesem Punkt zu kommen? Na die sollen mich mal kennenlernen

Aber darüber wollte ich eigentlich gar nicht schreiben. Worüber ich schreiben wollte war, das der IT’ler in mir sich beim Lesen des Editorials der Revue mit interessanten Einwürfen zu Wort gemeldet hat.

Im postheroischen Management werden die Beobachter aus ihrer passiven Rolle befreit. Sie werden zu Akteuren. Jeder ihrer Arbeitsschritte ist eine Entscheidung.

Einwurf des IT’lers: im modernen, IT-workflowgestützten vernetzten Arbeiten bestimmt die Workflowsoftware den nächsten Schritt, den nächsten Kontakt. Wir degradieren die Mitarbeiter zu mit Rechten und Rollen versehenen Inboxen…

Uns interessieren Management, Organisation und Gesellschaft in ihrem unreduzierten Dreiklang. Wir halten den Manager für den Virtuosen dieses Dreiklangs und den Berater für denjenigen, der ihm dabei den Rücken frei hält.

Einwurf des IT’lers: Störgefühle. Manager müssen heute einen Vierklang beherrschen: Management, Organisation, Technologie und Gesellschaft. Man könnte die Technologie unter „Organisation“ unterordnen, aber das wäre zu kurz gegriffen. Die IT als Blackbox, als reines Hilfsmittel: diese Zeit ist längst vorbei.

Die Technologie ist längst ein eigenes Monster geworden dessen man Herr werden muss. Aus dem Bleistift wurde längst ein eigenständig handelnder Cyborg mit eigenen Entscheidungsregeln… Und manchmal ists der Cyborg der die Mitarbeiter steuert und nicht mehr der Manager…

Mal sehen was beim Lesen sonst noch an Impulsen so kommt…

Andrew Smart