Deutsch

Häufige Fehler von Business Analysts (und wie man herauskommt)

Ich traf letzten Monat einen BA auf einen Kaffee. Vierzehn Monate im Job. Scharf, schnell, beliebt. Sie erzählte mir, sie "ertrinke in Anfragen": mehr als sechzig Tickets pro Quartal, Wochenenden, die in Montage übergehen, kein Ende in Sicht.

Ich stellte ihr eine Frage: Nennen Sie mir eine Entscheidung, die Ihre Arbeit letztes Quartal verändert hat.

Sie konnte es nicht. Nicht eine. Sie hatte 47 Dashboards ausgeliefert, 312 Slack-Pings beantwortet, Abfragen geschrieben, die ein Senior Engineer zum Nicken gebracht hätten. Und sie konnte keine einzige Entscheidung nennen, die durch irgendetwas davon anders verlaufen war.

Diese Lücke ist der gesamte Artikel. Es ist auch der Unterschied zwischen dem BA, der im zweiten Jahr befördert wird, und dem, der im vierten Jahr immer noch Ad-hoc-Abfragen ausführt.

Warum das zweite Jahr die Weggabelung ist

Die meisten BAs überleben das erste Jahr mit purer Anstrengung. Sie lernen das Schema, merken sich die Dashboards, finden heraus, wer wirklich was besitzt. Ergebnisse sehen wie Fortschritt aus, weil alles neu ist.

Das zweite Jahr ist anders. Das Schema ist nicht mehr neu. Die Ergebnisse sehen genauso aus wie im ersten Jahr (dieselben Abfragen, dieselben Dashboards, dieselben Slack-Threads), aber jetzt werden sie erwartet. Anstrengung hört auf, in Sichtbarkeit umgewandelt zu werden. Entweder wachsen Sie (Ihre Arbeit beginnt, Entscheidungen von den Tellern anderer Menschen zu nehmen) oder Sie stagnieren (Sie werden zur schnelleren Version des Helpdesks).

Die Weggabelung geschieht still. Die meisten Menschen bemerken nicht, dass sie den falschen Weg eingeschlagen haben, bis zum Review-Gespräch, wenn ihr Manager irgendeine Version von "Sie leisten gute Arbeit, aber ich muss mehr strategische Wirkung sehen" sagt. Das ist der Manager, der Ihnen in der höflichstmöglichen Sprache mitteilt, dass er nicht sagen kann, was Ihre Arbeit verändert hat.

Hier sind die sieben Fallen, die Sie auf den Plateau-Pfad setzen. Jede hat ein Symptom, das Sie in Ihrer eigenen Woche erkennen können, eine Zahl, die Sie messen können, und einen Fix, den Sie am Montag anwenden können.

Falle 1: Der Helpdesk werden

Symptom. Ihre DMs sehen aus wie eine Warteschlange. "Kurze Frage, können Sie X ziehen?" "Entschuldigung, aber enthält Y auch Z?" Sie antworten, weil Antworten schnell geht und Nein sagen sich unhöflich anfühlt. Dann wundern Sie sich, warum Sie nicht zum strategischen Projekt kommen.

Die Zahl. Nach meiner Erfahrung verbringt ein BA, der zum Helpdesk wird, 12-18 Stunden pro Woche mit Ad-hoc-Anfragen. Das ist ein Viertel bis ein Drittel Ihrer Woche, jede Woche, verdampft in Fragen, die meist dieselben fünf Antworten haben.

Der Fix. Hören Sie auf, einzelne Pings zu beantworten. Starten Sie einen #analytics-help-Kanal und leiten Sie jede DM dorthin mit einer Zeile um: "Ich poste in #analytics-help, damit andere die Antwort sehen können." Innerhalb von zwei Wochen werden Sie dieselben fünf Fragen wiederholen sehen. Erstellen Sie ein Self-Service-Dokument oder ein Looker-Board, das sie beantwortet, verlinken Sie es und beobachten Sie, wie Ihre Warteschlange schrumpft.

