Interviewfragen für Business Analysts, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Lies die kurze Antwort und sag sie laut. Das sind deine ersten dreißig Sekunden. Lies dann die ausführliche Antwort und such dir zwei oder drei Punkte aus, die du ergänzt, mit einem Beispiel aus deiner eigenen Arbeit: die Menschen, der Prozess, was du herausgefunden hast und was sich geändert hat. Interviewer wollen eine Methode und ein echtes Beispiel, keine Liste von Techniken.

Was ein Business Analyst wissen muss

• Anforderungen: herausfinden, was die Leute brauchen, durch Interviews, Workshops und Beobachtung, und es so aufschreiben, dass es gebaut und getestet werden kann.
• Prozesse: abbilden, wie die Arbeit heute gemacht wird und wie sie gemacht werden sollte, oft in BPMN, einer Standardnotation zum Zeichnen von Prozessen.
• Agile Umsetzung: User Stories mit Akzeptanzkriterien in JiraIn 18 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Klare Stories mit Akzeptanzkriterien schreiben und das Backlog aufgeräumt halten; Confluence für die Dokumente., Refinement mit dem Team und agilesIn 12 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).In kurzen Zyklen mit einem Team arbeiten: Anforderungen als Stories, Sprint für Sprint verfeinert und abgenommen. Arbeiten und ScrumIn 12 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Die Rollen und Termine kennen; viele Business Analysts helfen dem Product Owner, das Backlog bereit zu halten..
• Daten: Daten lesenIn 8 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Daten lesen, um ein Problem zu beziffern, eine Behauptung zu prüfen und das Ergebnis einer Änderung zu messen., um ein Problem zu beziffern und ein Ergebnis zu prüfen, mit SQLIn 25 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Die eigenen Fragen aus den Daten beantworten: Joins, Filter und Zählungen, ohne auf einen Entwickler zu warten., ExcelIn 14 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Analysen, einfache Modelle, Datenprüfungen und die Vergleichstabellen, die eine Entscheidung stützen. oder Dashboards in Power BIIn 14 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Dashboards bauen oder lesen, die zeigen, ob eine Änderung gewirkt hat; verbreitet in Firmen, die stark auf Microsoft setzen. oder TableauIn 2 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Ein weiteres verbreitetes Dashboard-Werkzeug; einfache Dashboards lesen und bauen reicht oft..
• Menschen: Stakeholder-ManagementIn 16 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Alle finden, die eine Änderung betrifft, verstehen, was jeder braucht, und alle informiert und an Bord halten. und klare KommunikationIn 27 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Klar schreiben (Anforderungen, Prozesslandkarten, Entscheidungen) und Workshops leiten, aus denen alle mit einer Einigung gehen., im Raum und schriftlich.
• Systeme: wie die Geschäftssysteme deiner Branche funktionieren, etwa SAPIn 14 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Viele Analysten arbeiten an SAP-Prozessen in Finanzen, Einkauf und Vertrieb; kenne die Module deines Bereichs. oder SalesforceIn 4 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Verbreitet in Vertriebs- und Serviceprojekten: wie seine Objekte und Prozesse zum Geschäft passen., und wie sie Daten austauschen.
• Recht und Vertrauen: personenbezogene Daten nach der DSGVOIn 9 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).EU-Datenschutz (DSGVO): welche personenbezogenen Daten ein Prozess nutzt, warum, wie lange und wer zustimmen muss. (EU) und ähnlichen Gesetzen: was ein Prozess speichern darf und wie lange.

Herausfinden, was gebraucht wird

Wie würdest du Anforderungen für ein neues System erheben, das ein altes ersetzt?

Worauf sie achten: eine klare Methode, die die echten Bedürfnisse findet, nicht nur eine Kopie des alten Systems.

Kurze Antwort: „Ich beginne beim Geschäftsziel und bei den Betroffenen. Ich lerne, wie die Arbeit heute gemacht wird, indem ich zuschaue und frage, und moderiere dann Workshops, um zu vereinbaren, was sich ändern muss. Die Anforderungen schreibe ich als User Stories mit Akzeptanzkriterien, lasse sie von Anwendern und Team prüfen und führe eine Liste offener Fragen, bis jede beantwortet ist.“

Die ausführliche Antwort in sechs Schritten:

1. Ziel und Umfang. Warum ersetzen wir es, und wie sähe Erfolg aus: niedrigere Kosten, weniger Fehler, schnellere Arbeit? Schreib auf, was zum Umfang gehört und was nicht.
2. Stakeholder. Liste alle Betroffenen auf: die Leute, die es jeden Tag nutzen, ihre Führungskräfte, die IT, die Finanzabteilung, die Rechtsabteilung und die Kunden, die die Ergebnisse sehen.
3. Der heutige Prozess. Schau den Leuten bei der Arbeit zu, lies die Masken und Berichte des alten Systems und bilde den Prozess ab. Oft nutzen die Leute das alte System auf Arten, die niemand aufgeschrieben hat.
4. Workshops. Bring die richtigen Leute zusammen, um den neuen Prozess und die Anforderungen zu vereinbaren, Gruppe für Gruppe. Trenne, was sie brauchen, von dem, wie sie es gewohnt sind.
5. Aufschreiben. Anforderungen als User Stories (als Rolle möchte ich etwas, damit ein Nutzen entsteht) mit Akzeptanzkriterien, dazu die Regeln, die überall gelten, etwa Geschwindigkeit, Sicherheit und Zugriff.
6. Prüfen und vereinbaren. Geh die Stories mit Anwendern und Team durch, ergänze Beispiele und lass sie freigeben oder ins Backlog aufnehmen.

Schwache Antwort: „Ich frage die Anwender, was sie wollen, und schreibe es auf.“ Die Leute wünschen sich das alte System in neuen Farben; Aufgabe des Analysten ist, das Bedürfnis dahinter zu finden.

Nachfrage: „Die Anwender wollen jede Funktion des alten Systems.“ Frag, wie oft jede genutzt wird und was ohne sie passiert; Daten aus dem alten System zeigen oft, dass viele nie genutzt werden.

Wie moderierst du einen Anforderungsworkshop?

Worauf sie achten: dass du dich vorbereitest, den Raum beim Thema hältst und mit Entscheidungen herausgehst.

Kurze Antwort: „Ich vereinbare vorher Ziel und Teilnehmer, schicke eine kurze Agenda und bereite einen Entwurf vor, auf den man reagieren kann, etwa eine Prozesslandkarte. Im Raum halte ich mich ans Ziel, sorge dafür, dass auch Stille zu Wort kommen, schreibe Entscheidungen sichtbar für alle auf und parke Nebenthemen. Danach schicke ich Entscheidungen und offene Fragen innerhalb eines Tages herum.“

Die ausführliche Antwort: Ein Workshop ist ein Arbeitstreffen, in dem die Betroffenen die Anforderungen gemeinsam formen. Lade die ein, die die Arbeit kennen, und die, die entscheiden; bei zu vielen Leuten wird nichts entschieden. Ein Entwurf bekommt bessere Reaktionen als ein leeres Blatt. Nutze einfache Techniken: Geh den Prozess Schritt für Schritt durch, frag bei jeder Ausnahme „was passiert, wenn ...?“ und lass abstimmen, wenn es zu viele Ideen gibt. Schließ mit einer klaren Liste: was wir vereinbart haben, was offen ist, wer es bis wann beantwortet.

Schwache Antwort: „Ich lade alle ein und schaue, was kommt.“ Nachfrage: „Eine Führungskraft redet alle anderen nieder.“ Bedank dich bei ihr, geh dann reihum mit Namen durch den Raum oder lass Ideen zuerst schriftlich sammeln, damit jede Stimme zählt.

Zwei Abteilungen wollen Gegensätzliches vom selben System. Was machst du?

Worauf sie achten: dass du Konflikte zwischen Stakeholdern mit Fakten und Fairness lösen kannst.

Kurze Antwort: „Ich treffe jede Seite einzeln, um zu verstehen, was sie braucht und warum, und bringe sie dann um das gemeinsame Geschäftsziel zusammen, mit den Fakten: Kosten, Risiko, wer betroffen ist. Oft lassen sich beide Bedürfnisse auf anderem Weg erfüllen. Wenn nicht, gebe ich die Wahl an die Person, der die Entscheidung gehört, mit den Optionen schriftlich.“

Die ausführliche Antwort: Konflikte drehen sich oft um Lösungen, nicht um Bedürfnisse. Der Vertrieb will ein Feld als optional, damit Aufträge schnell erfasst werden; die Buchhaltung will es als Pflichtfeld, damit die Rechnungen stimmen. Das gemeinsame Ziel sind richtige Rechnungen, ohne den Vertrieb zu bremsen, also kann das Feld später ausgefüllt werden, vor der Rechnungsstellung. Eine Stakeholder-Landkarte, die zeigt, wer betroffen ist und wer entscheidet, sagt dir, wen du einbeziehen musst. Der Analyst entscheidet nicht; er macht die Entscheidung leicht und sichtbar.

