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

Es ist 9:47 Uhr an Tag 3. Sie haben gerade herausgefunden, wie Ihr VPN funktioniert. Eine Slack-Nachricht von jemandem, dessen Namen Sie nicht kennen: „Hey, willkommen! Kurze Sache: Können Sie MRR nach Segment für das Board-Deck von morgen abrufen? Einfach aufgeteilt nach ARR-Band und Akquisitionskanal. Danke!"

Wie Sie auf diese Nachricht antworten, entscheidet die nächsten 12 Monate.

Wenn Sie Ja sagen und die Abfrage ausführen, haben Sie gerade den Vertrag unterschrieben. Sie sind jetzt die Ad-hoc-Abfrageperson. Sie werden 40 Stunden pro Woche mit „kurzen Sachen" verbringen und null strategische Arbeit liefern. Wenn Ihre Führungskraft an Tag 91 fragt, was Sie erreicht haben, haben Sie ein Slack-Archiv statt einer Geschichte.

Wenn Sie Nein sagen, sind Sie die neue Analystin, die das Board-Deck blockiert hat. Auch nicht gut.

Es gibt einen dritten Weg. Dieser Leitfaden ist dieser Weg.

Warum Analysten ein 30/60/90-Rahmenwerk mehr brauchen als alle anderen

Engineers bekommen ein Backlog. PMs bekommen eine Roadmap. Designer bekommen eine Figma-Datei, die bereits in Bewegung ist. Analysten kommen in einen Job, bei dem jeder Stakeholder glaubt, Priorität zu haben, die vorherige Analystin keine Dokumentation hinterlassen hat und der Unternehmensbildschirm Dashboards zeigt, die seit acht Monaten nicht angefasst wurden. Die Hälfte davon ist falsch. Niemand weiß, welche Hälfte.

Ohne einen Rahmen werden Sie zur SQL-Verkaufsmaschine. Mit einem werden Sie zur Person, die 30 defekte Dashboards abgeschaltet, ein kanonisches Umsatzmodell geliefert und das H2-Planungsmeeting mit einer Analytics-Roadmap betreten hat, um die Ihr VP nicht gebeten hatte, sie aber dringend brauchte.

Der Rahmen ist einfach: erst auditieren, dann eine Sache liefern, dann eine Kennzahl besitzen. Drei Monate. Eine Aufgabe pro Monat. Nicht vorspringen.

Tage 1 bis 30: Auditieren, nicht bauen

Der größte Fehler, den ich bei neuen Analysten sehe, ist, am vierten Tag einen SQL-Editor zu öffnen und etwas zu „reparieren". Sie wissen noch nicht, was kaputt ist. Sie wissen nicht, was tragend ist. Sie wissen nicht, welches „kaputte" Dashboard das einzige ist, dem der CFO vertraut.

Monat eins ist Aufklärung. Sie schreiben fast keine Abfragen. Sie machen viele Notizen.

Woche 1: Dashboard-Inventar

Rufen Sie eine Liste jedes Dashboards, Berichts und jeder gespeicherten Abfrage in Ihrem BI-Tool ab (Looker, Mode, Tableau, Metabase oder was auch immer Sie geerbt haben). Erfassen Sie für jedes fünf Felder:

• Name
• Eigentümer (oder „unbekannt")
• Aufrufhäufigkeit der letzten 60 Tage
• Letztes Bearbeitungsdatum
• Status (aktiv / verdächtig / inaktiv)

Inaktiv bedeutet: null Aufrufe in 60 Tagen, oder zuletzt bearbeitet von jemandem, der vor mehr als sechs Monaten das Unternehmen verlassen hat. Bei einem typischen mittelgroßen SaaS-Unternehmen werden Sie feststellen, dass 60 bis 70 Prozent der Dashboards inaktiv sind. Bei meinem letzten Unternehmen hatten wir 312 Dashboards. Nach dem Audit wurden 47 tatsächlich genutzt. Der Rest war Geisterschiffe.

Löschen Sie noch nichts. Erstellen Sie nur die Liste.

Woche 2: Schema-Rundgang und der kanonische Umsatzstreit

Jetzt lesen Sie. Öffnen Sie das dbt-Repository (oder Ihr Data Warehouse, falls kein dbt vorhanden ist). Suchen Sie die fünf Tabellen, die Sie jede Woche anfassen werden (meist eine Variante von accounts, subscriptions, events, users und einer Umsatztabelle). Lesen Sie die Modelldefinitionen. Lesen Sie die Spaltenkommentare. Lesen Sie die Macros.

Mit statistischer Sicherheit werden Sie feststellen, dass Ihr Unternehmen mehrere Umsatzdefinitionen hat. Bei einem Unternehmen, bei dem ich arbeitete, lebten 14 Umsatzvarianten im Data Warehouse. Gebuchter ARR. Fakturierter ARR. Prognostizierter ARR. Netto-Neu-ARR. Brutto-Bereinigter ARR. Jede war für einen bestimmten Zweck korrekt und für einen anderen falsch. Finance nutzte eine. Sales eine andere. Der CEO hatte eine dritte in einem Google Sheet.

Das ist normal. Es ist auch Ihre wichtigste Aufgabe in Woche 2. Vereinbaren Sie ein Meeting mit Ihrem Finance-Gegenüber. Fragen Sie: „Welche davon ist die maßgebliche Datenquelle für das Board?" Erhalten Sie die Antwort schriftlich. Nicht als Slack-Nachricht, sondern als Dokument. Dieses Gespräch ist das Fundament, auf dem alles andere aufbaut.

Wenn Finance Ihnen keine Antwort geben kann, ist das ein Befund. Notieren Sie ihn.

Woche 3: Stakeholder-Syncs (zuhören, nicht präsentieren)

Nehmen Sie an fünf Meetings teil: Revenue Ops, Customer Success, Marketing, Product, Finance. Sie sind nicht dort, um zu präsentieren. Nicht, um sich „vorzustellen". Sie sind dort, um die wiederkehrenden Fragen zu hören.

Das Muster, das Sie suchen: dieselbe Frage, von drei verschiedenen Teams auf drei verschiedene Arten gestellt. Das ist Ihr Woche-5-Dashboard.

Beispiele aus meinen Woche-3-Syncs:

• RevOps-Lead: „Wir wissen nie, in welchem Segment unser Pipeline tatsächlich konzentriert ist."
• CS-Director: „Ich wünschte, ich könnte Expansion ARR nach Branche sehen, ohne in ein Sheet zu exportieren."
• CMO: „Marketing-sourced Pipeline nach Segment liegt an fünf verschiedenen Stellen."

Das ist dieselbe Frage dreimal. Das ist das Dashboard, das Sie in Monat zwei bauen.

Bringen Sie ein Notizbuch. Öffnen Sie Ihren Laptop nicht. Bieten Sie nicht an, „schnell etwas abzurufen". Wenn jemand fragt, sagen Sie: „Ich bin für die nächsten zwei Wochen im Audit-Modus. Tragen wir es in das Aufnahmeformular ein, sobald es online ist." (Mehr zum Aufnahmeformular gleich.)

Woche 4: Die Abschalteliste

Jetzt schlagen Sie vor, die inaktiven Dashboards außer Betrieb zu nehmen. Hier schrecken neue Analysten zurück. Nicht tun.

Kehren Sie zu Ihrem Inventar zurück. Suchen Sie für jedes inaktive Dashboard den ursprünglichen Ersteller (oder das Team) und fragen Sie: „Das wurde seit X Tagen nicht mehr aufgerufen. Sind Sie damit einverstanden, dass ich es archiviere?" In 80 Prozent der Fälle lautet die Antwort: „Ja, bitte, ich hatte vergessen, dass es existiert." In 15 Prozent: „Behalte es, ich nutze es monatlich." In 5 Prozent erfahren Sie etwas Wichtiges über das Unternehmen.

Holen Sie die Zustimmung schriftlich ein. Ein Slack-Thread reicht. Dann archivieren, nicht löschen. Die meisten BI-Tools ermöglichen Archivierung mit einem Klick zur Wiederherstellung. Sie wollen einen Nachweis.

Das Skript, das für mich funktioniert hat:

Hey [Name], ich führe im Rahmen des Onboardings eine Dashboard-Bereinigung durch. Das „[Dashboard-Name]" hatte in 73 Tagen keinen Aufruf und wurde zuletzt von [Person, die gegangen ist] bearbeitet. Ich würde es gern archivieren (reversibel, kein Löschen). Einverstanden? Wenn Sie es lieber behalten möchten, kein Problem, ich möchte nur bestätigen, dass jemand es besitzt.

Versenden Sie diese in Zehnerbatches. Antworten nicht nachverfolgen. Keine Reaktion nach 5 Werktagen bedeutet: archivieren. Alles dokumentieren.

Bis Ende Woche 4 haben Sie typischerweise 40 bis 150 Dashboards abgeschaltet. Das ist Ihr erstes Ergebnis. Es ist auch das einzige Ergebnis, das Sie vorzeigen können, ohne eine Zeile SQL geschrieben zu haben. Genau das ist der Punkt.

Tage 31 bis 60: Eine Sache liefern, SLA festlegen

Monat zwei ist dort, wo die Arbeit sichtbar wird. Aber Sie dürfen nur drei Dinge tun. Ein Dashboard liefern. Ein SLA veröffentlichen. Ein dbt-Modell bauen. Das war es. Widerstehen Sie der Versuchung, mehr zu tun.

Das eine Dashboard liefern, um das alle gebeten haben

Erinnern Sie sich an die Frage aus Woche 3, die drei Teams gestellt haben? Bauen Sie dieses Dashboard. Nur dieses eine.

Die Disziplin hier ist brutal. Jemand wird fragen: „Könntest du dabei auch noch…?" Und die Antwort ist nein. Nicht weil die Anfrage schlecht ist, sondern weil jedes „dabei auch noch…" die Ad-hoc-Abfragepersonen-Falle mit zusätzlichen Schritten ist. Liefern Sie die eine Sache. Machen Sie sie gut. Liefern Sie sie.

Ein „gutes" erstes Dashboard bedeutet:

• Eine Frage, klar beantwortet. Nicht fünf Fragen.
• Die Kennzahldefinition ist die kanonische, um die in Woche 2 gestritten wurde, und die Dashboard-Fußzeile sagt das. („Umsatz definiert gemäß [Link zum dbt-Modell]. Zuletzt abgestimmt mit Finance am [Datum].")
• Maximal drei Filter. Segment, Datumsbereich, ein teamspezifischer Schnitt.
• Ein einleitender Absatz „So lesen Sie dieses Dashboard".
• Ein Eigentümer (Sie) und ein „Fragen?"-Slack-Channel.

Der letzte Punkt ist nicht verhandelbar. Jedes Dashboard ohne Eigentümer wird in 18 Monaten zum Geisterschiff. Sie werden der Analyst sein, der dieses Muster durchbricht.

Das Ad-hoc-SLA veröffentlichen

Das ist der Moment, an dem Sie aufhören, eine SQL-Verkaufsmaschine zu sein. Sie veröffentlichen eine einzelne Seite (ein Notion-Dokument, eine Confluence-Seite, was auch immer Ihr Unternehmen nutzt):

Ad-hoc-Datenanfragen-Aufnahme

1. Einreichen über [Formular / #data-requests-Channel]. Direkte Nachrichten an mich werden hierher weitergeleitet.
2. Drei Pflichtfelder: was Sie benötigen, bis wann Sie es benötigen, welche Entscheidung es informiert.
3. SLA: Anfragen unter 4 Stunden Aufwand, selber Tag oder nächster Morgen. Anfragen über 4 Stunden werden in den nächsten Sprint triagiert.
4. Alles mit dem Tag „board deck" oder „exec review" kommt nach vorne in die Warteschlange.

Drei Pflichtfelder. Nicht sieben. Nicht ein 14-Fragen-Aufnahmeformular. Das dritte Feld (welche Entscheidung es informiert) hat die magische Wirkung. Die Hälfte der Anfragen stirbt daran, weil die anfragende Person erkennt, dass sie die Daten eigentlich gar nicht braucht, sie waren nur neugierig. Die andere Hälfte kommt präziser herein, weil die Person zuerst nachdenken musste.

Lassen Sie Ihre Führungskraft die Ankündigung machen, nicht Sie. „Hallo Team, [Ihr Name] übernimmt jetzt die Analytics-Aufnahme. Bitte nutzen Sie das Formular." Dieser Satz ist hundert direkte Nachrichten wert, die Sie nicht absorbieren müssen.

Das SLA bedeutet kein Neinsagen. Es macht „nächsten Sprint" zu einer normalen Antwort statt zu einem Streit.

Ein dbt-Modell bauen

Das dbt-Modell ist die kanonische Umsatzdefinition, um die in Woche 2 gestritten wurde. Nur dieses eine. Nicht eine Metriken-Schicht. Nicht ein semantisches Refactoring. Ein Modell.

Nennen Sie es fct_revenue_canonical oder wie auch immer die Konvention Ihres Repositories lautet. Schreiben Sie den Dokumentationsblock. Fügen Sie Tests hinzu. Lassen Sie es reviewen. Mergen Sie es. Aktualisieren Sie Ihr Woche-5-Dashboard, sodass es daraus bezieht.

Das ist Ihr „Ich gehöre hierher"-Moment. Wenn jemand in einem Meeting sagt „warte, welche Umsatzzahl verwenden wir?" und ein Teamkollege antwortet „die kanonische, das ist das dbt-Modell, das [Ihr Name] geliefert hat", das ist der Moment, an dem Sie aufhören, der neue Analyst zu sein, und der Analyst werden.

Versuchen Sie unter keinen Umständen, den Rest des Data Warehouses in Monat zwei zu refaktorisieren. Der Friedhof neuer Analysten ist gepflastert mit Menschen, die in Woche 6 „alles neu aufbauen" wollten und in Woche 8 einen Board-Bericht kaputt gemacht haben. Liefern Sie ein Modell. Machen Sie weiter.

Tage 61 bis 90: Eine Kennzahl besitzen, den Plan pitchen

Monat drei ist der Punkt, an dem Sie nicht mehr nach abgeschlossenen Tickets gemessen werden, sondern danach, was Sie besitzen.

Zeit-bis-zur-Erkenntnis als Ihre Kennzahl übernehmen

Wählen Sie eine teamweite Kennzahl und besitzen Sie sie. Die stärkste für Analysten ist Zeit bis zur Erkenntnis: Median-Stunden von „Anfrage eingereicht" bis „Datenantwort geliefert". Manche Teams nennen es Erstantwortzeit auf Datenfragen. Gleiche Idee.

Messen Sie sie anhand Ihres Aufnahmeformulars (Sie haben jetzt eines). Ermitteln Sie einen Ausgangswert in Woche 9. Setzen Sie ein Ziel für Woche 12. Meins war: Median 6 Stunden, Ziel unter 4.

Warum diese Kennzahl und nicht, sagen wir, „Dashboard-Nutzungsgrad" oder „ausgeführte Abfragen"? Weil die Zeit bis zur Erkenntnis das ist, was Ihre Stakeholder spüren. Sie bemerken keine steigende Nutzung. Sie bemerken, wenn ihre Frage vor dem Mittagessen beantwortet wird statt erst nächsten Dienstag.

Berichten Sie sie wöchentlich im Standup Ihres Teams. Drei Zahlen: Median, p90, Anzahl. Das war es.

Der 90-Tage-Bericht

Schreiben Sie Ihrer Führungskraft etwa an Tag 85 einen einseitigen Bericht. Vier Abschnitte, in dieser Reihenfolge:

Abgeschaltet. Anzahl archivierter Dashboards mit Liste. Geschätzte Einsparung an Warehouse-Last, falls messbar.

Geliefert. Das eine Dashboard. Das eine dbt-Modell. Das Aufnahmeformular mit zwei Monaten Durchsatzdaten.

Kaputt. Was Sie gefunden haben, das noch falsch ist. Konkret. „Das MRR-nach-Segment-Modell zählt Trial-Conversions in der EMEA-Region doppelt. Betrifft 4 Dashboards. Die Behebung ist ein 1-Wochen-Projekt." Nichts beschönigen. Ihre Führungskraft will die Liste.

Nächste Schritte. Zwei strategische Projekte, eine Plattforminvestition, eine Personalanfrage falls relevant. Konkret. Mit groben Zeitrahmen.

Eine Seite. Nicht mehr. Als Dokument senden, dann in Ihrem 1:1 durchgehen.

Der H2-Plan-Pitch

Der 90-Tage-Bericht ist das Aufwärmen. Der Pitch kommt als nächstes. Im selben 1:1 sagen Sie: „Ich möchte den H2-Analytics-Plan besitzen. Die grobe Form: zwei strategische Projekte (X und Y), eine Plattforminvestition (eine Metriken-Schicht / Reverse ETL / Experimentation Framework) und eine Personalentscheidung (stellen wir einen zweiten IC oder einen Senior für die Leitung ein?). Ich habe bis [Datum] ein vollständiges Dokument."

Das ist der Moment, der den Analysten unterscheidet, der fünf Jahre IC bleibt, von dem, der in 18 Monaten ein Team führt. Die meisten Analysten warten, dass ihre Führungskraft für sie plant. Sie werden für Ihre Führungskraft planen.

Sie werden auf Widerstand stoßen. Der Plan wird bearbeitet. Zwei Ihrer Projekte werden gestrichen. Das ist in Ordnung. Der Pitch ist die Handlung, nicht das Artefakt.

Die Fallstricke (diese werden verlocken, lassen Sie sich nicht verführen)

In Monat 1 auf jede Ad-hoc-Anfrage Ja sagen. Ich habe es am Anfang gesagt, ich sage es nochmal. Das Ad-hoc-Laufband ist eine Einbahnstraße. Sie sagen in Woche 1 Ja, Sie sagen in Jahr 2 immer noch Ja.

Das Data Warehouse in Woche 2 neu aufbauen. Sie verstehen das Unternehmen noch nicht. Das „offensichtlich kaputte" Modell ist für jemanden tragend, den Sie noch nicht kennengelernt haben. Erst auditieren.

60 Tage schweigen, dann ein 40-seitiges Audit abliefern. Niemand hat nach dem Audit gefragt. Sie fragten nach Belegen, dass Sie existieren. Liefern Sie die Abschalteliste in Woche 4. Veröffentlichen Sie das SLA in Woche 6. Zeigen Sie sich.

Ein Dashboard mit der falschen Umsatzdefinition liefern. Sie haben die Finance-Abstimmung in Woche 2 übersprungen. Jetzt widerspricht Ihr Dashboard dem Board-Deck. Vertrauen ist verbrannt. Schwer wiederaufzubauen. Nicht tun.

Vorlagen, die Sie tatsächlich verwenden werden

Dashboard-Inventar-Tabelle. Sechs Spalten: Name, Eigentümer, zuletzt aufgerufen (Datum), zuletzt bearbeitet (Datum), Status (aktiv/verdächtig/inaktiv), Archivierungs- oder Behaltensentscheidung. Eine Zeile pro Dashboard. Nach zuletzt-aufgerufen aufsteigend sortieren, und die inaktiven schwimmen nach oben.

Stakeholder-Sync-Fragenliste. Fünf Fragen, in dieser Reihenfolge: (1) Welche Entscheidungen haben Sie letztes Quartal getroffen, bei denen Sie sich bessere Daten gewünscht hätten? (2) Welche Zahl prüfen Sie jeden Morgen? (3) Welches Dashboard nutzen Sie tatsächlich, versus welches Dashboard existiert für Sie? (4) Welche Frage bekommen Sie von Ihrer Führungskraft immer wieder, die Sie nicht schnell beantworten können? (5) Wenn ich Ihnen eine neue Perspektive auf das Unternehmen geben könnte, welche wäre das? Beachten Sie, dass keine davon lautet „Was brauchen Sie von mir?" Diese Frage liefert eine Wunschliste. Die obigen Fragen liefern die Wahrheit.

Ad-hoc-Aufnahmeformular. Drei Felder. Anfrage. Deadline. Entscheidung, die sie informiert. Das war es.

90-Tage-Bericht. Eine Seite. Abgeschaltet. Geliefert. Kaputt. Nächste Schritte. Aufzählungspunkte, keine Absätze.

Was „erfolgreich" an Tag 90 bedeutet

An Tag 90 ist die Dashboard-Anzahl in Ihrem BI-Tool gesunken, nicht gestiegen. Es gibt ein kanonisches dbt-Modell für die Kennzahl, über die Ihr Unternehmen früher gestritten hat. Stakeholder nutzen das Aufnahmeformular anstatt Ihnen direkt zu schreiben. Ihre Führungskraft hat von Ihnen einen schriftlichen H2-Plan, nicht umgekehrt. Und irgendwo auf dem Unternehmensbildschirm zeigen die Dashboards an einem Dienstag dieselbe Zahl wie an einem Freitag.

Sie sind nicht die Ad-hoc-Abfrageperson. Sie sind der Analyst.

Das ist der Job.

Mehr erfahren

• Data Analyst Stellenbeschreibung
• Ein Tag im Leben eines Data Analysts
• SQL und Datenmodellierung, die skaliert
• Stakeholder-Übersetzung: Von vagen Anfragen zu lieferbaren Analysen
• Data Analyst Kennzahlen: Zeit bis zur Erkenntnis, Nutzungsgrad, Wirkung
• Häufige Fallstricke für Data Analysts