Sehari dalam Kehidupan Business Analyst (B2B SaaS, Jalur IC)

Sebelum laptop saya terbuka, sudah ada 11 pesan Slack yang menanyakan mengapa MRR turun. Tidak satu pun dari mereka yang salah. Tidak satu pun yang memberikan jawaban yang sama.

Seorang PM melihat dasbor eksekutif, yang menarik dari model dbt yang berjalan pukul 5 pagi. Seorang CSM melihat laporan Salesforce yang mendefinisikan MRR sebagai nilai kontrak yang berkomitmen. VP Finance melihat tampilan pengakuan pendapatan, yang mengecualikan apa pun yang belum ditagih. Semuanya benar, dan semuanya melihat angka yang berbeda, dan pada pukul 9:30 seseorang akan bertanya kepada saya mana yang merupakan "MRR yang nyata." Jawaban itu membutuhkan 20 menit untuk diberikan dan 20 menit lagi untuk dipertahankan. Selamat datang di hari Selasa.

Apa yang dijanjikan JD versus seperti apa hari Selasa sebenarnya

Deskripsi pekerjaan mengatakan "dorong wawasan bisnis" dan "bermitra dengan kepemimpinan dalam keputusan strategis." Saya menerimanya. Kenyataannya adalah minggu saya kira-kira 60% SQL dan pipa data, 30% menerjemahkan antara Engineering dan Product (dan Sales, dan Finance, dan direktur CS itu yang hanya berkomunikasi melalui pesan suara), dan 10% analisis sesungguhnya. Wawasan hanya terjadi ketika pipa berjalan bersih. Seorang BA yang tidak bisa menjaga dasbor tetap hijau tidak pernah diundang ke meja strategi. Mereka terlalu sibuk di basement memperbaiki pipa.

Inilah jam demi jam untuk hari yang normal. Stack: Snowflake untuk gudang data, dbt untuk transformasi, Looker untuk BI (dengan beberapa notebook Hex untuk ad hoc), Notion untuk spesifikasi, Jira untuk tiket.

8:00 Pagi: Pemeriksaan kesehatan dasbor

Sebelum saya merespons satu pesan Slack pun, saya melakukan pemindaian lima menit yang sama setiap pagi:

Apakah jalannya dbt selesai? Periksa gambaran umum pekerjaan dbt Cloud. Hijau semua, atau apakah fct_revenue gagal pukul 4:47 pagi karena seseorang mengirimkan perubahan skema?
Timestamp kesegaran di dasbor eksekutif. Buka dasbor Looker eksekutif. Tile "terakhir diperbarui" harus mengatakan "hari ini, sekitar pukul 6 pagi." Jika tertulis "kemarin," sesuatu di upstream sudah basi.
Jumlah baris dibandingkan kemarin. Tiga kueri terhadap gudang data (pesanan, peluang, akun aktif). Jika jumlah baris turun lebih dari 5%, sinkronisasi Fivetran upstream rusak.
Tiga KPI utama. Jumlah logo baru, MRR, dan gross retention. Apakah mereka dalam kisaran yang wajar, atau adakah yang menunjukkan perubahan mingguan 40% yang berteriak "definisi rusak"?
Pemeriksaan "apakah ada yang menyentuh lapisan semantik semalam." Lihat repositori LookML untuk penggabungan dalam 12 jam terakhir.

Inilah kueri sanity-check yang saya simpan di Snowflake. Berjalan dalam lima detik:

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;

Jika baris hari ini hilang atau GMV berubah drastis, saya tahu sebelum CEO. Itulah seluruh intinya. Menangkap join yang rusak pukul 8:05 pagi adalah perbaikan tiga menit. Menangkapnya pukul 9:35 pagi setelah all-hands sudah dimulai adalah latihan pemadaman kebakaran 90 menit ditambah email permintaan maaf.

9:00 Pagi: Triase permintaan ad hoc

Antrean ada di tiga tempat, karena tentu saja begitu. Board intake Jira untuk permintaan formal. Saluran Slack #data-help untuk "pertanyaan cepat." Halaman Notion bersama di mana salah satu direktur terus menambahkan permintaan karena ia menolak menggunakan Jira. Saya memeriksa ketiganya.

Pagi ini: lima permintaan baru. Pekerjaan saya bukan menjawabnya. Pekerjaan saya adalah melakukan triase.

