Leitfaden für Business-Analyst-Interviews

Vorgehensweise — Ziel → Stakeholder → Entscheidungen → Daten → Anforderungen → Validierung

Zuerst kläre ich, welche Entscheidungen das Dashboard unterstützen soll, wer es wie oft nutzt und welche heutigen Probleme bestehen. Danach identifiziere ich Führung, operative Nutzer, Finance, Data Engineering, Compliance und Eigentümer der Quellsysteme. Für jede Kennzahl dokumentiere ich Definition, Verantwortlichen, Quelle, Berechnung, Filter, Granularität, Aktualisierung und Einschränkungen. Außerdem kläre ich Berechtigungen, Export, Drill-down, Warnungen und Verlauf. Wireframes helfen bei der Validierung; Akzeptanzkriterien und UAT-Szenarien machen die Lösung vor der Einführung prüfbar.

Vorgehensweise — Problem vor Lösung

Ich beginne mit dem Problem: Was ist am heutigen Ablauf langsam, fehleranfällig, intransparent oder nicht regelkonform? Wer stellt Anträge, wer genehmigt und was folgt danach? Dann erfasse ich Felder, Validierung, Routingregeln, Genehmigungsstufen, Eskalation, Ablehnung, erneute Einreichung, Benachrichtigungen, Berichte, Audit-Protokoll und Ausnahmen. Volumen, SLAs, Rollen, Compliance und Integrationen bestimmen die Qualitätsanforderungen. „Automatisiertes System“ ist eine Lösungsidee; die eigentliche Anforderung sind Geschäftsergebnis und Entscheidungsregeln.

Vorgehensweise — Änderung klären → Auswirkung bewerten → Priorisieren → Kommunizieren

Zuerst kläre ich Ursache und Dringlichkeit: neues Bedürfnis, übersehene Anforderung, Regulierung, Präferenz, technische Einschränkung oder Testerkenntnis. Danach bewerte ich Umfang, Zeit, Kosten, Abhängigkeiten, Daten, Integrationen, Tests, Schulung und Risiko gemeinsam mit Product, Engineering, QA und Fachseite. Die Änderung wird aufgenommen, verschoben, gegen etwas anderes getauscht oder abgelehnt. Entscheidung und Begründung gehören ins Änderungsprotokoll. Verdeckte Ausweitung des Umfangs ist das größte Risiko; deshalb kommuniziere ich ausdrücklich, was geliefert wird und was nicht.

Vorgehensweise — Ist-Prozess → Engpässe → Ursache → Soll-Prozess → Kennzahlen

Zuerst bilde ich den Ablauf von der Anmeldung bis zur vollständigen Aktivierung ab: Schritte, Verantwortliche, Systeme, Übergaben, Abhängigkeiten, Genehmigungen, Dokumente und Ausnahmen. Ich messe die Dauer je Schritt, statt nur den Gesamtwert zu betrachten. Danach segmentiere ich nach Kundentyp, Produkt, Region, Risiko und Kanal. Mögliche Ursachen sind manuelle Eingaben, fehlende Unterlagen, Rückstände in Compliance-Prüfungen, doppelte Genehmigungen oder Integrationslücken. Für jeden Engpass bewerte ich Wirkung und Umsetzbarkeit. Der Soll-Prozess kann frühzeitige Dokumentprüfung, automatische Erinnerungen, parallele Bearbeitung, Self-Service, risikobasiertes Routing und weniger Genehmigungen enthalten. Ich messe Median und 90. Perzentil der Dauer, Abschlussquote, Nacharbeit, Zufriedenheit und Compliance-Ausnahmen und starte mit einem begrenzten Pilot.

Vorgehensweise — Umfang → Beteiligte → Ablauf → Ausnahmen → Kontrollen

