AI dalam Alur Kerja Business Analyst: Di Mana Membantu, Di Mana Bermasalah

Pukul 9:14 pada hari Senin. Seorang VP meneruskan tangkapan layar Slack. Asisten AI baru di alat CSM mereka menyebutkan bahwa pelanggan aktif tumbuh 38% pada kuartal lalu. Eksekutif tersebut ingin memasukkan angka itu ke dalam deck board sebelum makan siang.

Anda membuka gudang data. Angka sebenarnya lebih mendekati 12%. Chatbot itu menghitung setiap baris di tabel customers tanpa memperhatikan kolom status, mengabaikan flag is_test yang ditambahkan data engineer pada bulan Februari, dan secara diam-diam menjumlahkan metrik yang direset setiap bulan seolah-olah itu bersifat kumulatif. Kini Anda punya empat puluh menit untuk menjelaskan apa yang salah tanpa terkesan seperti orang yang takut digantikan oleh otomasi.

Inilah kehidupan BA saat ini. Setiap alat BI dilengkapi fitur "tanya dalam bahasa biasa." Setiap IDE memiliki pelengkap otomatis yang menulis join. Sebagian besar hasilnya adalah SQL yang salah tapi percaya diri: kueri yang berjalan, menghasilkan angka, dan salah hitung dengan cara yang tidak memicu peringatan apa pun. Seseorang harus menjadi benteng terakhir. Orang itu masih Anda, dan alat-alat ini tidak membuat pekerjaan lebih mudah, melainkan menggeser di mana bagian yang sulitnya berada.

Berikut adalah pandangan BA yang aktif bekerja, ditulis untuk mereka yang telah merilis dasbor nyata dan pernah melakukan kesalahan nyata.

Di Mana AI Benar-Benar Membantu BA

Ada leverage yang nyata di sini. Menolaknya atas dasar prinsip sama energinya dengan para analis yang bersikeras menulis setiap join secara manual pada tahun 2014 karena IDE "hanya untuk junior." Pekerjaan telah berubah. Lima tempat di mana AI terbukti berguna:

Draf SQL untuk direfaktor. Kerangka join, sintaks window function, regex untuk field log yang tidak pernah didokumentasikan siapa pun. Anda memberi Claude nama kolom dan deskripsi satu baris tentang apa yang Anda inginkan, dan ia menghasilkan kueri yang 70% benar dan 100% lebih baik dari file kosong. Anda kemudian merefaktornya. Model lebih cepat dari jari Anda, dan jari Anda memang bukan hambatannya.

Dokumentasi skema dasbor. Empat puluh tiga kolom di fact_orders, tiga di antaranya bernama seperti flag_2 dan legacy_amt_v3. Tempel skema dan riwayat commit terbaru ke dalam model dan minta draf deskripsi kolom. Anda akan memperbaiki setengahnya. Anda juga akan memiliki dokumentasi yang sebelumnya tidak ada, yang jauh lebih baik dari versi di mana dokumentasi itu tidak pernah ditulis sama sekali.

Persiapan wawancara kebutuhan. Sebelum kickoff dengan pemangku kepentingan, minta model untuk menghasilkan pertanyaan-pertanyaan canggung yang cenderung Anda lupakan, seperti "apa artinya 'churn' di sini, bulan kalender atau 30 hari bergulir?" atau "bagaimana kita menangani akun yang turun tier lalu naik lagi dalam periode yang sama?" Model tidak mengenal bisnis Anda. Ia pandai mengingatkan Anda tentang kategori pertanyaan yang harus Anda ajukan.

Deteksi anomali pada dataset yang dikenal. Arahkan model ke deret waktu dan tanyakan "di mana orang yang teliti akan melihat pertama?" Model akan menandai hal yang tepat: lonjakan null mendadak, puncak point-in-time, hari di mana jumlah baris turun ke angka bulat yang mengindikasikan partial load. Anda tetap harus menyelidikinya. Model hanya mengompres proses pemindaian.

