Aplikasi Saran Pemesanan Ulang Inventaris: Min/Max ke Draft Pesanan

Masalah yang diselesaikan aplikasi ini (dan yang tidak diselesaikan)

Menjalankan toko biasanya berarti berayun antara dua kesalahan mahal: kehabisan barang yang laris (penjualan hilang, pelanggan frustrasi) atau membeli terlalu banyak (uang terikat di stok yang lambat). Masalah harian bukanlah “apakah kita punya stok?” Melainkan “apa yang seharusnya kita beli berikutnya, dan berapa banyak?”, tanpa menghabiskan satu jam melakukan perhitungan di spreadsheet.

Pengaturan min/max membuat keputusan itu sederhana. Untuk setiap SKU, Anda menyimpan dua angka:

• Min: level terendah yang ingin Anda capai sebelum memesan ulang.
• Max: level yang ingin Anda isi kembali ketika Anda memesan.

Jika sebuah SKU berada di 6 unit, min adalah 10, dan max adalah 25, saran adalah memesan 19. Anda tidak menebak dari ingatan. Anda menggunakan aturan yang jelas yang tetap konsisten minggu ke minggu.

Aplikasi saran pemesanan ulang inventaris mengambil jumlah on-hand saat ini (dan opsional apa yang sudah dipesan), menerapkan aturan min/max per SKU, dan menghasilkan draf daftar pembelian. Draf itu adalah keluaran utama: daftar singkat yang dapat ditinjau yang menjawab “apa yang sebaiknya kita pesan dan berapa banyak?” sebelum seseorang membuka portal pemasok atau mengirim email ke perwakilan.

Yang tidak dilakukan aplikasi ini adalah melakukan pembelian otomatis. Itu penting karena pembelian nyata punya pengecualian: pemasok kehabisan stok, ukuran kemasan memaksa pembulatan, item musiman harus dilewatkan, atau promosi akan datang. Aplikasi harus menghasilkan saran dengan cepat, lalu membiarkan manusia menyetujui, mengedit, atau menghapus baris.

Alat semacam ini biasanya digunakan oleh manajer toko, pemimpin operasi, dan staf pembelian. Ini juga berguna untuk tim kecil di mana satu orang mengerjakan banyak peran dan hanya membutuhkan titik awal yang dapat diandalkan.

Data yang perlu Anda simpan per SKU

Saran yang baik dimulai dengan data SKU yang membosankan tapi konsisten. Jika dasar-dasarnya berantakan, draf daftar pembelian Anda akan terasa acak, dan orang akan berhenti mempercayainya.

Usahakan rekaman SKU yang menjaga “bentuk” yang sama dari waktu ke waktu, bahkan jika proses Anda berkembang.

Field inti SKU (minimum yang berfungsi)

Agar bisa digunakan sejak hari pertama, Anda perlu:

• Identifier SKU (kode yang Anda scan atau ketik) dan nama singkat yang dikenali orang
• Unit ukuran (each, botol, kotak, kg) sehingga hitungan dan pesanan berarti sama
• Status (aktif/nonaktif) supaya item yang dihentikan tidak terus muncul
• Level Min dan Max (dan opsional titik pemesanan terpisah)
• Catatan plus info “terakhir diperbarui” (timestamp dan/atau siapa yang mengubah)

Min dan max adalah pembatas. Titik pemesanan terpisah bersifat opsional, tapi membantu ketika Anda ingin memesan lebih awal dari min karena lead time yang lama atau pasokan yang tidak dapat diandalkan.

Ketersediaan dan detail pemesanan (yang membuat perhitungan realistis)

Detail ini mengubah “berapa yang harus dibeli” menjadi “apa yang sebenarnya bisa Anda pesan”:

