Deutsch

Ein Tag im Leben eines Business Analyst (B2B SaaS, IC Track)

Bevor mein Laptop offen ist, gibt es 11 Slack-Nachrichten, die fragen, warum MRR gesunken ist. Keine davon ist falsch. Keine hat dieselbe Antwort.

Ein PM schaut auf das Executive-Dashboard, das aus einem dbt-Modell zieht, das um 5 Uhr morgens lief. Ein CSM schaut auf einen Salesforce-Bericht, der MRR als zugesagten Vertragswert definiert. Der VP Finance schaut auf die Umsatzerkennungsansicht, die alles ausschließt, was noch nicht fakturiert wurde. Alle haben recht, und alle schauen auf verschiedene Zahlen, und bis 9:30 Uhr wird jemand fragen, welches davon "das echte MRR" ist. Diese Antwort dauert 20 Minuten zu geben und weitere 20 zu verteidigen. Willkommen am Dienstag.

Was die Stellenbeschreibung versprochen hat vs. wie der Dienstag wirklich aussieht

Die Stellenbeschreibung sagte "Geschäftserkenntnisse vorantreiben" und "mit der Führung bei strategischen Entscheidungen zusammenarbeiten." Ich habe sie angenommen. Die Realität ist, dass meine Woche ungefähr 60 % SQL und Daten-Klempnerarbeit ist, 30 % Übersetzen zwischen Engineering und Produkt (und Sales, und Finance, und dem einen CS Director, der nur über Sprachnachrichten kommuniziert), und 10 % echte Analyse. Die Erkenntnis geschieht nur, wenn die Klempnerarbeit sauber läuft. Ein BA, der Dashboards nicht grün halten kann, wird nie zum Strategietisch eingeladen. Er ist zu beschäftigt im Keller, die Rohre zu reparieren.

Hier ist das Stunden-für-Stunden-Protokoll für einen normalen Tag. Stack: Snowflake für das Warehouse, dbt für Transformationen, Looker für BI (mit einigen Hex-Notebooks für Ad-hoc), Notion für Spezifikationen, Jira für Ticketing.

8:00 Uhr - Dashboard-Gesundheitsprüfung

Bevor ich auf eine einzige Slack-Nachricht antworte, mache ich jeden Morgen denselben Fünf-Minuten-Durchgang:

  1. Hat der dbt-Lauf fertig? Überprüfen Sie die dbt-Cloud-Job-Übersicht. Überall grün, oder ist fct_revenue um 4:47 Uhr fehlgeschlagen, weil jemand eine Schema-Änderung ausgeliefert hat?
  2. Frischezeitstempel auf dem Exec-Dashboard. Öffnen Sie das Executive-Looker-Dashboard. Das "Zuletzt aktualisiert"-Tile sollte "heute, ca. 6 Uhr" sagen. Wenn es "gestern" sagt, ist etwas Upstream veraltet.
  3. Zeilenanzahl vs. gestern. Drei Abfragen gegen das Warehouse (Bestellungen, Opportunities, aktive Konten). Wenn die Zeilenanzahl um mehr als 5 % gesunken ist, ist ein Upstream-Fivetran-Sync kaputt.
  4. Die drei wichtigsten KPIs. Neue Logo-Anzahl, MRR und Brutto-Retention. Sind sie in vernünftigen Bereichen, oder zeigt einer einen 40 %-Woche-über-Woche-Schwung, der schreit "Definition ist kaputt"?
  5. Die "Hat jemand die Semantikschicht letzte Nacht angefasst"-Prüfung. Schauen Sie das LookML-Repo nach Merges in den letzten 12 Stunden an.

Hier ist eine Plausibilitätsprüfungs-Abfrage, die ich in Snowflake angeheftet habe. Sie läuft in unter fünf Sekunden:

select
  date_trunc('day', created_at) as day,
  count(*) as orders,
  sum(amount) as gmv
from analytics.fct_orders
where created_at >= dateadd('day', -7, current_date)
group by 1
order by 1 desc;