Ich definiere zuerst Start, Ende, beteiligte Teams und Systeme sowie das Geschäftsziel. Für den Ist-Prozess dokumentiere ich Beteiligte, Schritte, Ein- und Ausgaben, Entscheidungen, Übergaben, Wartezeiten, Probleme und Ausnahmen. Ein Swimlane-Diagramm macht Verantwortlichkeiten sichtbar; validiert wird es mit den Personen, die den Prozess tatsächlich ausführen. Der Soll-Prozess zeigt geänderte oder entfernte Schritte, Automatisierung, neue Kontrollen, Rollenänderungen und Ausnahmebehandlung. Annahmen, offene Fragen, Abhängigkeiten und Erfolgskennzahlen gehören ebenfalls dazu. Je nach Zielgruppe erstelle ich eine knappe Management-Ansicht und eine detaillierte operative Darstellung.

Vorgehensweise — Verknüpfen → filtern → nach Monat und Kategorie gruppieren → Umsatz summieren

Zuerst kläre ich die Granularität. Liegt der Umsatz auf Bestell- oder Positionsebene? Wenn die Kategorie an der Position hängt, muss auch deren Umsatz aggregiert werden; sonst können Summen durch den Join doppelt gezählt werden. Die Abfrage verbindet Bestellpositionen über product_id mit Produkten und über die Bestellung mit Datum und Status. Sie filtert abgeschlossene Bestellungen, gruppiert nach Monat und Kategorie und summiert den Positionsumsatz. Bei Rabatten und Erstattungen kläre ich, ob Brutto- oder Nettoumsatz gefragt ist. Zur Validierung gleiche ich die Monatssumme mit der Finanzquelle ab, prüfe fehlende Kategorien und stelle sicher, dass stornierte sowie Testbestellungen ausgeschlossen sind.

Vorgehensweise — Ziel → Servicequalität → Effizienz → Kundenergebnis → Schutzkennzahlen

Zuerst kläre ich das Ziel: schnellere Lösung, höhere Zufriedenheit, kontrollierte Kosten, weniger Eskalationen oder Unterstützung des Wachstums. Die Kennzahlen müssen Kundenerlebnis und Effizienz gemeinsam abbilden. Sinnvoll sind erste Antwortzeit, Lösungsdauer, SLA-Erfüllung, Rückstand, Wiedereröffnungs- und Eskalationsquote, Lösung beim Erstkontakt, CSAT, Kontakte je Kunde, Kosten je Ticket und Volumen nach Kategorie. Ich segmentiere unter anderem nach Priorität, Kanal, Kundengruppe, Produkt und Region. Schutzkennzahlen verhindern Fehlanreize: Wer nur Bearbeitungszeit optimiert, kann Qualität verlieren. Das Dashboard sollte Geschwindigkeit, Qualität, Auslastung und Ursachen zusammen zeigen.

Vorgehensweise — Validieren → zerlegen → segmentieren → diagnostizieren → empfehlen

Zuerst validiere ich den Wert: Datenaktualität, Quellsysteme, Filter, Zeitraum, Retouren, Währungen und mögliche Definitionsänderungen. Danach zerlege ich Umsatz in Traffic oder Leads, Conversion, Warenkorbwert, Preis, Menge, Produktmix, Region, Kanal sowie Neu- und Bestandskunden. Die Segmentierung zeigt, ob der Rückgang aus einem Kanal, Produkt, Markt oder Kundensegment stammt. Anschließend prüfe ich Ursachen wie Saisonalität, Marketingausgaben, Wettbewerb, Lieferengpässe, Preisänderungen, Pipeline-Qualität, technische Fehler oder Reporting-Probleme. Die Empfehlung folgt dem Treiber und benennt Unsicherheit sowie die nächsten benötigten Daten. Bei weniger mobilem Checkout-Erfolg untersuche ich beispielsweise Funnel und Seitenleistung; bei weniger Traffic prüfe ich Kanäle und Kampagnen.

Vorgehensweise — Nutzer → Ziel → Nutzen → prüfbare Bedingungen