"Bisakah kamu tarik churn berdasarkan tier paket untuk kuartal lalu?" Memblokir. CFO menginginkannya untuk deck board pada hari Kamis. Jika lapisan semantik bersih, ini adalah kueri 15 menit. Jika fct_subscription_events masih memiliki masalah join plan_id lama, itu dua jam. Perkiraan: 30 menit. Ambil.
"Penasaran, berapa banyak pengguna trial kami yang berasal dari LinkedIn?" Penasaran, tidak terblokir. Dasbor marketing sudah memiliki pemisahan sumber akuisisi. Balas dengan tangkapan layar dan tautan. Dua menit.
"Perlu tahu win rate Q1 kami berdasarkan industri." Sudah ada di dasbor kinerja penjualan Looker. Kirimkan tautannya dan satu kalimat tentang filter mana yang harus diterapkan. Tiga menit.
"Bisakah kamu membangun dasbor untuk eksperimen harga baru kami?" Pekerjaan nyata. Perlu percakapan penilaian 30 menit, bukan kueri SQL. Balas: "Siap, mari kita habiskan 20 menit pada hari Kamis untuk menilai keputusan yang perlu didukung dasbor ini."
"Angka ini di dasbor CS terlihat aneh, bisakah kamu periksa?" Mungkin tidak ada apa-apa, mungkin segalanya. Buka. Angkanya baik-baik saja. Legenda salah karena seseorang mengganti nama ukuran. Perbaikan 10 menit di LookML.

Aturan triase yang menyelamatkan kewarasan saya: pisahkan "terblokir" dari "penasaran." Terblokir berarti keputusan tidak bisa bergerak maju tanpa jawaban. Penasaran berarti seseorang sedang berada di explore Looker dan terpancing secara intelektual. Penasaran diarahkan ke layanan mandiri. Terblokir naik ke atas antrean. Jika semuanya "terblokir," tidak ada yang terblokir.

Tim data tempat saya berada terdiri dari tiga orang. Di antara kami, kami mendapatkan 8 hingga 12 permintaan ad hoc baru per minggu. Tanpa triase, antrean memakan seluruh pekerjaan.

11:00 Pagi: Wawancara kebutuhan di tengah hari

Seorang PM memesan 45 menit di kalender saya. Agendanya berbunyi: "Penilaian dasbor keterlibatan." Saya sudah pernah di sini. PM menginginkan "dasbor untuk keterlibatan." Itu bukan permintaan. Itu adalah perasaan.

Pekerjaan saya dalam rapat ini adalah mencapai keputusan sebenarnya yang akan didukung dasbor, kemudian bekerja mundur ke dua atau tiga metrik yang bukan metrik semu. Inilah skrip pertanyaan yang saya gunakan, dan saya benar-benar membukanya di dokumen Notion ketika rapat dimulai:

Keputusan apa yang akan Anda buat secara berbeda setelah melihat dasbor ini? (Jika mereka tidak bisa menjawab, dasbor adalah permintaan metrik semu. Hentikan di sini.)
Siapa lagi yang perlu melihatnya, dan keputusan apa yang mereka buat?
Seberapa sering Anda akan melihatnya (harian, mingguan, bulanan)? (Harian berarti Anda membutuhkan peringatan Slack, bukan dasbor.)
Angka apa, jika berubah, yang akan membuat Anda melakukan sesuatu minggu ini?
Apa ambang batasnya? Apa yang dianggap 'baik' versus 'buruk'?
Apa yang sudah ada yang hampir seperti ini, tapi tidak persis? (Sering ada explore Looker yang sudah ada yang melakukan 80%-nya.)
Jika kami hanya bisa mengirimkan dua grafik, dua mana yang paling penting?

PM hari ini mengatakan "dasbor keterlibatan." Setelah 30 menit pertanyaan itu, apa yang sebenarnya mereka butuhkan adalah satu grafik (pengguna aktif mingguan berdasarkan kohort fitur) ditambah peringatan Slack ketika WAU turun lebih dari 10% minggu ke minggu. Upaya pembangunan: setengah hari. Permintaan asli, dipahami secara harafiah: mungkin dua minggu untuk sesuatu yang tidak akan dibuka siapa pun setelah sprint pertama.

PM yang meminta "dasbor" biasanya butuh satu grafik dan peringatan Slack. Kira-kira 70% waktu, dari pengalaman saya.

1:30 Siang: Async dengan eng dan product

Makan siang adalah sandwich di meja saya sambil meninjau PR dbt. Ini adalah bagian terjemahan dari pekerjaan, dan bagian yang tidak diceritakan siapa pun kepada Anda dalam wawancara.