• Kuantitas on-hand, dengan sumber yang jelas (hitung manual sekarang, sinkronisasi mungkin nanti)
• Pemasok pilihan (atau vendor utama)
• Ukuran kemasan (jumlah per case) sehingga Anda memesan dalam kelipatan yang valid
• Lead time (hari)
• Minimum order quantity (MOQ)

Jelaskan dari mana “on hand” berasal. Jika Anda mulai dengan entri manual, simpan tanggal hitungan terakhir. Jika nanti Anda sinkron dari POS atau alat gudang, simpan waktu sinkron terakhir juga. Detail kecil ini menjawab banyak pertanyaan “kenapa ini disarankan?”

Cara perhitungan saran min/max

Min/max adalah aturan sederhana: Anda hanya memesan ulang ketika stok rendah, dan Anda memesan cukup untuk kembali ke level aman. Hasilnya adalah daftar draf yang mudah dimengerti dan mudah diaudit.

1) Kapan memicu pemesanan ulang?

Pilih satu pemicu dan pertahankan konsistensi. Yang paling umum adalah:

• Jika On Hand berada pada atau di bawah Min (kadang disebut titik pemesanan), item tersebut memenuhi syarat.
• Jika On Hand di atas Min, saran adalah nol dan item tetap tidak muncul di draf.

Ini menghindari rekomendasi berisik untuk item yang sudah sehat.

2) Berapa banyak yang disarankan untuk dipesan?

Setelah item memenuhi syarat, ide dasar adalah “pesan hingga Max.” Rumus sederhana adalah:

base_suggested = max - on_hand
suggested = max(0, base_suggested)

Contoh: Min = 10, Max = 40, On Hand = 14.

• On Hand (14) di atas Min (10), jadi suggested = 0.

Jika On Hand turun menjadi 8:

• base_suggested = 40 - 8 = 32
• suggested = 32

Penyesuaian sederhana yang membuat draf lebih realistis

Setelah perhitungan dasar, tambahkan beberapa aturan kecil untuk mencocokkan bagaimana pembelian bekerja di dunia nyata:

• Pembulatan case pack: jika Anda harus membeli pack 12, bulatkan 32 menjadi 36.
• MOQ: jika MOQ adalah 50, naikan 36 menjadi 50.
• Jangan pernah menyarankan angka negatif: jika On Hand 55 dan Max 40, base-nya -15, tapi suggested harus 0.
• Batas opsional: jika Anda ingin menghindari pembelian besar, batasi jumlah pesanan maksimum.

Kasus tepi yang harus ditangani sejak awal

Data buruk menghasilkan saran buruk, jadi buat situasi ini jelas:

• SKU yang dihentikan: selalu sarankan 0, meskipun stok rendah.
• Inventaris negatif: anggap sebagai bendera merah; tetap hitung, tapi tunjukkan peringatan untuk ditinjau.
• Min/Max hilang: jangan menebak. Setel suggested ke 0 dan tandai SKU sebagai “perlu setup.”

Alur pengguna: dari hitungan inventaris ke draf daftar pembelian

Alur terbaik adalah yang tim Anda benar-benar pakai. Buat sederhana: catat apa yang Anda punya, lalu hasilkan saran. Fitur tambahan (label, dashboard, analitik) bisa ditambahkan kemudian.

Sesi tipikal seperti ini: pengguna melakukan hitungan cepat, memilih lokasi (jika perlu), memasukkan hitungan per SKU, menyimpan, lalu menekan satu tombol untuk membuat draf daftar pembelian. Pembeli meninjau draf itu dan menyesuaikannya sebelum apa pun disetujui.

Untuk menjaga layar tetap tenang, tambahkan satu filter praktis: tampilkan hanya SKU di bawah min, atau tampilkan semua SKU dengan status yang jelas. “Hanya di bawah min” lebih cepat di hari sibuk. “Tampilkan semua” membantu ketika Anda ingin memastikan tidak ada yang terlewat.

Alur sederhana yang bekerja untuk sebagian besar tim kecil:

