30/60/90 Hari Pertama sebagai Analis Bisnis Baru

Hari ke-3. Kamu masih mencari tahu channel Slack mana yang penting ketika DM ke-14 masuk: "tarik cepat, bisa ambilkan MRR per segmen sebelum EOD?" Akses Looker pun belum kamu dapat. Laptop baru menyala 19 jam.

Kamu membuka wiki. BA sebelumnya meninggalkan 47 dasbor. Dua belas di antaranya rusak. Sisanya 35 punya nama seperti revenue_FINAL_v3_use_this_one. Tiga tim (Finance, RevOps, chief of staff CEO) masing-masing memberitahumu, secara rahasia, bahwa angka revenue mereka adalah yang benar. Dua dari tiga angka itu bahkan tidak cocok sampai selisih 8%.

Inilah pekerjaannya. Bukan deskripsi jabatan, melainkan pekerjaan yang sesungguhnya. Kalau tidak hati-hati, 90 hari ke depan akan berjalan persis seperti yang dialami BA sebelumnya: tenggelam dalam permintaan ad hoc, tidak menghasilkan apapun yang benar-benar milik sendiri, dan perlahan-lahan kehabisan energi sekitar bulan keempat.

Kebanyakan BA kehilangan kuartal pertama mereka hanya karena antrean Slack. Begini cara menghindarinya.

Mengapa 30/60/90 Sangat Penting bagi BA

Engineer mendapat 30/60/90 karena pekerjaan mereka memiliki batas yang jelas: tiket, PR, rotasi on-call. PM mendapatnya karena para pemangku kepentingan mereka punya stand-up. BA sering melewatkannya, karena pekerjaan terasa tidak memiliki tepi.

Itulah masalahnya.

Tanpa rencana tertulis, kamu menjadi mesin pencetak SQL. Seseorang mengirim pertanyaan lewat DM, kamu menulis query, menempelkan jawaban, lalu lanjut. Diulang 80 kali seminggu. Pada hari ke-90, manajer bertanya apa yang sudah kamu hasilkan dan kamu menjawab, "Saya menutup 312 permintaan ad hoc." Itu bukan hasil karyamu. Itu antrean Jira dengan detak jantung.

Pekerjaan ini adalah soal wawasan, bukan penarikan data. Rencana 30/60/90 adalah cara untuk membeli kembali waktu agar bisa mengerjakan pekerjaan yang sebenarnya. Ini adalah kontrak yang kamu tulis dengan dirimu sendiri (dan secara diam-diam dengan manajermu), yang berbunyi: di bulan pertama saya tidak menjanjikan deliverable. Di bulan kedua saya akan menghasilkan satu hal yang berdampak berkelanjutan. Di bulan ketiga saya akan memiliki sebuah metrik.

Kalau manajermu tidak menyetujui kerangka ini, itu pun merupakan informasi. Itu menandakan bahwa peran ini adalah "penutup tiket," bukan "analis," dan kamu perlu merundingkannya ulang atau memperbarui CV sebelum bulan kedua.

Hari 1-30: Audit dan Belajar (Jangan Hasilkan Apapun, Jangan Berjanji)

Bulan pertama punya satu aturan: tidak ada dasbor baru, tidak ada laporan baru, tidak ada komitmen selain "saya akan kembali kepada kamu hari Selasa." Kamu sedang dalam mode menerima.

Inventarisasi setiap dasbor, laporan, dan ekstrak berkala

Buka Looker (atau Tableau, atau Mode, atau apapun yang digunakan timmu). Ekspor daftar aset lengkap. Tandai setiap item dalam spreadsheet:

Perusahaan SaaS ukuran menengah biasanya memiliki antara 40 sampai 200 aset BI, dan 30-50% akan masuk kategori usang atau rusak. Bukan karena pendahulumu malas. Itulah yang terjadi ketika tidak ada yang dibayar untuk merawat aset BI.

Buat daftar penghapusan (jangan dikirim dulu)

Pada hari ke-21, kamu seharusnya sudah memiliki daftar tertulis 15-25 dasbor yang perlu dihapus. Jangan kirim memo pada hari ke-21. Tahan dulu. Kamu belum punya kredibilitas untuk menghapus sesuatu, dan memo penghapusan dari karyawan berumur 3 minggu akan terkesan sembrono atau naif.

Simpan draft-nya. Kamu akan mengirimkannya pada hari ke-35, setelah menghasilkan satu hal dan membangun reputasi.

Pendalaman skema data

Cari tim data engineering. Ajak mereka ngopi. Minta mereka menjelaskan:

