Tutorial
Bacaan terbaru
Ya, saya bisa melihat sumber kebingungannya. ERD sebelumnya terlalu cepat masuk ke konsep production_batches, padahal alur bisnis dasarnya belum kita sederhanakan dulu. Kita rapikan konsepnya dari awal.
1. components.no_order sebaiknya dihapus
no_order saya masukkan karena kolom itu terlihat di CSV legacy component Anda. Tetapi setelah kita memahami domainnya, saya tidak melihat alasan kuat no_order berada di master components.
Master component harus menjelaskan:
Product 92093
└── Component 92093A
├── FREM TOP PGR
├── quantity_per_product = 8
├── ukuran
└── informasi teknis lainnya
Sedangkan order adalah transaksi produksi yang terjadi kemudian.
Jadi untuk ERD monitoring kita, saya sarankan:
components.no_order ❌ HAPUS
Kalau nanti diketahui bahwa kolom no_order di database lama ternyata punya arti teknis tertentu dan bukan nomor order produksi, baru kita evaluasi lagi.
2. Pahami tiga lapisan ini dahulu
Ini bagian paling penting.
Jangan melihat:
production_orders production_order_components production_batches
sebagai tiga jenis order.
Mereka punya fungsi berbeda.
Bayangkan:
PRODUCTION ORDER
"Apa yang harus dibuat?"
↓
PRODUCTION ORDER COMPONENTS
"Untuk membuatnya, komponen apa dan berapa banyak yang dibutuhkan?"
↓
PRODUCTION BATCHES
"Barang/komponen yang sedang bergerak di lantai produksi sekarang ada di mana?"
Jadi memang secara monitoring, pada akhirnya aktivitas produksi akan banyak berpusat pada production_batches.
Tetapi order dan component requirement tetap sangat penting sebagai sumbernya.
Contoh nyata
Kita gunakan data Anda.
Buyer:
BRB BRAFAB
Product:
product_code = 92093 name = CIRCUS TBL D130
Misalkan buyer memberi PO:
PO = 45021
dan memesan:
100 PC
Maka production order:
buyer_code = BRB po_number = 45021 product_code = 92093
Nomor monitoring:
BRB45021_92093
Ini saya setuju dengan pola Anda.
Tabel production_orders
Data kira-kira:
id = 1001 buyer_id = BRB product_id = 92093 po_number = 45021 order_number = BRB45021_92093 total_quantity = 100 order_date = 2026-08-08 deadline_date = 2026-10-10 grade = A status = active
Di sinilah jumlah order utama disimpan:
total_quantity = 100 PC
Jadi jawaban pertanyaan Anda:
Saya belum lihat jumlah kebutuhan disimpan di mana?
Ada dua jenis jumlah.
Jumlah produk yang dipesan:
production_orders.total_quantity
Contoh:
100 PC CIRCUS TBL D130
Sedangkan jumlah kebutuhan masing-masing component berada di:
production_order_components.required_quantity
3. Bagaimana production_order_components terbentuk?
Product 92093 mempunyai component seperti data CSV Anda.
Misalnya sebagian:
92093A FREM TOP PGR jml_set = 8 92093B FREM TOP TGH jml_set = 4 92093C SDK FREM TOP jml_set = 8 92093D SLAT TOP 1 2 3 jml_set = 24
Kita sudah memastikan bahwa:
jml_set = quantity_per_product
Maka ketika membuat order 100 PC:
92093A = 8 × 100 = 800 PC 92093B = 4 × 100 = 400 PC 92093C = 8 × 100 = 800 PC 92093D = 24 × 100 = 2.400 PC
Sistem membuat snapshot:
production_order_components
Contohnya:
ComponentQty / ProductOrderRequired92093A | 8 | 100 | 800
92093B | 4 | 100 | 400
92093C | 8 | 100 | 800
92093D | 24 | 100 | 2.400
Jadi:
required_quantity = production_orders.total_quantity × components.quantity_per_product
Ini bukan stok.
Ini adalah:
kebutuhan produksi untuk order tersebut.
Kenapa data ini perlu dicopy?
Karena kita tidak boleh terus menghitung dari master components.
Misalnya hari ini:
92093A = 8 PC/product
Order BRB45021 dibuat.
Dua bulan kemudian engineering mengubah master:
92093A = 10 PC/product
Order lama harus tetap:
800 PC
bukan berubah menjadi:
1000 PC
Makanya ada:
production_order_components
sebagai snapshot.
4. Baru sekarang masuk ke monitoring
Mari abaikan production_batches sebentar.
Kita punya:
Order BRB45021_92093 100 PC product
dan salah satu kebutuhan component:
92093A FREM TOP PGR Required = 800 PC
Flow component:
Komponen Masuk
↓
Oven
↓
Mill 1
↓
Mill 2
↓
Gudang Komponen (optional)
↓
Assembly
Pertanyaannya adalah:
Bagaimana sistem tahu 92093A sekarang berada di mana?
Di sinilah konsep monitoring muncul.
5. monitoring_processes BUKAN history
Ini perlu diluruskan.
monitoring_processes adalah master daftar proses.
Contohnya:
monitoring_processes id | level | code | name --------------------------------------------- 1 | 1 | COMPONENT_IN | Komponen Masuk 2 | 2 | OVEN | Oven 3 | 3 | MILL_1 | Mill 1 4 | 4 | MILL_2 | Mill 2 5 | 5 | WAREHOUSE | Gudang Komponen 6 | 6 | ASSEMBLY | Assembly 7 | 7 | RASTIK | Rastik 8 | 7 | SENDING | Sending ...
Anggap saja tabel ini seperti kamus:
“Di perusahaan kita tersedia proses produksi apa saja?”
Datanya relatif tetap.
Ini bukan histori order.
6. History sebenarnya adalah process_updates
Misalnya operator memindahkan component 92093A:
Komponen Masuk → Oven
Sistem mencatat:
process_updates batch = Batch 92093A from_process = Komponen Masuk to_process = Oven quantity = 800 work_center = Oven 3 updated_by = Ahmad processed_at = 8 Aug 2026 09:15
Kemudian:
Oven → Mill 1
muncul record baru:
batch = Batch 92093A from_process = Oven to_process = Mill 1 quantity = 800 updated_by = Budi processed_at = 9 Aug 2026 13:20
Kemudian:
Mill 1 → Mill 2
record lagi.
Maka histori akhirnya:
WaktuDariKeQtyUser8 Aug 09:15 | Komponen Masuk | Oven 3 | 800 | Ahmad
9 Aug 13:20 | Oven | Mill 1 | 800 | Budi
10 Aug 10:00 | Mill 1 | Mill 2 | 800 | Candra
Inilah history monitoring.
Jadi:
monitoring_processes
= master proses.
Sedangkan:
process_updates
= histori perpindahan proses.
7. Lalu apa sebenarnya production_batches?
Sekarang bagian yang membuat Anda bingung.
Saya beri contoh yang paling sederhana dahulu.
Kebutuhan:
92093A = 800 PC
Kita membuat:
production_batch batch_code = BATCH-001 component = 92093A quantity = 800 position = Komponen Masuk
Artinya:
800 PC component 92093A milik order BRB45021_92093 sedang berada di Komponen Masuk.
Kemudian semuanya masuk Oven 3:
BATCH-001 92093A 800 PC Oven 3
Kemudian Mill 1:
BATCH-001 92093A 800 PC Mill 1
Sederhana.
Kenapa tidak langsung menggunakan production_order_components?
Karena ada kondisi yang sangat mungkin terjadi:
Kebutuhan 92093A = 800 PC
tetapi tidak semua 800 bergerak bersama.
Misalnya:
500 PC sudah masuk Oven 300 PC masih Komponen Masuk
Kalau hanya menggunakan:
production_order_components.current_process_id
kita bingung harus menulis:
current_process = Oven
atau:
current_process = Komponen Masuk
Karena keduanya benar.
Di situlah batch diperlukan
Awalnya:
92093A 800 PC
setelah sebagian diproses:
92093A
│
├── Batch A
│ 500 PC
│ Oven
│
└── Batch B
300 PC
Komponen Masuk
Sekarang database tahu keadaan aktual dengan tepat.
Tetapi ada keputusan bisnis penting
Kalau PT Mandiri Jaya mengatakan:
“Untuk monitoring kami tidak perlu mencatat partial quantity. Kalau satu component masuk proses, kami anggap kebutuhan component order tersebut pindah seluruhnya.”
maka saya akan mengatakan:
production_batches tidak diperlukan.
Kita bisa membuat desain jauh lebih sederhana.
Tetapi kalau kenyataannya:
800 required 300 Oven 300 Mill 1 200 masih Komponen Masuk
harus dapat dimonitor, maka batch memang diperlukan.
Ini adalah alasan utama keberadaan tabel tersebut, bukan karena database harus dibuat rumit.
8. Hubungan tiga tabel tadi
Sekarang lihat struktur ini:
PRODUCTION ORDER
BRB45021_92093
100 PC
│
│ mempunyai kebutuhan component
▼
PRODUCTION ORDER COMPONENTS
│
├── 92093A = 800
├── 92093B = 400
├── 92093C = 800
└── 92093D = 2400
│
│ aktual produksi
▼
PRODUCTION BATCHES
│
├── 92093A / 500 / Oven
├── 92093A / 300 / Component In
│
├── 92093B / 400 / Mill 1
│
└── ...
Jadi benar:
Untuk monitoring posisi aktual, pusatnya memang production_batches.
Tetapi:
production_orders
adalah apa yang harus diproduksi.
production_order_components
adalah berapa kebutuhan component-nya.
production_batches
adalah di mana barang aktual berada sekarang.
Sedangkan:
process_updates
adalah bagaimana barang tersebut sampai ke posisi sekarang.
Itu empat konsep berbeda.
9. Contoh lengkap dari order sampai monitoring
Mari kita ikuti satu order.
A. Buat production order
Buyer = BRB PO = 45021 Product = 92093 Qty = 100 PC
Sistem generate:
BRB45021_92093
Database:
production_orders id 1001 po_number 45021 order_number BRB45021_92093 buyer_id BRB product_id 92093 total_quantity 100
B. Generate kebutuhan component
Sistem mengambil master components.
Misalnya:
92093A × 8 92093B × 4 92093C × 8
Maka:
production_order_components 92093A → 800 92093B → 400 92093C → 800
C. Monitoring dimulai
Awal:
92093A → 800 → Komponen Masuk 92093B → 400 → Komponen Masuk 92093C → 800 → Komponen Masuk
Ini direpresentasikan sebagai batch.
D. 500 component A masuk Oven 2
Operator pilih:
Order : BRB45021_92093 Component : 92093A - FREM TOP PGR Qty : 500 Tujuan : Oven Oven : Oven 2 Foto : wajib
Maka kondisi menjadi:
92093A 500 → Oven 2 300 → Komponen Masuk
Dan history:
Komponen Masuk → Oven qty = 500 oven = Oven 2 operator = Ahmad foto = ...
E. 500 tadi pindah ke Mill 1
Sekarang:
500 → Mill 1 300 → Komponen Masuk
History bertambah:
Oven → Mill 1 qty = 500
10. Assembly membuat objek monitoring berubah
Ini kasus spesial.
Sebelum assembly kita melacak:
92093A 92093B 92093C ...
Setelah assembly kita tidak lagi mengatakan:
92093A sedang di Rastik
karena barangnya sudah menjadi meja utuh.
Kita mengatakan:
Product 92093 25 PC sedang di Rastik
Contoh:
Component batches
│
│ Assembly menghasilkan 25 PC
▼
Product batch
92093
25 PC
Product batch tadi kemudian bergerak:
Assembly ↓ Rastik ↓ Finishing ↓ Anyaman? ↓ Fitting ↓ Final QC ↓ Packing ↓ Box ↓ Loading
Jadi setelah assembly:
production_batches.subject_type = product
bukan component.
11. Apakah batch_components wajib?
Tabel ini digunakan untuk menjawab:
25 meja yang sekarang ada di Final QC dahulu dibuat menggunakan batch component yang mana?
Misalnya:
Product batch PB-001 25 PC 92093
dibuat dari:
92093A batch #17 92093B batch #21 92093C batch #33
batch_components menyimpan hubungan tersebut.
Untuk sistem monitoring sederhana, ini sebenarnya bisa dianggap fitur traceability tingkat lanjut.
Jadi kalau Anda ingin versi pertama lebih sederhana, tabel ini bisa tetap disiapkan di ERD tetapi pemakaiannya baru kita aktifkan ketika flow Assembly sudah benar-benar dipahami.
12. Mengenai nomor PO
Saya setuju desainnya kita ubah menjadi:
production_orders ------------------ id buyer_id product_id po_number order_number total_quantity ...
order_number dibuat otomatis:
{buyer_code}{po_number}_{product_code}
Contoh:
BRB45021_92093
Saya juga lebih suka menyimpan po_number secara terpisah, jangan hanya terkandung di order_number.
Karena nanti pencarian:
Cari PO 45021
menjadi mudah.
Soal constraint, kalau perusahaan sudah memastikan PO number benar-benar unik secara global, kita bisa:
po_number UNIQUE
Tetapi ada pertimbangan scalability.
Kalau suatu hari finance mengatakan:
PO 45021 - 100 PC product 92093 - 50 PC product 86WG
maka production monitoring mungkin menghasilkan:
BRB45021_92093 BRB45021_86WG
Pada kondisi itu, po_number tidak bisa lagi unique di production_orders.
Karena Anda ingin sistem scalable, saya lebih menyukai:
order_number UNIQUE
dan:
INDEX po_number
sementara aturan PO unik bisa divalidasi aplikasi untuk scope sekarang.
Nanti ketika ada sales_orders, justru:
sales_orders.po_number
yang menjadi unique.
13. Saya juga ingin mengoreksi satu hal ERD sebelumnya
Saya sebelumnya menjadikan:
product_process_configs - uses_anyaman - anyaman_position
sebagai konfigurasi product.
Setelah pembahasan sekarang, menurut saya kita jangan terlalu banyak memasukkan konfigurasi route terlebih dahulu sampai kita tahu apakah route memang sifat tetap product atau dapat berubah per order.
Jadi untuk pemahaman ERD sekarang, sementara fokus saja pada:
Master ↓ Production Order ↓ Requirement ↓ Batch ↓ History
Baru percabangan route kita bahas setelah konsep monitoring ini sudah terasa natural.
Ringkasnya
Kalau saya sederhanakan seluruh desain menjadi satu gambar mental:
BUYER │ PRODUCT │ ├──────── COMPONENT MASTER │ ▼ PRODUCTION ORDER BRB45021_92093 100 PC │ ▼ PRODUCTION ORDER COMPONENTS "Kebutuhan" │ ├── A = 800 ├── B = 400 └── C = 800 │ ▼ PRODUCTION BATCHES "Posisi aktual" │ ├── A / 500 / Oven 2 ├── A / 300 / Komponen Masuk ├── B / 400 / Mill 1 └── ... │ ▼ PROCESS UPDATES "History" │ ├── Component In → Oven ├── Oven → Mill 1 ├── Mill 1 → Mill 2 └── ...
Sedangkan:
monitoring_processes
hanya berisi kamus/master tahapan produksinya, bukan history.
Menurut saya sebelum kita mengubah ERD lagi, ada satu keputusan bisnis yang paling menentukan: apakah dalam satu kebutuhan component, misalnya 92093A = 800 PC, memang mungkin secara aktual 500 berada di Oven sementara 300 masih di proses sebelumnya. Kalau jawabannya ya, production_batches sangat berguna dan desain tadi masuk akal. Kalau jawabannya tidak pernah perlu dimonitor sedetail itu, saya justru akan menyederhanakan ERD dan menghapus lapisan batch yang sekarang membuat desain terasa berat.