Bantuan › PPAP & SPC

Pemasok Otomotif: PPAP dan SPC

Bengkel yang memasok pabrikan mobil ditanya dua hal terus-menerus: "apakah Anda disetujui membuat part ini?" (PPAP) dan "apakah proses Anda benar-benar sanggup menahan toleransi ini?" (SPC). Panduan ini menjelaskan keduanya dari nol.

1. Apa itu PPAP?

PPAP adalah persetujuan pelanggan yang berkata "Anda boleh memproduksi massal part ini". Memproduksi tanpa itu berarti seluruh kiriman bisa ditolak. Di HNR, PPAP adalah persetujuan berkas: dokumen seperti rencana kendali, FMEA, dan laporan pengukuran dilengkapi dulu, baru keputusan diambil.

2. Alur PPAP: draf → diajukan → disetujui

1. Buka catatan — kode part dan revisi wajib; PPAP diberikan untuk satu revisi tertentu dari part.
2. Daftarkan dokumen wajib — rencana kendali, PFMEA, laporan pengukuran… Mana yang wajib berbeda tiap pelanggan, jadi daftarnya Anda yang tentukan.
3. Saat dokumen selesai, tandai statusnya "selesai".
4. Keputusan diambil manajer. Bila satu saja dokumen wajib kurang, persetujuan ditolak — persetujuan dengan berkas kurang adalah hal yang paling sering diaudit.

3. Apa itu SPC? Toleransi dan batas kendali bukan hal yang sama

Inilah yang paling sering dikacaukan orang yang baru mengenal SPC:

• Toleransi adalah tuntutan pelanggan: "diameter harus antara 9,9 dan 10,1 mm."
• Batas kendali adalah suara proses itu sendiri: "mesin Anda secara alami menghasilkan antara 9,98 dan 10,02."
• Pada grafik toleransi digambar merah dan batas kendali oranye putus-putus. Titik melewati oranye berarti prosesnya berubah; melewati merah berarti partnya afkir.

4. Untuk operator: memasukkan pengukuran

1. Jendela Produksi → tab SPC. Pilih karakteristik yang Anda ukur dari daftar (part + misalnya "Diameter").
2. Ketik nilainya dalam satu kotak, dipisah spasi atau koma: 9,98 9,99 10,01 10,00 10,02. Kelimanya disimpan sebagai satu subgrup.
3. Bila pengukuran milik satu perintah kerja, isi kotak No perintah kerja — baru setelah itu gerbang penghenti berlaku untuk perintah tersebut.
4. Simpan. Bila ada nilai di luar toleransi, peringatannya merah dan menuliskan apa yang harus Anda lakukan.

5. Cp, Cpk, Pp, Ppk — masing-masing mengatakan apa?

6. Apa fungsi tanda "penghenti"?

Ada kotak centang di definisi karakteristik: Penghenti. Secara bawaan mati dan sebaiknya tetap mati — sampai pelanggan menyatakan dimensi itu kritis.

• Mati: pengukuran di luar toleransi hanya dicatat dan muncul di laporan. Produksi tidak berhenti.
• Menyala: bila perintah itu punya pengukuran di luar toleransi yang belum diselesaikan, perintah kerja menjadi berhenti dan konfirmasi tak bisa ditulis. Setelah keputusan dicatat, perintah kembali ke keadaan semula dengan sendirinya — tak ada yang perlu ingat "buka lagi perintahnya".
• Tidak mengukur sama sekali bukan penghalang. Karakteristik yang belum diukur hanya didaftar sebagai peringatan; mewajibkan pengukuran akan mengunci lini di bengkel satu orang.

7. FMEA: kenapa RPN hilang dan diganti AP

FMEA adalah bentuk tertulis dari "apa yang bisa salah, seberapa buruk, apakah kita menangkapnya?". Anda memberi tiga angka: S (keparahan — dampak ke pelanggan), O (kejadian — seberapa sering), D (deteksi — apakah tertangkap). Ketiganya 1-10.

• AP Tinggi (merah): tulis tindakan perbaikan atau tulis alasan tidak bertindak. HNR tidak akan menyimpan baris prioritas tinggi dengan kolom tindakan kosong.
• AP Sedang (amber): tindakan diharapkan tetapi tidak wajib.
• AP Rendah (abu-abu): tindakan opsional.
• DFMEA / PFMEA adalah dua pertanyaan berbeda tentang part yang sama (desain dan proses) dan disimpan terpisah; tidak boleh dicampur.

