Beim Problem anfangen.
Im ersten Gespräch geht es darum, was konkret besser werden soll: eine Entscheidung, eine Übergabe, ein Bericht, dem niemand wirklich vertraut, ein Produktionsschritt, der sich nicht zuverlässig wiederholen lässt. Wo gehen heute Zeit, Qualität oder Informationen verloren? Wie sähe ein gutes Ergebnis aus? Und wer trägt dafür Verantwortung? Wenn es kein messbares Problem, keinen Zugang zu den relevanten Daten und keinen Owner gibt, ist KI noch nicht die Antwort. Und dann sage ich das auch.
Erst verstehen, was heute wirklich passiert.
Bevor ich etwas neu gestalte, schaue ich mir den aktuellen Zustand read-only an: Prozesse so, wie sie tatsächlich laufen. Die beteiligten Systeme. Ihre Daten. Wer welchen Schritt verantwortet. Und die Ausnahmen, die nur im Kopf einzelner Menschen existieren. Interviews, ein Blick in die laufenden Systeme, Daten- oder Repository-Audits – was immer die Situation braucht. Die produktiven Systeme werden in dieser Phase nicht verändert.
Festlegen, was wirklich gilt.
Fast jeder fragmentierte Prozess hat dasselbe Grundproblem: Dieselbe Information liegt an mehreren Stellen – aber niemand hat entschieden, welche davon verbindlich ist. Deshalb beginnt die Architektur für jede Art von Information – ERP, Shop, Ledger, Repository, Decision Log – mit drei Fragen: Welches System ist die Source of Truth? Wer darf hineinschreiben? Und wie lesen alle anderen Systeme daraus? KI auf einer ungeklärten Wahrheit produziert nur schneller selbstbewusste Antworten.
Entscheiden, wo KI hingehört – und wo nicht.
Ich zerlege Arbeit in Trigger, Schritte, Entscheidungen, Übergaben, Freigaben, Ausnahmen und Outputs. Dann wird entschieden, welche Teile deterministisch sind – und welche tatsächlich Interpretation brauchen. Schritte werden entfernt, vereinfacht, zusammengeführt, klassisch automatisiert oder mit KI neu gedacht. Wo Regeln feststehen und Schreibvorgänge kritisch sind, gewinnt konventionelle Automatisierung. KI verdient ihren Platz dort, wo Recherche, Klassifikation, Synthese, die Erklärung von Abweichungen oder unstrukturierte Inputs echten Mehrwert schaffen. Die besten Lösungen sind meistens hybrid. Einer der teuersten Fehler ist, KI dort zu bauen, wo eine saubere Integration die bessere Lösung gewesen wäre.
Architektur und Governance gehören zusammen.
Ein funktionierendes KI-System besteht aus weit mehr als seinem Modell: Systemgrenzen, Datenquellen, APIs und Connectoren, Model- und Provider-Routing, Agent-Rollen, Berechtigungen, Read/Write-Grenzen, geschützte Aktionen mit Human Gates, Kontext und Memory, Evidenz, Versionierung, Rollback und Monitoring. Und aus einer entscheidenden Frage: Wer besitzt das System nach der Übergabe? Governance wird vom ersten Entwurf an mitgebaut – nicht am Ende darübergelegt.
Kleine Einheiten. Sauber abgeschlossen.
Umsetzung passiert in der kleinsten Einheit, die vollständig und überprüfbar ist: eine klar abgegrenzte Änderung, ein nachvollziehbarer Ausgangszustand, definierter Scope, konkrete Tests und überprüfbare Evidenz. Work Units verbinden Geschwindigkeit mit Kontrolle. Und sie ermöglichen es internen Teams, Entwicklern oder Agenturen mitzuwirken, ohne dass die Architektur dabei verloren geht.
Erst der Beleg. Dann der Erfolg.
Nichts ist fertig, nur weil ein Agent behauptet, es sei fertig. Systeme werden gegen echte Commands, Tests, Builds, Browser- und Device-Checks, Screenshots und Diffs geprüft – Evidenz, die ein Mensch tatsächlich beurteilen kann. Dasselbe gilt fürs Business: Ein Pilot, der funktioniert, ist noch kein Produktionsprozess. Erst wenn jemand ihn besitzt und seine Fehlerzustände sichtbar sind, wird daraus eine belastbare Fähigkeit.