• Masukkan atau impor hitungan on-hand
• Hasilkan saran
• Tinjau draf daftar (hanya yang di bawah min, atau semua dengan status)
• Edit kuantitas yang disarankan dan tambahkan catatan
• Setujui draf dan ekspor atau bagikan untuk pembelian

Override penting karena kenyataan berantakan. Pembeli mungkin memesan ekstra untuk promosi, atau kurang karena kas terbatas atau pemasok terlambat. Perlakukan jumlah yang disarankan sebagai titik awal, bukan aturan.

Beberapa kontrol kecil mencegah banyak frustrasi:

• Kuantitas override manual (plus siapa yang mengubah)
• Flag “Hold” untuk melewatkan pemesanan item untuk sementara
• Field alasan opsional (musiman, masalah vendor, clearance)

Akhirnya, simpan snapshot saat draf dihasilkan: timestamp, hitungan on-hand yang digunakan, nilai min/max saat itu, dan jumlah yang disarankan sebelum override. Ketika seseorang bertanya “Kenapa kita memesan 24 ini?”, Anda bisa membuka draf dan melihat input persis yang menghasilkan angka itu.

Struktur database sederhana yang tetap fleksibel

Aplikasi reorder yang baik dimulai dengan beberapa tabel kecil yang bisa diandalkan. Tujuannya bukan ERP yang sempurna. Ini adalah basis bersih yang bisa tumbuh ketika Anda menambahkan pemasok, lokasi, atau aturan yang lebih cerdas.

Tabel inti untuk memulai

Untuk satu toko, pisahkan “apa item itu” dari “apa yang Anda punya” dan “bagaimana Anda memesan ulang”:

• SKUs: satu baris per item (kode SKU, nama, unit, kategori, aktif/nonaktif)
• Suppliers: nama pemasok dan detail kontak (dan syarat seperti lead time jika Anda melacaknya)
• Reorder settings: min, max, titik pemesanan per SKU, pemasok pilihan, ukuran kemasan
• Inventory levels: on-hand saat ini per SKU (kelak, per lokasi) plus tanggal hitung terakhir
• Draft orders: header (pemasok, status, dibuat oleh) dan baris (SKU, qty yang disarankan, qty final)

Ini tetap fleksibel karena Anda bisa mengubah aturan reorder tanpa menulis ulang daftar SKU, dan Anda bisa menyimpan draf pesanan sebagai catatan apa yang disarankan versus apa yang disetujui.

Jika Anda hanya punya satu toko hari ini, jangan buat lokasi berlebihan. Simpan inventaris sebagai satu angka per SKU. Ketika Anda menambahkan toko kedua atau gudang, perkenalkan tabel Locations dan ubah Inventory levels menjadi satu baris per SKU per lokasi.

Pembatas, peran, dan ekspor

Aturan validasi kecil mencegah input buruk berubah menjadi pesanan buruk. Tambahkan pengecekan seperti: min harus lebih kecil dari max, titik pemesanan tidak boleh negatif, dan ukuran kemasan tidak boleh nol. Putuskan apa yang terjadi ketika pengaturan hilang: blokir saran, atau tandai SKU sebagai “perlu setup.”

Peran membantu ketika banyak orang menghitung stok dan mengubah aturan:

• Viewer: bisa melihat SKU dan draf pesanan
• Editor: bisa memperbarui hitungan dan pengaturan reorder
• Approver: bisa memfinalisasi kuantitas dan menandai draf pesanan sebagai disetujui

Rencanakan bagaimana Anda akan mengirim pesanan. Meski nanti Anda otomatisasi pembelian, kebanyakan tim memulai dengan ekspor sederhana: unduhan CSV atau daftar siap pemasok yang bisa disalin dari layar draf pesanan.

Langkah demi langkah: membangun layar aplikasi dan logika

