Kenapa hotel kehabisan stok walaupun ada sistem pembelian?

Kerana kebanyakan sistem pembelian hanya tahu apa yang dibeli, bukan apa yang sedang digunakan. Stok dikira pada kiraan stok bulanan tetapi digunakan setiap jam oleh restoran, bar, pengemasan dan aktiviti. Antara kiraan, sistem pembelian bekerja dengan gambaran yang semakin lapuk hari demi hari — jadi pesanan semula berlaku terlalu lewat, atau terlalu awal, atas tekaan.

Apakah maksud penggunaan boleh diramal di hotel?

Penggunaan masa depan sesebuah hotel sebahagian besarnya sudah terjual. Pakej dalam buku tempahan terurai kepada komponennya — sarapan, makan tengah hari, aktiviti seperti snorkeling — jadi sistem tahu berapa banyak setiap satu dibawa oleh sesuatu tarikh hadapan sebaik sahaja tempahan dibuat. Tambah penggunaan point-of-sale secara langsung, di mana setiap jualan menolak kuantiti resipi daripada stok ketika ia direkodkan, dan keperluan pembelian esok menjadi satu pengiraan, bukan tekaan.

Kenapa ERP generik sukar mengendalikan perolehan hotel?

ERP generik pandai mengeluarkan pesanan pembelian, tetapi data yang meramal penggunaan hotel — tempahan hadapan, komponen pakej, resipi, kehadiran taman — berada di sisi pengurusan hartanah dan point-of-sale, yang tidak pernah dilihat oleh ERP berasingan. Ia tahu tentang permintaan sarapan selepas dapur membuat rekuisisi stok; sistem yang berkongsi pangkalan data tempahan tahu sejak bilik itu ditempah.

Bagaimana WinX memastikan susulan pembelian tidak hilang?

Dalam WinX, rantaian itu ialah satu rekod berpaut: permintaan stok outlet dipautkan kepada pesanan pembelian yang dikeluarkan daripadanya, pesanan kepada penerimaan barang terhadapnya, dan penerimaan ke lokasi stok tempat ia mendarat. Permintaan tertunggak, pesanan belum dihantar dan penghantaran separa ialah senarai yang diselenggara sistem — bukan e-mel yang perlu diingat untuk disusuli — dan had kelulusan dikuatkuasakan oleh profil kebenaran pembelian.

Insights

Perolehan: kenapa stor kehabisan barang pada malam Sabtu

Hotel, resort dan taman tema sebenarnya tiada masalah pembelian — mereka ada masalah keterlihatan. Stok dikira sebulan sekali tetapi digunakan setiap jam, jadi dapur mendapati kekurangan di tengah servis, penjaga stor mendapati lebihan stok semasa kiraan stok, dan tiada siapa yang mendapati pesanan belum dihantar itu langsung. Berikut sebab ia berlaku, dan kenapa kebanyakannya masalah pangkalan data, bukan masalah disiplin.

Kesakitannya: tiga cara pembelian tersasar

Stok yang tidak kelihatan. Kebenaran di stor dan kebenaran dalam laporan menyimpang sepanjang bulan. Pengeluaran ke outlet direkod di atas kertas, kepecahan tidak direkodkan, dan kiraan stok bulanan menyelaraskan realiti dengan lejar hanya selepas empat minggu keputusan dibuat atas angka lapuk.

Dibeli terlalu lewat, atau terlalu awal. Terlalu lewat ialah kehabisan stok malam Sabtu — item menu yang mati di tengah servis pada kiraan tetamu paling sibuk minggu itu. Terlalu awal lebih senyap tetapi lebih mahal: tunai terikat di atas rak, barang mudah rosak luput dalam penyejuk, stor disumbat menjelang bulan yang rupanya lembap. Kedua-duanya datang dari punca yang sama — memesan semula ikut gerak hati, kerana angkanya bukan angka langsung.

Susulan yang hilang. Outlet meminta stok; permintaan menjadi e-mel; e-mel menjadi pesanan pembelian — atau tidak. Pesanan tiba sebahagian, dan tiada siapa menyusuli bakinya kerana tiada senarai di mana-mana yang menyatakan ia tertunggak. Apabila permintaan, pesanan dan penghantaran berada di tempat berasingan, rantaian itu tiada ingatan.

Kenapa ia berlaku: data penggunaan berada dalam sistem lain

Ini bahagian strukturnya. Maklumat yang meramal penggunaan sesebuah hartanah tidak berada dalam sistem pembelian — ia berada dalam buku tempahan dan mesin juruwang:

Pakej sudah mengandungi komponennya. Apabila tetamu menempah bilik + sarapan + snorkeling untuk Jumaat depan, tempahan itu membawa item pecahannya — satu lagi sarapan, satu lagi slot snorkeling, pada tarikh yang diketahui. Darabkan merentas buku tempahan dan penggunaan Jumaat depan sebahagian besarnya sudah tertulis sebelum minggu itu bermula.
Setiap jualan menolak resipi. Sepinggan nasi lemak yang direkod di POS ialah santan, beras dan ikan bilis keluar dari stor — jika sistem tahu resipinya dan berkongsi pangkalan data.
Acara dan kehadiran diketahui lebih awal. Pesanan bankuet, blok kumpulan dan corak kehadiran taman semuanya berada dalam data operasi yang sama.