Schwache Antwort: „Ich gehe mit der ranghöheren Abteilung.“ Nachfrage: „Die Person, der die Entscheidung gehört, entscheidet nicht.“ Schreib auf, was jede Woche Warten kostet, und vereinbare mit ihr einen Termin.

Prozesse und Analyse

Ein Prozess dauert viel zu lange. Wie findest du heraus, warum, und wie behebst du es?

Worauf sie achten: dass du zuerst misst, die echte Ursache findest und sie mit den Leuten behebst, die die Arbeit machen.

Kurze Antwort: „Ich bilde den Prozess ab, wie er wirklich ist, messe, wie lange jeder Schritt und jede Wartezeit dauert, und finde, wo die Zeit hingeht. Meist sind es Wartezeiten und Übergaben, nicht die Arbeit selbst. Dann vereinbare ich Änderungen mit den Beteiligten, probiere sie im Kleinen aus und messe noch einmal.“

Die ausführliche Antwort in fünf Schritten:

1. Beschreibe das Problem in Zahlen. Wie lange dauert es jetzt, wie lange sollte es dauern, und für welche Fälle?
2. Bilde den Ist-Prozess ab. Geh ihn mit den Leuten durch, die ihn machen, so wie er ist, nicht wie das Handbuch sagt. Zeichne ihn in BPMN oder als einfache Kästchen und Pfeile.
3. Miss. Nutze, wo möglich, Daten aus den Systemen, zum Beispiel Zeitstempel pro Schritt, mit SQLIn 25 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Die eigenen Fragen aus den Daten beantworten: Joins, Filter und Zählungen, ohne auf einen Entwickler zu warten. oder ExcelIn 14 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Analysen, einfache Modelle, Datenprüfungen und die Vergleichstabellen, die eine Entscheidung stützen.. Trenne Bearbeitungszeit von Wartezeit.
4. Finde die Ursache. Such nach Wartezeiten, Nacharbeit, Übergaben, Freigaben, die niemand braucht, und Daten, die doppelt erfasst werden. Frag „warum?“, bis du bei einer Ursache ankommst, die du ändern kannst. LeanIn 0 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Verschwendung aus einem Prozess nehmen: Warten, Nacharbeit, Übergaben; verbreitet in Betrieb und Banken. nennt diese Dinge Verschwendung.
5. Ändern und prüfen. Vereinbare den neuen Prozess, probiere ihn mit einem Team aus, miss und führe ihn dann mit Schulung und aktualisierten Dokumenten ein.

Schwache Antwort: „Wir kaufen ein Werkzeug, um es zu automatisieren.“ Einen schlechten Prozess zu automatisieren lässt ihn nur schneller scheitern.

Nachfrage: „Die Ursache ist ein Freigabeschritt einer anderen Abteilung.“ Zeig ihr die Daten, frag, gegen welches Risiko der Schritt schützt, und such einen leichteren Weg, dieses Risiko abzudecken.

Was ist eine Gap-Analyse, und wann nutzt du sie?

Worauf sie achten: dass du die Technik kennst und sie nutzt, um Entscheidungen zu treffen, nicht um Dokumente zu produzieren.

Kurze Antwort: „Eine Gap-Analyse vergleicht, wo wir stehen, mit dem, wo wir hinwollen: den heutigen Prozess oder das heutige System mit dem Ziel, Schritt für Schritt. Die Lücken werden zur Liste der Änderungen, jede mit ihrer Größe und ihrem Wert. Ich nutze sie bei der Auswahl eines neuen Systems oder bei der Planung einer großen Veränderung.“

Die ausführliche Antwort: Liste die Zielfähigkeiten auf, also das, was das Geschäft können muss, und bewerte jede für heute: gut erfüllt, schlecht erfüllt oder gar nicht. Bei einem neuen System bewertest du jede Option an derselben Liste; eine Standardsoftware deckt vielleicht die meisten Bedürfnisse ab, wenn sich der Prozess ein wenig ändert. Jede Lücke bekommt einen Weg, sie zu schließen: den Prozess ändern, das System konfigurieren, etwas bauen oder sie akzeptieren. So wird aus einer langen Wunschliste eine Reihe von Entscheidungen mit Kosten.