Mulai dengan dua daftar sederhana: katalog SKU dan pemasok Anda. Setiap SKU harus punya nama yang dikenali orang, pemasok default, dan unit pembelian (each, case, carton). Jaga agar praktis. Ini adalah daftar yang tim Anda akan cari setiap hari.

Selanjutnya, tambahkan pengaturan reorder ke rekaman SKU. Min dan max adalah dasar, tetapi Anda akan mendapatkan saran lebih baik jika juga menyimpan ukuran kemasan dan lead time. Jika Anda membeli item yang sama dari dua pemasok, pilih salah satu sebagai default dan izinkan perubahan di draf pesanan nanti.

Untuk hitungan inventaris, bangun layar cepat yang mengutamakan kecepatan daripada kesempurnaan. Grid edit cepat bekerja baik: filter berdasarkan lorong atau kategori, ketik kuantitas yang dihitung, dan simpan.

Sebagian besar tim membutuhkan layar inti ini:

• Daftar SKU dan detail SKU (termasuk min, max, ukuran kemasan, lead time)
• Daftar pemasok dan detail pemasok
• Entri hitungan inventaris (grid + filter)
• Saran reorder (tabel hasil + aksi sederhana)
• Draf pesanan pembelian (baris yang bisa diedit + persetujuan)

Lalu terapkan logika saran: untuk setiap SKU, bandingkan “on hand” (dan opsional “on order”) ke aturan reorder Anda, hitung jumlah yang disarankan untuk kembali ke max, dan terapkan pembulatan ukuran kemasan agar Anda tidak menyarankan 13 unit ketika pemasok hanya menjual case berisi 12.

Hasilkan draf pesanan untuk ditinjau dan perlakukan seperti dokumen dengan status seperti Draft, Approved, Sent. Saat pengguna membuat draf, salin baris saran ke baris pesanan yang dikelompokkan berdasarkan pemasok, lalu biarkan orang mengedit kuantitas, mengganti pemasok, atau menghapus item.

Selesaikan dengan langkah output yang rapi. Beberapa tim mencetak draf dan melakukan pemesanan secara manual. Yang lain mengekspor file. Bagaimanapun juga, simpan apa yang disetujui sehingga Anda bisa membandingkan “disarankan vs dipesan” nanti dan memperbaiki aturan berdasarkan bukti nyata.

Kesalahan umum yang membuat saran reorder tidak dapat dipercaya

Matematika reorder sederhana. Yang merusak kepercayaan adalah setup yang berantakan. Sebagian besar masalah muncul sebagai draf yang terasa “salah,” bahkan ketika rumusnya benar.

Masalah klasik adalah unit campuran. Anda menghitung “each,” tapi memesan dalam “case,” atau menerima dalam “pack.” Jika unit SKU tidak jelas, aplikasi mungkin menyarankan 24 ketika yang Anda maksud adalah 24 case. Pilih satu unit dasar per SKU (seringnya “each”) dan simpan konversi seperti “1 case = 24 each” sehingga kuantitas pesanan akhir diterjemahkan dengan benar.

Min dan max juga sering diset seperti tebakan. Jika Anda mengabaikan kecepatan penjualan dan lead time pemasok, aturan terlihat rapi tapi gagal di lapangan. Item yang lambat dengan max tinggi mengikat uang, sementara item yang laris dengan min rendah menyebabkan kehabisan stok.

Kesalahan umum lain:

• Tidak melacak lokasi (back room vs shelf, toko A vs toko B), lalu bertanya-tanya kenapa on-hand tidak pernah cocok
• Membiarkan siapa saja mengedit min/max tanpa proses persetujuan dasar
• Menimpa nilai masa lalu sehingga Anda tidak bisa menjelaskan pesanan minggu lalu
• Menganggap stok rusak, disisihkan, atau sedang transit sebagai tersedia
• Menggunakan hitungan yang sudah beberapa hari, lalu menyalahkan saran

