Laporan Bulan Lalu Sebaiknya Tidak Berubah Bulan Ini

Seorang supervisor menarik laporan hasil kerja hari Senin. Hari Kamis dia menariknya lagi untuk rapat, periode yang sama persis, dan angkanya sudah berbeda.

Yang terjadi berikutnya biasanya bisa ditebak. Laporan itu dianggap rusak, tim IT dipanggil, dan setelah dicek ternyata tidak ada yang rusak sama sekali.

Sistemnya bekerja persis seperti yang diminta. Masalahnya, yang diminta bukan laporan.

Bucket itu benda hidup

Aging bucket adalah kriteria, bukan daftar. Isinya kira-kira begini: semua akun dengan tunggakan 31 sampai 60 hari, produk tertentu, di kota tertentu.

Setiap hari isinya berubah sendiri. Ada yang bayar lalu keluar. Ada yang jatuh lebih dalam lalu pindah ke bucket berikutnya. Ada yang direstrukturisasi dan hilang dari perhitungan.

Jadi ketika Anda bertanya berapa akun yang ada di bucket itu Senin lalu, sistem yang menyimpan kriteria saja akan menghitung ulang kriterianya hari ini, lalu menjawab dengan keanggotaan hari ini. Jawabannya benar secara teknis dan menyesatkan secara praktis.

Bagi hasil per agen kejadiannya sama. Kalau seorang agen dinilai dari berapa persen daftarnya yang tergarap, sementara penyebutnya bergerak setiap hari, angka itu tidak pernah berarti apa-apa dua kali.

Yang rusak bukan cuma laporannya

Kalau catatan masa lalu bisa berubah, beberapa hal ikut runtuh diam-diam.

Penilaian agen jadi tidak bisa dipertahankan. Seorang agen bisa terlihat malas bulan ini karena akun yang dia garap sudah lunas dan keluar dari daftar, sehingga jejak kerjanya ikut hilang. Percakapan soal kinerja berubah jadi perdebatan soal data.

Perencanaan kapasitas juga meleset. Anda tidak bisa tahu berapa orang yang dibutuhkan bulan depan kalau beban bulan lalu tidak pernah tercatat sebagai angka yang tetap.

Dan untuk yang menggarap data titipan dari pihak lain, ini jadi soal yang lebih serius. Ketika pemberi data bertanya kenapa dari seribu akun yang dititipkan hanya delapan ratus yang tersentuh, jawabannya harus bisa ditunjukkan apa adanya pada tanggal itu, bukan dihitung ulang hari ini.

Yang perlu dibekukan, dan yang tidak

Bedanya sederhana kalau sudah kelihatan.

Kriteria induknya harus tetap bisa diubah, karena aturan penagihan memang berubah. Yang tidak boleh ikut berubah adalah daftar kerja yang sudah dijalankan: siapa saja anggotanya saat itu, dan apa hasil tiap panggilannya.

Begitu daftar hari itu dibuat, isinya dibekukan. Mengubah kriteria bucket besok pagi akan mengubah daftar besok, dan tidak menyentuh satu baris pun dari yang kemarin.

Ini juga yang membuat masa simpan data bisa dipatuhi tanpa menghancurkan riwayat. Data pribadi anggotanya boleh dihapus ketika tenggatnya lewat, sementara angka hasilnya tetap tersimpan sebagai catatan bahwa pekerjaan itu pernah dilakukan dan hasilnya sekian.

Uji ini sebelum mempercayai laporan Anda

Ambil laporan periode yang sudah lewat, lalu bandingkan dengan salinan yang Anda simpan waktu periode itu masih berjalan.

Kalau angkanya sama, sistem Anda membekukan hasilnya dan Anda bisa berhenti membaca di sini. Kalau berbeda, sekarang Anda tahu kenapa angka rapat bulanan selalu terasa licin.

Dan kalau ternyata tidak ada seorang pun yang pernah menyimpan salinannya, itu sendiri sudah jawaban. Selama ini tidak ada yang menganggap angka itu perlu dipertahankan.

Di Koda, bucket berjadwal melahirkan daftar kerja bertanggal setiap pagi, dan anggota beserta hasilnya dibekukan begitu daftar itu jalan. Laporan hari Senin masih terbaca sebagai hari Senin berbulan-bulan kemudian, meski kriteria bucketnya sudah diubah tiga kali sejak itu.