Kenapa BMP Ada

Catatan keputusan dari pabrik parfum yang berjualan di marketplace

Dokumen ini adalah "kenapa". Apa ada di Data Model. Cara membangun ada di Blueprint. Perilaku fitur ada di dokumen referensi modul. Bila nanti ada keputusan baru yang ragu, batu ujinya satu: apakah ini menjaga cerita tetap benar?

1. Siapa kami

Ini adalah bisnis produksi & distribusi parfum — kosmetik golongan B, tunduk CPKB, diaudit BPOM. Bukan pedagang: kami mencampur, memeram, mengisi, menyegel. Barang kami mengalir dalam empat wujud: Raw Material (fragrance oil, alkohol, kemasan) → Bulk (konsentrat tercampur) → Finished Good (botol terisi, berlabel, bersegel) → terjual.

2. Bagaimana uang masuk

Hampir semua penjualan terjadi di luar sistem: pembeli menekan checkout di Shopee, Tokopedia, TikTok Shop; sisanya toko fisik, distributor B2B, dan jalur kecil tester/decant/scrap. Sistem tidak pernah melihat order individual itu — dan memang tidak perlu. Marketplace mencatat pembeli; kami mencatat bisnis.

3. Bagaimana barang dibuat

Supplier kami: importir fragrance oil berkatalog USD, supplier alkohol, supplier kemasan, ekspedisi. Produksi berjalan dua tahap dengan logika stok berbeda:

Dari drum supplier sampai channel penjualan, satu benang wajib terjaga: traceability batch — karena bila BPOM atau pembeli bertanya "batch ini ke mana saja?", jawabannya harus keluar dalam satu tarikan napas.

4. Kenapa tidak ERP jadi

Kami membedah 12 ERP open source (ERPNext, Dolibarr, OFBiz, metasfresh, iDempiere, Tryton, OpenPetra, Axelor, inoERP, LedgerSMB, BlueSeer, WebERP). Polanya sama: UI mengikuti bentuk database, bukan bentuk kerja user, dan mesin jualannya mengandaikan pipeline B2B "quotation → order → invoice". Bisnis kami kebalikannya: penjualan sudah terjadi sebelum sistem tahu. Maka ERPNext kami jadikan kamus perilaku, tapi BMP kami bangun sendiri — Phoenix/Ash/SQLite, offline/LAN, satu binary, tanpa cloud.

5. Keputusan yang terlihat aneh — dan alasannya

#1 — Customer adalah channel, bukan orang. Record customer kami kurang dari sepuluh: SHOPEE, TOKOPEDIA, TIKTOK, TOKOA, DISTB. Nama-alamat-HP pembeli hidup di sisi marketplace dan sengaja tidak masuk BMP. Privasi terjaga, database kecil, dan rekonsiliasi settlement justru mungkin — karena settlement marketplace memang per channel, bukan per orang.

#2 — Price list cuma satu: "Harga Dasar - IDR". Pertanyaan bisnisnya bukan "berapa harga tiap channel" melainkan "biaya dan diskon apa yang menempel di channel ini". Maka harga dasar satu; variasi diurus Fee Components (fee Shopee 3% + Rp2.000; diskon grosir = fee negatif) dengan tanggal berlaku dan snapshot saat order. Harga tidak bercabang dan ber-drift; sejarah tidak ditulis ulang.

#3 — Revenue GROSS; fee marketplace jadi beban. Memotong fee dari revenue (kebiasaan umum UMKM) membuat volume terlihat kecil dan margin bohong. Penjualan dicatat utuh; fee masuk beban lewat deductions pada Payment Entry. Settlement yang dulu "tebak-tebakan Excel" kini bisa diaudit sampai rupiah terakhir.

#4 — Sales Order adalah rekap harian, bukan order per pembeli. Satu SO konsolidasi per channel per hari (persis logika POS closing). Ledger tidak kebanjiran ribuan dokumen kecil, dan satu kolom menjawab audit internal: rekap Selasa siapa yang menginput? — Sales Person sebagai accountability, bukan mesin komisi.

