Tim data terkadang diminta untuk membuktikan ROI mereka kepada pimpinan senior untuk membenarkan anggaran untuk karyawan baru, peralatan, proyek, atau perubahan proses. Tetapi pekerjaan tim data pada dasarnya tidak dapat diukur . Seringkali alasan pertanyaan ROI ini tidak berakar pada kurangnya metrik yang tepat, melainkan kurangnya kepercayaan dan hubungan dengan pemangku kepentingan.

Haruskah Anda mengukur ROI tim data? Jika demikian, metrik mana yang layak dipertimbangkan? Posting ini merangkum argumen utama dari beberapa posting blog, podcast , diskusi dari komunitas data , dan pengalaman saya.

Argumen menentang pengukuran

Sebagian besar tim data bekerja sebagai fungsi pendukung. Mereka membantu tim lain membuat keputusan dan beroperasi lebih efisien, tetapi keterlibatan mereka dalam penciptaan nilai tidak langsung . Anda tidak dapat mengukur secara langsung ( terutama di awal ) dampak dari tabel, dasbor, atau alur baru .

Meningkatkan model data atau infrastruktur data Anda tidak serta-merta memberikan hasil yang dapat diukur secara finansial terkait dengan inti bisnis Anda. Itu tidak berarti perbaikan itu tidak berharga. Tapi yang berharga belum tentu bernilai . Tim data sering kali tidak mendapat pujian atas pekerjaan mereka, bukan karena mereka melakukan pekerjaan yang buruk, tetapi karena budaya perusahaan tidak menghargai pekerjaan data terlepas dari kualitas atau kuantitasnya.

Dalam situasi seperti itu, masalah mendasar bukanlah kurangnya pengukuran ROI, tetapi kurangnya kepercayaan. Alih-alih mencari metrik yang sempurna, tim data perlu perlahan-lahan menerobos masuk dengan terus memecahkan masalah bisnis, mendapatkan kepercayaan dari pemangku kepentingan, dan secara bertahap meningkatkan budaya dan proses.

Alternatif untuk memperlambat perubahan budaya adalah mempekerjakan Manajer Produk yang tanggung jawabnya mengomunikasikan nilai tim ini kepada kepemimpinan senior, mengelola harapan, dan menerjemahkan hasil kerja tim ini menjadi hasil bisnis. Dengan cara yang sama seperti tim teknik tidak perlu membuktikan ROI mereka, tim data juga tidak boleh — PM yang berdedikasi dapat memastikan bahwa tim berfokus pada pekerjaan penting daripada permintaan ad-hoc yang tidak terlihat dan sulit diukur.

Kemungkinan lainnya adalah membiarkan pemangku kepentingan menceritakan kisah ROI Anda . Departemen lain harus memperkirakan berapa banyak nilai yang dikirimkan tim data kepada mereka. Jika ternyata pemangku kepentingan Anda tidak menghargai data yang bekerja cukup untuk mendukung Anda mendapatkan anggaran yang disetujui, ini menunjukkan masalah organisasi yang lebih dalam yang menyamar sebagai kebutuhan akan metrik.

Metrik yang layak dipertimbangkan

Mari kita asumsikan bahwa Anda mengajukan argumen yang menentang pengukuran, tetapi kepemimpinan masih mengharapkan Anda menemukan beberapa cara untuk mengukur dampak tim data.

Jika Anda cukup beruntung bahwa pekerjaan tim Anda dapat langsung berkorelasi dengan penciptaan nilai ( data adalah inti dari bisnis Anda ), itu adalah metrik yang baik untuk memulai:

Tetapi jika tim data Anda bekerja sebagai fungsi pendukung , Anda perlu mencari tahu apa yang layak diukur untuk bisnis Anda dan keadaan infrastruktur data perusahaan. Jika Anda bekerja untuk startup tahap awal ( terus-menerus memadamkan api ) atau di sisi berlawanan dari spektrum — lingkungan perusahaan yang lamban ( memperbaiki pipa lama yang rusak ), metrik Anda mungkin terlihat berbeda dari metrik tim terdesentralisasi dengan hubungan yang mapan dengan spesifik fungsi bisnis.

Sebelum Anda dapat mulai mencari metrik yang tepat