8. Rencana Pengendalian dan karakteristik khusus (CC / SC)

FMEA menyebut "apa yang bisa gagal"; rencana pengendalian menyebut "di mana, dengan apa, berapa sampel, seberapa sering kita menangkapnya — dan apa yang kita lakukan setelahnya". Setiap baris punya rencana reaksi — kolom yang paling sering dikosongkan dan paling sering ditanya saat audit.

• CC (karakteristik kritis) — dimensi dengan dampak keselamatan atau regulasi. HNR tidak menyimpan baris CC tanpa kaitan ke karakteristik SPC: CC tanpa kaitan hanyalah label, dan sistem tidak bisa bertanya "sudah diukur?".
• SC (karakteristik signifikan) — memengaruhi kepuasan pelanggan atau kesesuaian; kaitan dianjurkan tetapi tidak wajib.
• Tingkat: prototipe · pra-produksi · produksi. Tiga rencana bisa berdampingan untuk satu part; gerbang hanya melihat yang aktif.
• Daftar baris punya tombol CSV untuk lantai produksi. Desain PDF kartu jalan bukan bagian dari putaran ini.

9. Gerbang konfirmasi: apakah baris CC dan AP-Tinggi sudah diukur?

Saat gerbang menyala: bila part perintah kerja punya rencana pengendalian aktif, baris bertanda CC atau terkait baris FMEA AP-Tinggi harus punya minimal satu pengukuran pada perintah itu. Bila tidak, konfirmasi ditolak dan pesannya menyebut karakteristik yang kurang beserta nomornya. Begitu pengukuran dimasukkan, gerbang terbuka sendiri.

Saat gerbang mati, daftar yang sama tampil sebagai indikator: kotak "Pemeriksaan perintah" di tab Rencana Pengendalian menyebut baris CC/AP-Tinggi yang belum diukur, tetapi tidak menghentikan apa pun.

10. MSA (Gage R&R): bisakah kita percaya pengukurannya?

Grafik SPC mengandaikan pengukurannya benar. MSA menguji andaian itu: apakah satu operator mendapat angka yang sama dua kali pada part yang sama (keterulangan, EV), dan apakah dua operator mendapat angka yang sama (reproduksibilitas, AV)?

• Buka studi: alat, karakteristik, part × operator × ulangan (AIAG menyarankan 10 × 3 × 3). Bila toleransi dikosongkan, diambil dari karakteristik SPC.
• Isi kisi lalu tekan Hitung. Kotak hasil menampilkan %EV, %AV, %GRR, %PV, ndc dan basis mana (toleransi atau variasi total) yang dipakai.
• Penerimaan: %GRR < 10 terima · 10-30 bersyarat · > 30 tolak, ditambah ndc ≥ 5. Ambangnya adalah pengaturan (kalite.msa_grr_esik / _iyi / _ndc_alt).
• Angka dari data tipis tidak disembunyikan tetapi tidak disajikan sebagai andal: lencana "DATA SEDIKIT" berada di sampingnya.
• Pada studi atribut sel diisi 1/0; kesepakatan dalam dan antar penilai serta kappa dihitung (≥0,75 terima).

11. Audit pemasok (VDA 6.3) dan kelas A/B/C

Rapor nilai pemasok mengukur apa yang terjadi (dokumen, retur, NCR). Audit menilai prosesnya — proses buruk mungkin belum menghasilkan pengiriman buruk. Keduanya catatan terpisah dan tampil berdampingan di rapor nilai.

• Nilai mengikuti skala VDA: 0 · 4 · 6 · 8 · 10. Tidak ada nilai di antaranya; tidak ada "kesesuaian 6,5".
• Nilai 0 atau 4 adalah temuan: tidak bisa disimpan dengan kolom tindakan kosong. Nilai rendah tanpa tindakan adalah cara termudah membuat audit terlihat "selesai".
• Pertanyaan tak terjawab TIDAK dihitung 0 — tidak masuk penyebut. Persentase adalah persentase dari yang diaudit, dan jumlah yang kosong dilaporkan terpisah.
• Ambang kelas adalah parameter: A ≥ 90, B ≥ 80, di bawahnya C (kalite.denetim_sinif_a / _b). Aturan penurunan kelas milik VDA bergantung spesifikasi pelanggan dan tidak dikarang di sini — persentase elemen ditampilkan terpisah dan keputusannya manusia.
• Teks pertanyaan tidak ditanamkan: katalog VDA 6.3 adalah terbitan berhak cipta. Struktur elemen P1..P7 sudah siap; perusahaan memasukkan pertanyaannya sendiri.
• Audit yang ditutup tidak bisa diubah. Untuk koreksi, buka audit baru; laporan lama tetap dengan tanggalnya.

