Pickup cell di lantai pertama rak.
Ambil salah satu faucet dapur di toko kami dan bawa ke bawah lengan Anda ke kasir. Di kasir, Anda diberi dokumen penjualan, dan saat ini jumlah produk ini di saldo di sistem dan di situs berkurang.
Pada malam hari, setiap toko menghitung perkiraan pesanan untuk periode berikutnya. Lebih tepatnya, ramalan untuk satu tahun ke depan dihitung setiap minggu, dan pesanan untuk manajer toko dihitung darinya setiap malam. Skrip melihat bahwa seseorang membeli mixer, dan jika penjualan berjalan dengan kecepatan seperti itu (ada seluruh blok model yang kompleks, apa yang dianggap "pada kecepatan seperti itu" dan pada periode apa), mixer akan habis dalam tujuh hari. Ini berarti Anda perlu membuat pesanan berikutnya untuk dikirimkan.
Sebagian besar barang masuk ke toko baik melalui cross-docking stream (gudang mentransfer palet tanpa membuka atau menyimpannya dalam stok), atau langsung dari pemasok lokal. Sebagian, kami telah menganalisis proses ini di posting terakhir . Pertimbangkan kasus yang sulit ketika sebuah toko membutuhkan mixer dari palet yang ada di gudang di Moskow.
Kesulitannya adalah mixer palet yang cukup banyak. Dan Anda perlu membawa 50 buah ke toko, katakanlah. Tidak bisa menerimanya sepenuhnya? Dan kemudian proses pengambilan muncul, ketika palet dikeluarkan dari sel, diletakkan, dan kemudian wadah bersarang dikeluarkan darinya. Ini bisa menjadi kotak transportasi, bagian dalam dan sepotong. Pusat distribusi hampir tidak pernah beroperasi dengan barang-barang, kecuali peralatan langka dan mahal. Untuk unit, pusat pemenuhan diperlukan, tetapi ini adalah bagian logistik yang sedikit berbeda, dan pos ini tidak akan membahasnya.
Pada akhirnya, ketika sebuah toko membutuhkan produk, kebutuhan tersebut dipertimbangkan dalam sistem peramalan GOLD GWR, dan dalam ERP (Oracle RMS), dokumen akhir muncul dengan berapa banyak dari apa yang perlu dibawa dan di mana. Ini memasuki Sistem Manajemen Gudang (WMS) dalam bentuk tugas "Kirim ke sana" dan dalam Sistem Manajemen Transportasi (TMS) dalam bentuk arahan "Ambil di gudang fulan dan bawa ke toko fulan". Selanjutnya, tugas TMS adalah menyediakan transportasi (untuk ini, aplikasi dikirim ke logistik), dan tugas WMS adalah memastikan dimulainya pemuatan pada saat dermaga terbuka untuk truk yang datang.
Barang dapat dikirim sebagai palet utuh atau di unit penyimpanan bersarang. Yang paling nyaman untuk gudang, tentu saja, memuat keseluruhan. Karena ketika unit penyimpanan bersarang (kotak) dibutuhkan, dibutuhkan waktu dan langkah manual. Artinya, membutuhkan sejumlah uang dan mengurangi perputaran barang (tidak memungkinkan gudang digunakan untuk sesuatu yang lain).
Sangat tepat untuk membandingkan gudang dengan database. Dia harus menanggapi secepat mungkin aplikasi yang menariknya. Bagian dari itu dalam memori adalah proses cross-docking yang tidak membutuhkan "penulisan" ke stok sama sekali. Bagian lainnya adalah cache: ini adalah buffer khusus di mana produk dapat berbaring beberapa saat sebelum operasi berikutnya. Dan bagian lainnya adalah tempat penyimpanan, tempat penyimpanan barang untuk diproses lebih lanjut.
Tugas gudang selalu mengurangi stok dan meningkatkan omsetnya (yaitu, mengurangi umur simpannya). Semakin sedikit barang yang menganggur, semakin menguntungkan bagi perusahaan. Tetapi pada saat yang sama, ketika seseorang meminta produk yang diinginkan, tetapi gudang tidak dapat menyediakannya, ini juga merupakan kegagalan. Semua matematika bekerja di antara dua ekstrem ini.
Jadi ada apa dengan mixer saya?
Proses ideal dari sudut pandang optimasi aliran adalah dengan menggunakan gudang hanya sebagai router. Proses ideal dalam hal ketersediaan adalah menyimpan semua barang dunia dalam persediaan dan mengeluarkannya sesuai kebutuhan.
Pada akhirnya, kompromi untuk mixer terlihat seperti ini: ada matematis optimal tentang cara memindahkannya. Terkadang menguntungkan untuk tidak membeli model khusus ini sama sekali (karena ada analog langsung), terkadang sangat menguntungkan untuk membeli dan membawa seluruh palet dan perlahan-lahan menjualnya dari gudang toko. Tetapi paling sering menguntungkan untuk membawa kotak transportasi. Jika ada 52 unit di dalam kotak, dan sistem penyimpanan menghitung bahwa 50 diperlukan, maka keputusannya jelas: sedikit lebih banyak akan dipesan - 52. Tetapi jika toko membutuhkan tiga unit, dan kotak - 100 unit, maka pertanyaan tentang kemanfaatan minimum muncul.
Kami tidak menggunakan algoritme minimax untuk toko, tetapi sekarang kami sedang mengembangkannya dan akan menggunakannya terutama untuk format kecil, karena sangat cocok jika tidak ada atau sedikit ruang di gudang toko dan Anda perlu segera mengisi kembali rak. Untuk format kecil akan ada: maksimum - kapasitas rak, minimum - jumlah "pemicu" untuk pesanan, jika stok turun ke nilai yang lebih rendah atau sama - kami membuat pesanan ke rak maksimum.
Pembentukan permintaan kami bekerja berdasarkan prinsip cakupan pesanan dan setiap pesanan ditutupi dengan stok hingga tanggal pengiriman pesanan berikutnya.
Misalnya, kami melakukan pemesanan hari ini, 01/01/2021, dan kami memiliki 18 buah tersisa. Tanggal pengiriman pesanan seperti itu adalah 01/07/2021 (pemasok membawa satu minggu sebelumnya). Tanggal pemesanan berikutnya adalah 14/01/2021, pengiriman 01/21/2021.
Katakanlah kita selalu menjual dua buah sehari.
Ini berarti bahwa kami harus menutup pesanan pada 01/01/2021 dengan stok sampai dengan 01/21/2021, jika tidak kami tidak akan memiliki apa-apa untuk dijual.
Oleh karena itu, sampai 21/1/2021 kita membutuhkan 21 * 2 = 42 buah.
Kami memiliki stok 18 buah, jadi kami memesan 24 buah pada 01/01/2021.
Tentunya, setiap order juga berisi bagian dari safety stock.
Selanjutnya data pesanan dimasukkan ke dalam wadah. Artinya, kalau butuh 45, 48 atau 49 buah, minimal pesan dus 50. Jika butuh 55 buah, pesan dua dus atau optimalkan modelnya. Seperti yang Anda lihat, semakin sedikit kuantisasi (semakin sering pengiriman dan unit bersarang yang lebih mudah dikelola dalam penampung), semakin akurat pengoptimalannya. Oleh karena itu, pengiriman ke toko dilakukan sesering mungkin, dan oleh karena itu subkotak muncul dalam kotak.
Bagaimana kotak itu bisa masuk ke dalam truk?
Jadi, tugas dari toko masuk ke ERP, dan dari sana ke gudang. Gudang harus menyediakan barang yang dikemas di dermaga saat mobil yang dipesan oleh sistem TMS tiba di sana dan membawanya ke toko.
Di gudang, semua pesanan dikelompokkan untuk kemudian mengoptimalkan rute tugas untuk setiap pemuat individu. Untuk setiap pemuat, rute dianggap di mana ia akan mengambil semua barang yang diperlukan paling cepat dan tidak akan mengganggu orang lain. Fungsinya adalah kebahagiaan umum, yaitu mengurangi total waktu eksekusi semua operasi secara umum.
Kemudian orang menerima koordinat target tertentu (palet dalam sel) dan tindakan dengannya dalam bentuk algoritme. Dan mereka memenuhinya. Ini dipecah menjadi langkah-langkah dalam semangat: "Pergi ke sel ini dan itu, ambil palet." Seseorang mengemudi, memindai kode batangnya di sana, sistem akan memeriksa bahwa semuanya sudah benar, dan memberikan tindakan berikut: "Lakukan di sana." Dan - sepanjang waktu. Kami mengoperasikan terminal seluler, dan penggerak mematuhinya. Jadi kami memiliki semacam API untuk orang-orang di gudang. Langkah selanjutnya, tentu saja, adalah mengeluarkan orang, tetapi tentang itu di lain waktu.
Saat palet perlu dibongkar, proses pengambilan terpisah dilakukan. Kami mengambilnya dari kompartemen penyimpanan di bagian atas dan menurunkannya ke kompartemen bawah. Dari sana kami mengambil dua kotak mixer, dari yang lain - tiga kotak barang lainnya (biar ada paku, menarik karena dikemas dalam jumlah besar) dan seterusnya. Semua ini dengan terminal dipindai dan diperiksa di setiap langkah. Alhasil, Anda tetap mendapatkan satu palet untuk dermaga, hanya dengan boks yang berbeda.
Jika sudah siap, label terpisah dicetak di atasnya di terminal, dan sekarang dihitung dalam sistem sebagai tempat terpisah. Bisa ditempatkan di buffer pengiriman atau langsung di dermaga.
Tempat pengambilan adalah penyangga, jadi setelah mengeluarkan barang dari palet pengambilan, sering kali palet asli perlu diangkat kembali. Karena di bagian bawah sel akan dibutuhkan sesuatu yang lain.
Orang yang meletakkan palet dari atas ke bawah dan orang yang mengambil kotak dari tempat pengambilan adalah dua orang yang berbeda. Pikeman baru saja mengambil barang, dan orang lain di forklift hanya menyulap palet.
Dari mana asal truk itu?
Dari alat TMS yang menggabungkan semua kebutuhan semua toko beberapa kali sehari dan memotong kebutuhan truk. Di sana, tidak hanya urutan setiap node dari grafik yang dipertimbangkan, tetapi juga rute optimal di sepanjang grafik dari transport yang berbeda. Toko tersebut memesan sekali seminggu, dan penjadwalan pengangkutan dimulai dua hari sebelum pengiriman. Dalam dua hari ini sudah jelas jenis transportasi apa yang akan datang ke dermaga, apa dan bagaimana cara memasukkannya ke dalamnya dan bagaimana perjalanannya. Otomatisasi ini berlaku untuk semuanya: ketika truk ini baru tiba di gudang, sistem akan mengetahui dari nomor gerbang mana yang harus dituju dan kapan, yaitu, kami juga mengelola optimalisasi lalu lintas di dermaga.
Dalam hal ini, kami tidak hanya memperhitungkan ketersediaan barang yang sebenarnya di gudang, tetapi juga barang yang hanya dikirim ke sana - ini juga merupakan bagian penting dari pengoptimalan.
Bagaimana diputuskan bahwa produk perlu diisi ulang untuk jumlah ini dan itu?
Pertama, kami melihat apakah produk ini masih akan dibeli. Untuk setiap toko ada matriks apa yang dijual dan apa yang tidak. Ini adalah kekhasan regional karena pemasok lokal, permintaan regional (peralatan profesional yang sangat mahal untuk perbaikan paling sering dibutuhkan hanya di Moskow), karakteristik budaya (di Kazakhstan, ada area karpet yang luas untuk dekorasi), dan sebagainya.
Produk mungkin berhenti dibeli di toko karena akhir musim: hanya sedikit orang yang membutuhkan mesin pemotong rumput di musim dingin dan dekorasi pohon Natal di musim panas.
Jika produk akan dibeli, kami menghitung berapa yang dibutuhkan untuk periode selanjutnya. Ini adalah model yang cukup menarik yang memperhitungkan sejarah penjualan suatu produk (ini adalah faktor pembobotan utama) dan mempertimbangkan profil musim dari keluarga tempat produk ini berada. Ketika sebuah produk memiliki sejarah penjualan yang panjang di toko ini dan toko lainnya, modelnya dibuat dengan mulus dan Anda bisa langsung mendapatkannya.
Saat item tersebut baru, tidak ada histori. Anda perlu mengambilnya dari suatu tempat, atau mengelola produk secara manual. Jika ini adalah analog langsung dari sesuatu yang diketahui, Anda dapat dengan mudah menunjukkan sepasang barang ke dalamnya di kartu. Ada sarung tangan yang bekerja dari satu produsen, yang lain datang (atau hanya artikel atau model yang diubah) - kami menunjukkan pasangan sebelumnya, dan modelnya didasarkan pada sejarah produk lain. Setelah enam minggu (ini adalah konstanta ajaib), ikatan produk secara otomatis dilepaskan dan hanya riwayatnya sendiri yang mulai dihitung.
Ketika suatu produk benar-benar baru dan umumnya tidak jelas apa yang harus dilakukan dengannya, sejumlah tertentu dibawa ke toko menurut perkiraan manual. Kemudian sejarah diketik. Rekan mode memiliki banyak matematika tentang ini, tetapi kami tidak melakukannya: kami masih tentang renovasi, dan mode kami baru saja mulai muncul di bidang desain dan dekorasi penggaris dapur pada umumnya. Permintaan lainnya lancar untuk hampir semua kelompok produk. Perubahan musiman diperhitungkan dengan cukup mudah: untuk produk baru - berdasarkan grup, untuk yang lama - menurut sejarah panjangnya.
Karena kami masih jauh dari dapat menghitung semuanya dengan benar dan sistem dapat membuat kesalahan, dokumen akhir dikirim untuk persetujuan ke administrator toko (atau orang yang bertanggung jawab atas pengiriman barang). Lebih tepatnya, ini biasanya dilakukan oleh manajer departemen (ada 15 departemen di toko: perkakas, perangkat keras, pipa ledeng, dll.). Ini menampilkan semua item, tanpa kecuali, yang dapat dikirim dalam departemen, dan jumlahnya. Artinya, jika pesanan berisi 0, maka ada posisi dan biayanya nol.
Kami sedang menguji ADR untuk beberapa vendor. Karena ada kasus ketika sistem menawarkan jumlah untuk pesanan, dan manajer toko mengkonfirmasi parameter tanpa perubahan dan untuk waktu yang lama, pengguna tidak perlu memproses pesanan tersebut di ERP dan kami secara otomatis mengirimkannya ke pemasok. Tetapi ada sekelompok koordinator yang mendukung toko dan memantau kebenaran pesanan tersebut.
Dengan kesepakatan, Anda dapat menghapus produk (jika musim Tahun Baru berakhir, maka Anda tidak perlu memesan 100 pohon buatan lagi) atau menambahkan satu pohon yang belum pernah dijual sebelumnya. Ini membutuhkan partisipasi orang lain dari kantor.
Dalam 99,9% kasus, semuanya diputuskan saat itu juga di toko, dan administrator hanya meningkatkan jumlah produk yang, menurut mereka, dijual lebih banyak dan lebih cepat daripada yang dapat diprediksi sistem. Meski begitu, 50-60 ribu SKU sangat sulit diproses hanya secara manual. Mereka akhirnya membuat sedikit perubahan yang membantu meningkatkan penjualan, merasa memegang kendali, tetapi tidak menyebabkan kesalahan manusia. Semuanya dilakukan dengan cara yang terdesentralisasi, yaitu, setiap toko mengelola pesanannya sendiri, kecuali dalam kasus yang jarang terjadi.
Ada produk manual. Misalnya, kabin shower non-standar. Ada barang dengan pengisian ulang semi-otomatis: sistem untuk barang tersebut menghitung penawaran untuk pesanan dan secara kuantitatif menampilkan berapa banyak yang harus dipesan. Manajer toko melihat perkiraan penjualan, riwayat penjualan dan, jika perlu, menyesuaikan kuantitas. Kami terlibat dalam mengurangi jumlah penyesuaian pada pesanan yang diusulkan, sehingga pengguna melakukan lebih sedikit operasi manual dan sistem menghasilkan proposal "ideal" untuk pesanan tersebut.
Kami sangat memahami rasio musiman, di mana produk yang sama dijual dengan harga yang berbeda sepanjang tahun. Tetapi pada saat yang sama, barang-barang yang banyak dijual untuk sebagian musim, tetapi bukan sebagian, belum diproses dengan sangat akurat. Model dipertajam untuk perpindahan yang mulus, dan bukan fluktuasi tajam.
Untuk menghitung pesanan, sistem memperhitungkan penundaan rata-rata pemasok. Jika kami melihat bahwa pemasok secara teratur terlambat lima hari, maka, selain penalti, GOLD akan mempertimbangkan hal ini dalam pembentukan pesanan dan memesan lebih banyak stok pengaman untuk memperhitungkan kemungkinan penundaan. Selain itu, kami telah mengembangkan analisis saldo harian: jika produk tidak ada di rak selama beberapa hari dalam seminggu dan jika hari-hari ini memiliki probabilitas penjualan yang signifikan, maka sistem akan melihatnya dan memahami bahwa minggu seperti itu harus dikecualikan untuk memperhitungkan riwayat penjualan, dan tidak menurunkan perkiraan.
Bagaimana gudang tahu berapa banyak yang harus diambil dan dari mana? Sekarang Anda tahu bagaimana sebuah toko mendefinisikan kebutuhannya. Anda tahu bagaimana itu dikonsolidasikan dan dikirim ke gudang, dan gudang harus mendapatkan pengangkutan dan mengirimkan semuanya. Namun ada lapisan lain: gudang perlu memproses semua ini.
Perkiraan penjualan untuk setiap toko dan prakiraan logistik, dengan mempertimbangkan rute dan penggunaan berbagai jenis transportasi (truk berpendingin, papan samping, dan sebagainya), memberikan pemahaman tentang berapa banyak barang yang akan dibutuhkan dan di mana. Dan pada tanggal berapa Anda perlu mendapatkannya.
Lebih jauh - lapisan pengoptimalan lainnya: mana yang lebih menguntungkan untuk mendapatkannya saat ini? Pesta yang mana? Beberapa pemasok menetapkan volume pengiriman minimum (Anda tidak akan dapat memesan satu kilogram paku), beberapa memberikan diskon volume, potongan harga, dan ketentuan khusus lainnya. Perlu diperhatikan bagaimana cara membawa barang dan dari mana. Kami baru saja mulai mengerjakan topik ini, meskipun dalam bentuk yang agak sederhana. Saya pikir dalam satu tahun akan ada sesuatu untuk diceritakan.
Terkadang lebih menguntungkan menyimpan barang dalam jumlah besar daripada membeli beberapa barang kecil; terkadang lebih menguntungkan untuk membagi pengiriman menjadi sepuluh lot lokal dari pemasok yang berbeda. Dll
Perlu diketahui persentase barang yang ditolak, agar tidak ada barang yang sampai, tetapi tidak bisa dijual. Gudang memuluskan semua fluktuasi ini karena jumlah yang besar.
Jika Anda tidak memprediksi semuanya secara akurat, maka marjinalitas kategori produk menurun (stok yang tidak perlu terakumulasi). Semakin besar ragamnya, semakin banyak item yang perlu Anda lacak. Ketika berbicara tentang puluhan ribu posisi di pasar di mana ada perubahan global (dan memang demikian), maka Anda tidak dapat melakukannya tanpa otomatisasi yang baik.