Deutsch

Ihre ersten 30/60/90 Tage als neuer Business Analyst

Tag 3. Sie finden noch heraus, welche Slack-Kanäle wichtig sind, als DM Nummer 14 eintrifft: "schnell mal ziehen, kannst du MRR nach Segment bis EOD holen?" Sie haben noch nicht einmal Looker-Zugang. Ihr Laptop läuft seit 19 Stunden.

Sie öffnen das Wiki. Der vorherige BA hat 47 Dashboards hinterlassen. Zwölf davon sind defekt. Die übrigen 35 tragen Namen wie revenue_FINAL_v3_use_this_one. Drei Teams (Finance, RevOps, der Chief of Staff des CEO) sagen Ihnen jeweils im Vertrauen, dass ihre Umsatzzahl die echte ist. Zwei dieser Zahlen stimmen noch nicht einmal auf 8% überein.

Das ist der Job. Nicht die Stellenbeschreibung, sondern der tatsächliche Job. Wenn Sie nicht aufpassen, verlaufen die nächsten 90 Tage genauso wie die des letzten BA: ertrinken in Ad-hoc-Anfragen, kein eigenes Projekt ausliefern und still um Monat vier ausbrennen.

Die meisten BAs verlieren ihr erstes Quartal an die Slack-Warteschlange. So vermeiden Sie das.

Warum ein 30/60/90-Plan speziell für BAs wichtig ist

Entwickler bekommen einen 30/60/90-Plan, weil ihre Arbeit klare Grenzen hat: Tickets, PRs, On-Call-Rotationen. PMs bekommen einen, weil ihre Stakeholder Stand-ups haben. BAs überspringen ihn oft, weil die Arbeit sich anfühlt, als hätte sie keine Kanten.

Genau das ist das Problem.

Ohne einen schriftlichen Plan werden Sie zur SQL-Automatenmaschine. Jemand schickt eine Frage per DM, Sie schreiben eine Abfrage, fügen die Antwort ein und machen weiter. 80-mal pro Woche wiederholen. An Tag 90 fragt Ihr Manager, was Sie geliefert haben, und Sie sagen: "Ich habe 312 Ad-hoc-Anfragen bearbeitet." Das ist keine eigene Leistung. Das ist eine Jira-Warteschlange mit Herzschlag.

Der Job ist Insight, nicht Datenpulls. Der 30/60/90-Plan ist der Weg, sich die Zeit zurückzuerkaufen, um den eigentlichen Job zu erledigen. Er ist ein Vertrag, den Sie mit sich selbst schließen (und still mit Ihrem Manager), der besagt: Im ersten Monat verspreche ich keine Lieferergebnisse. Im zweiten liefere ich eine Sache, die sich multipliziert. Im dritten besitze ich eine Metrik.

Wenn Sie Ihren Manager nicht dazu bringen können, diesen Bogen zu bestätigen, ist das ebenfalls eine Information. Es sagt Ihnen, dass die Rolle ein "Ticket-Abschließer" ist und kein "Analyst". Dann sollten Sie neu verhandeln oder vor Monat zwei Ihren Lebenslauf aktualisieren.

Tage 1-30: Prüfen und lernen (nichts liefern, nichts versprechen)

Der erste Monat hat eine Regel: keine neuen Dashboards, keine neuen Reports, keine Zusagen jenseits von "Ich melde mich bis Dienstag." Sie sind im Empfangsmodus.

Jedes Dashboard, jeden Report und jeden wiederkehrenden Export inventarisieren

Öffnen Sie Looker (oder Tableau, oder Mode, oder was auch immer Ihr Team verwendet). Exportieren Sie die vollständige Asset-Liste. Kennzeichnen Sie jedes Element in einer Tabelle:

Status Definition Maßnahme bis Tag 30
In Verwendung mehr als 20 Aufrufe in den letzten 90 Tagen, benannter Eigentümer Dokumentieren, stehen lassen
Veraltet weniger als 5 Aufrufe in 90 Tagen, kein Eigentümer Zur Abschussliste
Defekt Fehler beim Laden oder Zahlen widersprechen der Quelle Zur Abschussliste, im Audit markieren
Duplikat Dieselbe Metrik wie ein anderes Dashboard, andere Filter Zur Konsolidierung markieren