Das Schwierige ist nicht der Kanal. Es geht darum, einem VP zu sagen "das sollte Self-Service sein", ohne zu klingen, als würden Sie Arbeit ablehnen. Die Formulierung, die funktioniert: "Ich ziehe das gerne einmal. Um Ihre nächsten zehn Anfragen nicht zu blockieren, füge ich es bis Freitag dem [Team-Dashboard] hinzu, damit Sie es selbst abrufen können." Sie haben die Anfrage beantwortet. Sie haben die Arbeit auch von "Ihrer ewigen Warteschlange" zu "Ihrer einmaligen Warteschlange" verschoben.

Falle 2: Anforderungsfreigabe überspringen

Symptom. Ein Stakeholder beschreibt in einem 20-minütigen Gespräch, was er möchte. Sie nicken, machen Notizen, gehen bauen. Zwei Wochen später schaut er es an und sagt "oh, aber ich brauche es auch nach Region aufgeschlüsselt" oder "warte, das ist monatlich. Ich brauchte wöchentlich." Sie bauen neu. Er ist "fast da." Sie bauen wieder.

Die Zahl. Jeder Neuaufbau kostet 4-12 Stunden. Drei Neuaufbauzyklen an einem einzigen Dashboard entsprechen einer vollen Arbeitswoche, und der Stakeholder ist noch immer nicht sicher, ob er den Zahlen vertraut.

Der Fix. Bevor Sie eine einzige Abfrage schreiben, senden Sie ein einseitiges Anforderungsdokument mit drei Abschnitten: Entscheidung (welche Maßnahme wird diese Arbeit ermöglichen und wer trifft sie), Definition (was zählt als "Lead", "aktiver Nutzer", "Abwanderung", schriftlich vereinbart), und Fertig (wie sieht das aus, wenn es ausgeliefert wird, mit einer Skizze). Holen Sie ein schriftliches Okay für alle drei ein. Wenn der Stakeholder eine einseitige Zusammenfassung nicht liest, ist das Ihr Signal, dass die Anfrage nicht ernst genug ist, um sie zu bauen.

Das Freigabedokument ist keine Bürokratie. Es ist ein Zwangsmittel, das "Ich möchte ein Dashboard" in "Ich möchte jeden Montag X entscheiden und brauche Y dafür" verwandelt. Neunzig Prozent des Scope Creep stirbt in dieser Übersetzung.

Falle 3: Dashboards bauen, bevor die Entscheidung definiert ist

Symptom. Sie liefern ein Dashboard. Es hat 14 Diagramme, 6 Filter, alles farbkodiert. Der Stakeholder sagt "das ist großartig, danke." Drei Wochen später, als Sie nachsehen, wurde es zweimal geöffnet. Beide Male von Ihnen.

Die Zahl. In den meisten BI-Tools wird das mittlere Dashboard nach dem ersten Monat weniger als 5 Mal pro Monat aufgerufen. Wenn "der Kunde liebte es" nicht mit "der Kunde nutzt es" übereinstimmt, hatte das Dashboard keine echte Entscheidung angehängt.

Der Fix. Bevor Sie Tableau oder Looker öffnen, schreiben Sie einen Satz oben in Ihrem Notizblock: "Dieses Dashboard existiert, damit [Rolle] [Maßnahme] jeden [Rhythmus] entscheiden kann." Wenn Sie nicht alle drei Lücken füllen können, haben Sie kein Dashboard. Sie haben eine vage Anfrage, etwas zu machen.

Beispiele, die den Test bestehen:

  • "Dieses Dashboard existiert, damit der Sales VP entscheiden kann, welche zwei Regionen dieses Quartal Headcount erhalten, jeden Montagmorgen."
  • "Dieses Dashboard existiert, damit der CS Lead entscheiden kann, welche 5 Konten diese Woche anzurufen sind, jeden Dienstag um 9 Uhr."

Beispiele, die scheitern:

  • "Dieses Dashboard existiert, damit die Führung Einblick in den Funnel hat."
  • "Das ist ein Marketing-Performance-Dashboard."