• 5-7 tabel inti yang menjadi dasar 80% query analitik (biasanya users, accounts, subscriptions, events, opportunities, plus 1-2 tabel domain-spesifik)
• Di mana model dbt berada, siapa pemiliknya, dan mana yang masih aktif dirawat vs. yang terbengkalai
• Setiap varian definisi revenue di gudang data (kita akan kembali ke sini; kondisinya tidak menyenangkan)
• Tabel yang "jangan di-query langsung" (firehose event mentah, tabel terkunci untuk kepatuhan, atau apapun yang memicu on-call)

Catat dengan baik. Catatan sungguhan, dalam dokumen yang bisa kamu cari di masa depan. Pada hari ke-30, kamu seharusnya bisa menjawab "di mana ARR disimpan?" tanpa harus bertanya kepada siapapun.

1:1 dengan 5 peminta ad hoc teratas

Tarik data 90 hari terakhir dari antrean BA sebelumnya (riwayat Slack, Jira, atau di manapun mereka disimpan). Urutkan berdasarkan volume. Lima peminta teratas menghasilkan 60-70% dari total beban kerja. Jadwalkan 30 menit dengan masing-masing.

Pertanyaannya bukan "laporan apa yang kamu inginkan?" Itu hanya akan menghasilkan daftar keinginan berisi 14 dasbor. Pertanyaannya adalah: keputusan apa yang sebenarnya kamu buat dengan data ini?

Kamu akan menemukan bahwa 3 dari 5 peminta teratas menggunakan analitik untuk menjawab pertanyaan mendasar yang sama ("apakah kita mencapai target?") dengan framing yang berbeda. Itu adalah peluang konsolidasi. Dua lainnya mengerjakan hal yang benar-benar berbeda dan layak mendapatkan solusi tersendiri.

Buat formulir permintaan

Bahkan formulir di Notion pun lebih baik daripada DM. Formulir hanya butuh tiga kolom: keputusan apa yang sedang kamu buat, kapan kamu membutuhkannya, dan seperti apa hasilnya yang "cukup baik". Kolom ketiga itu menghapus 40% permintaan secara langsung, karena si peminta menyadari bahwa mereka sebenarnya tidak tahu.

Beritahukan formulir ini dengan lembut di minggu ke-4. Jangan diberlakukan wajib dulu. Hari ke-31 adalah saat formulir itu mulai memiliki daya paksa.

Hari 31-60: Hasilkan 1 Hal Berdampak Tinggi dan Tetapkan SLA

Bulan kedua adalah saat kamu mulai menunjukkan nilai. Kamu sudah layak untuk bergerak. Gunakan kesempatan itu.

Pilih SATU dasbor yang menggantikan 5+ penarikan ad hoc

Lihat kembali hasil riset pemintamu. Temukan "lubang berbentuk dasbor" yang jika diisi akan meredam paling banyak DM. Bagi kebanyakan BA SaaS B2B di tahun pertama, itu biasanya salah satu dari:

• Dasbor pipeline dan revenue terpadu dengan definisi yang konsisten di antara Sales, CS, dan Finance
• Tampilan churn pelanggan dan ekspansi yang disegmentasi berdasarkan ICP
• Jembatan antara penggunaan produk dan revenue untuk gerakan PLG

Pilih satu. Kirimkan. Dapatkan satu eksekutif yang menggunakannya dalam satu rapat. Itulah standarnya. Bukan "diluncurkan ke seluruh perusahaan." Digunakan, sekali saja, dalam konteks keputusan nyata. Kalau CRO membukanya dalam rapat prakiraan hari Senin, kamu sudah menang di bulan kedua.

Publikasikan SLA ad hoc

Kirim ini secara tertulis, ke channel, pada hari ke-35:

SLA analitik ad hoc

• Triase dalam 24 jam: saya akan merespons, menentukan ruang lingkup, dan memberitahu apakah ini penarikan 20 menit, proyek 2 hari, atau sesuatu yang sebaiknya dibuatkan dasbor.
• Pengiriman 72 jam untuk penarikan yang sudah ditentukan ruang lingkupnya di bawah 4 jam kerja.
• Apapun yang lebih besar masuk melalui formulir permintaan dan diprioritaskan setiap minggu.
• DM tanpa konteks akan diarahkan ke formulir.

Orang-orang akan membenci ini selama 10 hari. Kemudian mereka akan menyukainya, karena permintaan yang datang kembali memiliki keputusan nyata yang menyertainya dan jawabannya pun bertahan.

Mulai hapus item dari daftar penghapusan

Kirim memo. Berikan pemberitahuan 2 minggu ("dasbor-dasbor ini akan diarsipkan pada 14 Mei kecuali ada yang mengklaim kepemilikannya"). Dua atau tiga akan diklaim, dan itu baik-baik saja. Serahkan kepada mereka. Sisanya, arsipkan. Jangan hapus dari gudang data, cukup batalkan publikasinya dari alat BI. Kamu selalu bisa memulihkannya.

