AI dalam Aliran Kerja Penganalisis Perniagaan: Di Mana Ia Membantu, Di Mana Ia Gagal

Waktu menunjukkan 9:14 pada hari Isnin. Seorang VP memajukan tangkapan skrin Slack. Pembantu AI baharu alat CSM mereka menyatakan pelanggan aktif meningkat 38% suku tahun lepas. Eksekutif itu ingin meletakkan angka tersebut dalam dek pembentangan lembaga sebelum tengah hari.

Anda membuka gudang data. Angka sebenar lebih hampir kepada 12%. Chatbot itu mengira setiap baris dalam customers tanpa mengambil kira status, mengabaikan bendera is_test yang ditambah oleh jurutera data anda pada bulan Februari, dan dengan senyap menjumlahkan metrik yang disetel semula setiap bulan seolah-olah ia adalah kumulatif. Anda kini mempunyai empat puluh minit untuk menerangkan apa yang berlaku salah tanpa kelihatan seperti seseorang yang takut diautomasi.

Inilah kehidupan BA sekarang. Setiap alat BI menghantar ciri "tanya dalam bahasa biasa". Setiap IDE mempunyai pelengkap automatik yang menulis join. Kebanyakan output adalah SQL yang salah namun yakin: pertanyaan yang berjalan, mengembalikan angka, dan mengira dengan salah dengan cara yang tidak mencetuskan sebarang garis panduan. Seseorang perlu menjadi barisan pertahanan terakhir. Orang itu masih anda, dan alat-alat itu tidak menjadikan kerja lebih mudah sejauh mana ia telah mengalihkan tempat bahagian-bahagian sukar berada.

Ini adalah pandangan BA yang bekerja, ditulis untuk mereka yang telah menghantar papan pemuka sebenar dan melakukan kesilapan sebenar.

Di Mana AI Benar-Benar Membantu BA

Terdapat pengarasan nyata di sini. Menolaknya atas prinsip adalah tenaga yang sama seperti penganalisis yang berkeras menulis setiap join secara manual pada tahun 2014 kerana IDE adalah "untuk junior." Kerja telah berubah. Lima tempat di mana AI membuktikan nilainya:

Draf SQL untuk diubah suai. Skeleton join, sintaks fungsi tetingkap, regex untuk medan log yang tiada siapa dokumentasikan. Anda memberikan Claude nama lajur dan penerangan satu baris tentang apa yang anda inginkan, dan ia mengembalikan pertanyaan yang 70% betul dan 100% lebih baik daripada bermula dari fail kosong. Kemudian anda mengubah suainya. Model ini lebih pantas daripada jari anda; jari anda tidak pernah menjadi kesesakan pun.

Dokumentasi skema papan pemuka. Empat puluh tiga lajur dalam fact_orders, tiga daripadanya dinamakan seperti flag_2 dan legacy_amt_v3. Tampalkan skema dan sejarah commit terkini ke dalam model dan minta ia membuat draf penerangan lajur. Anda akan membetulkan separuh daripadanya. Anda juga akan mempunyai dokumentasi bertulis yang tidak wujud sebelum ini, yang lebih baik daripada versi di mana ia tidak pernah ditulis langsung.

Persediaan temu bual keperluan. Sebelum taklimat awal pihak berkepentingan, minta model menjana soalan-soalan janggal yang anda cenderung lupa, seperti "apa maksud 'churned' di sini, bulan kalendar atau 30 hari bergulir?" atau "bagaimana kita mengendalikan akaun yang turun taraf dan kemudian naik taraf dalam tempoh yang sama?" Model ini tidak mengetahui perniagaan anda. Ia pandai mengingatkan anda tentang kategori soalan yang perlu anda tanya pun.

Pengesanan anomali pada set data yang diketahui. Arahkan model ke satu siri masa dan tanya "di mana seseorang yang berhati-hati akan melihat dahulu?" Ia akan menandakan perkara yang betul: lonjakan null mendadak, lonjakan titik-masa, hari di mana bilangan baris turun kepada nombor bulat yang mencadangkan muatan separa. Anda masih perlu menyiasat. Model itu hanya memampatkan pengimbasan.

