BOM di ERP Manufaktur: Struktur Multi-Level, Scrap, dan Dampaknya pada HPP

1. Apa Itu BOM dan Kenapa Ia Menentukan Semua Modul Lain

Bill of Materials (BOM) adalah daftar resmi bahan, komponen, dan jumlah yang dibutuhkan untuk menghasilkan satu unit produk jadi. Dalam praktik pabrik, BOM bukan lampiran teknis yang berhenti di meja desain. Ia adalah titik temu tiga kepentingan yang biasanya bekerja terpisah: tim desain (apa yang harus dibuat), tim produksi (bagaimana membuatnya), dan tim keuangan (berapa biayanya).

Itulah sebabnya BOM sering disebut tulang punggung data manufaktur. Saat BOM benar, sistem dapat menghitung kebutuhan bahan, mengusulkan pembelian, dan membentuk harga pokok tanpa hitungan manual. Saat BOM salah atau tidak lengkap, kesalahannya menular ke seluruh sistem: pembelian memesan bahan yang keliru, gudang mencatat pemakaian yang tidak sesuai kenyataan, dan laporan harga pokok dibangun di atas angka yang keliru sejak awal.

Artikel ini fokus pada satu modul itu. Untuk gambaran modul ERP manufaktur secara keseluruhan, mulai dari panduan ERP untuk perusahaan manufaktur. Bila konsep dasarnya belum jelas, pahami dulu apa itu ERP dan mengapa ia berbeda dari sekadar software akuntansi.

2. BOM Satu Tingkat vs BOM Multi-Level

BOM satu tingkat hanya mendaftar komponen langsung untuk satu produk jadi. Cara ini bekerja pada produk sederhana, tetapi mulai runtuh begitu produk Anda mengandung sub-rakitan yang diproduksi sendiri.

Contohnya sederhana. Sebuah meja terdiri dari papan, rangka, dan sekrup. Namun rangka dirakit lebih dulu dari pipa, sambungan las, dan cat. BOM satu tingkat akan memaksa Anda mendaftar pipa dan cat sebagai komponen meja, padahal keduanya sebenarnya milik rakitan rangka. Akibatnya, ketika desain rangka berubah, Anda harus memperbaiki dua tempat sekaligus - dan salah satunya pasti terlupakan.

BOM multi-level menyusun hubungan induk-anak secara bertingkat: produk jadi, sub-rakitan, komponen, lalu bahan baku. Bentuk inilah yang membuat sistem dapat menjawab pertanyaan yang paling sering muncul di PPIC: kalau saya memproduksi 100 unit, berapa pipa yang harus dibeli? Jawabannya dihitung dengan menelusuri setiap tingkat, bukan direkap manual di spreadsheet.

Tanda Anda sudah membutuhkan multi-level: ada minimal satu komponen yang diproduksi sendiri, bukan dibeli langsung. Selama seluruh komponen dibeli dari pemasok, BOM satu tingkat biasanya masih memadai.

3. Anatomi Satu Baris BOM: Kolom yang Tidak Boleh Kosong

Satu baris BOM terlihat sederhana, tetapi kelengkapan kolomnya yang menentukan apakah sistem bisa bekerja otomatis. Kolom yang sebaiknya selalu terisi:

• Kode produk jadi (induk) - pada versi dan revisi tertentu, bukan hanya nama produk.
• Kode komponen (anak) - harus menunjuk master data yang sama dengan yang dipakai gudang dan pembelian.
• Jumlah per unit (quantity per) - memakai satuan yang konsisten antar bagian.
• Satuan ukur - satuan pemakaian dan satuan pembelian sering berbeda; konversinya harus didefinisikan, bukan diperkirakan.
• Tingkat sisa bahan (scrap) - dibahas pada bagian berikutnya.
• Tanggal berlaku - kapan komponen mulai dipakai dan kapan berhenti, agar BOM lama tidak ikut terpakai.
• Acuan operasi - di stasiun atau urutan kerja mana komponen itu diserap.