Ein typisches mittelgroßes SaaS-Unternehmen hat zwischen 40 und 200 BI-Assets, und 30-50% werden als veraltet oder defekt eingestuft. Das ist keine Faulheit des Vorgängers. So sieht es aus, wenn niemand dafür bezahlt wird, ein BI-Portfolio zu pflegen.

Die Abschussliste aufsetzen (noch nicht versenden)

Bis Tag 21 sollten Sie eine schriftliche Liste von 15-25 zu archivierenden Dashboards haben. Versenden Sie das Memo nicht an Tag 21. Warten Sie. Sie haben noch nicht die Glaubwürdigkeit, Dinge zu löschen, und ein Löschmemo von einem drei Wochen alten Mitarbeiter wirkt entweder leichtsinnig oder naiv.

Speichern Sie den Entwurf. Sie versenden ihn an Tag 35, nachdem Sie eine Sache geliefert und etwas Ansehen aufgebaut haben.

Schema-Tiefentauchgang

Suchen Sie das Data-Engineering-Team. Laden Sie es auf einen Kaffee ein. Bitten Sie darum, Sie durch folgende Punkte zu führen:

  • Die 5-7 Kerntabellen, die 80% der Analytics-Abfragen berühren (meistens users, accounts, subscriptions, events, opportunities sowie 1-2 domainspezifische)
  • Wo die dbt-Modelle liegen, wer jedes besitzt und welche aktiv gepflegt werden gegenüber aufgegebenen
  • Alle Umsatzdefinitionsvarianten im Data Warehouse (wir kommen darauf zurück; das ist problematisch)
  • Die "nicht direkt abfragen"-Tabellen (rohe Event-Firehoses, aus Compliance-Gründen gesperrte Tabellen, alles, was den On-Call-Dienst alarmiert)

Machen Sie Notizen. Echte Notizen in einem Dokument, das Ihr zukünftiges Ich durchsuchen kann. Bis Tag 30 sollten Sie in der Lage sein, "Wo liegt ARR?" zu beantworten, ohne jemanden zu fragen.

1:1 mit den fünf häufigsten Ad-hoc-Anfragenden

Ziehen Sie die letzten 90 Tage Anfragen aus der Warteschlange des vorherigen BA (Slack-Verlauf, Jira, wo auch immer). Sortieren Sie nach Volumen. Die fünf häufigsten Anfragenden haben 60-70% der Last erzeugt. Buchen Sie 30 Minuten mit jedem.

Die Frage ist nicht "welche Reports möchten Sie?" Das ergibt eine Wunschliste von 14 Dashboards. Die Frage ist: Welche Entscheidung treffen Sie tatsächlich mit diesen Daten?

Sie werden feststellen, dass 3 der 5 häufigsten Anfragenden Analytics nutzen, um dieselbe Grundfrage zu beantworten ("Erreichen wir die Zahl?") mit unterschiedlicher Rahmung. Das ist eine Konsolidierungschance. Die anderen 2 leisten echte, eigenständige Arbeit und verdienen ihre eigene Lösung.

Ein Aufnahmeformular einrichten

Selbst ein Notion-Formular ist besser als DMs. Das Formular braucht drei Felder: Welche Entscheidung treffen Sie, wann brauchen Sie es, und wie sieht "gut genug" aus? Das dritte Feld eliminiert 40% der Anfragen sofort, weil der Anfragende erkennt, dass er es tatsächlich nicht weiß.

Informieren Sie die Leute sanft in Woche 4 über das Formular. Setzen Sie es noch nicht durch. Ab Tag 31 hat es Verbindlichkeit.

Tage 31-60: Eine hochwertige Sache liefern und die SLA festlegen

Im zweiten Monat beginnen Sie, bezahlt zu werden. Sie haben sich das Recht erarbeitet, Maßnahmen zu ergreifen. Nutzen Sie es.

