KI in der Business-Analyse: Nicht nur schneller, sondern auch gründlicher

Ein öffentlicher Auftraggeber im Gesundheitswesen, ein über Jahrzehnte gewachsenes Stammdatensystem in C++ und Oracle mit 11 Programmen, rund 200 Datenbanktabellen und etwa 2 Mio. Zeilen Code – und vier Monate Zeit, um daraus eine belastbare Ausschreibung für eine cloud-native Neuentwicklung zu machen. Das Wissen über das System steckt verteilt in Code, Dokumenten und den Köpfen der Fachmitarbeiter:innen. Wer hier nur die Kernbereiche analysiert, zahlt später: Übersehene Spezialfälle tauchen erst in der Umsetzung auf und werden zu teuren Nachträgen. Und je stärker KI die Implementierung beschleunigt, desto mehr wird die
Qualität der Anforderungen zum entscheidenden Engpass.

In diesem Beitrag zeigen wir, wie wir diese Aufgabe mit der Arbeitsumgebung OpenCode und dem Prozessrahmen BMAD gelöst haben, was die KI dabei tatsächlich gebracht hat – und wo sie uns Nerven gekostet hat. Unser Fokus liegt auf dem, was Entscheider:innen wissen sollten, bevor sie KI in der Business-Analyse einsetzen.

Warum „KI einfach draufwerfen“ nicht reicht

Klassische Business-Analyse stößt bei Legacy-Modernisierungen an bekannte Grenzen: sehr viele Informationen in begrenzter Zeit, Anforderungen, die sich im Projektverlauf ändern, Widersprüche und Ausnahmen, die erkannt und aufgelöst werden müssen. Die naheliegende Idee, alle Unterlagen in einen Chat zu kippen, löst diese Probleme nicht – sie verlagert sie:

• Fehlende Nachvollziehbarkeit: Ohne strukturierten Prozess gehen Zwischenergebnisse und deren Herkunft verloren.

• Kontrollverlust: Bei vielen Sessions und Quellen geht die Übersicht verloren, der Quellenbezug verschwindet.

• Kontextgrenzen: Umfangreiche Dokumentenlagen passen schlicht nicht in ein Kontextfenster.

• Halluzinationen und stille Annahmen: Unbelegte, aber plausibel klingende Aussagen, hinzugedichtete Details und unbemerkt getroffene Annahmen erzeugen Scheingenauigkeit – in Anforderungen verändern sie den Umfang, ohne dass es auffällt.

• Konflikt-Glättung: Sprachmodelle neigen dazu, Widersprüche zu harmonisieren, statt sie aufzudecken – in einer Anforderungsanalyse das Gegenteil dessen, was man braucht.

Unser Setup: OpenCode + BMAD als Prozessrahmen

Unser Setup kombiniert zwei Bausteine:

1. OpenCode ist die Arbeitsumgebung, in der die KI arbeitet. Sie erlaubt die Auswahl unterschiedlicher Modelle, trennt einen Plan-Modus (analysieren, abwägen) von einem Build-Modus (Dateien erstellen und ändern) und bindet Projektregeln, Skills und Agenten ein. Alle Ergebnisse landen versioniert in einem Git-Repository – nicht im Chatverlauf.

2. BMAD ist eine Arbeitsmethodik, die die Analyse entlang von vier Sichten strukturiert: Business (Geschäftsprozesse, Stakeholder), Model (Datenstrukturen, Systemfähigkeiten), Architecture (Module, Integrationen, nicht-funktionale Anforderungen) und Decision (Entscheidungen nachvollziehbar dokumentieren). Dazu gehören Agenten, die Rollen eines Softwareteams abbilden („Wer arbeitet an der Aufgabe?“ – etwa Business-Analyse, Architektur oder technische Redaktion), und Skills als standardisierte Arbeitsabläufe („Wie wird die Aufgabe ausgeführt?“ – etwa ein kritisches Review der aktuellen Analyse zur Aufdeckung von Widersprüchen und Inkonsistenzen).

Gearbeitet haben wir in Iterationen: Quellen aufnehmen, Dokumente und Code analysieren, Anforderungen ableiten, kritisch prüfen, offene Fragen in Interviews klären – und mit den Antworten die nächste Iteration starten.

Der Clou: Mehr Ergebnis in besserer Qualität

Der eigentliche Mehrwert lag für uns nicht in einzelnen beeindruckenden Antworten, sondern im Gesamtergebnis:

