KI im Business-Analyst-Workflow: Wo sie hilft, wo sie versagt

Es ist 9:14 Uhr an einem Montag. Ein VP leitet einen Slack-Screenshot weiter. Der neue KI-Assistent des CSM-Tools meldet, dass aktive Kunden im letzten Quartal um 38 % gewachsen sind. Die Führungskraft möchte diese Zahl bis Mittag in einem Board-Deck haben.

Sie öffnen das Warehouse. Der tatsächliche Wert liegt näher bei 12 %. Der Chatbot hat jede Zeile in customers gezählt, unabhängig von status, das is_test-Flag ignoriert, das Ihr Data Engineer im Februar hinzugefügt hat, und eine Metrik, die sich monatlich zurücksetzt, still als kumulativ summiert. Sie haben jetzt vierzig Minuten, um zu erklären, was schiefgelaufen ist, ohne wie jemand zu klingen, der Angst hat, automatisiert zu werden.

Das ist das Leben des BA jetzt. Jedes BI-Tool liefert eine "In Klartext fragen"-Funktion. Jede IDE hat eine Autovervollständigung, die Joins schreibt. Der Großteil der Ausgabe ist falsches-aber-sicheres SQL: Abfragen, die laufen, Zahlen zurückgeben und auf eine Weise falsch zählen, die keine Leitplanken auslöst. Jemand muss die letzte Verteidigungslinie sein. Diese Person sind immer noch Sie, und die Tools haben die Arbeit nicht so sehr leichter gemacht, sondern verschoben, wo die schwierigen Teile liegen.

Hier ist die Sichtweise des arbeitenden BA, geschrieben für Menschen, die echte Dashboards ausgeliefert und echte Fehler gemacht haben.

Wo KI dem BA wirklich hilft

Hier gibt es echten Hebel. Ihn aus Prinzip abzulehnen ist dieselbe Energie wie bei Analysten, die 2014 darauf bestanden, jeden Join von Hand zu schreiben, weil IDEs "für Junioren" seien. Die Arbeit hat sich verändert. Fünf Bereiche, wo KI ihren Wert beweist:

SQL-Entwürfe zum Refactoring. Grundlegende Joins, Window-Function-Syntax, Regex für das eine Log-Feld, das niemand dokumentiert hat. Sie geben Claude die Spaltennamen und eine einzeilige Beschreibung dessen, was Sie wollen, und erhalten eine Abfrage zurück, die zu 70 % korrekt und zu 100 % besser ist als bei einer leeren Datei zu beginnen. Dann refaktorieren Sie sie. Das Modell ist schneller als Ihre Finger; Ihre Finger waren ohnehin nie der Engpass.

Dashboard-Schema-Dokumentation. Dreiundvierzig Spalten in fact_orders, drei davon mit Namen wie flag_2 und legacy_amt_v3. Fügen Sie das Schema und den letzten Commit-Verlauf in ein Modell ein und bitten Sie es, Spaltenbeschreibungen zu entwerfen. Sie werden die Hälfte davon korrigieren. Sie werden auch Dokumentation geschrieben haben, die zuvor nicht existierte, was besser ist als die Version, in der sie nie geschrieben wird.

Vorbereitung auf Anforderungsinterviews. Bitten Sie das Modell vor einem Stakeholder-Kickoff, die unangenehmen Fragen zu generieren, die Sie vergessen, wie "Was bedeutet 'abgewandert' hier, Kalendermonat oder rollend 30 Tage?" oder "Wie gehen wir mit Konten um, die im selben Zeitraum downgraden und dann upgraden?" Das Modell kennt Ihr Unternehmen nicht. Es ist gut darin, Sie an die Kategorien von Fragen zu erinnern, die Sie ohnehin stellen müssen.

Anomalieerkennung bei bekannten Datensätzen. Richten Sie ein Modell auf eine Zeitreihe und fragen Sie: "Wo würde ein sorgfältiger Mensch zuerst nachsehen?" Es wird die richtigen Dinge markieren: plötzliche Null-Spitzen, Punkt-in-Zeit-Spitzen, Tage, an denen die Zeilenanzahl auf eine gerundete Zahl fällt, die auf eine Teilladung hindeutet. Sie müssen trotzdem untersuchen. Das Modell komprimiert nur das Scannen.

