Methoden passen immer, …

… sonst wären sie nämlich keine. Sie hätten sich quasi nicht bewährt, wären “von der Bildfläche” verschwunden und durch andere ersetzt worden. Das passt natürlich nicht zu den immer wieder kehrenden Diskussionen, ob Methoden gut oder schlecht wären. Deshalb spiegele ich in diesem Post dazu meine Sicht.

Dieser Artikel ist die Fortsetzung zu meinen End-to-End Beiträgen innerhalb von Prozessen in Unternehmen. Im ersten Post habe ich ein paar grundlegende Themen zum Thema End-to-End Prozessbetrachtung in Unternehmen vorgenommen, die ich dann im zweiten Post am Beispiel eines Handelsunternehmens konkretisiert habe.

Beiträge zur Reihe “End-to-End Organisation und Steuerung/ Regelung von Unternehmen” Link
Ist bei End-to-End Prozessen auch immer wirklich End-to-End drin? link
Eine konkrete End-to-End Prozessbetrachtung am Beispiel eines Handelsunternehmens link
Methoden passen immer, … Dieser Beitrag
Die Big Data Analytics Matrix link
Maschinen kennen nur das “WAS”, niemals das “WARUM” link
Unreflektierte KPI Orientierung in Unternehmen ist wie “Malen nach Zahlen” link
Steuerung und Regelung von Unternehmen mit dem Viable System Model link

Komme ich also nun, wie bereits angekündigt, auf Kennzahlen zu sprechen. Um hier aber einen Ankerpunkt zu setzen, möchte ich erst einmal darlegen, welche Grenzen uns in komplexen Umfeldern im Kontext Steuerung und Regelung auferlegt sind. Basis meiner Ausführung ist der Kategorienfehler, der immer wieder in Bezug auf Kompliziertheit und Komplexität vollführt wird. Deshalb möchte am Anfang einige Worte über Kompliziertheit und Komplexität verlieren und dabei vor allem auf die markanten Unterschiede eingehen.

Kompliziertheit und Komplexität – der Versuch einer Versöhnung

Erzählt mir doch tatsächlich Jemand, dass der Bau des Flughafens BER kompliziert und nicht komplex sei. Warum? Na, Flughäfen wurden ja schon so viele erbaut. Ach ja? Mit den komplett identischen Rahmenbedingungen und den komplett identischen Menschen? Wann begreifen wir endlich, dass, wann immer Menschen in einem Thema involviert sind, dieses von Komplexität durchzogen ist? Warum? Wir Menschen nehmen ausschließlich über Modelle wahr. Und diese werden durch ganz viele Einflüsse von außen beeinflusst. Diese können politischer, privater, beruflicher, zwischenmenschlicher etc. Natur sein. Ich würde also im Kontext von menschlicher Wahrnehmung niemals von “Das liegt doch klar auf dem Tisch, warum hast Du das denn nicht gesehen?” reden.

Wir sind nun mal keine Maschinen, die stets nur monokontextural die Welt erforschen. Wir agieren polykontextural. Genau das macht Lebendigkeit aus. Und da wären wir bei Komplexität und verlassen das Habitat der Kompliziertheit.

Ich benutze oft die Begriffe “tot” und “lebendig” im Kontext von Kompliziertheit und Komplexität. Themenstellungen in “lebendigen” Umgebungen können niemals kompliziert sein. Sie sind immer komplex. Themenstellungen in “toten” Umgebungen sind stets kompliziert. Das möchte ich am Beispiel eines Uhrmachers erläutern, um zu verdeutlichen, dass auch Menschen an “toten” Fragestellungen oder Aufgaben beteiligt sein können, obwohl sie selber lebendig sind. Deshalb die Begriffe “tot” und “lebendig” auch in Anführungszeichen.

Ein Uhrmacher baut eine Uhr zusammen. Dafür gibt es ein ganz klar vorgegebenes Rezept, welches vielleicht 300 Schritte beinhaltet, die in einer ganz bestimmten Reihenfolge abgearbeitet werden müssen. Werden diese Schritte befolgt, wird definitiv eine funktionierende Uhr heraus kommen. Ist der Uhrmacher geübt, sprich, hat er genügend praktisches Wissen, ist diese Aufgabe für ihn einfach. Für mich als Ungelernten wird diese Übung schwierig sein, niemals komplex, denn ich kann ja einen Plan befolgen. Mit Übung bin ich vielleicht irgendwann so weit, dass ich diese Uhr zusammen gesetzt bekomme. Der Bauplan ist fix und ändert sich auch nicht. Man spricht hier von Monokontexturalität. Solche Tätigkeiten könnte man auch von Maschinen ausführen lassen, da klar definierte Abfolgen von Schritten programmierbar sind.