Wenn die Entscheidung nicht benannt ist, wird das Dashboard zur Tapete.

Falle 4: Zu starke Abhängigkeit von Excel-Exporten

Symptom. Sie ziehen Daten in Excel, weil der Stakeholder "damit spielen" möchte. Sie erstellen eine Pivot-Tabelle. Sie fügen einen SVERWEIS ein. Sie senden die Datei per E-Mail. Zwei Wochen später teilt der Stakeholder sie in einem Meeting und die Zahlen sind falsch, aber falsch auf eine Weise, die niemand reproduzieren kann, weil sie in einer Tabelle verschachtelt sind, die im Downloads-Ordner von jemandem liegt.

Die Zahl. Excel als Wahrheitsquelle kostet Sie mehr Reputation als Stunden. Eine falsche Zahl in einem Board-Deck und Ihr Status als "Datenpartner" braucht sechs Monate, um sich zu erholen.

Der Fix. Excel ist gut für eine einmalige Erkundung. Es ist nicht gut als wiederkehrender Bericht. Die Regel, die ich verwende: Wenn Sie dieselbe Excel-Datei zweimal gesendet haben, muss die dritte Version im BI-Tool leben, mit dem SQL irgendwo commitet, wo ein Kollege es finden könnte.

Reworks Produktivitätstools und die meisten BI-Plattformen können 80 % der wiederkehrenden Excel-Exporte durch einen geplanten Bericht ersetzen. Die verbleibenden 20 % sind echte Ad-hoc-Analysen, und das ist, wo Excel seinen Wert beweist. Kämpfen Sie nicht gegen Excel. Kämpfen Sie gegen Excel-als-Pipeline.

Falle 5: Keine Versionskontrolle für SQL/dbt-Modelle

Symptom. Sie öffnen Ihren Abfrageordner und finden customer_metrics.sql, customer_metrics_v2.sql, customer_metrics_FINAL.sql, customer_metrics_FINAL_USE_THIS.sql und das gespenstische customer_metrics_old_DO_NOT_USE.sql. Keine davon produziert dieselben Zahlen. Sie erinnern sich nicht, welche Sie im Board-Deck des letzten Quartals verwendet haben.

Die Zahl. Die Zeit, die für das Abgleichen von "Warum stimmt meine Zahl nicht mit Ihrer überein" aufgewendet wird, erreicht leicht 3-5 Stunden pro Monat. Mehr, wenn Sie der Analyst sind, der die Zahl in einem Führungsmeeting verteidigen muss.

Der Fix. Legen Sie Ihr SQL in Git. Es ist mir egal, ob es ein privates Repo, ein geteiltes dbt-Projekt oder ein in einem Cloud-Laufwerk synchronisierter Ordner ist. Versionieren Sie es, committen Sie es und hören Sie auf, Dateinamen als Versionskontrolle zu verwenden. Wenn Sie bereits mit dbt arbeiten, ist das kostenlos; Sie müssen nur aufhören, es mit einmaligen Abfragen im BI-Tool zu umgehen.

Ein minimales Setup für einen Solo-BA:

ba-queries/
  models/
    revenue/
      monthly_revenue.sql
      arr_by_segment.sql
    customers/
      active_customer_definition.sql
  README.md   # Was jedes Modell bedeutet, wer jede Definition besitzt

Committen Sie jede Änderung. Verweisen Sie auf den Commit-Hash, wenn jemand fragt "Woher kam diese Zahl?" Diese Gewohnheit allein verschiebt Sie von "dem Analysten" zu "dem Analysten, der seine Zahlen in einem Board-Meeting verteidigen kann." Das sind zwei verschiedene Jobs und sie werden unterschiedlich bezahlt.

Falle 6: Außerbetriebnahme-Reviews ignorieren

Symptom. Sie öffnen Looker. Sie zählen Ihre Dashboards. Es sind 47. Sie pflegen aktiv 9. Sie können sich an 3 erinnern. Die anderen 44 sind noch "live", ziehen jeden Morgen Daten, erscheinen noch im Katalog, wenn Stakeholder suchen.