Datenwörterbuch-Pflege. Jira-Tickets in Glossareinträge umzuwandeln ist eine echte Mühe. Ein geschlossenes Ticket in ein Modell einzuspeisen und nach einer Ein-Absatz-Definition zu fragen, ist die Art mechanischen Schreibens, die KI ausreichend erledigt und zu der Sie sonst nie kommen würden.

Beachten Sie das Muster: KI ist nützlich, wenn die Eingabe begrenzt ist und Sie der Editor bleiben. In dem Moment, in dem das Modell der endgültige Autor ist, beginnt es zu schlüpfen.

Wo KI still versagt

Dies ist der Abschnitt, der zählt. Die Fehler sind nicht laut. Die Abfrage läuft. Das Diagramm wird gerendert. Die Zahl ist falsch auf eine Weise, die dreißig Minuten Warehouse-Archäologie erfordert, um sie zu beweisen.

Datensemantik. Ihre orders-Tabelle hat eine status-Spalte mit Werten wie pending, processing, shipped, delivered, returned, void, chargeback und legacy_v2. Welche davon bedeutet "tatsächlich ein Verkauf"? Ihr Finance-Team hat eine Meinung. Ihr Ops-Team hat eine andere. Das Modell kennt keine der beiden und wählt die plausibelst klingende Option, meist delivered, was in ca. 8 % der Fälle falsch ist, weil Retouren in einem separaten Batch gebucht werden.

Null-Behandlung. Das Modell greift standardmäßig auf WHERE column IS NULL zurück. Ihr Warehouse verwendet leere Strings, Sentinel-Daten wie 1900-01-01, den literalen String "NULL" und eine Spalte, in der fehlende Werte als -999 kodiert sind. Das Modell wird keines davon erkennen, außer Sie teilen es ihm mit. Die meisten BAs vergessen es mitzuteilen, weil sie die Eigenheiten internalisiert haben und sie nicht mehr sehen.

Geschäftslogik. "Aktiver Kunde" hat in jedem Warehouse, das älter als zwei Jahre ist, mindestens sechs Definitionen. In diesem Monat eingeloggt. Hat ein bezahltes Abonnement. Hat ein bezahltes Abonnement und befindet sich nicht in der Mahnstufe. Hat ein bezahltes Abonnement, befindet sich nicht in der Mahnstufe und ist nicht als Testkonto markiert. Hat das Produkt in den letzten 14 Tagen genutzt. War laut Finance-Snapshot am Monatsende aktiv. Das Modell wird eine auswählen. Es wird Ihnen nicht sagen, dass es eine ausgewählt hat. Der CRO wird die resultierende Zahl in einem Board-Meeting zitieren.

Governance. Das Einfügen von Kundenzeilen in ein Chat-Fenster ist ein Datenexfiltrations-Ereignis. Das Einfügen des Schemas ist grenzwertig. Das Einfügen von Abfrageplänen, die echte PII enthalten, ist ein echter Vorfall. Die meisten BAs denken nicht daran, dass "Claude fragen" eine Datenbewegung ist, aber Legal tut es absolut, und so auch der nächste Prüfer.

Ich habe jeden dieser Fälle in den letzten zwölf Monaten bei einer echten Analyse schiefgehen sehen. Keiner kündigt sich an. Die Abfrage läuft. Das ist der Punkt.

Die Cursor-und-Claude-Schleife für SQL

So funktioniert es in der Praxis, für mich und die BAs, denen ich vertraue:

Schritt 1: Annahmen vor dem Code erzwingen. Der erste Prompt ist nie "Schreibe die Abfrage." Er lautet: "Bevor Sie SQL schreiben, listen Sie jede Annahme auf, die Sie machen müssten, um diese Frage gegen dieses Schema zu beantworten." Fügen Sie die relevanten Tabellendefinitionen ein. Das Modell gibt eine Liste zurück. Sie bearbeiten sie. Etwa ein Drittel der Annahmen werden falsch sein, und Sie streiten lieber mit einer Liste als mit einer fertigen Abfrage.

Ein echtes Beispiel. Die Frage: "Monatlich aktive Konten nach Plantier für Q1." Die Annahmen des Modells, leicht bearbeitet:

1. "Aktiv" bedeutet last_activity_at innerhalb des Kalendermonats.
2. Plantier ist accounts.plan_id verbunden mit plans.tier_name.
3. Testkonten (is_test = true) sind ausgeschlossen.
4. Free-Trial-Konten zählen als aktiv.
5. Konten mit mehreren Planwechseln in einem Monat werden ihrem Plan am Monatsende zugeordnet.
6. Zeitzone ist UTC.

