Series Từ số hóa đến AI #27: Giảm lỗi chất lượng bằng dữ liệu có cấu trúc: từ mã lỗi đến hành động CAPA

I. Phân biệt lỗi, triệu chứng, nguyên nhân và xử lý

Đây là điểm nhiều hệ thống dữ liệu bị lẫn.

• Lỗi/defect: biểu hiện không đáp ứng yêu cầu, ví dụ xước, sai kích thước, thiếu chi tiết.
• Triệu chứng: dấu hiệu quan sát được tại hiện trường.
• Nguyên nhân: cơ chế đã được xác nhận gây ra lỗi.
• Containment: hành động tức thời để giới hạn phạm vi ảnh hưởng.
• Disposition: quyết định đối với sản phẩm: rework, scrap, use-as-is theo phê duyệt hoặc xử lý khác.
• Corrective action: hành động loại bỏ nguyên nhân của vấn đề đã xảy ra.
• Preventive/systemic action: hành động giảm khả năng vấn đề tương tự xuất hiện ở nơi khác.

Nếu “thay linh kiện” được ghi ở trường nguyên nhân, nhà máy không biết linh kiện hỏng vì sao. Nếu “công nhân bất cẩn” được dùng như kết luận chung, cơ hội xem lại thiết kế, hướng dẫn, jig hoặc điều kiện công việc bị bỏ qua.

II. Bộ dữ liệu tối thiểu cho một sự kiện chất lượng

Không phải mọi lỗi nhỏ cần toàn bộ quy trình CAPA. Nhà máy nên phân cấp theo mức độ, rủi ro, tần suất và yêu cầu khách hàng.

III. Xây taxonomy và mã lỗi sao cho dùng được

Một danh mục tốt cần đủ chi tiết để phân tích nhưng không quá phức tạp khiến người dùng chọn đại.

Có thể thiết kế nhiều cấp:

1. Nhóm lỗi: ngoại quan, kích thước, chức năng, lắp ráp, vật liệu, đóng gói.
2. Mã lỗi: xước, nứt, thiếu chi tiết, sai chiều, quá kích thước.
3. Vị trí lỗi: bề mặt A, lỗ B, cụm C.
4. Mức độ: theo phân loại nội bộ hoặc yêu cầu áp dụng.

Ví dụ:

Cần có quy tắc owner tạo mã mới, tránh mỗi ca tự bổ sung biến thể. Trường “khác” có thể tồn tại nhưng phải được review định kỳ.

IV. Liên kết lỗi với sản phẩm, công đoạn, máy và ca

Một mã lỗi riêng lẻ chưa đủ. Nhà máy cần biết lỗi xuất hiện trong điều kiện nào:

• Sản phẩm hoặc phiên bản nào?
• Lô vật tư nào?
• Công đoạn nào tạo ra lỗi và công đoạn nào phát hiện?
• Máy, khuôn, jig hoặc dụng cụ nào?
• Ca/kíp, người vận hành hoặc setup nào?
• Có thay đổi thông số, vật tư, PM hoặc chuyển đổi sản phẩm gần đó không?

Điểm phân biệt occurrence point và detection point rất quan trọng. Lỗi có thể được phát hiện ở cuối chuyền nhưng phát sinh ở công đoạn trước. Nếu chỉ gắn lỗi với nơi phát hiện, dashboard có thể dẫn đến ưu tiên sai.

V. Luồng xử lý từ phát hiện đến CAPA

Bước 1: Ghi nhận và phân loại ban đầu

Xác định lỗi, mức độ, phạm vi nghi ngờ và bằng chứng. Dữ liệu ban đầu cần nhanh và đủ để phản ứng, chưa nhất thiết kết luận nguyên nhân.

Bước 2: Containment

Cách ly sản phẩm, dừng công đoạn nếu cần, kiểm tra phạm vi và bảo vệ khách hàng. Ghi rõ ai quyết định, thời gian và số lượng.

Bước 3: Xác nhận phạm vi

Liên kết lô, thời gian, máy, vật tư và sản phẩm để biết vấn đề bắt đầu/kết thúc ở đâu. Đây là điểm dữ liệu truy xuất tạo giá trị lớn.

Bước 4: Phân tích nguyên nhân gốc

Dùng 5 Why, Ishikawa, fault tree hoặc phương pháp phù hợp. Hệ thống nên lưu bằng chứng và giả thuyết bị loại, không chỉ kết luận cuối.

Bước 5: Hành động khắc phục

Mỗi action có owner, deadline, nguồn lực, trạng thái và bằng chứng. Phân biệt sửa sản phẩm hiện tại với sửa nguyên nhân hệ thống.

Bước 6: Kiểm tra hiệu lực

Xác định trước chỉ số và thời gian theo dõi: tỷ lệ lỗi, recurrence, kiểm tra audit, capability hoặc kết quả khác. CAPA chưa hoàn thành nếu chỉ đóng action mà chưa đánh giá hiệu lực.

VI. Dashboard chất lượng nên trả lời câu hỏi gì?

Một dashboard tốt có thể gồm:

• Pareto mã lỗi theo số lượng và chi phí.
• Tỷ lệ lỗi theo sản phẩm, công đoạn, máy, ca và vật tư.
• Occurrence point so với detection point.
• Lỗi mới, lỗi lặp lại và lỗi escape đến công đoạn sau/khách hàng.
• Thời gian containment, RCA và đóng CAPA.
• CAPA quá hạn theo owner và mức độ.
• Hiệu lực hành động sau 30/60/90 ngày.
• Heatmap lỗi theo điều kiện vận hành.
• Drill-down đến lô, hình ảnh, kết quả đo và lịch sử liên quan.

