Frank Gilbreth stellte um 1909 eine Kamera neben eine Baustelle und filmte Maurer beim Ziegelsetzen. Nicht um sie zu kontrollieren, jedenfalls nicht nur, sondern weil ihm aufgefallen war, dass niemand genau wusste, was beim Mauern eigentlich passiert. Das Ergebnis hielt er in seinem Buch über das Maurersystem fest: die Zahl der Handgriffe pro Ziegel ließ sich von achtzehn auf viereinhalb senken, wie der Wirtschaftshistoriker Brian Price in seiner Arbeit über die Gilbreths und die Vermarktung der Bewegungsstudie nachzeichnet. Kein besseres Werkzeug war dafür nötig. Nur ein neu gebautes Gerüst, anders gestapelte Ziegel und die genaue Beobachtung dessen, was ohnehin schon geschah.
Interessanter ist, was danach kam. Gilbreths eigene Maurer legten die Arbeit zweimal nieder, weil ihnen die Hoheit über ihr Handwerk genommen wurde; sein Bauunternehmen geriet trotz aller Bewegungsstudien in wirtschaftliche Schieflage. Die Diagnose stimmte. Die Einführung nicht.
Warum der Blick aufs Werkzeug zu spät kommt
Hundertfünfzehn Jahre später beginnen die meisten KI-Vorhaben an der Stelle, an der Gilbreth aufgehört hätte anzufangen: beim Werkzeug. Jemand testet ein Sprachmodell, es formuliert erstaunlich brauchbare Sätze, und aus diesem Erlebnis wird ein Projekt. Erst danach sucht man einen Bereich, in dem sich das Ganze einsetzen lässt. Meistens landet man beim Texten, weil das am sichtbarsten ist.
Das Muster ist so verbreitet, dass es einen Namen verdient hätte. Wie die Reihenfolge stattdessen aussieht, beschreibt der Serienrahmen: erst der Prozess, dann die Entscheidung über Automatisierung, dann das Werkzeug, zuletzt der Prompt. Werkzeug vor Aufgabe.
Dieser Beitrag ist der erste von sechs Teilen zu der Reihenfolge, die ich für sinnvoller halte und die im Serienrahmen beschrieben ist: erst der Prozess, dann die Entscheidung über Automatisierung, dann das Werkzeug, zuletzt der Prompt.
Wer mit dem Werkzeug beginnt, findet immer eine Verwendung dafür. Ob es die richtige war, stellt sich erst heraus, wenn die Lizenz verlängert werden soll.
Was eine Prozessdiagnose wirklich prüft
Eine Prozessdiagnose ist unspektakulärer, als der Name klingt. Sie nimmt einen einzelnen Vorgang, etwa die Freigabe einer Pressemitteilung, und schreibt auf, was tatsächlich geschieht: wie oft der Vorgang im Monat läuft, wie lange er von der ersten Zeile bis zum Versand dauert, wie viele Personen ihn anfassen, an welcher Stelle er liegen bleibt und wer wann etwas entscheidet.
Der Unterschied zwischen dem, was Beteiligte auf Nachfrage schätzen, und dem, was in Kalendern, Postfächern und Dateiversionen steht, ist regelmäßig der eigentliche Befund. Gefühlte Durchlaufzeit: zwei Tage. Tatsächliche: neun, davon sieben Warten.
Das ist Gilbreths Kamera, nur ohne Kamera. Erst sehen, was passiert. Dann entscheiden, was daran geändert wird.
Die drei Fragen vor jedem Prompt
Für den Anfang reichen drei Fragen, und sie kosten nichts außer Ehrlichkeit.
Erstens: Wie oft läuft dieser Vorgang wirklich, und wie viel Zeit vergeht dabei von Anfang bis Ende? Zweitens: Wo wartet er, und auf wen? Drittens: An welcher Stelle fällt ein Urteil, das jemand persönlich verantworten muss?
Die dritte Frage ist die unbequemste, weil ihre Antwort über alles Weitere entscheidet. Sie trennt die Vorgänge, die eine Maschine übernehmen darf, von denen, in denen sie nur zuarbeiten sollte. Genau an dieser Trennlinie sitzt der Kern der ganzen Sache: die Maschine kann Sätze produzieren, aber ob der Text die eigene Linie hält, entscheidet ein Mensch, der dafür geradesteht. Diese Trennung ist das Thema des zweiten Teils dieser Serie, Automatisieren oder unterstützen.
Fällt bei der zweiten Frage auf, dass ein Vorgang überwiegend wartet, ist übrigens schon klar, dass kein Sprachmodell hilft. Wartezeit beschleunigt man nicht durch schnelleres Schreiben.
Ein Sprachmodell kann eine Freigabe formulieren. Verantworten kann es sie nicht. Diese Grenze verschwindet nicht, wenn man sie ignoriert; sie wird nur teurer.
Wo RAND die eigentlichen Ursachen findet
Die RAND Corporation hat für den Bericht The Root Causes of Failure for Artificial Intelligence Projects fünfundsechzig Data Scientists und Ingenieure befragt, jeder mit mindestens fünf Jahren Praxis. Die fünf Ursachen, die dabei herauskamen, lesen sich wie ein Protokoll dessen, was passiert, wenn die Diagnose fehlt: Führung und Technik reden aneinander vorbei, weil nie festgelegt wurde, welches Problem gelöst werden soll; die Daten wurden nie für diesen Zweck gepflegt; die Technik wird von unten getrieben, weil sie interessant ist und nicht weil sie gebraucht wird; in den Betrieb der fertigen Lösung wird zu wenig investiert; und manchmal versucht jemand etwas, das heutige Systeme schlicht nicht können.
Vier dieser fünf Ursachen entstehen, bevor die erste Zeile Code geschrieben ist. Die Nachricht ist unbequem und tröstlich zugleich: das teuerste Versäumnis ist auch das billigste zu beheben.
Die Frage ist nicht, ob KI diese Aufgabe kann. Die Frage ist, ob diese Aufgabe die richtige war.
Pilotprojekt oder Feigenblatt
Pilotprojekte sind sinnvoll, sie werden nur regelmäßig mit ihrem Gegenteil verwechselt. Andrew Ng, früher Leiter von Google Brain, empfiehlt in seinem AI Transformation Playbook ausdrücklich, mit Projekten zu beginnen, die gelingen, nicht mit den wertvollsten. Sie sollen ein klar messbares Ziel haben, technisch machbar sein und innerhalb von sechs bis zwölf Monaten sichtbare Wirkung zeigen. Sein eigenes erstes Projekt bei Google war die Spracherkennung, nicht die Suche, und zwar mit Absicht.
Ehrlicherweise gehört dazu, dass Ng an Konzerne denkt, an Unternehmen mit Bewertungen ab einer halben Milliarde Dollar. Für ein Haus mit sechzig Beschäftigten sind sechs bis zwölf Monate keine Anlaufphase, sondern ein Geschäftsjahr. Der Gedanke überträgt sich trotzdem, in kleinerem Maßstab: ein Vorgang, ein messbares Ziel, ein Termin, an dem jemand nachrechnet.
Ein Feigenblatt erkennt man daran, dass diese Nachrechnung nie stattfindet. Die MIT-Untersuchung zum Stand der KI in Unternehmen, über die Fortune im August 2025 berichtete, kam zu dem Ergebnis, dass rund 95 Prozent der Pilotprojekte mit generativer KI keinen messbaren Ertrag in der Gewinn- und Verlustrechnung hinterlassen. Nicht, weil die Modelle schlecht wären. Weil niemand definiert hatte, woran der Erfolg abzulesen sein soll. Es scheitert die Kontrolle, nicht die Datenreife.
Ein Pilot hat ein Ziel, einen Termin und jemanden, der am Ende nachrechnet. Alles andere ist eine Anschaffung mit Präsentationsfolie.
Was das für Marketing und Kommunikation bedeutet
In Kommunikationsabteilungen ist die Diagnose einfacher als anderswo, weil die Vorgänge ohnehin dokumentiert sind. Jede Freigabeschleife hinterlässt eine Mail, jede Version eine Datei, jeder Report einen Termin im Kalender. Vier Wochen Rückschau genügen meistens, um zu sehen, wo die Zeit hingeht.
Was dabei regelmäßig auffällt: der Engpass ist selten das Schreiben. Er liegt in der Abstimmung, in der Suche nach dem letzten gültigen Stand, im Warten auf eine Freigabe, die jemand im Urlaub liegen lässt. Ein Sprachmodell, das schneller formuliert, verschiebt in dieser Lage nur den Stau.
Wie oft das schiefgeht, zeigt der Beitrag KI-Readiness in der Kommunikation; warum die Wahl des Modells dabei die am meisten überschätzte Entscheidung ist, steht in Das Modell ist nicht die Strategie.
Der Vorgang, der nicht schneller, sondern weg gehört
Manchmal endet eine Diagnose mit einem Ergebnis, das kein Anbieter je vorschlagen wird: der Vorgang gehört nicht beschleunigt, sondern gestrichen. Der Wochenreport, den seit zwei Jahren niemand öffnet. Die dritte Freigabestufe, die nie etwas geändert hat. Das Protokoll, das geschrieben und nie gelesen wird.
Ich habe das an eigenen Werkzeugen gelernt, teurer als nötig. Für das Redaktionssystem hinter dieser Website habe ich Funktionen gebaut, die technisch sauber liefen und im Arbeitsalltag nie gebraucht wurden, weil ich den Ablauf vorher nicht sauber genug beschrieben hatte. Wochen, die im Angebot nicht standen; niemandem sonst in Rechnung gestellt, aber bezahlt wurden sie trotzdem.
Die billigste Automatisierung ist die, die man nach der Diagnose nicht mehr braucht.
Gilbreth hatte am Ende recht mit seinen viereinhalb Handgriffen und trotzdem eine Baustelle, auf der gestreikt wurde. Wer heute einen Prozess vermisst, sollte die Menschen, die ihn ausführen, nicht erst danach fragen. Sie wissen ohnehin am genauesten, wo die Zeit versickert. Man muss die Kamera nur in die richtige Richtung halten.
Häufige Fragen
Eine Prozessdiagnose erfasst für einen einzelnen Vorgang, was tatsächlich passiert: wie oft er im Monat läuft, wie lange er von Anfang bis Ende dauert, wie viele Personen ihn anfassen, wo er liegen bleibt und wer wann entscheidet. Sie vergleicht diese Werte mit dem, was die Beteiligten schätzen. Die Lücke zwischen beidem ist meistens der eigentliche Befund.
Wie oft läuft der Vorgang wirklich, und wie viel Zeit vergeht dabei von Anfang bis Ende? Wo wartet er, und auf wen? An welcher Stelle fällt ein Urteil, das jemand persönlich verantworten muss? Die dritte Frage entscheidet darüber, ob eine Maschine den Vorgang übernehmen darf oder nur zuarbeiten sollte.
Daran, dass niemand nachrechnet. Ein echtes Pilotprojekt hat ein messbares Ziel, einen Termin und eine Person, die am Ende prüft, ob das Ziel erreicht wurde. Laut der MIT-Untersuchung zum Stand der KI in Unternehmen hinterlassen rund 95 Prozent der Pilotprojekte mit generativer KI keinen messbaren Ertrag in der Gewinn- und Verlustrechnung.
Ja, und das ist eines der wertvollsten Ergebnisse. Wochenreports, die niemand öffnet, dritte Freigabestufen, die nie etwas ändern, Protokolle, die geschrieben und nicht gelesen werden: solche Vorgänge gehören gestrichen statt beschleunigt. Ein Softwareanbieter wird das selten vorschlagen.