Kolom yang paling sering dibiarkan kosong adalah satuan dan tanggal berlaku. Keduanya terlihat sepele sampai produksi berjalan dan sistem mengurangkan stok dengan satuan yang salah.

4. Scrap, Yield, dan Kenapa Kebutuhan Bahan Selalu Lebih Besar

BOM teoretis menghitung bahan untuk produk yang sempurna. Kenyataannya selalu ada bahan yang terbuang, rusak, atau tidak lolos pemeriksaan. Karena itu jumlah di BOM tidak boleh diperlakukan sama dengan jumlah bahan yang harus dipesan.

Dua istilah yang perlu dibedakan:

• Scrap (tingkat sisa bahan) - tambahan yang dipakai sistem saat menghitung kebutuhan. Bila satu unit butuh 1 kg dan diketahui sekitar 5% terbuang, sistem akan merencanakan sedikit di atas 1 kg.
• Yield (hasil) - banyaknya hasil layak jual dari sejumlah bahan masuk. Proses yang menghasilkan 9 dari 10 bagian punya yield 90%.

Angka scrap dan yield yang realistis berasal dari data historis produksi sendiri, bukan dari angka standar di brosur. Karena itu modul BOM yang baik menyediakan tempat mencatat scrap per komponen dan menyandingkannya dengan konsumsi nyata, sehingga tim bisa melihat komponen mana yang pemborosannya mencurigakan.

Tanpa kolom ini, perusahaan mengompensasi dengan cara paling mahal: memesan bahan lebih banyak dari perhitungan sistem, lalu menyimpan sisa sebagai stok yang tidak pernah dihitung akurat.

5. Phantom BOM dan Barang Setengah Jadi

Di lantai produksi ada rakitan yang secara fisik tidak pernah punya nomor stok: begitu komponennya dirakit, ia langsung menuju proses berikutnya tanpa disimpan sebagai persediaan. Di banyak ERP hal ini dimodelkan sebagai phantom BOM - rakitan yang melebur ke induknya saat kebutuhan bahan dihitung.

Memilih antara phantom dan barang setengah jadi nyata bukan soal selera, melainkan soal apakah rakitan itu perlu dihitung stoknya:

• Bila rakitan selalu langsung dipakai dan tidak pernah disimpan, ia cocok dimodelkan sebagai phantom agar perhitungan kebutuhan bahan tetap rata.
• Bila rakitan disimpan, dijual terpisah, atau menumpuk di antara dua proses, ia sebaiknya menjadi barang setengah jadi dengan nomor stok sendiri.

Salah memilih di sini membuat laporan persediaan menampilkan stok yang tidak pernah ada di gudang, atau sebaliknya menyembunyikan tumpukan barang setengah jadi yang mengikat modal kerja.

6. Perubahan Desain dan Revisi BOM

BOM berubah. Pemasok komponen berganti, spesifikasi bahan disesuaikan, komponen lama digantikan penggantinya. Bila perubahan ini tidak terkontrol di sistem, pabrik akan memproduksi campuran produk cara lama dan cara baru tanpa menyadarinya.

Kemampuan minimum yang perlu diuji:

• BOM punya versi, dan setiap versi terikat pada produk yang dihasilkan. Produk lama tetap dibuat dengan BOM lamanya.
• Perubahan menuju persetujuan (engineering change) dapat dilacak: siapa mengubah, kapan, dan atas dasar apa.
• Sistem dapat menunjukkan produk mana yang masih memakai komponen lama, sehingga pembelian tidak memesan komponen yang sudah tidak terpakai.
• Rencana produksi yang sedang berjalan tidak berubah diam-diam ketika BOM diperbarui.

Tanpa kontrol versi, pertanyaan sederhana dari pelanggan - produk kami ini dibuat dengan komponen yang mana - tidak dapat dijawab dengan pasti. Ini persoalan serius pada produk yang diatur mutunya, misalnya yang menuntut penelusuran nomor batch.

7. Bagaimana BOM Menentukan Harga Pokok Produksi

BOM adalah pintu masuk bahan ke dalam perhitungan harga pokok produksi (HPP). Ketika BOM terhubung dengan harga komponen dan urutan operasi, sistem dapat menyusun harga pokok secara otomatis:

• Biaya bahan - kuantitas per unit dikalikan harga komponen, termasuk dampak scrap.
• Biaya tenaga kerja langsung - waktu operasi dikalikan tarif kerja di tiap stasiun.
• Biaya overhead - tarif per jam mesin atau per unit, dibebankan mengikuti urutan produksi.

Bila ketiga lapis ini hidup di dalam sistem, tim keuangan tidak perlu menghitung biaya per produk secara manual setiap kali harga bahan berubah. Yang tersisa adalah pemeriksaan kewajaran: membandingkan harga pokok standar dengan realisasi produksi, lalu menyelidiki selisih yang muncul.

Sebaliknya, bila BOM hanya disimpan di dokumen terpisah, HPP akan selalu menjadi proyek bulanan yang menyita waktu, dan hasilnya baru diketahui lama setelah keputusan harga diambil. Perbedaan cara kerja inilah salah satu alasan perusahaan naik dari software akuntansi ke ERP, sebagaimana dibahas pada ERP versus software akuntansi.

8. Kesalahan Umum dalam Mengelola BOM

• Master data tidak disamakan lebih dulu. BOM dibangun dari kode komponen yang berbeda dari yang dipakai gudang; selisihnya permanen.
• Satuan tidak konsisten. Satu komponen tercatat dalam gram di desain dan kilogram di pembelian.
• Struktur terlalu dalam atau terlalu rata. Terlalu dalam membuat perhitungan rumit tanpa manfaat; terlalu rata menyembunyikan hubungan antar komponen.
• Scrap diabaikan. Perhitungan kebutuhan bahan selalu kurang dari kenyataan lapangan.
• Tidak ada kontrol versi. BOM lama dan BOM baru dipakai bercampur setelah perubahan desain.
• BOM diperlakukan sebagai dokumen desain saja. Perubahan dilakukan tanpa memberi tahu pembelian dan keuangan, sehingga HPP tertinggal dari kenyataan.

9. Cara Menguji Modul BOM Sebelum Membeli ERP

Alih-alih menilai dari daftar fitur, uji dengan satu produk nyata dari pabrik Anda sendiri:

1. Pilih satu produk dengan struktur paling rumit, idealnya yang mengandung sub-rakitan buatan sendiri.
2. Masukkan BOM produk itu ke sistem, termasuk tingkat, satuan, dan persentase scrap.
3. Minta sistem menghitung kebutuhan bahan untuk pesanan 100 unit, lalu bandingkan dengan hitungan tim produksi Anda.
4. Ubah satu komponen pada sub-rakitan, lalu periksa apakah kebutuhan induk ikut menyesuaikan tanpa perbaikan manual.
5. Minta sistem menampilkan harga pokok produk itu langsung dari BOM, bukan dari hasil ekspor ke spreadsheet.
6. Sertakan operator dan staf PPIC dalam pengujian, bukan hanya manajer.

Uji ini memakan waktu satu hingga dua hari, tetapi jauh lebih murah daripada menemukan kelemahan modul setelah kontrak ditandatangani dan produksi berjalan. Kerangka pengujian serupa dipakai ImpactLabs saat memetakan kebutuhan sistem di layanan implementasi ERP.

10. Kesimpulan

BOM bukan daftar bahan yang berhenti di dokumen desain. Ia adalah struktur data yang menghubungkan desain, produksi, pembelian, dan keuangan. Bila strukturnya benar - multi-level sesuai kebutuhan, satuan konsisten, scrap realistis, dan versinya terkontrol - seluruh modul manufaktur di atasnya akan bekerja dari angka yang sama. Bila BOM salah, modul lain hanya mempercepat penyebaran angka yang keliru.

Mulailah dari satu produk yang paling rumit. Rapikan BOM-nya di sistem, lalu bandingkan hasil perhitungannya dengan kenyataan di lantai produksi. Selisih yang muncul di situ adalah daftar pekerjaan paling jujur, dan paling murah untuk dikerjakan lebih dulu.