Schwache Antwort: „Das ist ein Dokument, das die Unterschiede auflistet.“ Nachfrage: „Die Standardsoftware deckt die meisten Bedürfnisse ab, aber ein wichtiges nicht.“ Prüfe, ob sich der Prozess ändern kann, ob eine kleine Erweiterung es abdeckt und was die Lücke kostet, wenn sie offen bleibt.

Wie nutzt du Daten in deiner Analyse?

Worauf sie achten: dass du Meinungen mit Zahlen untermauerst und die Zahlen selbst beschaffen kannst.

Kurze Antwort: „Ich nutze Daten, um ein Problem zu beziffern, bevor wir Geld dafür ausgeben, um Behauptungen wie ‚das passiert ständig‘ zu prüfen und um zu messen, ob eine Änderung funktioniert hat. Ich kann einfaches SQL schreiben und schnell ein Dashboard bauen, und für alles Größere arbeite ich mit Datenanalysten.“

Die ausführliche Antwort: In einem Workshop sagt jemand, Kunden beschweren sich über die Lieferung. Daten machen daraus eine Zahl: wie viele Bestellungen zu spät sind, in welchen Regionen, seit wann. Mit SQL kannst du Bestellungen und Beschwerden selbst verknüpfen. Ein einfaches Diagramm in Power BIIn 14 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Dashboards bauen oder lesen, die zeigen, ob eine Änderung gewirkt hat; verbreitet in Firmen, die stark auf Microsoft setzen. zeigt das Muster Leuten, die keine Tabellen lesen. Vereinbare vor einer Änderung die Erfolgskennzahl und ihren Ausgangswert, damit das Ergebnis später geprüft werden kann.

Schwache Antwort: „Die Zahlen macht das Datenteam.“ Nachfrage: „Die Daten sagen das eine, die Anwender das andere.“ Prüfe beides: Den Daten fehlt vielleicht ein Teil des Prozesses, oder die Anwender erinnern sich an die schlimmsten Fälle. Seht euch gemeinsam ein paar echte Fälle an.

Woher weißt du, dass eine Änderung geliefert hat, was sie versprochen hat?

Worauf sie achten: dass du nach dem Go-live nachfasst, statt weiterzuziehen.

Kurze Antwort: „Vor der Änderung vereinbare ich mit dem fachlichen Verantwortlichen, wie Erfolg aussieht, und messe den Ausgangspunkt. Einige Wochen oder Monate nach dem Go-live messe ich erneut, spreche mit den Anwendern und berichte das Ergebnis ehrlich, auch was nicht funktioniert hat, mit den nächsten Schritten.“

Die ausführliche Antwort: Das heißt oft Benefits Realisation: prüfen, ob der Nutzen aus dem Business Case eingetreten ist. Wähl ein paar Kennzahlen, die du leicht bekommst, etwa Bearbeitungszeit, Fehler oder Kosten pro Vorgang. Trenne die Wirkung der Änderung von anderem, das sich gleichzeitig bewegt hat, etwa einer Hochsaison. Ist das Ergebnis schwach, finde heraus, warum: Vielleicht umgehen die Leute den neuen Prozess, was ein kurzer Besuch sofort zeigt.

Schwache Antwort: „Wenn es live ist, ist das Projekt fertig.“ Nachfrage: „Die Anwender sind zu ihren alten Tabellen zurückgekehrt.“ Finde heraus, was ihnen das neue System nicht gibt, und behebe das oder schule sie.

Anforderungen in agilen Teams und Tests

Was macht eine gute User Story und gute Akzeptanzkriterien aus?

Worauf sie achten: dass deine Stories gebaut und getestet werden können, ohne zu raten.

Kurze Antwort: „Eine gute Story sagt, wer was braucht und warum, ist klein genug, um in einem Sprint fertig zu werden, und lässt sich testen. Akzeptanzkriterien sagen genau, wann sie fertig ist, mit Beispielen, auch dafür, was passiert, wenn etwas schiefgeht.“