Wenn die heutige Zeile fehlt oder der GMV stark schwankt, weiß ich es, bevor der CEO es tut. Das ist der ganze Punkt. Einen kaputten Join um 8:05 Uhr zu erkennen ist eine Drei-Minuten-Reparatur. Ihn um 9:35 Uhr zu erkennen, nachdem das All-Hands bereits begonnen hat, ist eine 90-minütige Feuerübung plus eine Entschuldigungs-E-Mail.

9:00 Uhr - Ad-hoc-Anfragen-Priorisierung

Die Warteschlange ist an drei Stellen, weil natürlich. Jira-Aufnahme-Board für formelle Anfragen. Der #data-help-Slack-Kanal für "schnelle Fragen." Eine geteilte Notion-Seite, auf der eine der Directors immer wieder Anfragen hinzufügt, weil sie sich weigert, Jira zu benutzen. Ich überprüfe alle drei.

Heute Morgen: fünf neue Anfragen. Mein Job ist nicht, sie zu beantworten. Mein Job ist, sie zu priorisieren.

  • "Können Sie Abwanderung nach Plantier für letztes Quartal ziehen?" Blockierend. Der CFO braucht es für das Board-Deck am Donnerstag. Wenn die Semantikschicht sauber ist, ist das eine 15-Minuten-Abfrage. Wenn fct_subscription_events immer noch das alte plan_id-Join-Problem hat, sind es zwei Stunden. Schätzung: 30 Minuten. Nehmen Sie es an.
  • "Neugierig, wie viele unserer Trial-Nutzer kommen von LinkedIn?" Neugierig, nicht blockiert. Das Marketing-Dashboard hat bereits die Aufnahme-Quell-Aufteilung. Antworten mit einem Screenshot und einem Link. Zwei Minuten.
  • "Muss unsere Q1-Win-Rate nach Branche wissen." Existiert bereits im Vertriebsleistungs-Looker-Dashboard. Senden Sie den Link und einen Satz dazu, welchen Filter anzuwenden ist. Drei Minuten.
  • "Können Sie ein Dashboard für unser neues Preisexperiment bauen?" Echte Arbeit. Braucht ein 30-minütiges Scoping-Gespräch, keine SQL-Abfrage. Antwort: "Verstanden, verbringen wir Donnerstag 20 Minuten damit, die Entscheidung zu definieren, die dieses Dashboard vorantreiben muss."
  • "Diese Zahl auf dem CS-Dashboard sieht seltsam aus, können Sie nachsehen?" Könnte nichts sein, könnte alles sein. Öffnen Sie es. Die Zahl ist in Ordnung. Die Legende ist falsch, weil jemand ein Measure umbenannt hat. 10-Minuten-Fix in LookML.

Die Priorisierungsregel, die meinen Verstand gerettet hat: "blockiert" von "neugierig" trennen. Blockiert bedeutet, eine Entscheidung kann nicht vorankommen ohne eine Antwort. Neugierig bedeutet, jemand ist in einem Looker-Explore und wurde abgelenkt. Neugierig wird auf Self-Service hingewiesen. Blockiert geht an die Spitze der Warteschlange. Wenn alles "blockiert" ist, ist nichts blockiert.

Das Daten-Team, dem ich angehöre, sind drei Personen. Zusammen erhalten wir 8 bis 12 netto-neue Ad-hoc-Anfragen pro Woche. Ohne Priorisierung frisst die Warteschlange den gesamten Job.

11:00 Uhr - Anforderungsinterview am Mittag

Ein PM bucht 45 Minuten in meinem Kalender. Die Tagesordnung lautet: "Engagement-Dashboard-Scoping." Ich war schon einmal hier. Der PM möchte "ein Dashboard für Engagement." Das ist keine Anfrage. Das ist ein Gefühl.