Pada hari ke-60, kamu seharusnya sudah menghapus 12-20 aset dan alat BI seharusnya terasa jauh lebih bersih.

Tentukan baseline waktu menuju wawasan

Sebelum hari ke-60 berakhir, tentukan pengukuran baseline berapa lama sebuah permintaan dari pemangku kepentingan membutuhkan waktu dari "ditanyakan" hingga "dijawab dengan keputusan yang menyertainya." Lacak median, bukan rata-rata karena satu proyek seminggu akan mendistorsi rata-rata dan tidak memberikan informasi yang berguna.

Tiga pilihan yang bisa diterapkan:

• Median waktu penyelesaian permintaan: dari pengiriman formulir hingga "keputusan dicatat" (dalam hari)
• Keputusan yang didukung data: persentase keputusan kepemimpinan dalam 30 hari terakhir yang merujuk pada output analitik (sampel 10, tanyakan)
• Rasio dasbor terhadap penarikan: berapa banyak tampilan dasbor layanan mandiri terjadi per permintaan ad hoc

Pilih satu. Ukur sekarang. Tulis angkanya. Kamu akan membutuhkannya pada hari ke-90.

Hari 61-90: Miliki Metrik, Presentasikan Laporan

Bulan ketiga adalah saat kamu berhenti menjadi "BA baru" dan menjadi "analis yang memiliki waktu menuju wawasan." Pergeseran itu, secara internal, adalah yang membuka jalan ke peran berikutnya.

Percepat waktu menuju wawasan

Kamu sudah mengukurnya pada hari ke-60. Sekarang gerakkan. Tuas yang harus digunakan memang tidak glamor:

• Buat dasbor untuk 3 pertanyaan berulang terbanyak agar tidak lagi menjadi permintaan
• Buat 2-3 template query yang bisa digunakan tim secara mandiri
• Tolak dengan sopan "penarikan cepat" yang sebenarnya adalah perluasan ruang lingkup ("ini sebuah proyek, mari kita masukkan ke formulir")
• Analisis berpasangan dengan satu pemangku kepentingan per minggu agar mereka mempelajari skemanya

Target yang masuk akal untuk bulan ketiga: turunkan median waktu penyelesaian permintaan sebesar 30-40%, atau naikkan rasio dasbor terhadap penarikan dari baseline menjadi 50% lebih tinggi. Keduanya dapat dicapai jika bulan pertama dan kedua berjalan dengan benar.

Buat deck laporan 90 hari

Hari ke-85, tulis deck 7 slide untuk manajer dan skip-level-mu. Bukan dokumen penuh teks. Sebuah deck. Slide-nya:

1. Apa yang saya warisi: 47 dasbor, 14 versi revenue, tumpukan pekerjaan ad hoc sebanyak 23, tidak ada SLA
2. Apa yang sudah saya hapus: daftar penghapusan beserta jumlah tampilan (bukti yang konkret penting di sini)
3. Apa yang sudah saya hasilkan: satu dasbor berdampak tinggi, dengan nama eksekutif yang menggunakannya
4. SLA: tanggal publikasi, tingkat adopsi, kondisi antrean permintaan saat ini
5. Waktu menuju wawasan: angka baseline pada hari ke-60, angka terkini pada hari ke-90, selisihnya
6. Pencapaian pembersihan skema: definisi revenue yang kanonik (bagian berikutnya), dan konsolidasi lainnya
7. 90 hari ke depan: 1-2 OKR kuartalan yang kamu usulkan untuk dimiliki

Deck ini seharusnya membutuhkan 15 menit untuk dipaparkan. Kalau 30 menit, potong.

Tetapkan 1-2 OKR kuartalan yang benar-benar kamu miliki

Pada akhir pertemuan, manajermu seharusnya menyetujui satu atau dua hasil yang menjadi tanggung jawabmu di kuartal berikutnya. Contoh yang berhasil:

• "Kurangi median waktu menuju wawasan dari 6 hari menjadi 2 hari pada akhir Q3"
• "Migrasikan 3 laporan ad hoc dengan lalu lintas tertinggi ke dasbor layanan mandiri"
• "Tetapkan definisi metrik kanonik untuk revenue, ARR, dan net retention; hapus semua variannya"

Yang ingin kamu hindari: "dukung tim dengan analitik." Itu bukan OKR, itu deskripsi jabatan, dan saat review tidak memberikan manajermu apapun yang konkret untuk dipertahankan.

Kenyataan "Looker Punya 14 Versi Revenue"

Di suatu titik di bulan pertama, kamu menemukan gudang data memiliki 14 definisi revenue yang berbeda. Booked, billed, collected, recognized (GAAP), recognized (internal), MRR-converted, ARR-converted, ARR-net-churn, gross retention, net retention, ARR-with-rampdeals, expansion-only, new-logo-only, dan satu kolom yang secara harfiah bernama revenue_FINAL.

