NCR cho tóc giả không phù hợp: từ phát hiện tới disposition và đóng bằng chứng

Một sản phẩm không phù hợp không chỉ cần một nhãn “FAIL”. Nếu material, WIP hoặc thành phẩm bị phát hiện lệch specification nhưng record chỉ ghi vài chữ trong chat hoặc trên tờ giấy rời, team rất khó trả lời những câu hỏi quan trọng: phạm vi bị ảnh hưởng là bao nhiêu, hàng đang nằm ở đâu, ai có quyền quyết định rework, liệu lô đã shipment chưa, action nào cần xác minh và khi nào có thể đóng sự việc. Nonconformance Report (NCR) tạo cấu trúc cho toàn bộ chuỗi đó.

NCR không đồng nghĩa CAPA. Một NCR ghi nhận và quản lý một nonconformance cụ thể; CAPA chỉ cần mở khi risk, recurrence hoặc systemic evidence cho thấy cần điều tra và corrective action sâu hơn.

Trong sản xuất tóc giả OEM, NCR có thể bắt đầu từ incoming hair lot lệch tone, lace sai revision, base dimension ngoài tolerance, crown direction sai, density không đạt approved sample, barcode/label mismatch, packaging thiếu phụ kiện hoặc final inspection phát hiện workmanship lỗi. Quy trình NCR tốt giúp team containment sớm, bảo toàn evidence và đưa ra disposition có thẩm quyền.

1. Khi nào nên mở NCR?

NCR thường cần khi một requirement đã được xác định và item thực tế không đáp ứng requirement đó. Requirement có thể đến từ specification, drawing, approved sample, visual standard, packaging BOM, PO, label artwork hoặc process control.

Không nên mở NCR cho mọi observation nhỏ chưa chắc là requirement violation. Với borderline condition, trước hết dùng escalation/second review để xác định trạng thái. Nếu kết luận nonconforming, NCR mới là record chính thức.

Ngược lại, đừng tránh mở NCR chỉ vì lỗi có thể “sửa nhanh”. Nếu item đã fail checkpoint và cần rework, việc giữ original failure rất quan trọng cho FPY, Pareto và trend.

2. Một NCR tối thiểu cần những trường nào?

Một record thực dụng thường có: - NCR ID; - date/time; - reporter; - process/location; - brand/customer nếu cần; - model/SKU; - lot/PO; - revision; - quantity inspected; - quantity affected; - defect code; - requirement; - actual observation; - evidence; - containment status; - disposition; - approver; - reinspection; - closure.

Không phải form càng dài càng tốt. Mỗi field phải phục vụ traceability hoặc decision.

3. Requirement phải được ghi cụ thể

Câu “không đẹp” không đủ làm basis.

NCR nên chỉ rõ requirement: - lace color reference R04; - base width 15.0 ± 0.3 cm; - barcode phải match SKU; - approved crown whorl sample; - packaging BOM revision; - hair length method.

Khi requirement rõ, reviewer có thể kiểm lại mà không cần hỏi người lập NCR ban đầu.

4. Actual condition phải quan sát được

Ghi “lệch specification” vẫn quá chung. Hãy mô tả actual: - measured 15.6 cm; - barcode scans as SKU X instead of Y; - 4/20 units show loose seam at left temple; - visual tone outside approved swatch under standard light.

Nếu dùng ảnh, mỗi ảnh cần link tới item/lot và thời điểm phù hợp.

5. Containment trước root cause

Khi lỗi phát hiện, mục tiêu đầu tiên là ngăn item nghi ngờ tiếp tục đi qua process hoặc shipment.

Containment có thể gồm: - HOLD bin; - quarantine; - stop issue material; - isolate WIP; - block shipment; - search same lot; - identify downstream quantity.

Đừng chờ root cause rồi mới containment.

6. Xác định affected scope

Một NCR tốt không chỉ ghi “5 unit fail”. Cần biết còn bao nhiêu unit/material có cùng risk.

Hỏi: - cùng material lot? - cùng operator/setup? - cùng time window? - cùng label batch? - cùng supplier shipment? - đã split/merge vào lot nào? - có shipment trước đó không?

Affected scope quyết định containment và sampling mở rộng.

7. Last known good

Nếu lỗi xuất hiện trong process sequence, xác định last known good giúp giới hạn scope.

Ví dụ QC phát hiện unit #80 fail, nhưng #60 là lần check cuối PASS. Nếu không có evidence giữa #61–79, scope có thể cần giữ toàn bộ window đó.

Sequence tracking làm NCR mạnh hơn một record đơn vị riêng lẻ.

8. Quarantine status