Pemeliharaan kamus data. Mengubah tiket Jira menjadi entri glosarium adalah pekerjaan yang melelahkan. Memasukkan tiket yang sudah ditutup ke dalam model dan meminta definisi satu paragraf adalah jenis penulisan mekanis yang dilakukan AI dengan cukup baik dan yang sebaliknya tidak pernah Anda sempat lakukan.

Perhatikan polanya: AI berguna ketika input terbatas dan Anda tetap menjadi editor. Begitu model menjadi penulis akhir, hal-hal mulai meleset.

Di Mana AI Diam-Diam Gagal

Inilah bagian yang penting. Kegagalannya tidak terdengar keras. Kueri berjalan. Grafik terbentuk. Angkanya salah dengan cara yang membutuhkan tiga puluh menit arkeologi gudang data untuk dibuktikan.

Semantik data. Tabel orders Anda memiliki kolom status dengan nilai seperti pending, processing, shipped, delivered, returned, void, chargeback, dan legacy_v2. Mana yang berarti "benar-benar sebuah penjualan"? Tim Finance punya pendapat. Tim Ops punya pendapat berbeda. Model tidak tahu keduanya dan akan memilih opsi yang paling masuk akal, biasanya delivered, yang salah sekitar 8% waktu karena return diposting dalam batch terpisah.

Penanganan null. Model secara default menggunakan pemeriksaan WHERE column IS NULL. Gudang data Anda menggunakan string kosong, tanggal sentinel seperti 1900-01-01, string literal "NULL", dan satu kolom di mana nilai yang hilang dikodekan sebagai -999. Model tidak akan menangkap satupun dari ini kecuali Anda memberitahunya. Sebagian besar BA lupa memberi tahu karena mereka sudah menginternalisasi keanehan itu dan tidak lagi melihatnya.

Logika bisnis. "Pelanggan aktif" memiliki setidaknya enam definisi di gudang data mana pun yang berusia lebih dari dua tahun. Masuk bulan ini. Memiliki langganan berbayar. Memiliki langganan berbayar dan tidak dalam proses dunning. Memiliki langganan berbayar, tidak dalam proses dunning, dan tidak ditandai sebagai akun uji. Telah menggunakan produk dalam 14 hari terakhir. Aktif per snapshot Finance pada akhir bulan. Model akan memilih satu. Ia tidak akan memberi tahu Anda bahwa ia memilih satu. CRO akan mengutip angka yang dihasilkan dalam rapat board.

Tata kelola. Menempel baris pelanggan ke jendela chat adalah kejadian eksfiltrasi data. Menempel skema berada di garis batas. Menempel rencana kueri yang menyertakan PII nyata adalah insiden nyata. Sebagian besar BA tidak menganggap "tanya Claude" sebagai perpindahan data, tetapi Legal benar-benar menganggapnya demikian, begitu pula auditor berikutnya.

Saya telah melihat masing-masing kegagalan ini merusak analisis nyata dalam dua belas bulan terakhir. Tidak satu pun dari mereka yang mengumumkan dirinya sendiri. Kueri berjalan. Itulah intinya.

Loop Cursor + Claude untuk SQL

Cara ini sebenarnya bekerja dalam praktik, bagi saya dan para BA yang saya percayai:

Langkah 1: Paksa asumsi sebelum kode. Prompt pertama tidak pernah "tulis kuerinya." Itu selalu "sebelum Anda menulis SQL, daftarkan setiap asumsi yang harus Anda buat untuk menjawab pertanyaan ini terhadap skema ini." Tempel definisi tabel yang relevan. Model mengembalikan daftar. Anda mengeditnya. Sekitar sepertiga asumsi akan salah, dan Anda lebih suka berdebat dengan daftar daripada dengan kueri yang sudah jadi.

Contoh nyata. Pertanyaannya: "akun aktif bulanan berdasarkan tier paket untuk Q1." Asumsi model, yang sedikit diedit:

1. "Aktif" berarti last_activity_at dalam bulan kalender.
2. Tier paket adalah accounts.plan_id yang di-join ke plans.tier_name.
3. Akun uji (is_test = true) dikecualikan.
4. Akun trial gratis dihitung sebagai aktif.
5. Akun dengan beberapa perubahan paket dalam satu bulan diatribusikan ke paket mereka pada akhir bulan.
6. Zona waktu adalah UTC.