Eine User Story beschreibt, wer etwas benötigt, was benötigt wird und warum: „Als [Nutzer] möchte ich [Funktion], damit [Nutzen].“ Der Nutzen hilft dem Team, bei Zielkonflikten richtig zu entscheiden. Akzeptanzkriterien legen konkret und prüfbar fest, wann die Story erfüllt ist. Sie decken Normalfall, Validierung, Berechtigungen, Fehlerzustände, Grenzfälle, Datenregeln und bei Bedarf Qualitätsanforderungen ab. Beispiel: Eine Support-Leitung möchte Tickets nach Priorität und SLA-Status filtern. Die Kriterien definieren verfügbare Filter, Standardzustand, Kombinationen, leere Ergebnisse, Rechte, Export und Reaktionszeit. Vor der Entwicklung validiere ich Story und Kriterien mit Fachseite, Engineering, QA und Design.

Vorgehensweise — Geschäftliches Warum, funktionales Was, lieferbarer Ausschnitt

Ein Business Requirements Document beschreibt Problem, Ziele, Umfang, Stakeholder, übergeordnete Anforderungen, Annahmen, Einschränkungen und Erfolg. Es erklärt, warum die Arbeit nötig ist und welches Geschäftsergebnis erreicht werden soll. Ein Functional Requirements Document beschreibt genauer, was das System leisten muss: Abläufe, Regeln, Felder, Rechte, Integrationen, Berichte und Ausnahmen. Eine User Story ist eine kleinere, umsetz- und prüfbare Liefereinheit für agile Teams. Die passende Dokumentation hängt von Liefermodell und Risiko ab. Ein regulierter Bankenprozess benötigt meist mehr formale Nachweise als eine kleine Änderung an einem internen Dashboard.

Vorgehensweise — Umfang → Nutzer → Szenarien → Daten → Fehler → Freigabe

Zuerst definiere ich den UAT-Umfang: Abläufe, Rollen, Systeme, Integrationen, Berichte und Geschäftsregeln. UAT bestätigt die fachliche Einsatzbereitschaft und wiederholt nicht jeden QA-Test. Teilnehmen sollten Sachbearbeitung, Teamleitung, Compliance, Operations und Reporting. Die Szenarien stammen aus realen Fällen: Standardfall, fehlende Unterlagen, hoher Schaden, Ablehnung, Eskalation, Duplikat und Ausnahme. Passende Testdaten decken Grenzwerte, Rechte, Statuswechsel, Benachrichtigungen, Audit Trail, Berichte und Folgesysteme ab. Während des Tests erfasse ich Fehler mit Schweregrad, Verantwortung, Status und Geschäftsauswirkung und trenne Defekte von Schulungslücken oder neuen Änderungswünschen. Die Freigabe bestätigt bestandene kritische Szenarien, akzeptierte Restrisiken und betriebliche Bereitschaft.

Vorgehensweise — Gemeinsames Verständnis → Einschränkungen → Optionen → Dokumentation

Ich kläre zuerst Geschäftsproblem und gewünschtes Ergebnis. Mit Engineering untersuche ich technische Grenzen, Abhängigkeiten, Integrationen, Datenmodell, Leistung und Sicherheit. Komplexe Anforderungen zerlege ich in Geschäftsregel, Nutzerablauf, Datenbedarf, API-Verhalten, Rechte, Fehlerbehandlung und Reporting. Diagramme, Beispiele und Beispieldaten reduzieren Mehrdeutigkeit. Engineering liefert Optionen und Zielkonflikte, etwa ein kleineres MVP oder eine gestufte Umsetzung. Meine Aufgabe ist nicht, die technische Lösung allein zu entwerfen, sondern sicherzustellen, dass sie das Geschäftsziel erfüllt und Trade-offs sichtbar sind. Vereinbarungen, offene Fragen, Annahmen und Akzeptanzkriterien werden dokumentiert.

Vorgehensweise — Messen → segmentieren → diagnostizieren → verbessern