Item NCR cần trạng thái physical + digital rõ.

Không để item fail cạnh stock good chỉ có sticky note. Nếu system có HOLD status, transaction phải bị block theo rule.

NCR ID nên xuất hiện trên quarantine tag hoặc link để warehouse/production biết lý do.

9. Defect code và severity

Defect code giúp trend; severity giúp reaction.

Ví dụ label wrong SKU có thể severity khác một flyaway minor. Nhưng severity phải theo definition, không tự tăng/giảm để đạt AQL.

Nếu severity chưa rõ, route second review.

10. Disposition là gì?

Disposition trả lời “làm gì với item cụ thể này”, không nhất thiết giải quyết root cause.

Các lựa chọn: - rework; - repair nếu system định nghĩa riêng; - scrap; - return supplier; - sort; - use-as-is với concession; - reclassify; - further evaluation.

Mỗi loại cần authority.

11. Ai có quyền disposition?

Một operator không nên tự quyết use-as-is ngoài specification.

Authority matrix có thể: - minor standardized rework: line Quality; - material return: Quality + Sourcing; - use-as-is customer requirement: buyer/customer approval; - scrap high-value: Quality + Operations/Finance theo policy.

NCR phải lưu người quyết định và timestamp.

12. Rework trong NCR

Nếu disposition REWORK, NCR cần link controlled rework instruction, operator, quantity và reinspection.

Original FAIL không được overwrite.

Sau rework, unit có thể final PASS nhưng history vẫn cho thấy first-pass failure.

13. Sorting

Khi scope chưa rõ, 100% sort có thể là containment/disposition tạm.

Sort plan cần: - characteristic; - inspector qualification; - marking good/fail; - quantity balance; - sampling verification nếu có.

Đừng chỉ ghi “đã sort xong” không evidence.

14. Use-as-is và concession

Nếu item không đạt requirement nhưng buyer chấp nhận trong phạm vi cụ thể, record cần: - concession ID; - affected lot/qty; - expiry; - condition; - approver.

Không biến concession một lần thành rule mới.

Nếu condition lặp, cần change control hoặc corrective action.

15. Return to supplier

Incoming material fail có thể return supplier.

NCR cần giữ: - material lot; - qty; - supplier; - RMA/return reference; - remaining affected stock.

Supplier response có thể link SCAR/CAPA riêng.

16. Scrap

Scrap decision cần quantity reconciliation.

Item scrap phải được control đến khi disposition thực sự hoàn tất, không chỉ đổi status.

Nếu material có brand label, destruction method có thể quan trọng.

17. Root cause có luôn nằm trong NCR?

Tùy hệ thống. Minor isolated NCR có thể không cần formal root-cause analysis. Repeated/high-risk NCR nên link 8D/CAPA.

NCR có thể có preliminary cause nhưng không nên ép người lập đoán root cause để đóng form.

Truthful “cause pending” tốt hơn cause giả.

18. Trigger CAPA

Các trigger có thể: - critical defect; - customer escape; - repeat same defect; - threshold frequency; - systemic control failure; - audit trend; - high CoQ.

Không phải mọi NCR = một CAPA.

Điều này giữ CAPA focus.

19. Evidence trước rework

Ảnh hoặc measurement trước rework có giá trị vì sau khi sửa, original condition có thể biến mất.

Với defect visual, chụp: - overall; - detail; - scale/reference nếu cần.

Không dùng ảnh marketing.

20. Evidence sau rework

Sau rework, evidence phải chứng minh acceptance criteria đạt.

Có thể là: - measurement; - scan; - photo; - inspection record; - second reviewer.

Không cần photo mọi minor case nếu system không yêu cầu, nhưng evidence phải tương xứng risk.

21. Closure criteria

NCR chỉ nên close khi: - quantity reconciled; - disposition complete; - reinspection done nếu cần; - affected stock controlled; - required CAPA/SCAR linked; - records complete.

Không close chỉ vì “shipment cần chạy”.

22. NCR aging

Theo dõi open NCR age giúp thấy bottleneck.

Một NCR chờ disposition quá lâu khóa inventory và capacity.

Dashboard có thể hiển thị: - <3 days; - 3–7; - >7; - overdue by owner.

Threshold theo business.

23. Reopen NCR

Nếu closure evidence sai hoặc defect tái phát trong same scope, NCR có thể reopen hoặc mở linked NCR mới theo policy.

Giữ audit trail.

Không xóa closure cũ.

24. NCR và lot release

Nếu NCR ảnh hưởng lot đang chờ final release, publication/release gate phải biết.

