Saat Metrik Terlihat Terlalu Bagus: Memperbaiki AHT dari Sumbernya

#Kenapa metrik yang terlihat terlalu bagus perlu dicurigai?

Karena tidak ada yang menyelidiki kabar baik. Angka yang buruk memicu keluhan dan root-cause analysis. Angka yang bagus dipuji, disalin ke slide, lalu dibiarkan. Begitulah sebuah kesalahan bisa bertahan berbulan-bulan.

Kasus kami muncul dari sweeping kualitas acak, bukan dari keluhan. Average handling time sebuah project sangat rendah. Timnya terlihat cepat. Angkanya salah.

#Apa itu AHT, dan kenapa angka ini penting?

Average handling time (AHT) adalah total waktu yang dipakai untuk menangani pekerjaan dibagi jumlah task yang ditangani. Di Map Operations, AHT mengukur berapa lama setiap task peta dikerjakan: mengumpulkan, mengedit, atau mereview sebuah tempat atau ruas jalan.

Ini bukan angka pajangan. AHT adalah salah satu metrik inti yang dipantau divisi di berbagai negara. Angkanya dibawa ke rapat review rutin antar-leader, dan dipakai untuk menjustifikasi effort serta kebutuhan orang di setiap project. Kalau AHT satu project terlalu rendah, project itu terlihat lebih murah dari kenyataannya, dan setiap perbandingan dengannya jadi tidak adil bagi project lain.

#Apa yang pertama kali dicurigai?

Penjelasan yang paling mudah adalah yang paling menyenangkan: timnya memang cepat. Ada tim yang memang begitu.

Jadi kami mengujinya dengan kenyataan. Dengan isi pekerjaan setiap task, mungkinkah seseorang menyelesaikannya dalam waktu sesingkat itu? Jawabannya tidak. Selisihnya terlalu besar untuk dijelaskan oleh keahlian atau jam terbang. Ada sesuatu yang seharusnya dihitung, tetapi tidak.

#Ke mana hilangnya waktu itu?

Setiap task di worksheet dipecah menjadi beberapa aksi bertimestamp yang dicatat tim operasional. Rumusnya seharusnya menjumlahkan waktu penanganan dari aksi-aksi itu lalu membaginya dengan jumlah task.

Pembagiannya sendiri benar. Masalahnya ada pada apa yang masuk ke dalamnya: rumus itu tidak mencakup setiap sel aksi dalam rincian sebuah task, sehingga sebagian waktu kerja yang nyata tidak pernah masuk ke total. Waktu yang lebih sedikit dibagi jumlah task yang sama menghasilkan AHT yang terlihat sangat rendah.

Buka ukuran penuh

	Rumus lama	Rumus yang diperbaiki
Aksi yang dihitung per task	Sebagian aksi bertimestamp	Semua aksi dalam rincian task
Satuan hitung	Tidak konsisten antar-sheet	Distandarkan per task
AHT yang dihasilkan	Terlalu rendah, terlihat seperti tim yang cepat	Realistis dan bisa dibandingkan antar-project

Menstandarkan satuan hitung sama pentingnya dengan menambahkan sel yang terlewat. Kalau satu sheet menghitung per aksi dan sheet lain per task, pekerjaan yang sama menghasilkan dua AHT yang berbeda, dan para leader akhirnya membandingkan definisi, bukan performa.

#Kenapa memperbaiki worksheet master, bukan laporannya?

Setiap project baru dimulai dari salinan sebuah worksheet master. Artinya, rumus yang keliru itu bukan satu kesalahan, melainkan template yang mereproduksi kesalahan yang sama di setiap project yang menyalinnya.

Buka ukuran penuh

Jadi kami memperbaiki rumus di worksheet master itu sendiri. Sejak saat itu, tim mana pun yang memulai project baru di worksheet baru langsung mendapatkan perhitungan yang benar, tanpa ada yang perlu ingat untuk menambalnya.

Inilah arti shift-left dalam kualitas data: pindahkan pengecekan atau perbaikan sedekat mungkin ke tempat data itu dibuat. Membersihkan angka di hilir, laporan demi laporan, hanya mengobati gejalanya dan memastikan bulan depan harus dibersihkan lagi.

#Kenapa AHT yang akurat penting di luar satu project?

Karena metrik ini menyebar. AHT dari setiap negara digabung ke review tingkat divisi, dan keputusan soal effort dan prioritas bersandar padanya. AHT yang terlalu rendah bukan hanya menyanjung satu tim. Angka itu diam-diam membuat setiap project yang jujur terlihat lambat jika dibandingkan.

AHT yang akurat dan didefinisikan secara konsisten memberi setiap project justifikasi yang adil. Tim dibandingkan berdasarkan pekerjaan yang mereka lakukan, bukan berdasarkan versi spreadsheet mana yang kebetulan mereka salin.

#Apa pola yang bisa dipakai ulang?

Setiap metrik yang dibangun dari banyak template yang disalin, entah spreadsheet, dashboard, atau model dbt, membawa risiko yang sama.

• Selidiki outlier yang bagus. Angka yang terlalu bagus layak mendapat root-cause analysis yang sama dengan angka yang terlalu buruk.
• Uji dengan kenyataan. Tanyakan apakah angkanya masuk akal secara fisik sebelum menanyakan apakah timnya berbakat.
• Lakukan sweeping acak. Keluhan hanya menemukan masalah yang merugikan seseorang. Pengecekan kualitas acak menemukan masalah yang menyanjung seseorang.
• Perbaiki templatenya, bukan salinannya. Koreksi logikanya di tempat setiap salinan baru lahir, supaya perbaikannya menyebar dengan sendirinya.
• Beri versi pada definisi. Saat rumus berubah, tandai titik putusnya, supaya tidak ada yang membaca perubahan definisi sebagai perubahan performa.

Naluri yang sama mengalir di seri ini: di artikel celah poligon, sebuah tabel lookup diam-diam kurang menghitung pendapatan; di sini, sebuah template diam-diam kurang menghitung waktu. Keduanya terlihat baik-baik saja sampai ada yang mengecek inputnya.

#FAQ

#Apa itu average handling time (AHT)?

Total waktu yang dipakai untuk menangani task dibagi jumlah task yang ditangani. Ini metrik operasional standar di pusat layanan dan tim back-office, dan hanya seandal data waktu dan jumlah task yang mengisinya.

#Apa itu shift-left data quality?

Mengecek dan memperbaiki data sedekat mungkin dengan tempat data itu dibuat, bukan mengoreksinya belakangan di laporan. Perbaikan di sumber melindungi semua pemakaian di hilir sekaligus.

#Kenapa perlu sweeping kualitas acak kalau tidak ada keluhan?

Karena keluhan cenderung hanya muncul untuk masalah yang merugikan seseorang. Kesalahan yang membuat angka terlihat lebih bagus jarang dikeluhkan, jadi hanya pengecekan acak yang disengaja yang bisa menemukannya.

#Referensi

• Saat Celah Poligon Menjadi Celah Pendapatan, artikel sebelumnya dalam seri ini
• Geospatial Product Ops: Di Antara Peta dan Bisnis, tentang root-cause analysis untuk keberhasilan maupun kegagalan

Terakhir diperbarui: 30 Oktober 2026.