Mein Job in diesem Meeting ist es, zur tatsächlichen Entscheidung zu gelangen, die das Dashboard vorantreiben wird, und dann rückwärts zu zwei oder drei Metriken zu arbeiten, die keine Vanity-Metriken sind. Hier ist das Fragenscript, das ich verwende, und ich habe es buchstäblich in einem Notion-Dokument geöffnet, wenn das Meeting beginnt:

  1. Welche Entscheidung werden Sie nach dem Blick auf dieses Dashboard anders treffen? (Wenn sie nicht antworten können, ist das Dashboard eine Vanity-Anfrage. Hier aufhören.)
  2. Wer sonst muss es sehen, und welche Entscheidung treffen sie?
  3. Wie oft werden Sie es ansehen (täglich, wöchentlich, monatlich)? (Täglich bedeutet, Sie brauchen einen Slack-Alert, kein Dashboard.)
  4. Welche Zahl, wenn sie sich ändert, würde Sie diese Woche etwas tun lassen?
  5. Was ist die Schwelle? Was gilt als "gut" vs. "schlecht"?
  6. Was ist bereits vorhanden, das fast so ist, aber nicht ganz? (Oft gibt es ein vorhandenes Looker-Explore, das 80 % davon abdeckt.)
  7. Wenn wir nur zwei Charts ausliefern können, welche zwei zählen am meisten?

Der heutige PM sagte "Engagement-Dashboard." Nach 30 Minuten dieser Fragen, was er tatsächlich braucht, ist ein Chart (wöchentlich aktive Nutzer nach Feature-Kohorte) plus einen Slack-Alert, wenn WAU mehr als 10 % Woche-über-Woche fällt. Build-Aufwand: ein halber Tag. Die ursprüngliche Anfrage, für bare Münze genommen: wahrscheinlich zwei Wochen für etwas, das nach dem ersten Sprint niemand öffnen würde.

Der PM, der nach "einem Dashboard" fragt, braucht meistens einen Chart und einen Slack-Alert. Ungefähr 70 % der Zeit, nach meiner Erfahrung.

13:30 Uhr - Async mit Eng und Produkt

Das Mittagessen war ein Sandwich am Schreibtisch beim Überprüfen eines dbt-PRs. Das ist der Übersetzungsteil des Jobs, und das ist der Teil, den Ihnen niemand in Interviews sagt.

Kommentar zum dbt-PR. Ein Analytics Engineer refaktoriert dim_accounts und benennt eine Spalte von account_owner_id zu owner_user_id um. Die PR-Beschreibung erwähnt nicht die vier nachgelagerten Looker-Explores, die auf den alten Namen verweisen. Ich hinterlasse einen Kommentar mit Links zu jedem betroffenen Explore und einer Notiz, dass wir entweder (a) einen Spalten-Alias für Rückwärtskompatibilität benötigen oder (b) einen koordinierten LookML-PR gleichzeitig ausliefern müssen. Dieser 10-Minuten-Kommentar verhindert drei Slack-DMs um 9 Uhr morgen früh, die fragen, warum das Vertriebs-Dashboard kaputt ist.

Auf eine Produkt-Spezifikation antworten. Ein PM hat eine Spezifikation für einen neuen In-App-Onboarding-Flow geschrieben und mich getaggt, ob ich "Engagement mit jedem Schritt verfolgen" kann. Beim Blick auf das Event-Tracking existieren die Events, die er möchte, nicht. Die aktuelle Produktinstrumentierung feuert onboarding_started und onboarding_completed, Punkt. Um die Frage zu beantworten, die ihm tatsächlich wichtig ist (wo brechen Nutzer im Flow ab), brauchen wir schrittweise Events: onboarding_step_viewed mit einer step_name-Eigenschaft. Ich schreibe das in das Spezifikationsdokument mit dem genauen Event-Schema, weise auf den vorhandenen Tracking-Plan in Notion hin und füge ein Jira-Ticket in Engineerings Backlog hinzu, um die Events hinzuzufügen.