Die Zahl. Unter den Teams, mit denen ich zusammengearbeitet habe, wurden 30-50 % der Dashboards in 90 Tagen nicht geöffnet. Sie kosten noch immer Rechenleistung, verwirren noch immer neue Mitarbeiter und erzeugen noch immer "Moment, welches ist das richtige?" in Meetings.

Der Fix. Führen Sie eine vierteljährliche Außerbetriebnahme-Review durch. Es dauert einen Nachmittag. Ziehen Sie einen Nutzungsbericht aus Ihrem BI-Tool, sortieren Sie nach last_viewed_at, und tun Sie für alles, das älter als 90 Tage ist, eines von drei Dingen:

  1. Archivieren wenn niemand es besitzt.
  2. Befördern wenn es die kanonische Version einer wiederkehrenden Metrik ist (in einen "Kern"-Ordner verschieben, Definitionen sperren).
  3. Zusammenführen wenn es drei fast gleiche Versionen gibt, die eine sein sollten.

Beim ersten Mal werden Sie 20+ Dashboards archivieren und nichts Schlimmes wird passieren. Das ist der Punkt. Der Katalog wird sauberer, Ihre Abfragen laufen schneller und neue Mitarbeiter können das richtige Dashboard tatsächlich finden, ohne Sie zu fragen.

Falle 7: Nutzung ohne Entscheidungswirkung messen

Symptom. Ihr Manager fragt, wie die Analysefunktion läuft. Sie sagen "das Executive-Dashboard hatte letzten Monat 1.200 Aufrufe." Sie nickt und stellt eine andere Frage.

Die Zahl. "1.200 Aufrufe" klingt beeindruckend, bis Sie fragen: Aufrufe von wem, führend zu welcher Aktion, mit welchem Ergebnis? Wenn die Antwort "Ich weiß es nicht, aber das Diagramm zeigt nach oben rechts" lautet, haben Sie das Falsche gemessen.

Der Fix. Wechseln Sie Ihr Reporting von Nutzungsmetriken zu Entscheidungsmetriken. Benennen Sie für Ihre fünf wichtigsten Dashboards:

  • Die Entscheidung, die das Dashboard unterstützt (Falle 3, dieselbe Übung)
  • Den Rhythmus dieser Entscheidung (wöchentlich, monatlich, vierteljährlich)
  • Ein Beispiel aus dem letzten Quartal, in dem das Dashboard den Ausschlag gegeben hat

Das letzte ist der Schlüssel. Wenn Sie kein einziges Beispiel nennen können, bei dem das Dashboard eine Entscheidung verändert hat, ist das Dashboard Dekoration. Wenn Sie drei oder vier für Ihre fünf wichtigsten nennen können, sind Sie kein Report-Jockey mehr. Sie sind ein Analyst, dessen Arbeit Geld verändert hat.

Wenn die Review-Saison kommt, ist "Das Marketing-Führungsteam hat im März $400.000 von bezahlten Social-Anzeigen auf organisch umgeleitet, basierend auf dem Channel-Attribution-Dashboard, das ich gebaut habe" ein Satz, der Sie befördert. "1.200 Aufrufe" ist ein Satz, der Ihnen ein Dankeschön und denselben Titel einbringt.

Das zugrundeliegende Muster

Wenn Sie die sieben Fallen noch einmal lesen, teilen sie alle eine Wurzel: Ergebnisse statt Entscheidungen optimieren.

  • Helpdesk = Ergebnis (Tickets geschlossen)
  • Keine Freigabe = Ergebnis (schnell bauen, falsch bauen)
  • Dashboards vor Entscheidungen = Ergebnis (Diagramme ausgeliefert)
  • Excel-Exporte = Ergebnis (Dateien per E-Mail gesendet)
  • Keine Versionskontrolle = Ergebnis (Abfragen geschrieben, nicht verstanden)
  • Keine Außerbetriebnahme = Ergebnis (Katalog wächst, schrumpft nie)
  • Nutzung ohne Wirkung = Ergebnis (Aufrufe gemessen, kein Wert)