Dashboard cần tách số lượng lỗi và mức ảnh hưởng. Một lỗi hiếm nhưng nghiêm trọng không nên bị chìm dưới lỗi ngoại quan tần suất cao nhưng ảnh hưởng thấp.

VII. Dùng dữ liệu để ưu tiên RCA và CAPA

Không thể làm RCA sâu cho mọi sự kiện. Có thể ưu tiên theo:

• Mức độ an toàn, pháp lý hoặc khách hàng.
• Số lượng và chi phí ảnh hưởng.
• Tần suất và xu hướng tăng.
• Lỗi lặp lại sau hành động trước.
• Escape đến khách hàng hoặc công đoạn sau.
• Không rõ phạm vi truy xuất.
• Liên quan thiết bị hoặc quá trình critical.

Một ma trận severity - occurrence - detectability hoặc risk score có thể hỗ trợ, nhưng cần quy tắc rõ và không thay thế judgment chuyên môn.

VIII. AI có thể hỗ trợ chất lượng ở đâu?

Tùy dữ liệu, AI có thể:

• Phân loại mô tả lỗi hoặc hình ảnh vào nhóm gợi ý.
• Gom các sự kiện tương tự để phát hiện recurrence.
• Tóm tắt lịch sử lỗi của sản phẩm hoặc máy.
• Tìm mối liên hệ giữa lỗi với ca, vật tư, thiết bị và thông số.
• Cảnh báo xu hướng bất thường.
• Gợi ý tài liệu, CAPA hoặc case liên quan.
• Hỗ trợ thị giác máy tính cho một số bài toán kiểm tra.

AI không nên tự kết luận nguyên nhân gốc hoặc tự giải phóng sản phẩm khi chưa có quy trình phê duyệt. Kết quả cần được kiểm chứng bằng dữ liệu và chuyên gia chất lượng/quy trình.

IX. Một ví dụ dữ liệu từ “NG” đến thông tin có thể phân tích

Ghi nhận yếu: “Sản phẩm NG, đã chỉnh máy.”

Ghi nhận tốt hơn:

• Sản phẩm P-102, lot L2407, công đoạn ép, máy M-03, ca 2.
• Lỗi DIM-OVR tại kích thước X, 18/200 sản phẩm.
• Phát hiện tại QC sau công đoạn; khoảng nghi ngờ 14:10-14:45.
• Vật tư lot R-88; khuôn K-03; nhiệt độ cài đặt thay đổi lúc 13:50.
• Containment: dừng, cách ly 320 sản phẩm, kiểm 100%.
• Nguyên nhân xác nhận: cảm biến nhiệt lệch sau thay dây, bằng chứng đối chiếu thiết bị chuẩn.
• Hành động: thay cảm biến, bổ sung kiểm tra sau bảo trì, cập nhật checklist.
• Hiệu lực: theo dõi 10 lô tiếp theo, không recurrence.

Dữ liệu thứ hai cho phép truy xuất, RCA, học lại và đánh giá hành động.

X. Quản trị dữ liệu và trách nhiệm

Chất lượng không thể tự sở hữu toàn bộ dữ liệu. Cần phân vai:

• Sản xuất chịu trách nhiệm bối cảnh lệnh, ca, máy và sự kiện.
• Chất lượng sở hữu taxonomy lỗi, quyết định chất lượng và CAPA workflow.
• Bảo trì cung cấp sự cố, work order và thay đổi thiết bị.
• Kho/mua hàng cung cấp lô vật tư và nhà cung cấp.
• IT hỗ trợ hệ thống, tích hợp, phân quyền và audit trail.
• Process owner phê duyệt định nghĩa và thay đổi quy trình.

Dữ liệu dùng chung cần một nguồn chính thức và ID liên kết.

XI. Những sai lầm thường gặp

• Chỉ ghi OK/NG mà không có mã lỗi.
• Dùng mô tả tự do làm nguồn phân tích chính.
• Gắn lỗi với nơi phát hiện thay vì nơi phát sinh.
• Ghi action ở trường nguyên nhân.
• Đóng CAPA khi action hoàn thành nhưng chưa review hiệu lực.
• Không liên kết lô, máy, ca và vật tư.
• Danh mục quá dài, người dùng chọn “khác”.
• Dashboard chỉ đếm lỗi, không nhìn severity và escape.
• Dùng AI phân loại mà không kiểm tra độ đúng theo nhóm lỗi.

XII. Câu hỏi thường gặp

Có cần CAPA cho mọi lỗi không?

Không. Nhà máy nên có tiêu chí escalation theo mức độ, tần suất, khách hàng, recurrence và rủi ro. Lỗi nhỏ có thể xử lý theo workflow đơn giản hơn.

Mã lỗi nên chi tiết đến mức nào?

Đủ để dẫn đến hành động và phân tích, nhưng không quá chi tiết khiến người dùng khó chọn. Có thể dùng cấu trúc nhiều cấp và review nhóm “khác” định kỳ.

AI có thể tìm nguyên nhân gốc không?

AI có thể gợi ý mối liên hệ và sự kiện tương tự. Nguyên nhân gốc cần được xác nhận bằng bằng chứng, thử nghiệm và người có chuyên môn.

Có nên kết nối dữ liệu chất lượng với CMMS không?

Nên khi lỗi có thể liên quan thiết bị, khuôn, hiệu chuẩn hoặc bảo trì. Liên kết giúp kiểm tra sự cố và thay đổi gần thời điểm phát sinh.