Agiles Organisationsdesign meint NICHT eine Organisation möglichst agil zu gestalten. Sondern die Fähigkeit einer Organisation, in Abhängigkeit vom Problem, das „richtige“ Organisationsdesign zu wählen. Was meine ich damit? Vielen Organisationen, die ich kenne, kennen für jedes Problem nur die klassische Hierarchie. Vielleicht hin und wieder mal Projekte. Das ist auch richtig und gut so. Dadurch wird Standardisierung erreicht. Was schlussendlich zu Umsatz und Gewinn führt. Das gilt jedoch nicht für jedes Problem. Im Kern sehe ich vier verschiedene Sorten von Problemen.
Inhalt
1. Hierarchie im Aufbau – Prozess im Ablauf
Ich behaupte min. 80% aller Probleme lassen sich durch eine klassische Hierarchie bearbeiten. Im CYNEFIN-Modell sprechen wir konkret von einfachen und komplizierten Problemen (siehe dazu auch das CYNEFIN-Experiment als Video). Wie die obige Abbildung zeigen soll, braucht es hier nicht allzu viel an neuer Kommunikation. Vieles lässt sich im Rahmen eines Standards abwickeln. Um es nochmals zu sagen, das ist gut und richtig. Durch Standards lässt sich ein Geschäftsmodell skalieren. Damit erwirtschaftet selbst ein Hilfsmitarbeiter in einem Industriebetrieb einen Umsatz von €200.000.
2. Bereichsübergreifende Projekte
Dann gibt es Aufgaben die „zu kompliziert“, vielleicht auch schon komplex sind, die sich nicht innerhalb einer Abteilung abarbeiten lassen. Folgerichtig kommt hier der Ruf nach Projektarbeit im Unternehmen hoch. Wann ist ein Projekt ein Projekt? Diese Frage stelle ich immer wieder zu Beginn eines Projektmanagement-Seminars und alle Standards sagen im Kern das gleiche: Einmaligkeit. Projekte sind eine Organisationsform für möglichst einmalige Probleme in einem Unternehmen. Das kostet Geld, damit lässt sich nicht wirklich wiederholt Umsatz machen. Außer ich verkaufe die Abwicklung von Projekten für andere Unternehmen (z.B. Beratung, Entwicklung, usw.).
3. Agile Projekte
Jetzt gibt es einen Sonderfall im Projektmanagement, nämliche agile Projekte. Nach meiner Daumenregel kann man von agilen Projekten sprechen, wenn sich min. 30% der definierten Anforderungen pro Monat ändern. Mit agilen Projekten habe ich einen wesentlich höheren Overhead zur Steuerung des Projektes, weil ich das Projekt quasi in kleine Scheibchen zerlege und immer wieder plane. Dieser zusätzliche Steuerungsaufwand (=Kommunikation) ist durchaus gerechtfertigt, sofern sich die Anforderungen wirklich so schnell und häufig ändern. Hier sprechen wir definitiv von komplexen Problemen. Die Verteilung von klassischen zu agilen Projekten würde ich jetzt einfach mal frech mit 90:10 schätzen.
4. Design Thinking & Co
Schlussendlich können wir dem Ganzen jetzt noch die Krone aufsetzen. Standards greifen so gut wie gar nicht mehr. Ich muss dauernd in den Austausch gehen und noch mehr Aufwand in Kommunikation stecken. Nicht mal das Ziel ist klar. Wir wissen nur wir wollen was Neues bzw. Innovation. Jetzt kommt die Zeit sämtlicher cooler Methoden wie z.B. Design Thinking, Design Sprint oder Google Sprint. Damit verdiene ich zunächst überhaupt kein Geld, außer ich verkaufe die Durchführung für ein anderes Unternehmen. Die Wahrscheinlichkeit des Scheiterns ist hoch. Die Wahrscheinlich der Umsetzung ist gering. Aber es macht Spaß!
Ein idealtypisches Beispiel
Ich möchte für mein Unternehmen ein neues Produkt entwickeln. Zunächst greife ich in Schublade 4 und wende zur Organisation meines Teams Design Thinking an, um eine erste Ideen zu bekommen. Die beste Idee wählen wir mit der Lean Startup Logik, build-measure-learn, aus. Anschließend gehen wir mit SCRUM aus Schublade 3 auf den Weg der Produktentwicklung. Wir testen unseren Fortschritt iterativ mit der Zielgruppe und freuen uns über Änderungen. Parallel beschäftigen wir uns mit der Entwicklung des Geschäftsmodells, unterstützt durch den Business Model Canvas. Wenn wir den Prototypen erfolgreich getestet haben wechseln wir zu Schublade 2 und organisieren uns für die Industrialisierung des Produktes in einem klassischen Projekt-Setup. Zur Herstellung des fertigen Produktes bedienen wir uns in Schublade 1 und wählen eine klassische Hierarchie mit maximaler Effizienz.
Fazit – Agiles Organisationsdesign
Das momentan häufig praktizierte schwarz-weiß denken hinsichtlich Organisationsdesign ödet mich nur noch an. Hierarchie ist nicht das Beste. Agil ist nicht das Beste. Es gibt nicht das beste Organisationsdesign. Je nach Art des Problems (einfach, kompliziert, komplex, chaotisch) gibt es unterschiedliche Werkzeuge, die sich schlechter oder besser eignen. Agiles Organisationsdesign meint nun, in Abhängigkeit vom Problem, das „richtige“ Werkzeug zu wählen. Oder bist du schon mal auf die Idee gekommen mit einem Bleistift, ein Loch in die Wand zu machen, um ein Bild aufzuhängen.
Dr. Patrick Fritz
Kommentar verfassen