• Schnellere Wissensaufnahme: Interviews, Fachunterlagen und Legacy-Code ließen sich in kurzer Zeit erfassen, verdichten und miteinander verknüpfen. Die Fachgespräche haben wir aufgezeichnet und transkribiert; aus den Transkripten entstanden mit KI-Unterstützung strukturierte Protokolle, und offene Punkte flossen direkt in die Vorbereitung der nächsten Termine ein. Allein 18 Fachgespräche von jeweils zwei bis vier Stunden wurden so auf- und vorbereitet.

• Mehr Detailtiefe: Spezialfälle und Ausnahmen wurden mitgenommen, statt aus Zeitgründen unter den Tisch zu fallen. Ein seit Jahren nur als Symptom bekannter Exportfehler im Altsystem konnte durch die Kombination aus Code-Analyse und Fachgesprächen präzise lokalisiert und erklärt werden.

• Höhere Anforderungsqualität: mehr Anforderungen, präziser formuliert und über viele Dokumente hinweg konsistent gehalten.

Greifbar wird das an der Dokumentenkette des Projekts: Aus rund 197 Eingangsdokumenten und etwa 7.000 Code-Dateien entstanden 64 Analysedokumente, daraus 26 Arbeitspaket-Dokumente, die auch vom Kunden als vereinbarte Zwischenergebnis geprüft wurden und schließlich 3 finale Ausschreibungsdokumente – Ausschreibungsunterlage, Anforderungskatalog und Bewertungsmatrix. Die KI-Kosten dafür lagen bei rund 1.300 Euro.

„Am Ende stand eine Ausschreibung, die wir in dieser Tiefe und Konsistenz ohne KI in der verfügbaren Zeit nicht hätten erstellen können. Die KI war wie ein vollwertiges Teammitglied, welches die gesamte Projektlaufzeit unterstütze und für einen Tagessatz von 16€ arbeitete.“

Unsere Erfahrungen: einmal durch den Hype Cycle

Rückblickend lässt sich unser Projekt gut entlang des Gartner Hype Cycle erzählen.

Unsere Erfahrungskurve: Auf den schnellen Einstieg und erste beeindruckende Ergebnisse folgten hoher Review-Aufwand, Begriffsdrift und Formatprobleme. Gegenmaßnahmen wie ein Glossar, eine bewusste Modellwahl und klare Teamregeln führten schließlich zu einer stabilen, produktiven Arbeitsweise.

Gipfel der Erwartungen. Der Einstieg gelang erstaunlich schnell. Protokolle, Interviewvorbereitung und ein erster klickbarer Prototyp (HTML-Mockup) der Zielanwendung entstanden in kürzester Zeit – letzterer war der vielleicht beeindruckendste Moment des Projekts.

Tal der Enttäuschungen. Dann kam die Kehrseite. Die KI erzeugt viel Text in hoher Detailtiefe – und jemand muss ihn prüfen. Unsere Rolle verschob sich komplett weg vom Erstellen hin zum Reviewen. Das war ungewohnt und auf Dauer ermüdend; der Engpass lag fortan beim menschlichen Review. Hinzu kamen weitere Stolpersteine:

• Granularitäts-Falle: Sehr detailliert hergeleitete Aussagen erwiesen sich bei genauer Prüfung teils als nicht belastbar oder schlicht als unnötig. Mehr Detail heißt nicht automatisch mehr Wahrheit.

• Dokumentations- und Terminologie-Drift: Separat bearbeitete Dokumente entwickelten ihr eigenes Vokabular. Bei der Konsolidierung gingen zudem Tabelleninhalte unbemerkt und ohne Vorwarnung verloren – obwohl ausdrücklich eine 1:1-Übernahme gefordert war.

• Dateiformate: Beim Einlesen von PDF-, Word- und Excel-Dateien waren Prüfung und Nacharbeit nötig. In einem Fall wurden z.B. zwei Spalten einer Regeltabelle vertauscht interpretiert – aufgefallen ist das leider erst im fachlichen Review durch den Kunden.

• Lange Wartezeiten bei guten LLM-Modellen: Hochwertige (teure) LLM-Modelle erzeugen gute Ergebnisse, allerdings auch lange Wartezeiten für den bedienenden Menschen. Zwar kann man in opencode in mehreren Sessions arbeiten, dieses wird aber schnell unübersichtlich.

