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


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


Entscheidungen und IT

28. Mai 2008

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.


Wie sieht ein Forschungsabend aus?

11. Januar 2008

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:

Beispiel Aufstellung

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

 VPS-Variante

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“

9. Januar 2008

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


Ein Blog erblickt die Welt…

19. Dezember 2007

Nun hat uns das Web 2.0 – System also auch im Griff. Ein Blog, ein Blog für ein Königreich 🙂

Es gibt sicherlich keinen besseren Grund einen Blog zu gründen als denn eine Institutsgründung: das Institut für systemische IT (http://www.systemische-it.de) wird in Kürze im Web veröffentlicht. Und natürlich nutzen wir die modernen Formen der Kommunikation.

In diesem Blog werden Andrew D. Smart und Dr. Leo Maier in regelmässig unregelmässigen Abständen zum Thema „Systemik + IT“ bloggen und hoffen auf anregende Diskussionen.

Viele Grüße,

Andrew D. Smart