Revisi BOM ERP menjadi rumit ketika pesanan produksi lama masih berjalan sementara desain baru sudah disetujui. Daftar komponen baru mungkin terlihat benar di master data, tetapi itu belum menjawab apakah pesanan yang telah dirilis harus berubah, bagaimana material yang sudah dipotong ditangani, dan kapan perhitungan kebutuhan mulai menggunakan versi berikutnya.
Bill of materials atau BOM menjelaskan susunan material dan komponen untuk suatu produk. Artikel ini membahas effectivity, yaitu batas berlakunya suatu versi, beserta keputusan untuk pesanan terbuka. Fokusnya bukan penelusuran lot setelah produksi, melainkan pemilihan acuan sebelum serta selama pekerjaan berlangsung.
Versi Terbaru Tidak Selalu Menjadi Versi yang Benar
Bayangkan produk ilustratif P-100 memakai bracket revisi A. Engineering menyetujui revisi B, tetapi pelanggan tertentu masih menerima konfigurasi A dan sebagian produksi telah dimulai. Jika sistem selalu mengambil BOM terakhir, kebutuhan material dapat berubah tanpa keputusan operasional. Sebaliknya, mempertahankan versi lama untuk semua pesanan akan menghambat transisi yang memang sudah disetujui.
Rancangan ERP perlu menentukan konteks pemilihan: produk, lokasi, tanggal atau titik proses yang relevan, konfigurasi, dan pesanan yang mendapat pengecualian. Jangan menyimpulkan bahwa satu tanggal berlaku global cocok untuk semua pabrik. Ketersediaan tooling, material, serta persetujuan pelanggan dapat berbeda.
Dokumentasi Microsoft mengenai engineering versions menjelaskan pengelolaan versi produk engineering dan data engineering terkait. Referensi ini menunjukkan bahwa versi merupakan objek yang perlu dikelola; aturan effectivity di bawah adalah usulan desain proses yang harus dicocokkan dengan ERP yang digunakan, bukan ringkasan fitur universal.
Definisikan Apa yang Disebut Berlaku
Pilih Titik Penetapan Versi
Perusahaan dapat menetapkan versi saat pesanan dibuat, saat direncanakan, atau saat dilepas ke produksi. Pilihan ini mempunyai konsekuensi. Jika ditetapkan saat pembuatan, pesanan berumur panjang perlu ditinjau sebelum rilis. Jika ditetapkan saat rilis, perencanaan awal perlu mengetahui bahwa estimasi material belum final. Pilih satu aturan dasar dan dokumentasikan pengecualian.
Tanggal order tidak boleh otomatis dianggap tanggal mulai produksi. Tanggal server juga tidak cukup jika pabrik bekerja di zona waktu berbeda. Tentukan apakah batasnya berupa tanggal lokal, waktu tertentu, nomor pesanan, atau keputusan eksplisit pada kumpulan pesanan. Hindari aturan implisit yang hanya dipahami pembuat sistem.
Cegah Rentang yang Tumpang Tindih
Jika dua versi aktif untuk konteks yang sama, sistem perlu aturan seleksi yang dapat dijelaskan. Jika tidak ada versi yang cocok, proses sebaiknya berhenti untuk penilaian, bukan memilih versi terdekat secara diam-diam. Uji batas sebelum dan sesudah cutover, termasuk tanggal tepat saat pergantian.
Catat revisi BOM bersama routing atau instruksi proses yang dipakai. Komponen baru mungkin membutuhkan operasi tambahan atau parameter berbeda. Mengubah material sambil mempertahankan instruksi lama dapat menghasilkan pesanan yang konsisten secara administratif tetapi tidak siap dilaksanakan.
Kelompokkan Pesanan Terbuka Sebelum Cutover
- Belum dirilis: dapat menjadi kandidat perencanaan ulang setelah penilaian kebutuhan dan jadwal.
- Sudah dirilis, material belum dikeluarkan: perlu keputusan perubahan reservasi, dokumen produksi, dan komunikasi operator.
- Material sudah dikeluarkan: perlu penilaian terhadap material fisik, pekerjaan yang telah dilakukan, dan kemungkinan pengembalian atau rework.
- Produksi selesai: perlu keputusan disposisi produk sesuai ketentuan mutu dan komitmen pelanggan.
Klasifikasi tersebut bukan perintah untuk otomatis memindahkan semua pesanan ke revisi baru. Untuk setiap kelompok, tuliskan siapa yang memutuskan, bukti yang diperlukan, serta konsekuensi biaya dan jadwal. Bila keputusan belum tersedia, statusnya harus terlihat sebagai menunggu penilaian.
Pesanan yang sengaja tetap memakai versi lama perlu menyimpan alasannya. Misalnya, konfigurasi telah disetujui pelanggan atau pekerjaan telah melewati titik perubahan yang ekonomis. Keputusan ini harus dapat dilacak tanpa mengubah histori master lama agar terlihat seperti versi baru.
Simpan Acuan Pesanan dan Histori Perubahan
Rancangan yang dapat diaudit menyimpan referensi BOM dan revisi yang digunakan oleh pesanan, waktu pemilihan, serta pihak yang mengesahkan penggantian. Perubahan pada master selanjutnya tidak boleh diam-diam menghapus bukti acuan sebelumnya. Jika pesanan diperbarui, simpan nilai sebelum dan sesudah serta nomor perubahan engineering yang mendasarinya.
Perlu dibedakan antara BOM master, BOM yang diturunkan ke pesanan, dan material aktual yang dikonsumsi. Ketiganya dapat berbeda secara sah karena substitusi yang disetujui atau perubahan lingkup. Sistem harus menjelaskan perbedaannya; menyamakan semua catatan demi laporan yang rapi justru menghilangkan informasi penting.
Untuk pembahasan bukti asal material setelah eksekusi, gunakan panduan traceability lot produksi ERP. Traceability membantu menelusuri apa yang digunakan, sedangkan kontrol revisi membantu menentukan apa yang boleh digunakan. Keduanya saling mendukung dengan pertanyaan yang berbeda.
Material Lama Memerlukan Keputusan Fisik
Revisi baru tidak menghilangkan persediaan versi lama. Buat daftar material yang masih tersedia, terikat PO, sedang dikirim, atau telah menjadi barang dalam proses. QA dan engineering menentukan apakah material masih sesuai untuk penggunaan tertentu; procurement serta finance menilai dampak komersialnya.
Opsi yang dapat dinilai antara lain penggunaan terbatas pada pesanan yang diizinkan, pengembalian ke pemasok bila disepakati, rework dengan instruksi resmi, atau disposisi sesuai kebijakan perusahaan. Jangan memasukkan rekomendasi otomatis scrap sebagai default hanya karena versi berganti. Keputusan material harus berlandaskan fungsi, mutu, kontrak, dan biaya yang nyata.
Untuk perubahan komponen pengganti, cek satuan, jumlah, kehilangan proses, dan hubungan dengan subassembly. Jika satu komponen diganti oleh kit, penggantian kode satu-ke-satu belum tentu cukup. Uji perhitungan kebutuhan dengan contoh pesanan yang telah ditelaah oleh PPIC.
Uji Pemilihan Versi Sebelum Digunakan
Siapkan data uji yang memuat pesanan sebelum batas berlaku, tepat pada batas, dan sesudahnya. Tambahkan pesanan dari lokasi yang belum siap, pesanan dengan pengecualian resmi, serta konteks tanpa BOM aktif. Hasil yang diharapkan harus disepakati sebelum pengembang menjalankan pengujian.
Jalankan pula perubahan setelah pesanan dirilis. Pastikan sistem meminta kewenangan yang sesuai, menampilkan dampak material, dan menyimpan histori. Uji pembatalan perubahan supaya reservasi dan dokumen tidak tertinggal pada versi yang telah dicabut. Bukti uji perlu mencakup layar atau laporan transaksi, bukan hanya pesan sukses.
Jika BOM dikelola di aplikasi engineering terpisah, integrasi harus membawa identitas versi, status persetujuan, dan ruang lingkup berlaku. Sinkronisasi file berhasil tidak membuktikan ERP memilih versi yang tepat. Lakukan pemeriksaan hasil pada pesanan produksi yang menjadi konsumen datanya.
Pemilihan BOM perlu mengikuti kontrol perubahan spesifikasi produk agar persetujuan dan rilis tidak tercampur. Ketika komponen berasal dari pihak luar, hubungkan aturan itu dengan alur perubahan spesifikasi pemasok supaya PO dan dokumen acuan membawa versi yang disepakati.
FAQ Revisi BOM ERP
Apakah Semua Pesanan Harus Diperbarui Ketika BOM Berubah?
Tidak otomatis. Keputusan bergantung pada tahap pekerjaan, dampak teknis, persetujuan pelanggan, dan ketersediaan material. Daftar pesanan terdampak perlu diperiksa serta diberi keputusan yang tercatat.
Apakah Tanggal Berlaku Cukup untuk Mengendalikan Revisi?
Tanggal dapat menjadi bagian aturan, tetapi sering perlu digabung dengan lokasi, konfigurasi, status pesanan, dan pengecualian. Aturan paling sederhana yang benar untuk operasi Anda lebih baik daripada banyak parameter yang tidak dipakai.
Petakan Aturan Sebelum Mengubah ERP
Siapkan satu pasangan BOM lama dan baru, beberapa pesanan terbuka pada tahap berbeda, serta contoh keputusan atas material lama. Telaah kebutuhan melalui layanan ERP dan konteks digitalisasi manufaktur. Diskusikan aturan revisi BOM bersama Layana.ID untuk merumuskan pemilihan versi, pengecualian, dan bukti penerimaan yang dapat diuji.
Contoh P-100 merupakan skenario ilustratif, bukan proyek klien atau hasil implementasi. Gambar utama juga ilustrasi konseptual.