EINE Dashboard wählen, die 5+ Ad-hoc-Pulls ersetzt

Schauen Sie sich Ihre Anfragenanalyse an. Finden Sie das Dashboard-förmige Loch in der Welt, das, wenn es gefüllt würde, die meisten DMs zum Schweigen bringen würde. Für die meisten B2B SaaS-BAs in ihrem ersten Jahr ist es eine Variante von:

  • Ein einheitliches Pipeline-und-Umsatz-Dashboard mit konsistenten Definitionen in Sales, CS und Finance
  • Eine Abwanderungs-und-Expansions-Ansicht nach ICP segmentiert
  • Eine Produkt-Nutzungs-zu-Umsatz-Brücke für die PLG-Bewegung

Wählen Sie eine. Liefern Sie sie. Bringen Sie einen Führungskraft dazu, sie in einem Meeting zu nutzen. Das ist die Messlatte. Nicht "unternehmensweit ausgerollt." Einmal genutzt, in einem echten Entscheidungskontext. Wenn der CRO sie beim Montags-Forecast-Call aufruft, haben Sie Monat zwei gewonnen.

Die Ad-hoc-SLA veröffentlichen

Versenden Sie das schriftlich, in den Kanal, an Tag 35:

Ad-hoc-Analytics-SLA

  • Priorisierung innerhalb von 24h: Ich antworte, grenze es ein und teile mit, ob es ein 20-Minuten-Pull, ein 2-Tage-Projekt oder etwas ist, für das wir ein Dashboard bauen sollten.
  • 72h-Lieferung für eingegrenzte Pulls unter 4 Stunden Aufwand.
  • Alles Größere geht über das Aufnahmeformular und wird wöchentlich priorisiert.
  • Drive-by-DMs ohne Kontext werden an das Formular weitergeleitet.

Die Leute werden das 10 Tage lang ablehnen. Dann werden sie es lieben, weil die Anfragen, die zurückkommen, tatsächliche Entscheidungen enthalten und die Antworten haften bleiben.

Die Abschussliste abarbeiten

Versenden Sie das Memo. Geben Sie eine zweiwöchige Frist ("diese Dashboards werden am 14. Mai archiviert, sofern nicht jemand die Eigentümerschaft übernimmt"). Zwei oder drei werden beansprucht, und das ist in Ordnung. Übergeben Sie sie. Den Rest archivieren. Löschen Sie nicht im Warehouse, sondern nur die Veröffentlichung im BI-Tool. Sie können jederzeit wiederherstellen.

Bis Tag 60 sollten Sie 12-20 Assets entfernt haben und das BI-Tool sollte sich spürbar weniger überladen anfühlen.

Die Time-to-Insight-Basis festlegen

Bevor Tag 60 endet, legen Sie eine Basismesung fest: wie lange dauert es, bis eine Stakeholder-Anfrage von "gestellt" zu "beantwortet mit einer Entscheidung" geht? Verfolgen Sie den Median, nicht den Mittelwert. Ein wochenlanger Auftrag verzerrt den Durchschnitt und sagt nichts aus.

Drei Varianten, die funktionieren:

  • Mediane Anfrage-Abschlusszeit: von der Aufnahme bis zur "Entscheidung protokolliert" (in Tagen)
  • Datengestützte Entscheidungen: Prozentsatz der Führungsentscheidungen der letzten 30 Tage, die sich auf einen Analytics-Output bezogen haben (10 prüfen, nachfragen)
  • Dashboard-zu-Pull-Verhältnis: wie viele Self-Service-Dashboard-Aufrufe gab es pro Ad-hoc-Anfrage

Wählen Sie einen. Messen Sie jetzt. Schreiben Sie die Zahl auf. Sie brauchen sie an Tag 90.

Tage 61-90: Die Metrik besitzen, den Report präsentieren

Im dritten Monat hören Sie auf, "der neue BA" zu sein und werden "der Analyst, der Time-to-Insight besitzt." Diese Verschiebung intern ist das, was die nächste Rolle freischaltet.

Time-to-Insight verbessern