Anda harus terlebih dahulu mengidentifikasi siapa pelanggan Anda dan pemangku kepentingan terkait , apa yang mereka lakukan dan pedulikan, apa yang mereka harapkan dari Anda, dan bagaimana data dapat memberikan nilai bagi mereka.

Misalnya, meningkatkan keandalan pipeline data dan memperbaiki masalah kualitas data yang mendasarinya dapat menjadi tujuan akhir tim data. Anda dapat menggunakan tujuan tersebut sebagai titik awal untuk menyelaraskan pengukuran nilai dan kemajuan dengan pemangku kepentingan yang terpengaruh oleh masalah tersebut. Meskipun hal itu mungkin tidak berdampak langsung pada keuntungan, hal itu dapat membantu secara tidak langsung dengan meningkatkan proses dan efisiensi operasional , menghemat waktu atau biaya infrastruktur , dan mendapatkan lebih banyak kepercayaan pada data dan pekerjaan Anda. Dengan terlebih dahulu menuliskan apa yang diharapkan masing-masing pihak, Anda dapat mengklarifikasi dengan pemangku kepentingan bagaimana kerja data berkontribusi pada perubahan proses tambahanyang tidak mungkin terjadi tanpa keterlibatan tim data.

Aspek tambahan yang perlu dipertimbangkan saat menetapkan metrik nilai yang sesuai dengan pemangku kepentingan dari departemen lain:

• perincian dan cakrawala waktu apa yang sesuai untuk metrik Anda
• apa proses untuk menangkap dan melacak metrik itu
• apa proses untuk meninjau dan meningkatkan metrik tersebut — metrik harus memiliki tujuan, dan Anda perlu mengulanginya untuk memastikan Anda masih mengerjakan metrik yang tepat .

Menemukan metrik yang tepat itu menantang karena Anda perlu mengetahui bisnis untuk mengetahui apa yang harus diukur. Ada juga banyak aspek yang tidak terukur, seperti peningkatan pemahaman tentang bisnis yang dimungkinkan oleh data — mengetahui apa yang mendorong prospek dan pendapatan baru dan apa yang tidak layak diprioritaskan atau diinvestasikan. Keputusan buruk yang dapat dicegah dengan melihat data juga sulit dilakukan mengukur.

Salah satu metrik yang mungkin membantu dalam situasi seperti itu adalah kerangka waktu pengambilan keputusan yang diusulkan oleh Benn Stancil. Kerangkanya sederhana: kinerja tim data diukur dengan seberapa cepat keputusan dibuat. Semakin cepat, semakin baik kinerja Anda. Atau, seperti yang dikatakan Benn:

“Abaikan semua ambiguitas seputar pengukuran kualitas analitis dan ROI, dan lakukan apa pun untuk membuat orang lain lebih tegas.”

Pengukuran berorientasi bisnis lainnya adalah mengaitkan tujuan data dengan OKR perusahaan jika memungkinkan untuk menyelaraskan tujuan tersebut. Pendekatan ini memperjelas bagaimana pekerjaan tim data memengaruhi hasil fungsional.

Beberapa metrik lain yang layak dipertimbangkan adalah:

• Penghematan waktu — di banyak perusahaan, waktu dianggap sebagai aset yang paling berharga; jika Anda dapat memberikan beberapa jam kembali ke organisasi berkat efisiensi platform Anda dan menyediakan akses ke data lebih cepat, ada potensi penghematan biaya, peningkatan proses, dan kepuasan karyawan secara keseluruhan ( mengerjakan proyek yang berarti, bukan tugas berulang ); contoh dari hasil tersebut adalah peningkatan wawasan atau kemampuan untuk melakukan lebih banyak eksperimen ML dalam jangka waktu yang sama melalui paralelisme dan infrastruktur yang lebih baik — semuanya merupakan hasil yang terukur.
• Memotong biaya — ini mungkin diukur dengan biaya yang dihemat melalui alat yang tidak digunakan lagi yang tidak lagi diperlukan, bermigrasi ke alat yang lebih murah, peningkatan kinerja kueri yang mengurangi biaya komputasi, dll.
• Efisiensi operasional — perolehan efisiensi dapat dinyatakan melalui penghematan waktu berkat otomatisasi dan akses yang lebih mudah ke data atau wawasan tanpa komunikasi bolak-balik.

