Warum die Zusammenarbeit scheitert, obwohl Sie in digitale Tools investiert haben
Sie haben eine Digitalisierungsstrategie. Sie haben Bereiche, die funktionieren müssten. Die Leute sind gut, die Technik ist gekauft, die Prozesse sind dokumentiert. Und trotzdem: zu viele Meetings. Entscheidungen, die nur laufen, wenn eine bestimmte Person im Raum ist. Die Fähigsten gehen; nicht, weil die Arbeit zu schwer wäre, sondern weil sie den ganzen Laden mit ihrer eigenen Improvisation zusammenhalten, bis sie nicht mehr können. Ein Mitarbeiter in einer sehr innovativen Industrieorganisation erzählte mir einmal, er habe in einem Jahr 8000 E-Mails aus Koordinationssystemen bekommen. Als er das bei seiner Führungskraft ansprach, war die Antwort: Lösen Sie es selbst.
Diese Art von Problem wird, je nach Führungskraft, entweder als Digitalisierungsproblem gelesen, oder als fehlende persönliche Kompetenz. Die Organisation beauftragt jetzt entweder Hilfe bei Digitalisierung oder Stärkung persönlicher Kompetenzen. Es gibt ein Projekt, ein Programm, einen Workshop.
Ich blicke auf eine Ausschreibung, in der sich das so liest: eine „Analyse des Digitalisierungsstands unter Berücksichtigung von Struktur, Prozessen, Technologie und Kompetenzen“. Struktur und Kompetenzen — wie die Organisation gebaut ist und was die Menschen können — werden unter „Digitalisierung“ verbucht. Wir nennen etwas digital, was wirklich noch nichts mit Technologie zu tun hat.
Manchmal benennen Organisationen die Lücke selbst: „Fragen der strukturellen Entwicklung“ seien „bisher noch nicht berücksichtigt“. Im gleichen Atemzug wird dann die Entscheidung getroffen, eine Digitalisierungs-Reifegradbewertung auszuschreiben.
Wo also stattdessen ansetzen, wenn das Organigramm zwar steht, aber Strukturen irgendwie fehlen? Hier erforschen wir einen Ansatz, für den wir den Begriff Collaboration Architecture gefunden haben. Die Arbeit nennt sich Infrastrukturdenken in der Organisationsarbeit.
Welche Infrastruktur?
Die, durch die die Wissensarbeit tatsächlich läuft. Wenn hier organisatorisch eine Lücke klaffte — die IT-Abteilung ist zu weit weg und sonst hat auch keiner die Verantwortung, diese Strukturen zu gestalten — ist die Koordinationsinfrastruktur, in der Menschen arbeiten, oft irgendwie selbst zusammengeschustert.
Der Grund, warum diese Strukturen bisher in der Organisationsarbeit übersehen werden, liegt in ihrer Natur: Sie sind unsichtbar, solange sie funktionieren. Gute Koordination, gute Infrastruktur erkennt man daran, dass Probleme gar nicht erst entstehen. An Reibung, die ausbleibt. Man bemerkt sie erst im Scheitern. Wie oft denken wir schon an die Versorgung mit Strom, Wasser, Internet in unseren Häusern und Büros? Wenn diese Koordinations-Infrastruktur scheitert, lesen wir es oft als Fehler im Individuum. Die Teams wollen nicht. Die Leute sind veränderungsmüde. Sie sind noch nicht so weit. Also schicken wir Coaches, bieten Resilienztrainings, arbeiten an der Haltung. Irgendwann wird Information in diesen Gesprächen ein Thema, aber die Maßnahme hatte absolut kein Mandat, daran etwas zu tun, selbst wenn im Angebot das Wort „systemisch“ auftaucht. Sie löst kein Strukturproblem. Und so werden ausgerechnet die Besten — die, die Probleme nicht ignorieren und immer wieder ansprechen — zu den Auffälligen, den Schwierigen.
Das alles ist teuer. Auch in Dingen, die nicht mit Geld gemessen werden können. Die Lasten sind real, sie werden mit diesen Nicht-Lösungen ständig abgewälzt — auf die Einzelnen, die das nicht gestaltete System mit unbezahlter Koordinationsarbeit tragen. Manchmal lassen die Kosten sich beziffern. Eingebettet als Designerin in einer Organisation beobachtete ich letztes Jahr eine Entscheidung, die in Minuten getroffen wurde, ohne Abstimmung mit dem Team, dessen Wissensarbeit sie betroffen hat. Der Koordinationsaufwand, den diese eine Entscheidung erzeugte, betrug ein Vielfaches dessen, was die Gestaltungsarbeit vorher gekostet hätte. Weil dieses Team dann mit der nachträglichen Gestaltung beschäftigt war, statt mit der eigentlichen Arbeit, die direktes Einkommen generiert hätte. Die Kosten gingen in die Millionen. Messen konnte ich das, weil ich im Umsetzungsteam saß und es messen konnte. Normalerweise messen wir das nicht. Dann verschwinden diese Kosten nicht; sie werden zu zusätzlicher Koordinationsarbeit, für die niemand Arbeitszeit eingeplant hat. Messbar wird es irgendwann in Produktivitätseinbußen. Die zusätzlichen Lasten, die von den Mitarbeitenden getragen werden, bleiben unsichtbar.
Der Begriff „Collaboration Architecture“ bedeutet einen Blickwechsel: von „die Abteilungen arbeiten nicht gut zusammen“ zu „die Infrastruktur, durch die Wissen fließt, wurde nie gestaltet.“ In dem Moment, in dem man das Problem als Infrastruktur sieht, wird es bearbeitbar, wie alles, was man gestaltet. Hier praktiziert man dann Design — mit den Menschen, die mit dem Ergebnis arbeiten sollen. Design heißt hier: Nutzendenforschung, Gestalten, Prototypen bauen, Testen, Anpassen, erst dann zementieren. Das passiert lange bevor das nächste Werkzeug eingekauft wird und ist nicht einfach nur der nächste Workshop, sondern sehr spezifisch ein Gestaltungsraum. Es ist absolut nicht einfach nur das nächste Coaching, obwohl eine Lernerfahrung unbedingt dazugehört: Diese nimmt ihren Fokus auf die Führungsebene. Auf der operativen Ebene ist der Bedarf klarer. Hier findet dann die Gestaltung der Organisation für effektive Wissensarbeit statt: technische Infrastruktur + Kultur + Gewohnheiten.
Das kann klein anfangen und braucht keine organisationsweite Zustimmung, keinen Umbau des gesamten Wertesystems. Ein Team, das einen ehrlichen Blick darauf richtet, wer die Lasten trägt, die eine Struktur tragen müsste. Die Erkenntnis, dass die überlasteten Menschen nicht das Problem sind, sondern Anzeichen für eine fehlende Struktur: das ist hier schon die eigentliche Arbeit.
Dass andere Disziplinen zur Gestaltung von Organisationen, wie Service Design, auf einer solchen Infrastruktur beruhen, die sie selbst nicht bauen und für die bislang keine Disziplin wirklich Verantwortung hat, habe ich ausführlich und peer-reviewed dargelegt.¹ Der Punkt für die Praxis ist einfacher: Bevor Sie die nächste Software kaufen, fragen Sie, ob das Problem, das sie lösen soll, überhaupt ein technisches ist. Oft ist die ehrlichere Frage: Wie sind unsere Strukturen aufgebaut? Und die beantwortet Ihnen kein Anbieter von digitalen Diensten.
¹ Collaboration Architecture: Service Design for Knowledge Work, Touchpoint – The Journal of Service Design (SDN), 17-2, 2026
Schreibe einen Kommentar