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?


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


Der inhärente Konflikt „der IT“

18. Januar 2008

Ich habe mich kürzlich in einem XING-Forum in eine Diskussion rund um „Beyond Budgeting“ und IT-Abteilungen eingeklingt. Die Diskussion drehte sich um die Frage nach welchen „Nicht-Budget“-Zielen „die IT“ (im Sinne der Selbststeuerung) geführt werden könnte.

Für mich war das der Anlaß auf einen inhärenten Zielkonflikt hinzuweisen, welcher der IT innewohnt und den man bei der Suche nach Zielen bzw. der IT-Organisationsentwicklung generell nicht übersehen darf.

Der Konflikt bildet sich zwischen in dem Spannungsfeld von „Struktur“ und „Veränderung„.

Der erste Pol bildet die existierende IT mit ihrer existierenden Funktionalität ab, sowie der aktuellen Bedeutung „der IT“ im Unternehmen. Etwas sehr kurz gegriffen könnte man auch „Betrieb“ oder „Operations“ dazu sagen. Ich sehe es allerdings auch in einem weiteren, philosophischen Sinne: die Mitarbeiter und entsprechende Organisations-Substrukturen, welche in dieser Struktur arbeiten, sind tendenziell konservativ. Sie möchten den gegebenen Zustand bewahren und funktionsfähig halten – was ja auch sinnvoll ist. Es heisst nicht umsonst: never change a running system! Aber auch die aktuelle politische Lage, die gegenwärtige Macht/Verantwortung oder Nicht-Macht/Nicht-Verantwortung der IT-Abteilung zählt zum „Strukturpol“.

Die existierende IT bildet zum Teil oder fast ganz (je nach Konzerngröße) das Nervennetzwerk des Unternehmens ab. Woher stammen denn die Kennzahlen, mit denen das Management steuert? Welche Information wird nicht über eMail gesammelt bzw. weitergeleitet? Wer arbeitet nur mit Telefon und Meetings? Dieses Nervennetzwerk ist so bedeutsam und sensibel gegen Störungen, daß es massive Impulse gibt, Veränderungen daran zu verhindern – sowohl ausserhalb der IT Abteilung, aber auch recht massiv innerhalb der IT-Abteilung. Das ist angesichts der direkten und sehr unangenehmen, ggf. heftigst emotionalen Reaktionen der Nicht-IT-Mitarbeiter im Falle eines Systemausfalls oder bei Datenverlusten sicherlich auch verständlich.

Aber auch auf der politischen Ebene sind die strukturerhaltenden Kräfte vorhanden. Sobald „die IT“ mit im Boot ist und Geschäftsprozesse mit Hilfe von IT-Systemen digitalisiert werden, verliert der entsprechende Fachbereich an Macht und Flexibilität. Organisationsanpassungen, Geschäftsprozessanpassungen müssen dann mit der IT-Abteilung gemeinsam realisiert werden. Je nach aktueller Lage kann dies auf beiden Seiten sowohl begrüßt als auch abgelehnt werden:

  • vielleicht will die IT-Abteilung nicht noch zusätzliche Aufgaben und Arbeitsfelder haben,
  • vielleicht will die Fachabteilung eigentlich nicht abhängig werden von der Anpassungsgeschwindigkeit der IT-Abteilung,
  • vielleicht will aber auch die Fachabteilung das Thema loswerden und freut sich insgeheim darüber die dem Thema inheränte Problematik auf die IT-Abteilung abzuschieben…

Der zweite Pol des Spannungsfelds ist die Notwendigkeit sich mit der Veränderung der existierenden Strukturen beschäftigen zu müssen bzw. zu wollen. Funktionale Erweiterungen, Steigerungen der Komplexität (Differenzierung) sowie Verringerungen der Komplexität (Standardisierung) zählen dazu. Die Zielsetzungen der Veränderer sind hier ganz anders und reichen von „neueste Technologie einsetzen“ über „Gesamtsystemstabilität erhalten“ bis hin zu „Effizienz der Veränderung“.