Komentar pada PR dbt. Seorang analytics engineer sedang merefaktor dim_accounts dan mengganti nama kolom dari account_owner_id menjadi owner_user_id. Deskripsi PR tidak menyebutkan empat explore Looker hilir yang mereferensikan nama lama. Saya meninggalkan komentar dengan tautan ke setiap explore yang terpengaruh dan catatan bahwa kami memerlukan (a) alias kolom untuk kompatibilitas mundur atau (b) PR LookML yang dikoordinasikan dikirimkan pada saat yang sama. Komentar 10 menit ini mencegah tiga DM Slack pada pukul 9 pagi besok yang menanyakan mengapa dasbor penjualan rusak.

Merespons spesifikasi produk. Seorang PM menulis spesifikasi untuk alur onboarding baru dalam aplikasi dan menandai saya dengan pertanyaan apakah saya bisa "melacak keterlibatan dengan setiap langkah." Melihat pelacakan event, event yang mereka inginkan tidak ada. Instrumentasi produk saat ini memicu onboarding_started dan onboarding_completed, hanya itu. Untuk menjawab pertanyaan yang sebenarnya mereka pedulikan (di mana pengguna drop off dalam alurnya), kami membutuhkan event tingkat langkah: onboarding_step_viewed dengan properti step_name. Saya menulisnya dalam dokumen spesifikasi dengan skema event yang tepat, mengarahkan mereka ke rencana pelacakan yang ada di Notion, dan menambahkan tiket Jira di backlog Engineering untuk menambahkan event tersebut.

Inilah pekerjaan yang tidak muncul di dasbor mana pun tapi memisahkan BA yang dipekerjakan kembali dari yang tidak. Engineering berbicara tentang tabel dan skema. Product berbicara tentang fitur dan hasil. Pemangku kepentingan berbicara dalam perasaan dan pesan Slack. BA menjembatani ketiganya. PR dbt yang ditinjau sebelum makan siang mencegah pemadaman Looker setelah makan siang. Itulah pekerjaannya.

3:00 Sore: Penarikan data eksekutif akhir hari

VP Sales ping saya pukul 2:55 sore. Panggilan persiapan board pukul 4. Ia membutuhkan pipeline quarter-to-date berdasarkan segmen, dipecah berdasarkan tahap dan ditimbang berdasarkan probabilitas tahap. Slide sedang dibangun sekarang.

SQL-nya baik-baik saja. Saya memiliki kueri tersimpan untuk pemotongan yang persis ini. Tampilannya kira-kira seperti:

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;

Bagian yang sulit bukan kuerinya. Melainkan peringatan tambahannya. VP menginginkan satu angka di slide. Saya harus memutuskan yang mana dan memberi tahu dia alasannya. Tiga opsi, semuanya bisa dipertahankan:

Jumlah pipeline (jumlah mentah): angka terbesar, terlihat bagus, mencakup transaksi yang memiliki peluang 10% untuk ditutup.
Pipeline tertimbang (jumlah kali probabilitas tahap): lebih jujur, lebih kecil, yang disukai sebagian besar CFO.
Pipeline yang berkomitmen (hanya tahap 4 dan ke atas): paling konservatif, yang kami laporkan dalam QBR.

Saya mengirimkan data dengan catatan satu paragraf: "Slide harus menggunakan pipeline tertimbang. Itulah yang dipresentasikan CFO kuartal lalu, dan menggunakan definisi yang berbeda kuartal ini akan memicu pertanyaan 'mengapa metodologinya berubah.' Jika VP menginginkan angka mentah untuk narasi, cantumkan sebagai catatan kaki."

Datanya butuh empat menit. Rekomendasinya butuh 12. Rekomendasinya itulah yang membuat saya diundang kembali kuartal depan.

4:30 Sore: Kepanikan "laporan ini salah"

Tepat waktu. Seorang Direktur Customer Success mengirimi saya pesan Slack: "Hei, angka logo baru di dasbor CS menunjukkan 47 untuk April, tapi Salesforce menunjukkan 52. Bisakah kamu periksa?"

Ini adalah keadaan darurat yang paling umum dalam pekerjaan, dan hampir selalu memiliki akar penyebab yang sama. Inilah debug 20 menit yang saya jalankan, berurutan:

Pemeriksaan definisi. Apa yang dasbor sebut sebagai "logo baru"? Di Looker, itu difilter ke is_first_paid_invoice = true. Di Salesforce, laporan difilter ke opportunity_stage = 'Closed Won' DAN account_type = 'New Logo'. Itulah definisi yang berbeda. Suatu peluang bisa Closed Won tapi belum memiliki faktur berbayar (jeda penagihan 5 hari). Itu saja biasanya menjelaskan kesenjangan 5 transaksi.
Pemeriksaan zona waktu. Salesforce melaporkan dalam waktu lokal pengguna. Dasbor Looker menggunakan UTC. 30 April dalam waktu Pacific adalah 1 Mei dalam UTC. Satu atau dua transaksi selalu tertangkap di ini.
Pemeriksaan filter. Apakah laporan Salesforce mencakup pembaruan atau upgrade? Kadang-kadang filter "logo baru" dikonfigurasi dengan salah.
Pemeriksaan kesegaran data. Kapan sinkronisasi Salesforce-ke-Snowflake terakhir berjalan? Jika berjalan 10 menit yang lalu, baik. Jika berjalan enam jam yang lalu, dua transaksi lagi mungkin sudah ditutup sejak itu.
Bug data yang sebenarnya. Hanya setelah mengesampingkan empat yang pertama baru saya memeriksa apakah ada masalah upstream.

Jawaban hari ini: ketidaksesuaian definisi. Looker menggunakan faktur berbayar; Salesforce menggunakan closed-won. Keduanya "benar," mereka hanya menjawab pertanyaan yang berbeda. Angka Looker adalah yang tepat untuk tujuan tim CS (kita harus merayakan pelanggan yang membayar, bukan penutupan di atas kertas), tapi saya mendokumentasikan perbedaannya dalam deskripsi dasbor agar ini tidak terjadi lagi bulan depan.

Komunikasinya sepenting diagnosisnya. Saya tidak pernah membalas dengan "laporan Salesforce salah." Saya membalas dengan: "Keduanya benar, tapi mereka mengukur hal yang berbeda. Inilah arti masing-masing, inilah mengapa mereka berbeda bulan ini, dan inilah mana yang harus digunakan untuk QBR CS." Tidak ada yang defensif. Tidak ada yang eskalasi. Direktur berterima kasih kepada saya dan melanjutkan.

"Laporan ini salah" hampir selalu merupakan ketidaksepakatan definisi, bukan bug data. Mungkin 80% waktu. 20% sisanya adalah bug nyata, dan itu mendapatkan tiket Jira dan post-mortem.

5:30 Sore: Selesai

Lima permintaan ad hoc masuk pagi ini. Saya menutup tiga. Dua didorong ke besok dengan balasan Slack yang menjelaskan mengapa, agar tidak ada yang bertanya-tanya. Satu saya tambahkan ke backlog analytics engineering sebagai permintaan berulang. Penarikan "churn berdasarkan tier paket" masuk kira-kira dua kali per kuartal, dan sudah saatnya menjadikannya dasbor layanan mandiri agar tidak lagi mendarat di antrean saya. Itulah langkah dengan leverage tertinggi yang akan saya lakukan sepanjang hari, dan butuh dua menit.

Hal terakhir yang saya lakukan sebelum menutup laptop: catatan satu baris di log harian Notion saya. Apa yang saya kirimkan, apa yang saya pelajari, apa yang didorong. Besok pagi, ketika 11 pesan Slack mulai lagi, log itu adalah cara saya mengingat kebakaran mana yang sudah menyala.

Scorecard yang jujur

Di akhir hari yang baik, BA mengirimkan satu analisis nyata (penilaian dasbor keterlibatan yang mengubah pembangunan dua minggu menjadi grafik-plus-peringatan setengah hari), membuka blokir tiga pemangku kepentingan (penarikan churn CFO, pemotongan pipeline VP Sales, pertanyaan logo baru direktur CS), dan mencegah satu insiden angka yang salah (komentar PR dbt yang mencegah pemadaman Looker besok).

Itulah pekerjaannya. Bukan "dorong wawasan." Bukan "jadilah mitra strategis." Datang, jaga dasbor tetap hijau, terjemahkan antara orang-orang yang tidak bisa saling berbicara, dan jawab pertanyaan di balik pertanyaan.

10% yang merupakan analisis strategis sesungguhnya hanya terjadi ketika 90% berjalan bersih. BA yang mendapatkan promosi adalah mereka yang mengetahui hal ini pada bulan ketiga.

Playbook Business Analyst