#5 — Retur dua rasa, reason code wajib. "Wangi tidak cocok" = subjektif, urusan CS, tidak memicu investigasi QC. "Botol bocor" = objektif, memicu Non-Conformance. Tanpa pemisahan ini, QC tenggelam menyelidiki selera, dan cacat produksi asli lolos tanpa jejak.

#6 — Gerbang "FG layak jual" dijaga sistem, bukan SOP. Delivery Note hanya bisa memilih batch Accepted yang berada di FG Store. Menjual barang belum lulus QC dibuat mustahil secara sistem — karena SOP kertas bisa lupa; sistem tidak.

#7 — Stok tidak boleh negatif. Stok minus membuat valuasi bohong, COGS bohong, traceability fiksi. allow_negative_stock dikunci OFF tanpa override. Angka di layar harus selalu berarti barang di rak.

#8 — Batch, bukan serial. Parfum lahir per sesi produksi, bukan per botol. Satu batch = satu cerita: drum supplier mana, mixer mana, kapan maturing, ke channel mana terkirim.

#9 — Maturing soft-gate; deviasi punya rumah. SOP memeram (mis. 7 hari), tapi bisnis kadang mengejar tayang. Pelanggaran diperbolehkan dengan paksaan meninggalkan jejak: Non-Conformance terbuka otomatis. Kami tidak membangun sistem yang pura-pura tanpa pengecualian; kami membangun sistem yang membuat pengecualian terlihat.

#10 — IT mengurus sistem, tidak mengintip bisnis. Resep (twist_notes), margin, gaji, rekening = nyawa perusahaan. IT tetap mengelola user, log, server — tetapi field rahasia dienkripsi at-rest (Cloak) dan tak terbaca role mereka. Kepercayaan tidak dijadikan mekanisme keamanan; desain yang dijadikan mekanisme.

#11 — Hide, Don't Burn. Budget, cuti, Non-Conformance, dll. tidak dibuang — hanya disembunyikan sampai dibutuhkan. Yang dibuang benar hanya yang bertentangan dengan kodrat bisnis: Quotation/CRM, POS, Serial No, Subcontracting (CPKB melarang maklon; resep rahasia), Job Card, Share Management, Subscription, modul rekrutmen-performa.

#12 — Offline-first, murni BEAM, nol binary eksternal. Berjalan di LAN kantor, satu binary, tanpa CDN/cloud. PDF via Tincture, QR via eqrcode, export Excel via exceed — semuanya Elixir. Sistem yang bergantung internet adalah sistem yang mati saat modem rusak.

#13 — Email boleh menunggu. Fase ini: simpan PDF, kirim lewat Gmail/WhatsApp — workflow yang sudah alami bagi tim kecil. Otomasi layak dibangun saat volume membenarkan; sebelumnya ia hanya kompleksitas.

#14 — UI mengikuti kerja, bukan skema. Pager tradisional (bukan infinite scroll) karena data operasional butuh konteks total; search menancap, bukan modal gelap; satu fitur satu rumah; Settings Hub tunggal; label navigasi tidak boleh terpotong. ERP yang nyaman menjawab "apa yang mau user capai sekarang", bukan "bagaimana data ini disimpan".

6. Prinsip turunan — batu uji keputusan baru

  1. Catat yang sudah terjadi dengan jujur — sistem adalah buku catatan, bukan mesin optimisme.
  2. Sistem = penjaga gerbang compliance — yang berbahaya dibuat mustahil; yang pengecualian dibuat terlihat.
  3. Rahasia hidup di sistem, tapi tidak terlihat oleh semua orang — keamanan lewat desain, bukan kepercayaan.
  4. Setiap angka harus bisa dijelaskan — settlement, margin, selisih kurs vs kenaikan harga supplier (reference_usd_rate ada untuk itu).
  5. Sederhana sebagai default, skalabel sebagai toggle — UMKM hari ini, menengah besok, tanpa migrasi ulang.
  6. Stok strategis vs stok taktis — Bulk diramalkan, FG dipesankan; modal tidak membeku di botol berlabel.

BMP bukan ERP yang dikecilkan. Ia sistem operasi untuk satu cara berbisnis yang spesifik: pabrik parfum yang menjual lewat marketplace — dan setiap keputusan di atas ada agar cara berbisnis itu tetap jujur, tertelusur, dan rahasia pada tempatnya.