Studi Kasus: Rekap Kasir Harian dari Enam Jam Jadi Empat Menit
Toko tutup jam sepuluh malam. Kasir terakhir pulang jam sebelas. Tapi pemiliknya baru selesai jam dua pagi, karena rekap hari itu belum cocok dan selisihnya harus dicari satu per satu dari tumpukan struk. Besoknya, hal yang sama terulang.
Enam jam per hari untuk merekap penjualan adalah angka yang terdengar mustahil sampai Anda memecahnya. Di kasus ini, enam jam itu tersebar di beberapa orang dan beberapa waktu: sebagian di pagi hari, sebagian saat pergantian sif, sebagian lagi di malam hari. Karena tersebar, tidak ada yang pernah menghitungnya sebagai satu pekerjaan penuh. Padahal itu setara satu karyawan yang bekerja seharian tanpa menghasilkan satu rupiah pun penjualan.
Alur lama dan di mana enam jam itu habis
Sistem kasirnya sebenarnya sudah ada dan berjalan. Yang tidak ada adalah jembatan antara sistem kasir dengan segala hal lain yang perlu dicocokkan setiap hari.
Begini urutannya sebelum diubah:
- Cetak dan salin. Laporan penjualan dicetak dari mesin kasir, lalu diketik ulang ke spreadsheet karena formatnya tidak bisa dipakai langsung.
- Pisahkan metode bayar. Tunai, kartu, dan beberapa dompet digital dihitung terpisah, masing-masing dari laporan yang berbeda dan waktu penyelesaian yang berbeda pula.
- Cocokkan mutasi. Angka pembayaran non-tunai dicocokkan dengan mutasi rekening, yang masuknya tidak selalu di hari yang sama dan sering digabung dalam satu baris untuk beberapa transaksi.
- Hitung uang fisik. Uang di laci dihitung, dikurangi modal awal, dibandingkan dengan angka penjualan tunai.
- Kurangi pemakaian bahan. Stok bahan dihitung manual untuk item tertentu, dan selisihnya dicatat di berkas terpisah.
- Susun laporan harian yang dikirim ke pemilik lewat chat, dalam bentuk foto layar spreadsheet.
- Cari selisih. Kalau ada yang tidak cocok, mundur ke belakang dan telusuri struk. Ini bagian yang tidak punya batas waktu.
Langkah tujuh itulah yang membuat enam jam menjadi enam jam. Enam langkah pertama bisa selesai dalam waktu yang wajar pada hari yang mulus. Masalahnya, hari yang mulus jarang. Satu transaksi yang salah input di jam sibuk bisa memakan dua jam penelusuran malam harinya.
Yang mahal bukan merekapnya. Yang mahal adalah mencari kenapa rekapnya tidak cocok.
Biaya yang tidak kelihatan di jam kerja
Ada tiga kerugian lain yang lebih besar daripada jamnya sendiri. Pertama, laporan baru siap keesokan hari, jadi keputusan pembelian bahan selalu memakai data kemarin. Kedua, karena capek, orang mulai membulatkan: selisih kecil dianggap wajar dan tidak dicari lagi. Ketiga, kecurigaan. Ketika selisih terjadi berulang dan penyebabnya tidak pernah jelas, yang tumbuh bukan perbaikan proses melainkan ketidakpercayaan antar-sif.
Perubahan yang dilakukan
Fondasinya adalah Coffee Shop Management System, produk kami sendiri, yang disesuaikan untuk alur toko ini. Tapi urutan pengerjaannya lebih menentukan daripada perangkat lunaknya.
Menyatukan pencatatan lebih dulu
Sebelum apa pun diotomasi, semua transaksi harus masuk lewat satu pintu. Sebelumnya ada pesanan yang dicatat di kertas saat antrean panjang dan diinput belakangan, ada pesanan daring yang dicatat terpisah, dan ada penjualan karyawan yang dicatat di buku. Selama tiga pintu itu ada, tidak ada sistem yang bisa mencocokkan apa pun. Ini bagian yang paling banyak menemui penolakan dan paling sedikit melibatkan kode.
Menghitung otomatis, bukan mengetik ulang
Setelah satu pintu tercapai, rekap tidak lagi disusun. Ia sudah ada sepanjang hari dan tinggal ditutup. Penjualan per metode bayar, per kategori, per sif, dan per kasir terhitung sendiri saat transaksi terjadi. Pemakaian bahan untuk item standar berkurang otomatis mengikuti resep yang didaftarkan sekali di awal.
Menutup hari sebagai satu tindakan
Empat menit yang disebut di judul adalah waktu untuk: menghitung uang fisik di laci, memasukkan angkanya, membaca selisih yang muncul, dan menekan tombol tutup. Sistem tidak menghitung uang fisik, dan menurut kami memang tidak boleh. Bagian itu adalah kontrol yang justru harus tetap dilakukan manusia.
Laporan yang berangkat sendiri
Setelah hari ditutup, ringkasan terkirim ke pemilik tanpa ada yang perlu memotret layar. Isinya penjualan, komposisi metode bayar, item terlaris, dan selisih kas hari itu bila ada.
Penanganan selisih kas
Bagian ini sengaja tidak dihilangkan, dan itu keputusan yang perlu dijelaskan. Godaan saat membangun sistem seperti ini adalah membuat selisih otomatis "disesuaikan" agar laporan selalu rapi. Kami menolak, karena selisih adalah sinyal, bukan gangguan.
Yang berubah adalah kecepatan menemukan sebabnya. Karena setiap transaksi tercatat dengan waktu, kasir, dan sif, penelusuran yang dulu berarti membongkar tumpukan struk sekarang berarti menyaring daftar. Selisih pun dikelompokkan berdasarkan pola yang paling sering muncul:
| Pola selisih | Petunjuk yang biasanya menyertainya | Perbaikan yang tepat |
|---|---|---|
| Kembalian salah | Nilai kecil, acak, tersebar di banyak hari | Latihan kasir dan tampilan kembalian yang lebih jelas |
| Salah metode bayar | Tunai kurang, non-tunai lebih, jumlahnya sama persis | Konfirmasi metode sebelum transaksi ditutup |
| Transaksi batal tidak dicatat | Selisih muncul bersama nota koreksi | Alur pembatalan yang wajib beralasan |
| Modal awal laci tidak sama | Selisih tetap besarnya tiap hari | Modal awal dicatat dan dikunci di sistem |
| Konsumsi internal | Stok berkurang tanpa penjualan | Menu khusus untuk pemakaian karyawan |
| Penyimpangan | Terpusat pada orang atau jam tertentu | Kontrol dan pemeriksaan langsung |
Perhatikan bahwa hanya baris terakhir yang berkaitan dengan kejujuran. Lima baris di atasnya adalah masalah proses. Pengelompokan ini penting bukan untuk sistemnya, tapi untuk suasana kerjanya: ketika penyebab selisih bisa ditunjuk, tuduhan berhenti beredar.
Untuk selisih yang benar-benar tidak terjelaskan, kamera di atas area kasir sering jadi penentu. Pemilik toko ini memakai kamera WiFi yang mengarah ke laci, bukan untuk mengawasi orangnya, melainkan untuk memeriksa satu menit rekaman pada jam transaksi yang bermasalah. Perlu kami sebutkan terus terang: kami menjual kameranya, bukan memasangkannya. Unitnya plug-and-play dan tidak ada jasa penarikan kabel dari pihak kami.
Hasil setelah tiga bulan
Angka yang kami pegang dari kasus ini adalah dua: enam jam sebelumnya, empat menit sesudahnya. Kami tidak akan menambahkan persentase kenaikan penjualan atau penurunan selisih, karena angka semacam itu di kasus ini bercampur dengan banyak hal lain yang terjadi bersamaan dan tidak bisa dinisbatkan hanya pada sistem.
Yang bisa kami sampaikan adalah perubahan yang jelas terlihat:
- Tutup toko berhenti berarti kerja lembur. Sif malam pulang tidak lama setelah pintu ditutup.
- Keputusan belanja bahan memakai data hari itu, bukan data kemarin.
- Selisih ditangani di hari yang sama. Dulu ditumpuk sampai akhir pekan, dan pada saat itu ingatan orang sudah kabur.
- Perbandingan antar-sif jadi mungkin, sehingga pembahasannya soal jam sibuk dan komposisi menu, bukan soal siapa yang salah.
- Pemilik berhenti jadi penghubung data. Ini yang paling sering diremehkan pada bisnis kecil: waktu pemilik adalah sumber daya paling langka di toko.
Kalau Anda ingin memperkirakan nilainya untuk toko sendiri, hitung dengan cara ini dan sebutkan asumsinya: catat waktu rekap sebenarnya selama satu pekan penuh termasuk waktu mencari selisih, kalikan dengan jumlah hari buka per bulan, lalu kalikan dengan tarif jam kerja orang yang mengerjakannya. Tambahkan satu baris yang tidak bisa diangkakan tapi harus ditulis: berapa kali bulan lalu keputusan tertunda karena datanya belum siap.
Yang perlu disiapkan kalau ingin meniru
Bagian teknisnya bukan yang menentukan berhasil atau tidak. Ini yang menentukan:
- Satu pintu transaksi, tanpa pengecualian. Kalau masih ada penjualan yang dicatat di kertas, rekapnya tidak akan pernah cocok, sistem secanggih apa pun.
- Daftar bahan dan resep yang benar. Pengurangan stok otomatis hanya seakurat resep yang didaftarkan. Ini pekerjaan manual yang harus diselesaikan di awal dan tidak ada jalan pintasnya.
- Modal awal laci yang tetap dan dicatat. Sederhana, tapi menghilangkan seluruh kelas selisih.
- Kesepakatan soal konsumsi karyawan. Buat jalur resminya. Kalau tidak, ia akan tetap terjadi dan muncul sebagai selisih stok.
- Pelatihan singkat yang diulang. Sekali di awal tidak cukup. Kesalahan input paling banyak terjadi pada pekan-pekan pertama dan pada karyawan baru.
- Kesiapan menerima selisih apa adanya. Pada bulan pertama, selisih justru akan terlihat lebih banyak, karena sekarang semuanya tercatat. Itu bukan kemunduran; itu yang selama ini tidak terlihat.
Kapan ini bukan solusi yang tepat
Beberapa kondisi membuat pembangunan sistem seperti ini tidak sepadan, dan kami akan mengatakannya di awal.
Kalau toko Anda melayani sedikit transaksi bernilai besar, misalnya belasan transaksi sehari, rekapnya tidak akan pernah memakan enam jam dan penghematannya tidak menutup biaya. Kalau menunya sering berubah total tiap bulan, pemeliharaan daftar resep bisa jadi beban yang lebih berat daripada manfaat pengurangan stok otomatis. Kalau yang Anda cari hanya laporan penjualan tanpa urusan stok dan kas, aplikasi kasir siap pakai di pasaran sudah cukup dan jauh lebih murah daripada apa pun yang bisa kami bangun.
Sistem custom mulai masuk akal ketika alur Anda punya kekhususan yang tidak dilayani produk jadi: banyak cabang dengan aturan berbeda, integrasi ke sistem yang sudah ada, atau perhitungan yang tidak standar. Sebelum itu, produk jadi adalah jawaban yang jujur.
Kalau kondisi toko Anda mirip dengan yang dijelaskan di atas, cara kami membangun dan menyesuaikan sistem semacam ini ada di halaman jasa pembuatan aplikasi, dan contoh pekerjaan lain bisa dilihat di portofolio. Untuk kamera yang mengarah ke area kasir, pilihan unit plug-and-play beserta spesifikasinya ada di halaman produk.
Reza
