Setiap malam sekitar jam 8, pemilik sebuah jaringan ritel di Tangerang menerima lima panggilan telepon, satu dari masing-masing cabang. Setiap supervisor cabang membacakan angka hari itu: penjualan, stok yang habis, hal-hal yang tidak biasa. Sang pemilik mencatat, dan pada jam 9 malam ia sudah punya gambaran bisnisnya, gambaran yang sebenarnya sudah salah, karena disusun dari ingatan, secara terburu-buru, oleh orang-orang yang lelah.

Ini adalah studi kasus visibilitas inventaris ritel, tapi saya ingin jujur soal intinya di awal: solusinya bukan software canggih. Jaringan ini tidak membeli ERP, tidak merekrut data scientist, dan menghabiskan biaya lebih kecil dari yang banyak perusahaan keluarkan untuk sekadar mendesain ulang brosur mengilap. Solusinya adalah menyepakati satu sumber kebenaran dan memastikan setiap angka stok dientri tepat satu kali. Dashboard datang belakangan, dan itu bagian yang justru paling mudah.

Detailnya dianonimkan, dan beberapa angka dibulatkan, tapi pola ceritanya sudah saya lihat berulang di ritel, distribusi, dan F&B.

Titik awal: tiga versi kebenaran

Jaringan ini menjual barang rumah tangga di lima cabang, sekitar 2.800 SKU aktif, dengan gudang pusat memasok cabang setiap minggu. Di atas kertas mereka punya proses inventaris. Pada praktiknya mereka punya tiga:

  • Catatan POS, yang mencatat penjualan tapi tidak mencatat barang rusak, pemakaian internal, atau "pinjam-meminjam" informal antar-cabang yang terjadi setiap kali satu cabang kehabisan stok.
  • Spreadsheet cabang, dikelola berbeda oleh masing-masing supervisor. Satu memakai kode warna, satu memakai sheet tersembunyi kedua, satu lagi menyimpan separuh datanya di buku catatan.
  • Telepon malam hari, yang justru menjadi tempat keputusan sebenarnya diambil.

Karton barang yang sama bisa dihitung berbeda di ketiga tempat itu. Rekonsiliasi dilakukan bulanan, memakan waktu sekitar empat hari bagi tim admin, dan sebagian besar hanya menghasilkan perdebatan.

Biayanya nyata tapi tersebar, itulah sebabnya situasi ini bisa bertahan bertahun-tahun:

Gejala Estimasi biaya
Dead stock ketemu saat akhir tahun (kedaluwarsa, usang, terlupakan di gudang) ~Rp180 juta write-off pada tahun sebelumnya
Restock darurat (transportasi mendesak untuk barang yang sebenarnya berlimpah di cabang lain) Rp3 sampai 5 juta per bulan
Waktu admin untuk rekonsiliasi dan ritual telepon malam ~6 hari-orang per bulan
Stok fast mover habis sementara slow mover menumpuk Tidak terukur, tapi keluhan terbesar sang pemilik

Jika bisnis Anda mengenali beberapa gejala ini, Anda mungkin sudah melewati titik di mana spreadsheet masih bisa membantu. Saya menulis diagnostik khusus untuk itu di 7 Tanda Bisnis Anda Sudah Melampaui Spreadsheet.

Solusi keliru yang hampir mereka beli

Sebelum kami bertemu, jaringan ini sudah mendapat penawaran sekitar Rp400 juta untuk implementasi ERP penuh, mencakup inventaris, akuntansi, HR, dan procurement, dengan timeline delapan bulan.

Saya tidak punya masalah dengan ERP. Tapi diagnosisnya keliru. Masalah mereka bukan fitur yang kurang. Masalahnya adalah data stok lahir di tiga tempat berbeda dan tidak pernah direkonsiliasi. ERP yang diberi input yang sama kacaunya akan menghasilkan kekacauan yang sama, hanya dengan font yang lebih rapi, dan implementasi yang gagal itu akan meracuni kepercayaan tim terhadap upaya berikutnya selama bertahun-tahun.

Kebutuhan sesungguhnya muat dalam satu kalimat: setiap pergerakan stok dientri sekali, pada saat kejadiannya, ke dalam satu sistem bersama, terlihat oleh kantor pusat pada hari yang sama.

Apa yang sebenarnya kami lakukan

Proyek ini berlangsung sekitar sepuluh minggu, dalam tiga tahap yang disengaja.

Tahap 1: menyepakati satu sumber kebenaran (minggu 1 sampai 3)