Lot không được PASS chỉ vì phần lớn unit tốt nếu unresolved NCR nằm trong release scope.

Một release exception cần explicit disposition.

25. NCR và supplier scorecard

Incoming/supplier-caused verified NCR có thể feed scorecard.

Nhưng đừng charge supplier khi cause chưa verified.

Tách defect source khỏi root cause.

26. NCR và CoQ

Rework minutes, scrap, sorting và logistics từ NCR có thể feed Cost of Quality.

NCR ID là key để tránh double-count.

Không cần mọi NCR có currency ngay từ đầu; hours/qty cũng hữu ích.

27. NCR và change-point

Nếu defect xuất hiện ngay sau material/method/tool change, link change-point ID.

Điều này tăng tốc investigation.

Sau corrective action, enhanced checks có thể chạy cho next lots.

28. NCR và Andon

Andon event có thể là nguồn phát hiện, NCR là formal quality record.

Không cần NCR cho mọi andon nếu condition được xác nhận conform. Khi nonconformance được xác nhận, link event → NCR.

Hai system không nên tạo duplicate records không relation.

29. NCR cho label mismatch

Ví dụ packing scan thấy wrong barcode.

Containment: - stop label line; - HOLD units since last verified scan; - lock print queue; - reconcile label stock.

NCR ghi actual scan data. Disposition có thể relabel + 100% rescan. Closure cần quantity match.

30. NCR cho hair color mismatch

Incoming hair lot lệch approved swatch.

Containment: - HOLD whole lot; - trace issued quantity; - HOLD WIP using lot; - compare under standard lighting.

Disposition có thể return, sort, blend only if approved, hoặc concession. Không tự trộn để “giảm lệch”.

31. NCR cho base dimension

Measurement fail phải kiểm measurement system trước khi kết luận toàn lot.

Xác nhận tool/calibration/method. Sau đó expand sample.

Nếu fail verified, containment affected WIP.

32. NCR cho workmanship visual

Borderline visual cần standard/reference và second reviewer.

Nếu standard ambiguity là nguyên nhân, action có thể là update workmanship standard.

NCR vẫn ghi product disposition riêng.

33. Data integrity

NCR fields không nên sửa âm thầm sau approval.

Nếu quantity/scope thay đổi, giữ change history.

Electronic system cần audit trail.

34. Duplicate NCR

Khi nhiều inspectors phát hiện cùng incident, tránh mở 10 NCR tách nếu chúng thuộc một common event.

Có thể dùng parent NCR + affected records.

Nhưng nếu source/lot khác, không gộp chỉ để giảm số NCR.

35. Multi-brand context

Nếu cùng owner image/product family nhưng brand inventory riêng, NCR phải giữ brand scope.

Không tự suy một brand fail = brand kia fail nếu stock/lot khác. Nhưng nếu common source lot, investigation có thể mở cross-brand containment có evidence.

36. KPI không nên khuyến khích giấu lỗi

“Giảm số NCR” là KPI nguy hiểm nếu làm team ngại report.

Tốt hơn theo: - repeat NCR; - aging; - closure quality; - escape; - rework cost; - recurrence.

Một hệ thống trưởng thành có thể report nhiều hơn nhưng containment tốt hơn.

37. Audit NCR quality

Audit sample NCR: - requirement clear? - scope đủ? - containment timely? - authority đúng? - evidence trước/sau? - quantity balance? - closure justified?

Điều này đo chất lượng record, không chỉ số lượng.

38. Những lỗi thường gặp

- NCR chỉ ghi “defect”. - Không có requirement. - Không containment. - Qty fail nhưng không qty suspected. - Rework không giữ original fail. - Use-as-is không concession. - Close khi action chưa xong. - Root cause đoán. - Không link lot. - Không audit trail.

39. Checklist một NCR tốt

1. NCR ID. 2. Requirement. 3. Actual. 4. Evidence. 5. Model/lot/revision. 6. Quantity. 7. Containment. 8. Scope. 9. Defect/severity. 10. Disposition. 11. Authority. 12. Reinspection. 13. CAPA link nếu cần. 14. Quantity reconciliation. 15. Closure evidence.

Kết luận

NCR giúp biến một lỗi từ “chuyện xảy ra ở line” thành một quyết định có truy vết. Requirement, actual, containment, scope, disposition và closure evidence phải nối được với nhau.

Khi NCR giữ original failure, quantity balance và authority rõ, dữ liệu trở thành nền cho Pareto, CoQ, supplier scorecard và CAPA. Mục tiêu không phải tăng paperwork, mà là đảm bảo không có item nonconforming quay lại flow chỉ vì thông tin bị rơi giữa nhiều team.