Reka Bentuk Papan Pemuka yang Mendorong Keputusan, Bukan Kesombongan

Selasa, 9:47 malam. Ping Slack masuk. "Hei, laporan ini silap, MRR kami menunjukkan 4.1 juta tetapi Kewangan kata 4.3 juta, boleh tengok sekejap?"

Anda membuka papan pemuka. Anda tidak menyentuhnya sejak tujuh bulan yang lalu. Medan pemilik tertulis "Sarah K" dan Sarah berhenti pada Oktober. Ada 14 carta. Tiga daripadanya mendakwa menunjukkan MRR dan kesemua tidak bersetuju. Pemapar terakhir ialah tiga minggu yang lalu, dan itu adalah anda, membukanya untuk berkongsi pautan dalam utas yang tepat ini.

Ping itu bukan masalah kualiti data. Ia adalah masalah reka bentuk. Mungkin masalah reka bentuk anda, daripada binaan yang anda hantar semasa sprint yang sudah anda lupakan.

Kebanyakan alat BI secara senyap melaporkan nombor yang sama: antara 60 hingga 80 peratus papan pemuka dibuka kurang daripada lima kali sepanjang hayatnya. Data penggunaan dalaman Looker, log pentadbiran Tableau Server, analitik penggunaan Hex: bentuknya sama setiap kali. Perkuburan itu lebih besar daripada lantai yang aktif. Dan setiap papan pemuka yang mati masih mengeluarkan kos: perbelanjaan pertanyaan gudang untuk penyegaran berjadual, hakisan kepercayaan apabila pihak berkepentingan menemui nombor yang bercanggah, dan kalender anda apabila seseorang menghidupkannya semula pada pukul 9:47 malam.

Playbook ini adalah disiplin reka bentuk yang memastikan bilangan papan pemuka anda kekal rata atau berkurang sementara kepercayaan pihak berkepentingan bertambah. Ia adalah kraf IC, bukan persembahan vendor BI.

Prinsip yang membunuh dapur kerja yang sesak

Sebelum sebarang peraturan khusus, tiga prinsip. Jika anda menghayati ini, selebihnya akan tertulis sendiri.

Satu keputusan per papan pemuka. Tulis keputusan itu dalam tajuk. Bukan "Gambaran Keseluruhan Jualan." Itu adalah topik, bukan keputusan. Tulis "Perlukah kita meramalkan semula jualan S3?" atau "Pipeline AE mana yang memerlukan semakan pengurus minggu ini?" Jika anda tidak dapat menulis keputusan dalam satu ayat, anda tidak tahu untuk apa papan pemuka itu, dan begitu juga orang yang membukanya. Topik bertambah. Keputusan tidak.

Hierarki visual, bukan demokrasi visual. Nombor utama pada papan pemuka mestilah sekurang-kurangnya 3 kali lebih besar daripada apa-apa yang lain pada halaman. Kajian penjejakan mata pada alat BI (Tableau Research, 2023) menunjukkan pengguna menghabiskan 60% daripada 8 saat pertama mereka pada jubin terbesar. Jika semua saiznya sama, anda telah memberitahu pengguna bahawa tiada apa yang penting. Pilih satu nombor yang menjawab keputusan itu. Jadikan ia besar. Selebihnya adalah bukti sokongan.

Disiplin warna. Satu warna aksen untuk jenama atau metrik utama. Kelabu untuk selebihnya. Merah dan hijau hanya untuk varian terhadap sasaran, bukan untuk siri kategori. Jika carta "Hasil mengikut Wilayah" anda mempunyai bar merah, hijau, biru, kuning, dan oren, anda telah melatih pengguna bahawa merah tidak bermakna apa-apa. Kemudian apabila merah sebenarnya bermakna "kami terlepas rancangan," ia tidak berkesan. Warna adalah bajet terhad. Kebanyakan analyst menghabiskannya dalam carta pertama.