Nun stellen wir uns aber mal vor, dass eine Schraube fehlt. Ein Zahnrad kann nicht befestigt werden. Hier würde die Maschine einen Fehler melden, weil jetzt der Kontext verlassen wird. Das Fehlen der Schraube ist nicht Bestandteil des Kontextes, da es nicht Bestandteil des Planes und damit auch nicht Bestandteil des Programmcodes ist. Die Maschine weiß deshalb nicht, was zu tun ist. Der Uhrmacher ist in der Lage den Kontext zu wechseln. Er könnte nach anderen Möglichkeiten der Befestigung suchen oder theoretisch probieren, ob die Uhr auch ohne diesem Zahnrad funktioniert oder er könnte ganz einfach eine Schraube bestellen und später den Vorgang fortsetzen. Der Uhrmacher kann polykontextural denken und handeln. In diesem Fall wird dann der komplizierte Fall ein komplexer Fall. Der Bauplan ist nicht mehr gültig, denn Bestellung einer Schraube war in diesem nicht enthalten. Deshalb meldet die Maschine wie gesagt einen Fehler. Der Bestellvorgang müsste von einem Menschen in Form von Programmcode voraus gedacht werden, so das die Maschine diesen anstoßen könnte. Damit wäre diese Option wieder Bestandteil des monokontexturalen Bereiches, in dem die Maschine agieren kann.

Kommen wir in diesem Zusammenhang zum Messen und Wahrnehmen. Maschinen können messen. Messen passiert in monokontexturalen Umgebungen. Die Maschine kann messen, ob die Schraube festgezogen ist, die das Zahnrad hält. Das ist wieder monokontextural: Die Schraube ist “fest” oder “lose”. Im Falle des Fehlens der Schraube verlässt man hier die Ebene des Messens und geht in die Ebene der Wahrnehmung über. Die Maschine kann nicht wahrnehmen, der Uhrmacher schon. Beim Wahrnehmen muss man den Kontext erst einmal bestimmen, dieser ist nicht per Programmcode gegeben. “Die Schraube fehlt” setzt die Maschine in den Kontext “fest-lose” und dann ist Schluss. Die Maschine würde stetig zwischen “fest” und “lose” iterieren und niemals zum Ende gelangen. Eine endlose Schleife, die mit einem Fehler abgebrochen werden muss. Der Uhrmacher kann nach weiteren Möglichkeiten suchen, das ist gleichbedeutend mit dem Suchen nach einem weiteren Kontext. Er kann vielleicht eine neue Schraube suchen oder versuchen das Zahnrad irgendwie anders geartet zu befestigen.

In “toten” Umgebungen ist der Mensch mit der Umwelt eins geworden. Er ist trivialisiert. Das ist nicht despektierlich gemeint. Diese Trivialisierung ist ausreichend, da ein Rezept in Form einer Methode oder Algorithmus vorliegt, welches zielführend ist. Wahrnehmen ist also nicht notwendig, da kein Kontextwechsel vorgenommen werden muss. Messen reicht aus.

In einer komplexen und damit “lebendigen” Welt gilt das Motto “Sowohl-Als-Auch”, da hier stetig der Kontext gewechselt wird. Das bedeutet Widersprüchlichkeit handhaben zu müssen. Komplizierte Umgebungen kennen ausschließlich “Entweder-Oder”. Damit existieren in komplizierten Umgebungen auch keine Widersprüche. Komplizierte Sachverhalte können vollständig in Programmcode oder Algorithmen geschrieben und damit gemanaged werden. Bei komplexen Umgebungen funktioniert das nicht, da unsere Zweiwertige Logik, auf die jeder Programmcode basieren muss, Widersprüche und damit Polykontexturalität ausschließt. Komplexität ist also nicht steuer-, sondern bestenfalls handhabbar.

Eine Differenzierung zwischen Kompliziertheit und Komplexität habe ich auch in meinem Artikel Können Maschinen entscheiden auf der Plattform der Unternehmensdemokraten im Zusammenhang mit Lernen und Entscheiden vorgenommen. Dort habe ich ähnlich auf Basis der Monokontexturalität ausgeführt, dass Maschinen eben nur im Stande sind Lernen_1 Prozesse auszuführen. Warum? Weil die Lernen_2 Prozesse ausschließlich in komplexen Umgebungen von statten gehen können, da diese Kontextwechsel voraussetzen.

Was bedeutet das nun für Methoden?

Für diese Reflektion möchte ich auf das bekannte Cynefin-Modell verweisen und dieses aus meiner Sicht notwendigerweise erweitern, da es zu Kategorienfehler zwischen Kompliziertheit und Komplexität verleitet.

Cynefin

Nach diesem Modell werden die Kategorien “einfach”, kompliziert” und “komplex” auf eine Ebene platziert. Das ist aus meiner Sicht nicht passfähig. Die Einstufung “einfach” und damit auch “schwierig”, die es im ursprünglichen Modell nicht gibt, existiert eine Ebene höher in beiden Kategorien, “kompliziert” und “komplex”. “Einfach” ist also nicht gleich “einfach”.

“Einfach” in der Kategorie “kompliziert” bedeutet, dass das ausreichende Wissen, sowohl praktisch als auch theoretisch, gegeben ist, um eine komplizierte Fragestellung zu lösen. Grundsätzlich ist ein Lösungsweg vorhanden, den man theoretisch kennen und praktisch anwenden muss. Wird eine komplizierte Fragestellung als “schwierig” eingestuft, ist der vorliegende Lösungsweg nicht bekannt. Er muss erlernt werden, sowohl praktisch als auch theoretisch.