Sie haben es an Tag 60 gemessen. Jetzt verbessern Sie es. Die Hebel sind unspektakulär:

  • Die drei häufigsten wiederkehrenden Fragen als Dashboard abbilden, damit sie keine Anfragen mehr sind
  • 2-3 Abfrage-Templates bauen, von denen das Team Self-Service nutzen kann
  • "Schnelle Pulls" höflich zurückweisen, die eigentlich Scope Creep sind ("das ist ein Projekt, lassen Sie uns es aufnehmen")
  • Einmal pro Woche mit einem Stakeholder gemeinsam analysieren, damit er das Schema kennenlernt

Ein realistisches Ziel für Monat drei: die mediane Anfrage-Abschlusszeit um 30-40% senken oder das Dashboard-zu-Pull-Verhältnis um 50% gegenüber dem Ausgangswert steigern. Beides ist erreichbar, wenn Monat eins und zwei richtig gemacht wurden.

Den 90-Tage-Report-Deck erstellen

An Tag 85 schreiben Sie ein 7-Folien-Deck für Ihren Manager und den nächsthöheren Vorgesetzten. Kein wandfüllender Textwürfel. Ein Deck. Folien:

  1. Was ich geerbt habe: 47 Dashboards, 14 Versionen von Revenue, Ad-hoc-Backlog von 23, keine SLA
  2. Was ich entfernt habe: Archivierungsliste mit Aufrufzahlen (die Belege zählen)
  3. Was ich geliefert habe: das eine hochwertige Dashboard, mit der Führungskraft, die es nutzt, namentlich genannt
  4. Die SLA: Veröffentlichungsdatum, Akzeptanzrate, aktueller Stand der Aufnahmewarteschlange
  5. Time-to-Insight: Basiswert an Tag 60, aktueller Wert an Tag 90, das Delta
  6. Schema-Bereinigungserfolge: die kanonische Revenue-Definition (nächster Abschnitt), alle weiteren Konsolidierungen
  7. Nächste 90 Tage: 1-2 quartalsweise OKRs, die Sie vorschlagen zu besitzen

Das Deck sollte 15 Minuten zum Durchgehen dauern. Wenn es 30 Minuten braucht, kürzen.

1-2 quartalsweise OKRs festlegen, die Sie wirklich besitzen

Am Ende des Meetings sollte Ihr Manager einem oder zwei Ergebnissen zustimmen, für die Sie im nächsten Quartal verantwortlich sind. Beispiele, die funktionieren:

  • "Mediane Time-to-Insight von 6 Tagen auf 2 Tage bis Ende Q3 reduzieren"
  • "Die 3 meistgenutzten Ad-hoc-Reports auf Self-Service-Dashboards migrieren"
  • "Kanonische Metrikdefinitionen für Revenue, ARR und Net Retention etablieren; alle Varianten archivieren"

Was Sie vermeiden sollten: "das Team mit Analytics unterstützen." Das ist kein OKR, das ist eine Stellenbeschreibung, und beim Review gibt Ihrem Manager das nichts Konkretes zu verteidigen.

Die "Looker hat 14 Versionen von Revenue"-Realität

Irgendwo in Monat eins haben Sie festgestellt, dass das Warehouse 14 verschiedene Revenue-Definitionen hat. Gebucht, abgerechnet, eingezogen, anerkannt (GAAP), anerkannt (intern), MRR-umgerechnet, ARR-umgerechnet, ARR-Netto-Abwanderung, Brutto-Retention, Netto-Retention, ARR-mit-Rampdeals, nur Expansion, nur Neukunden und eine Spalte, die buchstäblich revenue_FINAL heißt.

Das können Sie nicht in Woche eins beheben. Wahrscheinlich auch nicht im ersten Quartal. Aber Sie können anfangen, und der Anfang ist der Unterschied zwischen einem BA und einem Senior BA.