Das ist die Arbeit, die in keinem Dashboard auftaucht, aber einen BA, der wiedereingestellt wird, von einem unterscheidet, der es nicht wird. Engineering spricht Tabellen und Schemas. Produkt spricht Features und Ergebnisse. Stakeholder sprechen in Gefühlen und Slack-Nachrichten. Der BA überbrückt alle drei. dbt-PRs vor dem Mittagessen überprüfen spart Looker-Ausfälle nach dem Mittagessen. Das ist der Job.

15:00 Uhr - Exec-Datenzug am Ende des Tages

Der VP Sales pingt mich um 14:55 Uhr. Board-Prep-Call ist um 16 Uhr. Er braucht Quartal-bis-dato-Pipeline nach Segment, aufgeschlüsselt nach Stage und gewichtet nach Stage-Wahrscheinlichkeit. Die Folie wird gerade erstellt.

Das SQL ist in Ordnung. Ich habe eine gespeicherte Abfrage für genau diesen Schnitt. Sie sieht ungefähr so aus:

select
  segment,
  stage,
  count(*) as opps,
  sum(amount) as pipeline_amount,
  sum(amount * stage_probability) as weighted_pipeline
from analytics.fct_opportunities
where close_quarter = 'Q2-2026'
  and is_active = true
group by 1, 2
order by 1, 2;

Das Schwierige ist nicht die Abfrage. Es ist der Vorbehalt. Der VP möchte eine Zahl auf der Folie. Ich muss entscheiden, welche, und ihm sagen warum. Drei Optionen, alle vertretbar:

  • Pipeline-Betrag (Rohsumme): größte Zahl, sieht toll aus, enthält Deals mit 10 % Abschlusswahrscheinlichkeit.
  • Gewichtete Pipeline (Summe × Stage-Wahrscheinlichkeit): ehrlicher, kleiner, was die meisten CFOs bevorzugen.
  • Zugesagte Pipeline (nur Stages 4 und höher): konservativster Wert, was wir im QBR berichten.

Ich sende die Daten mit einem Ein-Absatz-Hinweis: "Die Folie sollte gewichtete Pipeline verwenden. Das ist es, was der CFO letztes Quartal präsentiert hat, und eine andere Definition dieses Quartal zu verwenden wird eine 'Warum hat sich die Methodik geändert?'-Frage auslösen. Wenn der VP die Rohzahl für die Erzählung möchte, listen Sie sie als Fußnote auf."

Die Daten dauern vier Minuten. Die Empfehlung dauert 12. Die Empfehlung ist der Teil, der dafür sorgt, dass ich nächstes Quartal wieder eingeladen werde.

16:30 Uhr - Der "Dieser Bericht ist falsch"-Alarm

Pünktlich wie clockwork. Ein Director of Customer Success Slackt mich: "Hey, die neue Logo-Zahl auf dem CS-Dashboard sagt 47 für April, aber Salesforce sagt 52. Können Sie nachsehen?"

Das ist der häufigste Notfall im Job, und es ist fast immer dieselbe Grundursache. Hier ist das 20-Minuten-Debug, das ich in der Reihenfolge durchführe:

  1. Definitionsprüfung. Was nennt das Dashboard ein "neues Logo"? In Looker ist es auf is_first_paid_invoice = true gefiltert. Im Salesforce-Bericht ist es auf opportunity_stage = 'Closed Won' UND account_type = 'New Logo' gefiltert. Das sind verschiedene Definitionen. Eine Opportunity kann Closed Won sein, aber noch keine bezahlte Rechnung haben (5-Tage-Abrechnungsverzug). Das allein erklärt normalerweise eine 5-Deal-Lücke.
  2. Zeitzonprüfung. Salesforce berichtet in der Ortszeit des Nutzers. Das Looker-Dashboard ist in UTC. Der 30. April in Pacific Time ist der 1. Mai in UTC. Ein oder zwei Deals werden immer in diesem Übergang gefangen.
  3. Filterprüfung. Schließt der Salesforce-Bericht Verlängerungen oder Upgrades ein? Manchmal ist der "Neues Logo"-Filter falsch konfiguriert.
  4. Datenfrische-Prüfung. Wann hat der Salesforce-zu-Snowflake-Sync zuletzt gelaufen? Wenn er vor 10 Minuten lief, gut. Wenn er vor sechs Stunden lief, können zwei weitere Deals seit damals abgeschlossen haben.
  5. Tatsächlicher Datenfehler. Nur nachdem ich die ersten vier ausgeschlossen habe, prüfe ich, ob es ein Upstream-Problem gibt.