Zuerst definiere ich Nutzung passend zum Ziel: Anmeldung, Funktionsaufruf, abgeschlossener Ablauf, wiederholte Nutzung oder Geschäftsergebnis. Danach segmentiere ich nach Rolle, Team, Region, Schulungsgruppe und Zeit seit Einführung. Mögliche Ursachen sind fehlende Bekanntheit, unklarer Nutzen, schlechte Bedienbarkeit, fehlende Rechte, fortbestehende Altprozesse oder eine unpassende Lösung. Nutzungsfunnel, Support-Fälle, Interviews und Prozessbeobachtung helfen bei der Diagnose. Maßnahmen können Schulung, Kommunikation, UX- oder Ablaufverbesserungen, Abschaltung alter Werkzeuge, Rechtekorrekturen oder überarbeitete Anforderungen sein. Erfolg messe ich am beabsichtigten Ergebnis, etwa Zeitersparnis, weniger Fehler oder bessere SLA-Erfüllung, nicht nur an Klicks.

Vorgehensweise — Geschäftswert → Dringlichkeit → Risiko → Aufwand → Abhängigkeiten

Zuerst kläre ich die Geschäftsziele des Zeitraums, etwa Umsatz, Compliance, Kundenerlebnis, Kosten oder Risiko. Danach bewerte ich jede Anforderung nach Wert, Dringlichkeit, regulatorischem und operativem Risiko, Nutzerwirkung, Aufwand, Abhängigkeiten und Sicherheit der Annahmen. Ein leichtes Scoring schafft Transparenz, ersetzt aber kein Urteil: Compliance- oder Störungsanforderungen können zwingend sein. Ich gruppiere in Muss, hoher Wert, schnelle Wirkung, Voraussetzung und später und stimme offen ab, was ausgewählt oder verschoben wird und warum. Außerdem suche ich nach Überschneidungen und Ursachen. Zwanzig Wünsche können auf fünf Grundprobleme zurückgehen; eine Ursachenlösung ist oft besser als viele Einzelfunktionen.

Vorgehensweise — Heutige Kosten → Fehlerrisiko → Automatisierungskosten → Nutzen → Empfehlung

Ich bewerte quantitativen und qualitativen Nutzen. Zu den heutigen Kosten gehören Arbeitszeit, Fehler, Verzögerungen, Audit-Risiko und entgangene höherwertige Arbeit. Bei Finanz- oder Compliance-Prozessen kann Risikoreduktion wichtiger sein als reine Zeitersparnis. Dem stelle ich Entwicklung oder Anbieter, Wartung, Ausnahmebehandlung, Kontrollen, Tests, Schulung und Integration gegenüber. Auch Wachstum zählt: 40 Stunden heute können bei höherem Volumen schnell deutlich mehr werden. Ich empfehle Automatisierung bei stabilen, regelbasierten, häufigen und fehleranfälligen Abläufen mit klaren Quellen. Bei häufig wechselnden Regeln oder hohem Urteilsanteil beginne ich mit Standardisierung und Teilautomatisierung.

Vorgehensweise — Produktivität definieren → Ausgangswert → Nutzung → Ergebnis → Schutzkennzahlen

Zuerst definiere ich Produktivität passend zum Ziel: mehr qualifizierte Aktivitäten, kürzerer Verkaufszyklus, höhere Conversion, mehr Pipeline, bessere Prognosen oder mehr Umsatz je Person. Vor der Einführung brauche ich einen Ausgangswert und möglichst eine Vergleichsgruppe oder gestufte Einführung. Ich prüfe sowohl korrekte Nutzung als auch Ergebnisse. Relevante Werte sind Verwaltungszeit, Follow-ups, Reaktionszeit, Phasenfortschritt, Conversion, Verkaufsdauer, Datenqualität, Prognosegüte und Umsatz je Person. Zufriedenheit, Kundenerlebnis und Fehlanreize dienen als Schutzkennzahlen. Segmentierung nach Team, Region, Erfahrung und Markt zeigt Unterschiede. Daraus folgt die Entscheidung: skalieren, schulen, vereinfachen oder Anforderungen anpassen.

Vorgehensweise — Ziele klären → Trade-offs sichtbar machen → Evidenz nutzen → entscheiden

