OKR dan Kompensasi: Model Bonus yang Akurat di Sheets

Framework OKR Google sendiri dirancang untuk memisahkan skor dari keputusan kompensasi. Dalam dokumentasi resmi Google re:Work disebutkan bahwa "OKR bukanlah alat untuk mengevaluasi kinerja individu atau menentukan kompensasi." Sebagian besar perusahaan membaca itu, mengangguk setuju, lalu tetap menghubungkan skor OKR langsung ke formula bonus mereka.

Itu adalah pilihan kebijakan, bukan sesuatu yang salah. Tapi hal itu menciptakan masalah FP&A spesifik yang hampir tidak pernah dibahas dalam panduan implementasi OKR mana pun: ketika pencapaian OKR menjadi pengubah kompensasi, model bonus pool Anda menghadapi masalah distribusi yang berkorelasi, dan akrual pertengahan tahun menjadi tebak-tebakan kecuali model dibangun dengan benar.

Mengapa Google Memisahkan OKR dan Kompensasi

Mekanismenya sederhana. Jika karyawan tahu bahwa skor OKR mereka menentukan bonus, mereka akan menetapkan target yang lebih mudah dicapai. Ini terdokumentasi, dapat diprediksi, dan terjadi di hampir setiap perusahaan yang menghubungkan keduanya. Dalam survei Deloitte 2023 tentang manajemen kinerja, 58% pemimpin HR melaporkan bahwa keketatan penetapan tujuan menurun setelah organisasi mereka menghubungkan pencapaian tujuan langsung dengan upah variabel.

Skala skor Google berjalan dari 0,0 hingga 1,0, dengan 0,6-0,7 dianggap "baik" (lihat penjelasan lengkap metodologi penilaian Google re:Work kami). Alasan di balik kalibrasi itu adalah: jika 1,0 bisa dicapai secara rutin, berarti target tidak cukup ambisius. Hubungan dengan kompensasi membalik logika itu sepenuhnya. Karyawan mulai mengincar 0,8 karena skor 0,6 terasa berisiko ketika itu memengaruhi gaji mereka.

Itulah mengapa Google memisahkan keduanya. Pendekatan itu berhasil di Google. Tapi sebagian besar tim FP&A justru bekerja dalam kondisi sebaliknya, di mana OKR dan bonus sudah terhubung dan model yang tepat menjadi krusial.

Cara Perusahaan Sebenarnya Menghubungkan OKR dengan Kompensasi

Dalam praktiknya, arsitektur yang paling umum bukan bersifat biner (capai OKR = dapat bonus). Yang lebih umum adalah struktur modifier:

• Pencapaian OKR perusahaan menyesuaikan pendanaan bonus pool secara keseluruhan, biasanya antara 70% hingga 130% dari target
• Skor OKR individu atau tim memodulasi pembayaran individual dalam pool tersebut
• Diskresi manajer menangani kesenjangan antara output formula dan angka final

Bonus pool tahunan senilai Rp 76 miliar yang didanai 85% karena perusahaan mencapai skor 0,72 pada OKR-nya akan menghasilkan Rp 64,6 miliar untuk didistribusikan. Selisih itu langsung mengalir ke P&L, dan jika akrual kuartalan Anda mengasumsikan pendanaan penuh, Anda harus membalik sekitar Rp 11,4 miliar di Q4. Angka itu material. Angka itu muncul dalam board pack sebagai reconciling item, dan jika tim keuangan tidak memodelkan kisarannya sejak awal, hal itu terlihat seperti kejutan yang tidak terduga.

Tabel berikut menunjukkan kurva pendanaan pool yang umum digunakan sebagai acuan awal, sebelum disesuaikan dengan kebijakan internal masing-masing perusahaan:

Kurva ini biasanya dikodekan sebagai tabel lookup di tab Assumptions, bukan dihitung secara dinamis, sehingga mudah direvisi saat kebijakan berubah.

Tantangan Pemodelan: Distribusi yang Berkorelasi

Inilah masalah aktuaria yang dilewati sebagian besar model. Skor OKR tidak independen dari kinerja bisnis. Ketika perusahaan meleset dari target pendapatan sebesar 12%, OKR cenderung ikut rendah juga. Tidak selalu, tapi sering. Artinya:

1. Bonus pool Anda kekurangan dana (varians pendapatan negatif)
2. OKR modifier Anda di bawah 1,0 (pencapaian yang buruk)
3. Keduanya menekan akrual secara bersamaan

Jika model Anda memperlakukan pendanaan bonus pool dan OKR modifier sebagai input yang independen, Anda meremehkan skenario downside secara signifikan. Pendapatan yang meleset 10% dikombinasikan dengan rata-rata pencapaian OKR 0,65 (dibandingkan asumsi 0,80) dapat menekan pool Rp 76 miliar menjadi sekitar Rp 51 miliar, sebuah pergeseran sebesar 33%.

Arsitektur yang tepat adalah tabel sensitivitas yang menggerakkan kedua variabel secara bersamaan, bukan secara independen.

Membangun Model Kompensasi di Sheets

Implementasi yang wajar menggunakan 5 tab: Assumptions, OKR_Tracker, Headcount, Comp_Model, dan Bonus_Accrual. Begini cara mereka saling terhubung.

Tab Assumptions menyimpan input utama: target bonus pool (Rp 76 miliar), kurva pendanaan OKR perusahaan (tabel yang memetakan pencapaian ke persentase pool, misalnya 0,6 → 70%, 0,8 → 100%, 1,0 → 130%), dan kisaran modifier individu.