Ketiga-tiga ini adalah asas. Selebihnya adalah pemakaian.

Peraturan 5 metrik

Tiada papan pemuka dihantar dengan lebih daripada 5 metrik utama. Titik.

Inilah peraturan yang semua orang bantah dan semua orang silap untuk membantahnya. Hujahnya sentiasa sama: "tetapi VP mahu melihat X, dan Y, dan juga Z." Baik. Binanya di suatu tempat. Cuma tidak pada permukaan yang sama dengan keputusan itu.

Mengapa 5? Penyelidikan beban kognitif (Miller, 1956, ya, kajian "nombor ajaib tujuh," diperhalusi oleh Cowan pada 2001 kepada kapasiti memori kerja 4 tambah tolak 1) adalah asasnya. Dalam mesyuarat, dengan seseorang membentangkan, dengan Slack berbunyi, had praktikalnya adalah lebih rendah lagi. Papan pemuka dengan 14 jubin tidak dibaca. Ia imbas sekilas. Pengguna memilih dua yang kelihatan mengejutkan dan mengabaikan selebihnya. Anda melakukan kerja 12 jubin untuk perhatian 2 jubin.

Peraturan yang dipakai:

• Jika anda mempunyai 5 metrik utama dan seseorang meminta yang ke-6, anda membina dua papan pemuka. Satu untuk Keputusan A, satu lagi untuk Keputusan B. Pisahkan.
• Jika anda tidak dapat memutuskan yang 5, anda belum memutuskan keputusan mana yang papan pemuka itu layani. Kembali ke langkah satu.
• Perincian lanjut (drill-down) bukan metrik. Nombor utama yang boleh diklik yang membuka pecahan adalah satu metrik, bukan tujuh. Anggap bilangan jubin permukaan sebagai had.
• Jubin "rujukan" (definisi, cap masa penyegaran, anak tetingkap penapis) tidak dikira dalam 5. Hanya jubin yang dibaca pihak berkepentingan untuk membuat keputusan.

Saya pernah menghantar papan pemuka dengan tiga metrik. Tiga. CFO membukanya setiap minggu. Saya pernah menghantar papan pemuka dengan sebelas metrik. CFO membukanya sekali dan meminta saya "ringkaskan kesimpulannya." Itulah papan pemuka yang sama yang gagal.

Konteks mengalahkan visualisasi, setiap kali

Inilah pendirian yang berbeza: nombor dengan diagnosis bertulis mengalahkan carta cantik tanpa naratif. Setiap kali.

"MRR: 4.18 juta (-4.2% MoM)" dengan anotasi satu baris ("Turun disebabkan 3 peralihan pelanggan (churn) perusahaan di EMEA, ketiga-tiganya dibenderakan semasa QBR; tempahan pengembangan 2.1 juta mengimbangi bersih kepada -1.8%") lebih berguna daripada carta garis yang paling cantik sekalipun. Kerana carta menunjukkan sesuatu telah berlaku. Anotasi memberitahu anda apa yang berlaku, mengapa, dan sama ada perlu panik.

Jadikan ini peraturan untuk setiap jubin yang pergi ke papan pemuka yang akan dibaca manusia: satu baris tentang "apa yang berubah dan mengapa." Bukan perenggan. Satu baris. Jika anda tidak dapat menulisnya, jubin itu belum sedia untuk dihantar.

Inilah bahagian yang kebanyakan analyst langkau kerana ia terasa seperti penulisan, bukan analisis. Ia adalah analisis. Tindakan menulis "turun 4.2% kerana tiga peralihan pelanggan perusahaan di EMEA" memaksa anda untuk benar-benar menjawab soalan dan bukannya membentangkan carta dan beredar. Jika jawapannya ialah "saya tidak tahu lagi," itu juga anotasi yang sah. "Turun 4.2% MoM, punca utama sedang disiasat menjelang Jumaat, lihat #data-investigations" memberitahu pihak berkepentingan bahawa anda telah melihatnya, anda sedang menguruskannya, dan mereka tidak perlu menghubungi anda. Ping yang tidak anda terima itu adalah baris teks dengan ROI tertinggi yang akan anda tulis sepanjang minggu.