Zuerst kläre ich die zugrunde liegenden Ziele. Widersprüche entstehen häufig aus verschiedenen Anreizen, etwa Flexibilität im Vertrieb gegenüber Kontrolle in Compliance. Dann mache ich Auswirkungen, Betroffene und Risiken sichtbar und prüfe, ob Konfiguration, Berechtigungen, gestufte Lieferung oder Prozessänderungen beide Bedürfnisse erfüllen können. Daten zu Umsatz, Risiko, Nutzervolumen, Fehlern, Kosten oder Kundenwirkung helfen bei der Bewertung. Benötigt die Entscheidung eine höhere Befugnis, eskaliere ich mit Optionen und Empfehlung statt mit einem ungelösten Streit. Entscheidung, Begründung und zurückgestellte Bedürfnisse werden dokumentiert.

Vorgehensweise — Geschäftsauswirkung, Optionen, Trade-offs

Ich übersetze die Einschränkung in geschäftliche Folgen: mehr Kosten, längere Dauer, geringere Zuverlässigkeit, Sicherheitsrisiko, manueller Umweg oder späterer Start. Technischer Jargon hilft dabei selten. Danach stelle ich konkrete Optionen gegenüber. Beispielsweise liefert Option A den vollen Umfang in acht Wochen, Option B den Kern in drei Wochen mit manueller Ausnahmebehandlung und Option C nutzt ein vorhandenes Werkzeug mit Reporting-Grenzen. Jede Option braucht klare Trade-offs. Einfache Diagramme, Beispiele oder Testdaten machen Zusammenhänge verständlich. Das Ziel ist nicht, Stakeholder zu Technikern zu machen, sondern ihnen eine fundierte Entscheidung zu ermöglichen.

Vorgehensweise — Problem → Analyse → Lösung → Umsetzung → Wirkung

Ich wähle ein Beispiel mit klarem Vorher und Nachher: lange Durchlaufzeit, hohe Fehlerquote, viel Handarbeit, geringe Transparenz, Beschwerden oder Compliance-Risiko. Danach erkläre ich meine Analyse, etwa Prozessmodellierung, Nutzerinterviews, Engpassmessung, Datenprüfung oder Ursachenanalyse. Anschließend beschreibe ich Lösung und eigenen Beitrag zu Anforderungen, Stakeholder-Abstimmung, Prozess- oder Systemänderung, UAT, Schulung und Einführung. Den Abschluss bilden messbare Ergebnisse wie eingesparte Stunden, weniger Fehler, bessere SLA-Erfüllung, niedrigere Kosten oder höhere Zufriedenheit sowie eine kurze Lernerfahrung.

Vorgehensweise — Mehrdeutigkeit → Annahmen → Validierung → Entscheidung

Das Beispiel sollte zeigen, warum Warten auf vollständige Informationen den Fortschritt gefährdet hätte, welche Fakten fehlten und welche vorhanden waren. Ich erkläre dann, wie ich verantwortungsvoll voranging: Annahmen dokumentieren, die wertvollsten Lücken schließen, Stakeholder befragen, Szenarien bilden, Ersatzdaten nutzen oder gestuft vorgehen. Entscheidend ist ausgewogenes Urteil: weder leichtfertig noch handlungsunfähig. Ich mache Unsicherheit sichtbar, treffe eine begründete Entscheidung und schließe mit Ergebnis und Anpassung, nachdem neue Informationen verfügbar wurden.

Vorgehensweise — Kontext → Detail → Risiko → Handlung → Ergebnis

Ich nutze ein Beispiel, in dem Sorgfalt Nacharbeit, Compliance-Risiko, Datenfehler, Kundenschaden oder ein Startproblem verhindert hat. Ich erkläre den Kontext, warum das Detail wichtig war und wie ich es systematisch fand, etwa durch Anforderungsprüfung, Grenzfalltests, Datenabgleich, Ausnahmeprozess oder Validierung mit Nutzern. Danach beschreibe ich die Handlung: Kriterien ergänzen, Freigabe stoppen, Stakeholder abstimmen, Bericht korrigieren oder Kontrolle einführen. Das Ergebnis sollte konkret sein. Die Geschichte handelt nicht von Perfektionismus, sondern vom Schutz eines Geschäftsergebnisses.