Angka 4 dan 5 salah untuk standar pelaporan kami. Akun trial gratis tidak dihitung, dan kami mengatribusikan berdasarkan paket awal bulan karena itulah cara Finance melakukannya. Menangkap itu di sini menghemat Anda dari kueri yang melaporkan bentuk yang benar dengan angka yang salah.

Langkah 2: Draf di Cursor. Dengan asumsi yang sudah dikoreksi, minta kuerinya. Editor Cursor memungkinkan Anda melihat skema di sidebar, yang berarti model lebih kecil kemungkinannya untuk menghallusinasi nama kolom. Model tetap akan menghallusinasi satu atau dua. Itulah mengapa Anda membacanya.

Langkah 3: Refaktor seperti PR dbt. Perlakukan kueri yang dihasilkan AI seperti Anda memperlakukan PR dari junior. Komentar di bagian atas yang mencatat tujuan, asumsi, dan "draf yang dibantu AI, direfaktor oleh [Anda]." Catatan inline pada join yang tidak jelas. Hitung pengujian di akhir (SELECT COUNT(*) FROM final terhadap referensi yang diketahui) sebelum mengirimkan hasilnya kepada siapa pun.

Langkah 4: Jalankan terhadap gudang data, dua kali. Sekali pada rentang tanggal kecil untuk memeriksa kewarasan bentuknya. Sekali pada rentang nyata untuk mendapatkan jawabannya. Jika kedua angka terasa tidak masuk akal, memang demikianlah. Model tidak punya pendapat tentang kelayakan. Anda punya.

Loop ini tidak lebih lambat dari menulis SQL dari awal untuk sebagian besar kueri yang tidak sepele. Ini secara material lebih cepat. Ini juga secara material lebih aman dari versi di mana Anda menerima draf pertama.

Perangkap "AI yang Menghasilkan Kueri Ini"

Ada alasan baru yang beredar. Seseorang mengirimkan angka yang salah. Post-mortem dilakukan. Frasa itu muncul: "AI yang menghasilkan kueri ini."

Frasa itu melakukan dua pekerjaan. Yang jujur: "Saya menggunakan alat, alatnya salah, saya tidak menangkapnya." Baik, itu terjadi, catat, lanjutkan. Yang tidak jujur: "tanggung jawab untuk angka ini ada pada model, bukan pada saya." Itu setara modern dengan mengutip Wikipedia dalam pengajuan pengadilan dan mengangkat bahu ketika kutipan itu ternyata adalah lelucon edit seseorang dari tahun 2009.

Jika Anda mengirimkan angkanya, Anda memiliki angkanya. Jika Anda menjalankan kuerinya, Anda memiliki kuerinya. Model adalah alat penulisan. Anda adalah analisnya. Pemangku kepentingan tidak peduli tentang rantai kepemilikan di luar nama Anda di tiket, dan mereka tidak perlu peduli.

Versi praktis dari aturan ini: jangan pernah menempel output model ke tiket pemangku kepentingan tanpa terlebih dahulu menjalankannya melalui gudang data. Bukan "melihatnya." Menjalankannya. Dengan jumlah baris. Terhadap skema aktual, dengan filter aktual, pada rentang tanggal aktual. Jika Anda mendapati diri hampir melewatkan langkah itu karena tenggat waktu sempit, tenggat waktu itu memang selalu akan sempit, dan melewatinya adalah cara angka yang salah dikutip dalam deck board.

Tata Kelola dan Versioning

Perlakukan analisis yang dibantu AI seperti kode lainnya, karena memang itulah kode. Daftar periksa yang dapat diterapkan:

• Tinjauan PR. Setiap kueri yang dibantu AI yang dikirimkan ke dasbor atau laporan berulang melalui tinjauan yang sama seperti yang ditulis tangan. Tidak ada pengecualian untuk "ini hanya angka cepat."
• Komentar yang mencatat bantuan. Baris header: -- Draf yang dibantu AI (Claude, 2026-04-28); direfaktor dan divalidasi oleh [nama Anda]. Ini untuk analis berikutnya, bukan untuk model.
• Tidak ada PII dalam prompt. Skema tidak masalah. Tiga baris pertama biasanya tidak masalah jika itu data uji. Baris pelanggan nyata, alamat email, detail pembayaran, catatan karyawan: jangan pernah. Gunakan sampel sintetis atau deskripsi kolom saja.
• Log prompt untuk audit. Cursor dan Claude keduanya memiliki riwayat. Jangan hapus. Ketika sesuatu rusak enam bulan dari sekarang, Anda ingin menemukan prompt aslinya.
• Daftar kill-switch dataset. Beberapa tabel tidak pernah dikirimkan ke API pihak ketiga. Catatan HR, keuangan pelanggan, apa pun yang berada di bawah aturan residensi data regional. Tulis daftarnya. Pin di saluran Slack BA. Karyawan baru membacanya sebelum mendapatkan akses gudang data.

Pekerjaan tata kelola ini tidak glamor. Namun ini adalah perbedaan antara AI menjadi pengganda produktivitas dan AI menjadi penyebab yang disebutkan dalam laporan insiden data tahun depan.

Opsional: Posisi Ini dalam ACE Framework

Bagi tim yang menggunakan ACE Framework untuk memetakan kemampuan AI di seluruh bisnis, pekerjaan BA yang dibantu AI berada tepat di Analyze pada level Capabilities (level 2 dari 5). Anda menggunakan AI untuk menginterpretasikan data yang ada dan menghasilkan keputusan, bukan untuk menyerap sumber baru (Ingest), membuat prakiraan (Predict), menyusun dokumen (Generate), atau mengambil tindakan hilir (Execute).

Kerangka yang berguna karena memberi tahu Anda apa yang tidak dilakukan AI untuk BA: AI tidak membangun pipeline data, tidak menjalankan model terhadap data masa depan, tidak mengirim email otomatis ke pemangku kepentingan. Hal-hal itu berada di baris ACE lain dan memiliki mode kegagalannya sendiri. Menjaga jalur tetap bersih membuat percakapan tetap bersih.

Rencana 30 Hari

Jika Anda telah membaca sampai di sini dan ingin cara untuk memulai tanpa menulis ulang seluruh alur kerja, inilah caranya. Pilih satu tugas SQL berulang dan jalankan eksperimen.

Tujuan 30 hari ini bukan untuk "mengadopsi AI." Ini untuk belajar, di gudang data Anda yang spesifik, di mana model berbohong. Setiap gudang data berbohong dengan cara yang berbeda. Saran AI generik mengabaikan hal ini; itulah mengapa sebagian besar tidak berguna.

Setelah 30 hari Anda akan memiliki pemahaman yang terkalibrasi tentang leverage-nya. Anda akan tahu tugas mana yang 3 kali lebih cepat dengan AI dan mana yang lebih lambat karena verifikasi memakan penghematan waktunya. Anda akan menuliskan hal-hal yang dibawa tim Anda di kepala mereka, yang merupakan hadiah tersendiri untuk diri masa depan Anda.

Penutup

AI dalam alur kerja BA ibarat junior yang cepat di hari pertama. Berguna, antusias, dan salah dengan penuh keyakinan. Leverage-nya nyata, begitu pula mode kegagalannya. Pekerjaan tidak berubah: pahami pertanyaannya, pahami gudang datanya, kirimkan angka yang benar. Alat yang berubah adalah di mana bagian yang sulitnya berada.

BA yang mengetahui di mana model berbohong nilainya lebih tinggi, bukan lebih rendah. BA yang memperlakukan model sebagai penulis akhir adalah orang yang namanya muncul dalam laporan insiden tahun depan di samping "AI yang menghasilkan kueri ini."

Pilih yang pertama.

Pelajari Lebih Lanjut

• Template Job Description Business Analyst
• Desain SQL dan Dasbor yang Mendapatkan Kepercayaan
• Pengumpulan Kebutuhan yang Tidak Melenceng
• Kesalahan Umum Business Analyst