ERP generik — sebaik mana pun pesanan pembeliannya — tidak pernah melihat semua ini. Ia tahu tentang permintaan sarapan selepas dapur membuat rekuisisi stok. PMS hospitaliti kebanyakannya langsung tiada fungsi pembelian. Maka hartanah akhirnya meneka di tengah-tengah: penggunaan diketahui dalam satu sistem, pembelian dibuat dalam sistem lain, dan hamparan menjadi jambatan antara keduanya apabila ada yang sempat.

Bagaimana WinX menyelesaikannya: perolehan atas pangkalan data operasi

WinX meletakkan modul perolehan pada pangkalan data yang sama dengan tempahan, POS dan lejar am — jadi input di atas bukanlah integrasi, ia adalah cantuman jadual:

Kedudukan stok langsung bagi setiap lokasi — stor pusat dan stor outlet secara berasingan, dikemas kini oleh penerimaan barang, pengeluaran stor, agihan dan tolakan jualan ketika ia berlaku, dengan pembetulan kiraan stok apabila realiti masih menyimpang.
Penggunaan diketahui lebih awal — item pecahan pakej pada tempahan hadapan memberitahu dapur dan penjaga stor apa yang sudah dibawa oleh sesuatu tarikh sebelum ia tiba.
Rantaian susulan yang beringatan — permintaan stok outlet berpaut kepada pesanan pembelian yang dikeluarkan daripadanya, pesanan kepada penerimaan barang terhadapnya. Pesanan tertunggak dan terhantar separa ialah senarai tetap, bukan ihsan yang perlu diingat.
Kawalan tanpa geseran — profil kebenaran pembelian menguatkuasakan siapa boleh meminta, meluluskan dan memesan, mengikut jabatan dan mengikut had.
Kos yang jatuh di tempat sepatutnya — kerana penerimaan, pengeluaran dan jualan berkongsi lejar, kos jualan peringkat outlet ialah satu laporan, bukan projek arkeologi hujung bulan. Logik sama yang meletakkan P&L pada hari itu juga, bukan pada hujung bulan.

Perubahannya: daripada pembelian sebagai kerja kertas yang mengekori operasi, kepada pembelian sebagai pengiraan yang berjalan atas data yang sedia dihasilkan operasi. Beli apa yang buku tempahan kata anda perlukan — bukan apa yang ditakutkan oleh kehabisan stok yang lepas.

Terbukti di tempat perolehan paling sukar

Operasi berbilang outlet dan berbilang stor ialah tempat pembelian mula-mula pecah — dan tempat WinX berjalan paling besar. Manila Ocean Park + Hotel H2O menjalankan sekitar 40 outlet — pusat beli-belah dalam taman, hotel, spa, kiosk — pada satu pemasangan WinX, dengan agihan stor-pusat-ke-outlet atas rekod yang sama dengan mesin juruwang. Hartanah pulau seperti Atmosphere Resort & Spa di Dumaguete menghadapi tekanan sebaliknya: penghantaran bekalan jarang-jarang, jadi membeli terlalu sedikit dan membeli terlalu banyak kedua-duanya merugikan — dan di situlah senarai pembelian terkira mengalahkan senarai yang diteka.

Soalan lazim

Kenapa hotel kehabisan stok walaupun ada sistem pembelian?: Kerana kebanyakan sistem pembelian hanya tahu apa yang dibeli, bukan apa yang sedang digunakan. Stok dikira semasa kiraan stok tetapi digunakan setiap jam; antara kiraan, sistem bekerja dengan gambaran yang semakin lapuk hari demi hari, jadi pesanan semula berjalan atas tekaan.
Apakah sebenarnya maksud "penggunaan boleh diramal"?: Penggunaan masa depan sesebuah hartanah sebahagian besarnya sudah terjual. Pakej dalam buku tempahan terurai kepada komponennya — sarapan, makan tengah hari, aktiviti — jadi sistem tahu apa yang dibawa sesuatu tarikh hadapan sebaik sahaja tempahan dibuat. Tambah tolakan resipi langsung dari POS, dan keperluan esok menjadi satu pengiraan.
Kenapa ERP generik sukar mengendalikan perolehan hotel?: Data yang meramal penggunaan hotel — tempahan hadapan, komponen pakej, resipi, kehadiran — berada dalam PMS dan POS, yang tidak pernah dilihat ERP berasingan. Ia tahu tentang permintaan sarapan selepas dapur membuat rekuisisi stok; pangkalan data terkongsi tahu sejak bilik itu ditempah.
Bagaimana WinX memastikan susulan tidak hilang?: Rantaian itu ialah satu rekod berpaut: permintaan stok → pesanan pembelian → penerimaan barang → lokasi stok. Permintaan tertunggak dan penghantaran separa ialah senarai yang diselenggara sistem, dengan had kelulusan dikuatkuasakan oleh profil kebenaran pembelian.

Lihat senarai pembelian dikira daripada buku tempahan dan outlet anda sendiri.

Minta demo WinX