12. Deklarasi material IMDS, 8D dan EDI

• IMDS — bahan penyusun part (material, nomor CAS, proporsi, gram) dicatat. Digit periksa CAS diverifikasi: CAS yang salah diam-diam menggagalkan pemindaian bahan terlarang. Untuk part dengan BOM, deklarasi dijumlahkan dari komponen; komponen tanpa deklarasi tidak disembunyikan tetapi didaftar sebagai "deklarasi kurang" — penyebab nomor satu penolakan IMDS. Bila ambang ELV (2000/53/EC Lampiran II) timbal/raksa/kadmium/krom heksavalen terlampaui muncul peringatan; produksi tidak berhenti, keputusan pengecualian milik insinyur. XML IMDS resmi di luar lingkup putaran ini.
• 8D — tidak ada tabel baru: catatan NCR/CAPA yang ada sudah memuat separuh 8D (akar masalah = D4, tindakan korektif = D5, penutupan = D8). Enam langkah yang kurang ditambahkan sebagai kolom. Langkah kosong tidak disembunyikan; pada laporan ke pelanggan, langkah yang kurang adalah alasan penolakan. PDF format OEM untuk putaran berikutnya.
• EDI — pesan pesanan/rilis pelanggan diterima sebagai JSON atau CSV dan kolomnya diikat ke kolom kita lewat tabel pemetaan yang didefinisikan perusahaan. Pesan ditulis ke buku integrasi yang ada dan kunci idempotency mencegah satu pesan diproses dua kali. Pemrosesan menghasilkan draf pesanan plus permintaan produksi; tidak membuka perintah kerja dan tidak membebani pelanggan — mengubah draf jadi pesanan nyata adalah keputusan manusia. Baris yang kode partnya tak terpecahkan tidak dilewati; tetap sebagai "tidak cocok". ⚠ Skema segmen EDIFACT/VDA asli OEM tidak dikarang sebelum spesifikasi pelanggan datang; lapisan transport OFTP2/VAN di luar lingkup.

13. Perencanaan multi-pabrik: MRP per pabrik dan e-Kanban

Bila pengepresan, pengelasan, e-coat dan perakitan berada di gedung berbeda, kalimat “ada 500 di seluruh perusahaan” tidak berguna: material bisa kurang di perakitan sementara menumpuk di pengepresan. Karena itu MRP mendapat pemilih cakupan (Produksi › bilah Perencanaan): Umum dan Gudang (keduanya perilaku hari ini) dan Pabrik.

• Pada cakupan pabrik, netting menjumlahkan SEMUA gudang yang dipetakan ke pabrik itu, dan permintaan (perintah kerja terbuka dan permintaan produksi) disaring ke pabrik yang sama. Setiap pabrik melihat kekurangannya sendiri.
• Keanggotaan pabrik tidak disalin ke tempat baru. Diturunkan dari pemetaan gudang (Korporat › Pabrik / Gudang). Satu-satunya kolom baru adalah gudang tujuan permintaan produksi.
• Tidak pernah diam-diam bilang “tidak ada kekurangan” atas himpunan kosong. Jika tidak ada gudang terpetakan, rencana menolak berjalan dan MRP_TESIS_DEPOSUZ meminta Anda memetakannya. Mengirim gudang dan pabrik bersamaan menghasilkan MRP_KAPSAM_CAKISMASI — tidak ada aturan prioritas diam-diam.
• Permintaan tanpa gudang tujuan tidak masuk pabrik manapun; judul rencana menyebutkan berapa yang tertinggal. Pemetaan massal bisa dilakukan dari daftar pilihan ganda di layar Korporat › Pabrik / Gudang.
• Saran pabrik sumber: bila suatu item kurang dan pabrik lain punya kelebihan, pabrik itu ditampilkan pada baris — transfer internal dipertimbangkan sebelum pembelian.

e-Kanban. Untuk satu kartu (item + gudang sumber + gudang tujuan) jumlah kartu dihitung di server: N = ⌈ permintaan harian × hari transit × (1 + margin aman) ÷ jumlah wadah ⌉. Papan menampilkan kartu yang stok tersedianya jatuh di bawah titik pemesanan ulang. Pemicuan melewati jalur transfer yang sudah ada: persetujuan empat mata, dinding pabrik dan gerbang kepemilikan tetap berlaku — kanban tidak melewati satu pun.

