Collaboration Architecture: Eine alte Disziplin in einem neuen Umfeld

Warum Collaboration Architecture nicht aus dem Management kommt, sondern aus dem Ingenieurwesen

Wenn ich erkläre, woran ich arbeite, kommt früher oder später die Frage: In welcher Tradition stehen Sie eigentlich? Die Vermutung ist meistens, dass die Antwort irgendwo zwischen Organisationsentwicklung, Change Management und der post-bürokratischen Diskussion der letzten zwanzig Jahre liegen müsste. Netzwerkorganisation, Selbstorganisation, Agilität, all das.

Ich verstehe, warum die Frage so gestellt wird. Aber die Antwort ist eine andere, und sie ist nicht offensichtlich, bis man sie ausspricht.

Collaboration Architecture steht nicht in der Tradition des Managements. Sie steht in der Tradition des Ingenieurwesens.

Was Ingenieure seit zweihundert Jahren wissen

Eine Brücke wird nicht von selbst entstehen, nur weil zwei Ufer vorhanden sind. Sie wird nicht von selbst stehen bleiben, wenn Sie sie einmal gebaut und dann sich selbst überlassen haben. Sie wird nicht von selbst sicher sein, ohne dass jemand misst, wie sie sich unter Last verhält. Irgendjemand ist zuständig, in einem rechtlichen, beruflichen und ethischen Sinn, für ihr Funktionieren.

Vier Verben, entwerfen, pflegen, messen, verantworten, sind das Fundament jeder Ingenieursdisziplin, die mit komplexen Systemen arbeitet, von denen Menschen abhängig sind. Bauingenieurwesen, Maschinenbau, Verkehrsplanung, Softwarearchitektur, öffentliche Gesundheitsinfrastruktur. In jedem Feld, seit Generationen.

Diese Tradition ist nicht akademische Theorie. Sie ist die schmerzhaft erlernte Praxis von zwei Jahrhunderten. Sie hat sich gebildet aus eingestürzten Brücken, explodierten Fabriken, gescheiterten Softwaresystemen, Cholera-Epidemien in Städten ohne Wasserinfrastruktur. Jedes Mal, wenn eine Infrastruktur versagt hat, hat das Feld gelernt, was es bedeutet, sie richtig zu bauen. Diese Erfahrung ist tief eingebettet in das, was heute Ingenieurausbildung heißt.

Das eine Feld, das diese Tradition nie erreicht hat

Es gibt genau ein großes Feld, in dem diese Tradition nie angekommen ist: die Koordination von Wissensarbeit in Organisationen.

Das ist erst einmal überraschend. Wissensarbeit ist heute, neben der industriellen Produktion, die wichtigste Form, wie Wertschöpfung in entwickelten Volkswirtschaften stattfindet. Sie geschieht in Organisationen mit Tausenden oder Zehntausenden von Mitarbeitenden, in hochkomplexen Abstimmungsstrukturen, mit Schnittstellen, die in jeder anderen Disziplin als ingenieurspflichtig gelten würden. Aber dieses Feld hat keine eigene Ingenieurstradition entwickelt.

Stattdessen wurde die Koordination von Wissensarbeit historisch von drei anderen Disziplinen behandelt, die jeweils einen Teil des Problems sehen, aber keine die Infrastruktur:

Die HR- und Organisationsentwicklungs-Disziplin sieht Wissensarbeit als Aufgabe von einzelnen Menschen. Die richtige Kultur, das richtige Mindset, die richtige Personalentwicklung. Das Ergebnis dieser Arbeit ist nicht Infrastruktur. Sie arbeitet an den Menschen, die in der Infrastruktur arbeiten würden, wenn es eine gäbe.

Die IT- und Tooling-Disziplin hat Wissensarbeit als ein Werkzeugproblem gerahmt. Mehr Tools, bessere Tools, integrierte Tools. Auch wichtig, aber Tools ohne Koordinationsentwurf bilden auch keine Infrastruktur, durch die Wissen effektiv fließen kann.

Die Management- und Beratungsdisziplin hat Wissensarbeit als ein Strukturproblem gerahmt. Reorganisation, agile Transformation, Spotify-Modell, Holacracy, das Aufbrechen von Hierarchien zugunsten von Netzwerken. Die Annahme war, dass Koordinationsstrukturen sich von selbst bilden würden, wenn die alten Strukturen weg sind. Diese Annahme hält der industriellen Realität nicht stand. Ich habe das in neun Jahren in deutschen Industrieorganisationen wiederholt beobachtet.

