Updates zur systemischen IT

30. August 2010

Hallo,

seit Januar 2010 hat sich so einiges hinter den Kulissen getan, im Vordergrund eher weniger. Wir haben in 2010 noch keine Forschungsabende durchgeführt – was wohl einige unserer Teilnehmer aus 2009 schade fanden. Wir wollen die Aktivitäten gerne wieder aufgreifen, eine Wiederaufnahme der Forschungsabende wird aber noch einige Wochen benötigen.

Die Idee der systemischen IT ist nicht tot – ganz im Gegenteil, einiges aus den Impulsen der Forschungsabende wurde in die Praxis übertragen und erfolgreich ausprobiert. Aber wie das so ist – man kann halt immer nur in wenigen Spielfelder zu gleich unterwegs sein.

Andrew


Neuer Namen, neue Termine

20. August 2009

Nach meiner Rückkehr aus USA sind nun inzwischen fast 4 Wochen vergangen – und nach 7 Wochen „Famile pur“ hats auch ein bisschen gedauert bis ich wieder im Tritt war in meinen deutschen Bahnen…

Vor meiner Abreise hat sich noch eine weitere Mitstreiterin gefunden, über die ich noch nicht berichtet habe: Anja Müller, wandelbar Unternehmensberatung, Köln.

Sie ist ebenfalls eine „systemische IT’lerin“ – sie hat Wurzeln in der IT, aber inzwischen auch langjährige Erfahrungen als Beraterin und Coachin.

Willkommen im Team!

Die Institutsarbeit kommt nun – auch dank Anja und ihrem unermüdlichen Einsatz – wieder mit großen Schritten voran.

Nach meiner Rückkehr war dann natürlich eines der Themen: in welchem Bezug steht Anja zum Institut? Mitglied? Gibt es sowas wie Mitgliedschaft überhaupt in unserem experimentellen Umfeld? Was grenzt das Institut von den anderen systemischen IT’lern ab?

Letztlich sind wir zur Überzeugung gekommen: das „Institut“ erzeugt eine künstliche Grenze die wir (Leo und ich) eigentlich gar nicht haben wollten (wer ist „drin“ und wer ist „draussen“?)

Und der Begriff „Institut“ schafft eine Erwartungshaltung die wir ggf. gar nicht erfüllen können – nämlich das die Leitung für alle Aktivitäten verantwortlich ist und diese zu steuern hat. Was wir gar nicht so sehen – wir wollen forschen und experimentieren und eher weniger „managen“…

Von daher haben wir uns entschlossen das Institut in ein Netzwerk umzuwandeln… was in unserer Wahrnehmung auch deutlich besser zum systemischen Gedanken passt.

Unabhängig davon gehen die Vorbereitungen für die nächsten beiden Termine (11.9. sowie 18.9.) in die letzten Vorbereitungen. Wir feilen noch an der Einladung die aber Anfang der Woche finalisiert sein dürfte.

Wir haben schon eine Reihe von angemeldeten Gästen und freuen uns natürlich über jede weitere Anmeldung.

Die Veranstaltung findet in Köln statt – mehr Details auf der Netzwerk-Website.

Andrew Smart


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…


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…


Komplexe und komplizierte Aufgaben

26. Juli 2008

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


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


Die Glasperlen-Syntax

14. Januar 2008

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.