Ketiga gerbang mati secara bawaan (Pengaturan › Gerbang keamanan): depo.mrp_transit_arz (apakah barang pada transfer terbuka dihitung sebagai pasokan di MRP), depo.kanban_otomatik (apakah papan hanya menyarankan atau juga membuat instruksi transfer) dan depo.kanban_tesis_disi (bolehkah kanban antar pabrik membawa persetujuan otomatis). Selama yang terakhir mati, kanban antar pabrik berhenti dengan TESIS_TRANSFER_ONAY: pemicu otomatis tidak bisa menembus dinding pabrik sendirian.

14. Portal pemasok subkontrak (/fason)

Subkontraktor tidak punya akun HNR dan memang tidak seharusnya: memberi mereka pengguna ERP salah dari sisi lisensi maupun keamanan. Pola yang dipakai sama dengan portal karyawan dan dealer — tabel identitas terpisah, PIN dan sesi sendiri. Alamatnya /fason; perusahaan yang menentukan nama pengguna dan PIN.

• Hanya catatannya sendiri. Pemasok melihat paket subkontrak, sertifikat akreditasi dan skor audit yang terikat pada kode pelanggannya sendiri. Meminta paket orang lain menghasilkan 404 — 403 akan membocorkan bahwa catatan itu ada.
• Identitas tidak pernah dibaca dari permintaan. Kode pelanggan dicap dari sesi pada setiap panggilan; menulis kode lain di badan permintaan tidak mengubah apa pun.
• Portal tidak membuat pergerakan stok, tidak menerbitkan surat jalan dan tidak mengubah status pengiriman. Pemasok hanya melapor (nomor ASN, lot, daftar serial, berkas laporan pengukuran). Keputusan pengiriman milik pengguna HNR, karena gerbang akreditasi berjalan di sana.
• Kunci PIN bersifat per pengguna: lima percobaan salah mengunci akun itu 15 menit dan pemasok lain di kantor yang sama tidak terpengaruh. “Pengguna tidak ada” dan “PIN salah” memberi pesan sama agar nama akun tidak bisa ditelusuri, sementara log server membedakannya.
• Pertanyaan audit tidak pernah dibagikan. Pemasok melihat skor, kelas A/B/C dan jumlah tindakan terbuka; katalog pertanyaan VDA 6.3 tetap di perusahaan.

Ada dua tingkat gerbang dan keduanya mati secara bawaan: kalite.fason_portal membuka portalnya sendiri (login mendapat 403 PORTAL_KAPALI selama tertutup) dan kalite.fason_portal_asn membuka penulisan (portal hanya-baca selama tertutup). Membaca tidak berisiko; membiarkan pengguna luar menulis baris ke ERP adalah keputusan terpisah.

15. Fase waktu dan kapasitas pabrik: "kapan kurangnya?"

Sampai kini MRP hanya melaporkan satu total kekurangan. Barang yang dibutuhkan enam minggu lagi dan barang yang dibutuhkan minggu ini berada di baris yang sama dengan merah yang sama; perencana tidak dapat tahu mana yang harus dibeli lebih dulu. Ketika gerbang depo.mrp_zaman_fazlama dibuka, permintaan dan pasokan disebar ke ember berdasarkan tanggal jatuh tempo (mingguan atau bulanan, 1–26 ember), saldo kumulatif tiap ember dihitung, dan tanggal kekurangan pertama muncul di baris. Mengklik tanggal itu membuka deret ember: permintaan, pasokan dan saldo per ember.

Kapasitas pabrik. Di samping MRP per pabrik ada tombol “Kapasitas pabrik” (gerbang uretim.tesis_kapasite, bawaan mati). Jumlah sisa perintah kerja terbuka diubah menjadi menit rute (untuk cetakan banyak rongga ⌈jumlah/rongga⌉ × waktu), disebar ke ember menurut tanggal jatuh tempo perintah, dan dibandingkan dengan kapasitas menit mesin yang terhubung ke pabrik. Mesin milik pabrik mana diturunkan dari URT_MAKINE.DEPO lewat pabrik pada kebijakan gudang; tidak ada field pabrik terpisah di kartu mesin, karena menulis fakta yang sama di dua tempat berarti keduanya akan menyimpang.