OKR_Tracker adalah tempat skor kuartalan masuk, satu baris per tujuan, dengan kolom untuk pemilik, departemen, bobot kuartal, dan skor. Rumus rollup per departemen:

// Comp_Model!D4 - Rata-rata skor OKR departemen Engineering, tertimbang Q3
=SUMPRODUCT(
  (OKR_Tracker!$C$2:$C$200="Engineering")*
  (OKR_Tracker!$D$2:$D$200="Q3")*
  OKR_Tracker!$E$2:$E$200*
  OKR_Tracker!$F$2:$F$200
) /
SUMPRODUCT(
  (OKR_Tracker!$C$2:$C$200="Engineering")*
  (OKR_Tracker!$D$2:$D$200="Q3")*
  OKR_Tracker!$E$2:$E$200
)

Perhitungan bonus per karyawan di Comp_Model mengambil gaji pokok dari Headcount, persentase target bonus dari Assumptions, dan OKR modifier dari OKR_Tracker:

// Comp_Model!G4 - akrual bonus individu, tahunan
=Headcount!$E4 *
 VLOOKUP(Headcount!$D4, Assumptions!$B$14:$C$18, 2, FALSE) *
 IFERROR(
   VLOOKUP(Headcount!$A4, OKR_Tracker!$A:$G, 7, FALSE),
   Assumptions!$C$22   // fallback ke rata-rata perusahaan jika skor individu tidak tersedia
 ) *
 VLOOKUP(Assumptions!$B$4, Assumptions!$F$3:$G$8, 2, TRUE) // modifier pendanaan pool perusahaan

Modifier pendanaan pool di tingkat perusahaan menggunakan VLOOKUP dengan range lookup diatur ke TRUE karena Anda ingin interpolasi antara ambang batas pencapaian, bukan pencocokan eksak.

Bonus_Accrual kemudian merangkum ini per kuartal dengan penyesuaian timing yang sesuai:

// Bonus_Accrual!C6 - beban bonus Q3, departemen Engineering
=SUMIFS(
  Comp_Model!$G:$G,
  Headcount!$C:$C, "Engineering",
  Headcount!$H:$H, "<>" & "Termed"
) * Assumptions!$D$6 // fraksi akrual Q3 (misalnya 25%)

Masalah Distribusi Skor

Inilah yang diabaikan sebagian besar model bahkan setelah struktur di atas dibangun dengan benar: OKR modifier dalam formula Anda menggunakan skor rata-rata. Padahal distribusi skor sangat penting untuk total pembayaran, karena target bonus tidak seragam di seluruh organisasi.

Jika VP Product Anda dengan gaji Rp 3,5 miliar per tahun mendapat skor 0,95 dan analis Anda dengan gaji Rp 1,35 miliar mendapat skor 0,60, rata-rata skor OKR dari dua orang tersebut adalah 0,775. Tapi rata-rata tertimbang berdasarkan nilai kompensasi (dollar-weighted average), yang sebenarnya mendorong beban bonus Anda, adalah:

= (Rp 3.500.000.000 × 20% target × 0,95 + Rp 1.350.000.000 × 12% target × 0,60) /
  (Rp 3.500.000.000 × 20% + Rp 1.350.000.000 × 12%)
= (Rp 665.000.000 + Rp 97.200.000) / (Rp 700.000.000 + Rp 162.000.000)
= Rp 762.200.000 / Rp 862.000.000
= 0,884

Itu bukan 0,775. Karyawan berpenghasilan tinggi dengan skor OKR tinggi memiliki bobot yang jauh lebih besar dalam total beban kompensasi, dan model yang menggunakan pencapaian rata-rata sederhana akan meremehkan akrual ketika para top performer Anda juga merupakan top scorer OKR Anda.

Solusinya sederhana: hitung OKR modifier sebagai rata-rata tertimbang berdasarkan nilai kompensasi di seluruh headcount, bukan rata-rata tertimbang berdasarkan jumlah kepala. Tapi Anda perlu membangunnya dengan cara itu sejak awal, karena menambahkan pembobotan berbasis nilai ke dalam formula yang awalnya mengasumsikan head count adalah perubahan struktural yang cukup besar.

Per Juni 2026, ini adalah kesalahan yang paling sering saya temukan dalam model kompensasi yang terhubung dengan OKR. Dan ini juga yang paling mungkin menciptakan pembalikan (reversal) saat penutupan buku Q4.

Memperbarui Data OKR di Akhir Kuartal

Ada satu masalah praktis lagi: skor OKR biasanya baru bersifat final 2-4 minggu setelah akhir kuartal. Buku Q3 Anda tutup di Oktober, tapi skor OKR final mungkin baru tersedia pertengahan Oktober. Kesenjangan waktu itu membuat Anda membukukan akrual berdasarkan skor sementara yang masih bisa berubah.

Dua pendekatan yang bisa dipilih: (1) gunakan rata-rata pencapaian kuartal sebelumnya sebagai placeholder, lalu lakukan true up di periode berikutnya; atau (2) bangun model untuk menandai skor OKR mana yang masih sementara dan mana yang sudah final, lalu hitung kisaran nilai daripada estimasi titik tunggal.

Jika Anda menarik data skor OKR dari alat seperti Asana, Lattice, atau tracker berbasis Sheets buatan internal, ModelMonkey dapat mengambil data tersebut ke model kompensasi Anda secara otomatis saat penutupan kuartal, sehingga akrual Anda mencerminkan kondisi skor pada saat penutupan buku, ditandai sebagai sementara, tanpa perlu ekspor CSV manual.