Setiap fitur yang lahir dari tool internal biasanya punya cerita yang sama: bukan dari rencana besar di atas kertas, tapi dari masalah kecil yang ketemu di lapangan dan terus dikejar hingga tuntas. Dynamic Clustering v49 - salah satu tool di salesroute.id yang jadi motor Daily VRP - juga lahir dengan cara demikian.
Awalnya cuma mau benerin bug.
Versi pertama, dan lalu ke dua yakni v47, sudah bisa melakukan yang paling dasar: mengelompokkan outlet ke dalam cluster berdasarkan jarak dan kapasitas. Tapi ada satu parameter yang perilakunya aneh - "Max Outlet per Cluster" tidak berefek sama sekali kalau ada titik yang posisinya terisolasi dari titik-titik lain.
Setelah ditelusuri, penyebabnya muncul : ada radius maksimum 10 km yang di-hardcode di dalam kode, bukan parameter yang bisa diubah dari UI. Jadi walaupun kapasitas cluster diatur berapa pun, titik yang jauh sendirian akan tetap diperlakukan sesuai batas radius bawaan itu - bukan sesuai keinginan pengguna.
Perbaikan ini yang jadi cikal bakal v48: radius dijadikan input yang bisa diatur bebas. Kelihatan sepele, tapi ini pergeseran penting - dari tool yang "menentukan" jadi tool yang "menyesuaikan diri" dengan kondisi wilayah kerja yang beda-beda.
v49: mengakui bahwa algoritma tidak selalu benar
Begitu radius bisa diatur, muncul pertanyaan berikutnya: bagaimana kalau hasil clustering-nya sendiri, walau sudah dikonfigurasi dengan benar, tetap tidak sesuai dengan realita di lapangan? Algoritma clustering bekerja murni berdasarkan jarak dan kapasitas - dia tidak tahu ada outlet yang sebenarnya lebih dekat ke rute salesman lain karena akses jalan, atau ada preferensi tim yang tidak bisa direduksi jadi angka.
Dari sini lahir fitur andalan v49: kemampuan memindahkan outlet secara manual antar cluster, cukup dengan klik marker di peta. Fitur ini bukan pengganti algoritma, tapi pelengkapnya - semacam pengakuan bahwa keputusan akhir soal siapa melayani siapa tetap perlu ruang untuk human judgment, bukan cuma output mesin.
Kenapa ini penting untuk penyusunan VRP di PJP
Salah satu alasan paling konkret di balik pengembangan v49 adalah kebutuhan menyusun template VRP untuk Template PJP v5 yang memasukkan aktivitas delivery dan KPI Delivery Service Level (DSL) - bukan hanya urusan rute kunjungan salesman.
Begini konteksnya. Dalam simulasi pengembangan kolom Delivery Status di template PJP, setiap kunjungan outlet perlu dikaitkan dengan mobil pengangkut (kolom "Driver") dan status pengirimannya (Delivered atau Pending dengan alasan tertentu : Toko Tutup, Jalan Macet, Waktu Tidak Keburu, Toko Tidak Pesan dsb). Alokasi mobil ini tidak bisa asal comot dari cluster kunjungan yang sudah ada, karena kapasitas mobil (maksimal 30 invoice per mobil per hari) dan pengelompokan geografisnya perlu dihitung ulang secara khusus - inilah yang menjadi tugas Dynamic Clustering.
Kaitannya dengan DSL sendiri bukan sekadar teori. Dari pengalaman menangani dashboard Delivery Service Level di beberapa area/ cabang yang pernah saya handle, ditemukan fakta bahwa mayoritas alasan barang tidak terkirim (sekitar 40%) adalah "Toko Tutup" - sebuah kategori yang paling gampang dijadikan kambing hitam jika tidak divalidasi lebih jauh (apakah mobil benar2 sampai ke lokasi, atau cuma laporan sepihak si driver). Pengalaman semacam ini yang membuat kebutuhan akan clustering yang presisi dan bisa dikoreksi manual menjadi lebih dari sekadar fitur teknis - ini soal membangun data delivery yang bisa dipercaya untuk mengukur kinerja secara adil.
Dengan v49, proses ini menjadi lebih realistis:
Clustering otomatis mengelompokkan outlet2 dalam radius yang sudah disesuaikan dengan kondisi wilayah - bukan radius generik 10 km yang dulu terkunci di kode.
Kapasitas per mobil (30 invoice/ hari) dihormati sebagai batasan capacitated VRP, memastikan alokasi tidak timpang dan overlap antar driver.
Koreksi manual lewat klik marker menutup celah kasus-kasus yang tidak tertangkap algoritma murni - outlet yang secara geografis dekat tapi aksesnya sulit, atau yang perlu dipindah karena pertimbangan operasional lain.
Titik depot yang dipakai konsisten di seluruh proses ini - baik simulasi Excel maupun di tool Dynamic Clustering v47/ v48/ dan v49 - memastikan hasil cluster antar versi tetap bisa dibandingkan 'kesemek-to-kesemek' , bukan ber-ubah2 karena titik referensi yang bergeser.
Pada Intinya
Dynamic Clustering v49 bukan lahir dari rencana untuk "membuat fitur VRP yang keren". Ia lahir dari rangkaian pertanyaan praktis: kenapa radius ini tidak bisa diubah? Kenapa hasil cluster ini tidak masuk akal untuk outlet yang satu ini? Bagaimana caranya alokasi mobil untuk delivery bisa dihitung dengan kapasitas yang jelas, sambil tetap terhubung dengan KPI DSL yang selama ini jadi sumber perdebatan di lapangan?
Jawaban dari pertanyaan2 itulah yang akhirnya membentuk sebuah tool clustering yang tidak cuma menghitung jarak, tapi juga punya ruang untuk dikoreksi oleh orang yang paham medannya - sebuah kombinasi yang dibutuhkan setiap kali data geografis harus diterjemahkan menjadi keputusan operasional yang nyata: siapa mengirim ke mana, dengan mobil apa, dan kenapa.
Semoga bermanfaat, aamiin.