Die Kräfte und Ziele beider Pole kollidieren innerhalb „der IT.

Ein einfaches Beispiel zu Datenstrukturen: man kann eine Adresse in verschiedenen Formen speichern. Die eine Form ist einfach und statisch: die Felder werden benannt, liegen in einer explizit dafür definierten Tabelle und bekommen eine feste Länge und eine klare Typenbezeichnung. Die zweite Form ist generisch: die Felder werden flexibel definiert, die Typen und Längendefinitionen der Adressstruktur werden durch die Programmierung nach Belieben definiert und angepasst. Die Daten liegen in einem zentralen Topf der für verschiedene Datenbereiche zuständig ist.

Die Bewahrer der Strukturen bevorzugen die erste Variante: sie ist statisch, klar definiert, es ist per Definition unmöglich das „fremde“ bzw. falsche Daten in der Tabelle gespeichert werden, die Datenbank selbst verhindert durch die vordefinierten Typen und Längen das es zu Datenschrott kommt.

Die Struktur-Veränderer bevorzugen im Zweifelsfall die zweite Variante, weil sie das Gefühl (oder das Wissen) haben, daß sich die Definition einer Adresse morgen schnell ändern kann. Hier werden quasi Regeln definiert welche beschreiben wie eine Adresse aussieht, und die Software folgt dann diesen Regeln. Muß die Adressdefinition geändert werden, dann ändert man ein paar Regeln und schon funktioniert die neue Version der Software. Definiert man die Regeln falsch, oder gibt es bei der Regelausführung Fehler dann kommt es (ggf. unbemerkt) zu Datenschrott, der erst in der Produktion bemerkt wird. Je generischer diese Regeln sind umso wahrscheinlicher ist dieser Fall, da die mögliche Komplexität exponentiell steigt und bald nicht mehr alle möglichn Fehlerfälle getestet werden.

Bei statischen Strukturen steigt der Aufwand der Anpassung, bei generischen Strukturen sinkt der Anpassungsaufwand. Ein weiterer Aspekt ist auch, daß die Softwarequalität leidet wenn man statische Strukturen zu oft anpasst. Wenn ein Programm per se entsprechend der Veränderungen generisch strukturiert ist, bleibt die Softwarequalität tendenziell stabil(er).

Diese beiden Pole prallen bei vielen kleinen wie großen Designentscheidungen aufeinander. Letztlich werden Annahmen über die Zukunft benötigt: wie wahrscheinlich ist es das sich diese Struktur, die Funktion, diese Datentonne, diese Anforderung nochmal ändert? Und wenn sie sich ändert, in welche Richtung geht die Änderung? Und wie häufig könnte sie sich danach nochmal ändern?

Man könnte nun sagen „nungut, das ist das Problem der IT, wenn kümmerts, die werden schon wissen was sie tun“. Weit gefehlt. Dieser Konflikt wird auch von außen in die IT hinein gespiegelt, denn für das restliche Unternehmen hat die IT ebenfalls zwei übergeordnete, konfliktträchtige Ziele bzw. Funktionen: beste Stabilität und optimiale Veränderung zugleich.

Beides zu erfüllen ist essentiell für den Unternehmenserfolg – das eine sichert das Tagesgeschäft, das andere den zukünftigen Unternehmenserfolg (unter der Prämisse das strategische Veränderungen am Markt auch wesentliche Anpassungen der Unternehmens-IT zur Folge haben).

Letztlich spiegelt sich in der IT das grundsätzliche Spannungsfeld des Unternehmens zwischen Effizienz und Anpassung.

Oft ist die IT-Abteilung aber nicht in der Lage eben jenen grundsätzlichen Konflikt zu erkennen und – sofern es sich eigentlich um die Frage der Unternehmensstrategie handelt – auf jene Ebene zurück zu transportieren, auf die dieser Konflikt eigentlich geklärt werden muss: der Unternehmensleitung.

Andrew Smart