Die ausführliche Antwort: Die Form ist „als Rolle möchte ich etwas, damit ein Nutzen entsteht“. Das Warum zählt am meisten, weil es dem Team erlaubt, eine bessere Lösung zu finden. INVEST ist eine Checkliste für Stories: independent, negotiable, valuable, estimable, small und testable (unabhängig, verhandelbar, wertvoll, schätzbar, klein, testbar). Akzeptanzkriterien werden oft als Given, When, Then geschrieben: Gegeben ein Kunde mit einer unbezahlten Rechnung, wenn er bestellt, dann sieht er eine Zahlungserinnerung. Schreib auch die Fehlerfälle auf: fehlende Daten, keine Berechtigung, ein System, das ausgefallen ist.

Schwache Antwort: „Das System soll benutzerfreundlich sein.“ Das kann man weder bauen noch testen. Nachfrage: „Die Story ist zu groß für einen Sprint.“ Teile sie nach Prozessschritten, nach Nutzertyp oder zuerst nach dem einfachen Fall und später nach den Ausnahmen.

Wie priorisierst du Anforderungen, wenn nicht genug Zeit für alle da ist?

Worauf sie achten: eine Methode, die am Ziel hängt, und den Mut zu sagen, was nicht gemacht wird.

Kurze Antwort: „Ich ordne sie nach Nutzen für das Geschäftsziel gegen Aufwand und Risiko, mit dem Product Owner oder dem fachlichen Verantwortlichen, der entscheidet. MoSCoW hilft: Must have, Should have, Could have, Won't have this time. Die Must-haves müssen für den Go-live wirklich nötig sein, nicht nur gewünscht.“

Die ausführliche Antwort: Frag bei jeder Anforderung: Was passiert, wenn wir ohne sie live gehen? Lautet die Antwort „wir brechen das Gesetz“ oder „wir können die Arbeit nicht machen“, ist sie ein Muss. Gesetze und Verträge kommen zuerst; dann die Einträge, die für den Aufwand den meisten Nutzen bringen. Abhängigkeiten ändern die Reihenfolge: Manche Einträge werden vor anderen gebraucht. Schreib die Won't-haves auf und teile sie, damit später niemand überrascht ist.

Schwache Antwort: „Alles ist ein Must-have.“ Nachfrage: „Ein Direktor besteht darauf, dass sein Eintrag ein Muss ist.“ Frag, was am ersten Tag ohne ihn passiert, und biete eine Übergangslösung oder einen Termin für das nächste Release an.

Wie unterstützt du den User Acceptance Test?

Worauf sie achten: dass du die Tests mit den Anforderungen verknüpfst und dem Fachbereich hilfst, über den Go-live zu entscheiden.

Kurze Antwort: „Im User Acceptance Test prüfen echte Anwender vor dem Go-live, ob das System ihre Arbeit unterstützt. Ich mache mit den Anwendern aus den Anforderungen Testszenarien, plane, wer was wann testet, bereite Testdaten vor, verfolge die Fehler und liefere ein klares Bild, damit der Fachbereich über den Go-live entscheiden kann.“

Die ausführliche Antwort: Der UAT ist keine zweite Runde der Entwicklertests; er prüft den ganzen Prozess mit realistischen Fällen, auch mit Ausnahmen. Jedes Szenario hängt an einer Anforderung, damit du zeigen kannst, was abgedeckt ist. Sortiere Fehler danach, wie schlimm sie für das Geschäft sind, und vereinbare vorher, was vor dem Go-live behoben sein muss. Schule die Tester kurz und sei im Raum oder erreichbar, während sie testen.

Schwache Antwort: „Die Anwender testen, wenn sie Zeit haben.“ Nachfrage: „Die Anwender finden vieles, das nie in den Anforderungen stand.“ Sortiere es: Echte Lücken kommen mit Priorität ins Backlog, Wünsche ins nächste Release; und lern, warum die Lücke übersehen wurde.

Eine Anforderung ändert sich spät im Projekt. Wie gehst du damit um?

Worauf sie achten: dass du Änderungen akzeptierst, aber ihre Kosten sichtbar machst.

Kurze Antwort: „Ich finde heraus, warum sie sich geändert hat und was sie betrifft: andere Anforderungen, das Design, die Tests, den Termin und die Kosten. Das zeige ich der Person, die entscheidet, mit Optionen, und wenn entschieden ist, aktualisiere ich die Anforderungen und informiere alle Betroffenen.“