Alat yang memudahkan ini: sel teks Hex di sebelah sel carta, jubin HTML Looker dengan komen bertemplat, papan pemuka Tableau dengan objek teks nota kaki bagi setiap jubin. Kesemua sokongan pola ini. Tiada yang menguatkuasakannya. Anda yang menguatkuasakannya.

"Laporan ini silap" dalam kaji semula selepas insiden (post-mortem)

Pada akhirnya seorang pihak berkepentingan akan mempersoalkan nombor. Itu bukan pilihan. Soalannya ialah sama ada anda menanganinya seperti seorang profesional atau seperti seseorang yang cuba memenangi hujah dalam Slack.

Berikut adalah protokolnya. Hafalkan. Ia akan menyelamatkan kerjaya anda sekurang-kurangnya dua kali.

Langkah 1. Akui dalam masa 5 minit, bukan 5 jam. "Terima, sedang menyiasat, akan balas menjelang EOD dengan apa yang saya temui." Itulah keseluruhan mesejnya. Jangan mempertahankan. Jangan berhujah. Jangan menerangkan mengapa nombor anda betul sebelum anda benar-benar menyemaknya. Kebimbangan pihak berkepentingan berkurang sebaik sahaja mereka melihat "sedang menyiasat."

Langkah 2. Sahkan pertanyaan. Buka SQL yang mendasarinya. Jalankan semula. Adakah anda menghasilkan semula nombor papan pemuka? Jika ya, papan pemuka tidak berbohong. Masih ada soalan sama ada pertanyaan itu betul, tetapi permukaannya konsisten. Jika tidak, anda mempunyai masalah caching atau penjadualan; tandakannya dan segarkan.

Langkah 3. Sahkan sumber kebenaran. Apa yang Kewangan / RevOps / sistem rekod katakan? Adakah lajur mrr anda diperoleh daripada subscriptions.amount atau daripada paparan terwujud monthly_recurring_revenue yang dibina pada tahun 2022 oleh seseorang yang telah berhenti? Adakah Kewangan menarik terus dari Stripe sementara anda menarik dari penyegerakan Fivetran yang 6 jam lapuk? 90% tiket "laporan ini silap" diselesaikan di sini, dan penyelesaiannya jarang "papan pemuka silap" atau "Kewangan silap." Ia adalah "kami mengira dua perkara yang sedikit berbeza dan memanggilnya dengan nama yang sama."

Langkah 4. Dokumentasikan ketidakpadanan. Dalam templat kaji semula selepas insiden, isikan: cap masa laporan, pertanyaan yang digunakan (tampal), nilai sumber kebenaran, nilai papan pemuka, punca utama (ketidakpadanan definisi / data lapuk / pepijat sebenar), pembetulan (jalankan semula / perubahan definisi / anotasi baharu), dan komunikasi pihak berkepentingan.

Langkah 5. Hantar pembetulan atau kaveat dalam masa 24 jam. Sama ada anda membetulkan isu yang mendasari, atau anda menambah anotasi peringkat jubin yang menerangkan jurang itu. Kedua-dua boleh diterima. Apa yang tidak boleh diterima ialah membiarkannya tergantung sementara dua bahagian organisasi terus beroperasi dengan nombor yang berbeza.

Jangan sekali-kali berhujah dalam utas Slack. Hujah dalam utas adalah cara analyst mendapat reputasi sebagai "defensif." Pindahkan perbualan ke dokumen kaji semula selepas insiden dalam masa 30 minit. Dokumen itulah artifaknya. Utas itu adalah hingar.