Kamu tidak bisa memperbaiki ini di minggu pertama. Kemungkinan besar kamu juga tidak bisa memperbaikinya di kuartal pertama. Tapi kamu bisa memulai, dan memulai adalah perbedaan antara BA dan Senior BA.

Playbook yang tidak bersifat politis:

1. Pilih seorang penjaga, bukan pemenang. Jangan memihak Finance atau RevOps. Dapatkan satu orang dari masing-masing (ditambah kamu) untuk menyetujui menjadi komite standar. Tiga orang. Bertemu selama 45 menit.
2. Usulkan SATU definisi kanonik untuk metrik yang paling diperdebatkan (biasanya ARR atau net retention). Tulis SQL-nya. Tunjukkan angka yang dihasilkan untuk kuartal lalu. Bandingkan dengan angka masing-masing tim saat ini.
3. Dapatkan persetujuan secara tertulis. Thread Slack sudah cukup. Intinya adalah nanti, ketika seseorang mempertanyakan angkanya, kamu bisa menautkannya.
4. Hapus sisanya di dbt. Tandai model lama sebagai deprecated, berikan jangka waktu 30 hari, kemudian hapus. Dasbor tim lain akan rusak. Kirim peringatan, pegang keputusan.
5. Ulangi untuk metrik berikutnya di kuartal berikutnya. Ini adalah pembersihan 12 bulan, bukan sprint.

Jebakannya adalah mencoba mengkanonisasi 14 metrik di bulan kedua. Kamu akan memulai perang wilayah, kalah, dan menghabiskan modal politik yang kamu butuhkan untuk hal-hal lain. Satu metrik per kuartal. Lambat dan disetujui lebih baik daripada cepat dan dikembalikan.

Jebakan Umum yang Harus Dihindari

Beberapa pola yang menjatuhkan BA baru di 90 hari pertama:

• Berkata ya untuk setiap penarikan. Kamu merasa membantu. Tapi kamu tidak. Kamu melatih organisasi untuk melewati formulir permintaan. Pada bulan ketiga SLA sudah membusuk dan kamu kembali ke status mesin pencetak.
• Membangun ulang sebelum memahami. Godaan untuk menghancurkan pekerjaan BA sebelumnya dan memulai dari awal memang besar. Jangan lakukan. Setengahnya bersifat load-bearing dengan cara yang tidak jelas. Audit dulu, hapus kedua, bangun ketiga.
• Mengabaikan tim data engineering. Mereka memiliki data inputmu. Kalau kamu membangun dasbor di atas tabel yang akan segera mereka hapus, kamu akan mengetahuinya di saat yang paling buruk. Ajak mereka ngopi.
• Tidak ada SLA tertulis. SLA lisan bukan SLA. Itu hanyalah perasaan. Perasaan tidak bertahan saat push Q3.
• Memihak dalam perang metrik. Kalau RevOps dan Finance tidak sepakat soal revenue, tugasmu adalah memfasilitasi percakapan standar, bukan menyatakan pemenang. Memihak satu kubu menghasilkan satu sekutu dan satu musuh. Memfasilitasi menghasilkan dua sekutu.

Pada Hari ke-90, Kamu Seharusnya Diukur Berdasarkan Keputusan yang Dimungkinkan

Kalau manajermu membuka review hari ke-90 dan bertanya "berapa banyak query yang kamu jalankan," kamu punya manajer yang kurang tepat (atau framing peran yang kurang tepat) dan kamu perlu memperbaiki salah satunya.

Framing yang benar: berapa banyak keputusan yang dimungkinkan oleh pekerjaanmu, seberapa lebih cepat organisasi sampai pada keputusan tersebut, dan aset apa yang berkelanjutan (dasbor, SLA, metrik kanonik) yang kamu tinggalkan sehingga kuartal berikutnya mendapat manfaatnya?

Itulah perbedaan antara BA dan mesin pencetak. Mesin pencetak menutup tiket. BA mengubah cara perusahaan melihat dirinya sendiri. Hari ke-90 adalah saat perbedaan itu mulai terlihat di kalendermu: lebih sedikit DM ad hoc, lebih banyak "bisakah kamu ikut rapat perencanaan, kami ingin pendapatmu."

Ketika undangan itu tiba, kamu sudah melewati masa onboarding dan masuk ke pekerjaan yang sesungguhnya. Sekarang bangun 90 hari berikutnya.

Pelajari Lebih Lanjut

• Business Analyst Job Description Template
• Cara Mengelola Formulir Permintaan Ad Hoc Tanpa Tenggelam
• Mengkanonisasi Definisi Metrik Lintas Tim
• Waktu Menuju Wawasan: Metrik BA yang Benar-Benar Penting