Projekte starten selten nach Lehrbuch, egal ob in einer Behörde oder in der Industrie. Sie starten dort, wo der Druck am größten ist: bei Rückständen, langen Bearbeitungszeiten, politischen oder regulatorischen Erwartungen, bei einem Fachbereich, der schnell Entlastung braucht, oder bei einem Markt, der sich plötzlich verschiebt. Am Anfang steht eine Idee und ein leeres Dokument, oder eine Reihe von Workshops, aus denen Use Cases destilliert werden, die dann möglichst schnell in Umsetzung gehen sollen. Das funktioniert manchmal. Häufig produziert es aber Spezifikationen, die an der Realität vorbeigehen, weil die Realität nie explizit gemacht wurde.
Das Paradox lässt sich knapper fassen: Die meisten Projekte starten am falschen Ende, bei dem, was werden soll, statt bei dem, was schon da ist. Denn in den allermeisten Fällen liegen die Grundlagen für eine belastbare Lösung bereits vor. Daten existieren. Rollen existieren. Prozesse existieren. Zustände, Ereignisse, Übergaben sind alle da. Was fehlt, ist eine Form, in der diese Wirklichkeit für die Lösung lesbar wird. Und weil das fehlt, fängt jedes Projekt wieder bei null an, obwohl es auf einem reichen Bestand sitzt.
Drei Stufen, aufeinander aufbauend
Ein tragfähiges Vorgehen sortiert diese Arbeit in drei Stufen, die aufeinander aufbauen.
Die erste Stufe ist digital-twin-driven: ein lesbares Abbild der Unternehmens- oder Verwaltungsrealität mit den vorhandenen Daten, Prozessen, Rollen, Objekten, Zuständen, Ereignissen. Spielbar, auch wenn nicht perfekt und nicht vollständig. Neue Ideen lassen sich darin ausprobieren, bevor sie in produktive Systeme eingreifen. Varianten werden durchgespielt, Engpässe sichtbar, Wirkungen bewertet. Die Verwaltung ist plötzlich nicht mehr ein Katalog von Dokumenten, sondern eine Umgebung, in der gelernt werden kann.
Die zweite Stufe ist conceptgraph-driven: Die Beziehungen, Abhängigkeiten, Regeln und Kontextwechsel, die in den Daten und Prozessen stecken, werden explizit gemacht. Was hängt wovon ab? Welche Rollen lösen welche Ereignisse aus? Wo wechselt der Kontext von einem Verfahren in ein anderes? Das entstandene Netz, ein Concept Graph, macht sichtbar, was in klassischen Strukturen verborgen bleibt. [^s020] Viele Missverständnisse in Spezifikationen entstehen, weil die implizite Beziehungslogik von den Beteiligten unterschiedlich gedacht wird. Eine explizite Fassung löst das.
Die dritte Stufe ist spec-driven: Erst hier wird definiert, was die Lösung leisten soll, welche Rolle sie übernimmt, welche Daten sie nutzt, in welche Prozesse sie eingreift, welche Regeln gelten, woran Erfolg erkennbar ist. Dieses Spezifizieren geschieht auf einem Digital Twin und einem Concept Graph, die die Domäne schon abbilden. Die Spezifikation ist damit eine gezielte Auswahl aus einer bereits strukturierten Landschaft, kein Rate-Versuch ins Unbekannte.
Wo KI in jeder Stufe wirklich trägt
Wer die drei Stufen nur auflistet, verschenkt das Wesentliche. Die Rolle, die KI in jeder Stufe spielen kann, unterscheidet sich deutlich, und genau das macht das Modell interessant.
In der Digital-Twin-Stufe wird KI vom Antwort-Werkzeug zum Experimentier- und Optimierungshebel. Auf einer realitätsnahen Abbildung kann sie Prozesse simulieren, Varianten durchspielen, Auswirkungen sichtbar machen, bevor produktive Systeme verändert werden. Muster, Engpässe, Risiken und Verbesserungspotenziale werden erkennbar, ohne dass jemand in der echten Welt etwas kaputt macht.
In der Concept-Graph-Stufe wird KI präziser, weil sie nicht mehr aus Datenpunkten raten muss. Begriffe, Rollen, Objekte und fachliche Zusammenhänge sind strukturiert verfügbar, was aus Daten Kontext macht. Eine KI, die den Graphen kennt, sucht besser, begründet besser, entscheidet besser und halluziniert weniger, weil sie weniger erraten muss.
In der Spec-Stufe wirkt KI als Strukturierungs- und Übersetzungs-Werkzeug. Anforderungen, User Stories, Akzeptanzkriterien und Testfälle lassen sich schneller formulieren, Lücken und Widersprüche früher erkennen. Der operative Gewinn liegt in der Form: Die Spezifikation kann direkt in dem Schema gehalten werden, das Alistair Cockburn in Writing Effective Use Cases etabliert hat, also Use Cases mit Hauptabläufen, Alternativabläufen und Ausnahmeabläufen, jeweils mit expliziten Akzeptanzkriterien, die zugleich als Testfälle formuliert sind. Aus der Spec entsteht damit nicht erst eine Testsuite; sie ist bereits eine.
Was am Ende steht
Wenn alle drei Stufen durchlaufen sind, liegt etwas qualitativ anderes vor als ein Anforderungsdokument. Es liegt eine Spezifikation vor, die in die Domäne geerdet, in ihren Beziehungen explizit und mit Tests direkt verknüpft ist. Diese Spezifikation kann vom Team nicht nur gelesen, sondern als Ausgangspunkt für agentische Umsetzung genutzt werden. Sie wird zum Execution Contract: ein Paket aus klarem Ziel, Kontext, Eingaben, Constraints, erwarteten Outputs, Prüfregeln und Eskalationspunkten, das spezialisierte Agenten direkt ausführen können. Agenten wissen dadurch, was sie tun sollen, was sie nicht tun sollen und woran ihr Ergebnis gemessen wird. Die Anschlussfähigkeit an Nachbar-Verfahren bringt die Spezifikation aus dem Concept Graph mit, statt dass sie in der Umsetzung nachträglich rekonstruiert werden müsste. [^s114]
Für die Verwaltung ist das besonders relevant. Ein lokales Problem, etwa ein Fachbereich mit Rückstand oder eine politisch geforderte Entlastung, bleibt nicht eine Insellösung. Es wird Teil einer fachlichen Ordnung, die über das einzelne Projekt hinaus trägt. Das ist Anschlussfähigkeit.
Erst Ordnung, dann Fortschritt
Die verbreitete Annahme, schnelle Projekte entstünden durch schnelles Anfangen, trägt nicht weit. Schnelle Projekte entstehen durch solide Grundlagen, auf denen man schnell anfangen kann. Das ist etwas anderes. Digital Twin, Concept Graph und spec-driven entwickeln zusammen die Grundlage, auf der dann auch ein punktueller, druckgetriebener Einstieg zu einer strukturierten Lösung wird. KI wirkt dabei als Verstärker, unterschiedlich in jeder Stufe, aber nie als Ersatz für die fachliche Ordnung, die sie voraussetzt.
Grundlage dieser Serie sind Gespräche mit Projektleiter:innen in öffentlicher Verwaltung und Industrie über Probleme, an denen sie arbeiten, und Stellen, wo es hakt. Verdichtete Beobachtungen, keine Strategiepapiere.
