Köln, ich komme :-)

So, das gröbste ist geschafft, ich bin sowohl privat als auch beruflich jetzt in Köln beheimatet.

Noch Stapeln sich die Kisten, und das übliche organisatorische Schaulaufen (Ummelden, Auto, Adressen etc.) steht noch an, aber ich bin soweit „up and running“.

Die Arbeit im Insitut wird sicherlich noch 1-2 Woche ruhen müssen, aber dann gehts mit neuer Kraft weiter.

Die neue Adresse: Arndtstr. 10, 50676 Köln

Andrew Smart

Komplexe und komplizierte Aufgaben

Ich habe mit wachsender Neugier das Buch „Denkwerkzeuge der Höchstleister“ gelesen. Ich finde die Thesen in diesem Buch sehr passend.

Den Abschnitt „Im Kontext hoher Dynamik ist Können wichtiger als Wissen“ treffen die Autoren die Unterscheidung zwischen Wissen und Können, und ordnen diese beiden Fähigkeiten jeweils den Problemklassen „Komplizierte Aufgaben“ und „Komplexe Aufgaben“ zu.

Mit Wissen kann man komplizierte Aufgaben lösen, aber nur mit Können kann man komplexe Aufgaben lösen. Die Autoren vergleichen das mit einer Fußballmannschaft. Die Logistik einer Fußballmannschaft ist kompliziert, aber mit genügend Wissen über die Zusammenhänge lösbar. Die Durchführung des Spiel selbst ist komplex (weil hochdynamisch) und mit theoretischem Wissen über das Fußballspiel eben nicht lösbar. Dafür muß man es können.

Diese Unterscheidung passt hervorragend in die IT. Es wimmelt nur so von komplizierten und komplexen Aufgaben, und manchmal ist der Erfolg dadurch determiniert zuerst – und vor allem – die richtige Einordnung zu finden. Können wir diese Aufgaben mit Knowhow lösen, oder bedarf es eines Könners?

Die IT ist per se sehr wissenslastig. Was ich mir schon alles an Bibliotheken, Betriebssystemen, Programmiersprachen, Datenbanken, Softwarepaketen und Entwicklungsumgebungen „reingezogen“ habe geht auf keine Kuhaut. In der IT zu arbeiten bedeutet lebenslanges, kontinuierliches Lernen.

Dadurch gilt in der IT oft die Ableitung: Wissen = Können. Oder anders ausgedrückt: ohne gründliches technisches Wissen kann auch ein Könner nicht wirklich gut arbeiten.