Das nicht-politische Playbook:

  1. Einen Hüter wählen, keinen Gewinner. Stellen Sie sich nicht auf die Seite von Finance oder RevOps. Bringen Sie eine Person aus jedem (plus Sie selbst) dazu, dem Standards-Komitee zuzustimmen. Drei Personen. Treffen Sie sich 45 Minuten.
  2. EINE kanonische Definition vorschlagen für die am heißesten umkämpfte Metrik (meistens ARR oder Net Retention). Schreiben Sie das SQL. Zeigen Sie, welche Zahl es für das letzte Quartal ergibt. Vergleichen Sie mit der aktuellen Zahl jedes Teams.
  3. Freigabe schriftlich einholen. Ein Slack-Thread ist in Ordnung. Der Punkt ist: wenn später jemand die Zahl anzweifelt, können Sie darauf verlinken.
  4. Den Rest in dbt archivieren. Alte Modelle als veraltet markieren, 30 Tage Frist geben, dann entfernen. Die Dashboards anderer Teams werden defekt werden. Senden Sie die Warnung, halten Sie die Linie.
  5. Nächstes Quartal die nächste Metrik wiederholen. Das ist eine 12-monatige Bereinigung, kein Sprint.

Die Falle besteht darin, 14 Metriken in Monat zwei zu kanonisieren. Sie werden einen Revierkampf auslösen, verlieren und das politische Kapital verbrennen, das Sie für alles andere benötigen. Eine Metrik pro Quartal. Langsam und abgezeichnet schlägt schnell und zurückgesetzt.

Häufige Fallen vermeiden

Einige Muster, die neue BAs in den ersten 90 Tagen versenken:

  • Jedem Pull zustimmen. Sie fühlen sich hilfreich. Das sind Sie nicht. Sie trainieren die Organisation, das Aufnahmeformular zu umgehen. In Monat drei ist die SLA verfault und Sie sind wieder im Automaten-Status.
  • Vor dem Verstehen neu bauen. Es ist verlockend, die Arbeit des vorherigen BA zu vernichten und sauber neu zu beginnen. Tun Sie es nicht. Die Hälfte davon ist tragendes Element auf Weisen, die nicht offensichtlich sind. Erst prüfen, dann entfernen, dann bauen.
  • Das Data-Engineering-Team ignorieren. Sie besitzen Ihre Eingabedaten. Wenn Sie ein Dashboard auf einer Tabelle aufbauen, die sie gerade archivieren wollen, erfahren Sie das genau zum schlechtesten Zeitpunkt. Laden Sie auf den Kaffee ein.
  • Keine schriftliche SLA. Verbale SLAs sind keine SLAs. Sie sind Eindrücke. Eindrücke überstehen keinen Q3-Schub.
  • In den Metrikenkriegen Partei ergreifen. Wenn RevOps und Finance über Revenue uneinig sind, ist Ihr Job, das Standards-Gespräch einzuberufen, keinen Gewinner zu erklären. Eine Seite wählen gibt Ihnen einen Verbündeten und einen Feind. Das Gespräch einzuberufen gibt Ihnen zwei Verbündete.

An Tag 90 sollten Sie an ermöglichten Entscheidungen gemessen werden

Wenn Ihr Manager Ihr Tag-90-Review öffnet und fragt "wie viele Abfragen haben Sie ausgeführt", haben Sie den falschen Manager (oder die falsche Rahmung der Rolle) und müssen eines davon beheben.

Die richtige Rahmung: Wie viele Entscheidungen hat Ihre Arbeit ermöglicht, wie viel schneller kam die Organisation zu diesen Entscheidungen, und welches kumulative Asset (ein Dashboard, eine SLA, eine kanonische Metrik) haben Sie hinterlassen, von dem das nächste Quartal profitiert?

Das ist der Unterschied zwischen einem BA und einer Automatenmaschine. Die Automatenmaschine schließt Tickets. Der BA verändert, wie das Unternehmen sich selbst sieht. Ab Tag 90 beginnt sich dieser Unterschied in Ihrem Kalender zu zeigen. Weniger Ad-hoc-DMs, mehr "Können Sie am Planning-Meeting teilnehmen, wir möchten Ihre Einschätzung."

Wenn diese Einladung auftaucht, sind Sie über das Onboarding hinaus und im eigentlichen Job. Jetzt bauen Sie die nächsten 90.

Mehr erfahren