Sinkronisasi Stok antara Toko Fisik, Marketplace, dan Gudang

Satu pesanan yang dibatalkan karena barang ternyata habis merugikan Anda dua kali. Pertama, omzet transaksi itu hilang. Kedua, dan ini yang lebih mahal, marketplace mencatat pembatalan itu sebagai kesalahan penjual, lalu menurunkan peringkat toko Anda di pencarian. Kerugian yang kedua terus berjalan berminggu-minggu setelah pesanannya sendiri dilupakan.

Anehnya, hampir semua toko yang mengalami ini punya catatan stok. Masalahnya bukan tidak mencatat, tapi mencatat di beberapa tempat sekaligus tanpa ada yang menjadi rujukan utama.

Kenapa oversell terjadi walau stok tercatat

Bayangkan satu SKU yang sama tercatat di empat tempat: kasir toko, dua lapak marketplace, dan kartu stok gudang. Empat tempat itu tidak pernah salah masing-masing. Yang salah adalah asumsi bahwa keempatnya bicara tentang barang yang sama pada waktu yang sama.

Pola kejadiannya biasanya begini:

Penjualan offline tidak mengurangi stok online. Pembeli di toko mengambil unit terakhir jam 14.00. Lapak marketplace masih menampilkan angka 1 sampai admin sempat mengubahnya malam hari. Delapan jam itu adalah jendela oversell.
Stok dialokasikan per kanal. Untuk menghindari bentrok, banyak toko membagi stok: 5 untuk marketplace A, 5 untuk B, 5 untuk toko. Akibatnya, saat A kehabisan jatah, barangnya sebenarnya masih ada di rak, tapi pembeli melihat "stok habis". Ini bukan oversell, ini kehilangan penjualan diam-diam.
Barang sudah dibayar tapi belum dipetik. Antara pesanan masuk dan barang keluar dari gudang, ada rentang waktu di mana unit itu secara fisik masih ada tapi sudah tidak boleh dijual. Kalau sistem hanya mengurangi stok saat barang keluar, rentang itu jadi lubang.
Retur yang belum diperiksa langsung dimasukkan kembali. Barang kembali ke angka stok padahal kondisinya belum tentu layak jual.
Update manual yang tertunda. Admin mengunggah file stok dua kali sehari. Semua kejadian di antaranya tidak terlihat oleh sistem mana pun.

Semua pola di atas berakar pada satu hal yang sama: tidak ada satu tempat yang berhak menyatakan berapa jumlah stok sebenarnya.

Sumber kebenaran tunggal untuk stok

Prinsipnya sederhana walau penerapannya butuh disiplin: satu sistem memegang angka stok, sisanya hanya menampilkannya. Semua perubahan, dari mana pun asalnya, masuk ke sistem itu lebih dulu, lalu disebarkan keluar.

Apa yang harus dipegang sistem pusat

Bukan cuma angka. Yang membuat sinkronisasi bisa dipercaya adalah tiga jenis angka yang dibedakan:

Stok fisik. Jumlah unit yang benar-benar ada di rak atau gudang.
Stok terikat. Unit yang sudah ada pesanannya tapi belum keluar. Masih terhitung fisik, tapi tidak boleh dijual lagi.
Stok tersedia. Fisik dikurangi terikat. Angka inilah yang dikirim ke semua kanal.

Begitu tiga angka ini dibedakan, alokasi per kanal tidak diperlukan lagi. Semua kanal melihat angka tersedia yang sama, dan yang pertama memesan mengikat unitnya. Ini menyelesaikan oversell dan kehilangan penjualan sekaligus, karena tidak ada stok yang menganggur di jatah kanal yang sepi.

Sistem mana yang layak jadi pusat