In der Kategorie “kompliziert” rede ich also von Methoden oder Algorithmen, die an den bekannten Lösungsweg angelehnt sind.

Für “komplexe” Fragestellungen kann per Definition kein Wissen existieren, welches in Form eines Rezeptes zu einem Lösungsweg geformt werden kann. Hier sind Erfahrung und Talent essentiell, die Agilität im jeweiligen Kontext erhöhen. Je größer oder kleiner Erfahrung und Talent sind, spreche ich dann von den Einwertungen “einfach”, schwierig” oder “chaotisch”. Da kein Rezept gegeben ist, kann man Lösungswege auch nicht vorweg in Form von Algorithmen programmieren. Hier sind Frameworks und Heuristiken angebracht, die genügend Freiraum für das eigene Denken lassen.

Die untere Abbildung stellt die Abhängigkeiten und damit die Erweiterung des Cynefin Modells dar.

Kompl-IZ-EX Modell

Im Komplizierten rede ich also von Methoden, im Komplexen von Frameworks. Ein Vermischen beider ist verboten, da man sonst einem Kategorienfehler unterlegen ist.

Methoden müssen stets monokontextural sein. Das ist quasi ihre DNA, sonst wären sie keine Methoden. Klassische Projektmanagementmethoden beispielsweise sind unter dem Deckmantel entstanden, dass man Projekte zum Erfolg führen will, egal um welche Projekte es sich handelt. Dann hat man bestimmte Muster an Handlungen ausfindig machen können, die einem Projekterfolg eher zuträglich oder eben nicht zuträglich sind. Diese Muster wurden dann zu Rezepten verallgemeinert, ähnlich des Backens eines Kuchens oder des Zusammenbauens einer Uhr. Aber ist das zulässig? Nein. Deshalb ist auch der Bau des Flughafens BER nicht kompliziert, sondern komplex. Ganz egal, wie viel Flughäfen vorher bereits erbaut wurden.

Daher passt für mich auch der Name “Projektmanagementmethode” nicht. Projekte liegen stets im Komplexen, Methoden im Komplizierten. Projektframeworks passt für mich eher. Maschinen können ausschließlich in komplizierten Ungebungen agieren. Themen können die Kompliziertheit in Richting Komplexität verlassen, allerdings ausschließlich durch den Menschen initiiert. Bei dieser Transformation ist dann zu beachten, keinen Kategorienfehler zu begehen, da Algorithmen und Methoden im Reich der Komplexität nicht angewendet werden dürfen.

Die Versöhnung

In komplexen Umgebungen gibt es für Herausforderungen und Probleme kein Rezept. Diese gibt es nur in komplizierten Umgebungen, wo der Mensch entweder nicht stattfindet oder so weit trivialisiert wurde, dass er mit der Umwelt eins geworden ist. Dieses Suchen nach Rezepten kann einfach oder schwierig sein, je nach Wissensstand des Beobachters. Damit will ich also ebenfalls sagen, dass nicht alle komplizierten Themen von jedem Menschen bewältigt werden können. Ich weiß zum Beispiel nicht, ob ich jemals eine Uhr zusammen bauen kann, auch wenn das Rezept dafür vorliegt. Mag sein, dass mir dafür praktisches Wissen fehlt, was ich mir niemals aneignen kann.

Damit ist auch meine Eingangsthese belegt. Methoden passen immer, denn diese gelten nur in komplizierten Umgebungen und sind damit ganz klar gegen ein Soll validierbar. In komplexen Umgebungen bekommt der Mensch mit seinen Skills und Erfahrungen eine besondere Rolle zugeschrieben. Wissen alleine reicht hier nicht aus, um komplexe Themen zu handhaben, denn nur das ist im Idealfall möglich. Beherrschen von Komplexität ist eine Illusion. Dieses Handhaben kann dann je nach Erfahrung einfach, schwierig oder eben chaotisch sein.

Dieser Fakt legt auch nahe, dass wir mit viel mehr Demut bezüglich des Umgangs mit unserer Natur zu Werke gehen sollten, denn sie ist von uns nicht beherrschbar, egal wie weit auch den Fortschritt unserer komplizierten Technologie vorantreiben.

Unternehmen agieren in Umfeld von Komplexität. Wir haben nun festgestellt, dass komplexe Umgebungen nicht gesteuert, sondern bestenfalls gehandhabt werden können. Im kommenden Beitrag im Rahmen dieser Serie werden wir mit dieser Erkenntnis im Kopf habend, vorherrschende Analytics und Data Science im Umfeld von Big Data beleuchten.

1 Star2 Stars3 Stars4 Stars5 Stars (5 Bewertung(en), Durchschnitt: 4.40 von 5)
Loading ... Loading ...
This entry was posted in Komplexität and tagged . Bookmark the permalink.