Studi kasus demand forecasting ini dimulai dari keluhan yang cukup umum. Sebuah jaringan retail di Tangerang dengan beberapa cabang datang ke kami dengan pola yang sudah menggerus margin selama bertahun-tahun: produk terlarisnya selalu habis di pertengahan bulan, setiap bulan, sementara produk yang kurang laku menumpuk di gudang tiap toko sampai akhirnya harus didiskon besar-besaran hanya supaya bisa terjual. Bukan karena timnya tidak kompeten. Pemesanan masih ditentukan lewat feeling dan spreadsheet, dan feeling tidak bisa scale ke banyak toko dengan basis pelanggan yang berbeda-beda.
Insting sang pemilik adalah menyalahkan manajer cabang atas keputusan pemesanan yang buruk. Masalah sebenarnya bersifat struktural: setiap manajer memesan ke kantor pusat berdasarkan ingatan tentang apa yang laku bulan lalu, tanpa visibilitas terhadap pola musiman, tanpa perbandingan antar cabang, dan tanpa waktu untuk benar-benar menganalisis histori transaksi dua belas bulan secara manual.
Diagnosis: tiga gejala, satu akar masalah
Sebelum menyentuh teknologi apa pun, kami menghabiskan dua minggu hanya untuk mempelajari data penjualan yang sudah mereka miliki di sistem POS, tapi belum pernah benar-benar dianalisis sebagai satu kesatuan.
- Stockout mengelompok pada produk yang sama setiap bulan. SKU tertentu konsisten habis pada tanggal 20 di setiap cabang, artinya sepuluh hari kehilangan penjualan pada produk terbaik mereka, setiap bulan, selama bertahun-tahun.
- Dead stock mengelompok di cabang tertentu, bukan di seluruh perusahaan. Produk yang laris di satu cabang justru tidak tersentuh di cabang lain dengan demografi pelanggan yang berbeda, padahal kantor pusat memesan bauran produk yang sama untuk semua toko.
- Lonjakan musiman baru terlihat setelah terjadi. Ramadan, musim kembali sekolah, akhir tahun, masing-masing memicu lonjakan permintaan yang selalu mengejutkan tim pemesanan setiap tahun, padahal polanya sama persis dengan tahun sebelumnya.
Akar masalahnya bukan kekurangan data. Mereka punya lebih dari dua tahun histori transaksi harian tersimpan di ekspor POS, tidak pernah disentuh. Akar masalahnya adalah tidak ada yang punya waktu untuk mengubah histori itu menjadi forecast, sehingga pemesanan kembali mengandalkan ingatan dan feeling.
Mulai sederhana: moving average mengalahkan feeling
Sebelum merekomendasikan apa pun yang menyerempet machine learning, kami membangun model paling sederhana yang bisa berfungsi: weighted moving average per SKU per cabang, dengan penyesuaian musiman di atasnya untuk periode lonjakan yang sudah diketahui. Ini bukan hal eksotis. Ini jenis forecasting yang sudah ada di buku teks supply chain selama beberapa dekade. Insight-nya bukan pada matematikanya, melainkan pada penerapannya secara konsisten, per toko, bukan mengandalkan ingatan satu orang tentang apa yang laku terakhir kali.
Model ini mengambil data penjualan dua belas minggu terakhir tiap SKU di cabang tertentu, memberi bobot lebih besar pada minggu-minggu terbaru dibanding yang lebih lama, lalu menghasilkan kuantitas reorder yang disarankan. Untuk periode musiman yang sudah diketahui, kami menerapkan pengali berdasarkan periode yang sama di tahun sebelumnya.
Itu saja seluruh model untuk fase pertama. Tanpa neural network, tanpa platform vendor, hanya logika spreadsheet terstruktur yang berjalan di atas ekspor POS mereka yang sudah ada, diperbarui setiap minggu.
Hasil setelah dua siklus pemesanan
| Metrik | Sebelum | Setelah 2 siklus |
|---|---|---|
| Hari stockout per bulan (20 SKU teratas, rata-rata semua cabang) | 8-10 hari | 2-3 hari |
| Write-down dead stock per kuartal | Berulang, signifikan | Berkurang kira-kira separuh |
| Waktu pemesanan manual per cabang per minggu | 3-4 jam | Di bawah 1 jam |
Pengurangan stockout saja sudah menutup biaya seluruh proyek dalam dua bulan pertama, karena itulah produk dengan margin tertinggi dan perputaran tercepat mereka. Pengurangan dead stock butuh waktu lebih lama untuk terlihat hasilnya, tapi dampaknya lebih struktural, karena membebaskan ruang rak dan modal yang selama ini tertahan diam-diam di produk yang tidak diminati di cabang tertentu.
Di mana machine learning masuk, dan di mana ia tidak diperlukan
Setelah model moving-average terbukti selama dua kuartal, kami memperkenalkan model yang sedikit lebih canggih untuk sebagian SKU bernilai tinggi, yang memperhitungkan pola permintaan lintas cabang dan elastisitas harga saat promosi. Di titik inilah wajar kalau ini disebut machine learning, meski tetap model yang sederhana dan bisa dijelaskan, bukan black box. Poin urutan yang penting: ini baru masuk akal setelah model sederhana sudah menyelesaikan sebagian besar masalah. Langsung loncat ke model kompleks di hari pertama akan lebih lama dibangun, lebih sulit dipercaya, dan hanya akan menyelesaikan stockout yang sama yang sudah diselesaikan gratis oleh moving average.
Ini mencerminkan apa yang biasanya berlaku juga dalam keputusan memilih sistem POS: tingkat kecanggihan seharusnya mengikuti kebutuhan yang sudah terbukti, bukan mendahuluinya.
Yang nyaris salah jalan
Rollout ini tidak berjalan mulus tanpa gesekan. Manajer cabang awalnya kurang percaya pada kuantitas pesanan yang disarankan sistem, karena bertentangan dengan insting mereka sendiri pada beberapa SKU di siklus pertama. Alih-alih memaksakan adopsi, kami menjalankan model secara paralel dengan pemesanan manual pada siklus pertama, membandingkan kuantitas yang disarankan dengan yang benar-benar dipesan manajer, lalu meninjau selisihnya bersama-sama setelahnya. Pada sebagian besar kasus, saran model terbukti lebih akurat dibanding penjualan aktual, yang membangun kepercayaan lebih cepat daripada argumen metodologi apa pun. Periode parallel-run itu, yang sering dilewati oleh tim yang buru-buru ingin menyatakan sistem sudah live, biasanya menjadi pembeda antara alat forecasting yang benar-benar terpakai dan yang diam-diam diabaikan setelah bulan kedua.
Pelajaran untuk peritel multi-cabang mana pun
Jika stockout dan dead stock Anda mengikuti pola yang bisa diprediksi dan berulang, dan kebanyakan memang begitu, Anda tidak butuh kecerdasan buatan untuk memperbaikinya. Anda butuh seseorang yang benar-benar mau melihat histori transaksi yang sudah Anda miliki, membangun model forecast yang cukup sederhana untuk dipahami dan dipercaya tim Anda, lalu menjalankannya secara konsisten setiap siklus pemesanan alih-alih mengandalkan ingatan. Mulai dengan model paling sederhana yang menjawab pola aktual Anda, buktikan selama dua atau tiga siklus, dan baru tambahkan kompleksitas setelah dasarnya benar-benar solid. Jaringan retail dalam studi kasus ini tidak butuh software yang lebih baik, melainkan disiplin yang lebih baik dalam memanfaatkan data yang sudah dikumpulkan software mereka sendiri.