Pertanyaan berikutnya biasanya: sistem yang mana? Jawabannya bukan yang paling mahal, melainkan yang memenuhi tiga syarat sederhana. Ia harus mencatat setiap pergerakan barang sebagai kejadian bertanggal, bukan hanya menyimpan angka terakhir. Ia harus bisa dibaca dan ditulis oleh program lain, bukan hanya oleh manusia lewat layar. Dan ia harus dimiliki oleh Anda, bukan oleh satu marketplace tertentu.

Syarat ketiga sering diabaikan dan mahal akibatnya. Menjadikan salah satu marketplace sebagai pusat terasa hemat di awal, tapi mengunci Anda pada aturan mainnya, dan membuat kanal lain selalu jadi warga kelas dua. Kalau Anda berencana menambah kanal, pusat harus netral.

Untuk banyak toko, sistem kasir atau sistem stok yang sudah dipakai sehari-hari sudah bisa jadi pusat, asalkan ia mampu mengeluarkan datanya secara terprogram. Kalau tidak mampu, itu batasan yang menentukan dan perlu diselesaikan lebih dulu sebelum membicarakan integrasi apa pun.

Pemetaan SKU yang sering diremehkan

Sebelum sinkronisasi apa pun bisa jalan, satu produk harus punya satu kode di semua tempat. Kenyataannya, produk yang sama sering punya nama berbeda per kanal, dan varian sering tidak dipecah sampai level yang benar. Sepatu ukuran 42 warna hitam adalah SKU tersendiri, bukan catatan tambahan di kolom deskripsi.

Pekerjaan pemetaan ini membosankan dan biasanya makan waktu lebih lama daripada koding integrasinya. Kami sarankan menyelesaikannya lebih dulu di spreadsheet, sebelum vendor mana pun mulai bekerja. Kalau ini belum beres, integrasi secanggih apa pun akan menyinkronkan angka ke produk yang salah.

Jeda sinkronisasi yang bisa diterima

Sinkronisasi tidak pernah benar-benar seketika. Yang perlu Anda tentukan adalah berapa jeda yang masih aman untuk bisnis Anda, karena jeda yang lebih pendek berarti biaya dan kerumitan yang lebih tinggi.

Faktor penentunya bukan selera, melainkan hubungan antara kecepatan penjualan dan sisa stok. Kalau sebuah SKU terjual satu unit setiap tiga jam, jeda lima belas menit tidak berbahaya. Kalau SKU lain terjual sepuluh unit dalam satu jam saat promo, jeda lima menit pun bisa kebobolan.

Isi kerangka berikut dengan data toko Anda sendiri untuk menentukan target jeda per kelompok produk:

Kelompok produk	Unit terjual per jam saat puncak	Sisa stok tipikal	Jeda aman (menit)
Produk cepat laku	isi	isi	isi
Produk normal	isi	isi	isi
Produk lambat	isi	isi	isi

Cara membacanya: kalau sisa stok tipikal Anda 3 unit dan puncaknya 6 unit per jam, artinya stok bisa habis dalam 30 menit. Jeda sinkronisasi harus jauh di bawah itu, dan Anda perlu ambang aman yang menghentikan penjualan sebelum menyentuh nol.

Ambang aman sebagai pengaman kedua

Cara paling murah menekan risiko tanpa mempercepat sinkronisasi adalah menyisakan buffer. Untuk produk cepat laku, kirim ke marketplace angka tersedia dikurangi satu atau dua unit. Anda kehilangan sedikit peluang jual, tapi menghindari pembatalan yang merusak peringkat. Buffer ini hanya masuk akal untuk produk yang perputarannya tinggi, bukan untuk semua SKU.

Penanganan retur dan barang rusak

Retur adalah tempat di mana angka stok paling sering rusak diam-diam, karena barangnya masuk kembali secara fisik sebelum statusnya jelas.

Perlakukan barang retur sebagai lokasi tersendiri, bukan sebagai penambahan stok. Alurnya: barang masuk ke lokasi "karantina retur", diperiksa, lalu dipindahkan ke salah satu dari tiga tujuan — kembali ke stok jual, masuk ke stok cacat dengan harga berbeda, atau dihapus sebagai kerugian. Selama masih di karantina, ia tidak muncul di angka tersedia mana pun.