Punkte 4 und 5 sind falsch für unseren Berichtsstandard. Free-Trial-Konten zählen nicht, und wir ordnen nach dem Plan zu Monatsbeginn zu, weil Finance das so macht. Das hier zu erkennen, bewahrt Sie vor einer Abfrage, die die richtige Form mit den falschen Zahlen meldet.

Schritt 2: In Cursor entwerfen. Mit korrigierten Annahmen bitten Sie um die Abfrage. Cursors Editor zeigt das Schema in der Seitenleiste, was bedeutet, dass das Modell weniger wahrscheinlich Spaltennamen halluziniert. Es wird trotzdem ein oder zwei halluzinieren. Deshalb lesen Sie es.

Schritt 3: Wie einen dbt-PR refaktorieren. Behandeln Sie die KI-generierte Abfrage so, wie Sie den PR eines Juniors behandeln würden. Kommentare oben, die Zweck, Annahmen und "KI-unterstützter Entwurf, refaktoriert von [Ihnen]" vermerken. Inline-Anmerkungen zu nicht offensichtlichen Joins. Testzählungen am Ende (SELECT COUNT(*) FROM final gegen eine bekannte Referenz), bevor Sie das Ergebnis an jemanden senden.

Schritt 4: Zweimal gegen das Warehouse ausführen. Einmal mit einem kleinen Datumsbereich zur Plausibilitätsprüfung der Form. Einmal mit dem echten Bereich für die Antwort. Wenn beide Zahlen unplausibel klingen, sind sie es. Das Modell hat null Meinung zur Plausibilität. Sie schon.

Diese Schleife ist für die meisten nicht-trivialen Abfragen nicht langsamer als das Schreiben von SQL von Grund auf. Sie ist erheblich schneller. Sie ist auch erheblich sicherer als die Version, in der Sie den ersten Entwurf akzeptieren.

Die "KI hat diese Abfrage generiert"-Falle

Es gibt eine neue Ausrede, die kursiert. Jemand liefert eine falsche Zahl. Die Nachbesprechung findet statt. Der Satz taucht auf: "die KI hat diese Abfrage generiert."

Der Satz erfüllt zwei Aufgaben. Die ehrliche: "Ich habe ein Tool verwendet, das Tool war falsch, ich habe es nicht abgefangen." In Ordnung, das passiert, protokollieren Sie es, weitermachen. Die unehrliche: "Die Verantwortung für diese Zahl liegt beim Modell, nicht bei mir." Das ist das moderne Äquivalent dazu, Wikipedia in einer Gerichtseinreichung zu zitieren und mit den Schultern zu zucken, wenn die Quelle sich als jemandes Scherzbearbeitung aus 2009 herausstellt.

Wenn Sie die Zahl gesendet haben, gehört Ihnen die Zahl. Wenn Sie die Abfrage ausgeführt haben, gehört Ihnen die Abfrage. Das Modell ist ein Schreibwerkzeug. Sie sind der Analyst. Stakeholder kümmern sich nicht um die Herkunftskette über Ihren Namen im Ticket hinaus, und das sollten sie auch nicht müssen.

Die praktische Version dieser Regel: Fügen Sie die Ausgabe eines Modells nie in ein Stakeholder-Ticket ein, ohne sie zuerst durch das Warehouse laufen zu lassen. Nicht "es anschauen." Ausführen. Mit einer Zeilenanzahl. Gegen das tatsächliche Schema, mit den tatsächlichen Filtern, im tatsächlichen Datumsbereich. Wenn Sie sich dabei ertappen, diesen Schritt überspringen zu wollen, weil die Deadline eng ist, dann war die Deadline immer eng, und das Überspringen ist der Grund, warum die falsche Zahl in einem Board-Deck zitiert wird.

Governance und Versionierung

Behandeln Sie KI-unterstützte Analysen wie jeden anderen Code, denn das ist Code. Eine Checkliste:

• PR-Review. Jede KI-unterstützte Abfrage, die an ein Dashboard oder einen wiederkehrenden Bericht geht, durchläuft dieselbe Prüfung wie eine handgeschriebene. Keine Ausnahmen für "es ist nur eine schnelle Zahl."
• Kommentare, die Unterstützung vermerken. Eine Kopfzeile: -- KI-unterstützter Entwurf (Claude, 2026-04-28); refaktoriert und validiert von [Ihr Name]. Das ist für den nächsten Analysten, nicht für das Modell.
• Kein PII in Prompts. Das Schema ist in Ordnung. Die ersten drei Zeilen sind meist in Ordnung, wenn es Testdaten sind. Echte Kundenzeilen, E-Mail-Adressen, Zahlungsdetails, Mitarbeiterdatensätze: niemals. Verwenden Sie nur synthetische Beispiele oder Spaltenbeschreibungen.
• Prompt-Logs für Audits. Cursor und Claude haben beide einen Verlauf. Löschen Sie ihn nicht. Wenn in sechs Monaten etwas kaputtgeht, werden Sie den ursprünglichen Prompt suchen wollen.
• Kill-Switch-Liste von Datensätzen. Einige Tabellen werden niemals an eine Drittanbieter-API gesendet. HR-Datensätze, Kundenfinanzen, alles unter einer regionalen Datenspeicherregel. Schreiben Sie die Liste auf. Pinnen Sie sie im BA-Slack-Kanal an. Neue Mitarbeiter lesen sie, bevor sie Warehouse-Zugang erhalten.

Die Governance-Arbeit ist unrühmlich. Sie ist auch der Unterschied zwischen KI als Produktivitätsmultiplikator und KI als benannter Ursache im nächsten Datenvorfallbericht.

Optional: Einordnung in das ACE-Framework

Für Teams, die das ACE-Framework nutzen, um KI-Fähigkeiten im Unternehmen zu kartieren: KI-unterstützte BA-Arbeit fällt klar in Analyze auf der Capabilities-Ebene (Ebene 2 von 5). Sie nutzen KI, um vorhandene Daten zu interpretieren und Entscheidungen herzuleiten, nicht um neue Quellen aufzunehmen (Ingest), Prognosen zu erstellen (Predict), Dokumente zu entwerfen (Generate) oder nachgelagerte Aktionen auszuführen (Execute).

Nützliche Einordnung, weil sie zeigt, was KI für den BA nicht tut: Sie baut keine Datenpipelines, führt keine Modelle gegen zukünftige Daten aus und sendet keine automatischen E-Mails an Stakeholder. Diese liegen in anderen ACE-Zeilen und haben ihre eigenen Fehlerquellen. Die Spuren sauber zu halten, hält die Gespräche sauber.

Der 30-Tage-Plan

Wenn Sie bis hierhin gelesen haben und einen Einstieg suchen, ohne Ihren gesamten Workflow umzuschreiben, wählen Sie eine wiederkehrende SQL-Aufgabe und führen Sie das Experiment durch.

Das Ziel der 30 Tage ist nicht "KI adoptieren." Es geht darum, in Ihrem spezifischen Warehouse zu lernen, wo das Modell lügt. Jedes Warehouse lügt anders. Generischer KI-Rat ignoriert das, deshalb ist der Großteil davon nutzlos.

Nach 30 Tagen werden Sie ein kalibriertes Gefühl für den Hebel haben. Sie werden wissen, welche Aufgaben mit KI dreimal schneller sind und welche langsamer sind, weil die Überprüfung die Einsparungen auffrisst. Sie werden die Dinge aufgeschrieben haben, die Ihr Team bisher nur im Kopf hatte, was ein separates Geschenk an Ihr zukünftiges Selbst ist.

Abschluss

KI im BA-Workflow ist am ersten Tag ein schneller Junior. Nützlich, eifrig und selbstsicher falsch. Der Hebel ist real, und die Fehlermodi sind es auch. Die Arbeit hat sich nicht geändert: die Frage verstehen, das Warehouse verstehen, die richtige Zahl liefern. Die Tools haben verändert, wo die schwierigen Teile liegen.

Der BA, der weiß, wo das Modell lügt, ist wertvoller, nicht weniger. Der BA, der das Modell als endgültigen Autor behandelt, ist derjenige, dessen Name im nächsten Vorfallbericht neben "die KI hat diese Abfrage generiert" erscheint.

Wählen Sie den ersten.

Mehr erfahren

• Business Analyst Job Description Template
• SQL und Dashboard-Design, das Vertrauen verdient
• Anforderungserhebung, die sich nicht verändert
• Häufige Fehler von Business Analysts