Die heutige Antwort: Definitions-Mismatch. Looker verwendet bezahlte Rechnung; Salesforce verwendet Closed Won. Beide sind "richtig", sie beantworten nur verschiedene Fragen. Die Looker-Zahl ist die richtige für die Zwecke des CS-Teams (wir sollten zahlende Kunden feiern, nicht Papier-Abschlüsse), aber ich dokumentiere den Unterschied in der Dashboard-Beschreibung, damit das nächsten Monat nicht wieder passiert.

Die Kommunikation ist genauso wichtig wie die Diagnose. Ich antworte nie mit "Der Salesforce-Bericht ist falsch." Ich antworte mit: "Beide sind korrekt, aber sie messen verschiedene Dinge. Hier ist, was jedes bedeutet, hier ist, warum sie diesen Monat abweichen, und hier ist, welches für das CS-QBR zu verwenden ist." Niemand wird defensiv. Niemand eskaliert. Der Director dankt mir und macht weiter.

"Dieser Bericht ist falsch" ist fast immer ein Definitions-Meinungsverschiedenheit, kein Datenfehler. Vielleicht 80 % der Zeit. Die anderen 20 % sind echte Bugs, und die bekommen ein Jira-Ticket und eine Nachbesprechung.

17:30 Uhr - Tagesabschluss

Heute Morgen kamen fünf Ad-hoc-Anfragen rein. Ich habe drei geschlossen. Zwei wurden auf morgen verschoben mit einer Slack-Antwort, die erklärt, warum, damit niemand sich fragt. Eine habe ich dem Analytics-Engineering-Backlog als wiederkehrende Anfrage hinzugefügt. Die "Abwanderung nach Plantier"-Abfrage kommt ungefähr zweimal pro Quartal rein, und es ist Zeit, sie zu einem Self-Service-Dashboard zu machen, damit sie nicht mehr in meiner Warteschlange landet. Das ist die wirkungsstärkste Maßnahme des ganzen Tages, und sie dauerte zwei Minuten.

Das Letzte, was ich tue, bevor ich den Laptop schließe: eine einzeilige Notiz in meinem Notion-Tagesprotokoll. Was habe ich ausgeliefert, was habe ich gelernt, was wurde verschoben. Morgen früh, wenn die 11 Slack-Nachrichten wieder beginnen, ist dieses Protokoll der Weg, wie ich mich erinnere, welche Feuer bereits brannten.

Das ehrliche Scoreboard

Am Ende eines guten Tages hat der BA ein Stück echter Analyse ausgeliefert (das Engagement-Dashboard-Scoping, das einen Zwei-Wochen-Build in einen Halbtag-Chart-plus-Alert verwandelt hat), drei Stakeholder freigeschaltet (der CFO-Abwanderungs-Pull, der VP-Sales-Pipeline-Schnitt, die CS-Director-Neues-Logo-Frage), und einen Falsch-Zahlen-Vorfall verhindert (der dbt-PR-Kommentar, der den morgigen Looker-Ausfall gerettet hat).

Das ist der Job. Nicht "Erkenntnisse vorantreiben." Nicht "ein strategischer Partner sein." Zeigen Sie auf, halten Sie die Dashboards grün, übersetzen Sie zwischen den Menschen, die nicht miteinander reden können, und beantworten Sie die Frage hinter der Frage.

Die 10 %, die echte strategische Analyse sind, geschehen nur, wenn die 90 % sauber laufen. Die BAs, die befördert werden, sind diejenigen, die das bis zum dritten Monat herausgefunden haben.

Mehr erfahren