Wer dirigiert die Organisation von morgen?
Bild KI-generiert (Microsoft Copilot)
Wir befinden uns gerade in einem eigenartigen Zwiespalt. Auf der einen Seite steigt der Druck, jetzt mit KI handeln zu müssen. Jede Konferenz und jedes Board-Meeting suggeriert, wer heute nicht KI-ready ist, ist morgen abgehängt. Auf der anderen Seite wächst gleichzeitig eine spürbare KI-Hype-Müdigkeit. Dabei geht es den meisten Organisationen in erster Linie nicht um Innovation, sondern um Effizienzgewinne. Ein nachvollziehbares, aber folgenreiches Missverständnis, denn genau in dieser Lücke zwischen Ambition und Zielsetzung entsteht ein Großteil der Enttäuschung, die man derzeit über KI-Projekte hört.
Neu ist diese Entwicklung nicht. Neu ist allerdings die Kombination aus Geschwindigkeit, wirtschaftlichem Druck und Unsicherheit, die gleichzeitig aufeinandertrifft und dabei eine Intensität erreicht, die frühere Technologiewellen wie Cloud, Apps oder Microservices so nicht kannten.
Was macht es gerade so schwierig?
Wer sich die Unternehmenslandschaft ehrlich ansieht, erkennt schnell, dass die zentrale Schwäche nicht in fehlender Technologie liegt. Modelle, Tools und Frameworks sind verfügbar, oft sogar im Überfluss. Das eigentliche Problem ist die Umsetzung. Viele Initiativen kommen bis zur Entscheidung und bleiben dort stehen. Sie schaffen es selten in die produktive Nutzung.
Die Gründe dafür sind selten technischer Natur. Fehlende Befähigung, sinkende Entscheidungsbereitschaft, kurze Planungshorizonte und ein ausgeprägtes Absicherungsverhalten bremsen die Umsetzung. Genau hier liegt jedoch der eigentliche Wettbewerbsvorteil. Er steckt nicht in Tools oder Modellen, sondern im unternehmensspezifischen Kontext, also im Wissen, in den Prozessen und in der Entscheidungslogik. Dieser Kontext wird zum zentralen Differenzierungsfaktor. Wer ihn nicht strukturiert verfügbar macht, wird auch mit dem besten Modell keine relevanten Ergebnisse erzielen.
Die Gretchenfrage nach der Wertschöpfung
Damit kommen wir zur eigentlich spannenden Frage, die viel zu selten offen gestellt wird. Was ist heute Wertschöpfung, und wie sieht sie morgen aus?
Die Art, wie die Wertschöpfung von Produkten gesteuert wird, vom Turnschuh bis zur Versicherungspolice, verändert sich gerade grundlegend. Gesteuert wird zunehmend über Daten, Software und automatisierte Entscheidungslogik. Produktdesign, Pricing, Produktionsplanung, Qualitätssicherung und Kundenschnittstelle laufen immer stärker technologie- und datengetrieben. Das verändert Organisationen und Skills gleichermaßen. Wer diese Steuerung beherrschen will, braucht andere Strukturen und Kompetenzen als eine klassisch funktional gegliederte Organisation.
Daraus folgt eine unbequeme Reihenfolge. Bevor man über Tools, KI oder neue Prozesse und Produkte spricht, gehört eine Frage davor. Wie sieht eine Organisation aus, die für die Wertschöpfung von morgen optimiert ist, und wie weit sind wir davon entfernt? Im Mittelstand wird diese Frage fast nie gestellt, weil sie zu groß und zu unbequem ist. Dabei ist sie die einzige Frage, deren Antwort Tools, KI, Skills und Prozesse überhaupt sinnvoll positioniert.
Der Re-Design-Dreischritt
Aus dieser Erkenntnis ergeben sich drei Schritte, die in dieser Reihenfolge bearbeitet werden sollten und die zugleich einen möglichen Veränderungsweg beschreiben.
Der erste Schritt ist das Wertstrom-Mapping. Wo entsteht heute Wert, und wo wird er morgen entstehen? Welche Wertströme gibt es, und wer ist heute organisatorisch dafür verantwortlich? An dieser Stelle wird häufig sichtbar, dass die Verantwortung für die Wertschöpfung von morgen nicht klar verankert ist. Sie liegt zwischen Funktionen, Bereichen und Zuständigkeiten und damit oft bei niemandem.
Der zweite Schritt ist das Operating-Model-Design. Wie muss die Organisation aufgestellt sein, damit die neuen Wertströme bedient werden können? Welche neuen Einheiten braucht es, welche alten lösen sich auf, und welche werden anders zugeschnitten?
Der dritte Schritt ist die Übergangs-Architektur. Wie kommt man vom heutigen Modell zu einem Neuen, ohne das laufende Geschäft zu gefährden? Das ist der schwierigste Teil, und der Teil, an dem die meisten Re-Designs scheitern. Die Antwort liegt selten im großen Wurf, sondern in einer parallelen Doppelstruktur, in der das Neue wachsen kann, während das Alte noch trägt.
Was ist eine Global Process Organisation, und warum jetzt?
Genau an diesem Punkt setzt ein Organisationsmodell an, das derzeit an Fahrt gewinnt, die Global Process Organisation, kurz GPO.
Die klassische Organisation ist entlang von Funktionen gegliedert. Business definiert eine Anforderung und gibt sie weiter, IT übersetzt und baut, liefert zurück. Dazwischen liegen Übergaben, Informationsverluste und unterschiedliche Zeithorizonte, die einen latenten Grundkonflikt erzeugen, den fast jede Organisation kennt. Business wirft IT vor, nicht zu verstehen, was das Geschäft braucht. IT wiederum kritisiert, dass Business nicht versteht, was technisch sinnvoll oder überhaupt möglich ist.
Eine GPO bricht mit diesem Schnitt. Statt entlang von Abteilungen wird entlang von Wertströmen organisiert. Ein Prozess wie die Erstellung eines personalisierten Kundenangebots oder die automatisierte Prüfung und Freigabe einer Rechnung wird end-to-end von einer Einheit verantwortet, die Business-, Tech- und Datenkompetenz bündelt, statt sie über Abteilungsgrenzen zu verteilen.
Ein Beispiel macht das greifbar. Bei der Rechnungsprüfung ist in der klassischen Organisation der Einkauf für die Bestellreferenz zuständig, die Buchhaltung für Kontierung und Archivierung und die IT für die ERP-Schnittstelle. Niemand verantwortet die Durchlaufzeit als Ganzes, denn die Verzögerungen entstehen an den Übergaben. In einer GPO gehört der gesamte Prozess einer Einheit. Ein Process Owner verantwortet das Ergebnis end-to-end, ein Data-Analyst automatisiert Abgleich und Plausibilitätsprüfung, und ein Entwickler:in pflegt die Logik direkt im Team, ohne Umweg über andere Abteilungen. Statt eines Prozesses, der durch vier Abteilungen wandert, gibt es eine Einheit von der Rechnungserfassung bis zur Zahlungsfreigabe.
Warum gerade jetzt? Weil KI und agentenbasierte Softwareentwicklung genau die technische Hürde auflösen, die GPOs bisher unpraktikabel gemacht hat. Business konnte bislang nicht einfach technische Logik umsetzen, sondern musste beschreiben, übersetzen lassen und warten. Heute kann es, zumindest in ersten Entwürfen, selbst bauen. Damit wird die GPO nicht nur ein theoretisch elegantes Organisationsmodell, sondern ein praktisch umsetzbares. Sie ist im Kern das Ergebnis konsequenten Wertstrom-Mappings und Operating-Model-Designs, also die Organisationsform, die entsteht, wenn man wirklich nach Wertströmen statt nach Funktionen schneidet.
Vibe Coding goes Professional
Ein sichtbares Symptom dieser Verschiebung ist das, was inzwischen Vibe Coding genannt wird. Fachbereiche bauen selbst funktionierende Software-Prototypen, ohne den klassischen Umweg über ein IT-Ticket. Was vor kurzem noch als Spielerei galt, wird zunehmend professionalisiert. Business-Anwender:innen beschreiben nicht mehr nur, was sie brauchen, sondern erzeugen einen ersten funktionsfähigen Entwurf, oft direkt mit KI-Unterstützung.
Das ist mehr als ein Produktivitätstrend. Es ist der praktische Vollzug dessen, was die GPO organisatorisch verspricht. Die Grenze zwischen fachlicher Anforderung und technischer Umsetzung verschwimmt immer mehr.
Vom Ausführenden zum Spezifizierenden und Prüfendem
Damit verändert sich zwangsläufig auch die Rolle der klassischen IT. Aus deterministischer Ausführung wird probabilistische Aufsicht. Früher war jeder Schritt selbst geschrieben, und wer skalieren wollte, musste entweder Kontrolle abgeben oder wurde unsauber. Fehler konnten entstehen, übersehen werden und Schaden anrichten. Diese Logik verschiebt sich.
In der neuen Rolle definiert die IT das Zielbild und die Limitationen. Multi-Agenten-Systeme entwerfen das Ergebnis. Fehler sind Teil der Logik und werden im Prozess korrigiert, nicht mehr ausschließlich vorab vermieden. Aus der Rolle der entwickelnden Person als ausführende Instanz wird die Rolle einer entwickelnden Person, die spezifiziert, steuert und Ergebnisse prüft. Das ist ein fundamentaler Rollenwechsel, nicht weniger verantwortungsvoll, aber anders verantwortlich.
Agentic Coding im Realitätscheck
So verlockend dieses Bild klingt, es verdient einen nüchternen Blick. Agentenbasiertes Coding zeigt in der Praxis ein zweischneidiges Ergebnis. Auf der Habenseite steht ein spürbarer Produktivitätsschub, in Teilbereichen sogar vollständig KI-generierter Code, eine deutlich schnellere Time-to-Market und ein Schließen von Ressourcenlücken, die viele Organisationen ohnehin plagen.
Auf der Sollseite steht ein ebenso deutlicher Befund. Fast doppelt so viele Bugs wie zuvor, knapp fünfundzwanzig Prozent mehr Sicherheitslücken und ein spürbarer Kontrollverlust, ein gewisses Eigenleben der Agenten, das sich nicht einfach wegwünschen lässt.
Diese Punkte zeigen, wie wichtig es ist, beim Einsatz von Agentic Coding die Governance-Frage von Beginn an zu stellen.
Wer dirigiert die GPO? Die Techies-These
Damit stellt sich die eigentliche Machtfrage der neuen Organisation. Wer übernimmt die Orchestrierung, wenn Business selbst bauen kann und IT vom Ausführenden zum Prüfenden wird?
Eine steile, aber gut begründbare These lautet, dass die Gewinner und Strippenzieher dieser Entwicklung nicht die Business-Manager:innen sind, die sich selbst als breit aufgestellte Generalisten mit KI-Kompetenz verstehen. Prozesswissen allein reicht nicht, um mit KI zum Disruptor bestehender Kräfteverhältnisse zu werden. Entscheidend ist vielmehr das Verständnis technischer Muster und Architekturen hinter der Wertschöpfungskette, also die Fähigkeit, die eigene Wertschöpfung in Technologie zu abstrahieren. Das ist die neue Must-have-Kompetenz.
Mit anderen Worten verschiebt sich das Gewicht. Wer technische Tiefe und Business-Verständnis verbindet, hat in der neuen Organisation zunehmend bessere Chancen, und oftmals haben Techies mit Business-Verstand hier die Nase vorn. Der Grund liegt in einer Asymmetrie. Business-Verständnis lässt sich in der Regel leichter vertiefen als technisches Verständnis, weil Techies durch den täglichen Umgang mit Systemen ohnehin viel von den Business-Strukturen kennen, die diese Systeme abbilden. Umgekehrt ist der Weg von Business zu echter technischer Tiefe steiniger, gerade im Bereich der KI-Technologie, die selbst erfahrene Techies an Grenzen bringt. Die Dirigent:innen der neuen Organisation kommen damit häufiger aus der Technik als aus dem klassischen Management.
Company Knowledge Graphs als Betriebssystem der GPO
Egal wer orchestriert, ohne eine gemeinsame Wissensbasis bleibt jede Orchestrierung Stückwerk. Der Übergang von reinen Datenplattformen zu agentenbasierten Systemen gelingt nur, wenn die organisatorischen Hausaufgaben vorher gemacht wurden. Kontext ist King. Daten allein werden nicht mehr handhabbar, der Business-Kontext muss jederzeit passen.
Genau hier setzen Company Knowledge Graphs an. Sie sind das Betriebssystem der Cloud-Native-Ära 2.0 und vernetzen alle Systeme endgültig, nicht als weiteres Tool, sondern als strukturelle Voraussetzung dafür, dass Agenten, Menschen und Prozesse auf derselben Wissensbasis arbeiten. Ohne diese Grundlage bleibt jede noch so ambitionierte GPO eine Ansammlung leistungsfähiger, aber isolierter Insellösungen.
Löst das den Konflikt zwischen IT und Business, oder verschiebt er sich nur?
Nach so viel struktureller Neuordnung liegt eine verlockende Schlussfolgerung nahe. Die GPO löst endlich den alten Grabenkampf zwischen IT und Business. Diese Schlussfolgerung ist zur Hälfte richtig, und genau deshalb gefährlich, wenn man sie unreflektiert übernimmt.
Was tatsächlich gelöst wird, ist die klassische Übergabe-Reibung. Wenn ein Team einen Wertstrom End-to-End verantwortet und Business-Mitarbeiter:innen erste Entwürfe selbst bauen können, entfällt genau der Übersetzungsverlust, der den klassischen Konflikt historisch erzeugt hat.
Was sich jedoch lediglich verlagert, ist der Grundkonflikt zwischen Geschwindigkeit und Kontrolle. Die zuvor genannten Zahlen, fast doppelt so viele Bugs und ein Viertel mehr Sicherheitslücken, zeigen, dass der Konflikt nicht verschwindet, sondern sich in das Team selbst verlagert - zwischen schneller Entwicklung per Vibe Coding und der Verantwortung für ein belastbares Ergebnis. Es ist derselbe Interessenkonflikt wie zuvor, nur ohne Abteilungsgrenze dazwischen.
Auch die Orchestrator-Frage selbst ist eine Machtverschiebung und kein neutraler Fortschritt. Wenn Techies mit Business-Verstand die GPO künftig dirigieren, verschiebt sich das Gewicht weg von klassischen Business-Leadern, eine Entwicklung, die nicht überall widerspruchslos akzeptiert werden dürfte.
Diese Machtverschiebungen machen deutlich, dass Governance durch die GPO noch notwendiger wird. Als Schiedsrichter:in zwischen zwei Abteilungen wird sie zum Korrektiv zwischen Tempo und Risiko innerhalb eines Prozesses.
Governance als Steering Committee und Teil der Übergangs-Architektur
Damit landet die eigentliche Schlüsselfrage weniger bei der Technologie als bei der Entscheidungslogik. Wer entscheidet, wenn Business selbst baut, IT prüft statt ausführt und Agenten mitgestalten? Ein funktionierendes Steering Committee übernimmt dabei nicht die klassische Rolle des Flaschenhalses zwischen Fachbereich und IT, sondern die Rolle des Übersetzers zwischen Wertstrom-Ambition und tragfähigem Risiko.
Architekturentscheidungen dürfen dabei nicht fremdvergeben werden, klare Entscheidungskompetenz und Mandate sind Pflicht, keine Kür. Die Governance selbst sollte konsequent als Teil der Übergangs-Architektur verstanden werden, als jene parallele Doppelstruktur, in der die neue GPO wachsen kann, während die alte Organisation noch trägt. Keine einmalige Entscheidung, vielmehr ein lernendes System, das mit jeder neuen Eskalation nachschärft, wo die Grenze zwischen Autonomie und Kontrolle heute richtig verläuft.
Fazit: Re-Design vor Tools
Am Ende führt jede Diskussion über Vibe Coding, Agentic AI und Orchestratoren zur selben Ausgangsfrage zurück. Was ist heute Wertschöpfung, und wie sieht sie morgen aus? Wer diese Frage nicht beantwortet hat, wird jedes Tool, jedes Modell und jede Organisationsreform an der falschen Stelle ansetzen.
Ob sich eine GPO lohnt, hängt davon ab, zu welchem Grad die Wertschöpfung durch Daten und datengetriebene Entscheidungen gesteuert wird. Die Vulkanisierung einer Sohle beispielsweise ist keine GPO-Domäne. Welche Maschine, wann welche Sohle mit welcher Materialcharge produziert, dagegen schon. Entsprechend betrifft das längst viele Bereiche. Produktionssteuerung, Schadensregulierung oder Patientenaufnahme sind allesamt Wertströme, die von end-to-end-Verantwortung profitieren, am stärksten dort, wo hohe Wiederholungsfrequenz, Automatisierungspotenzial und Datenintensität zusammenkommen. Erst dann rechtfertigt sich eine global einheitliche, funktionsübergreifende Einheit.
Genau deshalb ist die Global Process Organisation kein Selbstzweck und keine Blaupause, die man einfach überstülpt. Sie ist die konsequente Antwort auf eine Wertschöpfung, die zunehmend digital, kontextgetrieben und agentisch unterstützt gesteuert wird. Ihre Auswahl ist selektiv, ihre Organisation aber konsequent global. Wer einen Wertstrom als GPO definiert, hebt ihn vollständig aus lokalen und funktionalen Strukturen heraus.
Damit löst die GPO den alten Konflikt zwischen IT und Business nicht auf, sie verlagert ihn. Weil Tech- und Business-Kompetenz in derselben Einheit sitzen, verliert die Frage, wer entscheidet, dort an Bedeutung. Sie verlagert sich jedoch eine Ebene höher, etwa zwischen mehrere GPO-Einheiten oder gegenüber zentralen Funktionen wie Datensicherheit und Architekturstandards. Und eine andere Frage rückt in den Vordergrund. Wie viel Tempo und Entscheidungsfreiheit kann die Organisation den einzelnen Einheiten zugestehen, ohne die Kontrolle über Risiken, Konsistenz und Haftung zu verlieren? Diese Abwägung ist kein neues Phänomen dezentraler Autonomie, gewinnt in der GPO aber an Gewicht, weil die Einheiten mehr Verantwortung und technologische Hebelwirkung bündeln als klassische Teams.
Genau diese Frage, nicht die nächste Tool-Entscheidung, sollte heute auf der Agenda jedes Steering Committees stehen.