Skenario sederhana: Anda menjual kapsul kopi. Rak menunjukkan 6 kotak, back room ada 18, dan toko kedua punya 12. Jika Anda hanya melacak satu angka “on hand,” seseorang menghitung 6 dan sistem menyarankan pemesanan, padahal sebenarnya Anda punya 36. Field lokasi memperbaiki ini dengan cepat.

Pengecekan cepat sebelum Anda percaya daftar draf

Sistem min/max sederhana, tapi daftar draf hanya sebaik data yang mendasarinya. Sebelum Anda mengirim apa pun ke pemasok, luangkan waktu sebentar untuk memindai kesalahan diam yang membuat saran terlihat yakin tapi salah.

Mulailah dengan setup: setiap SKU yang bisa di-reorder membutuhkan min, max, dan ukuran kemasan yang benar. Jika ada yang hilang, aplikasi harus menandai SKU dan melewatkannya atau menandainya sebagai “perlu setup.” Satu field kosong saja bisa diam-diam menghasilkan pesanan besar atau tidak ada pesanan sama sekali.

Selanjutnya, periksa wajar kuantitas on-hand. Stok negatif terjadi (retur diproses terlambat, penerimaan belum diposting, kebingungan unit), tetapi harus jarang. Jika Anda melihat -12 on hand untuk item lambat, perlakukan saran sebagai “perlu investigasi,” bukan “beli.” Hitung ulang atau tinjau transaksi lebih murah daripada membongkar kelebihan nantinya.

Checklist singkat yang menangkap sebagian besar masalah:

• Setup: min, max, ukuran kemasan, dan pemasok terisi untuk setiap SKU yang bisa direorder
• Kuantitas: on-hand terlihat masuk akal (tidak ada typo jelas seperti 500 bukannya 50)
• Pengemasan: saran dibulatkan ke case pack dan menghormati MOQ
• Kebijakan: semua orang tahu apakah Anda memesan hingga max atau ke target yang lebih aman
• Keterlacakan: edit menunjukkan siapa yang mengubah angka dan kapan

Aturan pengemasan pantas mendapat perhatian khusus. Jika pemasok menjual case 24 dan draf menyarankan 13, sistem Anda harus menyesuaikan berdasarkan kebijakan (seringnya membulatkan naik untuk menghindari kehabisan). Ide yang sama untuk MOQ: tunjukkan saran asli dan saran yang disesuaikan agar peninjau mengerti apa yang berubah.

Juga tentukan apa arti “cukup baik” untuk tim Anda. Memesan hingga max agresif dan bisa mengikat uang. Target yang lebih konservatif (mis. pesan hingga max hanya untuk top movers, dan ke titik tengah untuk item yang lebih lambat) dapat mengurangi overstock sambil membangun kepercayaan.

Akhirnya, simpan jejak audit. Bahkan “Terakhir diubah oleh” dan “Terakhir diubah pada” sederhana di setiap baris membangun kepercayaan dan membantu menyelesaikan perselisihan kemudian.

Contoh: reorder mingguan untuk toko kecil

Bayangkan toko lingkungan kecil yang menjual 30 SKU. Pemilik melakukan hitungan fisik setiap Senin pagi dan ingin aplikasi saran pemesanan ulang inventaris menghasilkan draf daftar pembelian yang bisa mereka cek cepat.

Mereka membeli dari dua pemasok: Supplier A (snack dan minuman) dan Supplier B (kebutuhan rumah tangga).

Tiga SKU dan perhitungan saran

SKU 1: Sparkling Water 12-pack (Supplier A)

On hand: 8 pack. Min: 10. Max: 30. Pack size: 6.

Karena 8 di bawah min (10), aplikasi menyarankan memesan hingga max.

Dibutuhkan untuk mencapai max = 30 - 8 = 22 pack.

Bulatkan ke ukuran pack (6): 22 menjadi 24.

Saran pesanan: 24 pack.