Was in keiner dieser drei Disziplinen vorkommt: die ingenieurmäßige Behandlung der Frage, wie Koordinationsinfrastruktur entworfen, gepflegt, gemessen und verantwortet werden muss, damit sie unter Last trägt.

Was passiert, wenn man die Disziplin importiert

Wenn man die ingenieurtechnische Tradition auf die Koordination von Wissensarbeit anwendet, verändern sich die Fragen, die man stellt.

Man fragt nicht mehr: Wie schaffen wir die richtige Kultur? Man fragt: Welche Protokolle tragen unsere Zusammenarbeit, und was passiert, wenn sie versagen?

Man fragt nicht mehr: Welches Tool brauchen wir? Man fragt: Welche Last muss die Infrastruktur tragen, und mit welchen Werkzeugen können wir sie bauen?

Man fragt nicht mehr: Wie schaffen wir flache Hierarchien? Man fragt: Wer trägt die Verantwortung für die Koordinationsinfrastruktur zwischen den Funktionen, und ist diese Person mandatiert und ausgestattet, sie zu tragen?

Diese Fragen sind die Standardfragen jeder Ingenieursdisziplin, die sich mit Infrastruktur befasst. Sie klingen nur deshalb ungewohnt im Organisationskontext, weil sie dort nie systematisch gestellt wurden.

Und das ist die ganze Pointe: Wir bauen hier keine neue Theorie. Wir importieren eine alte Disziplin in ein Feld, in dem sie überfällig ist.

Was das für die Praxis bedeutet

Drei Konsequenzen, die für Operative Leitungen relevant sind:

Erstens: Wenn Koordination eine Infrastrukturfrage ist, dann ist sie messbar. So wie eine Brücke hat auch eine Koordinationsstruktur eine Tragfähigkeit. Wie viele Stunden pro Woche verbringen Ihre Teams mit Arbeit, die durch fehlende Infrastruktur entsteht? Wie oft werden Entscheidungen doppelt getroffen? Was kostet das, in Euro, pro Quartal? Diese Fragen sind beantwortbar. Sie werden nur selten gestellt.

Zweitens: Wenn Koordination eine Infrastrukturfrage ist, dann braucht sie Verantwortung. Genau wie eine Brücke einen verantwortlichen Bauingenieur braucht, braucht eine Koordinationsinfrastruktur jemanden, dessen Aufgabe es ist, sie zu entwerfen, zu pflegen, zu messen und für ihr Funktionieren zu haften. In den meisten Organisationen gibt es diese Rolle nicht. Das ist keine Personalfrage; das ist eine strukturelle Lücke.

Drittens: Wenn Koordination eine Infrastrukturfrage ist, dann verändert sich, was Beratung leisten kann. Eine Beratung, die kommt, einen Plan abliefert und geht, hat eine Brücke geplant, aber sie nicht an der Realität getestet oder gebaut. Eine Beratung, die dauerhaft anwesend bleibt, ersetzt die Rolle, die intern verantwortet werden sollte. Die einzige verantwortliche Form von Beratung in dieser Disziplin ist eine, die explizit darauf zielt, sich selbst abzuschaffen.

Genau das ist die Praxis: wir gestalten Infrastruktur mit, wir bauen die interne Rolle, die Verantwortung übernimmt, wenn wir gegangen sind, und wir bauen die Strukturen, in denen diese interne Rolle funktionieren kann.

Die Tradition, in der wir stehen

Wenn jemand uns also fragt, in welcher Tradition wir stehen, ist die Antwort: in der Tradition derer, die Brücken bauen, Wasserwerke entwerfen, Stromnetze planen, Softwarearchitekturen entwickeln. In der Tradition derer, die seit zweihundert Jahren gelernt haben, dass komplexe Systeme, von denen Menschen abhängen, Entwurf, Pflege, Messung und Verantwortung brauchen.

Nicht in der Tradition der Organisationsentwicklung. Nicht in der Tradition des Change Managements. Nicht in der Tradition der post-bürokratischen Vordenker, deren Arbeit ich respektiere und von der ich gelernt habe, aber deren Disziplin diese Werkzeuge nicht zur Verfügung hat.

Was in der Hochbau-, Verkehrs- und Softwarearchitektur seit Generationen selbstverständlich ist, beginnt erst jetzt, sich in der Organisationsarbeit zu etablieren. Wir nennen es Infrastructure-First Organisational Thinking. Die praktische Disziplin heißt Collaboration Architecture. Die Werkzeuge sind dieselben, die Ingenieure schon immer benutzt haben. Es ist nur überraschend, dass sie hier so lange gefehlt haben.