• Teamarbeit zu dritt: BMAD ist für eine Person mit einer KI gedacht. Wir haben zu dritt an gemeinsamen, versionierten Textdokumenten gearbeitet – und Merge-Konflikte waren oft inhaltlicher, nicht nur technischer Natur und damit schwer automatisiert auflösbar wie bei klassischen Merge-Konflikten in Programmcode.

Pfad der Erleuchtung. Geholfen haben vor allem einfache, disziplinierte Maßnahmen: ein Glossar für einheitliche Begriffe auch bei separat bearbeiteten Dokumenten, das LLM-Modell passend zur Aufgabe wählen, klare Zuständigkeiten pro Person und ein Single-Committer-Prinzip bei Durchgängen über das Gesamtdokument. Manche Korrekturen haben wir bewusst von Hand vorgenommen – bei sehr großen Dokumenten war das schlicht schneller als ein weiterer KI-Durchlauf. Und über 200 systematisch nachverfolgte offene Fragen mit Quelle und Verantwortlichen sorgten dafür, dass Widersprüche sichtbar blieben, statt geglättet zu werden. Und immer wieder: Kleinteilige Reviews aller produzierten Ergebnisse.

Plateau der Produktivität. Mit diesen Regeln hat sich eine stabile Arbeitsweise eingestellt, die wir heute so wieder wählen würden.

Fazit und Ausblick: Mit Struktur wird KI zum Qualitäts- und Produktivitätshebel

Ja, wir waren schneller. Doch der Geschwindigkeitsvorteil ist gedämpft – denn was die KI in Minuten erzeugt, müssen Menschen in Stunden prüfen und verantworten. Der eigentliche Gewinn liegt im Ergebnis: mehr Tiefe, mehr Vollständigkeit, mehr Konsistenz. Gute Business-Analyse wird durch KI also nicht überflüssig – im Gegenteil: Wenn die Umsetzung immer schneller wird, entscheidet die Qualität der Anforderungen über den Projekterfolg. Für Entscheider:innen heißt das:

• Prozessrahmen statt freiem Prompten: Eine Methodik wie BMAD macht KI-Ergebnisse nachvollziehbar und steuerbar.

• Review-Kapazität realistisch einplanen: Der Engpass verschiebt sich vom Erstellen zum Prüfen – und das ist anstrengend. Verteilen Sie diese Last auf mehrere Schultern.

• Glossar und Detailgrad früh festlegen: Das verhindert Begriffsdrift und ausufernde Detailtiefe.

• Modelle bewusst wählen: Leistungsfähige Modelle für Analyse und Planung, günstigere für klar abgegrenzte Aufgaben – und Sessions und Kontext klein halten, um Halluzinationen zu vermeiden.

• Teamarbeit organisieren: klare Zuständigkeiten, kleine Commits, ein Single-Committer bei Gesamtdurchgängen.

• Zeit für finale Formate einplanen: Der Wechsel von Markdown zu Word oder anderen gängigen Formaten ist ein eigener Arbeitsschritt.

Spannend ist, was sich mit der entstandenen Wissensbasis weiter anfangen lässt: Begleitende Dokumente wie ein Leistungsregister entstehen daraus mit wenig Aufwand, oder sie kann als Einarbeitungsgrundlage für das spätere Umsetzungsteam dienen. Auch einen dedizierten Projektplan mit Epics, Stories und Meilensteinen haben wir mit BMAD bereits daraus abgeleitet. Eine Teststrategie und begleitende Testmethodik konnten wir für die Ausschreibung ebenfalls erstellen aus der sich später problemlos aufgrund der beschriebenen Use Cases und Akzeptanzkriterien Testfälle ableiten lassen. Hier liegt das Potenzial einer durchgängigen Kette von den Anforderungen bis zur Umsetzung.
Offen bleibt für uns der Umgang mit vertraulichen Daten – hier sind Architekturen mit voller Datenhoheit gefragt, wie wir sie etwa in unserem Beitrag zum Self-Hosted Code-Copilot beschreiben. Wie KI bereits beim Formulieren von Anforderungen unterstützt, zeigt zudem unser Beitrag User Stories by KI.

Sie planen eine Legacy-Modernisierung oder möchten KI gezielt in Ihrer Business-Analyse einsetzen?
Wir unterstützen Sie gern – von der Analyse des Altsystems über die Anforderungserhebung bis zur fertigen Ausschreibung, inklusive der Einführung KI-gestützter Arbeitsweisen in Ihrem Team.