Setiap pagi jam 07:30, operations manager sebuah perusahaan logistik skala menengah di kawasan Jabodetabek memulai harinya dengan cara yang sama: empat puluh menit menelepon. Menelepon driver untuk menanyakan posisi mereka. Menelepon kepala gudang untuk menanyakan apa saja yang sudah dikirim. Menelepon cabang Bandung untuk menanyakan paket yang belum terkirim kemarin. Setelah itu ia menyusun semua jawaban itu menjadi satu pesan WhatsApp untuk para direktur, dan pada jam 08:15 informasinya sudah basi.
Studi kasus dashboard logistik ini bercerita tentang apa yang terjadi ketika perusahaan tersebut menyatukan posisi armada, status driver, dan progres pengiriman ke dalam satu layar. Dari sisi teknis, pembangunannya cukup lurus. Bagian yang menarik, dan alasan saya menuliskan ini, adalah bahwa manfaat terbesarnya bukan di sisi operasional, melainkan politis.
Perusahaan ini mengoperasikan sekitar 45 kendaraan, 60 driver, dan kurang lebih 1.200 order pengiriman per hari di seluruh Jawa. Nama dan detail telah dianonimkan, tapi angka-angkanya representatif untuk skala perusahaan seperti ini.
Titik Awal: Data di Mana-mana, Kebenaran Tak Ada di Mana Pun
Sebelum proyek ini berjalan, perusahaan sebenarnya tidak kekurangan data. Mereka punya GPS tracker di sebagian besar truk, dipasang dua tahun sebelumnya oleh vendor fleet-tracking. Mereka punya sistem delivery order, sebagian aplikasi desktop lawas, sebagian lagi Excel. Driver melaporkan status lewat tiga grup WhatsApp yang berbeda. Cabang Bandung dan Semarang masing-masing menyimpan spreadsheet sendiri.
Masalahnya, tidak ada satu pun sumber data ini yang saling cocok, dan tidak ada satu orang pun yang bisa melihat semuanya sekaligus. Gejala-gejala spesifiknya:
- Ritual telepon pagi. Empat puluh menit setiap hari dihabiskan ops manager untuk menyusun manual gambaran yang seharusnya sudah tersaji dari sebuah sistem.
- Perang ops versus sales. Sales menjanjikan jendela waktu pengiriman ke pelanggan berdasarkan spreadsheet mereka. Ops bekerja dari spreadsheet yang berbeda. Ketika pengiriman terlambat, masing-masing pihak punya "bukti" bahwa pihak lain yang salah, dan rapat manajemen mingguan rutin menghabiskan satu jam hanya untuk memperdebatkan data siapa yang benar.
- Aset menganggur yang tak terlihat. Tidak ada yang bisa menjawab "truk mana saja yang sedang parkir sekarang, dan kenapa?" tanpa serangkaian panggilan telepon.
- Pertanyaan status dari pelanggan harus melalui CS ke ops lalu ke WhatsApp driver dan kembali lagi, perjalanan bolak-balik 2 sampai 4 jam untuk pertanyaan yang seharusnya bisa dijawab dalam 10 detik.
Yang Kami Bangun, dan yang Sengaja Tidak Kami Bangun
Mandatnya adalah satu layar kebenaran bersama, bukan ERP baru. Disiplin scope ini penting karena perusahaan sudah pernah mengalami kegagalan proyek "sistem besar" bertahun-tahun sebelumnya, jenis proyek mandek yang saya bahas di cara menyelamatkan proyek transformasi digital yang gagal.
Pembangunannya, diselesaikan dalam waktu sekitar empat bulan:
- Integrasikan, jangan ganti. Kami menarik posisi GPS dari API vendor tracker yang sudah ada, alih-alih memasang hardware baru. Data delivery order lama disinkronkan ke satu database pusat berukuran kecil. Total biaya hardware baru: nol rupiah.
- Aplikasi status driver menggantikan check-in via WhatsApp. Sengaja dibuat sederhana: terima manifest, berangkat, tiba, terkirim dengan foto bukti, atau gagal dengan kode alasan. Lima tombol, dibangun sebagai aplikasi mobile web sehingga tidak perlu instalasi apa pun.
- Dashboard itu sendiri. Satu layar web yang menampilkan setiap kendaraan di peta, setiap order pengiriman dengan status langsung, ringkasan per cabang, dan panel exception: keberangkatan telat, kendaraan mogok, pengiriman gagal. Diberi kode warna, mudah dibaca di TV ruang ops maupun di ponsel direktur.
- Tampilan berbasis peran. Sales mendapat akses baca ke status pengiriman. Satu keputusan itu ternyata menjadi baris paling berharga dalam keseluruhan spesifikasi.
Total biaya proyek berada di kisaran ratusan juta rupiah rendah, jumlah yang cukup berarti, tapi hanya sebagian kecil dari penawaran "ganti semuanya" yang sudah dikumpulkan perusahaan sebelumnya.
Kemenangan Terbesarnya Politis, Bukan Teknis
Ini bagian yang jarang diceritakan vendor. Dalam waktu satu bulan setelah go-live, perdebatan mingguan ops versus sales itu benar-benar berhenti dengan sendirinya. Bukan karena ada yang jadi lebih pintar berdebat, tapi karena tidak ada lagi yang bisa diperdebatkan. Ketika sales dan ops melihat layar yang sama, menampilkan truk yang sama dan event pengiriman dengan timestamp yang sama, "data kamu salah" berhenti menjadi pilihan yang tersedia.
Ops manager mengatakannya dengan terus terang: dashboard ini bukan cuma menghemat empat puluh menit teleponnya, tapi menyelamatkan dirinya dari posisi sebagai medan pertempuran manusia di antara dua departemen. Satu kebenaran bersama adalah mekanisme resolusi konflik. Di organisasi tempat setiap departemen menyimpan spreadsheet privat masing-masing, perselisihan menjadi tak terbantahkan, dan perselisihan yang tak terbantahkan menjadi permanen. Data bersama yang bertimestamp membuat perselisihan menjadi terbatas. Ada yang benar, layar menunjukkan siapa, semua orang lanjut jalan.
Kalau Anda hanya mengambil satu pelajaran dari studi kasus dashboard logistik ini, ambil yang ini. Proyek visibilitas biasanya dijustifikasi dengan angka efisiensi, tapi nilai terdalamnya sering kali adalah bahwa proyek itu mengakhiri perang.
Hasil Terukur Setelah Enam Bulan
Angka efisiensinya pun ikut datang:
| Metrik | Sebelum | Setelah 6 bulan |
|---|---|---|
| Penyusunan status pagi | ~40 menit telepon | Di bawah 5 menit, dibaca dari layar |
| Waktu respons query status pelanggan | 2 sampai 4 jam | Di bawah 15 menit |
| Truk menganggur tanpa alasan tercatat | Tidak diketahui | Teridentifikasi: 4 sampai 6 unit per hari, lalu terpangkas kurang lebih separuhnya |
| Waktu rapat manajemen mingguan untuk perdebatan "data siapa yang benar" | ~1 jam | Praktis nol |
| Tingkat pengiriman tepat waktu | Tidak bisa diukur secara andal | Dibuat baseline, lalu meningkat 9 poin |
Temuan soal aset menganggur ini layak dicatat khusus. Begitu setiap truk tampil di satu peta lengkap dengan alasan statusnya, perusahaan menemukan bahwa mereka sebenarnya memiliki kapasitas menganggur setara 4 sampai 6 truk per hari yang tersembunyi di berbagai cabang. Mereka menunda dua rencana pembelian kendaraan baru, nilainya lebih besar dari seluruh biaya proyek ini, karena dashboard membuktikan kapasitas itu sudah ada.
Perhatikan juga baris tingkat pengiriman tepat waktu: sebelum proyek ini, angka itu bahkan tidak bisa dipercaya. Anda tidak bisa memperbaiki metrik yang dua departemen saja tidak sepakat soal angkanya.
Yang Membuatnya Berhasil
- Integrasi, bukan penggantian. Memakai kembali vendor GPS dan data order lama memangkas biaya, dan yang lebih penting, memangkas resistensi. Tidak ada yang harus meninggalkan tool di tengah proyek.
- Aplikasi driver sengaja dibuat membosankan. Lima tombol, berbahasa Indonesia, diuji dulu ke driver yang paling gagap teknologi. Masalah adopsi jauh lebih sering menggagalkan proyek seperti ini dibanding masalah teknis.
- Ada eksekutif yang memilikinya. Direktur operasional secara pribadi memimpin standup pagi langsung dari dashboard sejak minggu pertama. Ketika leadership membaca dari layar, layar itu yang menjadi kebenaran.
- Exception, bukan noise. Dashboard ini memimpin dengan apa yang sedang bermasalah saat ini, sehingga orang mengeceknya karena berguna, bukan karena disuruh.
Intinya
Kalau manajer Anda memulai setiap hari dengan merekonstruksi realita lewat telepon, dan departemen-departemen Anda berdebat dari spreadsheet yang saling bersaing, Anda tidak butuh penggantian ERP. Anda butuh satu layar kebenaran bersama yang bertimestamp, dibangun sebagian besar dengan mengintegrasikan apa yang sudah Anda miliki. Dengan harga yang disiplin, proyek seperti ini balik modal lewat penundaan pembelian dan waktu manajemen yang terselamatkan dalam waktu satu tahun, dan gencatan senjata antar departemen datang secara gratis. Kalau operasi Anda terdengar seperti bagian "sebelum" dari cerita ini, saya membantu perusahaan menyusun scope untuk pembangunan seperti ini, dimulai dari apa yang sudah Anda punya.