Mengapa kami sengaja tidak membina POS besar

Jika anda pernah menilai perisian titik jualan untuk restoran kecil, anda akan mengenali coraknya. Dek vendor menunjukkan lima puluh ciri. Skrin konfigurasi mempunyai ratusan tetapan. Yuran berulang dikalibrasi untuk rangkaian. Selepas tiga bulan anda dan pasukan anda masih menggunakan mungkin dua belas ciri — tetapi anda membayar untuk semua lima puluh, dan tersandung pada yang lain setiap syif.

Ini bukan kebetulan. Ini adalah apa yang berlaku apabila satu produk perlu memenuhi lengkung pertumbuhan vendor yang dibiayai usaha dan melayani sebuah restoran 40-tempat duduk di pusat Kuala Lumpur. Kedua-dua keperluan ini tidak menunjuk ke arah yang sama.

Apa yang sebenarnya dimaksudkan dengan "POS minimal"

Apabila kami mengatakan "minimal", kami tidak bermaksud dilucutkan atau berkualiti rendah. Kami maksudkan: hanya apa yang restoran ini perlukan, dan tiada yang lain. Tiga contoh konkrit dari pengedaran kami sendiri:

• Kaunter izakaya di mana chef mahu kemasukan pesanan mengikuti aliran sebenar omakase — bukan interaksi "meja → tiket" generik. Jadi kami memodelkan kursus, bukan hanya item.
• Konsep makan tengah hari dan makan malam kecil di mana dapur menjalankan dua stesen berbeza. POS harus mengarahkan item yang betul ke pencetak yang betul dengan format yang betul. Tiada "enjin peraturan" diperlukan — hanya pemetaan jelas yang dikodkan keras.
• Seorang pemilik yang menutup peti setiap malam dan hanya mahu tiga nombor di skrin utama: pendapatan, hidangan teratas, dan varians tunai. Itulah skrin utama. Bukan "modul papan pemuka".

Apa yang kami tinggalkan

Senarai ini sekurang-kurangnya sama pentingnya dengan apa yang kami masukkan:

• Tiada bendera ciri multi-penyewa. Setiap kedai mendapat binaan yang sesuai dengannya.
• Tiada "semua boleh dikonfigurasi". Jika satu tetapan hanya diperlukan oleh satu jenis restoran, kami mengkodkannya untuk yang memerlukannya dan meninggalkannya dari yang lain.
• Tiada enjin tema, tiada pasaran plugin, tiada peta jalan ciri masa depan. Kami menghantar apa yang diperlukan sekarang.

Apa yang kami kekalkan kecil dengan sengaja

• Pangkalan data. Satu instans PostgreSQL per kedai, bersaiz mengikut jumlah transaksi sebenar. Tiada perkhidmatan mikro.
• Pangkalan kod. Satu pangkalan kod TypeScript per keluarga kedai, berkongsi modul biasa di mana ia benar-benar masalah yang sama.
• Jejak operasi. Satu pelayan, satu saluran paip sandaran, satu pandangan pemantauan. Membosankan dengan sengaja.

Mengapa ini berkesan untuk pengendali kecil

Hasilnya adalah perisian yang sesuai dengan operasi dan bukannya meminta operasi untuk menyesuaikan diri dengannya. Ia juga, yang penting, jauh lebih murah untuk dimiliki. Sebuah kedai tunggal yang menjalankan POS minimal kami membayar sebahagian kecil daripada apa yang akan dibayar kepada vendor POS perusahaan generik — dan kosnya kekal boleh diramal apabila operasi berkembang.

Pendekatan ini bukan untuk setiap perniagaan. Francais 200-kedai memerlukan perisian yang berbeza, dan kami bukan pasukan yang sepatutnya membinanya. Tetapi untuk kebanyakan restoran bebas dan rangkaian kecil di Malaysia? Menyesuaikan saiz POS adalah salah satu keputusan leverage tertinggi yang boleh dibuat oleh pemilik.

Sedang mengusahakan POS untuk operasi anda sendiri? Hubungi kami — kami gembira untuk berkongsi pandangan.