Die ausführliche Antwort: Traceability, also die Verknüpfung jeder Anforderung mit ihren Entwürfen und Tests, macht die Auswirkung schnell sichtbar. In einem agilen Team bedeutet eine Änderung meist, das Backlog neu zu ordnen; in einem Festpreis- oder Phasenprojekt läuft sie über einen Änderungsantrag (Change Request), eine formale Entscheidung über Umfang, Zeit und Geld. So oder so: Führe eine kurze Historie, was sich geändert hat, warum und wer zugestimmt hat, denn sechs Monate später fragt jemand danach.

Schwache Antwort: „Wir nehmen sie einfach auf.“ Oder: „Die Anforderungen sind eingefroren, also nein.“ Nachfrage: „Die Änderung ist ein neues Gesetz.“ Dann ist sie ein Muss; finde, was sonst weichen kann, um Platz zu machen.

Wie schreibst du Anforderungen für zwei Systeme, die Daten austauschen müssen?

Worauf sie achten: dass du eine Schnittstelle so klar beschreiben kannst, dass zwei Teams sie getrennt bauen können.

Kurze Antwort: „Ich beschreibe, welche Daten fließen, in welche Richtung, wann und warum: die Felder, ihre Bedeutung und ihr Format, welches System jedes führt, wie oft sie gesendet werden und was passiert, wenn etwas fehlschlägt oder ein Wert fehlt. Beide Teams prüfen es, bevor jemand baut.“

Die ausführliche Antwort: Systeme sprechen oft über eine API miteinander, einen vereinbarten Weg, wie ein Programm ein anderes nach Daten fragt, etwa eine REST-APIIn 1 % der Anzeigen für Business Analyst gefragt (Stand 05.11.2026).Wissen, was eine API ist, damit du Anforderungen für Systeme schreiben kannst, die Daten austauschen.. Der Analyst entwirft die API nicht, sondern schreibt die fachliche Seite: eine Mapping-Tabelle vom Quellfeld zum Zielfeld, die Regeln für jedes Feld, Beispiele mit echten Werten und die Fehlerfälle. Vereinbare, welches System für jedes Datum der Master ist, zum Beispiel für die Kundenadresse, damit sich zwei Systeme nicht gegenseitig überschreiben.

Schwache Antwort: „Die Entwickler klären das unter sich.“ Nachfrage: „Die beiden Systeme nutzen verschiedene Codes für dasselbe Land.“ Ergänze eine Mapping-Regel und benenne, wer die Liste aktuell hält.

Wie erfasst du Anforderungen für personenbezogene Daten in einem Prozess?

Worauf sie achten: dass Datenschutz von Anfang an Teil der Anforderungen ist.

Kurze Antwort: „Bei jedem personenbezogenen Feld frage ich, warum wir es brauchen, wer es sehen darf, wie lange wir es aufbewahren und wie es gelöscht wird. In der EU verlangt die DSGVO für jede Nutzung eine Rechtsgrundlage und erlaubt Menschen, Auskunft über ihre Daten zu verlangen, also schreibe ich das mit dem Datenschutzbeauftragten als Anforderungen auf, nicht als Nachgedanken.“

Die ausführliche Antwort: Führe eine einfache Liste der personenbezogenen Daten, die der Prozess nutzt: das Feld, den Zweck, die Rechtsgrundlage, wer Zugriff hat, die Aufbewahrungsfrist. Nach der DSGVO (EU) braucht ein neuer Prozess mit sensiblen Daten unter Umständen eine Datenschutz-Folgenabschätzung, eine schriftliche Prüfung der Risiken. Schreib Akzeptanzkriterien für Zugriffsrechte und Löschung, damit sie wie jede andere Funktion getestet werden.

Schwache Antwort: „Die Rechtsabteilung prüft das vor dem Go-live.“ Nachfrage: „Das Marketing will die Daten jedes Kunden für immer behalten.“ Frag, wofür sie genutzt werden, und vereinbare eine Frist, die diese Nutzung abdeckt.

Umfang, Business Cases und die Führung von Analysten

Diese Fragen kommen bei Senior und Lead Business Analysts und bei Rollen als Business Architect.

Wie baust du einen Business Case für eine Veränderung?

Worauf sie achten: dass du eine Veränderung ehrlich mit Geld, Risiko und Strategie verknüpfen kannst.

Kurze Antwort: „Ein Business Case sagt, welches Problem wir lösen, die Optionen einschließlich Nichtstun, Kosten und Nutzen jeder Option über einige Jahre, die Risiken und eine Empfehlung. Die Zahlen erarbeite ich mit dem Finanzbereich und den fachlichen Verantwortlichen, und ich nenne meine Annahmen, damit man sie hinterfragen kann.“