Tahap ini sama sekali tidak melibatkan software. Kami mengumpulkan pemilik, kepala gudang, dan kelima supervisor cabang dalam satu ruangan dan menuntaskan pertanyaan-pertanyaan yang selama ini diperdebatkan lewat telepon selama bertahun-tahun. Siapa menghitung apa, kapan. Apa yang dianggap rusak versus masih layak jual. Bagaimana transfer antar-cabang dicatat, oleh pengirim atau penerima. Apa arti stok habis secara presisi.

Hasilnya adalah buku aturan dua halaman. Membosankan untuk dibuat, dan menjadi artefak paling berharga dari seluruh proyek ini. Setiap keputusan teknis berikutnya hanyalah implementasi dari dokumen ini.

Tahap 2: satu titik entri per pergerakan (minggu 3 sampai 7)

Kami membangun aplikasi web sederhana, ramah perangkat mobile karena staf cabang bekerja dari ponsel, dengan tepat empat fungsi: terima stok, catat penyesuaian (kerusakan, koreksi), catat transfer, dan spot count harian untuk sebagian SKU secara bergilir. Penjualan tetap mengalir otomatis dari POS yang sudah ada.

Aturan desainnya ketat: mengentri satu pergerakan harus lebih cepat dibanding cara lama mencatatnya untuk telepon malam. Di bawah lima belas detik per entri. Kalau lebih lambat, staf akan wajar meninggalkannya saat sedang tertekan, dan masalah "tiga versi kebenaran" akan kembali dengan wajah baru.

Spreadsheet cabang lama dipensiunkan pada tanggal yang tegas, bukan dijalankan paralel tanpa batas waktu. Menjalankan paralel terasa aman tapi artinya entri ganda, dan entri ganda justru penyakit intinya.

Tahap 3: dashboard (minggu 7 sampai 10)

Baru setelah itu kami membangun apa yang sebenarnya diminta pemilik sejak awal: dashboard yang menampilkan stok real-time per cabang, fast mover versus slow mover, item di bawah ambang batas reorder, dan aging stok, yaitu seberapa lama barang sudah mengendap. Telepon malam berhenti pada minggu pertama. Kebiasaan kopi pagi yang berubah: sang pemilik membuka dashboard jam 8 pagi dan hanya menelepon cabang yang menunjukkan anomali.

Total biaya, termasuk workshop: di bawah Rp120 juta, kurang dari sepertiga penawaran ERP.

Hasil setelah enam bulan

  • Dead stock turun sekitar 30%. Tampilan aging membuat stok lambat terlihat dalam hitungan minggu, bukan saat penghitungan akhir tahun. Jaringan ini mulai menjalankan promo clearance selagi barang masih layak jual.
  • Biaya transportasi darurat turun lebih dari separuh, karena supervisor bisa melihat stok cabang lain sebelum melakukan reorder ke gudang.
  • Rekonsiliasi turun dari empat hari menjadi sekitar setengah hari per bulan, sebagian besar hanya verifikasi spot-check.
  • Yang tidak bisa diukur: rapat manajemen berubah. Diskusi dimulai dari satu layar bersama, bukan dari ingatan yang saling bersaing. Perdebatan soal berapa angka sebenarnya berubah menjadi keputusan soal apa yang harus dilakukan.

Tidak semuanya berjalan mulus. Kepatuhan satu cabang buruk pada bulan pertama, dan solusinya bersifat sosial, bukan teknis: pemilik menjadikan dashboard sebagai satu-satunya sumber yang diterima dalam rapat, sehingga supervisor yang angkanya hilang harus menjelaskan kesenjangan itu di depan umum. Kepatuhan mengikuti dalam hitungan minggu.

Pelajarannya

Pelajaran dari studi kasus visibilitas inventaris ritel ini adalah bahwa visibilitas bukan fitur software yang dibeli. Ia adalah disiplin yang disepakati, lalu diotomasi. Urutannya penting: aturan dulu, titik entri tunggal kedua, dashboard terakhir. Sebagian besar proyek inventaris gagal yang pernah saya tinjau menjalankan urutan ini terbalik, membeli dashboard duluan dan berharap disiplin akan mengikuti.

Jika malam-malam Anda diisi telepon yang merekonstruksi apa yang sebenarnya terjadi di bisnis Anda sendiri hari itu, mulailah dari buku aturan dua halaman. Biayanya cuma satu rapat. Dan jika Anda ingin mitra berpengalaman yang menguji ketat diagnosis sebelum Anda menandatangani penawaran software bernilai ratusan juta, itu persis jenis keterlibatan yang saya ambil lewat kerja kemitraan saya. Proyek termurah adalah proyek keliru yang tidak jadi Anda beli.