Saya menyimpan log berjalan bagi setiap kaji semula selepas insiden yang pernah saya hantar. Membacanya semula adalah satu-satunya latihan pembangunan kemahiran terbaik yang saya lakukan. Saya dapat melihat dengan tepat ketidakpadanan definisi mana yang terus berulang (sentiasa pengiktirafan hasil, sentiasa) dan di mana perlu melabur dalam pembetulan hulu. Setiap insiden juga merupakan isyarat tentang jubin mana yang memerlukan anotasi kekal supaya orang seterusnya tidak perlu menghubungi anda.

Penggunaan adalah metrik yang membuktikan papan pemuka berfungsi

Papan pemuka yang anda bina suku tahun lalu: adakah ia berfungsi? Kebanyakan analyst tidak dapat menjawab soalan itu, yang peliknya kerana kita secara profesional terobsesi dengan pengukuran.

Ukirkan penggunaan. Setiap alat BI mempunyai data tersebut:

• Looker mempunyai System Activity, sebuah Explore dalaman. history.query_run_count, dashboard.view_count, user.id, semua boleh ditanyakan.
• Tableau Server / Cloud mempunyai projek Admin Insights. views_workbooks dan views_dashboards memberikan anda pembukaan setiap aset setiap pengguna.
• Hex mempunyai analitik penggunaan terbina dalam pada halaman tetapan ruang kerja.
• Mode mempunyai API Discovery dan laporan pentadbiran.
• Power BI mempunyai laporan Metrik Penggunaan per ruang kerja.

Jejaki tiga nombor per papan pemuka, setiap bulan:

1. Pemapar unik. Bukan pembukaan. Manusia. Papan pemuka dengan 200 pembukaan dari 2 pemapar adalah tab yang dibiarkan terpasang oleh seseorang, bukan papan pemuka yang berfungsi.
2. Masa pada papan pemuka. Papan pemuka yang tiada siapa tatal adalah papan pemuka yang tiada siapa baca. Kebanyakan alat BI merekodkan tempoh sesi; kurang daripada 30 saat bermakna mereka membukanya dan beredar.
3. Kadar pemapar berulang. Daripada pemapar bulan lalu, berapa ramai yang kembali bulan ini? Pemapar berulang adalah khalayak sebenar. Yang lain datang sekali dan beredar.

Papan pemuka dengan kurang daripada 3 pemapar unik sebulan, selama dua bulan berturut-turut, adalah calon pemansuhan. Bukan calon "perlu reka bentuk semula." Calon pemansuhan. Hentikan pengoptimuman perkara yang tiada siapa buka.

Latihan paling berguna yang saya jalankan setiap suku tahun: susun setiap papan pemuka yang saya miliki mengikut bilangan pemapar berulang. Lima teratas mendapat masa dan perhatian saya. Lima terbawah mendapat semakan pemansuhan. Yang pertengahan mendapat pengabaian jinak, yang tidak mengapa. Pengabaian adalah murah, pemansuhan adalah jujur, dan penjagaan aktif adalah mahal. Gunakan di mana ia menghasilkan pulangan.

Semakan pemansuhan 6 bulan

Pemansuhan adalah ciri, bukan kegagalan. Hayati ini dan anda tidak akan pernah merasa buruk kerana mematikan papan pemuka lagi.

Setiap enam bulan, anda membuat sapu bersih. Blok setengah hari. Tarik data penggunaan untuk setiap papan pemuka dalam ruang anda. Susun mengikut pemapar unik, menaik. Kemudian:

1. Apa-apa yang kurang daripada 3 pemapar/bulan sepanjang 6 bulan terakhir: arkib. Bukan padam. Arkib. Pindahkan ke folder tersembunyi, letakkan pin dalam #data-archive mengumumkan apa yang dipindahkan, pautan senarai arkib. Jika ada yang membantah, anda boleh memulihkannya dalam 60 saat. Tiada siapa yang akan membantah. Mereka tidak membukanya.
2. Apa-apa yang 3-10 pemapar/bulan: sahkan semula pemilikan. Hubungi pemilik yang dinamakan. "Masih milik ini? Masih relevan? Masih ada keputusan yang dinamakan?" Jika pemilik telah berhenti, anda adalah pemilik baharu. Putuskan sama ada patut dikekalkan atau dihantar ke arkib. Tiada balasan dalam seminggu = arkib.
3. Apa-apa yang 10+ pemapar/bulan: kekalkan, audit anotasi jubin, segarkan nombor lapuk, dan kemas kini keputusan dalam tajuk jika perniagaan telah berubah. Ini adalah luas permukaan sebenar anda. Ia layak mendapat penyelenggaraan.
4. Siarkan senarai pemansuhan secara terbuka. Mesej ringkas dalam saluran data organisasi: "Sapu bersih selesai: arkib 12 papan pemuka, kekalkan 47, berikut senarainyanya." Tiga perkara berlaku. (a) Tiada siapa yang mengadu kerana tiada apa yang mereka benar-benar gunakan hilang. (b) Pasukan lain melihat irama ini dan mula melakukan yang sama. (c) Pimpinan menyedari bahawa seseorang sedang melayan contoh BI seperti infrastruktur, bukan tempat pembuangan sampah.

Kali pertama saya menjalankan sapu bersih seperti ini di syarikat terdahulu, saya mengarkibkan 38 papan pemuka. Dua orang menghubungi saya, kedua-duanya tentang papan pemuka yang sama, yang saya pulihkan dalam tiga minit. Itulah keseluruhan permukaan risiko. Ganjarannya adalah contoh BI yang memuatkan lebih pantas, keputusan carian yang lebih jelas, dan lebih sedikit utas Slack "tunggu, mana satu papan pemuka hasil yang sebenar?" secara nyata.

Dalam enam bulan, contoh BI anda harus mempunyai lebih sedikit papan pemuka berbanding hari ini. Bukan lebih. Jika lebih banyak, disiplin reka bentuk tidak berfungsi dan irama pemansuhan sedang dilangkau. Kedua-duanya boleh diperbaiki. Kedua-duanya adalah tugas anda.

Templat yang boleh anda guna

Spesifikasi satu halaman papan pemuka. Isi sebelum anda mula membina:

• Keputusan yang dijawab papan pemuka ini: (satu ayat, berakhir dengan kata kerja)
• Khalayak: (peranan yang dinamakan, bukan "pihak berkepentingan")
• 5 metrik utama, ditarafkan: (1, 2, 3, 4, 5)
• Irama penyegaran: (masa nyata / setiap jam / harian / mingguan, padankan dengan halaju keputusan)
• Pemilik: (manusia yang dinamakan, bukan pasukan)
• Kriteria penutupan: ("arkib jika kurang daripada 3 pemapar unik/bulan selama 60 hari")

Templat kaji semula selepas insiden. Isi dalam masa 24 jam setiap cabaran:

• Dilaporkan oleh, bila, dalam saluran mana
• Nombor yang dijangkakan pihak berkepentingan berbanding nombor papan pemuka
• Pertanyaan yang digunakan (tampal SQL penuh)
• Perbandingan sumber kebenaran (nilai Kewangan / RevOps / sistem)
• Punca utama (definisi / kesegaran / pepijat / kesilapan pengguna / sebenarnya betul)
• Pembetulan dihantar (pautan ke PR atau anotasi)
• Komunikasi kembali kepada pihak berkepentingan (tampal balasannya)

Senarai semak semakan 6 bulan. Blok setengah hari, jalankan sapu bersih:

• Tarik data penggunaan untuk semua papan pemuka yang dimiliki
• Susun menaik mengikut pemapar unik
• Arkib: kurang daripada 3 pemapar/bulan selama 6 bulan
• Pengesahan semula pemilik: 3-10 pemapar/bulan
• Audit dan segarkan: 10+ pemapar/bulan
• Siarkan senarai pemansuhan secara terbuka
• Kemas kini log pemansuhan (tarikh, bilangan diarkib, bilangan dikekalkan)