• Kualitas data — meskipun meningkatkan metrik kualitas data umumnya bermanfaat sebagai tujuan tim data, mengukur kualitas data itu sendiri sulit; sering kali, sistem sumber memutus jalur pipa karena perubahan skema — menggunakannya sebagai metrik akan menunjukkan penurunan kinerja tim data meskipun kualitas data sistem sumber berada di luar kendali Anda
• Tingkat kepuasan dengan akses ke data — pengukuran ini dapat menjadi heuristik yang berguna untuk menentukan bagaimana persepsi berbagai pemangku kepentingan bekerja dengan tim data, tetapi kelemahan dari pertanyaan ini adalah dapat dipengaruhi oleh bias pribadi; orang dapat melihat pertanyaan ini sebagai ukuran kesukaan daripada kinerja tim data aktual dan oleh karena itu tidak mewakili pekerjaan yang sedang dilakukan.

Terlepas dari metrik yang dibahas di atas, Anda dapat mempertimbangkan metrik kuantitatif yang berfokus pada produktivitas dan keluaran , seperti:

1. Jumlah pipeline data yang berhasil atau gagal
2. Jumlah proyek yang diselesaikan sesuai dengan waktu yang direncanakan
3. Jumlah keputusan yang dibuat
4. Jumlah aplikasi bertenaga data yang didukung , dasbor , tabel , sistem sumber terintegrasi , dan produk data yang diluncurkan

1. Kegagalan pipa data seringkali berada di luar kendali kami; sama halnya, memecah satu alur kerja menjadi beberapa alur kerja yang lebih kecil untuk menunjukkan jalur pipa yang lebih sukses ( untuk memanipulasi metrik ) tidak akan membantu bisnis dengan cara apa pun.
2. Perencanaan proyek bergantung pada ruang lingkup, persyaratan, kendala, dan banyak aspek organisasi — tidak satu pun dari aspek tersebut yang harus menentukan apakah kami menganggap pekerjaan data berdampak atau berharga; seringkali, proyek yang gagal dianggap sukses karena membuktikan bahwa sesuatu ( misalnya, proyek greenfield ) tidak layak dilanjutkan lebih lanjut.
3. Jumlah keputusan terlalu sewenang-wenang — satu proyek besar dapat dianggap sebagai satu keputusan. Namun, pertimbangkan sistem rekomendasi berbasis data, di mana setiap rekomendasi juga dapat dianggap sebagai satu keputusan. Sistem dapat merekomendasikan rute mana yang harus diambil, dan pengguna membuat keputusan ( misalnya, mengambil rute B ); untuk menggunakan jumlah keputusan sebagai metrik, angka ini perlu dinormalisasi dan distandarisasi.
4. Metrik pemanfaatan , seperti berapa banyak tabel yang Anda buat, menunjukkan produktivitas , bukan dampak atau nilai ; itu bisa berguna untuk dilacak, tetapi jumlah tabel atau dasbor yang lebih banyak tidak sama dengan pekerjaan analitik yang lebih baik — seringkali lebih sedikit lebih baik.

Tidak ada jawaban tunggal, tidak ada rumus ajaib, dan tidak ada metrik tunggal yang berlaku untuk semua orang. Metrik dapat mendukung membangun kepercayaan , tetapi itu saja tidak cukup.

Seperti biasa, kebenaran ada di antara keduanya — pimpinan senior harus menghargai kerja tim Anda tanpa harus membuktikannya, tetapi jika Anda perlu membuktikannya, bersiaplah untuk itu. Tunjukkan, jangan beritahu. Tunjukkan apa yang disampaikan tim Anda dan bagaimana tim Anda memecahkan masalah bisnis di masa lalu. Tunjukkan dampak perubahan proses inkremental yang tidak akan terjadi tanpa keterlibatan tim ini. Tunjukkan apa yang Anda ubah menjadi lebih baik — bagaimana uang dan waktu dihemat dan bagaimana efisiensi operasional meningkat. Dan metrik apa pun yang Anda pilih, ulangi — jangan biarkan kesempurnaan menjadi musuh kebaikan.

Pada akhirnya, Anda harus bekerja keras untuk terus menyempurnakan pemahaman Anda tentang bisnis untuk menilai metrik mana yang dibutuhkan dan mana yang berguna.