Hal yang sama berlaku untuk barang rusak di gudang. Yang penting bukan sekadar mengurangi angka, tapi mencatat alasan penguranganya. Tanpa alasan, selisih stok opname jadi misteri yang tidak bisa diperbaiki. Dengan alasan, Anda bisa melihat bahwa kerugian terbesar datang dari kemasan yang penyok saat pengiriman, dan itu masalah yang bisa dibereskan.

Barang pindah antar lokasi juga perlu dicatat

Kalau Anda punya gudang terpisah dari toko, perpindahan barang di antara keduanya adalah sumber selisih yang sering luput. Barang dikirim hari Senin, sampai hari Rabu, dan selama dua hari itu ia tidak ada di kedua tempat menurut catatan, padahal secara fisik ada di jalan.

Perlakukan pengiriman internal seperti pesanan: barang keluar dari lokasi asal dan masuk ke status transit, lalu dikonfirmasi diterima di lokasi tujuan. Konfirmasi penerimaan itu yang penting, karena di situlah selisih ketahuan lebih awal, bukan tiga bulan kemudian saat opname.

Stok opname tetap diperlukan

Sistem sebagus apa pun tidak menghilangkan kebutuhan menghitung fisik. Yang berubah adalah frekuensinya: dari opname total yang menutup toko sehari, menjadi opname berputar untuk sebagian SKU tiap minggu. Selisih yang ditemukan bukan aib, melainkan data untuk menemukan lubang di proses.

Perkiraan biaya integrasi

Kami tidak memasang angka di sini karena biaya integrasi berbeda jauh tergantung berapa kanal, apakah marketplace-nya menyediakan API resmi, dan seberapa berantakan data awalnya. Yang bisa kami berikan adalah daftar komponen biaya supaya penawaran yang Anda terima bisa dibaca, bukan ditelan bulat-bulat.

Pembersihan dan pemetaan SKU. Sekali di awal, volumenya sebanding jumlah produk dan varian. Bisa Anda kerjakan sendiri untuk menekan biaya.
Sistem pusat stok. Kalau belum ada, ini bagian terbesar. Kalau sudah punya sistem kasir yang layak, biayanya turun drastis.
Konektor per kanal. Dihitung per marketplace, bukan sekaligus. Menambah kanal ketiga nanti lebih murah daripada dua yang pertama.
Penanganan kegagalan. Antrean ulang saat API marketplace sedang bermasalah, dan notifikasi kalau sinkronisasi berhenti. Sering dipotong dari penawaran untuk menurunkan harga, lalu jadi sumber masalah utama.
Biaya berjalan. Server, pemantauan, dan penyesuaian saat marketplace mengubah API-nya. Ini pasti terjadi, jadi tanyakan sejak awal siapa yang menanggungnya.

Kapan integrasi belum sepadan

Kalau Anda menjual di satu kanal saja, atau jumlah SKU aktif Anda di bawah lima puluh dengan perputaran lambat, satu orang admin dengan proses yang disiplin akan lebih murah dan lebih fleksibel. Begitu juga kalau produk Anda dibuat sesuai pesanan, karena konsep stok tersedia tidak berlaku.

Batas praktisnya biasanya muncul saat Anda mulai menghitung jam yang habis untuk menyamakan angka secara manual, atau saat pembatalan mulai memengaruhi peringkat lapak. Sebelum titik itu, uangnya lebih baik dipakai untuk hal lain.

Clovertechno membangun sistem operasional untuk ritel dan F&B, termasuk produk kami sendiri, Coffee Shop Management System, yang menangani stok bahan dan penjualan dalam satu tempat. Selengkapnya ada di halaman pembuatan aplikasi dan katalog produk. Kalau Anda ingin membahas kondisi toko Anda sebelum memutuskan, mulai dari halaman kontak.