Das ist natürlich prinzipiell richtig, aber nur dann wenn es sich um ein komplizierte Aufgabe handelt. Bei den komplexen Aufgaben muß man schon genauer hinschauen. Sobald die Aufgabe z. B. sehr kommunikationslastig ist (Mensch-Mensch-Kommunikation um genau zu sein wird der Anteil des „Könnens“ viel stärker zum Erfolg beitragen als das Wissen.

Aber auch manche scheinbar wissenslastige Jobs sind im Kern komplex. Nehmen wir einmal das Thema „Datenbank-Tuning„. Ist das kompliziert oder komplex?

Erste Antwort eines Managers: ich will einen Spezialisten für die Datenbank X – und zwar für die Version 10.2.1 – weil nur er weiß die vielen verschiedenen Tuning-Optionen der Software. Doch nur das Wissen über die Konfigurationsoptionen macht keinen guten DB-Tuner. Das Zusammenspiel zwischen Hardware, Betriebssystem, Datenbank-Software und der Anwendungssoftware ist hochdynamisch und komplex. Man braucht einen Könner - und dabei ist die konkrete Version der Datenbank eher nebensächlich.

*grübel* Es wäre interessant mal eine Abbildung der komplexen wie komplizierten Arbeitsgebiete und Themen in der IT zu erstellen…

Die Idee mit Aufstellungen in der IT zu arbeiten ist übrigens der Versuch den komplexen Problemen beizukommen. Eben da wo das Wissen über Prozesse, Methoden und Technologien nicht mehr weiterhilft. Wenn es also nicht nützt 10 Büchern (Tom DeMarco: Bärentango, Der Termin, Der Mythos Mannmonat etc) über das IT-Management gelesen zu haben.

Andrew Smart

Gefühle, Motivation und IT

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

Entscheidungen und IT

Als ich die Tage mal wieder durch Dirk Baeker’s „Postheroisches Management“ geblättert habe, bin ich über die Ausführungen „Der Grundbegriff der Entscheidung“ gestolpert (S 101).

Im Kern: Entscheidungen in Organisationen werden auf Basis von Entscheidungsprämissen getroffen. Oder anders ausgedrückt: die eigentliche Entscheidung ergibt sich fast zwangsläufig aus den Prämissen.

Das kennen wir in der IT wenn es darum geht, eine Produktevaluation durchzuführen: schon mit Festlegung der Evaluationskriterien und der Gewichte wird das auszuwählende Produkt festgelegt. Je nach politischer Situation stellt der Evaluationsprozess somit eigentlich nur die formale Rechtfertigung derjenigen Entscheidung dar, die man vorher schon gerne gefällt hätte.

Aber darauf wollte ich gar nicht hinaus.

Für mich haben diese Entscheidungsprämissen eine zentrale Bedeutung wenn es darum geht die Wirkung von IT-Systemen auf Gesamtorganisationen richtig zu bewerten. Diese Entscheidungsprämissen fliessen auf allen Ebenen in die Gestaltung der IT-Systeme, da sie struktureller und impliziter Bestandteil des Anforderungskatalogs und damit der IT-Architektur werden.

Nehmen wir eine x-beliebige Abteilung. Der Abteilungsleiter ist macht- und kontrollfokussiert, und legt viel Wert darauf, daß seine Mitarbeiter nur jeweils das tun können, was sie explizit tun dürfen. Spezifiziert die Abteilung nun ein IT-System, so wird das Thema „Rechte“ deutliche Beachtung finden. Die Kern-Prämisse des Rechtesystems wird sein: es kann nur etwas getan werden wenn es explizit erlaubt ist. Die Gruppen- und Teamleiter werden als Folge einen organisatorischen Overhead hinsichtlich „wer darf was“ mitschleppen (oder das Rechtesystem unterlaufen in dem sie intern sehr viele Rechte freizügig vergeben).

Stellen wir uns mal vor der Abteilungsleiter wechselt. „Der neue“ setzt auf Integrität und Selbststeuerung, und möchte nur sichergestellt wissen, daß bestimmte Dinge wie z.B. Freigabe von großen Beträgen nur von explizit berechtigten Mitarbeitern durchgeführt werden.

Das passt nicht zum alten Rechtesystem. Die Regelmechanik kann „einfach“ nur explizite Erlaubnis – aber eben nicht explizite Verbote. Gehen wir mal davon aus das die IT’ler an dieser Stelle strikt nach Anforderung programmiert haben, und keinerlei Generik oder Voraussicht haben walten lassen. In einer solchen Situation kann man zwar die gewünschte Rechtestruktur über Positiv-Regeln zwar formulieren, aber nur sehr umständlich. Jeder Mitarbeiter bekommt dann alle Rechte auf alles – bis auf diejenigen Funktionen die nur einzelne durchführen dürfen. Worüber man natürlich gesondert Buch führen muss – die herausgestellten Mitarbeiter kann man nur angesichts der vielen Erlaubnisse nur schwer erkennen.

Was machen die Gruppen- und Teamleiter: die werden zum großen Teil aus Selbstschutz (Aufwandsvermeidung) den alten Stil „explizite Erlaubnis“ fortführen. Die Mitarbeiter bekommen an dieser Stelle eine doppelte Botschaft: der neue Chef sagt „Integrität und Vertrauen“, und in der täglichen Arbeit ändert sich nichts. „Für jeden Sch*** musste zum Teamleiter laufen um die Rechte zu bekommen…“

Die alte Entscheidungsprämisse „explizite Erlaubnis“ – das Vermächtnis des alten Chefs – wirkt wie ein dunkler Schatten in die Organisation hinein. Und der neue Abteilungsleiter wundert sich, daß seine Mitarbeiter nicht wirklich befreit loslegen. Die IT wundert sich, warum die Abteilung mit dem alten System plötzlich unzufrieden ist.

Das Schlimmste was jetzt passieren kann: das Rechtesystem wird über Änderungsaufträge nach und nach umgestrickt - man will ja nicht zuviel Geld ausgeben für etwas, was man schon bezahlt hat. Die Folge ist eine grausame Vermischung von impliziten und expliziten Erlaubnis- und Verbotsregeln, weil man nie richtig Geld ausgibt, um das alte System entweder komplett auszutauschen oder vernünftigt neu zu machen.

Das Rechtesystem wird letztlich ein Unrechtssystem, und die Formulierung der Regeln ein Mysterium. Was wiederum Lücken und Fehler provoziert – hoffentlich nicht mit der Folge krimineller Machenschaften.

Das Problem: die Fachabteilungen wissen selbst oft nicht, nach welchen Entscheidungsprämissen sie handeln. Diese Prämissen sind oft dem Organisations-Unterbewußtsein zuzurechnen – wirksam, aber unsichtbar. Und selbst wenn diese Prämissen bekannt sind: diese zu formulieren ist ein politischer Akt, ein Statement, eine Festlegung. Fast wie der Blick in die Unterhose – so stellen sich die Fachabteilungen zumindest an wenn man versucht jene Prämissen schriftlich zu fixieren (meine persönliche Erfahrung).

Nun kann man es auf der anderen Seite verstehen, daß die Fachabteilungen die Prämissen nicht fixieren nicht möchten. Diese Prämissen sind oft Bestandteil der taktischen oder strategischen Ausrichtung, und hinmit „subject to change„.

Und genau da liegt die Krux: die Fähigkeit jene Prämissen flexibel anpassen zu können ist wesentlicher Bestandteil der Selbstorganisationsfähigkeit der Organisation (=Systems).

Und eben jene Prämissen fliessen (zum Teil unvermeidlich) in die Gestaltung der unverzichtbaren IT-Systeme ein. Diese Prämissen werden Bestandteil der in digitalen Beton gegossenen Geschäftsprozesse (= Software) und schränken dadurch die Selbstorganisationsfähigkeit der Organisation ggf. drastisch ein.

Es sei denn die Prämissen werden kommuniziert, und es wird kommuniziert das sie sich ggf. ändern können. Dann ist die IT wiederum in der Lage die Software entsprechend aufzustellen. Oder bestimmte Teile einfach gar nicht zu implementieren (was ich inzwischen immer öfters empfehle) um die Selbstorganisationsfähigkeit nicht einer 5%-tigen Effizienzsteigerung zu opfern.

Merke: „falsch“ designte IT-Systeme beschränken die Selbstorganisationsfähigkeit einer Organisation.

Kein Forschungsabend im Februar

Bedingt durch private Themen fällt der Forschungsabend im Februar leider aus. Dies ist auch der Grund warum es von meiner Seite aus in den letzten Wochen im Blog so ruhig geworden ist.

Sobald sich die Dinge geklärt und sortiert haben gehts mit der Institutsarbeit wieder weiter.

Postheroisches Management & IT

Ü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“

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

Die Glasperlen-Syntax

Der folgende Text entstammt der Feder meines Institutsmitbegründers Dr. Leo Maier und beschreibt – meiner Meinung nach – sehr präzise den Nutzen von Aufstellungen:

Ausgangspunkt der folgenden Überlegung war eine Hypothese, die einmal am Rande einer Diskussion auftauchte: Was wäre, wenn das Gehirn mit der Sprache noch unterfordert wäre? Wenn also die biologische Leistungsfähigkeit unseres Gehirns erst mit erweiterten kulturellen Medien ausgeschöpft werden könnte? Wie müssten diese Medien aussehen? Wie könnte es, anders gefragt, ein Denken jenseits von Sprache geben?

In seinem Buch „Das Glasperlenspiel“ beschreibt Hermann Hesse eine Form von Wissenstradierung und Wissensgenerierung, die auf einem eigenwilligen Spiel mit Glasperlen aufgebaut ist. Nun ist zwar die Einschätzung dieses Autors im Laufe eines Lebens durchaus Schwankungen ausgesetzt, aber die Beschreibung dieses Spiels ist etwas, das nach wie vor höchste Bewunderung verdient. Denn Hesse reizt die Beschreibung dieses Spiels bis zum äußersten aus. Noch einen winzigen Schritt in Richtung Explizitheit weiter und er müsste schon all seine Karten auf den Tisch legen und den „Bluff“ offenbaren. Denn natürlich gibt es dieses Spiel nicht. Er beschreibt lediglich eine Fiktion. Aber muss es eine Fiktion bleiben – oder könnte es ein solches Spiel tatsächlich geben?

Ich nehme einmal an, dass dies wirklich möglich ist, und untersuche, wie es aussehen müsste.

Dabei spielt die Methodik der (Struktur-) Aufstellung eine besondere Rolle. Bert Hellinger hat diese Technik ursprünglich entwickelt und in die Familientherapie eingebracht. (Fremde) Personen werden vom Klienten als Stellvertreter für Familienmitglieder in einem Raum „aufgestellt“, d.h. in Form einer Konstellation angeordnet. Diese entwickeln dort erstaunlicherweise (?) die Gefühle der realen Personen.

Durch gezielte Veränderungen dieser Konstellation, kann man auch die entsprechenden Themen und Probleme verändern, aufgrund derer der Klient, diese Aufstellung durchführt. Später hat man festgestellt, dass sich diese Methode abstrahieren und auf andere Felder übertragen lässt. Es müssen beispielsweise keine Personen sein, die man aufstellt. Man kann auch Krankheiten, Symptome und Medikamente aufstellen. Oder alternative Geschäftsstrategien eines Unternehmens. Oder die Architektur eines Rechennetzwerkes Usw. (Habe all das übrigens schon – mit guten Ergebnissen – selbst gemacht!) Dies nennt man dann eine Strukturaufstellung. Es hat die gleiche Syntaktik wie die Familienaufstellung, aber natürlich eine völlig andere Semantik. Gehen wir noch einen Schritt weiter.

Mit meinen erfahrenen Aufstellungskollegen ist es oft gar nicht mehr notwendig, uns tatsächlich im Raum zu verteilen. Es genügen kleine Symbole, die wir auf dem Tisch verteilen und wir „denken“ uns dann eben in diese Punkte und ihre Gefühle hinein. Damit sind wir eigentlich schon bei den Glasperlen. In einem ersten Schritt gibt es eine Abbildung der relevanten Größen in Symbole hinein. Beispielsweise: „Frankfurter Schule“ ® rotes Steinchen. „Luhmann“ ® blaues Steinchen. „Mehrwertigkeit“ ® grünes Steinchen. Damit wäre gegenüber dem Namen erst einmal noch nichts gewinnen, wenn man jetzt weiterhin nur die klassische Syntaktik der Sprache zur Verfügung hätte.

Aber die Aufstellungssyntaktik geht über die sprachliche an zwei entscheidenden Stellen hinaus: Sie erlaubt, erstens, über die Form der Konstellation komplexere Verbindungen der betrachteten Größen. Und sie fügt, zweitens, das Medium der Einfühlung in das Denken mit ein. Man sieht die komplexe Perspektivität der Elemente nicht nur, man spürt sie. Man kann ein solches Glasperlen-Spiel allein machen oder auch mit anderen. Es gibt also auch das Analogon zum Gespräch in diesem neuen Denk-Medium. Es gibt verschiedene logische Ebenen, die durch unterschiedlich Spielfelder abgebildet werden. Es gibt zwei hierbei zwei Typen der Verbindung: Das „Ergebnis“ eines Brettes kann ein Steinchen in einem neuen Spielfeld werden („Chunk up“). Oder umgekehrt kann ein einzelnes Steinchen in einem neuen Spielfeld ausdifferenziert werden („Chunk down“).

Anders als in klassischen Typentheorien (Russell) ist es durchaus möglich, dass dasselbe Steinchen (nicht nur das gleiche) auf unterschiedlichen Ebenen gleichzeitig auftritt. Diese Zirkularitäten und Schleifenbildungen sind keine Behinderung, sondern sogar eine Bereicherung dieser Denkform. Der Ausgangspunkt ist eine klassische Semantik, die über eine neue (grafische) Grammatik bearbeitet wird. Aber dabei muss es nicht stehen bleiben. Es ist gut möglich, dass sich auch neue Semantiken herausbilden. (Damit betreten wir wohl auch den Bereich Jongenscher Hyperbilder.) Es gibt dann beispielsweise auch (semantische) Erkenntnisse, die über die sprachliche Form hinausgehen. Man würde sie einem Dritten daher nicht sagen, sondern am Brett zeigen. (Die Struktur dieses Denkens würde sich somit dem Medium Kunst annähern.) Um Menschen als echte „Gesprächs“-Partner für diese Denkform zu haben, braucht es natürlich erst einmal eine entsprechende Propädeutik, d.h. sie müssen als ersten Schritt die „Sprache“ der Aufstellung lernen, also die entsprechenden Erfahrungen sammeln.

Wie sieht ein Forschungsabend aus?

Eine weitere häufig gestellte Frage ist: wie kann ich mir so einen Forschungsabend vorstellen?

Der typische Ablauf an einem Abend sieht ungefähr so aus:

• wir treffen uns
• ich/wir erklären kurz das Prozedere der Aufstellung
• jemand schmeisst ein echtes oder fiktives Thema in die Runde
• wir probieren aus wie man das Thema aufstellen könnte
• danach wir diskutiert ob das so funktioniert, was man verändern könnte etc
• dann kommt das nächste Thema dran.

Wie läuft eine „Aufstellung“ ab?

Fiktives Beispiel: ich überlege ob wir die Webseiten im Institut auf einen eigenständigen Server hosten sollen oder ob wir es bei einer VPS-Variante belassen. Ich bin sozusagen der Client, und mein Partner Leo Maier würde mich durch die Aufstellung begleiten. Meine Frage ist: ich will wissen welche Server-Variante welche Vorzüge hat.

Um aufzustellen brauchen wir etwas freien Platz. Es sind genügend Personen an dem Abend da, also nehme ich mir für jeden Aspekt der mir so in den Sinn kommt eine der anwesenden Personen und stelle damit eine Art lebendes Strukturmodell. In der Mitte der Server, hinten links die Website, vorne rechts den Aspekt Performance, vorne links den Aspekt Kosten (reine Fiktion!). Sprich: es stehen 4 Personen im Raum, plus mir und Leo. Beispielhaft als Diagramm die Servervariante:

Dann wird mit der Struktur gearbeitet: statt des Servers wird jemand anders als VPS-Lösung aufgestellt, die Aufstellung verändert sich dadurch:

In beiden Fällen bespricht Leo mit mir anhand der aufgestellten Skulptur welche Vor- und Nachteile die jeweilige Lösung hat. Und die Stellvertreter welche für die Aspekte im Raum stehen werden ebenfalls nach Meinungen befragt. Interessanterweise – und das ist das Spannende beim Aufstellen – können einem die Stellvertreter erstaunliche Perspektiven und Sichtweisen anbieten.

Ich hab dann noch die Möglichkeit in diese lebende Struktur einzusteigen und z.B. die Perspektive des Servers zu übernehmen.

Nach einigem Befragen und Nachhaken wird dann die Skulptur aufgelöst, d.h. die Stellvertreter gehen aus der Aufstellung raus, man bespricht noch die Erkenntnisse und die Arbeit ist beendet.

Ich habe selbst schon an über 100 Aufstellungen (allerdings nicht auf IT-Themen bezogen) mitgemacht und selbst schon x-dutzend Aufstellungen angeleitet. Ich kann aus eigener Erfahrung sagen das man nachher meistens deutlich klüger ist als vorher, und das man dann Aspekte des Themas sieht die man vorher nicht wahrgenommen hat.

Das von mir benutzte Beispiel ist jetzt ein echtes IT-Thema. Ich kann jetzt nicht mit 100% Sicherheit sagen ob das so wie ich es beschrieben habe wirklich Sinn machen würde. Vielleicht würde man auch eine andere Form wählen – das gilt es eben humorvoll-gelassen auszuprobieren.

Skeptiker können natürlich zu Recht einwenden das man eine derartige Frage auch anhand eines Fragebogens und/oder einer Evaluation klären kann. Das ist inhaltlich natürlich richtig. Inhaltlich (welche Variante ist besser) kommt man sowohl bei der klassischen Evaluation als auch bei der Aufstellung zum gleichen Ergebnis.

Man vernachlässigt aber den Aspekt das man in kürzerer Zeit über einen derartigen Aufstellungsprozess eine viel größere Gruppe an Personen an der Entscheidungsfindung teilnehmen lassen kann – und das eine mehr Personen das Gefühl hat zur Entscheidung wirklich etwas beigetragen zu haben. Abgesehen davon dauert eine Aufstellung vielleicht 45m – 60m. Bei 10 Personen die in diese Entscheidung einbezogen werden sollen wären das 10 Arbeitsstunden.

Schafft man mit insgesamt 10 Arbeitsstunden eine saubere, inhaltlich korrekte Evaluation einer derartigen Entscheidung, inkl. der Wissensvermittlung wie die Entscheidung zustande gekommen ist und mit dem vermittelten Gefühl bei der Entscheidung beteiligt worden zu sein?

Die Antwort überlasse ich meinen meeting- und evaluationserprobten Lesern…

Andrew Smart

Vision und Idee der „systemischen IT“

Frohes neues Jahr all unseren Lesern & Kontakten!

Nach der Feiertagspause habe ich einen kleinen Ausflug in die Welt der Businessplanwettbewerbe gemacht und eine Idee in den Wettbewerb geworfen die viel mit IT-Projekten, Kommunikation in denselben und natürlich systemischen Aspekten zu tun hat. Mal sehen wie gut die Idee in der ersten Runde ankommt. Ich verrate auch zum Schluß des Wettbewerbs worum es bei dieser Idee genau geht.

Nicht das ich nichts zu tun hätte – nur ist meine Schublade ist voller Ideen, und der Wettbewerb ist eine gute Möglichkeit mal eine liebgewordene und schon länger gepflegte Idee rauszukramen und von einem kompetenten Gremium bewerten zu lassen.

Aber darüber wollte ich eigentlich gar nicht schreiben.

Wir haben viel positives Feedback zu unserer Seite und unserer Idee erhalten, und es haben sich bereits interessante Kontakte ergeben zu Personen und Organisationen die wohl in einem ähnlichen Umfeld unterwegs sind. Das freut uns natürlich außerordentlich – wir stehen nicht alleine auf weiter Flur.

Wir wurden natürlich auch befragt was denn unsere Vision sei und was wir genau bezwecken möchten. Ich denke es macht Sinn wenn ich auf diese Fragen im Blog eingehe…

Leo und ich sind beide erfahrene systemische Aufsteller, wobei er natürlich bei weitem mehr Erfahrung hat – ich bin „erst“ 2000 auf die Systemik gekommen. Wir kennen die Methode gut, der Denkansatz ist überzeugend, und die Effektivität unbestritten. Wir arbeiten ja nicht im luftleeren Raum – die Aufstellungsmethode ist längst ver- und erprobt, es gibt reihenweise Ausbildungen, es gibt Berufsverbände und natürlich auch etliche Guru’s.

In der IT ist weder der gedankliche Ansatz der Systemik noch die Methode bekannt oder verbreitet. Nungut, die IT-Welt ist von jeher eher der Technik als dem Menschen zugewendet. Von daher verwundert es auch nicht das Methoden, die einen hohen Anteil an menschlicher Interaktion erfordern, nicht sofort aufgegriffen werden.

Ich sehe aber dennoch einige Gründe warum diese beiden Welten sehr gut zueinanderpassen.

Zum einen das Systemverständnis: einem IT’ler muss man nicht mehr viel über Feedbackschleifen/Rückkopplungen erzählen, und auch nicht über die Sicht auf das „Gesamtsystem“: das ist quasi das täglich Brot in der IT. Da gibt es nicht viele Hürden zu überwinden, um aus einem IT’ler einen Systemiker zu machen, weil sie es im Grunde schon längst sind.

Wenn man sich die modernen IT-Entwicklungsmethoden wie agile Softwareentwicklung anschaut, stellt man fest das das Kommunikationsthema ebenfalls schon längst in der IT angekommen ist. Ein Beispiel: im Buch „Agile Softwareentwicklung“ beschreibt Alistair Cockburn unter „Teams als Ökosystem“: Ein Softwareprojekt erzeugt ein kleines Ökosystem, das aus Persönlichkeiten unterschiedlicher Kulturen besteht. … Jede Position und jeder Mitarbeiter beeinflussen sich gegenseitig. … Die Mitarbeiter der Teams werden ihre Konventionen natürlich im Laufe der Zeit, periodisch oder sobald ein wichtige (sic!) Ereignis ihr Ökosystem trifft, erneut betrachten und korrigieren (…).

Das ist Systemik pur – in einem Buch das sich mit Softwareentwicklung beschäftigt. Es gibt inzwischen auch eine zunehmende Zahl von IT-Führungskräften die in diesem Kontext ebenfalls Erfahrungen gesammelt hat.

Die Vision des Instituts ist es, die Potentiale des systemischen Ansatzes inkl. des dazugehörigen Methodenkoffers für die IT nutzbar zu machen. Primär wird das über Forschungsabende realisiert in der IT’ler & Systemiker an echten Themen ausprobieren. Was übrigens bei weitem weniger experimentell klingt als es ist: unser Partner S.O.U.L. hat die Aufstellungsmethode bereits erfolgreich auf diverse Spezialthemen „angepasst“. Die Methode hat halt einfache eine universelle Qualität.

Ich bin mir sicher das wir im Laufe des Jahres 2008 einen guten Schwung bekommen werden und schon sehr bald konkrete Ergebnisse vorweisen können.

Andrew Smart