Tiga dokumen ini mencakupi 90% kebersihan papan pemuka. Cetak. Pin. Gunakan.

Perangkap biasa

Beberapa pola yang saya lihat, berulang kali, pada setiap pasukan:

• Membina daripada permintaan, bukan keputusan. Pihak berkepentingan berkata "saya mahu carta penukaran mengikut sumber." Anda membinanya. Anda menghantarnya. Enam minggu kemudian, tiada siapa yang membukanya, kerana keputusan sebenar ialah "adakah kita patut teruskan bayar kontrak Google Ads?", dan itu memerlukan CAC mengikut sumber ditambah lapisan pengekalan, bukan carta palang penukaran. Sentiasa tanya keputusannya sebelum menulis SQL.
• Papan pemuka eksekutif dengan 14 jubin kerana VP "mahu melihat semuanya." VP tidak mahu melihat semuanya. VP mahu berasa termaklum dan mendapati dua kejutan. Berikan mereka papan pemuka 5 jubin dengan ringkasan bertulis satu baris di bahagian atas, dan mereka akan berterima kasih kepada anda. Mungkin akan dinaikkan pangkat, akhirnya.
• Palet pelangi. Lapan siri, lapan warna, semua ketepuan yang sama. Pengguna tidak membaca apa-apa. Gunakan satu aksen, kelabu selebihnya, sorot hanya siri yang bergantung keputusan.
• Tidak pernah mansuh, hanya menambah. Ini adalah kematian perlahan. Setiap suku tahun, bilangannya meningkat. Setiap suku tahun, kualiti purata papan pemuka menurun. Enam bulan kemudian, contoh BI tidak boleh dicari dan tiga papan pemuka berbeza mengatakan tiga perkara berbeza tentang MRR. Pembetulannya adalah irama sapu bersih. Tanpanya, anda menambah hutang teknikal selama-lamanya.

Apa rupa "baik" itu

Anda telah menghayati ini apabila:

• Setiap papan pemuka yang anda miliki mempunyai keputusan yang dinamakan dalam tajuknya, bukan topik.
• Anda boleh menyenaraikan, dari ingatan, 5 papan pemuka teratas anda mengikut penggunaan dan 5 calon pemansuhan terbawah.
• Ping "laporan ini silap" turun suku demi suku, kerana setiap jubin mempunyai diagnosis bertulis yang dibaca pihak berkepentingan dahulu.
• Contoh BI mempunyai lebih sedikit papan pemuka dalam 6 bulan berbanding hari ini, bukan lebih.
• Dokumen kaji semula selepas insiden anda mempunyai sekurang-kurangnya 5 entri dari tahun lalu, dan anda boleh menunjukkan pembetulan hulu yang lahir daripada setiap satunya.

Itulah ukurannya. Bukan "saya bina lebih banyak papan pemuka." Bukan "pihak berkepentingan suka carta saya." Ia ialah: saya menghantar luas permukaan yang orang gunakan, saya mendokumentasikan kegagalan, dan saya memansuhkan yang tidak layak mendapat tempatnya.

Reka bentuk papan pemuka bukan latihan estetik. Ia adalah latihan bajet perhatian. Setiap jubin menelan perhatian pihak berkepentingan. Setiap papan pemuka menelan masa penyelenggaraan anda. Gunakan kedua-duanya seperti sumber yang terhad, kerana memang terhad.

Ketahui Lebih Lanjut

• Pengurusan Pihak Berkepentingan untuk Data Analyst
• SQL dan Pemodelan Data yang Berskala
• Metrik Data Analyst: Masa untuk Mendapat Cerapan, Penggunaan, Impak
• Templat Penerangan Kerja Data Analyst