Die ausführliche Antwort: Nutzen gibt es in verschiedenen Arten: gespartes Geld, verdientes Geld, verringertes Risiko und erfüllte Pflichten, etwa ein Gesetz. Sei vorsichtig mit weichem Nutzen wie „gesparte Arbeitszeit“: Sag, wofür diese Zeit genutzt wird. Zeig eine Spanne, nicht eine Zahl, und den Punkt, ab dem der Case nicht mehr trägt. Ein Senior-Analyst prüft den Case auch später: Ist der Nutzen eingetreten? So entsteht Vertrauen für den nächsten.

Schwache Antwort: „Der Nutzen ist offensichtlich.“ Nachfrage: „Der Finanzbereich sagt, deine Einsparungen seien zu optimistisch.“ Nimm seine Zahlen, zeig das Ergebnis und sieh, ob der Case noch trägt.

Wie hältst du als Lead Business Analyst die Analyse über viele Teams hinweg einheitlich?

Worauf sie achten: bei Lead-Rollen Standards setzen und anderen Analysten helfen, gute Arbeit zu machen.

Kurze Antwort: „Ich vereinbare ein paar gemeinsame Standards: wie wir Stories und Akzeptanzkriterien schreiben, wie Prozesse gezeichnet werden, wo Dokumente liegen und ein gemeinsames Glossar der Fachbegriffe. Ich prüfe Arbeit, arbeite im Tandem mit neueren Analysten und leite ein regelmäßiges Treffen, in dem Analysten ihre Arbeit zeigen und voneinander lernen.“

Die ausführliche Antwort: Uneinheitliche Anforderungen kosten Zeit, wenn Teams voneinander abhängen. Ein Glossar verhindert, dass zwei Teams mit „Kunde“ oder „Auftrag“ verschiedene Dinge meinen. Vorlagen machen den richtigen Weg zum einfachen Weg. Als Mentor gebe ich Feedback an echter Arbeit, nicht an Theorie, und lasse Analysten früh Workshops leiten, mit Unterstützung. Ich plane die Analysearbeit auch mit Projekt- und Produktverantwortlichen, damit Analysten nicht auf zu viele Teams verteilt sind.

Schwache Antwort: „Jeder Analyst arbeitet auf seine Art.“ Nachfrage: „Ein erfahrener Analyst lehnt die Vorlagen ab.“ Frag, was daran falsch ist, verbessert sie gemeinsam und behalte die wenigen Regeln, die zählen.

Was macht ein Business Architect, das ein Business Analyst nicht macht?

Worauf sie achten: bei Rollen als Business Architect das Denken über die ganze Organisation, nicht über ein Projekt.

Kurze Antwort: „Ein Business Analyst arbeitet an einer Veränderung oder einem Projekt. Ein Business Architect sieht das ganze Unternehmen: was es können muss, welche Prozesse und Systeme jeden Teil unterstützen und welche Veränderungen für die Strategie am wichtigsten sind. Er hilft der Geschäftsleitung, Projekte auszuwählen und zu ordnen.“

Die ausführliche Antwort: Das wichtigste Werkzeug ist eine Capability Map, eine Liste dessen, was das Geschäft können muss, etwa „Kundenaufträge abwickeln“, unabhängig davon, wer es macht oder welches System. Legt man Projekte, Systeme und Kosten darüber, zeigen sich Doppelungen, Lücken und wo investiert werden sollte. Business Architects arbeiten mit Enterprise Architects auf der technischen Seite und mit Strategie und Finanzbereich an den Prioritäten.

Schwache Antwort: „Das ist ein erfahrenerer Business Analyst.“ Nachfrage: „Zwei Projekte bauen dieselbe Fähigkeit.“ Zeig es auf der Landkarte, mit den Kosten, und bring die Projektverantwortlichen zusammen, damit sie sich auf eine einigen.

Dein Lebenslauf für diese Fragen

Jede Antwort oben fällt leichter, wenn dein Lebenslauf sie schon enthält, denn der Interviewer fragt nach dem, was dort steht. Schreib unter jede Stelle zu jedem dieser Punkte eine Zeile, in den Wörtern der Anzeigen:

Bewerte deinen Lebenslauf dann an einem echten Job: Du siehst, welche dieser Punkte der Job verlangt und welche dein Lebenslauf noch nicht belegt.