Penyelenggaraan kamus data. Menukar tiket Jira menjadi entri glosari adalah kerja yang menjemukan. Memasukkan tiket yang ditutup ke dalam model dan meminta definisi satu perenggan adalah jenis penulisan mekanikal yang AI lakukan dengan mencukupi dan yang anda sebaliknya tidak akan sempat lakukan.

Perhatikan coraknya: AI berguna apabila input dibatasi dan anda kekal sebagai penyunting. Sebaik sahaja model itu menjadi pengarang akhir, perkara mula tergelincir.

Di Mana AI Senyap Gagal

Ini bahagian yang penting. Kegagalan tidak berlaku dengan kuat. Pertanyaan berjalan. Carta dipaparkan. Angka salah dengan cara yang memerlukan tiga puluh minit arkeologi gudang untuk dibuktikan.

Semantik data. Jadual orders anda mempunyai lajur status dengan nilai seperti pending, processing, shipped, delivered, returned, void, chargeback, dan legacy_v2. Yang mana daripada itu bermaksud "sebenarnya jualan"? Pasukan Kewangan anda mempunyai pendapat. Pasukan Ops anda mempunyai pendapat yang berbeza. Model ini tidak mengetahui mana-mana daripada mereka dan akan memilih pilihan yang terdengar paling munasabah, biasanya delivered, yang salah kira-kira 8% masa kerana pulangan yang diposkan dalam kelompok berasingan.

Pengendalian null. Model ini lalai kepada semakan WHERE column IS NULL. Gudang anda menggunakan rentetan kosong, tarikh sentinel seperti 1900-01-01, rentetan literal "NULL", dan satu lajur di mana nilai yang hilang dikodkan sebagai -999. Model ini tidak akan menangkap mana-mana daripada ini melainkan anda memberitahunya. Kebanyakan BA terlupa untuk memberitahunya kerana mereka telah menginternalisasi keanehan itu dan tidak lagi melihatnya.

Logik perniagaan. "Pelanggan aktif" mempunyai sekurang-kurangnya enam definisi dalam mana-mana gudang data yang berusia lebih dari dua tahun. Log masuk bulan ini. Mempunyai langganan berbayar. Mempunyai langganan berbayar dan tidak dalam dunning. Mempunyai langganan berbayar, tidak dalam dunning, dan tidak ditandai sebagai akaun ujian. Telah menggunakan produk dalam 14 hari terakhir. Aktif mengikut syot kilat Kewangan pada penghujung bulan. Model akan memilih satu. Ia tidak akan memberitahu anda bahawa ia memilih satu. CRO akan memetik angka yang terhasil dalam mesyuarat lembaga.

Tadbir urus. Menampal baris pelanggan ke dalam tetingkap sembang adalah peristiwa eksfiltrasi data. Menampal skema adalah di ambang. Menampal pelan pertanyaan yang merangkumi PII sebenar adalah insiden sebenar. Kebanyakan BA tidak menganggap "tanya Claude" sebagai pergerakan data, tetapi Undang-Undang pasti menganggapnya demikian, begitu juga juruaudit seterusnya.

Saya telah menyaksikan masing-masing daripada ini memecahkan analisis sebenar dalam dua belas bulan terakhir. Tiada yang mengumumkan diri mereka. Pertanyaan berjalan. Itulah maksudnya.

Gelung Cursor dan Claude untuk SQL

Cara ini sebenarnya berfungsi dalam amalan, bagi saya dan BA yang saya percayai:

Langkah 1: Paksa andaian sebelum kod. Arahan pertama tidak pernah "tulis pertanyaan." Ia adalah "sebelum anda menulis SQL, senaraikan setiap andaian yang perlu anda buat untuk menjawab soalan ini terhadap skema ini." Tampalkan definisi jadual yang berkaitan. Model mengembalikan senarai. Anda menyuntingnya. Kira-kira satu pertiga daripada andaian akan salah, dan anda lebih suka berhujah dengan senarai daripada dengan pertanyaan yang siap.

Contoh sebenar. Soalan: "akaun aktif bulanan mengikut peringkat pelan untuk S1." Andaian model, disunting sedikit:

1. "Aktif" bermaksud last_activity_at dalam bulan kalendar.
2. Peringkat pelan adalah accounts.plan_id yang digabungkan ke plans.tier_name.
3. Akaun ujian (is_test = true) dikecualikan.
4. Akaun percubaan percuma dikira sebagai aktif.
5. Akaun dengan berbilang perubahan pelan dalam sebulan dikaitkan kepada pelan mereka pada penghujung bulan.
6. Zon waktu adalah UTC.

Nombor 4 dan 5 salah untuk piawaian pelaporan kami. Akaun percubaan percuma tidak dikira, dan kami mengaitkan mengikut pelan awal bulan kerana itulah cara Kewangan melakukannya. Menangkap ini di sini menjimatkan anda daripada pertanyaan yang melaporkan bentuk yang betul dengan angka yang salah.

Langkah 2: Draf dalam Cursor. Dengan andaian yang dibetulkan, minta pertanyaan. Editor Cursor membolehkan anda melihat skema dalam bar sisi, yang bermaksud model kurang berkemungkinan menghayalkan nama lajur. Ia masih akan menghayalkan satu atau dua. Itulah sebabnya anda membacanya.

Langkah 3: Ubah suai seperti PR dbt. Layani pertanyaan yang dijana AI seperti anda melayan PR junior. Ulasan di bahagian atas yang mencatat tujuan, andaian, dan "draf berbantukan AI, diubah suai dan disahkan oleh [nama anda]." Nota sebaris pada mana-mana join yang tidak jelas. Kiraan ujian di hujung (SELECT COUNT(*) FROM final terhadap rujukan yang diketahui) sebelum menghantar hasilnya kepada sesiapa pun.

Langkah 4: Jalankannya terhadap gudang, dua kali. Sekali pada julat tarikh kecil untuk menyemak bentuknya. Sekali pada julat sebenar untuk mendapatkan jawapan. Jika kedua-dua angka terasa tidak munasabah, ia memang tidak munasabah. Model tidak mempunyai pendapat tentang kemunasabahan. Anda ada.

Gelung ini tidak lebih perlahan daripada menulis SQL dari awal untuk kebanyakan pertanyaan yang tidak remeh. Ia jauh lebih pantas. Ia juga jauh lebih selamat daripada versi di mana anda menerima draf pertama.

Perangkap "AI Menjana Pertanyaan Ini"

Terdapat alasan baru yang beredar. Seseorang menghantar angka yang salah. Post-mortem berlangsung. Frasa tersebut muncul: "AI menjana pertanyaan ini."

Frasa itu melakukan dua pekerjaan. Yang jujur: "Saya menggunakan alat, alat itu salah, saya tidak menangkapnya." Baik, itu berlaku, catatkan, teruskan. Yang tidak jujur: "tanggungjawab untuk angka ini terletak pada model, bukan pada saya." Itu setaraf moden dengan memetik Wikipedia dalam pemfailan mahkamah dan angkat bahu apabila petikan itu ternyata adalah suntingan jenaka seseorang dari tahun 2009.

Jika anda menghantar angka itu, anda memiliki angka itu. Jika anda menjalankan pertanyaan itu, anda memiliki pertanyaan itu. Model adalah alat penulisan. Anda adalah penganalisis. Pihak berkepentingan tidak peduli tentang rantaian jagaan melebihi nama anda pada tiket, dan mereka tidak sepatutnya perlu.

Versi praktikal peraturan ini: jangan tampal output model ke dalam tiket pihak berkepentingan tanpa terlebih dahulu menjalankannya melalui gudang. Bukan "melihatnya." Menjalankannya. Dengan kiraan baris. Terhadap skema sebenar, dengan penapis sebenar, pada julat tarikh sebenar. Jika anda mendapati diri anda hampir melangkau langkah itu kerana tarikh akhir terlalu ketat, tarikh akhir itu sentiasa akan ketat, dan melangkau itulah cara angka salah itu dipetik dalam dek pembentangan lembaga.

Tadbir Urus dan Pengeversian

Layani analisis berbantukan AI seperti kod lain, kerana ia adalah kod. Senarai semak yang berkesan:

• Semakan PR. Setiap pertanyaan berbantukan AI yang dihantar ke papan pemuka atau laporan berulang melalui semakan yang sama seperti yang ditulis tangan. Tiada pengecualian untuk "ini hanya angka cepat."
• Ulasan yang mencatat bantuan. Baris pengepala: -- Draf berbantukan AI (Claude, 2026-04-28); diubah suai dan disahkan oleh [nama anda]. Ini adalah untuk penganalisis seterusnya, bukan untuk model.
• Tiada PII dalam arahan. Skema adalah baik. Tiga baris pertama biasanya baik jika ia adalah data ujian. Baris pelanggan sebenar, alamat e-mel, butiran pembayaran, rekod pekerja: tidak pernah. Gunakan sampel sintetik atau penerangan lajur sahaja.
• Log arahan untuk audit. Cursor dan Claude kedua-duanya mempunyai sejarah. Jangan kosongkan. Apabila sesuatu pecah enam bulan dari sekarang, anda akan ingin mencari arahan asal.
• Senarai suis mati set data. Sesetengah jadual tidak pernah dihantar ke API pihak ketiga. Rekod HR, kewangan pelanggan, apa-apa di bawah peraturan kediaman data serantau. Tulis senarai itu. Pin dalam saluran Slack BA. Pekerja baru membacanya sebelum mereka diberi akses gudang.

Kerja tadbir urus tidak glamor. Ia juga merupakan perbezaan antara AI menjadi pengganda produktiviti dan AI menjadi punca yang dinamakan dalam laporan insiden data tahun depan.

Pilihan: Di Mana Ini Terletak dalam Kerangka ACE

Untuk pasukan yang menggunakan Kerangka ACE untuk memetakan keupayaan AI merentasi perniagaan, kerja BA berbantukan AI berada tepat dalam Analyze pada peringkat Capabilities (tahap 2 daripada 5). Anda menggunakan AI untuk mentafsir data sedia ada dan menghasilkan keputusan, bukan untuk memasukkan sumber baru (Ingest), meramal (Predict), membuat draf dokumen (Generate), atau mengambil tindakan hiliran (Execute).

Pembingkaian yang berguna kerana ia memberitahu anda apa yang AI tidak lakukan untuk BA: ia tidak membina saluran paip data, ia tidak menjalankan model terhadap data masa depan, ia tidak menghantar e-mel automatik kepada pihak berkepentingan. Perkara-perkara itu berada dalam baris ACE lain dan mempunyai mod kegagalan mereka sendiri. Memastikan lorong bersih memastikan perbualan bersih.

Pelan 30 Hari

Jika anda telah membaca sejauh ini dan mahukan cara untuk bermula tanpa menulis semula keseluruhan aliran kerja anda, inilah ia. Pilih satu tugas SQL berulang dan jalankan eksperimen.

Matlamat 30 hari bukan untuk "menggunakan AI." Ia adalah untuk belajar, dalam gudang khusus anda, di mana model berbohong. Setiap gudang berbohong dengan cara yang berbeza. Nasihat AI generik mengabaikan perkara ini; itulah sebabnya kebanyakannya tidak berguna.

Selepas 30 hari anda akan mempunyai pemahaman yang dikalibrasi tentang pengarasan. Anda akan tahu tugas mana yang 3x lebih pantas dengan AI dan yang mana lebih perlahan kerana pengesahan memakan penjimatan. Anda akan menuliskan perkara-perkara yang pasukan anda telah simpan dalam kepala, yang merupakan hadiah berasingan untuk diri anda pada masa hadapan.

Penutup

AI dalam aliran kerja BA adalah pekerja junior yang pantas pada hari pertama. Berguna, bersemangat, dan dengan yakin membuat kesilapan. Pengarasan adalah nyata, dan begitu juga mod kegagalan. Pekerjaan tidak berubah: fahami soalan, fahami gudang, hantar angka yang betul. Alat-alat telah mengubah tempat bahagian-bahagian sukar berada.

BA yang tahu di mana model berbohong lebih bernilai, bukan kurang. BA yang melayan model sebagai pengarang akhir adalah orang yang namanya muncul dalam laporan insiden tahun depan di sebelah "AI menjana pertanyaan ini."

Pilih yang pertama.

Ketahui Lebih Lanjut

• Templat Penerangan Kerja Penganalisis Perniagaan
• Reka Bentuk SQL dan Papan Pemuka yang Mendapat Kepercayaan
• Pengumpulan Keperluan yang Tidak Berubah
• Perangkap Biasa Penganalisis Perniagaan