SKU 2: Potato Chips (Supplier A)

On hand: 14 kantong. Min: 12. Max: 36. Pack size: 12.

Karena 14 di atas min, saran adalah 0. Meskipun belum mencapai max, stok masih sehat dan tidak perlu diisi minggu ini.

SKU 3: Dish Soap 500 ml (Supplier B)

On hand: 3 botol. Min: 6. Max: 18. Pack size: 6.

Karena 3 di bawah min, pesan hingga max.

Dibutuhkan untuk mencapai max = 18 - 3 = 15 botol.

Bulatkan ke ukuran pack (6): 15 menjadi 18.

Saran pesanan: 18 botol.

Penyesuaian pembeli (anggaran dan nalar umum)

Draf adalah titik awal, bukan komando. Minggu ini, pemilik memiliki anggaran lebih ketat dan juga tahu penjualan sparkling water melambat saat hujan.

Mereka mengubah Sparkling Water dari 24 pack menjadi 18 pack (masih kelipatan 6). Chips tetap 0. Dish soap tetap 18 karena laris dan terlihat berisiko.

Langkah tinjau-dan-ubah inilah yang membuat draf seringkali lebih berguna daripada mengirim PO otomatis.

Draf daftar pembelian bersih (dikelompokkan per pemasok)

Supplier A

• Sparkling Water 12-pack: 18 pack (diubah dari 24)
• Potato Chips: 0

Supplier B

• Dish Soap 500 ml: 18 botol

Dengan hanya 30 SKU, loop mingguan ini bisa memakan waktu sekitar 10 menit: hitung, tinjau saran, lakukan beberapa edit, lalu bagikan draf yang dikelompokkan ke setiap pemasok.

Langkah selanjutnya: luncurkan kecil, lalu perbaiki aturan

Cara tercepat mendapat nilai adalah memulai sempit. Pilih satu toko (atau satu lokasi) dan satu grup pemasok dengan jumlah SKU yang dapat diatur. Anda akan belajar lebih banyak dari draf yang bersih dan ditinjau daripada mencoba menutup semua kasus tepi di hari pertama.

Putuskan sejak awal bagaimana Anda akan menangkap hitungan on-hand. Entri manual baik pada awalnya, asalkan konsisten. Aturan sederhana seperti “hitungan diperbarui setiap Kamis sebelum pemesanan” lebih baik daripada setup kompleks yang tidak dipercaya siapa pun.

Rencana peluncuran praktis:

• Mulai dengan 20-50 SKU yang mudah dihitung dan penting untuk pendapatan
• Tinjau draf dengan manajer selama 2-3 siklus sebelum melakukan pemesanan dari situ
• Simpan field catatan singkat per SKU (mis. “musiman” atau “case pack 12”)
• Perluas ke pemasok berikutnya hanya setelah grup pertama terasa stabil

Setelah dasar bekerja, perbaiki matematika perlahan. Dua peningkatan yang biasanya cepat balik modal: estimasi permintaan rata-rata (mis. “rata-rata penjualan mingguan 4 minggu terakhir”) dan sedikit safety stock berdasarkan lead time. Jika pemasok butuh 10 hari, menaikkan titik pemesanan untuk menutup kelebihan permintaan satu minggu dapat membantu menghindari reaksi terhadap keterlambatan.

Tetapkan ritme untuk menjaga aturan tetap jujur. Mingguan, tinjau saran dan perbaiki kecerobohan jelas. Bulanan, tune nilai min/max, fokus pada top movers dan risiko overstock terbesar.

Jika Anda membangun ini sebagai aplikasi inventaris tanpa kode, AppMaster (appmaster.io) adalah salah satu opsi yang sesuai alur kerja: modelkan SKU dan pemasok di database, masukkan logika min/max ke dalam proses visual, dan hasilkan draf pesanan yang staf bisa tinjau dan setujui sebelum apa pun dikirim.