Rahmen Sie den Job neu. Sie werden nicht bezahlt, um Abfragen zu schreiben, Dashboards zu liefern oder Tickets zu schließen. Sie werden bezahlt, um Entscheidungslatenz für das Unternehmen zu reduzieren. Entscheidungen, die früher ein Meeting erforderten, aus einem Diagramm heraus treffbar machen. Entscheidungen, die früher eine Woche dauerten, an einem Tag treffbar machen.

Jede Stunde Ihrer Woche sollte dazu passen. Wenn nicht, ist es Overhead, und Overhead summiert sich nicht.

Ein 30-Tage-Plan zum Herauskommen

Sie können nicht alle sieben auf einmal beheben. Versuchen Sie stattdessen folgendes:

Woche 1: Die Blutung stoppen. Richten Sie Ihren #analytics-help-Kanal ein. Leiten Sie jede DM dorthin um. Schreiben Sie eine einseitige Vorlage für die Anforderungsfreigabe. Verpflichten Sie sich, sie bei den nächsten zwei Anfragen ohne Ausnahme zu verwenden.

Woche 2: Vertrauen zurückgewinnen. Wählen Sie Ihre drei meistgenutzten Dashboards aus. Schreiben Sie für jedes den Satz "Dieses existiert, damit [Rolle] [Maßnahme] jeden [Rhythmus] entscheidet." Wenn Sie ihn nicht ausfüllen können, planen Sie ein 20-minütiges Gespräch mit dem Besitzer. Aktualisieren Sie die Dashboard-Beschreibung mit dem Satz.

Woche 3: Aufräumen. Legen Sie Ihr SQL in ein Git-Repo, auch ein privates. Verschieben Sie zumindest die Abfragen, die Ihre drei wichtigsten Dashboards antreiben. Führen Sie eine Außerbetriebnahme-Review durch. Listen Sie alle Dashboards auf, die Sie besitzen, und markieren Sie jedes als Archivieren / Befördern / Zusammenführen.

Woche 4: Die Arbeit zeigen. Nehmen Sie Ihr letztes Quartal und schreiben Sie drei "Entscheidungswirkung"-Sätze. Echte. ("Team X hat Y basierend auf der Analyse Z, die ich geliefert habe, umgeleitet.") Wenn Sie keine drei schreiben können, ist das diagnostisch. Ihr Plan für das nächste Quartal ist, drei echte entstehen zu lassen.

Das Freitags-Selbst-Audit. Stellen Sie sich jeden Freitag, bevor Sie den Laptop schließen, drei Fragen:

  1. Welche Entscheidung hat meine Arbeit diese Woche verändert?
  2. Welche Anfrage habe ich angenommen, die Self-Service hätte sein sollen?
  3. Welches Dashboard sollte ich nächste Woche archivieren?

Drei Minuten, drei Fragen. Die Fragen ändern sich nicht. Ihre Antworten werden es in sechs Monaten tun.

Abschluss

Der BA zu Beginn dieses Artikels, die keine Entscheidung nennen konnte, die ihre Arbeit verändert hatte, war nicht schlecht in ihrem Job. Sie war großartig darin. Sie war außergewöhnlich beim Oberflächen-Job (Ticket schließen, Dashboard liefern, Ping beantworten) und unter Wasser beim eigentlichen Job (Entscheidungslatenz aus dem Unternehmen entfernen).

Die Fallen in diesem Artikel sind keine Intelligenzprobleme. Es sind Aufmerksamkeitsprobleme. Sie driften in sie hinein, nicht weil Sie faul sind, sondern weil der Oberflächen-Job sich im Moment produktiv anfühlt und der eigentliche Job unsichtbar ist, bis zur Review-Saison.

Wählen Sie diese Woche eine Falle. Beheben Sie sie bis Freitag. Die Beförderung wird nicht dadurch kommen, dass Sie mehr tun. Sie wird kommen, indem Sie die Dinge tun, die Entscheidungen verändern, und zu allem anderen höflich und schriftlich Nein sagen.

Mehr erfahren